lab Minőségbiztosítás a hálózati rétegben Távközlési és Médiainformatikai Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem Hálózati réteg Feladat: a csomagok eljuttatása a forrástól a célig legalacsonyabb réteg, amely a két végpont közti átvitellel foglalkozik. Megoldandó feladatok: Hálózati topológia ismerete, útvonalválasztás Túlterhelések elkerülése Különböző hálózatok összekapcsolása 2 Hálózati réteg A hálózati réteg belső szervezése: Összeköttetés alapú virtuális áramkörök A csomagnak / cellának nem kell útvonalat választania Összeköttetés nélküli datagramok Nincsenek előre meghatározott útvonalak, még akkor sem, ha a hálózati réteg által nyújtott szolgálat összeköttetés alapú Minden csomag más-más útvonalat követhet 3 1
Hálózati réteg A virtuális áramkör és a datagram alapú hálózatok összehasonlítása: Virtuális áramkör alapú hálózat Datagram alapú hálózat Áramkör felépítése Címzés Állapotinformáció Kötelező Minden csomag áramköri azonosítót tartalmaz Virtuális áramköri táblázat Nem szükséges Minden csomagban a teljes forrás- és célcím Nincs Forgalomirányítás Torlódásvédelem Minden csomag azonos útvonalon Könnyű virtuális áramkörök puffereltek Minden csomag függetlenül Bonyolult 4 lab Torlódásvédelmi módszerek Távközlési és Médiainformatikai Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem Torlódás Terhelés Ideális átbocsátás Tényleges átbocsátás Késleltetés Holtpont 6 2
Erőforrás-kezelési sémák osztályozása Erőforrás-kezeléssel egybeépített útválasztás külső, adott forgalomirányító protokoll Központosított hop-by-hop (elosztott) Mérés alapú foglalás alapú Folyamszintű állapotok aggregálás 7 Erőforrás-kezeléssel egybeépített útválasztás Megpróbál jó útvonalra irányítani, olyan útvonalon foglalni, ahova be is fér a folyam Elosztott eset: útvonalak próbálgatása Központosított eset: rögtön tudhatja a legjobb útvonalat (pl. QOSPF) Kapcsolódó technikák QOSPF Explicit routing / source routing MPLS 8 Erőforrás-kezelés és külső útválasztás Forgalomirányító protokoll működését az erőforrás kezelés nem tudja befolyásolni Oda irányít, ahova akar (általában: SPF) A kapott útvonalon kell erőforrást menedzselni, beengedési döntést hozni Elvárások az útválasztással szemben: A folyam összes csomagja azonos útvonalon menjen Ne változzon meg az útvonal Hálózati hiba Adaptív terhelés-megosztás 9 3
Központosított erőforrás-kezelés Van egy központi vezérlő Ismeri a felügyelt hálózatrész erőforrásainak kihasználtságát Ezt lehet lekérdezni hívás érkezésekor Foglalásos esetben: ez tárolja a foglaltságokat Mérés-alapú esetben: ő kapja meg a mérési jelentéseket Routing kapcsolat 10 Központosított erőforrás-kezelés 2 Előny: Csak egy dedikált gépben kell a funkciókat implementálni, nem pedig minden útválasztóban Hátrány: Single Point-of-Failure, azaz ha elromlik, magával rántja az egész hálózatot Jelzések miatti forgalomnövekedés Signalling overhead 11 Központosított erőforrás-kezelés - példa Bandwidth Broker 1 Tartományok közti (inter-domain) kommunikáció Bandwidth Broker 2 'A' Felhasználó Kérés Határcsomópont T A R T O M Á N Y Tartományon belüli (intra-domain) kommunikáció Határcsomópont Határcsomópont T A R T O M Á N Y Tartományon belüli (intra-domain) kommunikáció Határcsomópont 'B' Felhasználó 12 4
Központosított erőforrás-kezelés - példa Szomszédos tartomány Szomszédos tartomány Alkalmazások és hosztok Felhasználói interfész Inter-domain interfész BB szerver Adatbázis interfész Adatbázis Hálózatok Intra-domain interfész Határcsomópontok és belsõ csomópontok Határcsomópontok és belsõ csomópontok 13 Elosztott erőforrás-kezelés Hop-by-hop probing Belső csomópontok csak a saját terheltségeiket, illetve foglaltságaikat ismerik Minden linken egy-egy különálló hívásengedélyezési döntés születik Ha csak egy is elutasító: elutasítás Pl.: RSVP, RMD 14 Mérés alapú erőforrás-kezelés 1 Csomópontok mérik pl. a link kihasználtságot Általában van valamilyen mérés minden csomópontban, így nem biztos, hogy külön igényelne implementációt Nem biztos, hogy tárolni kell akármilyen új változót, beengedési döntéshez elég lehet csak a legutóbb mért kihasználtság is 15 5
Mérés alapú erőforrás-kezelés 2 Előnyök: Egyszerű probing, csak lekérdezés Implicit foglalás az, hogy csomagokat ad az új folyam (kihasználtság nő) Nem kell külön lebontás, hisz ha a folyam megszűnik adni, eltűnik a foglalása is Nagy kihasználtság, jó statisztikus multiplexálási képesség 16 Mérés alapú erőforrás-kezelés 3 Hátrányok: Mérési pontatlanság Rövid idejű: gyors, de nagyon variáns lehet. Hosszú idejű: jó átlag, de nem túl friss. Nem nyújt 100% garanciát (VBR folyamoknál) Ha egy folyam csak szünetel, elveszti foglalását Általában mégis igényel külön implementációt Osztályonkénti mérések Átlagolások (EWMA, mozgóablak, formulák) 17 Foglalás alapú erőforrás-kezelés 1 A beengedési döntés az új folyam leírójának és a korábbi folyamok tárolt foglaltság állapotainak függvénye Előnyök: Tud 100%-os garanciát adni csúcssebességű foglalásnál Nagy kihasználtság nem csúcssebességű foglalásnál, ha pontosak a forgalomleírók Adásszünet alatt sem veszik el a foglaltság, nagyobb garancia lehet, mint MBAC-nál Egyszerű lehet a foglaltságok processzálása (pl. összeg) 18 6
Foglalás alapú erőforrás-kezelés 2 Hátrányok: Általában nincsenek pontos forgalomleírók, ráadásul nem tudjuk előre (vagy külön shaping eljárás kell), így nem biztos, hogy elég hatékony az adott formula, és nem nyújt 100% garanciát sem Csúcssebességű foglalás kis kihasználtságot eredményez VBR forgalomnál 19 Foglalás alapú erőforrás-kezelés 3 Hátrányok (folyt.): Bonyolultabb probing, mert foglalási adminisztrációt is igényel Állapotok miatt nagyobb memóriaigény (változók tárolása) Foglalás megszüntetéséről külön gondoskodni kell folyam megszűnésekor Explicit release / tear-down Soft-state (foglalás frissítés) Vegyes (RMD és RSVP is) 20 Foglalás alapú erőforrás-kezelés 4 Hátrányok (folyt.) Elosztott (hop-by-hop) esetben ráadásul a félig lefoglalt útvonalakkal is törődni kell elutasítás esetén Partial release Nagyobb signalling overhead, mint MBAC-nál (refresh és release) 21 7
Soft-states 1 A folyam beengedésekor ugyan eltároljuk a foglalást, azonban elvárjuk, hogy valamilyen módon frissítse foglalását, különben egy bizonyos idő után úgy tekintjük, hogy a folyam megszűnt Előny: Megszűnik a foglalás, ha a hívás távozik Visszautasítható hibakezeléskor 22 Soft-states 2 Hátrány: Ha a folyam nem sokkal az utolsó frissítés után távozik, egy teljes frissítési intervallumig bent maradhat a foglalása feleslegesen Megoldások: Minden adatcsomag frissít (csak folyamszintű állapotok esetén) Speciális frissítő csomagok használata 23 Explicit Release Külön bontó csomaggal történő felszabadítás Előny: A foglalás pontosan addig él, amíg a folyam akarja Hátrány: Hibásan megszűnő folyamok esetleg nem küldenek bontó csomagot, így foglalásuk örökre megmarad 24 8
Soft-state és Explicit Release Frissítést is elvárjuk, de lehet explicit bontó csomaggal is megszüntetni a lefoglaltságokat Előny: Hibás folyamok kezelése megvalósul Nincs bent felesleges foglalás semmikor Hátrány: Legnagyobb jelzési többletforgalom 25 Foglalás és mérés együtt Hibrid megoldások Valamilyen forgalom-leírókat jelez és tárol Méréseket is végez A kettőt együtt használja egy formulán keresztül beengedési döntés meghozatalára VBR-re lehet nagyon jó Jó kihasználtság, miközben korlátozható a QoS violation aránya is 26 Tárolt információk Az, hogy milyen információt kell tárolni és terjeszteni, csak a hívásengedélyezési algoritmus függvénye. A protokollnak ezt kell támogatnia. Pl. mérés alapú megoldásnál az előző ciklus végén számolt átlagot Pl. foglalás alapúnál: csak az igényelt sávszélességek összegét, stb. 27 9
Granularitás Állapotok nyilvántartása folyamonként Mérések, forgalomleírók, bejövő és kimenő portok, időzítők, stb. folyamonként Aggregált állapotok Folyamcsoportonként tárolt állapotok Topológia-függő folyamcsoportosítás Topológia-független csoportosítás Pl. DiffServ-konform megoldások, forgalmi osztályok 28 lab Terhelésmegosztási módszerek Távközlési és Médiainformatikai Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem Terhelésmegosztás szükségessége A hálózatban jelentkező forgalmi igények nem homogének, és időben is változnak A hálózatnak kiépítése során számos feltételnek kell megfelelnie, ezért nem teljesen az ismert igényekhez igazodnak a linkek, illetve ezek kapacitásai 30 10
Terhelésmegosztás szükségessége 2 A következmény: Működés során lesznek jobban és kevésbe terhelt részei a kommunikációs hálózatnak Az erősen terhelt linkek torlódáshoz vezethetnek szolgáltatás minőségének romlásával jár új kapcsolatok blokkolásához vezethet 31 Terhelésmegosztás szükségessége 3 A megoldást a terhelés megfelelő kiegyenlítése, megosztása jelentheti Mára a terheléskiegyenlítés a forgalommenedzsment fogalomkörébe került, sokszor a kettőt nem is választják el egymástól 32 Terhelésmegosztás Fontos követelmények: Stabilitás Útvonal integritás (különböző súllyal számít, nincs egyetértés) Alternatív útvonalak szükségesek Megfelelő architektúrális és/vagy protokoll támogatás szükséges lehet kifinomultabb megoldásokhoz 33 11
Követelmények: Stabilitás Terhelésmegosztás is kétfajta lehet: Statikus Előre drótozott A gyakorlatban egyszerűsége miatt a gerinchálózatokban néha alkalmazzák. Tipikusan tervezéskor már van elképzelés az ilyen megoldásokra. Pl.: Két útvonal 50-50%-os megosztással. Ezzel a továbbiakban nem foglalkozunk. 34 Követelmények: Stabilitás Dinamikus Az aktuális igényekhez adaptálódó Itt jelent gondot a stabilitás. El kell kerülni, hogy a rendszer a terhelést ide-oda pakolgassa. Egy egyszerű mohó példa: mindig a legkevésbé terhelt link felé terelek mindent. Így egyszer az egyik egyszer a másik útvonalon halad a forgalom. Ez teljesítmény csökkenéshez vezethet! 35 Követelmények: Útvonal integritás Fontos elvárás, hogy az alkalmazott megoldás az egyes folyamok útvonalát lehetőleg ne módosítsa. Ez azért fontos, mert más útvonalra terelve a csomagok más késleltetést és jittert szenvednek el, ezért átsorrendeződhetnek. Ez a TCP protokollt visszaszabályozásra kényszerítheti. A jövőben pedig az erőforrást használó alkalmazásoknak jelenthet gondot, ha az útvonal váltás miatt új foglalást kell kezdeményezniük. 36 12
Alternatív útvonalak Csak egyforma hosszú út lehet alternatív Ilyenek az SPF-en alapuló megoldások Tetszőleges hopszámú út választható MPLS LSP-k erre adnak lehetőséget Általános követelmény: loop-mentes megoldás 37 A terhelésmegosztás célja Átbocsátóképesség növelése De más is lehet: hibatűrés, hiszen kevésbé terhelt linkek esetén egy linkhiba kevesebb folyamot érint, és az alternatív útvonalak miatt viszonylag egyszerű a gyors hibajavítás 38 A terhelésmegosztás célja A lényeg az alkalmazott algoritmusban van, mely a forgalom igényeket valamilyen szempont szerint szétosztja Ilyen szempont lehet: Maximális linkterhelés legyen minimális Átlagos linkterhelés legyen minimális Maximalizáljuk a jövőben beérkező igények bejutását Minden igénynek tartsunk fent alternatív kapacitást is hibázás esetére stb 39 13
Megoldások Három fő irányvonal Meglévő architektúrák módosítása nélkül OSPF metrikákon alapuló módszerek Új architektúra bevezetésével OMP (Optimized Multi-Path) Hot topic: MPLS-TE 40 Meglévő architektúrák módosítása nélkül Egy fontos kutatási terület, olyan terhelésmegosztó módszerek kifejlesztése, melyek nem kívánnak új protokollokat sem architektúrális módosításokat. E megoldások az OSPF link súlyait állítják úgy, hogy a Shortes Path Routing segítségével azonos súlyú útvonalak alakuljanak ki, melyek között egyszerű azonos felosztású terhelésmegosztást valósítanak meg. 41 Meglévő architektúrák módosítása nélkül A súlyok számításához egy lineáris programot kell megoldani Sokáig limitáció volt, hogy csak egyenlő mértékben lehetett a terhelést megosztani az egyenlő hosszú utak között, de már kidolgoztak egy megoldást mely lehetővé teszi a továbbító tábla megfelelő konfigurálásával a tetszőleges arányú terhelés szétterjesztést 42 14
Meglévő architektúrák módosítása nélkül E módszer tipikusan csomagok szintjen végez terhelésmegosztást, ezért itt nem foglalkoznak az útvonal integritás betartásával. Ez bizonyos alkalmazásoknál hátrány lehet. Megjegyzés: ma megoszlanak a vélemények az útvonal megőrzésének fontosságáról, itt ezt nem tekintik fő szempontnak 43 Új architektúra bevezetésével Egyik legelső dinamikus terhelésmegosztó módszer volt az OMP Optimised Multi-Path megoldás. Minden csomaghoz az fejléce alapján egy véletlen számot számoltak, úgy hogy egy folyam csomagjaihoz mindig ugyan azt a számot kapták, majd ez alapján az egyes útvonalakhoz rendelt valószínűségeket figyelembe véve továbbították a csomagokat. 44 Új architektúra bevezetésével Az OMP megoldása is tipikusan csomagszintű, azt OSPF hálózatokban, tehát itt sem biztosított az útvonal megtartása 45 15