BME Híradástechnikai Tanszék 2008/2009 tavasz

Mobil Internet11. előadás – Multihoming IPv6 hálózatokban (MIPv6 és NEMO multihoming alapok)Bokor Lászlóbokorl@hit.bme.hu BME Híradástechnikai Tanszék 2008/2009 tavasz

Kivonat • Egy kis ismétlés • Multihoming – Terminológia • Multihoming – Bevezetés • Multihoming – Mire is jó? • Multihoming – Célok és előnyök • Multihoming – Megoldandó problémák • MIPv6 multihoming – Terminológia • MIPv6 multihoming – Lehetséges konfigurációk • NEMO multihoming – Terminológia • NEMO multihoming – Lehetséges konfigurációk • Multiple Care-of Addresses Registration (MCoA) 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 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

Multihoming – Bevezetés • Konvergencia, heterogén rendszerek • Ubiquitous Internet („bármikor, bárhonnan”) • Különböző hozzáférési technológiák együttélése • Több interfész integrálása egyetlen eszközbe • Kommunikációs folyamok dinamikus átirányítása interfészek között • Optimális interfész kiválasztása • ár • teljesítmény • sávszélesség • megbízhatóság • lefedettség • ... • Interfészek kombinálása, együttes használata Mobil Internet előadás BME-HIT

Multihoming – Terminológia • Interfész: hálózati entitás csatlakozási pontja a link(ek)hez • Multihomed node („többotthonú” csomópont): • olyan hoszt vagy router, mely több IPv6 cím közül választhat • több prefix segítségével (multi-prefixed): egy vagy több linkjén több prefix kerül hirdetésre • több interfész segítségével (multi-interfaced): egy vagy több linkre csatlakozik több interfésze Mobil Internet előadás BME-HIT

Multihoming – Mire is jó? I. • Internet-hozzáférés bárhonnan, bármikor • egy adott hozzáférési technológia korlátozott lefedettségi területéről elmozdulva átválthatunk egy másik (szélesebb lefedettséget biztosító) technológiára, így a folyamatban lévő kommunikációs session nem szűnik meg • pl. WiFi (WLAN az épületben) – WiMAX (WMAN a városban) Mobil Internet előadás BME-HIT

Multihoming – Mire is jó? II. • Folyamatban lévő session-ök átirányítása • egy adott hozzáférési technológiát használó session átirányítása egy másik technológiára, felhasználói preferenciák vagy a folyam követelményei alapján • pl. UMTS-en érkező videohívás átirányítása WiFi hotspot hozzáférésre Mobil Internet előadás BME-HIT

Multihoming – Mire is jó? III. • Felhasználói preferenciáknak való megfelés • rögzített infrasturktúrán történő válogatás a hozzáférési technológiák közül, felhasználói igények szerint • pl. otthoni dial-up, publikus WLAN és UMTS kapcsolat esetében: • publikus WLAN a nem érzékeny adatok átvitelére (web-böngészés) • UMTS a biztonságos adatátvitelhez (nem baj, ha drágább) • dial-up (lassú, de olcsó, így éjszakára fájlrendszer-szinkronizálásához tökéletes) Mobil Internet előadás BME-HIT

Multihoming – Mire is jó? IV. • A legjobb elérhető hozzáférési konfiguráció kiválasztása • az aktuális feltételeknek való optimális megfelelés, tökéletes alkalmazkodás • pl. orvos a mentőkocsiban: • balesethez hívják, celluláris hálózaton tartja a kapcsolatot a központtal • súlyos fejsérült ellátáshoz konzultálnia kell: video-hívást kezdeményez a celluláris hálón • szüksége van a beteg adataira: letöltést indít, de nem a celluláris hálón kapja az adatokat, hanem a mentőkocsi műholdas down-linkjén, ami jobban megfelel a nagy adathalmaz gyors letöltésére • up- és downlink elkülönített kezelését is biztosítani kell! Mobil Internet előadás BME-HIT

Multihoming – Mire is jó? V. • Megbízhatóság növelése • hibatűrő, redundáns kommunikációs rendszerek létrehozása • bi-casting down- és up-stream irányban • pl. rendfentartó egység kommunikációját biztosító architektúra Mobil Internet előadás BME-HIT

Multihoming – Mire is jó? VI. • Átvitel sebességének növelése • redundáns hozzáférések egyidejű használata az adatáviteli sebesség növelése céljából • pl. reptéren a gép indulása előtt még gyorsan letölteni a munkához szükséges fájlokat: két WLAN kártyával két AP-hoz csatlakozva növelhetjük a rendelkezésünkre álló sávszélességet Mobil Internet előadás BME-HIT

Multihoming – Célok és előnyök • Állandó és „ubiquitous” hozzáférés • Hálózati lefedettség technológiákon átívelve történő növelése • Megbízhatóság, hibatűrés • Hálózati komponens multiplikálása • Kommunikációs folyamok átirányítása • A már kiépített folyam leállítása és ismételt felépítése nélkül! • Terhelés-megosztás • A hálózat terhelésének több útvonal segítségével történő elosztása • Terhelés-kiegyenlítés / folyamok szétosztása • Adott folyam több interfészen történő (együttes vagy szeparált) átvitele • Felhasználók választási lehetőségeinek bővítése • Felhasználói preferenciák alapján történő hozzáférés/hálózat kiválasztásának támogatása • Aggregált sávszélesség • Több interfész, több hozzáférés, több hálózat, nagyobb szávszélesség Mobil Internet előadás BME-HIT

Multihoming – Célok és előnyökaz „egy interfész, több prefix” esetben • Pl. Egy WLAN kártya egy AP-hoz csatlakozova, de az AP két AR-felől továbbít router hirdetéseket • Állandó és „ubiquitous” hozzáférés: NEM • ha megszűnik az egyedüli használható link, akkor megszűnik a kapcsolat a külvilág felé • Megbízhatóság, hibatűrés: BIZONYOS ESETEKBEN • az egyik AR (tehát az egyik IPv6 prefix) meghibásodását képes kezelni (bi-casting) • Kommunikációs folyamok átirányítása: IGEN • hasznos lehet az egyik AR (tehát az egyik IPv6 prefix) meghibásodásakor • Terhelés-megosztás: IGEN • a hoszt különböző címeit használva a terhelés a hálózat szempontjából megosztható (pl. a két AR között) • Terhelés-kiegyenlítés / folyamok szétosztása: NEM • egyetlen interfészen ez nem megoldható • Felhasználók választási lehetőségeinek bővítése: IGEN • a használt forráscím a felhasználói preferenciáknak megfelelően választható ki (pl. melyik routert kívánjuk alapértelmezettként használni) • Aggregált sávszélesség: BIZONYOS ESETEKBEN • indirekt módon megoldható: a rendelkezésre álló címek között váltogatva a teljes átvitel nőhet (pl. az AR-ek közötti terhelés-megosztás miatt), vagy a cím alapján forgalmat korlátozó szerverek „kijátszásával” Mobil Internet előadás BME-HIT

Multihoming – Célok és előnyöka „több interfész” esetben • Egyszerre, vagy felváltva használható több interfész áll rendelkezésre • Pl. Egy WLAN és egy UMTS kártya • Állandó és „ubiquitous” hozzáférés: BIZONYOS ESETEKBEN • több hozzáférési hálózat közül válogatva nagyobb esélyünk van a „bárhol bármikor” biztosítására • Megbízhatóság, hibatűrés: IGEN • a redundancia két szintje: véd a link eltűnése és a cím érvénytelenné válása ellen is • Kommunikációs folyamok átirányítása: IGEN • a két interfész között bármilyen forgatókönyvet követve, bi-casting linkek és címek között egyaránt • Terhelés-megosztás: IGEN • A hoszt különböző interfészeit használva a terhelés a hálózat szempontjából megosztható (pl. az AR-ek között) • Terhelés-kiegyenlítés / folyamok szétosztása: IGEN • több interfész esetében megvalósítható • Felhasználók választási lehetőségeinek bővítése: IGEN • interfész- és címválasztás egyaránt • Aggregált sávszélesség: IGEN • eltérő hozzáférési hálózatok egyidejű jelenlétével az elérhető átvitel a két hálózat képességeinek aggregáltja lesz Mobil Internet előadás BME-HIT

Multihoming – Megoldandó problémák • Forráscím kiválasztása • a kommunikációs folyamatokban a forráscímként használt cím kiválasztása az egyik legfontosabb kérdés, melynek megválaszolásában rengeteg paraméter szerepet játszhat: • felhasználói preferencia • ingress filtering • célprefix • interfész típusa • link karakterisztikája • A hiba felismeréséből és a helyreállításból eredő késleltetés • a link megszakadásának/cím érvénytelenségének detektálása, majd a felépülés késleltetést eredményez • bizonyos transzport rétegbeli protokollok (pl. SCTP) támogatják a multihomingot, így ezt a kérdést hatékonyan megoldják • Az átvitel karakterisztikájának változása • egy adott adatfolyam másik útvonalra történő terelése a vég-vég karaktersztika megváltozása (pl. magasabb késleltetés, csomagvesztés, MTU, stb.) miatt gondokat okozhat az átvitelben • ezt a magasabb rétegekben kezelni kell • Átlátszóság biztosítása • a címváltozás a lehető legkisebb behatást eredményezze a felsőbb rétegekben • pl.: az új címre/címekre történő adattovábbítást meg kell oldani (pl. MIPv6 és NEMO mechanizmusait használva/kiegészítve) Mobil Internet előadás BME-HIT

MIPv6 Multihoming – Terminológia • Multihomed Mobile Node („többotthonú” mobil csomópont) • Az általános (multihomed node) definíciója így pontosul: az MN multihomed, ha • egyszerre több címet használhat forráscímként • több alagút áll rendelkezésére a csomagok továbbítására • több Home Address (HoA) • több prefix érhető el az otthoni linken • több interfésze van az MN-nek eltérő otthoni linkeken • több Care-of Address (CoA) • több prefix érhető el az idegen linken • több interfésze van az MN-nek eltérő idegen linkeken • A HA több címmel rendelkezik (vagy több HA-val rendelkezik az MN) • mindkét fenti eset egyidejű fennállása • Több cím egyidejű használata • egy bejövő csomag az egyszerre használt címek bármelyikét célcímként tartalmazva eléri az MN-t vagy ezen címek bármelyike használható forráscímként • Több interfész egyidejű használata • Bármelyik interfészről küldhető IP csomag Mobil Internet előadás BME-HIT

MIPv6 Multihoming – A megvalósítás követelményei • Nem haszált interfészek gyors aktiválása • Forgalom átirányítása címek/interfészek között • Érvényes címek egyidejű használhatósága • Több interfész egyidejű használhatósága • Érvényes címek között a forgalom megosztásának képessége • Ha több Home Agent létezik az MN HoA-jához tartozó kötések kezelésére, akkor az MN-nek képesnek kell lennie ezen otthoni ügynökök egyidejű használatára, vagy a közöttük történő váltásra • Átlátszóság biztosítása (TCP-vel nehéz, SCTP-vel könnyebb) Mobil Internet előadás BME-HIT

MIPv6 Multihoming – Lehetséges konfigurációk I. • 1 HoA, 1 CoA: (1,1) • multihoming csak több interfész létezése esetén jöhet szóba • maximum két interfész lehet egyszerre aktív ebben a forgatókönyvben, mert ellenkező esetben vagy: • több interfész lenne az otthoni linken (több HoA) • több interfész lenne az idegen linken (több CoA) • Képességek: • Megbízhatóság: korlátozott megvalósíthatóság • csak két érvényes címünk van (a HoA és a CoA), de ezek _egyszerre_ nem használhatóak adatok vételére: az otthoni és az idegen hálózaton _egyszerre_ nem kaphat csomagokat az MN (természetesen a kettő közti átkapcsolás lehetséges) • ha az egyik cím érvénytelenné válik, akkor a kommunikációs folyamatokat újra lehet inicializálni a másik címre, de ez nem transzparens • Terhelés-kiegyenlítés/folyamok megosztása • az MN által továbbított folyamok használhatják egyszerre a két interfészt, így ezek az előnyök kihasználhatók • a CN-nek azonban meg kell adnia melyik címre/interfészre kívánja az adatokat küldeni: ebben az irányban nem érhető el terlhelés-kiegyenlítés és folyam-megosztás Mobil Internet előadás BME-HIT

MIPv6 Multihoming – Lehetséges konfigurációk II. • n HoA, 1 CoA: (n,1) • az MN multihomed, hiszen több HoA-ja van (pl. egyszerre két operátornál is előfizető) • ha az MN több interfésszel rendelkezik, akkor csak egy lehet ezek közül az idegen linkhez csatlakozva • Képességek: • Megbízhatóság: korlátozott megvalósíthatóság • Ha az otthoni ügynök leáll, akkor a kommunikációs folyamatot újra kell inicializálni • Ha a használt HoA érvénytelenné válik • vagy a HA állt le: előző eset • vagy a HoA nem kerül megfelelően a HA-hoz (routing hiba): a HoA nem változtatható meg átlátszó módon, a kommunikációs folyamatot újra kell inicializálni • Terhelés-kiegyenlítés/folyamok megosztása • mechanizmus szükséges ahhoz, hogy az MN kiválaszthassa melyik HoA-t használja egy folyam inicializálásához és ahhoz is, hogy a CN tudjon választani az MN HoA-i közül • folyamok interfészek közti megosztása szintén lehetséges, de csak az MN felől indulók esetében Mobil Internet előadás BME-HIT

MIPv6 Multihoming – Lehetséges konfigurációk III. • 1 HoA, n CoA: (1,n) • az MN multihomed, hiszen több CoA-ja van (pl. több interfésszel több idegen hálózatra kapcsolódik) • ha az MN több interfésszel rendelkezik, akkor csak egy lehet ezek közül az otthoni linkhez csatlakozva • Képességek: • Megbízhatóság: korlátozott megvalósíthatóság • érvénytelenné vált CoA okozta problémákból képes felépülni az ilyen rendszer • Terhelés-kiegyenlítés/folyamok megosztása • több CoA-t kellene kötni egyetlen HoA-hoz (új típusú regisztrációra van szükség) Mobil Internet előadás BME-HIT

MIPv6 Multihoming – Lehetséges konfigurációk IV. • n HoA, n CoA: (n,n) • a II. és a III. konfigurációk kombinációjaként tekinthető • Képességek: • Megbízhatóság: • érvénytelenné vált CoA és HoA okozta problémákból is képes felépülni az ilyen rendszer • a leginkább hibatűrő konfiguráció • Terhelés-kiegyenlítés/folyamok megosztása • a MIPv6 módosítása nélkül is lehet eltérő CoA-kat eltérő HoA-khoz kötni (ebben a forgatókönyvben új típusú regisztrációra nincs szükség) Mobil Internet előadás BME-HIT

MIPv6 Multihoming – Lehetséges konfigurációk V. • n HoA, 0 CoA: (n,0) • minden interfész otthoni linkhez csatlakozik • ez a forgatókönyv hasonló a multihomed rögzített csomópontok esetéhez • Képességek: • Megbízhatóság: • egyik otthoni linkről való lecsatlakozáskor az MN képes CoA-t kötni az éppen nem használt HoA-jához • Terhelés-kiegyenlítés/folyamok megosztása • mechanizmus szükséges ahhoz, hogy az MN kiválaszthassa melyik HoA-t használja egy folyam inicializálásához és ahhoz is, hogy a CN tudjon választani az MN HoA-i közül • folyamok interfészek közti megosztása szintén lehetséges, de csak az MN felől indulók esetében Mobil Internet előadás BME-HIT

NEMO Multihoming – Terminológia • multihomed MNN: működéséhez több cím közül választhat • több prefix (multi-prefixed): több prefix kerül hirdetésre a hoszt linkjén/linkjein • több interfész (multi interfaced): a hoszt egy vagy több linken több interfészt is használhat • multihomed MR: működéséhez több cím közül választhat • több prefix (multi-prefixed): az MR egress interfésze által használt linken/linkeken több prefix kerül hirdetésre • több interfész (multi interfaced): az MR egy vagy több linken több egress interfészt is használhat • multihomed NEMO: mozgó hálózatok „többotthonúságáról” akkor beszélünk, ha • az MR multihomed • több single homed MR működik a NEMO-ban • a NEMO több HA-hoz csatlakozhat • a NEMO-ban több globális prefix érhető el Mobil Internet előadás BME-HIT

NEMO Multihoming – Lehetséges konfigurációk 1. • egyetlen MR, egyetlen HA, egyetlen MNP (1,1,1): • az MR-nek több egress interfésszel kell rendelkeznie, vagy • az idegen linknek több prefixet kell hirdetnie Mobil Internet előadás BME-HIT

NEMO Multihoming – Lehetséges konfigurációk 2. • egyetlen MR, egyetlen HA, több MNP (1,1,n): • az MR-nek multihomed-nak kell lennie • a több MNP miatt az MNN-ek alapból multihomed tulajdonságokkal rendelkeznek! Mobil Internet előadás BME-HIT

NEMO Multihoming – Lehetséges konfigurációk 3. • egyetlen MR, több HA, egyetlen MNP (1,n,1): • az MR több HA-hoz is regisztrálhat: a NEMO multihomed! • az MR lehet single- vagy multihomed is Mobil Internet előadás BME-HIT

NEMO Multihoming – Lehetséges konfigurációk 4. • egyetlen MR, több HA, több MNP (1,n,n): • az előző konfigurációhoz hasonló, de a NEMO több MNP-vel rendelkezik Mobil Internet előadás BME-HIT

NEMO Multihoming – Lehetséges konfigurációk 5. • több MR, egyetlen HA, egyetlen MNP (n,1,1): • egyetlen HA-hoz tartozó több (single- vagy multihomed) MR, egyetlen MNP-t kezel Mobil Internet előadás BME-HIT

NEMO Multihoming – Lehetséges konfigurációk 6. • több MR, egyetlen HA, több MNP (n,1,n): • több MNP! Mobil Internet előadás BME-HIT

NEMO Multihoming – Lehetséges konfigurációk 7. • több MR, több HA, egyetlen MNP (n,n,1): Mobil Internet előadás BME-HIT

NEMO Multihoming – Lehetséges konfigurációk 8. • több MR, több HA, több MNP (n,n,n): Mobil Internet előadás BME-HIT

Multiple CoAs Registration – Bevezetés • Cél: az egyetlen otthoni címhez ne csak egyetlen elsődleges ideiglenes címet lehessen hozzákötni, hanem többet is • Ennek érdekében a normál MIPv6 és NEMO protokolloknál megismert mechanizmusokhoz képest annyi változás történik, hogy minden egyes kötéshez egy azonosító szám is rendelődik • A kötések megkülönböztetése ezen azonosító alapján történik Mobil Internet előadás BME-HIT

MCoA – Általános működés I. • A kötések megkülönböztetésére a Binding Unique Identification-nek (BID) nevezett szám szolgál • BID tartozhat interfészhez vagy ideiglenes címhez. • Erről az azonosítóról az MN a BU üzenetben értesíti a HA-t és a CN-eket, akik a BID-eket feljegyzik a Binding Cache-ükben • Az otthoni cím magát az MN-t azonosítja, míg a BID az ugyanazon MN által regisztrált egyes kötéseket különbözteti meg • Az ideiglenes IPv6-os címek megszerzése után az MN-ek legenerálják a CoA-khoz tartozó BID-eket, majd azokat eltárolják a Binding Update List-jükben • A mobil csomópontok BU üzenet/üzenetek segítségével regisztrálják a CoA-kat a HA-nál és a CN-eknél • A CoA-khoz tartozó BID-eket a Binding Unique Identifier al-opcióban helyezik el • Az MN-nek ugyanazokat a BID-eket küldik a HA-iknak és CN-jeiknek Mobil Internet előadás BME-HIT

MCoA – Általános működés II. • Az MN regisztrálhatja a CoA-kat külön-külön (ekkor annyi BU üzenetet kell küldenie, ahány CoA-e van) • Az MN regisztrálhatja valamennyi CoA-ját akár egyszerre is egyetlen BU üzenetben („bulk registration”) • ez a fajta regisztráció csak a HA irányában lehetséges, a CN-ek felé külön-külön BU üzenetek küldésére van szükség • Ha egy MN-nek megváltozik az egyik CoA-ja, akkor egy BU üzenetet küld a HA-nak és minden kommunikációs partnerének, akik a BID alapján megkeresik a bejegyzést a Binding Cache- ükben és frissítik azt • Egy MN kötéseit egymástól függetlenül is karbantarthatja • Amennyiben az MN normál MN-ként akar működni (azaz nem „MCoA-képesként”), akkor egyszerűen egy olyan BU üzenetet küld, amely nem tartalmazza a BID al-opciót • Ebben az esetben egyetlen kötés jön létre, és ha szükséges, akkor minden olyan már létező kötés törlődhet, amelyhez BID tartozik Mobil Internet előadás BME-HIT

MCoA – Általános működés III. • Ha egy MN-nek több interfésze van, akkor előfordulhat olyan helyzet, hogy az egyik interfésze újra az otthoni hálózathoz csatlakozik, a többivel azonban még idegen hálózathoz kapcsolódik • ilyenkor, ha a MN haza akar térni, törölnie kell a kötéseit • ezt egy olyan BU üzenettel tudja elérni, amelyben a kötés élettartamát nullára állítja • Előfordulhat azonban az is, hogy az MN nem akar hazatérni annak ellenére, hogy az egyik interfésze az otthoni hálózatához csatlakozik • ekkor egyszerűen az MN-nek csak le kell tiltania azt az interfészét, amelyik az otthoni hálózathoz csatlakozik, majd egy BU üzenettel törölnie kell ehhez az interfészhez tartozó kötéseket a HA-nál és a CN-eknél Mobil Internet előadás BME-HIT

MCoA – BID al-opció • A Binding Unique Identifier al-opció az MCoA használatakor a • BindingUpdate • Binding Acknowledgment • Binding Refresh Request • Care-ofTest Init • Care-of Test üzenetekbe kerül bele. • Mezők: • Type: TBD • Length: 4, ha C nincs beállítva, más esetben 20 • BID: 16 bites unsigned int (a „0” érték foglalt) • Status: hibakódok szállítása • Care-of Address (C) flag: HA-hoz történő BU küldésekor, ha „bulk registration” van • Overwrite (O) flag: utasítja a HA-t minden eddigi binding felülírására az aktuális BU tartalmával • Home Binding (H) flag: jelzi, hogy az MN az otthoni linken van-e • Reserved: 5 bit (jelenleg „0”-val feltöltve) • Care-of Address: a BID-hez tartozó CoA („C” jelzőbitnek bekapcsolva kell lennie) Mobil Internet előadás BME-HIT

MCoA – MN működése I. • Amikor az MN kötéseket akar regisztrálni egy CN-nél, akkor a Return Routability (lásd a képen) eljárást is végre kell hajtania • minden egyes CoA-hoz küldenie kell egy CoTI üzenetet, de a HoTI üzenetet csak egyszer kell elküldenie! • Minden egyes CoTI üzenetben szerepelnie kell a BID al-opciónak. • A visszakapott CoT üzenetnek is tartalmaznia kell a BID al-opciót • amennyiben nem tartalmazza, az azt jelenti, hogy az adott CN nem támogatja a MCoA-t • az MN-nek ebben az esetben egy normál BU üzenetet kell küldenie • Abban az esetben, ha a CN támogatja az MCoA protokollt és a CN elfogadta a CoTI üzenetet, akkor az MN küldheti a BU üzenetet a BID al-opcióval. Mobil Internet előadás BME-HIT

MCoA – MN működése II. • BU üzenet küldésekor az MN eldöntheti, hogy csak egyetlen CoA-t akar-e regisztrálni vagy többet • ha ez utóbbi eset mellett dönt, akkor köteles a CoA-kat BID-del megkülönböztetni • Otthoni regisztráció esetén az MN alkalmazhat „bulk registration”-t is • ez hasznos, hiszen az MN-nek ebben az esetben nem kell annyi vezérlő üzenetet küldenie • A MN természetesen töröltetni is tudja a kötéseit. Egyszerre törölteti az összeset abban az esetben, ha nem ad BID al-opciót a BU üzenetben, és a kötés élettartamát nullára állítja, vagy egyszerűen az otthoni címét adja meg a BU üzenet forrás cím mezőjében. • Lehetőség van azonban arra is, hogy csak egy kötést töröljön, ekkor bele kell tennie a kötéshez vonatkozó információval ellátott BID al-opciót a BU üzenetbe Mobil Internet előadás BME-HIT

MCoA – MN működése III. • A CoT üzenethez hasonlóan a BU üzenetre válaszként küldött BA üzenetnek is tartalmaznia kell a BID al-opciót • Ennek hiánya ebben az esetben is arra utal, hogy a BA üzenet küldője nem támogatja az MCoA protokollt • Ha az MN egy olyan Binding Refresh kérést kap, amelyben van BID al-opció, akkor a válaszként küldött BU üzenetben köteles elhelyezni a BID al-opciót Mobil Internet előadás BME-HIT

MCoA – HA és CN működése • Egy CN és természetesen egy HA is rendelkezhet többszörös kötéssel ugyanazon MN felé, és bármelyik kötést használhatják az MN-nel való kommunikációhoz • Ha egy CN vagy HA a Binding Cache-ében keresi egy MN-nek a címét, akkor a kereséshez a kulcs az MN otthoni címe és a BID kell legyen, ha a CN vagy a HA ismeri BID-et • Ha a kapott BU üzenetben nincs BID al-opció, de a CN vagy HA már korábbról rendelkezik több kötéssel ugyanahhoz az otthoni címhez, akkor frissítik az összes létező kötést a kapott kötéssel • Ennek eredményeként csak egy kötésük lesz az adott MN felé. Ellenkező esetben (a BU tartalmaz BID al-opciót) a BU üzenetet kapó csomópontnak a BID al-opciót fel kell dolgoznia. Mindkét esetben a BU üzenet feldolgozása után nyugtázni kell azt egy BA üzenettel, amelynek tartalmaznia kell a BID al-opciót abban az esetben, ha az a BU üzenetben is benne volt. • Ha a CN vagy a HA azt érzékeli, hogy egy regisztrált kötés hamarosan lejár, akkor egy Binding Referesh Request üzenettel kérheti a kötés frissítését. Azon kötéseknél, amelyeknél BID is tartozik a kötéshez, a BRR üzenetnek is tartalmaznia kell a BID al-opciót. 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. [] 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. [] T. Ernst, N. Montavont, R. Wakikawa, C. Ng, K. Kuladinithi: “Motivations and Scenarios for Using Multiple Interfaces and Global Addresses”, draft-ietf-monami6-multihoming-motivation-scenario-02.txt, July 2007. [] N. Montavont, R. Wakikawa, T. Ernst, C. Ng, . Kuladinithi: “Analysis of Multihoming in Mobile IPv6”, draft-ietf-monami6-mipv6-analysis-04.txt November 2007. [] R. Wakikawa, T. Ernst, K. Nagami, V. Devarapalli: “Multiple Care-of Addresses Registration”, draft-ietf-monami6-multiplecoa-04.txt, November 2007. [] H. Soliman, N. Montavont, N. Fikouras, K. Kuladinithi: “Flow Bindings in Mobile IPv6 and Nemo Basic Support”, draft-soliman-monami6-flow-binding-05.txt, November 2007. [] Kis Tóth László: „IPv6 alapú mobil technológiák vizsgálata európai kiterjedésű teszthálózatban”, BME-HIT diplomaterv, 2007. Mobil Internet előadás BME-HIT

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

BME Híradástechnikai Tanszék 2008/2009 tavasz