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

Az előadások a következő témára: "BME Híradástechnikai Tanszék 2008/2009 tavasz Mobil Internet 11. előadás – Multihoming IPv6 hálózatokban (MIPv6 és NEMO multihoming alapok) Bokor László."— Előadás másolata:

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

2 2009.03.25 Mobil Internet előadás BME-HIT 2 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)

3 2009.03.25 Mobil Internet előadás BME-HIT 3 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!

4 2009.03.25 Mobil Internet előadás BME-HIT 4 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

5 2009.03.25 Mobil Internet előadás BME-HIT 5 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

6 2009.03.25 Mobil Internet előadás BME-HIT 6 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

7 2009.03.25 Mobil Internet előadás BME-HIT 7 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

8 2009.03.25 Mobil Internet előadás BME-HIT 8 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)

9 2009.03.25 Mobil Internet előadás BME-HIT 9 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

10 2009.03.25 Mobil Internet előadás BME-HIT 10 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)

11 2009.03.25 Mobil Internet előadás BME-HIT 11 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!

12 2009.03.25 Mobil Internet előadás BME-HIT 12 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

13 2009.03.25 Mobil Internet előadás BME-HIT 13 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

14 2009.03.25 Mobil Internet előadás BME-HIT 14 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

15 2009.03.25 Mobil Internet előadás BME-HIT 15 Multihoming – Célok és előnyök az „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”

16 2009.03.25 Mobil Internet előadás BME-HIT 16 Multihoming – Célok és előnyök a „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

17 2009.03.25 Mobil Internet előadás BME-HIT 17 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)

18 2009.03.25 Mobil Internet előadás BME-HIT 18 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

19 2009.03.25 Mobil Internet előadás BME-HIT 19 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)

20 2009.03.25 Mobil Internet előadás BME-HIT 20 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

21 2009.03.25 Mobil Internet előadás BME-HIT 21 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

22 2009.03.25 Mobil Internet előadás BME-HIT 22 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)

23 2009.03.25 Mobil Internet előadás BME-HIT 23 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)

24 2009.03.25 Mobil Internet előadás BME-HIT 24 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

25 2009.03.25 Mobil Internet előadás BME-HIT 25 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

26 2009.03.25 Mobil Internet előadás BME-HIT 26 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

27 2009.03.25 Mobil Internet előadás BME-HIT 27 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!

28 2009.03.25 Mobil Internet előadás BME-HIT 28 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

29 2009.03.25 Mobil Internet előadás BME-HIT 29 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

30 2009.03.25 Mobil Internet előadás BME-HIT 30 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

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

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

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

34 2009.03.25 Mobil Internet előadás BME-HIT 34 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

35 2009.03.25 Mobil Internet előadás BME-HIT 35 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

36 2009.03.25 Mobil Internet előadás BME-HIT 36 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

37 2009.03.25 Mobil Internet előadás BME-HIT 37 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

38 2009.03.25 Mobil Internet előadás BME-HIT 38 MCoA – BID al-opció •A Binding Unique Identifier al-opció az MCoA használatakor a –Binding Update –Binding Acknowledgment –Binding Refresh Request –Care-of Test 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)

39 2009.03.25 Mobil Internet előadás BME-HIT 39 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.

40 2009.03.25 Mobil Internet előadás BME-HIT 40 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

41 2009.03.25 Mobil Internet előadás BME-HIT 41 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

42 2009.03.25 Mobil Internet előadás BME-HIT 42 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.

43 2009.03.25 Mobil Internet előadás BME-HIT 43 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.

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