Informatika | Hálózatok » Heterogén hálózatok együttműködése, Vertical Hannover mérés

Mérési útmutató a Mobil Hírközlés Laboratórium méréseihez LXXXIII. Mérés Heterogén hálózatok együttmőködése – Vertical Handover mérés Mérés helye: Híradéstechnikai Tanszék Mobil Távközlési és Informatikai Laboratórium (MC2L) I.B 113 Összeállította: Szálka Tamás Fülöp Péter Bakonyi Gábor Lendvai Károly PhD hallgató PhD hallgató okleveles mérnök mérnök hallgató Utolsó módosítás: 2007. február 28 1 1 Bevezetés A napjainkban érvényesülı fix-mobil konvergencia mellett egyre többféle hozzáférési technológia áll rendelkezésünkre (EDGE – Enhanced Data Rates for Global Evolution, GPRS – General Packet Radio System, WLAN – Wireless LAN) és ezek száma illetve lefedettsége folyamatosan bıvül (UMTS – Universal Mobile Telecommunication System, WiMAX, Wifi). A felhasználói eszközök, készülékek piacán is tapasztalhatóak a változások. Manapság egy jól felszerelt notebook vagy okostelefon többféle

vezeték nélküli interfészel rendelkezik, melyen keresztül kapcsolódhatnak a világhálóhoz. Jogosan merül fel az igény, hogy kihasználva az egyes access technológiák elınyeit, és figyelembe véve hátrányaikat mindig a számunkra legkedvezıbb kapcsolaton keresztül kommunikáljunk. Jelenleg a készülékek arra képesek, hogy egyik, vagy másik interfészükön kapcsolódjanak a világhálóhoz, de ha váltani szeretnénk közöttük, akkor ezt manuálisan kell megtennünk. Képzeljük el, hogy reggel a munkahelyünkre utazunk, és közben a laptopunkon email-t olvasunk. Tegyük fel, hogy éppen kétféle hálózat érhetı el, GSM és UMTS Az e-mailek letöltéséhez megfelelı az olcsó, keskenysávú GPRS kapcsolat, így ezt használjuk. A levelek elolvasása után videokonferenciát indítunk, amihez már szélessávú kapcsolat szükséges, így a vertical handover-képes laptopunk átvált a drágább UMTS hálózatra. Ahogy beérünk a munkahelyünkre, ott már

WLAN lefedettség is van, ami olcsó és szélessávú, ezért laptopunk lebontja a UMTS kapcsolatot, és WLAN-hoz csatlakozik, ezen folytatjuk a videokonferenciát. Mindeközben a hálózatváltásokból semmit sem vettünk észre, a használt alkalmazások folyamatosan futottak. A mérés célja hogy megismerje a hallgató a hozzáférési hálózatok közötti átjárhatóság problémáját, az IP címváltás során felmerülı nehézségeket, a seamless handover lehetséges megoldásait illetve egy tesztrendszer segítségével a piacon elérhetı technológiákat és a kutatásfejlesztés fázisában lévı rendszereket. 2 2 Felvetıdı problémák Hogy a fenti példa megvalósulhasson gyors, zökkenımentes vertical handover folyamat szükséges. Ehhez fontos a használt hálózati protokoll, és felhasználói program ismerete, egyes protokollok ugyanis nem tőrik a hálózatváltást, míg mások gond nélkül veszik. Ha például biztonságos kapcsolatot használunk, az

IP-cím (Internet Protocol) változása fennakadást okozhat a biztonságos kommunikációban. Más esetekben, például emailezés közben (POP3 (Post Office Protocol version 3) protokoll használatakor) semmi gond sincs. Meg kell tehát figyelni, hogy melyik alkalmazásnak milyen sávszélességbeli, szolgáltatásbeli igényei vannak, így dönthetünk, hogy melyik hálózatra kell váltani, illetve azt is szem elıtt kell tartani, hogy a futó alkalmazás lehetıvé teszi-e egyáltalán a hívásátadást. Az elérhetı hálózatok közötti döntéshez rengeteg információ szükséges, tehát méréseket kell végeznie a rendszernek, hogy melyik hálózat milyen sávszélességet vagy szolgáltatásokat biztosít. Fontos, hogy az adatok frissek és pontosak legyenek, de nem terhelhetjük sem a hálózatot, sem az eszközünket túl gyakori vagy hosszadalmas mérésekkel. Láthatjuk tehát, hogy különbözı hozzáférési hálózatok közötti hívásátadáskor rendkívül

körültekintınek kell lenünk, a döntéshez mélyrehatóan kell ismernünk az elérhetı hálózatokat, a futó alkalmazásokat, sıt, a számlázási idıszakokat, tarifákat is. 3 Handover csoportosítása A handover hozzáférési pontok közötti hívásátadást jelent, alapvetıen két fajtáját szokás megkülönböztetni, a horizontal handover-t (HH), és a vertical handover-t (VH). HH-rıl beszélünk akkor, amikor ugyanazon hálózat két, földrajzilag elkülönülı hozzáférési pontja között történik a váltás. Ez történik például akkor, amikor mobiltelefonnal barangolás közben egy cellából egy másikba lépünk. VH-rıl akkor beszélünk, amikor egy helyen egymás fölött párhuzamosn többfajta hozzáférési hálózat érhetı el, és ezek között történik a hívásátadás. Fizikailag nem, de hálózati szempontból ekkor is mozgunk. Tehát a késıbbiekben ha mobilitás fogalmát használjuk, akkor a heterogén hálózatok közötti átjárást

is beleértjük. 3 A handovert osztályozhatjuk aszerint is, hogy hol történik a hálózatok közötti döntés. Mobile Controlled Handover-rıl (MCHO) beszélünk akkor, amikor a hívásátadást a mobil terminál vezérli, a döntést a mobil terminál hozza. Hátránya, hogy mobil eszközünket bonyolult szoftverrel kell ellátni, elınye, hogy hálózatfüggetlen, nincs szükség támogatottságra a hálózat részérıl. A mérés során egy ilyen rendszert ismerhetnek meg a hallgatók Network Controlled Handover-rıl (NCHO) beszélünk, ha a döntést a hálózatnak egy erre a célra létrehozott ügynöke végzi, ekkor nem terheljük a mobil eszközt a döntéshozatallal. 4 Heterogén hálózatok közötti mobilitás A fentebb említettek alapján levonhatjuk a következtetést, miszerint a különbözı hozzáférési technológiák egyszerő átjárhatóságának egyik legnagyobb akadálya az Internet Protocol tervezési hiányossága. Az IP cím kettıs funkciót

lát el Egyedi azonosítóként szolgál, és helyzetinformációt hordoz. Mobilitás világában, és így a heterogén hálózatok közötti átváltásnál ez a két fogalom nem szerepelhet egy kalap alatt, hiszen ha mozgunk az egyedi azonosítónk nem tudja megmondani hol is vagyunk, ellenben ha helyzetinformációt tudunk nyújtani, nem lehet ez az egyedi azonosítónk. A mobilitással együttjáró IP címváltozás kezelésére különbözı OSI rétegekben fejlesztettek ki megoldást. A következı fejezetben a különbözı rétegekben kialakítható mobilitás támogatási stratégiákat követjük végig létezı, vagy fejlesztés alatt lévı példákkal. Azt követı részben pedig a teljes hálózat szemszögébıl vizsgáljuk, csoportosítjuk a megoldásokat. 4.1 Átjárhatóság megvalósítása Az OSI modellben az egyes rétegek elég lazán vannak definiálva, ebbıl adódóan felmerülhetnek problémák. Például léteznek szolgáltatások melyek több rétegben is

megvalósításra kerültek, míg mások pedig egyikben sem. Szolgáltatások, mint például a mobilitás is, nem tartoznak egyértelmően egyik réteghez sem, több helyen is megvalósíthatóak. 4 Amit biztosan tudunk hogy az átjárhatóságot megvalósító rendszereknek három alapvetı követelményt kellene kielégíteniük: - Átlátszó átvitel : a hálózatok közötti váltás ne okozzon nagy adatvesztést, a váltás ne tartson sokáig és a hosszú távú kapcsolat orientált protokollokat használó programok zavartalanul futhassanak tovább. - Lokáció menedzsment : a heterogén hálózatok között mozgó eszköznek mindvégig elérhetınek kell lennie egy statikus azonosító segítségével függetlenül attól, hogy helyileg éppen hol van. - Infrastruktúra mentesség : minél jobban a hálózat szélén van a mobilitás megvalósítva, annál kevesebb változtatásra van szükség a jelenlegi hálózatokban. 4.11 Adatkapcsolati réteg A fizikai

réteg feletti mobilitáskezelés csupán regionális megoldásként szerepelhet, egy adott alhálózaton belüli szabad mozgást valósíthatunk meg segítségével. Hozzáférési hálózatok közötti átjárásra önmagában teljesen alkalmatlan. Más, magasabb rétegbeli megoldással karöltve azonban gyors, és hatékony megoldások születhetnek, példaként láthatjuk a MIP (Mobile IP) és CIP (Cellular IP) együttmőködését. Ezeknek lehetıségeknek a hátránya hogy a globális megvalósítása nehézkes, hálózatban lévı node-ok nagy részét fel kell készíteni a protokollok kezelésére. 4.12 Hálózati réteg A hálózatokban egyre erısebb az IP dominanciája. A jövıbeni fejlıdés mindenképpen integrált NGN (Next Generation Networks) IP alapú csomagkapcsolt hálózatok irányába mutat. Másrészrıl a „homokóra alakú” protokoll stackmodell alapján az IP egyeduralkodó. Mindezek azt jelentik, hogy a hozzáférési technológiák sokasága

egységesen IP alapon mőködik és fog mőködni, ebbıl következıen az IP alapon megvalósított handover megoldásoknak nagy jelentısége lesz, tehát a legérdemesebb ebben a rétegben keresni a megoldást az átjárhatóság kérdésére. A vertical handover szempontjából itt a cél úgy megoldani a hálózatváltást és az ezzel járó IP címváltozást, hogy arról a felhasználó és az általa futtatott applikáció a lehetı legkevésbé értesüljön. Illetve ha értesül róla, az ne zavarja meg Magán az eszközön ezt a váltást elrejteni 5 csak belsı erıforrást igényel. Például egy szoftvermodul, vagy protokoll stack változtatás, amely a váltást kezelve a felhasználói alkalmazás felé állandó IP-címet, vagy állandó új réteget mutat (1. ábra) Nagyobb körültekintést igényel a távoli kommunikációs partner kezelése. Felmerülhet az ötlet, hogy a mobil eszközön futó megoldás funkcionális tükörképét alkalmazzuk. Ez nehezebben

megvalósítható, hiszen minden kiszolgáló szoftverét kell kiegészíteni, ugyanakkor nem oldja meg a kapcsolat azonosíthatóságát. A kapcsolat azonosítására azért van szükség, hogy a kiszolgáló tudja, hogy melyik csomag, melyik mobil eszköztıl, milyen céllal érkezett. A TCP/IP szokványos kapcsolatazonosítójának része az IP-cím. Ha tehát a handover miatt változik az IP-cím, a kiszolgáló nem tudhatja, hogy még mindig ugyanazzal a mobil eszközzel kommunikál. Erre jó példa a Host Identity Protocol, amit a késıbbiekben részletezünk HTTP, HTTPS, FTP, RTSP,. TCP virtuális IP vertical handover démon UDP IP adatkapcsolati réteg fizikai réteg érvényes IP 1 érvényes . IP 2 1. ábra: IP protokoll-stack lehetséges módosítása A képen jelölt virtuális IP cím az applikációk által látott cím, amelyen keresztül a távoli alkalmazásokkal kommunikálnak. Az érvényes IP címek a kliens valódi címei, amelyeket az egyes hozzáférési

hálózatokhoz való csatlakozáskor kap. A vertical handover démon kezeli az IP címeket és átfordításukat Másik lehetıség hogy egy állandó címmel rendelkezı harmadik entitást (nevezzük késıbbiekben szervernek) vonunk be a kommunikációba, amit vagy az otthoni hálózatunkba (pl. Mobile IP) vagy a teljes hálózat egy optimális pontjára helyezünk el. A mozgó készülék valamilyen formában mindig tudajta a harmadik entitással az aktuális elérhetıségét. Természetesen ennek a folyamatnak védetnek kell lennie, különben számtalan visszaélésre adna lehetıséget. Aki a mobil terminállal akar kapcsolatot létesíteni az a szervernek küld, aki továbbít a mobil utolsó ismert címére. Fordított kommunikáció szintén a szerveren keresztül zajlik A megoldásnak két alapvetı hátránya van: 6 - A csomagok adott esetben hatalmas utat tesznek meg, mivel oda-vissza is átmennek a szerveren. - Ha a szerverrel történik valami, akkor a mobil

állomás elérhetetlenné válik. Ez utóbbi megoldás esetén az alkalmazások egy virtuális IP címen keresztül – elrejtve ezzel a valódi interfészeket – akarnak kommunikálnak a távoli kommunikációs partnerrel. Azonban ahogy az elıbb említettük, a harmadik entitás segítségével tudjuk csak megoldani, hogy egy egységes címen keresztül folyamatosan elérhetı legyen a mobil állomás. Így jogosan merül fel a kérdés: hogyan irányítsuk el az adatokat a harmadik entitáshoz? Alapvetıen három lehetıség nyílik az IP hálózatokban a feladat elvégzésére, a tunneling, source routing és payload kiterjesztés, vagy egyszerősített tunneling. Tunneling A tunneling, vagy más néven IP encapsulation, lényege, hogy a szabványos IP csomagot becsomagolja egy újabb IP csomagba. Ezáltal az eredeti csomag elé kerül egy újabb IP fejléc, emiatt csak payload-ként értelmezik a hálózati csomópontok. Így a külsı fejléc segítségével eljuttathatjuk a

csomagot a klienstıl a szerverig, amely levágja a külsı IP csomagolást, és megkapja a belsı IP csomagot, amit változtatás nélkül továbbküldhet. Mindehhez arra van szükség, hogy a kliens minden interfészén keresztül kiépítsen egy alagutat a szerverhez és fordítva. Ez egy kliens-szerver regisztrációs protokoll segítségével megoldható. Kliens Alkalmazás Handover Kliens Handover Szerver Tunnel 2. ábra: Tunneling 7 Cél állomás A megoldás igencsak elegáns, már bejáratott és támogatott szoftverelemekre épül, azonban a vezetéknélküli környezetben oly szőkös sávszélesség miatt a csomagonkénti 20 oktettnyi IP csomagoló fejléc túl nagy overheadet jelent. Ezáltal egy weboldal letöltésénél, ahol sok kis csomagban töltıdik le az oldal, a csomagonkénti 20 bájt érezhetıen lelassíthatja az átvitelt. Source Routing A source routinggal elérhetjük, hogy a csomagunk teljesen az általunk elıre megválasztott útvonalon, és a

kívánt routereken, állomásokon keresztül érkezzen meg a célcímre, még akkor is, ha ez az útvonal teljesen eltér az optimálistól. Ekkor az útvonalkijelölés nem a default gateway ismeretei alapján történik. A módszer veszélye a funkcionalitásában rejlik, hiszen ha egy általunk megválasztott csomópont, melyen a csomagot át akarjuk küldeni, meghibásodik, a csomagunk elveszik. A source routing implementálása különbözı IPv4 és IPv6 felett. Az IPv4 datagram fejlécében definiálták az opciók mezıt, amelyben a forrás általi forgalomirányítást úgy definiálhatjuk, hogy az opciók mezıben megadunk egy fejlécet a és utána az állomások címét tartalmazó változó hosszúságú törzset. Ebben egymást követıen IP címeket kell megadnunk, kezdve a forrás IP-vel, majd a routerek, csomópontok IP címe, melyeken a csomagunkat keresztül akarjuk vezérelni, végül pedig a cél IP. Hátránya hogy a routerek többsége nem támogatja ezt a

lehetıséget, így ez csupán elvi lehetıség maradhat. IPv6-ban hasonlóan mőködik, elınye, hogy beépített lehetıség az IPv6ban, támogatott a routerek által, hátrány, hogy nagy overhead-et eredményez a kiterjesztett címeket nézve is. Payload kiterjesztés, vagy egyszerősített tunneling A legkisebb overhead-et jelentı megoldás az általunk kidolgozott technika, az IP payload felhasználása. Ugyan ennek a megoldásnak nincs szabványos implementációja, a kedvezı overhead-arány miatt mégis optimális lehet. A generált IP csomagot olyan plusz információkkal, és módosításokkal látjuk el, mely a csomagot a szerverhez juttatja, és ott információt nyújt a további feldolgozásához. 8 Az eredeti IP csomag két IP címet tartalmaz, a cél IP-t és a forrás IP-t. A rendszerben a kliens csomagjait ellátjuk egy harmadik IP címmel, és szükség esetén egy 2 bájtos kapcsolat azonosítóval is. Az eredeti célcímet a hasznos adat végéhez

csatoljuk, és az IP fejlécben szereplı célcímhez a handover szerver címét írjuk. Ezzel elérhetjük hogy érvényes címet kapunk, és az útvonalválasztás során a szerverhez irányítódik a csomag, a hozzászúrt célcím figyelembevétele nélkül. Majd a szerver egyszerően levágja a plusz terhet a csomagról, beilleszti azt a célcím helyére, a klienst azonosító, szerver interfészhez rendelt címet pedig a forráscím helyére és továbbküldi a tényleges célállomás felé. Visszaféle ugyanez történik fordítva Kliens Alkalmazás Handover Kliens IP Layer: Handover Szerver Cél állomás 3. ábra: Payload extension Vannak olyan megoldások amelyek ötvözik a „protokoll változtatás” és „harmadik entitás” startégiákat. Ilyen például a Mobil Ipv6, amelynél lehetıség van közvetlen küldésre is a HomeAgent-en keresztül lezajlott kezdı kapcsolatfelvétel után. A következı fejezetekben röviden bemutatunk néhány létezı

megoldást 4.121 Mobile IP - MIP Ezzel a technológiával más mérés és tárgy keretében már bizonyára találkozott a hallgató, ezért csak röviden írnánk róla: a mobil állomásnak (MN – Mobile Node) van egy „otthoni ügynöke” (HA – Home Agent). Ha a mobil állomás az otthoni linkjére csatlakozik, nem számít mobil állomásnak, IP címe az otthoni ügynök címe (HA – Home Address). Ha eltávozik onnan és egy másik linkre csatlakozik, keres magának egy „távoli ügynököt” (FA – Foreign 9 Agent), nála bejelentkezik, és megadja az otthoni ügynökének az IP címét. A távoli ügynök továbbítja a bejelentkezést az otthoni ügynök felé, majd az megerısítı üzenetet küld vissza az új címre (COA – Care of Address). Ezután ha valaki csomagot küld a mobil állomásnak, akkor azt az otthoni címére küldi. Ott az otthoni ügynök becsomagolja, elküldi a távoli ügynöknek, az kicsomagolja és átadja a mobil állomásnak. A

csomagolás miatt a kommunikációban résztvevı routerek ugyanúgy mőködnek, mint hagyományos kommunikáció kiszolgálásakor, a mobilitást kizárólag az otthoni ügynök, a távoli ügynök és a mobil állomás kezeli. A mobil állomás a csomagokat közvetlenül a címzettnek adja fel, tehát a mobil eszköztıl a célállomás felé történı adatátvitel opcionálisan, közönséges módon, az otthoni ügynök kihagyásával is történhet (Mobile IPv6 ban ez nem opcionalitás, hanem alapkövetelmény). Az így kialakuló kétirányú kommunikációt háromszögelésnek nevezik. A távoli ügynökre nincs is mindig szükség, DHCP (Dynamic Host Configuration Protocol) protokoll segítségével a mobil állomás egy új linkre csatlakozva magának is kérhet IP címet, majd azzal bejelentkezhet az otthoni ügynökének, és a csomagolást is elvégezheti. Így komolyabb ugyan az elvárás a mobil eszköztıl, de leegyszerősödik a rendszer. A hierarchikus kiegészítés

egy adott területen belüli mozgások elfedését használja fel a mobilitás kezelés hatékonyabbé tételéhez, illetve ezt az elvet kiterjesztheti a teljes hierarchikus topológiára. 4.122 Host Identity Protocol – HIP HIP külön választja az azonosítási és a helyzetinformáció funkciókat egymástól. Ezzel a „protocol stack változtatás” csoportba tartozik. Egy új azonosítót, Host Identity-t (HI) vezet be, ami egy nyilvános-titkos kulcspár nyilvános kriptografikus kulcsa. A kulcspár titkos része azonosítja a host-ot a hálózaton. A szeparálás azt is eredményezi, hogy biztonságos úton megoldható a mobilitás és a multihoming. Tehát a HIP-ben azonosítóként a publikus kulcs szolgál. Amennyiben a host birtokolja a titkos kulcsot, ez bizonyítja, hogy valóban birtokolja azt az azonosítót, melyet a nyilvános kulcs reprezentál. A HI-t egy 128bit hosszú Host Identity Tag (HIT) reprezentál, melyet a HI-ból képzünk hash-eléssel. Mivel a HIT

128 bit hosszú, így egybıl használható IPv6-os alkalmazásokhoz. 10 HIP alkalmazásakor a felsıbb rétegeket, ideértve az alkalmazásokat, nem látják többé az IP címet. Ehelyett HIT-et látják, mint címet A lokációs információ el van rejtve az új rétegben, a Host Identity rétegben. A felsıbb rétegekbıl érkezı csomagokban a cél cím helyett a HIT szerepel. Az átfordítás az új HI rétegben történik meg. A célcím átváltozik a leképzett IP címmé ugyanúgy, ahogy a forrás HIT átvált a forrás IP címre. Ez a leképzés a HIT és az IP között több módon történhet meg, például egy DNS jellegő szerver segítségével. A mobilitás a következıképpen valósul meg a HIP segítségével. A HIP esetében a lokációs információ és az azonosítás elkülönítésével a csomagok azonosítása és célba juttatása tisztán elkülönül egymástól. A host kap egy csomagot és a feladót a helyes kulcsról azonosítja, majd dekódolja a

csomagot. Tehát az azonosítás szempontjából a csomagban található IP címnek nincs jelentısége. A HIP mobil csomópont mozog a hálózatban, változtatja hozzáférésének pontját. Szükségszerően ezzel megváltozik az IP cím is, errıl tájékoztatni kell a kapcsolódó hosztokat egy readdress (REA) csomagban. Ez az információt az úgynevezett Forwarding Agent-nek (FA) is el lehet küldeni, ez hasonló a home-agent struktúrához. Ebben az esetben a mobil állomás új címe az FA-tól kérhetı le. A HIP megoldás nagy elınye hogy beépített a biztonság, viszont a kulcs azonosítás miatt nagy számítási kapacitást igényel. 4.13 Szállítási réteg Mobilitásról a szállítási rétegnek tudnia kell, mivel tradicionálisan ennek a rétegnek a feladata a torlódásvédelem. Ahhoz pedig, hogy a torlódásvédelem hatékony legyen, adatok kellenek a két végpont közötti útról. (A mobilitás akármelyik rétegben legyen megvalósítva, a

torlódásvédelemmel ellátott átviteli protokollokon mindenképpen változtatni kell) 4.131 mSCTP – mobile Stream Control Transmission Protocol Az SCTP protokollt arra tervezték, hogy TCP-t és esetleg még az UDP-t is leváltsa. Hasonlít a TCP-re, de jóval többre képes annál, mint például multistreaming és multihoming támogatása. Éppen a multihoming az az új tulajdonság, ami miatt az SCTP alkalmas lehet mobilitás kezelésére. 11 Egy host akkor „multihomed”, ha több hálózati rétegbeli címmel rendelkezik. Egy transzport protokoll pedig akkor támogatja a multi-homingot, ha egy transzport végponthoz több hálózati rétegbeli címet lehet hozzárendelni. A mobilitás esetében ez úgy van megvalósítva, hogy lehetıség nyílik arra, hogy a végpont megváltoztassa az IP címét miközben a transzport végpontvégpont kapcsolat nem szakad meg. Természetesen ennek dinamikusan kell megtörténnie Ezért született meg az ADDIP (Dynamic Address

Reconfiguration) kiegészítés az SCTP-hez, ami lehetıvé teszi, hogy hozzáadjunk, elvegyünk és megváltoztassunk IP címeket egy aktív kapcsolat alatt. Az így kiegészített SCTP-t hívják Mobile SCTP-nek (mSCTP) Soft handover a következıképpen zajlik le: a mobil állomás adott IP címmel felépíti a SCTP kapcsolatot egy másik állomással, majd úgy dönt, hogy átmegy egy másik hálózatba. Az új hálózatban új IP címet kap. Ezt az új IP címet a mobil hozzáfőzi a már meglévı asszociációhoz és errıl a kapcslatban lévı node-ot is értesíti. Ezek után a mobil az új IP címet jelöli meg elsıdleges IP címnek és a régi IP címet törli az asszociációból. Ha a kapcsolat felépítése fordítva történik, akkor szükség van valamiféle harmadik entitásra (DNS, vagy agent), aki tudja a mobil eszköz aktuális elérhetıségét. Az SCTP egyik hiányossága, hogy a csomagvesztést torlódásként értelmez, és visszavesz a sebességbıl. Azaz

vezetéknélküli környezetben gyakori csomagvesztés miatt az SCTP nagyon gyenge átvitelre képes csak. 4.14 Viszony réteg Hasonló elınyökkel rendelkezik mint a szállítási rétegbeli mobilitás, de a megvalósítása kevésbé bonyolult. Amennyiben a cím megváltozik, egyszerően létrehoz egy új transzport kapcsolatot, és a régit megszünteti. Nem sok megoldás létezik a témában, egyik közülük a Pennsylvania-i egyetemen kidolgozott DHARMA (Distributed Home Agent for Robust Mobile Access), mely a MIP megoldás és viszonyréteg elınyeit ötvözi. 4.15 Alkalmazási réteg Az itt mőködı megoldások lényege hogy egy konkrét használt alkalmazáson belül kezelıdik le a mobilitás. Legjellemzıbb példák erre a Session Initiation Protocol (SIP) protokollt használó multimédiás alkalmazások. 12 4.151 Session Initiation Protocol – SIP A SIP egy aplikációs rétegbeli protocol, amit arra használnak hogy multimédiás sessionöket hozzanak létre

unicast és multicast felhasználásával. A SIP entitásai a felhasználói ügynökök, a proxy szerverek és az átirányító szerverek. Egy felhasználó egy e-mail cím szerő azonosítóval rendelkezik. A SIP jó néhány metódust definiál: - INVITE : Meghív egy felhasználót, vagy felhasználókat egy session-be. Az üzenet törzse tárolja a session leírót, például az SDP-t (Session Description Protocol) felhasználva. A session leíró tartalmazza, hogy a felhasználó milyen címére küldjék a neki szánt streaming adatot, milyen audió, videó kodeket ismer, stb. - ACK: Visszaigazolás az INVITE kérésre. - BYE: Akkor küldik ezt a csomagot, amikor a hívást meg kívánják szakítani. - OPTIONS: Ezzel az üzenettel kérdezik le a szerver képességeit. - CANCEL: Megszakítja a folyamatban lévı kérést. - REGISTER: Regisztráció egy SIP szervernél. - REINVITE: Módosítja felépült kapcsolatát egy adott felhasználóval, például abban az

esetben ha megváltozott az IP címe. Minden egyes új SIP tranzakciónak van egy egyedi hívás azonosítója, ami azonosítja a session-t. Ha a session-t módosítani kell, mert például egy új médiát szeretnék hozzáfőzni, akkor ugyanazt a hívás azonosítót használjuk egy inicializáló kérésben. Ezzel azt jelezzük, hogy a létezı session-t szeretnénk módosítani. A SIP felhasználói ügynököknek két alapvetı funkciója van: várja a bejövı SIP üzeneteket és SIP üzeneteket küld abban az esetben ha valamilyen bejövı üzenetre választ kell adnia. A SIP proxy szerver SIP üzeneteket továbbít domain név alapján. Az átírányító szerver viszont a felhasználó címét adja vissza, ahelyett hogy továbbítaná a SIP üzenetet a felhasználó felé. Mindez lehetıvé teszi hogy skálázható rendszereket építhesünk Mind az átírányító, mind a proxy szerver képes felhasználói regisztrációkat fogadni, amiben a felhasználó aktuális címe

van megadva. A címet lehet lokálisan SIP szerveren tárolni, vagy pedig egy dedikált cím szerveren. Így lehetıvé válik a mobilitás támogatása 13 Kövessük végig egy SIP hívás lehetséges menetét. A hivó küld egy INVITE üzenetet, ami tartalmaz egy session leírást SDP-ben kifejezve. Az átirányító szerver az üzenetet megkapva konzultál egy cím szerverrel, hogy megtudja hova kell továbbítania a meghívást. Ez a válasz lehet egy újabb átirányító, egy proxy, vagy éppen már a hívott címe. A proxy szerver továbbítja az INVITE kérést a felhasználó felé, az átirányító szerver visszaadja a pontos címét a hívott félnek. Ha az INVITE kérés eléri a célját, akkor egy OK üzenetet kap vissza a kezdeményezı fél, amit még egy ACK üzenettel nyugtáz. Ahhoz hogy az IP mobilitás megvalósuljon, abból a feltételezésbıl indulunk ki, hogy a mobil állomásnak van egy saját otthoni hálózata, ahol van egy SIP szerver, ami minden

egyes alkalommal kap egy regisztrációs üzenetet a mobil állomástól, amikor az helyet változtat. Ez a megoldás hasonlít a home agent regisztrációhoz a MIP-nél, azonban fontos észrevenni, hogy itt nincs szükség arra, hogy a mobil állomásnak legyen egy fix IP címe az otthoni hálózatban. Ha a mobil állomás mozog egy session alatt, akkor egy REINVITE üzenetet kell küldenie a másik felhasználónak, akivel kommunikál. Ebben az üzenetben a hívás azonosító megegyezik az eredeti híváséval, az új címet pedig a kapcsolat mezıbe kell elhelyezni. Ebbıl tudja a másik fél, hogy ezentúl a mobil állomásnak szánt csomagokat erre az új címre kell küldeni. 5 Mobilitáskezelési algoritmusok, stratégiák a hálózatban A mobilitás megvalósításának fiatal történelmében már most sok-sok ismertebb és kevésbé ismert megoldás született, és elıreláthatólag születni is fog. Ahhoz hogy egységesen tudjuk kezelni és esetleg összehasonlítani,

modellezni a mobilitás menedzsment algoritmusokat, valamilyen szempont szerint érdemes csoportosítani. Attól függıen, hogy milyen stratégiát alkalmaznak az egyes megoldások, négy nagy csoportba sorolhatjuk be ıket. 1. Centralizált Ennél a struktúránál a mobil állomás mindig küld update üzeneteket egy központi management node-nak az aktuális elérhetıségérıl. Mivel ez a központi node mindig tudja a mobil állomás elérhetıségét, ezért képes továbbítani a mobilnak szóló csomagokat (Mobile IP), vagy éppen meg tudja mondani a mobil állomás elérhetıségét (SIP). 14 Ezek a rendszerek ilyen szempontból egyszerőek, de nagy hálózati jelzés overhead-et eredményeznek. 2. Hierarchikus A központi, globális management-el ellentétben itt lokális management node-okat alkalmazunk, amik egy jól definiált területen belül kezelik a mobil mozgásást (Hierarchical Mobile IP). Ugyanúgy jelen van egy központi management node is, azonban az

ötlet ott rejlik, hogy a helyzet frissitı információkat csak a központi node felé vezetı régi út, és az új út metszéséig küldjük, az itt lévı lokális management node-nak. A megoldás elınye, hogy nem terheljük az egész hálózatot, azonban bonyolultabb strutktúrát eredményez, mint az elızı. 3. Cellás típusú A mobilitás megoldására léteznek cellás megoldások. Ennek legismertebb típusa a Cellular IP (CIP), aminek alapötlete a GSM-bıl jön. A lényege, hogy jól definiált paging területeket hozunk létre, amik több cellát fognak össze. A cellák között átjárás nem okoz IP cím váltást, a handover ilyen esetben alacsonyabb rétegben, általában az adatkapcsolati rétegben valósul meg. 4. Tracking A tracking megoldások lényege, hogy a handover végrehajtásának eredményeképpen megkapott új IP címet közvetlenül a régi hozzáférési csomóponttal közli a mobil, és nem szól feljebb a hierachiában. Így a neki szóló

csomagokat az egyes access point-ok igyekeznek a mobil állomás után küldeni. Az azonban érzékelhetı, hogy ha a mobil sokszor vált hálózatot, akkor hatalmas kerülıutat tehetnek meg a csomagok. Ennek optimalizálása érdekében, a mobil node ’x’ lépés után frissíti a központi agent-et. Több kutatás foglalkozik azzal, hogy meghatározza adott hálózati struktúrához, handover gyakorisághoz és mobilhoz fordulása gyakorisághoz az optimális ’x’ értéket. Két alcsoportja létezik ezeknek a megoldásoknak, attól függıen hogy a visszaszólás a régi hozzáférési ponthoz hogyan történik meg. Wireless tracking-nek nevezzük, ha még a rádiós 15 interfészt, és wired tracking-nek, ha a hozzáférési pontok között levı hálózatot használja a mobil node. Az elıbbire ismert példa az LTRACK, az utóbbira a Handoff-Aware Wireless Access Internet Infrastructure (HAWAII). 6 Mérés során használt eszközök (software + hardware) 6.1 Vertical

handover megoldása és a tesztrendszer A tesztrendszerben a 4.12 fejezetben leírt hálózati rétegbeli megoldás került implementálásra az 1. ábrán felüntetett protokoll stack változtatással A kliens és szerver közötti kapcsolat megvalósítására a harmadik ábrán szemléletett egyszerősített tunneling szolgál. A 4 és az 5. ábra jól szemlélteti a csomagok útját a klienstıl a célállomásig és vissza Alkalmazás Alkalmazás Alkalmazás Szállítás (TCP, UDP) Szállítás (TCP, UDP) Szállítás (TCP, UDP) Hálózat (IP) Hálózat (IP) Címcsere/hozzáfûzés Hálózat (IP) Csomagirányítás Címcsere Csomagazonosítás Adat kapcs. Adat kapcs. Adatkapcsolat Adatkapcsolat Fizikai Fizikai Fizikai Fizikai Handover Szerver Távoli hoszt Mobil eszköz 4. ábra: A csomagok útja a klienstıl a távoli célállomásig Alkalmazás Alkalmazás Alkalmazás Szállítás (TCP, UDP) Szállítás (TCP, UDP) Szállítás (TCP, UDP) Hálózat

(IP) Hálózat (IP) Csomagazonosítás Hálózat (IP) Címcsere Címcsere/hozzáfûzés Adat kapcs. Adat kapcs. Adatkapcsolat Adatkapcsolat Fizikai Fizikai Fizikai Fizikai Handover Szerver Távoli hoszt Mobil eszköz 5. ábra: A csomagok útja a távoli célállomástól a kliensig 16 A kliensoldali funkcionalitást egy NDIS driver szolgáltatja, amelyrıl bıvebben a 6.22 részben lesz szó. A szerver oldalon a megoldást a 632-es részben leírt NTMF keretrendszer szolgáltatja. A tanszéki tesztrendszer felépítését, és az IP címek kiosztását az 6. ábra szemlélteti 152.66248184 152.66248109 6. ábra: A tesztrendszer felépítése Jelszókiosztás Laptop(ok): Windows XP - Nincs jelszó Szerver(ek): Unix: Bejelentkezés a grafikus környezetbe: user: vhuser pass: vhuser Bejelentkezés rootként: user: root pass: VHserver 17 6.2 Kliens 6.21 Hálózati beállítások A mobil kliens számítógépeken Windows XP operációs rendszer fut. Az

alkalmazások felé mutatott állandó IP cím (virtuális IP cím) megvalósításához szükségünk van egy virtuális hálózati kártyára, amin be tudjuk állítani a kliens virtuális, az Interneten is érvényes címét. A mérés során az OpenVPN projekt virtuális hálózati kártyáját (TAP adapter) használjuk, amely már elıre telepítve van mindkét mobil kliensen. A virtuális címek a következık: 152.66248109 (mobil kliens B) és 15266248182 (mobil kliens A) (ezeknek a címeknek egyezniük kell a szervernek a tanszéki hálózat felé nézı interfészére DHCP-n kiosztott IP címmel, lásd 6.32 fejezet) Alaphelyzetben a mobil klienseken két aktív hálózati kapcsolat van (egy vezetékes és egy vezeték nélküli), amelyek az elsı mérési feladat elvégzéséhez szükségesek. A virtuális adapter ekkor le van tiltva. Alaphelyzetbıl a VH környzezet beállítása: - a mobil kliens LAN kábelét a szerverek alatt található labor switch-bıl át kell rakni

a Linksys WLAN router-be, és a vezetékes hálózati interfészen be kell állítani a 192.1681(1)51-es címet (a laptopokra rá van írva, hogy milyen címet kell kapniuk!), a DNS és az alapértelmezett átjáró helyét üresen kell hagyni, - CSATLAKOZNI KELL a Linksys WLAN AP-hoz, majd a vezeték nélküli hálózati interfészen be kell állítani a 192.1681(1)52-es címet, a DNS és az alapértelmezett átjáró helyét üresen kell hagyni, - engedélyezni kell a TAP adaptert, - telepíteni kell a vertical handover drivert (Passthru driver, lásd 6.222-ben), és - a VH menedzsment alkalmazás segítségével el kell indítani a vertical handover szolgáltatást (lásd 6.23) Az alaphelyzet be/vissza-állítása: - be kell zárni a VH menedzsment alkalmazást, - le kell szedni a vertical handover driver-t (tetszıleges hálózati interfész Tulajdonság ablakánál ki kell választani a Passthru Driver-t és Uninstall) 18 - a kábelt a Linksys WLAN router-bıl

át kell rakni a szerverek alatt található labor switch-be, és a vezetékes hálózati interfészen vissza kell állítani a DHCP használatát, - vezeték nélküli hálózati interfészen vissza kell állítani a DHCP használatát, majd csatlakozni kell az „mcl” SSID-jő WLAN AP-hoz, - le kell tiltani a TAP adaptert. Az alaphelyzetben történı váltáshoz nem a 6.23-as fejezetben leírt vertical handover menedzsment alkalmazást használjuk, hanem két egyszerő scriptet: C:VHmeresactivate LAN.bat C:VHmeresactivate WLAN.bat Ezzekkel az egyes route-ok metrikáját lehet állítani, ami tulajdonképpen megfelel a „hard” handover fogalmának. 6.22 Vertical handover driver 6.221 Felépítés A 4. és 5 ábrán látható és a 412 fejezetben leírt mőködés megvalósítására Windows operációs rendszer alatt az adatkapcsolati rétegben elhelyezkedı NDIS (Network Driver Interface Specification) API nyújt lehetıséget. Az NDIS segítségével különbözı

feladatokat ellátó hálózati driverek készíthetık. A mérésen egy ún. NDIS intermediate drivert használunk, amely beépül a hálózati kártyák drivere és a hálózati protokollok (esetünkben a TCP/IP) közé (7. ábra) 19 7. ábra: Az NDIS intermediate driver elhelyezkedése a protokoll stack-ben A csomagok módosításához a drivernek különbözı adatokra van szüksége (például egy adott hálózati interfész Ethernet és IP címe stb.), melyeket egy felhasználói módban futó handover management program (lásd 6.23) ad át neki A mőködés a 8 ábrán figyelhetı meg, mely a 4. és az 5 ábrát foglalja össze Windows környezetben 20 8. ábra: A handover megvalósítása Windows operációs rendszer alatt 6.222 Telepítés A driver (C:VHmeresinstallpassthru.sys) telepítéséhez szükség van két darab információs fájlra (C:VHmeresinstall etsf.inf és C:VHmeresinstall etsf minf), melyek alapján az operációs rendszer beilleszti a driver-t a

protokoll stack-be. Ez a három fájl megtalálható a mobil klienseken. A telepítés menete a következı: - A Hálózati kapcsolatoknál kiválasztunk egy tetszıleges hálózati kártyát - Jobb klikk, Tulajdonságok - Telepítés - Szolgáltatás - Saját lemez - Megadjuk az egyik .inf fájl elérési útját (C:VHmeresinstall etsfinf és C:VHmeresinstall etsf m.inf) - Kiválasztjuk a telepítendı driver-t (Passthru driver) - Mivel a driver digitálisan nincs aláírva, figyelmeztetı üzenetek jelennek meg, melyeket figyelmen kívül kell hagyni 21 A telepítés után a hálózati kártya által használt elemek között megjelenik a Passthru Driver. Annak ellenére, hogy csak az egyik hálózati kártyán végeztük el a telepítést, a driver az összes interfészhez hozzákapcsolódik. 6.23 Vertical handover menedzsment alkalmazás 6.231 Indtítás Az alkalmazás indítása a C:VHmeresInstallVerticalHandover.exe vagy a desktop-on az ikon segítségével

történik. 6.232 Felépítés és beállítások A menedzser alkalmazás fı feladata, a driver felkonfigurálása és vezérlése. A program induláskor felveszi a kapcsolatot a driverrel, valamint lekérdezi az operációs rendszertıl az elérhetı hálózati interfészeket. Az interfészek paramétereinek az ismeretében a szükséges adatokat (IP cím, MAC cím, Interfész típusa, Virtuális adapter-e) leküldi a drivernek. 6.233 Funkciók ismertetése 192.1681(1)50 9. ábra: A menedzsment alkalmazás felhasználói felülete I 22 A GUI két tab-ból áll. A Manage Handover fülön a következık vannak: - Start/Stop Handover gomb: Ennek a gombnak a segítségével tudjuk, a szükséges beállítások elvégzése után a rendszert aktiválni. - Server IP Address mezı: Itt állíthatjuk be, a handover szerver IP címét. A helyes IP cím beírása után a Set IP gomb segítségével tudjuk leküldeni a beállítást a drivernek. Vigyázzunk, hogy a helyes címet írjuk

be, mivel ez létfontosságú a mőködéshez. - Adapters mezı: Itt találhatók meg az elérhetı hálózati adapterek. (Csak azok az interfészek jelennek meg a listában, melyeken ténylegesen képesek vagyunk forgalmazni. Azok az adapterek, amelyek inaktív állapotban vannak, azok nem látszanak, csakúgy, mint a loopback interfész és a virtuális adapter). - Adapter parameters / Adapter Statistics: A fent ismertetett Adapters mezıben kiválasztott interfész paraméterei, illetve forgalmi statisztikái láthatóak. - Select Active Adapter: Ebben a legördülı listában ugyanazok az adapterek szerepelnek, mint az Adapters mezıben. Itt választhatjuk ki azt, hogy melyik interfész legyen az aktív adapter - Active Adapter Statistics: Az aktív adapter forgalmi statisztikái. - Auto Handover Control checkbox: Ezzel a checkbox-val kapcsolhatjuk ki, illetve be az automatikus hálózatváltást. Ha a checkbox aktív, akkor vagy a beépített döntési függvény

alapján, vagy a Manage Connections tabon beállított döntési függvény alapján vált a program az interfészek között. Ha kikapcsolt állapotba helyezzük, akkor a rendszer figyelmen kívül fogja hagyni a hálózati paraméterek változásait. (Ha az éppen aktuális adapter inaktív állapotba kerül, akkor az problémákat okozhat) - Program Messages: 23 Itt láthatjuk a rendszerüzeneteket. 10. ábra: A menedzsment alkalmazás felhasználói felülete II 6.234 A mőködéshez szükséges beállítások, használat: A program induláskor (C:VHmeresInstallVerticalHandover.exe) automatikusan elvégzi a legtöbb beállítást. A mérés megkezdéséhez az alábbi beállításokat kell végrehajtani: - A handover server kliens felé mutató IP címének beállítása (Server IP Address, 192.1681(1)50) - Szükség esetén a döntési függvény módosítása - Aktív adapter kiválasztása (Select Active Adapter) - Handover elindítása (Start/Stop Handover)

Figyeljünk arra, hogy a handovert csak akkor tudjuk aktiválni, ha az összes fenti beállítást elvégeztük. 24 6.3 Szerver A korábban leírt szerver funkcionalitás megvalósítására az NTMF keretrendszert alkalmazzuk a PC-n futó unix operációs rendszeren. A leírását és a szerver konfigurálását a következı fejezet tartalmazza. 6.31 NTMF – Network Traffic Manipulation Framework Az NTMF egy protokolltesztelésre készült hálózati forgalom-manipuláló szoftver. Feladata, hogy man-in-the-middle módon a kommunikációba ékelve, az átviteli protokoll tesztelése céljából a kívánt módon módosítsa a felek közötti információáramlást. Ezzel a módszerrel bármilyen átmenı csomag módosítható, így mesterségesen elıállítható minden olyan helyzet, amelyben az adott protokollnak valahogy reagálnia kell a környezet változására. Az NTMF mőködését jól szemlélteti az alábbi ábra, amelyen látható, hogy a közbülsı csomóponton

levı szőrınek megfelelı forgalom áthalad az NTMF-en, miközben a szőrı negáltjának megfelelı csomagok a szokásos, operációs rendszer által biztosított routing alapján továbbítódnak. Az NTMF-en áthaladó forgalmat a betöltött plugin-nek megfelelıen módosítja az NTMF és továbbítja a kommunikációs partner felé. 11. ábra: Az NTMF és az operációs rendszer viszonya Az NTMF mőködése teljesen független a futtató operációs rendszertıl és annak csomagkezelı alrendszerétıl. Elhelyezkedését a forgalom útvonalán úgy lehet elképzelni, mint egy oszcilloszkópot, amelyet rákötöttünk az állomás hálózati interfészeinek drótjaira. Így minden, a hálózati interfészeken megjelenı kimenı és bejövı csomagot fizikai, bitszinten 25 feldolgozhat, függetlenül attól, amit az állomás operációs rendszere tenne a csomagokkal. Az NTMF ezzel együtt megoldja, hogy a valóban feldolgozott átmenı forgalmat az operációs rendszer már

ne kezelje, ahogy a fenti ábra mutatja. Az NTMF-et futtató állomásnak címzett csomagok azonban az NTMF mellett az operációs rendszerhez is eljutnak. Az NTMF úgynevezett szőrıket definiál, amelyekkel kiválogatja az átmenı forgalomból azokat a csomagokat, amelyeket módosítani fog. A szőrıszabálynak megfelelı csomagok felkerülnek az NTMF feldolgozási láncába, amely teljes csomagkezelı- és routing-eljárást is meg tud valósítani, nincs szükség az operációs rendszer funkcióira. A feldolgozási láncba a programozói interfészen keresztül be lehet illeszteni csomagkezelı plugin-eket, melyek azt az utasítás-sorozatot tartalmazzák, amelyet az áthaladó csomagra le kell futtatni. A feldolgozás során gyakorlatilag tetszıleges változtatást lehet végezni a csomagon, kezdve egy fejléc mezı átírásától a csomag eldobásáig vagy teljesen új csomag létrehozásáig. A plugin-eket egy C++ API segítségével kell megírni, részben a nyelv,

részben az NTMF által biztosított függvényekkel és eljárásokkal. A plugin, beillesztése után, a szőrıknek megfelelı csomagok mindegyikére lefut, de az NTMF biztosít többféle lehetıséget is a csomagok közötti állapotátmenetek és állapotgépek alkalmazására is (DFSM – Discrete Finite State Machine). Az NTMF testreszabhatóságát nemcsak a tetszıleges pluginok csatolása biztosítja, hanem lehetıség van saját routing modulok írására is. A routing modulban sokféle csomagirányítási algoritmus valósítható meg, szintén az említett C++ API segítségével. A tesztrendszerben nem használt az NTMF saját routing modulja, így az operációs rendszer routing tábláját vesszük igénybe. 6.32 Unix beállítások A vertical handover szerver beállításához a következıket kell elvégezni. Miután beléptünk a grafikus felületre a vhuser/vhuser login paraméterekkel, nyissunk terminál-ablakot, ahol a su paranccsal váltsunk adminisztrátori

módba. A jelszó „VHserver” A szerveren elméletben leírt funkcionalitást egy NTMF plugin biztosítja. A plugin feladata, hogy a kliens géptıl érkezı és az oda tartó csomagokat kezelje és továbbítsa. Ennek megfelelıen két ágon fut a plugin: klienstıl jövı, illetve kliens felé tartó csomagok esetén. A klienstıl érkezı csomagok esetén a plugin levágja a hozzáfőzött 4 bájtos kiegészítést a csomag végérıl. Ezután továbbítja a csomagot az eredeti célállomás felé A kliens felé tartó csomagok 26 esetén a plugin az aktív interfésznek megfelelı címmel egészíti ki a csomagot, majd továbbítja a kliens állomás felé. Annak érdekében, hogy az NTMF plugin valóban feldolgozhassa a csomagokat, a megfelelı capture filter beállítása mellett további beállításokat is el kell végezni. Ugyanis a szerverhez érkezı csomagok címzettje az IP fejléc mezıi alapján maga a szerver. Ezért a szerver IP stackje, akkor is megkapja a

csomagokat, ha a capture filter helyesen van beállítva. A szerver IP stackje nem tudja értelmezni a csomagokat, ezért minden csomagra visszautasító választ ad (például TCP kapcsolat esetében lezárja a kapcsolatot). Elkerülendı ezt a viselkedést, a szerver szabványos IP stack-je nem kaphatja meg a csomagokat, amit az iptables csomagszőrı alkalmazásával tudunk megvalósítani. Az iptables segítségével a capture filterben megjelölt csomagokat kell kiszőrni a következı struktúrájú utasításokkal: $> iptables -t filter -A INPUT -p tcp --dport 80 -j DROP A fenti utasítás a szerver 80-as TCP portjára érkezı csomagokat eldobja, így azok kizárólag az NTMF számára láthatóak a szerveren. A helyes mőködéshez a /home/vhuser/iptables.VHmeres szkript lefuttatása elég, a standard szabályokat automatikusan beállítja! /usr/local/src/ntmf-R20061205114600/ntfm/src/ipv4 handover server .cpp forráskód módosítása a szerver címei alapján HA

SZÜKSÉGES: A szerver eth0 interfészének DHCP-n kiosztott címét ellenırizni kell, VHserverA esetében általában a 152.66248184, a VHserverB esetében a 15266248109 cím érvényes Ellenırzése : $> ifconfig eth0 HA A CÍM NEM EGYEZIK AZ ÉRVÉNYESSEL, AKKOR KELL A KÖVETKEZİKET VÉGREHAJTANI, AMÚGY CSAK INFORMÁCIÓS JELLEGGEL ÉRDEMES VÉGIGMENNI RAJTA: A forráskód végén az extern void * plugin init() függvényben unsigned long server változóba a szerver eth0 interfészének (DHCP-vel) kiosztott címét kell beírni: unsigned long server=StringToLong("152.66248XXX",""); /usr/local/src/ntmf-R20061205114600/ntfm/src/main.cpp-ben módosítása: 27 a capture filter megfelelı A cél az, hogy a capture filter elkapjon minden olyan csomagot, amely a kliens felé halad vagy onnan érkezik. Mindkét esetben a szerver megfelelı interfészének címét kell beírni ide, a megfelelı portokkal együtt. A broadcast címeket érdemes

szintén beletenni a filter-be, hogy az ntmf ne foglalkozzon feleslegesen broadcastolt csomagokkal. VHserverA esetén: capture filters["eth0"] = "( ip and ( dst host 152.66248XXX ) and not dst host 152.66248255 and (icmp or port 80 or port 53 or port 21 or port 20 or port 1234 or port 18000) )"; capture filters["eth1"] = "( ip dst host 192.168150 and not dst host 192.1681255 and (icmp or port 80 or port 53 or port 21 or port 20 or port 1234 or port 18000) )"; VHserverB esetén: capture filters["eth0"] = "( ip and ( dst host 152.66248XXX ) and not dst host 152.66248255 and (icmp or port 80 or port 53 or port 21 or port 20 or port 1234 or port 18000) )"; capture filters["eth1"] = "( ip dst host 192.1681150 and not dst host 192.1681255 and (icmp or port 80 or port 53 or port 21 or port 20 or port 1234 or port 18000) )"; A XXX helyére a szerver aktuális, DHCP-vel kiosztott címét

kell beírni, ahogy az ipv4 handover server .cpp fájlban A forrásfájlok szerkesztése után fordítsuk le a make paranccsal a plugint. cd /usr/local/src/ntmf-R20061205114600/ntfm/src/ make ./ntmf Ezzel binárissal indíthatjuk az NTMF-et. Futás közben a szerveren minden csomagról történik kiírás, ami a következı képpen néz ki: Mobile VH Client (SRC: xxxxxxxx --> VH Server Address (Real DST: yyyyyyyy) VH Server Address (Mobile DST: zzzzzzzz <-- Correspondent Node (Real SRC: vvvvvvvv) Ahol a 28 xxxxxxxx = A mobil kliens éppen aktuális IP címe hexában a mobiltól a szerverhez érkezı csomagban az source IP mezıben. yyyyyyyy = A mobil kliens távoli kommunikációs partnerének az IP címe hexában a mobiltól a szerverhez érkezı csomag végén. zzzzzzzz = A mobil kliens aktuális IP címe hexában a szervertıl a mobil felé menı csomagban a destination IP mezıben. vvvvvvvv = A mobil kliens távoli kommunikációs partnerének az IP címe hexában a

távoli partnertıl szerverhez érkezı csomagban destination IP mezıben. 29 6.33 Beállítások röviden 1. Bejelentkezés adminisztrátorként 2. /usr/local/src/ntmf-R20061205114600/ntfm/src/ipv4 handover server cpp szervercím átírás (HA SZÜKSÉGES) 3. /usr/local/src/ntmf-R20061205114600/ntfm/src/maincpp capture filter beállítás (HA SZÜKSÉGES) 4. /usr/local/src/ntmf-R20061205114600/ntfm/src/ forrásfájljainak fordítása make paranccsal (HA SZÜKSÉGES) 5. /home/vhuser/iptablesvhmeres futtatása 6. cd /usr/local/src/ntmf-R20061205114600/ntfm/src/ ./ntmf bináris futtatása 30 7 Mérési feladatok 1. IP címváltozás vizsgálata Ellenırizze a LAN és WLAN kapcsolat egyidejő kiépítettségét a kliensen (a 6.21 pontban alaphelyzetnek nevezett állapotnak kell aktívnak lennie, ennek hiánya esetén az „alaphelyzet visszaállítása” részben leírt beállításokat hajtsa végre). A C:VHmeresactivate LAN.bat és C:VHmeresactivate WLAN.bat script

segítségével az elsıdlegesen használt hálózati interfészt váltsa át a. FTP fájl-letöltés közben (kapcsolat kezdeténél a LAN legyen aktív, ajánlott a kernel.org/pub/linux vagy az uhulinux.hu címet anonymous belépéssel választani, majd egy nagyobb fájl letöltését választani), b. HTTP-n weboldal használata közben (ajánlott a wwwyoutubecom oldalon egy videó lejátszása közben véghezvinni a váltást, és utána egy új videót választani), c. HTTP-n weboldalról fájl letöltése közben (ajánlott a wwwletoltescom oldalról egy nagyobb mérető fájlt választani és lementeni letöltésvezérlı nélkül), és írja le mit tapasztalt, magyarázza meg a protokoll sajátosságainak megfelelıen. A mobil kliensen elérhetı FlasGet letöltı program segítségével ismételje meg a 1.c feladatot. Foglalja össze tapasztalatait 2. VH tesztrendszer konfigurálása Telepítse fel a VH környezetet a kliens gépen (621) Konfigurálja be a szervert (6.33)

Indítsa el a VH menedzsment alkalmazást és konfigurálja be (6.23) Hajtson végre vertikális handovert a. FTP fájl-letöltés közben, b. HTTP-n weboldal használata közben, c. HTTP-n weboldalról fájl letöltése közben, és írja le most mit tapasztalt. A mobil kliensen elérhetı FlasGet letöltı program segítségével ismételje meg a 2.c feladatot. Foglalja össze milyen változást észlel 3. Döntési függvény vizsgálata A VH menedszment alkalmazásban az elsıdleges interfész a LAN kapcsolat, és a WLAN másodlagos. A VH menedzsment alkalmazáson az Auto Handover Control legyen aktív majd állítsa az aktív adapter a WLAN kapcsolat. Húzza ki a LAN kábelt. Kezdje el a(z) a. FTP fájletöltést, b. Video Stream fogadást*, várjon 5-6 másodpercig, amíg a sebesség beáll állandóra. Ezt követıen dugja vissza a LAN kábelt. Mit tapasztalt? Majd húzza ki a LAN kábelt Ebben az esetben mi történt a váltáskor? Magyarázza meg, hogy mi a különbség

a két féle váltás között, magyarázza meg a látottakat! 4. QoS paraméterek vizsgálata Video Stream* fogadása, a. VH driver használtával, vertikális handover végrehajtása során és, b. VH driver használatvál, vertikális handover végrehajtásával, hálózat leterhelésének szimulálásával* és, a kliensen futó Wireshark (Ethereal) program segítségével loggolja a RTP csomagokat a virtuláis TAP win32 adapteren, vizsgálja meg a QoS paramétereket és készítsen diagrammot (Ha UDP csomagokat jelenít meg a Wireshark RTP helyett, akkor egérrel jobb gomb egy tetszıleges csomagon, decode as és RTP-t kell választani. A diagramm rajzoltatása pedit a Statistics->RTP->Stream Analysis menüponttal elıugró ablakon lehetséges). Hasonlítsa össze a különbözı alpontokban kapott QoS értékeket! A b feladatban használt script segítségével*, határozza meg azt a sebességet (csomag/s) amikor a stream hiba nélkül dekódolható, illetve amikor

már egyáltalán nem dekódolható. A jegyzıkönyvbe PrintScreen segítségével szúrjon be képernyıképeket a diagramokról! 5. Állítsa vissza a mobil kliensen az alaphelyzetet!! 32 *(VideoLAN konfigurálása: Indítsa el a VideoLAN stream sugárzó alkalmazást a labor egyik szabad gépén, ehhez kérje a mérésvezetı segítségét! Fájl->Varázsló->Adatszórás hálózatnak->RTP unicast, céllállomásnak állítsa be a mobil kliens publikus IP címét, amit a szerver kezel, port marad a default 1234, aztán Finish. Csatlakozzon rá a mobil kliensen futó VideoLAN program segítségével, Fájl->Hálózati adatfolyam megnyitása, alapértelmezett beállítások). *(Hálózat leterhelésének szimulálása: a /home/vhuser/iptables.VHmeres szkript mellett található egy /home/vhuser/block network.VHmeres szkript, ami szimulálja leterhelt hálózatot úgy, hogy egy beépített csomag/sec-el engedi a LAN, illetve a WLAN kapcsolat felé a forgalmat. Ennek

elindításával a 4b feladatban kért környezet válik aktívvá, majd a /home/vhuser/iptables.VHmeres újboli futtatásával inaktívvá. A /home/vhuser/block network.VHmeres [LAN sebesség csomag/sec-ben] [WLAN sebesség csomag/sec-ben] paraméterezéssel is használható, ekkor megadható az átereszı képessége a közegnek, ami szükséges a 4-es pluszfeladathoz. Például a block network.VHmeres 200 100 a LAN esetében 200 csomagot enged át másodpercenként, a WLAN esetében 100-at. Ha paraméter nélkül hívja meg a block network.VHmeres-t, akkor az alapértelmezett értékek: 200/120.) 33 8 Ellenörzı kérdések 1. Milyen információkat kell ismernünk a hálózatról ahhoz, hogy hatékony és gyors vertical handovert hajthassunk végre? 2. Osztályozza a handovereket, mondjon rájuk példákat! 3. Miért nem alkalmas az IP protokoll a mobilitás kezelésére? 4. Sorolja fel az átjárhatóság három kívánatos alapfeltételét, és írja le pár

mondattal mit jelentenek! 5. Miért érdemes megvalósítani a vertical handovert a hálózati rétegben? 6. Milyen két stratégiát alkalmazhatunk az IP rétegben a mobilitás kezelésére? 7. Hogyan jutathatjuk el az IP csomagokat egy közbülsı állomáshoz? 8. Milyen hálózat rétegbeli megoldásokat ismer, nagyon röviden jellemezze ıket! 9. Milyen szállítási rétegbeli megoldást ismer, jellemezze! 10. Milyen aplikációs rétegbeli megldásokat ismer, röviden jellemezze ıket! 11. Egységesen személve milyen 4 nagy csoportra oszthatjuk a mobilitás menedzsment algoritmusokat? 34