Útvonal-kijelölés, útvonalválasztás, routing

Az előadások a következő témára: "Útvonal-kijelölés, útvonalválasztás, routing"— Előadás másolata:

1 Útvonal-kijelölés, útvonalválasztás, routing
Médiakommunikációs hálózatok Média-technológia és –kommunikáció szakirány 2013. tavasz

2 Útvonalválasztás ↔ útvonal-kijelölés
Routing Útvonalválasztás ↔ útvonal-kijelölés Működjön a hálózat összeköttetés alapú, vagy összeköttetés-mentes módon, nyugodtan elcsodálkozhatunk azon a képességén, hogy egy globálisan egyedi azonosító alapján képes megtalálni a kívánt partnert. Persze joggal kérdezhetjük azt is, hogy mi ebben a csoda, hiszen rendkívül összetett feladatok végzésére alkalmas automatákat ismerünk, tehát nyilván ezt az útvonal-keresési, -kijelölési, -választási feladatot is el lehet végezni. Csakhogy van egy kis gond ezzel az automatával, nevezetesen nem állandó a „felépítése”. Jó, hát akkor adaptív módon kell viselkednie. Igen ám, de rendkívül nagy a mérete, értve ezt a benne terjedő információ időtartamához viszonyítva, és ezért szinte sohasem lehet pontos, aktuális információval rendelkezni a hálózat állapotáról. Az tehát a csoda, hogy ennek ellenére lehetséges a feladat viszonylag jó, kielégítő elvégzése. (persze nem muszáj ezzel az elmélkedéssel kezdeni, de az előadás során valahol célszerű rámutatni erre) Kezdhetünk szárazabban, mert azt is nagyon fontos hangsúlyozni, hogy miért egységes a routing feladat az összeköttetés-alapú és –mentes hálózatokban. Erre vonatkozóan van egy rövid elmélkedés a következő szlájdhoz. Az útvonal-kijelölést használtam az összeköttetés-alapú hálózatokban felmerülő feladatra, és a választást a másik esetre.

3 Bevezetés: a feladat értelmezése
Bb ? C A ? D B ? Da Ba↔Db Db Ba G E Az ábrához: a Ba állomás, végpont (a B csomóponthoz kapcsolódó a nevű) kommunikálni akar a Db-vel. A csomópontoknak sorban útvonalat kell választaniuk, vagy kialakítaniuk. A címhez: I. Megismerni, nyilvántartani a hálózat felépítését, beleértve a csomópontokat, az összekötéseket (link), a lehetséges útvonalakat. II. A hálózati csomópontok számára biztosítani mindazt az ismeretet, ami ahhoz szükséges, hogy egy – a csomópontnál megjelenő – kommunikációs igény kiszolgálására alkalmas útvonalat ki lehessen jelölni. Lényeges megkülönböztetni a feladat elvégzésére alkalmas algoritmusokat, módszereket, és az ilyen módszerek megvalósítására kialakított protokollokat. Itt most a módszerekkel foglalkozunk, a protokolloknak csak a nevét említjük meg. Kissé eltér az összeköttetés-alapú és az összeköttetés mentes eset. Az előbbinél a fellépő igény hatására létre kell hozni a valóságos (áramkörkapcsolt eset), vagy a virtuális (csomagkapcsolt eset) csatorná(ka)t a végpontok között. A végpontok azonosítására globálisan (a hálózat egészét tekintve) egyedi azonosítók szolgálnak. A kívánságot bejelentő saját azonosítóján kívül megadja a partner vagy partnerek azonosítóját, azonosítóit. Ezek az adatok képezik a kiindulást az útvonal kialakításához az összeköttetés-alapú esetben. Az egyes csomópontokban felhalmozott ismeretek alapján lépésről lépésre megindul az útvonal kiválasztása, és a kívánt partnerhez érve befejeződik. Az útvonal feljegyzésre kerül az érintett csomópontokban (ezeket kapcsolónak hívjuk), majd értesítés megy a kommunikáló végekhez, hogy elkészült az útvonal, megkezdhető a kommunikáció. Ezzel szemben az összeköttetés-mentes esetben nem kell kérni útvonal-kialakítást, hanem rögtön küldhetünk egy adagnyi üzenetet, és a csomópontok a megfelelő útvonalat a csomag továbbításával egyidejűleg megválasztják és azon a csomagot továbbítják. Mindkét esetben jelen van az útválasztás, az egyik esetben a választott út rögzítése, a másik esetben annak ismételt elvégzése, és a csomag továbbítása. Láthatóan a feladat két jól elkülönülő részre bontható: (i) útválasztás; (ii) információ-továbbítás De honnan származik az információ, amelyet a csomópontok felhasználnak az út kialakítására? H F Ea

4 Összeköttetés-alapú /-mentes
Ba Db G F B H A E C D Ea Bb Da vonalkapcsolt csomagkapcsolt Először kiemeljük a vonalkapcsolt esetben a tényleges csatornát, amit azzal jelzünk, hogy a zöld vonal átmegy a csomópontokon. Azután az összeköttetés-alapú csomagkapcsolt esetben jelezzük a kialakított virtuális csatornát, amely a csomópontokban végrehajtott feljegyzések révén jön létre, amit azokkal a nyilakkal jelzünk, amelyek mutatják, hogy honnan-hová kell rakni a csomagokat. Az összeköttetés-mentes esetre pedig jelezzük, hogy semmi maradandó nem jön létre a hálózatban, mindig mindent újra kell csinálni. És most térjünk vissza az előbb feltett kérdéshez: De honnan származik az információ, amelyet a csomópontok felhasználnak az út kialakítására?

5 Útvonaltáblák Útvonal-kijelölés ill. útv.választás:
csomópontok táblázatai alapján Táblázatok kitöltése: manuálisan automatikusan: centralizáltan elosztottan célpont következő lépés … Ba Db G F B H A E C D Ea Bb Da RK Lényegében senki nem talált ki eddig jobb ötletet, mint útvonal-táblák alapján végezni a hívás-felépítést vagy a csomag-továbbítást. Az viszont már szerteágazó, hogy miként történjék azok kitöltése. A manuális kitöltés egy kisméretű hálózatban célszerű módszer. Valójában a manuális kitöltés minden esetben részét képezi valamely módszernek, mert például egy személyi számítógép üzembeállításakor meg kell neki adni bizonyos, a hálózattal kapcsolatos adatokat az induláshoz, és ez manuális kitöltését jelenti egy host útvonal-táblájának. Az automatikus nyilván egy program által történik. Azonban ez nem egy triviális feladat, és a következőkben ezeket az ismereteket tárgyaljuk. Először a centralizált kontra elosztott esetet vizsgáljuk. A centralizált esetben egy ponton összegyűjtjük a hálózatról megszerezhető valamennyi ismeretet, majd ennek birtokában meghatározzuk az egyes csomópontok útvonal-tábláinak a szükséges bejegyzéseit, és továbbítjuk azokat a csomópontokhoz. Az elosztott esetben valamennyi csomópont egyénileg gyűjt információt a hálózatról, és készíti el saját útvonal-tábláját. Ha röviden értékelni akarjuk a centralizált és az elosztott módszert, akkor a következőket állapíthatjuk meg: Centralizált esetben nyilván egyetlen kép alakul ki a hálózatról, tehát valamennyi ebből származtatott útvonal-tábla „konzisztens” lesz. (Úgy is mondhatjuk, hogy egybehangzó.) Persze azt sose felejtsük el, hogy egy nagyméretű hálózat aktuális állapotát képviselő információ megszerzése, majd az ebből származtatott útvonal-táblák terítése időt igényel, és bizony ezalatt megváltozhat a hálózat állapota. Ezért igaz ugyan, hogy fennáll a konzisztencia, de persze nem a valós helyzetre vonatkoznak a táblázatok. (Elkeseredni azért nem kell, mert a tapasztalat szerint az így keletkező hibákkal együtt lehet élni.) Szétosztott esetben a probléma már ott jelentkezik, hogy mennyire képesek a csomópontok egységes képet kialakítani a hálózatról. Mindegyik csomópont gyűjti az információt a saját nézőpontjából, és határozza meg az útvonal-táblát saját magának. Az persze megint igaz, hogy az információgyűjtés időt igényel, az egyes csomópontok nem egyszerre végzik el (valójában nem is értelmezhető az „egyszerre”), és nem garantálható a konzisztens kép a hálózatról. (kivéve a teljesen statikus hálózat esetét, ami nyilván egy fikció) Az „egybehangzó” kép kialakulásának azért a hálózat dinamikus változásain kívül többé-kevésbé akadályát jelenti az alapvetően eltérő „nézőpontok” léte is. Vagy pontosabban külön odafigyelést igényel. A centralizált eset igen nagy hátránya a sérülékenysége. Amennyiben meghibásodik a központ, akkor leáll az útvonal-táblák frissítése. Nyilván megfelelő tartalékolás segít ezen, de azon nem segít semmi, hogy a hálózat állapotát meghatározó információszerzésnek, és az útvonal-táblák szétosztásának a forgalma egy helyre koncentrálódik. Az illusztrációnál a korábbi hálózatot ismételtem meg, és a centralizálthoz betettem egy RK (routing központ) elemet, amelyhez oda-vissza nyilak mutatják az információáramlást. Az elosztottra megjelenő nyilak az A csomópont, majd a G csomópont „gyűjtésére” utalnak, és egy stb jelzi, hogy ezt mindegyiknek meg kell csinálni. Egyébként még egyszer hangsúlyoznám, hogy a routing az nem call proccessing (hívás-felépítés), vagy nem packet forwarding (csomag-továbbítás), hanem mindaz a tevékenység, amelynek eredményeként létrejönnek az útvonal-táblák. stb

6 Az útvonal-adatbázis kialakítása
Két alapvetően eltérő koncepció: A tapasztalatok alapján előre becsült forgalmi viszonyoknak megfelelő útvonal-táblák centralizált kialakítása és szétosztása Az aktuális forgalmi helyzet állandó figyelése, az annak legjobban megfelelő útvonaltáblák kialakítása Az előbbi a telefonhálózatokra alkalmazható Az utóbbi az adathálózatokban követendő Az Internet esetén elosztott változatban A hálózatban használható, vagy még inkább az adott végpontok „összekötésére” legalkalmasabb (hogy mi a legalkalmasabb, azt mindjárt megvizsgáljuk) útvonalak kialakításához szükséges, vagy használható információ valójában elég sokrétű, és sokféle lehet. Jelenleg például még alapvetően eltér egymástól a telefonhálózatokban alkalmazott módszer a számítógép-hálózatokban alkalmazottól. A telefonhálózatokban a várható forgalom jó előre-jelezhetősége, valamint centralizált menedzselése alapot teremt arra, hogy akár centralizáltan, viszonylag rövid időszakokra (néhány óra) előre tervezetten készítsük el a csomópontokban, az útvonal-kialakításhoz felhasználandó ismereteket. Ezzel szemben a számítógép-hálózatokban messze nem jósolható olyan jól a forgalom várható alakulása, valamint a legérdekesebbnek tekinthető esetben, az Internetben nincs meg az egységes felügyelet. Így itt sokkal inkább az éppen aktuális állapot alapján célszerű az adatbázist létrehozni, és a lehető legdinamikusabban megújítani. Nézzük ezután, hogy mire is gondolunk a már sokszor emlegetett „hálózat állapotát leíró információ” alatt!

7 A gyűjthető információ
Csomópontok összekötése: pl.: B-A, B-C, B-E, B-G nem működik: pl.: B-E B->Ba,->Bb Linkek jellemzői: B-A: 2 Mbit/s B-C: 10 Mbit/s B-E: 2 Mbit/ s Forgalom (sor): B-A: 2 B-C: 0 Ba Db G F B H A E C D Ea Bb Da A hálózatot a fellépő információtovábbítási igények kiszolgálási képessége szempontjából a következő jellemzők, adatok írják le: Mely csomópontok mely csomópontokkal vannak összekötve (link) Itt meg lehet különböztetni két alapvető állapotot: (i) működőképes a link, vagy (ii) működésképtelen De jellemezni lehet az összekötés állapotát finomabban is: (i) mekkora a terhelése (hány % a rajta lévő forgalom az átviteli képességének), (ii) mekkora az átviteli képessége, (iii) mekkora a késleltetése (értve alatta a linken kiszolgálásra várakozók mennyiségét, pontosabban kifejezve azt a sorbanállási késleltetéssel), (iv) mekkora a link kiszolgálási díja (mennyibe kerül rajta a bitenkénti információátvitel) Ha a hálózat valamennyi csomópontjáról rendelkezésre áll a felsorolt információ, akkor ebből meghatározható, hogy bármely két felhasználót milyen útvonalon célszerű összekötni. Amennyiben a célszerűség alatt a legrövidebb útra gondolunk, akkor elegendő a minimálisan létező és működőképes összekötések ismerete. Ha pedig meg tudjuk állapítani a célszerű utakat, akkor azokból kiolvashatjuk az egyes csomópontok által kialakítandó útvonal darabot, és meghatározhatjuk az útvonal-táblákat, amelyek bejegyzései lényegében útvonal darabokat képviselnek. A csomópontok összekötése harmadik sorában szereplő B->Ba,->Bb azt akarja szimbolizálni, hogy a B csomópont kiszolgálja a két végződést (vagy LAN-t)

8 A megoldások csoportosítása
Centralizált ↔ Szétosztott Tényleges forgalomtól függő ↔ Forgalomfüggetlen Egyutas ↔ Többutas A több út csak tartalék vagy terhelés-elosztásra is képes? (Lépésenkénti ↔ Forrás általi) Viszonylag egyszerűen elvégezhető a feladat, ha állandó elrendezésű hálózatot tételezünk fel. Egyszer kell csak lerögzíteni az útvonalak kialakításához szükséges ismereteket, ezeket olyan formában tárolni a csomópontokban, hogy a felmerülő kívánságokat minél kevesebb munkával teljesíteni lehessen. Statikus routing-nak szokták ezt nevezni, és számítógép-hálózatok perifériáján, a lokális hálózatokban gyakorlatilag máig ez a helyzet, azaz a hálózat felügyelője manuálisan elhelyezi az információt az eszközökben. A centralizált – elosztott csoporthoz példaként a telefonhálózat és az Internet említhető. Mik az alapvető okok? A telefonhálózatok központi felügyelettel (egységes adminisztrációval) irányítottak, így kézenfekvő, és lehetséges a centralizált routing, mint elvi kiindulás. A forgalom rendkívül jól jósolható. Amennyiben eltekintünk – az egyébként úgyis kezelhetetlen – katasztrófáktól (háború, földrengés, szökőár, karácsony, szilveszter), akkor nagy pontossággal meg lehet mondani, hogy melyik, nap melyik órájában, hol és mekkora forgalom lesz. A hálózati csomópontok útvonaltábláit erre lehet felkészíteni. Végül még egy elemet említünk, nevezetesen az igények egyöntetűségét, azaz mindenki beszélgetni akar, és ehhez kér egy rögzített csatornát, jól ismert eloszlással leírható ideig. Ezzel alapvetően szemben áll az Internet, mint a telefonhálózattal összemérhető terjedelmű, és jelentőségű adat(?)hálózat. (A kérdőjel arra akar utalni, hogy ma már nem jelentéktelen a valódi idejű, ún távközlési, sőt műsorszórási igénybevétel sem.) Az eltérés leglényegesebb, a routing szempontjából fontos, elemei: (i) nincs egységes adminisztráció: a hálózat működtetése jószándékú, saját érdekeiket megértő emberek, szervezetek által történik, (ii) a forgalom jósolhatósága rossz: nem lehet előre kellő pontossággal megmondani, hogy mikor, mely útvonalakon mekkora forgalom következik be, (iii) az igények nem egységesek, hanem rendkívül sokrétűek: nem csak azt nem lehet tudni, hogy mikor, milyen útvonalakon fog folyni a forgalom, de azt még kevésbé, hogy milyen lesz az a forgalom, azaz mik lesznek az elvárásai, és ezzel áttérhetünk a második pontra. A forgalom-függőség esetén vigyázni kell, hogy ne legyen félreértés: itt az aktuális, a tényleges forgalmi helyzetről van szó. Így például a telefonhálózat routingja napjainkban még jellegzetesen forgalom-független, mert a jósolt forgalom alapján irányít, míg az Internet alapvetően törekszik a tényleges forgalom alapján adaptívan dolgozni, a telefon ebből a szempontból nem alkalmazkodik. Az utak száma egy igen izgalmas kérdés. Az egyszerűbb változatban csak arról van szó, hogy az útvonal-táblában egy adott célhoz tartozó bejegyzés csak egy utat tartson nyilván, vagy „tartalékként” tegyen el további uta(ka)t is. Ebben az esetben valójában a router mindig az „első” útra irányít, de amennyiben az meghibásodik, akkor „semmi idő alatt” előveszi a következőt, és így nincs fennakadás egy pillanatig sem. Az érdekesebb esetben valójában tényleg több út használható párhuzamosan, amelynek célja a terhelés oly módon történő megosztása, hogy ne legyenek túlterhelt utak, miközben azonos, vagy kicsit hosszabb utak üresek. A negyedik pontról nekem elég határozottan az a véleményem, hogy szinte csak zavarkeltésből szokták a többiek mellé felsorolni. Ugyanis úgy vélem, hogy a routing módszerek arra irányulnak, hogy útvonal-táblákat hozzanak létre, amelyek megmondják a következő lépést. Ezzel szemben az összeköttetés-mentes hálózatok routereit érdemes úgy kialakítani, hogy a csomagtovábbítás során felülírható legyen a saját lokális döntésük a követendő útvonalról, és így megadhassa a feladó, hogy mely útvonalon szeretné továbbíttatni a csomagját. De ez nem routing, hanem egy lehetőség különböző tesztekre, vizsgálatokra, nyomkövető szoftverek írására, futtatására.

9 A módszerrel szembeni követelmények
Minél kisebb méretű útvonaltáblát adjon: Kisebb tár, olcsóbb csomópont Gyorsabban működő csomópont Kisebb routingforgalom A routingforgalom minimalizálása Robosztusság: Hibás tábla esélyének minimalizálása Pl. fekete lyuk, hurok, oszcilláció, tévedés/hamisítás Optimális útvonalak kijelölése: az út optimalitása az igénytől függő Többféle módszert találtak ki a routingra. Ezeknek a módszereknek az alapvető jellemzői: Hogyan és mit gyűjtenek, majd miként készítenek útvonal-táblákat a gyűjteményükből? Persze fontos megismerni a módszereket, de azt is lényeges tisztázni, hogy: Milyen szempontok alapján értékelhetjük a fenti tevékenységekre vonatkozó módszereket? A slide-on felsoroltuk az alapvető követelményeket, tehát a kiértékelés annak alapján történhet, hogy mennyire teljesíti a módszer azokat. Sajnos ezek sokszor ellentmondóak, abban az értelemben, hogy amennyiben valamelyiket jól teljesítjük, akkor az a másik rovására megy. Az útonaltáblák minimális méretére való törekvés jól érthető: (i) kevesebb tároló hely kell, (ii) gyorsabban lehet keresni a kisebb táblában, ami fontos, mert a csomagtovábbítás során gyorsan kell működni egy összeköttetés-mentes hálózatban, de az sem mindegy, hogy mennyi ideig tart a hívásfelépítés, (iii) a táblák mérete és a routing forgalom között közvetlen az összefüggés (pl centralizált esetben letöltésre kerülnek). Általában követelménynek tekinthető, hogy a táblák mérete lassabban nőjön, mint a kiszolgált felhasználók száma. A robosztusság is triviális követelmény, mert a hibás tábla rossz útvonalat eredményez, ami megakadályozza a csomag célbajuttatását, vagy az összeköttetés felépítését, miközben semmi akadálya nem lenne azoknak (nincs torlódás, foglaltság). A következő jelenségeket írhatjuk a hibás útvonaltáblák rovására: „fekete lyuk” létrejötte, azaz valamely célba sosem jut el csomag / nem épül ki összeköttetés valamely tábla hibás bejegyzése miatt Hurok kialakulása, azaz két vagy több csomópont egymást tekinti következő lépésnek Oszcilláció létrejötte, amikor a terheléstől függően dinamikusan változtatjuk a táblákat, akkor előállhat (rossz módszernél) az az eset, hogy egy túlterhelt útról átterelődik a forgalom egy alulhasznált útra, majd így ez lesz túlterhelt, és oda vissza leng az egész A robosztussághoz tartozik még a tévedésen, vagy a rosszakaratúan történő hamis útvonal-tábla kezelés. Az optimális útvonal kérdése – mint az optimalitásé általában - elég összetett. A triviális megoldás nyilván a legrövidebb út, de mint jól tudjuk János bácsi tud a légvonalbelinél rövidebbet is. Persze már az út hosszának mérése is felvet problémákat. A hálózatok esetén a legegyszerűbb, de jó megoldás az útvonalba eső csomópontok számával mérni a távolságot, mert itt lassul le a haladás, amennyiben földfelszíni a kommunikációs csatorna. Viszont egy szinkron-műholdas csatorna esetén már számottevő a terjedési késleltetés is. Persze vannak esetek, amikor nem a legrövidebb úthoz ragaszkodunk, még csak nem is leggyorsabban járhatóhoz, hanem például a legmegbízhatóbbhoz (hibaarányban értve), vagy a legolcsóbbhoz (pénzben kifejezve), vagy a leglátványosabbhoz, amikor valamilyen szép tájat akarunk bejárni.

10 Routing a blokkolás minimalizálására
A telefonhálózat leegyszerűsített szerkezete helyközi gerinc helyi hálózat Itt azon gondolkoztam, hogy ezt a sorrendet kövessem, vagy fordítva legyen. Ennek a sorrendnek a történetiség, a bonyolultság fokozatos növelése, és a fontos részekre történő kifutás az értelme. Úgy vélem, hogy érdemes röviden rámutatni a telefonhálózatokban alkalmazott routing jellemzőire, mert: Ezzel is hangsúlyozhatjuk a hálózatok lehető közös kezelésének szükségességét, és lehetőségét Rámutathatunk, hogy milyen szorosan kapcsolódik az útvonalválasztás a hálózat felépítéséhez, topológiájához A mondandónk érdekében csak két rétegre egyszerűsítettük a hálózatot, nevezetesen a lokális központok, és a távolsági központok rétegére (természetesen ezek nem architekturális rétegek). Az ábrán van egy lokális központ csoport, összelinkelve, amelyek például egy városban helyezkednek el, valamint szinte szimbolikusan látható a távolsági központoknak egy csoportja, szintén szimbolikusan a full mesh topológia szemléltetésével. A lokális központok mindegyike linkelve van egy távolsági központhoz. Az ábrán nem látható módon természetesen sok további lokális központ, illetve azok csoportjai léteznek, a mutatotthoz hasonló linkekkel. Hogyan történik a call processing, azaz az útvonal-kijelölés? Azonos központhoz tartozó helyi hívásoknál nincs útvonal, a csoport másik tagjához tartozó hívás esetén van közvetlen útvonal, és van két-lépéses a távolsági központon keresztül. Távolsági hívás esetén az útvonal a távolsági központhoz megy. Itt – lévén teljes szövevény – mindenki mindenkivel összeköttetésben van, így a következő két egyszerű lehetőség adódik: (i) ugyanide van bekötve a hívott lokális központja (de nincs közvetlen link a két lokális központ között), vagy (ii) egy másik távolsági központhoz kell továbblépni. Nemzeti szinten ezzel az útvonal-kijelölés kész. Nemzetközi szinten tovább kell lépni a másik nemzeti hálózathoz, de lényegében csak mennyiségi a különbség. Most nézzük az alkalmazott routing alapelvét! Az útvonal-táblák kitöltése centralizáltan, és a jósolt forgalom függvényében, de nagyon egyszerűen történik. Valójában csak a távolsági központok számára van választási lehetőség, hiszen a lokális központoknak vagy közvetlen összekötésük van a hívott lokális központjához, vagy tovább kell lépnie a távolsági központhoz. A távolsági központ azonban két útvonalat használhat: (i) a közvetlen összekötés azzal a távolsági központtal, amelyhez a hívott lokális központja be van kötve, vagy amennyiben itt nincs szabad trönk, akkor (ii) egy plusz lépés. Ez utóbbi tehát azt jelenti, hogy úgy kell kitölteni az útvonal-táblákat, hogy legyen egy tartalék út, amely remélhetőleg kevésbé terhelt olyankor, amikor a közvetlen összekötéseken nagy a forgalom. Ezt még úgy fejlesztették tovább, hogy megengedték több két-lépéses összekötés vizsgálatát is. Ezzel a módszerrel a telefonhálózatok jó eredményt érnek el a címben jelzett célt tekintve, azaz lényegesen csökkenthetik a blokkolás (sikertelen legyen a hívás trönk foglaltsága miatt) valószínűségét. helyi központ előfizetők

11 Elosztott routing „Routing az összekötöttség – connectivity – maximalizálására” Legyen a módszer elosztott! Az útvonaltáblák kialakítását végezzék maguk a csomópontok Két alapvető módszer ismert: „distance-vector” – Bellman-Ford algoritmus „link-state” – Dijkstra algoritmus A módszerek különböznek: a gyűjtött információban a gyűjtés módjában A címmel még elégedetlen vagyok, de a cél az, hogy megmutassuk annak a hatását a routingra, amit a túlságosan merev, és központosított telefonhálózattól történő elszakadás jelentett. Ennél az elszakadásnál (tekintettel a katonai vonatkozásokra) nagy szerepet kapott a minden körülmények közötti konnektivitás, azaz a „túlélés” biztosítása. Ehhez jól kapcsolódik az elosztott routing választása, azaz ne legyen valami sérülékeny központ, hanem az útvonal-táblák kialakítását végezzék maguk a csomópontok, és ameddig legalább kettő van, addig életképes a módszer. Az alapvető módszerekhez bevezetésként tételezzünk fel egy egyenrangú (flat) hálózatot, amelyben tehát valamennyi csomópont egyenlő szerepet játszik. (Ma már tudjuk, hogy ez akadálya a növekedési képességnek, azaz it has poor scalability, de nagyon jó bevezetőként.) Két módszert dolgoztak ki, amelyek abban különböznek, hogy milyen információt gyűjtenek és hogyan teszik azt, annak érdekében, hogy a csomópontok egyöntetű (konzisztens) képet alakíthassanak ki a hálózatról.

12 A módszerek lényege Valójában nem információ gyűjtés, hanem terítés történik „Kinek, mit mondunk?”: Távolság-vektor (Distance-vector): A csomópontok elmondják a hálózatról alkotott elképzeléseiket a szomszédaiknak Összekötés-állapot (Link-state): A csomópontok elmondják mindenkinek a szomszédaikról nyert tapasztalataikat A csomópontok alapvetően kérdés nélkül küldözgetik az információjukat, ezért mondtam a terítést a gyűjtés helyett. Itt most még csak a lényeges eltérést akarom hangsúlyozni, tehát a distance-vector módszer elképzelést közöl a szomszédokkal, a link-state pedig tapasztalatokat közöl mindenkivel. Azt, hogy mit takar az elképzelés, a tapasztalat, és hogyan lehet ezt mindenkivel közölni, a következőkben részletezzük.

13 A „távolság-vektor” módszer
A gyűjtött információ és a gyűjtés módja: A csomópontok elmondják a hálózatról alkotott elképzeléseiket a szomszédaiknak Az „elképzelések”: melyik csomópont milyen távol van egy lista (vektor) melynek elemei „csomópont azonosító – távolság” párok A távolság-vektorát közli mindegyik csomópont valamennyi szomszédjával A távolság mérése „ A csomópontok elmondják a szomszédaiknak az elképzeléseiket a hálózatról”: a gyűjtés módja annyiból áll, hogy mindegyik csomópont csak a vele összekötésben lévő csomóponttal kommunikál, a küldött információ pedig lényegében egy elképzelés. Elképzelése annak, hogy az illető csomópont valamely cél címet hány lépésben érne el, ha a szomszédain keresztül elindulna. Ezt az elképzelést oly módon fejezik ki, hogy készítenek egy vektort, amelynek összetevői a csomópont által ismert többi hálózati csomópont, illetve a csomópontnak azoktól mért távolsága. Már most szögezzük le, hogy a módszerektől függetlenül egy sarkalatos kérdés a távolság mértéke. Eddig is utaltunk rá, hogy nagyon leegyszerűsítve ez lehet a lépések (hops) száma, de valójában nagyon kifinomult módon súlyozhatjuk a link átviteli sebességét, sorbanállási hosszt, monetáris költséget. A távolságra egyébként használják a költség kifejezést is. Így lényegében a vektor elemei az illető csomópont által elképzelt költség a hálózat többi (ismert) csomópontjához. Miért hangsúlyozzuk az „elképzelést”? Mert a csomópontoknak nem lehet biztos és éppen aktuális ismeretük egy nagyméretű dinamikusan változó hálózatról. Sőt még könnyen adódhatnak félreértések is, és így téves elképzelések alakulhatnak ki. (erre még rámutatunk)

14 A Bellman – Ford algoritmus
Ba Db G F B H A E C D Ea Bb Da Példa: A B,1 B A,1 C,1 E,1 G,1 ∞ C D,1 D E F,1 B A,1 C,1 D,2 E,1 G,1 ∞ C B,1 D,1 B-hez megérkezik C üzenete: A csomópontok megkapják a szomszédaiktól a távolság-vektorokat és ebből kell egy konzisztens képet kialakítaniuk az egész hálózatról. Hogyan történik ez? Lépésről lépésre. Kiindulásként mindenki csak a szomszédait ismeri, a hálózat – feltételezhető – többi része még „végtelen” távol van. Amint megkapják a szomszédok üzeneteit, akiknek vélhetően vannak távolabbi szomszédaik, akkor kiegészíthetik a vektoraikat újabb bejegyzésekkel. Még a legegyszerűbb példa bemutatása is gondokkal jár. Itt azt próbáltam megoldani, hogy elképzelhető legyen az egész, miközben csak egy kiragadott részlettel foglalkozunk. A történéseket csak a B csomópont szempontjából szeretnénk valamennyire is megérteni. A kiinduló táblázatban csak a B sorában jelöltük végtelennel, hogy feltételezünk további részeket is. Ennek „helyére” írjuk az újabb csomópontok adatait, ha azok a szomszédok üzeneteiből kiderülnek. (én most abc sorrendbe írtam be) Így, amikor C üzenete megérkezik, akkor B számára kiderül, hogy van egy D csomópont is, amely a szomszédjától 1 távolságra van, tehát tőle 2 távolságra lesz. A történet hasonlóan folytatódik, amikor a többi szomszéd üzenete is megjön. Még az E csomópont üzenetét mutattam meg, amelyből például F léte és távolsága derül ki. Mi a lényege a Bellman-Ford algoritmusnak? Ha a beérkező üzenetet megvizsgálva kiderül, hogy rövidebb útra van lehetőség, akkor végrehajt egy cserét a vektorban. Ha sok időnk van mutathatunk példát, de mindenképpen érzékeltethetjük a következő módon: tételezzük fel, hogy D üzenete eljutott E-hez, az tovább F-hez, majd G-hez, és innen B-hez. A fentiek alapján tudjuk, hogy F táblázatába bekerült D két lépéssel, G táblázatába így D már 3 lépéssel szerepel, és ezért B úgy látja, hogy D a G-n keresztül 4 lépéssel érhető el. ha ezután érkezik hozzá E vagy C üzenete, amelyekben D egy lépéssel szerepel, akkor nyilván lecseréli a bejegyzést, mert 2 kisebb, mint négy. Még annyi megjegyzést kell ehhez tenni, hogy a most mondott példa elég természetes, mert a csomópontok a vektor-távolság módszer alapelképzelése (és a realizált protokollok) szerint nem szinkronizáltan, hanem szándékosan „szétszórva” küldik üzeneteiket, csökkentve így az általuk keltett forgalom csomósodásának esélyét. Azt már látjuk a fentiekből, hogy miként lesz a csomópontoknak (bizonyíthatóan) konzisztens képük a hálózatról, de érdemes még az útvonal-táblák kialakítására is rámutatni. (Azt bizonyították, hogy a fenti algoritmus konvergens, de azt is tudjuk – rá is fogunk mutatni, hogy vannak tranziensei.) Végül fontos megjegyezni, hogy bár a név arra ösztönöz, amit itt – az egyszerűség kedvéért – csináltunk, nem kell a lépésszámnál leragadni, hanem bármilyen módon mért költséget rendelhetünk az összekötésekhez. Így a szomszédok 1-től eltérő költséggel lesznek elérhetők, és a legkisebb költségű út nem biztos, hogy a legkevesebb lépésszámú lesz. Ugyanakkor azt is fontos hangsúlyozni, hogy ez a választás csak akkor lesz eredményes, ha valamennyi csomópont azonos mértéket használ a költségre, ellenkező esetben inkább zavaró lesz, sőt kaotikusnak is nevezhető az eredmény. B-hez megérkezik E üzenete: B A,1 C,1 D,2 E,1 F,2 G,1 ∞ E B,1 D,1 F,1

15 Az útvonal-táblák kialakítása
Ba Db G F B H A E C D Ea Bb Da 1 2 3 4 5 6 Például: B távolság-vektora Sorszámoztuk B portjait Kitölthetjük B útvonal-tábláját: B A,1 C,1 D,2 E,1 F,2 G,1 ∞ Ba 6 közvetlen Bb 2 Da 3 C-n át Db Ea 4 E-n át Amennyiben a csomópontokon rendelkezésre állnak a távolság-vektorok, csekély munkával kitölthetők az útvonal-táblák. Alapvetően mit is tartalmaznak a táblák? Azt, hogy valamely célhoz a csomópont melyik portján keresztül vezet az út. A könnyű megértés kedvéért azt az egyszerűsítést végeztük, hogy a kis példa-hálózatunkban a csomópontok által kiszolgált végpontok (/alhálózatok) azonosítására a csomópont nevéhez kötött azonosítót használtunk (Ba, Bb, Da, Db), ami csak annyit jelent most, hogy nem kellett a vektorokba beírni még azt is, hogy kik vannak 0 távolságra az adott csomóponttól. Az útvonal-tábla kitöltésénél – jelenlegi példában csak a Da és Db címek az érdekesek – kihasználjuk azt, hogy a távolság-vektor kialakításánál a D-re vonatkozó bejegyzést a C-től kaptuk, aki a csomópont 3-as portjára van kötve.

16 A távolság-vektor módszer alapproblémája
C táv Köv. lépés A 2 B 1 C A végtelenig-számolás: Példa: A B-C link megszakad B kijavítja a bejegyzését B és A kicserélik elképzeléseiket és korrigálnak: Ha ismét cserélnek és korrigálnak: x A B C A 2 B ∞ - A ∞ - B 3 A távolság-vektor jól működik, ha valamennyi csomópont mindig üzemel. Amennyiben a csomópontok leállnak (meghibásodnak) majd újraindulnak, akkor problémák lépnek fel, mert zavaró tranziensek jelentkeznek. Ennek alapvető oka az, hogy a csomópontok nem közlik a távolság-vektorukkal együtt, hogy milyen módon, lépések révén jutottak a közölt eredményre. Így könnyen bekövetkezhet a végtelenig-számolás jelensége, amely a módszer alapproblémája. Azt hiszem, hogy érdemes követni a szokásos legegyszerűbb példát. Az A és a B jelű csomópontok egymás szomszédjai. A példa a C csomóponthoz jutás esetét magyarázza. Kezdetben mindkét link él, és a routerek a kezdeti tábla szerint működnek. A B által felújított állapot és az A korábbi állapotának cseréje közel egyidőben történik. Szándékosan használjuk az elképzelést. Ekkor A rájön, hogy a B-n keresztül C-hez vezető út megszakadt, és korrigál. Ezzel szemben B nem tudja, hogy az A által mondott két lépéses út C-hez rajta keresztül vezet, így megörül a lehetőségnek, hogy bár egy lépéssel hosszabban, mint korábban (erre egyébként nem emlékszik, csak azt látja, hogy végtelennél rövidebb) mégiscsak elérhető C és ő is korrigál. Az „egymás hülyítése” addig tart, míg mindketten el nem jutnak a stabil végtelen távolságú C állapotba. Így itt az ideje, hogy megjegyezzük, miszerint végtelennek persze egy nagyon is véges számot választanak, több protokoll a 16-ot tekinti annak. Mindenesetre egy ilyen „felszámolás” eltart egy ideig, attól függően, hogy milyen időközönként küldenek információt a routerek egymásnak. Ennek szokásos értéke 30 mp, amiből a felszámolás időtartama több percre adódik. De miért baj az, hogy eljátszanak ezek a routerek? Azért, mert ezalatt az időszak alatt valamennyi C-nek tartó forgalmat egymásnak irányítják oda-vissza. Egy hurkot képeznek, amely egyrészt lehetetlenné teszi a célba jutást. Persze megszakadt a link, így C nem érhető el, de az A-B linket túlterhelik, és így azon a célba juttatható forgalom is gátolva lesz. A 4 B ∞ -

17 A távolság-vektor javítási lehetőségei
Az alapelv: ki kell egészíteni a távolság-vektort a létrejöttére utaló megjegyzésekkel Melyik csomóponton keresztül érvényes Ez érdekes téma, de kérdés, hogy van-e rá elég idő, mert címszavakat felsorolni nem érdemes, viszont a megoldások alapötletei is gondolkozást igényelnek.

18 Az „összekötés-állapot” módszer
A gyűjtött információ és a gyűjtés módja: A csomópontok elmondják mindenkinek a szomszédaikról nyert tapasztalataikat A „tapasztalatok”: a szomszédokhoz vezető linkek aktuális állapota (ez pontosan ismerhető) Az információ elküldése „mindenkinek” a korlátozott (felügyelt) elárasztás-sal: elküldik a szomszédokhoz, akik továbbadják kivéve azon a linken, amelyen érkezett Kellően sokat vitatják, hogy miért is jobb a link-state, mint a distance-vector, így én nem mennék bele, maradnék az alapelv ismertetésénél.

19 A küldött információ és „védelme”
Például: B csomópont Védelem a „félreértés” ellen: sorszámozás és öregítés Védelem a hibák és rosszakarat ellen: hibavédő kódolás és autentikáció (hitelesítés) Ba Db G F B H A E C D Ea Bb Da B A 1 C E 2 G Ba Bb A linkeknek két végük van, a küldött információt a küldő és a link másik végén lévő csomópont azonosítja, az információ lényege pedig a link költsége valamilyen mérték szerint. A példában felsoroltuk a B csomópontból induló linkeket, beleértve a végpontokhoz vezetőket is. (Egyébként a routing szempontjából nem kell feltétlenül csomópont – végpont szembeállítást végezni.) A harmadik oszlop a linkek költsége. Például a közvetlenül kiszolgáltakhoz most nullát írtunk. Ez a táblázat eljut valamennyi csomóponthoz, és azok egymástól függetlenül meghatározzák a követendő utakat, és beírják útvonal-táblájukba azok első lépését. Semmi többet nem kéne tenni, ha mindig minden működne. Mivel ez képtelenség, ezért gondoskodni kell egy „félreértés elleni védelemről”. Valójában ez két elemet tartalmaz: sorszámozás, és öregítés. A védelemnek két szintje van, az egyik a sorszámozás (és annak is gondos alkalmazása), valamint az öregítés. A másik pedig a szó szerinti védelem az integritást, és az autentikációt biztosítandó. Ezt megfelelő hibadetekciós kódolással, és jelszavas azonosítással érik el. Az öregítés azt jelenti, hogy az üzeneteket nem szabad örökérvényűnek tekinteni. Mindig joggal tételezhetjük fel, hogy a kommunikációban zavar, akadály lép fel. Így amennyiben megadott ideig nem érkezik egy „frissítés”, amely persze gyakran a korábbi üzenet, csak – mondtuk – más sorszámmal, akkor a régit érvénytelennek kell tekinteni, és új utakat számolni. De hogyan is történik az utak kiszámítása?

20 A Dijkstra algoritmus Példa: B csomópont B P és T halmazok
Ba Db G F B H A E C D Ea Bb Da Példa: B csomópont P és T halmazok Ha T halmaz üres, akkor vége van B C(B,1) E(B,2) D(C,2) C B 2 D 1 D(E,3) F(E,3) D C 2 E 1 Amikor mindenkinél megvannak az összes többi csomópont előbb vázolt üzenetei, akkor mindenki elkezdheti kialakítani, kiszámítani a tőle vezető le grövidebb utakat a többi csomóponthoz. A példahálózat képét nyilván nem ismerik a csomópontok, ezt kell nekik megalkotni az üzeneteikből. Mégis egyszerűbb a kép alapján bemutatni az algoritmust, mintsem elveszni a táblázatokban, de fontos erre felhívni a figyelmet. Illusztrációként mutatjuk a C, D, E által küldött táblázatokat. Alkalmas például arra, hogy rámutassunk egy link „aszimmetrikus” lehetőségére (különböző lehet a költség a link két irányában). Használhatjuk a Permanens és a Temporary elnevezéseket az algoritmusban alkalmazott halmazokra. Először csak mi (akik készítjük) vagyunk permanensek, tehát B. A Temporary-ba betesszük a szomszédainkat, jelenleg a C-t és az E-t, mert a többivel most nem foglalkoznék a rövidség kedvéért. Például úgy tartjuk nyilván a csomópontokat, hogy a nevük mögé zárójelben beírjuk, hogy mely csomóponton keresztül, és mekkora költséggel érhető el. (A B szomszédaira vonatkozó adatok az előző szlájd táblázatában szerepelnek.) Most nem írom be a többieket (A,G,stb), de persze kellene. A szomszédokat akkor írjuk be T-be, ha még nincsenek ott, vagy ha már ott vannak, de az új szomszédságból fakadóan kisebb költséggel is elérhetők, de ekkor lecseréljük a korábbi bejegyzést. A T-ből a legkisebb költségűt átvisszük P-be, ha még nincs ott. És beírjuk T-be a szomszédait a fenti feltétellel. (én most a halmazok tartalmát nem ismétlem soronként, tehát a halmaz az egész függőleges oszlop, a vízszintes vonalak csak a lépéseket hangsúlyozzák. E B 2 D 1 F

21 A hierarchikus routing
Ha egy hálózatnak N csomópontja és E összekötése van, akkor kimutatható: A legrövidebb út számítása: O(E logE) Az útvonaltábla mérete: O(N) Nem lehet hierarchia nélkül egy Világháló: # csomópont Tábla-hely Számítási idő 1 O(0) 1.000 O(3.000) O( ) O( ) O(100 millárd) Az Internet növekedésével viszonylag hamar kiderült, hogy az egységes (flat), nem-hierarchikus hálózati struktúra nem lesz működőképes, mert az útvonal-táblák olyan mértékű növekedést mutatnak, ami kezelhetetlenné válik, és a legrövidebb utak számítása is jelentős időt igényel. A táblázatban és a második sorban szereplő számításra vonatkozó megjegyzés természetesen csomópontonként értendő. És bár informatikusok jól tudhatják, de az utolsó oszlop azt jelenti, hogyha egy csomópont táblájának meghatározása egységnyi időt igényel (ordó nulla), akkor a 10 millárd csomópontos hálózat esetén a számítási kb 100 milliárd lenne.

22 Az autonóm rendszerek Az autonóm rendszer (AS)
olyan egység, amelyen belül egységes routing policy érvényesül egyetlen hálózat, vagy hálózatok csoportja közös hálózatadminisztrátor (vagy azok csoportja) kezeli egyetlen szervezeti egység (pl. egyetem, üzleti vállalkozás) megbízásából Gyakran routing-domainnak is nevezzük Az autonóm rendszer globálisan egyedi azonosítót kap, az ASN-t (Autonomous System Number) Ezen úgy lehet segíteni, hogy „szétdaraboljuk” az egységes hálózatot. A szétdarabolás azt jelenti, hogy ún autonom rendszereket (Autonomous System) alakítunk ki, amelyek – nevükkel összhangban – önállóan oldanak meg bizonyos feladatokat, így például a routingot. Ez azt jelenti, hogy a külvilágnak egyetlen elérési pontként kell csak ismernie az AS-t, tehát egyetlen bejegyzés az útvonal-táblában, függetlenül annak kiterjedésétől, a benne szereplő végpontok számától. Az AS ún határ-routere fogja „elintézni” a belső feladatokat. autonomous system - On the Internet, an autonomous system (AS) is the unit of router policy, either a single network or a group of networks that is controlled by a common network administrator (or group of administrators) on behalf of a single administrative entity (such as a university, a business enterprise, or a business division). An autonomous system is also sometimes referred to as a routing domain. An autonomous system is assigned a globally unique number, sometimes called an Autonomous System Number (ASN). Networks within an autonomous system communicate routing information to each other using an Interior Gateway Protocol (IGP). An autonomous system shares routing information with other autonomous systems using the Border Gateway Protocol (BGP). Previously, the Exterior Gateway Protocol (EGP) was used. In the future, the BGP is expected to be replaced with the OSI Inter-Domain Routing Protocol (IDRP). The Internet's protocol guideline for autonomous systems, after offering a definition similar to the one above, provides a more technical definition as follows: An AS is a connected group of one or more Internet Protocol prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy. CONTRIBUTORS:Olivier CaymaexLAST UPDATED:09 Jun Read more about autonomous system: - The Internet's RFC 1930 provides " Guidelines for the creation, selection, and registration of an Autonomous System (AS) .„ RFC 1786 refers to autonomous systems in describing the Representation of IP Routing Policies in a Routing Registry . In the Internet, an autonomous system (AS) is a collection of IP networks and routers under the control of one entity (or sometimes more) that presents a common routing policy to the Internet. See RFC 1930 for additional detail on this updated definition. Originally, the definition required control by a single entity, typically an Internet service provider or a very large organization with independent connections to multiple networks, that adhere to a single and clearly defined routing policy. See RFC 1771, the original definition (now obsolete) of the Border Gateway Protocol (BGP). The newer definition of RFC 1930 came into use because multiple organizations can run BGP using private AS numbers to an ISP that connects all those organizations to the Internet. Even though there are multiple autonomous systems supported by the ISP, the Internet only sees the routing policy of the ISP. That ISP must have a public, registered ASN. A unique AS number (or ASN) is allocated to each AS for use in BGP routing. With BGP, AS numbers are important because the ASN uniquely identifies each network on the internet. Contents 1 Assignment 2 Types Assignment AS numbers are assigned by the IANA, which also allocate IP addresses, to regional internet registries (RIRs) in blocks. The local RIR then assigns an AS number to an entity from the block assigned by the IANA. Entities wishing to receive an ASN must complete the application process of their local RIR and be approved before being assigned an ASN. Current IANA ASN assignments can be found on their website: [1] AS numbers are currently 16-bit integers, which allow for a maximum of assignments. AS numbers are divided into two ranges. The first are public AS numbers, which may be used on the internet and range from 1 to The second range, from to 65534, are known as private numbers, and can only be used internally within an organization. The RIRs plan to issue 32-bit AS numbers, starting in These numbers will be written using a number format of <base-ten representation of the upper 16 bits>.<base-ten representation of the lower 16 bits>. Types Autonomous Systems can be grouped into three categories, depending on their connections and operation. A multihomed AS is an AS that maintains connections to more than one ISP. This allows the AS to remain connected to the internet in the event of a complete failure of one of their ISPs. However, this type of AS would not allow traffic from one ISP to pass through on its way to another ISP. A stub AS refers to an AS that is only connected to a single ISP. This may be a waste of an AS number if the network's routing policy is the same as its upstream ISP's. There is often more to Internet routing: the apparently-stub AS may in fact have peering with other autonomous systems that is not reflected in public route-view servers. Specific examples include private interconnections in the financial and transportation sectors. A transit AS is an AS that provides connections through itself to the networks connected to it. That is, network A can use the transit AS to connect to network B. ISPs are always transit ASs, because it is their business to connect disparate networks in exchange for money. The ISP is considered to be 'selling transit service' to the end network, thus the term transit AS.

23 Autonóm rendszerek Egy autonóm rendszer a többi autonóm rendszer számára jelzi az általa képviselt csoporto(ka)t Az egész csoport egyetlen bejegyzés lesz az útvonal-táblában A R AS_1 AS_2 B AS_3 Az illusztrációban a szögletes dobozok gerinc-routereket jelölnek, míg az R jelű karikák az AS-ek, vagy azon belüli hálózatok határ-routerei. A foltokban tehát összetett hálózatok vannak, amelyek belső viszonyit egységesen adminisztrálják, és minimum a határ-routerek ismerik a hálózatot, így minden érkező csomagot irányítani tudnak. Ugyanakkor ezek a határ-roterek csak ún összesített ismeretet küldenek a külvilág felé, amelyből a többiek, alapvetően a gerinc-roterek megállapíthatják, hogy valamely csomagot melyik AS határ-roternek kell átadni ahhoz, hogy az majd belül célba juttassa. Azt vegyük észre, hogy a jelenlegi szövegek, mind a slide-on, mind a kommentben, kellően eltávolodtak a routingtól, sokkal inkább a csomag-továbbítás elvégezhetőségére utalva kísérlik meg rávilágítani, hogy milyen feleadatok is merülnek fel a routingot illetőleg. Persze az továbbra is igaz, hogy előkell állítani a legjobb útvonal-táblákat, tehát semmi sem változott alapvetően, hanem csak kicsit színesebb lett a feladat. Úgy gondolom, hogy ezt a szintet kell követni a még hátralévő pontokban (mobil és multicast) esetén is. Végül azt jegyezném meg, hogy csak itt jegyzem meg, hogy az alapvetően háromféle AS közül az illusztráció csak a stub-ot mutatja, tehát csak szóban kéne mondani, hogy van multimomed és transit is (lásd az előző lap kommentjében).

24 A mobil végpontokat megengedő routing
„Kiegészítések” a csomópontokon: Mobil ügynök: Home agent = hazai ügynök Foreign agent = idegen ügynök R HA FA HA FA A mobil telefon nyújtotta lehetőségek nagy csábítást jelentettek az Internet felhasználók számára, és úgy gondolták, hogy máshol is találhatnak olyan csatlakozási lehetőséget, mint a megszokott környezetükben, amikor már felszerelkeztek a hordozható PC-ikkel. Sikeresen el lehet mondani ezzel kapcsolatban, hogy valaki átmegy a barátjához rövidebb-hosszabb időre, és mivel vár egy fontos telefont (még a mobil korszak előtt vagyunk), fogja a vezetékes telefonját és megkéri a barátját, hogy csatlakoztathassa az Ő telefonaljzatukba. A megoldás ugyanúgy nem működik, mint amikor megkíséreljük a saját laptopunkat idegen helyen csatlakoztatni a hálózathoz, hacsak nem csinálunk valamit, amit a slide címében jeleztünk. A csomópontokat, amelyek megengedik, hogy idegen felhasználó berendezések csatlakozzanak a hálózathoz fel kell készíteni erre. A felkészítés alapelve: ügynököket helyezünk el a csomóponton, amely ügynökök elvégzik mindazt a feladatot, amely a helyüket változtató host-okkal kapcsolatban felmerül. Lényegében a mobil routing egy kiegészítés a csak rögzített végződéseket kezelni képes routinghoz képest. Az illusztrációban az M mobil host csatlakozik a bejegyzett helyén (otthon) a hálózathoz, és ezt természetesen a Home Agent is nyilvántartja. A csatlakozásról feltehetjük, hogy rádiócsatornán történik. A terminál elvándorol és csatlakozik egy másik helyen a hálózathoz. Az idegen ügynök veszi a mobil host bejelentkezését (részletezhetjük is, de nem túl lényeges, hogy ki a kezdeményező). Az idegen ügynök felveszi a kapcsolatot a mobil host Home Agent-jével. Az F jelű fix host üzenetet küld az M jelű mobil hostnak, akinek ismeri az otthoni címét. A csomag megérkezik az „otthoni” routerhez, akinél a Home Agent már tudja, hogy a nála „otthonos” mobil host hol tartózkodik. Becsomagolja a kapott csomagot, és elküldi ahhoz a csomóponthoz, amelyikhez a mobil host csatlakozik. A becsomagolt csomagot szokták úgy is tekinteni, és a továbbítást nevezni, hogy egy alagúton keresztül jut el a csomag az ideiglenesen kiszolgáló csomóponthoz. Természetesen a csomag fizikai útvonala a tényleges linken lesz! Az új csomópontban a Foreign Agent megért (hiszen előtte megbeszélte az otthoni ügynökkel), hogy a megérkezett csomag a bejelentkezett mobil hostnak szól, kicsomagolja a csomagot, így előkerül a mobil host címe aki örömmel veszi a csomagját. Végül ismét hívjuk fel a figyelmet, hogy a routing alapfeladata nem változot, továbbra is meg kell találni a legjobb utakat, de most felmerül egy kiegészítő feladat is. Ezt a járulékos feladatot a vonatkozó ügynökök látják el. További megjegyzéseket lehet és érdemes tenni. Az egyszerűbb kérdés, hogy foglalkozni kell a meghibásodó látogató problémájával is. (például elmegy a mobil host tápfeszültsége és nem tudott kijelentkezni az idegen ügynöktől) nem szabad, hogy egy hamis helyzetértékelés korlátlanul fennálljon. Egy sokkal érdekesebb probléma a mobil hostok kiszolgálásával kapcsolatban a biztonság. F M

25 A multicast routing Példa: Megoldandó feladatok: Ba -> Da, Db és Ea
Három unicast Multicast Megoldandó feladatok: Címzés Csoportkezelés Útválasztás segítése Ba Db G F B H A E C D Ea Bb Da Itt szintén felmerülnek járulékos feladatok az alap-routinghoz kiegészítésül, mert a csomópontok közötti utakat most is kell ismerni, és a táblákat ki kell tölteni, de nem egyetlen címre kell eljuttatni csomagokat. (vagy nem egy összeköttetést kell egyidejűleg kiépíteni egy konferenciabeszélgetés esetén) Foglalkozzunk csak a csomagkommunikációval! Mi az alapfeladat, miért érdekes és szükséges ezzel törődni? Az alapfeladat a kommunikáció hatékony végrehajtása, azaz a lehető legkevesebb erőforrás igénybevételével juttassuk el ugyanazt a csomagot több helyre. Azért szükséges ezzel törődni, mert sok cél esetén nagy az erőforrás-megtakarítás lehetősége. Azért érdekes, mert sajátos problémákat vet fel, amelyeknek érdekes megoldása van. Persze azért az is igaz, hogy a hatékonyságon túl meg kell oldani, hogy bizonyos feladatok teljesíthetők legyenek. Ha kis kitérőt akarunk tenni, például a hálózati konvergencia irányába, akkor elmondhatjuk, hogy a közvetlen kommunikáció mindhárom fajtáját szeretnénk egyetlen hálózaton biztosítani. Melyik ez a három fajta? Az egyik a pár”beszéd”, amit biztosít a telefonhálózat (azért használtam idézőjelet, mert nem csak beszéd lehetséges két partner között). A másik az „igehirdetés”, amit megold a műsorszóró hálózat (ez ugye a pont-multipont kommunikáció, és hangsúlyozottan egyirányban). A harmadik a konferencia, ami a multipont-multipont eset, persze értelemszerűen mindig csak egy forrás van, de az bármelyik lehet, és dinamikusan változhat a konferencia fennállása alatt. Erre a feladatra nem jött létre hálózat. A telefonhálózat korlátozott lehetőséget kidolgozott (három résztvevős), de az igazi kezdetek az Interneten jelentek meg. (Csak a biztonság kedvéért – hiszen informatikusokat oktatunk – mindezek a hálózatok a vonatkozó közvetlen kommunikációnak a táv-megfelelőjét akarják megvalósítani.) Térjünk vissza oda, hogy mi az, ami nem oldható meg akárhogyan? A sokpontos műsorszórás, és még inkább a sokpontos konferencia. Az előbbi esetén nem csupán arról van szó, hogy hatékonyabb a forrásból egy, vagy néhány példányban elindítani a műsort, majd az indokolt pontokon másolatokat készítve folytatni, hanem fizikailag korlátozott az egyidejűleg indítható példányszám (itt ugye most arra utalunk, hogy a műsorszórás – kellő erővel – megoldható úgyis, hogy mindenkinek egyenként elküldjük a műsort, és ezalatt valódi idejű információt értünk, nem pedig tárolt információ átadását, nevezzük streamingnek). A konferencia esetén a helyzet még összetettebb. Az elmélkedés helyett térjünk a lényegre. A bevezető példában rámutatunk az erőforrás-használat eltérésére unicast- és multicast esetben. Például úgy lehet számolni, hogy a három unicast esetén a felső két linket 2 csomag, az alsó egy linket 1 csomag veszi igénybe, ami 5 link-szer-csomag. A multicast esetben az alsó két linket 1 csomag használja, tehát 2 link-szer-csomag a terhelés, vagy erőforráshasználat. Milyen problémákat kell a multicast esetén megoldani az alap-routingon túl? Kezelni, címezni kell a csoportokat (csoportok kezelése összetettebb, és feljebb lévő tevékenységet is igényel, de az nem tárgy a routingnak) A forrásnak és a címzettekhez vezető úton lévő csomópontoknak kitalálhatóvá kell tenni az utakat. Problems: Discovering the set of current multicast groups Expressing interest in receiving packets from a group Discovering the set of receivers in a group Delivering data to every member of the group

26 A többescímzés, csoportazonosítás
Azonosítsuk a csoportot! A hálózat csatlakozási pontjait azonosítja: Fizikai cím Logikai cím A csoportot egy, a logikai címhez hasonló azonosító különbözteti meg, nem a csoport tagjainak címlistája! A csoport létezésének feltétele, hogy legalább egy tagja legyen Világossá kell tenni, hogy a végpontok azonosítására mi szolgál: Ún fizikai cím (pl hálózati interfész kártya azonosítója) Ún logikai cím, amelyet a hálózati csomópontok nyilvántartanak, az útvonal-táblákban ez jelenik meg A csoport azonosítására készíthető egy lista a csoport logikai címeiről, de szerencsére van ennél sokkal jobb ötlet is! Nem a végződések listája fogja azonosítani a csoportot, hanem egy az egyedi végződés azonosítására szolgáló logikai címhez hasonló azonosító, ún csoport-cím. Ez tehát nem végződést, hanem egy csoportot azonosít. Mire jó ez a csoport-azonosító? Így van egy absztrakt valami, amihez lehet csatlakozni, és amiből lehet távozni. Milyen tulajdonságú legyen ez az azonosító? Mi legyen létezésének a kritériuma? A csoport akkor létezik, ha van legalább egy tagja! Most jön az a kérdés, hogy honnan lehet tudni, hogy van egy csoport egy valamilyen azonosítóval, de ez a kérdés van a routingon kívül, sőt felett. Tehát tételezzük fel, hogy gondoskodtunk a csoport meghirdetésének lehetőségéről, és bármely érdeklődőnek rendelkezésre áll a vonatkozó azonosító, azaz megismerheti azt.

27 Multicast routing, módszerek
A csoport résztvevői a hálózatban: Sűrű elhelyezkedés: Elárasztás + lemondás (flood-and-prune) Legrövidebb útvonalfa alkalmazása reverse path forwarding Csoportlemondás Forráslemondás Ritka elhelyezkedés: Explicit csatlakozás Gerinc alapú fa alkalmazása (Core Based Tree) Elhelyezkedés független A kettő ötvözete Most képzeljük el, hogy van egy bennünket érdeklő csoport. Megtudjuk a csoport azonosítóját a bennünket kiszolgáló hálózati csomóponttól, akkor mit csináljunk? Mondjuk meg a bennünket kiszolgáló hálózati csomópontnak, hogy részt kívánunk venni a megadott azonosítójú csoportban. Mi történik ezután? A hálózati csomópont jelzi a csoportot kiszolgáló legrövidebb-út-fán felette állónak, hogy szeretné megkapni a csoport információját. Valójában bizonytalan vagyok abban, hogy mennyire érdemes részletezni a reverse-path forwarding, a flood-and-prune és a core-based tree módszereket. Lehet, hogy itt a kellő rövidség mellett maradnék. Végül úgy döntöttem, hogy összhangban az eddigiekkel megpróbálok rámutatni az ismert, jellemző módszerekre. Azt hiszem érdemes rámutatni, hogy különböző módszer az üdvözítő dense és sparse csoport esetén. Amennyiben a hálózatban a csoport tagjai sűrűn vannak, ami azt jelenti, hogy kevés kivételtől eltekintve a hálózat csaknem valamennyi csomópontja érdekelt a csoport üzeneteinek továbbításában, akkor célravezető módszer a hálózat elárasztása a csoport üzeneteivel. Lényegében az érdekes kérdés az elárasztás hatékonysága, azaz lehetőség szerint ne legyenek felesleges üzenettovábbítások, tehát mindenhová csak egyszer (egy példányban) jusson el a csomag, de egy példányban viszont tényleg eljusson. Korábban (link-state) már említettük az elárasztásnak egy korlátozását, amikor senki nem továbbította az üzenetet azon a linken, amelyen érkezett. Ez a korlátozás azonban kevés. Most nem ritkán küldött routing üzenetekről van szó, hanem gyakran küldött információról. A duplikált példányokat minimalizálni kell, mert egyrészt felesleges terhelés, másrészt még a csomópontoknál is több ellenőrzés (amit már egyszer odaadtak a felhasználónak azt nem kell megismételni). A multicast routingban kitalált további korlátozás a legrövidebb útvonal-fa alkalmazása a reverse-path forwarding módszerben. A reverse-path forwarding szabály: egy csomópont akkor továbbítja az S forrástól érkezett csomagot valamennyi (további) interfészén, ha a csomag azon az interfészen érkezett, amely megfelel a csomópont S-hez vezető legrövidebb útjának. Itt lehet példát mutatni arra, hogy ez nagyon jó, de nem küszöböli ki az összes duplikációt. Tovább lehet még lépni, ha még tüzetesebben vizsgáljuk az útvonal-táblát, mert hangsúlyozni kell, hogy ezek a járulékos tevékenységek mind arra épülnek, de sajnos el lehet érni azt is, hogy végül egye példány sem érkezik bizonyos csomópontokba. Heurisztikus ötleteket alkalmaztak a protokollokban. Ha az elárasztást már sikerült kellően finoman „behangolni”, akkor következik az a kérdés, hogy mi legyen azokkal a csomópontokkal, amelyek Felesleges terhelésként élik meg a csoport kommunikációját, mert sem ők maguk nem szolgálnak ki csoporttagokat, sem rajtuk keresztül nem vezet út ebből a célból. A megoldás a csoport csomagjainak visszautasítása, lemondása (mint egy előfizetés esetén). Ezek a csomópontok szólnak a forrás irányában felettük levő csomópontnak, ahonnan a csomagokat kapják, hogy nem kérik azokat. Az értesített csomópontok feljegyzik, hogy mely csoport üzeneteit, mely interfészeiken nem kell továbbítani. Ezt lehet még színezni is, mert egy multipont-multipont csoport esetén a források dinamikusan változhatnak, és még az is megengedhető, hogy a fogyasztó valamely csoport bizonyos forrásait mondja csak le. Amennyiben a csoport résztvevői egy nagy hálózat néhány, és területileg szétszórt csomópontját érintik csak, akkor az elárasztás és lemondás alkalmazása nem hatékony, felesleges nyűg a hálózat nyakán, miközben néhány szereplő élvezi azt az előnyt, hogy nem kell a csoporthoz explicit módon csatlakozni, illetve abból távozni. Ez egyébként az ellenkező (dense) esetben igen jelentős, mert a sok jelentkezés felesleges forgalmat, és sok munkát jelentene a linkeken és a csomópontokban. Lényegében a sűrű eset hasonló a műsorszóráshoz, mert nem kell bejelenteni, hogy bekapcsoljuk a vevőkészülékünket. Mi ennek a módszernek a lényege? Multicast gerincet hozunk létre erre kijelölt csomópontokból. Amennyiben valaki csatlakozni akar egy – valahonnan megtudott – csoporthoz, bejelentkezést küld, amelyet az őt kiszolgáló csomópont továbbít az általa ismert legközelebbi multicast gerinc routerhez. A bejelentkező üzenet akár több csomóponton keresztül éri el a célzott csomópontot, és így az útvonalba eső többi csomópontnak is fel kell jegyeznie, hogy mely csoport üzeneteit kell melyik interfészre továbbítaniuk. Így létrejön lényegében egy fa, amelyen a csoport üzeneti továbbításra kerülnek, és ezek a fák (több csoport is lehet egyidejűleg) a multicast gerincre épülnek. Egyébként ez a gerinc tunnel-ekkel is kialakítható, ami jelentősen növeli a hatékonyságot.(Nem kell sok érdektelennek figyelni a részletekre.) És hogyan lehetne univerzális módszert csinálni? Sajnos nem falrengető az ötlet. Detektálni kell, hogy sűrűnek, vagy ritkának minősítsük a csoportot, majd annak megfelelően járunk el a fentiekben ismertetett módon. Talán egyetlen megjegyzésre érdemes ötlet, hogy ritka elrendezés esetén a csomópontok választhatnak a CBT és a shortest-path között. Ennek az az előnye, hogy így csökkenteni lehet a CBT előbb nem említett hátrányát, a nagyobb sérülékenységi hajlamát, hiszen egy core router kiesése az egész csoport „megdöglésével” jár.

28 Összefoglalás Routing: az a folyamat, amelynek eredményeként a csomópontokban létrejönnek az útvonal-táblák Két fő módszer: Távolság-vektor (distance-vector) Összekötés-állapot (link-state) Kiegészítések szükségesek: Mobilitás biztosítására Pont-multipont, multipont-multipont kommunikáció esetén A routing az információ-továbbító hálózatok számára olyan alapfeltétel, amely egyáltalán lehetővé tesz tényleges – információ-továbbító feladatuk végrehajtását. Nem a call proccessing vagy a packet forwardig jelenti a routingot, hanem annak biztosítása, hogy az előbbieket el lehessen végezni. Mind a mobilitás biztosítása, mind a csoportok hatékony kezelése fontos a jövő számára, és bizonyos mértékig feltétele a hálózati konvergencia megvalósulásának, vagy kiterjedésének. A módszerek protokollokban kerülnek alkalmazásra, amelyeket megfelelő kommunikációs programok valósítanak meg.