Mérési útmutató a Mobil Hírközlés Laboratórium méréseihez. Heterogén hálózatok együttműködése Vertical Handover 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. november 20.

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.1.1 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.1.2 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

UDP

virtuális IP vertical handover démon

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.1.2.1 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.1.2.2 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.1.3 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.1.3.1 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.1.4 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.1.5 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.1.5.1 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.1.2 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.2.2. részben lesz szó. A szerver oldalon a megoldást a 6.3.2-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.66.248.184

152.66.248.109

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.2.1 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.66.248.109 (mobil kliens B) és 152.66.248.182 (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.3.2 fejezet; A DHCP címkiosztás változása miatt elképzelhető, hogy a szerver nem az itt leírt címet kapja a hálózattól. A TAP adapter mindig azt a címet kapja, amit a szerver kapott DHCP-n!). A TAP adapteren be kell állítani a megfelelő címet (152.66.248.XXX) a Windows hálózati beállításain keresztül (Vezérlőpult/Hálózati kapcsolatok/TAP adapter tulajdonságai/TCP-IP beállítások). 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 1. mérési feladat elvégzéséhez szükségesek. A virtuális adapter ekkor le van tiltva (Hálózati kapcsolatok ablak/TAP adapteren jobb klikk/Letiltás)! A további feladatokhoz szükséges a VH környezet beállítása az alaphelyzetből: -

a mobil kliens LAN kábelét a szerverek alatt található labor switch-ből át kell rakni a Linksys WLAN routerbe, és a vezetékes hálózati interfészen be kell állítani a 192.168.1.(1)51-es lokális 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 routerhez (vezetéknélküli hálózatok kezelőablakában kiválasztani a WLAN hálózatot + „Csatlakozás”), majd a vezeték nélküli hálózati interfészen be kell állítani a 192.168.1.(1)52-es címet (a Linksys WLAN router nem oszt címeket DHCP-n keresztül), a DNS és az alapértelmezett átjáró helyét üresen kell hagyni,

-

engedélyezni kell a TAP adaptert (Hálózati kapcsolatok ablak/TAP adapteren jobb klikk/Engedélyezés),

18

-

a TAP adapteren az IP cím mellett a következő beállítások szükségesek: alhálózati maszk = 255.255.255.0 alapértelmezett átjáró = DNS = 152.66.248.12 ; 152.66.249.12

-

telepíteni kell a vertical handover drivert (Passthru driver, lásd 6.2.2.2-ben)

-

a VH menedzsment alkalmazás segítségével el kell indítani a vertical handover szolgáltatást (lásd 6.2.3).

Az alaphelyzet visszaállítása, amely a mérés végén kötelező: -

be kell zárni a VH menedzsment alkalmazást,

-

le kell szedni a vertical handover drivert (Hálózati kapcsolatok ablakban tetszőleges hálózati interfész Tulajdonság ablakában ki kell választani a Passthru Driver-t és Uninstall)

-

a kábelt a Linksys WLAN router-ből átdugni 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

(Vezérlőpult/

Hálózati

kapcsolatok/

Vezetékes

hálózat

tulajdonságai/TCP-IP beállítások), -

vezeték nélküli hálózati interfészen vissza kell állítani a DHCP használatát (Vezérlőpult/ Hálózati kapcsolatok/ Vezetéknélküli hálózat tulajdonságai/TCP-IP beállítások), majd csatlakozni kell az „mcl” SSID-jű WLAN-hoz,

-

le kell tiltani a TAP adaptert (Hálózati kapcsolatok ablak/TAP adapteren jobb klikk/Letiltás).

A mérés során kétféle handovert használunk. Az alaphelyzetben (1. feladat) két élő hálózati kapcsolat közötti hard handovert hajtunk végre, vertical handover támogatás nélkül. A további feladatokban (2.-4.) segítségül hívjuk a tanszéken elkészített vertical handover tesztrendszert, amelyben a hálózatok közötti váltást soft handoverrel valósítjuk meg. Az alaphelyzetben történő váltáshoz két egyszerű DOS batch szkriptet használunk: C:\VHmeres\activate_LAN.bat C:\VHmeres\activate_WLAN.bat

19

A szkriptek tanulmányozásával kiderül, hogy egyszerű routing metrika beállítást végeznek. Vagyis a hálózati interfészek (vezetékes és vezetéknélküli) prioritását változtatják meg, az alacsonyabb metrika érték nagyobb prioritást jelent. A legkisebb metrikájú kapcsolatot használja az operációs rendszer a hálózati kommunikációhoz.

6.2.2 Vertical handover driver A vertical handover tesztrendszer használatához szükséges a mérő laptopon a VH driver telepítése. Ez a driver gondoskodik a soft handoverről. 6.2.2.1 Felépítés A 4. és 5. ábrán látható és a 4.1.2 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).

7. ábra: Az NDIS intermediate driver elhelyezkedése a protokoll stack-ben

20

A vertical handover tesztrendszer a csomagok módosításával segíti a soft handovert. Ehhez a VH 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ó vertical handover menedzsment alkalmazás (lásd 6.2.3) 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. Alkalmazások (pl. Firefox, Outlook)

A routing tábla az intranetes forgalmat a virtuális hálózati kártya felé irányítja

Routing tábla

Virtuális adapter M1

Vezérlőprogram

A driver-t egy felhasználói módban futó program vezérli

Protokollok (TCP/IP)

Virtuális adapter M2

Virtuális adapter M3

Handover driver Virtuális adapter P1

Virtuális adapter P2

Virtuális adapter P3

A driver a virtuális hálózati kártyáról az éppen használt interfészre irányítja a forgalmat

Virtuális hálózati kártya Kliens számítógép

Intranet

Internet Handover szerver

8. ábra: A handover megvalósítása Windows operációs rendszer alatt

6.2.2.2 Telepítés A VH driver (C:\VHmeres\install\passthru.sys) telepítéséhez szükség van két darab információs fájlra (C:\VHmeres\install\netsf.inf és C:\VHmeres\install\netsf_m.inf), 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

21

-

Saját lemez

-

Megadjuk az egyik .inf fájl elérési útját (C:\VHmeres\install\netsf.inf és C:\VHmeres\install\netsf_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

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.2.3 Vertical handover menedzsment alkalmazás A felhasználó ezzel a programmal tudja vezérelni, hogy melyik interfészt veszi igénybe a hálózati kommunikációhoz. 6.2.3.1 Indtítás Az alkalmazás indítása a C:\VHmeres\Install\VerticalHandover.exe vagy a desktop-on az ikon segítségével történik. 6.2.3.2 Felépítés és beállítások A menedzsment alkalmazás fő feladata a VH 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.2.3.3 Funkciók ismertetése

22

192.168.1.(1)50

9. ábra: A menedzsment alkalmazás felhasználói felülete I.

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:

23

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: Itt láthatjuk a rendszerüzeneteket.

10. ábra: A menedzsment alkalmazás felhasználói felülete II.

24

6.2.3.4 A működéshez szükséges beállítások, használat: A program induláskor (C:\VHmeres\Install\VerticalHandover.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.168.1.(1)50, a laptopra rá van írva a hozzá tartozó szerver cím)

-

(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.

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.3.1 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é.

25

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 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).

26

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.3.2 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 leírt funkcionalitást a szerveren 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 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!

27

/usr/local/src/ntmf-R20061205114600/ntmf/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.66.248.184, a VHserverB esetében a 152.66.248.109 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.66.248.XXX",".");

/usr/local/src/ntmf-R20061205114600/ntmf/src/main.cpp-ben a capture filter megfelelő

módosítása: 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.66.248.XXX ) and not dst host 152.66.248.255 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.168.1.50

and

not

dst

host

192.168.1.255 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.66.248.XXX ) and not dst host 152.66.248.255 and (icmp or port 80 or port 53 or port 21 or port 20 or port 1234 or port 18000) )";

28

capture_filters["eth1"]

=

"(

ip

dst

host

192.168.1.150

and

not

dst

host

192.168.1.255 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/ntmf/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 xxxxxxxx = A mobil kliens éppen aktuális IP címe hexában - a mobiltól a szerverhez érkező csomagban az source IP mezőben. Ezen az értéken figyelhető meg a handover, hiszen a mobil két interfésze közül az aktív címe kerül ide. 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. Erre a címre küldte a mobil az eredeti csomagot. zzzzzzzz = A mobil kliens aktuális IP címe hexában a szervertől a mobil felé menő csomagban az IP destination mezőben. Ezen az értéken is megfigyelhető a handover, amint a szerver érzékeli a váltás, az új címre küldi a csomagokat. vvvvvvvv = A mobil kliens távoli kommunikációs partnerének IP címe hexában - a távoli partnertől szerverhez érkező csomagban az IP destination mezőben. Ez a mobil publikus IP címe, amin az internet felől elérhető.

29

6.3.3 Beállítások röviden 1. Parancssorban bejelentkezés adminisztrátorként (root) $> su

Jelszó: VHserver 2. $> ifconfig eth0 A szervercím ellenőrzése: 152.66.248.XXX 3. $> cd /usr/local/src/ntmf-R20061205114600/ntmf/src/ Az NTMF futtató környezetének könyvtárába lépünk. (A parancs beírása közben a TAB billentyű használatával a rendszer segít kiegészíteni a félig beírt könyvtár nevét.) 4. $> mcedit ipv4_handover_server_.cpp A forráskód megnyitása mcedit editor segítégével. 5. A szervercím átírása (HA SZÜKSÉGES): 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 (2.

pontban ellenőrzött cím): unsigned long server=StringToLong("152.66.248.XXX",".");

Ha történt módosítás, akkor elmenteni a forráskódot és kilépni. 6. $> mcedit main.cpp A forráskód megnyitása mcedit editor segítégével. 7. A capture filter beállítása (HA SZÜKSÉGES): A forráskódban a capture_filters["eth0"] változóba a szerver eth0 interfészének (DHCP-vel) kiosztott címét kell beírni. (2. pontban ellenőrzött cím) Ha történt módosítás, akkor elmenteni a forráskódot és kilépni. 8. $> make A forrásfájlok lefordítása, ha módosították. 9. $> /home/vhuser/iptables.VHmeres Az iptables csomagszűrési szabályok beállítása. 10. $> ./ntmf Az NTMF keretrendszer futtatása. Ha „Segmentation fault” történik, újból kiadni ezt a parancsot.

30

7 Mérési feladatok 1. IP címváltozás vizsgálata. Ebben a feladatban a hard handovert vizsgáljuk, nem vesszük igénybe a vertical handover tesztrendszer szolgáltatásait. Ellenőrizze a LAN és WLAN kapcsolat egyidejű kiépítettségét a kliensen (a 6.2.1 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:\VHmeres\activate_LAN.bat és C:\VHmeres\activate_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/kernel/v2.6

vagy

az

uhulinux.hu

címet

anonymous

belépéssel választani, majd egy nagyobb fájl letöltését választani), hívja segítségül a kliens gépen megtalálható TotalCommander FTP kliensét b. HTTP-n weboldal használata közben (ajánlott a www.youtube.com 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 www.letoltes.com 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ő FlashGet letöltő program segítségével ismételje meg az 1.c feladatot. Foglalja össze a letöltés közben tapasztaltakat (megszakadás, megakadás, stb)!

2. VH tesztrendszer konfigurálása. Ebben a feladatban a vertical handover tesztrendszer segítségével a soft handovert vizsgáljuk. Telepítse fel a VH környezetet a kliens gépen (6.2.1). Konfigurálja be a szervert (6.3.3). Indítsa el a VH menedzsment alkalmazást és konfigurálja be (6.2.3). Hajtson végre vertikális handovert a VH menedzsment alkalmazás segítségével 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ő FlashGet letöltő program segítségével ismételje meg a 2.c feladatot. Foglalja össze milyen változást észlelt az 1. feladatban tapasztaltakhoz képest!

3. Ebben a feladatban az automatikus hálózatváltást vizsgáljuk, a beépített döntési függvény alapján. A VH menedszment alkalmazásba beépített döntési függvényben az elsődleges interfész a LAN kapcsolat, és a WLAN másodlagos, hiszen a LAN gyorsabb és megbízhatóbb kapcsolatnak számít. Ezért a LAN kapcsolatot fogja használni a rendszer, amikor elérhető. 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* (a megjegyzésben leírtak szerint), 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? A letöltés közben megint húzza ki a LAN kábelt. Ebben az esetben mi történt a váltáskor? Tapasztalatait magyarázza meg a döntési függvény alapján! Mi a különbség a két féle váltás között?

32

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** (a megjegyzésben leírtak szerint) és, a kliensen elindított Wireshark (Ethereal) program segítségével loggolja a RTP csomagokat a virtuláis TAP win32 adapteren (Capture/Options ablakban interfész = „TAP win32 adapter”, capture filter=udp). 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. Vizsgálja meg a QoS paramétereket és készítsen diagrammot a Statistics->RTP->Stream Analysis menüponttal előugró ablakon, a Graph gombbal! Hasonlítsa össze a különböző alpontokban kapott QoS értékeket! A diagram rajzolásánál érdemes a tengelyek skálázását kézzel beállítani, hogy jobban látszódjanak a csomagvesztések és az átvitel folytonossági hibái. A jegyzőkönyvbe PrintScreen segítségével szúrjon be képernyőképeket a diagramokról! A 4.b. feladatban használt hálózat-terhelő 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ó (például kép- és hangminőség alapján).

5. Állítsa vissza a mobil kliensen az alaphelyzetet!

Segítség a feladatokhoz: * 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! 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.

33

** Hálózat leterhelésének szimulálása: a /home/vhuser/block_network.VHmeres szkript szimulálja a leterhelt hálózatot úgy, hogy egy beépített csomag/sec-el engedi a LAN, illetve a WLAN kapcsolat felé a forgalmat. Így megadható, hogy hány stream-csomag jusson el a kliens gépre másodpercenként. Ennek elindításával a 4.b feladatban vizsgált hálózati terhelés válik aktívvá. Inaktiválni a /home/vhuser/iptables.VHmeres szkript újboli futtatásával lehet.

A /home/vhuser/block_network.VHmeres szkript paraméterezéssel is használható, ekkor megadható az áteresztő képesség. Például a „block_network.VHmeres 200 100” parancs 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.) A paraméterek behangolásával találhatóak meg a 4.b. feladatban szereplő dekódolhatósági határok.

34

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?

35