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

Átírás

1 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ó 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

2 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

3 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

4 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 ) 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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