470 likes | 584 Views
Mobil Internet 10 . előadás – Mozgó hálózatok t ámogatása ( NEMO routing optimali záció) Bokor László bokorl @hit.bme.hu. BME Híradástechnikai Tanszék 2008/2009 tavaszi félév. Kivonat. Egy kis ismétlés NEMO RO – NEMO BS problémáinak hatásai NEMO RO – Problémafelvetés
E N D
Mobil Internet10. előadás – Mozgó hálózatok támogatása(NEMO routing optimalizáció)Bokor Lászlóbokorl@hit.bme.hu BME Híradástechnikai Tanszék 2008/2009 tavaszi félév
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) Mobil Internet előadás BME-HIT
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! Mobil Internet előadás BME-HIT
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! Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
Binding Update Kétirányú alagút MNP 2001:738:2001:2089::/64 LFN címe 2001:738:2001:2089::eui64/64 Egy kis ismétlés – NEMO Basic Support Binding Cache: 2001:738:2001:2088::eui64/64 – MR-CoA 2001:738:2001:2089::/64 – MR-CoA 3ffe:ffff:fe3:8000::/64 2001:738:2001:2088::/64 MR-HoA 2001:738:2001:2088::eui64/64 MR-CoA 3ffe:ffff:fe3:8000::eui64/64 Mobil Internet előadás BME-HIT
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) Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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” Mobil Internet előadás BME-HIT
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és1 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” 1Deering, S. and B. Zill, "Redundant Address Deletion whenEncapsulating IPv6 in IPv6", Work in Progress, November 2001. Mobil Internet előadás BME-HIT
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. Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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! Mobil Internet előadás BME-HIT
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. Mobil Internet előadás BME-HIT
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é Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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) Mobil Internet előadás BME-HIT
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) Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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ő. Mobil Internet előadás BME-HIT
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ó Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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é Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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) Mobil Internet előadás BME-HIT
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) Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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. Mobil Internet előadás BME-HIT
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. Mobil Internet előadás BME-HIT
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). Mobil Internet előadás BME-HIT
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 Mobil Internet előadás BME-HIT
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. Mobil Internet előadás BME-HIT
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. Mobil Internet előadás BME-HIT
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 rootMR egy „single point of failure” • MRBC bejegyzések fentartása és lejárat utáni frissítése Mobil Internet előadás BME-HIT
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 OptimizationProblem 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. Mobil Internet előadás BME-HIT
Köszönöm a figyelmet! Mobil Internet előadás BME-HIT