5. A hálózati réteg A hálózati réteg tervezési kérdései

5.

A hálózati réteg

A hálózati réteg feladata, hogy a csomagokat a forrástól egészen a célig eljuttassa. Eh­ hez esetleg több routeren is keresztül kell a csomagnak haladnia. Ez a feladat látható­ an elkülönül az adatkapcsolati réteg feladatától, amely ennél szerényebb: azaz keretek továbbítása egy vonal egyik végétől a másikig. Ezért a hálózati réteg a legalacsonyabb réteg, amely két végpont közti átvitellel foglalkozik. E célok elérése érdekében a hálózati rétegnek ismernie kell a kommunikációs alhá­ lózat (vagyis a routerek halmaza) topológiáját, és megfelelő útvonalakat kell találnia azon keresztül. Arra is ügyelnie kell, hogy úgy válassza ki a routereket, hogy elkerülje néhány kommunikációs vonal és router túlterhelését, míg mások tétlenül maradnak. Végül a hálózati rétegre hárul azon problémák megoldása is, melyek akkor merülnek fel, amikor a forrás és a cél különböző hálózatokban vannak. Ebben a fejezetben megtárgyaljuk mindezeket a kérdéseket, elsősorban az Internet és annak hálózati réteg protokollja, az IP példáján keresztül, és szót ejtünk a vezeték nélküli hálózatokról is.

5.1.

A hálózati réteg tervezési kérdései

A következő szakaszok bevezetnek néhány olyan kérdésbe, amelyekkel a hálózati ré­ teg tervezőjének meg kell birkóznia. Ezek közt találjuk a szállítási rétegnek nyújtott szolgálatot és az alhálózat belső tervezését.

5.1.1.

Tárol-és-továbbít típusú csomagkapcsolás

Mielőtt azonban rátérnénk a hálózati réteg részleteinek megtárgyalására, érdemes át­ tekintenünk azt a környezetet, amelyben a réteg protokolljai működnek. Ezt szemlél­ teti az 5.1. ábra. A rendszer legfőbb elemei a sötét ellipszisben található szolgáltatói berendezések (átviteli vonalakkal összekötött routerek), és az ellipszisen kívül ábrá­ zolt felhasználói berendezések. A Hl hoszt egy bérelt vonalon keresztül közvetlen összeköttetésben áll a szolgáltató A routerével. Ezzel szemben a H2 hoszt olyan LANhoz csatlakozik, melynek F routerét a felhasználó birtokolja és üzemelteti. Ez a router

385

A HÁLÓZATI RÉTEG

Szolgáltatói berendezések

F1 folyamat

Csomag

F2 folyamat

5.1. ábra. A hálózati réteg protokolljainak környezete is bérelt vonalon keresztül kapcsolódik a szolgáltatói berendezésekhez. Az F routert az ellipszisen kívül ábrázoltuk, mivel nem tartozik a szolgáltatóhoz, bár a felépítését, szoftvereit és protokolljait tekintve valószínűleg nem különbözik a szolgáltató routereitől. Vitatható ugyan, hogy az alhálózathoz tartozik-e vagy sem, de a fejezetünk szempontjából a felhasználói területen lévő routereket is az alhálózat részének tekint­ jük, hiszen ugyanazokat az algoritmusokat hajtják végre, mint a szolgáltató routerei (és minket most leginkább az algoritmusok érdekelnek). A berendezések működése a következő. A hosztok az elküldeni kívánt csomagokat a saját LAN-on vagy a szolgáltató felé vezető pont-pont kapcsolaton keresztül a legköze­ lebbi routerhez továbbítják. A router tárolja a csomagot, amíg az teljes egészében be nem érkezik, hogy ki lehessen számítani az ellenőrző összeget. Ezután a csomag mindig a soron következő routerhez kerül, míg el nem éri a címzett hosztot. Ezt hívják tárol-éstovábbít típusú csomagkapcsolásnak, amint azt az előző fejezetekben már láthattuk.

5.1.2.

A szállítási rétegnek nyújtott szolgálatok

A hálózati réteg a hálózati réteg/szállítási réteg interfészen nyújtja szolgálatait a szál­ lítási rétegnek. Fontos tudnunk, hogy milyen jellegűek ezek a szolgálatok. A hálózati réteg tervezésénél a következő vezérelveket tartották szem előtt: 1. A szolgálatoknak függetleneknek kell lenniük az alhálózat kialakításától. 2. A szállítási réteg elől el kell takarni a jelenlevő alhálózatok számát, típusát és to­ pológiáját. 3. A szállítási réteg rendelkezésére bocsátott hálózati címeknek egységes számozási rendszert kell alkotniuk, még LAN-ok és WAN-ok esetén is. Ezen célok figyelembevételével, a hálózati réteg tervezői nagy szabadsággal ren­ delkeznek a szállítási rétegnek nyújtandó szolgáltatások részletes specifikációinak el-

386

SZÁMÍTÓGÉP-HÁLÓZATOK

készítése során. Ám ez a szabadság gyakran indulatos csatározássá válik két szemben­ álló csoport közt. A vita középpontjában az áll, hogy vajon a hálózati réteg összeköt­ tetés alapú vagy összeköttetés nélküli szolgáltatást nyújtson-e. Az egyik tábor (amelyet az Internet közössége képvisel) véleménye az, hogy az al­ hálózat dolga csak a bitek ide-oda mozgatása és semmi más. Nézetük szerint (amelyet valódi, működő számítógép-hálózattal való 30 éves tapasztalat támaszt alá), az alhálózat eredendően megbízhatatlan, függetlenül annak tervezésétől. Ezért a hosztoknak a megbízhatatlanságot tényként kell elfogadniuk, és a hibavédelmet (vagyis a hibajelzést és -javítást) és a forgalomszabályozást maguknak kell elvégezniük. Ez a nézet gyorsan ahhoz a következtetéshez vezet, hogy a hálózati szolgálatnak összeköttetés nélkülinek kell lennie, a SEND PACKET és RECEIVE PACKET primitíveken kívül alig kell valami más. Hangsúlyozottan nincs szükség a csomagok sorrendi keze­ lésére és forgalomszabályozásra, mert ezt a hosztok amúgy is mindenképpen megte­ szik, és valószínűleg kevés nyereség származik abból, ha ezeket kétszer hajtjuk végre. Továbbá, minden csomagnak hordoznia kell a teljes célcímet, mivel mindegyik elkül­ dött csomag az előző csomagoktól függetlenül kerül továbbításra (ha egyáltalán voltak ilyenek). A másik tábor (amelyet a telefontársaságok képviselnek) véleménye az, hogy az alhálózatnak megbízható, összeköttetés alapú szolgálatot kell nyújtania. Állításuk sze­ rint a világméretű telefonhálózattal szerzett 100 éves sikeres gyakorlat jó alapot ad ehhez. Ebből a nézőpontból a szolgálatminőség a meghatározó tényező, márpedig ezt az alhálózatban kiépített összeköttetések nélkül nagyon nehéz elérni, különösen az olyan valós idejű forgalmak esetén, mint amilyen a hang vagy a mozgóképek továb­ bítása. A két tábort legjobban az Internet és az ATM példája szemlélteti. Az Internet öszszeköttetés nélküli, míg az ATM összeköttetés alapú hálózati réteg szolgálatot nyújt. Ugyanakkor érdemes megjegyezni, hogy az Internet is kezd lépést tartani az egyre fontosabbá váló szolgálatminőségi garanciákkal, pontosabban, kezd magára venni olyan tulajdonságokat is, amelyek eddig csak az összeköttetés alapú szolgálatokat jel­ lemezték, amint azt hamarosan látni fogjuk. Erre a fejlődésre utaltunk már a VLANokról szóló tanulmányunkban is a 4. fejezetben.

5.1.3.

Az összeköttetés nélküli szolgálat megvalósítása

Miután láttuk, hogy a hálózati réteg kétfajta szolgálatot tud a felhasználónak nyújtani, ideje megnéznünk, hogyan működik belül. A felkínált szolgáltat típusától függően kétfajta szerveződés lehetséges. Az összeköttetés nélküli szolgálat esetében az alháló­ zatba érkező csomagok egyenként és egymástól függetlenül kerülnek továbbításra; előzetes kapcsolat-felépítésre nincs szükség. Ebben az összefüggésben a csomagokat gyakran datagramoknak (datagrams, DG), az alhálózatot pedig datagram alhá­ lózatnak (datagram subnet) is nevezik, a távirat (telegram) kifejezés mintájára. Ha összeköttetés alapú szolgálatot használunk, a forrás és a cél router között előre ki kell építeni egy útvonalat, mielőtt egyetlen adatcsomagot is elküldenénk. Ezt a kapcsolatot virtuális áramkörnek (virtual circuit, VC) nevezzük a telefonhálózat fizikai áram-

387

v HÁLÓZATI RÉTEG

Csomag

Router

Szolgáltató berendezése

F2 folyamat

F1 folyamat

A táblázata Kezdetben Később C táblázata E táblázata A A A C A A B A B D B B B B C C C C C C C D D D D D B D B E E E E B E C F E F C F B F F Cél Kimeneti vonal

5.2. ábra. Forgalomirányítás datagram alhálózatban köreinek mintájára, az alhálózat neve pedig ebben az esetben virtuális áramkör alhálózat (virtual circuit subnet). Ebben a fejezetben a datagram, a következőben pedig a virtuális áramkör alhálózatokat vizsgáljuk. Nézzük meg tehát, hogy működik egy datagram alhálózat. Tegyük fel, hogy az 5.2. ábra FI folyamata egy hosszú üzenetet szeretne küldeni az F2 folyamat számára. FI átadja az üzenetet szállítási rétegének azzal az utasítással, hogy továbbítsa azt a H2 hoszt F2 folyamatának. A szállítási réteg kódja a Hl hoszton fut, tipikusan az operá­ ciós rendszeren belül. Ez elé tesz egy szállítási fejrészt az üzenet elejéhez és továb­ bítja azt a hálózati rétegnek, amelyik valószínűleg szintén egy eljárás az operációs rendszeren belül. Tegyük fel, hogy az üzenet négyszer olyan hosszú, mint a maximális csomagméret, tehát a hálózati rétegnek' négy csomagra kell bontania, és mindegyiket sorban az A routerhez továbbítania valamilyen kétpontos protokoll, pl. a PPP felhasználásával. Ezen a ponton lép be a képbe a szolgáltató. Az alhálózat minden routerének van egy belső táblázata, amely minden lehetséges cél esetére megadja, hogy merrefelé kell to­ vábbítani a csomagokat. A táblázat bejegyzései olyan kettősök, amelyek a címzett router azonosítóját és a címzetthez vezető kimeneti vonal azonosítóját tartalmazzák. A lektor megjegyzése: Valójában nem a hálózati, hanem a szállítási rétegben történik az üzenet csomagokra tördelése és a csomagok összerakása üzenetté.

388

SZÁMÍTÓGÉP-HÁLÓZATOK

Csak közvetlen kapcsolatban álló összeköttetéseket lehet használni. Az 5.2. ábrán pél­ dául az A routernek csak két kimeneti vonala van - egy a fi és egy a C felé - így min­ den bejövő csomagot a két router közül valamelyiknek kell továbbküldeni, még akkor is, ha a címzett egy ezektói különböző router. A kezdeti forgalomirányító táblázatát a képen a „kezdetben" oszlop mutatja. Négy csomag útját követhetjük végig az ábrán. Az A router a beérkezett 1., 2. és 3. csomagot rövid ideig tárolta (hogy kiszámít­ hassa ellenőrző összegüket), majd a táblázatának megfelelően továbbította a C-hez. Az 1. csomag az F-hez, majd az F-hez került, F-hez érve beágyazódott egy adatkap­ csolati keretbe, és a LAN-on keresztül eljutott //2-höz. A 2. és a 3. csomag ugyanezt az utat járta be. A 4. csomaggal azonban valami más történt. Az A-tól a B routerhez került, annak ellenére, hogy az F volt a címzett. Valami miatt az A úgy döntött, hogy a 4. csomagot más úton továbbítja, mint az első hármat. Értesülhetett például egy, az ACE út mentén lévő torlódásról, és módosíthatta a forgalomirányító táblázatát, amint azt az ábra „ké­ sőbb" oszlopa mutatja. Azt az algoritmust, mely a táblázatok karbantartását végzi és meghozza a forgalomirányítási döntéseket, forgalomirányító algoritmusnak (routing algorithm) nevezzük. Ezen algoritmusok képezik fejezetünk egyik legfontosabb tárgyát.

5.1.4.

Az összeköttetés alapú szolgálat megvalósítása

Az összeköttetés alapú szolgálathoz szükségünk van egy virtuális áramkör alhálózatra. Nézzük, hogyan is működik ez! A virtuális áramkörök alapötlete az, hogy elkerülik, hogy minden egyes csomag számára újra és újra útvonalat kelljen választani, szemben az 5.2. ábrán látottakkal. Ehelyett, már az összeköttetés felépítésekor kiválasztanak a forrás és a cél hoszt között egy utat, melyet a routerek az összeköttetés-kiépítés kere­ tében tárolnak a táblázataikban. Ezt az utat használják aztán a kapcsolat teljes forgal­ mának lebonyolítására, pontosan úgy, ahogy a telefonhálózat esetében is.2 Amikor az összeköttetés megszűnik, a virtuális áramkör is elbomlik. Az összeköttetés alapú szol­ gálat esetén minden csomag tartalmaz egy azonosítót, amely megmondja, hogy a csomag melyik virtuális áramkörhöz tartozik. Példaként tekintsük az 5.3. ábrán látható helyzetet. Itt a Hl hoszt kialakított egy összeköttetést //2-vel. Ezt jelzi a forgalomirányító táblázatok első bejegyzése. Az A router táblázatának első sora szerint, ha egy l-es azonosítót hordozó csomag érkezik a Hl felől, akkor azt a C router felé kell továbbítani l-es azonosítóval. Hasonlóképp, C első bejegyzése az F-hez továbbítja a csomagot, szintén l-es összeköttetés­ azonosítóval. Most nézzük meg, mi történik, ha H3 is szeretne összeköttetést létesíteni //2-vel. Összeköttetés-azonosítónak az 1-et választja (mivel ő kezdeményezi az összeköttetést és ez az egyetlen összeköttetése), és arra utasítja az alhálózatot, hogy hozza létre a A lektor megjegyzése: A telefonhálózatra való hivatkozás nem szerencsés, mivel ott a fi­ zikai áramkör, míg az összeköttetés alapú csomagkapcsolásnál logikai csatorna, virtuális áram­ kör alakul ki a két távoli felhasználó között és szolgál a teljes forgalom lebonyolítására.

389

A HÁLÓZATI RÉTEG

Szolgáltató berendezése

F1 folyamat F2 folyamat A táblázata Cl 1 C; 2

H1i 1 H3| 1

C táblázata A :1 E :1 A| 2 E i 2

E táblázata F |1 Ci 1 C; 2 F; 2

Bejövő Kimenő 5.3. ábra. Forgalomirányítás virtuális áramkör alhálózatban virtuális áramkört. Ez eredményezi a második sort a táblázatokban. Vegyük észre, hogy ez ütközéshez vezet, mert bár A könnyen meg tudja különböztetni a #7-bői és a //5-ból érkező, egyaránt l-es azonosítójú csomagokat, C már nem képes erre. Ezért A új összeköttetés-azonosítót rendel hozzá a második összeköttetés kimenő forgalmához. Az ilyen konfliktus helyzetek elkerüléséhez tehát az szükséges, hogy a routerek képe­ sek legyenek megváltoztatni az összeköttetés-azonosítókat a kimenő csomagokban. Egyes esetekben ezt a működést címkekapcsolásnak (label switching) is nevezik.

5.1.5.

A virtuális áramkör és a datagram alapú alhálózatok összehasonlítása

Mind a virtuális áramköröknek, mind a datagramoknak megvannak a maguk támoga­ tói és ellenzői. Mi most megkíséreljük mindkét oldal érveit összefoglalni. A főbb té­ mák megtalálhatók az 5.4. ábrán, bár a szőrszálhasogatók bizonyára az ábra minden részére tudnának ellenpéldát találni. Az alhálózaton belül sokfajta kompromisszum lehetséges a virtuális áramkörök és a datagramok közt. Az egyik kompromisszum a routerek memóriaterülete és a sáv­ szélesség közt áll fenn. Virtuális áramkörök esetén a csomagoknak csak áramkörszá­ mokat kell tartalmazniuk teljes célcímek helyett. Ha a csomagok általában elég rövi­ dek, a minden csomagban jelenlevő teljes célcím jelentős mértékű többletet jelent, és ez­ által sávszélesség veszhet el. A virtuális áramkörök használatáért fizetendő ár a routereken belüli táblázat helyigénye. A kommunikációs áramkörök és a router memóriájának egymáshoz viszonyított költségétől függően egyik vagy másik lehet olcsóbb. Egy másik kompromisszum az összeköttetés-felépítési és a címfeldolgozási idő közt kereshető. A virtuális áramkörök használata megkövetel egy összeköttetés-felépí-

390

SZÁMÍTÓGÉP-HÁLÓZATOK

Kérdés

DG alhálózatokban

VÁ alhálózatokban

Áramkör-felépítés

Nem szükséges

Megkövetelt

Címzés

Minden csomag tartalmazza a teljes forrás- és célcímet

Minden csomag egy rövid VÁ számot tartalmaz

Állapotinformáció

Az alhálózat nem tartalmaz állapotinformációkat

Minden VÁ táblázat helyet követel az alhálózatban

Forgalomirányítás

Minden csomagot függetlenül irányítanak

Az útvonalat akkor választják ki, amikor a VÁ felépül; minden csomag ezt az útvonalat követi

A forgalomirányí­ tók meghibásodá­ sainak hatása

Semmi, eltekintve az össze­ omlás során elveszett csoma­ goktól

Minden VÁ megszakad, amely a csődöt mondott for­ galomirányítón keresztülha­ ladt

Szolgálatminőség

Bonyolult

Könnyű, ha elég erőforrást lehet előre lefoglalni mindegyik VÁ számára

Torlódásvédelem

Bonyolult

Könnyű, ha elég erőforrást lehet előre lefoglalni mindegyik VÁ számára

5.4. ábra. A datagram és a virtuális áramkör alapú alhálózatok összehasonlítása

tési fázist, amely időbe kerül, és erőforrásokat igényel. A virtuális áramkör alapú alhá­ lózatban azonban könnyű eldönteni, mi legyen a csomagokkal: a router az áramkör számát indexként használja a táblázatokhoz, a kimenő vonal meghatározásához. Egy datagram alapú alhálózatban bonyolultabb eljárás szükséges ahhoz, hogy eldöntsük, merre menjen a csomag. További kérdés, hogy mennyi helyet foglalnak el a táblázatok a routerek memóriá­ jában. Egy datagram alhálózatban minden lehetséges címzett számára fenn kell tartani egy bejegyzést, míg a virtuális áramkör alhálózatban csak az egyes áramkörök számá­ ra kell egy-egy bejegyzés. Megjegyzendő ugyanakkor, hogy a virtuális áramkörök ezen előnye sem ennyire egyértelmű, mert a kapcsolatot felépítő csomagokat is irányí­ tani kell, ezek pedig ugyanúgy tartalmazzák a célcsomagok címét, mint a datagramok. A virtuális áramkörök a szolgálatminőségi garanciák és az alhálózaton belüli torló­ dásvédelem területén rendelkeznek némi előnnyel, mert az erőforrásokat (puffereket, sávszélességet, processzoridőt) előre, a kapcsolat felépítésekor le tudják foglalni. Mire a csomagok megérkeznek, a szükséges sávszélesség és routerkapacitás már rendelke­ zésre fog állni. Datagram alhálózatokban a torlódások elkerülése bonyolultabb kérdés. A tranzakciófeldolgozó rendszereknél (mint például, amikor az üzletek hitelkár­ tyákkal történt vásárlásokat ellenőriznek) egy virtuális áramkör felállításához és kitör­ léséhez szükséges többlet könnyen felülmúlhatja az áramkör valódi használatát. Ha a forgalom nagy része várhatóan ilyen típusú lesz, az alhálózaton belüli kapcsolt virtuá­ lis áramkörök használatának nincs sok értelme. Másfelől viszont, az állandó virtuális

A HÁLÓZATI RÉTEG

391

áramkörök, amelyeket kézzel hoznak létre, és hónapokig vagy évekig fennállnak, itt hasznosak lehetnek. A virtuális áramkörök azonban sebezhetők is. Ha egy router összeomlik, és elveszti memóriája tartalmát, még ha egy másodperccel később újra is indul, az összes rajta keresztülhaladó virtuális áramkört meg kell szakítani. Ezzel ellentétben, ha egy datagram alapú router megy tönkre, csak azok a felhasználók szenvednek kárt, akiknek a csomagjai éppen ebben a routerben álltak sorban, sőt talán nem is mindegyikük, attól függően, hogy nyugtázták-e már azokat. Egy kommunikációs vonal elvesztése vég­ zetes a rajta keresztülhaladó virtuális áramkörök számára, de könnyen ellensúlyozható datagramok használata esetén. A datagramok azt is lehetővé teszik a routereknek, hogy kiegyenlítsék az alhálózat terhelését, mivel az útvonalak egy hosszabb csomag­ sorozat közben is módosíthatók.

5.2.

Forgalomirányító algoritmusok

A hálózati réteg fő feladata, hogy a csomagokat a forrásgéptől a célgépig irányítsa. A legtöbb alhálózatban a csomagoknak ehhez több routeren kell keresztülhaladni, több átugrást kell megtenni. Az egyetlen figyelemre méltó kivétel az adatszóró hálózatok esete, de a forgalomirányítás itt is téma lehet, ha a forrás és a cél nem ugyanazon háló­ zaton van. Azok az algoritmusok, amelyek az útvonal meghatározását szolgálják, és azok az adatstruktúrák, amelyeket az algoritmusok használnak, a hálózati réteg terve­ zésének egyik legfontosabb területét alkotják. A forgalomirányító algoritmus (routing algorithm) a hálózati réteg szoftverének azon része, amely azért a döntésért felelős, hogy egy bejövő csomag melyik kimeneti vonalon kerüljön továbbításra. Ha az alhálózat belül datagramokat használ, ezt a dön­ tést újra meg újra meg kell hozni minden beérkező adatcsomagra, mivel a legjobb út­ vonal lehet, hogy változott a legutóbbi meghatározás óta. Ha az alhálózat belül virtuá­ lis áramköröket használ, a forgalomirányító döntéseket csak akkor hozzák meg, ha új virtuális áramkör épül fel. Ezután az adatcsomagok már csak az előzőleg kijelölt útvo­ nalat követik. Ezt az utóbbi esetet néha viszony-forgalomirányításnak (session rout­ ing) is nevezik, mivel az útvonal érvényben marad a teljes felhasználói viszony (mint pl. egy bejelentkezési viszony egy terminálról, vagy egy fájl-átvitel) alatt. Néha célszerű megkülönböztetnünk a forgalomirányítást, azaz a választandó útvo­ nalról való döntést, és a továbbítást, ami a csomag beérkezésekor történik. Képzeljük azt, hogy a router két folyamatot tartalmaz. Az egyik kezeli a beérkező csomagokat: mindegyik számára kikeres egy kimeneti vonalat a forgalomirányító táblázatokból. Ez a folyamat a továbbítás (forwarding). A másik folyamat a forgalomirányító tábláza­ tok feltöltéséért és karbantartásáért felelős - itt kerülnek be a képbe a forgalomirá­ nyító algoritmusok. Függetlenül attól, hogy az útvonalakat minden egyes csomagra egymástól függet­ lenül választják ki vagy csak új összeköttetés létrejöttekor, vannak bizonyos tulaj­ donságok, amelyek kívánatosak egy forgalomirányító algoritmus esetében. Ezek a kö­ vetkezők: helyesség, egyszerűség, robusztusság, stabilitás, igazságosság, optimalitás

392

SZÁMÍTÓGÉP-HÁLÓZATOK

•, I

\ «

A'

4

»

*

-i H

B'

5.5. ábra. Konfliktus az igazságosság és az optimalitás közt és hatékonyság. A helyesség és az egyszerűség magától értetődő, a robusztusság azonban elsőre talán kevésbé nyilvánvaló. Amikor egy nagyobb hálózatot üzembe helyeznek, elvárják, hogy az évekig rendszerszintű hibáktól mentesen működjön. Ez alatt az idő alatt mindenféle hardver- és szoftverhiba lesz. Hosztok, routerek és vona­ lak többször is tönkremennek és megjavulnak, és a topológia is sokszor fog változni. A forgalomirányító algoritmusnak képesnek kell lennie arra, hogy megbirkózzon a to­ pológiában és a forgalomban bekövetkező változásokkal anélkül, hogy az összes hoszton futó összes munkát meg kelljen szakítani, és a hálózatot újraindítani, ahány­ szor csak valamelyik router összeomlik. A stabilitás szintén fontos célja a forgalomirányító algoritmusnak. Léteznek algo­ ritmusok, amelyek soha nem közelítik meg az egyensúlyi állapotot, bármilyen hosszan fussanak is. Egy stabil algoritmus eléri az egyensúlyt, és meg is őrzi azt. Az igazsá­ gosság és az optimalitás szintén nyilvánvalónak tűnnek - bizonyára senkinek nem lenne kifogása ellenük - de amint kiderül, gyakran egymásnak ellentmondó célok. Er­ re a konfliktusra látható egy egyszerű példa az 5.5. ábrán. Tegyük fel, hogy elegendő forgalom van A és A\ B és B\ és C és C" között ahhoz, hogy telítse a vízszintes össze­ köttetéseket. Hogy a folyamok összegét maximalizáljuk, az X és X' közti forgalmat teljesen el kellene zárni. Sajnos X és X' esetleg nem így látja a dolgot. Nyilvánvaló, hogy valami kompromisszumra van szükség a globális hatékonyság és az egyes állo­ mások azonos elbírálása közt. Mielőtt akárcsak megpróbálnánk kompromisszumot keresni az igazságosság és az optimalitás közt, el kell határoznunk, mit akarunk optimalizálni. Nyilvánvaló jelölt erre az átlagos csomagkésleltetés minimalizálása, de ugyanígy a teljes hálózati átbocsátóké­ pesség maximalizálása is. Ez a két cél is ütközik, azonban ha bármely sorbanállási rend­ szert a teljesítőképessége határán működtetünk, az hosszú sorbanállási késleltetést von maga után. Kompromisszumként sok hálózatban a csomagok által megteendő ugrások szá­ mát kísérlik meg minimalizálni, mivel az ugrások számának csökkentése a késleltetést ja­ vítja, és a felhasznált sávszélességet is csökkenti, ezáltal az átbocsátóképesség is javul. A forgalomirányító algoritmusok két nagy osztályba sorolhatók: adaptív és nem adaptív algoritmusok. A nem adaptív algoritmusok (nonadaptive algorithms) nem támaszkodnak döntéseikben mérésekre vagy becslésekre az aktuális forgalomról és to­ pológiáról. Ehelyett az 7-től Z-ig használandó útvonalat (minden 7-re és J-re) előre,

393

A HÁLÓZATI RÉTEG

off-line módon számolják ki, és a hálózat indításakor letöltik a routerekbe. Ezt az eljá­ rást néha statikus forgalomirányításnak (static routing) is szokták nevezni. Ezzel ellentétben az adaptív algoritmusok (adaptive algorithms) úgy változtat­ ják forgalomirányítási döntéseiket, hogy tükrözzék a topológiában és rendszerint a forgalomban is történt változásokat. Az adaptív algoritmusok különbözhetnek abban, hogy honnan kapják az információikat (helyileg, a szomszédos routerektől vagy min­ den routertól), mikor változtatják az útvonalakat (minden AT másodpercben, amikor a terhelés változik, vagy amikor a topológia változik), és milyen mértéket használnak az optimalizáláshoz (távolságot, ugrások számát vagy becsült áthaladási időt). A követ­ kező szakaszokban sokféle algoritmust fogunk tárgyalni, ezek között lesznek statiku­ sak és dinamikusak is. 5.2.1.

Az optimalitási elv

Mielőtt beleásnánk magukat az egyes algoritmusokba, segítségünkre lehet, hogy az optimális útvonalakról egy általános megállapítás tehető, a hálózat topológiájától és a forgalomtól függetlenül. Ez a megállapítás az optimalitási elv (optimality principle) néven ismeretes. Az állítás szerint, ha a / router az I routertől K router felé vezető op­ timális útvonalon helyezkedik el, akkor a /-tői K-ig vezető útvonal ugyanerre esik. Hogy ezt belássuk, nevezzük az útvonal 7-től Z-ig tartó részét ri-nek és az útvonal má­ sik részét r2- ne k. Ha létezne egy r2-nél jobb, /-tői K-ig tartó útvonal, ezt összefűzhet­ nénk rj-gyel, hogy az 7-től K-ig tartó útvonalon is javítsunk. Ez viszont ellentmond állításunknak, miszerint r\T2 optimális. Az optimalitási elv egyenes következményeként beláthatjuk, hogy az összes forrás­ ból egy célba tartó optimális útvonalak egy fát alkotnak, amelynek gyökere a cél. Az ilyen fákat nyeló'fának (sink tree) nevezzük. Egy ilyen látható az 5.6. ábrán, ahol a távolság mértékegysége az ugrások száma. Vegyük észre, hogy a nyelőfa nem feltétle­ nül egyedi; más fák is létezhetnek ugyanolyan úthosszakkal. Minden forgalomirányító algoritmus célja a nyelőfák felderítése és használata az összes router számára. Mivel a nyelőfa valóban fa, nem tartalmaz hurkot, ezért minden csomag véges és B

5.6. ábra. (a) Egy alhálózat, (b) Egy nyelőfa a B routerhez

B

394

SZÁMÍTÓGÉP-HÁLÓZATOK

korlátos számú ugráson belül kézbesítésre kerül. A gyakorlatban az élet nem ilyen könnyű. Kapcsolatok és routerek tönkremehetnek és megjavulhatnak működés köz­ ben, ezért különböző routereknek különböző elképzeléseik lehetnek a pillanatnyi to­ pológiáról. Szintén csendben elmentünk azon kérdés mellett, hogy a routereknek egyénileg kell-e beszerezni az információt, amelyre a nyelőfaszámítás épül, vagy ezt az információt valami más módszerrel gyűjtik össze. Ezekre a kérdésekre hamarosan visszatérünk. Mindazonáltal az optimalitási elv és a nyelőfa egy mérőszámot adnak, amelyhez más forgalomirányító algoritmusokat viszonyíthatunk.

5.2.2.

Legrövidebb útvonal alapú forgalomirányítás

Kezdjük a forgalomirányító algoritmusok tanulmányozását egy olyan módszerrel, amelyet sok formában, széles körben használnak, mivel egyszerű és könnyű megérte­ ni. Az ötlet az, hogy építsük fel az alhálózat egy gráfját, ahol minden router egy cso­ mópontnak, és minden él egy kommunikációs vonalnak (amit gyakran kapcsolatnak [link] is hívnak) felel meg. Két adott router közötti útvonal kiválasztásához az algorit­ mus egyszerűen a köztük levő legrövidebb utat keresi meg a gráfban. A legrövidebb út (shortest path) fogalma némi magyarázatra szorul. Egy út hoszszát mérhetjük például a megtett ugrások számával. Ezzel a mértékegységgel az 5.6. ábrán szereplő ABC és ABE út ugyanolyan hosszú. Egy másik mértékegység lehet a földrajzi távolság kilométerekben, amikor is ABC nyilvánvalóan sokkal hosszabb, mint ABE (feltéve, hogy az ábra léptékhelyes). Ám az ugrások száma és a földrajzi távolság mellett sok egyéb mértékegység lehet­ séges. Például mindegyik él súlya lehetne egy szabványos tesztcsomagra vonatkozó átlagos sorbanállási és átviteli késleltetés, amelyet óránkénti próbafuttatásokkal mér­ nénk. Ezzel az élsúlyozással a legrövidebb út a leggyorsabb út lesz, a legkevesebb kilométerű vagy legkevesebb élből álló helyett. A legáltalánosabb esetben az élsúlyok a távolság, a sávszélesség, az átlagos forga­ lom, a kommunikációs költség, az átlagos sorhosszúság, a mért késleltetés és más ér­ tékek függvényeként számíthatók ki. A súlyozó függvény változtatásakor az algorit­ mus a „legrövidebb" utat, a számos feltétel közül valamelyik vagy ezek kombinációja szerint számolná ki. Számos algoritmus ismert egy gráf két csomópontja közti legrövidebb út kiszámí­ tására. Az alábbi Dijkstrától (1959) származik. Minden csomópontot felcímkézünk (zárójelben) a forráscsomóponttól való, legrövidebb ismert út mentén mért távolságá­ val. Kezdetben nem ismertek ilyen utak, ezért minden csomópont címkéje végtelen. Ahogy az algoritmus halad előre és találja meg az utakat, a címkék módosulhatnak, jelezve az egyre jobb utakat. Egy címke lehet ideiglenes vagy állandó. Kezdetben minden címke ideiglenes. Amikor kiderül, hogy a címke a legrövidebb lehetséges utat jelzi, állandóvá tesszük, és ezek után már nem módosítjuk. A címkéző algoritmus bemutatásához nézzük az 5.7.(a) ábrán szereplő, irányítat­ lan, súlyozott gráfot, ahol a súlyok például távolságot jeleznek. Az A-tól D-ig vezető legrövidebb utat akarjuk megtalálni. Azzal kezdjük, hogy az A csomópontot állandó­ nak jelöljük meg, amit a kör besötétítésével jelzünk. Ezután sorban végigvizsgáljuk az

395

A HÁLÓZATI RÉTEG

B (2, A)

C (00, - )

- ) b D (oo,

C (9, B)

B (2, A)

-)JD D (oo ,-) Ai G (6, A) (c) B (2, A)

D(oo, 1)

H (»-)

C (9, B)

DK-)

F (6, E)b>D («>,-) A,

G (5, E)

H (9, G) (e)

G (5, E)

/

H (8, F)

(f)

5.7. ábra. Az első öt lépés az A-tól D felé vezető legrövidebb út kiszámításában. A nyilak a munkacsomópontot jelzik A-val (a munkacsomóponttal) szomszédos csomópontokat, és újracímkézzük őket az A-tól való távolságukkal. Amikor ezeket újracímkézzük, akkor azzal a csomóponttal is felcímkézzük őket, amelyiktől a vizsgálatot végeztük, hogy később rekonstruálhassuk a végső utat. Miután A minden szomszédját megvizsgáltuk, az egész gráfban levő ideiglenesen felcímkézett csomópontok közül a legkisebb címkével rendelkezői állan­ dóvá tesszük, amint az az 5.7.(b) ábrán látszik. Ez lesz az új munkacsomópont. Most fi-től kezdjük, és az összes szomszédját megvizsgáljuk. Ha B címkéjének és a B és a vizsgálandó csomópont közti él súlyának összege kisebb, mint a vizsgálandó csomópont címkéje, akkor rövidebb utat találtunk, és a csomópontot újracímkézzük. Miután a munkacsomópont összes szomszédját megvizsgáltuk, és ha lehetett, az ideiglenes címkéket újra cseréltük, az egész gráfból kikeressük a legkisebb értékű, ideiglenes címkével rendelkező csomópontot. Ezt állandóvá tesszük, és ez lesz a kö­ vetkező körben a munkacsomópont. Az 5.7. ábrán az algoritmus első öt lépése látható. Hogy lássuk, miért működik az algoritmus, nézzük az 5.7.(c) ábrát. Ezen a ponton éppen E-t tettük állandóvá. Tegyük fel, hogy volna ABE-né\ rövidebb út, mondjuk AXYZE. Két lehetőség van: vagy a Z csomópontot már állandóvá tettük, vagy még nem. Ha igen, akkor az E-t már megvizsgáltuk (abban a körben, ami előtt Z-t állandó­ vá tettük), tehát az AXYZE nem kerülte el a figyelmünket és így nem lehet a legrövi­ debb út.

396

SZÁMÍTÓGÉP-HÁLÓZATOK

#define MAX_NODES 1024 #define INFINITY 1000000000

/* a csomópontok számának maximuma 7 /* egy szám, amely nagyobb, mint bármely leghosszabb út */ int n, dist[MAX_NODES][MAX_NODES] /* dist[i][j] a távolság i-től j-ig 7 void shortest_path(int s, int t, int path[]) { struct state { /* a munka tárgyát képező út 7 int predecessor; /* előző csomópont 7 int length; /* a forrástól eddig számolt hossz */ enum {permanent, tentative} label; /* a címke állapota 7 } state[MAX_NODES]; int i, k, min; struct state *p; for (p = &state[0]; p < &state[n]; p++) { /* állapotinicializálás */ p->predecessor = - 1 ; p->length = INFINITY; p->label = tentative; } state[t].length = 0; state[t].label = permanent; k = t; /* k a kezdeti munkacsomópont */ do { r Van jobb út k felől? */ for (i = 0; i < n; i++) /* ennek a gráfnak n csomópontja van 7 if (dist[k][i]! = 0 && state[i].label == tentative) { if (state[k].length + dist[k][i] < state[i].length) { state[i]. predecessor = k; state[i].length = state[k].length + dist[k][i]; } } I* Keressük meg a legkisebb címkével rendelkező ideiglenesen felcímkézett csomópontot! */ k = 0; min = INFINITY; for (i = 0; i = 0); 5.8. ábra. Dijkslra algoritmusa egy gráfon keresztüli legrövidebb út kiszámítására Most nézzük azt az esetet, amikor Z még mindig ideiglenesen van felcímkézve. Z címkéje vagy nagyobb, vagy egyenlő E-ével, amikor is AXYZE nem lehet ABE-nél rö­ videbb út, vagy £-énél kisebb, amikor is Z és nem E lesz előbb állandó, lehetővé téve, hogy E-t Z-ből vizsgálhassuk.

A HÁLÓZATI RÉTEG

397

Ezt az algoritmust az 5.8. ábrán adjuk meg. Az n és dist globális változók írják le a gráfot; ezek még a shortest_path eljárás meghívása előtt inicializálásra kerülnek. A program és a fentebb leírt algoritmus között az egyetlen különbség, hogy az 5.8. ábrán a legrövidebb utat a végcsomóponttól, f-től számítjuk, a forráscsomópont, s helyett. Mivel egy irányítatlan gráfban a í-től í-ig vezető legrövidebb út ugyanaz, mint az í-től í-ig vezető, nem számít, melyik végén kezdjük (hacsak nincs több legrövidebb út, amikor is a keresés megfordítása egy másikat derítene fel). A visszafelé keresésnek az az oka, hogy minden csomópontot a megelőző, és nem a következő csomóponttal cím­ kéztünk fel. Amikor a végső utat a kimeneti változóba, a path-ba másoljuk, emiatt meg­ fordul az útvonal. A keresés megfordításával a két hatás kioltja egymást, és a választ a helyes sorrendben szolgáltatjuk.

5.2.3.

Elárasztás

Egy másik statikus algoritmus az elárasztás (flooding), amelyben minden bejövő cso­ magot minden kimenő vonalon kiküldünk, kivéve azon, amelyiken beérkezett. Az el­ árasztás nyilván nagyszámú kettőzött csomagot eredményez, valójában végtelen szá­ mút, hacsak nem teszünk intézkedéseket a folyamat elfojtására. Ilyen intézkedés, hogy legyen minden csomag fejrészében egy ugrásszámláló, amely minden ugráskor csök­ ken eggyel, és ha eléri a nullát, a csomagot eldobjuk. Ideális esetben az ugrásszámláló kezdeti értékének a forrástól a célig vezető út hosszát kell beállítani. Ha a küldő nem tudja, milyen hosszú az út, beállíthatja a legrosszabb esetre, nevezetesen az alhálózat teljes átmérőjére. Az elárasztás gátak közötti tartására egy másik módszer az, hogy tartsuk nyilván, mely csomagokkal végeztük már el az elárasztást, hogy elkerüljük másodszori kikül­ désüket. E cél elérésének egyik módja az, hogy a forrásrouter helyezzen el egy sorszá­ mot minden csomagba, amelyet a hosztjaitól kap. Ezek után minden routernek szüksé­ ge van forrásrouterenként egy listára, amely megmondja, mely sorszámokat látott már ebből a forrásból. Ha a beérkező csomag rajta van a listán, a router nem küldi tovább szomszédainak. Hogy meggátolja a lista korlát nélküli növekedését, minden listát ki kell egészíteni egy számlálóval, /c-val, melynek jelentése: k-ig minden sorszám előfordult már. Ami­ kor a csomag megérkezik, egyszerűen ellenőrizni kell, hogy az másodpéldány-e. Ha igen, el kell dobni. Ráadásul az egész k alatti listára nincs szükség, mivel k hatéko­ nyan összefoglalja azt. Az elárasztás egy változata, amely valamivel ésszerűbb, a szelektív elárasztás (selective flooding). Ebben az algoritmusban a routerek nem küldenek ki minden bejövő csomagot minden vonalon, csak azokon, amelyek megközelítőleg jó irányba mutat­ nak. Rendszerint nincs sok értelme egy nyugatra tartó csomagot egy kelet felé vezető vonalon kiküldeni, hacsak nem egészen különleges a topológia, és a router is teljesen biztos ebben. Az elárasztás nem praktikus a legtöbb alkalmazásban, de van néhány eset, ahol hasznos lehet. Katonai alkalmazásokban például, ahol minden pillanatban nagyszámú

398

SZÁMÍTÓGÉP-HÁLÓZATOK

router robbanhat darabokra, kifejezetten kívánatos az elárasztás egészséges robusztus­ sága. Elosztott adatbázis-alkalmazásokban néha szükséges az Összes adatbázis egy­ szerre történő frissítése, amikor is az elárasztás hasznos lehet. Vezeték nélküli háló­ zatokban egy állomás által sugárzott üzeneteket minden, az adott állomás vételkörze­ tében található másik állomás is veszi, ami szintén egyfajta elárasztásnak tekinthető, és néhány algoritmus ki is használja ezt a tulajdonságot. Az elárasztás negyedik lehet­ séges felhasználása, hogy más forgalomirányító algoritmusokat hasonlítunk hozzá, mint mértékegységhez. Az elárasztás mindig a legrövidebb utat választja, mert az öszszes lehetséges utat egyszerre választja. Ebből következően, nincs olyan algoritmus, amely rövidebb késleltetést tudna produkálni (ha az elárasztási folyamatból adódó többletidőt elhanyagoljuk).

5.2.4.

Távolságvektor alapú forgalomirányítás

A modern számítógép-hálózatok általában dinamikus algoritmusokat használnak a fentebb leírt statikusak helyett, mert a statikus algoritmusok nem veszik figyelembe a hálózat aktuális terhelését. Két algoritmus is igen népszerű: a távolságvektor alapú és a kapcsolatállapot alapú forgalomirányítás. Ebben a szakaszban az előbbit, a követke­ zőben pedig az utóbbit fogjuk tanulmányozni. A távolságvektor alapú forgalomirányítás (distance vector routing) alapja, hogy minden routernek egy táblázatot (vagyis egy vektort) kell karbantartania, amely­ ben minden célhoz szerepel a legrövidebb ismert távolság, és annak a vonalnak az azonosítója, amelyiken a célhoz lehet eljutni. A táblázatokat a szomszédokkal való in­ formációcsere útján frissítik. A távolságvektor alapú forgalomirányító algoritmust néha máshogy is nevezik, mint például elosztott Bellman-Ford forgalomirányítási algoritmus vagy - az őt ki­ fejlesztő kutatók után (Bellman,1957; Ford és Fulkerson,1962) - Ford-Fulkerson-algoritmus. Ez volt az ARPANET eredeti forgalomirányító algoritmusa és ezt használ­ ták az Interneten is RIP néven. A távolságvektor alapú forgalomirányító algoritmusban minden router karbantart egy táblázatot, amelyet az alhálózatban levő összes router szerint indexelnek, és amely mindegyikhez egy bejegyzést tartalmaz. Ez a bejegyzés két részből áll: az adott célhoz előnyben részesített kimeneti vonalból és a becsült időből vagy távolságból. A mér­ tékegység lehet az ugrások száma, időbeni késleltetés millíszekundumokban, az út mentén sorban álló összes csomag száma, vagy valami hasonló. Feltételezzük, hogy a router tudja a szomszédaitól való „távolságát". Ha a mérték­ egység az átugrások száma, akkor a távolság csak egy ugrás. Ha a mértékegység a sor­ hossz, akkor a router egyszerűen megvizsgál minden sort. Ha a mértékegység a késlel­ tetés, a router ezt közvetlenül mérheti különleges ECHÓ csomagokkal, amelyeket a vevő csak időbélyeggel lát el és visszaküld, amilyen gyorsan csak tudja. Példának okáért tételezzük fel, hogy a mértékegység a késleltetés, és a router isme­ ri az összes szomszédja felé a késleltetést. T ms-onként minden router minden szom­ szédjának listát küld az összes cél felé becsült késleltetéseiről. És minden szomszédjá­ tól kap egy hasonló listát. Képzeljük el, hogy épp most érkezett egy táblázat az X

399

A HÁLÓZATI RÉTEG

szomszédtól, amely tartalmazza X,-t, vagyis X becslését arról, hogy mennyi időbe telik az i routerig eljutni. Ha a router tudja, hogy a késleltetés X felé m ms, akkor azt is tudja, hogy az i routert X-en keresztül Xt + m ms idő alatt tudja elérni. Ezt a számolást minden szomszédra elvégezve, egy router megtudhatja, melyik becslés tűnik a leg­ jobbnak, és a következőkben ezt a becslést és a hozzá tartozó vonalat használja az új forgalomirányító táblázatban. Vegyük észre, hogy a régi forgalomirányító táblázatot nem használják a számításhoz. Ezt a frissítési folyamatot illusztrálja az 5.9. ábra. Az (a) rész egy alhálózatot ábrá­ zol. A (b) rész első négy oszlopa a J router szomszédjaitól kapott késleltetési vektoro­ kat mutatja. A állítása szerint B felé 12, C felé 25, D felé 40 ms-os késleltetéssel ren­ delkezik. Tegyük fel, hogy J a szomszédai, A, I, H és K felé a késleltetéseket sorrend­ ben 8, 10, 12 és 6 ms-ra méri vagy becsüli.

(a) Új becsült késle Iteté s J-tő

Routerek felé A B C D E F G H 1 J K L

A 1 H K 0 24 20 21 12 36 31 28 25 18 19 36 40 27 8 24 14 30 7 22 23 19 20 40 18 6 31 31 17 0 20 19 21 14 0 22 7 11 9 10 22 24 22 0 33 29 9 9 JA Jl JH JK késleltetése késleltetése késleltetése késleltet ése 8 10 12 6

v

J négy szomszédjától kapott vektorok

\ Vonal 8 20 28 20 17 30 18 12 10 0 6 15

A A I H I I H H I

K K

J ú forgalonnrányitó táblázata

(b)

5.9. ábra. (a) Egy alhálózat, (b) J-hez érkező késleltetési vektorok A, I, H, K felől, és J új forgalomirányító táblázata

400

SZÁMÍTÓGÉP-HÁLÓZATOK

Gondoljuk el, hogyan számítja ki J a G felé vezető új útvonalat. Tudja, hogy el tud jutni A-ba 8 ms alatt, és A állítása szerint képes 18 ms alatt eljutni G-be, tehát J tudja, hogy 26 ms-os késleltetéssel kell számolnia, ha a G felé tartó csomagokat A-nak to­ vábbítja. Hasonlóan, a G felé J-n, H-n és K-n keresztül tapasztalható késleltetés sor­ rendben 41-nek (31 + 10), 18-nak (6 + 12), és 37-nek (31 +6) adódik. Ezen értékek közül a 18 a legjobb, így bejegyzi a forgalomirányító táblázatába, hogy G-ig a késlel­ tetés 18 ms, és a használandó útvonal H-n keresztül vezet. Ugyanezt a számolást kell elvégezni az összes többi célra is. Az új forgalomirányító táblázat az ábra utolsó osz­ lopában látható.

A végtelenig számolás problémája A távolságvektor alapú forgalomirányítás elméletben működik, de a gyakorlatban van egy komoly hátránya: bár konvergál a helyes válaszhoz, de ezt esetleg lassan teszi. Pontosabban, gyorsan reagál a jó hírekre, de ráérősen a rosszakra. Vegyünk egy routert, amelynek az X célig vezető legjobb útja nagy késleltetésű. Ha a legközelebbi cserekor az A szomszéd hirtelen egy rövid várakozású utat jelent az X-ig, a router egy­ szerűen átkapcsolja az X felé menő forgalmat az A felé vezető vonalra. Egy vektor­ csere folyamán a jó hír feldolgozásra került. Hogy lássuk, milyen gyorsan terjed a jó hír, vegyük az 5.10. ábra öt csomópontból álló (lineáris) alhálózatát, ahol a késleltetés mértékegysége az ugrások száma. Tegyük fel, hogy A kezdetben nem működik, és ezt az összes többi router tudja. Más szavak­ kal, mind végtelent írtak be az A felé érvényes késleltetéshez. Amikor A megjavul, a többi router ezt a vektorcserékből tudja meg. Az egyszerű­ ség kedvéért feltételezzük, hogy létezik egy hatalmas gong valahol, amelynek periodi­ kus ütéseire a routerek egyszerre cserélik ki vektoraikat. Az első csere idején B meg­ tudja, hogy bal oldali szomszédjának nulla késleltetése van A-ig. B most bejegyzi a forgalomirányító táblázatába, hogy A egy ugrásnyira van balra. Az összes többi router A B C D E •—•—•—•—• co oo oo oo Kezdetben

A B C D E •—•—•—•—• 1 2 3 4 Kezdetben

1

co oo oo 1 csere után

3

2

3

4

1 csere után

1

2

3

4

3

4

2 csere után

1

2

1 2

co oo 2 csere után 3

co 3 csere után

5 4

5

4

3 csere után

3

4

5

6

5

6

4 csere után

7 7

6 8

7 7

6 8

5 csere után 6 csere után

00

CO

00

CO

4 csere után

(a)

(b)

5.10. ábra. A végtelenig számolás problémája

A HÁLÓZATI RÉTEG

401

még mindig azt gondolja, hogy A nem működik. Az ekkor érvényes forgalomirányí­ tási táblázatok A-ra vonatkozó bejegyzéseit láthatjuk az 5.10.(a) ábra második sorá­ ban. A következő cserekor C megtudja, hogy fi-nek van egy 1 hosszú útja A felé, tehát frissíti a forgalomirányító táblázatát, hogy az egy 2 hosszú utat jelezzen, de D és E csak később tudja meg a jó hírt. Világos, hogy a jó hír egy ugrás/csere sebességgel terjed. Egy olyan alhálózatban, ahol a leghosszabb út N ugrás hosszú, N csere múlva mindenki tudni fog az újjáéledt vonalakról és routerekről. Most vegyük az 5.10.(b) ábrán látható szituációt, ahol kezdetben minden vonal és router működik. AB, C, D és E routerek távolsága A-tól sorrendben 1, 2, 3 és 4. Hir­ telen A elromlik, vagy más esetben, az A és fi közti vonal megszakad, ami B felől nézve gyakorlatilag ugyanaz. Az első vektorcserénél B nem hall semmit A felől. Szerencsére C azt mondja: „Ne aggódj. Van egy A-hoz vezető, 2 hosszú utam." B nem tudhatja, hogy C útja magán B-n vezet keresztül. Amennyit B tud, aszerint C-nek akár tíz kimenő vonala is lehet füg­ getlen A-hoz vezető' utakkal, amelyek mind 2 hosszúak. Ennek eredményeként B most azt gondolja, hogy elérheti A-t C-n keresztül, egy 3 hosszú úttal. D és E nem frissítik az A-ra vonatkozó bejegyzéseiket az eísó' cserekor. A második cserekor C észreveszi, hogy mindkét szomszédja azt állítja, hogy az Ahoz vezető út 3 hosszú. Kiválaszt közülük egyet véletlenszerűen, és az A-hoz tartozó új távolságot 4-re állítja, mint ahogy az 5.10.(b) ábra harmadik sorában látszik. A so­ rozatos cserék idézik elő az 5.10.(b) ábra maradék részén mutatott történést. Ebből az ábrából nyilvánvaló, miért terjed lassan a rossz hír: soha nincs egyik routernek sem több mint eggyel magasabb értéke, mint a szomszédainak a minimuma. Fokozatosan mindegyik router felküzdi magát a végtelenig, de az ehhez szükséges cserék száma a végtelen ábrázolásához használt számtól függ. Ennél az oknál fogva okos gondolat a végtelent a leghosszabb út hossza + l-re állítani. Ha a mértékegység az időbeni késleltetés, nincs ilyen jól definiált felső korlát, tehát egy nagy értékre lesz szükség, hogy a hosszú késleltetésű utakat ne vegyük meghibásodottnak. Nem megle­ pő módon, ez a probléma a végtelenig számolás (count-to-infinity) problémája né­ ven ismert. Történt már néhány kísérlet a probléma megoldására (mint például a meg­ osztott láthatár tiltott visszaúttal - split horizon with poisoned reverse - az RFC 1058ban), de ezek egyike sem működik jól általános esetben. A probléma lényege az, hogy ha X elmondja 7-nak, hogy van egy valahová vezető útja, 7-nak sehogy sem áll mód­ jában megtudnia, hogy vajon ő maga rajt van-e ezen az úton.

5.2.5.

Kapcsolatállapot alapú forgalomirányítás

Az ARPANET távolságvektor alapú forgalomirányítást használt 1979-ig, amikor is ezt felváltotta a kapcsolatállapot alapú forgalomirányítás. Két fő probléma okozta a bukását. Először is, mivel a távolságmérték a várakozási sorok hossza volt, az útvonal kiválasztásakor nem vette figyelembe a vonalak sávszélességét. Kezdetben az összes vonal 56 kb/s-os volt, így a vonalak sávszélessége nem volt téma, de miután néhány vonalat felfejlesztettek 230 kb/s-ra, másokat pedig 1,544 Mb/s-ra, jelentős probléma lett a sávszélesség figyelembe nem vétele. Természetesen lehetséges lett volna a kés-

402

SZÁMÍTÓGÉP-HÁLÓZATOK

leltetés alapú mértéket úgy megváltoztatni, hogy a sávszélességet is beszámítsa, de volt egy második probléma is, nevezetesen, hogy az algoritmus gyakran túl lassan konvergált, még a megosztott láthatárhoz hasonló trükkökkel is. Ezen okok miatt egy teljesen új algoritmus váltotta fel, amelyet mostanában kapcsolatállapot alapú forga­ lomirányításnak (link state routing) neveznek. Manapság a kapcsolatállapot alapú forgalomirányítás különböző változatait széles körben használják. A kapcsolatállapot alapú forgalomirányítás mögötti ötlet egyszerű, és öt részből te­ hető össze. Minden routernek a következőket kell tennie: 1. Felkutatni a szomszédait és megtudni a hálózati címeiket. 2. Megmérni a késleltetést vagy költséget minden szomszédjáig. 3. Összeállítani egy csomagot, amely a most megtudottakat tartalmazza. 4. Elküldeni ezt a csomagot az összes többi routernek. 5. Kiszámítani az összes többi routerhez vezető legrövidebb utat. Gyakorlatilag a teljes topológiát és az összes késleltetést kísérletileg megmérik és eljuttatják az összes routernek. Ezután a Dijkstra-algoritmust használhatják, hogy megtalálják a legrövidebb utat az összes többi routerhez. Az alábbiakban mind az öt lépést részletesebben is megvizsgáljuk.

A szomszédok megismerése Amikor egy router beindul, az első feladata, hogy megtudja, kik a szomszédai. Ezt a célt azáltal éri el, hogy egy speciális HELLO csomagot küld ki minden hozzá kapcsoló­ dó vonalon. A másik végen levő routertől elvárja, hogy egy választ küldjön vissza, amelyben közli azonosítóját. Ezeknek a neveknek globálisan egyedieknek kell lenni-

(a) 5.11. ábra. (a) Kilenc router és egy LAN. (b) Az (a) gráfmodellje

(b)

A HÁLÓZATI RÉTEG

403

ük, mert amikor később egy távoli router azt hallja, hogy három router az F-hez csat­ lakozik, el kell döntenie, hogy mind a három ugyanaz az F vagy sem. Amikor két vagy több routert LAN köt össze, a helyzet kicsivel bonyolultabb. Az 5.11 .(a) ábra egy LAN-t mutat, amihez három router, A, C és F kapcsolódik közvetlenül. Ezen routerekhez egy vagy több további router kapcsolódik, amint az ábra mutatja. A LAN modellezésének egyik módja, hogy egy csomópontnak fogjuk fel, amint az 5.1 l.(b) ábra mutatja. Itt egy új, mesterséges csomópontot vezettünk be, 7V-et, amihez A, C és F kapcsolódik. A tényt, hogy lehetséges A-tól C-ig eljutni a LAN-on, itt az ANC út mutatja.

A vonal költségének mérése A kapcsolatállapot alapú forgalomirányítás megköveteli, hogy minden router tudja, vagy legalábbis reálisan tudja becsülni a szomszédai felé fennálló késleltetést. A kés­ leltetés meghatározásának legközvetlenebb módja egy speciális ECHÓ csomag kikül­ dése a vonalon, amelyet a másik oldalnak azonnal vissza kell küldenie. A körbejárási késleltetést megmérve és kettővel elosztva, a küldő router reális becslést kaphat a kés­ leltetésről. Még jobb eredmények eléréséhez a kísérletet számos alkalommal el lehet végezni, és az átlagot lehet használni. Ez az eljárás persze implicit módon azt feltéte­ lezi, hogy a késleltetések szimmetrikusak, ami nem mindig felel meg a valóságnak. Érdekes kérdés, hogy a terhelést a késleltetés mérésekor figyelembe vegyük-e vagy sem. Ha beleszámoljuk a terhelést, akkor a körbejárási időzítőt akkor kell indítani, amikor az ECHÓ csomagot a sorba betesszük. Ha figyelmen kívül hagyjuk a terhelést, akkor az időzítőt akkor kell indítani, amikor az ECHÓ csomag a sor elejére ér. Mindkét esetet meg lehet indokolni. Ha a forgalom által okozott késleltetéseket is belevesszük a mérésekbe, ez azt jelenti, hogy amikor egy router két azonos sávszéles­ ségű vonal közül választhat, és az egyik folyton terhelt, a másik pedig nem, akkor a terheletlen vonalon keresztül vezető utat rövidebbnek fogja fel. Ez a választás jobb teljesítményt fog eredményezni. Sajnos van egy érv a terhelésnek a késleltetésbe való beszámítása ellen is. Vegyük az 5.12. ábra alhálózatát, amely két részre oszlik, keletire és nyugatira, amelyeket két

5.12. ábra. Egy alhálózat, amelyben a keleti és nyugati részeket két vonal köti össze

404

SZÁMÍTÓGÉP-HÁLÓZATOK

vonal köt össze, CF és El. Tegyük fel, hogy a kelet-nyugat közti forgalom legna­ gyobb része a CF vonalat használja, és ezért a vonal erősen terhelt, és hosszú késlelte­ téssel bír. Ha bevesszük a sorban állási késleltetést a legrövidebb út számításába, ak­ kor El vonzóbbnak fog tűnni. Miután használatba vesszük az új forgalomirányító táb­ lázatokat, a kelet-nyugat forgalom legnagyobb része El-n keresztül fog haladni, és ezt a vonalat túl fogja terhelni. Következésképpen a következő frissítéskor CF fog a leg­ rövidebb útnak tűnni. Ennek eredményeként a forgalomirányító táblázatok vadul in­ gadozhatnak, ami szeszélyes forgalomirányításhoz és számos más lehetséges problé­ mához vezethet. Ha a terhelést figyelmen kívül hagyjuk, és csak a sávszélességet néz­ zük, a probléma nem lép fel. Alternatívaként a terhelést szétoszthatjuk mindkét vonal­ ra, de ez a megoldás nem használja ki teljesen a legrövidebb utat. Mindent egybevéve azonban még így is tanácsos lehet több vonal között megosztani a terhelést, minden vonalon a terhelés adott hányadával, hogy elkerüljük a legjobb útvonal kiválasztásá­ nak ingadozásait.

A kapcsolatáflapot csomagok összeállítása Az információcseréhez szükséges adatok összegyűjtése után a következő lépés az, hogy minden router összeállít egy csomagot, amely az összes adatot tartalmazza. A csomag a feladó azonosítójával kezdődik, amit egy sorszám és egy korérték (ezt ké­ sőbb tárgyaljuk), végül pedig a szomszédok listája követ. Minden szomszédhoz meg­ adják a feléje tapasztalható késleltetést is. Az 5.13.(a) ábrán egy példa alhálózat lát­ ható, a vonali késleltetések feltüntetésével. Az 5.13.(b) ábrán mind a hat routerhez lát­ hatók a megfelelő kapcsolatállapot csomagok. A kapcsolatállapot csomagok összeállítása egyszerű. Nehéz azt eldönteni, hogy mi­ kor állítsuk őket össze. Az egyik lehetőség, hogy periodikusan, vagyis szabályos idő­ közönként. Egy másik lehetőség, hogy amikor valami jelentős esemény történt, mint például egy vonal vagy szomszéd meghibásodott, megjavult, vagy megváltoztatta a tulajdonságait. B

2

C

E

8

F

(a)

Kapcsolat A Sorsz. Kor B 4 E 5

B Sorsz. Kor A 4 rc" 2 F 6

Állapot C Sorsz. Kor B 2 D 3 E 1

Csomagok

D Sorsz. Kor C 3 ^ 7

(b)

5.13. ábra. (a) Egy alhálózat, (b) Ezen alhálózat kapcsolatállapot csomagjai

E Sorsz. Kor A 5 C 1 F 8

F Sorsz. Kor B 6 D 7 E 8

A HÁLÓZATI RÉTEG

405

A kapcsolatállapot csomagok szétosztása Az algoritmus legkényesebb része a kapcsolatállapot csomagok megbízható szétosztá­ sa. Amint a csomagokat szétosztják és használni kezdik, az elsőket megkapó routerek meg fogják változtatni az útvonalaikat. Következésképpen, különböző routerek eset­ leg a topológia más-más változatait használják, ami inkonzisztenciákhoz, hurkokhoz, elérhetetlen gépekhez és más problémákhoz vezethet. Eló'ször leírjuk az alapvető' szétosztó algoritmust, majd később pár finomítást is adunk. Az alapötlet, hogy használjuk az elárasztást a kapcsolatállapot csomagok szét­ osztására. Hogy az áradást kézben tartsák, minden csomag tartalmaz egy sorszámot, amely minden egyes csomagküldésnél eggyel növekedik. A routerek számon tartanak minden (forrásrouter, sorszám) párt, amit csak látnak. Amikor egy új kapcsolatállapot csomag érkezik, összevetik a már látott csomagok listájával. Ha új, eddig nem látott csomag, akkor továbbítják minden vonalon, kivéve azon, amelyiken érkezett. Ha má­ sodpéldány, eldobják. Ha egy csomag olyan sorszámmal érkezik, amely alacsonyabb, mint a legmagasabb már látott sorszám, akkor elavult csomagnak tekintik és nem to­ vábbítják, hiszen a router rendelkezik már ennél frissebb információval is. Ennek az algoritmusnak van néhány problémája, de ezek kezelhetők. Először is, ha a sorszámok átfordulnak, zűrzavar fog eluralkodni. Itt a megoldás az, hogy 32 bites sorszámokat kell használni. Egy kapcsolatállapot csomagot feltételezve másodpercen­ ként, az átfordulás 137 év múlva következne be, így ezt a lehetőséget figyelmen kívül hagyhatjuk. Másodszor, ha egy router valamikor összeomlik, elfelejti, melyik sorszámnál tar­ tott. Ha újra 0-ról kezdi, a következő csomagot másodpéldányként felmenti és nem to­ vábbítja. Harmadszor, ha egy sorszám megsérül, és 65 540 érkezik meg 4 helyett (egy 1 bi­ tes hiba), az 5-től 65 540-ig tartó csomagokat elavultként visszautasítja, mivel a jelen­ legi sorszámot 65 540-nek hiszi. Mindezekre a problémákra az a megoldás, hogy minden csomagba a sorszáma után a csomag korát is bele kell tenni, és ezt másodpercenként eggyel csökkenteni kell. Amikor a kor eléri a nullát, az attól a routertól származó információt eldobják. Rend­ szerint mondjuk 10 másodpercenként érkezik egy új csomag, tehát a router információja csak akkor válik használhatatlanná, ha egy router meghibásodott (vagy ha hat egymás után következő csomag elveszett, de ez valószínűtlen). A kor mezőértékét minden router is csökkenti a kezdeti elárasztás során, így egy csomag sem veszhet el és élhet közelebbről meg nem határozott ideig (egy nulla korú csomag eldobásra kerül). A robusztusabbá tételhez néhány finomításra van szükség. Amikor egy kapcsolatálla­ pot csomag beérkezik a routerhez elárasztásra, nem kerül bele rögtön az adásra várakozó sorba. Ehelyett egy tárolóterületre kerül, hogy ott egy keveset várakozzon. Ha egy másik kapcsolatállapot csomag is beérkezik ugyanattól a forrástól, az elküldés előtt összeha­ sonlítják a sorszámukat. Ha egyenlők, a másodpéldány, ha különböznek, a régebbi kerül eldobásra. A routerek közti vonalakon bekövetkező hibák kivédésére minden kapcsolat­ állapot csomagot nyugtáznak. Amikor egy vonal tétlenné válik, körforgásos alapon vé­ gignézik a tárolóterületet, hogy kiválasszanak egy elküldendő csomagot vagy nyugtát. Az 5.14. ábrán látható a B router által az 5.13.(a) ábra alhálózatához használt adat-

406

SZÁMÍTÓGÉP-HÁLÓZATOK

struktúra. Minden sor megfelel egy nemrég érkezett, de még nem teljesen feldolgozott kapcsolatállapot csomagnak. A táblázat rögzíti, honnan indult a csomag, a sorszámát, a korát és az adatokat. Ezenkívül B mindhárom vonalához (az A, C, illetve F felé ve­ zetőkhöz) vannak küldési és nyugtázási jelzők. A küldési jelzők azt jelentik, hogy a csomagot a jelzett vonalon tovább kell küldeni. A nyugtázási jelzők azt jelentik, hogy ott a csomagot nyugtázni kell. Küldési jelzők

ACK jelzők

Forrás

Sorsz.

Kor

A

C

F

A

C

F

A

21

60

0

1

1

1

0

0

F

21

60

1

1

0

0

0

1

E

21

59

0

1

0

1

0

1

C

20

60

1

0

1

0

1

0

D

21

59

1

0

0

0

1

1

Adat

5.14. ábra. Az 5.13. ábra B routerének csomagpufferje Az 5.14. ábrán A kapcsolatállapot csomagja közvetlenül érkezett, így el kell külde­ ni C-nek és F-nek, és nyugtázni A-nak, ahogy a jelzőbitek mutatják. Hasonlóan az Ftől érkezett csomagot továbbítani kell A-nak és C-nek, és nyugtázni F-nek. A harmadik, F-től érkezett csomaggal azonban más a helyzet. Ez kétszer is meg­ jött, egyszer EAB-n és egyszer EFB-n keresztül. Következésképpen, csak C felé kell elküldeni, de A és F felé is nyugtázni kell, ahogy a bitek mutatják. Ha egy másodpéldány érkezik, amíg az eredeti még mindig a pufferben van, a bite­ ket át kell állítani. Például, ha egy másolat érkezik F felől C állapotáról, mielőtt a táb­ lázat negyedik bejegyzését továbbították volna, a hat bitet 100011-re kell változtatni, hogy jelezzük, hogy a csomagot nyugtázni kell F felé, de elküldeni nem. Az új útvonalak számítása Amint egy router a kapcsolatállapot csomagok egy teljes készletét összegyűjtötte, megszerkesztheti az alhálózat teljes gráfját, mivel minden kapcsolat képviselve van. Valójában minden kapcsolat kétszer szerepel, egyszer-egyszer mindkét irányba. A két érték átlagolható vagy külön használható. Most helyileg lefuttathatjuk a Dijkstra-algoritmust, hogy megszerkesszük a legrö­ videbb utat minden lehetséges célhoz. Ennek az algoritmusnak az eredményeit beír­ hatjuk a forgalomirányító táblázatba, és visszatérhetünk a normális működéshez. Egy olyan alhálózatban, amely n routerből áll és mindnek k szomszédja van, a be­ jövő adat tárolásához szükséges memória mérete fen-nel arányos. Nagy alhálózatoknál ez gond lehet. Szintén kérdéses lehet a számítási idő. Mindezek ellenére, sok gyakor­ lati helyzetben a kapcsolatállapot alapú forgalomirányítás jól működik.

A HÁLÓZATI RÉTEG

407

De hardver- vagy szoftverproblémák nagy pusztítást okozhatnak ezzel az algorit­ mussal (és másokkal is). Például, ha egy router azt állítja, hogy van olyan vonala, ami­ lyenje valójában nincs, vagy elfelejt egy olyan vonalat, amilyenje viszont van, az alhá­ lózat gráfja helytelen lesz: Ha egy router nem továbbít csomagokat, vagy továbbítás közben megrongálja azokat, gondok merülnek fel. Végül, ha kifogy a memóriából, vagy rosszul végzi el az útvonalak kiszámítását, csúnya dolgok fognak történni. Ahogy az alhálózat a tíz- vagy százezres csomóponti nagyságrendbe nő, annak a valószínűsé­ ge, hogy alkalmanként egy router meghibásodik, már nem lesz elhanyagolható. A trükk az, hogy próbáljuk a kárt korlátozni, amikor az elkerülhetetlenül bekövetkezik. Perlman (1988) részletesen tárgyalja ezeket a problémákat és a megoldásaikat. A kapcsolatállapot alapú forgalomirányítást széles körben használják a jelenlegi hálózatokban, ezért helyénvaló pár szót szólni az ezeket használó példaprotokollokról. Az OSPF-protokoll, amelyet egyre többen használnak az interneten, egy kapcsolatál­ lapot alapú algoritmust használ. Az OSPF-et az 5.6.4. részben írjuk le. Egy másik fontos kapcsolatállapot alapú protokoll az IS-IS (Intermediate System - Intermediate System), amelyet a DECnet számára terveztek, és amelyet később át­ vett az ISO is az összeköttetés nélküli hálózati rétegbeli protokolljába, a CLNP-be. Azóta módosították, hogy más protokollokat is kezeljen, különösen az IP-t. Az IS-IS-t számos internet-gerinchálózatban (például a régi NFSNET gerinchálózatban is), és né­ hány digitális cellás rendszerben használják, mint amilyen a CDPD. A Novell NetWare az IS-IS egy kisebb változatát használja (az NLSP-t) az IPX-csomagok for­ galomirányításához. Alapvetően az IS-IS egy képet oszt szét a routerek topológiájáról, amelyből számít­ ják a legrövidebb utat. Minden router bejelenti a kapcsolatállapot információiban, hogy mely hálózati rétegbeli címeket tud közvetlenül elérni. Ezek a címek lehetnek IP-, IPX-, AppleTalk- vagy bármilyen más címek. Az IS-IS egy időben többféle háló­ zati rétegbeli protokollt is támogathat. Az IS-IS számára tervezett újításokból sokat átvett az OSPF is (az OSPF-et évekkel az IS-IS után tervezték). Ezek közt olyanok vannak, mint a kapcsolatállapot frissítések elárasztásának önstabilizáló eljárása, a kijelölt router koncepciója egy LAN-on, vala­ mint az utak kettéosztásának és többfajta mérték használatának számításai és támo­ gatási módszere. Ennek következtében csak nagyon kicsi a különbség az OSPF és az IS-IS között. A legfontosabb különbség, hogy az IS-IS olyan módon kódolt, hogy azon egyszerű és természetes egyszerre többfajta hálózati rétegbeli protokoll informá­ cióit szállítani, míg az OSPF ezzel a tulajdonsággal nem rendelkezik. Ez az előny kü­ lönösen értékes nagy, többprotokollos környezetekben.

5.2.6.

Hierarchikus forgalomirányítás

Ahogy a hálózat mérete nő, a routerek forgalomirányító táblázatai is arányosan nőnek. Nemcsak a routerek memóriáját fogyasztják az egyre növekvő táblázatok, hanem több CPU-időre is van szükség az átvizsgálásukhoz, és nagyobb sávszélesség szükséges ah­ hoz, hogy elküldjük ezek állapotjelentéseit. Egyszer csak a hálózat akkorára nő, hogy már nem lehetséges minden egyes routerben minden más router számára egy bejegy-

408

SZÁMÍTÓGÉP-HÁLÓZATOK

zést fenntartani, ezért a forgalomirányítást hierarchikusan kell elvégezni, ahogy azt a telefonhálózatban is teszik. Amikor hierarchikus forgalomirányítást használunk, a routereket úgynevezett tar­ tományokra (regions) osztjuk. Minden router tudja, hogyan irányítsa a saját tartomá­ nyán belüli célok felé a csomagokat, de nem tud semmit a többi tartomány belső szer­ kezetéről. Amikor különböző hálózatokat kapcsolunk össze, természetes, hogy mind­ egyiket különálló tartománynak tekintjük, és így az egyik hálózaton belüli routerek­ nek nem kell tudniuk a többi hálózat topologikus szerkezetéről. Hatalmas hálózatok esetén kétszintű hierarchia elégtelen lehet; szükség lehet arra, hogy a tartományokat kerületekbe, a kerületeket zónákba, a zónákat csoportokba szer­ vezzük és így tovább, amíg csak ki nem fogyunk az egyesítésekre használt nevekből. A többszintű hierarchiára példaként nézzük meg, hogyan irányíthatnak egy csomagot a kaliforniai Berkeleyből a kenyai Malindibe. A berkeleybeli router ismerné a Kali­ fornián belüli részletes topológiát, de minden, az államból kifelé tartó forgalmat a Los Angeles-i routerhez küldene. A Los Angeles-i router képes lenne a többi belföldi routerhez irányítani a forgalmat, de a külföldi forgalmat New Yorkba küldené. A New York-i router úgy lenne felprogramozva, hogy minden forgalmat a célország külföldi forgalomért felelős routeréhez küldjön, mondjuk Nairobiba. Végül a csomag lefelé ha­ ladna a kenyai fán belül, amíg el nem éri Malindit. Az 5.15. ábra egy mennyiségi példát ad a forgalomirányításra egy kétszintű hie­ rarchiában, öt tartománnyal. Az IA teljes forgalomirányító táblázata 17 bejegyzést tar1A teljes táblázata

1. tartomány

2. tartomány

/''lB^\

/ 2A 2B

Í 1A ÁT1 C /

\2C

2D/

\ \ '"5B '"'5B

5C'\

4. tartomány /3A

4A

3. tartomány

5. tartomány

(a) 5.15. ábra. Hierarchikus forgalomirányítás

1A hierarchikus táblázata

Cél Vonal Átugrások Cél Vonal Átugrások

1A 1B 1C 2A 2B 2C 2D 3A 3B 4A 4B 4C 5A 5B 5C 5D 5E

1B 1C 1B 1B 1B 1B 1C 1C 1C 1C 1C 1C 1C 1B 1C 1C

1 1 2 3 3 4 3 2 3 4 4 4 5 5 6 5

(b)

1B 1C 2 3 4 5

1B 1C 1B 1C 1C 1C

1 1 2 2 3 4

(c)

A HÁLÓZATI RÉTEG

409

talmaz, ahogy az az 5.15.(b) ábrán látszik. Amikor a forgalomirányítást hierarchiku­ san végezzük, mint az 5.15.(c) ábrán, akkor, mint előzőleg, vannak a helyi routerekre vonatkozó bejegyzések, de a többi tartományt egy-egy csomópontba sűrítettük össze, így a 2. tartomány felé tartó összes forgalom az 15-24 vonalon keresztül halad, de a távoli forgalom többi része az 1C-35 vonalat használja. A hierarchikus forgalomirá­ nyítás a táblázat méretét 17 bejegyzésről 7-re csökkentette. Ahogy a tartományok szá­ mának tartományonkénti routerek számához viszonyított aránya nő, úgy növekszik a megtakarítás a táblázathelyekben. Sajnos ez a helymegtakarítás nincs ingyen. Ezért büntetést kell fizetni, mégpedig a megnövekedett úthossz formájában. Például az \A és 5C közti legjobb út a 2-es tarto­ mányon át vezet, de a hierarchikus forgalomirányításnál minden, az 5-ös tartomány felé tartó forgalom a 3-as tartományon keresztül zajlik, mert az 5-ös tartományon be­ lül a legtöbb célhoz ez a jobb. Amikor egy egyedülálló hálózat nagyon nagyra nő, egy érdekes kérdés merül fel: hány szintje legyen a hierarchiának? Vegyünk például egy 720 routerből álló alháló­ zatot. Ha nincs hierarchia, minden routernek 720 táblázatbejegyzésre van szüksége. Ha az alhálózatot felosztjuk 24 tartományra, amelyek mindegyikében 30 router van, minden routernek 30 helyi és 23 távoli bejegyzésre van szüksége, ez összesen 53 be­ jegyzés. Ha háromszintű hierarchiát választunk, nyolc kerülettel, amelyek mindegyike 9, tízrouteres tartományból áll, minden routernek 10 bejegyzésre van szüksége a helyi routerekhez, 8 bejegyzésre a saját kerületen belüli tartományokhoz, és 7 bejegyzésre a távoli kerületekhez, ez összesen 25 bejegyzés. Kamoun és Kleinrock (1979) felfedez­ ték, hogy egy N routerből álló alhálózathoz a szintek optimális száma In N, amely e • In N bejegyzést igényel routerenként. Azt is megmutatták, hogy a hierarchikus for­ galomirányítás által okozott átlagos valódi úthosszúság-növekedés elegendően kicsi ahhoz, hogy általában elfogadható legyen.

5.2.7.

Adatszóró forgalomirányítás

Néhány alkalmazásban a hosztoknak néhány vagy az összes többi hosztnak kell üze­ neteket küldeniük. Például egy olyan szolgáltatás, amely időjárás-jelentést, tőzsdei hí­ reket vagy élő rádióműsort oszt szét, a legjobban úgy működhet, hogy adatszórással minden géphez adatokat küld, és az érdeklődők elolvashatják azokat. Egy csomag mindenhová történő egyidejű elküldését adatszórásnak (broadcasting) nevezzük. Különböző módszereket javasoltak ennek megvalósítására. Az egyik adatszóró eljárás, amely nem igényel semmi különleges tulajdonságot az alhálózattól, úgy működik, hogy a forrás egyszerűen külön csomagot küld minden egyes rendeltetési helyre. Ez a megoldás nemcsak sávszélesség-pazarló, hanem azt is megköveteli a forrástól, hogy rendelkezzen a rendeltetési helyek teljes listájával. A gyakorlatban lehet, hogy ez az egyetlen lehetőség, de a lehetséges eljárások közül ez a legkevésbé kívánatos. Az elárasztás egy másik nyilvánvaló jelölt. Bár az elárasztás nem megfelelő a ren­ des kétpontos kommunikációhoz, az adatszóráshoz komolyan számításba vehető, kü­ lönösen, ha az alább leírt módszerek közül egyik sem alkalmazható. A probléma az el-

410

SZÁMÍTÓGÉP-HÁLÓZATOK

árasztással, ha adatszórásra használjuk ugyanaz, mint a két pont közötti forgalomirá­ nyítás esetén: túl sok csomagot generál és túl nagy sávszélességet fogyaszt. Egy harmadik algoritmus a többcélú forgalomirányítás (multidestination routing). Ha ezt az eljárást használják, minden csomag tartalmaz vagy egy listát a rendel­ tetési helyekről vagy egy bittérképet, amely a kívánt rendeltetési helyeket jelzi. Ami­ kor egy csomag megérkezik egy routerhez, a router megnézi a rendeltetési helyek lis­ táját, hogy eldöntse, mely kimeneti vonalakra lesz szükség. (Akkor van kimeneti vo­ nalra szükség, ha az a legjobb út legalább egy rendeltetési hely felé.) A router előállít­ ja a csomag egy új másolatát minden használandó kimeneti vonal számára, és csak azokat a célcímeket teszi bele, amelyeknek azt a vonalat kell használniuk. Ezzel a ren­ deltetési helyek halmazát felosztja a kimenő vonalak közt. Elegendő számú ugrás megtétele után minden csomag csak egy címet fog tartalmazni, és normális csomag­ ként kezelhető. A többcélú forgalomirányítás olyan, mint a külön címzett csomagok esete, kivéve, hogy amikor több csomagnak is ugyanazt az útvonalat kell követnie, egyikük fizeti a teljes viteldíjat, a többi ingyen utazik. Egy negyedik adatszóró algoritmus kifejezetten kihasználja az adatszórást kezde­ ményező routerhez tartozó nyelőfát, vagy bármely más kényelmes feszítőfát. Egy fe­ szítőfa (spanning tree) az alhálózat részhalmaza, amelyben minden router benne van, de nem tartalmaz hurkokat. Ha minden router tudja, mely vonalai tartoznak a feszí­ tőfához, egy bejövő adatszórásos csomagot minden, a feszítőfához tartozó vonalra ki­ másolhat, kivéve azt, amelyen érkezett. Ez az eljárás kitűnően használja ki a sávszé­ lességet, csak annyi csomagot hoz létre, amennyi mindenképpen szükséges a feladat elvégzéséhez. Az egyetlen probléma az, hogy minden routernek ismernie kell valami­ lyen feszítőfát, hogy alkalmazható legyen. Néha ez az információ rendelkezésre áll (pl. kapcsolatállapot alapú forgalomirányítás esetén), de néha nem (pl. távolságvektor alapú forgalomirányítás esetén). Az utolsó adatszóró algoritmusunk kísérlet arra, hogy az előző algoritmus visel­ kedését megközelítsük, még akkor is, amikor a routerek nem tudnak semmit a feszí­ tőfákról. Az ötlet, amelyet visszairányú továbbításnak (reverse path forwarding) neveznek, figyelemre méltóan egyszerű, ha már egyszer megmutatták. Amikor egy adatszórásos csomag megérkezik egy routerhez, a router ellenőrzi, hogy azon a vona­ lon kapta-e meg, amelyen rendszerint ő szokott az adatszórás forrásához küldeni. Ha igen, akkor nagy esély van rá, hogy az adatszórásos csomag a legjobb utat követte a routertol, és ezért ez az első másolat, amely megérkezett a routerhez. Ha ez az eset, a router kimásolja minden vonalra, kivéve arra, amelyiken érkezett. Viszont, ha az adat­ szórásos csomag más vonalon érkezett, mint amit a forrás eléréséhez előnyben ré­ szesítünk, a csomagot eldobják, mint valószínű másodpéldányt. A visszairányú továbbítás algoritmusára az 5.16. ábrán láthatunk példát. Az (a) rész az alhálózatot, a (b) rész az alhálózat I routerének nyelőfáját, a (c) rész pedig a visszairányú algoritmus működését szemlélteti. Az első ugrás során / csomagokat küld F-nek, //-nak, i-nek és N-nek, ahogy azt a fa második sora mutatja. Ezen csoma­ gok mindegyike az I felé vezető előnyben részesített úton érkezett (feltételezve, hogy az előnyben részesített utak a nyelőfával egybeesnek); ezt jelzi a betűk körüli kör. A második ugrás során nyolc csomag keletkezik: minden olyan router, amely az első ug­ rás során megkapta a csomagot, létrehoz kettőt. Amint látjuk, mind a nyolc még meg

411

A HÁLÓZATI RÉTEG

(a)

(b)

5.16. ábra. Visszairányít továbbítás, (a) Egy alhálózat, (b) Egy nyelőfa. (c) A visszairányú továbbítás által felépített fa nem látogatott routerhez érkezik, és öt közülük az előnyben részesített vonalon. Abból a hat csomagból, amely a harmadik ugrás során keletkezik, csak három érkezik az előnyben részesített úton (C-hez, £-hez és /f-hoz); a többi másodpéldány. Öt ugrás és 24 csomag után az adatszórás megszakad, ezzel szemben a nyelőfa pontos követése­ kor négy ugrásra és 14 csomagra lett volna szükség. A visszairányú továbbítás legfontosabb előnye, hogy ésszerűen hatékony és könynyen megvalósítható. Nem követeli meg a routerektől, hogy tudjanak feszítőfákról, és a céllista vagy bittérkép által okozott többlet sincs jelen minden adatszórásos csomag­ ban, mint a többcélú forgalomirányításnál. A folyamat megállításához sincs szükség külön mechanizmusokra, mint ahogy az elárasztás esetében szükség volt (vagy min­ den csomagban egy átugrásszámláló és az alhálózat átmérőjének előzetes ismerete, vagy forrásonként a már látott csomagok listája).

5.2.8.

Többesküldéses forgalomirányítás

Néhány alkalmazás megköveteli, hogy egymástól nagy távolságokra lévő folyamatok meghatározott csoportokban együtt tudjanak működni egymással. Ilyen lehet például, egy elosztott adatbázis rendszert megvalósító folyamatok csoportja. Ezekben az ese­ tekben gyakran szükséges, hogy egy folyamat a csoport összes többi tagjának üzenetet

412

SZÁMÍTÓGÉP-HÁLÓZATOK

küldjön. Ha a csoport kicsi, küldhet két pont közötti üzenetet is. Ha a csoport nagy, ez a stratégia drága. Néha az adatszórás használható, de az adatszórás használata arra, hogy 1000 gépet értesítsünk egy millió csomópontos hálózaton, nem hatékony, mert az elküldött üzenet a legtöbb vevőt nem érdekli (vagy ami még rosszabb, nagyon is érdekli, de nem szabad látniuk). Ezért olyan üzemmódra van szükségünk, amellyel jól meghatározott, számszerűleg nagy, de a teljes hálózathoz viszonyítva kis csoportok­ nak tudunk üzenetet küldeni. Az ilyen csoportnak történő üzenetküldést többesküldésnek (multicasting) nevezzük, és az ehhez tartozó forgalomirányító algoritmust többesküldéses forgalomirányításnak (multicast routing). Ebben a részben leírunk egy módszert a többesküldés forgalomirá­ nyítására. További információkért lásd (Chu és mások, 2000; Costa és mások, 2001; Kaséra és mások, 2000; Madruga és Garcia-Luna-Aceves, 2001; Zhang és Ryu, 2001). A többesküldéshez a csoportok menedzselése is szükséges. Valami módon létre kell hozni csoportokat, majd ezeket meg kell szüntetni, a folyamatoknak csatlakoz­ niuk kell a csoporthoz, és ki kell válniuk belőle. Hogy hogyan valósulnak meg ezek a feladatok, azzal a forgalomirányító algoritmus nem foglalkozik. Amivel viszont igen, az az, hogy amikor egy folyamat csatlakozik egy csoporthoz, tudatja ezt a tényt a hosztjával. Fontos, hogy a routerek tudják, mely hosztok mely csoportokhoz tartoz­ nak. Vagy a hosztoknak kell a routereiket értesíteni a csoporttagságokban beállt válto­ zásokról, vagy a routereknek kell rendszeresen lekérdezni a hosztjaikat. Bárhogy is történik, a routerek megtudják, hogy mely hosztjuk mely csoportokba tartozik. A routerek értesítik a szomszédjaikat, így az információ tovaterjed az alhálózaton. A többesküldés forgalomirányításához minden router kiszámít egy, az alhálózatban levő összes többi routert lefedő feszítőfát. Például, az 5.17.(a) ábrán van egy alhálózat két csoporttal, 1-gyel és 2-vel. Néhány router olyan hosztokhoz csatlakozik, amelyek az egyik vagy mindkét csoportba tartoznak, ahogy az ábrán látszik. A legbaloldalibb router feszítőfája látható az 5.17.(b) ábrán. Amikor egy folyamat többesküldéses csomagot küld egy csoportnak, az első router megvizsgálja a feszítőfáját és csonkolja, eltávolítván az összes vonalat, amely nem csoporttag hoszthoz vezet. Példánkban az 5.17.(c) ábrán látható az 1. csoport csonkolt feszítőfája. Hasonlóan az 5.17.(d) ábrán látható a 2. csoport csonkolt feszítőfája. A többesküldéses csomagokat csak a megfelelő feszítőfa mentén továbbítják. Különféle módjai vannak a feszítőfa csonkolásának. A legegyszerűbbet akkor használhatjuk, amikor kapcsolatállapot alapú forgalomirányítást használunk, és min­ den router ismeri az alhálózat teljes topológiáját, beleértve azt is, hogy mely hosztok mely csoportokhoz tartoznak. Ekkor a feszítőfát minden út végénél kezdve, és a gyö­ kér felé haladva csonkolhatjuk, eltávolítva mindazon routereket, amelyek nem tartoz­ nak a kérdéses csoportba. A távolságvektor alapú forgalomirányításnál más csonkolási stratégiát követhe­ tünk. Az alapalgoritmus a visszairányú továbbítás. Viszont, amikor egy olyan router kap többesküldéses üzenetet, amelynek nincs abban a csoportban érdekelt hosztja és nincs más routerekhez kapcsolata, PRUNE üzenettel válaszol, utasítva a küldőt, hogy en­ nek a csoportnak szóló többesküldéseket ne küldjön többet. Amikor egy router, amelynek nincs csoporttag a hosztjai közt, minden vonalán ilyen üzeneteket kapott, ő is PRUNE üzenettel válaszolhat. Ily módon az alhálózat rekurzívan csonkolódik.

413

A HÁLÓZATI RÉTEG

(a)

(b)

(c)

(d)

5.17. ábra. (a) Egy alhálózat, (b) Egy feszítőfa a legbaloldalibb routerhez- (c) Egy többesküldés-fa az 1. csoport számára, (d) Egy többesküldés-fa a 2. csoport számára

Ezen algoritmus egyik lehetséges hátránya, hogy nagy hálózatokra nehezen mére­ tezhető. Tegyük fel, hogy a hálózatban n csoport van, mind átlagosan m taggal. Min­ den csoporthoz m csonkolt feszítőfát kell tárolni, ez összesen mn fa. Amikor sok nagy csoport van, tekintélyes méretű tár kell a tárolásukhoz. Egy alternatív terv mag alapú fákat (core-based trees) használ (Ballardie és má­ sok, 1993). Itt egy feszítőfát számolnak ki csoportonként, a gyökérrel (maggal) a cso­ port közepén. Többesküldéses üzenet küldéséhez a hosztnak a maghoz kell az üzene­ tet küldenie, amely aztán elvégzi a többesküldést a feszítőfa mentén. Bár ez a fa nem lesz optimális minden forrás számára, a tárolási költségek m fáról csoportonként egy fára csökkennek, ami jelentős megtakarítás.

5.2.9.

Forgalomirányítás mozgó hosztok esetében

Manapság emberek milliói rendelkeznek hordozható számítógéppel, és általában bár­ hol is vannak a világon, el akarják olvasni az elektronikus leveleiket, és el akarják érni a rendes fájlrendszerüket. Ezek a mozgó hosztok új bonyodalmat jelentenek: ahhoz, hogy egy csomagot egy mozgó hoszthoz irányíthassunk, a hálózatnak először meg kell találnia azt. A mozgó hosztok hálózatba való bevonásának témaköre még nagyon

414

SZÁMÍTÓGÉP-HÁLÓZATOK

fiatal, de ebben a részben felvázolunk néhány idevágó kérdést, és adunk egy lehetsé­ ges megoldást is. A hálózattervezők által tipikusan használt világmodellt az 5.18. ábra mutatja. Van egy WAN-unk, amely routerekbol és hosztokból áll. A WAN-hoz LAN-ok, MAN-ok és olyan drót nélküli cellák kapcsolódnak, amelyeket a 2. fejezetben tanulmányoztunk. Azokat a hosztokat, amelyek soha nem mozognak, mozdulatlan (stationary) hosztoknak nevezzük. Ezek a hálózathoz rézvezetéken vagy üvegszálon keresztül kap­ csolódnak. Ezzel szemben a mozgó hosztokat két csoportra oszthatjuk. A vándorló (migratory) hosztok alapvetően mozdulatlanok, bár időről időre egyik rögzített helyről a másikra költöznek, de csak akkor használják a hálózatot, amikor fizikailag is kapcsolód­ nak hozzá. A barangoló (roaming) hosztok valóban mozgás közben használják a számí­ tógépet, és akkor is fenn akarják tartani hálózati kapcsolataikat, amikor épp mozognak. A mozgó hoszt (mobile hőst) kifejezést mindkét utóbbi kategóriára használjuk, vagyis minden hosztra, amelyik nem otthon van, de szüksége van hálózati kapcsolatra. Feltesszük, hogy minden felhasználónak van állandó lakhelye (permanent home location), amely soha nem változik. A felhasználóknak van egy állandó lakcímük is, amely felhasználható a lakhely meghatározására, hasonlóan, ahogy az 1-212-5551212 telefonszámból kiolvasható az Egyesült Államok (l-es országkód) és Manhattan (212). A forgalomirányítás célja a mozgó felhasználókkal rendelkező rendszerekben az, hogy lehetővé tegyük a mozgó felhasználók számára csomagok küldését a lakcí­ mükre, és hogy a csomagok hatékonyan érjék el őket, bárhol is legyenek. Termé­ szetesen a trükk az, hogy meg kell őket találni. Az 5.18. ábra modelljében, a világ (földrajzilag) fel van osztva kis egységekre. Hívjuk ezeket körzetnek, ahol egy körzet tipikusan egy LAN- vagy vezeték nélküli cella. Minden körzetnek van egy vagy több idegen ügynöke (foreign agent), amely nyilvántartja az összes, ebbe a körzetbe látogató mozgó felhasználót. Ezenkívül min­ den körzetnek van egy hazai ügynöke (home agent) is, amely azon felhasználókat tartja nyilván, akiknek itt van a lakhelyük, de most éppen más körzetbe látogattak el. Amikor egy új felhasználó belép a körzetbe, vagy rákapcsolódással (például egy

Vezeték nélküli cella Mozgó hoszt Idegen ügynök

\

WAN MAN 5.18. ábra. Egy WAN, amelyhez LAN-ok, MAN-ok, és vezeték nélküli cellák kapcsolódnak

A HÁLÓZATI RÉTEG

415

LAN-ba való bekötéssel), vagy egyszerűen a cellába lépés útján, a számítógépének re­ gisztráltatnia kell magát az ottani idegen ügynöknél. A bejegyeztetési folyamat tipiku­ san a következőképpen működik: 1. Minden egyes idegen ügynök periodikusan szétküld egy csomagot, amelyben léte­ zését és a címét közli. Egy újonnan érkezett mozgó hoszt várhat egy ilyen üzenetre, de ha egy ilyen sem érkezik elég gyorsan, a mozgó hoszt is szétküldhet egy cso­ magot, „Van itt idegen ügynök?" tartalommal. 2. A mozgó hoszt bejegyezteti magát az idegen ügynöknél, megadja a lakcímét, jelen­ legi adatkapcsolati rétegbeli címét, és valamilyen biztonsági információt. 3. Az idegen ügynök kapcsolatba lép a mozgó hoszt hazai ügynökével, és azt mondja: „Az egyik hosztod itt van." Az üzenet, amely az idegen ügynöktől a hazai ügy­ nökig megy, tartalmazza az idegen ügynök hálózati címét. Tartalmaz továbbá biz­ tonsági információt is, hogy meggyőzze a hazai ügynököt arról, hogy a mozgó hoszt valóban ott van. 4. A hazai ügynök megvizsgálja a biztonsági információt, amely egy időbélyeget is tartalmaz annak bizonyítására, hogy azt az elmúlt pár másodpercben hozták létre. Ha ezzel meg van elégedve, utasítja az idegen ügynököt a folytatásra. 5. Amikor az idegen ügynök megkapja a nyugtát a hazai ügynöktől, létrehoz egy bejegy­ zést a táblázataiban, és tudatja a mozgó hoszttal, hogy regisztrációja megtörtént. Ideális esetben, amikor egy felhasználó elhagy egy körzetet a regisztráció törlése végett, ezt be kellene jelenteni, azonban sok felhasználó csak kikapcsolja a számítógé­ pét, amikor végzett. Amikor egy csomagot küldenek a mozgó hosztnak, azt a hoszt otthoni LAN-jára irányítják, mert a cím alapján ez a teendő, amint azt az 5.19. ábra első lépése mutatja. Itt az északnyugati Seattle városában levő adó egy csomagot szeretne küldeni az Egyesült Államokon keresztül az általában New Yorkban tartózkodó címzetthez. A mozgó hosztnak címzett csomagokat New Yorkban az otthoni LAN hazai ügynöke el­ fogja. A hazai ügynök ezután megkeresi a mozgó hoszt új (ideiglenes) helyét, és meg­ keresi a mozgó hosztot kezelő idegen ügynök címét, Los Angelesben. Ezután a hazai ügynök két dolgot tesz. Elsőként beágyazza a csomagot egy külső cso­ mag adatmezejébe, és ezt a csomagot elküldi az idegen ügynöknek (a 2. lépés az 5.19. áb­ rán). Ezt a mechanizmust alagút típusú továbbításnak hívják, és később részletesebben is megtárgyaljuk. Miután megkapta a beágyazott csomagot, az idegen ügynök kiveszi az ere­ deti csomagot az adatmezőből, és adatkapcsolati keretként küldi el a mozgó hosztnak. Másodikként a hazai ügynök utasítja az adót, hogy a továbbiakban a mozgó hosztnak szánt csomagokat úgy küldje el, hogy ágyazza be azokat a kimondottan az idegen ügynök­ nek címzett csomagok adatmezejébe ahelyett, hogy egyszerűen a mozgó hoszt otthoni cí­ mére küldené (3. lépés). Az ezt követő csomagokat már egyenesen a hoszthoz lehet irányí­ tani az idegen ügynökön keresztül (4. lépés), teljesen kihagyva az otthoni hálózatot.

416

SZÁMÍTÓGÉP-HÁLÓZATOK.

1. A csomagot a mozgó hoszt otthoni címére küldik

4. A további csomagokat egy alagúton keresztül az idegen ügynökhöz küldik

3. Az adó megkapja az idegen ügynöj; címét 2. A csomagot egy alagúton keresztül átviszik az idegen ügynökhöz

5.19. ábra. Csomagok forgalomirányítása mozgó kosztok számára A különböző javasolt megoldások több helyen is eltérnek egymástól. Először is az a kérdés, hogy a protokoll mekkora részét végezzék a routerek és mekkorát a hosztok, és a hosztok melyik rétege. Másodszor, néhány megoldásban az út menti routerek fel­ jegyzik a leképzett címeket, így el tudják fogni és átirányítani a forgalmat, még mi­ előtt a lakhelyhez érne. Harmadszor, néhány megoldásban minden látogató egy egyedi ideiglenes címet kap; más megoldásokban az ideiglenes cím egy ügynökre hivatkozik, amely az összes látogatónak szóló forgalmat kezeli. Negyedszer, a megoldások abban is különböznek, hogy hogyan oldják meg a gya­ korlatban azt az esetet, amikor egy célcímre irányuló csomagot egy másik címre kell kézbesíteni. Egy választás, hogy változtassuk meg a célcímet és adjuk újra a módosí­ tott csomagot. Alternatívaként az egész csomagot, lakcímestül, mindenestül egy másik csomag adatmezejébe ágyazhatjuk be, amelyet az ideiglenes címre küldünk. Végül a megoldások a biztonsági megfontolások tekintetében is különböznek. Általában, ami­ kor egy hoszt vagy router egy ilyen formájú üzenetet kap: „Mostantól kezdve kérlek, küldd el Cayla minden levelét nekem" lehet, hogy egy pár kérdése lesz arról, hogy ki­ vel beszélt, és hogy ez vajon jó ötlet-e vagy sem. Számos mozgó hoszt kezelő proto­ kollt tárgyal és hasonlít össze (Hac és Guo, 2000; Perkins, 1998a; Snoeren és Balakrishnan, 2000; Solomon, 1998; valamint Wang és Chen, 2001) munkája. 5.2.10.

Forgalomirányítás ad hoc hálózatokban

Azt már láttuk, hogyan történik a forgalomirányítás, ha a hosztok mozognak,- de a routerek helyhez kötöttek. Ennél is szélsőségesebb eset az, ha maguk a routerek is mozognak. íme néhány példa:

A HÁLÓZATI RÉTEG

417

1. Katonai járművek egy harctéren, ahol nincs létező infrastruktúra. 2. Hajóflotta a tengeren. 3. Válságstáb egy földrengés sújtotta területen, ahol megsemmisült az infrastruktúra. 4. Hordozható számítógéppel rendelkező felhasználók csoportja egy olyan helyen, ahol nincs 802.11. Az ilyen esetekben minden csomópont egy routerből és egy hosztból áll, általában egyazon számítógépen belül. Az olyan csomópontokból álló hálózatot, amelyek vé­ letlenül éppen egymás közelében tartózkodnak, ad hoc hálózatnak vagy MANETnek (Mobile Ad hoc NETworks) hívjuk. Tekintsük át röviden most ezeket! További információkért lásd (Perkins, 2001) munkáját. Az ad hoc hálózatokat az különbözteti meg a vezetékes hálózatoktól, hogy ezeknél a rögzített topológiákra, rögzített és ismert szomszédokra, valamint az IP-címek és fi­ zikai elhelyezkedés közötti rögzített kapcsolatra vonatkozó jól bevált szabályainkat egyszeriben kidobhatjuk az ablakon. A routerek itt jöhetnek-mehetnek, és egyik pilla­ natról a másikra új helyeken bukkanhatnak fel. Ha egy routernek egy vezetékes háló­ zatban van egy érvényes útvonala valamely címzett irányába, az az útvonal a végte­ lenségig érvényes marad (eltekintve egy esetleges rendszerhibától). Egy ad hoc háló­ zatban a topológia állandóan változásban lehet, így az egyes utak kívánatossága, só't érvényessége is spontán, minden előzetes figyelmeztetés nélkül megváltozhat. Mon­ dani sem kell, hogy ezen körülmények miatt az ad hoc hálózatok forgalomirányítása teljesen eltér a fix, telepített hálózatokétól. Számos javaslat született már az ad hoc hálózatok forgalomirányító algoritmusaira. Az érdekesebbek egyike az Ad hoc igény szerinti távolságvektor (Ad hoc Ondemand Distance Vector, AODV) alapú algoritmus (Perkins és Royer, 1999). Ez a Bellman-Ford-féle távolságvektor algoritmus távoli rokona, amit hozzáigazítottak a mobil környezet sajátosságaihoz, figyelembe véve az ebben a környezetben jellemző­ en korlátozott sávszélességet és a szűkös akkumulátor-kapacitást. Az algoritmus to­ vábbi szokatlan tulajdonsága, hogy igény szerint működik, azaz csak akkor határoz meg egy utat valamely cél felé, amikor valaki ténylegesen el szeretne küldeni egy csomagot az adott célnak. Nézzük meg, mit is jelent ez!

Útvonal -felfedezés Egy ad hoc hálózatot bármely pillanatban leírhatunk a csomópontjai (routerek és hosztok) által meghatározott gráffal. Két csomópont akkor van összekötve (azaz él köti össze őket a gráfban), ha rádiós úton közvetlenül kommunikálni tudnak egymás­ sal. Mivel a két készülék közül az egyik erősebb adóval rendelkezhet, mint a másik, előfordulhat, hogy A-nak van összeköttetése 5-hez, de .B-nek nincsen A-hoz. Az egy­ szerűség kedvéért azonban tegyük fel, hogy minden összeköttetés szimmetrikus. Azt is meg kell jegyezni, hogy az a tény, hogy két csomópont egymás vételkörzetén belül

418

SZÁMÍTÓGÉP-HÁLÓZATOK

5.20. ábra. (a) A adáskörzete, (b) Miután B és D megkapták A üzenetét, (c) Miután C, F és G is megkapta A üzenetét, (d) Miután E, H és I is megkapta A üzenetét. A sötétített csomópontok az új vevők. A nyilak a lehetséges visszairányít útvonalakat jelzik.

van, még nem jelenti azt, hogy ténylegesen összeköttetésben is vannak - az épületek, dombok vagy más tereptárgyak akadályozhatják kommunikációjukat. Az algoritmus működését az 5.20. ábrán látható ad hoc hálózattal szemléltetjük, ahol az A csomópont egy folyamata csomagot szeretne küldeni az / csomópontba. Az AODV-algoritmus minden csomópontban karbantart egy táblázatot az egyes címzet­ tekre vonatkozó információkkal, például arról, hogy melyik csomópontnak kell kül­ deni a csomagokat az adott címzett eléréséhez. Tegyük fel, hogy A végignézi a táblá­ zatát, de nem talál benne /-re vonatkozó bejegyzést. Ekkor magának kell felfedeznie az /-be vezető útvonalat. Az utakat tehát csak akkor térképezik fel, amikor szükség van rájuk - ezen tulajdonsága miatt mondjuk az algoritmust „igény szerinti"-nek (on demand). Azért, hogy A megtalálja I-t, egy speciális ROUTE REQUEST (Útvonalkérelem) cso­ magot állít össze és kezd el sugározni. A csomag eléri B-t és D-t, ahogy azt az 5.20.(a) ábra mutatja. Mint tudjuk, B és D azért van a gráfon összekötve A-val, mert tudják venni A adását. Az F csomópont például nincs összekötve A-val, mert nem képes fog­ ni A rádiójelét. A ROUTE REQUEST csomag felépítését az 5.21. ábra mutatja. A csomag tartalmazza a forrás- és célcímeket (ezek jellemzően IP-címek), melyek azonosítják, hogy ki ki­ csodát keres. A csomag tartalmaz még egy Kérelem-azonosítót (Request ID), mely egy helyi számláló, amit minden csomópont karbantart és eggyel megnövel minden ROUTE REQUEST üzenet szétküldésekor. A Forráscím és a Kérelem-azonosító mezők együtt egyértelműen azonosítják a ROUTE REQUEST csomagot, így lehetővé teszik, hogy a csomópontok eldobják az esetlegesen vett másodpéldányokat.

Forráscím

Kérelem­ azonosító

Célcím

5.21. ábra. A ROUTE REQUEST csomag felépítése

Forrás sorszáma

Cél sorszáma

Ugrás­ számláló

A HÁLÓZATI RÉTEG

419

A Kérelemazonosító számlálóján felül minden csomópont fenntart egy második számlálót is, amit minden ROUTE REQUEST küldésekor (vagy valaki más ROUTE REQUEST üzenetére való válaszadáskor) eggyel megnövel. Ennek a számlálónak a működése egy kicsit az óra járására hasonlít, és arra használható, hogy megkülönböztessük az új utakat a régiektől. Az 5.21. ábrán látható negyedik mezó' az A sorszáma, az ötödik mezó" 7-nek az A által látott legfrissebb sorszáma (vagy 0, ha A még sosem látta 7-t). Hamarosan rá­ világítunk ezen mezők használatára. Az utolsó mező, az Ugrásszámláló tartja számon, hogy hány ugrást tett meg a csomag eddigi útja során. A mező kezdeti értéke 0. Ha egy ROUTE REQUEST csomag megérkezik egy csomóponthoz (ez esetben 7J-hez és ű-hez), a következő lépések szerint kerül feldolgozásra: 1. A vevő megnézi, hogy van-e a (Forráscím, Kérelem-azonosító) párost tartalmazó bejegyzése a helyi előzménytáblázatában, azaz hogy látta és feldolgozta-e már ko­ rábban ugyanezt az üzenetet. Ha az üzenet másodpéldánynak bizonyul, eldobják és a feldolgozás véget ér. Ha nem, a csomópont az új azonosító-párost beírja az előz­ ménytáblázatba, hogy a későbbi másodpéldányokat kiszűrhesse, és a feldolgozás folytatódik. 2. A vevő kikeresi a címzettet a forgalomirányító táblázatából. Ha van ismert, friss út a címzett felé, egy ROUTE REPLY (Útvonalválasz) csomagot küld vissza a forráshoz, hogy közölje vele, hogyan juthat el a céljához (alapvetően: „Használj engem!"). A „friss" azt jelenti, hogy a forgalomirányító táblázatban tárolt Cél sorszáma érték nagyobb vagy egyenlő a ROUTE REQUEST csomagban talált Cél sorszáma mező ér­ tékénél. Ha kisebb, akkor a tárolt útvonal régebbi, mint a forrás által előzőleg is­ mert út, így a 3. lépés kerül végrehajtásra. 3. Mivel a vevő nem ismer friss utat a cél felé, megnöveli az Ugrásszámláló mező értékét eggyel, és újra szétküldi a ROUTE REQUEST csomagot. Magát a csomag tar­ talmát egyúttal tárolja egy új bejegyzésként a visszairányú útvonaltáblázatában. Ezen információ segítségével fogja majd a visszafelé vezető útvonalat felépíteni, hogy a későbbiekben a válasz visszaérhessen a forráshoz. Az 5.20. ábrán a nyilak jelzik a visszaút felépítésének folyamatát. Az újonnan létrehozott visszaútbejegyzéshez elindul egy időzítő is, melynek lejártakor a bejegyzés törlődik. Sem B, sem D nem tudja, hol van 7, így mindkettő létrehoz egy, az A-ra visszamu­ tató visszaut-bejegyzést, ahogy azt az 5.20. ábra nyilai mutatják, és az Ugrásszámlálót l-re állítva újra szétküldik a csomagot. B adása eléri C-t és D-t. C e kérelem számára létrehoz egy új bejegyzést a visszaúttáblázatában, majd újra szétküldi azt, míg D el­ dobja, mint másodpéldányt. Hasonlóképp utasítja vissza B is D adását. Ugyanakkor D adását F és G elfogadja és tárolja, ahogy azt az 5.20.(c) ábra mutatja. Amikor E, H és 7 is vették az adást, a ROUTE REQUEST végre elér egy olyan csomópontot, amelyik tudja, hol van 7 - ez a pont történetesen az 7 maga, amint azt az 5.20.(d) ábra mutatja. Vegyük észre, hogy bár a csomagok szétküldését itt három különálló lépésben mutattuk be, a különböző csomópontok adásai általános esetben semmilyen módon nincsenek koordinálva.

420

SZÁMÍTÓGÉP-HÁLÓZATOK

Forráscím

Célcím

Cél sorszáma

Ugrás­ számláló

Élettartam

5.22. ábra. A ROUTE REPLY csomag felépítése Az 7 csomópont a beérkezett kérelemre válaszul egy ROUTE REPLY (Útvonalválasz) csomagot állít össze, az 5.22. ábrának megfelelően. A Forráscím, Célcím és Ugrás­ számláló mezők a kérelemből vannak kimásolva, de a Cél sorszáma már az 7 memóri­ ájában lévő számlálóból származik. Az Ugrásszámláló 0-t kap értékül. Az Élettartam mező határozza meg az útvonal érvényességének idejét. A válaszcsomagot közvetle­ nül ahhoz a csomóponthoz juttatják vissza, ahonnan a ROUTE REQUEST csomag érke­ zett, ez ebben az esetben a G. Innen a válasz a visszaút mentén D-be, majd végül A-ba jut. Az Ugrásszámlálót minden csomópontban megnövelik eggyel, így A megtudja, milyen távol van tőle a címzett, 7. A válaszcsomagot minden közbeeső csomópont megvizsgálja a visszaúton. A cso­ mag tartalma bekerül az adott csomópont helyi forgalomirányító táblázatába, mint egy 7 felé vezető út, ha a következő feltételek közül legalább egy teljesül: 1. Ismert, 7-be tartó út nincs. 2. 7 sorszáma a ROUTE REPLY csomagban nagyobb, mint a táblázatban szereplő érték. 3. A sorszámok megegyeznek, de az új útvonal rövidebb. Ezáltal a visszaút mentén lévő összes csomópont ingyen, mintegy A útvonal­ felfedezésének melléktermékeként, megtudja az 7-be vezető utat. Azok a csomópon­ tok pedig, amelyek megkapták az eredeti ROUTE REQUEST csomagot, de nincsenek rajta a visszaúton (B, C, E, F és H ebben a példában), a megfelelő időzítő lejártával kitörlik a visszaútra vonatkozó bejegyzésüket a táblázatukból. Egy nagyméretű hálózatban az algoritmus sok csomagot generál, még közeli célok esetén is. A csomagok számát azonban lehet csökkenteni. Az IP-csomag Élettartam mezejét a feladó a hálózat becsült átmérőjének értékére állíthatja, az pedig minden ug­ rásnál egyet csökken. Ha eléri a nullát, a csomagot eldobják, ahelyett hogy továbbadnák. A felfedezés folyamatát ez a következőképp módosítja. A címzett keresésekor a feladó a ROUTE REQUEST csomag Élettartamát l-re állítja. Ha belátható időn belül nem érkezik válasz, egy újabb kérelem kerül elküldésre, 2-es Élettartammal. Az ezt követő kísérletekben pedig 3, 4, 5 stb. kerül az Élettartam mezőbe. A feladó így először lokáli­ san, később pedig egyre nagyobb sugarú körökben kísérelheti meg a keresést.

Útvonal -karbantartás Mivel a csomópontok mozoghatnak, illetve ki is kapcsolhatják őket, a topológia vá­ ratlanul megváltozhat. Az 5.20. ábrán lévő példánkban, ha G-t kikapcsolják, A nem fogja észrevenni, hogy az 7-hez eddig használt útvonala (ADG1) már nem érvényes.

421

A HÁLÓZATI RÉTEG

Az algoritmusnak ezzel is meg kell birkóznia. Ennek érdekében minden csomópont periodikusan szétküld egy Hello üzenetet. Erre minden szomszédnak válaszolnia kell. Ha valahonnan nem jött üzenet, a feladó tudja, hogy az adott szomszédja elhagyta az adáskörzetét és már nincs vele összeköttetésben. Hasonlóképp, abból, hogy megpróbál elküldeni egy csomagot egy szomszédnak, és az nem válaszol, megtudhatja, hogy a szomszédja többé nem elérhető'. Ezzel az információval megszabadulhatunk azoktól az utaktól, amelyek már nem működnek. Minden N csomópont minden lehetséges címzetthez nyilvántartja azon szomszédait, melyek az elmúlt AT idő során csomagot továbbítottak neki az adott címzetthez. Ezeket hívjuk az N adott célra vonatkozó aktív szomszédainak (active neighbors). N a forgalomirányító táblázatában minden címzetthez nyilvántartja a címzett felé használandó kimeneti csomópontot, a címzett ugrásokban mért távolsá­ gát, a legfrissebb cél sorszámot, és a címzetthez tartozó aktív szomszédok listáját. A példánkban szereplő topológiában D egy lehetséges forgalomirányító táblázatát az 5.23. ábra mutatja. Ha bármely szomszédja elérhetetlenné válik, N megvizsgálja forgalomirányító táblázatában, hogy mely címzettekhez vezet út az imént távozott szomszédon keresz­ tül. Minden ilyen útvonal esetében közölni kell az aktív szomszédokkal, hogy az N-en át vezető útvonaluk immár érvénytelen és törlendő a forgalomirányító táblázatból. Az aktív szomszédok értesítik a saját aktív szomszédjaikat, és így tovább, míg rekurzív módon az összes, az imént távozott csomóponttól függő útvonal kikerül az összes for­ galomirányító táblázatból. Az útvonal-karbantartás illusztrációjaként tekintsük az előző példánkat, annyi kü­ lönbséggel, hogy G-t most hirtelen lekapcsoltuk. A megváltozott topológiát az 5.23.(b) ábra szemlélteti. Amikor D felfedezi, hogy G eltűnt, megnézi a forgalomirá­ nyító táblázatát, és azt találja, hogy G-t használta az E, G és / felé vezető útvonalakon. Az ezen címzettekhez tartozó aktív szomszédok uniója az {A, fi} halmaz. Más szóval, A és fi bizonyos útvonalai G-től függenek, így őket értesíteni kell arról, hogy ezek az utak már nem működnek. D ezt meg is teszi, amikor olyan csomagokat küld nekik, melyek hatására ezen csomópontok megfelelő módon frissíthetik forgalomirányító

Címzett A B C E F G H 1

Következő Távolság Aktív ugrás szomszédok 1 F, G A 1 F, G B F 2 B 2 G A, B 1 F A, B 1 G A, B 2 F A, B 2 G (a)

Egyéb mezők

(b)

5.23. ábra. (a) D forgalomirányító táblázata G kikapcsolása előtt, (b) A gráfG kikapcsolása után.

422

SZÁMÍTÓGÉP-HÁLÓZATOK

táblázatukat. D végül maga is kitörli az £-re, G-re és /-re vonatkozó bejegyzéseket saját táblázatából. Az előzőkből talán még nem látszik elég világosan, de az AODV- és a BellmanFord-algoritmus közti legfontosabb különbség az, hogy az előbbinél a csomópontok nem küldik szét periodikus üzenetekben a teljes forgalomirányító táblájukat. Ezzel sávszélességet és akkumulátor-kapacitást is meg lehet takarítani. Az AODV adatszóró és többesküldéses forgalomirányításra is képes. A részleteket lásd (Perkins és Royer, 2001). Az ad hoc forgalomirányítás nagyon izgalmas kutatási terület, és máris rengeteg cikk született a témában. Ezek közül néhány: (Chen és má­ sok, 2002; Hu és Johnson, 2001; Li és mások, 2001; Raju és Garcia-Luna-Aceves, 2001; Ramanathan és Redi, 2002; Royer és Toh, 1999; Spohn és Garcia-Luna-Aceves, 2001; Tseng és mások, 2001; valamint Zadeh és mások, 2002).

5.2.11.

Csomópontkeresés egyenrangú (peer-to-peer) hálózatokban

Az egyenrangú hálózatok viszonylag új jelenségnek számítanak. Ezekben sok, rend­ szerint állandó vezetékes internetkapcsolattal rendelkező felhasználó lép kapcsolatba egymással, hogy megosszák erőforrásaikat. Az egyenrangú technológia első, széles körben elterjedt alkalmazása a tömeges bűnözést szolgálta: általa 50 millió Napsterfelhasználó csereberélt a jogtulajdonosok engedélye nélkül szerzői jogvédelem alá eső zeneszámokat, míg végül a bíróság nagy viták közepette be nem szüntette a Napstert. Az egyenrangú hálózati technológiának azonban számos érdekes és legális alkalmazá­ sa is van. A technológia egy, a forgalomirányítás kérdéséhez hasonló problémát is fel­ vet, és bár ez némileg eltér az általunk eddig tanulmányozottaktól, azért érdemes egy pillantást vetnünk rá. Az egyenrangú hálózatokat az teszi érdekessé, hogy teljesen elosztottak. Minden csomópont egyenértékű, nincs központi vezérlés vagy hierarchia. A tipikus egyenran­ gú hálózatokban mindegyik felhasználónak van olyan információja, ami a többieket érdekelheti. Ez lehet ingyenes szoftver, (szabadon terjeszthető) zene, fényképek és így tovább. Ám ha nagyon sok felhasználónk van, ezek nem fognak tudni egymásról, és nem fogják tudni, hol találják meg azt, amit keresnek. Erre az egyik megoldás egy nagy központi adatbázis lenne, de ez bizonyos okokból nem mindig megvalósítható (pl. senki nem hajlandó üzemeltetni és karbantartani). így a kérdés arra összpontosul, hogy hogyan találhatja meg a felhasználó a keresett információt tartalmazó csomó­ pontot, ha nincs központi adatbázis, sőt központi katalógus sem. Tegyük fel, hogy minden felhasználónak van valamilyen adategysége, pl. egy zene­ szám, fénykép, program, állomány stb., amire esetleg más felhasználók is kíváncsiak lehet­ nek. Minden adategységet egy ASCII karakterlánc nevez meg. A potenciális felhasználók csak ezt az ASCII karakterláncot ismerik, és szeretnék megtudni, hogy vannak-e olyan em­ berek, akik rendelkeznek ilyen példánnyal, és ha igen, akkor mi az IP-címük. Példának okáért tekintsünk egy elosztott származástani adatbázist. Minden szárma­ záskutatónak van néhány on-line feljegyzése a saját őseiről és rokonairól, esetleg fényképekkel, hang-, sőt videofelvételekkel együtt. Több embernek lehet pl. közös dédapja, így egy ősről több csomópontban is lehetnek feljegyzések. A feljegyzés neve

A HÁLÓZATI RÉTEG

423

lehet a személy neve, valamilyen kanonikus formában. Tegyük fel, hogy egy szárma­ záskutató egyszer csak rábukkan saját dédapjára egy archívumban, és azt olvassa, hogy dédapja az unokaöccsére hagyta az arany zsebóráját. Miután így megtudta az unokaöcs nevét, a származáskutató szeretné megtudni, hogy vajon más kutatóknak van-e feljegyzésük róla. A kérdés az, hogy központi adatbázis nélkül hogyan lehetsé­ ges kitalálni, hogy - ha egyáltalán létezik - kinek van ilyen feljegyzése. Számos algoritmust javasoltak már a probléma megoldására. Mi most a Chord (Húr) algoritmust (Dabek és mások, 2001a; valamint Stoica és mások, 2001) fogjuk megvizsgálni. Ennek működése némileg leegyszerűsítve a következő. A Chordrendszer n felhasználóból áll, melyek közül mindegyik néhány állományt tárol, és mindannyian készek a katalógus apróbb részeit tárolni, hogy azt mások is használhas­ sák. Minden felhasználói csomópont rendelkezik egy IP-címmel, amiből a hash nevű hash-függvény segítségével egy m-bites szám képezhető. A Chord az SHA-l-et hasz­ nálja hash-ként Az SHA-1 eredetileg a kriptográfiában használatos, és bővebben a 8. fejezetben tárgyaljuk. Egyelőre legyen csak egy függvény, mely egy változó hosszú­ ságú bájtfüzért kap paraméterül, és előállít belőle egy erősen véletlenszerű 160 bites számot. Ily módon minden IP-címet 160 bites számmá alakíthatunk, amelyet csomó­ pont-azonosítónak (node identifíer) nevezünk. Elviekben mind a 2160 azonosító elrendezhető növekvő sorrendben egy nagy kör men­ tén. Néhányuk megfeleltethető résztvevő csomópontnak, de a legtöbbjük nem. Az 5.24.(a) ábrában megmutatjuk az azonosítók körét az m - 5 esetre (egyelőre hagyjuk figyelmen kí­ vül a körben lévő húrokat). Ebben a példában az 1, 4, 7, 12, 15, 20 és 27 azonosítójú, söté­ tített karikák felelnek meg tényleges csomópontoknak; a többiek nem léteznek. Definiáljuk most a következőik) függvényt, mint a körben az óramutató járása sze­ rint k-i követő első létező csomópont azonosítóját. Például következőig) = 7, következői8) = 12, és következői!!) - 27. Az állományok neveiből (zeneszámok címei, ősök nevei stb.) szintén a hash (azaz az SHA-1) segítségével egy 160 bites számot állítunk elő, ez lesz a kulcs (key). Va­ gyis ahhoz, hogy egy névből (az állomány ASCII-nevéből) kulcsot kapjunk, a kulcs = hash(név) összefüggést alkalmazzuk. Ez a számítás csak egy, a hash-re vonatkozó helyi eljáráshívás. Ha egy személy egy adott névre vonatkozó származástani feljegy­ zést mindenki száméra hozzáférhetővé szeretne tenni, először összeállít egy inév, sa­ ját IP-cím) párost, majd megkéri a következőihashinév))-nek megfelelő csomópontot, hogy tárolja a párost. Ha (különböző csomópontokban) több állomány is létezik ugyanahhoz a névhez, akkor ezek párosait ugyanaz a csomópont fogja tárolni. Ily mó­ don a katalógus véletlenszerűen lesz szétosztva a csomópontok között. A hibatűrőség érdekében p darab különböző hash-függvényt is használhatnánk, hogy minden párost p számú csomópontban tároljunk, de a továbbiakban nem tárgyaljuk ezt a lehetőséget. Ha egy felhasználó később rá akar keresni egy adott névre, a hash-sel előállítja a kulcsot és a következőikulcs) összefüggéssel megtalálja annak a csomópontnak az IPcímét, mely a keresett katalóguspárosokat tárolja. Az első lépés könnyű; a második már nem az. Ahhoz, hogy egy bizonyos kulcshoz tartozó csomópont IP-címét meg­ kaphassuk, minden csomópontnak fenn kell tartania bizonyos adminisztratív adatszer­ kezeteket. Ezek egyike a körben következő csomópont IP-címe. Az 5.24. ábrában pél­ dául a 4. csomópont után a 7., míg a 7. után a 12. csomópont következik.

424

SZÁMÍTÓGÉP-HÁLÓZATOK

..--, (31) •30.; --•

(°.)

Tényleges csomópontt ^ (26;

Í25) •

-

•

•

\

Csomópont­ azonosító

ig; {23; (22) Í2Í

(18) ,--, ..... '-" V1.7J (16)

A. Qj)

(14) •--

(a) Követő Start IP-címe

2 3 5 9 17

4 4 7 12 20

Az 1. csomópont finger-táblázata

Követő Start IP-címe

7 7 12 12 20

5 6 8 12 20

A 4. csomópont finger-táblázata

Követő Start IP-címe

13 14 16 20 28

15 15 20 20 1

A 12. csomópont finger-táblázata

(b)

5.24. ábra. (a) 32 csomópont-azonosítóból álló halmaz, körbe rendezve. A sötét karikák tényleges gépeknek felelnek meg. Az ívek az l-es, 4-es és 12-es csomópontokból induló fingereket mutatják, (b) Példák afinger-táblázatokra A keresés a következők szerint folytatódhat. A kezdeményező csomópont elküld egy csomagot a sorban utána következőnek, mely tartalmazza a saját IP-címét és a ke­ resett kulcsot. A csomag körbehalad a gyűrűn, amíg meg nem találja a keresett cso­ mópont-azonosító követőjét. Ez a csomópont megvizsgálja, hogy van-e a keresett kulcsra vonatkozó információja. Ha van, közvetlenül visszajuttatja azt a kezdeménye­ ző csomóponthoz, aminek az IP-címét már ismeri.

A HÁLÓZATI RÉTEG

425

A tökéletesítés első lépéseként minden csomópont eltárolhatná mind az őt követő, mind az őt megelőző csomópont IP-címét. így a kéréseket az óramutató járásával megegyező vagy ellenkező irányban is el lehet indítani, attól függően, hogy melyik utat véljük rövidebbnek. Például, az 5.24. ábrán a 7. csomópont az óramutató járása szerint haladva keresné a 10. csomópontot, de ellenkező irányban a 3.-at. Az összes csomópont közti lineáris keresés azonban még két irányban is igen ke­ véssé hatékony, ha az egyenrangú rendszer elég nagy, mivel a keresésnél érintett pontok átlagos száma n/2. A jóval gyorsabb keresés érdekében ezért minden csomó­ pont karbantart egy úgynevezett finger-táblázatot (finger table). A táblázatnak m bejegyzése van, 0-tól m - l-ig indexelve, és mindegyik különböző, tényleges csomó­ pontra mutat. A bejegyzéseknek két mezőjük van: start és a következó\start) csomó­ pont IP-címe, ahogy azt az 5.24.(b) ábra példája mutatja három csomópontra. A k. csomópontban lévő i. bejegyzés mezőinek értéke: start — k + 2' (modulo 2m) a következő(start[í\) csomópont IP-címe Figyeljük meg, hogy minden csomópont viszonylag kevés másik csomópont IPcímét tárolja, és hogy ezek többsége a csomópont-azonosítót tekintve elég közelinek mondható. A finger-táblázat segítségével a k. csomópontban lévő kulcsot a következőképp ta­ lálhatjuk meg. Ha a kulcsa kés a következó\k) közé esik, akkor a kulcstól információt tároló csomópont a következőik), és a keresés véget ért. Ellenkező esetben megkeres­ sük a finger-táblázatban azt a bejegyzést, melynek a start mezője a kulcs legközelebbi elődje. A keresési kérést ekkor közvetlenül az ebben a bejegyzésben található IPcímre küldjük azzal, hogy folytassa az a keresést. Mivel e csomópont már közelebb van a kulcshoz, de még mindig alatta van, jó az esélye annak, hogy képes lesz vissza­ térni a válasszal legfeljebb néhány további kérdés után. Valójában minden keresés megfelezi a célig hátralévő távolságot, így megmutatható, hogy a keresések átlagos száma log2«. Első példaként keressünk rá a kulcs = 3 értékre az 1. csomópontban. Mivel az 1. csomópont látja, hogy a 3. közte és a követője, a 4. között van, a keresett csomópont a 4. Ezzel a keresés befejeződik, és visszatér a 4. csomópont IP-címével. Második példaként keressük meg a kulcs - 14 értéket az 1. csomópontban. Mivel a 14. nem esik 1. és 4. közé, meg kell nézni a finger-táblázatot. A 14. legközelebbi elődje 9., így a kérést a 9. bejegyzéshez tartozó IP-címre küldjük, ami történetesen a 12. csomópont címe. A 12. csomópont látja, hogy a 14. és a követője (15) közé esik, így visszatér a 15. csomópont IP-címével. Harmadik példaként keressük a kulcs =16 értéket az 1. csomópontban. Ismét a 12. csomóponthoz kerül a kérés, de ő ezúttal nem tudja megadni magától a választ. Meg­ keresi tehát, hogy melyik a legközelebbi, 16.-at megelőző csomópont, és megtalálja a 14. bejegyzést, ami a 15. csomópont IP-címét rejti. A kérést ide továbbítják. A 15. csomópont azt látja, hogy a 16. közé és az ő követője (a 20) közé esik, így visszaküldi a 20. csomópont IP-címét a hívónak, aki továbbküldi azt az 1. csomópontnak. Mivel a csomópontok bármikor bekapcsolódhatnak és távozhatnak is, a Chord-

426

SZÁMÍTÓGÉP-HÁLÓZATOK

algoritmusnak valahogy ezeket a műveleteket is kezelnie kell. Feltesszük, hogy a rendszer a működése kezdetén még elég kicsi volt ahhoz, hogy a csomópontok köz­ vetlenül információt cserélhessenek egymással, hogy felépítsék az első" kört és a finger-táblázatokat. Ezt követően a következő önműködő folyamat szükséges az ad­ minisztrációhoz. Amikor egy új csomópont, r, csatlakozni akar, fel kell vennie a kap­ csolatot egy létező csomóponttal és meg kell kérnie, hogy keresse meg számára a kö~ vetkező{r) IP-címét. Az új csomópont ezután megkérdi következő{r)-X, hogy ki az ő elődje, majd mindkettejüket arra kéri, hogy illesszék be őt maguk közé a körbe. Pél­ dául, ha az 5.24. ábrán a 24. csomópont csatlakozni akar, akkor megkéri valamelyik csomópontot, hogy keresse meg neki következó'(24)-et, ami 27. Ekkor megkérdi 27.et, hogy ki az ő elődje (20.). Végül mindkettejüket értesíti létezéséről, így a 20. a 24.et követőjének fogja tekinteni, míg a 27. az elődjének. Ezen felül a 27. csomópont át­ adja az új tagnak a 21. és 24. közé eső kulcsokat, melyek ezentúl hozzá fognak tartoz­ ni. Ezzel a csatlakozás lezárult. Eközben azonban számos finger-táblázat érvénytelenné vált. Hogy ezt a hibát kija­ vítsák, minden csomópont futtat egy folyamatot a háttérben, mely időről időre meg­ hívja a következő függvényt és újraszámol minden fingért. Ha ezen keresések közül valamelyik új csomópontra bukkan, a megfelelő finger-bejegyzést frissítik. Amikor egy csomópont szabályszerűen hagyja el a hálózatot, átadja kulcsait a kö­ vetőjének, majd értesíti az elődjét a távozásáról, hogy az kapcsolódhasson a távozó követőjéhez. Ha azonban a csomópont váratlanul összeomlik, baj van, hiszen az elődjének nem lesz érvényes követője. Hogy kiküszöböljék ezt a problémát, a csomó­ pontok nemcsak egy, hanem s darab közvetlen követőt tartanak számon, így akár s-l egymás után meghibásodott csomópontot is kihagyva még mindig képesek újraegye­ síteni a kört. A Chord-algoritmus segítségével készítettek már elosztott fájlrendszert (Dabek és mások, 2001b) és más alkalmazásokat is, és a kutatás tovább folytatódik. Egy másik egyenrangú rendszer, a Pastry-t (Tészta) és alkalmazásait írja le (Rowston és Druschel, 2001a; valamint Rowston és Druschel, 2001b). A Freenet egy további egyenrangú rendszer, melyet (Clarké és mások, 2002) tárgyal. Egy negyedik példát is leír (Ratnasamy és mások, 2001) munkája.

5.3.

Torlódásvédelmi algoritmusok

Amikor túl sok csomag van jelen az alhálózatban (vagy egy részében), a teljesítőké­ pesség visszaesik. Ezt a helyzetet torlódásnak (congestion) nevezzük. Az 5.25. ábra festi le a tüneteket. Amikor a hosztok által az alhálózatba beadott csomagok száma a szállítási kapacitáson belül marad, akkor mind kézbesítésre kerül (kivéve egy párat, amely átvitel során hibákat szenvedett), és a kézbesítettek száma arányos az elküldöt­ tek számával. Ahogy azonban a forgalom túl nagyra nő, a routerek már nem képesek ezt a forgalmat követni, és csomagokat kezdenek elveszteni. Ez általában tovább rontja a helyzetet. Nagyon nagy forgalomnál a teljesítőképesség teljesen összeomlik, és szinte egy csomag sem kerül kézbesítésre.

A HÁLÓZATI RÉTEG

427

-Tökéletes

Elküldött csomagok 5.25. ábra. Amikor túl nagy forgalmat követelünk, bekövetkezik a torlódás, és a teljesítőképesség meredeken visszaesik

A torlódást sok tényező okozhatja. Ha hirtelen nagy mennyiségű csomag kezd ér­ kezni három vagy négy bejövő vonalon, és mindnek ugyanarra a kimenő vonalra van szüksége, egy várakozó sor fog felépülni. Ha a memória kevés ahhoz, hogy mindet befogadja, akkor csomagok fognak elveszni. Több memória hozzáadása egy adott pontig segíthet, de Nagle (1987) kimutatta, hogy ha a routereknek végtelen kapacitású memóriája van, a torlódás nem javul, hanem rosszabbá válik, mivel mire a csomagok a sor elejére kerülnek, az időzítésük már (többször is) lejárt, és így már másodpéldá­ nyok is továbbításra kerültek. A router mindezeket a csomagokat kötelességtudóan to­ vábbítja a következő routerhez, megnövelvén a terhelést a rendeltetési helyig vezető út mentén. A lassú processzorok is okozhatnak torlódást. Ha a routerek CPU-ja lassú a megkö­ vetelt könyvelési feladatok (pufferek sorba állítása, táblák frissítése stb.) elvégzésé­ hez, sorok képződhetnek, még ha van is fölös vonalkapacitás. Hasonlóan, a kis sáv­ szélességű vonalak is okozhatnak torlódást. A vonalak kapacitásának növelése és a pro­ cesszorok meghagyása, vagy a vonali kapacitás megtartása és a processzor megváltozta­ tása, gyakran javít a helyzeten, de sokszor csak a szűk keresztmetszetet helyezi át. A rendszer egy részét, de nem az egészét javítva, szintén sokszor csak a szűk keresztmet­ szetet helyezi máshova. A valódi probléma gyakran az, hogy a rendszer részei nem ille­ nek össze. A probléma mindaddig megmarad, amíg a részek egyensúlyba nem kerülnek. A torlódás hajlamos arra, hogy önmagát gerjessze és rosszabbodjon. Ha egy routernek nincs szabad puffere, az újonnan érkező csomagokat el kell dobja. Amikor egy csomag eldobásra kerül, az azt elküldő routernek (egy szomszédnak) lejárhat az időzí­ tése, és a csomagot esetleg végtelen sokszor újraadhatja. Mivel nem dobhatja el a csomagot, amíg azt nem nyugtázták, a vevő oldali torlódás arra kényszeríti az adót, hogy ne szabadítsa fel a puffert, amit különben megtenne. Ily módon a torlódás viszszafelé terjed, mint ahogy ez a fizetőkapu felé közeledő autóknál is tapasztalható. Érdemes kifejezetten rámutatni a különbségre a torlódásvédelem és a forgalomsza­ bályozás közt, mivel a kapcsolatuk nem magától értetődő. A torlódásvédelem azzal foglalkozik, hogy az alhálózat képes legyen elszállítani a kért forgalmat. Ez egy átfo­ gó, globális kérdés, amely magába foglalja minden hoszt, minden router viselkedését,

428

SZÁMÍTÓGÉP-HÁLÓZATOK

a tárol-és-továbbít feldolgozást a routereken belül, és minden más tényezőt, amely hajlamos lerontani az alhálózat szállítási képességeit. Ezzel szemben a forgalomszabályozás egy adott adó és egy adott vevő közti két­ pontos forgalomra vonatkozik. Feladata megakadályozni, hogy egy gyors adó folya­ matosan gyorsabban adjon, mint ahogy a vevő ezt fogadni tudja. A forgalomszabályo­ zás majdnem mindig magába foglal egy közvetlen visszacsatolást a vevőtől az adóig, hogy megmondja az adónak, miképp állnak a dolgok a túlvégen. Hogy lássuk a két fogalom közti különbséget, vegyünk egy 1000 gigabit/s kapaci­ tású üvegszálas optikai hálózatot, amelyen egy szuperszámítógép próbál egy fájlt át­ vinni egy személyi számítógépre 1 Gb/s-mal. Bár nmcsen torlódás (maga a hálózat nincs bajban), forgalomszabályozásra van szükség, hogy a szuperszámítógépet gyako­ ri megállásra kényszerítsük, lélegzethez juttatva ezzel a személyi számítógépet. A másik végletként vegyünk egy tárol-és-továbbít hálózatot 1 Mb/s-os vonalakkal és 1000 nagy számítógéppel, amelyek fele fájlokat próbál átvinni 100 kb/s-mal a má­ sik feléhez. Itt a probléma nem az, hogy a gyors adók elnyomják a lassú vevőket, ha­ nem egyszerűen az, hogy az összes kívánt forgalom meghaladja azt, amit a hálózat ke­ zelni képes. Az ok, amiért a torlódásvédelmet és a forgalomszabályozást gyakran összekeverik az, hogy néhány torlódásvédelmi algoritmus működés közben üzeneteket küld vissza bizonyos forrásoknak, utasítva őket, hogy lassítsanak, amikor a hálózat bajba kerül. Ezért egy hoszt kaphat „lassíts" üzenetet azért is, mert a vevő nem tudja kezelni a ter­ helést, vagy azért is, mert a hálózat nem bír vele. Erre a gondolatra később még viszszatérünk. A torlódásvédelem tanulmányozását először egy, a kezelésére szolgáló általános modell szemrevételével kezdjük. Ezután sokfajta megközelítést fogunk látni a torlódás megelőzésére, majd változatos dinamikus algoritmusokat, a torlódás bekövetkezése utáni helyzet lekezelésére.

5.3.1.

A torlódásvédelem alapelvei

A komplex rendszerek, mint például a számítógép-hálózatok sok problémája megvizs­ gálható szabályozáselméleti szempontból. Ez a megközelítés a megoldásokat két cso­ portra osztja: nyílthurkú (open loop) és zárthurkú (closed loop) megoldásokra. A nyílthurkú megoldások a problémát jó tervezéssel kísérlik meg megoldani, más sza­ vakkal, eleve nem engedik a torlódást kialakulni. Miután a rendszer életre kelt, nem végeznek futás közben korrekciókat. A nyílthurkú szabályozás eszközei közé tartoznak azok a döntések, hogy mikor fo­ gadunk el új forgalmat, mikor dobunk el csomagokat és melyeket, valamint az üteme­ zési döntések a hálózat különböző pontjain. Mindezekben közös, hogy a döntéseket a hálózat aktuális állapotától függetlenül hozzák. Ezzel ellentétben, a zárthurkú rendszerek a visszacsatolt kör elvén alapulnak. En­ nek a megközelítésnek három része van, ha torlódásvédelemre alkalmazzuk: 1. Figyelni a rendszert, hogy észrevegyük, hol és mikor következik be torlódás.

A HÁLÓZATI RÉTEG

429

2. Továbbadni ezt az információt azokra a helyekre, ahol be lehet avatkozni. 3. Módosítani a rendszer működését, hogy helyrehozzuk a problémát. Különböző mértékegységek alapján mérhetjük az alhálózatban a torlódást. Ezek közül a legfontosabbak a pufferhiány miatt eldobott csomagok százalékos aránya, az átlagos sorhosszak, a lejárt időzítésű és újraaüott csomagok, az átlagos csomagkéslel­ tetés, és a csomagkésleltetés szórása. Minden esetben a növekvő számok súlyosbodó torlódást jeleznek. A visszacsatolt kör második lépése az információ továbbítása az észlelés helyétől oda, ahol valamit tudunk tenni ellene. Ennek a nyilvánvaló módja az, hogy a torlódást észlelő router egy csomagot küld a forgalom forrásához vagy forrásaihoz, bejelentve a problémát. Természetesen ezek a csomagok pont abban a pillanatban növelik a terhe­ lést, amikor erre a legkevésbé van szükség, nevezetesen, amikor az alhálózatban amúgy is torlódás van. Léteznek azonban más lehetőségek is. Például fenntarthatunk minden csomagban egy bitet vagy egy mezőt, amelyet a routerek kitölfhetnek, amikor a torlódás valami­ lyen küszöbszint fölé emelkedik. Amikor egy router érzékeli ezt a torlódott állapotot, minden kimenő csomagban kitölti ezt a mezőt, hogy figyelmeztesse a szomszédokat a veszélyre. Megint egy másik megközelítés az, hogy a hosztok vagy a routerek küldjenek ki rendszeresen próbacsomagokat, amelyek rákérdeznek a torlódásra. Ezt az információt arra lehet azután használni, hogy a problémás területeket megkerülve irányítsuk a for­ galmat. Néhány rádióállomás helikoptert alkalmaz a városi forgalom figyelésére, ab­ ban a reményben, hogy a hallgatók az autóikkal a torlódások helyét elkerülik. Minden visszacsatolást tartalmazó megoldás azon a reményen alapul, hogy a torló­ dás tudata ráveszi a hosztokat arra, hogy megfelelő lépéseket tegyenek a torlódás csökkentése érdekében. Ahhoz, hogy ez helyesen működjön, az időléptéket gondosan be kell állítani. Ha egy router ÁLLJ-t kiált, valahányszor két csomag érkezik egymás után, és INDULJ-t, amikor 20 us-ig tétlen, a rendszer vadul ingadozni fog és soha nem konvergál. Másfelől, ha a biztonság kedvéért 30 percet vár, mielőtt bármit is mondana, a torlódásvédelmi algoritmus túl lassan fog reagálni ahhoz, hogy bármilyen valódi haszna legyen. Ahhoz, hogy jól működjön, valamilyen átlagolás szükséges, de az időállandó helyes beállítása korántsem magától értetődő feladat. Sok torlódásvédelmi algoritmus ismeretes. Hogy értelmes módon lehessen ezeket rendszerezni, Yang és Reddy (1995) kifejlesztettek egy rendszertant a torlódásvédelmi algoritmusokhoz. Azzal kezdik, hogy az algoritmusokat nyílt- és zárthurkúakra bont­ ják, ahogy fentebb leírtuk. A nyílthurkú algoritmusokat tovább osztják a forrásnál be­ avatkozókra és a célnál beavatkozókra. A zárthurkú algoritmusokat szintén két alkate­ góriára bontják: explicit visszajelzésesre és implicit visszajelzésesre. Az explicit viszszajelzéses algoritmusokban csomagokat küldenek vissza a torlódás helyéről, hogy fi­ gyelmeztessék a forrást. Az implicit algoritmusokban a forrás kikövetkezteti a torló­ dás létezését helyi megfigyelésekből, mint amilyen a nyugták visszaérkezéséhez szük­ séges idő. A torlódás megléte azt jelenti, hogy a terhelés (ideiglenesen) nagyobb, mint amit az

430

SZÁMÍTÓGÉP-HÁLÓZATOK

erőforrások (a rendszer egy részében) kezelni képesek. Két megoldás juthat eszünkbe: növelni az erőforrásokat, vagy csökkenteni a terhelést. Az alhálózat például elkezdhet telefonvonalakat használni, hogy ideiglenesen megnövelje a sávszélességet bizonyos pontok közt. Műholdas rendszerekben gyakran az átviteli teljesítmény megnövelése is nagyobb sávszélességet ad. Ha a forgalmat megosztjuk több útvonal között ahelyett, hogy mindig a legjobb (optimális) útvonalat használnánk, azzal szintén hatékonyan megnövelhetjük a sávszélességet. Végül a tartalék routereket is üzembe lehet helyez­ ni, melyek egyébként csak vésztartalékul szolgálnak (hogy a rendszert hibatűrővé te­ gyék), hogy nagyobb kapacitást biztosítsanak egy súlyosabb torlódás esetén. Néha azonban egyáltalán nem lehet növelni a kapacitást, vagy azt már előzőleg a felső határig növeltük. Ekkor a torlódás leküzdésére az egyetlen mód az, hogy a terhe­ lést csökkentjük. Sok módszer létezik a terhelés visszafogására, mint például megta­ gadni a szolgáltatást néhány felhasználótól, rontani a néhány vagy az összes felhasz­ nálónak nyújtott szolgáltatás színvonalát, továbbá a felhasználókat kényszeríteni arra, hogy igényeiket egy jobban előre látható módon ütemezzék. Ezen eljárások közül néhány legjobban virtuális áramkörökre alkalmazható. Olyan alhálózatokra, amelyek belsőleg virtuális áramköröket használnak, ezek az eljárások a hálózati rétegben használhatók. Datagram alapú alhálózatoknál is használhatjuk eze­ ket még a szállítási réteg összeköttetéseiben. Ebben a fejezetben a hálózati rétegbeli alkalmazásaikra összpontosítunk. A következő fejezetben majd meglátjuk, mit tehe­ tünk a szállítási rétegbeli torlódások kezelése érdekében.

5.3.2.

Torlódásmegeló'zó' módszerek

A torlódásvédelmi eljárások vizsgálatát kezdjük a nyílt hurkú rendszerekkel. Ezeket a rendszereket úgy tervezték, hogy eleve megpróbálják minimalizálni a torlódást ahe­ lyett, hogy kialakulása után reagálnának arra. Ezt a célt az egyes szinteken megfelelő politikák használatával próbálják elérni. Az 5.26. ábrán olyan adatkapcsolati, hálózati és szállítási politikákat láthatunk, amelyek befolyásolhatják a torlódást (Jain,1990). Kezdjük az adatkapcsolati rétegnél és haladjunk fölfelé. Az újraadási politika azt határozza meg, hogy az adónak milyen gyorsan jár le az időzítése, és mit ad ekkor. Egy türelmetlen adó, amelynek gyorsan lejár az időzítése, és újraadja az összes elintézet­ len keretet a visszalépés n-nel protokollt használva, nagyobb terhelést idéz elő, mint egy türelmes adó, amely a szelektív ismétlést használja. Ehhez kapcsolódik a tárolási politika. Ha a vevők automatikusan eldobják a sorrenden kívül érkező kereteket, ak­ kor ezeket később újra kell adni, ami pluszterhelést képez. A torlódásvédelem szem­ pontjából tehát a szelektív ismétlés egyértelműen jobb, mint a visszalépés n-nel. A nyugtázási politika is befolyásolja a torlódást. Ha azonnal nyugtázunk minden keretet, a nyugtakeretek külön forgalmat jelentenek. Ha viszont a nyugtákat eltesszük, hogy a visszairányú forgalomra ültethessük rá azokat, emiatt külön lejárhatnak időzí­ tők, és újraadhatják a keretet. Egy szoros forgalomszabályozási eljárás (pl. kisméretű csúszóablak) lecsökkenti az adatfolyam sebességét és segít elkerülni a torlódást. A hálózati rétegben a virtuális áramkörök és a datagramok közti választás szintén befolyásolja a torlódást, mivel számos torlódásvédelmi algoritmus csak virtuális áram-

431

A HÁLÓZATI RÉTEG

Politikák

Réteg • Újraadási politika

Szállítási

• Sorrenden kívül érkezett csomagok tárolási politikája • Nyugtázási politika • Forgalomszabályozási politika • Időzítés meghatározása • Az alhálózaton belül virtuális áramkörök vagy datagramok

Hálózati

• Csomag-sorbaállítási és kiszolgálási politika • Csomageldobási politika • Forgalomirányító algoritmus • Csomagélettartam menedzselés Adatkapcsolati

• Újraadási politika • Sorrenden kívül érkezett csomagok tárolási politikája • Nyugtázási politika • Forgalomszabályozási politika

5.26. ábra. A torlódást befolyásoló politikák

kör alapú alhálózattal működik. A csomag-sorbaállítási és -kiszolgálási politika attól függ, hogy a routereknek bemenő' vonalanként van-e egy soruk, kimenő vonalanként van-e egy soruk, vagy bemenő és kimenő soruk is van. Attól is függ, hogy milyen a csomagfeldolgozási sorrend (prioritásos vagy körforgó). A csomageldobási politika dönti el, mely csomagokat kell eldobni, ha nincs már hely. Egy jó politika enyhíthet a torlódáson, egy rossz ronthat rajta. A forgalomirányítási algoritmus segíthet elkerülni a torlódást, ha az összes vonalra elosztja a forgalmat, ellenben ha rossz, túl sokat küldhet olyan vonalakon, ahol már amúgy is torlódás van. Végül a csomagélettartam menedzselés azt mondja meg, med­ dig élhet egy csomag, mielőtt eldobnák. Ha ez túl hosszú, az elveszett csomagok soká­ ig akadályt jelentenek, míg ha túl rövid, lejárhat a csomagok ideje, mielőtt céljukat el­ érnék, ami újraadásokat eredményezhet. A szállítási rétegben ugyanazok a kérdések, mint az adatkapcsolati rétegben, hoz­ závéve, hogy az időzítési intervallum nehezebben határozható meg, mivel az átviteli idő egy hálózaton kevésbé jósolható, mint az átviteli idő egy vezetéken két router közt. Ha túl rövid az időzítés, felesleges csomagok átvitelére kerülhet sor. Ha túl hosszú, a torlódás csökken, de ennek csomagvesztés esetén a válaszidő látja kárát.

5.3.3.

Torlódásvédelem virtuális áramkör alapú alhálózatokban

A fentebb leírt torlódás védelmi eljárások alapvetően nyílthurkúak: inkább eleve meg­ próbálják a torlódás kialakulását megelőzni, minthogy az esemény bekövetkezte után foglalkozzanak vele. Ebben a szakaszban néhány megközelítést írunk le a torlódás di-

432

SZÁMÍTÓGÉP-HÁLÓZATOK

namikus szabályozására virtuális áramkör alapú alhálózatokban. A következő kettő­ ben olyan módszereket fogunk látni, amelyek bármely alhálózatban alkalmazhatók. Egy módszer, amelyet széles körben használnak már kialakult torlódás további romlásának meggátlására, a belépés ellenőrzése (admission control). Az ötlet egy­ szerű: mikor már jelezték a torlódást, nem építünk fel több virtuális áramkört, amíg a probléma meg nem szűnik. Ezért az új szállítási rétegbeli összeköttetések felépítésére irányuló kísérletek sikertelenek lesznek. Még több ember beeresztése csak ront a hely­ zeten. Bár ez a megközelítés elég durva, egyszerű és könnyű kivitelezni. A telefon­ rendszerben, amikor egy kapcsolót túlterhelnek, az szintén belépésellenőrzést hajt végre azáltal, hogy nem ad tárcsahangot. Egy alternatív megközelítés, hogy engedjünk meg új virtuális áramköröket, de fi­ gyelmesen úgy irányítsuk ezeket, hogy a problémás területeket elkerüljük. Példának vegyük az 5.27.(a) ábra alhálózatát, ahol két routerben van torlódás, ahogy jeleztük. Tegyük fel, hogy egy, az A routerhez kapcsolódó hoszt egy, a B routerhez kapcso­ lódó hoszttal akar összeköttetést létrehozni. Rendesen ez az összeköttetés áthaladna az egyik torlódott routeren. Hogy ezt a helyzetet elkerüljük, újrarajzolhatjuk az alhálóza­ tot, ahogy az 5.27.(b) ábrán látszik, kihagyva a torlódott routereket és a hozzájuk kap­ csolódó vonalakat. A szaggatott vonal egy lehetséges útvonalat mutat egy, a torlódott routereket elkerülő virtuális áramkör számára.

5.27. ábra. (a) Egy torlódott alhálózat, (b) Egy újrarajzolt alhálózat, amely kiküszöböli a torlódást, és egy virtuális áramkör A-tól B-ig Egy másik, virtuális áramkörökhöz kapcsolódó stratégia egy megegyezés kezdemé­ nyezése a virtuális áramkör felépülésekor a hoszt és az alhálózat közt. Ez a megegye­ zés rendszerint meghatározza a forgalom nagyságát, a forgalom alakját, a kívánt szolgá­ lat minőségét, és más paramétereket. Hogy betarthassa a megegyezés rá eső részét, az alhálózat jellemzően erőforrásokat foglal le az út mentén, amikor a virtuális áramkör felépül. Ezek az erőforrások tartalmazhatják a tábla- és pufferterületet a routerekben és sávszélességet a vonalakon. így valószínűtlen, hogy torlódás következzen be az új vir­ tuális áramkörökön, mivel a szükséges erőforrások garantáltan rendelkezésre állnak. Ezt a lefoglalást szabványos működési eljárásként mindig megtehetjük, vagy csak akkor, amikor az alhálózatban torlódás van. Ha mindig megtesszük, hátránya, hogy hajlamos az erőforrások pazarlására. Ha hat virtuális áramkör, amelyek mindegyike

A HÁLÓZATI RÉTEG

433

1 Mb/s-ot használhat, ugyanazon 6 Mb/s-os vonalon keresztül halad, a vonalat meg­ teltnek kell jeleznünk, még akkor is, ha ritkán forgalmaz mind a hat virtuális áramkör egyszerre. Következésképpen, a torlódásvédelem ára a kihasználatlan sávszélesség. 5.3.4.

Torlódásvédelem datagram alapú alhálózatokban

Térjünk most át egy megközelítésre, amely mind virtuális áramkör, mind datagram alapú alhálózatokban használható. Minden router könnyen megfigyelheti a kimeneti vonalai és egyéb erőforrásai kihasználtságait. Például hozzárendelhet minden vonal­ hoz egy valós változót, u-t, amelynek 0 és 1 közti értéke az utóbbi időben annak a vo­ nalnak a kihasználtságát jelzi. Hogy u-t jól tudjuk becsülni, a pillanatnyi vonalkihasz­ náltságból,/-bői periodikusan (0 vagy 1) mintákat vehetünk, és u-t a következő képlet szerint frissíthetjük: a

új-a"régi

+

(1""ű)/

ahol az a konstans azt határozza meg, milyen gyorsan felejti el a router a közelmúlt történéseit. Mindig, amikor u a küszöbszint fölé emelkedik, a kimeneti vonal „figyelmeztető' ál­ lapotba kerül. Minden újonnan érkező csomagot ellenőrzünk, hogy a kimeneti vonala fi­ gyelmeztető állapotban van-e. Ha igen, akkor valamilyen intézkedést kell foganatosíta­ nunk. Ez az intézkedés a következő pontokban tárgyalt alternatívák közül kerülhet ki. A figyelmeztető bit Akárcsak a kerettovábbítás vagy keretátjátszás (frame relay), a régi DECNET architek­ túra is egy speciális bit beállításával jelezte a figyelmeztető állapotot a csomag fejrész­ ében. Amikor a csomag megérkezett a címzetthez, a szállítási entitás bemásolta a bitet a forrásnak küldött következő nyugtába. A forrás ezt követően csökkentette a forgalmát. A router mindvégig beállította a figyelmeztető bitet, amíg csak figyelmeztető álla­ potban volt, ami azt jelentette, hogy a forrás is így kapta meg a nyugtákat. A forrás te­ hát folyamatosan figyelte a figyelmeztetéses nyugták arányát, és ennek megfelelően állította be az adási sebességét. Amíg jöttek figyelmeztető bitek, addig folytatta a for­ rás a sebességcsökkentést. Mikor már alig csordogált a forgalom, újból gyorsított. Ve­ gyük észre, hogy mivel minden útba eső router beállíthatta a figyelmeztető bitet, a forgalom csak akkor nőhetett, ha egy routernek se voltak gondjai. Lefojtó csomagok Az előző torlódásvezérlő algoritmus eléggé körülményes, hiszen kerülő úton szólítja fel lassításra a forrást. Miért ne tehetnénk meg ezt közvetlenül? Ebben a megközelí­ tésben a router egy lefojtó csomagot (choke packet) küld vissza a forrás hosztnak, megadva benne a csomagban talált célcsomópontot. Az eredeti csomagot megjelölik (egy bitet beállítanak a fejrészben), így nem fog több lefojtó csomagot generálni a to­ vábbi útja során, és a megszokott módon továbbítódik.

434

SZÁMÍTÓGÉP-HÁLÓZATOK

Amikor a forrás hoszt megkapja a lefojtó csomagot, csökkentenie kell az adott cél csomópontnak küldött forgalmát X százalékkal. Mivel valószínűleg már más csoma­ gok is úton vannak ugyanazon cél csomópont felé, melyek további lefojtó csomagokat generálnak, a hosztnak célszerű egy rögzített ideig figyelmen kívül hagynia az ugyan­ arra a cél csomópontra vonatkozó lefojtó csomagokat. Miután ez az idő lejárt, a hoszt egy időre ismét figyelni fogja a lefojtó csomagokat. Ha érkezik egy, akkor a vonalon még mindig torlódás van, tehát a hoszt tovább csökkenti a folyamot, és újból elkezdi figyelmen kívül hagyni a lefojtó csomagokat. Ha a figyelési intervallum alatt nem jön újabb lefojtó csomag, a hoszt ismét növelheti a folyamot. A protokollban implicit mó­ don jelenlevő visszacsatolás tehát segíthet megelőzni a torlódást anélkül, hogy elfoj­ tana bármilyen folyamot, amíg nincs nagy baj. A hosztok stratégiai paramétereik beállításával csökkenthetik forgalmukat. Ilyen paraméter például az ablakméret. Az első lefojtó csomag jellemzően az előző érték felére csökkenti az adatsebességet, a következő a negyedére, és így tovább. A sebes­ ség növelése ugyanakkor kisebb lépésekben történik, hogy ne fordulhasson elő hirte­ len újabb torlódás. Ennek a torlódásvédelmi algoritmusnak számos változata létezik. Az egyikben a routerek különböző küszöbszinteket tarthatnak fent. Attól függően, hogy éppen me­ lyik küszöbszintet lépték túl, a lefojtó csomag enyhe figyelmeztetést, szigorú figyel­ meztetést vagy ultimátumot tartalmazhat. Egy másik variáció a sorhosszakat vagy a pufferkihasználtságot használja jelzés­ ként a vonal kihasználtsága helyett. Természetesen ezzel a mértékkel is ugyanaz az exponenciális súlyozás használható, mint az K-val. Lépésről lépésre ható lefojtó csomagok Nagy sebességeknél és nagy távolságoknál a lefojtó csomagnak a forráshoszthoz való küldése nem működik jól, mert a reakció lassú. Vegyünk például egy San Franciscó-i hosztot (az 5.28. ábrán az A router), amely 155 Mb/s-mal küld adatot egy New York-i hosztnak (az 5.28. ábrán a D router). Ha a New York-i hoszt kezd kifogyni a pufferek­ ből, kb. 30 ms-ba kerül egy lefojtó csomagnak visszajutni San Franciscóba, hogy uta­ sítsa, lassítson le. A lefojtó csomag terjedése az 5.28.(a) ábra második, harmadik és negyedik lépésében látszik. Ezalatt a 30 ms alatt további 4,6 megabit lesz már útban. Még ha a San Franciscó-i hoszt azonnal le is áll, a csőben levő 4,6 megabit továbbra is be fog folyni és foglalkozni kell vele. Csak az 5.28. ábra hetedik rajzán fog a New York-i router egy lassabb folyamot észlelni. Egy alternatív megközelítés, hogy a lefojtó csomag minden csomópontra hasson, amelyen keresztülhalad, ahogy az 5.28.(b) ábra sorozata mutatja. Itt amint a lefojtó csomag eléri F-et, F-nek csökkentenie kell a D felé tartó adatfolyamot. Ha így te­ szünk, akkor F-nek több puffert kell szentelnie az adatfolyamnak, mivel a forrás to­ vábbra is teljes gőzzel ad, de D-nek azonnali enyhülést hoz, mint egy fejfájás-csillapí­ tó egy tv-reklámban. A következő lépésben a lefojtó csomag eléri F-t, és utasítja F-t, hogy csökkentse az F felé tartó adatfolyamot. Ez jobban igénybe veszi F puffereit, de F-nek azonnali enyhülést ad. Végül a lefojtó csomag eléri A-t, és az adatfolyam való­ ban lelassul.

435

A HÁLÓZATI RÉTEG

F

Nagy forgalom

Csökkentett forgalom

Csökkentett forgalom

A forgalom még mindig a legnagyobb sebességű

A forgalom csökkent

(a)

(b)

5.28. ábra. (a) Egy lefojtó csomag, amely csak a forrásra van hatással, (b) Egy lefojtó csomag, amely minden olyan csomópontra hatással van, amelyen áthalad

436

SZÁMÍTÓGÉP-HÁLÓZATOK

Ennek a lépésről lépésre sémának a kiterjedő' hatása gyors megkönnyebbülést biz­ tosít a torlódás helyénél, azon az áron, hogy a folyam felsőbb részén több puffert használ. így a torlódást csomagvesztés nélkül csírájában elfojthatjuk. Ezt az ötletet (Mishra és Kanakia, 1992) részletesebben tárgyalja, és szimulációs eredményekkel is szolgálnak.

5.3.5.

Terhelés eltávolítása

Amikor a fenti módszerek közül egyik sem tünteti el a torlódást, a routerek bevethetik a nehéztüzérséget: a terhelés eltávolítását. A terhelés eltávolítása (load shedding) annak a szép megfogalmazása, hogy ha a routereket elárasztják olyan csomagok, ame­ lyekkel nem tudnak megbirkózni, akkor egyszerűen kidobják azokat. A kifejezés az elektromos áram előállításának világából jön, ahol azt a gyakorlatot jelenti, hogy a közművek bizonyos területeken szándékosan áramszünetet idéznek elő, hogy az egész hálózat megmeneküljön az összeomlástól forró nyári napokon, amikor az áram iránti igény nagyban meghaladja a termelt mennyiséget. Egy, a csomagoktól fuldokló router véletlenszerűen is kiválaszthatja az eldobandó csomagokat, de rendszerint ennél többet is tehet. Hogy melyik csomagot dobja el, az a futó alkalmazástól függ. Fájlátvitelnél egy régebbi csomag többet ér, mint egy új, mert a 6. csomag eldobása és a 7.-től 10.-ig terjedő csomagok megtartása egy hézagot okoz a vevőnél, amely miatt a 6.-tól 10.-ig terjedő csomagokat esetleg újra kell adni (ha a vevő üzemszerűen eldobja a sorrenden kívül érkező csomagokat). Egy 12 csomagból álló fájlban a 6. eldobása miatt esetleg újra kell adni a 7.-től 12.-ig terjedőket, míg a 10. eldobása miatt csak a 10.-től 12.-ig terjedőket kell esetleg újraadni. Ezzel ellentét­ ben, a multimédiában egy új csomag fontosabb, mint egy régi. Az előbbi koncepciót (a régi jobb, mint az új) gyakran bor (wine) politikának, az utóbbit (az új jobb, mint a régi) gyakran tej (milk) politikának nevezik. Az ennél eggyel magasabb intelligenciaszintre lépés együttműködést igényel az adótól. Sok alkalmazásnak egyes csomagok fontosabbak, mint mások. Például bizo­ nyos mozgókép-tömörítő algoritmusok periodikusan visznek át egy egész képkeretet, és a következő képkereteket az utolsó teljes képtől való különbség formájában küldik. Ebben az esetben egy olyan csomag eldobása, amely a különbség része, előnyösebb, mint egy olyan eldobása, amely egy teljes képkeret része. Egy másik példaként ve­ gyünk egy ASCII szöveget és képeket tartalmazó dokumentum átvitelét. Egy sor kép­ pont elvesztése valamelyik képben sokkal kevésbé káros, mint egy sor olvasható szö­ veget elveszteni. Hogy egy intelligens csomageldobó politikát valósítsunk meg, az alkalmazásoknak csomagjaikat prioritás-osztályoknak megfelelően kell megjelölniük annak jelzésére, hogy azok mennyire fontosak. Ha így tesznek, akkor amikor csomagokat kell eldobni, akkor a routerek először a legalacsonyabb osztályú csomagokat dobják el, majd a kö­ vetkező legalacsonyabb osztályúakat és így tovább. Persze, hacsak nincs valami jelen­ tős ösztönzés arra nézve, hogy a csomagokat máshogy kelljen megjelölni, mint csak NAGYON FONTOS - SOHA NE DOBD EL, senki nem fogja a csomagokat osztály­ ba sorolni.

A HÁLÓZATI RÉTEG

437

Ösztönző eszköz lehet a pénz, ha az alacsony prioritású csomagokat olcsóbb elkül­ deni, mint a magas prioritásúakat. Egy másik lehetőség az, hogy a feladóknak esetleg megengedhetjük, hogy enyhébb terhelés esetén magas prioritású csomagokat küldje­ nek. A terhelés növekedtével azonban ezeket eldobjuk, így késztetve a felhasználókat arra, hogy felhagyjanak az ilyen csomagok küldésével. Egy másik lehetőség az, amikor a hosztoknak megengedjük, hogy a virtuális áram­ kör felépítésekor egyeztetett megállapodásban szereplő határokat túllépjék (vagyis a megengedettnél nagyobb sávszélességet használjanak), azzal a feltétellel, hogy min­ den fölös forgalom alacsony prioritásúnak lesz megjelölve. Egy ilyen stratégia tulaj­ donképpen nem rossz ötlet, mivel jobban kihasználja a tétlen erőforrásokat, s megen­ gedi a hosztoknak, hogy mindaddig használják ezen erőforrásokat, amíg más nem ér­ deklődik irántuk, anélkül azonban, hogy a hosztok nehezebb időkben is jogot formál­ hatnának ezekre az erőforrásokra.

Véletlen korai detektálás (Random Early Detection) Jól tudjuk, hogy hatékonyabb, ha azonnal, az észlelés pillanatától elkezdünk foglal­ kozni a torlódással, mint ha hagynánk, hogy elduguljon minden, és csak aztán próbál­ nánk meg foglalkozni vele. Ez a megfigyelés vezet ahhoz az ötlethez, hogy már az­ előtt dobáljuk el a csomagokat, mielőtt teljesen kifogynánk a pufferterületből. Egy er­ re szolgáló, népszerű algoritmus a véletlen korai detektálás (Random Early Detec­ tion, RED), melyet (Floyd és Jacobson, 1993) írnak le. Némely szállítási protokollban (beleértve a TCP-t is) a forrás lassítással reagál az elveszett csomagokra. Logikájuk mögött az az érvelés húzódik meg, hogy a TCP-t vezetékes hálózatokra tervezték, márpedig azok nagyon megbízhatók, így a csomagvesztés nagy valószínűséggel a puf­ ferek túlcsordulásának, nem pedig az átviteli hibáknak köszönhető. Ezt a tényt ki­ használhatjuk arra, hogy segítsünk csökkenteni a torlódásokat. Az alapötlet az, hogy ha a routerek már azelőtt elkezdik eldobálni a csomagokat, hogy a helyzet végképp reménytelenné válna, akkor marad idő arra, hogy valamilyen lépéseket tegyünk, mielőtt túl késő lenne. Innen származik a mechanizmus nevében a „korai" szó. A routerek figyelik a sorhosszaik pillanatnyi átlagát, és ennek segítségével állapít­ ják meg, hogy mikor kell elkezdeniük a csomagokat eldobálni. Ha az átlagos sorhossz valamelyik vonalon túllép egy küszöbszintet, akkor azt a vonalat torlódottnak tekintik, és valamilyen intézkedést tesznek a torlódás megszüntetésére. Mivel a router valószínűleg nem tudja megmondani, hogy melyik forrás okozza a legtöbb gondot, amit tehet, az az, hogy véletlenszerűen választ ki egy eldobandó cso­ magot a várakozó sorból. De hogyan értesítse a router a forrást a problémáról? Elküldhet például egy lefojtó csomagot, ahogy azt az előzőkben leírtuk. Ezzel a megközelítéssel azonban csak to­ vább terheli a már amúgy is torlódott hálózatot. Egy másik stratégia szerint megteheti, hogy egyszerűen eldobja a kiválasztott csomagot, és nem szól róla senkinek. A forrás előbb-utóbb észreveszi a nyugta hiányát, és valamit tenni fog. Mivel tudja, hogy a csomagvesztést általában a torlódás és a csomagok eldobálása okozza, válaszként las-

438

SZÁMÍTÓGÉP-HÁLÓZATOK

sftani fog. Ez az implicit formájú visszacsatolás csak akkor működik, ha a források az elveszett csomagokra az adási sebességük csökkentésével reagálnak. Vezeték nélküli hálózatokban, ahol a legtöbb veszteséget a rádiós kapcsolat zajossaga okozza, ez a megközelítés nem alkalmazható.

5.3.6.

Dzsitterszabályozás

Az olyan alkalmazásoknak, mint a hang- és mozgóképátvitel, nem igazán számít, hogy a csomagok kézbesítéséhez 20 vagy 30 ms kell, feltéve, hogy az átviteli idő ál­ landó. A csomagok megérkezési idejének ingadozása (azaz szórása) a dzsitter (jitter). A nagy dzsitter, például amikor egyes csomagok 20, mások 30 ms alatt ér­ keznek meg, a hangot vagy a képet egyenetlen minőségűvé teszi. Egy ilyen esetet is szemléltet az 5.29. ábra. Ezzel szemben elfogadható lehet egy olyan egyezmény, mely biztosítja, hogy a csomagok 99 százaléka 24,5 és 25,5 ms közötti késleltetéssel kerül leszállításra. Ezt a beígért tartományt persze meg is kell tudni valósítani. Ehhez figyelembe kell venni a fénysebességű átvitel idejét, a routerek okozta minimális késleltetést és esetleg további, elkerülhetetlen késleltetésekre is számolni kell némi időt.

ÍÖ

>.

c

•CC

o

« E o O Késleltetés

Minimális késleltetés (a fénysebesség miatt)

(a)

£

Kis dzsitter Késleltetés

(b)

5.29. ábra. (a) Nagy dzsitter. (b) Kis dzsitter A dzsitterre korlátot adhatunk, ha kiszámoljuk a várható átviteli időt az út mentén minden átugrásra. Amikor egy csomag egy routerhez érkezik, a router ellenőrzi, hogy mennyivel siet vagy késik az ütemezéshez képest a csomag. Ha a csomag siet az üte­ mezéshez képest, éppen annyival tartja vissza, hogy pontos legyen. Ha késik az üte­ mezéshez képest, a router próbálja gyorsan kilökni az ajtón. Egyes alkalmazásokban, mint pl. a hálózati videózás, a dzsíttert kiküszöbölhetjük úgy, hogy a vevőnél puffereljük az adatokat, és lejátszáskor a pufferből olvassuk ki azokat ahelyett, hogy a hálózatról várnánk a valós idejű folyamot. Más alkalmazások számára azonban a puffereléssel együtt járó késleltetés nem elfogadható; különösen

439

A HÁLÓZATI RÉTEG

igaz ez az olyan, valós idejű interakciót igénylő alkalmazásokra, mint például az Internet-telefónia vagy a videokonferencia. A torlódásvédelem aktív kutatási terület. A legújabb eredményeket foglalja össze (Gevros és mások, 2001) munkája.

5.4.

A szolgálat minősége

Az előző szakaszokban látott megoldások célja a torlódások csökkentése és a hálózat teljesítőképességének növelése. A multimédiás hálózatok térnyerése miatt azonban ezek az ad hoc mértékek már nem elegendők. A hálózatok és protokollok tervezésénél komoly erőfeszítéseket kell tenni, hogy megfelelő szolgálatminőségi garanciákat nyújthassunk. A következő szakaszokban folytatjuk a hálózatok teljesítőképességének vizsgálatát, de erősebben összpontosítunk az egyes alkalmazásokat kielégítő szolgá­ latminőségi garanciák megvalósításának módjaira. Ugyanakkor rögtön az elején le kell szögeznünk, hogy a bemutatott elgondolások közül sok még nem teljesen kifor­ rott, és sokat változhatnak még.

5.4.1.

Követelmények

Egy forrásból egy adott cél csomópont felé tartó csomagok áramát folyamnak (flow) nevezzük. Egy összeköttetés alapú hálózatban az ugyanazon folyamhoz tartozó cso­ magok ugyanazt az útvonalat járják be; összeköttetés nélküli hálózatokban haladhat­ nak különböző utakon is. Az egyes folyamok igényeit alapvetően négy paraméterrel írhatjuk le: megbízhatóság, késleltetés, dzsitter és sávszélesség. Ezek együttesen hatá­ rozzák meg a folyam által igényelt szolgálatminőséget (Quality of Service, Qo,S). Az 5.30. ábra több gyakori alkalmazást és azok követelményeinek szigorúságát so­ rolja fel.

Alkalmazás

Megbízhatóság

Késleltetés

Dzsitter

Sáv­ szélesség

E-mail

Nagy

Kicsi

Kicsi

Kicsi

Fájlátvitel

Nagy

Kicsi

Kicsi

Közepes

Webes hozzáférés

Nagy

Közepes

Kicsi

Közepes

Távoli bejelentkezés

Nagy

Közepes

Közepes

Kicsi

Hálózati zenehallgatás

Kicsi

Kicsi

Nagy

Közepes

Hálózati videózás

Kicsi

Kicsi

Nagy

Nagy

Telefónia

Kicsi

Nagy

Nagy

Kicsi

Videokonferencia

Kicsi

Nagy

Nagy

Nagy

5.30. ábra. A szolgálatminőségi követelmények szigorúsága

440

SZÁMÍTÓGÉP-HÁLÓZATOK

Az első négy alkalmazás magas követelményeket támaszt a megbízhatósággal szem­ ben. Ezeknél egyetlen bitet sem szabad hibásan átvinni. Ezt rendszerint úgy érik el, hogy ellenőrző összeggel látnak el minden csomagot, amit a cél csomópontnál ellenőriznek. Ha egy csomag megsérült az átvitel során, nem kerül nyugtázásra, és végül ismétléssel küldik el. Ez a stratégia nagy megbízhatóságot biztosít. Az utolsó négy alkalmazás (hang/kép) tolerálja a hibákat, így ezeknél nem képeznek ellenőrző összegeket. A fájlátviteli alkalmazások, beleértve az e-mailt és a videózást is, nem érzékenyek a késleltetésre. Ha minden csomag egyformán néhány másodperc késleltetést szenved, az nem okoz problémát. A weben való szörfözés, távoli bejelentkezés és hasonló inter­ aktív alkalmazások azonban már érzékenyebbek a késleltetésre. A valós idejű alkal­ mazások pedig, mint például a telefónia és a videokonferencia, már kimondottan szi­ gorú követelményeket támasztanak a késleltetéssel szemben. Ha egy telefonhívás során minden szót pontosan 2000 másodperccel késleltetünk, a felhasználók elfogad­ hatatlannak fogják tartani a kapcsolatot. Ezzel szemben a hang- vagy videoállományok egy kiszolgálóról történő lejátszása nem igényel alacsony késleltetést. Az első három alkalmazás nem érzékeny arra, ha a csomagok szabálytalan időkö­ zönként érkeznek be. A távoli bejelentkezés egy kicsit már kényesebb, mivel a karak­ terek apró löketekben fognak a képernyőn megjelenni, ha a kapcsolat nagyobb dzsitterrel terhelt. A videó és különösen a hang pedig rendkívül érzékenyek a dzsitterre. Az nem okoz gondot, ha egy felhasználó egy filmet néz a hálózaton keresztül, és a kere­ tek pontosan 2000 másodperc késleltetést szenvednek. De ha az átvitel ideje véletlen­ szerűen ingadozik 1 és 2 másodperc között, máris tragikus eredményt kapunk. A hangátvitelnél még a néhány milliszekundumos dzsitter is tisztán hallható. Az alkalmazások végül a sávszélesség-igényeiket tekintve is eltérnek egymástól: az e-mail és a távoli bejelentkezés nem sok sávszélességet használnak, de a videó bár­ mely formája rengeteget. Az ATM-hálózatok QoS igényeik alapján a következő négy nagyobb csoportba so­ rolják a folyamokat-. 1. Állandó bitsebesség (pl. telefónia). 2. Valós idejű, változó bitsebesség (pl. tömörített videokonferencia). 3. Nem valós idejű, változó bitsebesség (pl. filmet nézni az Interneten keresztül). 4. Rendelkezésre álló bitsebesség (pl. fájlátvitel). Ezek a kategóriák más hálózatokban, más célokra is hasznosak lehetnek. Az állan­ dó bitsebességgel egy olyan vezetéket szimulálhatunk, mely változatlan sávszélessé­ get és változatlan késleltetést biztosít. Változó bitsebesség például akkor fordulhat elő, ha egy mozgóképet tömörítünk, és némely keret jobban tömöríthető, mint a többi. így egy nagyon részletgazdag keret elküldése sok bitet igényelhet, egy fehér fal képe vi­ szont rendkívül jól tömöríthető. A rendelkezésre álló bitsebesség az olyan alkalmazá­ soknak felel meg, amelyek nem érzékenyek a késleltetésre vagy a dzsitterre, mint pél­ dául az e-mail.

441

A HÁLÓZATI RÉTEG

5.4.2.

Jó szolgálatminőséget biztosító megoldások

Most, hogy már tudunk egyet s mást a QoS követelményekről, hogyan tudjuk őket ki­ elégíteni? Nos, kezdjük azzal, hogy nem létezik varázsszer: önmagában egyetlen technika sem nyújt optimális módon hatékony, megbízható szolgálatminőséget. Mégis számos eljárást fejlesztettek már ki, melyek gyakorlati megoldásai sokszor több mód­ szert is ötvöznek. Tekintsük most át a rendszertervezők által a szolgálatminőség eléré­ sére használt módszereket!

Túlméretezés Egyszerű megoldásnak tűnik az, hogy annyi routerkapacitást, pufferterületet és sáv­ szélességet biztosítunk, amennyivel a csomagok könnyedén átrepülhetnek a hálóza­ ton. Ennek a megoldásnak viszont az a gyengéje, hogy drága. Ahogy azonban az idő halad és a tervezőknek több fogalmuk lesz arról, hogy valójában mennyi is az elég, ez a megoldás még akár praktikussá is válhat. Bizonyos mértékig a telefonhálózat is túl­ méretezett. Ritkán fordul elő, hogy felvesszük a telefont, és nem kapunk rögtön tár­ csahangot. Egyszerűen annyi a rendelkezésre álló kapacitás, hogy az igényeket mindig ki lehet elégíteni.

Pufferelés Az adatfolyamok kézbesítés előtt pufferelhetők a vételi oldalon. Ez nincs hatással a megbízhatóságra vagy a sávszélességre. A késleltetést növeli, de elsimítja a dzsittert. A hálózati hang- és mozgóképátvitel esetén a dzsitter okozza a legnagyobb problémát, ez a módszer tehát sokat segíthet. Láthattuk már a nagy és a kis dzsitter közti különbséget az 5.29. ábrán. Az 5.31. ábra egy olyan folyamot mutat, ahol a csomagok jókora dzsitterrel érkeznek meg. Az 1. csomagot a í = 0 s időpontban küldte el a kiszolgáló, és a t - 1 s időpontban érkezik A csomagok elhagyják a forrást A csomagok megérkeznek a pufferbe A csomagok elhagyják a puffert

00000000 0 0 000 0 , A pufferben töltött idő i ' 12 J

5

i

i

i

i

I

i

10

00000 0 i

i

i

I

15

ldő(s) v ;

5.31. ábra. A kimenő adatfolyam egyenletessé tétele puffereléssel

i

i

'

i

i

I

20

„ J Szünet a lejátszásban

'

i

442

SZÁMÍTÓGÉP-HÁLÓZATOK

meg az ügyfélhez. A 2. csomag nagyobb késleltetést szenved, és 2 másodperc alatt érke­ zik meg. Beérkezésük után a csomagokat az ügyfél számítógépe puffereli. A lejátszás t = 10 s-nál kezdődik. Addigra az első 6 csomag bekerült a pufferbe, így ezeket egyenletes időközönként elővéve zökkenésmentes lesz a lejátszás. Sajnos a 8. csomag olyan sokat késett, hogy még mindig nem áll rendelkezésre, amikor ráke­ rülne a sor, így a lejátszásnak meg kell állnia, arflíg beérkezik. Ez persze egy idegesítő szünetet okoz a zenében vagy a filmben. Ezt a problémát enyhítheti, ha még tovább késleltetjük a lejátszás kezdetét, bár ezzel nagyobb pufferre lesz szükségünk. A hang­ vagy videofolyamokat is tartalmazó kereskedelmi weboldalak ezért mind olyan leját­ szókat használnak, amelyek körülbelül 10 s-os részeket tárolnak a lejátszás előtt.

Forgalomformálás A fenti példában a forrás egyenlő időközönként adta le a csomagjait, de ez az adás más esetekben lehet szabálytalan ütemű is, ami torlódást idézhet elő a hálózatban. A nem egyenletes kimenet jellemzően olyan "kiszolgálóknál fordul élő, melyek sok fo­ lyamot kezelnek egyszerre, és emellett még más műveleteket is megengednek, mint pl. a gyors előre- és hátracsévélés, felhasználók azonosítása stb. Az általunk használt megoldás (pufferelés) ráadásul bizonyos esetekben egyáltalán nem is alkalmazható, pl. a videokonferenciánál. Ugyanakkor biztosan jobb szolgálatminőséget érhetnénk el, ha valahogy rá tudnánk venni a kiszolgálókat (és a hosztokat általában), hogy szabá­ lyos időközökkel forgalmazzanak. Lássunk hát egy olyan módszert, a forgalomfor­ málást (traffic shaping), mely nem az ügyfél, hanem a kiszolgáló oldalán teszi egyenletessé a forgalmat. A forgalomformálás az adás átlagos sebességének (és löketszerűségének) szabá­ lyozásáról szól. Ezzel szemben a korábban tamilt csúszóablakos protokollok csak az egyszerre úton lévő adatok mennyiségét korlátozzák, nem pedig a küldés sebességét. Amikor egy kapcsolat felépül, a felhasználó és az alhálózat (azaz az ügyfél és a szol­ gáltató) megegyeznek egy, az adott áramkörre vonatkozó forgalommintázatban (azaz formában). Ezt szolgáltatásszintű megállapodásnak (service levél agreement) is hívjuk. Mindaddig, amíg az ügyfél betartja az alku rá vonatkozó részét, és csak az el­ fogadott szerződésnek megfelelő módon küld csomagokat, a szolgáltató vállalja, hogy időben le is szállítja azokat. A forgalomformálás csökkenti a torlódást, ezáltal segít a szolgáltatónak betartani az ígéretét. Az efféle egyezmények nem nagyon fontosak a fájlátvitelnél, de nagy jelentőségük van a valós idejű adatok esetén, például a hang- és videokapcsolatoknál, melyeknek szigorú szolgálatminőségi követelményeik vannak. A forgalomformálásnál az ügyfél valójában azt mondja a szolgáltatónak: „Ilyen az átviteli mintám. Képes vagy ezt kezelni?" Ha a szolgáltató belemegy a játékba, felme­ rül a kérdés, hogy vajon hogyan tudja megállapítani, hogy az ügyfél tartja-e magát az egyezményhez, és mit lehet tenni, ha kiderül, hogy nem? A forgalom haladásának, fo­ lyamának figyelését forgalmi rendfenntartásnak (traffic policing) nevezzük. Virtuális áramkör alhálózatokban egyszerűbb egyeztetni, majd később fenntartani egy forgalom­ formát, mint datagram alhálózatokban. Ettől függetlenül a datagram alhálózatoknál is al­ kalmazhatjuk ugyanezeket az elgondolásokat a szállítási szintű kapcsolatoknál.

443

A HÁLÓZATI RÉTEG

A lyukas vödör algoritmus Képzeljünk el egy vödröt, az alján egy kis lyukkal, ahogy az 5.32.(a) ábrán látható. Mindegy, hogy a víz milyen sebességgel érkezik a vödörbe, a kimenő folyam kons­ tans p sebességű, amikor van víz a vödörben, és nulla, amikor a vödör üres. Ha a vö­ dör megtelt, a további érkező víz kicsordul a vödörből és elveszik (vagyis nem jelenik meg a lyuk alatti kimeneti folyamban). Ugyanez az ötlet alkalmazható csomagokra is, ahogy az 5.32.(b) ábra mutatja. A felfogás szerint minden hoszt egy lyukas vödröt, vagyis egy véges belső sort tartalma­ zó interfészen keresztül kapcsolódik a hálózathoz. Ha egy csomag akkor érkezik a sorba, amikor az tele van, a csomagot eldobják. Más szavakkal, amikor egy vagy több folyamat a hoszton belül akkor próbál csomagot küldeni, amikor már a sor betelt, az új csomagot minden felhajtás nélkül eldobják. Ez az elrendezés beépíthető a hardver interfészbe vagy szimulálható a hoszt operációs rendszere által. Ezt először Turner (1986) javasolta, és lyukas vödör (leaky bucket) algoritmusnak hívják. A gyakor­ latban ez nem más, mint egy egykiszolgálós sorban állási rendszer állandó kiszolgálá­ si idővel. A hoszt óraütésenként egy csomagot tehet a hálózatra. Ezt megint csak az inter­ fészkártya vagy az operációs rendszer kényszerítheti ki. Ez a mechanizmus a hoszton belüli felhasználói folyamatoktól eredő egyenetlen csomagfolyamot egyenletes cso­ magfolyamként adja a hálózatra, kisimítva a lökéseket és nagyban csökkentve a torló­ dás esélyét.

Csap

Csomag Egy lyukas vödröt tartalmazó interfész

Lyukas vödör

A víz állandó —. sebességgel csöpög ki a lyukon keresztül (a)

Szabályozatlan folyam A vödör csomagokat tárol Szabályozott folyam

Hálózat (b)

5.32. ábra. (a) Egy lyukas vödör vízzel, (b) Egy lyukas vödör csomagokkal

444

SZÁMÍTÓGÉP-HÁLÓZATOK

Amikor a csomagok mind azonos méretűek (pl. ATM-cellák), akkor az algoritmust a leírt formájában használhatjuk. Viszont amikor változó méretű csomagokat használunk, gyakran jobb óraütésenként egy rögzített számú bájtot megengedni, mint egy csomagot, így ha a szabály 1024 bájt/óraütés, egyetlen 1024 bájtos csomagot lehet elfogadni óra­ ütésenként, két 512 bájtos csomagot, négy 256 bájtos csomagot és így tovább. Ha a fennmaradó bájtszám túl kicsi, a csomagnak meg kell várnia a következő óraütést.

0

Idő(ms)

-*-

500

5.33. ábra. (a) Egy lyukas vödör bemenete, (b) Egy lyukas vödör kimenete. (c)-(e) Egy vezérjeles, 250 KB, 500 KB és 750 KB kapacitású vödör kimenete. (f) Egy 500 KB-os vezérjeles vödör kimenete, amely egy 10 MB/s-os lyukas vödröt táplál

A HÁLÓZATI RÉTEG

445

Az eredeti lyukas vödör algoritmust könnyű megvalósítani. A lyukas vödör egy véges sorból áll. Amikor egy csomag érkezik, ha van hely a sorban, hozzáillesztik; egyéb­ ként eldobják. Minden óraütéskor egy csomagot viszünk át (hacsak nem üres a sor). A bájtszámolós lyukas vödröt majdnem ugyanígy valósítjuk meg. Minden óraütés­ kor a számlálót n-re állítjuk. Ha a sorban első csomagnak kevesebb bájtja van, mint a számláló jelenlegi értéke, átvisszük, és a számlálót a bájtok számával csökkentjük. További csomagokat is küldhetünk, amíg a számláló értéke elég nagy. Amikor a számláló a sorban következő csomag hossza alá csökken, az átvitel megáll a követke­ ző óraütésig, amikor is felülírjuk és elveszítjük a fennmaradó bájtszámot. A lyukas vödörre egy példaként képzeljük el, hogy egy számítógép 25 millió bájt/s (200 Mb/s) sebességgel tud adatot termelni, és a hálózat is ezen a sebességen műkö­ dik, ellenben a routerek ezt az adatsebességet csak rövid időn keresztül tudják kezelni. Hosszabb időn át legjobban 2 millió bájt/s-ot meg nem haladó sebességgel tudnak működni. Tegyük fel, hogy az adat 1 millió bájtos lökésekben érkezik, vagyis minden másodpercben egy 40 ms-os lökés. Hogy az átlagos sebességet lecsökkentsük 2 millió bájt/s-ra, használhatunk egy lyukas vödröt p = 2 MB/s értékkel és C = 1 MB-os kapa­ citással. Ez azt jelenti, hogy a legfeljebb 1 MB-os lökéseket adatvesztés nélkül tudjuk kezelni, és az ilyen lökések mindig 500 ms-ra terülnek szét, mindegy, milyen gyorsan érkeztek. Az 5.33.(a) ábrán látjuk a lyukas vödör bemenetét 25 MB/s-on 40 ms-ig. Az 5.33.(b) ábrán látjuk a kimenetet egyenletes 2 MB/s-mal áramlani 500 ms-ig.

A vezérjeles vödör algoritmus A lyukas vödör algoritmus merev kimeneti mintát kényszerít az átlagos sebességre, a forgalom lökéseitől függetlenül. Sok alkalmazásnak jobb, ha a kimenetet engedjük gyor­ sulni valamelyest, amikor nagy löketek érkeznek, így egy rugalmasabb algoritmusra van szükség, lehetőség szerint olyanra, amely soha nem veszt adatot. Egy ilyen algo­ ritmus a vezérjeles vödör (tokén bucket) algoritmus. Ebben az algoritmusban a lyukas vödör vezérjeleket tartalmaz, amelyeket egy óra állít elő egy vezérjel/Ar sebességgel. Az 5.34.(a) ábrán egy vödröt láthatunk, amelyben három vezérjel van, és öt csomag vár a továbbításra. Hogy egy csomag továbbítható legyen, el kell fognia és megsemmisítenie egy vezérjelet. Az 5.34.(b) ábrán láthatjuk, hogy három csomag keresztüljutott az öt­ ből, de a másik kettő megrekedt, két további vezérjel előállítására várva. A vezérjeles vödör algoritmus másfajta forgalomalakítást biztosít, mint a lyukas vödör algoritmusa. A lyukas vödör algoritmus nem engedi a tétlen hosztoknak, hogy az engedélyeket félretegyék, és később nagy löketeket küldjenek. A vezérjeles vödör algoritmus megengedi ezt a félretevést, a vödör maximális méretéig, n-ig. Ez a tulaj­ donság azt jelenti, hogy akár n csomagból álló lökések is küldhetők egyszerre, amely megenged némi lökésszerú'séget a kimeneten és gyorsabb választ ad a bemenet hirte­ len lökéseire. További különbség a két algoritmus között az, hogy a vezérjeles vödör eldobja a vezérjeleket (azaz az átviteli kapacitást), ha a vödör megtelik, de sosem dob el csoma­ gokat. A lyukas vödör algoritmus ellenben a csomagokat is eldobja, ha megtelik a vödör.

446

SZÁMÍTÓGÉP-HÁLÓZATOK

Hoszt számítógép

DDDDD

Hoszt számítógép

Egy vezérjel kerül a vödörbe minden AT időtartam alatt

A vödör vezérjeleket tárol /

\ ^

D D

/

t7 D D D

Hálózatok (a)

Hálózatok (b)

5.34. ábra. A vezérjeles vödör algoritmusa, (a) Előtte, (b) Utána Itt is elképzelhető egy kis módosítás, ha úgy vesszük, hogy a tökének nem egy csomag, hanem k bájt elküldésére jogosítanak fel. Ilyenkor csak akkor lehet küldeni csomagot, ha van annyi tokenünk, amennyi lefedi a csomag hosszát bájtokban. A ma­ radék tokeneket meg lehet őrizni későbbi felhasználásra. Mind a lyukas vödör, mind a vezérjeles vödör algoritmusokat felhasználhatjuk a routerek közti forgalom egyenletesebbé tételére, valamint a hosztok kimenő forgalmá­ nak szabályozására is, amint azt a példákban megmutattuk. Van azonban egy jelentős különbség is a két felhasználás között. Egy hosztot szabályozó vezérjeles vödör nyu­ godtan leállíthatja a hoszt forgalmazását, ha a szabályok ezt indokolják. Ha viszont egy routernek mondjuk, hogy álljon le a küldéssel, miközben a bemenetet elárasztja a bejövő forgalom, az eredmény adatvesztés lehet. A vezérjeles vödör alapvető algoritmusának megvalósítása csak egy változó, amely a vezérjeleket számlálja. A számlálót eggyel növeljük AT időközönként, és eggyel csökkentjük, amikor csomagot küldünk. Amikor a számláló eléri a nullát, nem küldhe­ tünk csomagot. A bájtszámlálásos változatban a számlálót k bájttal növeljük minden AT -ben, és mindegyik elküldött csomag hosszát kivonjuk belőle. Alapjában véve, a vezérjeles vödör megenged lökéseket, de csak egy szabályozott legnagyobb hosszig. Nézzük például az 5.33.(c) ábrát. Itt van egy vezérjeles vödrünk 250 KB-os kapacitással. A vezérjelek egy 2 MB/s-ot megengedő sebességgel érkez­ nek. Feltéve, hogy a vezérjeles vödör tele van, amikor az 1 MB-os löket megérkezik, a vödör körülbelül 11 ms-ig tud a teljes 25 MB/s sebességgel adni. Ezután vissza kell állnia a 2 MB/s-ra, amíg a teljes bemeneti löketet el nem küldte. A maximális sebességű löket hosszának kiszámítása kissé trükkös. Nem egyszerű-

A HÁLÓZATI RÉTEG

447

en 1 MB osztva 25 MB/s, mert miközben kiadjuk a lökést, további vezérjelek érkez­ nek. Ha a lökethosszat S s-nak, a vezérjeleket tartalmazó vödör kapacitását C bájtnak, a vezérjelek érkezési sebességét p bájt/s-nak, és a legnagyobb kimeneti sebességet M bájt/s-nak vesszük, láthatjuk, hogy a kimeneti löket legfeljebb C+pS bájtot tartal­ maz. Azt is tudjuk, hogy a bájtok száma egy S s hosszú, maximális sebességű löketben MS. így kapjuk a következőt: C + pS = MS Ezt az egyenletet megoldva kapjuk az S = C/(M - p) eredményt. A mi paramétereink­ re, ahol C = 250 KB, M-25 MB/s, és p =2 MB/s, 11 ms körüli löketidőt kapunk. Az 5.33.(d) és (e) ábrák mutatják a vezérjeleket tartalmazó vödröt sorrendben 500 KB és 750 KB kapacitással. Egy lehetséges probléma a vezérjeles vödör algoritmusával, hogy ismét megenged nagy löketeket, még ha a maximális löket időtartama szabályozható is p és M figyel­ mes megválasztásával. Gyakran kívánatos csökkenteni a csúcssebességet, de a lyukas vödör alacsony értékéhez való visszatérés nélkül. A simább forgalom előállításának egy módja, hogy egy lyukas vödröt teszünk a ve­ zérjeles vödör után. A lyukas vödör sebességének nagyobbnak kell lennie a vezérjeles vödör p-jánál, de kisebbnek a hálózat maximális sebességénél. Az 5.33.(f) ábra egy 500 KB-os vezérjeles vödröt követő 10 MB/s-os lyukas vödör kimenetét mutatja. Sok fejtörést okozhat azonban, ha az összes ilyen sémát fenn akarjuk tartani. A há­ lózatnak alapjában véve követnie kell az algoritmust, és meg kell győződnie arról, hogy az engedélyezettnél több csomag vagy bájt nem kerül-e elküldésre. Ezek az eszközök ugyanakkor lehetőséget nyújtanak arra, hogy a hálózati forgalmat kezelhetőbb formára hozzuk, ezzel is hozzájárulva a szolgálatminőségi követelmények kielégítéséhez. Erőforrás-lefoglalás A szolgálatminőség garantálásához jó kezdet, ha szabályozni tudjuk a felkínált forga­ lom alakját. Persze, ennek az információnak a hatékony felhasználása implicit módon azt is jelenti, hogy megköveteljük, hogy minden csomag ugyanazt az útvonalat köves­ se. Nehéz lenne bármit is garantálni úgy, hogy a csomagokat véletlenszerűen szórjuk szét a különböző routerek között. Következésképp, a forrás és a cél csomópont között valamilyen, a virtuális áramkörhöz hasonló kapcsolatot kell létrehozni, és a folyamhoz tartozó összes csomagnak ezt az útvonalat kell követnie. Amint megvan a folyam kijelölt útja, lehetővé válik, hogy az út mentén erőforráso­ kat foglaljunk le azért, hogy biztosan rendelkezésre álljanak a szükséges kapacitások. Háromféle erőforrást lehet lefoglalni: 1. Sávszélességet. 2. Pufferterületet. 3. Processzoridőt.

448

SZÁMÍTÓGÉP-HÁLÓZATOK

A sávszélesség kérdése a legkézenfekvőbb. Ha egy folyamnak 1 Mb/s sávszéles­ ségre van szüksége, és a kimeneti vonal kapacitása 2 Mb/s, akkor azon a vonalon nyilván nem fogunk tudni három ilyen folyamot átvezetni. A sávszélesség lefoglalása tehát annyit jelent, hogy nem foglaljuk túl a kimeneti vonalakat. A második erőforrás, amiből gyakran hiányt szenvedünk, a pufferterület. Amikor egy csomag megérkezik, a hardware általában a hálózati illesztőkártyán helyezi el azt. A router szoftverének innen át kell másolnia egy, a memóriában lévő pufferterületre, és az adott puffert adáshoz sorba állítani a kiválasztott kimeneti vonalon. Ha nincs szabad puffer, a csomagot el kell dobni, mivel egyszerűen nincs hová tenni. A jobb szolgálatminőség érdekében néhány puffert fenntartanak meghatározott folyam szá­ mára, hogy az adott folyamnak ne kelljen a pufferért versengenie a többiekkel. Ily módon - egy bizonyos határig - mindig lesz szabad puffer, amikor a folyamnak szük­ sége van rá. Végül a processzoridő is szűkös erőforrásnak számít. A routernek minden csomag feldolgozásához bizonyos processzoridőre van szüksége, így egy másodperc alatt csak korlátozott számú csomag feldolgozására van lehetőség. Ahhoz, hogy minden csoma­ got kellő időben feldolgozhassunk, biztosítanunk kell, hogy a processzor ne legyen túlterhelve. Első pillantásra úgy tűnhet, hogy ha mondjuk 1 us ideig tart egy csomagot feldol­ gozni, akkor a router másodpercenként 1 millió csomagot tud kezelni. Ez a számítás azonban nem felel meg a valóságnak, mert a terhelés statisztikai ingadozásai miatt mindig lesznek tétlen periódusok. Ha a processzornak minden egyes ciklusra szüksége van a munkája elvégzéséhez, akkor egy esetleges tétlenség okozta pár ciklusnyi kiesés miatt is olyan hátrányba kerül, amit már soha nem fog tudni behozni. Sőt, még a kevéssel az elméleti kapacitás alatt maradó terhelés esetén is sorok ala­ kulhatnak ki, és késleltetés léphet fel. Tekintsünk egy olyan helyzetet, ahol a csoma­ gok véletlenszerű időközönként, átlagosan X csomag/s sebességgel érkeznek be. Az általuk igényelt processzoridő szintén véletlen eloszlású, az átlagos feldolgozási kapa­ citás u csomag/s. Ha feltesszük, hogy mind a beérkezés, mind a kiszolgálás Poissoneloszlású, akkor a tömegkiszolgálás eszközeivel megmutatható, hogy a csomagok által elszenvedett T késleltetés átlagos értéke T=l/|i x l/(l-X/n)=l/|i

x 1 / (1 - p)

ahol p = Á/u a processzor kihasználtsága. Az első tényező, 1/u, azt mutatja meg, hogy mennyi lenne a kiszolgálási idő versengés nélkül. A második tényező a többi folyam­ mal való versengés okozta lassulást jelképezi. Például, ha X = 950 000 csomag/s és |i = 1 000 000 csomag/s, akkor p = 0,95 és az egyes csomagok által elszenvedett átla­ gos késleltetés 20 us lesz 1 us helyett. Ebben benn van a sorban állás és a kiszolgálás ideje is, amint az alacsony terhelés esetén látszik (Á7u = 0). Ha a folyam útvonalán mondjuk 30 router van, akkor egyedül a sorban állásból fakadó késleltetés is már 600 us lesz.

449

A HÁLÓZATI RÉTEG

Belépés-engedélyezés Pillanatnyilag ott tartunk, hogy a valamely forrásból beérkező forgalom jól formált, és potenciálisan egyetlen útvonalat követ, melynek mentén előre lefoglaltuk az erőforrá­ sokat. Amikor egy router egy ilyen folyammal találkozik, a kapacitását és a más fo­ lyamokkal szemben már vállalt kötelezettségeit figyelembe véve el kell döntenie, hogy elfogadja vagy visszautasítja-e az új folyamot. Az elfogadásról vagy elutasításról szóló döntés nem pusztán a folyam kéréseinek (sávszélesség, pufferek, processzoridő) és a router ezen három dimenzió mértékében mért felesleges kapacitásainak összehasonlításából áll. Ennél azért bonyolultabb kér­ désről van szó. Kezdjük azzal, hogy néhány alkalmazás tisztában van ugyan a saját sávszélesség-igényével, a pufferekről és a processzoridőről azonban már kevesen tud­ nak, így mindenképp más utat kell találnunk a folyamok leírására. Továbbá, egyes al­ kalmazások sokkal jobban tudnak tolerálni egy esetlegesen lekésett határidőt, mint mások. Végül, egyes alkalmazások hajlandók lehetnek a folyami paraméterekről al­ kudozni, mások ellenben nem. Például egy általában 30 keret/s sebességgel működő filmlejátszó hajlandó lehet 25 keret/s sebességre visszaállni, ha nincs elég sávszéles­ ség az előbbi sebességhez. Hasonlóképp változtatható a keretenkénti képpontok szá­ ma, a hang sávszélessége és egyéb jellemzők. Mivel az egyeztetésben sok fél vesz részt (a feladó, a címzett, és a kettejük közötti úton lévő összes router), a tárgyalás alapját képező paramétereket tekintve pontosan le kell tudnunk írni a folyamokat. Az ilyen paraméterek halmazát folyammeghatározás­ nak (flow specification) hívjuk. Általában a feladó (pl. egy videokiszolgáló) állítja elő a folyammeghatározást, amikor is ajánlatot tesz az általa használni kívánt para­ méterekre. A meghatározás végighalad a leendő útvonalon, ahol minden router meg­ vizsgálja azt, és igénye szerint módosítja az egyes paramétereket. A módosítások nem növelhetik a folyamot, csak csökkenthetik (pl. alacsonyabb bitsebességet megadhat­ nak, magasabbat nem). Az útvonal végére érve a paramétereket rögzíteni lehet. A folyammeghatározás lehetséges tartalmára mutat példát az 5.35. ábra, mely az RFC 2210-et és az RFC 2211-et veszi alapul. Itt öt paraméterünk van, melyek közül az első a Vezérjeles vödör sebessége, ami a vödörbe kerülő bájtok másodpercenkénti számát adja meg. Ez a feladó által fenntartható legnagyobb adási sebesség, hosszú idő átlagában nézve. A második paraméter a vödör bájtokban vett mérete. Ha például a Vezérjeles vödör sebessége 1 MB/s és a Vezérjeles vödör mérete 500 KB, a vödröt 1/2 másodpercen át Paraméter

Egység

Vezérjeles vödör sebessége

bájt/s

Vezérjeles vödör mérete

bájt

Adatsebesség csúcsértéke

bájt/s

Minimális csomagméret

bájt

Maximális csomagméret

bájt

5.35. ábra. Példa a folyammeghatározásra

450

SZÁMÍTÓGÉP-HÁLÓZATOK

lehet folyamatosan tölteni, amíg megtelik (ha közben nincs semmilyen más adás). Minden ezután küldött vezérjel elvész. A harmadik paraméter, az Adatsebesség csúcsértéke a maximális megengedett át­ viteli sebesség. A feladó sosem lépheti túl ezt az értéket, még rövid időre sem. Az utolsó két paraméter a minimális és maximális csomagméretet határozza meg, beleértve a szállítási és a hálózati réteg fejrészeit is (pl. TCP és IP). A minimális méret azért fontos, mert a feldolgozás minden csomagnál időt vesz igénybe, függetlenül at­ tól, hogy milyen rövid a csomag. Lehet, hogy egy router képes másodpercenként 10 000 darab 1 KB-os csomagot kezelni, de korántsem biztos, hogy megbirkózik má­ sodpercenként 100 000 darab 50 bájtos csomaggal, hiába felel ez meg alacsonyabb bitsebességnek. A maximális csomagméret a hálózat belső korlátjai miatt fontos, eze­ ket ugyanis nem lehet túllépni. Ha például az útvonal egy része egy Etherneten ke­ resztül vezet, akkor a maximális csomagméret nem lehet több, mint 1500 bájt, füg­ getlenül attól, hogy hálózat fennmaradó része mennyit képes kezelni. Érdekes kérdés, hogy a router hogyan alakíthatja át a folyammeghatározásokat konkrét erőforrás-foglalások halmazává. Ez a leképezés a tényleges megvalósítástól függ, és nincs szabványosítva. Tegyük fel, hogy egy router 100 000 csomagot dolgoz fel másodpercenként. Ha felajánlanak neki egy 1 MB/s-os folyamot, ahol a minimális és a maximális csomagméret is 512 bájt, a router kiszámíthatja, hogy az adott forrás­ ból 2048 csomagot kaphat másodpercenként. Ebben az esetben a processzoridejének 2%-át kell fenntartania az adott folyam számára, sőt lehetőleg valamivel többet, hogy elkerülhetők legyenek a hosszú sorban állás okozta késleltetések. Ha a router stratégi­ ája az, hogy sohasem osztja ki a processzoridő több mint 50%-át (ami kétszeres kés­ leltetést jelent), és már 49%-ban foglalt, akkor ezt a folyamot vissza kell utasítania. Hasonló számítások szükségesek más erőforrások esetében is. Minél szorosabb a folyammeghatározás, annál több hasznát veszik a routerek. Ha a meghatározás megállapítja, hogy 5 MB/s Vezérjeles vödör-sebességre van szüksége, de a csomagméret 50-től 1500 bájtig terjedhet, akkor a csomagsebesség is bárhol lehet 3500 és 105 000 csomag/s között. A router lehet, hogy pánikba esik az utóbbi láttán és visszautasítja a folyamot, pedig 1000 bájtos minimális csomagmérettel az 5 MB/s-os folyamot még elfogadhatta volna.

Arányos útvonalválasztás A legtöbb forgalomirányító algoritmus minden cél csomóponthoz igyekszik megtalál­ ni a legjobb utat, és aztán minden forgalmat az adott címzetthez vezető legjobb úton lebonyolítani. A jobb szolgálatminőség érdekében azonban egy másik megközelítést is javasoltak: eszerint az egyazon címzetthez tartó forgalmakat is érdemes több útvo­ nalra szétosztani. Mivel a routereknek általában nincs teljes rálátásuk a hálózat egé­ szének forgalmára, az egyetlen járható út a forgalom több útvonal közti megosztására az, ha a helyben rendelkezésre álló információt használjuk fel. Egyszerű megoldás­ ként a forgalmat feloszthatjuk egyenlő részekre, vagy megoszthatjuk esetleg a kime­ neti vonalak kapacitásainak arányában. Emellett más, kifinomultabb algoritmusok is léteznek, melyekről (Nelakuditi és Zhang, 2002) írnak részletesebben.

451

A HÁLÓZATI RÉTEG

Csomagütemezés Ha egy router több folyamot kezel, fennáll a veszélye annak, hogy egy folyam túl nagy részét sajátítja ki a kapacitásoknak, és ezáltal kiéheztet másokat. Ha a beérkezé­ sük sorrendjében dolgozzuk fel a csomagokat, akkor egy kelló'en agresszív feladó megszerezheti a csomagjai által érintett routerek kapacitásának nagy részét, ezzel rontva a másoknak jutó szolgálatminőséget. Az ilyen kísérletek meghiúsítására szá­ mos csomagütemező algoritmus született, lásd (Bhatti és Crowcroft, 2000) munkáját. Az első ilyen elgondolások között volt az egyenlő esélyű sorbaállítás (fair queuing) algoritmusa, melyet (Nagle, 1987) írt le. Az algoritmus lényege, hogy a routerek külön várakozó sorokat tartanak fenn minden kimeneti vonalon, minden fo­ lyam számára egyet. Ha egy vonal tétlen lesz, a router körforgásos (round robin) ala­ pon végignézi a sorokat, és kivesz egy csomagot a következő sorból. Ily módon, ha n hoszt verseng egy adott kimeneti vonalért, akkor mindegyik egy csomagot küldhet el minden n csomagból. Több csomag küldése nem javítja ezt az arányt. Bár kiindulási alapnak jó, az algoritmusnak mégis van egy problémája: nagyobb sávszélességet ad a nagy csomagokat használó hosztoknak, mint a kis csomagokat használóknak. Bár kiindulásnak jó, az algoritmusnak van egy problémája: nagyobb sávszélességet ad a nagy csomagokat használó hosztoknak, mint a kis csomagokat használó hosztok­ nak. Demers és mások (1990) javasoltak egy továbbfejlesztést, ahol a körforgást úgy valósítják meg, hogy bájtonkénti körforgást szimulál csomagonkénti körforgás he­ lyett. Ez úgy működik, hogy újra és újra végignézi a sorokat bájtról bájtra, amíg meg nem találja azt az óraütést, amikor minden csomag a végére ér. Ezután a csomagokat a véget érésük sorrendjébe rendezi, és ebben a sorrendben küldi el. Az algoritmust az 5.36. ábra mutatja. Az 5.36.(a) ábrán 2-6 bájt hosszú csomagokat láthatunk. Az első (virtuális) óra­ ütéskor az A vonalon levő csomag első bájtját küldjük el. Ezután a B vonal csomagjá­ nak első bájtját és így tovább. Az első véget érő csomag a C, nyolc óraütés után. Az 5.36.(b) ábrán megadjuk a sorrendet. Új érkezők hiányában a csomagokat a felsorolt sorrendben küldjük el, C-től A-ig. Ennek az algoritmusnak egy problémája, hogy minden hosztnak azonos prioritást omag

Befejeződési idő

l\

C

8

B

B

16

D

17

D

E

18

E

A

20

c

o

(a)

(b)

5.36. ábra. (a) Egy router, amelyben az O vonal felé öt csomag áll sorban, (b) Az öt csomag befejeződésének ideje

452

SZÁMÍTÓGÉP-HÁLÓZATOK

biztosít. Sok esetben kívánatos a videokiszolgálóknak több sávszélességet adni, mint a hagyományos fájlkiszolgálóknak, tehát akár két vagy több bájtot is adhatunk nekik óraütésenként. Ezt a módosított algoritmust súlyozott egyenlő esélyű sorba állításnak (weighted fair queueing) nevezik, és széles körben használják. A súly megegyezhet az egy gépből kijövő folyamok számával, így minden folyamat egyenlő sávszélessé­ get kap. Az algoritmus egy hatékony megvalósítását tárgyalja (Shreedhar és Varghese, 1995). A csomagok routeren vagy kapcsolón keresztül való tényleges továbbítását egyre inkább hardveresen végzik, lásd (Elhanany és mások, 2001) munkáját.

5.4.3.

Integrált szolgáltatások

1995 és 1997 között az IETF sok energiát fektetett egy élő közvetítésű (streaming) multimédia architektúra kidolgozásába. A munka eredménye két tucat RFC lett, az RFC 2205-től kezdve az RFC 2210-ig. E művek a folyam alapú algoritmusok, avagy integrált szolgáltatások (integrated services, IS) nevet viselik. Az elgondolá­ sok egyaránt irányulnak az egyesküldéses és a többesküldéses alkalmazásokra. Az előbbire példa egy szóló felhasználó, aki egy videoklipet néz egy híroldalról. Az utóbbira digitális televízió-állomások egy csoportja, melyek egy IP-csomagokból álló folyammal közvetítik műsorukat a különböző helyeken tartózkodó nézőknek. Az alábbiakban a többesküldésre fogunk koncentrálni, mivel az egyesküldés is ennek egy speciális esete. A csoportok tagjai számos többesküldéses alkalmazásban dinamikusan megvál­ toztathatják a tagságukat, például bekapcsolódhatnak egy videokonferenciába, majd ha megunták, átkapcsolhatnak egy szappanoperára vagy a sportcsatornára. Ilyen fel­ tételek mellett nem működik jól az a megközelítés, hogy a feladók előre lefoglalják a sávszélességet, mert ehhez a közönségük minden be- és kilépését nyomon kéne kö­ vetniük. Egy olyan rendszerben pedig, amit arra terveztek, hogy nézők millióinak szolgáltasson televíziós közvetítést, ez egyáltalán nem is működne.

RSVP - erőforrás-foglalási protokoll Az integrált szolgáltatások architektúrájának fő IETF-protokollja az RSVP (Resource reSerVation Protocol - erőforrás-foglalási protokoll). Leírását az RFC 2205 és más RFC-k tartalmazzák. Ezt a protokollt a foglalásokhoz használják; az adatok el­ küldését más protokollok végzik. Az RSVP lehetővé teszi, hogy több adó adjon vevők több csoportjának, továbbá hogy az egyes vevők szabadon választhassanak a csator­ nák között. A protokoll ezenfelül optimizálja a sávszélesség-felhasználást, miközben kiküszöböli a torlódásokat is. A legegyszerűbb formájában a protokoll a feszítőfát használó többesküldéses for­ galomirányítást használja, ahogy azt korábban leírtuk. Minden csoporthoz hozzáren­ delünk egy csoportcímet. Hogy egy csoportnak küldjön, az adó a csoport címét teszi annak csomagjaiba. A szokásos többesküldéses forgalomirányítás ezután felépít egy feszítőfát, amely a csoport minden tagját lefedi. A forgalomirányító algoritmus nem

A HÁLÓZATI RÉTEG

453

\ T / Vevők

(b) (0 (a) 5.37. ábra. (a) Egy hálózat, (b) A többesküldéses feszítőfa az 1. hoszt számára, (c) A többesküldéses feszítőfa a 2. hoszt számára

az RSVP része. A rendes többesküldéstől való egyetlen eltérés az, hogy egy kevés ki^$ » í& TO/OT/ routereket utasítsuk bizonyos, a memóriájukban levő adatstruktúrák karbantartására. Példaként teKintsük az 5.37. ábra hálózatát. Az 1. és 2. hoszt többesküldéses adó, a 3., 4. és 5. hoszt többesküldéses vevő. Ebben a példában az adók és a vevők szétvál­ nak, általában azonban a két halmaz átlapolódik. A többesküldéses fa az 1. hosztra az 5.37.(b) ábrán, » 2. hosztra az 5.37.(c) ábrán látható. Hogy jobb vételt érjen el, és kiküszöbölje a torlódást, az egy csoportba l e y ő vevők közül bármelyik küldhet egy foglalási üzenetet a fán felfelé az adóig. Az üzenetet a korábban tárgyalt visszairányú továbbítási algoritmus segítségével terjesztik. Minden lépésnél a router észreveszi a foglalást, és fenntartja a szükséges sávszélességet. Ha nem áll rendelkezésre elegendő sávszélesség, sikertelenséget jelez vissza. Amikorra az üzenet visszajut a forrásig, már le lesz foglalva a sávszélesség a feszítőfa mentén az adótól a foglaláskérést benyújtó vevőig. Ilyen foglalásra látható példa az 5.38.(a) ábrán. Itt a 3. hoszt egy csatornát igényelt az 1. hoszthoz. Ha ez már felépült, a csomagok torlódás nélkül folyhatnak az 1 -tői a 3-ba. Most vegyük szemügyre, mi történik, ha a 3. hoszt legközelebb a másik adóhoz, a 2. hoszthoz foglal csatornát, hogy a felhasználó egyszerre két tv-műsort tudjon néz­ ni. Egy másig tít is fenn lesz tartva, ahogy az 5.38.(b) ábra mutatja. Vegyük észre, hogy két külön csatornára van szükség a 3. hoszttól az E routerig, mert két független adatfolyam kerül továbbításra.

454

SZÁMÍTÓGÉP-HÁLÓZATOK

Az 2. forrás számára • F fenntartott sávszélesség

Az 1. forrás számára fenntartott sávszélesség

J

r

K

H

T

T

3

4

5

.

(b) 2

5.38. ábra. (a) A 3. hoszt egy csatornát igényel az 1. koszthoz, (b) Ezután a 3. hoszt egy második csatornát igényel a 2. koszthoz, (c) Az 5. hoszt egy csatornát igényel az 1. hoszthoz Végül az 5.38.(c) ábrán az 5. hoszt elhatározza, hogy az 1. hoszt által adott progra­ mot akarja nézni, és szintén foglalást végez. Először, saját célra sávszélességet foglal le a H routerig. Viszont ez a router látja, hogy már kapja a táplálást az 1. hoszttól, így ha a szükséges sávszélesség már le van foglalva, nem kell többet lefoglalnia. Vegyük észre, hogy a 3. és 5. hosztok már más sávszélességet kérhettek (pl. a 3.-nak fekete-fe­ hér televíziókészüléke van, és így nincs szüksége a színinformációra), így a lefoglalt kapacitásnak olyan nagynak kell lennie, hogy kielégítse a legmohóbb vevőt is. Amikor egy foglalást végez, a vevő (opcionálisan) megnevezhet egy vagy több for­ rást, amelyekből venni akar. Azt is megmondhatja, hogy ezek a választások rögzí-

A HÁLÓZATI RÉTEG

455

tettek a foglalás időtartama alatt, vagy a vevő meg akarja tartani a forrás változtatás le­ hetőségét későbbre. A routerek ezeket az információkat a sávszélesség-tervezés opti­ malizálásához használják fel, nevezetesen, két vevőt csak akkor állítanak be közös út használatára, ha mindkettő beleegyezett, hogy később ne változtasson forrást. Ennek a stratégiának az oka a teljesen dinamikus esetben az, hogy a lefoglalt sáv­ szélesség el van különítve a forrás választásától. Ha egy vevő már lefoglalt sávszéles­ séget, átkapcsolhat egy másik forrásra, és megtarthatja a létező út azon részét, amely érvényes az új forrásra is. Ha a 2. hoszt például több videofolyamot is továbbít, a 3. hoszt tetszése szerint kapcsolgathat köztük, a foglalás változtatása nélkül: a routerek nem törődnek vele, milyen programot néz a vevő.

5.4.4.

Differenciált szolgáltatások

A folyam alapú algoritmusoknak megvan az a képességük, hogy jó szolgálatminősé­ get tudnak biztosítani egy vagy több folyam számára, mivel bármilyen igényelt erő­ forrást le tudnak foglalni az út mentén. Megvannak azonban a maguk hátrányai is. Minden egyes folyam kialakítása előkészületeket igényel, ez pedig nehezen kézben tartható, ha több ezer vagy millió folyamról van szó. Ráadásul a folyamok állapotát a routerekben tárolják, ami sebezhetővé teszi őket a routerek összeomlása esetén. Végül jelentős változtatásokat követelnek meg a routerek szoftverében is, a folyamok fel­ építése pedig bonyolult üzenetváltásokkal jár együtt a routerek között. Ebből fakadóan az RSVP-nek és a hasonló protokolloknak alig született még megvalósítása. Ezen okok miatt az IETF is egy egyszerűbb megközelítést gondolt ki a szolgálat­ minőség megvalósítására, egy olyat, amely minden routerben javarészt helyileg imp­ lementálható, az előkészületek és az egész útvonal bevonása nélkül. Ezt a megoldást osztály alapú (class-based) szolgálatminőségnek nevezik (szemben az eddig látott folyam alapúval). Az IETF egy architektúrát is szabványosított a számára, differenciált szolgáltatások (differentiated services, DS) néven, melyet az RFC 2474, RFC 2475 és számos más RFC ír le. A következőkben itt is bemutatásra kerül. Differenciált szolgáltatásokat (DS) az egy adminisztratív körzet (pl. egy internet­ szolgáltató vagy telefontársaság) alá tartozó routerek egy csoportja kínál. Az admi­ nisztráció definiálja a szolgáltatási osztályok egy halmazát a nekik megfelelő továbbí­ tási szabályokkal együtt. Ha egy ügyfél feliratkozik egy DS-re, akkor a körzetbe belé­ pő csomagjai egy Szolgáltatás típusa (Type of Service) mezőt is hordozhatnak, így bi­ zonyos osztályok számára jobb szolgáltatások biztosíthatók (pl. prémiumszolgáltatás), mint mások számára. Egy adott osztályhoz tartozó forgalomtól megkövetelhető, hogy egy meghatározott mintának feleljen meg - ez lehet például egy adott sebességgel csöpögő lyukas vödör. Egy jó üzleti érzékkel megáldott szolgáltató külön díjat szá­ molhat fel minden leszállított prémium csomag után, vagy engedélyezhet legfeljebb havi TV darab prémium csomagot egy rögzített havi különdíj ellenében. Vegyük észre, hogy ez a séma - szemben az integrált szolgáltatásokkal - nem igényel előzetes kap­ csolat-felépítést, sem erőforrás-lefoglalást, sem időigényes végpontok közti tárgyalá­ sokat külön-külön minden egyes folyamhoz. Emiatt a DS viszonylag egyszerűen megvalósítható.

456

SZÁMÍTÓGÉP-HÁLÓZATOK

Osztály alapú szolgáltatásokkal más területeken is találkozhatunk. A csomagküldő szolgálatok például gyakran kínálnak éjszakai, kétnapos vagy háromnapos kézbesítést. A légitársaságok első osztályú, üzleti osztályú és turista osztályú szolgáltatásokat nyúj­ tanak. Gyakran a távolsági vonatokon is többféle szolgáltatási osztály van, sőt még a pá­ rizsi metrónak is két osztálya van. A csomagok esetében az osztályok többek közt a késleltetés, a.dzsitter, és a torlódás esetén történő eldobás valószínűsége szerint kü­ lönbözhetnek (ez a terjedelmesebb Ethernet-keretekre valószínűleg nem érvényes). Hogy jobban meg tudjuk különböztetni a folyam alapú és az osztály alapú szolgá­ latminőséget, vegyük szemügyre az Internet-telefónia példáját! Folyam alapú sémát használva minden hívás megkapja a maga erőforrásait és garanciáit. Osztály alapú sémával az összes hívás együtt kapja meg az adott osztály számára lefoglalt erőforrá­ sokat. Ezeket az erőforrásokat nem vehetik el a fájlátviteli osztályhoz vagy más osz­ tályhoz tartozó csomagok, de az egyes telefonhívásoknak sem lesznek fenntartva kü­ lön-külön erőforrások.

Gyorsított továbbítás A szolgáltatási osztályok megválasztása a hálózat-üzemeltetők dolga, de mivel a cso­ magokat gyakran különböző szolgáltatókhoz tartozó alhálózatok között továbbítják, az IETF már a hálózatfüggetlen szolgáltatási osztályok meghatározásán dolgozik. A legegyszerűbb ilyen osztály a gyorsított továbbítás (expedited forwarding), kezdjük most ezzel. Az osztályt az RFC 3246 írja le. A gyorsított továbbítás mögött megbúvó ötlet nagyon egyszerű. Kétfajta szolgáltatási osztály áll rendelkezésre: szabályos és gyorsított. A forgalom túlnyomó része várhatóan szabályos lesz, de a csomagok egy kis hányadát gyorsítjuk. Az ilyen gyorsított csoma­ goknak elvileg úgy kell keresztülhaladniuk az alhálózaton, mintha más csomag nem is lenne ott jelen. Ezt a „kétcsöves" rendszert ábrázolja jelképesen az 5.39. ábra. Vegyük észre, hogy fizikailag továbbra is csak egy vonalunk van. Az ábra logikai csővezetékei csak a sávszélesség fenntartásának egy módját jelzik, és nem egy második fizikai vonalat. Ezt a stratégiát például úgy valósíthatjuk meg, hogy a routereket úgy programozzuk be, hogy két kimenő várakozási sort tartsanak fenn minden egyes kimeneti vonalhoz, egyet a szabályos, egyet a gyorsított csomagok számára. Amikor egy csomag megér-

5.39. ábra. A gyorsított csomagok forgalommentesnek látják a hálózatot

457

A HÁLÓZATI RÉTEG

kezik, a megfelelő' sorba kerül. A csomagidőzítéshez célszerű valamilyen, a súlyozott egyenlő esélyű sorba állításhoz hasonló algoritmust használni. Például, ha a forgalom 10%-a gyorsított, és 90%-a szabályos, akkor a sávszélesség 20%-át megtarthatjuk a gyorsított forgalomnak, a maradékot pedig a szabályosnak. Ezzel kétszer annyi sáv­ szélességet biztosítunk a gyorsított forgalom számára, mint amennyire szüksége van, így alacsony késleltetést is biztosíthatunk. Ezt a kiosztást úgy valósíthatjuk meg, ha egy gyorsított csomag küldése jut négy szabályos csomag elküldésére (feltéve, hogy mindkét osztálynál hasonló a csomagméretek eloszlása). Ily módon a gyorsított cso­ magok remélhetőleg egy terhelés nélküli alhálózatot látnak, még akkor is, ha valójá­ ban nagy a terhelés.

Biztosított továbbítás A szolgáltatási osztály az előzőnél némileg kidolgozottabb kezelését nyújtja a biztosí­ tott továbbítás (assured forwarding) sémája, melyet az RFC 2597 ír le. A séma négy prioritási osztályt ad meg; itt minden osztályhoz saját erőforrások tartoznak. Ezenfelül a torlódásba került csomagok eldobására is definiálnak három különböző valószínűséget (kis, közepes és nagy). Mindent összevetve, a két tényező együtt 12 szolgáltatási osztályt határoz meg. Az 5.40. ábra a csomagok biztosított továbbításának egy lehetséges módját mutatja. Első lépésben minden csomagot a négy prioritási osztály egyikébe sorolnak. Ezt megteheti a feladó hoszt (ahogy az ábra is mutatja) vagy az első (ún. beléptető) router. Az osztályozást azért előnyösebb a feladó hoszt oldalán elvégezni, mert itt több in­ formáció áll rendelkezésre arról, hogy mely csomagok tartoznak mely folyamokhoz. A második lépésben a csomagokat az osztályuknak megfelelően megjelöljük. Eh­ hez egy fejrész-mezőre van szükség. Szerencsére rendelkezésünkre áll egy 8 bites Szolgálat típusa mező az IP-fejrészben, amint azt hamarosan látni fogjuk. Az RFC 2597 rögzíti, hogy ezek közül 6 bit használható a szolgáltatási osztály megadására, így a kódolásban marad hely a múltbeli és a jövőbeli szolgáltatási osztályok számára is. Beléptető router

Csomagok cz> Osztályozó

Kimeneti vonal

Formázó/ Jelölő ^ > Selejtező

Négy prioritási osztály

Osztály

Sorban álló csomag

5.40. ábra. Az adatáramlás egy lehetséges megvalósítása a biztosított továbbításnál

458

SZÁMÍTÓGÉP-HÁLÓZATOK

A harmadik lépésben a csomagokat egy formázó/selejtező szűrőnek adjuk át, ami néhány csomagot késleltethet vagy eldobhat annak érdekében, hogy a négy folyamot elfogadható alakra hozza, például lyukas vagy vezérjeles vödör segítségével. Ha túl sok a csomag, itt el is lehet dobni néhányat, az eldobási kategória szerint. Még finomabb sémák is elképzelhetők, melyek méréseket vagy visszacsatolást is alkalmaznak. Ebben a példában az említett három lépést a feladó hoszt hajtja végre, és a kimeneti folyam már így kerül bele a beléptető routerbe. Érdemes megjegyezni, hogy ezeket a lépéseket egy speciális hálózati szoftver, vagy akár az operációs rendszer is elvégez­ heti, hogy ne kelljen a már létező alkalmazásokat megváltoztatni.

5.4.5.

Címkekapcsolás és MPLS

Amikor az IETF kidolgozta az integrált és differenciált szolgáltatásokat, már számos routergyártó is dolgozott a továbbítási módszerek javításán. Ez a munka arra irányult, hogy egy címkét rakjanak minden csomag elé, és a forgalomirányítást a célcím helyett ezen címke alapján végezzék el. Azzal, hogy a címke egy belső táblázat egy sorát címzi meg, a megfelelő kimeneti vonal megtalálása pusztán egy táblázatban való ke­ resés kérdése lesz. Ennek a módszernek a felhasználásával nagyon gyorsan el lehet végezni a forgalomirányítást, és le lehet foglalni a szükséges erőforrásokat az út mentén. A címkézés ettől persze veszélyesen közel kerül a virtuális áramkörökhöz. Az X.25, az ATM, a keretátjátszás és más, virtuális áramkörökkel rendelkező hálózatok szintén egy címkét (azaz egy virtuális áramkör-azonosítót) tesznek minden csomagba, majd ki­ keresik azt egy táblázatban, és a táblázat bejegyzése alapján végzik a forgalomirányítást. Annak ellenére, hogy az internetes közösségben sokan erős ellenérzéseket táplálnak az összeköttetés alapú hálózatok iránt, az ötlet mégis újra meg újra felbukkan, ezúttal a gyorsabb forgalomirányítás és a jobb szolgálatminőség érdekében. Ugyanakkor az Internet és az összeköttetés alapú hálózatok alapvetően különböző módon építik fel az útvonalai­ kat, tehát ez a módszer semmiképp sem azonos a hagyományos vonalkapcsolással. Ez az „új" kapcsolási ötlet számos különböző (szabadalmaztatott) név alatt fut, mint például a címkekapcsolás (label switching) és a jelölőkapcsolás (tag switching). Az IETF végül a többprotokollos címkekapcsolás (MultiProtocol Label Switching, MPLS) néven szabványosította az elgondolást. Az alábbiakban mi is MPLS-nek fog­ juk nevezni. A protokollt többek között az RFC 3031 írja le. Kis kitérőként jegyezzük meg, hogy egyesek különbséget tesznek a. forgalomirá­ nyítás és a kapcsolás között. A forgalomirányítás során a célcímet keressük ki egy táblázatból, hogy megtudjuk, hová kell küldeni a csomagot. A kapcsolás ellenben a csomagban található címkét használja indexként a továbbítási táblázathoz. Ezek a de­ finíciók persze még messze nem univerzálisak. Az első probléma az, hogy hová tegyük a címkét? Mivel az IP-csomagokat nem virtuális áramkörökhöz tervezték, az IP-fejrészben nincs mező a virtuális áramkör­ azonosítók számára. Emiatt új MPLS-fejrészt kell rakni az IP-fejrész elé. Az 5.41. áb­ ra egy, két router közötti vonalon használatos PPP adatkapcsolati protokoll keretszer­ kezetét mutatja, beleértve a PPP-, MPLS-, IP- és TCP-fejrészeket is. Ebben az érte­ lemben az MPLS a 2. és a 3. réteg közötti 2,5. réteg.

A HÁLÓZATI RÉTEG

Fejrészek PPP

Bitek'

MPLS

IP

20 Címke

TCP

Felhasználói adat

3 1 QoSS

8

CRC

"-..

TTL

5.41. ábra. Egy TCP-szegmens átvitele IP, MPLS és PPP segítségével

Az általános MPLS-fejrésznek 6 mezője van, melyek közül a legfontosabb a Címke (Label) mező, amely az indexet tartalmazza. A QoS mező a szolgálatminőségi osztályt jelzi. Az S mező a hierarchikus hálózatokban használatos, és több, egymásra halmozott címkére utal (lásd lejjebb). Ha ez eléri a 0-t, a csomagot eldobják. Ez akadályozza meg, hogy egy csomag a végtelenségig keringjen egy forgalomirányítási zavar esetén. Mivel az MPLS-fejrészek nem tartoznak sem a hálózati réteg csomagjához, sem az adatkapcsolati réteg keretéhez, az MPLS nagyban független mindkét rétegtől. Ez töb­ bek közt azt is jelenti, hogy olyan MPLS-kapcsolók is készíthetők, melyek mind IPcsomagokat, mind ATM-cellákat is képesek továbbítani, attól függően, hogy éppen mi érkezik. Innen származik a „többprotokollos" szó az elnevezésben. Amikor egy MPLS-címkével kiegészített csomag (vagy., cella) megérkezik egy MPLS-t ismerő routerhez, a címkét indexként használják egy táblázathoz annak megha­ tározására, hogy melyik kimeneti vonalat kell használni, és hogy milyen új címkét kell használni. Az effajta címkecserélgetést a virtuális áramkör alhálózatokban is használják, mert a címkéknek csak helyi jelentőségük van, és két különböző router össze nem tarto­ zó csomagokat is továbbíthat ugyanazzal a címkével egy másik routerhez ugyanazon a kimeneti vonalon. Ahhoz, hogy a címkék a másik oldalon megkülönböztethetők legye­ nek, azokat minden ugrásnál újra le kell képezni. Ezt a mechanizmust láthattuk már mű­ ködés közben az 5.3. ábrán. Az MPLS ugyanezt a módszert használja. Az MPLS a tömörítés mértékében eltér a virtuális áramköröktől. Az egyes folya­ mok minden további nélkül rendelkezhetnek saját címkekészlettel az alhálózatban. Sokkal gyakoribb azonban az, hogy a routerek több, egy adott routernél vagy LANnál végződő folyamot összefognak, és egy közös címkét használnak hozzájuk. Az egy címkéhez csoportosított folyamokat egyazon továbbítási ekvivalenciaosztályhoz (Forwarding Equivalence Class, FEC) tartozónak nevezzük. Ez az osztály nemcsak a csomagok címzettjét, hanem a szolgáltatási osztályukat is lefedi (a differenciált szolgáltatások értelmében), mert a továbbítás szempontjából az osztály minden cso­ magját egyformán kezelik. A hagyományos virtuális áramkörös forgalomirányításnál nem lehet több, külön­ böző címzetthez tartó útvonalat egyazon virtuális áramkör-azonosítóval ellátni, mert ekkor a végső célállomásnál nem lehetne őket egymástól megkülönböztetni. MPLS használata esetén a csomagok továbbra is tartalmazzák a célcímet a címkén kívül, így

460

SZÁMÍTÓGÉP-HÁLÓZATOK

a címkézett útvonal végén a címke-fejrészt el lehet távolítani, és a továbbítás a meg­ szokott módon folytatódhat a hálózati rétegbeli célcím felhasználásával. Az MPLS és a hagyományos virtuális áramkörök között az egyik legnagyobb kü­ lönbség a továbbítási táblázat felépítésének módjában van. Ha a felhasználó egy öszszeköttetést szeretne kiépíteni egy hagyományos virtuális áramkör hálózatban, akkor egy kapcsolatfelépító' csomagot indít útjára a hálózatban, hogy létrehozza az útvonalat és a megfelelő bejegyzéseket a továbbítási táblázatokban. Az MPLS nem így műkö­ dik, mivel itt nincs minden egyes kapcsolat számára külön felépítési fázis (ez túl sok meglévő internetszoftvert érintene). Ehelyett kétféleképpen lehet bejegyzéseket létrehozni a továbbítási táblázatban. Az adatvezérelt (data-driven) megközelítésben a csomag megérkezésekor az első érintett router felveszi a kapcsolatot a csomag útja mentén következő routerrel, és megkéri, hogy hozzon létre egy címkét a folyamnak. Ezt a módszert aztán rekurzív módon tovább al­ kalmazzák. Ezzel gyakorlatilag igény szerint hozzuk létre a virtuális áramköröket. Az effajta terjesztést végző protokollok gondosan ügyelnek arra, hogy elkerüljék a hurkok kialakulását. Ehhez általában a színes szálak (colored threads) módszerét használják. A FEC visszafelé való terjedését ahhoz lehet hasonlítani, mintha egy egyedi színű szálat húznánk végig visszafelé a hálózaton. Ha egy router olyan színt lát, amilyen színű szállal már rendelkezik, akkor tudja, hogy hurok alakult ki, és va­ lamilyen javító intézkedést tesz. Az adatvezérelt megközelítést elsősorban olyan háló­ zatokban használják, melyekben a szállítást az ATM végzi (mint a telefonrendszerek többségében). A másik, nem ATM alapú rendszerekben használatos megoldás a vezérlés alapú (control-driven) módszer. Ennek többféle változata is létezik, ezek közül az egyik működése a következő. Amikor egy router elindul, akkor megnézi, hogy mely útvo­ nalak számára lesz ő a végállomás (azaz, hogy mely hosztok vannak a hozzá tartozó LAN-on). Ezeknek aztán létrehoz egy vagy több FEC-t, mindegyikhez hozzárendel egy címkét, majd átadja a címkéket a szomszédainak. Ezek aztán beírják a címkéket a továbbítási táblázataikba, és új címkéket küldenek a szomszédaiknak, míg végül min­ den router megtanulja az útvonalat. A megfelelő szolgálatminőség érdekében erőfor­ rások is lefoglalhatok az út kiépítése során. Az MPLS egyszerre több szinten is működhet. A legmagasabb szinten minden szolgáltatót egyfajta metaroutemek tekinthetünk, amelynél létezik egy, a forrás és a cél csomópont között a metaroutereken át vezető út. Ez az út használhatja az MPLS-t. Ugyanakkor az egyes szolgáltatók hálózatán belül is használhatunk MPLS-t, így egy alacsonyabb szintű címkézéshez jutunk. így egy csomag voltaképpen egy egész veremnyi címkét hordozhat magával. Az 5.41. ábrán bemutatott S bit lehetővé teszi, hogy a router eltávolítson egy címkét, ha tudja, hogy maradnak még további címkék utána. Az S bitet l-re állítják a legalsó címkében, és 0-ra minden egyéb címkében. A gyakorlatban ezt a lehetőséget többnyire a virtuális magánhálózatok és a rekurzív alag­ utak megvalósítására használják. Bár az MPLS mögött rejlő alapötlet eléggé kézenfekvő, a részletek már rendkívül bonyolultak, számtalan változattal és optimalizációs lehetőséggel, ezért ezt a témát nem taglaljuk tovább. További információkért lásd (Davie és Rekhter, 2000; Lin és mások, 2002; Pepelnjak és Guichard, 2001; valamint Wang, 2001) munkáit.

A HÁLÓZATI RÉTEG

5.5.

461

Hálózatok összekapcsolása

Egészen eddig hallgatólagosan feltételeztük, hogy csak egyetlen homogén hálózat van, amelyben minden gép minden egyes rétegben ugyanazt a protokollt használja. Sajnos ez a feltételezés túlzottan optimista. Sok különböző hálózat létezik, beleértve a LAN-okat, MAN-okat és WAN-okat is. Minden rétegben számos protokoll használata elterjedt. A következő' szakaszokban gondosan szemügyre vesszük azokat a kérdése­ ket, amelyek akkor merülnek fel, ha kettő vagy több hálózatot egy internetté kapcso­ lunk össze. Számottevő véleménykülönbség mutatkozik abban a kérdésben, hogy vajon a mai hálózati típusok sokfélesége egy átmeneti állapot, amely elmúlik, mihelyt mindenki rájön, hogy milyen csodálatos az [ide mindenki a saját kedvenc hálózatát írhatja], vagy vajon egy elkerülhetetlen, de állandó tulajdonsága a világnak, amely meg fog maradni. A különböző hálózatok létezése mindig különböző protokollok létezését is jelenti. Úgy hisszük, hogy a különböző hálózatok változatossága (és ezáltal a protokolloké is) mindig is létezni fog a következő okok miatt. Mindenekelőtt az, hogy a különböző hálózatokat nagyon sokféle alapon működtetik. Majdnem minden személyi számító­ gép TCP/IP-t futtat. Sok nagyvállalatnak vannak SNA-t futtató nagygépes hálózatai. A telefontársaságok jelentős része üzemeltet ATM-hálózatokat. Néhány személyi számítógépekből álló LAN még mindig Novell NCP/IPX-et vagy AppleTalk-ot használ. Végül, a vezeték nélküli távközlés is feltörőben van, és számos új protokollt hoz ma­ gával. Ez a tendencia még évekig fog tartani átállási problémák és az új technológiák megjelenése miatt, továbbá azért is, mert nem minden szállító gondolja saját érdeké­ nek azt, hogy az ügyfelei egyszerűen átállhassanak egy másik szállító rendszerére. Másodszor, ahogy a számítógépek és a hálózatok egyre olcsóbbak lesznek, az in­ tézményekben a beszerzési döntések szintje lejjebb kerül. Sok társaságnál olyan ér­ telmű politika van érvényben, hogy az egymillió dollárnál nagyobb értékű beszerzé­ seket a legfelső vezetésnek, a 100 000 dollárnál nagyobb értékű beszerzéseket pedig a középső vezetésnek kell jóváhagynia, de a 100 000 dollárnál kisebb értékű beszerzé­ seket a részlegvezetők minden felsőbb jóváhagyás nélkül elvégezhetik. Ez könnyen oda vezethet, hogy a mérnöki osztály TCP/IP-t futtató UNIX munkaállomásokat tele­ pít, a marketingosztály pedig Macintoshokat AppleTalkkal. Harmadszor, a különböző hálózatok (pl. az ATM- és a vezeték nélküli hálózatok) műszaki megoldása markánsan különbözik egymástól, így nem lehet meglepő, hogy ahogy új hardvereket fejlesztenek ki, új szoftvereket is fognak készíteni, hogy illesz­ kedjenek az új hardverhez. Például az átlagos otthon ma olyan, mint az átlagos iroda tíz évvel ezelőtt: tele van számítógépekkel, amelyek nem beszélnek egymással. A jö­ vőben teljesen természetes lehet majd az, hogy a telefon, a televíziókészülék és más eszközök egy hálózatban vannak, hogy távolról lehessen őket irányítani. Ez az új technológia kétségkívül új hálózatokat és új protokollokat fog hozni. A különböző hálózatok összekapcsolási módjainak példájaként tekintsük az 5.42. ábrát. Itt egy vállalati hálózatot láthatunk, ahol a különböző telephelyeket egy nagy kiterjedésű ATM-hálózat köti össze. Az egyik telephelyen egy FDDI optikai gerinc-

462

SZÁMÍTÓGÉP-HÁLÓZATOK

N

| az Internethez

Ethernet

Hordozható | | | | y* számítógép 802.11

5.42. ábra. Összekapcsolt hálózatok együttese hálózat segítségével van összekötve egy Ethernet, egy 802.11 vezeték nélküli LAN, és a vállalat számítóközpontjának SNA nagygépes hálózata. Mindezen hálózatok összekapcsolásának az a célja, hogy bármelyik hálózat fel­ használói kapcsolatba léphessenek bármelyik másik hálózat felhasználóival, valamint hogy a felhasználók bármelyik hálózaton tárolt adathoz hozzáférhessenek. Ennek a célnak az elérése azt jelenti, hogy csomagokat küldünk egyik hálózatból a másikba. Mivel a hálózatok gyakran alapvető' kérdésekben különböznek, így nem mindig könynyű eljuttatni a csomagokat az egyik hálózatból a másikba, amint azt a következőkben látni fogjuk.

5.5.1.

Miben különböznek a hálózatok?

A hálózatok sok mindenben különbözhetnek egymástól. A különbségek egy része a fizikai és az adatkapcsolati rétegben van, mint például az eltérő modulációs eljárások vagy keretformátumok. Ezekkel most nem foglalkozunk. Ehelyett az 5.43. ábrán fel­ sorolunk néhány olyan különbséget, melyek a hálózati rétegben fordulhatnak elő. Ezen különbségek nem láthatósága az, ami a hálózatok összekapcsolását nehezebbé teszi, mint az egy hálózaton belüli működtetést. Amikor egy adott hálózaton lévő forrás gép által küldött csomagoknak egy vagy több idegen hálózaton kell áthaladniuk, mielőtt elérnék a célhálózatot (ami szintén különbözhet a forráshálózattól), számos probléma jelentkezhet a hálózatok közti inter­ fészeken. Először is, amikor egy összeköttetés alapú hálózatról származó csomagok­ nak át kell haladni egy összeköttetés nélkülin, sorrendjük megváltozhat. Ez olyasva­ lami, amire az adó nem számít, és aminek a kezelésére a vevő nincs felkészülve. Gyakran protokollkonverziókra lesz szükség, amely bonyolult lehet, ha a kívánt funk­ ciókat nem lehet megfogalmazni. Címkonverziókra is szükség lesz, amelyek valami­ féle címtárrendszert igényelnek. Többesküldéses csomagok továbbítása olyan háló­ zaton keresztül, amely nem támogatja a többesküldést, azt igényli, hogy külön csoma­ got kell létrehozni minden rendeltetési helyre.

463

A HÁLÓZATI RÉTEG

Tétel

Néhány lehetőség

Felkínált szolgálat

Összeköttetés alapú vagy összeköttetés nélküli

Protokollok

IP, IPX, CLNP, AppleTalk, DECnet stb.

Címzés

Egyszerű (802) vagy hierarchikus (IP)

Többesküldés

Van vagy nincs (ugyanez adatszórásra is)

Csomagméret

Minden hálózat megszab egy legnagyobb értéket

Szolgálat minősége

Meglehet vagy Hiányozhat; sokfajta létezik

Hibakezelés

Megbízható, sot'rendhelyes vagy nem sorrendhelyes kézbesítés

Forgalomszabályozás

Csúszóablak, sebességszabályozás, más vagy nincs

Torlódásvédelem

Lyukas vödör, lefojtó csomagok stb.

Biztonság

Bizalmassági szabályok, titkosítás stb.

Paraméterek

Eltérő időzítéseK, folyammeghatározások stb.

Számlázás

Összeköttetési idő alapján, csomag alapján, bájtok alapján vagy sehogy

5.43. ábra. Néhány abból a sok dologból, amelyben a hálózatok eltérhetnek

A különböző hálózatok által használt eltérő maximális csomagméretek ugyancsak nagy fejfájást okoznak. Hogyan továbbítana egy 8000 bájtos csomagot egy olyan há­ lózaton keresztül, amelynek a maximális mérete 1500 bájt? Gond a szolgálatok minő­ ségének eltérése is, amikor egy valós idejű kézbesítési megkötésekkel rendelkező cso­ mag egy olyan hálózaton halad keresztül, amely nem nyújt sefnmilyen valós idejű ga­ ranciát. A hibavédelem, a forgalomszabályozás és a torlódásvédelem gyakran eltér külön­ böző hálózatokban. Ha a forrás és a cél is arra számít, hogy minden csomag sorrend­ ben hiba nélkül kézbesítésre kerül, de mégis egy közbenső hálózat eldob csomagokat, ahányszor csak torlódást lát feltűnni a láthatáron, vagy a csomagok céltalanul kószál­ hatnak egy ideig, majd felbukkanhatnak és kézbesítésre kerülhetnek, akkor sok al­ kalmazás el fog romlani. A különböző biztonsági mechanizmusok, paraméter-beállítá­ sok és számlázási szabályok, vagy akár a nemzeti személyiségi jogi törvények is okozhatnak problémát.

5.5.2.

Hogyan lehet összekapcsolni a hálózatokat?

Amint azt a 4. fejezetben láthattuk, a hálózatokat különböző eszközökkel kapcsolhat­ juk össze. Tekintsük át ezt most még egyszer röviden. A fizikai rétegben a hálózatokat ismétlőkkel vagy elosztókkal (hubokkal) köthetjük össze - ezek pusztán átrakják a biteket az egyik hálózatról egy másik, azonos típusú hálózatra. Az ilyen eszközök többsége analóg, és semmit sem tud a digitális protokollokról (csak újragenerálja a jeleket).

464

SZÁMÍTÓGÉP-HÁLÓZATOK

Egy réteggel feljebb hidakat és kapcsolókat találunk, melyek az adatkapcsolati ré­ tegben működnek. Ezek már kezelik a kereteket, megvizsgálják a MAC-címeket, és különböző hálózatok irányába is végeznek kerettovábbítást, miközben kisebb protokollátalakítást is végeznek, például Ethernetről FDDI-re vagy 802.1 l-re. A hálózati rétegben routerek vannak, melyek képesek két hálózatot összekötni. Ha a két hálózatban eltérő a hálózati réteg, a router akár a csomagformátumot is át tudja alakítani, bár csomagátalakítással már egyre ritkábban találkozhatunk. Az olyan routert, ami több protokollt is képes kezelni, többprotokollos routernek (multiprotocol router) nevezzük. A szállítási rétegben szállítási átjárókat találunk, melyek két szállítási szintű össze­ köttetés között teremtenek kapcsolatot. Egy szállítási átjáró például lehetővé teheti a csomagok áramlását egy TCP- és egy eltérő szállítási protokollal rendelkező SNAhálózat között azzal, hogy lényegében hozzáragasztja a TCP-összeköttetést az SNAösszeköttetéshez. Végül az alkalmazási rétegben az alkalmazási átjárók az üzenetek jelentését játszszák át egyik hálózatról a másikra. Példaként megemlíthetjük az internetes e-mail (RFC 822) és az X.400-as e-mail közti átjárókat, melyeknek elemezniük kell az e-mail üzeneteket és különböző mezőket meg kell változtatniuk a fejrészben. Ebben a fejezetben a hálózati réteg szintjén megvalósított hálózat-összekapcsolá­ sokra koncentrálunk. Hogy lássuk, miben különbözik ez az adatkapcsolati rétegben történő összekapcsolástól, tekintsük az 5.44. ábrát. Az 5.44.(a) ábrán a forrás gép, F, szeretne egy csomagot küldeni a cél csomópontnak, C-nek. Ezek a gépek különböző Ethernet-hálózatokon vannak, melyeket egy kapcsoló köt össze. F beágyazza a cso­ magját egy keretbe, és útnak indítja azt. A keret megérkezik a kapcsolóhoz, ami a MAC-címe alapján megállapítja, hogy a keretnek a LAN 2-höz kell mennie. A kap­ csoló ekkor egyszerűen leveszi a keretet a LAN 1-ről, és rárakja a LAN 2-re. Jelmagyarázat D Fejrész czn Csomag • Farokrész

Router

Kapcsoló

nr~i n a—' '

LAN 1

^-»-trzi ^-»-IIZÍ

,% (a)

LAN 2

rr~i—J

LAN 1

^>a

,^ (b)

LAN 2

5.44. ábra. (a) Két Ethernet-hálózat kapcsolóval összekötve, (b) Két Ethernet-hálózat routerekkel összekötve. Most tekintsük ugyanezt az esetet, de kapcsoló helyett két routerrel kössük össze az Ethernet-hálózatokat! A routereket egy pont-pont vonal köti össze, ami egy akár több ezer kilométeres bérelt vonal is lehet. Itt a router veszi fel a keretet, majd kiveszi a ke­ ret adatmezejéből a csomagot. Ezután megvizsgálja a csomagban lévő címet (pl. IPcímet), és megkeresi ezt a címet a forgalomirányító táblázatában. Ezen cím alapján

465

A HÁLÓZATI RÉTEG

dönti el, hogy elküldje-e a csomagot a távoli routernek, esetlegesen egy másfajta ke­ retbe ágyazva, a vonali protokolltól függően. A túlsó végen a csomagot egy Ethernet­ keret adatmezejébe helyezi, és rárakja a LAN 2-re. Ez alapvető' különbség a kapcsolt (vagy hidalt) és a routereket használó eset között. Egy kapcsoló (vagy híd) esetében az egész keretet a MAC-címe alapján továbbítja. A router a csomagot kiveszi a keretből, és a csomagban lévő cím alapján dönti el, hogy hová küldje a csomagot. A kapcsolóknak a kapcsoláshoz nem kell érteniük a használt hálózati réteg protokollját, de a routereknek igen.

5.5.3.

Egymás után kapcsolt virtuális áramkörök

A hálózatok összekapcsolásának kétféle megoldása lehet: a virtuális áramkör alapú alhálózatok egymás után kapcsolása (konkatenációja), és a datagram típusú internet. Meg is vizsgáljuk ezeket sorjában, de előbb jöjjön néhány intő szó. A múltban a leg­ több (nyilvános) hálózat összeköttetés alapú volt [sőt a keret-átjátszás (frame relay), az SNA, a 802.16 és az ATM még mindig azok]. Később az Internet gyors előretöré­ sével a datagramok jöttek divatba. Hiba lenne azonban azt gondolni, hogy a datagramok ideje örökké tart. Ebben a szakmában csak egyvalami örök: a változás. A multi­ médiás hálózatok térhódításával valószínűleg az összeköttetés alapú megoldások is visszatérnek majd valamilyen formában, hiszen a garantált szolgálatminőséget egy­ szerűbb összeköttetésekkel biztosítani, mint nélkülük. Ezért az alábbiakban szentelünk néhány sort az összeköttetés alapú hálózatoknak is. Az egymás után kapcsolt virtuális áramkör modellben, amit az 5.45. ábra mutat, egy távoli hálózatban levő hoszthoz hasonló módon épül fel az összeköttetés, mint ahogy azt normálisan felépítenénk. Az alhálózat látja, hogy a rendeltetési hely távoli, és egy virtuális áramkört épít fel a célhálózathoz legközelebb eső routeréhez. Ezután felépít egy virtuális áramkört attól a routertől egy külső „átjáróig" (többprotokollos routerig). Ez az átjáró feljegyzi a virtuális áramkör létezését a táblázataiban, és toSNA Többprotokollos router

Router

í X.25

/

—-^-—-*\. J

M

ATM

M

OSI

<Jí

i 2

Hoszt

" Két végpont között egymás után kapcsolt virtuális áramkörök 5.45. ábra. Hálózatok összekapcsolása virtuális áramkörök egymás után kapcsolásával

466

SZÁMÍTÓGÉP-HÁLÓZ ATO K

vábblépve kiépít egy virtuális áramkört a következő alhálózatban levő routerig. Ez a folyamat folytatódik, amíg a célhosztot el nem érjük. Amikor az adatcsomagok elkezdenek az útvonalon áramlani, minden átjáró átjátszsza a bejövő csomagokat, és szükség szerint konvertál a csomagformátumok és virtuá­ lis áramkör számok között. Világos, hogy minden adatcsomag ugyanazon az átjáróso­ rozaton halad végig, és ezért sorrendben érkezik meg. Ennek a megközelítésnek a lényeges tulajdonsága, hogy virtuális áramkörök egy sorozata épül fel egy vagy több átjárón keresztül a célig. Minden átjáró táblázatokat tart karban, amelyek azt tartalmazzák, hogy milyen virtuális áramkörök haladnak át rajta, merre kell azokat irányítani, és mi az új virtuális áramkör száma. Ez a módszer akkor működik a legjobban, ha az összes hálózatnak nagyjából ugyanolyan tulajdonságai vannak. Például, ha mindegyik megbízható kézbesítést ga­ rantál a hálózati rétegbeli csomagokra, akkor az adatfolyam a forrástól a célig szintén megbízható lesz, kivéve, ha valami összeomlik az út mentén. Hasonlóan, ha egyikük sem garantálja a megbízható kézbesítést, akkor a virtuális áramkörök egymás után kapcsolása sem lesz megbízható. Másfelől, ha a forrásgép olyan hálózaton helyezke­ dik el, amely garantálja a megbízható kézbesítést, de a közbeeső hálózatok egyike el­ veszthet csomagokat, az egymás után kapcsolás alapvetően megváltoztatja a szolgálat természetét. A virtuális áramkörök egymás után kapcsolása a szállítási rétegben is szokásos. Le­ hetőség van egy - mondjuk SNA-t használó - bitcsövet építeni, amely egy átjáróban végződik, és az átjárótól a következő átjáróig egy TCP-összeköttetést használni. Ilyen módon egy különböző hálózatokat és protokollokat átívelő virtuális áramkört lehet a két végpont között felépíteni.

5.5.4.

Összeköttetés nélküli hálózatok kapcsolódása

A másik összekapcsolt hálózati modell a datagram modell, amit az 5.46. ábra mutat. Ebben a modellben az egyetlen szolgálat, amit a hálózati réteg felkínál a szállítási ré­ tegnek, az a lehetőség, hogy datagramokat adhat be az alhálózatba, és remélheti a leg­ jobbat. A hálózati rétegben nem történik említés sem virtuális áramkörökről, sem ezek egymás után kapcsolásáról. Ez a modell nem követeli meg, hogy az egy összeköt­ tetéshez tartozó összes csomag ugyanazon az átjárósorozaton haladjon végig. Az 5.46. ábrán az 1. hoszttól a 2. hoszt felé tartó datagramok különböző utakat követnek az összekapcsolt hálózatokon keresztül. Minden csomagra külön hoznak forgalomirányí­ tási döntést, esetleg a csomag elküldésének pillanatában fennálló forgalmat is figye­ lembe véve. Ez a stratégia több útvonalat is használhat, és ezáltal nagyobb sávszéles­ séget érhet el, mint az egymás után kapcsolt virtuális áramkör modell. Másfelől vi­ szont nincs garancia arra, hogy a csomagok a célhoz sorrendben érkeznek, már ha egyáltalán megérkeznek. Az 5.46. ábra modellje nem is olyan egyszerű, mint amilyennek látszik. Például, ha minden hálózatnak saját hálózati rétegbeli protokollja van, nem lehetséges az egyik hálózatból származó csomagok számára, hogy egy másikon áthaladjanak. Elképzel­ hetjük, hogy a tcbbprotokollos routerek valóban megpróbálják az egyik formátumot a

467

A HÁLÓZATI RÉTEG

Többprotokollos router

Hoszt

5.46. ábra. Összeköttetés nélküli hálózatok összekapcsolása másikba átfordítani. Ámde ha a két formátum nem közeli rokona egymásnak, azonos információs mezőkkel, az ilyen konverziók soha nem lesznek teljesek, és gyakran ku­ darcra vannak ítélve. Ezen okok miatt az átalakítást ritkán kísérlik meg. Egy másik, még komolyabb probléma a címzés. Képzeljünk el egy egyszerű esetet: egy, az Internethez kapcsolódó hoszt megpróbál egy IP-csomagot elküldeni egy olyan hosztnak, amely egy ezzel határos SNA-hálózaton foglal helyet. Az IP- és az SNAcímek különbözők. Az IP- és SNA-címek között ezért egy mindkét irányban működő leképezésre len­ ne szükség. Ráadásul elvi eltérések is vannak a hálózatok közt abban, hogy egyáltalán mi az, ami megcímezhető. Az IP-nél a hosztoknak (pontosabban a hálózati kártyák­ nak) van címük. Az SNA-nál a hosztokon kívül más entitásoknak (pl. hardvereszkö­ zöknek) is lehet címük. Ezért a legjobb esetben is egy adatbázist kéne fenntartani, ami a lehetséges mértékig mindent mindenhová leképez - ez azonban a gondok állandó forrása lenne. Egy másik ötlet, hogy tervezzünk egy egyetemes „internet" csomagot, és azt is­ merje fel minden router. Ez a megközelítés tulajdonképpen az IP - egy olyan csomag, amelyet arra terveztek, hogy sok hálózaton keresztülvihető legyen. Előfordulhat per­ sze, hogy az IPv4 (a jelenlegi Internet protokoll) minden más formátumot kiszorít a piacról, az IPv6 (a jövő Internet protokollja) pedig nem kap életre, így aztán soha semmi új nem lesz a nap alatt, de a történelem mást sugall. Nehéz úgy rábírni min­ denkit egyetlen közös formátum elfogadására, ha a cégeknek az előnyös, hogy saját egyedi formátumokat használjanak, melyek felett csak ők rendelkeznek. Foglaljuk most össze röviden a hálózatok összekapcsolásának két megközelítését. A virtuális áramkörök egymás után kapcsolása ugyanazokkal az előnyökkel bír, mint a virtuális áramkörök használata egyetlen alhálózaton belül: a puffereket előre lefog­ lalhatjuk, a sorrendhelyesség garantált, rövid fejrészeket használhatunk, és elkerül­ hetjük a késleltetett és többszörözött csomagok által okozott problémákat is. Ugyanazok a hátrányai is: a routerekben minden megnyitott összeköttetés táblázat­ helyet igényel, nincs alternatív forgalomirányítás, hogy elkerülhessük a torlódott terü­ leteket, és sérülékeny az út menti forgalomirányító-meghibásodásokra nézve. Hátra-

468

SZÁMÍTÓGÉP-HÁLÓZATOK

nya még az is, hogy bonyolult, ha nem egyenesen lehetetlen megvalósítani akkor, ha az egyik érintett hálózat egy megbízhatatlan datagram alapú alhálózat. A hálózat-összekapcsolás datagram típusú megközelítésének tulajdonságai ugyan­ azok, mint a datagram alapú alhálózatoké: több lehetó'ség a torlódásra, de több lehe­ tőség a hozzá való alkalmazkodásra is, robusztusság a router-meghibásodásokra néz­ ve, és hosszabb fejrészek kellenek. Változatos adaptív forgalomirányítási algoritmu­ sok lehetségesek egy interneten, mint ahogy egy egyedülálló datagram alapú alhálóza­ ton belül is. A hálózat-összekapcsolás datagram típusú megközelítésének egy nagy előnye, hogy olyan alhálózatok fölött is használható, amelyek belül nem virtuális áramköröket használnak. Sok LAN, mobilhálózat (pl. légi és tengeri flották), és néhány WAN is ebbe a kategóriába tartozik. Amikor egy internet ezek közül valamelyiket magába fog­ lalja, súlyos problémák lépnek fel, ha a hálózatok összekapcsolásának stratégiája vir­ tuális áramkörökre alapozott.

5.5.5.

Alagút típusú átvitel

Két különböző hálózat együttműködését kezelni általános esetben túlságosan bonyo­ lult. Ám van egy köznapi speciális eset, amely megoldható. Ez az eset az, amikor a forrás- és célhosztok azonos típusú hálózatokon vannak, de van köztük egy másfajta hálózat. Példaként gondoljunk egy nemzetközi bankra, aminek van egy TCP/IP alapú Ethernet-hálózata Párizsban, egy TCP/IP alapú Ethernet-hálózata Londonban, és egy nem IP alapú nagy kiterjedésű hálózata a kettő között, ahogy azt az 5.47. ábra mutatja. A megoldás erre a problémára egy olyan módszer, amelyet alagút típusú átvitel­ nek (tunneling) neveznek. Hogy egy IP-csomagot küldjön a 2. hosztnak, az 1. hoszt összeállít egy csomagot, benne a 2. hoszt IP-címével, behelyezi egy Ethernet-keretbe, amelyet a párizsi többprotokollos routernek címez, és ráadja az Ethernetre. Amikor a .

Egy Ethernet Párizsban

Ethernet keret

Úgy működik, mint egy soros vonal , Többprotokollos router

IP-csomag a WAN-csomag adat mezejében

5.47. ábra. Alagút típusú átvitel Párizsból Londonba

Alagút

Egy Ethernet Londonban

Ethernet keret

469

A HÁLÓZATI RÉTEG

többprotokollos router megkapja a keretet, kiveszi az IP-csomagot, belehelyezi egy WAN hálózati rétegbeli csomag adatmezejébe, és ez utóbbit megcímzi a londoni több­ protokollos router WAN-címére. Amikor ez odaér, a londoni router kiveszi az IP-cso­ magot, és egy Ethernet-keret belsejében elküldi a 2. hosztnak. A WAN-t tekinthetjük úgy is, mint egy nagy alagutat, amely az egyik többproto­ kollos routertől a másikig tart. Az IP-csomag egyszerűen az alagút egyik végétől a másikig utazik, kényelmesen a kis dobozában. Nem kell aggódnia amiatt, hogy foglal­ koznia kell a WAN-nal. Ugyanígy a két Etherneten levő hosztoknak sem. Csak a többprotokollos routereknek kell megérteniük az IP- és WAN-csomagokat. Gyakorla­ tilag az egész távolság, ami az egyik többprotokollos router közepétől a másik köze­ péig terjed, egy soros vonalként működik. Egy hasonlatként az alagút típusú átvitel világosabbá tételére, vegyünk egy embert, aki az autójával Párizsból Londonba utazik. Franciaországon belül az autó saját erejéből mozog, de amikor eléri a La Manche csatornát, berakják egy nagy sebességű vonatba és átszállítják Angliába a Csalagúton keresztül (az autóknak nem szabad behajtani a Csalagútba). Valójában az autót mint rakományt szállítják, ahogy az 5.48. ábrán látható. A másik oldalon az autót kiengedik az angol utakra és ismét saját erejéből fog mozogni. A csomagok alagút típusú átvitele egy idegen hálózaton keresztül ugyanígy működik. /

La Manche csatorna

5.48. ábra. Egy autó alagút típusú átvitele Franciaországból Angliába

5.5.6.

Forgalomirányítás összekapcsolt hálózatokban

Az összekapcsolt hálózatokon keresztüli forgalomirányítás hasonló az egyedülálló al­ hálózaton belüli forgalomirányításhoz, csak további bonyodalmakkal jár. Vegyük pél­ dául az 5.49.(a) ábrán látható összekapcsolt hálózatokat, ahol öt hálózatot hat többpro­ tokollos router köt össze. Ennek a szituációnak a gráfbeli modellezését bonyolítja, hogy minden többprotokollos router közvetlenül elérhet minden ahhoz a hálózathoz csatlakozó routert, ahova ő is csatlakozik (vagyis csomagokat tud küldeni annak). Pél­ dául az 5.49.(a) ábrán B közvetlenül elérheti A-t és C-t a 2. hálózaton keresztül, és D-t is a 3. hálózaton keresztül. Ez az 5.49.(b) ábrán látható gráfhoz vezet. Ha egyszer felépítettük a gráfot, ismert forgalomirányító algoritmusok, mint a tá­ volságvektor és kapcsolatállapot alapú algoritmusok, alkalmazhatók a többprotokollos routerek halmazára. Ez egy kétszintű forgalomirányítási algoritmust eredményez: min­ den hálózaton belül egy belső átjáró protokollt (interior gateway protocol) hasz-

470

SZÁMÍTÓGÉP-HÁLÓZATOK

(Több^-protokollos) router

® E

(a)

F

(b)

5.49. ábra. (a) Összekapcsolt hálózatok, (b) Az összekapcsolt hálózatok gráfja nálnak, de a hálózatok közt egy külső átjáró protokollt (exteriőr gateway protocol) használnak. (Az „átjáró" egy régebbi szóhasználat a „routerre".) Tulajdonképpen, mi­ vel minden hálózat független, különféle algoritmusokat használhatnak. Mivel az öszszekapcsoltak közül mindegyik hálózat független az összes többitől, gyakran hivat­ koznak rájuk autonóm rendszerekként (Autonomous System, AS). Egy tipikus internetcsomag a saját LAN-ján indul, a helyi többprotokollos routernek címezve (a MAC-réteg fejrészében). Miután odaért, a hálózati réteg kódja eldönti a saját forgalomirányító tábláit használva, hogy melyik többprotokollos routernek to­ vábbítsa a csomagot. Ha ez a router elérhető a csomag eredeti hálózati protokollját használva, közvetlenül oda továbbítja. Egyébként alagút típusú átvitelt használ, a köz­ beeső hálózat által megkövetelt protokollba beágyazva. Ezt a folyamatot addig ismét­ lik, amíg a csomag el nem éri a célhálózatot. A hálózatok közti és hálózaton belüli forgalomirányítás közti egyik különbség, hogy a hálózatok közti forgalomirányításhoz gyakran át kell lépni nemzetközi határokat. Hir­ telen különféle törvényeket kell figyelembe venni, mint pl. Svédország szigorú szemé­ lyiségjogi törvényeit a svéd állampolgárok személyi adatainak Svédországból történő kiviteléről. Egy másik példa az a kanadai törvény, amely kimondja, hogy a Kanadában képződő és végződő adatforgalom nem hagyhatja el az országot. Ez a törvény azt jelenti, hogy nem irányíthatjuk az ontariói Windsorból a Vancouverbe menő forgalmat a közeli Detroiton keresztül, még akkor sem, ha az az útvonal gyorsabb és olcsóbb. Egy további különbség a belső és külső irányítás közt a költségek területén mutat­ kozik. Egyetlen hálózaton belül általában egyetlen számlázási algoritmus érvényes. De különböző hálózatok más-más felügyeletek alá tartozhatnak, és az egyik út olcsóbb lehet, mint a másik. Hasonlóan a különböző hálózatok által felajánlott szolgálatok minő­ sége eltérhet, és ez okot adhat arra, hogy az egyik út helyett a másikat válasszuk. 5.5.7.

Darabokra tördelés

Minden hálózat megszab valamilyen maximális csomagméretet. Ezeknek a határok­ nak különféle okai lehetnek. Néhány ezek közül a következő: 1. Hardver (pl. egy Ethernet-keret hossza).

A HÁLÓZATI RÉTEG

471

2. Operációs rendszer (pl. minden puffer 512 bájtos). 3. Protokollok (pl. a csomaghossz mezőben a bitek száma). 4. Igazodás valamilyen nemzet(köz)i szabványhoz. 5. Az a kívánság, hogy a hibák által okozott újraadások valamilyen szintre csökkenjenek. 6. Az a kívánság, hogy egyetlen csomag se foglalhassa le a csatornát túl sokáig. Mindezen tényezők eredményezik, hogy a hálózattervezők nem választhatnak tetszé­ sük szerinti maximális csomagméretet. A maximális adatmezőhosszak 48 bájttól (ATM) 65 515 bájtig (IP-csomagok) terjednek, bár az adatmezőhossz magasabb réte­ gekben gyakran nagyobb. Egy nyilvánvaló probléma jelentkezik, amikor egy nagy csomag olyan hálózaton akar keresztülhaladni, amelynek a maximális csomagmérete túl kicsi. Egy megoldás az, hogy eleve elkerüljük a probléma felmerülését. Más szavakkal, az internetnek olyan forgalomirányító algoritmust kell használnia, amely nem küld olyan csomago­ kat olyan hálózatokon keresztül, amelyek nem tudják azokat kezelni. Viszont ez a megoldás egyáltalán nem megoldás. Mi történik, ha az eredeti csomag túl nagy ahhoz, hogy a célhálózat kezelje? A forgalomirányító algoritmus aligha tudja elérni a címzettet. Alapvetően az egyetlen megoldás a problémára, hogy engedjük meg az átjáróknak, hogy a csomagokat darabokra (fragments) tördeljék, és minden darabot mint önálló internetcsomagot küldjék el. De mint ahogy azt minden kisgyermekes szülő tudja, egy nagy tárgy kisebb darabokká alakítása lényegesen könnyebb, mint a visszairányú fo­ lyamat. (A fizikusok még egy nevet is adtak ennek a jelenségnek: a termodinamika második főtétele.) A csomagkapcsoló hálózatoknak is gondjaik vannak a darabok új­ bóli összerakásával. Két ellentétes stratégia létezik a darabok eredeti csomaggá történő visszaállítására. Az első stratégia az, hogy a „kiscsomagos" hálózat által okozott darabolást átlátszóvá kell tenni az utána következő hálózatok számára, amelyeken a csomagnak át kell ha­ ladnia a végső célállomás felé. Ezt a lehetőséget az 5.50.(a) ábra mutatja. Ebben a megoldásban a kiscsomagos hálózat átjárókon keresztül (többnyire specializált routerek) kapcsolódik a többi hálózathoz. Amikor egy túlméretes csomag érkezik egy átjáróhoz, az átjáró feldarabolja, és az összes darabot ugyanannak a kimenő átjárónak címezi, amelyik a részeket aztán újra összeállítja. Ily módon a kiscsomagos hálózaton történő áthaladás átlátszó lesz. A következő hálózatok nem is tudják, hogy a darabolás megtörtént. Az ATM-hálózatoknak például speciális hardverük van a csomagok átlát­ szó módon történő cellákba darabolásához és a cellák csomagokká történő összeállítá­ sához. Az ATM-világban a darabolást szegmentálásnak hívják; az elv ott is ugyanez, de néhány részlet különbözik. Az átlátszó darabolás egyszerű, de van néhány problémája. Egyrészt a kimeneten levő átjárónak tudnia kell, mikor kapta meg a.z összes részt, tehát vagy egy számláló mezőt vagy egy „csomag vége" mezőt el kell helyezni minden csomagban. Másrészt az összes csomagnak ugyanazon az átjárón keresztül kell távoznia. Azzal, hogy nem

472

SZÁMÍTÓGÉP-HÁLÓZATOK

1. hálózat

G1 feldarabol egy nagy csomagot

2. hálózat

G 2 összeállítja a darabokat

G 3 újra darabol

G4 újra összeállít

(a)

G feldarabol egy nagy csomagot

A

darabokat nem állítják össze, 9 a v é 9 s ő c é l t (e9y hosztot)

amí

el nem érték (b)

5.50. ábra. (a) Átlátszó darabolás, (b) Nem átlátszó darabolás engedjük meg, hogy egyes darabok más-más útvonalat kövessenek a végső' cél felé, mint a többi, némi teljesítményt vesztünk. Egy utolsó probléma pedig a nagy csoma­ gok ismételt összeállításához és feldarabolásához szükséges többletidő', amikor ezek egy sor kiscsomagos hálózaton haladnak keresztül. A másik darabolási stratégia, hogy tartózkodjunk a közbeeső átjáróknál az összera­ kástól. Ha egyszer egy csomagot feldaraboltunk, minden csomagot úgy kezelünk, mint­ ha az egy eredeti csomag lenne. Minden darabot átjuttatunk a kimeneti átjárón keresztül, mint az az 5.50.(b) ábrán látszik. Az összeállítás csak a célhosztban történik meg. A nem átlátszó darabolásnak is van néhány problémája. Például minden hoszttól megköveteli, hogy képes legyen az összeállítás elvégzésére. Még egy probléma, hogy amikor egy nagy csomagot feldarabolunk, a teljes átviendő adatmennyiség megnő, mivel minden darabnak kell legyen egy fejrésze. Míg az első módszerrel ez a többlet eltűnik, amint a csomag kilép a kiscsomagos hálózatból, ezzel az eljárással a többlet megmarad az út hátralevő szakaszára. Viszont egy előnye ennek az eljárásnak az, hogy több kimeneti átjárót is használhatunk, és nagyobb teljesítményt érhetünk el. Természetesen, ha az egymás után kapcsolt virtuális áramkör modellt használjuk, ez­ zel az előnnyel semmit nem érünk. Amikor egy csomagot feldarabolunk, a darabokat oly módon kell megszámozni, hogy az eredeti adatfolyamot vissza lehessen állítani. A darabok számozásának egy módja a fa struktúra használata. Ha a 0-s csomagot fel kell hasítani, a darabokat ne­ vezzük 0.0-nak, 0.l-nek, 0.2-nek stb. Ha ezeket a darabokat később is fel kell darabol­ ni, a részeket így számozzuk: 0.0.0, 0.0.1, 0.0.2,..., 0.1.0, 0.1.1, 0.1.2 stb. Ha elég me­ zőt tartottunk fent a fejrészben a legrosszabb esetre, és sehol nem keletkeznek másod­ példányok, ez a módszer elégséges ahhoz, hogy az összes részt helyesen össze lehes­ sen állítani, mindegy, milyen sorrendben érkeznek.

473

A HÁLÓZATI RÉTEG

Ellenben, ha akár csak egy hálózat is elveszít vagy eldob csomagokat, akkor a vég­ pontok közötti újraadásra van szükség, és ez sajnálatos hatással van a számozási rend­ szerre. Tegyük fel, hogy egy 1024 bites csomagot kezdetben négy egyenlő méretű da­ rabra daraboltunk, és a darabokat a következőképpen számoztuk: 0.0, 0.1, 0.2 és 0.3. A 0.1 számú darab elveszik, de a többi rész megérkezik a célállomáshoz. A forrásnak végül lejár az időzítője, és újraadja az eredeti csomagot. Csakhogy ezúttal lecsap Murphy törvénye, és a követett útvonal most egy 512 bites csomaghatárral rendelkező hálózaton halad keresztül, így két darab keletkezik. Amikor az új 0.1-es számú darab megérkezik a célállomáshoz, a vevő azt fogja hinni, hogy most már mind a négy rész megvan, és helytelenül fogja összeállítani a csomagot. Egy teljesen más (és jobb) számozási rendszer az, hogy a hálózatközi protokollnak kell egy olyan elemi darabméretet meghatároznia, amely elég kicsi ahhoz, hogy az elemi darab minden hálózaton keresztül tudjon jutni. Amikor egy csomagot darabolnak, minden rész egyenlő lesz az elemi csomagmérettel, kivéve az utolsót, ami rövidebb lehet. Egy internetcsomag számos darabot tartalmazhat hatékonysági okokból. Az in­ ternet fejrésznek tartalmaznia kell az eredeti csomagszámot, és a csomagban levő (el­ ső) elemi darab számát. Mint rendesen, kell egy olyan bit is, amely azt jelzi, hogy az internetcsomagban levő utolsó elemi darab az eredeti csomag utolsó darabja. Ez a megközelítés két sorszámmezőt igényel az internet fejrészben: az eredeti cso­ magszámot és a darabszámot. Nyilvánvalóan kompromisszum van az elemi darab mé­ rete és a darabszámban levő bitek száma közt. Mivel az elemi darabméretről feltesz-

Az első elemi darab száma, amely ebben a csomagban van Csomags zám

\ 27

Csomag vége 13Ít / 0 1 A

B

1 bájt

D

C

E

F

G

H

J

I

Fejrész

(a) 27

0 0 A

B

C

D

E

F

G

27

H

Fejrész

8 1

I

J

Fejrész (b)

27

0 0 A

Fejrész

B

C

D

E

27

5 0 F

Fejrész (c)

G

H

27

8 1

I

J

Fejrész

5.51. ábra. Darabolás, ha az elemi darabméret 1 bájt. (a) Eredeti csomag, amely 10 adatbájtot tartalmaz, (b) A darabok egy olyan hálózaton való keresztülhaladás után, ahol a maximális csomagméret 8 adatbájt + fejrész, (c) A darabok egy 5 adatbájt + fejrész méretű átjárón való áthaladás után

474

SZÁMÍTÓGÉP-HÁLÓZATOK

szük, hogy minden hálózat számára elfogadható, egy sok darabot tartalmazó internet­ csomag további darabolása nem okoz problémát. A végső határ, hogy az elemi darab egyetlen bit vagy bájt legyen, amikor is a darabszám a bit vagy a bájt elhelyezkedését mutatja az eredeti csomagon belül, ahogy az az 5.51. ábrán látszik. Néhány intemetprotokoll még tovább viszi ezt az eljárást, és a virtuális áramkörön történő egész átvitelt egy óriási csomagnak fogja fel, így minden darab tartalmazza a darab első bájtjának abszolút bájtszámát.

5.6.

Hálózati réteg az Interneten

Mielőtt belemerülnénk az Internet hálózati rétegének részleteibe, érdemes egy pillan­ tást vetnünk azokra az elvekre, melyek annakidején az Internet tervezőit vezették, és amelyeknek mai sikerét is köszönheti. Manapság amúgy is túl gyakran tűnik úgy, hogy az emberek megfeledkeztek ezekről. Az elveket az RFC 1958 sorolja fel és tár­ gyalja meg. Ez egy ugyancsak hasznos olvasmány (sőt, a protokolltervezők számára kötelezővé kellene tenni, és még vizsgázniuk is kellene belőle). Az RFC erősen tá­ maszkodik (Clark, 1888; valamint Saltzer és mások, 1984) ötleteire. Most pedig öszszefoglaljuk, hogy mi mit tartunk a legfontosabb 10 vezérelvnek (a fontosabbaktól a kevésbé fontosabbak felé haladva). 1. A lényeg, hogy működjön. Ne véglegesítsd a tervet vagy a szabványt, amíg több prototípus nem kommunikált sikeresen egymással. Túlságosan is gyakran fordul elő, hogy a tervezők elkészítenek egy 1000 oldalas szabványt, elfogadtat­ ják, aztán rájönnek, hogy alapjaiban rossz és nem is működik. Ezután megírják a szabvány 1.1-es verzióját. Ezt az utat nem szabad követni. 2. Maradj az egyszerűnél. Ha kétségek merülnek fel, használd a legegyszerűbb megoldást. William of Occam fogalmazta meg ezt az elvet (Occam borotvája) a 14. században. Vagy, hogy mai szóhasználattal éljünk: küzdj a funkciók ellen. Ha egy funkció nem feltétlenül szükséges, hagyd ki, különösen, ha ugyanaz a hatás elérhető más funkciók kombinációjával. 3. Válassz egyértelműen. Ha ugyanazt a dolgot többféleképpen is meg lehet olda­ ni, válassz ki egy megoldást. Ha két vagy több módon is megvalósíthatjuk ugyanazt, az csak bajt okoz. A szabványokban gyakran csak azért vannak külön­ böző lehetőségek, paraméterek vagy üzemmódok, mert számos, nagy befolyással rendelkező kidolgozó fél ragaszkodik ahhoz, hogy a saját elgondolása a legjobb. A tervezőknek keményen ellen kell állniuk ennek a tendenciának. Egyszerűen nemet kell mondani. 4. Használd ki a modularitást. Ez az elv közvetlenül a protokollvermek alkalma­ zásának ötletéhez vezet, melyekben minden réteg független a többitől. Ily mó­ don, ha a körülmények egy modul vagy réteg megváltoztatását követelik meg, a többit ez nem érinti.

A HÁLÓZATI RÉTEG

475

5. Számíts heterogén környezetre. Minden nagy hálózatban előfordulnak külön­ böző hardverek, átviteli berendezések és alkalmazások. Ahhoz, hogy ezeket mind kezelni tudd, a hálózat tervezése legyen egyszerű, általános és rugalmas. 6. Kerüld a statikus opciókat és paramétereket. Ha a paraméterek használata végképp elkerülhetetlen (pl. a maximális csomagméret), akkor jobb, ha az adó és a vevő megegyeznek egy értékben, mint ha rögzített opciókat határoznánk meg. 7. Amit tervezel, az legyen jó - nem muszáj tökéletesnek lennie. A tervezőknek gyakran van egy olyan tervük, ami jó ugyan, de nem képes valamilyen furcsa speciális esetet kezelni. Ahelyett, hogy erre összekuszálnák a tervet, tanácsosabb a jó terv mellett kitartaniuk, a mesterkedések terhét pedig azokra hagyni, akiknek különleges igényeik vannak. 8. Légy szigorú a küldésnél és elnéző a vételnél. Más szavakkal, csak olyan cso­ magokat küldj, amik szigorúan megfelelnek a szabványoknak, de számíts rá, hogy a bejövő csomagok nem lesznek teljesen szabványosak, és próbáld meg ke­ zelni őket. 9. Gondolj a skálázhatóságra. Ha a rendszernek hosztok millióit és felhasználók ' milliárdjait kell hatékonyan kezelnie, semmilyen központosított adatbázis nem jöhet szóba, a terhelést pedig olyan egyenletesen kell megosztani a rendelkezé­ sekre álló erőforrások között, amennyire csak lehet. 10. Mérlegeld a teljesítményt és a költségeket. Ha egyMlózat gyatra teljesítményt nyújt, vagy irreális költségeket produkál, senki sem fogja majd használni. Tegyük most félre az általános elveket, és kezdjük el az Internet hálózati rétegének tanulmányozását. A hálózati réteg szintjén az Internet autonóm rendszerek (Autonomous Systems, AS) összekapcsolt együttesének tekinthető. Nincs igazi szerkezete, de létezik számos főbb gerinchálózata, amelyek nagy sávszélességű vonalakból és gyors routerekből állnak. A gerinchálózatokhoz csatlakoznak a területi vagy regionális (középszintű) hálózatok, és ezekhez a hálózatokhoz csatlakoznak az egyetemeken, vállalatoknál és internetszolgáltatóknál levő LAN-ok. Az 5.52. ábrán ennek a kvázihierarchikus szerveződésnek egy vázlata látható. Az a ragasztó, amely az Internetet egybetartja, az IP (Internet Protocol - hálózat­ közi protokoll). Sok régebbi hálózati rétegbeli protokolltól eltérően, ezt már a kezde­ tektől a hálózatok összekapcsolását szem előtt tartva tervezték. A hálózati rétegről egy jó elképzelés a következő lehet: az a feladata, hogy optimális szállítást biztosítson a datagramok forrásgéptől a célgépig történő eljuttatásához, függetlenül attól, hogy ezek a gépek ugyanazon a hálózaton vannak-e vagy sem, és vannak-e köztük más hálózatok vagy nincsenek. Az Interneten a kommunikáció a következőképpen működik: a szállítási réteg veszi az adatfolyamokat, és datagramokra tördeli azokat. Elméletben a datagramok egyen­ ként 64 Kbájt hosszúak lehetnek, de a gyakorlatban rendszerint 1500 bájt körüliek.

476

SZÁMÍTÓGÉP-HÁLÓZATOK

IP alapú vezérjeles gyűrűs LAN

5.52. ábra. Az Internet sok hálózat egybekapcsolt összessége Minden datagram átvitelre kerül az Interneten, esetleg menet közben kisebb egysé­ gekre darabolva. Amikor végül minden darab megérkezett a célgéphez, a hálózati ré­ teg összeállítja azokat az eredeti datagrammá. A datagramot azután átadja a szállítási rétegnek, amelyik beilleszti azt a vételi folyamat bemeneti adatfolyamába. Ahogy az 5.52. ábrából látszik, az 1. hoszttól induló csomagnak hat hálózatot kell megjárnia, hogy eljusson a 2. hosztig. A gyakorlatban ez rendszerint sokkal több, mint hat hálózat.

5.6.1.

Az IP-protokoll

Az Internet hálózati rétegének tanulmányozásához jó kiindulási pont maguknak az IPdatagramoknak a formátuma. Egy IP-datagram egy fejrészből és egy szövegrészből áll. A fejrésznek van egy 20 bájtos rögzített része és egy változó hosszúságú opcioná­ lis része. A fejrész formátuma az 5.53. ábrán látható. Felsővég formában továbbítják: balról jobbra, a Verzió mező legmagasabb helyi értékű bitje megy elsőnek. (A SPARC felsővégű, a Pentium alsóvégű.) Az alsó vég-számítógépeken szoftveres átalakításra van szükség adáskor és vételkor is. A Verzió mező azt tartja nyilván, hogy a datagram a protokoll melyik verziójához tartozik. Azzal, hogy a verzió helyet kapott a datagramban, lehetségessé vált, hogy a verziók közti átmenet évekig is eltarthasson, miközben egyes gépeken még a régi, má­ sokon pedig már az új verzió fut. Jelenleg az IPv4 és az IPv6 közti átmenet zajlik már évek óta, és a folyamat még korántsem közelít a végéhez, lásd (Durand, 2001;

477

A HÁLÓZATI RÉTEG

32 bit • I

l

I

Verzió

I

I

I

IHL

L

I

I

I

1

L

[

l

l

l

l

1

I

I

l

l

i

j

Teljes hossz

Szolgálat típusa

Darabeltolás

Azonosítás Élettartam

J

Fejrész ellenőrző összege

Protokoll Forrás címe Cél címe

Opciók (0 vagy több szó)

5.53. ábra. Az IP- (Internet Protocol) fejrész Wiljakka, 2002; valamint Waddington és Chang, 2002) munkáit. Vannak, akik egye­ nesen azt gondolják, hogy az átállás sosem fog megtörténni, lásd (Weiser, 2001) írá­ sát. Ha már a számozásnál tartunk, megemlítjük, hogy az IPv5 egy kísérleti, valós idejű, élő közvetítéses protokoll volt, amit sosem használtak széles körben. Mivel a fejrész hossza nem állandó, a fejrész egy mezője, az IHL, szolgál arra, hogy 32 bites szavakban megadja a fejrész hosszát. A legkisebb érték 5, ez esetben semmilyen opció nem szerepel. Ennek a 4 bites mezőnek a maximális értéke 15, amely 60 bájtra korlátozza a fejrészt, ennélfogva az opciókat 40 bájtra. Néhány opció­ hoz, mint pl. az, amelyik a csomag által megtett utat jegyzi fel, a 40 bájt túl kicsi, ez­ által az opció értelmét veszti. A Szolgálat típusa mező azon kevés mezők egyike, melyek jelentése (kissé) meg­ változott az évek során. Azonban akárcsak régen, még ma is arra szánják, hogy kü­ lönbséget tegyen az eltérő szolgáltatási osztályok között. A megbízhatóságnak és a sebességnek számos kombinációja képzelhető el. A digitalizált hang számára a gyors kézbesítés fontosabb, mint a pontos kézbesítés. A fájlátvitel számára viszont a hiba­ mentes átvitel fontosabb a gyors átvitelnél. A 6 bites mező eredetileg a következőket tartalmazta (balról jobbra): egy három­ bites Precedencia mezőt, és három jelzőbitet, D-t, T-t és R-t. A Precedencia mező ér­ téke a prioritásnak felelt meg, 0-tól (normál csomag) 7-ig (hálózati vezérlőcsomag). A három jelzőbit lehetővé tette a hosztnak, hogy megmondja, mi neki a legfontosabb a {Késleltetés (Delay), Átbocsátás (Throughput), Megbízhatóság (Reliability)} halmaz­ ból. Elméletben ezek a mezők teszik lehetővé a routerek számára, hogy válasszanak például egy nagy átbocsátóképességű és nagy késleltetésű műholdas kapcsolat, és egy kis átbocsátóképességű és kis késleltetésű bérelt vonal között. A gyakorlatban azon­ ban a mai routerek gyakran teljes egészében figyelmen kívül hagyják a Szolgálat típu­ sa mezőt. Az IETF aztán végül bedobta a törölközőt, és kicsit megváltoztatta a mezőt, hogy alkalmazkodjon a differenciált szolgáltatásokhoz. A hat bitet ma arraiiasználják, hogy

478

SZÁMÍTÓGÉP-HÁLÓZATOK

jelezzék, hogy az előbb tárgyalt szolgáltatási osztályok közül melyikhez tartozik a csomag. Ezek az osztályok magukba foglalják a négy sorba állítási prioritást, a három eldobási valószínűséget, és a történelmi osztályokat. A Teljes hossz-ba. a datagram minden része beleértendő, a fejrész és az adatrész is. A maximális hossz 65 535 bájt. Jelenleg ez a felső korlát még elmegy, de a jövőbeni gigabites hálózatoknál nagyobb datagramokra lehet majd szükség. Az Azonosítás mező ahhoz szükséges, hogy a célhoszt eldönthesse, melyik datagramhoz tartozik az újonnan érkezett darab. Egy datagram minden darabja ugyanazt az Azonosítás értéket tartalmazza. Egy kihasználatlan bit, majd két egybites mező következik. A DF jelentése: Ne Darabold (Don't Fragment). Ez egy, a routereknek szóló parancs, hogy ne darabolják fel a datagramot, mivel a cél képtelen a részek újbóli összerakására. Például amikor egy számítógép elindul, a ROM-ja kérheti, hogy küldjenek el neki egy memóriaképet egyetlen datagramban. Ezt a datagramot a DF bittel megjelölve, az adó tudja, hogy egy darabban fog megérkezni, még ha ez azt is jelenti, hogy el kell kerülnie egy kiscsomagos hálózatot a legjobb úton, és egy optimálisnál rosszabb útvonalat kell hasz­ nálnia. Minden gépnek kötelessége elfogadnia az 576 bájtos vagy kisebb darabokat. Az MF jelentése: Több Darab (More Fragments). Minden darabban, kivéve az utol­ sóban, be kell állítani ezt a bitet. Ahhoz kell, hogy tudjuk, vajon egy datagram minden darabja megérkezett-e. A Darabeltolás (Fragment Offset) megmondja, hova tartozik a mostani darab a datagramban. Egy datagram minden darabjának - kivéve az utolsót - 8 bájt többszö­ rösének kell lennie, mert ez az elemi darabméret. Mivel 13 bit áll rendelkezésre, ez legfeljebb 8192 darabot jelent datagramonként, amely 65 536 bájtos maximális datagramhosszt eredményez, eggyel nagyobbat, mint amit a Teljes hossz mező lehetővé tesz. Az Élettartam mező egy számláló, amelyet a csomag élettartamának korlátozására használnak. Ez elvileg az időt mérné másodpercekben, ezáltal maximálisan 255 má­ sodperc hosszú életet tenne lehetővé. Minden átugrásnál csökkenteni kell, és ha hoszszú ideig állt sorban egy routerben, akkor elvileg többször is csökkenteni kellene. Gyakorlatilag csak az átugrásokat számolja. Amikor eléri a nullát, a csomagot el kell dobni, és egy figyelmeztető csomagot kell küldeni vissza a forráshoszthoz. Ez a tulaj­ donság megelőzi, hogy a datagramok a végtelenségig kóboroljanak, ami egyébként megtörténhetne, ha a forgalomirányító táblázatokba valamikor hiba csúszna. Amikor a vételi oldalon a hálózati réteg összeállított egy teljes datagramot, tudnia kell, mit tegyen vele. A Protokoll mező mondja meg, melyik szállítási folyamatnak adja át. Lehetséges a TCP, de az UDP és pár másik is. A protokollok számozása az Interne­ ten egységes. A protokollok számozását és a többi számkiosztást az RFC 1700 tartal­ mazta, de ma már egy on-line adatbázisban találhatók a www.iana.org weboldalon. A Fejrész ellenőrző összeg csak a fejrészt ellenőrzi. Egy ilyen ellenőrző összeg hasznos a routereken belüli rossz memóriaszavak által előidézett hibák kijelzésére. Az algoritmus az, hogy egyes komplemens aritmetikával az érkezés sorrendjében adjuk össze a 16 bites félszavakat, és vegyük az eredmény egyes komplemensét. Ezen algo­ ritmus alapján a Fejrész ellenőrző összeget a csomag érkezésekor nullának várjuk. Ez az algoritmus robusztusabb, mintha egy normális (aritmetikai) összeadást használna. Vegyük észre, hogy a Fejrész ellenőrző összeget minden átugrásnál újra kell számíta-

479

A HÁLÓZATI RÉTEG

Opció

Leírás

Biztonság Szigorú forrás általi forgalomirányítás

Meghatározza, mennyire titkos a datagram

Laza forrás általi forgalomirányítás

Felsorolja a felkeresendő routereket

Útvonal feljegyzése

Minden router fűzze hozzá az IP-címét

Időbélyeg

Minden router fűzze hozzá az IP-címét és az időbélyegét

Megadja a teljes követendő utat

5.54. ábra. Néhány IP-opció ni, mivel legalább egy mező mindig változik (az Élettartam mező), de használhatók trükkök a számítás felgyorsítására. A Forrás címe és Cél címe mutatja a hálózat számát és a hoszt számát. Az internet­ címeket a következő részben tárgyaljuk. Az Opciók mező egy menekülési útvonal, amelyet arra terveztek, hogy a protokoll következő verzióinak lehetőségük legyen olyan információkat bevenni, amelyek az eredeti tervben nem voltak jelen, hogy kí­ sérletezhessenek új ötletek kipróbálásával, és hogy ne kelljen olyan információk szá­ mára is fejrészbiteket lefoglalni, amelyekre csak ritkán van szükség. Az opciók válto­ zó hosszúságúak. Mindegyik egy egybájtos, az opciót azonosító kóddal kezdődik. Né­ hány opciónál ezt egy egybájtos hosszmező követi, majd egy vagy több adatbájt. Az Opció mezőt négy bájt többszörösére töltik ki. Eredetileg öt opció létezett, ahogy az az 5.54. ábrán látszik, de azóta néhány újat is definiáltak. A teljes, aktuális listát im­ már a www.iana.org/assignments/ip-parameters weboldalon gondozzák. A Biztonság opció azt mondja meg, milyen titkos az információ. Elméletben egy katonai router használhatná ezt a mezőt arra, hogy ne irányítson bizonyos, a katonaság szempontjából „rosszfiúnak" minősülő országokon keresztül. A gyakorlatban minden router figyelmen kívül hagyja, így az egyetlen gyakorlati funkciója az, hogy a kémek könnyebben megtalálhassák a jó dolgokat. A Szigorú forrás általi forgalomirányítás opció IP-címek sorozataként megadja a teljes utat a forrástól a célig. A datagramnak pontosan ezt az utat kell követnie. Ez na­ gyon hasznos rendszermenedzserek számára, hogy vészcsomagokat küldjenek a forga­ lomirányító táblák meghibásodása esetén, vagy időzítési méréseket végezzenek. A Laza forrás általi forgalomirányítás opció megköveteli a csomagtól, hogy a megadott routereken, a megadott sorrendben áthaladjon, de útközben áthaladhat más routereken is. Rendesen ez az opció csak egy pár routert bocsát rendelkezésre, hogy egy bizonyos utat kényszerítsen ki. Például, hogy egy Londonból Sydneybe tartó cso­ magot kelet helyett nyugat felé kényszerítsünk, ez az opció például megadhat New York-i, Los Angeles-i és honolului routereket. Ez az opció nagyon hasznos, ha politi­ kai vagy gazdasági megfontolásokból keresztül kell haladni bizonyos országokon, vagy el kell kerülni azokat. Az Útvonal feljegyzése opció arra utasítja az útba ejtett routereket, hogy az IPcímüket fűzzék hozzá az opció mezőhöz. Ez lehetővé teszi a rendszermenedzserek­ nek, hogy kinyomozzák a hibákat a router algoritmusokban. (,,Miért keresik fel a Houstonból Dallasba menő csomagok először mind Tokiót?") Amikor az ARPANET

480

SZÁMÍTÓGÉP-HÁLÓZATOK

először létrejött, egyik csomag sem érintett kilenc routernél többet, így az opció 40 bájtja bőségesen elegendő volt. Ahogy fentebb említettük, most már túl kicsi. Végül az Időbélyeg opció olyan, mint az Útvonal feljegyzése opció, kivéve, hogy minden router a 32 bites IP-címe mellé egy 32 bites időbélyeget is feljegyez. Ez az opció is főleg a router algoritmusok hibakereséséhez való.

IP-címek

5.6.2.

Az Interneten minden hosztnak és routernek van egy IP-címe, amely a hálózat számát és a hoszt számát kódolja. A kombináció egyedi: elméletileg nincs két olyan gép, amelynek ugyanaz az IP-címe. Minden IP-cím 32 bit hosszú és az IP-csomagok For­ rás címe és Cél címe mezőikben hordozzák. Fontos megjegyezni, hogy az IP-cím va­ lójában nem egy hoszthoz tartozik. Igazából egy hálózati interfészre utal, tehát ha egy hoszt két hálózathoz is csatlakozik, akkor két IP-címének is kell lennie. Mindazonáltal a gyakorlatban a legtöbb hoszt egy hálózathoz csatlakozik, így csak egy IP-címe van. Az IP-címeket több évtizeden keresztül az 5.55. ábrán látható öt kategóriába so­ rolták. Ez a kiosztás az osztályos címzés (classful addressing) elnevezést kapta. Ma már nem használják, de az irodalomban még gyakran hivatkoznak rá. Rövidesen megtárgyaljuk az osztályos címzés utódait. Az A, B, C és D osztályú formátumok lehetőségei: 128 hálózat, egyenként 16 mil­ lió hoszttal, 16 384 hálózat legfeljebb 64 K hoszttal, és kétmillió hálózat (pl. LAN-ok) egyenként legfeljebb 256 hoszttal (bár ezek közül néhány különleges eset). Támoga­ tott továbbá a többesküldés is, ahol is egy datagramot több hoszthoz irányítanak. Az 1111-el kezdődő címeket későbbi használatra tartják fenn. Ma már több mint 500 000 hálózat csatlakozik az Internethez, és ez a szám évről évre nő. A hálózatszámokat az ICANN (Internet Corporation for Assigned Nantes and Numbers, Kiosztott Ne32 bit _ I I I .

i

i

i

i

i

i

i

i

i

i

i

i

i

i

i

i

i

i

i

Hoszt

Hálózat

B

10

C

110

i

Hosztcímek tartománya

Oszt ály A 0

i

128.0.0.0-tól 191.255.255.255-ig

Hoszt

Hálózat Hálózat

1.0.0.0-tól 127.255.255.255-ig

Hoszt

192.0.0.0-tól 223.255.255.255-ig

D

1110

Többesküldéses cím

224.0.0.0-tól 239.255.255.255-ig

E

1111

Jövőbeli felhasználásra fenntartva

240.0.0.0-tól 255.255.255.255-ig

5.55. ábra. IP-címformátumok

481

A HÁLÓZATI RÉTEG

vek és Számok Internet Társasága) nevű nonprofit szervezet kezeli a konfliktusok elkerülése végett. Az ICANN pedig különböző helyi hatóságokra bízta a címtér egy részét, hogy azok osszák ki az IP-címeket az internetszolgáltatóknak és más vállala­ toknak. A hálózati címeket, amelyek 32 bites számok, rendszerint pontokkal elválasztott decimális jelölésrendszerben (dotted decimai notation) írják. Ebben a formátum­ ban minden 4 bájtot tízes számrendszerben írnak ki, 0-tól 255-ig, például a C0290614 hexadecimális címet 192.41.6.20-ként írják. A legkisebb IP-cím a 0.0.0.0 és a legna­ gyobb a 255.255.255.255. 00000000000000000000000000000000 0 0

Egy hoszt ezen a hálózaton

Hoszt

0 0

11111111111111111111111111111111 Hálózat

1111

1111 (Bármi)

127

Ez a hoszt

Adatszórás a helyi hálózaton Adatszórás egy távoli hálózaton Visszacsatolás

5.56. ábra. Különleges IP-címek A 0 és -1 értékeknek speciális jelentéseik vannak, ahogy az 5.56. ábrán látszik. A 0 érték jelentése: ez a hálózat vagy ez a hoszt. A -1-et adatszóró címként használják, és a jelzett hálózat összes hosztját értik alatta. A 0.0.0.0 IP-címet a hosztok az elindulásuk alatt használják. Az olyan IP-címek, amelyeknek a hálózatszáma 0, az aktuális hálózatra vonatkoznak. Ezek a címek lehe­ tővé teszik a gépeknek, hogy a saját hálózatukra hivatkozzanak anélkül, hogy tudnák a számát. (De az osztályát ismerniük kell, hogy tudják, hány 0-t tegyenek az elejére.) A csupa 1-ből álló cím az adatszórást teszi lehetővé a helyi hálózaton, jellemzően egy LAN-on. A helyes hálózatcímmel és csupa 1 hoszt mezővel rendelkező címek lehető­ vé teszik adatszóró csomagok küldését az interneten bárhol elhelyezkedő távoli LANokra. Végül, az összes 127.xx.yy.zz formájú cím fenntartott a visszacsatolásos teszte­ lésre. Az erre a címre küldött csomagok nem kerülnek ki a vezetékre; helyileg dolgoz­ zák fel és bejövő csomagokként kezelik azokat. Ez lehetővé teszi csomagok küldését a helyi hálózatra anélkül, hogy az adó ismerné annak számát. Alhálózatok Amint azt láttuk, egy hálózatban minden hosztnak ugyanazzal a hálózatszámmal kell rendelkeznie. Az IP-címzésnek ez a tulajdonsága a hálózatok növekedtével gondokat okozhat. Tekintsünk például egy egyetemet, ahol kezdetben egy darab B osztályú há­ lózat volt a Számítástudományi Tanszék Ethernet-hálózatán lévő gépek számára. Egy évvel később a Villamosmérnöki Tanszék is ki akart kerülni az Internetre, vettek hát

482

SZÁMÍTÓGÉP-HÁLÓZATOK

egy ismétlőt, hogy kiterjesszék a SZT Ethernet-hálózatát a saját épületükig. Ahogy az idő haladt, sok más tanszék is szerzett számítógépeket, és gyorsan elérték a négy is­ métlő/Ethernet-határt. Más szervezésre volt tehát szükség. Új hálózati címhez nem lett volna könnyű hozzájutni, mivel a hálózati címek szű­ kös erőforrásnak számítottak, és az egyetemnek már amúgy is volt több mint 60 000 hoszt számára elegendő címe. A gondot az okozta, hogy egy A, B vagy C osztályú cím egy adott hálózatra, nem pedig LAN-ok egy gyűjteményére vonatkozott. Miután egyre több szervezet került ilyen helyzetbe, kissé megváltoztatták a címzési rendszert, hogy kezeljék a problémát. A megoldás az, hogy megengedjük, hogy egy hálózat a belső felhasználás szem­ pontjából több részre osztódjon, miközben a külvilág számára továbbra is egyetlen hálózatként látszik. Egy tipikus mai egyetemi hálózat az 5.57. ábrához hasonlóan néz­ het ki, ahol a központi router egy internetszolgáltatóhoz vagy regionális hálózathoz, illetve számos, az egyetem területén szétszórt Ethernet-hálózathoz csatlakozik. Min­ den Ethernet-hálózatnak saját routere van, amivel a központi routerhez kapcsolódik (valószínűleg egy gerinc LAN-on keresztül, de a routerek közötti kapcsolatok most nem lényegesek). Az Internet irodalmában a hálózat részeit (ez esetben az Ethernet-hálózatokat) alhálózatoknak (subnets) nevezik. Amint azt az 1. fejezetben említettük, ez a szó­ használat ütközik az „alhálózat" szó azon jelentésével, ahol az egy hálózatban levő routerek és kommunikációs vonalak összességét értjük alatta. A szövegkörnyezetből azonban remélhetőleg ki fog derülni, hogy melyik jelentésre gondoltunk. Ebben a szakaszban és a következőben csak az új definíciót használjuk. Amikor beérkezik egy csomag, honnan fogja tudni a központi router, hogy melyik alhálózatnak (Ethernetnek) kell átadnia? Lehetne mondjuk egy 65 536 bejegyzésből álló táblázat a központi routerben, ami az egyetem minden hosztjához megmondja, hogy melyik routert kell használni. Ez még működne is, de a központi router tábláza­ tának nagyon nagynak kéne lennie, és sok kézi karbantartásra lenne szükség, amikor hosztokat beraknánk, áthelyeznénk vagy kivonnánk a forgalomból.

Router Művészeti tanszék Angol nyelvi tanszék

?????

Francia nyelvi tanszék

????? ?????

Zenei tanszék

Az internet­ szolgáltató felé

PC

????? 'A331W ????? ????? X. ' Ethernet

5.57. ábra. Egy egyetemi hálózat, mely több tanszéki LAN-ból áll

Számítás­ tudományi tanszék Villamos­ mérnöki tanszék Matematika­ tanszék Fizika­ tanszék

A HÁLÓZATI RÉTEG

483

.. I

32 bit i

i

i

i

i

i

I

i

i

i

Hálózat

10

maszk

i

i

i

i

i

— I

i

i

i

i

i

i

i

Alhálózat

I

i

I

Hoszt

11111111111111111111110000000000

5.58. ábra. Egy B osztályú hálózat 64 alhálózatra való felosztására Egy másik sémát találtak hát ki ehelyett. Alapvetően, ahelyett, hogy egyetlen B osztályos címet használnánk, ahol 14 bites a hálózat száma és 16 bites a hosztok szá­ ma, néhány bitet elveszünk a hosztok számából, hogy létrehozzunk egy alhálózatszá­ mot. Például, ha az egyetemnek 35 tanszéke van, akkor használhat 6 bites alhálózat­ számot és 10 bites hosztszámot. Ez lehetővé tesz 64 Ethernet-hálózatot, mindegyiken 1022 hoszttal (a 0 és a -1 nem megengedett, amint már említettük). Ezt a felosztást később meg is lehet változtatni, ha kiderül róla, hogy nem jó. Az alhálózatokra osztás megvalósításához a központi routernek szüksége van egy alhálózati maszkra (subnet mask), ami a hálózat- és alhálózatszám, valamint a hosztszám közötti felosztást jelzi, ahogy azt az 5.58. ábra mutatja. Az alhálózati maszkok szintén a pontozott decimális jelölésrendszerben íródnak, kiegészítve egy / jellel és azt követően a hálózati + az alhálózati rész bitjeinek számával. Az 5.58. ábra példájánál az alhálózati maszk 255.255.252.0. A másik jelölésben a/22 jelzi azt, hogy az alhálózati maszk 22 bit hosszú. A hálózaton kívül nem látszik az alhálózatokra való felosztás, így egy új alhálózat kialakításához nem kell felvenni a kapcsolatot az ICANN-nel, vagy megváltoztatni bármilyen külső adatbázist. Ebben a példában az első alhálózat használhatja az IPcímeket 130.50.4.1-től kezdődően; a második kezdheti 130.50.8.I-nél; a harmadik 130.50.12.I-nél és így tovább. Hogy megértsük, hogy miért négyesével változnak az alhálózatszámok, vegyük szemügyre a nekik megfelelő bináris számokat: 1. alhálózat: 2. alhálózat: 3. alhálózat:

10000010 10000010 10000010

00110010 00110010 00110010

000001100 00000001 000010100 00000001 000011100 00000001

Itt a függőleges vonal (I) mutatja az alhálózatszám és a hosztszám közti határt. Tőle balra van a 6 bites alhálózatszám, jobbra pedig a 10 bites hosztszám. Ahhoz, hogy megértsük, hogyan működnek az alhálózatok, el kell magyaráznunk, hogyan dolgozza fel a router az IP-csomagokat. Minden routernek van egy táblázata néhány (hálózat, 0) alakú IP-címmel, és néhány (saját hálózat, hoszt) alakú IPcímmel. Az első típus megmondja, hogyan érhetők el a távoli hálózatok, a második pedig megmondja, hogyan érhetők el a helyi hosztok. A táblázathoz csatolva megta­ lálható az is, hogy melyik címzett felé melyik hálózati illesztőt kell használni, és bi­ zonyos egyéb információk is. Amikor egy IP-csomag megérkezik, megkeresik a célcímét a forgalomirányító táblázatban. Ha a csomag egy távoli hálózatba tart, továbbítják a következő routerhez

484

SZÁMÍTÓGÉP-HÁLÓZATOK

a táblázatban megadott illesztőn keresztül. Ha a cél csomópont egy helyi hoszt (pl. a router LAN-ján), akkor elküldik közvetlenül a címzettnek. Ha a hálózati rész nem ta­ lálható, a csomagot továbbítják az alapértelmezett routerhez, aminek részletesebb táblázatai vannak. Ezzel az algoritmussal tehát minden routernek elég a többi hálóza­ tot és a helyi hosztokat nyilvántartania, nem pedig (hálózat, hoszt) párokat, ami nagy­ ban csökkenti a forgalomirányító táblázat méretét. Amikor az alhálózatokra osztást bevezetik, a forgalomirányító táblázatokat is meg­ változtatják, (saját hálózat, alhálózat, 0) és (saját hálózat, saját alhálózat, hoszt) alakú bejegyzések hozzáadásával. így a k alhálózaton lévő router tudni fogja, hogy hogyan érheti el a többi alhálózatot, valamint a k alhálózaton lévő hosztokat. Más alhálózato­ kon lévő hosztokról nem kell tudnia részleteket. Valójában csak annyit kell megvál­ toztatni, hogy minden routernek egy logikai ÉS műveletet kell végeznie az alhálózati maszkkal, hogy megszabaduljon a hosztszámtól, és az eredményül kapott címet kike­ resse a táblázatából (miután megállapította, hogy melyik hálózati osztályhoz tartozik). Például, ha egy, a 130.50.15.6 címre küldött csomagot a központi routerbe érkezve ÉS kapcsolatba hozunk a 255.255.252.0/22 alhálózati maszkkal, akkor megkapjuk a 130.50.12.0 címet. Ezt azután kikeressük a forgalomirányító táblázatokból, hogy megtudjuk, melyik kimeneti vonalat kell használni, hogy eljussunk a 3. alhálózat routeréig. Az alhálózatokra osztás tehát csökkenti a routerekben a forgalomirányító táblázatok méretét azáltal, hogy egy, a hálózatokból, alhálózatokból és hosztokból ál­ ló, háromszintű hierarchiát hoz létre.

CIDR - Osztálynélküli körzetek közti forgalomirányítás Az IP-t már évtizedek óta intenzíven használják. Eddig rendkívül jól működött, ahogy azt az Internet exponenciális növekedése is megmutatta. Sajnos az IP gyors tempóban lesz saját népszerűségének áldozata: kezd kifogyni a címekből. Ez a fenyegető végzet sok tárgyalást és vitát szült az Internet közösségén belül arról, hogy mit is lehetne ez ellen tenni. Ebben a szakaszban megtárgyaljuk a problémát és a megoldási javaslato­ kat is. Pár látnók még 1987-ben megjósolta, hogy egy napon az Internet 100 000 hálóza­ tig növekedhet. A legtöbb szakértő ezt semmibe vette azzal, hogy ez évtizedekre van még, ha egyáltalán bekövetkezik. A 100 000. hálózatot 1996-ban kötötték be. A prob­ léma, ahogy említettük, az, hogy az Internet gyorsan fogy ki az IP-címekből. Elmélet­ ben több mint kétmilliárd cím létezik ugyan, de a címtartomány osztályok szerinti szervezésének gyakorlata (lásd az 5.55. ábrát) ebből milliókat elveszteget. Az igazi bajkeverők konkrétan a B osztályú hálózatok. A legtöbb szervezetnek egy 16 millió címmel rendelkező A osztályú hálózat túl nagy, míg egy C osztályú hálózat 256 cím­ mel túl kicsi. Egy 65 536 címmel rendelkező B osztályú hálózat viszont pont jó. Az Internet folklórjában ez a helyzet a három medve problémája (three bears probIem, mint a hasonló című mesében) néven ismert. A valóságban egy B osztályú cím túl nagy a legtöbb szervezetnek. Tanulmányok­ kal is kimutatták, hogy az összes B osztályú hálózatnak több mint a fele kevesebb, mint 50 hoszttal rendelkezik. Ezeknél egy C osztályú hálózat is megtette volna, de

A HÁLÓZATI RÉTEG

485

nyilván minden B osztályú címet kérö szervezet úgy gondolta, hogy egy napon kinőné a 8 bites hosztmezőt. Visszatekintve, lehet, hogy jobb lett volna, ha a C osztályú háló­ zatok 8 helyett 10 bitet használtak volna a hosztszámra, amely így hálózatonként 1022 hosztot tenne lehetővé. Ebben az esetben a legtöbb szervezet valószínűleg belenyugo­ dott volna egy C osztályú címbe, és ezekből félmillió darab lehetne (szemben a mind­ össze 16 384 B osztályú hálózattal). Nehéz az Internet tervezőit hibáztatni azért, mert nem hagytak több (és kisebb) B osztályú címet. Azokban az időkben, amikor meghozták a döntést a három osztály lét­ rehozásáról, az Internet egy kutatási hálózat volt, ami a főbb amerikai kutatóegyete­ meket kötötte össze (és ezeken kívül még nagyon kevés céget és katonai támaszpon­ tot, melyek hálózati kutatással foglalkoztak). Senki sem látta az Internetben a jövő tömegpiaci kommunikációs rendszerét, ami még a telefonhálózattal is felveszi majd a versenyt. Azokban az időkben az emberek minden bizonnyal azt mondták: „Az USAnak körülbelül 2000 főiskolája és egyeteme van. Még ha az összes rá is kapcsolódik az Internetre, és más országokból is sok egyetem csatlakozik, akkor sem érjük el a 16 000-et, hiszen nincs is annyi egyetem az egész világon. Továbbá, ha a hosztszám egész számú bájtból áll, az gyorsítja a csomagok feldolgozását." Ugyanakkor, ha a felosztás 20 bitet rendelt volna a B osztályú hálózatszámhoz, egy másik probléma merült volna fel: a forgalomirányító táblázatok robbanása. A routerek szemszögéből nézve az IP-címtér egy kétszintű hierarchia, hálózatszámokkal és hosztszámokkal. A routereknek nem kell tudniuk a hosztokról, de mindenképp tudni­ uk kell az összes hálózatról. Ha félmillió C osztályú hálózatot használnánk, az Interneten minden routernek egy félmillió bejegyzésből álló táblázatra lenne szüksége. Minden hálózathoz lenne egy bejegyzés, ami egyebek közt megmondaná, hogy me­ lyik vonalat kell használni az adott hálózat felé. A félmillió bejegyzéses táblázatok fizikai tárolása valószínűleg megoldható, bár költséges kritikus routereknél, amelyek a táblázatokat statikus RAM-ban, B/K kártyá­ kon tartják. Egy komolyabb probléma, hogy a táblázatok kezeléséhez szükséges kü­ lönféle algoritmusok komplexitása lineárisnál gyorsabban nő. Még rosszabb, hogy sok létező router szoftverét és firmware-jét akkor tervezték, amikor az Internethez 1000 hálózat csatlakozott és a 10 000 hálózat még évtizedekre levőnek tűnt. Az akkor ho­ zott tervezési döntések ma már gyakran távolról sem optimálisak. Ezenfelül különféle forgalomirányító algoritmusok is megkövetelik a routerektől, hogy periodikusan szétküldjék táblázataikat (pl. a távolságvektor alapú protokollok). Minél nagyobbak a táblázatok, annál valószínűbb, hogy néhány rész útközben elve­ szik, ami a másik oldalon hiányos adatokhoz és esetleg forgalomirányítási zavarokhoz vezethet. A forgalomirányító táblázatok problémája megoldható lett volna mélyebb hierar­ chia használatával. Működhetne például egy olyan IP-cím, ami ország, állam/tarto­ mány, város, hálózat és hoszt mezőket tartalmazna. Ekkor minden routernek csak azt kéne tudnia, hogyan juthat egy adott országba, a saját országán belüli államok­ ba/tartományokba, a saját államában vagy tartományában lévő városokba, és a váro­ sán belüli hálózatokba. Sajnos ez a megoldás lényegesen több mint 32 bitet igényelne az IP-címek számára, és nem használná ki hatékonyan a címeket (Liechtensteinnek ugyanannyi bitje lenne, mint az Egyesült Államoknak).

486

SZÁMÍTÓGÉP-HÁLÓZATOK

Röviden szólva, egyes megoldások megoldanak egy problémát, de létrehoznak helyette egy újat. Az alkalmazásra került megoldás, ami egy kicsivel több lélegzethez jutatta az Internetet, a CIDR (Classless InterDomain Routing, osztálynélküli kör­ zetek közti forgalomirányítás). Az RFC 1519-ben leírt CIDR mögött az az alapötlet áll, hogy a maradék IP-címeket változó méretű blokkokban osszák ki, osztályokra való tekintet nélkül. Ha egy helynek mondjuk 2000 címre van szüksége, akkor egy 2048 címből álló blokkot kap, ami a 2048-as bájthatárra esik. Az osztályok elhagyása még bonyolultabbá teszi a továbbítást. A régi osztályos rendszerben a továbbítás a következők szerint működött. Amikor egy csomag megér­ kezett egy routerhez, az IP-címének másolatát 28 bittel jobbra léptették, hogy meg­ kapják a 4 bites osztályszámot. Ezután 16-felé szétválogatták a csomagokat A, B, C és D osztályra (ha ez támogatva volt), ahol nyolc eset tartozott az A osztályhoz, négy a B-hez, kettő a C-hez és egy-egy a D-hez és E-hez. Az egyes osztályok kódja ezután kimaszkolta a 8, 16 vagy 24 bites hálózatszámot, és jobbra igazította egy 32 bites szó­ ban. A hálózatszámot aztán kikeresték az A, B vagy C táblázatból, általában az A és a B hálózat szerint indexelve és a C szerint hashelve. Amint meglett a bejegyzés, ki le­ hetett keresni a kimeneti vonalat és a csomagot elküldték. A CIDR-rel ez az egyszerű algoritmus már nem működik. Ehelyett a forgalomirá­ nyító táblázatok minden bejegyzését egy 32 bites maszk hozzáadásával egészítik ki. így most egyetlen forgalomirányító táblázat van az összes hálózathoz, ami (IP-cím, alhálózati maszk, kimeneti vonal) hármasok tömbjéből áll. Amikor egy csomag beér­ kezik, először is kiveszik a célcímét. Azután (elvileg) bejegyzésről bejegyzésre végig­ nézik a forgalomirányító táblázatot, kimaszkolják a célcímet és összehasonlítják ^a bejegyzésekkel, hogy illeszkedést találjanak. Lehetséges, hogy több bejegyzés (külön­ böző hosszúságú alhálózati maszkokkal) is illeszkedik, ebben az esetben a leghoszszabb maszkot használják. Azaz, ha van illeszkedés a /20-as és a /24-es maszkra is, akkor a /24 bejegyzését használják. A címillesztés folyamatának felgyorsítására bonyolult algoritmusokat javasoltak (Ruiz-Sanchez és mások, 2001). A kereskedelmi routerek saját VLSI chipeket hasz­ nálnak, melyekbe ezt az algoritmust hardveresen beépítik. Hogy érthetőbbé tegyük a továbbítás algoritmusát, vegyünk egy példát, ahol milli­ ónyi cím áll a rendelkezésünkre a 194.24.0.0-tól kezdve. Tegyük fel, hogy a Camb­ ridge-i Egyetemnek 2048 címre van szüksége, mire kiosztják neki a 194.24.0.0-tól a 194.24.7.255-ig terjedő címeket, a 255.255.248.0 maszkkal együtt. Következőnek az Oxfordi Egyetem kér 4096 címet. Mivel a 4096 címből álló blokknak 4096-os bájt-

Egyetem

Hány hoszt?

Első cím

Utolsó cím

Cambridge

194.24.0.0

194.24.7.255

2048

194.24.0.0/21

Edinburgh

194.24.8.0

194.24.11.255

1024

194.24.8.0/22

(Nem használt)

194.24.12.0

194.24.15.255

1024

194.24.12.0/22

Oxford

194.24.16.0

164.24.31.255

4096

194.24.16.0/20

5.59. ábra. IP-cím kiosztások egy halmaza

Hogy írjuk?

487

A HÁLÓZATI RÉTEG

határra kell kerülnie, nem kaphatják meg a 194.24.8.0-tól kezdődő címeket. Ehelyett a 194.24.16.0-tól a 194.24.31.255-ig terjedő címeket kapják, a 255.255.240.0 alhálózati maszkkal együtt. Most az Edinburghi Egyetem kér 1024 címet, és megkapja őket 194.24.8.0-tól 194.24.11.255-ig a 255.255.252.0 maszkkal. Ezeket a kiosztásokat foglalja össze az 5.59. ábra. A forgalomirányító táblázatokba tehát világszerte bekerült a három imént kiosztott bejegyzés. Ezek (bináris alakban) a következők: Cím C: 11000010 00011000 00000000 00000000 E: 11000010 00011000 00001000 00000000 O: 11000010 00011000 00010000 00000000

Maszk 11111111 11111111 11111000 OOOOOOOC 11111111 11111111 11111100 OOOOOOOC 11111111 11111111 11110000 OOOOOOOC

Most pedig gondoljuk végig, mi történik, amikor beérkezik egy, a 194.24.27.4 címre küldött csomag. A cím bináris alakban a következő 32 bites karakterláncnak felel meg: 11000010 00011000 00010001 00000100 Először ezt logikai ÉS kapcsolatba hozzuk Cambridge maszkjával, így kapjuk a kö­ vetkezőt: 11000010 00011000 00010000 00000000 Ez az érték nem illeszkedik Cambridge alapcímére, az eredeti címet tehát a következő lépésben Edinburgh maszkjával hozzuk ÉS kapcsolatba: 11000010 00011000 00010000 00000000

Ez az érték Edinburgh alapcímére sem illeszkedik, így most Oxforddal próbálkozunk, az eredmény: 11000010 00011000 00010000 00000000 Ez már illeszkedik Oxford alapcímére. Ha a táblázatban tovább kutatva nem találunk ennél hosszabb illeszkedést, akkor az oxfordi bejegyzést fogjuk használni, és a cso­ mag az abban megnevezett vonalon lesz kiküldve. Most nézzük meg ezt a három egyetemet a Nebraska állambeli Omaha egy routerének szemszögéből, melynek csak négy kimeneti vonala van, Minneapolis, New York, Dallas és Denver felé. Amikor az ottani router szoftvere megkapja a három új bejegyzést, felismeri, hogy mindhármat összefoghatja egyetlen, csoportos bejegyzés­ sé (aggregáté entry): 194.24.0.0/19. Ennek bináris alakja és alhálózati maszkja a kö­ vetkező: 11000010 00011000 00000000 00000000

11111111 11111111 11100000 00000000

Ezen bejegyzés hatására a három egyetem közül bármelyiknek küldött csomagok New York irányába indulnak el. Az omahai routernek tehát a bejegyzések összefogása révén sikerült két bejegyzéssel csökkentenie a forgalomirányító táblázatának méretét.

488

SZÁMÍTÓGÉP-HÁLÓZATOK

Ha New York és London között egyetlen vonal van a teljes Nagy Britanniába menő forgalom számára, akkor New York szintén használhat csoportos bejegyzést. Ugyan­ akkor, ha London és Edinburgh felé külön vonalai vannak, akkor már három külön bejegyzést kell fenntartania. A csoportosítást szerte az Interneten intenzíven használ­ ják, hogy csökkentsék a routerek táblázatainak méretét. Példánkkal kapcsolatban utolsó megjegyzésként megemlítjük, hogy az omahai csoportos bejegyzés a még kiosztatlan címekre küldött csomagokat is New York felé irányítja. Ez nem is gond mindaddig, amíg ezek a címek valóban nincsenek kiosztva, mivel ekkor valószínűleg nem fordulnak elő ilyen csomagok. Ha azonban ezeket a címeket később kiosztják egy kaliforniai vállalatnak, akkor a 194.24.12.0/22 bejegy­ zés hozzáadására lesz szükség, hogy kezelni tudjuk ezeket a címeket is.

NAT - hálózati címfordítás Az IP-címek szűkös erőforrások. Ha egy internetszolgáltatónak mondjuk /16 (régeb­ ben B osztályú) címe van, akkor ezzel 65 534 darab hosztszámhoz jut. Ha ennél több ügyfele van, bajban van. Az otthoni, tárcsázós kapcsolattal rendelkező előfizetők ese­ tében a probléma megkerülhető azzal, ha a bejelentkező számítógép dinamikusan kap IP-címet, amit vissza is vesznek, amikor a kapcsolat véget ér. Ily módon egyetlen /16os címmel akár 65 534 aktív felhasználó is kiszolgálható, ami valószínűleg egy több százezer előfizetővel rendelkező internetszolgáltató számára is elegendő. Amikor egy kapcsolat lebomlik, az IP-címet egy másik hívónak adják. Ez a stratégia működik ugyan az olyan szolgáltatóknál, melyeknek közepesen sok otthoni felhasználójuk van, de csődöt mond azoknál, akik elsősorban üzleti felhasználókat szolgálnak ki. A gondot az jelenti, hogy az üzleti felhasználók folyamatos on-line kapcsolatot szeretnének a munkaidő alatt. Mind a kis cégek, mint például egy három személyből álló utazási iroda, mind a nagyvállalatok több számítógéppel rendelkeznek, melyeket LAN köt össze. Néhány számítógép alkalmazotti PC; mások lehetnek mondjuk webkiszolgálók. Általában egy router is van a LAN-on, melyet bérelt vonal köt össze a szolgáltatóval a folyamatos elérhetőség érdekében. Ez a felállás azt vonja maga után, hogy minden számítógépnek egész nap szüksége van az IP-címére. Ennek ered­ ményeképp a szolgáltató üzleti ügyfeleinek összesen nem lehet több számítógépe, mint ahány IP-címe van a szolgáltatónak. Ez egy /16-os cím esetén 65 534-re korlá­ tozza a gépek számát. Egy több tízezer üzleti ügyféllel rendelkező szolgáltató pedig gyorsan túllépi ezt a határt. A dolgot tovább nehezíti, hogy egyre több otthoni felhasználó fizet elő az internetre ADSL-en vagy kábelhálózaton keresztül. Ezekre a szolgáltatásokra az jellemző, hogy (1) a felhasználó állandó IP-címet kap és (2) nincsenek percdíjak (csak egy havi alap­ díj), így sok ADSL- és kábelfelhasználó állandóan be van jelentkezve a hálózatba. Ez­ zel a fejlődéssel csak tovább nő az IP-címek hiánya. A tárcsázós esethez hasonló, menet közbeni IP-címkiosztásnak itt nincs értelme, mert a használatban lévő IP-címek száma bármely pillanatban többszöröse lehet a szolgáltató által birtokolt címek számának. Hogy még tovább bonyolítsuk a dolgokat, sok ADSL és kábelfelhasználó rendel­ kezik otthon több számítógéppel, gyakran minden családtagnak van egy, és mindany-

489

A HÁLÓZATI RÉTEG

nyian egész nap on-line akarnak lenni annak az egyetlen IP-címnek a felhasználásá­ val, amit a szolgáltató adott nekik. Azt a megoldást használják, hogy az otthoni PCket egy LAN-nal kötik össze, amire egy routert is tesznek. A szolgáltató szemszögé­ ből a család ezután ugyanolyan, mint egy néhány számítógépes kisvállalat. Üdvözöl­ jük a Kovács Rt.-nél. Az IP-címek kifogyásának kérdése nem elvi probléma, ami talán valamikor a távoli jövőben fog előfordulni. Ez itt és most történik. A hosszú távú megoldás az, hogy az egész Internet átáll az IPv6-ra, ami 128 bites címeket használ. Az átállás lassan meg is kezdődik, de még évek telnek el, mire befejeződik. Ezért gondolták néhányan azt, hogy rövid távon egy gyors javításra van szükség. Ez a gyors javítás a NAT (Network Address Translation, hálózati címfordítás) képében jött el. A NAT-ot az RFC 3022 írja le, és mi is összefoglaljuk az alábbiakban. További információkért lásd (Duteher, 2001) munkáját. A NAT alapötlete az, hogy az internetforgalom számára minden cégnek egyetlen egy (vagy legalábbis kevés számú) IP-címet osztanak ki. Egy vállalaton belül minden számítógép egyedi IP-címet kap, amit a házon belüli forgalom irányításához használ­ nak. Amikor viszont egy csomag elhagyja a vállalatot, és kimegy az internetszolgálta­ tó felé, akkor címfordításra kerül sor. Mindezt az teszi lehetővé, hogy három IP-címtartományt jelöltek ki privát használatra. A vállalatok saját berkeiken belül úgy hasz­ nálják fel ezeket, ahogyan akarják. Az egyetlen kikötés az, hogy magán az interneten nem jelenhet meg olyan csomag, ami ezeket a címeket tartalmazza. A három fenntar­ tott címtartomány: 10.0.0.0 172.16.0.0 192.168.0.0

-10.255.255.255/8 -172.31.255.255/12 -192.168.255.255/16

(16 777 216 hoszt) (1 048 576 hoszt) (65 536 hoszt)

Az első tartomány 16 777 216 hoszt számára nyújt elegendő címet (leszámítva a 0-t és -1-et, mint mindig), a legtöbb vállalat ezt is választja, még akkor is, ha nincs is szükségük ennyi címre. A NAT működését az 5.60. ábra mutatja be. A vállalat határain belül minden gép­ nek egyedi címe van, ÍO.x.y.z alakban. Ha azonban egy csomag elhagyja a vállalat területét, akkor áthalad egy NAT-dobozon (NAT box), ami átalakítja a belső IP-forrás csomópont címét, vagyis az ábrán a 10.0.0.1-et a vállalat tényleges IP-címére, ami pél­ dánkban 198.60.42.12. A NAT-dobozt gyakran a tűzfallal együtt, egy eszközben valósít­ ják meg, mert a tűzfal a biztonság érdekében amúgy is gondosan megvizsgálja, hogy mi jön be a vállalathoz, és mi lép ki onnan. A tűzfalakat a 8. fejezetben fogjuk tanulmá­ nyozni. A NAT-dobozt ezenkívül akár a vállalati routerrel is egybeépíthetjük. Eddig még mindig átsiklottunk egy apró részlet fölött: amikor a válasz visszaérke­ zik (pl. egy webkiszolgálótól), természetesen a 198.60.42.12 címre küldik. Honnan fogja ekkor a NAT-doboz tudni, hogy melyik címre cserélje ezt ki? Ebben rejlik a NAT problémája. Ha lenne még egy maradék mező az IP-fejrészben, azt felhasznál­ hatnánk arra, hogy nyomon kövessük, ki volt az eredeti feladó; de már csak egy 1 bit maradt kihasználatlanul. Elvileg készíthetnénk egy új opciót, ami az eredeti forráscí­ met tartalmazná, de ehhez az egész Internet összes gépének szoftverét meg kellene

490

SZÁMÍTÓGÉP-HÁLÓZATOK

Vállalati LAN

, Csomag a fordítás előtt Csomag a fordítás után

/ 198.60.42.12

-o NAT-doboz/ tűzfal Kiszolgáló

Bérelt vonal

Internet-szolgáltató routere

Vállalati létesítmények határa

5.60. ábra. A NAT-doboz elhelyezése és működése változtatni, hogy kezeljék ezt az új opciót. Ez nem túl ígéretes alternatíva egy gyors javítás számára. Valójában a következő történt. A NAT tervezői megfigyelték, hogy a legtöbb IPcsomag TCP- vagy UDP-tartalmat hordoz. Amikor a 6. fejezetben tanulmányozni fogjuk a TCP-t és az UDP-t, látni fogjuk, hogy mindkettejük fejrésze tartalmaz egy forrás port és egy cél port mezőt. Az alábbiakban csak a TCP-portokat tárgyaljuk, de ugyanaz érvényes az UDP-portokra is. A portok 16 bites egészek, melyek azonosítják, hogy hol kezdődik és végződik egy TCP-kapcsolat. Ezek a portok lesznek tehát azok a mezők, amikre a NAT működéséhez szükségünk van. Amikor egy folyamat egy TCP-kapcsolatot szeretne kiépíteni egy másik, távoli folyamattal, akkor hozzácsatolja magát egy addig a saját gépén nem használt TCPporthoz. Ezt nevezzük forrás portnak (source port), és ez mondja meg a TCPszoftvemek, hogy hová küldje az adott kapcsolathoz tartozó bejövő csomagokat. A folyamat megad egy cél portot (destination port) is, hogy megmondja, kinek kell a csomagokat adni a távoli oldalon. A 0-1023-ig terjedő portokat a jól ismert szolgál­ tatások számára tartották fenn. A webkiszolgál ók például a 80-as portot használják, így a távoli kliensek könnyen megtalálják őket. Minden kimenő TCP-üzenet tartalmaz egy forrás és egy cél portot is. Ez a két port együtt azonosítja a kapcsolatot használó folyamatokat mindkét végponton. Egy hasonlat talán világosabbá teszi a portok használatát. Képzeljünk el egy válla­ latot egy darab központi telefonszámmal. Amikor az emberek felhívják a központi számot, akkor egy központossal beszélhetnek, aki megkérdi, melyik melléket kérik, majd kapcsolja a kért melléket. A központi szám hasonló a vállalat IP-címéhez, a kap­ csolat két végén a mellékek pedig hasonlók a portokhoz. A portok tulajdonképpen to­ vábbi 16 bitet adnak a címzéshez, hogy azonosítsák, melyik folyamat melyik bejövő csomagot kapja meg. A Forrás port mező használatával megoldhatjuk a leképezési problémánkat. Ami-

A HÁLÓZATI RÉTEG

491

kor egy kilépő csomag eléri a NAT-dobozt, a 10.x.y.z forráscímet lecseréljük a vállalat igazi IP-címére. Ezenkívül, a TCP Forrás port mezőt lecseréljük egy mutatóra, ami a NAT-doboz 65 536 bejegyzésből álló fordítási táblázatába mutat. A mutatott bejegy­ zés tartalmazza az eredeti IP-címet és az eredeti forrás portot. Végül az IP- és a TCPfejrészek ellenőrző összegeit is újraszámolják, és az eredményt beleírják a csomagba. Azért kell kicserélni a Forrás port mezőt, mert a 10.0.0.1 és a IQ.Q.0.2 gépekből in­ duló összeköttetések is használhatják például véletlenül az 5000-es portot, vagyis a Forrás port önmagában nem elég a feladó folyamat azonosítására. Amikor egy csomag megérkezik a NAT-dobozhoz az internetszolgáltatótól, a TCPfejrészben található Forrás port mezőt kiveszik, és indexként használják a NATdoboz leképezési táblázatában. Az így talált bejegyzésből kiveszik a belső IP-címet és az eredeti TCP Forrás portot, és belerakják azokat a csomagba. Ezután újraszámolják mind az IP-, mind a TCP-ellenőrzőösszegeket, és azokat is beleírják a csomagba. A csomagot végül átadják hagyományos továbbításra a vállalati routernek a \0.X-~y-Z cím használatával. A NAT-ot az ADSL és kábelfelhasználók IP-címhiányának enyhítésére is felhasz­ nálhatjuk. Amikor az internetszolgáltató minden felhasználónak kioszt egy címet, ak­ kor a lO.x.y.z alakú címeket használja. Amikor a felhasználói csomagok kilépnek a szolgáltató területéről, és belépnek az internetbe, keresztülhaladnak egy NATdobozon, ami lefordítja azokat a szolgáltató tényleges IP-címére. A visszaúton a cso­ magok az ellenkező irányú leképezésben vesznek részt. E tekintetben az Internet többi részének szempontjából a szolgáltató és annak ADSL- vagy kábelfelhasználói éppen olyanoknak látszanak, mint egy nagyvállalat. Jóllehet ez a séma voltaképp megoldja a problémát, az IP-közösségben mégis so­ kan visszataszítónak tartják. íme az ellenérvek rövid összegzése. Először is, a NAT megsérti az IP architektutális modelljét, mely szerint minden. IP-cím globálisan egy­ értelmű módon egyetlen gépet azonosít. Az Internet teljes szoftverstruktúrája erre a tényre épül. A NAT révén azonban gépek ezrei használhatják (és használják is) a 10.0.0.1 címet. Másodszor, a NAT az összeköttetés nélküli Internetből egyfajta összeköttetés alapú hálózatot csinál. A gondot itt az okozza, hogy a NAT-doboznak minden rajta keresz­ tülmenő kapcsolatról információt (egy leképezést) kell tárolnia. A kapcsolatállapot ilyen jellegű számontartása az összeköttetés alapú hálózatok sajátossága, és nem az összeköttetés nélkülieké. Ha a NAT-doboz összeomlik és a leképezési táblázat elvész, akkor a doboz összes TCP-kapcsolata megszűnik. Ha nincs NAT, a routerek összeomlá­ sa nincs hatással a TCP-re. Ilyenkor mindössze az történik, hogy a feladó folyamat idő­ zítője néhány másodperc alatt lejár, mire az minden nyugtázatlan csomagot újraad. A NAT használatával az Internet olyan sebezhető lesz, mint egy vonalkapcsolt hálózat. Harmadszor, a NAT megsérti a protokoll rétegelés legfontosabb alapelvét: a k. ré­ teg nem tehet semmilyen feltételezést arról, hogy a k +1. réteg mit tett az adatmezejé­ be. Az alapelv az, hogy a rétegeket függetlennek kell tartani. Ha a TCP-t egyszer to­ vábbfejlesztik TCP-2-re, és megváltozik a fejrész formátuma (például 32 bitesek lesz­ nek a portszámok), akkor a NAT megbukik. A rétegezett protokollok lényege pont az, hogy biztosítják, hogy az egyik rétegben bekövetkezett változások nem követelik meg a többi réteg megváltoztatását. A NAT megszünteti ezt a függetlenséget.

492

SZÁMÍTÓGÉP-HÁLÓZATOK

Negyedszer, a folyamatok az Interneten nem feltétlenül használnak TCP-t vagy UDP-t. Ha az A gépen egy felhasználó úgy dönt, hogy egy új szállítási protokoll segít­ ségével fog beszélgetni a B gép egy felhasználójával (pl. egy multimédiás alkalmazás útján), akkor a NAT-doboz bevezetésével az alkalmazás már nem fog működni, mert a NAT-doboz nem fog megfelelő TCP Forrás portot találni. Ötödször, néhány alkalmazás a szöveg törzsébe illeszti az IP-címeket. A vevó' azután innen veszi ki és használja tovább azokat. Mivel a NAT semmit nem tud ezek­ ről a címekről, kicserélni sem tudja azokat, így a másik oldalon a címek használatára tett bármilyen kísérlet kudarcot fog vallani. A szabványos FTP (Filé Transfer Protocol) fájlátviteli protokoll is így működik, ezért a NAT jelenlétében csődöt mondhat, hacsak nem teszünk különleges óvintézkedéseket. Hasonlóképpen, a H.323 Internet-telefónia protokollnak (amit a 7. fejezetben fogunk tanulmányozni) is van egy ilyen sajátossága, ezért nem biztos, hogy NAT-tal együtt is működik. A NAT-ot eset­ leg meg lehet javítani, hogy működjön a H.323-mal is, de az nem túl jó ötlet, hogy a NAT-doboz szoftverét minden egyes alkalommal, amikor egy új alkalmazás megjele­ nik, újra ki kell javítani. Hatodszor, mivel a TCP Forrás port 16 bites, legfeljebb 65 536 gépet lehet egy IPcímhez rendelni. A tényleges érték ennél kicsit kevesebb, mert az első 4096 portot speciális célokra tartják fenn. Persze ha ennél több IP-cím áll rendelkezésünkre, akkor mindezekkel lekezelhetünk legfeljebb 61 440 gépet. A NAT több más problémája mellett ezeket is tárgyalja az RFC 2993. Általában véve, a NAT ellenzői azt mondják, hogy a túl kevés IP-cím problémájának egy ilyen ideiglenes és csúnya bütyköléssel való megoldása csak csökkenti az igazi megoldásra, vagyis az IPv6-ra való átállásra ösztönző nyomást; ez pedig nem jó dolog.

5.6.3.

Az Internet vezérlő protokolljai

Az adattovábbításra használt IP-n kívül az Internetnek számos, a hálózati rétegben használt vezérlő protokollja van, mint például az ICMP, ARP, RARP, BOOTP és a DHCP. Ebben a szakaszban sorban mindegyiket áttekintjük.

ICMP - Internet vezérlőüzenet protokoll Az Internet működését a routerek szorosan figyelemmel kísérik. Amikor valami váratlan esemény történik, ezt az eseményt az ICMP (Internet Control Message Protocol internet vezérlőüzenet protokoll) segítségével jelentik. Az ICMP-t az Internet tesz­ telésére is használják. Körülbelül egy tucat ICMP-üzenetet definiáltak. A legfontosab­ bakat az 5.61. ábra sorolja fel. Minden ICMP-üzenetet egy IP-csomagba ágyaznak be. A CÉL ELÉRHETETLEN üzenetet akkor használják, ha az alhálózat vagy a router nem tudja megtalálni a célt, vagy egy DF bittel rendelkező csomagot nem lehet kézbesí­ teni, mert egy „kiscsomagos" hálózat az útjába állt. Az IDŐTÚLLÉPÉS üzenetet akkor küldik, ha egy csomagot azért dobnak el, mert a számlálója elérte a nullát. Ez az esemény annak a tünete, hogy a csomagok hurokba

493

A HÁLÓZATI RÉTEG

Leírás

Üzenet típusa Cél elérhetetlen

A csomagot nem lehetett kézbesíteni

Időtúllépés

Az élettartam mező elérte a 0-t

Paraméter probléma

Érvénytelen fejrész mező

Forráslefojtás

Lefojtó csomag

Átirányítás

Egy routert tanít meg a földrajzra

Visszhang kérés

Kérdés, hogy egy gép életben van-e

Visszhang válasz

Igen, életben vagyok

Időbélyeg kérés

Ugyanaz, mint a Visszhang kérés, csak időbélyeggel

Időbélyeg válasz

Ugyanaz, mint a Visszhang válasz, csak időbélyeggel

5.61. ábra. A legfőbb ICMP-üzenettípusok kerültek, hogy hatalmas torlódás van, vagy hogy az időzítő értékét túl alacsonyra állí­ tották be. A PARAMÉTER PROBLÉMA üzenet azt jelzi, hogy egy fejrész mezőije érvénytelen ér­ ték került. Ez a probléma hibát jelez az adó hoszt IP-szoftverében, vagy esetleg egy, az út során érintett router szoftverében. A FORRÁSLEFOJTÁS üzenetet régebben a túl sok csomagot küldő hosztok visszafo­ gására használták. Amikor egy hoszt ilyen üzenetet kapott, le kellett lassítania. Ma­ napság már ritkán használják, mert amikor torlódás következik be, ezek a csomagok csak olajat öntenek a tűzre. A Interneten a torlódásvédelem most nagyrészt a szállítási rétegben történik, és a 6. fejezetben fogjuk tanulmányozni. Az ÁTIRÁNYÍTÁS üzenetet akkor használják, ha egy router észreveszi, hogy egy csomag rosszul irányítottnak tűnik. A router használja, hogy a küldő hosztot értesítse a valószínű hibáról. A VISSZHANG KÉRÉS és VISSZHANG VÁLASZ üzeneteket egy adott hoszt elérhetősé­ gének és életben létének megvizsgálására használják. A VISSZHANG üzenetet megkap­ va, a célnak vissza kell küldenie egy VISSZHANG VÁLASZ üzenetet. Az IDŐBÉLYEG KÉ­ RÉS és IDŐBÉLYEG VÁLASZ üzenetek hasonlók, kivéve, hogy az üzenet érkezési ideje és a válasz indulási ideje is szerepelnek a válaszban. Ezt a tulajdonságot a hálózati tel­ jesítmény mérésére használják. A fentieken kívül más üzeneteket is definiáltak. Az üzenetek on-line listáját a www.iana.org/assignments/icmp-parameters webcímen találhatjuk.

ARP - címfeloldási protokoll Bár az Interneten levő összes gépnek van egy (vagy több) IP-címe, ezeket voltakép­ pen nem használhatjuk csomagok küldésére, mivel az adatkapcsolati réteg hardverje nem érti az internetcímeket. Manapság a legtöbb hoszt egy olyan interfészkártyával kapcsolódik a LAN-hoz, amely csak a LAN-címeket érti meg. Például minden eddig gyártott Ethernet-kártya egy 48 bites Ethernet-címmel felszerelve érkezik. Az Ether-

494

SZÁMÍTÓGÉP-HÁLÓZATOK

192.31.65.7

E1

A CS routernek két IP-címe van 192.31.60.4, 192.31.65.1 192.31.65.5

<

Az EE routernek két IP-címe van 192.31.60.7 192.31.63.3

E5

E2 CS Ethernet 192.31.65.0

192.31.63.8

Egyetemi FDDI-gyűrű 192.31.60.0

E6

Ethernet címek

EE Ethernet 192.31.63.0

5.62. ábra. Három összekapcsolt C osztályú hálózat: két Ethernet- és egy FDDI-gyűrű

net-kártyák gyártói egy címtartományt igényelnek a központi hatóságtól, hogy biztosan ne legyen két kártyának ugyanaz a címe (hogy elkerüljék az ütközéseket, ha a két kártya valaha is ugyanazon a LAN-on tűnne fel). A kártyák a 48 bites Ethernet-címekre ala­ pozva küldenek és fogadnak kereteket. Semmit sem tudnak a 32 bites IP-címekről. Felmerül a következő kérdés: hogyan képezik le az IP-címeket az olyan adatkap­ csolati rétegbeli címekre, mint amilyen az Ethernet-cím is. Ennek a működését az 5.62. ábra példáján keresztül magyarázzuk el, ahol egy kisebb egyetem néhány C osztályú (azaz /24-es) hálózata látható. Két Ethernet-hálózatunk van, egy a Számítás­ tudományi Tanszéken, 192.31.65.0 IP-címmel, és egy a Villamosmérnöki Tanszéken, 192.31.63.0 IP-címmel. Ezeket a 192.31.60.0 IP-című egyetemi gerincgyú'rű (pl. FDDI) köti össze. Minden Ethernet-hálózaton lévő gépnek van egy egyedi Ethernet­ címe, El-tői Efj-ig jelölve, és minden FDDI-gyűrűn lévő gépnek vagy egy FDDIcíme, F/-től F3-ig jelölve. Kezdésként nézzük meg, hogyan küld az 1. hoszt egy felhasználója egy csomagot a 2. hoszt egy felhasználójának. Tegyük fel, hogy a küldő ismeri a szándéka szerinti vevő címét, valami ilyesmit: [email protected]. Az első lépés a 2., eagle.cs.uni.eduként ismert hoszt IP-címének megkeresése. Ezt a felkutatást a Körzetnév Kezelő Rendszer (Domain Name System: DNS) végzi, amelyet a 7. fejezetben fogunk tanul­ mányozni. Most csak feltételezzük, hogy a DNS visszaadja a 2. hoszt IP-címét (192.31.65.5). Az 1. hoszt felsőbb rétegbeli szoftvere most felépít egy csomagot 192.31.65.5-tel a Cél címe mezőben, és átadja az IP-szoftvemek átvitelre. Az IP-szoftver megnézheti a címet, és láthatja, hogy a cél a saját hálózatán van, de valami módon meg kell találnia a cél Ethernet-címét. Egy megoldás az, hogy legyen egy konfigurációs állomány vala­ hol a rendszerben, amely leképezi az IP-címeket Ethernet-címekre. Ez a megoldás ter­ mészetesen lehetséges, de a több ezer géppel rendelkező szervezetek számára ezeknek az állományoknak a naprakészen tartása hibára hajlamos, időrabló munka. Jobb megoldás az, hogy az 1. hoszt kiad egy adatszóró csomagot az Ethernetre, kér­ dezvén: „Kié a 192.31.65.5-ös IP-cím?" Az adatszórás minden géphez megérkezik a

A HÁLÓZATI RÉTEG

495

192.31.65.0-s Etherneten, és mindegyik leellenőrzi az IP-címét. Csak a 2. hoszt fog vála­ szolni a saját Ethernet-címével (£2-vel). Ily módon az 1. hoszt megtudja, hogy a 192.31.65.5-ös IP-cím az £2-es Ethernet-című hoszton van. Az e kérdés feltevésére és a válasz megkapására szolgáló protokoll az ARP (Address Resolution Protocol - címfel­ oldási protokoll). Az Interneten majdnem minden gép futtatja, és az RFC 826 definiálja. Az ARP előnye a konfigurációs állományokkal szemben az egyszerűség. A rend­ szermenedzsernek nincs sok dolga, csak minden géphez egy IP-címet kell hozzáren­ delnie és dönteni az alhálózati maszkok felől. Az ARP elvégzi a többit. Ezen a ponton az 1. hoszt IP-szoftvere felépít egy Ethernet-keretet £2-nek címezve, belehelyezi a (192.31.65.5-nek címzett) IP-csomagot az adatmezőbe, és ráadja az Ethernetre. A 2. hoszt Ethernet-kártyája észleli a keretet, begyűjti, és egy megszakítást kezdeményez. Az Ethernet-meghajtó kicsomagolja az IP-csomagot az adatmezőből és átadja az IP-szoftvernek, amely látja, hogy helyes a címzés, és feldolgozza. Változatos optimalizálások lehetségesek az ARP hatékonyabbá tételére. Először is, ha egyszer egy gép futtatta az ARP-t, eltárolja az eredményt arra az esetre, ha rövid idő múlva ugyanazzal a géppel kell kapcsolatba lépnie. A következő alkalommal meg­ találja a hozzárendelést a saját gyorstárában, ezáltal szükségtelenné válik a második adatszórás. Sok esetben a 2. hosztnak vissza kell küldenie egy választ, ezáltal arra kényszerül, hogy az adó Ethernet-címének megállapításához futtassa az ARP-t. Ezt az ARP-adatszórást el lehet kerülni, ha az 1. hoszt beleteszi az IP-Ethernet hozzárendelését az ARP-csomagba. Amikor az ARP-csomag megérkezik a 2. hoszthoz, a (192.31.65.7, El) pár bekerül a 2. hoszt gyorstárába majdani felhasználásra. Tulajdonképpen az Etherneten levő összes gép bejegyezheti ezt a leképezést az ARP gyorstáraiba. Még egy optimalizálás az, hogy minden gépnek a saját leképezését adatszórással közzé kell tenni, amikor elindul. Ezt az adatszórást általánosan egy, a saját IP-címét kereső ARP formájában lehet megvalósítani. Normális esetben nem lehet válasz. Az adatszórás egy mellékhatásaként azonban egy bejegyzés keletkezik mindenkinek az ARP gyorstárában. Ha mégis lesz válasz, akkor két géphez van ugyanaz az IP-cím hozzárendelve. Az újnak értesíteni kell a rendszermenedzsert és nem szabad elindulnia. Hogy lehetőséget hagyjunk a leképezések megváltoztatására, például amikor egy Ethernet-kártya tönkremegy és egy újra (és ezáltal új Ethernet-címre is) cserélik, az ARP-gyorstárban levő bejegyzéseknek néhány perces időzítés után le kell járniuk. Most nézzük újra az 5.62. ábrát, csak most az 1. hoszt a 4. (192.31.63.8) hosztnak akar egy csomagot küldeni. Az ARP használata csődöt fog mondani, mivel a 4. hoszt nem látja az adatszórást (a routerek nem továbbítják az Ethernet szintű adatszórást). Két megoldás van. Először, a CS router beállítható úgy, hogy feleljen a 192.31.63.0 hálózatnak (és esetleg más lokális hálózatoknak is) szóló ARP-kérésekre. Ebben az esetben, az 1. hoszt egy (192.31.63.8, E3) bejegyzést fog létrehozni az ARP-gyorstár­ ban, és boldogan küldi a 4. hosztnak szóló összes forgalmat a helyi routernek. Ezt a megoldást helyettesítő ARP-nek (proxy ARP) nevezik. A második megoldás, hogy az 1. hosztnak rögtön látnia kell, hogy a cél egy távoli hálózaton van, és az összes ilyen forgalmat egy alapértelmezett Ethernet-címre küldje, amely az összes távoli for­ galmat kezeli, ez esetben Zsi-ra. Ez a megoldás nem követeli meg a CS routertől, hogy tudja, mely távoli hálózatokat szolgál ki. Bármelyik módon is jutottunk ide, ezután az történik, hogy az 1. hoszt az IP-cso-

496

SZÁMÍTÓGÉP-HÁLÓZATOK

magot egy olyan keret adatmezejébe csomagolja bele, amelyet EJ-nak címeztek, Amikor a CS router megkapja az Ethernet-keretet, kiveszi az IP-csomagot az adatmezőből és ki­ keresi az IP-címet a forgalomirányító táblázataiból. Megtudja, hogy a 192.31.63.0 háló­ zatnak szóló csomagoknak a 192.31.60.7-es routerhez kell menniük. Ha még nem tudja 192.31.60.7 FDDI-címét, egy adatszóró ARP-csomagot helyez a gyűrűre, és megtudja, hogy annak gyú'rú'címe F3. Ezután elhelyezi a csomagot egy F3-nak cím­ zett FDDI-keret adatmezejében, és kirakja a gyűrűre. Az EE routernél az FDDI-vezérlő kiveszi a csomagot az adatmezőből és átadja az IP-szoftvernek, amely látja, hogy 192.31.63.8-nak kell a csomagot küldenie. Ha ez az IP-cím nincs az ARP gyorstárában, egy adatszórásos üzenetet bocsát ki az EE Ether­ netre és megtudja, hogy a cél címe E6. így egy £ő-nak címzett Ethernet-keretet épít, elhelyezi a csomagot az adatmezőben, és átküldi az Etherneten. Amikor az Ethernet­ keret megérkezik a 4. hoszthoz, a csomagot kiveszik a keretből és átadják az IP-szoft­ vernek feldolgozásra. Az 1. hoszttól egy WAN-on át egy távoli hálózatig szükségképpen ugyanígy lehet eljutni, kivéve, hogy ez alkalommal a CS routert a táblázatai az F2 FDDI-című WANrouter használatára utasítják.

RARP, BOOTP és DHCP Az ARP megoldja azt a problémát, hogy megtudjuk, melyik Ethernet-cím felel meg egy adott IP-címnek. Néha a fordított problémát kell megoldani: Adott egy Ethernet­ eim, mi a hozzá tartozó IP-cím? Ez a probléma különösen akkor merül fel, amikor egy lemez nélküli munkaállomást indítunk el. Egy ilyen gép rendszerint egy távoli állo­ mánykiszolgálótól kapja meg az operációs rendszerének bináris képét. De hogyan tud­ ja meg az IP-címét? A megoldás a (RFC 903 definiálja) RARP (Reverse Address Resolution Protocol - fordított rímfeloldási protokoll) használata. Ez a protokoll lehetővé teszi egy újonnan indított munkaállomásnak, hogy adatszórással közölje Ethernet-címét, és azt mondja: „A 48 bites Ethernet-címem 14.04.05.18.01.25. Tudja valaki az IPcímemet?" A RARP-szerver meglátja a kérést, kikeresi az Ethernet-címet a konfigu­ rációs állományaiban, és visszaküldi a megfelelő IP-címet. A RARP használata jobb, mint egy IP-cím beágyazása a memóriaképbe, mert lehe­ tővé teszi minden gépen ugyanannak a képnek a használatát. Ha az IP-címek bele len­ nének égetve a képbe, minden munkaállomásnak saját képre lenne szüksége. A RARP hátránya, hogy csupa 1-ből álló célcímet (korlátozott adatszórást) használ a RARP-szerver eléréséhez, viszont az ilyen adatszórásokat nem továbbítják a routerek, így minden hálózaton szükség van egy RARP-szerverre. Hogy ezt a problémát megkerüljék, feltaláltak egy másik induláskor használandó protokollt, amit BOOTPnek hívnak (1. RFC 951, 1048 és 1084). A RARP-tól eltérően ez UDP-üzeneteket használ, amelyeket a routerek továbbítanak. Ezenkívül további információkkal is el­ látja a lemez nélküli munkaállomásokat, beleértve a memóriaképet tartalmazó állo­ mánykiszolgáló IP-címét, az alapértelmezett router IP-címét, és a használandó alháló­ zat! maszkot. A BOOTP-t az RFC 951, 1048 és 1084 írja le.

497

A HÁLÓZATI RÉTEO

A BOOTP komoly problémája az, hogy az IP-címeket Ethernet-címekre leképező táblázatokat manuálisan kell karbantartani. Amikor egy új hosztot ráraknak egy LANra, az nem használhatja a BOOTP-t mindaddig, amíg egy adminisztrátor ki nem oszt neki egy IP-címet és saját kezűleg be nem írja az (Ethernet-cím, IP-cím) bejegyzést a BOOTP konfigurációs táblázatába. Azért, hogy kiküszöböljék ezt a sok hibalehetősé­ get rejtő lépést, a BOOTP-t kiterjesztették, és új nevet adtak neki, így jött létre a DHCP (Dynamic Hőst Configuration Protocol, dinamikus hoszt-konfigurációs protokoll). A DHCP mind a manuális, mind az automatikus IP-címkiosztást lehetővé teszi. Leírását az RFC 2131 és 2132 tartalmazza. A DHCP a legtöbb rendszerben jó­ részt teljesen felváltotta a RARP-ot és a BOOTP-t. A RARP-hoz és a BOOTP-hez hasonlóan a DHCP is azon az ötleten alapul, hogy egy külön kiszolgáló osztja ki az IP-címeket azoknak a hosztoknak, akik ezt kérik. Ennek a kiszolgálónak nem kell ugyanazon a LAN-on lennie, mint a kérelmező hosztoknak. Mivel tehát nem biztos, hogy a DHCP-kiszolgáló elérhető üzenetszórás­ sal, ezért minden LAN-on egy DHCP-közvetítő ügynökre (DHCP relay agent) van szükség, ahogy azt az 5.63. ábra mutatja. Ahhoz, hogy megtudja a saját IP-címét, az újonnan induló gép csomagszórással szétküld egy DHCP FELFEDEZÉS csomagot. A LAN-on lévő DHCP-közvetítő ügy­ nök elfog minden DHCP-csomagszórást. Amikor egy DHCP FELFEDEZÉS csoma­ got talál, egyesküldéssel elküldi ezt a csomagot a DHCP-kiszolgálónak, amely esetleg egy távoli hálózaton van. A közvetítő ügynöknek ehhez csak a DHCP-kiszolgáló IPcímét kell tudnia. Az IP-címeknek egy külön készletből (pool) való automatikus kiosztása felveti azt a kérdést, hogy vajon mennyi ideig tartson egy IP-cím hozzárendelése. Ha egy hoszt elhagyja a hálózatot, és nem adja vissza az IP-címét a DHCP-kiszolgálónak, akkor ez a cím tartósan elveszik. Egy idő után sok cím tűnhet el így. Ennek megelőzésére ki­ oszthatjuk az IP-címeket egy rögzített időtartamra is. Ezt a módszert lízingelésnek (leasing) nevezik. A hosztnak röviddel a lízing lejárta előtt újítást kell kérnie a DHCP-kiszolgálótól. Ha nem sikerül ilyen kérelmet küldenie, vagy a kérelmet a ki­ szolgáló elutasítja, akkor a hoszt nem használhatja tovább a korábban megkapott IPcímet. Újonnan induló hoszt, mely IP-címet keres

DHCPközvetítő

DHCP FELFEDEZÉS csomag

5.63. ábra. A DHCP működése

Más hálózatok

Router

DHCPkiszolgáló

Egyesküldéses csomag a DHCP-közvetítőtől (csomagszórás) a DHCP-kiszolgálónak

498 5.6.4.

SZÁMÍTÓGÉP-HÁLÓZATOK

OSPF - belső átjáró protokoll

Az imént befejeztük az Internet vezérlő protokolljainak tárgyalását. Ideje továbblépnünk következő' témánkra: az Interneten belüli forgalomirányításra. Ahogy már korábban is említettük, az Internet nagyszámú autonóm rendszerből (AS) tevődik össze. Minden AS-t más szervezet működtet, és belül a saját forgalomirányító algoritmusát használhatja. Például az X, Y és Z társaságok belső hálózata rendesen három AS-ként látszódna, ha mind a három az Interneten lenne. Mindhárom belül különböző forgalomirányító algo­ ritmusokat használhat. Mindazonáltal az, hogy még a belső forgalomirányításhoz is lé­ teznek szabványok, egyszerűsíti az AS-ek közti határfelületek megvalósítását, és módot ad a kód újrahasznosítására. Ebben a részben az egy AS-en belüli forgalomirányítást fogjuk tanulmányozni, a következőben pedig az AS-ek közti forgalomirányítást vesszük szemügyre. Az egy AS-en belüli forgalomirányító protokollt belső átjáró protokollnak (interior gateway protocol) nevezik; az AS-ek közti forgalomirányításra szolgáló algo­ ritmus neve külső átjáró protokoll (exteriőr gateway protocol). Az eredeti Internet belső átjáró protokollja egy, a Bellman-Ford-algoritmusra épülő távolságvektor alapú protokoll volt, melyet az ARPANET-ből vettek át. Kis rendszerekben jól működött, de ahogy az AS-ek nagyobbak lettek, egyre kevésbé volt elfogadható. Szenvedett a végtelenségig számolás problémájától és általában a lassú konvergenciától is, így 1979 májusában felváltotta egy kapcsolatállapot alapú proto­ koll. 1988-ban az Internet Engineering Task Force elkezdte a munkát egy utódon. Ez az utód, amelynek a neve OSPF (Open Shortest Path First), 1990-ben szabvány lett. Ma már sok routergyártó támogatja, és a közeljövőben ez lesz a fő belső átjáró proto­ koll. Alább egy vázlatot adunk arról, hogyan működik az OSPF. A teljes történetet lásd az RFC 2328-ban. Mivel már sok tapasztalat gyűlt össze más forgalomirányító protokollokról, az új protokollt tervező csoportnak hosszú listája volt a teljesítendő követelményekről. Elő­ ször is, az algoritmust a mindenki által hozzáférhető irodalomban kellett publikálni, innen az „O" (Open) az OSPF-ben. Nem felelt volna meg egy olyan megoldás, ame­ lyet egyetlen vállalat birtokol. Másodszor, az új protokollnak mindenféle távolságmér­ téket támogatnia kellett, beleértve a fizikai távolságot, a késleltetést és így tovább. Harmadszor, dinamikus algoritmusnak kellett lennie, méghozzá olyannak, amely a to­ pológia változásaihoz automatikusan és gyorsan alkalmazkodik. Negyedszerre, és ez új az OSPF-ben, támogatnia kellett a szolgálat típusára alapo­ zott forgalomirányítást. Az új protokollnak képesnek kellett arra lennie, hogy a valós idejű forgalmat egy adott útvonalra, a másfajta forgalmat pedig másfelé irányítsa. Az IP-protokollnak van egy Szolgálat Típusa mezeje, de semmilyen létező protokoll nem használta. Ezt a mezőt az OSPF is tartalmazta, de még így sem használta senki, így végül eltávolították. Ötödszörre, és a fentiekkel összefüggésben, az új protokollnak terheléskiegyenlí­ tést is kellett végeznie, a terhelést több vonalra szétosztva. A legtöbb ezt megelőző protokoll minden csomagot a legjobb útvonalon küldött el. A második legjobb útvona­ lat egyáltalán nem használták. Sok esetben a terhelés több vonalra való szétosztása jobb teljesítményt ad. Hatodszor, a hierarchikus rendszerek támogatására is szükség volt. 1988-ra az In-

499

A HÁLÓZATI RÉTEG

ternet már olyan nagyra nőtt, hogy egyik routertől sem lehetett elvárni, hogy ismerje az egész topológiát. Az új protokollt úgy kellett megtervezni, hogy erre egyik routernek se legyen szüksége. Hetedszerre, valami kevés biztonság is kellett, hogy a mókás kedvű hallgatókat meggátolják abban, hogy a routereket hamis forgalomirányítási információ küldésével félrevezessék. Végül valamilyen rendelkezés kellett az olyan routerek kezeléséhez, amelyek alagút típusú átvitelen keresztül kapcsolódtak az internethez. Az előző proto­ kollok ezt nem kezelték jól. Az OSPF háromfajta összeköttetést és hálózatot támogat: 1. Kétpontos vonalak pontosan két router közt. 2. Többszörös hozzáférésű hálózatok adatszórási lehetőséggel (pl. a legtöbb LAN). 3. Többszörös hozzáférésű hálózatok adatszórási lehetőség nélkül (pl. a legtöbb cso­ magkapcsolt WAN). A többszörös hozzáférésű (multiaccess) hálózat olyan, hogy több router is lehet rajta, és ezek mindegyike közvetlenül tud a másikkal kommunikálni. Minden LAN és WAN rendelkezik ezzel a tulajdonsággal. Az 5.64.(a) ábra egy olyan AS-t mutat, WAN 1

L1

W3 (b)

5.64. ábra. (a) Egy autonóm rendszer, (b) (a) egy gráfreprezentációja

500

SZÁMÍTÓGÉP-HÁLÓZATOK

amely mind a háromfajta hálózatot tartalmazza. Vegyük észre, hogy a hosztok általá­ ban nem játszanak szerepet az OSPF-ben. Az OSPF úgy működik, hogy a valódi hálózatok, routerek és vonalak összességét egy irányított gráfba képezi le, ahol minden élhez tartozik egy költség (távolság, kés­ leltetés stb.). Ezután az élek súlyaira alapozva kiszámítja a legrövidebb utat. Két router közti soros kapcsolatot egy élpár jelképez, mindkét irányba egy-egy éllel. Ezek súlyai különbözhetnek. Egy többszörös hozzáférésű hálózatot egy csomópont jelképez, minden routemek megfelel egy további csomópont. A hálózatnak megfelelő" csomó­ pontból a routerek felé vezető éleknek 0 súlyuk van, és ki is maradnak a gráfból. Az 5.64.(b) ábra mutatja az 5.64.(a) ábra gráfreprezentációját. Alapjában véve az OSPF azt csinálja, hogy a valódi hálózatot egy ilyen gráfba képezi le, majd kiszámítja a legrövidebb utat minden routertől minden más routerig. Az Interneten sok AS önmagában is nagy, és nem magától értetó'dő a menedzselé­ sük. Az OSPF lehetó'vé teszi, hogy ezeket megszámozott területekre (area) osszuk fel, ahol egy terület egy hálózat vagy hálózatok összefüggő halmaza. A területek nem fedhetik át egymást, de nem kell kimerítőnek lenniük, vagyis néhány router esetleg egyik területhez sem tartozik. A terület az alhálózatok egy általánosítása. Egy terüle­ ten kívülről annak topológiája és részletei nem láthatók. Minden AS-nek van egy gerinchálózati (backbone) területe, amit 0. területnek hívnak. Minden terület csatlakozik a gerinchálózathoz, esetleg alagutakon keresztül, így az AS bármely területéről bármelyik másik területére el lehet jutni a gerinchálóza­ ton keresztül. Az alagutat a gráfban egy él és egy költség jelképezi. Minden router, amely két vagy több területhez csatlakozik, a gerinchálózat része. Mint az más terüle­ tekre is igaz, a gerinchálózat topológiája sem látszik a gerinchálózaton kívülről. Egy területen belül minden router ugyanazzal a kapcsolatállapot adatbázissal rendel­ kezik, és ugyanazt a legrövidebb út algoritmust futtatja. A legfőbb feladata, hogy kiszá­ mítsa a legrövidebb utat saját magától minden már routerig a területen belül, beleértve azt a routert is, amelyik a gerinchálózathoz kapcsolódik. Ilyenből legalább egy kell legyen. Egy olyan routemek, amely két területhez is kapcsolódik, mindkét terület adatbázisára szüksége van, és mindkettőre külön kell futtatnia a legrövidebb út algoritmust. Rendes működés közben háromfajta útvonalra lehet szükség: területen belülire, te­ rületek közöttire és AS-ek közöttire. A területen belüli útvonalak a legkönnyebbek, mivel a forrásrouter már tudja a legrövidebb utat a célrouterig. A területek közti for­ galomirányítás mindig három lépésben megy végbe: menjünk a forrástól a gerincháló­ zatig; menjünk a gerinchálózaton keresztül a célterületig; menjünk a célig. Ez az algo­ ritmus egy csillag elrendezést kényszerít az OSPF-re, ahol a gerinchálózat a csillag közepe és a többi területek az ágai. A csomagokat úgy irányítjuk a forrástól a célig, „ahogy vannak". Nem ágyazzuk be azokat, és nem visszük keresztül alagutakon, ha­ csak nem egy olyan területre megy, amelyet a gerinchálózattal csak egy alagút köt össze. Az 5.65. ábra az Internet egy részét mutatja AS-ekkel és területekkel. Az OSPF négy routerosztályt különböztet meg: 1. A belső routerek teljes egészükben egy területen belül vannak. 2. A területhatár-routerek két vagy több területet kötnek össze.

501

A HÁLÓZATI RÉTEG

3. A gerinchálózati routerek a gerinchálózaton vannak. 4. Az AS-határ routerek a más AS-ekben levő routerekkel beszélnek. Ezek az osztályok átfedhetik egymást, például minden határrouter automatikusan a gerinchálózat része is. Ezenkívül, egy olyan router, amely a gerinchálózaton van, de nem része semmilyen más területnek sem, belső router is. Az 5.65. ábra mind a négy router osztályra mutat példát. Amikor egy router elindul, HELLO üzeneteket küld minden kétpontos vonalán, és ezeket többesküldéssel elküldi a LAN-okon az összes többi routerből álló csoportnak is. WAN-okon valamilyen konfigurációs információra van szüksége, hogy tudja, kivel lépjen kapcsolatba. A válaszokból minden router megtudja, kik a szomszédai. Az OSPF azáltal működik, hogy információt cserél az összefüggő (adjacent) routerek közt, amely nem ugyanaz, mint a szomszédos routerek. Nem hatékony, hogy egy LAN-on minden router minden másikhoz beszéljen. Hogy ezt a szituációt elkerül­ jék, egy routert megválasztanak kijelölt routernek (designated router). Ezt nevezik az összes többi routerrel összefüggőnek, és ez cserél velük információt. Az olyan szomszédos routerek, amelyek egymással nem összefüggők, egymás közt nem cserél­ nek információt. Mindig naprakészen tartanak egy tartalék kijelölt routert is, hogy az AS-határrouter

Gerinchálózat Gerinchálózati router

Terület

A BGP protokoll köti össze az AS-eket

J- Területhatárrouter

5.65. ábra. Az AS-ek, gerinchálózatok és területek viszonya az OSPF-ben

502

SZÁMÍTÓGÉP-HÁLÓZATOK

átállást megkönnyítsék, amennyiben az elsődleges kijelölt router összeomlana, és azonnali cserére szorulna. Rendes működés közben minden router periodikusan eláraszt KAPCSOLATÁLLAPOT FRISSÍTÉS üzenetekkel minden vele összefüggő routert. Ez az üzenet megadja annak állapotát, és biztosítja a topológiai adatbázisban használt költségeket. Az elárasztási üzeneteket nyugtázzák, hogy megbízhatók legyenek. Minden üzenetnek van egy sor­ száma, így a routerek láthatják, hogy egy bejövő KAPCSOLATÁLLAPOT FRISSÍTÉS régebbi vagy újabb annál, amelyik nekik megvan. A routerek akkor is elküldik ezeket az üzene­ teket, amikor egy vonal tönkremegy vagy megjavul, vagy a költsége megváltozik. Az ADATBÁZIS LEÍRÁS üzenetek megadják minden, a küldő által jelenleg birtokolt kapcsolatállapot bejegyzés sorszámát. A vevő a saját értékeit az adóéval összehason­ lítva eldöntheti, kinek van a legújabb értéke. Ezeket az üzeneteket egy vonal megjaví­ tásakor használják. Bármely partner kérhet kapcsolatállapot információt a másiktól a KAPCSOLATÁLLA­ POT KÉRÉS üzeneteket használva. Ennek az algoritmusnak a tovaterjedő hatása az, hogy minden összefüggő router-pár ellenőrzi, hogy kinek vannak a legújabb adatai, és ily módon az új információ elterjed a területen belül. Mindezeket az üzeneteket nyers IPcsomagokként küldik el. Az öt üzenettípus összefoglalása látható az 5.66. ábrán. Üzenet típusa

Leírás

Hello

A szomszédok felderítésére használatos

Kapcsolatállapot frissítés

Az adó költségeit küldi el a szomszédainak

Kapcsolatállapot nyugta

Nyugtázza a kapcsolatállapot frissítést

Adatbázis leírás

Bejelenti, milyen frissítésekkel bír az adó

Kapcsolatállapot kérés

Információt kér a partnertől

5.66. ábra. Az öt OSPF-üzenettípus Végre összerakhatjuk a darabokat. Az elárasztást használva, minden router tudatja a területén belüli összes többi routerrel a szomszédait és költségeit. Ez az információ lehetővé teszi mindegyik router számára, hogy összeállítsa a területe(i) gráfját, és ki­ számítsa a legrövidebb utat. Ezt a gerinchálózati terület is elvégzi. Ezenkívül a gerinc­ hálózati routerek a területhatár-routerektől is elfogadnak információt, hogy kiszámol­ ják a legjobb útvonalat minden gerinchálózati routertől minden más routerig. Ezt az információt visszafelé is elterjesztik a területhatár-routerekhez, amelyek kihirdetik ezt a körzeteikben. Ezt az információt használva egy router, amely egy területek közti csomagot készül küldeni, kiválaszthatja a legjobb kijáratot a gerinchálózat felé.

5.6.5.

BGP - külső átjáró protokoll

Az egy AS-en belülre ajánlott forgalomirányító protokoll az OSPF (bár korántsem csak ezt használják). Az AS-ek közt egy másik protokollt, BGP-t (Bordér Gateway Protocol - határátjáró protokoll) használnak. Az AS-ek közt azért van másfajta pro-

A HÁLÓZATI RÉTEG

503

tokollra szükség, mert a belső átjáró protokoll és a külső átjáró protokoll céljai nem ugyanazok. A belső átjáró protokollnak csak annyi a dolga, hogy a csomagokat a lehető leghatékonyabban mozgassa a forrás és a cél közt. Nem kell törődnie a politikával. A külső átjáró protokolloknak viszont sokat főhet a fejük a politika miatt. Például egy vállalati AS-nek kellhet az a képesség, hogy csomagokat tudjon küldeni az inter­ net bármely helyére, és csomagokat tudjon fogadni az internet bármely helyéről. Vi­ szont nem biztos, hogy hajlandó egy idegen AS-ben keletkezett és egy másik idegen AS-be tartó csomagokat szállítani, még ha a saját AS a legrövidebb úton is lenne a két idegen AS közt. („Ez az ő problémájuk, nem a mienk.") Másfelől viszont hajlandó le­ het átmenő forgalmat továbbítani a szomszédainak vagy esetleg más olyan AS-eknek is, amelyek fizettek ezért a szolgáltatásért. Például a telefontársaságok boldogan mű­ ködnének szolgáltatóként az ügyfeleik számára, de más számára nem. Általában a kül­ ső átjáró protokollokat, így a BGP-t is úgy tervezték, hogy sokfajta forgalomirányítási politika kényszeríthető ki vele az AS-ek közti forgalomban. A tipikus politikák nagypolitikai, biztonsági vagy gazdasági megfontolásokat von­ hatnak maguk után. Egy pár példa a forgalomirányítási korlátozásokra: 1. Ne legyen átmenő forgalom bizonyos AS-eken keresztül. 2. Soha ne helyezzük Irakot egy, a Pentagonnál kezdődő útvonalra. 3. Ne használjuk az Egyesült Államokat arra, hogy Brit Columbiából Ontarióba menjünk. 4. Csak akkor haladjunk át Albánián, ha nincs más út a célhoz. 5. Az IBM-nél kezdődő vagy végződő forgalom ne menjen át a Microsofton. A politikákat kézzel konfigurálják minden BGP-routerben. Ezek nem részei magának a protokollnak. Egy BGP-router szemszögéből a világ AS-ekből és a köztük lévő vonalakból áll. Két AS-t összekötöttnek minősítünk, ha van köztük a BGP-routereiket összekötő vo­ nal. A BGP átmenő forgalom iránti különleges érdeklődéséből adódóan a hálózatokat a következő három csoportba sorolhatjuk. Az első csoportba a csonka hálózatok (stub networks) esnek, amelyeknek csak egy összeköttetésük van a BGP gráffal. Ezeket nem lehet az átmenő forgalom céljaira felhasználni, mivel nincs senki a másik oldalukon. Ezután jönnek a többszörösen bekötött hálózatok (multiconnected networks), amelyeket használhatná az átmenő forgalom, csakhogy ezek ezt megta­ gadják. Végül vannak az átmenő hálózatok (transit networks), mint amilyenek a ge­ rinchálózatok, amelyek esetleg némi megkötéssel, és általában fizetség ellenében ké­ szek kezelni egy harmadik fél csomagjait. A BGP routerek páronként TCP-összeköttetést létrehozva kommunikálnak egy­ mással. Az ilyen működés megbízható kommunikációt biztosít és annak a hálózatnak a részleteit is elrejti, amelyiken áthalad. A BGP alapvetően távolságvektor protokoll, de egészen eltér a legtöbb ilyentől, mint az RIP. Ahelyett, hogy csak a költségeket tartaná nyilván az egyes célokhoz irá­ nyítva, minden BGP-router pontosan nyomon követi a használt útvonalat. Hasonlóan,

504

SZÁMfrÓGÉP-HÁuSZATOK

Az F által a szomszédaitól kapott, D-re vonatkozó információ B-től: „Én a BCD-t használom" G-től: „Én a GCD-t használom" 1-től: „Én az IFGCD-t használom" E-tó'l: „Én az EFGCD-t használom" I

(a)

"J

(b)

5.67. ábra. (a) BGP-routerek egy halmaza, (b) Az F-nek küldött információ ahelyett, hogy minden szomszédnak periodikusan megadná a becsült költséget minden lehetséges célig, minden egyes BGP-router az általa használt pontos útvonalat mondja meg a szomszédainak. Példának vegyük az 5.67.(a) ábrán látható BGP-routereket. Pontosabban, vegyük F forgalomirányító táblázatát. Tegyük fel, hogy az FGCD utat használja, hogy eljusson D-hez. Amikor a szomszédok forgalomirányítási információt adnak át neki, a teljes útvonalaikat megadják, ahogy az 5.67.(b) ábra mutatja. (Az egyszerűség kedvéért csak a D célt mutatjuk.) Miután minden szomszédtól beérkezett az útvonal-információ, F megvizsgálja, hogy ezek közül melyik a legjobb. Gyorsan elveti az / és az E útvonalát, mivel ezek áthaladnak magán F-en. Ezek után csak a f i é s a G között kell választani. Minden BGP-router tartalmaz egy olyan modult, amely megvizsgálja az egy megadott célhoz vezető utakat, és pontozza őket, majd visszaad minden ezen cél felé vezető úthoz egy „távolság" értéket. Bármely olyan útvonal, amely egy politikai korlátozást sért, auto­ matikusan végtelen értéket kap. A router ezután a legrövidebb távolságú útvonalat fo­ gadja el. A pontozó függvény nem a BGP protokoll része, és bármilyen, a rendszer­ menedzserek által jónak tartott függvény lehet. A BGP egyszerűen oldja meg a végtelenségig számolás problémáját, amely meg­ fertőzte a többi távolságvektor alapú algoritmust. Példaként tegyük fel, hogy G össze­ omlik vagy az FG vonal megszakad. Ezután F a három megmaradt szomszédjától fog útvonalakat kapni. Ezek a BCD, IFGCD és EFGCD útvonalak lesznek. Azonnal lát­ hatja, hogy a két utóbbi útvonal értelmetlen, mivel áthaladnak magán F-en, így FBCD-t választja új útvonalnak. Más távolságvektor alapú algoritmusok gyakran a rosszat választják, mert nem tudják, mely szomszédjuknak van független útvonala a célig és melyiknek nincs. A BGP meghatározását az RFC 1771-től 1774-ig terjedő dokumentumok tartalmazzák.

505

A HÁLÓZATI RÉTEG

5.6.6.

Többesküldés az Interneten

A rendes IP-kommunikáció egy adó és egy vevő közt zajlik. De néhány alkalmazás esetében hasznos, ha egy folyamat képes nagyszámú vevőnek egyszerre küldeni (multicasting). Ilyen például a többszörözött, elosztott adatbázisok frissítése, részvényárfo­ lyamok átvitele több brókerhez és a digitális konferenciatelefonok (vagyis több részt­ vevős hívások) kezelése. Az IP támogatja a többesküldést a D osztályú címek használatával. Minden D osz­ tályú cím egy hosztcsoportot azonosít. Huszonnyolc bit használható a csoportok azo­ nosítására, így egy időben több mint 250 millió csoport létezhet. Amikor egy folyamat egy D osztályú címre küld egy csomagot, egy legjobb erőfeszítés típusú kísérlet törté­ nik arra, hogy a megcímzett csoport minden tagjának a csomagot kézbesítsék, de erre semmi garancia nincs. Egyes tagok esetleg nem kapják meg a csomagot. Az IP kétfajta csoportcímet támogat: az állandó címeket és az ideiglenes címeket. Egy állandó csoport mindig létezik, és nem kell felállítani. Minden állandó csoportnak egy állandó csoportcíme van. Néhány példa az állandó csoportokra: 224.0.0.1 Az egy LAN-on 224.0.0.2 Az egy LAN-on 224.0.0.5 Az egy LAN-on 224.0.0.6 Az egy LAN-on

levő összes levő összes levő összes levő összes

rendszer. router. OSPF-router. kijelölt OSPF-router.

Az ideiglenes csoportokat létre kell hozni, mielőtt használhatnánk őket. Egy folya­ mat megkérheti a hosztját, hogy csatlakozzon egy bizonyos csoporthoz. Arra is meg­ kérheti a hosztját, hogy lépjen ki a csoportból. Amikor egy hoszt utolsó folyamata is elhagyja a csoportot, az a csoport többé nem lesz jelen a hoszton. Minden hoszt nyil­ vántartja, hogy a folyamatai jelenleg milyen csoportokhoz tartoznak. A többesküldést speciális többesküldéses routerek valósítják meg, amelyek vagy egybe vannak építve a szokásos routerekkel, vagy nem. Körülbelül percenként egy­ szer minden hoszt egy hardver (vagyis adatkapcsolati rétegbeli) többesküldést intéz a LAN-on levő hosztjaihoz (224.0.0. l-es cím), megkérve azokat, hogy jelentsék, milyen csoportokhoz tartoznak jelenleg a folyamataik. Minden hoszt az összes olyan D osztá­ lyú címre válaszol, amely érdekli. Ezek a lekérdező és válasz csomagok egy IGMP-nek (Internet Group Manage­ ment Protocol - internet csoportfelügyeleti protokoll) nevezett protokollt használ­ nak, amely távolról hasonlít az ICMP-hez. Csak kétfajta csomagja van: lekérdezés és válasz. Mindkettő egyszerű, rögzített formátumú; az adatmező első szava némi vezér­ lőinformációt tartalmaz, a második szava pedig egy D osztályú címet. Ezt a protokollt az RFC 1112 írja le. A többesküldés forgalomirányítása feszítőfák használatával történik. Minden töb­ besküldéses router egy módosított távolságvektor protokollt használva cserél informá­ ciót a szomszédaival, hogy minden csoporthoz felépítsenek egy feszítőfát, amely az összes csoporttagot lefedi. Változatos optimalizációk használatosak a fa csonkolásá­ hoz, hogy kiküszöböljék az egyes csoportokban nem érdekelt routereket és hálózato­ kat. A protokoll nagyban kihasználja az alagút típusú átvitelt, hogy ne zavarja a nem a feszítőfában levő routereket.

506 5.6.7.

SZÁMÍTÓGÉP-HÁLÓZATOK

Mobil IP

Az Internet sok felhasználójának van hordozható számítógépe, és akkor is összekötte­ tésben akarnak maradni az Internettel, amikor egy távoli internethelyet látogatnak meg, só't még az utazás közben is. Sajnos az IP címzési rendszere miatt az otthontól távoli munkát könnyebb mondani, mint elvégezni. Ebben a szakaszban megvizsgáljuk a problémát és a megoldását. Részletesebb leírást ad (Perkins, 1998a) munkája. Az igazi bajkeverő' maga a címzési séma. Minden IP-cím egy hálózatszámot és egy hosztszámot tartalmaz. Vegyük példának a 160.80.40.20/16 IP-című gépet. A 160.80 megadja a hálózatszámot (8272 decimálisán); a 40.20 pedig a hosztszámot (10260 de­ cimálisán). A routereknek a világon mindenütt olyan forgalomirányító táblázataik vannak, melyek megmondják, hogy 160.80-as hálózathoz melyik vonalat használva lehet eljutni. Valahányszor egy olyan csomag jön be, amelyiknek a célcíme 160.80.xxx.yyy formájú, az ezen a vonalon megy ki. Ha egyszer csak az ezzel a címmel rendelkező gépet hirtelen elszállítjuk valami tá­ voli helyre, a csomagjait továbbra is az otthoni LAN-jára (vagy routerjéhez) irányít­ ják. A tulajdonos nem kap többet e-levelet és így tovább. Az, hogy a gépnek az új el­ helyezkedésének megfelelő' IP-címet adunk, nem egy vonzó lehetőség, mivel nagyszá­ mú emberrel, programmal és adatbázissal kellene tudatni a változást. Más megközelítés az, hogy a routerek a teljes IP-címet használják a forgalomirá­ nyításhoz, ne csak az osztályt és a hálózatot. Viszont ez a stratégia azt követelné meg, hogy minden routernek millió és millió táblázatbejegyzése legyen, ami az Internetre nézve csillagászati költséggel járna. Amikor az emberek kezdték követelni, hogy lehessenek mozgó hosztjaik is, az IETF felállított egy munkacsoportot, hogy megoldást találjon. A munkacsoport gyor­ san kialakított számos olyan célt, amelyet minden megoldásban kívánatosnak ítéltek. A főbb célok a következők voltak: 1. Minden mozgó hosztnak bárhol képesnek kell lennie az otthoni IP-címe használatára. 2. A rögzített hosztokban nem engedélyezünk szoftverváltoztatásokat. 3. A router szoftverben és táblázatokban nem engedélyezünk változásokat. 4. A mozgó hosztokhoz menő legtöbb csomagnak nem szabad az úton kitérőket tennie. 5. Nem okozhat többletmunkát, amikor a mozgó hoszt otthon tartózkodik. A választott megoldás az, amit az 5.2.9. részben leírtunk. Hogy röviden összefog­ laljuk, minden helynek, amelyik lehetővé kívánja tenni a felhasználói számára a ba­ rangolást, egy hazai ügynököt kell létrehoznia. Minden helynek, amely látogatókat kí­ ván megengedni, egy idegen ügynököt kell létrehoznia. Amikor egy mozgó hoszt megjelenik egy idegen helyen, kapcsolatba lép az ottani idegen ügynökkel és beje­ gyezteti magát. Az idegen ügynök ezután kapcsolatba lép a felhasználó hazai ügynö­ kével, és ad neki egy közvetett vagy c/o címet (care-of address), rendszerint az ide­ gen ügynök saját IP-címét.

A HÁLÓZATI RÉTEG

507

Amikor egy csomag megérkezik a felhasználó otthoni LAN-jára, valamilyen, a LAN-hoz csatlakozó routeren keresztüljön be. A router ekkor megpróbálja a szokásos módon meghatározni a hoszt helyét, egy ARP-csomag szórása által, amely például azt kérdezi: „Mi a 160.80.40.20 Ethernet címe?" A hazai ügynök erre a kérdésre a saját Ethernet-címének megadásával válaszol. Ezután a router a 160.80.40.20-nak szóló csomagokat a hazai ügynöknek küldi. Az pedig ezeket egy alagúton keresztül elküldi a c/o címére, beágyazván őket egy, az idegen ügynöknek címzett IP-csomag adatme­ zejébe. Ezután az idegen ügynök ezeket kibontja és kézbesíti a mozgó hoszt adatkap­ csolati címére. Ezenkívül a hazai ügynök megadja az alcímet az adónak, így a jövőben a csomagokat egyenesen az idegen ügynökhöz vihetik át egy alagúton keresztül. Ez a megoldás minden fentebb felsorolt követelménynek eleget tesz. Egy kis részlet valószínűleg megérdemli, hogy megemlítsük. Amikor a mozgó hoszt mozog, a routemek valószínűleg a gyorstárában van a (rövidesen érvénytelenné váló) Ethernet-címe. Hogy ezt felcseréljük a hazai ügynök Ethernet-címével, egy ön­ kényes ARP-nek (gratuitous ARP) nevezett trükköt használnak. Ez egy különleges, kéretlen üzenet a routernek, amely kicserélteti vele a gyorstár egy bizonyos bejegyzé­ sét, ebben az esetben a távozni készülő mozgó hosztét. Amikor a mozgó hoszt később visszatér, ugyanez a trükk használatos a router gyorstárának újbóli frissítésére. A tervezésben semmi nincs, ami megtiltaná, hogy egy mozgó hoszt saját idegen ügynöke legyen, de ez a megközelítés csak akkor működik, ha a mozgó hoszt (idegen ügynök minőségében) logikailag kapcsolódik az internethez a pillanatnyi helyén. Arra is képesnek kell lennie, hogy megszerezzen egy (ideiglenes) IP-alcímet saját haszná­ latra. Ennek az IP-címnek ahhoz a LAN-hoz kell tartoznia, amelyikhez pillanatnyilag kapcsolódik. Az IETF mozgó hosztokra vonatkozó megoldása számos olyan problémát is meg­ old, amelyet eddig nem említettünk. Például, hogyan találjuk meg az ügynököket? A megoldás az, hogy minden ügynök rendszeresen adatszórással közli a címét és a bizto­ sítani kívánt szolgálatot (hazai, idegen vagy mindkettő). Amikor egy mozgó hoszt el­ érkezik valahova, egyszerűen figyelhet ezekre a hirdetésnek (advertisement) neve­ zett adatszórásokra. Alternatívaként adatszórással kiadhat egy csomagot, amely beje­ lenti az érkezését, és remélheti, hogy a helyi idegen ügynök válaszol rá. A másik megoldandó probléma az, hogy mit tegyünk az udvariatlan mozgó hosztokkal, amelyek búcsúzás nélkül távoznak. A megoldás, hogy a bejegyzés csak egy rögzített időtartamig legyen érvényes. Ha nem frissítik rendszeresen, lejár, így az ide­ gen hoszt kitisztíthatja a táblázatait. További kérdés a biztonság. Amikor egy hazai ügynök egy olyan üzenetet kap, amely arra kéri, hogy Nóra minden csomagjait valamilyen IP-címre továbbítsa, jobb, ha nem engedelmeskedik, amíg meg nem győződött arról, hogy az üzenet forrása Nó­ ra és nem olyasvalaki, aki csak megszemélyesíteni próbálja. Erre a célra kriptográfiai hitelesítő protokollokat használnak. Az ilyen protokollokat a 7. fejezetben fogjuk ta­ nulmányozni. Az utolsó pont, amit a munkacsoport megcélzott, a mozgékonyság szintjeire vonat­ kozik. Képzeljünk el egy repülőgépet, fedélzetén egy Ethernettel, amit a navigációs és repülési számítógépek használnak. Ezen az Etherneten van egy rendes router, amely egy rádiókapcsolaton keresztül beszél a földön levő vezetékes internettel. Egy szép

508

SZÁMÍTÓGÉP-HÁLÓZATOK

napon valamelyik ravasz marketingfőnöknek az az ötlete támad, hogy minden karfába szereljenek egy Ethernet-csatlakozót, és így a mobil számítógépekkel rendelkező uta­ sok is bekapcsolódhatnak. Most már két mobilitási szintünk van: a légi jármű saját számítógépei, amelyek az Ethernethez képest mozdulatlanok, és az utasok számítógépei, amelyek ehhez képest mo­ bilak. Ezenkívül a fedélzeti router a földi routerhez képest mozog. Egy ilyen önmagában is mobil rendszeren belüli mobilitást, rekurzív alagút típusú átvitelekkel kezelhetünk.

5.6.8.

IPv6

Bár a CIDR-rel és a NAT-tal nyerhetünk még egy pár évet, mindenki világosan látja, hogy az IP napjai a jelenlegi formájában (IPv4) meg vannak számlálva. Az említett technikai problémákon kívül egy másik kérdés is bujkál a háttérben. Az Internetet ko­ rai éveiben nagyrészt az egyetemek, a csúcstechnológiai ipar, és az Egyesült Államok kormányzata (különösen a Honvédelmi Minisztérium) használták. Az Internet iránti érdeklődésben az 1990-es évek közepén bekövetkezett robbanással azonban mások is elkezdték használni, mégpedig jellemzően eltérő igényekkel rendelkező emberek. Ma egyfelől rengeteg, vezeték nélküli hordozható számítógéppel rendelkező ember hasz­ nálja az otthoni bázissal való kapcsolattartásra. Másfelől a számítástechnika, a táv­ közlés és a szórakoztatóipar közelgő konvergenciája miatt lehetséges, hogy nemsoká­ ra a világon minden telefon és televíziókészülék egy internetcsomópont lesz, ami mil­ liárdnyi hálózati zenehallgatásra és videózásra használt gépet eredményez. Ilyen kö­ rülmények között nyilvánvalóvá vált, hogy az IP-nek fejlődnie kell, és rugalmasabbá kell válnia. Látván, hogy ezek a problémák feltűnnek a horizonton, 1990-ben az IETF elkezdte a munkát az IP új verzióján, egy olyanon, amely soha nem fogy ki címekből, minden­ féle egyéb problémákat is megold, és ezek mellett rugalmasabb és hatékonyabb is. A fő célok a következők voltak: 1. A több milliárd hoszt támogatása, még nem hatékony címtartomány-hozzárendelés árán is. 2. A forgalomirányító táblázatok méretének csökkentése. 3. A protokoll egyszerűsítése, lehetővé téve ezzel a routereknek a csomagok gyorsabb feldolgozását. 4. A jelenlegi IP-nél jobb biztonság (hitelesítés és titkosság) biztosítása. 5. Nagyobb figyelem szentelése a szolgálat típusának, különösen a valós idejű ada­ toknál. 6. A többesküldés segítése, hatósugarak megadásának lehetővé tételével.

A HÁLÓZATI RÉTEG

509

7. Lehetőség arra, hogy egy hoszt a címének megváltoztatása nélkül barangoljon. 8. A protokoll fejlődésének lehetővé tétele. 9. Az új és a régi protokoll még évekig egymás mellett létezhessen. Az IETF egy, mindezen igényeket kielégítő protokoll kifejlesztése érdekében ja­ vaslatokra és vitára szóló felhívást tett közzé az RFC 1550-ben. Huszonegy válasz ér­ kezett, közülük nem mind volt teljes javaslat. 1992 decemberére hét komoly javaslat feküdt az asztalon. Ezek az IP kisebb módosításaitól kezdve addig terjedtek, hogy az egészet ki kellene dobni, és egy teljesen másmilyen protokollal helyettesíteni. Az egyik javaslat az volt, hogy a TCP-t a CLNP felett kellene futtatni, amely 160 bites címeivel mindörökre elegendő címtartományt biztosított volna, és egyesített vol­ na két fő hálózati rétegbeli protokollt. De sokan úgy érezték, ez annak lett volna az el­ ismerése, hogy az OSI világban tulajdonképpen valamit jól csináltak, ez az állítás pe­ dig politikailag helytelennek minősül Internet-körökben. A CLNP-t közvetlenül az IPről mintázták, így a kettő valójában nem különbözik annyira egymástól. Tulajdonkép­ pen a végül is kiválasztott protokoll sokkal jobban különbözik az IP-tői, mint a CLNP. Egy másik csapás a CLNP-re az volt, hogy gyatrán támogatja azokat a szolgálat­ típusokat, amelyek a multimédia hatékony átviteléhez szükségesek. A jobb javaslatok közül hármat közölt az IEEE Network (Deering, 1993; Francis, 1993; Katz és Ford, 1993). Sok vita, módosítás és pozícióharc után kiválasztották a Deering- és a Francis-féle javaslatok egy módosított kombinációját, amelyet ekkor már SIPP-nek (Simple Internet Protocol Plus) hívtak, és az IPv6 jelölést adták neki. Az IPv6 egészen jól megfelel a célnak. Megtartja az IP jó tulajdonságait, elveti vagy kevésbé hangsúlyossá teszi a rosszakat, és újakat is hozzáad, ahol szükség van rá. Általánosságban, az IPv6 nem kompatibilis az IPv4-gyel, de az összes többi Internetprotokollal igen, beleértve a TCP-, UDP-, ICMP-, IGMP-, OSPF-, BGP- és DNS-protokollokat, néhol úgy, hogy kisebb módosításokra van szükség (főleg a hosszabb címek kezelése miatt). Alább tárgyaljuk az IPv6 főbb tulajdonságait. További információ ta­ lálható az RFC 1883-1887-ben. Először, ami a legfontosabb, az IPv6-nak hosszabb címei vannak, mint az IPv4nek. 16 bájt hosszúak, amely megoldja azt a problémát, amelyet az IPv6-nak meg kell: egy gyakorlatilag végtelen Internet-címellátmányt biztosít. Nemsokára több mondani­ valónk is lesz a címekről. Az IPv6 második fő fejlesztése a fejrész egyszerűsítése. Csak 7 mezőt tartalmaz (ezzel szemben az IPv4 13-at). Ez a változás lehetővé teszi a routereknek, hogy gyor­ sabban dolgozzák fel a csomagokat, és ezáltal javítsák az átbocsátást. A fejrészt is rö­ videsen megtárgyaljuk. A harmadik fő fejlesztés az opciók jobb támogatása. Ez a változás szükségszerűen együtt jár az új fejrésszel, mert a korábban megkövetelt mezők most opcionálisak let­ tek. Ezenkívül az opciók megjelenésének a módja is más, így a routereknek egyszerű átlépni a nem nekik szánt opciókon. Ez a tulajdonság a csomagfeldolgozási időt gyor­ sítja fel. A negyedik terület, ahol az IPv6 jelentős előrelépést jelent, a biztonság. Az IETF-

510

SZÁMÍTÓGÉP-HÁLÓZATOK

nek elege volt azokból az újságtörténetekből, ahol koraérett 12 évesek a személyi számítógépeikkel bankokba és katonai bázisokba törnek be az interneten. Erősen érez­ hető volt, hogy valamit kell tenni a biztonság javítása érdekében. A hitelesítés és tit­ kosság az új IP kulcstulajdonságai. Ezeket aztán visszamenőleg az IPv4-be is beépí­ tették, így a biztonság területén a különbségek ma már nem olyan jelentősek. Végül, több figyelmet szenteltek a szolgálatminőségnek is. Erre már a múltban is tettek több, lagymatag kísérletet, de most, ahogy a multimédia jobban teret hódít az interneten, a dolog egyre sürgetőbbé válik.

A fő IPv6 fejrész Az IPv6 fejrész az 5.68. ábrán látható. A Verzió mező IPv6-nál mindig 6 (és az IPv4nél mindig 4). Az alatt az idő alatt, amíg átallnak az IPv4-ről, ami lehet, hogy egy év­ tizedet fog igénybe venni, a routerek megvizsgálhatják ezt a mezőt, hogy eldöntsék, milyen fajta csomagjuk van. Viszont ez mellékhatásként elveszteget pár utasítást a kritikus úton, így valószínűleg sok megvalósítás meg fogja próbálni ezt elkerülni, és az adatkapcsolati fejrészben fog használni valamilyen mezőt arra, hogy megkülönböz­ tesse az IPv4 csomagokat az IPv6 csomagoktól. Ily módon a csomagokat közvetlenül a megfelelő hálózati rétegnek adhatják át. Viszont az, hogy az adatkapcsolati réteg tudjon a hálózat csomagtípusáról, teljesen megszegi azt a tervezési elvet, miszerint egyik réteg sem tudhat a felette levő réteg által átadott bitek jelentéséről. A „Csináljuk helyesen" és „Legyen gyors" táborok közt kétségkívül hosszú és parázs viták lesznek. A Forgalmi osztály mezőt arra használják, hogy a különböző valós idejű szállítási követelményekkel rendelkező csomagok között különbséget tegyenek. Az IP-ben kezdettől fogva volt már ilyen célra szolgáló mező, de csak szórványosan akadtak olyan routerek, amelyek meg is valósították ezt a funkciót. Jelenleg is folynak kísér,. 1

32 bit 1

I

1

1

Verzió

I

i

1

|

I

1

I

)

I

1

1

I

l

I

l

I

I

1

I

I

I

I

I

1

I

I

Folyamcímke

Forgalmi osztály Adatmező hossza

-

Következő fejrész

-

Forráscím (16 bájt)

-

Célcím (16 bájt)

5.68. ábra. A rögzített IPv6 fejrész (kötelező)

Átugráskorlát

L_J

A HÁLÓZATI RÉTEG

511

letek annak megállapítására, hogyan lehetne legjobban felhasználni ezt a mezőt a multimédia-forgalomhoz. A Folyamcímke mező még mindig kísérletek tárgya, de arra lehet majd használni, hogy egy forrás és egy cél felállíthasson egy álösszeköttetést, bizonyos tulajdonsá­ gokkal és igényekkel. Például egy bizonyos hoszt bizonyos folyamatától egy bizonyos célhoszt bizonyos folyamatáig tartó csomagfolyamnak szigorú késleltetési igényei le­ hetnek, és ezért fenntartott sávszélességre van szüksége. A folyamot előre fel lehet ál­ lítani, és egy azonosítót adni neki. Amikor egy nem nulla Folyamcímke mezőjű cso­ mag tűnik fel, minden router kikeresheti a belső táblázataiból, hogy milyen különleges elbánást igényel. Tulajdonképpen a folyamok bevezetése kísérlet arra, hogy mind a datagram alapú alhálózat rugalmassága, mind a virtuális áramkör alapú alhálózatok garanciái együtt legyenek. Minden folyamot a forráscíme, a célcíme és a folyamszám azonosít, így sok folyam lehet egy időben aktív két adott IP-cím közt. Ilyen módon, ha más hosztoktól jövő, de ugyanolyan folyamszámmal rendelkező folyamok ugyanazon a routeren haladnak ke­ resztül, a router meg tudja őket különböztetni a forrás- és célcímeket használva. Várha­ tóan a folyamszámokat véletlenszerűen fogják választani, ahelyett, hogy 1-től kezdve folyamatosan osztanák ki azokat, hogy a routerek könnyen tudják azokat hash-elni. Az Adatmező hossza mező megmondja, mennyi bájt következik az 5.68. ábra 40 bájtos fejrésze után. A név megváltozott az IPv4 Teljes hossz mezejéhez képest, mivel a jelentés is módosult: a 40 fejrészbájtot már nem számolják bele a hosszba, mint régebben. A Következő fejrész mező kiengedi a zsákbamacskát. A fejrészt azon oknál fogva lehetett egyszerűsíteni, mert lehetnek további (opcionális) kiegészítő fejrészek. Ez a mező mondja meg, melyik kiegészítő fejrész következik a (jelenleg) hat közül, ha egyáltalán van ilyen. Ha a fejrész az utolsó IP-fejrész, a Következő fejrész mező azt mondja meg, melyik szállítási protokoll kezelőjének (TCP, UDP) kell a csomagot to­ vábbítani. Az Átugráskorlát mező gátolja meg a csomagokat abban, hogy azok örökké élhes­ senek. Ez gyakorlatilag ugyanaz, mint az Élettartam mező az IPv4-ben, vagyis egy olyan mező, amelyet minden átugrásnál csökkentenék. Elméletben az IPv4-ben ez idő volt másodpercekben mérve, de egy router sem használta így, ezért a nevet megvál­ toztatták, hogy arra utaljon, ahogy valójában azt használják. Következnek a Forrás címe és Cél címe mezők. Deering eredeti javaslata, az SIP, 8 bájtos címeket használt, de a felülvizsgálási folyamat során sok ember érezte úgy, hogy 8 bájtos címekkel az IPv6 néhány évtizeden belül ki fog fogyni a címekből, míg a 16 bájtos címek soha nem fogynak el. Más emberek érvelése szerint a 16 bájt túlzás, megint mások pedig 20 bájtos címeket részesítettek volna előnyben, hogy az IPv6 kompatibilis legyen az OSI-protokollal. Egy másik frakció változó hosszúságú címe­ ket akart. Sok vita után úgy határoztak, hogy a legjobb kompromisszum a rögzített hosszúságú 16 bites címek esete. A 16 bájtos címek leírására új jelölésrendszert is javasoltak. Nyolc, négy-négy he­ xadecimális számjegyből álló csoportként írjuk le a címet, a csoportok között kettős­ ponttal, valahogy így: 8000:0000:0000:0000:0123:4567:89AB:CDEF

512

SZÁMÍTÓGÉP-HÁLÓZATOK

Mivel sok cím sok nullát fog tartalmazni, három ésszerűsítést engedélyeztek. Elő­ ször is, egy csoporton belül a bevezető nullák elhagyhatók, így a 0123 helyett 123 ír­ ható. Másodszor, egy vagy több, 16 nullából álló csoport két kettősponttal helyettesít­ hető, így a fenti címből a következő lesz: 8000:: 123:4567:89 AB :CDEF Végül, az IPv4 címek két kettőspont és a régi, pontokkal elválasztott decimális szám formájában írhatók fel, például: ::193.31.20.46 Talán szükségtelen ennyire kihangsúlyozni, de rengeteg 16 bájtos cím létezik. Egész pontosan 2 128 , azaz körülbelül 3 x 1038 darab van belőlük. Ha az egész Föld, szárazföldön és vízen egyaránt, számítógépekkel lenne befedve, az IPv6 7 x 1023 IPcímet tenne lehetővé négyzetméterenként. A vegyészhallgatók észre fogják venni, hogy ez a szám nagyobb az Avogadro-számnál. Bár nem az volt a szándék, hogy a Föld felszínén minden molekulának saját IP-címet adjunk, azért nem is járunk annyira messze ettől. A gyakorlatban a címtartomány nem lesz hatékonyan kihasználva, mint ahogy a telefonszámok címtartománya sincsen. (A manhattani körzetszám, 212, majdnem tele van, de a wyomingi, 307, majdnem üres.) Az RFC 3194-ben Durand és Huitema ki­ számolták, hogy a telefonszámok kiosztását irányadónak véve még a legpesszimistább forgatókönyv szerint is bőven több mint 1000 IP-cím jut a Föld felszínének (száraz­ föld és víz egyaránt) minden négyzetméterére. Röviden, nem tűnik valószínűnek, hogy a belátható jövőben kifogynánk belőlük. Tanulságos összehasonlítani az IPv4 fejrészt (5.53. ábra) az IPv6 fejrésszel (5.68. ábra), hogy lássuk, mi maradt ki az IPv6-ból. Az IHL mező eltűnt, mert az IPv6 fej­ rész rögzített hosszúságú. A Protokoll mezőt is kivették, mert a Következő fejrész me­ ző megmondja, mi jön az utolsó IP-fejléc után (pl. egy UDP- vagy TCP-szegmens). Minden, a darabolással kapcsolatos mezőt eltávolítottak, mert az IPv6 másképp közelíti meg a darabolást. Először is, minden, az IPv6-hoz igazodó hoszttól elvárjuk, hogy dinamikusan határozza meg a használt datagram méretét. Ez máris kevésbé va­ lószínűvé teszi a darabolás előfordulását. Ezzel együtt a minimális méretet is meg­ emelték 576-ról 1280 bájtra, hogy 1024 bájt adatot és több fejlécet is lehetővé tegye­ nek. Ezenkívül, amikor egy hoszt egy túl nagy IPv6-csomagot küld, az a router, amely képtelen azt továbbítani, darabolás helyett egy hibaüzenetet küld vissza. Ez az üzenet arra utasítja a hosztot, hogy minden, ehhez a címzetthez tartó csomagot tördeljen fel a jövőben. Az, hogy a hoszt eleve jó méretű csomagokat küld, végül is sokkal hatéko­ nyabb, mint ha a routerek darabolják azokat menet közben. Végül az Ellenőrző összeg mező is eltűnt, mert kiszámítása nagyban csökkenti a hatékonyságot. A ma használt hálózatok megbízhatósága és azon tény mellett, hogy az adatkapcsolati és a szállítási rétegeknek rendszerint megvan a maguk ellenőrző össze­ ge, egy újabb ellenőrző összeg hozadéka kisebb, mint amekkora teljesítőképesség-

A

513

HÁLÓZATI RÉTEG

romlást okoz. Mindezen funkciók eltávolítása egy egyszerű és nagyszerű hálózati protokollt eredményezett. Az IPv6 ezzel a tervezéssel elérte célját: egy gyors, mégis rugalmas protokoll lett, bőséges címtartománnyal. Kiegészítő fejrészek A hiányzó mezők némelyikére azért továbbra is szükség van, így az IPv6 bevezette az (opcionális) kiegészítő fejrész (extension header) fogalmát. Ezek a fejrészek hasz­ nálhatók hatékony módon kódolt külön információ biztosítására. Jelenleg a kiegészítő fejrészeknek hat típusa definiált, ezeket az 5.69. ábra sorolja fel. Mindegyik opcioná­ lis, de ha több mint egy van jelen, akkor közvetlenül a rögzített fejléc után kell sze­ repelniük, és célszerűen a megadott sorrendben. Leírás

Kiegészítő fejrész Átugrás opciók

Különféle információk a routerek számára

Címzetti opciók

További információk a címzett számára

Forgalomirányítás opció

Laza lista a felkeresendő routerekről

Darabolás opció

A datagramdarabok kezelése

Hitelesítés opció

Az adó személyazonosságának ellenőrzése

Titkosított biztonsági adatmező

Információ a titkosított tartalomról

5.69. ábra. Az IPv6 kiegészítő'fejrészei Némelyik fejrésznek kötött a formátuma; mások változó számú és hosszúságú me­ zőt tartalmaznak. Ez utóbbiaknál minden tétel egy (Típus, Hossz, Érték) hármasként van kódolva. A Típus egy egybájtos mező, amely azt mondja meg, hogy melyik op­ cióról van szó. A Típus értékeket úgy választották meg, hogy az első 2 bit megmondja a routernek, mit tegyen, ha nem tudja feldolgozni az opciót. A lehetőségek: átugorni az opciót; eldobni a csomagot; eldobni a csomagot és visszaküldeni egy ICMP-csomagot; ugyanaz, mint az előző, azzal a különbséggel, hogy a többesküldéses címekre ne küldjön ICMP-csomagot (hogy egy rossz csomag ne generáljon több millió ICMP-jelentést). A Hossz is egy egybájtos mező. Azt mondja meg, milyen hosszú az érték (0 és 255 bájt közt). Az Érték 255 bájt erejéig bármilyen kívánt információ lehet. Az átugrás (hop-by-hop) fejrészt olyan információkhoz használják, amelyeket minden, útba eső routernek meg kell vizsgálnia. Eddig egyetlen ilyen opciót definiál­ tak a 64 KB-nál hosszabb datagramok támogatására. Ennek a fejrésznek a formátumát az 5.70. ábra mutatja. Amikor ezt az opciót használják, akkor a rögzített fejrészben az Adatmező hossza mező értékét 0-ra állítják be. Következő fejrész

0

194

4

Jumbogram adat mezejének hossza

5.70. ábra. Az átugrás opció kiegészítőfejrésze óriás datagramokhoz (jumbogramokhoz)

514

SZÁMÍTÓGÉP-HÁLÓZATOK

Mint minden kiegészítő fejrész, ez is egy olyan bájttal kezdődik, ami megmondja, hogy milyen lesz a következő fejrész. Ezt a bájtot egy másik követi, amelyik meg­ mondja, hogy hány bájt hosszú az átugrás opció fejrésze, leszámítva az első 8, kötele­ ző bájtot. Minden kiegészítő fejrész így kezdődik. A következő két bájt jelzi, hogy ez az opció a datagram méretét határozza meg (194-es kód), egy 4 bájtos szám formájában. Az utolsó négy bájt adja meg a datagram méretét. A 65 536 bájtnál kisebb méretek nem megengedettek. Ha ilyen mégis előfor­ dulna, az első router eldobja a csomagot, és visszaküld egy ICMP-hibaüzenetet. Az ilyen fejrész-kiegészítést használó datagramokat óriás datagramoknak vagy jumbogramoknak nevezik. A jumbogramok használata a szuperszámítógépes alkalmazások számára fontos, melyeknek gigabájt nagyságrendű adatokat kell hatékonyan átvinni az interneten. A címzetti opciók fejrészt olyan mezőknek szánták, melyeket csak a cél csomó­ pontban kell értelmezni. Az IPv6 kezdeti verziójában ide nem definiáltak mást, csak üres opciókat, hogy kitöltsék ezt a fejrészt 8 bájt többszörösére, ezt a fejrészt tehát eleinte nem fogják használni. Azért került bele mégis a protokollba, hogy az új router és hoszt szoftverek használhassák, ha egy napon valakinek egy címzetti opcióra lenne szüksége. A forgalomirányítás opció fejrész egy vagy több routert sorol fel, melyeket a cél­ hoz vezető úton fel kell keresni. Ez nagyon hasonlít az IPv4 laza forrás általi forga­ lomirányításához annyiban, hogy minden felsorolt címet sorban végig kell járni, de közben más, nem felsorolt routereket is útba lehet ejteni. A forgalomirányítás opció fejrész formátumát az 5.71. ábra mutatja. A forgalomirányítás opció kiegészítő fejrész első 4 bájtja négy 1 bájtos egész szá­ mot tartalmaz. A Következőfejrész és a Kiegészítőfejrész hossza mezőket már leírtuk. A Forgalomirányítás típusa mező megadja a fejrész hátralévő részének formátumát. A 0 típus azt jelenti, hogy egy fenntartott 32 bites szó követi az első szót, majd bizo­ nyos számú IPv6-cím következik. A jövőben más típusokat is kitalálhatnak, ha szük­ ség lesz rá. Végül a Hátralevő szegmensek száma mező tartja számon, hogy a listában szereplő címek közül még hányat nem látogattunk meg. Ezt minden router érintése után eggyel csökkentik. Amikor a számláló eléri a 0-t, akkor a csomag már csak ma­ gára hagyatkozhat, és nem kap több útmutatást arra nézve, hogy melyik utat kövesse. Ezen a ponton általában olyan közel van a céljához, hogy a legjobb útvonal már egy­ értelmű. Következő fejrész

Kiegészítő fejrész hossza

Forgalomirányítás típusa

Típus által meghatározott adatok

5.71. ábra. A kiegészítőfejrész forgalomirányításhoz

Hátralevő szegmensek száma

A HÁLÓZATI RÉTEG

515

A darabolási opció fejrésze az IPv4-hez hasonlóan kezeli a darabolást. A fejrész­ ben szerepel a datagramazonosító, a darabszám, és egy bit, ami azt mondja meg, hogy jönnek-e még további darabok. Az IPv4-től eltéró'en az IPv6-ban már csak a forráshoszt darabolhat fel egy csomagot, az útba esó' routerek nem. Ez ugyan nagy gondolkodásmódbeli törés a múlthoz képest, mégis egyszerűbbé teszi a routerek mun­ káját, és meggyorsítja a forgalomirányítást. Ahogy fentebb említettük, ha a router egy túl nagy csomaggal találja magát szemben, akkor eldobja azt, és visszaküld egy ICMP-csomagot a forráshosztnak. Ez az információ teszi lehetővé a forráshoszt szá­ mára, hogy ezt a fejrészt használva kisebb részekre darabolja a csomagot, és újra pró­ bálkozzon. A hitelesítés opció fejrésze egy olyan eljárást biztosít, mely által a csomag vevője meggyőződhet róla, hogy tényleg a feladó küldte-e a csomagot. A titkosított biztonsági adatmező lehetővé teszi, hogy egy csomag tartalmát úgy titkosítsuk, hogy csak a szándékaink szerinti vevő tudja elolvasni. Ezek a fejrészek titkosítási módszereket használnak küldetésük teljesítéséhez.

Viták az IPv6-tal kapcsolatban Tudván a nyílt tervezési folyamatról és arról, hogy sok érintett ember makacsul ra­ gaszkodott az álláspontjához, nem okozhat meglepetést az, hogy számos, az IPv6 ese­ tében hozott döntés erősen vitatott volt. Ezek közül egy párat foglalunk össze az aláb­ biakban. A részleteket lásd az RFC-kben. Már megemlítettük a vitát a címek hosszáról. Az eredmény egy kompromisszum lett: 16 bájtos rögzített hosszúságú címek. Egy másik csata bontakozott ki az Atugráskorlát mező hossza körül. Az egyik tá­ bor nagyon úgy érezte, hogy a maximális átugrásszám (a 8 bites mezőből adódó) 255re való korlátozása öreg hiba. Végül is, a 32 ugrásból álló utak ma már elterjedtek, és 10 év múlva sokkal hosszabb utak is elterjedtek lehetnek. Ezek az emberek azzal ér­ veltek, hogy egy hatalmas méretű cím használata előrelátó volt, de egy kicsi átugrás­ számláló használata rövidlátásra utal. Álláspontjuk szerint a legnagyobb bűn, amit egy számítástechnikus elkövethet, hogy valahol túl kevés bitet hagy meg. A válasz az volt, hogy minden mező megnövelésére akad érv, de ez egy felduzzadt fejrészhez vezetne. Egyébként is, az Atugráskorlát mező feladata, hogy a csomagok ne kószálhassanak hosszú ideig szerteszét, és 65 535 ugrás túlságosan hosszú. Végül, ahogy az Internet növekszik, egyre több és több nagytávolságú összeköttetés fog épül­ ni, lehetővé téve, hogy bármely országból bármely más országba legfeljebb fél tucat ugrással eljussunk. Ha 125 ugrásnál több szükséges eljutni a forrástól a megfelelő nemzetközi átjáróikhoz, akkor valami nincs rendben a nemzeti gerinchálózatokkal. A 8 bitet támogatók nyerték meg ezt a csatát. A másik hevesen vitatott téma a csomagméret volt. A szuperszámítógépes társada­ lom 64 KB-nál nagyobb csomagokat akart. Amikor egy szuperszámítógép átvitelbe kezd, akkor tényleg dolga van, és nem akarja, hogy 64 KB-onként megszakítsák. A nagy csomagok ellen az az érv merült fel, hogy ha egy 1 MB-os csomag elér egy 1,5 Mb/s-os TI vonalat, akkor ez a csomag 5 másodpercre lefoglalja a vonalat, és jól észlelhető

516

SZÁMÍTÓGÉP-HÁLÓZATOK

késleltetést okoz a szintén ezt a vonalat használó interaktív felhasználóknál. Itt komp­ romisszumot értek el: a rendes csomagokat 64 KB-ra korlátozták, de az átugrás kiegé­ szítő fejrész használható jumbogramok engedélyezésére. A harmadik forró téma az IPv4 ellenőrző összeg eltávolítása volt. Néhány ember ezt ahhoz hasonlította, mintha egy autóból kiszednénk a fékeket. Ha így teszünk, az autó könnyebb lesz, és gyorsabban haladhat, de ha valami váratlan esemény történik, akkor gond van. Az ellenőrző összegek elleni érv az volt, hogy bármely alkalmazásnak, amely való­ ban törődik az adatintegritással, amúgy is kell lennie egy ellenőrző összegének a szál­ lítási rétegben, így túlzás az IP-be is berakni egyet (az adatkapcsolati réteg ellenőrző összegén felül). A mozgó hosztok is vita tárgyát képezték. Ha egy hordozható számítógép félig kör­ berepüli a világot, működhet-e tovább a célban ugyanazzal az IPv6-címmel, vagy egy hazai és idegen ügynökös sémát kelljen használnia? A mozgó hosztok aszimmetriát is okozhatnak a router rendszerben. Könnyen meglehet, hogy egy kis mobil számítógép könnyen meghallja a nagy mozdulatlan router által kibocsátott erős jelet, de a mozdu­ latlan router nem hallja a mozgó hoszt által kibocsátott erőtlen jelet. Következéskép­ pen néhányan a mozgó hosztok számára kifejezett támogatást akartak beépíteni az IPv6-ba. Ez az erőfeszítés meghiúsult, amikor egyik javaslatban sem tudtak meg­ egyezni. Valószínűleg a legnagyobb csata a biztonság körül dúlt. Mindenki egyetértett, hogy szükség van rá. A harc afölött folyt, hogy hol és hogyan legyen. Először nézzük a hol kérdését. A hálózati rétegbe helyezése mellett az az érv szólt, hogy ekkor ez szabvá­ nyos szolgáltatássá válik, amelyet minden alkalmazás minden előzetes tervezés nélkül használhat. Az ellene szóló érv az, hogy a valóban titkos alkalmazások a végpontok közötti titkosításnál nem érik be kevesebbel, ahol is a forrásalkalmazás végzi a titkosí­ tást, és a célalkalmazás fejti vissza. Bármivel, ami ennél kevésbé biztonságos, a fel­ használó ki van szolgáltatva a hálózati réteg esetlegesen hibás megvalósításának, ame­ lyek fölött nem bír ellenőrzéssel. Erre az érvre az a válasz, hogy ezek az alkalmazások tartózkodhatnak az IP titkosítási tulajdonságainak kihasználásától, és maguk végezhe­ tik el a munkát. Erre pedig az a viszontválasz, hogy azok, akik nem bíznak meg abban, hogy a hálózat jól végezné ezt el, nem akarják megfizetni az ilyen képességgel rendelke­ ző lassú és terjedelmes IP-megvalósítások árát, még ha az ki is van kapcsolva. A biztonság elhelyezésének másik vetülete ahhoz kapcsolódik, hogy sok (de nem minden) országnak szigorú kiviteli törvényei vannak a titkosításra nézve. Néhány or­ szág, főképpen Franciaország és Irak, belföldön is nagyban korlátozzák a használatát, hogy az embereknek ne lehessenek titkaik a rendőrség előtt. Ennek eredményeként semmilyen olyan IP-megvalósítást, amely elég erős titkosítási rendszert használ ah­ hoz, hogy valóban hasznos legyen, nem lehet kivinni az Egyesült Államokból (és sok más országból) világszerte a vásárlókhoz. A legtöbb számítógépes cég erőteljesen el­ lenzi azt, hogy két szoftverkészletet kelljen karbantartania, egyet belföldi használatra és egyet kivitelre. Egy ponton nem volt vita, és ez az, hogy senki sem számít arra, hogy egy vasárnap reggel kikapcsolják az IPv4 Internetet, és az hétfő reggel IPv6 Internetként indul újra. Ehelyett elkülönült IPv6 „szigetek" fognak először átállni, kezdetben alagutakon ke-

A HÁLÓZATI RÉTEG

517

resztül kommunikálva. Ahogy az IPv6 szigetek nó'nek, úgy olvadnak össze egyre na­ gyobb szigetekké. Végül minden sziget össze fog olvadni, és az Internet teljesen át fog állni. Mivel a ma üzemelő' IPv4 routerekben hatalmas pénzek vannak, az átállási folyamat valószínűleg egy évtizedet fog igénybe venni. Ennél fogva óriási erőfeszíté­ sek történtek annak biztosítása érdekében, hogy az átállás amennyire csak lehet, fáj­ dalommentes legyen.

5.7.

Összefoglalás

A hálózati réteg szolgálatokat nyújt a szállítási rétegnek. Alapulhat virtuális áramkö­ rökön vagy datagramokon. A legfőbb dolga mindkét esetben az, hogy a csomagok forgalomirányítását végezze a forrástól a célcsoportig. A virtuális áramkör alapú alhálózatokban akkor hoznak forgalomirányítási döntést, amikor az áramkör felépül. Datagram alapú alhálózatokban ezt minden csomagra elvégzik. A számítógép-hálózatokban sokféle forgalomirányító algoritmus használatos. A statikus algoritmusok közé olyanok tartoznak, mint a legrövidebb út alapú forgalom­ irányítás és az elárasztás. A dinamikus algoritmusok közé tartozik a távolságvektor és a kapcsolatállapot alapú forgalomirányítás. A legtöbb meglevő hálózat ezek közül valamelyiket használja. Egyéb, fontos forgalomirányítási területek: a hierarchikus for­ galomirányítás, forgalomirányítás mozgó hosztok számára, az adatszóró valamint a többesküldéses forgalomirányítás és az egyenrangú hálózatok forgalomirányítása. Az alhálózatokban könnyen torlódás léphet fel, ami megnöveli a csomagok késlel­ tetését és csökkenti az átbocsátóképességet. A hálózattervezők a torlódást megfelelő tervezés révén igyekeznek elkerülni. A módszerek között van az újraadási politika, a pufferelés, a forgalomszabályozás és mások- Ha a torlódás mégis bekövetkezik, ke­ zelni kell. Visszaküldhetők lefojtó csomagok, eltávolítható a terhelés, vagy más mód­ szerek is alkalmazhatók. A torlódások puszta kezelésén túl a következő lépés az, hogy ténylegesen megpró­ bálunk elérni egy beígért szolgálatminőséget. Az erre használatos módszerek között megtalálhatjuk a kliens oldalán történő pufferelést, a forgalomformálást, az erőforrás­ foglalást, és a belépés-engedélyezést. A jó szolgálatminőség érdekében kigondolt megközelítések között vannak az integrált szolgáltatások (beleértve az RSVP-t is), a differenciált szolgáltatások és az MPLS. A hálózatok sok mindenben különbözhetnek egymástól, így amikor több hálózatot kapcsolnak össze, problémák adódhatnak. Néha a gondokat megkerülhetjük, ha egy csomagot alagút típusú átvitellel viszünk át egy idegen hálózaton, de ha a forrás- és célhálózat is eltér, akkor ez a megközelítés csődöt mond. Amikor a különböző háló­ zatoknak eltérő a maximális csomagméretük, segítségül hívhatjuk a darabolást. Az Internetnek sokféle, a hálózati réteghez kapcsolódó protokollja van. Ezek kö­ zött van adatátviteli protokoll, ilyen az IP-, de vannak vezérlő protokollok is, mint amilyen az ICMP, ARP és RARP, továbbá forgalomirányító protokollok, amilyen az OSPF és a BGP. Az Internet gyorsan kifogy az IP-címekből, ezért kifejlesztették az IP új verzióját, az IPv6-ot.

SZÁMÍTÓGÉP-HÁLÓZATOK

518

Feladatok 1. Adjon két példát olyan alkalmazásokra, amelyeknek az összeköttetés alapú szol­ gálat a megfelelő, majd adjon két olyan példát, amelyeknek az összeköttetés nél­ küli szolgálat a legjobb! 2. Előfordulhatnak-e olyan körülmények, amikor egy virtuális áramkör szolgálat a csomagokat nem sorrendhelyesen kézbesíti (vagy legalábbis ezt kellene tennie)? Indokolja! 3. A datagram alapú alhálózatok minden csomagot különálló egységként irányíta­ nak, függetlenül az összes többitől. A virtuális áramkör alapú alhálózatoknak nem kell ezt megtenniük, mivel minden adatcsomag egy előre meghatározott útvonalat követ. Ez a megfigyelés jelenti-e azt, hogy a virtuális áramkör alapú alhálózatok­ nak nincs szükségük arra a képességre, hogy elszigetelt csomagokat tetszőleges forrásból tetszőleges célhoz tudjanak irányítani? Indokolja válaszát! 4. Adjon három példát olyan protokoll-paraméterekre, amelyek összeköttetés felépí­ tésekor egyeztetés tárgyát képezhetik! 5. Fontoljuk meg a következő, a virtuális áramkör szolgálat megvalósítását érintő tervezési kérdést. Ha az alhálózaton belül virtuális áramköröket használunk, akkor minden csomagnak 3 bájtos fejrésszel kell rendelkeznie, és minden routemek 8 bájtnyi tárhelyet kell lekötni az áramkörök azonosításához. Ha belül datagramokat használunk, 15 bájtos fejrészre van szükség, de nem kell a routerekben táblázat­ hely. Az átviteli kapacitás 1 centbe kerül 106 bájtonként és átugrásonként. A routerek memóriái 1 centért vehetők meg bájtonként, és két év alatt amortizálód­ nak (csak munkaórákat számolva). A statisztikailag átlagos viszony 1000 másod­ percig tart, amely idő alatt 200 csomagot visznek át. Az átlagos csomagnak négy átugrásra van szüksége. Melyik megvalósítás olcsóbb és mennyivel? 6. Feltételezve, hogy minden hoszt és router megfelelően működik, és mindkettő szoftvere hibáktól mentes, van-e valami, bármilyen kicsi esély arra, hogy egy cso­ magot rossz célhoz kézbesítenek? 7. Tekintsük az 5.7. ábra hálózatát, de hagyjuk figyelmen kívül a vonalak súlyozá­ sát! Tegyük fel, hogy forgalomirányító algoritmusként az elárasztást használjuk. Sorolja fel, hogy milyen utakat fog az az A-ból a D-be küldött csomag bejárni, melynek ugrásszámlálójának maximális értéke 3! Mondja meg azt is, hogy hány ugrásnyi sávszélességet használ fel! 8.

Adjon egyszerű heurisztikus eljárást arra, hogy hogyan lehet egy adott forráscso­ móponttól egy adott célcsomópontig két utat (feltéve, hogy létezik két ilyen út) megtalálni egy olyan hálózatban, amely bármelyik kommunikációs vonal elvesz-

A HÁLÓZATI RÉTEG

519

tését túléli! A routereket kellően megbízhatónak tekintjük, tehát nem szükséges a routerek összeomlásának lehetó'sége miatt aggódni. 9. Vegyük az 5.13.(a) ábra alhálózatát. Távolságvektor alapú forgalomirányítást használunk, és a következő vektorok éppen most érkeztek meg a C routerhez: Btól: (5, 0, 8, 12, 6, 2), D-től: (16, 12, 6, 0, 9, 10), és E-től: (7, 6, 3, 9, 0, 4). A mért késleltetések sorrendben B-ig, D-ig és E-ig: 6, 3 és 5. Mi lesz C új forgalomirá­ nyító táblázata? Adja meg mind a használandó kimenő vonalat, mind a várt kés­ leltetést! 10. Ha egy 50 routerből álló hálózatban a késleltetéseket mint 8 bites számokat je­ gyezzük fel, és a késleltetési vektorokat másodpercenként kétszer cseréljük ki, mekkora sávszélességet emészt fel (duplex) vonalanként az elosztott forgalomirá­ nyító algoritmus? Tegyük fel, hogy minden routernek három vonala van más rou­ terek felé. 11. Az 5.14. ábrán a két ACF bitkészlet logikai VAGY kapcsolata minden sorban 111. Ez csak egy véletlen itt, vagy igaz minden alhálózatra minden körülmények között? 12. Milyen régió- és klaszterméreteket válasszunk egy 4800 routerrel történő hierar­ chikus forgalomirányítási esethez, hogy a lehető legkisebb méretű forgalomirá­ nyító táblázatot kapjuk egy háromszintű' hierarchiában? Jó kiindulás az a feltéte­ lezés, hogy közel optimális egy olyan megoldás, ahol k klaszterünk van, azok mind k régióból állnak, melyekben mindenhol k router van; ami azt jelenti, hogy k körülbelül 4800 köbgyökével egyenlő (kb. 16). Találjon próbálgatással olyan kombinációkat, ahol mindhárom paraméter 16 közelében van. 13. A szövegben azt állítottuk, hogy amikor egy mozgó hoszt nincs otthon, az otthoni LAN-jára küldött csomagokat a hazai ügynök fogja el. Egy 802.3 LAN feletti IPhálózaton hogyan viszi véghez ezt az elfogást a hazai ügynök? 14. Az 5.6. ábra alhálózatát tekintve mennyi csomagot generál egy adatszórás B-ből, ha a használt eljárás: (a) A visszairányú továbbítás? (b) A nyelőfa? 15. Tekintsük az 5.16.(a) ábra hálózatát! Képzeljük el, hogy egy új vonalat húzunk F és G közé, de az 5.16.(b) ábrán látható nyelőfa változatlan marad. Hogyan fog megváltozni az 5.16.(c)? 16. Számítson ki egy többesküldéses feszítőfát a C router számára az alábbi alhálózat­ ban, ha a csoporttagok az A, B, C, D, E, F, I és K routerekben vannak!

520

SZÁMÍTÓGÉP-HÁLÓZATOK

17. Az 5.20. ábrán bemutatott, A-tól induló keresés során a H és / csomópontok kül­ denek-e szét bármilyen üzenetet? 18. Tegyük fel, hogy az 5.20. ábra B csomópontja épp most indult újra, és nincs for­ galomirányítási információ a táblázataiban. Egyszer csak szüksége lesz egy, a Hba vezető útvonalra. Ekkor üzeneteket küld szét l-es, 2-es, 3-as stb. TTL értékkel. Hány kör alatt fog találni egy útvonalat? 19. Az egyenrangú keresésre szolgáló Chord-algoritmus legegyszerűbb változatában a keresések nem használnak finger-táblázatot. Ehelyett lineárisan haladnak végig a kör mentén, tetszőleges irányban. Meg tudja-e pontosan jósolni egy csomópont, hogy melyik irányban érdemes keresnie? Fejtse ki részletesen válaszát! 20. Tekintsük az 5.24. ábra Chord-körét. Tegyük fel, hogy egyszer csak bekapcsoló­ dik a 10. csomópont. Befolyásolja-e ez az 1. csomópont finger-táblázatát, és ha igen, hogyan? 21. Egy belül virtuális áramköröket használó alhálózat számára egy lehetséges torló­ dásvédelmi mechanizmus lehetne az, hogy egy router tartózkodik egy vett csomag nyugtázásától, amíg (1) meg nem tudja, hogy a virtuális áramkörön az utolsó átvi­ telét sikeresen vették és (2) nincs szabad puffere. Az egyszerűség kedvéért téte­ lezzük fel, hogy a routerek egy megáll-és-vár protokollt használnak, és minden virtuális áramkörnek van egy kijelölt puffere a forgalom mindkét irányában. Ha T másodpercbe kerül egy csomagot átvinni (legyen az adat vagy nyugta), és n router van az útvonalon, milyen sebességgel kézbesítik a csomagot a célhosztnak? Te­ gyük fel, hogy az átviteli hibák ritkák és a hoszt-router összeköttetés végtelenül gyors. 22. Egy datagram alapú alhálózatban a routerek eldobhatnak csomagokat, amikor erre szükség van. Annak a valószínűsége, hogy egy router eldob egy csomagot, p. Ve­ gyük azt az esetet, amikor a forráshoszt összeköttetésben áll a forrásrouterrel, amely összeköttetésben áll a célrouterrel, azon keresztül pedig a célhoszttal. Ha bármelyik router eldob egy csomagot, a forráshosztnak végül is lejár az időzítése,

A HÁLÓZATI RÉTEG

521

és újra próbálkozik. Ha mind a hoszt-router, mind a router-router vonalakat átugrásnak vesszük, mi az átlagértéke: (a) Az egy csomag által átvitelenként megtett ugrásoknak? (b) A sikeresen véghezvitt átviteleknek? (c) Az egy vett csomag által igényelt ugrásoknak? 23. írja le a figyelmeztető bites és a RED módszer közötti két fő különbséget! 24. Mondjon egy érvet arra, miért csak egy csomagot kell a lyukas vödör algoritmus­ nak óraütésenként átengednie, függetlenül attól, hogy milyen nagy a csomag! 25. Egy bizonyos rendszerben a lyukas vödör algoritmus bájtszámláló változatát használják. A szabály az, hogy egy 1024 bájtos csomagot, két 512 bájtos csoma­ got stb. lehet minden óraütéskor elküldeni. Adja meg ennek a rendszernek egy olyan súlyos korlátját, amelyet a szövegben nem említettünk! 26. Egy ATM-hálózat vezérjeles vödör sémát használ a forgalomformáláshoz. 5 us-onként kerül új vezérjel a vödörbe. Minden vezérjel egy 48 bájtnyi adatot tartalmazó cella továbbítását engedélyezi. Mi a legnagyobb fenntartható adatsebesség? 27. Egy 6 Mb/s-os hálózaton elhelyezkedő számítógépet egy vezérjeles vödör szabá­ lyoz. A vezérjeles vödröt 1 Mb/s sebességgel töltik, és az kezdetben 8 megabitét tar­ talmaz. Milyen hosszan forgalmazhat a számítógép a teljes 6 Mb/s-os sebességen? 28. Képzeljünk el egy folyam-meghatározást, ahol a maximális csomagméret 1000 bájt, a vezérjeles vödör sebessége 10 millió bájt/s, a vezérjeles vödör mérete 1 millió bájt, és a maximális adási sebesség 50 millió bájt/s. Milyen hosszú lehet egy löket maximális sebesség esetén? 29. Az 5.37. ábra hálózata RSVP-t használ többesküldéses fákkal az 1. és 2. hosztokhoz, amint az látható. Tegyük fel, hogy a 3. hoszt egy 2 MB/s sávszéles­ ségű csatornát igényel, az 1. hosztból jövő folyam számára, és egy másik, 1 MB/s-os csatornát, a 2. hosztból jövő folyam számára. Ezzel egy időben a 4. hoszt igényel egy 2 MB/s sávszélességű csatornát, az 1. hosztból jövő folyam számára, és az 5. hoszt is igényel egy 1 MB/s sávszélességű csatornát, a 2. hosztból jövő folyam számára. Összesen mekkora sávszélességeket foglalnak le ezen igények számára az A, B, C, E, H, J, K és L routerekben? 30. A CPU egy routerben 2 millió csomagot képes feldolgozni egy másodperc alatt. A felajánlott terhelés 1,5 millió csomag/s. Ha egy útvonalon a forrástól a címzettig 10 router van, mennyi idő fordítódik a sorban állásra és a CPU-kon történő feldol­ gozásra?

522

SZÁMÍTÓGÉP-HÁLÓZATOK

31. Vegyük a differenciált szolgáltatások használatát gyorsított továbbítással. Van-e garancia arra, hogy a gyorsított csomagok alacsonyabb késleltetést szenvednek, mint a szabályos csomagok? Ha igen, miért, ha nem, miért nem? 32. Szükséges-e a darabolás az egymás után kapcsolt virtuális áramkörökön alapuló összekapcsolt hálózatokban, vagy csak a datagram alapú rendszerekben? 33. Az alagút típusú átvitel egy egymás után kapcsolt virtuális áramkörökből álló al­ hálózaton magától értetődő: az egyik végen levő többprotokollos router egyszerű­ en felállít egy virtuális áramkört a másik végponthoz, és csomagokat ad át rajta. Használható az alagút típusú átvitel a datagram alapú alhálózatokban is? Ha igen, hogyan? 34. Tegyük fel, hogy az A hoszt össze van kötve az RÍ routerrel, az RÍ router össze van kötve az R2 routerrel, az R2 pedig össze van kötve a B hoszttal. Tegyük fel, hogy az A hoszt IP-szoftverének átadunk egy olyan TCP-üzenetet, ami 900 adatbájtot és 20 bájtnyi TCP-fejrészt tartalmaz, hogy szállítsa el azt a B hosztnak. Adja meg az IP-fejrész Teljes hossz, Azonosítás, DF, MF és Darabeltolás mezőit a három összeköttetésen keresztül áthaladó összes csomagra! Feltesszük, hogy az A-Rl összeköttetés 1024 bájtos maximális keretméretet támogat, ami tartalmazza a 14 bájtos keretfejrészt is, az R1-R2 összeköttetés maximum 512 bájtos keretmé­ retet támogat, benne 8 bájtos keretfejrésszel, az R2-B összeköttetésen pedig a ma­ ximális keretméret 512 bájt a 12 bájtos keretfejrésszel együtt. 35. Egy router olyan IP-csomagokat ont magából, melyeknek teljes hossza (az adat­ mező és a fejrész együtt) 1024 bájt. Feltéve, hogy a csomagok 10 másodpercig él­ nek, milyen maximális vonali sebességgel működhet a router anélkül, hogy fenn­ állna az IP-datagramazonosítók körbefordulásának veszélye? 36. Egy Szigorú forrás általi forgalomirányítás opcióval ellátott IP-datagramot fel kell darabolni. Gondolja, hogy az opciót minden darabba bemásolják, vagy ele­ gendő csak az első darabba belerakni? Indokolja válaszát! 37. Tegyük fel, hogy a B osztályú címek hálózati részéhez 16 helyett 20 bitet használ­ tunk volna. Hány B osztályú hálózat lett volna ekkor? 38. Alakítsa át a C22F1582 hexadecimális jelölésű IP-címet pontokkal elválasztott decimális jelölésre. 39. Az Interneten egy hálózatnak 255.255.240.0 az alhálózati maszkja. Legfeljebb hány hosztot képes kezelni ez a hálózat? 40. A 198.16.0.0-tól kezdve sok egymást követő IP-cím áll a rendelkezésünkre. Te­ gyük fel, hogy az A, B, C és D szervezetek rendre 4000, 2000, 4000 és 8000 címet

523

A HÁLÓZATI RÉTEG

igényelnek. Adja meg mindegyik szervezethez az annak kiosztott első és utolsó IP-címet, és az alhálózati maszkot a w.x.y.z/s jelölés szerint. 41. Egy router épp most kapta meg a következő új IP-címeket: 57.6.96.0/21, 57.6.104.0/21, 57.6.112.0/21 és 57.6.120.0/21. Lehet-e csoportosítani ezeket, ha mindegyik ugyanazt a kimeneti vonalat használja? Ha igen, mi lesz a csoportos cím? Ha nem, miért nem? 42. A 29.18.0.0-tól a 29.18.128.255-ig terjedő IP-cím készletet a 29.18.0.0/17 címbe csoportosítottuk. Ugyanakkor van egy eddig kiosztatlan, 1024 címet tartalmazó rés 29.18.60.0-tól 29.18.63.255-ig, amit most egyszerre kiosztanak egy olyan hosztnak, ami egy másik kimeneti vonalat használ. Szükséges lesz-e most fel­ bontani a csoportos címet blokkjaira, hozzáadni egy új blokkot a táblázathoz, hogy aztán meglássuk, lehetséges-e valamilyen újracsoportosítás? Ha nem, mit lehet tenni ehelyett? 43. Egy router forgalomirányító táblázatában a következő (CIDR) bejegyzések talál­ hatók: Cím/maszk 135.46.56.0/22 135.46.60.0/22 192.53.40.0/23 alapértelmezett

Következő ugrás 0. interfész 1. interfész 1. router 2. router

Mit tesz a router, ha rendre a következő IP-címeket tartalmazó csomagok érkeznek? (a) 135.46.63.10 (b) 135.46.57.14 (c) 135.46.52.2 (d) 192.53.40.7 (e) 192.53.56.7 44. Sok cég olyan politikát folytat, hogy kettő (vagy több) router segítségével köti össze a hálózatát az Internettel, hogy így biztosítson némi redundanciát arra az esetre, ha valamelyik router meghibásodna. Tartható-e ez a politika NAT-ok használata esetén? Indokolja válaszát. 45. Épp most magyarázta el az ARP-protokollt a barátjának. Amikor Ön végzett, ő azt mondja: „Értem. Az ARP szolgálatot biztosít a hálózati rétegnek, tehát az adat­ kapcsolati réteg része." Mit mond neki?

524

SZÁMÍTÓGÉP-HÁLÓZATOK

46. Az ARP és az RARP mindketten címeket képeznek az egyik címtérből a másikba. Ebben a vonatkozásban hasonlók. Mégis, a megvalósításaik alapvetően különbö­ zők. Mi az a fő dolog, amelyben különböznek? 47. írjon le egy olyan módszert, amivel az IP-darabokat össze lehetne állítani a célban. 48. A legtöbb IP-datagram összeállító algoritmusnak van egy időzítője, hogy egy el­ veszett darab ne foglalhassa le örökké az összeállító puffereket. Tegyük fel, hogy egy datagramot négy darabra darabolnak. Az első három darab megérkezik, de az utolsót késleltetik. Végül is az időzítő lejár, és eldobjuk a már a vevő memóriájá­ ban levő három darabot. Kicsivel később bebotorkál a negyedik darab. Mi vele a teendő? 49. Az IP-ben és az ATM-ben is az ellenőrző összeg csak a fejrészt védi, az adatot nem. Mit gondol, miért választották ezt így? 50. Egy Bostonban élő személy Minneapolisba utazik, és viszi magával a hordozható számítógépét is. Meglepetésére a minneapolisi úti céljánál levő LAN egy vezeték nélküli IP LAN, így nem kell hozzá csatlakoznia. Vajon szükséges azért még mindig végigcsinálni az egész ügyletet a hazai és idegen ügynökökkel, hogy az elevelek és a többi forgalom helyesen érkezzen meg? 51. Az IPv6 16 bájtos címeket használ. Ha egy egymillió címből álló blokkot utalnak ki minden pikoszekundumban, meddig fognak kitartani a címek? 52. Az IPv4 fejrészben használt Protokoll mező nincs jelen a rögzített IPv6 fejrész­ ben. Miért nem? 53. Amikor bevezetik az IPv6-protokollt, meg kell-e változtatni az ARP-protokollt? Ha igen, akkor a változások elvi Vagy technikai jellegűek? 54. írjon egy programot, amely elárasztásos forgalomirányítást szimulál. Minden cso­ mag tartalmazzon egy számlálót, amelyet minden átugrásnál csökkentenék. Ami­ kor a számláló eléri a nullát, a csomagot eldobják. Az idő diszkrét felosztású, és minden vonal egy csomagot kezel időintervallumonként. Készítsen három válto­ zatot a programból: minden vonal elárasztása, a bemeneti vonalon kívül minden vonal elárasztása, és csak a legjobb k (statisztikusán választott) vonal elárasztása. Hasonlítsa össze az elárasztást a determinisztikus forgalomirányítással (k= 1) a késleltetés és a felhasznált sávszélesség szempontjából. 55. írjon egy programot, amely diszkrét időosztást használva egy számítógép-hálóza­ tot szimulál. Minden router minden várakozási sorában az első csomag egyetlen átugrást tesz meg időintervallumonként. Ha egy csomag megérkezik és nincs hely a számára, akkor eldobják, és nem adják újra. Ehelyett van egy végpontok közötti protokoll, lejáró időzítésekkel és nyugtacsomagokkal kiegészítve, amely a csomagot

A HÁLÓZATI RÉTEG

525

a forrásroutertől újra elküldi. Ábrázolja a hálózat átbocsátóképességét, mint a vég­ pontok közötti időzítési intervallum függvényét, a hibaaránnyal paraméterezve! 56. írjon olyan függvényt, mely egy IP-router továbbítási funkcióját látja el! A függ­ vény egy IP-címet kap paraméterként. Ezenkívül hozzáférhet még egy globális táblázathoz, ami hármasokból áll. Minden hármas három egész számot tartalmaz: egy IP-címet, egy alhálózati maszkot és a használandó kimeneti vonalat. A függ­ vény CIDR használatával keresi ki a táblázatból az IP-címet, visszatérési értéke pedig a használandó kimeneti vonal. 57. Használja a traceroute (UNIX) vagy a tracert (Windows) programokat, hogy nyomon kövesse a saját gépétől a más kontinenseken lévő egyetemekhez vezető útvonalakat! Készítsen listát a felfedezett tengerentúli összeköttetésekről! Néhány hely a próbálkozásokhoz: www.berkelely.edu (California) www.mit.edu (Massachusetts) www.vu.nl (Amsterdam) www.ucl.ac.uk (London) www.usyd.edu.au (Sydney) www.u-tokyo.ac.jp (Tokió) www.uct.ac.za (Cape Town)