BME Híradástechnikai Tanszék 2008/2009 tavaszi félév Mobil Internet 10. előadás – Mozgó hálózatok támogatása (NEMO routing optimalizáció) Bokor László.

Az előadások a következő témára: "BME Híradástechnikai Tanszék 2008/2009 tavaszi félév Mobil Internet 10. előadás – Mozgó hálózatok támogatása (NEMO routing optimalizáció) Bokor László."— Előadás másolata:

1 BME Híradástechnikai Tanszék 2008/2009 tavaszi félév Mobil Internet 10. előadás – Mozgó hálózatok támogatása (NEMO routing optimalizáció) Bokor László bokorl@hit.bme.hu

2 2008.03.20 Mobil Internet előadás BME-HIT 2 Kivonat Egy kis ismétlés NEMO RO – NEMO BS problémáinak hatásai NEMO RO – Problémafelvetés NEMO RO – Terminológia NEMO RO – Mit érhetünk el? NEMO RO forgatókönyvek –Nem beágyazott NEMO-k esetében –Beágyazott NEMO-k esetében –Infrastruktúrán alapuló optimalizáció –Intra-NEMO optimalizáció NEMO RO – Szükséges kompromisszumok NEMO RO – Mekkora a problématér? Néhány konkrét megvalósítás: –Optimized NEMO (ONEMO ) –Mobile Router-Assisted Route Optimization (MoRaRo)

3 2008.03.20 Mobil Internet előadás BME-HIT 3 Egy kis ismétlés – Mi az a NEMO? Egyetlen terminál mozog: –utasok laptop termináljaikkal a vonaton –drága 3G hozzáférést használva érik el az Internetet Hatékonyabb megoldás: –a vonat rendelkezik mobil routerrel –az MR biztosítja a vezeték nélküli Internet-hozzáférést az egész vonat számára –az utasok termináljainak elég Ethernet (vagy WiFi) interfésszel rendelkeznie az MR-hez való kapcsolódáshoz –az MR lát el minden egyéb feladatot –a terminálok és az MR egy hálózatot alkotva együtt mozognak, ám az utasok (és termináljaik) számára ez teljesen transzparens!

4 2008.03.20 Mobil Internet előadás BME-HIT 4 Egy kis ismétlés – NEMO komponensek Mobil Router (MR) –access router vezeték nélküli uplink-kel az Internet felé –hasonlít egy ADSL routerhez, de az Internethez vezeték nélkül csatlakozik és NEMO protokoll stack is fut rajta –a hozzá tartozó mozgó hálózat mobilitását kezeli NEMO hosztok (MNN) –LFN –LMN –VMN –A VMN-en kívül nincs a hosztokban feltétlenül szükség Mobile IPv6 implementációra!

5 2008.03.20 Mobil Internet előadás BME-HIT 5 Egy kis ismétlés – NEMO alkalmazások ITS rendszerek –szenzorok és egyéb kommunikáló egységek a járművekben –utasok kézi terminálokkal –MR(ek) a járművekben, egress interfészükkel biztosítva az Internet-hozzáférést Katonai alkalmazások –előre telepített infrastruktúra nélküli kommunikációs rendszerek –egymással és a HQ-val korlátlan adatáramoltatásra képes egységek

6 2008.03.20 Mobil Internet előadás BME-HIT 6 Egy kis ismétlés – NEMO típusok Solid NEMO –egyetlen hierarchia-réteggel rendelkező NEMO Nested NEMO –egymásba ágyazott NEMO hálózatok több rétegű hierarchiája –pl. utas PDA-val, PDA Bluetooth-on keresztül csatlakozik az utas mobiltelefonjához, a telefon WiFi-n az MR-hez –pl. harcoló egységek hierarchiája katonai küldetésen Single-homed NEMO –egyetlen, single-homed MR Multihomed NEMO –multihomed MR –több MR

7 2008.03.20 Mobil Internet előadás BME-HIT 7 Egy kis ismétlés – NEMO Basic Support 2001:738:2001:2088::/64 MR-HoA 2001:738:2001:2088::eui64/64 MNP 2001:738:2001:2089::/64 LFN címe 2001:738:2001:2089::eui64/64 MR-CoA 3ffe:ffff:fe3:8000::eui64/64 3ffe:ffff:fe3:8000::/64 Binding Update Binding Cache: 2001:738:2001:2088::eui64/64 – MR-CoA 2001:738:2001:2089::/64 – MR-CoA Kétirányú alagút

8 2008.03.20 Mobil Internet előadás BME-HIT 8 Egy kis ismétlés – NEMO BS problémák CoA szerzése hosszú idő (>2s) Alagutazás a HA és az MR között mindkét irányban –sub-optimális, de egyszerűen implementálható –Az alagutazás költségei magasak (tunneling overhead) BU „vihar” (BU storm) Többszörösen beágyazott NEMO-k esetében további gondok: –nem optimális útvonalválasztás (sub-optimal routing vagy pinball routing): a csomagoknak több HA-n kell keresztüljutniuk, amíg elérik a CN-t vagy a beágyazott NEMO MNN-jeit –több IP alagút fejléc-réteg –komoly probléma és aktuális kutatási téma Minden egyes beágyazási szint (hierarchy layer) egy újabb alagutazási réteget eredményez –újabb IPv6 encapsulation –növekszik a csomagméret –ha a csomag mérete eléri az MTU-t: töredezés (fragmentation)

9 2008.03.20 Mobil Internet előadás BME-HIT 9 NEMO BS problémáinak hatásai I. Hosszabb útvonalak, megnövekedett késleltetések, az infrastruktúra indokolatlan terhelése: –A kétirányú alagutak miatt a csomagok a CN-MNN között hosszabb utat kénytelenek megtenni, mintha közvetlenül közlekednének a cél és a forrás között –Ha a CN vagy a NEMO közel van a Home Network-höz, akkor ez a hatás nem jelentős –Egyéb esetekben nagyságrendekkel is nőhet a késleltetés, rontva a szállítási réteg protokolljainak teljesítményét (pl. TCP-nél az RTT- től is függ a küldési ráta) és a valósidejű multimédia szolgáltatások élvezhetőségét –A sub-optimális útvonal az infrastruktúrát is feleslegesen terheli

10 2008.03.20 Mobil Internet előadás BME-HIT 10 NEMO BS problémáinak hatásai II. Megnövekedett „packet overhead”: –A kétirányú alagutak miatti plusz fejlécek jelentősen rontják a hálózat átviteli képességeit –Az alagutak IP fejléceinek mérete bizonyos forgalmak esetében jelentős a hasznos adatok méretéhez képest is: pl. hangátvitel 8 kbps sebességű algoritmus esetében (G.729): –20 ms-onkénti mintavétel használatakor 50 csomag kerül kiküldésre másodpercenként –Az alagút minden IPv6 fejléce 320 bit csomagonként, azaz 16 kbps –Ez kétszerese a hasznos teher igényelte sávszélességnek!! Megnövekedett számítási késleltetés: –a kétirányú alagutak miatti encapsulation/decapsulation encryption/decryption, MTU számítási, töredezés/helyreállítás műveletek növelik a számítási késleltetést

11 2008.03.20 Mobil Internet előadás BME-HIT 11 NEMO BS problémáinak hatásai III. Megnövekedett esély a csomagok töredezésére: –újabb késleltetést/számítási terhelést növelő hatás –csökkenti a használható sávszélességet Növekvő érzékenység a linkhibákra: –feltételezve, hogy minden linken ugyanannyi a hiba valószínűsége, akkor a hosszabb útvonalak nagyobb linkszáma érzékenyebbé teszi a NEMO BS protokollt a linkhibákra

12 2008.03.20 Mobil Internet előadás BME-HIT 12 NEMO BS problémáinak hatásai IV. Az otthoni hálózat (Home Network) szűk keresztmetszetté válhat: –Az aggregált forgalom otthoni hálózatban esetlegesen kialakuló torlódása további késleltetéshez és akár csomagvesztéshez is vezethet –Ha ilyen késleltetések/csomagvesztések jelzési üzeneteket érintenek (pl. Binding Update) akkor egész NEMO-k elérhetősége kerülhet veszélybe –A felesleges alagutazás (és a hozzá kapcsolódó járulékos feladatok) csökkentik az Otthoni ügynök csomagtovábbító kapacitását –Az otthoni link és a HA egyaránt „single point of failure”

13 2008.03.20 Mobil Internet előadás BME-HIT 13 NEMO BS problémáinak hatásai V. Negatív hatások erősödése nested NEMO szituációkban: –a sub-optimális útvonalak miatt a negatív hatások beágyazott mozgó hálózatok esetében halmozottan jelentkeznek –„pinball routing”: a csomagoknak több HA-n kell keresztüljutniuk, amíg elérik a CN-t vagy a beágyazott NEMO MNN-jeit –tovább növekvő csomagméret: a beágyazottság minden egyes szintje újabb IPv6 fejlécet jelent. Fejléc-tömörítés 1 nem alkalmazható, mert a forrás és a cél is változik minden „hop” után –a beágyazott MR számára az útvonal minden egyes otthoni linkje és HA-ja „single point of failure” 1 Deering, S. and B. Zill, "Redundant Address Deletion when Encapsulating IPv6 in IPv6", Work in Progress, November 2001.

14 2008.03.20 Mobil Internet előadás BME-HIT 14 NEMO BS problémáinak hatásai VI. A sub-optimális hatások átörökítése a Mobile IPv6-ba: –Mobile IPv6-ot használó VMN-ek RO képessége megszűnik a NEMO-ba lépéssel, ugyanis a VMN-CN útvonal a MIPv6 RO végrehajtása után is sub-optimális lesz az MR-HA alagutak jelenléte miatt –Ugyanez a hatás létezik, ha nem a mobil egység, hanem a CN található NEMO hálózatban VMN-ek letiltása biztonsági okokból: –Mivel a kétirányú alagutakon minden NEMO forgalom eljut a HA- hoz, ezért ártó szándékú VMN-ek rosszindulatú csomagjai is eljuthatnak így a NEMO otthoni hálózatába. Ezért elképzelhetőek olyan rendszerek, ahol biztonsági megfontolásokból a VMN-ek forgalma szűrésre kerül, ami jelentős korlátozás a protokoll funkcionalitását tekintve.

15 2008.03.20 Mobil Internet előadás BME-HIT 15 NEMO BS problémáinak hatásai VII. Instabil kommunikáció beágyazott NEMO hálózatok „belsejében”: –egymásba ágyazott NEMO-k esetén gyakori az olyan szituáció, mikor a root MR Internetkapcsolatának megszűnése a nested NEMO elemeinek egymással folytatott kapcsolatának megszűnéséhez vezet akkor is, ha ezek az elemek egymással közvetlen kapcsolatban vannak és kapcsolatukat nem érte behatás. –egymásba ágyazott NEMO-k esetén a root MR szűk keresztmetszetté válhat

16 2008.03.20 Mobil Internet előadás BME-HIT 16 NEMO BS problémáinak hatásai VIII. „Patthelyzet” kialakulásának veszélye: –léteznek olyan forgatókönyvek, melyekben a szülő MR egyben otthoni ügynöke is NEMO-jainak (azaz a mozgó hálózat saját gyermek MR-jeihez rendelt MNP-k aggregációjkaként adódik) –ilyenkor, ha a szülő MR saját gyermek NEMO-jainak egyikéhez csatlakozik, akkor a gyermek NEMO MR-je nem lesz képes megtalálni HA-ját, így a szülő NEMO forgalma blokkolásra kerül, patthelyzet jön létre

17 2008.03.20 Mobil Internet előadás BME-HIT 17 NEMO routing optimalizáció – Problémafelvetés Láttuk, hogy a NEMO BS problémái miatt: –magas késleltetések –kialakuló szűk keresztmetszetek miatti torlódások –egymásba ágyazott NEMO hálózatok esetében a gondok halmozódása –stb... Mindez akár a NEMO Internetkapcsolatának megszűnéséhez és feloldhatatlan patthelyzetek kialakulásához is vezethet MIPv6 routing optimalizáció (RO) a CN és az MN közti vég- vég kapcsolat minőségét javítja, és a HA terhelését csökkenti, NEMO helyzetekben azonban sokszor hatástalan A NEMO RO feladatai a normál MIPv6 esetnél tehát sokkal komplexebbek, és nem oldhatók meg ilyen egyszerűen!

18 2008.03.20 Mobil Internet előadás BME-HIT 18 NEMO RO – Terminológia Correspondent Router (CR): –Olyan router, mely a kommunikáló fél (CN) nevében képes az RO session-ök (routing optimalizációs folyamatok) végződtetésére Correspondent Entity (CE): –Olyan hálózati elem, mellyel egy MNN vagy MR routing optimalizációs folyamatot kísérel meg végrehajtani. A hálózati elem lehet CN vagy CR.

19 2008.03.20 Mobil Internet előadás BME-HIT 19 NEMO RO – Mit érhetünk el? I. A cél természetesen a NEMO BS problémáinak kiküszöbölése: –Kisebb csomagkésleltetés, jitter és csomagvesztés rövidebb, gyorsabb, jobb minőségű MNN-CN útvonalak keresése: QoS! –Hálózati erőforrások hatékonyabb kihasználása RO használatával az optimális vég-vég útvonalak kevesebb torlódást és kisebb hálózati terhelést jelentenek –Linkhibákkal szembeni nagyobb ellenállóképesség az optimalizált útvonal valószínűleg kevesebb linket tartalmaz, így a linkhiba valószínűsége csökken –Hatékonyabb adatátvitel RO használatával kevesebb alagútra van szükség, így az encapsulation/decapsulation, valamint az alagutazás egyéb járulékos feladatai kevésbé foglalják az erőforrásokat és a transzport rétegben is jobb teljesítményt tesznek elérhetővé

20 2008.03.20 Mobil Internet előadás BME-HIT 20 NEMO RO – Mit érhetünk el? II. –Enyhébb számítókapacitási követelmények szintén az alagutak számának csökkenéséből következik –Az otthoni hálózat szűk keresztmetszetté válásának elkerülése RO használatával a csomagok útvonalából eliminálhatóak az otthoni ügynökök, a HA-k és és az otthoni hálózatok terhelése tehát szintén csökkenthető –Az otthoni hálózatokban a VMN-ekkel szemben alkalmazott retorziók szükségtelenné válnak RO segítségével a VMN-ek közvetlenül CN-jeikhez tudják küldeni csomagjaikat, az otthoni hálózatok ártó VMN-ekkel szembeni védelme így feleslegessé válik –Instabil és patthelyzet jellegű kommunikációs szituációk eliminálása a csomagok közvetlen (alagutak alkalmazása nélkül történő) küldése lehetővé teszi ezen negatív hatások kiküszöbölését

21 2008.03.20 Mobil Internet előadás BME-HIT 21 NEMO RO forgatókönyvek – Nem beágyazott NEMO-k esetében Az MR küld kötési információt (Binding Information) a CE-nek (CN vagy CR) –CR eset az érdekesebb: ha a CR a HA-nál közelebb van a CN-hez, akkor az új útvonal optimizáltnak tekinthető –MNN-től CN-felé: az MR megkeresi a CR-t, majd alagutat hoz létre a CR-hez, és beállítja a CN felé mutató routing bejegyzéseket az alagút használatára. A HA így „eltűnik” az útvonalból. –CN-től az MNN-felé: a CR a CN - HA útvonalon található, ismeri az MR által kezelt MNP-ket és rendelkezik egy felépített alagúttal az MR-rel (az MR aktuális CoA-ján végződtetve). A CR így képes az MR felé irányuló csomagok elfogására és MR felé történő továbbítására. –CE-k ilyen jellegű használata a NEMO BS logikus kiterjesztése: az MR képes (egy vagy több MNP-t tartalmazó) BU-k küldésére a potenciális CE-k felé, a CE-k pedig képesek kétirányú alagutak létrehozására, és routing információk injektálására az útvonalválasztó rendszerbe (annak érdekében, hogy az MNP az alagútba legyen irányítva) –CR természetesen lehet MR is, aki így képes RO végrehajtására MNN-jei nevében. Ebből következik, hogy az ilyen jellegű forgatókönyvek VMN-ek támogatásáról nem gondoskodnak, ez ugyanis a normál MIPv6-tal történő interakciót feltételezné A megközelítést használó protokollok: –Optimized Route Cache (ORC) –Path Control Header (PCH)

22 2008.03.20 Mobil Internet előadás BME-HIT 22 NEMO RO forgatókönyvek – Beágyazott NEMO-k esetében VMN jelenléte a NEMO-kban, illetve egymásba ágyazott NEMO-k Két fő megközelítés: –az útvonalon található HA-k számának csökkentését célzó módszerek: csak MR-ek egymásba ágyázását támogatja MIPv6-ot használó VMN-eket is támogatja (interakció a MIPv6 RR mechanizmusaival) Pl.: Reverse Routing Header (RRH) –az alagutak számának csökkentését célzó módszerek speciális jelzésüzenetek vagy routing fejlécek segítségével irányítják a csomagokat az alagutak mellőzése esetén a felfedezett útvonalon Pl.: Access Router Option (ARO), Nested Path Info (NPI)

23 2008.03.20 Mobil Internet előadás BME-HIT 23 NEMO RO forgatókönyvek – Infrastruktúrán alapuló optimalizáció Speciális infrastruktúra segíti az optimalizációs mechanizmusok implementációját (pl.: mint a MAP- ok a HMIPv6-ban, vagy a proxy HA a HAHA protokollban) Másik lehetőség DHCP alapú prefix delegáció használata („IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6”) –a nested NEMO MR-jehez az AR MNP-ket delegál, és az MR-ek a CoA-jukat is ebből a prefixből állítják elő. –így az adott AR-hez tartozó valamennyi MR CoA-ja egyetlen, aggregálható címtartomány része lesz, ami lehetővé teszi az egymásba ágyazott alagutak eliminálását

24 2008.03.20 Mobil Internet előadás BME-HIT 24 NEMO RO forgatókönyvek – NEMO-n belüli (intra-NEMO) optimalizáció NEMO struktúrákon belüli csomópontok (MNN-ek) egymással való kommunikációjának minőségét javítani szándékozó megoldások tartoznak ide pl.: –az MR-ek képesek MNP-ik többi MR felé történő kihírdetésére vagy –a NEMO struktúra kisimítása: a teljes NEMO struktúra egyetlen virtuális linkre kapcsolódva jelenjen meg. Ezt célozzák a Mobile Ad-hoc Network (MANET) protokollok: speciális ad-hoc routing protokollok használatával a struktúra belső működése zavartalan akkor is, ha a külvilág számára éppen nem elérhető.

25 2008.03.20 Mobil Internet előadás BME-HIT 25 NEMO RO – Szükséges kompromisszumok I. Az előnyök mellett természetesen bizonyos negatív hatásokkal is jár a NEMO RO mechanizmusok bevezetése, így kompromisszumokra van szükség: –Megjelenő új jelzési üzenetek (járulékos jelzésterhelés) új üzenetek bevezetésére van szükség, melyek összességében nagyobb terhelést okoznak a NEMO BS-hez képest az MNN-ek, CN-ek számának, valamint a beágyazottsági szinteknek a növekedésével ez a terhelés tovább nőhet mindez növeli a „BU Storm”, pontosabban a „Signaling Storm” veszélyét adaptív viselkedés segíthet időben szétkenni a burst-öket –Növekvő komplexitás, növekvő rendszerkövetelmények A NEMO RO mechanizmusok összetettebbek, mint a NEMO BS, így az ilyen protokollokat futtató rendszerek felé támasztott követelmények is komplexebbek –Hálózatváltás okozta késleltetés növekedése A NEMO RO módszerek üzenetváltásai, útvonal- és topológia-felfedező procedúrái nagyobb időigényűek, mint a NEMO BS egyszerűbb mechanizmusai FMIPv6-jellegű megoldásokkal orvosolható

26 2008.03.20 Mobil Internet előadás BME-HIT 26 NEMO RO – Szükséges kompromisszumok II. –Új funkciók megjelenése minél kevesebb NEMO entitást kell új funkcióval felvértezni az RO mechanizmus implementálásához, annál jobb, _de_ minél több NEMO entitás vesz részt az RO műveletekben, annál jobb lehet az új útvonal! LFN: nehéz új funkciókkal bővíteni, hiszen a szabvány szerint minden standard IPv6 csomópont lehet LFN. Így előfordulhat, hogy csak a módosított LFN-ek vehetnek részt az RO előnyeiből. VMN: mivel egy viszonylag új szabványt, a MIPv6-ot futtatják, ezért van rá esély, hogy nagyobb gond nélkül vértezhetők fel újabb funkciókkal MR: optimális esetben csak az MR kapna új, RO-t lehetővé tevő funkciókat AR: mivel hagyományos IPv6 routerekről van szó, ezért új funkciókkal való kibővítésük körülményes HA: viszonylag egyszerűen bővíthetők RO funkciókkal CN: nehéz új funkciókkal bővíteni, hiszen a szabvány szerint minden standard IPv6 csomópont lehet CN. Így előfordulhat, hogy csak a módosított CN-ek vehetnek részt az RO előnyeiből. CR: kifejezetten RO feladatok ellátásra (így új funkciók futtatására) definiált entitás

27 2008.03.20 Mobil Internet előadás BME-HIT 27 NEMO RO – Szükséges kompromisszumok III. –Új funkciók felismerésének biztosítása A kompatibilitás biztosításához szükség van annak eldönthetőségére, hogy egy adott RO protokoll követelményeinek egy adott hálózati entitás képes-e eleget tenni Az RO folyamat inicializálója indítja el felismerési folyamatot Negatív válasz esetén „graceful fall back” –Skálázhatóság Ugyanannyi belső csomópontot feltételezve a legtöbb RO protokollban több RO session egyidejű kezelése szükséges, mint NEMO BS esetén az egyidőben létező és fenntartott kétirányú alagutak száma Az MR és a CE entitások skálázhatósága ezért kiemelten fontos! –A mobilitás átlátszóságának biztosítása A NEMO BS egyik nagy előnye, hogy az MNN-ek számára tökéletesen átlátszó módon biztosítja a hálózati mobilitás támogatását, ám ez sok RO megoldás esetében nem oldható meg: az MNN-nek információval kell ellátnia MR-jét az optimalizáció műveleteinek végrehajtásához

28 2008.03.20 Mobil Internet előadás BME-HIT 28 NEMO RO – Szükséges kompromisszumok IV. –Privát szféra (Privacy) védelmével kapcsolatos megfontolások RO nélkül a CN nem rendelkezik információval a vele kommunikáló NEMO és MNN hálózati topológiában elfoglalt aktuális helyéről RO implementálásához azonban szükség lehet ilyen adatok CN-hez történő eljuttatására MIPv6 esetében az MN dönthet arról, hogy kívánja-e az RO mechanizmust használni, ám NEMO esetében sokszor csak az MR kezében van ennek az eldöntése, így MNN privát szférája veszélybe kerülhet –Biztonsági (Security) megfontolások A HA és az MR általában ugyanabból az adminisztrációs tartományból kerül ki, így NEMO BS esetében nincs probléma a köztük létrehozandó bizalmas kapcsolat kiépítése során RO mechanizmusok esetében az inicializáló MR adminisztrációs tartományától eltérő tartományba tartozó MR-ek/CE-k kerülnek a folyamatba: az RO mechanizmusokat kiegészítő biztonsági protokollokkal kell felvértezni! –Hagyományos (legacy) csomópontok támogatása Kompatibilitás lefelé

29 2008.03.20 Mobil Internet előadás BME-HIT 29 NEMO RO – Mekkora a problématér? I. Milyen NEMO entitások vesznek részt az RO műveletekben? –MNN és CN MNN hoz létre optimális útvonalat CN-je felé, hasonlóan a MIPv6 módszeréhez teljes vég-vég kapcsolat optimalizált, de: –skálázhatóság –új funkciók –átlátszóság –MR és CN az MNN-ek nevében az MR hoz létre optimális útvonalat a CN-ek felé ez is optimális út (hiszen az MNN összes csomagja így is, úgy is átmegy az MR-en), skálázhatóbb és kevesebb helyen kell új funkciókat implementálni, de: –a CN-ben itt is szükség van új funkciókra –MR-ekben tárolandó állapotinformációk nagy száma miatti skálázhatósági problémák –MR és CR CN és MNN új funkciókkal történő bővítésére nincs szükség, skálázható privacy viszonylagosan védett (csak a CR ismerhet kényes adatokat), de: –CR detektálása nehézkes lehet –security kérdések

30 2008.03.20 Mobil Internet előadás BME-HIT 30 NEMO RO – Mekkora a problématér? II. Ki inicializálja az RO folyamatokat és mikor? –Ki? logikus választás a topológiában helyet változtató (tehát mozgó) csomópont –nested esetben a sub-NEMO csomópontjait informálni kell a mozgás tényéről, ami jelzésterhelést jelent! a CE is inicializálhat –pl. egy már felállított RO kapcsolat időzítője lejár, de a kommunikáció még mindig aktív –Mikor? az RO költséggel jár, tehát megfontolás tárgya, hogy mikor indítjuk a folyamatait az RO session-öket milyen gyakori üzenetküldéssel tartjuk fent? –Lifetime dinamikus beállítása »rövid: CE-k cache-e friss, de nagy jelzésterhelés »hosszú: kisebb jelzésterhelés, CE-k cache-e elavulhat

31 2008.03.20 Mobil Internet előadás BME-HIT 31 NEMO RO – Mekkora a problématér? III. RO-képes csomópontok hogyan kerüljenek felismerésre? –kérdés: az RO inicializálója honnan tudja meg, hogy a CE rendelkezik-e az RO session létrehozásához szükséges funkcionalitással? Az inicializáló üzenetre a CE képességeit tartalmazó üzenettel hibaüzenettel válaszol (vagy egyáltalán nem is válaszol), ami újabb késleltetéseket okoz –kérdés: ha a CE nem CN hanem CR, akkor hogyan detektálható a jelenléte? pl. a CR-ek számára előre lefoglalt, „well-known” címekre (pl. anycast cím) történő csomagküldéssel Router Alert Option (RAO) beillesztésével a CN-nek szánt csomagba meg kell oldani több CR egy kérésre történő egyidejű jelentkezésének kérdését ártó CR-ek elleni biztonsági intézkedések foganatosítása

32 2008.03.20 Mobil Internet előadás BME-HIT 32 NEMO RO – Mekkora a problématér? IV. Honnan származtassuk az MNN címét? –Az RO általában azt jelenti, hogy az MNN címe és a NEMO- jának aktuális helye közti kötés a CE-ben tárolásra kerül –Az MNN címének származtatására két fő mód létezik: Az MNP alapján történő származtatás –az RO inicializálója ilyenkor az MR, és egyetlen üzenetben több MNN kötése végezhető el –ha azonban a privcacy sérül, akkor az MNP-hez tartozó valamennyi MNN érintett a problémában Explicit meghatározás (teljes MNN cím alapján történő kötés) –az MNN az inicializáló: új funkciók szükségesek –MR inicializál az MNN nevében: MR-ben minden hozzá tartozó MNN állapotát tárolni kell

33 2008.03.20 Mobil Internet előadás BME-HIT 33 NEMO RO – Mekkora a problématér? V. Hogyan kössük az MNN címét topológiai helyéhez? –Az RO mechanizmusokban elengedhetetlen az MNN címének és helyének egymáshoz kötése (binding) a CE-kben MNN címének a szülő MR aktuális topológiai helyéhez való kötése –BU-ban az MNP: NEMO BS logikus kiterjesztése (CE-n kétirányú tunnel az MR-hez, és az MNP beleirányítva a tunnelbe) –szülő MR-rel kapcsolatos információk küldése: MNN ezen új funkciójával a kötés elvégezhető –MR proxy jellegű funkciókkal való kiegészítése: az MR az MNN nevében végez kötéseket MNN címének upstream MR-ek szekvenciájához való kötése –A CE így egyből pontos információkhoz jut, ám az MNN honnan szerzi meg upstream MR-jeinek szekvenciáját? –Speciális Router Advertisement üzenetek segítik a topológia felderítést –MR-ek hierarchiáján is át kell vinni az RA üzenetek információit –A mobilitás átlátszósága sérül –Nested esetben az upstream MR-ek helyzetének változása RO folyamatokat indukál a downstream MR- eknél MNN címének a root MR aktuális topológiai helyéhez való kötése –A CE közvetlenül a root MR-hez küldi az MNN-nek irányzott csomagjait, a NEMO-n belül pedig a struktúra „kisimításával” kerülnek a csomagok optimális úton az MNN-hez: »Prefix delegation/Neighbour Discovery Proxy/Hierarchical Registrations/Mobile Ad-hoc routing

34 2008.03.20 Mobil Internet előadás BME-HIT 34 NEMO RO – Mekkora a problématér? VI. Hogyan vigyük át az RO jelzésüzeneteket? –„in-plane” jelzésüzenetek beépítése adatcsomagok fejléceibe folyamatos adatátvitel közben a struktúra esetleges átalakulása miatti változások egyszerűen közölhetők a CE-vel: gyakran változó struktúrákban gyors reagálás –„off-plane” saját, dedikált jelzésüzenetek definiálása „in-plane” módszerhez képest a jelzési overhead csökkenését jelenti ritkán változó struktúrákban –„in-plane” és „off-plane” egyszerre előnyök egyesítése

35 2008.03.20 Mobil Internet előadás BME-HIT 35 NEMO RO – Mekkora a problématér? VII. Hogyan vigyük át a hasznos adatokat tartalmazó csomagokat? –a kialakított, optimalizált útvonalon történő IP-IP alagút létrehozásával hagyományos routing infrastruktúra használható itt is előfordulhat többszörös alagutazás: overhead! –routing fejlécek használatával hasznos, ha a küldő az MR-ek szekvenciáját ismeri, így a keresztezendő MR-eket a fejlécben explicite jelölve megszabja a csomag útvonalát –routing bejegyzések felvételével a szülő MR-ekben forráscím alapú útvonalválasztás (source address routing) támogatásához

36 2008.03.20 Mobil Internet előadás BME-HIT 36 NEMO RO – Mekkora a problématér? VIII. Milyen biztonsági megfontolásokat kell figyelembe venni? –CE-k védelme DoS Snooping –MNN-ek védelme CR valóban az, akinek mondja magát? –Vég-vég integritás védelme proxy-jellegű megoldások megtörik a vég-vég kapcsolatokat – Privát szféra védelme („Location privacy”): helyinformációk felfedése a CE-k felé felfedés mértéke (pl. csak a root MR-t tudja, vagy a teljes utat) felfedés felügyelete (MNN képesség: optimális útvonal vs. tökéletes privacy)

37 2008.03.20 Mobil Internet előadás BME-HIT 37 Optimized NEMO (ONEMO) – A módszer alapötlete Motiváció: rövidítsük le az útvonalat úgy, hogy a legrövidebb (közvetlen) úton kommunikáljon a CN és az MNN. Új –csomagtovábbító algoritmus –jelzési protokoll mely a partner dinamikus felfedezésére szolgál –Router Advertisement (RA) üzenet a beágyazott NEMO átjárójának kihirdetéséhez –BU mechanizmus az optimális útvonal kiépítéséhez Egyetlen alagutat használjunk csak fel a root MR és a CR között Az alagút kiépítését a kommunikáló MNN-ek közvetlen upstream MR-jei kezdeményezik A protokoll –definiál egy CN-hez közeli CR-t (ami akár MR is lehet, de nem szükséges mobility handover-t támogatnia), lehetőleg a CN hálózatában –bevezeti a NEP (Nest Entrance Point) fogalmát (NEP: a root-MR CoA-ja) A NEP-et a root MR RA üzenetben hirdeti a sub MR-eknek A sub MR-ek a felső interfészeiken kapott RA-kból kimásolják, és a saját MNP-jüket tartalmazó RA-jukba bemásolják a NEP option-t Minden sub MR-ben található egy NET (Nest Entrance Table), ebben tárolják a NEP-et. Az MR ez alapján képes RO kezdeményezésére A root MR végzi el az RO tunnel kiépítését a sub-MR-ek nevében Az adatok a root MR és a CR közötti alagútban mennek, a root MR alatt routing továbbítja a csomagokat az MNN felé (amíg nincs kész az RO alagút, addig az adatok a NEMO BS szerinti sub- optimális útvonalon haladnak)

38 2008.03.20 Mobil Internet előadás BME-HIT 38 Optimized NEMO (ONEMO) – Működés I. A CN a NEMO BS szerinti útvonalon küldi csomagjait az MNN-nek. Közvetlenül az MNN feletti MR kezdeményezheti az RO-t, amikor megkapja az első ilyen csomagot a HA-jától (tehát a módszer feltételezi a NEMO BS meglétét) Az RO-t kezdeményező MR ellenőrzi, hogy a CN nincs-e az MNN-el azonos nested hálózatban –Ha azonos nested hálózatban vannak, akkor sima routing alapján továbbítja a csomagokat –Ha nincsenek azonos hálózatban, akkor az MR egy CR Discovery üzenetet küld egy „well-known”anycast címre, amit a CN-től kapott csomag forráscíméből származtat A CR Discovery üzenetre a CR egy CR Replay üzenettel válaszol, mely tartalmazza a CR global unicast címét Erre a global címre küld az MR egy Reflective BU-t (RBU), amiben szerepel a NEP. A CR beírja a NEP-et a Binding Cache-ébe A CR erre a NEP-re küld egy BU-t (a hagyományos routingra támaszkodva). A root MR visszaküld egy BA-t és kiépül az RO alagút a CR és a root MR között

39 2008.03.20 Mobil Internet előadás BME-HIT 39 Optimized NEMO (ONEMO) – Működés II. MR intra-NEMO mozgása nem okoz problémát (hagyományos routing-al megoldható a NEMO belsejében) MR inter-domain mozgása esetében az új címet kapó MR frissíti HA-ját a NEMO BS alapján. Az elmozgott MR az új root MR-től kapott NEP címmel küld egy új RBU-t a CR-nek. Ezután CR küld egy BU-t a NEP címére. Kiépül a tunnel a CR és a root MR között. Root MR mozgása esetén frissíteni kell a root MR HA-ját a NEMO BS szerint. Ezután kitalálja, hogy még mindig root pozícióban van-e (a kapott RA-kból), és ha igen, akkor megváltoztatja az RA-jában a hirdetett NEP-et. Ezt érzékelik sub MR-jei, amik elkezdik az RO kiépítést. LMN vagy VNM mozgása során a normál MIPv6 szabályainak megfelelően jár el az ONEMO. Ha egy mozgó MNN új MR alá érkezik, akkor végrehajtja a MIPv6 szerint az otthoni regisztrációt, és ha volt aktív kapcsolata egy CN-nel, akkor végrehajtja vele a MIPv6 RO-t. Ezután már az adatok az MN HA-jának kihagyásával közlekednek, de az új MR-nek nincs még optimalizált útvonala az újonnan érkezeett MNN CN-je vagy annak CR-je felé: egy ideig még NEMO BS útvonalon jut el a MIPv6 jelzés, és az adatok is a MNN-től a CN-ig. Ezutánaz MNN upstream MR-je észreveszi, hogy ONEMO RO-ra van szükség: végrehajtja az RO-t, hogy ne a NEMO BS útvonalon menjenek az adatok. A folyamat végén az összes HA-t kihagyja az útvonal.

40 2008.03.20 Mobil Internet előadás BME-HIT 40 Optimized NEMO (ONEMO) – Előnyök és hátrányok Előnyök: –Nem szerepel HA az optimalizált útvonalon –A jelzési overhead független a beágyazottsági szinttől –Nincs háromszögelés az RO útvonalon –Megoldást kínál valamennyi létező use case-re (non-nested, distinct nested, same nested, MIPv6 és nem MIPv6 képes node- ok közötti kommunikáció) –Megoldja az intra-NEMO mozgás kérdéseit Hátrányok: –Ha sok MNN kommunikál ugyanabból a nested hálózatból, akkor a root MR-nek sok alagutat kell kezelnie (mozgás esetén frissítenie), így nagy lehet a számítási terhelés a root MR-ben.

41 2008.03.20 Mobil Internet előadás BME-HIT 41 MR-Assisted RO (MoRaRo) – A módszer alapötlete Motiváció: kiterjeszteni a MIPv6-os RO megoldást NEMO hálózatokra is Az MNN a CN-el RO-t csak egyszer, a kommunikációs session kezdetén hajt végre. A különböző mozgások során a root MR fogja kezelni a hozzá tartozó MNN-ek RO session-jeit. Ennek érdekében a MoRaRo az MR-ekben definiál egy speciális Bindig Cache-t (MRBC). Ebben tárolja az adott MR a hozzá tartozó nested MR-ek CoA-jai és a rajtuk keresztül elérhető MNP-k közötti kötéseket. Az MR az MRBC bejegyzései alapján továbbítja a csomagokat a beágyazott NEMO hálózatban. Az MRBC bejegyzései időbélyeget tartalmaznak, ezért bizonyos időközönként a sub MR-eknek újra kell regisztrálniuk magukat (és MNP-jüket) a root MR-nél. A root MR-ben tartalmaz egy másik Binding Cache-t is (ROBC), melynek segítségével képes az egész struktúra valamennyi MNN-jei nevében az RO fenntartására mozgások során. Az MNN HoA-ja, CoA-ja, CN-jeinek a címe,valamint a biztonságos működéshez szükséges adatok közötti kötéseket tárolja. Amíg forgalom van az MNN és CN-jei között, addig nem törlődik az ROBC bejegyzés, ám ha nincs forgalom, akkor adott idő múlva törlésre kerül. A root MR folyamatosan hirdeti CoA-ját és HoA-ját a sub MR-jeinek RA üzeneteiben. A MoRaRo egyetlen alagutat használ a működéshez, mégpedig a root MR és MNN-jei között (az ROBC és MRBC adatainak segítségével alagutazza az MNN-ig a csomagokat).

42 2008.03.20 Mobil Internet előadás BME-HIT 42 MoRaRo – Működés I. A root MR megnézni a beérkező csomag RH 2-es (Routing Header Type 2) fejlécének Home Address Option mezejét, így megtudja az MNN HoA-ját (ennek a csomagnak a forráscíme a CN, és célcíme a root MR CoA, mert a CN- nél bejegyzett Binding Cache az MNN HoA-ját a root MR CoA-jához köti). Ezt követően a root MR az ROBC-ben megkeresi az MNN HoA-jához tartozó CoA-t, majd az MRBC alapján továbbítja a csomagot egy olyan alagútban, aminek a forráscíme a root MR HoA-ja, és célcíme az MNN CoA-ja. Az MNN –> root MR irányban is hasonló a helyzet, az alagútban egy root MR CoA - CN forrás és célcímű csomag megy (dest. address: root-MR HoA, src. address: MN CoA). Érdekes kérdés, hogy miért a root-MR HoA-ja a dest. addr.. Ennek két oka van: –ha a root-MR miközben továbbítaná a root-MR HoA-ja felé a csomagot, magára ismer a célcímben, és feldolgozza, továbbítja a csomagot a CN-hez. –ha az MNN vagy az MNN-t tartalmazó nested NEMO sub-tree elmozog a root MR- től, akkor a NEMO BS által még a régi root MR-en át fog menni az adatfolyam, legalábbis addig, amíg nem történik meg a MoRaRo RO. Amíg nincs kész az RO, addig az adatok a NEMO BS szerinti útvonalon haladnak

43 2008.03.20 Mobil Internet előadás BME-HIT 43 MoRaRo – Működés II. CN a NEMO BS szerinti útvonalon küld egy csomagot az MNN-nek. Közvetlenül az MNN feletti upstream MR továbbítja a csomagot az MNN-nek. Ha az MNN-nek még nincs RO útvonala a CN- hez, akkor beindul a MoRaRo RO. A Return Routability teszt után küld az MNN egy RO-Inform üzenetet a root-MR-nek. –az MNN a MIPv6-nál megismert RR tesztet csinál a CN-nel –Az ROBC-hez szükséges adatokat (amely az RO útvonal fenntartásához szükséges), az MNN az RO-Inform (MNN HoA, CoA, CN cím, auth. data) üzenetben küldi a root MR-nek, az RR test után. Erre az RO-Inform üzenetre válaszol a root MR egy RO-accept üzenettel. Ha ez sikeres, akkor az MNN küld egy BU-t a CN-nek (a Mobility Header Mobility Options részében az Alternate Care-of Address Option-ben a root MR CoA-val /lokátor funkció/, és a Destination Options Header Home Address Option-jében az MNN HoA-jával /azonosító funkció/)). Ezután CN a Binding Cache-ben létrehoz egy bejegyzést (MNN HoA root MR CoA), küld egy BA-t az MNN-nek (Routing Header Type 2-ben tartalmazza a MNN HoA-ját /azaz, hogy kinek szól az üzenet/, a célcím viszont a root-MR CoA-ja lesz). Ezután RH Type 2-es fejlécekkel (ezen belül a Home Address Option-nal, ami a MNN HoA-át /azonosítóját/ tárolja) a root MR-nek küldi az adatokat. A CN felé menő forgalomban pedig a Destination Options Header tartalmazza a MNN HoA-ját, és ez, illetve a meglévő binding cache-ek „jelentik” az alagutat. LFN, esetén az MR egy proxy-ként működik. MR végzi el az RO-hoz szükséges feladatokat a saját CoA-jával, az LFN CoA-ja helyett. A csomagokat pedig továbbítja az LFN-nek.

44 2008.03.20 Mobil Internet előadás BME-HIT 44 MoRaRo – Működés III. Az MR-ek inter-domain mozgása esetében az új címet kapó MR-ek regisztrálják CoA- jukat és MNP-(ike)t, azokhoz az MR-ekhez, akik a hierarchiában felettük állnak, egészen a root-MR-ig (egy elmozgott hálózatban ezt elég a legfelső MR-nek megtennie, mert ő tudja minden alatta lévőnek is az információját). Emellett a NEMO BS miatt az elmozgott hálózat root MR-je (tehát az új CoA-t kapó MR) frissíti HA-ját is. MR-ek intra-NEMO mozgása során ugyanaz a teendő, mint inter-domain mozgás esetén. A root MR mozgása esetén frissíti HA-ját, majd értesíti az aktív RO session-ben résztvevő CN-eket egy BU üzenetben a CoA változásáról. Az ehhez szükséges adatokat a ROBC-ből tudja, így nincs szükség ehhez az MNN-ekre. Nem szükséges az RR teszt végrehajtása sem. Az alatta levő sub MR-eket RA-ban értesíti a címváltozásról, így az alatta lévő összes MNN tudja, hogy a jövőben a MoRaRo RO-nál az új root MR CoA-t használja a BU Alternate Care-of-Address mezőben. MNN mozgás esetén ha egy új Access Router alá érkezik, akkor végrehajtja a MIPv6 szerint az otthoni regisztrációt, plusz, ha közben beszélt egy CN-nel, akkor végrehajtja felé is a MIPv6 RO-t. Ezután már az adatok a MNN HA-jának kihagyásával jutnak el (MIPv6 RO-optimalizált útvonal). Ha az MNN egy új MR alá érkezett (látja a BA-ból), akkor a teljes MoRaRo RO-t hajtja végre.

45 2008.03.20 Mobil Internet előadás BME-HIT 45 MoRaRo – Előnyök és hátrányok Előnyök: –Nincs szükség dupla optimalizációra, azaz nem kell külön az MNN mozgásokhoz egy MIPv6 RO, majd ezután egy NEMO RO –Kevés bevezetendő új funkció, nem definiál új hálózati entitást a már meglévőkön kívül –Az MNN a CN-el csak egyszer, a session kezdetén hoz létre RO-t (kivéve, ha az MNN elmozog), ugyanis a NEMO mozgásoknál átveszi az MNN-ek szerepét a root MR –Az RO során kialakított új útvonal már nem tartalmazza a HA-t –Nem lesz háromszögelés az RO útvonalon –A jelzésterhelés független a beágyazottság szintjétől Hátrányok: –A CN-nek mindenképpen MIPv6 képesnek kell lennie (nincs CR) –A root MR egy „single point of failure” –MRBC bejegyzések fentartása és lejárat utáni frissítése

46 2008.03.20 Mobil Internet előadás BME-HIT 46 Irodalom [] T. Ernst, H-Y. Lach: “Network Mobility Support Terminology”, IETF RFC 4885, July 2007. [] T. Ernst: “Network Mobility Support Goals and Requirements”, IETF RFC 4886, July 2007. [] V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert: “Network Mobility (NEMO) Basic Support Protocol”, RFC 3963, January 2005. [] B. McCarthy, C. Edwards, M. Dunmore: “Applying NEMO to a Mountain Rescue Domain”, ICOIN2006, LNCS 3961, pp. 10-20, 2006. [] N. Montavont, T. Noel, T. Ernst: “Multihoming in Nested Mobile Networking”, IEEE SAINTW’04, pp 184-189, 2004. [] E. Perera, V. Sivaraman, A. Seneviratne: “Survey on Network Mobility Support”, ACM SIGMOBILE CCR, V36-I2, April 2004. [] C. Ng, P. Thubert, M. Watari, F. Zhao: “Network Mobility Route Optimization Problem Statement”, IETF RFC 4888, July 2007. [] C. Ng, F. Zhao, M. Watari, P. Thubert: “Network Mobility Route Optimization Solution Space Analysis”, IETF RFC 4889, July 2007. [] R. Wakikawa, M. Watari: “Optimized Route Cache Protocol (ORC)”, Internet Draft, draft-wakikawa-nemo-orc-01.txt, October 2004. [] Jongkeun Na, Seongho Cho, Chongkwon Kim, Sungjin Lee, Hyunjeong Kang, Changhoi Koo: “Route Optimization Scheme based on Path Control Header”, Internet Draft, draft-na-nemo-path-control-header-00.txt, November 2004. [] P. Thubert, M. Molteni: “IPv6 Reverse Routing Header and its application to Mobile Networks”, Internet Draft, draft-thubert-nemo-reverse- routing-header-07.txt, February 2007. [] C. Ng, J. Hirano: “Securing Nested Tunnels Optimization with Access Router Option”, Internet Draft, draft-ng-nemo-access-router-option- 01.txt, January, 2005. [] Jongkeun Na, Seongho Cho, Chongkwon Kim, Sunjin Lee, Hyunjeong Kang, Changhoi Koo: “Secure Nested Tunnels Optimization using Nested Path Information”, Internet Draft, March, 2004. [] Troan, O. and R. Droms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6”, RFC 3633, December 2003. [] P. Thubert, R. Wakikawa, V. Devarapalli: “Global HA to HA protocol”, draft-thubert-nemo-global-haha-02.txt, Internet Draft, April 2007. [] S. Baek, J. Yoo, T. Kwon, E. Paik, M. Nam: “Routing Optimization in the same nested mobile network”, Internet Draft, draft-baek-nemo- nested-ro-00.txt, October 2005. [] M. Watari, T. Ernst, R. Wakikawa, J. Murai: “ONEMO - Routing Optimization for Nested Mobile Networks”, IEICE Trans. Commun. Vol. E89-B, No. 10, Oct. 2006. [] Ved P. Kafle, E. Kamioka, S. Yamada: “MoRaRo: Mobile Router-Assisted Route Optimization for Network Mobility (NEMO) Support”, IEICE Trans. Inf. & Syst., Vol. E89-D, No. 1, January 2006.

47 2008.03.20 Mobil Internet előadás BME-HIT 47 Köszönöm a figyelmet!