Gyors linkhibajavítás IP hálózatokban

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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban ú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 Border Router

Area 1

Area Border Router

AS Border Router

Area 2

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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban 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


R1

5

5 20

5

S

R2

15

R4

15 5

R3

15 5

D

R5 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

Gyors linkhibajavítás IP hálózatokban 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é.

R1

1 1

S

10 1

R2

10

D 10 Elsődleges Alternatív

R3 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

Gyors linkhibajavítás IP hálózatokban 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

Gyors linkhibajavítás IP hálózatokban 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 D

C Hiba sújtotta környék

E

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

Gyors linkhibajavítás IP hálózatokban é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

+ Akár többszörös csomóponti- illetve linkhibát Másodperces képes javítani nagyságrendű + Gyors hibadetekció az alsóbb réteg használatával − Globális információáramlás

OSPF

IGP

100.00%

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 halmazt kulcsélek halmazának, vagy röviden kulcshalmaznak nevezzük, és K

d 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. Egy u→v él eleme a K

d 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 A kulcshalmaz definíciójából következik, hogy egy K

d 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

K

R6 R1  R2

halmaz üres. Ugyanakkor ha például az R2→R5 link meghibásodik, akkor az R2

25

Gyors linkhibajavítás IP hálózatokban 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 nézve K

R6 R2  R1

= { R2→R5, R5→R6 }

R2

1 2

R1

1 2

R3

R5

3

1

R6

3

R4 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: 1. Minden d ∈ V csúcsra K

d 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

-vel

j ∈ V csúcs hibamentes esetben az i-től bármely cél felé vezető

3. Ha egy

legrövidebb úton (a T ér, a K

i

d j i

4. Jelölje V

'

i

fában) nem a következő csúcs, akkor az algoritmus véget

halmaz üres marad minden d ∈ V csúcsra 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

Gyors linkhibajavítás IP hálózatokban 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 Ha

j  i ∈T

u v u

'

-vel

(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 nézve, amelyek a V

u v u

u v u

fa i után következő csúcsai közül azokra

csúcshalmaznak is elemei, az u→v él kulcsél, tehát hozzá kell venni

minden ilyen célcsúcshoz tartozó K

d 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

Gyors linkhibajavítás IP hálózatokban tulajdonságaik (például robosztusságuk) megtartása mellett. Ez különösen igaz a FIFRL technikára, amely önmagában csupán egyszeres hibákat tud javítani – viszont lényegesen gyorsabban mint a kapcsolatállapot-alapú protokollok. A fentiekkel ellentétben célunk elsősorban nem egy komplett rendszer kifejlesztése, hanem egy egyszerű, gyorsan megvalósítható, önállóan is működőképes, egyszeres linkhibát javító FIFRL prototípus készítése volt. Mindenekelőtt az útválasztó technika átkapcsolási sebességét szerettük volna megmérni, illetve összehasonlítani a hagyományos IP hálózatok hibajavító képességével. Ennek megfelelően rendszerünket főként meglévő modulok összeépítésével fejlesztettük, annak tudatában, hogy az egyes programok közötti átkapcsolás (környezetváltás – context switching) jelentős időveszteséget okozhat, amely megnövelheti a hibajavítási időt. A későbbiek során erről még lesz szó. A fejlesztés első lépéseként a 3.3. fejezetben leírt FIFRL algoritmust kellett implementálnunk, hiszen a módszer a gyakorlatban még nem került megvalósításra. Programozási nyelvnek a C++-t választottuk, valamint felhasználtunk egy LEMON (Library of Efficient Models and Optimization in Networks) nevű C++ könyvtárt [18], amely gráfelméleti algoritmusok hatékony és egyszerű használatát teszi lehetővé. Az elsődleges és az interfész-specifikus útvonalakat Dijkstra algoritmusával számoltuk – ehhez természetesen ismerni kell a hálózati topológiát reprezentáló gráfot. Mivel a kapcsolatállapot-alapú protokollokkal szemben a FIFRL technikát használó útválasztók nem hajtanak végre topológia-felderítést, ezért a program számára készítenünk kellett egy konfigurációs fájlt, amely leírja a hálózatot (csomópontok, közöttük lévő kapcsolatok, élsúlyok). A program ez alapján meghatározza a csomagtovábbítási szabályokat és az interfészek IP címeit minden csomópont számára, majd szöveges fájlokba menti azokat, melyeket a későbbiek során különböző shell scriptek dolgoznak fel. A pontos működést a következő pontban tárgyaljuk részletesen.

29


4.3. A rendszer felépítése és működése A FIFRL rendszerünk felépítése és működése a 6. ábra alapján követhető nyomon. Három állapotot különböztethetünk meg: inicializálás, link-állapot figyelés, valamint hibakezelés. Az egészet egyetlen shell script vezérli, amely további scripteket és programokat indít el attól függően, hogy a rendszer éppen melyik állapotban van, illetve milyen esemény következett be. Inicializáláskor elsőként lefut a FIFRL algoritmus, amely az előző pontban leírtak alapján kiszámolja a csomagtovábbítási szabályokat és az IP címeket. A kimeneti fájlokat ezután egy awk nevű, szöveg alapú adatok feldolgozására készített program segítségével két script dolgozza fel: az init és a tables. Az init script egyetlen feladata az útválasztó interfészeinek beállítása a megfelelő IP címek alapján. Linuxban erre a célra az ifconfig parancs használható. Az init befejeződését követően a tables script fut le, amely az ip utasítás (ip route) segítségével feltölti a linux kernel útválasztó tábláit (routing tables) a csomagtovábbítási szabályokkal, mégpedig az alábbiaknak megfelelően: minden egyes interfész rendelkezik két saját útválasztó táblával. Az egyik nyilvántartja az összes csomóponthoz, mint célhoz vezető legrövidebb út következő állomását (forwarding table), feltéve hogy a csomag a szóban forgó interfészen érkezett, és a hálózatban nincs hiba. Amennyiben az adott interfész meghibásodik, akkor a hozzá tartozó másik táblában (backwarding table) tárolt csomagtovábbítási szabályok lesznek érvényesek az összes többi interfészen bejövő csomag számára. Szükség van továbbá olyan táblákra is, amelyek az adott csomópont által indított csomagok továbbítási szabályait tartják nyilván (local tables). Hibamentes hálózatot feltételezve nyilván elegendő egyetlen ilyen táblát fenntartani, azonban az egyes interfészek meghibásodásai eltérő módon befolyásolhatják a helyileg indított csomagok útvonalait. Ebből kifolyólag minden egyes interfészhez tartozik egy harmadik tábla is, amely az interfész meghibásodása estén az adott csomópontból induló csomagok továbbítási szabályait tartalmazzák. Látható, hogy amíg a hagyományos hibajavító algoritmusok csupán egyetlen útválasztó táblát használnak, addig a FIFR L technika a csomópontokhoz interfészenként további három útválasztó táblát rendel.

30


6. ábra: A FIFRL implementációs modellje

31

Gyors linkhibajavítás IP hálózatokban Annak érdekében, hogy a különböző interfészen érkező, illetőleg a csomópont által indított csomagokat meg lehessen különböztetni egymástól, jelzésekkel (packet mark) kell ellátni őket. Linuxban a csomagokat iptables utasításokkal lehet megjelölni. A különböző jelzések egy-egy útválasztó táblára „mutatnak”, ezeket össze kell rendelni egymással: úgynevezett szabályokat (ruleokat) kell létrehozni. Ehhez a már említett ip parancsot használhatjuk (ip rule). Így tehát amikor egy útválasztó csomagot kap, vagy csomagot indít, az arra helyezett jelzés alapján megkeresi a szabályok között, hogy a csomagtovábbítást melyik útválasztó táblában lévő bejegyzések alapján kell végezni. A későbbi működés során lényegében csak a csomagjelzéseket kell megváltoztatni, attól függően, hogy milyen esemény következett be (meghibásodott vagy helyreállt egy kapcsolat). Ezzel elérjük, hogy az egyes csomópontokon áthaladó csomagok más-más útválasztó táblák szabályai alapján kerüljenek továbbításra, hibamentes, illetve hibát tartalmazó hálózatban egyaránt. A csomópontok útválasztó tábláinak feltöltésén túl a tables script feladata a jelzés-útválasztó tábla összerendelések (szabályok) lérehozása, valamint az alapértelmezett, hibamentes hálózatban használt csomagjelzések felvétele is – feltételezzük, hogy a hálózatban induláskor nincs meghibásodás. Az inicializálás befejeződése után az útválasztók készen állnak feladatuk elvégzésére. A rendszert vezérlő script elindít egy rtnet nevű programot [23], amely a linux kernel netlink rétegének jelzésein keresztül a csomópont interfészeinek állapotát figyeli. A program kimenetét awk dolgozza fel: amennyiben változás következik be valamelyik interfészen, a változásnak megfelelően paraméterezve lefuttatja a link_state nevű scriptet. A link_state egy újabb awk segítségével a FIFRL program kimenetéből meghatározza, hogy az interfészen bekövetkezett változás alapján milyen csomagjelzéseket kell lecserélni, iptables utasításokon keresztül végrehajtja a szükséges módosításokat, végül visszaadja a vezérlést a rendszer működését irányító scriptnek. Látható, hogy az általunk fejlesztett FIFRL rendszer nem egyetlen program által vezérelt működést valósít meg, hanem különböző programok és scriptek együttműködésével végzi az útválasztási feladatokat. A moduláris felépítés hátránya az egyes elemek közötti átkapcsolás következtében fellépő időveszteség; előnye, hogy mivel az egyes modulok működés szempontjából

32

Gyors linkhibajavítás IP hálózatokban jól elkülöníthetők egymástól, bármelyik helyettesíthető hasonló funkciókat ellátó modullal. Így például az egyszeres linkhibát javító FIFRL algoritmus könnyedén kicserélhető egyszeres csomóponthibát javítani képes algoritmussal, csupán arra kell ügyelni, hogy a kimeneti fájlok felépítése megfeleljen a rendszer követelményeinek. Hasonlóképpen az rtnet helyett is használhatunk más programot, amely az interfészek állapotát monitorozza (például mii-tool).

4.4. A fejlesztés során tapasztalt problémák A FIFRL rendszer Linux környezetben való implementálása során felmerült néhány probléma, melyek egy része Linux-specifikus, másik része pedig a FIFRL algoritmus elméleti leírásának hiányosságaiból ered. A tesztrendszerünk működésének bemutatásakor említettük, hogy a csomópontoknak rendelkezniük kell egy olyan útválasztó táblával, amely az általuk indított csomagokra vonatkozó útválasztási szabályokat írja le. A FIR publikációkban [16],[17] leírt algoritmusok csak az interfészspecifikus útvonalak kiszámítását tárgyalják, feltételezik, hogy a csomópontok alapértelmezetten rendelkeznek a helyileg indított csomagok (legrövidebb úton történő) továbbítására vonatkozó információkkal. Mivel a FIFRL prototípusunkat úgy terveztük, hogy önállóan is működőképes legyen, ezért külön ki kellett számolni ezeket az útvonalakat is az interfész-specifikus csomagtovábbítási szabályok mellett. Ehhez kapcsolódóan egy másik probléma is felmerült a tesztek során: a Linux rendszermag (kernel) tartalmaz egy egyszerű, úgynevezett Reverse Packet Filtering hurok-elkerülő mechanizmust, melynek lényege, hogy amennyiben egy útválasztó visszakap egy általa indított csomagot, akkor azt eldobja. A FIR technikánál ilyen eset könnyen előfordulhat, hiszen egy meghibásodást észlelő útválasztó a csomagok továbbítását az előre kiszámolt alternatív útvonalon végzi, amely érintheti a csomagot küldő útválasztót – például egy gyűrű topológiában. Mivel a FIR rendszerben továbbításkor figyelembe kell venni az érkezési irányt is, az útválasztónak a csomagok eldobása helyett a bejövő interfészhez tartozó továbbítási szabályok szerint kellene eljárnia. A Reverse Packet Filtering a Linux kernel megfelelő helyen történő módosításával kikapcsolható, viszont ennek a következő fejezetben tárgyalt méréseink szempontjából nincs igazán jelentősége (a mérési topológiánk nem igényelte).

33

Gyors linkhibajavítás IP hálózatokban A FIR leírások nem térnek ki arra a kérdésre sem, hogy mit kell tenni, ha az algoritmus egy adott helyzetben nem talál érvényes útvonalat valamely célcsomópont felé. A FIFRL algoritmus fejlesztésekor ezeket az eseteket is kezelnünk kellett. Úgy döntöttünk, hogy ilyenkor eldobjuk a csomagot („fekete lyukba” irányítjuk). Az általunk megvalósított FIFRL algoritmus a publikációban leírthoz képest még egy pontban eltér: a hálózati topológiát reprezentáló gráfban az élek helyére felveszünk egy-egy virtuális csomópontot, amelyet az eredeti él két végpontjával összekötünk; az új élek súlya megegyezik az eredeti él súlyával. Az így kapott hálózatban az útvonalak számításakor az eredeti csomópontok helyett a virtuális csomópontok lesznek a célok („hálózatot” címzünk), de természetesen a kiszámított útvonalakon csak a valódi csomópontokat vesszük figyelembe a továbbítási szabályok felírásánál. Ezt a trükköt azért alkalmaztuk, hogy az útválasztó táblákba ne kelljen minden útválasztó minden IP címéhez bejegyzést készíteni. Az egy üzenetszórásos (broadcast) hálózatba tartozó interfészekhez elegendő egyetlen bejegyzést létrehozni, az alhálózati maszk (netmask) lehetővé teszi, hogy így is minden interfész címezhető legyen. Megjegyezzük, hogy az OSPF hasonló elven működik. A fejlesztés során az egyik legnagyobb gondot az interfész-állapot figyelés jelentette. Ahhoz, hogy a rendszer gyorsan tudjon reagálni egy-egy meghibásodásra, elengedhetetlenül fontos, hogy a hibában érintett útválasztók a lehető legrövidebb idő alatt érzékeljék a közöttük lévő kapcsolat megszakadását. A modernebb hálózati kártyák eszközvezérlője (driver) lehetővé teszi, hogy az adatkapcsolati réteg eseményvezérelten, az interfész állapotának megváltozásakor jelezzen a felsőbb rétegeknek. Sajnos a laboratóriumi gépekben lévő hálózati kártyák meghajtója nem eseményvezérelt működést valósít meg, hanem az interfészek folyamatos lekérdezésével (polling) ellenőrzi azok állapotát. Ez jóval nagyobb terhelést jelent a rendszer számára, mint a megszakításra (interrupt) épülő megoldás, ráadásul a lekérdezések között eltelt idő a mérések szempontjából nem volt megfelelő, az útválasztó lassan reagált a változásra. A probléma megoldásához módosítanunk kellett a kernelben a hálózati kártya meghajtójának forráskódját, csökkentettük a két lekérdezés között eltelt időt. Ennek hátránya – a megnövekedett terhelésen túl –, hogy a prototípusunk erősen függ a hálózati kártyától és annak eszközvezérlőjétől.

34

Gyors linkhibajavítás IP hálózatokban Az OSPF technikával végzett mérések során megállapítottuk, hogy az útválasztók rendelkeznek egy gyorsítótárral (route cache), amely az útválasztó táblák csomagtovábbítási szabályainak másolatát tartalmazza. Az itt tárolt bejegyzések gyorsabban érhetőek el, ezért az útválasztók a gyorsítótárat használják csomagtovábbításkor. Mivel az útválasztó táblákban tárolt szabályok módosulhatnak a hálózati topológiában történt változások miatt, a csomópontok periodikusan, néhány másodpercenként frissítik a gyorsítótárat. Ez nem elég gyors ahhoz, hogy a bejegyzések minden időpillanatban tükrözzék a hálózat aktuális állapotát, ennek következtében időveszteség léphet fel hibajavításnál. A probléma a FIFRL technikánál nem jön elő, hiszen az útválasztó táblák tartalma nem változik a működés során, így a gyorsítótár és az útválasztó táblák bejegyzései mindig szinkronban vannak egymással. Ezzel szemben az OSPF egyetlen útválasztó táblát tart karban, az abban tárolt csomagtovábbítási szabályok módosulhatnak a topológiában történt változások hatására. A mérések hitelessége érdekében kiiktattuk a gyorsítótárat a rendszerből. Végezetül (felsorolás szintjén) megemlítünk néhány kisebb problémát, amelyek a FIFRL prototípus fejlesztése, illetve tesztelése során merültek fel: ●

Ahhoz, hogy a számítógép útválasztóként működhessen, a Linux proc struktúrájában engedélyezni kell a csomagtovábbítást (ip_forward).

●

Az útválasztó táblák feltöltése előtt a csomópont interfészeinek IP címét be kell állítani, különben a bejegyzések nem jönnek létre.

●

Az útválasztó táblákba fel kell venni a csomópont közvetlen szomszédainak elérhetőségét is.

35


5. Mérési eredmények Az eddigiek során ismertettük a hagyományos IP hálózatokban használt hibajavító algoritmusokat, valamint áttekintést adtunk a különböző gyors IP hibajavító technikákról. Ezt követően bemutattuk az általunk implementált, egyszeres linkhibát javító FIFRL algoritmust, rávilágítottunk a megvalósítás során hozott tervezői döntésekre, valamint kitértünk a felmerült problémákra és azok megoldására. Ebben a fejezetben rátérünk munkánk legfontosabb célkitűzésére, a hagyományos (Hello protokollt használó) OSPF, az adatkapcsolati réteg jelzéseire épülő, gyors linkhiba-észleléssel beállított OSPF, valamint a FIFRL linkhibajavító algoritmus mérések segítségével történő összehasonlításának ismertetésére. Az alábbiakban először bemutatjuk a mérési környezetet, a mérések során használt hálózati topológiát, végül az elvégzett mérések eredményeit értékeljük.

5.1. A mérési környezet ismertetése A mérések során egy Linux alapú teszthálózatban linkhibát idéztünk elő, és megfigyeltük annak hatását az általunk generált forgalmakra. Megvizsgáltuk a hálózat áteresztőképességét, a csomagkésleltetéseket, valamint a csomagvesztést – az utóbbiból következtettünk a hibajavítás gyorsaságára. A mérésekhez az alábbi programokat használtuk fel: Distributed Benchmark System (DBS) [19] – elosztott forgalom-generáló és mérő program, verziószám: 1.1.5. A program a hálózat tetszőleges csomópontjai között jól paraméterezhető hálózati forgalmat állít elő; ez alapján a kiértékelő és grafikus megjelenítő modul segítségével a hálózat legfontosabb tulajdonságairól (áteresztőképesség, késleltetés, csomagvesztés, stb.) nyerhetünk információt. A DBS működése a következő: a hálózatban ki kell jelölni egy csomópontot, amely az egész mérést koordinálja (vezérlő). A csomópont a mérés kezdetekor a küldő és vevő útválasztónak elküldi a forgalomra vonatkozó beállításokat, mint például a csomagok száma és mérete, a mérés időtartama, használandó szállítási rétegbeli protokoll, stb. A mérési feladatok kiosztásához, valamint a mérés befejeződését követően az eredmények vezérlőhöz való elküldéséhez a mérés elején TCP kapcsolat létesül a vezérlő csomópont és a kliensek között. Ezt

36

Gyors linkhibajavítás IP hálózatokban követően megkezdődik a tényleges forgalom küldése a vezérlőtől kapott információk alapján. A mérés végén – miután minden csomag átvitelre került, vagy pedig lejárt a mérésre szánt idő – a vevő csomópont elküldi a vezérlőnek a mérési eredményeket: az általa vett csomagok küldési és vételi idejét, azonosítóját (sorszámát), valamint méretét. Az adatokat a vezérlő feldolgozza és rögzíti. Network Time Protocol (NTP) [20],[21] 4.2.2 verziójú implementációja (ntpd). A mérések elvégzéséhez szükség volt arra, hogy a hálózat csomópontjainak órái szinkronban legyenek egymással, hiszen ellenkező esetben a DBS által mért adatok nem a valós helyzetet tükrözték volna a csomagok küldési és vételi időpontjának elcsúszása miatt. Az NTP protokoll nanoszekundumos nagyságrendű pontossággal képes szinkronizálni az órákat [20]. Quagga Routing Suite [22], verziószám: 0.99.5. Korábbi elnevezése Zebra; a program egy standard OSPF implementáció Linux operációs rendszerekhez. Az előző fejezetben leírt, általunk fejlesztett FIFRL program és a hozzá tartozó scriptek.

5.2. A mérési paraméterek és a topológia megválasztása A méréseket a hagyományos OSPF, a gyors linkhiba-észleléssel beállított OSPF, valamint a FIFRL rendszeren egyaránt az 7. ábrán látható gráffal reprezentált hálózaton végeztük. Összesen 45 mérést hajtottunk végre: egyenként 15-öt mindhárom technikánál. A mérések során az útválasztó technikák mindegyikét úgy állítottuk be, hogy a lehető leggyorsabban képesek legyenek észlelni és kijavítani a hálózatban fellépő linkhibákat. A hagyományos OSPF a Hello protokollt használja a hibadetektáláshoz: az egyes útválasztók minden másodpercben küldenek egy-egy Hello üzenetet a szomszédaiknak. Amennyiben egy csomópont két másodpercen belül nem kap Hello csomagot valamelyik szomszédjától, akkor a kettejük közötti linket hibásnak tekinti. Megjegyezzük, hogy a jelenlegi Quagga verzióban ez a lehető leggyorsabb hibadetekciót biztosító beállítás, az időzítők másodperc alatti értékre nem állíthatók be.

37

Gyors linkhibajavítás IP hálózatokban A gyors linkhiba-észleléssel beállított OSPF a hálózati topológiában történt változásokról a Hello protokoll helyett az adatkapcsolati rétegének (jelen esetben Ethernet) jelzésein keresztül értesül, melyek alapján a hibákat azok bekövetkezésének pillanatában képes észlelni.

R2

1

T1

1

R1

2

1

2

1

R4

T3

T2 30

10

3

R3 7. ábra: A mérések során használt hálózati topológia az élsúlyok feltüntetésével A mérések során DBS-t használtunk forgalom generáláshoz és a mérések kiértékeléséhez, ezért elsőként szinkronizálnunk kellett a hálózat résztvevőinek óráit az NTP protokoll alapján. Időszervernek az R2 csomópontot választottuk, az ő órájához igazították a többiek a saját óráikat. Ezek után egy-egy mérés a következőképpen nézett ki: a hálózatban a küldő csomópont a T1, a vevő csomópont pedig a T3 volt. A csomagok útja Dijkstra legrövidebb út algoritmusa alapján: T1→R1→R2→R4→T3, amely a 7. ábrán jól nyomonkövethető. A forgalom elindulását követő (körülbelül) tizedik másodpercben megszakítottuk az R4→T3 linket, majd újabb tíz másodperc elteltével visszaállítottuk a „meghibásodott” összeköttetést. Az élsúlyokból jól látszik, hogy a megszakítás után a legrövidebb út a küldő és a vevő csomópont között: T1→R1→R3→T3. A két szélső csomópont UDP-t használt a csomagok küldéséhez; a 20000-es porton kommunikáltak egymással. A DBS-t úgy állítottuk be, hogy egy-egy mérés legfeljebb 30 másodpercig tartson. A csomagok mérete 500 byte volt, a T1 útválasztó másodpercenként 2000 csomagot küldött a T3 csomópontnak. Ezen adatokból könnyedén kiszámítható, hogy nagyjából

38

Gyors linkhibajavítás IP hálózatokban 8 Mbps adatátviteli sebességgel zajlott a kommunikáció a két útválasztó között.

5.3. A mérési eredmények A mérések kiértékelését követően első lépésként a hálózat áteresztőképességét (throughput) vizsgáltuk meg, amely a hálózaton időegység alatt átfolyó adatmennyiséget mutatja meg. Az 8. ábrán a FIFRL útválasztó technika áteresztőképesség-grafikonja látható a hálózat T1 és a T3 csomópontja között, egy mérés teljes hosszán (30 másodperc). A mérés első harmadában az adatátviteli sebesség az előzetes számításoknak megfelelően körülbelül 8 Mbps, kis ingadozással. A tizedik másodpercet elérve azonban rövid ideig tartó hirtelen visszaesés figyelhető meg a vevő oldalán. A jelenség azzal magyarázható, hogy ezen a szakaszon a T1 útválasztó által küldött csomagok nem jutottak el a T3 csomópontig, vagyis elvesztek. A tizedik másodperc viszont (nem véletlenül) éppen az az időpillanat, amikor megszakítottuk az R4 és a T3 csomópontok közötti kapcsolatot.

8. ábra: Áteresztőképesség (FIFRL), a piros vonal a küldött, a zöld a vett adatmennyiséget jelöli 39

Gyors linkhibajavítás IP hálózatokban A mérés második harmadának végén (huszadik másodperc) az R4→T3 link visszaállításának pillanata követhető nyomon. A környező szakaszokhoz képest itt valamivel nagyobb ingadozás figyelhető meg az adatátviteli sebességben. Ez sem véletlen, ugyanis a link helyreállása miatt az útválasztók visszatértek korábbi állapotukba, és a csomagokat az eredeti, meghibásodás előtti útvonalon továbbították. A hiba megszűnését kővetően visszaálláskor általában nincs csomagvesztés, hiszen a linkhiba esetével szemben minden időpillanatban létezik érvényes útvonal, a csomagok nem érintenek meghibásodott linket. Mivel azonban az átállás erőforrás- és időigényes művelet, a gyakorlatban előfordulhat, hogy közben néhány csomag nagyobb késleltetéssel kerül átvitelre – ez látható a 8. ábrán. Rosszabb esetben az is megtörténhet, hogy egy-egy csomag elveszik, amelyet tapasztaltunk is néhány mérés alkalmával. Egy link kiesése tehát az eredetileg rajta áthaladó csomagok elvesztésével jár; a csomagvesztés mértéke erősen függ attól, hogy az útválasztók milyen gyorsan képesek reagálni a hálózatban bekövetkező linkhibára. A 9. ábrán látható grafikon (szintén a FIFRL esetében) a küldött és vett, valamint a vesztett adatcsomagok sorszámát ábrázolja az idő függvényében, a mérés kilencedik és tizenegyedik másodperce közötti szakaszán. Megfigyelhető, hogy az R4→T3 link megszakításakor – a tizedik másodperc környékén – a T3 csomópont csak egy nagyon rövid ideig nem vett csomagot, a rendszer néhány ms alatt alkalmazkodott az új állapothoz. Ezzel szemben az OSPF rendszerekben az R4 és a T3 csomópontok közötti kapcsolat megszakításakor – várakozásainknak megfelelően – az átállási folyamat valamivel hosszabb ideig tartott, jelentősebb adatátviteli sebesség csökkenést tapasztaltunk. A link visszaállítására mindegyik rendszer nagyjából hasonlóan reagált.

40


9. ábra: Küldött (piros), vett (zöld) és vesztett (kék) adatcsomagok sorszáma (FIFRL)

A fentiekből arra következtethetünk, hogy a FIFRL rövidebb idő alatt alkalmazkodik az egyszeres linkhiba által okozott változáshoz, mint az OSPF.

5.4. A hibajavítási idők összehasonlítása A mérések során elsősorban arra voltunk kíváncsiak, hogy mennyi időt vesz igénybe az egyes útválasztó technikák alkalmazkodása a linkhiba miatt kialakult új hálózati topológiához. A DBS ezt közvetlenül nem tudja mérni, viszont az elveszett csomagok számát és időbélyegét igen, mely alapján következtetni lehet az átkonfigurálás következtében fellépő időveszteségre: a legelső és a legutolsó elvesztett csomag küldési időpontja közötti időkülönbség jó becslést ad a hibajavítási időre.

41

Gyors linkhibajavítás IP hálózatokban Az egyes rendszereken végrehajtott mérések hibajavítási idővel illetve csomagvesztéssel kapcsolatos legfontosabb eredményeit az alábbi táblázatokban foglaltuk össze. Külön oszlopban feltüntettük a link visszaállításakor fellépő időveszteséget is, ahol ez kimutatható volt. Látható, hogy a FIFRL rendszer átlagosan 89 ms alatt képes helyreállni az egyszeres linkhibát követően, míg a gyors linkhiba-detektálással beállított OSPF-nek körülbelül háromszor ennyi, a hagyományos OSPF-nek pedig nagyjából tizenhétszer ennyi időre van szüksége. A csomagszámra vonatkozó adatok a mérések teljes hosszán értendők.

Mérés sorszáma

Hibajavítási idő [ms]

Visszaállási idő [ms]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Minimum Maximum

103.986 87.990 85.991 84.032 86.989 87.032 90.032 86.946 87.991 93.754 87.990 87.989 86.030 91.094 89.031 84.032 103.986

0.000 0.000 0.042 1.000 0.043 0.044 0.000 0.000 1.043 0.000 0.000 0.000 0.000 0.000 1.998 0.000 1.998

Küldött csomagok Vesztett csomagok száma [db] száma [db] 60004 60002 60004 60003 60001 60004 60002 60002 60002 60000 60002 60002 60000 60002 60002 60000 60004

2. táblázat: A FIFRL rendszer mérési eredményei

42

209 177 173 170 175 176 182 174 177 189 177 177 174 184 180 170.000 209.000


Mérés sorszáma



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Minimum Maximum

255.998 254.972 255.037 254.001 254.000 255.999 253.000 262.999 258.003 255.001 257.000 255.001 258.001 256.997 261.998 253.000 262.999

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000


514 511 512 510 510 514 508 528 518 512 516 512 518 516 526 508.000 528.000

3. táblázat: A gyors linkhiba-detektálással beállított OSPF rendszer mérési eredményei Mérés sorszáma



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Minimum Maximum

1546.851 1416.856 1278.878 1685.833 1500.844 1783.823 1527.825 1521.825 1586.688 1813.751 2061.729 2244.770 1268.880 1369.864 2019.803 1268.880 2244.770

0.028 0.026 0.000 0.000 2.123 1.094 0.000 1.192 1.025 0.028 2.030 0.000 1.025 1.000 1.027 0.000 2.123


4. táblázat: Az OSPF rendszer mérési eredményei

43

3098 2837 2560 3375 3010 3573 3057 3048 3179 3630 4130 4491 2544 2744 4045 2544.000 4491.000

Gyors linkhibajavítás IP hálózatokban A csomagvesztésre vonatkozó adatok szemléltetéséhez tekintsük a 10. ábrát. Látható, hogy a FIFRL útválasztó technika a link megszakításakor alig veszít néhány csomagot, ugyanakkor az is megfigyelhető, hogy a link visszaállását követően is volt csomagvesztés, de ez elhanyagolhatóan rövid kiesést jelentett a hálózatban.

10. ábra: Csomagvesztés (FIFRL), a piros a küldött, a zöld a vett, a kék pedig a vesztett adatcsomagokat jelöli A mérések alapján az OSPF-fel kapcsolatban két megállapítás tehető. Egyrészt a gyors linkhiba-észleléssel beállított rendszer a hálózat hibáit sokkal gyorsabban képes észlelni és kijavítani, mint a hagyományos OSPF, köszönhetően annak, hogy a hibadetekció nem a Hello protokollon keresztül történik. A másik, hogy a hagyományos OSPF-nél az egyes hibajavítási idők között viszonylag nagy, akár egy másodperc is lehet az eltérés. Ennek oka a Hello protokoll működési mechanizmusában keresendő: mivel egy csomópont egy linket csak akkor tekint hibásnak, ha a link túloldalán lévő szomszédjától két másodpercen belül nem kap HELLO

44

Gyors linkhibajavítás IP hálózatokban csomagot, ezért egyáltalán nem mindegy, hogy a legutolsó HELLO üzenethez képes mennyivel később következik be a hiba. A két szélsőséges eset a 11. ábra alapján: a hiba közvetlenül az utoljára megkapott (0.) HELLO üzenet után, vagy pedig a soron következő (1.) HELLO üzenet megérkezése előtt következik be. Mivel bármely két HELLO üzenet között éppen egy másodperc a különbség, legfeljebb ekkora eltérés lehetséges a különböző hibajavítási idők között.

Rerouting

Link error

t [s] 0. HELLO

1. HELLO

2. HELLO

Dead Interval

11. ábra: Hibadetektálás a Hello protokollal (OSPF)

5.5. A csomagkésleltetések összehasonlítása A FIR technika tárgyalásánál említettük, hogy az interfész-alapú útvonaltovábbítás egyik hátránya a szükségesnél hosszabb úton történő javítás. Ennek az a következménye, hogy a hiba fennállásának ideje alatt a csomagkésleltetés igen megnőhet. Méréseink során valóban megfigyeltük ezt a jelenséget. Tekintsük a 12. ábrát, amely a mérési topológiát ábrázolja a meghibásodott link, és a legrövidebb javítóút feltüntetésével (vastag vonal). Korábban már megállapítottuk, hogy az élsúlyok alapján a legrövidebb út a két szélső csomópont között hibamentes esetben T1→R1→R2→R4→T3, míg az R4→T3 link meghibásodása esetén T1→R1→R3→T3. Látható, hogy a javítóút hossza egy csomóponttal rövidebb, ezért várhatóan a csomagkésleltetés is kisebb lesz a hiba fennállása alatt. Ahhoz azonban, hogy az útválasztók a csomagokat ezen az úton továbbítsák, a hálózat összes résztvevőjét értesíteni kell a meghibásodott linkről. Az OSPF-nél ez teljesül, hiszen globális információáramlás van, a csomópontok ismerik a mindenkori hálózati topológiát. Ezzel szemben a

45

Gyors linkhibajavítás IP hálózatokban FIFRL hálózatban csak az R4 illetve a T3 útválasztó tud a közöttük lévő kapcsolat megszakadásáról, a hiba tényét nem terjesztik a hálózatban; rajtuk kívül a többi csomópont továbbra is az eredeti útvonalon próbálja továbbítani a csomagokat. Az R4 útválasztóhoz érve a csomópont visszaküldi őket R2-nek, hiszen a hiba ismeretében számára a legrövidebb út rajta keresztül vezet. R2 a visszakapott csomagokat már másfelé továbbítja, figyelembe veszi azok érkezési irányát is (interfész-specifikus csomagtovábbítás). Ezek alapján a csomagok útja az R4→T3 link meghibásodását követően: T1→R1→R2→R4→R2→R1→R3→T3, amely valóban hosszabb mint a létező legrövidebb út a T1 és T3 csomópontok között.

R2

1

T1

1

R1

2

1

2

1

R4

/

T3

T2 30

10

3

R3

12. ábra: A mérési topológia a legrövidebb javítóúttal A fentieket méréseink alátámasztották: a mérés második harmadában (a hiba fennállása alatt) a csomagok nagyobb késleltetést szenvedtek, amely a 13. ábra grafikonján jól látható.

46


13. ábra: Csomagkésleltetés (FIFRL) A csomagkésleltetésre vonatkozó méréseket az 5. illetve a 6. táblázatokban foglaltuk össze. Mivel a javítóút hossza szempontjából nincs különbség a kétféle OSPF rendszer között, ezért csak a hagyományos OSPF, valamint a FIFRL útválasztó technikák mérési eredményeit tüntettük fel. Látható, hogy a csomagkésleltetés várható értéke a hiba előtti szakaszban nagyjából azonos mindegyik rendszernél (1 ms körüli érték), míg a hiba utáni szakaszban OSPF esetén valamivel kisebb, FIFRL esetén pedig közel kétszeresére növekszik.

47


H I B A

E L Ő T T

H I B A

U T Á N

Szórás [ms] Csomagszám Szórás [ms] Mérés Csomagszám Átlagos Átlagos sorszáma [darab] késleltetés [ms] [darab] késleltetés [ms] 7999 0.880 0.669 7999 2.349 0.968 1 2 8001 2.326 0.747 7999 3.781 1.339 3 8001 3.009 0.728 7999 4.147 0.940 4 8001 3.998 0.794 8001 5.090 1.309 5 8001 1.565 0.750 8001 3.043 1.317 6 7999 0.926 0.699 7999 2.345 1.252 7 8001 1.131 0.696 7999 2.231 1.209 8 8001 1.062 0.791 7999 2.493 1.245 9 7999 1.553 0.717 8001 2.669 1.275 10 7999 0.856 0.699 8001 1.960 1.239 11 7999 0.440 0.609 7999 1.855 0.903 12 7999 1.510 0.696 7999 2.943 1.226 13 7999 1.019 0.745 7999 2.215 1.271 14 7999 0.386 0.669 7999 1.671 1.461 15 7999 0.177 0.516 7999 1.272 1.361 Összesített 119997 1.389 0.702 119993 2.671 1.221

5. táblázat: A FIFRL csomagkésleltetései, szórása

H I B A

E L Ő T T

H I B A

U T Á N

Szórás [ms] Csomagszám Szórás [ms] Mérés Csomagszám Átlagos Átlagos sorszáma [darab] késleltetés [ms] [darab] késleltetés [ms] 1 8001 1.206 0.821 8001 0.933 0.529 2 7999 1.346 0.739 7999 0.697 0.541 3 7999 1.158 0.659 7999 0.630 0.552 4 8001 0.786 0.749 7999 0.231 0.613 5 8001 1.119 0.704 8000 0.765 0.529 6 8001 0.773 0.685 7999 0.484 0.530 7 8001 0.909 0.729 7999 0.623 0.528 8 7999 1.055 0.716 7999 0.695 0.581 9 7999 1.154 0.665 7999 0.825 0.494 10 8001 1.005 0.753 8001 0.825 0.514 11 7999 0.931 0.723 7999 0.881 0.525 12 8001 1.092 0.643 8000 0.923 0.490 13 8001 1.418 0.715 8000 0.994 0.533 14 8001 1.321 0.640 8001 1.061 0.534 15 8001 1.261 0.711 8001 1.074 0.482 Összesített 120005 1.102 0.710 119996 0.776 0.532

6. táblázat: Az OSPF csomagkésleltetései, szórása

48

Gyors linkhibajavítás IP hálózatokban A nagy számú mérés (több ezer csomag) miatt a csomagkésleltetésre kapott várható érték meglehetősen pontos, de méréseink megbízhatóságának ellenőrzéseképpen kiszámítottuk a szórást is. Láthatóan az átlaghoz képest nem túl magas, ami növeli az eredmények hihetőségét. A csomagszám ezúttal nem a mérés teljes hosszán, hanem a hibát megelőző, illetőleg a hiba fennállása alatti (körülbelül) négy-négy másodperces szakaszon értendő.

5.6. A mérések tanulságai Ebben a fejezetben az általunk megvalósított, egyszeres linkhibát javítani képes FIFRL rendszeren, valamint a hagyományos IP hálózatokban használt OSPF két változatán elvégzett mérések eredményeit ismertettük. Célunk elsősorban a hibajavító képességek összehasonlítása volt. Az eredmények hitelessége érdekében igyekeztünk egyenlő feltételeket biztosítani a különböző technikák számára. Ennek megfelelően a méréseket minden esetben ugyanazon a hálózaton végeztük el, valamint mindhárom módszert úgy állítottuk be, hogy képességeikhez mérten a lehető leggyorsabban alkalmazkodjanak a mesterségesen létrehozott linkhiba következtében kialakult új topológiához. A mérési eredményeink alapján (várakozásainknak megfelelően) a FIFRL bizonyult a leggyorsabbnak hibajavítás szempontjából: az előre meghatározott és beállított javító útvonalaknak köszönhetően a hiba bekövetkezésétől számított 90 ms-on belül alkalmazkodott a változáshoz, mintegy háromszor gyorsabban, mint az adatkapcsolati réteg jelzésein alapuló OSPF rendszer. A három módszer közül a Hello protokollt használó OSPF reagált leglassabban a hibára, azonban fontos megjegyezni, hogy ez a technika nem függ az adatkapcsolati réteg által nyújtott szolgáltatásoktól. Az előző két technikával szemben akkor is működik, ha az alsóbb réteg nem képes észlelni az interfészek állapotában bekövetkező változásokat (például vezetéknélküli közeg esetén). A mérések alátámasztották azon állításunkat is, mely szerint a FIR technika (sajnos) hosszabb úton javít, mint az OSPF, emiatt a hiba fennállása alatt a csomagkésleltetés megnőhet. Teszthálózatunk méretéből adódóan ez elhanyagolható, viszont nagyobb hálózatokban jelentős lehet, amely a valós idejű (multimédiás) szolgáltatások minőségét érzékenyen érintheti.

49


6. Az elvégzett munka értékelése Dolgozatunkban bemutattuk a hagyományos IP hálózatokban használt útválasztó technikák működési elvét, rávilágítottunk azokra a problémákra, amelyek a hibajavítás lassúságáért felelősek. Ismertettünk néhány algoritmust, amelyek a valós idejű alkalmazások igényeit is kielégítő hibajavítást képesek megvalósítani. Ezek közül a FIFRL technikát a gyakorlatban implementáltuk, valamint valós hálózaton elvégzett mérések segítségével összehasonlítottuk a hibajavító képességét az OSPF kétféle változatával. Megállapítottuk, hogy a gyors IP hibajavító algoritmusok valóban sokkal eredményesebbek a hagyományos megoldásoknál, ugyanakkor arra is rámutattunk, hogy a csomagkésleltetés a hiba fennállásának ideje alatt megnőhet, ami a multimédiás forgalom minősége szempontjából nem előnyös. A gyors IP hibajavító algoritmusok további hátránya, hogy a hagyományos módszerekkel szemben nem robosztusak. Egyrészt némelyik technikánál – így a FIR-nél is – a többszörös hibák problémát okozhatnak, hurok kialakulásához vezethetnek, másrészt az adatkapcsolati réteg interfész-állapotra vonatkozó jelzései nélkül működésképtelenek. Ezen okok miatt a gyors IP hibajavító technikák nem helyettesíthetik a jelenlegi módszereket, velük együttműködve viszont nagyságrendekkel gyorsabb hibajavítás valósítható meg. Mérési eredményeink alapján elmondhatjuk, hogy az általunk implementált FIFRL technika hibajavítás szempontjából gyorsabb ugyan, mint az OSPF, de a kívánalmaktól (50 ms) még elmarad. Ennek oka (véleményünk szerint) egyrészt a laboratóriumi gépek lassúsága, másrészt a rendszer moduláris felépítése – az operációs rendszer környezetváltásai nagymértékben befolyásolhatják a hibajavítás sebességét. Ebből kifolyólag még sok optimalizálási lehetőség van nyitva, melyeket későbbi munkánk során szeretnénk körüljárni. A közeljövőben szeretnénk nagyobb teljesítményű gépeken méréseket végezni, és az egyszeres csomóponthibát javítani képes FIFRN algoritmust is kipróbálni. A távolabbi jövőben szeretnénk rendszerünk modularitását csökkenteni, valamint az OSPF technikával való együttműködést megvalósítani.

50


Irodalomjegyzék [1] M. Shand and S. Bryant, „IP Fast Reroute Framework”, IETF Network Working Group, Internet Draft, June 2007 [2] CISCO Routing Basics: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/routing.htm [3] Tim

Szigeti,

Christina

Hattingh:

„Quality

of

Service

Design

Overview”,

http://www.informit.com/articles/article.aspx?p=357102&rl=1 [4] Wikipedia: Routing Protocol, http://en.wikipedia.org/wiki/Routing_protocol [5] Atul Khanna John Zinky: „The Revised ARPANET Routing Metric”, http://pdos.csail.mit.edu/decouto/papers/khanna89.pdf [6] Y. Rekhter: „A Border Gateway Protocol 4”, http://www.ietf.org/rfc/rfc1771.txt [7] Wikipedia: „Interior Gateway Protocol”, http://en.wikipedia.org/wiki/Interior_gateway_protocol [8] J. Moy: „RFC 2328 - OSPF Version 2”, http://www.faqs.org/rfcs/rfc2328.html [9] Minas Gjoka, Vinayak Ram and Xiaowei Yang, „Evaluation of ip fast reroute proposals”, IEEE Communication Systems Software and Middleware, 2007. COMSWARE 2007. 2nd International Conference, 7-12. January 2007 [10] A. Atlas and A. Zinin, „Basic Specification for IP Fast-Reroute: Loop-free Alternates”, IETF Network Working Group, Internet Draft, September 2007 [11] Stefano Previdi, „IP Fast ReRoute technologies”, Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), 2. March 2006 [12] Janos Farkas, Csaba Antal and Lars Westberg, „Fast Failure Handling in Ethernet Networks”, IEEE International Conference on Communications, 11-15 June 2006

51

Gyors linkhibajavítás IP hálózatokban [13] S. Bryant, C. Filsfils, S. Previdi and M. Shand, „IP Fast-reroute Using Tunnels”, IETF Network Working Group, Internet Draft, April 2005 [14] S. Bryant, M. Shand and S. Previdi, „IP Fast Reroute Using Not-via Addresses”, IETF Network Working Group, Internet Draft, July 2007

[15] Amund Kvalbein, Audun Fosselie Hansen, Tarik Cicic, Stein Gjessing and Olav Lysne, „Fast IP Recovery using Multiple Routing Configurations”, IEEE INFOCOM 2006 [16] Srihari Nelakuditi, Sanghwan Lee, Yinzhe Yu, Zhi-Li Zhang and Chen-Nee Chuah, „Fast Local Rerouting for Handling Transient Link Failures”, Tech. Rep. TR-2004-004, University of South Carolina, 2004 [17] Zifei Zhong, Srihari Nelakuditi, Yinzhe Yu, Sanghwan Lee, Junling Wang and Chen-Nee Chuah, „Failure Inferencing based Fast Rerouting for Handling Transient Link and Node Failures”, IEEE INFOCOM 2005 [18] Library of Efficient Models and Optimization in Networks (LEMON), Home Page: https://lemon.cs.elte.hu/ [19] Distributed Benchmark System (DBS), Home Page: http://www.ai3.net/products/dbs/ [20] David L. Mills, „Network Time Protocol (Version 3) Specification, Implementation and Analysis”, IETF Network Working Group, RFC1305, March 1992 [21] Network Time Protocol (NTP), Home Page: http://www.ntp.org/ [22] Quagga Routing Suite, Home Page: http://www.quagga.net/ [23] RTnet, Home Page: http://www.rtnet.org

52

Gyors linkhibajavítás IP hálózatokban

Recommend Documents