Centralizált, részben és teljesen elosztott, valamint programozható hálózatokhoz tervezett mobilitás menedzsment sémák analitikus elemzése

Centralizált, részben és teljesen elosztott, valamint programozható hálózatokhoz tervezett mobilitás sémák analitikus elemzése Paróczai Dávid, Bokor László Email: devhawas@gmail.com, bokorl@hit.bme.hu Kivonat - Ezen dokumentumban először néhány mobilitás-kezelő protokoll kerül bemutatásra, ahol a jelenleg használt központosított mobilitás mellett ismertetjük az elosztott alapú, skálázható megvalósítás meghatározó képviselőit, majd kategorizálásra kerülnek ezek az eljárások a főbb mobilitási szempontok szerint. Továbbá létrehozunk egy generikus hálózati topológiát, amely segítségével a különböző mobilitási protokollokat összehasonlítjuk különböző metrikák alapján. A létrehozott modell lefedi a vizsgált mechanizmusok eltéréseit, így lehetőséget nyújt a teljesítmények viszonyának elemzésre, amelyek közül kiemelkedik a skálázhatóság, a mobil eszköz helyzetfrissítése és az üzenetküldés költségének matematikai analízise. Ezt követően a kapott eredményeket kiértékeljük és levonjuk ezek alapján a következtetéseket. Kulcsszavak MIPv6, MIPv6 RO, MIPv6 ERO, CNet, DMM MIPv6, SDN DMM, UFAGW HIP, UFAGW PMIP, OpenFlow I. BEVEZETÉS Az információs rendszerekhez való mobil hozzáférés biztosítására képes technológiák térhódítása a felhasználói készülékek számának növekedését és teljesítménybeli fejlődését vonta maga után [1]. A megjelenő követelmények kielégítése a mobilitási algoritmusok újragondolását igényli, hogy a skálázhatóságnak és méretezhetőségnek is megfeleljenek a protokollok amellett, hogy biztosítják a mobil eszközök kommunikációs kapcsolatainak folytonosságát, azaz új kapcsolódási pontok kommunikációba való bevonását úgy, hogy a korábban kiépített kapcsolatok ne sérüljenek. Ezen kívül biztosítaniuk kell a heterogén struktúrák közötti átjárhatóságot, hogy a hálózatok képesek legyenek egy közös kommunikációs felületen, egymással együttműködve kezelni a mozgó terminálok adatforgalmát, a mobilitás hatásait a felhasználó számára transzparensen megoldva. A hálózatba integrált segítő eszközök különféleképpen konfigurálhatóak és nem egységesek. A központi anchor entitásokra eső terhelés pedig igen csak jelentős, mivel a hálózat peremén nem kerültek szétosztásra a mobilitás ért felelős funkciók. Azonban jelenleg még nincs egy általánosan elfogadott szabvány a szóban forgó feltételek együttes kielégítésére. Sok, egymástól kisebb-nagyobb mértékben eltérő megközelítés jött létre, amelyek más-más módon elégítik ki a mobilitási elvárásokat. A jövő hálózati paradigma középpontjában az egyszerűség és a gyorsaság áll, ahol kulcsfontosságú a protokoll skálázhatósága, átadási hatékonysága, valamint az optimalizált forgalom továbbítása és jelzés késleltetése. Az SDN megközelítés ezeket a problémákat kívánja kijavítani az úgynevezett virtualizáció és magas szintű programozhatóság szemléletmódokat használva [2][3]. Az SDN eljárás növeli a hálózat funkcionalitását, széles absztrakciót biztosít, miközben az adat és a vezérlési síkokat függetleníti egymástól, miközben a mögöttes fizikai hálózat és topológia transzparens marad a felhasználó előtt. Ennek megvalósítása érdekében egy új absztrakciós szintet emel a mechanizmus a hagyományos rendszer architektúrája fölé. Ezáltal a heterogén tulajdonságú hálózati rétegek és szolgáltatások sokszínűségét lefedi egy programozható interfész segítségével, amellyel az erőforrások kihasználtság terheltsége szabályozható. A jelenlegi IP mobilitási sémák elsősorban centralizált és hierarchikus felépítésűek, amelyek a jelentős forgalom növekedés esetén nem hatékonyak, és a jól ismert egyszeres meghibásodási pont (Single Point of Failure) problémáját is felvetik. Ezzel szemben az elosztott vagy részben elosztott mechanizmus használata során az egyes entitások maguk gyűjtik össze a számukra fontos információkat [4]. Ezáltal megbontják az központosított képet, de kiküszöbölik a centralizált megoldásokban megjelenő és a skálázhatósági problémákat felvető anchor csomópontokat. Az elosztott mobilitás alternatívák szétválasztják a vezérlés síkot az adatsíktól, így nagyban növelve a heterogén hálózat agilitását. Ezért ebben a cikkben a centralizált és elosztott mobilitás megközelítéseket hasonlítjuk össze, különös figyelmet fordítva a virtuális és programozható hálózatokban is használható megoldásokra. A cikk második felében olvasható a protokollok rövid leírása az elemzés szempontja szerint, míg a harmadik szakaszban a vizsgálathoz használt generikus modell található. A protokollok helyzetfrissítési mechanizmusainak elemzése a IV. és V. fejezetben olvasható, míg a VI., VII. fejezet a protokollokkal megvalósított üzenetküldési sémák elemzését taglalja, 1

míg a skálázhatósági jellemzők vizsgálatát a VIII. és IX. fejezet foglalja össze. II. MOBILITÁS MENEDZSMENT PROTOKOLLOK Ebben a fejezetben az elemzett centralizált, elosztott és SDN protokollok rövid leírása olvasható, ahol kiváltképp a sémák skálázhatósági jellemzőit, valamint hívásátadási és jelzéskésleltetési jellemzőit szeretnénk kiemelni. A. MIPv6 A centralizált mobilitás egyik legfőbb képviselője a hagyományos MIPv6 protokoll. Központi eleme az otthoni hálózatban lévő honi ügynök (Home Agent, HA) [5], amely nyilvántartja a mobil egység aktuális tartózkodási helyét. A sémában a készülék két címet birtokol. Az első a terminál otthoni címe (HoA), amelyen keresztül mindig elérhető, illetve hálózatváltás esetén az új hálózattól kap egy úgynevezett ideiglenes címet (CoA). A frissen megszerzett, idegen hálózatban érvényes ideiglenes címéről a mobil értesíti honi ügynökét, aki beregisztrálja a HoA-hez tartozó CoA-t. Abban az esetben, ha egy partner csomópont (CN) kommunikálni szeretne a mobil terminállal (MN), akkor az adatokat az MN otthoni címére küldi el. Ezeket a csomagokat a Home Agent egy alagúton keresztül az MN CoA címére juttatja. Ez a háromszögelt küldés (CN->HA- >MN->CN) azonban szuboptimális útvonalat eredményez, és járulékos overheadet okoz: a két csomópont közötti kommunikáció nem optimális útvonalon halad végig, sőt a Home Agent és Mobile Node között alagutazás kiépítése szükséges, illetve a jelzésüzeneteknek relatív hosszú utat kell bejárniuk, ha nagy a HA és MN közötti topológiai távolság. B. MIPv6 Route Optimization (RO) A Route Optimization a MIPv6 szabvány részeként érhető el [5], amely direkt MN-CN kommunikációt akkor is garantálja, ha az MN nem az otthoni alhálózatában tartózkodik, hanem egy idegen tartományban (vagyis kiküszöböli a háromszögelés okozta problémákat). Az MN és CN közti vég-vég kapcsolat létrehozásának fontos követelménye, hogy a kommunikáló partner ismerje a mobil csomópont idegen hálózatbeli címét a közvetlen információcsere megvalósítása érdekében. A két diskuráló fél ezt úgy tudja elérni, hogy az MN hálózatváltás esetén egyaránt értesíti a Correspondent Node-ot és az otthoni ügynökét az érvényes idegen címéről. Ekkor a Mobile Node elküldi az új címét a CNnek, aki eltárolja ezt a bejegyzést a Binding Cache-ben. Tehát CN a csomagküldés megkezdése előtt megvizsgálja a nyilvántartásában lévő regisztrációkat. Ha talál az MNhez tartozó otthoni címmel megegyező bejegyzést, ahol rögzítve lett egy idegen cím, akkor erre a Care-of Address-re küldi ki a csomagokat. Amennyiben nincs egyezés a táblában, akkor pedig az MN HoA-jára küldi el. Amennyiben a CN a Binding Cache-ből kinyert MN idegen címének felhasználásával küld csomagot MN számára, akkor a mobil eszköz nem tudja, hogy neki szól az üzenet, mivel az azonosításhoz a HoA-ját használja. Ennek következtében került bevezetésre az úgynevezett Type 2 Routing Header (T2RH). A T2RH az eddigi routing fejléchez képest egy Home Address mezővel bővítették ki, hogy a kommunikációs partner a mobil eszköz otthoni címét bele tudja injektálni a vevő oldali azonosításhoz. Emellett a csomópontok engedélyezhetik vagy tilthatják az útvonal optimalizálást annak függvényében, hogy el akarják-e titkolni a helyzetüket a másik fél elől. Azonban a T2RH minden csomag esetén 40 byte többletet jelent, amely a csomag tördelését vonhatja maga után (az MTU-k függvényében). Biztonsági kérdések miatt a MIPv6 RO-ba bevezették az úgynevezett Return Routability procedúrát [6]. Az eljárás a mobil eszközhöz tartozó Home Address és a Care of Address címek ellenőrzéséből áll, hogy a kommunikációt vevő csomópont ellenőrizni tudja a küldő IP cím szerinti hitelességét. A HoA cím ellenőrzés esetén a Binding-ot kezdeményező mobilterminál küld egy Home Test Init (HoTI) üzenetet a hozzátartozó Home Agent-jén keresztül, amelyre a CN visszajelez egy HoT üzenettel a küldő HA-ján keresztül. Ezt követően az MN egy Care of Test Init (CoTI) üzenetet küld közvetlenül a kommunikációs partnernek, hogy tényleg az MN birtokolja az adott CoA címet. A frissítés visszaigazolás végett a CN egy CoT üzenetben jelez vissza a küldőnek. A procedúra így nagyban csökkenti a DoS támadások lehetőségét, illetve megelőzi a Flooding/Bombing Attack típusú támadásokat. C. MIPv6 Enhanced Route Optimization (ERO) A MIPv6 RO továbbfejlesztéseként hozták létre az ERO mobilitás sémát [5]. Az Enhanced Route Optimization az úgynevezett Cyptographically Generated Addresses (CGA) alkalmazására épít. Ezen címeket az otthoni címből generálják, oly módon, hogy a mobil csomópont IP címében az alsó 64 bitet kicserélik egy hash függvénnyel előállított bitsorozatra, amelyet a készülék a saját publikus kulcsával hoz létre. Így a kommunikáció során az MN a CN számára elküldi a publikus kulcsát és az azonosításhoz még szükséges paramétereket, ezzel lehetővé teszi a csomópont számára az IP cím tulajdonjogának bizonyítását és az önálló hitelesítést. A Home Test Init és Home Test üzeneteket csak bizonyos esetekben kell használni, mivel a CGA cím kiváltja a mobil csomópont címének hitelesítését, ezáltal alacsonyabb hívásátadási késleltetést érhetünk el. Az első hálózatváltáskor a mobil csomópont elküldi a CGA címét a vele kommunikációt folytató csomópontnak, amivel azonosítja magát a partner előtt. Erre válaszként a Correspondent Node generál egy úgynevezett Permanent Home Keygen Token-t, amit a többi váltás esetén fognak használni az információt cserélő csomópontok. Fontos megemlíteni azt a tényt, hogy a Care of Address idegen hálózatbeli azonosító címet nem titkosítjuk kriptográfiailag a Home Address-hez hasonlóan, hiszen nem sok értelme lenne. Ezzel viszont egy kis nyereséget ér el a protokoll a folyamat késleltetése terén. Így a CoTI és CoT tesztüzenetek segítségével az úgynevezett Care of Keygen Token kerül legenerálásra a CN által az MN számára. A CoKT szerint definiáltak a rendszerben két féle Binding Update üzenet státuszt a szóban forgó token megléte szerint. Az egyik elnevezés a korai BU, míg a másik a teljes BU üzenet. Az első esetben az MN-nek még nincs a birtokában a token, ezért a CN-hez fordulva még meg kell ezt szereznie tőle. Így az általa kiküldött 2

frissítési üzenet nem ellenőrzött állapot megjelöléssel kerül bele a partnere Binding Cache-jébe. Az utóbbi elnevezés pedig azt a változatott takarja, amikor már a mobil csomópont megkapta partnerétől a CoKT-t, ennek következtében a BU üzenete már bekerül teljes jogosultsággal a CN által kontrollált BC-be. D. Corresponding Network Homing A Corresponding Network Homing protokoll a háromszög útvonal mellékhatását hivatott kiküszöbölni oly módon, hogy a Home Agent a Correspondent Node és a Mobile Node közötti közvetlen úton helyezik el [8]. Ennek köszönhetően az IP csomagok természetes útvonalon haladnak végig a két végpont közt. Azonban ez nem lehetséges, ha az MN-t egy fix HoA egyetlen HAhoz köti helyileg. Ezért az MN a CN-hez legközelebb lévő HA-tól kapja meg a HoA-t (nevezhető CHoA-nak is, mivel CN szerint határozzák meg), amelyet használ az egész IP kommunikáció során. Azaz a mechanizmus alkalmazása esetén az MN egy Home Agent-jét helyezzük el a kommunikációs partnerhez közel. Nevezzük ezt az entitást Corresponding Home Agent-nek (CHA), amely lokálisan egy helyen lehet a CN-nel (például CDN szerver), vagy a topológiát nézve a CN oldalon helyezkedik el. Ebben az esetben terhelés kiegyensúlyozó vagy dedikált csomópontként vesz részt a protokoll működésében. Harmadik esetben pedig a CN oldalon lévő ISP szolgálja ki. A CHA telepítése előnyös a Mobile Network Operator szempontjából, mivel tehermentesíti a mobilitás et és az adatátvitelt a maghálózatban. Növeli a felhasználói élményt, mert az átviteli késleltetés csökken, így az MN egy időben több alkalmazás használhat, és mindegyikhez külön egy-egy CHA-t rendelhet annak függvényében, hogy az útvonalak közül az optimálisat érje el, ezzel is növelve a felhasználói QoS-t. E. MIPv6-alapú elosztott mobilitás A centralizált mobilitás kezeléshez képest a MIPv6 elosztott mobilitás megvalósítás rugalmasabb részekre bontja szét a központi horgonypont szerepét [9]. Az optimális útvonal kiválasztásának végrehajtásáért az egyes Mobility Routing-ok (MR) felelnek, miközben a helymeghatározási információkat az MR-hez rendelt Location Managemnet entitás (LM) biztosítja. Így amikor a mobil eszköz megváltoztatja a helyzetét a régi MR-ről az új MR-re, akkor az új MR-nek meg kell próbálnia kinyerni az említett eszköz HoA/HNP konfigurációs állapotát elsőként, majd frissíteni az LM-et az új routing helyzetével. Tehát az MR egy logikai függvény segítségével megnézi, hogy a csomagokat lokálisan merre kell továbbítania. Míg a Home Address Allocation (HAA) az otthoni hálózat prefixumának vagy a Mobile Node otthoni címének elosztását végzi. Továbbá a protokoll működéséhez feltétel, hogy minden a helyi hálózatban résztvevő routerre telepíteni kell ezeket a funkciókat megvalósító függvényeket, illetve a HAA és LM entitásokat kombinált egységként vagy külön-külön is lehet telepíteni a hálózatba, amit az Operating Policy határoz meg. Megjegyzendő, hogy jobb, ha egy adminisztratív domainben több LM kerül telepítésre a sok mobil eszköz miatt, így könnyebben fenntartható a nagymennyiségű információforgalom. Amennyiben az MN CN felé szeretne kommunikációt kezdeményezni, akkor a mobil terminálhoz tartozó MR megnézi, hogy van-e nála CN-re irányuló routing lokalizációs információja. Ha nincs, akkor az MN-hez tartozó LM-hez fordul egy Query üzenetben az MR és LM közti interfészen. Amikor megkapja a válasz üzenetet (Resp), akkor a CN helyére vonatkozó lokális routing információt el kell tárolnia. A rendelkezésre álló információkat felhasználva egy elosztott routing mechanizmust tud létrehozni, amely kiépít egy alagutazást a mobil eszköz MR-je és kommunikációs partner MR-je között, majd a CN-hez tartozó MR IPv6 beágyazással eljuttatja a csomagokat a CN részére. F. PMIP-alapú részben elosztott mobilitás A protokoll magját egy központi kontroller adja, amelyet Central Mobility Database-nek (CMD) nevezünk és a hálózati logika megvalósításért felelős [10][11]. A hagyományos PMIPv6 LMA-val szemben [behivatkozni a PMIPv6 RFC-t] a CMD-n nem továbbít adatokat, viszont képes PBU és PBA üzeneteket küldeni és fogadni. A MAG-ot LMA funkciókkal bővítették, feladata a Binding Cache fenntartása a hozzácsatlakozott MN-nekre nézve, emellett PBU és PBA küldésére és feldolgozására is felkészítették, illetve minden MAAR számára el kell terjeszteni az érvényes BC-t. Minden MAAR egyedülálló globális prefix-szel konfigurálható, ugyanakkor nem lehet átfedés ezek között, a CMD pedig egy átfogó hálózati képet tart fent az aktuális kötésekről. A Central Mobility Database-nek három különböző szerepkörét tárgyaljuk a cikkben: a CMD egy PBU/PBA relé, a CMD egy MAAR lokátor, illetve a CMD egy MAAR proxy. Amennyiben a CMD egy PBU/PBA relé, akkor a mobil csomópont mozgásakor az új MAAR eltárolja az eszköz BCE-jét és küld ennek megfelelően egy PBU regisztrációt a vezérlő egységnek. Amire a kontroller entitás az MN_ID mellé beregisztrálja az aktuális mobil terminál helyét, majd a régi MAAR felé egy PBU-ban feltünteti a mobil eszköz új CoA címét. Ezután a régi MAAR elvégzi a saját Cache-nek a frissítését, majd PBA-val válaszol a vezérlőnek, hogy módosította a mobil csomóponthoz tartozó bejegyzést. A visszaigazolás után a CMD egy új PBA üzenetet küld az új MAAR-nak, hogy létrejöjjön a két MAAR között egy kétirányú alagút a csomagvesztés elkerülése végett. Ha a CMD egy MAAR lokátor, akkor az átadási késleltetés csökkenthető oly módon, hogy a régi MAAR számára engedélyezett PBA visszacsatolást közvetlenül az új MAAR-nak küldjük el. Az eljárás PBU értesítési mechanizmusa megegyezik a CMD PBU/PBA relé konstrukciójával. Azonban a régi MAAR párhuzamosan küldi ki az értesítést a kontrollernek és az új MAAR-nak, így a vezérlő mentesül a PBA továbbítása alól, illetve a szóban forgó MAAR-ok között hamarabb kiépülhet a szükséges alagút a veszteségmentes adattovábbítás miatt. A csomagok küldése változatlan a relé megoldáshoz képest. Harmadik szerepkör esetén a CMD egy MAAR proxyként jelenik meg a hálózatban, ahol az új MAAR PBU jelzéssel értesíti a kontrollert, amikor érzékeli, hogy hozzá csatlakozott a mobil terminál. Ezután a vezérlő leellenőrzi a BCE-t, majd frissíti ennek megfelelően. Ezt követően a CMD párhuzamosan értesíti egy PBU üzenetben a régi MAAR-t a változásról, miközben PBA 3

jelzést küld az új MAAR-nak, amely ezek alapján már el tudja végezni a routing update-t. Miután a régi MAAR is elvégezte a routing update-t, akkor visszajelez egy PBAval a CMD-nek. Valójában, amikor a vezérlő megkapja a PBU-t, az új regisztrációra vonatkozóan, akkor már rendelkezik az összes szükséges információval az új és a régi MAAR eszközök közötti alagutazás kiépítéséhez. G. PMIP-alapú teljesen elosztott mobilitás Amíg a részben elosztott DMM PMIPv6-ban egy központi vezérlő (Központi Mobilitás Adatbázis, CMD) található, addig a teljesen elosztott változatot követő architektúrában ez az anchor csomópont nem jelenik meg. Azonban a vezérlőben definiált funkciók nem hagyhatóak el, ezért a hálózatban résztvevő eszközök szerepkörét ki kell bővíteni a hiányzó mechanizmusokkal [10]. Ebből kifolyólag minden MAAR entitás van egy globálisan irányítható IPv6 előtagokat tartalmazó címtár (prefix pool), melyből a linkjeihez csatalakozó MN-ek számára címet oszthat. Mivel a központi csomópont eltűnt a hálózatból, így minden MAAR eszköznek saját cache táblát kell fenntartania a közvetlenül hozzájuk csatlakozott mobilterminálokról. A MAAR-ba integrált funkciók miatt az adat és a vezérlési síkokat teljes egészében ennek az entitásnak kell kezelnie. Abban az esetben, ha egy MN csatlakozik egy MAARhoz, akkor két fő információt követel meg a MAAR a mobilitás biztosítása és a zökkenőmentes adatáramlás végett: a P-MAAR csomópontok címét, és ha volt meghirdetve előtag, akkor a meghirdetett előtagot. A protokoll ezen folyamatához számos módszert készítettek, amelyek különböző szinteken jelennek meg, viszont a mechanizmus célja minden esetben ugyan az. Egy ilyen működési elvárás, hogy a kapcsolódási cél a handover előtt megismerje a jelenlegi MAAR entitás paramétereit, ahonnan átvándorol majd a mobil készülék, így a mobil kontextus akadálymentesen átvihető. További lehetőség lehet a peer-to-peer megközelítés vagy egy MN-->MAAR kommunikációs protokoll (pl.: IEEE 802.21) alkalmazása. Ezek mellett a teljesen elosztott DMM PMIP koncepció feltételezi, hogy a csomópontok megbízható és biztonságos MAAR-to-MAAR kommunikáció szerint működnek. Ennek következtében optimális útvonal épül ki a MAAR entitásokon keresztül a csomópontok kommunikációja során. H. UFA-HIP A koncepció egy teljesen elosztott architektúrára épít, miközben a HIP szabványra támaszkodva új névteret vezet be a csomópontok elszeparálása érdekében, amelyeket az applikációk a hoszttal való kommunikáció során használnak [12]. Kétféle azonosító fogalmat különböztetünk meg a protokoll működése során. Az első az úgynevezett hoszt azonosító (Host Identifier, HI), a másik pedig a hoszt azonosító címke (Host Identifier Tag, HIT). A HI azonosító egy entitás hivatkozását jelöli, amely egyedien és globálisan azonosít. A HIT ismertetőjel pedig a HI hashelt értéke, amely független a használt kriptográfiai algoritmusoktól és a célcím helyett szerepel a mechanizmus működése során, így növelve a biztonságot és a frissítés gyorsaságát [13][14]. Azonban az új névtér bevezetése végett egy új réteg integrálása szükséges a transzport és a hálózati réteg közé, mivel az IP cím helyett a HIT azonosítót látják már csak az alkalmazások. Ezzel különválasztva az azonosítási és helyzetinformációs funkciókat egymástól. Az úgynevezett randevú pont (RVS) bevezetése a kommunikáló felek minél gyorsabb frissítését segíti elő. Ez egy második globális névfeloldó szolgáltatás, amely kapcsolattartó entitásként is funkcionál, miközben az első HIP üzenetet továbbítja a kommunikáló felek között. Így a szeparálás következtében biztonságos adatút és multihoming építhető ki. Az UFA-HIP mechanizmus kiépítése során az architektúra négy fő komponensre bontható szét, amely az inter-gw átadások biztonságos lezajlását valósítja meg. A négy rész a következő egységek: hozzáférési hálózat (Acces Network), IP/MPLS tranzit hálózat, HIPalapú ellenőrzési hálózat, átadás előkészítő- és kezdeményező alrendszer. A központi IP horgony eltávolítását követően a hálózati funkciókat a felhasználókhoz közel osztották szét a tranzit- és a hozzáférési hálózatokban, amelyek az UFA GW és PoA entitásokba lettek integrálva. Az UFA-HIP protokoll esetén az UFA GW egy intelligens útvonalválasztó a hálózat szélén, amelyhez a MIH PoA-k csatlakoznak, a PoA-khoz pedig a mobil terminálok csatlakoznak mozgásuk során [MIH-et behivatkozni]. Azonban az UFA GW-ben példányosítani kell a MIH PoS funkciókat, ami lehetővé teszi a vezérlésátadási döntéseket és a hatékony adaptációt a szolgáltatásokat támogató erőforrások számára. Az UFA- HIP telepítése estén a mobil termináloknak és az UFA GW-nek támogatniuk és engedélyezniük kell a HIP-et. Továbbá a maghálózatban biztosítani kell a HIP vezérlési funkciókat, amely az MN folyamatos elérhetőségét biztosítja. Ez megvalósítható egy RVS funkcióval kombinált HIP-képes DNS szolgáltatással vagy egy teljesen elosztott HIP jelzési architektúrával. Amennyiben megtörténtek a DHCP Solicit / Advertise / Request / Reply üzenetváltások UFA GW és MN között, akkor az MN helyzetváltása a következőképen alakul. Elsőként a mobil terminál jelez az UFA GW-nek, az UFA GW pedig a HIP CP-nek (RVS) jelez. Erre a HIP kontroller visszaigazol. Azonban a hitelesítés érdekében dupla üzenetváltás megy végbe az UFA GW és HIP CP között. Ha ez megtörtént, akkor utolsó lépésként a RVS regisztrálja a mobil csomópont új helyét. Fontos megemlíteni, hogy az MN-nek és az UFA GW-nek is kölcsönösen ellenőriznie kell a másik szerepét egy tanúsítvánnyal. Ennek megvalósítására a HIP BEX és Update eljárások segítségével érhető el. I. UFA-PMIP Az UFA-PMIP egy hálózat alapú mobilitást támogató protokoll, amely a PMIPv6 jelzésátviteli rendszerét újrahasznosítja számos funkcionális eleme mellett. Amennyiben PMIPv6 protokoll van telepítve a kommunikációs hálózatban, akkor nem kell semmilyen változást a mobil csomópontokban megvalósítani, számukra tökéletesen transzparens a mobilitás-kezelés [6]. A PMIPv6 eljárás során egy LMA kerül telepítése domainenként az mobilterminálok elérhetőségének biztosítására. A terminológia szerint az LMA mellé egy MAAR entitást is bevezettek, amely a mobilterminál mobilitás jét végzi az MN nevében, mivel a PMIP nem követel meg a mobil csomópontoktól 4

semmilyen mobilitással kapcsolatos jelzést. Ezáltal egy hozzáférési átjáróként funkcionál, míg az LMA egy helyi mobilitási horgony a hálózatban. A MAG entitáshoz csatlakozik az MN a mozgása során és kezdeményezi a helyváltoztatási jelzés, amely során kiépül a MAG és LMA között egy kétirányú alagút hasonlóan a Home Agent által használt alagúthoz. Így helyzetfrissítés esetén a mobil terminál a PoA-n keresztül jelez az UFA GWnek, aki egy Binding Update üzenetben az LMA-hoz fordul [12], hogy az frissítse a mobil csomópont aktuális helyét. Amennyiben elvégezte a bejegyzés módosítását, akkor egy BA jelzést küld vissza az UFA GW számára, így véglegesítve a helyzetváltoztatást. Az átadásról alaphelyzetben az UFA GW dönt, azonban az MN is befolyásolhatja a kimenetelét. A protokoll során a meglévő szolgáltatás platformok és alkalmazásszerverek maradnak központosítottak. Az üzenetküldés során az MN a kapcsolódott PoA-n elküldi az UFA GW-nek a hasznos csomagot, amely vagy egy másik UFA GW-en keresztül éri az LMA-t vagy egyből az LMA-hoz fordul. Az aktuális UFA GW és LMA között egy kétirányú alagút épül ki a csomagok továbbítása érdekében, majd az LMA a kommunikációs partnernek továbbítja a hasznos adatcsomagot. J. SDN A protokoll új gondolatmenete a vezérlési sík és szállítmányozási sík egymástól való elszeparálására építi a működési mechanizmusát. A szoftver által meghatározott hálózat, amely dinamikus, rugalmas és költséghatékony, így jól alkalmazható a mai komplex alkalmazásokhoz. Ez köszönhető az elszeparált architektúrának, amely a továbbítási és vezérlési rétegek elkülönítésével a mögöttes infrastruktúrát transzparensé teszi a hálózati szolgáltatások számára. Az SDN architektúrája közvetlenül programozható a továbbítási funkciók szerint, annak érdekében, hogy a hálózat szintű forgalom dinamikusan módosítható legyen. Ennek következtében a rendszer agilissá válik, hiszen a hálózati intelligencia központosított szerver-alapú, azaz az SDN vezérlők átfogó képet tartanak fent a hálózatról. Az SDN megközelítés lehetővé teszi a hálózat számára az optimalizált és biztonságos erőforrás gazdálkodást. A mechanizmus során a mobil terminálok a Binding Update üzeneteiket a velük megegyező alhálózatban elhelyezkedő legközelebbi switchnek küldik el, amely jelzi az új kapcsolódást a kontroller felé. Ezek után a vezérlő a két kommunikáló partner között felprogramozza az adatok közvetítésében résztvevő switcheket, amennyiben a switch flow táblájában nincs a csomaghoz tartozó bejegyzés. Ha a csomagra vonatkozóan mégis van a switch birtokában flow bejegyzés, akkor annak megfelelően továbbítja azt. Azonban előfordulhat olyan eset is, hogy a switch flow táblájában a csomag több bejegyzésre is illeszkedik, ilyenkor egy előre definiált prioritási érték szerint fogja továbbküldeni a csomagot. Az SDN-alapú szemlélet egy kiemelkedő nyílt megvalósítása az OpenFlow szabvány, amely már megjelent az ipari alkalmazásokban is. K. OpenFlow OpenRoads Az OpenFlow egy nyílt szabványú protokoll [16][3][17][2], amely működési elve a hálózat infrastruktúrájának programozhatóságát, adaptív és dinamikus módosítását teszi lehetővé. A működés megváltoztatását egy központi elem teszi lehetővé [18], amit OpenFlow Controller-nek szokás nevezni. Az OpenFlow Controller lehetőséget nyújt az adatutak elkülönítésére és az eszközök izolációjára. A kontroller funkcióban a hálózati eszközök felett áll, hiszen ez a központi entitás osztja ki a rendszerben található eszközök számára a szükséges információkat [19]. Következésképpen a logika jelentős része a kontrollerbe lett integrálva, míg a többi hálózati elemben kisebb mértékű a hagyományos rendszerekhez képest [20]. Amikor az OpenFlow hálózati elemekről beszélünk, akkor a switch elnevezést használjuk, viszont fontos megemlíteni, hogy ezek nem feltétlenül az adatkapcsolati rétegben működnek, mert a kitűntetett szerepű kontroller tetszőleges módon üzemeltetheti az eszközöket. Ezekben a switchekben flow táblák vannak elhelyezve, illetve a kontrollerrel egy OpenFlow csatorna köti össze. Egy switch flow táblája flow bejegyzésekből épül fel, amely szerint az AP megvizsgálja a beérkező csomagokat. Ha van rá szabály az illeszkedési struktúravizsgálat során, akkor annak megfelelően továbbítja azokat. Amennyiben nincs a csomagra alkalmazható flow bejegyzés, akkor a switch a vezérlő kontrollerhez fordul. A kontroller a jelzés következtében bonyolult algoritmusok felhasználásával kiszámolja, hogy a szóban forgó csomagot milyen áramlási útvonalon kell továbbítania a hozzá kéréssel forduló switchnek. Az elemzés kiértékelése után a vezérlő entitás telepíti az áramlási útvonalban résztvevő switchekre az új flow bejegyzéseket. Az információ elterjesztésére a kapcsolók értesítik egymást a megváltozott bejegyzésekről. Miután a magas szintű absztrakciók végrehajtását elvégezte a csomag továbbítására vonatkozóan a kontroller, azután megkezdődik a vevőnek való adatcsomag küldése. Ennek következtében a protokoll az adat- és vezérlési síkot elszeparálja egymástól a hálózati eszközökben. III. GENERIKUS MODELL A mobilitás-kezelő protokollok teljesítményre vonatkozó matematikai modelleknek számos változata létezik [21][22][23], viszont elosztott megvalósítást leíró modellből ehhez képest kevés áll [24][25][26]. Sőt az általunk vizsgált protokollokat egyik meglévő modell sem fedte le teljes mértékig, valamint nincs még olyan általános matematikai modell, amely kielégítené a mobilitás protokollok sokszínűségét. Így egy saját hálózati modellt igyekeztünk megalkotni, amelyen nyomon követhető a protokollok jelzésüzeneteire és hasznos adatküldésre vonatkozó sajátosságai is. Fontos szempont volt a kivitelezés során, hogy a kijelölt protokollokat vizsgálni lehessen a rájuk jellemző elrendezésben, azaz megfeleljen az osztatlan telepítési követelmények mellett a részben elosztott és a teljesen elosztott kritériumoknak. A létrehozott hálózati topológia modellt az alábbi kép mutatja be. 5

1. ábra Generikus hálózati topológia modell Fontos szempont volt a kivitelezés során, hogy kijelölt protokollokat vizsgálni tudja a rájuk jellemző elrendezésben, azaz megfeleljen az osztatlan telepítési követelmények mellett a részben elosztott és a teljesen elosztott kritériumoknak, amelyek szerint összemérhetőnek kell lennie a kapott eredményeknek. A protokollok elemzése során a kommunikációs partner és a mobil csomópont különböző hálózatban szerepel, illetve a honi ügynök, LMA és HIP kontroller entitások is eltérő hálózatban szerepelnek a mobilterminálhoz képest. A mobil csomóponttal megegyező hálózatba tettük az elosztott architektúrákra jellemző szétosztott funkciókat képviselő anchor csomópontokat (MR, LMA, HAA, UFA GW, CMD, SDN CMD, PoA), amelyek telepítését a vizsgált protokollok megkövetelték. A hasonló funkciókat ellátó entitásokat egy csomópont jelöli a generikus modellünkben, valamint az 1. ábrán látható MR blokkok összeköttetése nem közvetlen módon történik, hiszen egyetlen protokoll sem követeli meg ennek fennállását. Végül a vizsgálat során a mobilterminált a MAAR/PoA/MA címet viselő funkcionális elemhez csatlakoztattuk. IV. PROTOKOLLOK HELYZETFRISSÍTÉSI MECHANIZMUSAI Ha a mobil felhasználók mozgásuk során elhagyják korábbi IP domain-jüket és egy új domain-be lépnek, akkor a mobilitás kezelési protokoll gondoskodik arról, hogy helyzetváltoztatás után is elérhető maradjon a mobil, és hogy a helyzetváltoztatás során ne szakadjon meg a kapcsolat a mobil és kommunikációs partnerei között. A mobilitás kezelése így alapvetően két feladat megvalósítását jelenti. Egyrészt szükség van a mozgó mobil csomópontok helyzetének folyamatos követésére, másrészt pedig meg kell oldani az ún. hívásátadás (handoff/handover) kezelését, azaz a felhasználók kapcsolatainak karbantartását. Az előbbit helyzetnyilvántartásnak (Location Management), az utóbbit pedig hívásátadás-kezelésnek (Handover Management) hívjuk. A helyzet-nyilvántartásnak két feladatot kell megoldania: a mobil csomópontok követését, azaz a helyzet-frissítést (Location Update), valamint ezen mobil egységek megkeresését (paging), amikor nekik címzett adatok átvitelére van szükség. Ebben a fejezetben a protokollokban alkalmazott helyzetfrissítési sémákat elemezzük. A protokollok analizálása során használt fontosabb jelöléseket az alábbi táblázat foglalja össze. 1. táblázat Helyzetfrissítési paraméterek Handover taxonómia τ1 vezeték nélküli késleltetés τ2 vezetékes késleltetés s újraküldések száma Ttimer újraküldési időzítő k jelzésüzenetek száma dxy X és Y csomópont közti hopok száma TL2 L2 szintű handover ideje ϕ extra késleltetés ideje ax X anchor csomópont feldolgozási képessége ΔT mozgásérzékelés késleltetési ideje F switchek konfigurálási ideje Fontos megemlíteni, hogy ez a dokumentáció csak az L3 szintű handover-t vizsgálja. Az L2 szinten történő handover-t csak egy konstans értékkel adjuk hozzá minden egyes protokoll számítandó átadásához, mivel az általunk vizsgált protokollok nem befolyásolják ezt az időtartalmat. A. MIPv6 A HA anchor entitás Bindig Update-ben való értesítésére, illetve a csomópont BA visszacsatolására az alábbi egyenletet írhatjuk fel a generikus modellben feltűntetett távolságok alapján. Így a helyzetfrissítés a következőképpen számítható MIPv6 protokoll esetén. B. MIPv6 RO A MIPv6 RO protokollban szükség van az RR procedúrára a hitelesítési folyamat ellenőrzése miatt. A protokoll helyzetfrissítése során a HoTI és HoT üzenetek költségfüggvénye a következő egyenlettel írható fel. Hasonlóan áll elő a CoTI és CoT jelzési üzenetek átvitele és feldolgozása azzal a különbséggel, hogy jelentések nem a Home Agent csomóponton futnak keresztül. Az MN Home Agent-jét frissítő BU és BA üzenetváltások a hagyományos MIPv6-ban leírtakkal megegyezően zajlanak le. Azonban az optimális útvonal kiépítése végett a kommunikációs partnert is értesíteni kell a megváltozott helyzetről. 6

A leírtak alapján a MIPv6 RO helyzetfrissítését az alábbi egyenlet reprezentálja. Második esetben a domain váltást követően a régi és az új MR ugyanazt az LM-et használják. C. MIPv6 ERO A HoA cím tesztelés változatlanul megmaradt az ERO protokollban is, illetve a HA-hoz tartozó kötés frissítés is. Viszont a CoA cím már egy korai Bindig Update és Acknowledgement üzenetekbe kerül beágyazásra. Ezután azt a feltételezést tesszük, hogy 50-50% eséllyel fordulnak elő a fentebb említett esetek, amely alapján a két egyenlet számtani átlagát vesszük a helyzetfrissítés meghatározásához. Ezek után még egy teljes BU/BA is lejátszódik a korai kötésfrissítés után, amely a következőképen írható le. F. PMIP-alapú részben elosztott mobilitás A kapott képletekből pedig adódik a MIPv6 ERO helyzetfrissítése. D. Corresponding Network Homing A protokoll analízise során ismét feltettük, hogy a mobil terminál címhitelesítési ideje megegyezik a MIPv6 HoA és CoA tesztelési üzenetváltásának értékével. Ezután rögtön különböztessük meg a három fő CMD opció szerint a helyzetfrissítést. Az első esetben a kontroller egy PBA/PBA relé. A CNet helyzetfrissítése hasonlóan alakul a MIPv6-ban megismert handover-rel, azonban a HA helyett a CHA anchor csomópontot értesíti a mobilterminál a helyzetváltoztatás kapcsán a jelzésüzeneteivel. Így a következőt mondhatjuk el a CNet Homing helyzetfrissítéséről a felírt egyenletek alapján. Amennyiben a CMD egy MAAR lokátor, akkor az egyenlet az alábbiak szerint módosul. E. MIPv6-alapú elosztott mobilitás A DMM MIPv6 esetén kiesik a HA entitás a hálózatból, helyette az MR és az LM végzi a helyzetfrissítést. Azonban a hitelesítési idő nagyságát a HoTI, HoT, CoTI és CoT idővel megegyező nagyságúra állítottuk a mérés során, amíg a MR egy hitelesítő szerverhez fordulva azonosítja a kérvényező mobil csomópontot. A frissítést az aktuális MR végzi, azonban két esetre oszthatjuk ennek megvalósulását. Az első variáció, amikor a régi és az új MR különböző LM-et használ. Az utolsó esetben a kontroller egy MAAR proxyként funkcionál, ebből kifolyólag a helyzetfrissítés a következőként határozható meg. 7

UFA-PMIP Ezekből az átlagos helyzetfrissítési időt a három esetből egy egyszerű számtani, aritmetikai középérték számítással kapjuk meg. Az UFA-PMIP protokoll a PMIPv6 jelzésrendszerét hasznosította újra, így a HA anchor csomópont helyett az LMA került bevezetésre, továbbra is az MN hitelesítési idejének nagyságát a HoTI-CoTI mechanizmus időigényével tesszük ismét egyenlővé. Az UFA-HIP elemzéséhez hasonlóan két részre bontjuk a helyzetfrissítés tárgyalását. Az első rész, amikor a mobil csomópont az UFGW-jel veszi fel a kapcsolatot: G. PMIP-alapú teljesen elosztott mobilitás A protokoll analízise során ismét feltettük, hogy a mobil terminál címhitelesítési ideje megegyezik a MIPv6 HoA és CoA tesztelési üzenetváltásának értékével, akárcsak a PMIP-alapú részben elosztott mobilitás nél. Míg a második fele a következőképpen határozható meg, az UFAGW és LMA kommunikációja szerint: Azonban a helyzetfrissítés esetén már nem jelenik meg központi vezérlőegység (CMD), így az új MAAR egységnek kell elvégeznie az értesítések küldését. A kapott egyenletekből pedig következik a helyzetfrissítés egyenlete. I. OpenFlow OpenRoads H. UFA-HIP A hitelesítési időt hasonlóan itt is a CoA és HoA címek MIPv6 RO protokoll esetén bemutatott tesztelési időigényével tesszük egyenlővé. A mobil terminál és az UFA GW közötti jelzésforgalom a következőképpen írható fel. A protokoll helyzetfrissítése során a hitelesítési időt továbbra is a HoTI-CoTI tesztfolyamat időigényével tesszük egyenlővé. A handover idejét nagyban befolyásolja az új switchek felkonfigurálásának ideje, amely alapján felírható az eljárás helyzetfrissítési egyenlete. Majd az UFA GW továbbítja az MN kötési kérvényét a HIP kontroller rendszer felé, amelyet a következőképpen reprezentáltunk (megjegyzendő, hogy az UFA-HIP eljárás esetén ez az üzenetváltás kétszer zajlik le): V. HELYZETFRISSÍTÉSEK ÖSSZEHASONLÍTÁSA A vizsgálat megkezdése előtt bemutatjuk, hogy milyen paraméter beállításokat használtunk a MATLAB-ban megvalósított függvények leírása során, amellyel a protokollok összehasonlítását végeztük. Ezeket a beállításokat az alábbi táblázat foglalja össze. A fentebb taglalt képletekből pedig előállítható az UFA-HIP helyzetfrissítése. 8

2. táblázat Helyzetfrissítési paraméterek Helyzetfrissítési paraméterek τ1 2 ns τ2 0.5 ns s 0 Ttimer 0.5 ns k 1 db TL2 2 ns ϕ 3 ns ΔT 0.1 ns F 3 ns dmnma 1 hop dmamr 1 hop dmrgw 3 hop dgwha 3 hop dgwcha 3 hop dchacn 3 hop dgwcn 2 hop dhacn 4 hop dmrlm 1 hop dmnpoa 1 hop dpoaufagw 1 hop dufagwgw 3 hop dufagwhip 3 hop dufagwlma 3 hop dujmrregimr 2 hop dujmrregilm 2 hop dujmrujlm 1 hop dujmrlm 1 hop dgwlma 3 hop dlmacn 4 hop dgwhip 3 hop dhipcn 4 hop dmnsmaar 1 hop dsmaarcmd 2 hop dpmaarcmd 2 hop dsmaarpmaar 3 hop dsmaargw 3 hop dmnmaar 1 hop dmaarcmd 2 hop acmd 1/350 ns apmaar 1/250 ns asmaar 1/250 ns aha 1/500 ns acha 1/350 ns alma 1/450 ns ahip 1/450 ns aufagw 1/250 ns apoa 1/250 ns aregimr 1/250 ns aregilm 1/250 ns aujlm 1/250 ns A megválasztott paraméterek alapján a következő oszlopdiagramon vizsgáljuk meg a frissítési időket. A második ábrán látható módon a DMM MIPv6 teljesít legjobban a beállított paraméterek szerint, ugyanis a Home Agent felé ez a protokoll már nem küld Binding üzenetet, mivel az elosztott hálózati entitások kiváltják a feladatát, így a frissítő üzeneteknek nem kell ezt a távot megtenniük. Ezért azt mondhatjuk, hogy a frissítési eljárásra vonatkozó költségfüggvénye nagyban függ az elosztott komponensek közötti távolságtól, illetve attól is, hogy az LM és a HAA kombinált egységként jelenik meg az egyes domainekben vagy sem. Ezek mellett jelentősen befolyásolja még a frissítési időt az adminisztratív domainbe telepített LM-ek száma és feldolgozási képessége, ugyanis az információ fenntartás ugrásszerűen megnövekvő mobil terminálok esetén is kielégítendő követelmény. A második legjobban teljesítő protokoll az OpenFlow alapú SDN eljárás, amely csak a switchek felkonfigurálási ideje miatt marad le. Viszont, ha sok hálózati elemet kell felkonfigurálnia a vezérlőnek, 2. ábra Helyzetfrissítés akkor az egyenletben feltűntetett F konstans értéke eltérhet, amely során a mechanizmus helyzetfrissítési ideje nagyban megnőhet. Azonban érdemes megemlítenünk azt a tény is, hogy a csomagtovábbítási során a központi logika képes a leterhelt útvonalakat, csomópontokat elkerülni, ezzel a hálózat terhelését kiegyensúlyozhatja. A hagyományos MIPv6 frissítési mechanizmusa igen egyszerű, mivel csak az MN Home Agent-jét kell mindig időszerűen informálni az aktuális változásokról. Tehát a frissítési idő mértéke csak a mobil eszköz és a HA távolságától függ. Amennyiben a mobil csomópont a hozzátartozó HA-hoz közel mozog, akkor a bemutatott frissítési idő jelentősen csökken a mobilterminál és Home Agent távolsággal arányosan, viszont eltávolodás esetén pedig jelentősen megnövekszik. A protokoll előnye, hogy nem terheli le a hálózatot nagy mennyiségű jelzésüzenettel. Az MIPv6 RO már bevezette a kommunikációs partner frissítését is, amely jelentős többletet jelenthet a helyzetfrissítési képletekben. Így a szufficit mennyiségét az MN és CN távolsága határozza meg, amelyet az MIPv6 ERO-ban is megfigyelhetünk, ráadásul kétszer is megjelenik, melynek oka a Binding Update két részre bontása: korai és teljes, ezáltal a szóban forgó távot kétszer annyi alkalommal kell bejárni a jelzési üzeneteknek, mint az RO esetén. Azonban nem szabad elhanyagolni azt a tényt, hogy a CoTI, CoT alapú CoA cím tesztelését a korai BU/BA üzenetváltásokkal végzi el a protokoll a működése során. Az SDN megoldások esetén nem sok eltérés fedezhető fel a három elemzett módszer közül, ugyanis a bejárt távolságok megegyeznek a CMD relé és proxy estében, míg a MAAR lokátor szerepe esetén nem a vezérlő jelez vissza az új MAAR-nak, hanem a régi MAAR küldi el számára a nyugtázó PBA üzenetet, mellyel távolsága nagyban befolyásolja a frissítési idő nagyságát. Ugyanakkor mindhárom variáció estén optimális útvonal épül ki a két végpont között a kommunikáció során. Az UFA-HIP és UFA-PMIP esetén a helyzetet változtató mobil csomópontnak minden esetben jelzést kell küldenie az UFAGW-nek, amely a megfelelő elosztott anchor csomópontnak és az adott variánsban szereplő központi adatbázisnak továbbítja az információt. Az első esetben a 9

HIP kontroller dolgozza fel a beérkező kötés frissítési üzeneteket, így az UFAGW HIP esetén a vezérlő csak a jelzésüzenteket dolgozza fel, míg az UFAGW PMIP-ben használt LMA-n a hasznos üzenetek is átmennek. VI. PROTOKOLLOK ÜZENETKÜLDÉSÉNEK VIZSGÁLATA A protokollok helyzetfrissítési mechanizmusainak vizsgálata után nézzük meg, hogyan teljesítenek hasznos csomag küldése esetén az egyes eljárások. Vizsgálatainkban h karakter jelöli a hasznos üzenetek számát. A. MIPv6 A protokoll működése során a Home Agent alagutazást használ a hasznos csomagok továbbítására, amit egy konstans alagutazási késleltetési idővel jelenítünk meg a modellben. F. PMIP-alapú részben elosztott mobilitás A protokoll mindhárom tárgyalt esetében az üzenetküldési mechanizmus megegyezik, tehát csak a helyzetfrissítési módszereikben térnek el egymástól. G. PMIP-alapú teljesen elosztott mobilitás A PMIP-alapú teljesen elosztott mechanizmus üzenetküldése esetén a MAAR entitás hozza létre az optimális útvonalat a két kommunikáló fél között, amelyet a következőképpen foglalhatunk egyenletbe. H. UFA-HIP B. MIPv6 RO A hagyományos MIPv6 protokollhoz képest az RO mechanizmus már optimális útvonalat épít ki a kommunikáló felek között. Azonban ennek megvalósítása érdekében a T2RH (Type 2 Routing Header) többletköltséget rak minden csomagra, amellyel megnöveli minden egyes küldött csomag méretét. C. MIPv6 ERO Amennyiben a mobilterminál üzenetet küld a kommunikációs partnerének, akkor mindig az UFAGW-n fog áthaladni a hasznos csomag. I. UFA-PMIP Az eljárás során a csomagok az UFAGW és az LMA között kiépített kétirányú alagúton továbbítódnak. A MIPv6 ERO esetében szintén optimális útvonal épül ki a küldő és vevő között, azonban a helyzetfrissítési üzenetek megnövelt száma miatt nincs szükség T2RH-re. J. OpenFlow OpenRoads D. Corresponding Network Homing A CNet a hagyományos MIPv6 elveit követi azzal a különbséggel, hogy a CN-hez közelebb telepített CHA-t használja az alagutazás során. E. MIPv6-alapú elosztott mobilitás A központi anchor csomópont szerepét szétosztották kisebb felelősségű funkcionális eszközök között, így nem kell a csomagoknak akkora utat bejárniuk, mint a MIPv6 esetében. Az OpenFlow protokoll az optimális útvonalat épít ki az intelligens központi kontroller segítségével. VII. ÜZENETKÜLDÉSI JELLEGZETESSÉGEK ÖSSZEHASONLÍTÁSA A 3. táblázatban már bemutatott helyzetfrissítési paraméterek mellett még az alábbi táblázatban látható értékek szükségesek a függvények megvalósításához. 3. táblázat Üzenetküldési paraméterek Üzenetküldési paraméterek IE 0.5 ns h 10:5:100 db token 0.9 10

A beállított paraméterek alapján a 3. ábrán látható grafikonokat kaptuk. 2. ábra A vizsgált protokollok üzenetküldési költsége Leolvasható az ábráról, hogy az UFA-PMIP protokoll teljesített a legrosszabbul. Ennek oka, hogy a hasznos csomagnak a generikus modellben hosszú utat kell bejárnia, ugyanis kötelezően érintenie kell az UFAGW entitást, ami a kapott csomagot a kiépített alagúton továbbítja az LMA-nak. Az LMA pedig a kommunikációs partnernek küldi tovább az üzenet. Az UFA-PMIP grafikonja alatt a MIPv6 helyezkedik el. Üzenetküldés terén rosszul teljesít az eljárás, mert a hasznos csomagoknak mindig a Home Agent entitáson keresztül kell haladniuk, ami hosszabb utat eredményez. Ezek mellett említésre méltó még az a jelenség is, hogy az áthaladó csomagokra IPv6 beágyazó mechanizmust kell végrehajtania a protokollnak működése során. Ez a két tényező igen csak megnöveli a költségfüggvényt a többi eljáráshoz képest. A CNet Homing protokoll jobbnak bizonyult a megadott paraméterek tesztelése során, mint a hagyományos MIPv6. A protokoll hatékonysága a hálózatban elhelyezett CHA-CN távolságtól fog függeni. Amennyiben a CHA közel helyezkedik el hop-ok számát tekintve az MN és a CN közötti optimális útvonalhoz, akkor megközelíti a DMM MIPv6, RO és ERO protokollok optimális útvonal költségét. Viszont a kiépített alagút miatt sohasem lesz olyan hatásfoka, mint az RO vagy ERO eljárásoknak. Ezek után nézzük meg a CNet protokoll grafikonja alatt a DMM MIPv6 elosztott megközelítését, amely hatékonyságát annak köszönheti, hogy a felhasználókhoz közel osztotta szét a Home Agent funkcióit. A hagyományos MIPv6-tal és CNet-tel ellentétben a DMM MIPv6 az MR-en keresztül optimális útvonalat épít ki, így jelentősen csökkentve a csomagok által megtett útvonalat. A hasznos csomagokat domain váltás során az LM-ben található bejegyzések alapján továbbítjuk, így a célcsomópont címét le kell kérni a kommunikáció megkezdéséhez. Azonban előfordulhat, hogy a CN nem értesült még az átadási eseményről és az adatcsomagot az MN régi MR-jéhez küldi. Ebben az esetben a mobil terminál nem kapja meg az üzenetet, amelyet neki szántak, így a régi MR az új MR felé egy alagutat épít ki, majd ezen az alagúton át továbbítja az üzeneteket. Az ilyen esemény bekövetkezése plusz költséget jelent, mivel hosszabb útvonalon kapja kézhez a csomagot a mobil csomópont, illetve a szóban forgó MR-ek között alagutazásra van szükség. A DMM MIPv6 az UFA-HIP grafikonjával esik egybe a használt paraméterek esetén. Ugyanis az UFA-HIP protokoll az üzeneteket a minden esetben az UFAGW-en küldi át. Tehát a hatékonysági faktorát nagyban befolyásolja, hogy a rendszerben elhelyezett UFAGW érintéséhez mennyivel kell hosszabb utat bejárnia a csomagoknak az optimális útvonalhoz képest. A második legjobb helyen az MIPv6 RO található, amely minden esetben optimális útvonalat épít ki a mobil eszköz és a kommunikációs partner között, azonban mégis elmarad az ERO hatékonyságától. Ennek oka, hogy a MIPv6 ERO protokoll tokeneket használ a hitelesítés meggyorsítására, azaz az első kommunikáció előtt legenerálja a CN a megfelelő azonosító tokeneket, így a továbbiakban hatékonyabb lesz a küldő fél kilétének meghatározása. Ezzel szemben az RO eljárás nem használ tokent a kommunikáció során, sőt CN felől érkező üzenetek esetén még a hasznos csomagokhoz hozzáadódik egy 40 byte-os Type 2 Routing Header fejléc is. Ezt a fejlécet a mobil csomópontnak fel kell dolgoznia a hitelesítés miatt, amelyből megtudja, hogy neki szól a csomag. Amennyiben kisméretű csomagokkal kommunikál a két fél, akkor ez az érték jelentős többletként jelenik meg. Ha nagyméretű üzenetváltásokat folytatnak egymás között a csomópontok, akkor pedig egyre jobban megközelíti az ERO-hoz tartozó függvényt. Az OpenFlow és SDN DMM megoldások pedig az ERO protokollhoz hasonlóan optimális útvonalat építenek ki a kommunikáló felek között, így a megkapott grafikonok a többi protokoll alatt helyezkednek el. VIII. SKÁLÁZHATÓSÁG VIZSGÁLATA Az egyre változatosabb alkalmazások megjelenése az Interneten a meglévő kommunikációs algoritmusokkal szemben új követelményt állított fel. Egy ilyen igény a skálázhatóság, mivel egyre több mobil eszköz csatlakozik az egyes hálózatokhoz egyre növő forgalmat injektálva a hálózatokba, így a méretezhetőséget biztosítani kell a felhasználók számára. Tehát elvárjuk egy mobilitást kezelő protokolltól, hogy a növekvő terhelés esetén is optimálisan működjön, azaz a kommunikációs protokoll hatékonysága jelentősen ne változzon attól, ha a rendszerben változnak a mobilitási paraméterek vagy módosul a felhasználók száma [26]. Ezt a tulajdonságot nagyban befolyásolja az adott protokoll jelzésforgalma, a hálózatba integrált feldolgozási egységek kapacitása és mennyisége. A modell megalkotása során csak azt a szempontot vettük figyelembe, amikor a mobil csomópont IP alhálózatot vált, ugyanis a mobil terminál pontos tartózkodási helyének meghatározására nincs szükség az analitikus elemzéshez a mi megközelítésünkben. Sőt a cellaváltások közül is csak azokat az eseteket kell számításba venni, amelyek során IP domain váltás történik a rendszerben, hiszen az egyes protokollok jelzés üzenetei ekkor jelennek meg többletként a hasznos csomagok továbbítása mellett. Ezért speciális mozgásmodellre nincs szükség: a mobil entitások mozgása során nem lényeges, hogy melyik cellából, domainből melyikbe léptek át, csak 11

az fontos számunkra, hogy történt-e domain váltás vagy sem. A következő táblázatban olvashatóak a skálázhatóságra vonatkozó paraméterek listája. 4. táblázat Skálázhatósági paraméterek Skálázhatósági paraméterek J, J jelzésüzenetek száma M mobilterminálok száma A alagutazási költség H hasznos üzenetek száma D, D anchor csomópontok száma F, F anchor csomópontok feldolgozási képessége V valószínűségi változó E domain váltások száma S switchek felkonfigurálási költsége C valószínűségi változó A skálázhatósági viszonyszámot a szolgáltatásminőség segítségével igyekeztünk meghatározni. A szolgáltatás minősége csak kismértékben csökkenhet a megnövekvő csomópontszám, mobilitás és forgalmi paraméterek esetén. Ezek alapján kijelenthető, hogy a skálázhatóság mértéke nagyban függ a szétterjesztendő és összegyűjtendő információk mennyiségétől, azaz a jelzésforgalom nagyságától. Azonban nem szabad megfeledkezni arról a tényről, hogy a jelzésüzenetek generálása mellett a mobilterminálok hasznos üzenet váltások is végrehajtanak, amelyek bizonyos protokollok esetén az anchor csomópontokon mennek keresztül. Így a dokumentumban a skálázhatóságra vonatkozó egyenletet egy törttel írtuk le, amelyben a számláló a rendelkezésre álló anchor csomópontok kapacitását mutatja, míg a nevező pedig az anchor csomópontokat érintő számítási terhelést. Tehát az anchor csomópontok kapacitását a szóban forgó entitások feldolgozási képességének és a rendelkezésre álló darabszámának a szorzata adja. A nevező meghatározása már nagyobb eltérést mutat az egyes protokollok sajátosságai miatt, hiszen egyes esetekben nem épül ki végpont-végpont kommunikáció a két fél között. Ebből kifolyólag törtvonal alatti részben megjelenhet a hasznos üzenetek továbbításának többlet terhelési költsége, amelyet az anchor csomópontnak fel kell dolgoznia, ugyanakkor minden horgonynak küldenie és fogadnia kell a jelzésüzeneteket. A. MIPv6 Ebben az esetben minden jelzésüzenetet a HA kap meg, illetve minden hasznos üzenet rajta keresztül megy át, így a hasznos üzeneteket alagutazni kell a Home Agent és a mobilterminál között. Tehát ezért van A-val beszorozva az (M * H) tag. B. MIPv6 RO Mivel nem minden adatcsomag megy keresztül a HA-n, így egy valószínűségi változóval igyekszünk lefedni a protokoll sajátosságát. Azonban az összes jelzésüzenet átmegy az otthoni ügynökön. C. MIPv6 ERO Az ERO eltérő számú jelzésüzenetet használ attól függően, hogy a kommunikációs partnertől megszerezte-e már vagy sem a szükséges tokeneket. Ezt a két esetet ismét egy valószínűségi változóval különböztetjük meg. D. Corresponding Network Homing A CNet Homing protokoll skálázhatósági képlete megegyezik a hagyományos MIPv6 protokoll képletével. E. MIPv6-alapú elosztott mobilitás Itt a V valószínűségi változó, azt határozza meg, hogy értesíteni kell-e az MR-hez tartozó LM-et és HAA-t vagy sem. Tehát a régi MR és az új MR közös LM-t birtokol, vagy nem. Fontos megemlíteni, hogy csak az üzenetváltásokat alagutazza a protokoll a működése során (MR-ek között), illetve váltáskor a veszteségmentes továbbítás miatt még néhány csomagot, amíg nem megy végbe a BU. F. PMIP-alapú részben elosztott mobilitás A CMD-n nem megy végig egyetlen adat csomag sem, tehát neki csak a jelzésüzeneteket kell tudnia lekezelni. Azonban a MAAR-on keresztül mennek át a jelzés üzenetek, de úgy vettük, hogy a MAAR képes minden hozzá csatlakozott mobilterminált ellátni jelzésforgalom és üzenetforgalom terén. Ebből kifolyólag a következő egyenletet írhatjuk fel, amelyben az F a CMD feldolgozási képességét, F pedig a MAAR entitás feldolgozási képességét jelöli. A skálázhatósági egyenletben pedig a szűkkeresztmetszetet vesszük figyelembe. G. PMIP-alapú teljesen elosztott mobilitás Mivel a központi vezérlőegységet megszűntették a protokoll struktúrájából, így minden terhelés a MAAR csomópontokra hárítódik, azaz ezen entitásoknak kell feldolgozni a jelzésüzeneteket és továbbküldeni a mobilterminálok hasznos üzeneteit. 12