Ideális átbocsátás. Tényleges átbocsátás. Késleltetés Holtpont. Terhelés

lab

IP ALAPÚ TÁVKÖZLÉS

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

TMIT BME


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

TMIT BME


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

TMIT BME


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 Áramkör felépítése

Datagram alapú hálózat

Kötelező

Nem szükséges

Címzés

Minden csomag áramköri azonosítót tartalmaz

Minden csomagban a teljes forrás- és célcím

Állapotinformáció

Virtuális áramköri táblázat

Nincs

Forgalomirányítás

Minden csomag azonos útvonalon

Minden csomag függetlenül

Torlódásvédelem

Könnyű – virtuális áramkörök puffereltek

Bonyolult

4

lab


Torlódásvédelmi módszerek


TMIT BME


Torlódás Ideális átbocsátás Tényleges átbocsátás Késleltetés Holtpont Terhelés 6

2

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


Központosított erőforrás-kezelés - példa

Ké ré s

Bandwidth Broker 1

(inter-domain) kommunikáció

Bandwidth Broker 2 Tartományon belüli (intra-domain) kommunikáció

Tartományon belüli (intra-domain) kommunikáció

Határcsomópont

'A' Felhasználó

Tartományok közti

T A R T O M Á N Y

Határcsomópont

Határcsomópont

T A R T O M Á N Y

Határcsomópont

'B' Felhasználó

12

4

TMIT BME


Központosított erőforrás-kezelés - példa

Szomszédos tartomány

Szomszédos tartomány Inter-domain interfész

Alkalmazások és hosztok Felhasználói interfész

BB szerver

Adatbázis

Adatbázis interfész

Hálózatok Intra-domain interfész Határcsomópontok és belsõ csomópontok

Határcsomópontok és belsõ csomópontok 13

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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


TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


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

TMIT BME


Ú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

TMIT BME


Ú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

Ideális átbocsátás. Tényleges átbocsátás. Késleltetés Holtpont. Terhelés

Recommend Documents