A tantárgy vezérgondolatai. Az IP kezdeti vezérelvei. A TE céljai

Átírás

1 A tantárgy vezérgondolatai Mai elektronikus kommunikáció folyamata IP hálózat forgalmi tervezése I. Csákány Éva és Konkoly Lászlóné cikke alapján Takács György 5. Előadás Csak szolgáltatást lehet eladni Nincs elektronikus kommunikációs szolgáltatás hálózat nélkül Egy hidat nem annak alapján lehet tervezni, hogy korábban ott hányan úszták át a folyót Hálózat boltban nem vásárolható, azt tervezni, megvalósítani, működtetni, fejleszteni, lebontani kell olyan, mint egy ember. Forgalom igény Műszaki Projekt tervek döntés Koncepció váltás Új igény Megvalósulás és üzemelés Pénzbefektetés Elektronikus kommunikációs szolgáltatás Nyereség Minőségi IP hálózatok az IP hálózatok felhasználói egyre inkább igénylik az elvárt minőséget garantáló szolgáltatásokat az értéknövelt szolgáltatásokért hajlandók többet fizetni a szolgáltató a forgalom osztályozásával és az erőforrások alkalmas kiosztásával biztosíthatja a differenciálást az egyes szolgáltatásokhoz tartozó tarifák között is különbséget tud tenni Az IP kezdeti vezérelvei Túlélőképes hálózati architektúra, Best effort minőség, Csomagvesztés, csomagkésleltetés, késleltetésingadozás (dzsitter), throughput nem garantálható, Igényes cégek megoldásai kezdetben ATM PVC (virtual channel) bérlés STM-1-STM-64 bérlés Mivel garantált minőséget így biztosíthattak maguknak pl. HTTP esetén gyors válaszidőt (meghatározza a thorughput és a weboldal mérete) vagy VoIP-nél kis késleltetést (max 150 ms és max 35 ms dzsitter) Korszerű megoldások nyilvános szolgáltatóktól Virtuális magánhálózati szolgáltatás (VPN) Nem kell a cégeknek saját hálózatot építeni IP adatforgalom, beszédforgalom valós idejű adatforgalom ugyanazon hálózaton, Best effort nem alkalmazható, Internet Traffic Engeneering (TE) a megoldás Ez hálózattervezési kérdés. 7 A TE céljai Egy működő IP hálózat teljesítőképességének növelése, Elérhető forgalom alapú megközelítéssel (csomagvesztés, csomagkésleltetés, késleltetésingadozás, throughput biztosításával és garantálásával) is. Elérhető erőforrás alapú megközelítéssel, azaz a hálózati terhelés minél egyenletesebb megvalósításával is. A megfelelő helyreállási idő biztosítása (lehet osztályonként különböző is). Torlódások bekövetkezésének és hatásának minimalizálása. 8 Példa torlódás menedzselési elvekre Csomagszintű eljárások osztályozás, mérés, kondicionálás sor menedzselés Útvonal menedzselés OSPF metrika állítása MPLS Traffic Engineering Hálózatfejlesztés Kapacitástervezés (link bővítés, új csomópontok bekapcsolása) Technológia fejlesztés Rövid válaszidő Közepes válaszidő Hosszú válaszidő (microsec, msec) (napok, órák) (hetek,hónapok évek) 9

2 A jövő forgalma csak bizonytalan becsléssel Közepes és rövid idejű torlódás menedzselés aktuális terhelésnél kompenzálhatja a tervezési bizonytalanságot A torlódás menedzselés lehet megelőző vagy követő TE fázisai A hálózat működését befolyásoló vezérlési szabályok meghatározása A működő hálózat működési adatainak összegyűjtése (link, CPU kihasználtsága) A hálózat teljesítőképességének kiértékelése analitikus vagy szimulációs eszközökkel ehhez kell egy hálózati modell, amely a működő hálózat absztrakt mása. A hálózat teljesítőképességének optimalizálása, a megoldás kiválasztása, amely alapján megtörténnek a beavatkozások. (Beavatkozás a hálózatba beengedett forgalom szabályozása, a forgalom elosztása az erőforrások között, új kapacitások létesítése) TE megvalósításához szükségesek Mérőrendszer Modellező, analizáló, szimuláló rendszer (pl. a Magyar Telekom által használt OPNET) Optimalizáló rendszer TE vezérlő rendszer QoS és MPLS - a gazdaságos minőségi IP szolgáltatás építőkövei Az IETF két QoS architektúrát szabványosított (IntServ és DiffServ) az IP QoS megvalósítására skálázhatósági okok miatt - szolgáltatói IP hálózatban a DiffServ alkalmazható A DiffServ architektúra lehetővé teszi, hogy a forgalmat osztályokba soroljuk, és hogy az egyes csomópontokban a különböző osztályok a nekik megfelelő kiszolgálást kapják. Az MPLS Traffic Engineering lehetővé teszi, hogy a forgalmat egyenletesebben osszuk el a rendelkezésre álló linkeken, mint hagyományos IGP (Interior Gateway Protocol) Az MPLS előre definiált védelmi útvonalak kialakításának biztosításával megoldásokat nyújt a hiba esetén történő gyors helyreállításra IP hálózatok QoS képességei a szolgáltatások szétválaszthatók dedikált (lefoglalt) sávszélesség nyújtásán keresztül vagy prioritás beállításával kontrollálható, hogy az egyes forgalom típusok a hálózati erőforrásait milyen mértékben használják testre szabott szolgáltatások nyújthatók a felhasználók igényének és pénzének megfelelően a felhasználó és a szolgáltató közötti SLA (Service Level Agreement) szerződés-en keresztül kézben tarthatóvá válnak a veszteségi és várakozási jellemzők a real time és interaktív forgalomra úgy, hogy a többi forgalom is elfogadható minőségben bonyolítható le Az Intserv architectúra az adatok küldésének megkezdése előtt az alkalmazás kéri az általa igényelt minőségű szolgáltatást a hálózattól az RSVP (Resource Reservation Protocol) protokolt használják az alkalmazások QoS igényeik jelzésére A kérést egy explicit jelzés valósítja meg az alkalmazás által küldött információk (forgalmi profil, az igényelt sávszélesség, késleltetési és veszteségi követelmények) alapján Az adat csak akkor küldhető, ha a hálózat megerősítette a kérést A hálózat elvárása, hogy a küldött adat a bejelentett forgalmi profilnak megfeleljen A módszert szolgáltatói hálózatban általában nem alkalmazzák DiffServ architektúra DiffServ architektúránál a szállítás nem jelzés alapján, hanem a csomagban lévő információ alapján történik Ez a modell aggregát forgalom folyamokat kezel, ezért szolgáltatói hálózatban is alkalmazható A DiffServ egy előre tervezhető QoS megoldás, ahol a hálózat rúterei előre fel vannak készítve különböző követelményeket igénylő forgalom osztályok kezelésére A forgalmi osztályokat képező aggregátok a csomagok fejlécében lévő DSCP (DiffServ Code Point) mezőben tartalmazzák az igényelt QoS-re vonatkozó információt a csomagok ennek megfelelően kerülnek kiszolgálásra a rúterek interfészein

3 DiffServ funkciók a hálózat rútereiben Osztályozás, mérés, megjelölés, eldobás, formázás, beengedés vezérlés Edge rúter Diffserv tartomány Core rúter VoIP ADAT VoIP ADAT Best- Effort Best- Effort Sorbaállítás Kiszolgálás ütemezése Torlódás menedzselése 19 A DiffServ tartományba belépő csomagokat a hálózat szélén lévő (edge) rúterek osztályozzák Az osztályozás az IP fejrész alábbi mezőin alapulhat: forrás és cél IP címe, szállítási réteg protokoll, alkalmazás port számok, a beérkezés interfésze, fizikai (MAC) cím, IP Precedencia mező, előző DSCP érték, 2. rétegbeli információk Az osztályozás után kerül sor az edge rúterekben a csomagok megjelölésére, vagyis a TOS (Type of Service) byte funkcióját módosító DSCP kód megadására Ezek alapján kerül sor a BA (Behaviour Aggregate) folyamok meghatározására, amelyekhez hozzárendelésre kerülnek azok a szabályok, amelyek szerint a rúterek majd ütemezik, sorba állítják, formázzák, ha kell, eldobálják az egyes BA-k szerinti csomagokat. 20 A BA szabályokat a PHB (Per-Hop Behaviour) alapján különböztetik meg egymástól. A leggyakrabban használt 3 PHB a Best Effort forgalomra vonatkozó Default PHB, az azonnali kiszolgálásban részesülő EF (Expedited Forwarding) PHB és a biztos továbbítású AF (Assured Forwarding). Az AF-nál 4 osztályt (AF1, AF2, AF3, AF4) definiáltak, az egyes osztályokon belül pedig az eldobásra vonatkozóan 3 precedencia érték is megadható. az edge rúterek végzik a forgalom kondícionálását, amely a forgalom mérését, formázását (shaping), az SLA-val nem konform csomagok eldobását (policing) vagy megjelölését jelenti. az edge rúterekben kerül sor a forgalom beengedésének vezérlésére is, melynek során bizonyos forgalom folyamok nem kerülnek beengedésre, nehogy lerontsák a már bentlévők kiszolgálásának minőségét. 21 A hálózat core rúterei felelősek a torlódás elkerüléséért, és a torlódásos szituációk kezeléséért, miközben teljesítik a PHB-ra vonatkozó előírásokat. A különböző sorokba beállított csomagok kiszolgálásának ütemezésére többféle eljárás alkalmazható: a prioritásos (Priority Queueing) és az osztályok szerint súlyozott (Class-Based Weighted Fair Queueing) kiszolgálás. Az prioritásosnál mindig a legnagyobb prioritású sor kerül kiszolgálásra, és csak ha az üres, akkor kerül sor a nála alacsonyabb prioritású sorra. Az osztályonként súlyozott kiszolgálás lehetővé teszi, hogy a sorokhoz súlyokat rendeljünk, amelyek arányában kapják az egyes osztályok a sávszélességet. A beszéd forgalomnak célszerű abszolút prioritást adni, míg a többi forgalomosztály között célszerű súlyozva megosztani a maradék kapacitást. 22 A QoS követelmények teljesítésére egyik lehetőség a hálózat linkjeinek túlméretezése és így javítható a szolgáltatások minősége. A kapacitás növelése csökkenti a veszteséget és a késleltetést, ha a forgalom a kapacitás növelésével nem nő meg arányosan. Előfordulhat ugyanis, hogy bizonyos linkeken a hálózat más pontjain lévő szűk keresztmetszetek miatt (pl. TCP forgalom szabályozó képessége következtében) a forgalom korlátozva van. Egy szűk keresztmetszet kapacitásának bővítése azonnal maga után vonhatja a forgalom növekedését más linkeken is. A linkek az idő nagy részében kihasználatlanok lesznek (v.ö. Korlátlan és ingyenes sávszélesség!) A túlméretezés nem nyújt lehetőséget a garantált szolgáltatás nyújtására, csupán egy, a korábbinál átlagosan jobb szolgáltatást lehet elérni vele 23 A QoS követelmények teljesítésére másik lehetőség az, amikor a minőségi szolgáltatások igényéhez igazodóan, a szolgáltatások közti differenciálást biztosító jóval kifinomultabb technikákat és ezeknek megfelelő árazást alkalmazunk. A sokkal szigorúbb QoS persze szintén pénzbe kerül. S hogy mennyibe, az itt is a már fent felsorolt tényezőknek a függvénye. Ebben az esetben azonban garantált minőséget lehet biztosítani, pontosan megfelelve a szolgáltatói szerződésben foglaltaknak. Ebben az esetben a jobb minőséget nem az erőforrások túlméretezésével, hanem azok alkalmas kiosztásával érjük el, amelynek megtervezése a TE folyamat egyik eredménye. 24 MPLS Traffic Engineering Az MPLS Traffic Engineering (MPLS TE) alkalmazása lehetővé teszi a forgalom egyenletes elosztását a hálózati linkeken, valamint olyan védelmi lehetőségeket nyújt, amelyek hiba esetén gyorsabb helyreállítást biztosítanak, mint a hagyományos IP rerouting. Az MPLS protokoll IP hálózatokban való alkalmazásának két fő motiváló tényezője az MPLS alapú VPN szolgáltatás lehetősége és az MPLS TE képességei. Az MPLS TE alkalmazása önmagában nem alkalmas különböző forgalom osztályok számára előírt minőség biztosítására, de az explicit útvonalak megadásának lehetősége által megvalósítható, hogy a forgalom egyenletesebben foglalja el a rendelkezésre álló erőforrásokat, és ezáltal csökkenjen a torlódás valószínűsége, tehát jobb minőségű szolgáltatást lehessen nyújtani. Az explicit útvonal (az MPLS belépési pontján a teljes átviteli út ismert) felépülhet a két szabványosított jelzési protokoll, a CR- LDP és a TE-RSVP valamelyike által 25 DiffServ mellett működő MPLS Traffic Engineering A 3270 RFC-ben került leírásra az MPLS TE és a DiffServ együttműködése A DiffServ rúterek az IP csomag DSCP bitjei alapján döntenek arról, hogy melyik kiszolgálási sorba teszik be az adott csomagot, azaz milyen PHB-t biztosítanak számára Az MPLS rúterek a csomagok továbbítása során nem vizsgálják az IP fejrészt, ezért szükséges a DSCP bitek leképezése úgy, hogy az MPLS rúterek által is vizsgálható legyen 26 DiffServ-aware MPLS Traffic Engineering hálózati nódok interfészein egységes sorakoztatási szabályokat állítanak be, és az útvonal-választást végző algoritmus biztosítja, hogy az interfészre csak a beállított kiszolgálási szabályoknak megfelelő mennyiségű forgalom kerüljön, a rúterek kiszolgálási osztályonként tartják nyilván az egyes interfészeken rendelkezésre álló szabad kapacitást, ezt az információt terjesztik a hálózatban 27

4 SPGuru-val végzett szimulációs 1. mintafeladat Egy adott linken (34 Mbps) az MRTG mérés által szolgáltatott adatok mellett megvizsgáltuk, hogy a link terhelésének növelése milyen hatással lenne az ezen a linken áthaladó beszédforgalom késleltetési jellemzőire. Azaz, a forgalom milyen %-os növekedése mellett teljesülne még a beszédcsomagokra előírt szolgáltatási minőség. Erre a feladatra az SPGURU egy speciális modulja, az ESP (Expert Service Prediction) modul használható. A beszédforgalom minőségére az alábbi 2 kvantitatív SLA-t definiáltuk: A késleltetés legyen kevesebb, mint 10 msec a csomagok több, mint 90%-a esetén A késleltetés ingadozása legyen kevesebb, mint 1 msec a csomagok több, mint 90%-a esetén a háttérforgalmat 2 szakaszban (negyedévenként) az eredeti forgalomhoz képest 30 illetve 60%-kal növeltük. a háttérforgalmat 2 szakaszban (negyedévenként) az eredeti forgalomhoz képest 30 illetve 60%-kal növeltük SPGuru-val végzett 2. szimulációs mintafeladat Beszédátvitelre vonatkozó késleltetés és dzsitter értékek hogyan változnak egy hálózatban az alábbiak függvényében: hop számtól függően a hálózat többi forgalmának típusától függően a hálózat terhelésétől a hang forgalomra alkalmazott sorakoztatási, ütemezési eljárástól a vizsgálathoz használt hálózat 5 rúterből és a hozzájuk kapcsolódó LAN-okból áll A forgalmakat az (S_1, S_2,...,S_11) nevű LAN-okból indítottuk, és az egy adott LAN-ból induló forgalmak egy meghatározott LAN-ban (D_1, D_2,,D_11) végződtek. A forgalmi viszonylatokat úgy alakítottuk ki, hogy a rúterek közötti 4Mbps-os linkeken azonos terhelés alakuljon ki, és csak ezek legyenek szűk keresztmetszetek a hálózatban. Így pl. az S_1 LAN-ból induló forgalom 5 hop-on keresztül jutott el a D_1 LANba, az S_2 LAN-ból induló forgalom 4 hop-on keresztül a D_6 LAN-ba stb szcenárió: csak beszédforgalommal terheltük a hálózatot. Minden egyes LAN-ból 5, 10, 13 és 15 beszélgetésnek megfelelő forgalmat indítottunk a hozzá definiált LAN végződéshez. Az eredmények azt mutatták, hogy a beszédforgalomra elvárt késleltetési paraméterek függnek a hop számtól és a terheléstől, de a 15 beszéd/lan esetén romlanak el először. Ekkor a hálózat 4Mbps-os linkjei kb. 80%-ig terheltek, és ez a forgalom 75 db egyidejű beszélgetésnek felelt meg. Az elfogadható vég-vég késleltetés a beszéd esetén 150 msec, ennek nagy része azonban nem a rúterek interfészén, hanem a be- és kicsomagoláskor, a fejrész kompresszáláskor, a hívott oldalon történő dzsitter eltávolításkor keletkezik, ezért mi a a vizsgálatban a 10 msec alatti értéket tekintettük elfogadhatónak A késleltetés változása az 5, 10, 13 és 15 beszéd/lan esetekben A linkterhelés változása az 5, 10, 13 és 15 beszéd/lan esetekben

5 Csomagvesztés a 15 beszélgetés/lan esetében Csomagkésleltetés a hop-szám függvényében 2. szcenárió: Ebben a vizsgálatban LAN-onként csupán 5 db beszélgetésnek megfelelő forgalmat indítottunk, és e mellé web oldalak letöltésére irányuló (web-browsing alkalmazás) forgalmat tettünk. LAN-onként 700 db web klienst definiáltunk, akik (exponenciális eloszlás szerint) átlagosan 1 percenként töltöttek le egy-egy (exponenciális eloszlás szerint) átlagosan 5Kbyte-os méretű oldalt. Két esetet vizsgáltunk, az egyikben a rúterek interfészein a kétféle forgalomhoz közös FIFO sorokat alkalmaztunk, míg a másik esetben a beszéd forgalmat egy prioritásos sorból szolgáltuk ki Késleltetés változása QoS alkalmazása esetén Dzsitter változása QoS alkalmazása esetén 3.szcenárió: Ebben a feladatban azt vizsgáltuk, milyen hatása van a hálózat többi forgalmának a beszéd- forgalom késleltetésének alakulására. Ennek érdekében összehasonlítottuk az 1.szcenárió-beli 13 beszélgetés/lan modellünk eredményét egy olyan modell eredményeivel, ahol LAN-onként 1 db beszélgetés mellett 700 db web kliens forgalmát vittük át a hálózatban. A web forgalomhoz tartozó cél LAN-ok megegyeztek az adott LAN-ból kiinduló beszédforgalom cél LAN-jaival A háttérforgalom típusának (beszéd, web) hatása a beszéd késleltetésre - késleltetés A háttérforgalom típusának (beszéd, web) hatása a beszéd késleltetésre -linkterhelés Tanulság Hálózattervezés és hálózatmenedzsment összenőttek!