Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Távközlési és Médiainformatikai Tanszék Gyors linkhibajavítás IP hálózatokban TDK dolgozat Szerzők: Tóth Zoltán V. inf., Lajtha András Balázs V. inf. Konzulens: Enyedi Gábor TMIT, Rétvári Gábor TMIT Ipari konzulens: Császár András Ericsson Magyarország Kft.
Tartalomjegyzék Kivonat...4 Abstract...5 1. Bevezető...6 2. Hibajavítás hagyományos IP hálózatokban...8 2.1. Útválasztó protokollok...9 2.2. Open Shortest Path First (OSPF)...10 2.3. Hibajavítás az OSPF protokollal...13 3. Gyors IP hibajavítás...16 3.1. Néhány gyors IP hibajavító technika áttekintése...18 3.1.1. Equal Cost Multiple Path(ECMP)...18 3.1.2. Loop-free Alternates - LFA...19 3.1.3. Alagutazási technikák (tunneling)...20 3.1.4. Not-via...21 3.1.5. Multiple Routing Configuration - MRC...22 3.1.6. Failure Insensitive Routing - FIR...23 3.1.7. Összefoglalás...24 3.2. Failure Inferencing based Fast ReRoute FIFRL...25 4. A tesztrendszer fejlesztése...28 4.1. A laborkörnyezet bemutatása...28 4.2. Tervezés...28 4.3. A rendszer felépítése és működése...29 4.4. A fejlesztés során tapasztalt problémák...33 2
5. Mérési eredmények...36 5.1. A mérési környezet ismertetése...36 5.2. A mérési paraméterek és a topológia megválasztása...37 5.3. A mérési eredmények...39 5.4. A hibajavítási idők összehasonlítása...41 5.5. A csomagkésleltetések összehasonlítása...45 5.6. A mérések tanulságai...49 6. Az elvégzett munka értékelése...50 Irodalomjegyzék...51 3
Kivonat Napjainkban az Internet egyre bővülő szolgáltatásai szerves részévé váltak a gazdaságnak, tudománynak és a hétköznapi életnek. Azonban az utóbbi években megjelent, és egyre nagyobb teret hódító valós idejű alkalmazások (IP telefónia, videotelefon, IPTV) olyan új követelményeket támasztanak az IP hálózatokkal szemben, melyeket a mai IP eszközök nem tudnak megbízhatóan teljesíteni. Ennek okai többek között az IP alapú hálózatok hibajavítási mechanizmusainak elégtelenségében keresendők: a hálózat egyes szakaszainak meghibásodása esetén csomagvesztés és az elfogadhatónál nagyobb késleltetés léphet fel. Munkánk során arra a kérdésre kerestük a választ, hogy pusztán az IP lehetőségeit felhasználva megvalósítható-e valós idejű alkalmazások igényeit kielégítő hibajavítás. Pillanatnyilag több megoldás is vár a szabványosításra. Célunk volt, hogy ezen megoldásokat megismerjük, összehasonlítsuk, és a tanszéken rendelkezésre álló Linux-alapú tesztrendszeren implementáljuk. Végül, kiterjedt mérések segítségével azt vizsgáltuk, hogy az általunk implementált módszer, összevetve a hagyományos IP hibajavító metódusokkal, milyen gyorsan és milyen megbízhatósággal képes a fellépő meghibásodásokat kezelni. Dolgozatunkban először gyors áttekintést adunk az IP hálózatok felépítéséről és az útvonalválasztás általános szabályairól, majd bemutatjuk az IP hálózatokban hagyományosan használt, az útvonalválasztó protokollban implementált hibajavító metódusokat. Ezt követően ismertetünk és összehasonlítunk több megoldást, melyeket az IP hálózati hibák pro aktív, gyors javítására terveztek. Az összehasonlítás alapján (figyelembe véve az implementálhatóság és a tesztkörnyezet adottságait) kiválasztottunk egy konkrét gyors hibajavító módszert, a Failure Insensitive Fast ReRouting (FIR) metódust. Elkészítettünk egy FIR keretrendszert, amelyhez implementáltuk az élhibák javítására alkalmas FIFRL algoritmust. Ezt követően alapos méréseket végeztünk, melyek során hálózati meghibásodást hoztunk létre valós hálózatokban, és összehasonlítva vizsgáltuk a FIR, valamint az IP hagyományos hibajavító mechanizmusának képességét. Dolgozatunkat az elvégzett mérések eredményeinek értékelésével zárjuk és ajánlásokat fogalmazunk meg az IP gyors hibajavító módszerek megvalósítását illetve bevezetését illetően. 4
Abstract Nowadays, the growing services of the Internet have been turned into the integral part of economy, science and for everyday life as well. Usage of real-time applications (e.g. IP telephony, video telephony and IPTV) appeared in the past few years is increasing, and new requirements are laid on IP networks, which can not be reliably achieved by today's IP devices. The reason for this (among others) is the weak resilience of IP-based networks: the failure of some network parts causes packet loss and unacceptable delay. In our work we have been searching for a failure recovery mechanism, that fulfills all requirements of real-time applications, using only the services provided by the IP layer. Recently there are some possible solutions waiting for standardisation. Our aim was to learn and compare these methods with each other, and implement one of them in a Linux-based test system offered by Department of Telecommunications and Media Informatics. Finally, we have made some measurements, where we analyzed the failure recovery abilities (speed, reliability) of our system, compared to the technics used in traditional IP networks. In this document, we give a fast overview about the IP networks and routing in general. After that we introduce the failure recovery methods implemented in routing protocols, which are used in traditional IP networks. Following this we describe and compare a few technics designed for IP fast reroute. Considering the abilities of these technics and the test environment in the laboratory, we chose Failure Insensitive Fast ReRoute (FIR) method for implementation. We have created a modular framework system with a FIR algorithm, which can handle single link failures. After that we made thorough measurements in some scenarios, where we manually created failures in the network. We measured the abilities of our FIR system compared to the traditional failure recovery routing protocols. We are finishing our document with the evaluation of the test results, and we formulate recommendations regarding the implementation and launch of the IP fast reroute technics. 5
1. Bevezető Napjainkban az Internet gyors terjedésének köszönhetően a kommunikáció jelentős része ezen a közegen keresztül bonyolódik. A korábban már elterjedt alkalmazások mint például az elektronikus levelezés, csevegés mellett egyre nagyobb az igény a multimédiás alkalmazások nyújtotta szolgáltatásokra. A felhasználók az Interneten keresztül telefonbeszélgetéseket, videokonferenciákat bonyolítanak, televíziót néznek és így tovább. A valós idejű szolgáltatások köre folyamatosan bővül. Közös jellemzőjük, hogy alapvetően Internet Protokoll (IP) felett kell megvalósítani őket, hiszen manapság a teljes hálózati infrastruktúra IP alapú. Az új technológiák megjelenése és fejlődése a korábbiakhoz képest sokkal szigorúbb követelményeket támaszt a hálózattal szemben, melyet az Internet jelenleg nem képes maradéktalanul kielégíteni. Ennek oka az IP felépítésében keresendő: az általa nyújtott szolgáltatásra a legjobb szándék (best effort) jellemző, azaz a hálózat mindent megtesz annak érdekében, hogy a szolgáltatás minőségére (Quality of Service) vonatkozó kritériumokat például csomagkésleltetés, csomagvesztési arány teljesítse, de nem garantál semmit. A valós idejű alkalmazások szempontjából az egyik legkritikusabb pont a csomagkésleltetés, és ehhez kapcsolódóan a hibák gyors javítása. Az igazán jó szolgáltatáshoz garantálni kell, hogy a hálózat legfeljebb 50 ms alatt alkalmazkodni tudjon a topológiában bekövetkező változásokhoz, sajnos azonban a hagyományos IP hálózatokban használt hibajavító mechanizmusok lassúak, perces nagyságrendű javítást eredményeznek. A mindennapos szolgáltatások (levelezés, böngészés, adatátvitel stb.) még elviselnek ilyen mértékű kiesést, viszont a multimédiás alkalmazások ennél lényegesen gyorsabb hibajavító algoritmusokat követelnek meg az élvezhető minőség biztosítása érdekében. Másik komoly probléma, hogy a valós hálózatokban viszonylag ritkán fordulnak elő olyan hibák, amelyek állandósulnak, többségük úgynevezett tranziens hiba, melyek ideiglenes, rövid ideig tartó kiesést okoznak. Ezek megfelelő kezelése gondot okoz, hiszen a hiba bekövetkezésekor, majd annak megszűnésekor egyaránt alkalmazkodni kell a változáshoz, ami sok esetben tovább tart (hosszabb kieséssel jár), mintha az útválasztók egyszerűen megvárnák, amíg a megszakadt 6
kapcsolat helyreáll. Ezen időzítő bevezetésével lehet segíteni, viszont ekkor az állandósult hibákra való reagálás lesz lassabb, hiszen mindig meg kell várni, amíg az időzítő lejár nyilván egy hibáról nem lehet előre eldönteni, hogy mennyi ideig fog fennállni, vagyis az útválasztók nem tudnak különbséget tenni állandósult és tranziens hiba között. Olyan módszerre lenne szükség, amely a kétféle hibát egyforma gyorsan képes javítani. A felmerülő problémákra a gyors IP hibajavítás (IP Fast ReRoute IPFRR [1]) lehet a megoldás. Az alapgondolat az, hogy ha a rendszert előre felkészítjük az esetlegesen előforduló csomópont illetve linkhibákra (alternatív útvonalakat határozunk meg a célállomások felé), akkor az útválasztók gyorsabban képes lesznek reagálni a változásokra. A másik lényeges eltérés a hagyományos módszerekhez képest, hogy nem kell tájékoztatni a hálózat összes résztvevőjét a topológia változásairól, elég ha a hibában közvetlenül érintett csomópontok helyileg kezelik őket. Munkánk során célunk az volt, hogy tanulmányozzuk a létező IPFRR technikákat, összehasonlítsuk őket néhány szempontból, valamint valós hálózatokon végzett mérések segítségével megvizsgáljuk, hogy mennyivel gyorsabb hibajavítást lehet megvalósítani segítségükkel a hagyományos IP hibajavító technikákhoz képest. Ehhez áttekintettük a rendelkezésre álló irodalmat: egyrészt megismertük a hagyományos IP hálózatok hibajavító mechanizmusát erről szól a bevezetést követő második fejezet, másrészt felkutattuk az irodalomban fellelhető, szabványosításra váró gyors IP hibajavító megoldásokat, melyeket a harmadik fejezetben ismertetünk. Különböző praktikus szempontok szerint összehasonlítottuk az algoritmusokat, majd ez alapján kiválasztottunk egy konkrét IPFRR megoldást, a Failure Insensitive Fast ReRoute (FIR) technikát [9-10], melynek egyszeres linkhibát javító változatát egy Linux-alapú teszthálózaton implementáltuk. A fejlesztés folyamatát dolgozatunk negyedik fejezetében írjuk le. Az implementáció segítségével méréseket végeztünk, melyek során összehasonlítottuk a hagyományos és a FIR technikák hibajavító képességét. A mérési eredményeket az ötödik fejezetben tárgyaljuk. Végezetül az utolsó fejezetben összefoglaljuk munkánk tanulságait, valamint ismertetjük a továbbfejlesztési lehetőségeket. 7
2. Hibajavítás hagyományos IP hálózatokban Az IP protokoll önmagában nincs felvértezve hibajavító képességgel. Ennek ellenére az IPalapú hálózatok képesek hatékonyan kezelni a fizikai rétegbeli meghibásodásokat, mégpedig a hálózati útválasztás megfelelő megváltoztatásával. Ebben a fejezetben először bemutatjuk a statikus útválasztást majd bevezetjük az útválasztó protokollok fogalmát. Ezt követően az IP hálózatokban elterjedt útválasztó protokoll, az OSPF segítségével ismertetjük az útválasztó protokollok felépítését, és működését. Végül bemutatjuk, hogy az OSPF hogyan kezeli a hálózat meghibásodásait, és elemezzük, hogy az OSPF hibajavító képessége megfelel-e a real-time alkalmazások követelményeinek. Az IP hálózatok útválasztásának alapja [2], hogy minden útválasztó csak a csomag útjának következő csomópontját határozhatja meg. Ezt követően a következő csomópont felel a csomag célba juttatásáért. Ebből következik, hogy egy hálózat útválasztóinak összehangolt munkája szükséges ahhoz, hogy a csomagok optimális útvonalon haladjanak a hálózat tetszőleges két csomópontja között. Az útválasztás a csomópontokban egy táblázat, az úgynevezett forgalomtovábbítási táblázat (forwarding table) alapján történik, mely megmutatja, hogy adott címzett felé melyik következő csomóponthoz kell továbbítani a csomagot. Kezdetben a forgalomtovábbítási táblákat a hálózat operátora töltötte fel manuálisan. Ezt a megoldást a szaknyelv statikus útválasztásnak hívja. Statikus útválasztás esetén a hálózat valamely elemének meghibásodásakor az útválasztók nem változtatnak működésükön, és így a meghibásodott elemen korábban áthaladó forgalom elveszik. Ilyenkor a csomagvesztés addig áll fent, amíg az operátor nem értesül a hibáról és át nem konfigurálja az útválasztókat. A statikus útválasztás előnye, hogy az útválasztók feladata egyszerű, gyorsan elvégezhető. Hátránya azonban, hogy a használata nagy hálózatokban nehézkes. Emellett az emberi hibák és mulasztások gyakran nehezen felderíthető konfigurációs hibákhoz vezetnek. Mivel a hibajavítás operátori beavatkozást igényel, távolról sem felel meg a real-time alkalmazások századmásodperces elvárásainak [3]. Ahol a magas meghibásodási arány vagy a magas szolgáltatásminőségi követelmények miatt a statikus útválasztás mellett nem elégíthetőek ki 8
a hálózattal szemben támasztott elvárások, vagy a hálózat mérete, bonyolultsága túlnőtt az operátorok képességein, ott más megoldást kell találni. A megoldás a dinamikus útválasztás, vagyis az útválasztó protokollok használata [4]. Az útválasztó protokollok elsődleges feladata az útválasztók forgalomtovábbítási tábláinak automatikus kitöltése, és ennek karbantartása a hálózat topológiájának változásait követve. A fejezetben látni fogjuk, hogy a fenti mechanizmus emellett hogyan valósítja meg a hálózati hibák észlelését, és azok javítását is. Az útvonalakat az IP hálózatokban a forgalomtovábbítási táblákban találjuk, elosztva az útválasztók között, így azok konzisztens kitöltéséhez több útválasztó együttműködése szükséges. Ennek érdekében az útválasztó protokollok a hálózat topológiájáról közvetlen vagy származtatott információkat terjesztenek szét, majd ezen információk, és a korábban is rendelkezésre álló információk alapján minden útválasztó önállóan számolja ki az útvonalakat, és képezi le azokat útválasztó táblákká. A dinamikus útválasztás kétségtelen előnye, hogy minimális konfiguráció után az útválasztók autonóm módon képesek a forgalomtovábbítási tábláikat kitölteni, és karbantartani. Ezzel az emberi hibák lehetősége csökken, és azok megkeresése, javítása, könnyebbé válik. A statikus útválasztáshoz képest az útválasztó protokollok a hálózati hibákra gyorsan reagálnak, és ezzel csökkentik a hiba káros hatásainak mértékét. Hátrányuk azonban, hogy nagyobb hálózatokban esetlegesen jelentős jelzési forgalommal terhelik a hálózatot, és a futásukkal foglalják az útválasztók számítási kapacitását. Miután a következő fejezetben röviden ismertetjük az útválasztó protokollok különböző típusait, a dinamikus útválasztás mechanizmusát mutatjuk be az egyik elterjedt útválasztó protokollon. Ez a protokoll az OSPF. 2.1. Útválasztó protokollok Az első útválasztó protokollok az ARPANET-hez [5] készültek, mely homogén volt, minden eszköze felett rendelkezhettek a tervezők, és ezeknek az eszközöknek a száma mai szemmel csekélynek mondható volt. A mai világ hálózata, az Internet több ország több szolgáltatójának szállítóhálózatából, és az ezekhez csatlakozó magán és állami hálózatokból áll. Különböző 9
részeinek különböző felügyeletei vannak, akik felelnek az eszközök működtetéséért. Nem várható el, és nem is lenne kivitelezhető, hogy egy-egy meghibásodás híre az egész hálózatban terjesztésre kerüljön. Ezért az Internet útválasztás szempontjából több önálló rendszerre (Autonomous System, AS) van osztva. Az önálló rendszereken belül útválasztó protokollok (Interior Gateway Protocol, IGP), a rendszerek között határ útvonalválasztó protokollal (Exterior Gateway Protocol, EGP) terjesztik a hálózati topológiára vonatkozó információkat. Az EGP-kre nem fogunk bővebben kitérni a dolgozatunkban, az érdeklődő olvasó vonatkozó irodalmat [6]-ben találhat. Az IGP-k [7] két nagy csoportra oszthatók: a távolságvektor (distance vector) és a kapcsolatállapot-alapú (link state) protokollokra. A továbbiakban csak a kapcsolatállapot-alapú protokollok ismertetésére szorítkozunk, mivel ezek hatékonyabb hibajavításra képesek. Természetesen a távolságvektor alapú technikáknak is vannak előnyei, ennek tárgyalása azonban túlmutat a dolgozat hatáskörén. A kapcsolatállapot-alapú protokollok egyik legfontosabb alapelve, hogy folyamatosan biztosítják minden útválasztó számára a hálózati topológia teljes ismeretét. Ez a rendszert robusztussá teszi, hiszen a hálózat mindenkori állapotának ismeretében az útválasztók a csomagokat bármely célállomáshoz el tudják juttatni, amennyiben létezik hozzá útvonal. A következőkben a kapcsolatállapot-alapú útválasztás működését, és a hibajavítást az egyik legelterjedtebb IGP-n, az OSPF-en fogjuk bemutatni. 2.2. Open Shortest Path First (OSPF) Az OSPF (Open Shortest Path First, [8]) útválasztó protokoll célja egy, a hálózati topológia változására gyorsan reagáló, és a hálózatot mégis kevéssé terhelő útválasztó protokoll megvalósítása volt. Az OSPF tisztán IP alapú megoldás, a csomagok továbbításához szükséges információcsere is IP csomagokban jut el egyik útválasztótól a másikig. Az OSPF-et futtató útválasztók a hálózat állapotáról kapcsolatállapot táblázatokat tartanak fent. Ezek a táblázatok útválasztók és IP alhálózatok, valamint útválasztók és útválasztók közötti közvetlen összeköttetések költségeit tárolják. (Közvetlen összeköttetésről akkor beszélünk, ha két útválasztó egymást nem IP címek segítségével, hanem a saját interfésze kiválasztásával éri el. Az ilyen összeköttetések nem IP alhálózatok, ezért kezeli őket az OSPF külön.). 10
Az útválasztók a továbbítási tábláik tartalmát a kapcsolatállapot táblázatok alapján határozzák meg. Ezért fontos, hogy ezek a táblázatok mindig a hálózat valós összeköttetéseit tartalmazzák, és minden útválasztó kapcsolatállapot táblázata megegyezzen. Az útválasztó protokollok tehát három feladatot kell hogy ellássanak a hálózat működtetéséhez: egyrészt fel kell térképezniük a hálózatban az összeköttetéseket és útválasztókat, másrészt ezt az információt terjeszteniük kell a hálózat útválasztói közt, végül karban kell tartaniuk a továbbítási táblákat. Az OSPF a hálózat feltérképezéséhez hagyományosan a Hello protokollt alkalmazza. Ennek lényege, hogy az útválasztók periodikusan ún. Hello csomagokat cserélnek a szomszédos csomópontokkal. Ha két szomszédos útválasztó küldött egymásnak Hello csomagot, és a szomszéd fogadta is azt, akkor az útválasztók az összeköttetést működőképesnek tekintik. A protokoll azt is megszabja, hogy egy bizonyos számú elmaradt Hello üzenet után az összeköttetést sérültnek kell tekinteni. Ha egy új, eddig még ismeretlen útválasztótól érkezik Hello csomag, akkor azt szomszédosnak kell tekinteni. A Hello csomagok tartalmazzák az útválasztó szomszédait is, így aszimmetrikus kapcsolatok is felderíthetőek. Amellett, hogy a szomszédos útválasztók között a hálózat feltérképezéséhez szükséges alapvető kommunikációt biztosítja, a Hello protokoll másik fontos szerepe a kiemelt útválasztó kiválasztása. Az útválasztók minden alhálózatban kijelölnek egy kiemelt útválasztót (és egy tartalék kiemelt útválasztót). A kiemelt útválasztók gyűjtik össze, és terjesztik az adott alhálózat összeköttetéseinek állapotát. Ez a gyakorlat, bár a helyes működéshez nem feltétlenül szükséges,, hozzájárul a jelzésforgalom csökkenéséhez. Az OSPF a hálózat állapotának terjesztéséhez Kapcsolat Állapot Jelentéseket (Link State Advertisement, LSA) használ. Az LSA-k összeállításának, küldésének, igénylésének összetett mechanizmusát a vonatkozó dokumentum [8] részletesen tárgyalja, jelen írásunkban megelégszünk az alapok ismertetésével. Az LSA-knak két csoportja van: az első egy alhálózat állapotát írja le (mely útválasztók csatlakoznak az adott alhálózathoz). Ezeket a csomagokat az alhálózat kijelölt útválasztója állítja össze és küldi szét. A másik csomagtípus az egyes útválasztók összeköttetéseinek állapotáról (melyik hálózatokhoz csatlakozik az adott útválasztó) tájékoztatja a többi útválasztót. Az 11
útválasztók periodikusan generálnak és küldenek szomszédaiknak állapotjelentéseket, melyek a hálózaton belül elárasztással terjednek. Emellett a topológiai változásokat az útválasztók az LSA-k segítségével azonnal jelezhetik a hálózat többi részének. OSPF a mindenkori legrövidebb utakon továbbítja a csomagokat a célcím felé. Több legrövidebb út esetén a terhelést egyenlően osztja el a két útvonal közt. A legrövidebb utakat a kapcsolatállapot adatbázisból számolják ki az útválasztók Dijkstra algoritmusának segítségével. A fentebb leírtak felvetik a skálázhatóság kérdését. A kapcsolatállapot-alapú protokollok az állapot-jelentéseket az egész hálózatról és az egész hálózatban terjesztik. Ez a hálózat méretének növekedésével növekvő terhelést jelent a hálózati útválasztóknak, és az összeköttetéseknek is. Emellett a Dijkstra algoritmus futásideje és memória-igénye négyzetesen nő a csomópontok számával. Az OSPF ezt a problémát a körzetek (Area) bevezetésével hidalta át (lásd 1. ábra). Az LSA-k ezután csak a körzeteken belül terjednek, és csak a körzetekről hordoznak információt. A körzeteket egy gerinckörzet köti össze, mely a saját csomópontjainak elérhetősége mellett az egyes körzetek elérhetőségeit is terjeszti és számolja. A körzetek jellemzően egy-egy IP címtartománynak felelnek meg. A körzetek alkalmazásával a hálózat növekedése nem jár együtt a hálózati terhelés, és a számítás-igény túlzott növekedésével. Azonban a számolt útvonalak már nem lesznek feltétlenül a legrövidebbek két különböző körzetbe tartozó csomópont között. A körzetek jó megválasztásával ez a negatív hatás minimalizálható. 12
OSPF Autonomous System Area 0 Backbone Area 1 Area Border Router Area Border Router Area 2 AS Border Router AS Border Router Route to another AS Route to another AS 1. ábra: Az OSPF hálózati hierarchiája. A körzetek között Area Border Router-ek teremtenek átjárást, míg az AS határán AS Border Router-ek helyezkednek el. 2.3. Hibajavítás az OSPF protokollal A protokoll ismertetése után rátérünk az OSPF hibajavító mechanizmusára. A hiba nem más, mint a hálózati topológia megváltozása. Mivel a fizikai link szakadást az OSPF sem tudja orvosolni, ezért a hibajavítás úgy definiálható, mint a csomagtovábbítás igazítása az új hálózati topológiához. Ennek eléréséhez először fel kell ismerni a topológia változását, azt terjeszteni a hálózatban, kiszámolni az új legrövidebb utakat, és végül átkonfigurálni az útválasztó táblákat. Az OSPF-ben hagyományosan a hibadetektálás a korábban ismertetett Hello protokoll feladata. A hiba detektálása úgy valósul meg a Hello protokoll segítségével, hogy a hibás összeköttetésen a szomszédos csomópontok közt periodikusan cserélt Hello csomagokból egy adott 13
számú nem érkezik meg, ezáltal az összeköttetést az útválasztók is meghibásodottnak tekintik. A hibadetektálás sebességét Hello protokoll esetén két, konfigurálható paraméter határozza meg. Az első a Hello Interval, a Hello csomagok periódusideje. A másik paraméter a Router Dead Interval, mely azt határozza meg, hogy egy felismert kapcsolatot az útválasztók mennyi ideig tekintenek aktívnak a legutolsó beérkező Hello üzenettől kezdve. Ez a hálózat tranziens hibáira való érzéketlenséget fejezi ki: minél nagyobb az értéke, annál hosszabb átmeneti meghibásodásokat tolerál anélkül, hogy a hálózat átkonfigurálását kezdeményezné. Jellemző értéke egyes írások szerint a Hello csomagok periódusának kétszerese, más források a Hello Interval négyszeresét ajánlják. A Hello Interval, és a Router Dead Interval legkisebb választható értéke egy másodperc, ami real-time alkalmazások esetén elfogadhatatlan alsó korlátot ad a hibajavítás idejére. Bár ennél kisebb értékek is alkalmazhatóak az OSPF forráskódjának módosításával, a Hello csomagok kezelése a kívánt századmásodperces nagyságrendben már olyan mértékben terheli a hálózati elemeket, hogy azok teljesítménye mérhetően romlik. A hibajavítási idő csökkentése érdekében a Hello üzenetek segítségével történő hibadetektálás mellett az OSPF egy másik, gyors linkhiba-észlelési lehetőséget is biztosít. A gyors linkhibaészlelés lényege, hogy a hálózati interfész vezérlőprogramja (driver), amint szakadást érzékel az interfészen, egy rendszerüzenetben azonnal képes értesíteni az OSPF protokollt, így annak nem kell megvárnia a Router Dead Interval leteltét a hiba kezelésének megkezdéséhez. A gyors linkhibaészlelési lehetőség előnye, hogy a Hello protokoll kiküszöbölésével gyakorlatilag késleltetés nélkül képes hibát detektálni. Hátránya azonban, hogy a vezérlőprogramban speciális támogatást igényel, így ez a funkció nem minden hálózati interfészen érhető el. A hiba észlelését követően az útválasztók, amelyek a hibát észlelik, LSA-kban tájékoztatják a hálózat többi útválasztóját a változásról. Az LSA-k terjednek a hálózatban, amíg az összes útválasztó értesül a meghibásodásról. A folyamat zárólépése a megváltozott legrövidebb útvonalak kiszámítása, és azok betöltése az útválasztó táblákba. Miután röviden ismertettük a reaktív, a hibát globálisan javító megoldás lépéseit, kitérünk az ebben rejlő előnyökre, és hátrányokra. 14
A hagyományos útválasztó protokollok előnye a robusztusságuk. Tetszőleges számú hibát képesek kijavítani, akár egyszerre, akár egymás után lépnek fel azok a hálózatban. Ennek oka, hogy a hálózati hibát a protokollok a hálózati topológia változásaként tekintik, és egyszerűen igazodnak az új topológiához, akármilyen mértékben tér is az el a korábban ismerttől. A fent vázolt mechanizmus másik tagadhatatlan előnye, hogy a hálózatban a továbbítási útvonalak állandósult állapotában a csomagok minden esetben a legrövidebb úton kerülnek továbbításra hogy ezt miért hangsúlyozzuk, arra a későbbi fejezetekben derül fény. Azért lehetséges ez, mivel a hálózat minden útválasztója megegyező képet tart fent a hálózatról, így a számolt legrövidebb út következő csomópontja is ugyanazt a legrövidebb utat számolja, és használja a továbbítás alapjául. Ennek az állapotnak a kialakításáról és fenntartásáról az LSA-k gondoskodnak. Nem elhanyagolható hátrány azonban, hogy meghibásodás esetén az útválasztók különböző, és a valós állapottól is eltérő képet tárolhatnak a hálózatról. Ennek oka az LSA-k terjedési sebességében keresendő. Következménye pedig, hogy az eltérő hálózati topológiákból számolt továbbítási táblák a hálózatban hurkokat okozhatnak. A hurkok pedig a hálózat túlterheléséhez, így a szolgáltatás minőségének romlásához és a hibajavítás idejének növekedéséhez vezethetnek. Tranziens hibák esetén ez a hatás akkumulálódhat is, ha az újabb állapotváltozás még azelőtt áll be, hogy az első változás hatása lecsengett volna. Ez ellen késleltetésekkel, türelmi idők bevezetésével védekezik az OSPF: korlátozva van például, hogy milyen gyakran számolhatja újra az útválasztó a továbbítási tábláit. 15
3. Gyors IP hibajavítás Az előző fejezetben rámutattunk arra, hogy a hagyományos IP hálózatokban használt hibajavító algoritmusok sok esetben lassúak, az egyre növekvő igényeket elsősorban multimédiás forgalom esetén nem képesek maradéktalanul kielégíteni. Olyan új módszerre lenne szükség, amely a kapcsolatállapot-alapú protokollokhoz (link-state protocol) hasonlóan robosztus, ugyanakkor lényegesen gyorsabban és hatékonyabban képes kezelni a hálózatban fellépő csomópont- illetve linkhibákat, valamint a tranziens hibákat egyaránt. Mielőtt rátérnénk a lehetséges megoldások tárgyalására, tekintsük át mégegyszer röviden, hogy melyek azok a legfontosabb okok, amelyek a kapcsolatállapot-alapú protokollok lassú reagálásáért felelősek, és hogyan kellene orvosolni őket. Az egyik legnagyobb problémát a globális információáramlás (global response) jelenti. Tudjuk, hogy minden csomópontnak ismernie kell a hálózat teljes topológiáját, ezért amikor valamilyen változás következik be elérhetetlenné válik egy link/útválasztó, vagy éppen ellenkezőleg új elemek jelennek meg a hálózatban, ennek tényét az érintett csomópontoknak ismertetniük kell a többiekkel is, hogy alkalmazkodni tudjanak az új állapothoz. Ez a folyamat már kisebb hálózatokban is időigényes az információ terjedése, az új útvonalak kiszámítása és betöltése miatt, ráadásul olyan csomópontokat is érinthet, amelyek egyébként nem vesznek részt az adott irányú forgalomban. Az átállás alatt csomagvesztés lép fel, amely akár a hálózat egészének forgalmát is érintheti. A globális információáramlás miatt a hálózatban fellépő hiba megfelelő detektálása nagyon fontos. Említettük, hogy a kapcsolatállapot-alapú protokolloknál ez nehezen kivitelezhető, hiszen ha túl korán reagálunk egy tranziens hibára, akkor a hálózat könnyen többállapotúvá válhat és hurkok (microloop-ok) jelenhetnek meg, ugyanakkor ha egy állandó hibára lassan reagálunk, akkor pedig megnő a csomagvesztés és a késleltetés. A kapcsolatállapot-alapú protokollok lassúságát okozza az is, hogy reaktívak, azaz a hiba fellépésekor a hibáról való értesülést követően kezdik el kiszámolni a csomópontok az új útvonalakat. A legrövidebb utak kiszámítása ugyan a mai korszerű útválasztóknak köszönhetően 16
viszonylag gyors, körülbelül 40 mikroszekundum csomópontonként [11], azonban egy nagy hálózatban már nem hanyagolható el: például 1000 csomópont esetén ~40 ms a számítási idő. Ennél jelentősebb időveszteséget okoz az új útvonalak betöltése az útválasztó memóriájába, azaz a csomagtovábbítási szabályok táblázatainak (Forwarding Information Base FIB) frissítése, amely nagyságrendileg 100 ms-ot vesz igénybe. A jelterjedési késleltetések további időveszteséget okoznak, hiszen a hálózat legközelebb akkor lesz csak konzisztens állapotban, amikor a hibáról legutoljára értesült útválasztó is kiszámolta (és betöltötte) az új útvonalakat. A fenti problémák orvoslása az úgynevezett gyors IP hibajavítás (IP Fast Reroute IPFRR, [1]) feladata. A három legfontosabb cél a globális információáramlás elnyomása illetve késleltetése, lokális akciók kivitelezése, valamint proaktív hibakezelés. A rendszer működése a következőképpen képzelhető el: a hálózatban esetlegesen fellépő hiba javításában nem minden csomópont vesz részt legalábbis egy ideig, csupán a hiba közvetlen környezetében lévő útválasztók. Az érintett csomópontok a meghibásodott link vagy csomópont helyett ideiglenesen egy ismert és előre beállított alternatív útvonalra terelik át a forgalmat, minimalizálva ezzel az új útvonal kiszámításának és betöltésének következményeképpen fellépő csomagvesztést, továbbá a hiba tényét nem terjesztik szét a hálózatban azonnal. Ha tranziens hibáról van szó, akkor annak megszűnését követően visszatérhetnek az eredeti útvonalakra, így a többiek észre sem veszik az átmeneti zavart, ha viszont egy bizonyos idő elteltével a hiba még mindig fennáll, akkor az már állandó jellegűnek tekinthető. Ez utóbbi esetben már szükséges lehet a hálózat többi résztvevőjének értesítése a topológiában történt változásról. Nyilvánvalóan az egyes csomópontokat előre fel kell készíteni a hálózatban előforduló hibákra annak érdekében, hogy probléma esetén gyorsan tudjanak reagálni, és ne veszítsenek értékes időt az új útvonalak keresésével, vagyis proaktív hibakezelésre van szükség. Az elsődlegesen használt útvonalakon kívül a csomópontok minden célállomáshoz előre kiszámítanak egy (esetleg több) alternatív útvonalat is, és ha a hálózatban valahol hiba keletkezik, egy ilyen másodlagos útvonalra terelik át a forgalmat. A helyi problémakezelés (local response) miatt a hiba helyétől távolabbi csomópontok semmit sem tudnak a hibáról, így a csomópontról csomópontra történő továbbítás következtében 17
előfordulhat, hogy az eredeti útvonalválasztás alapján visszaküldik a csomagot. Fontos az ilyen hurkok elkerülése, ezért az alternatív útvonalszámítás algoritmusának tervezésére nagy hangsúlyt kell fektetni. 3.1. Néhány gyors IP hibajavító technika áttekintése Ebben a fejezetben megnézzük, milyen főbb gyors hibajavító megoldási javaslatok születtek IP hálózatokban. A szóban forgó módszert először az MPLS (Multiprotocol Label Switching) gerinchálózati technikában, valamint az SONET/SDH (Synchronous Optical NETworking, Synchronous Digital Hierarchy) optikai hálózatokban alkalmazták, a cél ezen technológia előnyeinek átültetése IP alapú hálózatokba is. Az MPLS (és a SONET/SDH) képes bármely hibát 50 ms-on belül kijavítani; továbbá az Ericsson kutatói Ethernet hálózatokban is kifejlesztettek egy módszert, amely hasonlóan 50 ms alatt képes csomópont- illetve linkhibákat javítani [12], így ez az érték egyaránt a gyors IP hibajavító algoritmusokkal szemben támasztott követelmény. 3.1.1. Equal Cost Multiple Path(ECMP) Az egyik legrégebbi és egyúttal legegyszerűbb gyors IP hibajavító technika az Equal Cost Multiple Path (ECMP), amely ma már a legtöbb hálózatban alapértelmezetten be van kapcsolva. A módszer azt használja ki, hogy az egyes célállomások felé több egyforma hosszú legrövidebb út is vezethet (különböző linkeken), amelyek között a csomópontok normál működés esetén megpróbálják egyenlő arányban megosztani a forgalmat. Így azon túl hogy adott esetben jobban ki tudják használni a rendelkezésre álló sávszélességet hiba esetén, azaz ha valamelyik útvonal kiesik, a megmaradtra irányítják át a forgalmat. 18
S 5 15 5 R1 R2 R3 5 20 15 5 R4 R5 15 5 D Elsődleges Alternatív 2. ábra: ECMP Az ECMP egyszerű, és nagyon könnyen implementálható, hiszen a meglévő elemeken kívül nincs szükség újakra, valamint nem kell kooperáció más útválasztókkal sem. Hátránya, hogy habár jól működik mindaddig, amíg egynél több egyforma legrövidebb út létezik a cél felé, ez nem minden esetben van így. A 2. ábrán látható, hogy az S csomópontnak D felé három ECMP útvonala van: R1, R2 és R3 irányában, így ha például meghibásodik az elsődleges útvonalon lévő S-R2 link, a két alternatív útvonalat fogja használni. Ugyanakkor az R2 útválasztó csak egyetlen legrövidebb úton éri el a D csomópontot, ezért ha az R2-R5 link hibásodik meg, az ECMP nem tudja kezelni a helyzetet. 3.1.2. Loop-free Alternates - LFA Az ECMP-hez hasonló elven alapul a Loop-free Alternates (LFA), viszont valamivel több esetben alkalmazható. Az LFA technika lényege, hogy az elsődleges útvonal továbbra is a legrövidebb út lesz ugyan, de a csomópontok az alternatív útvonalak számításakor nemcsak a más legrövidebb úton elhelyezkedő szomszédokat veszik figyelembe, hanem bármelyik szomszédot, amely náluk közelebb van a célhoz. Nincsen globális információáramlás, tehát az esetleges hiba tényét az útválasztók nem hirdetik azonnal a hálózatban; mégsem alakulhatnak ki hurkok, hiszen a csomópontok úgy továbbítják a csomagokat a szomszédaiknak, hogy a legrövidebb út sohasem a küldő útválasztón keresztül vezessen. Gyakorlatilag minden egyes lépésben csökken a hátralévő távolság egészen a célállomásig ez nyilvánvalóan csak hurokmentes út esetén lehetséges. 19
A módszer előnyei hasonlóak az ECMP-hez, de még mindig nem fed le minden eshetőséget. Könnyen elképzelhető ugyanis, hogy egy csomópontnak csak egyetlen olyan szomszédja van, amelyik közelebb van nála valamelyik célállomáshoz, így ha a közöttük lévő link megszakad, az LFA nem talál alternatív útvonalat. Tekintsük az alábbi, 3. ábrát! Látható, hogy az S csomópont legrövidebb útja a D célállomás felé az R2-n keresztül vezet. Tételezzük fel, hogy megszakadt az S-R2 link, ekkor a második legrövidebb úton a következő csomópont R1. Azonban S mégsem R1 felé továbbítja a csomagokat, hanem R3 felé, különben hurok keletkezne: R1 nem tud semmit a meghibásodott linkről, és számára a D felé vezető legrövidebb út S-en keresztül vezet. Abban az esetben, ha az S-R3 link súlya is 1 lenne, akkor az LFA nem lenne képes alternatív útvonalat találni a D csomópont felé. 1 R1 10 S 1 R2 1 D 10 R3 10 Elsődleges Alternatív 3. ábra: LFA Szimulációs tesztek során az LFA a meghibásodások körülbelül 75-80%-ában talált javító útvonalat [11]. 3.1.3. Alagutazási technikák (tunneling) A gyors IP hibajavító technikák fejlődésének következő lépcsőfoka az alagutaztatás (tunneling), amellyel az LFA hibajavító képességén igyekeztek javítani. Az alapötlet a következő: tételezzük fel, hogy van a csúcsoknak egy olyan halmaza, amelyek az eredeti útvonalválasztás alapján visszaküldenék a csomagokat a hibát kezelő csomópont felé, azaz hurok alakulna ki. A cél az hogy kijuttassuk a csomagokat a hálózat ilyen hiba sújtotta környékéből. Ha egy csomópontnak nincs 20
olyan közvetlen szomszédja, amely közelebb lenne a célállomáshoz nála (azaz nem működik az LFA), akkor keresni kell egy távolabbi, legalább két ugrásra lévő csomópontot, ami viszont már biztosan közelebb van, és egy IP alagúton keresztül megpróbálni eljuttatni hozzá a csomagokat. Ez akár a meghibásodott link túloldalán lévő útválasztó is lehet, hiszen onnan már biztosan hurokmentes útvonalon haladhatnának tovább a célig a csomagok, de természetesen bármely közbülső csomópont megfelel, amely teljesíti ezt az alapvető feltételt. Nyilvánvalóan az alagutaztatás olyan helyzetekben is működőképes lehet, amelyeket az LFA már nem képes megoldani, ám ez a módszer sem tud kezelni minden esetet: például ha minden csomópont a hibát kezelő útválasztón keresztül akarja továbbítani a forgalmat; továbbá csomóponthibák javítása még mindig hurok kialakulásához vezethet. Gyors IP hibajavításban alagút használata egyrészt előnyös, mert ilyen technikák már léteznek, ugyanakkor a csomagok becsomagolása következtében fellépő többletköltség (overhead) miatt az alagút alkalmazása egyúttal a módszer hátrányának is tekinthető. A szerzők az alagutazás technikáról szóló cikküket [13] később visszavonták, és a módszer helyett annak egy továbbfejlesztett változatát, az úgynevezett Not-via technikát publikálták [14], amelyet a következő alfejezetben mutatunk be röviden. A Not-via várhatóan néhány éven belül a Cisco Systems és az IETF (Internet Engineering Task Force) által szabványosításra is kerül. 3.1.4. Not-via Az alagút alapú megoldás továbbfejlesztése az úgynevezett Not-via technika, ami már link- és csomóponthibát egyaránt javítani tud. Ennél a módszernél a csomópontok minden egyes interfészéhez két IP címet rendelünk: egy normál és egy not-via IP címet. Hiba esetén a hibát kezelő csomópont a csomagokat megpróbálja eljuttatni a megszakadt link túloldalán lévő csomópont szomszédjához, vagyis a következő utáni útválasztóhoz, ahonnan már az eredeti legrövidebb hurokmentes úton lehet továbbítani azokat (4. ábra). Azért nem a közvetlen szomszédjának küldi, mert nem lehet egyértelműen megállapítani, hogy csak a közöttük lévő link szakadt meg, vagy pedig maga a csomópont állt le. Annak érdekében, hogy ne alakuljon ki hurok a hálózatban, a hibát kezelő csomópont a következő utáni útválasztónak nem a normál IP címére küldi a csomagokat, 21
hanem becsomagolja őket (alagutaztatás), azaz eléjük rak egy IP fejrészt. Ebben a célállomás IP címe nem más, mint a következő utáni útválasztó ugyanazon interfészének not-via címe. Ezzel jelzi minden más útválasztónak a hálózatban, hogy melyik hibásnak vélt csomópont nélküli topológián kell továbbítaniuk a csomagokat nem rajta keresztül (not via the dead node). Forward packet to C not-via B A B C D E Hiba sújtotta környék Hibamentes környék 4. ábra: A Not-via (tunneling) technika alapgondolata Természetesen minden útválasztónak előre ki kell számítania ezeket az alternatív útvonalakat, vagyis nemcsak a potenciális célok felé, hanem a tartományon belüli útválasztók minden egyes notvia címére is meg kell határozni a legrövidebb utakat (utóbbi esetben a not-via címhez tartozó szomszédos csomópont nélküli hálózatban). Érezhetően ez sok számítást igénylő feladat, amely az alagút használata mellett a módszer nagy hátránya. 3.1.5. Multiple Routing Configuration - MRC Az eddigiekhez képest egészen más elven alapul a Multiple Routing Configuration (MRC) működése. Az egyes útválasztók különböző úgynevezett konfigurációkat alakítanak ki az eredeti hálózati topológiából, mégpedig az élsúlyok eltérő felvételével; az alternatív útvonalak számítását ezeken a konfigurációkon végzik el. Amikor valamely csomópont elkerülésével kell kialakítani az útvonalakat (csomóponthiba), egy olyan konfigurációt választanak, ahol a csomóponthoz tartozó élek súlyai kellően nagyok ahhoz, hogy a legrövidebb út ne rajtuk keresztül vezessen a különböző célállomások felé. Az ilyen csomópontot elszigetelt csomópontnak, éleit pedig tiltott éleknek nevezzük. Tiltott éleken nyilván csak az elszigetelt csomópont által indított, vagy pedig az oda tartó csomagok mehetnek át az adott konfigurációban. A linkhiba javítása hasonlóképpen történik: az útválasztók az él súlyát végtelenre állítják, így semmilyen forgalom nem halad át rajta. Ezeket az 22
éleket elszigetelt éleknek nevezzük. A hálózat minden eleme szerepel valamelyik konfigurációban elszigeteltként, így minden esetlegesen előforduló csomópont- vagy linkhiba javítható. Az MRC techinka könnyen átlátható, megvalósítása mégis nehézségekbe ütközik. Azt ugyanis, hogy egy adott csomagot az útválasztóknak melyik konfiguráció szerint kell továbbítaniuk, az IP fejrész DSCP (Differentiated Services Code Point) mezőibe kódolt azonosító mondhatná meg [15]. Mivel ezek a mezők az összes többivel együtt más célokra vannak fenntartva, nincs szabványosítható szabad fejlécbit az MRC konfigurációk azonosításra IPv4-ben. Esetleg alagutaztatás is elképzelhető, ahol egy-egy privát cím egy-egy konfigurációt jelöl. 3.1.6. Failure Insensitive Routing - FIR A kapcsolatállapot-alapú protokollokra ilyen például az előző fejezetben tárgyalt OSPF épülő útválasztók a csomagok továbbítását kizárólag a célállomás címe alapján végzik, függetlenül attól hogy a csomag melyik szomszédjuktól érkezett. A FIR technika alapgondolata ezzel szemben az, hogy a csomópontok az útvonalak számításakor figyelembe veszik a csomag érkezési irányát is, azaz interfész alapú továbbítást valósítanak meg. Ha egy útválasztó olyan szomszédjától kap csomagot, ahonnan az adott cél felé hibamentes esetben nem érkezhetne (nem a legrövidebb úton történik a csomagtovábbítás), akkor ebből arra következtet, hogy valahol a hálózatban hiba van. A helyi problémakezelés miatt nem tud semmit a hibáról a hibát észlelő csomópontok nem terjesztik a hálózatban, viszont a hurok elkerülése érdekében az ilyen szokatlan irányból érkező csomagokat egy alternatív útvonalon fogja továbbítani. Ezeket az interfész-specifikus útvonalakat természetesen előre ki kell számítani a gyors reagálás érdekében (proaktív hibakezelés). A FIR előnye, hogy nem igényel módosítást az IP fejlécben, és alagutaztatásra sincs szükség, továbbá bármely egyszeres csomópont- vagy linkhibát képes hurokmentes úton javítani (a két változat némileg eltér egymástól). A módszer hátránya, hogy az alternatív útvonalak kiszámítása valamivel bonyolultabb, mint a hagyományos útvonalszámító algoritmusok, valamint látni fogjuk, hogy bizonyos esetekben hosszabb úton javít, mint a hagyományos technikák. 23
3.1.7. Összefoglalás A következő fejezetben részletesen tárgyaljuk az általunk megvalósított, egyszeres linkhibát javító FIR elméleti hátterét, előbb azonban az eddigiek összefoglalásaként az alábbi táblázatban összehasonlítjuk a különböző gyors IP hibajavító megoldásokat néhány szempont szerint. Útválasztó technika Típus (család) Hibajavító képesség Hibajavítási idő Korlátozások, megjegyzések OSPF IGP 100.00% Másodperces nagyságrendű + Akár többszörös csomóponti- illetve linkhibát képes javítani + Gyors hibadetekció az alsóbb réteg használatával Globális információáramlás ECMP IP FRR 20-30% 100 ms + OSPF-be beépíthető LFA IP FRR 75-80% 100 ms + Egyszerű Alap IP FRR támogatás Not-via IP FRR 100.00% 100 ms + Következő utáni csomópont koncepcióból származó előnyök + Szabványosítás folyamatban Gyors alagutaztatást igényel Speciális címmenedzsmentre van szükség MRC IP FRR 100.00% 100 ms + Akár többszörös hibákat is képes javítani Túl sok konfiguráció lehetséges FIR IP FRR 100.00% 100 ms + Meglévő elemekkel működik Többszörös hibák hurokhoz vezethetnek Interfész-specifikus csomagtovábbítást igényel 1. táblázat: Az útválasztó technikák összehasonlítása 24
3.2. Failure Inferencing based Fast ReRoute FIFRL Mérlegelve az egyes módszereket a megvalósíthatóság szempontjából, a FIR előnyös tulajdonságai alapján döntöttünk úgy, hogy az egyszeres linkhibát javító FIR technikát (FIFRL) a gyakorlatban is kipróbáljuk. A FIFRL technika működése a következő: legyen adott egy hálózat, amelyet egy G = (V, E) irányítatlan (kétirányú), súlyozott gráffal modellezünk. V jelöli a csúcsok (útválasztók), E pedig az élek (linkek) halmazát. Az élek súlya mindkét irányban azonos, amely egy hálózattól elvárható követelmény. Egy csomópont valamely interfészéhez tartozó csomagtovábbítási szabályok számításához meg kell adni az éleknek egy olyan részhalmazát, amelyek közül legalább egy meghibásodása esetén a csomópont adott interfészére meghatározott csomag érkezhet. Ezt a d halmazt kulcsélek halmazának, vagy röviden kulcshalmaznak nevezzük, és K j i -vel jelöljük. Jelentése: azon élek halmaza, amelyek közül bármely(ek) kiesése következtében a d célállomás felé tartó csomagok a j csomópontból az i csomópontba továbbítódnak, azaz áthaladnak a j i linken. d Egy u v él eleme a K j i kulcshalmaznak, ha az alábbi két feltétel mindegyikét kielégíti: 1. ha az u v link működik, a d célállomás felé tartó csomagok az i csomópontból a j csomópontba továbbítódnak 2. ha az u v link meghibásodik, akkor az u csomóponttól a d célállomásig vezető legrövidebb út átmegy a j i élen d A kulcshalmaz definíciójából következik, hogy egy K j i halmaz üres, ha a d célállomás felé vezető legrövidebb úton az i csomópont a j után következik (hibamentes hálózatban). A formális leírás könnyebb megértéséhez tekintsük a 5. ábrán látható topológiát! Legyen a küldő csomópont R1, a célállomás pedig R6. Hibamentes esetben a legrövidebb út az R2 csomóponton keresztül vezet, azaz a hálózat normál működése esetén R1 nem kaphat R2-től olyan csomagot, amelynek címzettje az R6 jelű csomópont. A fentiek alapján ez azt jelenti, hogy a R6 K R1 R2 halmaz üres. Ugyanakkor ha például az R2 R5 link meghibásodik, akkor az R2 25
csomópont az R6 felé tartó csomagokat R1-nek fogja küldeni. Hasonlóképpen ha az R5 R6 link nem működik, akkor a csomagok útja az R5 csomóponttól: R5 R2 R1 R4 R6. A két esetből adódik, hogy ha az R1 jelű csomópont olyan csomagot kap R2-től, amelynek címzettje R6, akkor ebből arra következtethet, hogy az R2 R5 illetve az R5 R6 link valamelyike (vagy akár mindkettő) meghibásodott. Formálisan ez azt jelenti, hogy az R6 célállomásra és az R2 R1 linkre R6 nézve K R2 R1 = { R2 R5, R5 R6 } 1 R2 1 R1 2 R3 2 R5 1 R6 3 R4 3 5. ábra: A FIR mintatopológia A kulcshalmazokat a hálózatot reprezentáló gráfban minden csomópontra mint célra, és minden élre (mindkét irányban) meg kell határozni. Egy j i interfész kulcshalmazai a következő algoritmus segítségével számolhatók: d 1. Minden d V csúcsra K j i = 2. Minden i V csúcsra meghatározzuk a tőle induló legrövidebb utat a többi csúcs felé. Ez egy i gyökerű fa lesz, jelöljük T i -vel 3. Ha egy j V csúcs hibamentes esetben az i-től bármely cél felé vezető legrövidebb úton (a T i fában) nem a következő csúcs, akkor az algoritmus véget d ér, a K j i halmaz üres marad minden d V csúcsra 4. Jelölje V ' azon csúcsok részhalmazát, amelyek a T i fában j után következnek, tehát amelyek az i csomópontból indulva j-n keresztül érhetők el (ezen csúcsokra mint 26
célokra nézve lehetnek kulcsélek) 5. Minden u v E { j i } élre meghatározzuk a legrövidebb utakat az u v él nélküli gráfban az u csúcstól indulva. Jelöljük az így kapott fát T u u v -vel Ha j i T u u v (azaz az u v él nélküli gráfban az u-tól bármely cél felé vezető legrövidebb úton szerepel a j i él), akkor a T u u v fa i után következő csúcsai közül azokra nézve, amelyek a V ' csúcshalmaznak is elemei, az u v él kulcsél, tehát hozzá kell venni d minden ilyen célcsúcshoz tartozó K j i halmazhoz A fenti algoritmust minden j i élre le kell futtatni. Látható hogy az interfésztől függő útvonalválasztás miatt lényegesen több csomagtovábbítási szabályt kell meghatározni a látszólag bonyolult, ám viszonylag alacsony számítási igényű algoritmus segítségével: szimulációs tesztek alapján a FIR-nek körülbelül hatszor annyi időre van szüksége ugyanazon hálózatban az útvonalak kiszámításához, mint a hagyományos hibajavító algoritmusoknak [16], ugyanakkor megfelelő kódoptimalizálással ez a jövőben még javítható. A FIR (mint már említettük) önmagában alkalmazva csupán egyszeres csomópont- vagy linkhiba esetén biztosít hurokmentes javító útvonalakat, többszörös hibák esetén ez már nem garantálható. Ugyanakkor könnyedén képes együttműködni a hagyományos hibajavító mechanizmusokkal, hiszen lényegében csak az interfész-független útvonalszámító algoritmust kell lecserélni a csomópontokban a fent leírt interfész-specifikus útvonalszámításra alkalmasra. A két rendszert kombinálva hatékony hibakezelés valósulhat meg: az elképzelés szerint az útválasztók a teljes hálózati topológia ismeretében a legrövidebb utak kiszámítása mellett az interfészspecifikus útvonalakat is meghatározzák. Amikor csomópont- vagy linkhiba keletkezik a hálózatban, a szomszédos útválasztók a meghibásodott linke(ke)n áthaladó forgalmat átirányítják egy alternatív útvonalra (lokális akciók). A hálózat többi résztvevője következtetni tud a hibára a csomagok érkezési iránya alapján, így másik úton fogják továbbítani őket a hurok elkerülése érdekében. Ha a hiba állandósul, akkor ennek tényét a szomszédos csomópontok elterjesztik a hálózatban; az útválasztók újraszámolják az elsődleges és az interfész-specifikus útvonalakat az új topológiának megfelelően. 27
4. A tesztrendszer fejlesztése Az előző fejezetben áttekintettük a különböző gyors IP hibajavító algoritmusokat, valamint részletesen bemutattuk a FIFRL útválasztó technika elméleti hátterét. Jelen fejezetben a FIFRL rendszer gyakorlati megvalósítása során hozott tervezői döntésekről, a rendszer felépítéséről, működéséről, valamint az implementálás nehézségeiről lesz szó. 4.1. A laborkörnyezet bemutatása A rendszer fejlesztéséhez, illetve teszteléséhez a Távközlési és Médiainformatikai Tanszék biztosított számunkra 7 darab számítógépet a QoSIT laboratóriumban. Mai viszonylatban ezek nem korszerű gépek (legalábbis hardver szempontjából), viszont céljainknak többé-kevésbé megfeleltek: Hardver: Processzor: Intel Pentium II. 400 MHz Memória: 128 MB Hálózati kártyák: Intel Corporation 82557/8/9 [Ethernet Pro 100] Szoftver: Operációs rendszer: GNU/Linux Debian 4.0 ( Etch ) Kernel: 2.6.18 (módosított hálózati kártya driverrel, lásd később) GCC verzió: 4.1.2 (2006-11-15) 4.2. Tervezés Az előző fejezetben említettük, hogy a gyors IP hibajavító algoritmusok célja eredetileg nem a hagyományos IP hálózatokban lévő rendszerek lecserélése, hanem sokkal inkább velük együttműködve azok hátrányainak kiküszöbölése, hibajavító képességük fejlesztése előnyös 28