IP alapú hálózatok tervezése és üzemeltetése II.

1. IP alapú hálózatok tervezése és üzemeltetése II. 15/7

2. Az előző előadás tartalma • ISDN • ISDN bemutatása • ISDN szabványok és hozzáférési módok • ISDN 3-layer modell és protokollok • ISDN funkciók • ISDN referencia pontok • ISDN kapcsoló típusok • ISDN DDR • xDSL • Problémák az előfizetői hurokkal • Teljesítmény sűrűség spektrum • HDSL • SDSL • IDSL • ADSL • RADSL • VDSL

3. Az előadás tartalma • QoS • Intserv • Diffserv • RSVP

4. Források • http://www.cs.huji.ac.il/course/2005/com1/Presentations/Lessons/qos.pdf • http://www.cs.cmu.edu/afs/cs/academic/class/15441f01/www/lectures/lecture22.ppt

5. Motiváció • Az Internet jelenleg csak egy szolgáltatás osztályt támogat: “best-effort” szolgáltatás. • Nincs belépés korlátozás és biztosíték sem a kézbesítésre • A jelenlegi alkalmazások elasztikusak. • Tolerálják a csomagvesztést és késleltetést • Alkalmazkodnak a torlódásokhoz • A jövőbeli (Jelenbeli) valós idejű alkalmazások nem lesznek elasztikusak • Mit módosítsunk az alkalmazásokat vagy az Internetet?

6. Alkalmazás típusok • Elasztikus alkalmazások • Gyorsabb-jobb de elviselik a rossz körülményeket is • Pl.: FTP • Folyamatos média alkalmazások • Alsó és felső korlát az elfogadható teljesítményre • Időnként tudnak alkalmazkodni a megváltozó körülményekhez ”tolerant real time” • Pl.: a videó keret sebesség változtatásával • “Network-aware” alkalmazások • Szigorúan valós idejű alkalmazások • Szigorú követelmények – “intolerant real-time” • Pl.: vezérlő alkalmazások

7. A QOS javítása IP hálózatokban • IETF csoportok dolgoznak néhány javaslaton ajobb QOS vezérlés érdekében az IP hálózatokon • RSVP, Differentiated Services, és Integrated Services.

8. Áttekintés • A QoS alapjai • Integrated Services (Intserv) • Differentiated Services (Diffserv) • Resource ReSerVation Protocol (RSVP)

9. A QOS garanciák szabályai • Egyszerű modell a torlódás tanulmányozására (“Súlyzó Topológia”):

10. A QOS garanciák szabályai • Telefon alkalmazás 1Mbps és egy FTP alkalmazás osztozik a 1.5 Mbps vonalon. • Az FTP burst-ök torlódásokat okozhatnak, az audió csomagokat eldobhatja a forgalomirányító • Az audió-nak szeretnénk prioritást adni az FTP-vel szemben. • Első szabály: A csomagok megjelölése és egy forgalomirányító oldali szabály kell a különböző csomagok különböző kezeléséhez

11. A QOS garanciák szabályai • Helytelenül viselkedő alkalmazás (az audio nagyobb sebességgel küldi a csomagokat mint 1Mbps). • Második szabály: biztosítsunk védelmet az egyes forgalmi osztályoknak egymás ellen (isolation). • Szabály mechanizmusok mellyel biztosítható a források szabálykövető megtartása (sávszélesség); • A széleken kell a jelölésnek és a szabály kényszerítésnek megtörténnie:

12. A QOS garanciák szabályai • A megjelölés és szabály kényszerítés alternatívája: minden alkalmazás folyam részére egy savszélesség rész lesz lefoglalva. Ez nem vezet hatékony sávszélesség kihasználáshoz. • Harmadik szabály: Az izoláció mellett törekedni kell a hatékony erőforrás kihasználásra is.

13. A QOS garanciák szabályai • A fizikai kapacitáson túl nem lehet folyamokat kiszolgálni • Negyedik szabály: Kell egy hívás engedélyező folyamat; az alkalmazás deklarálja az igényeit a hálózat meg megmondja, hogy tudja-e teljesíteni .

14. Összefoglaló

15. Internet QoS rövid története • Komoly kutatása 80-as évek végén és a 90-es évek elején. • Telekommunikációs szemlélet. • ATM QoS és az Integrated szolgáltatások ezen alapultak. • Folyamonkénti, szigorú QoS. • Az utolsó 5 évben a fókusz a Differenciált szolgáltatások irányába tolódott • A fókusz a QoS folyam aggregátumok irányába tolódott. Pl.: egy felhasználó összes folyama

16. Csomag időzítés • Fifo • Prioritásos • Round Robin • Súlyozott Round Robin

17. Szabály mechanizmusok Cél:korlátozzuk a forgalmat, hogy ne haladja meg a definiált paramétereket Három gyakori kritérium: • (Hosszú idejű) Átlagos sebesség:hány csomag küldhető idő egységenként (hosszú idő alatt) • Fontos kérdés: mi az időtartam hossz: 100 csomag 6 másodperc vagy 6000 csomag percenként! • Csúcs sebesség:pl., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate • (Max.) Burst Size: max. csomag szünet nélkül

18. Szabály mechanizmusok Token Bucket: Burst Size,Average Rate. • A kosár b zsetont tartalmaz • r token/secsebességgel gyártódnak amíg tele nem lesz a kosár

19. IETF Intserv • per-flow/ folyam alapú QoS. • Specifikus alkalmazásokat támogat: videó folyam • Matematikai garanciákon alapul • Problémák: • Komplexitás • Skálázhatóság • Üzleti modell • Díj számítás

20. Az Integrált Szolgáltatások elemei • A szolgáltatás modell • Mit igér a hálózat? • Szolgáltatás interfész • Hogyan mondja meg az alkalmazás, hogy mit szeretne? • Csomag ütemezés • Hogyan elégíti ki a hálózat az igényeket? • A garancia biztosítása • Hogyan kommunikálják le az ígéretet? • Hogyan menedzseli az új alkalmazások belépését?

21. Szolgáltatás modell • A hálózat adat folyamokat támogatna különböző QoS-sel • Best effort • Prediktív vagy differenciált szolgáltatás • Szigorú garanciák (real-time) • A szolgáltatások halmaza melyet egy hálózat támogat a szolgáltatás modell • Modell mely segítségével szolgáltatást lehet választani • Pl.: ár/teljesítmény

22. Szolgáltatás modellek • Garantált szolgáltatás • Szigorú valós idejű szolgáltatások • A felhasználó definiálja a forgalom karakterisztikáját és a szolgáltatás igényeket • Minden forgalomirányítónál erőforrás foglalás vezérlés • Matematikailag garantálja a sávszélességet, a késleltetést és a jittert • Kontrolált terhelés. • Az alkalmazások alkalmazkodnak a körülményekhez egy teljesítmény ablakban • A felhasználó definiálja a forgalom karakterisztikáját és a szolgáltatás igényeket • Minden forgalomirányítónál erőforrás foglalás vezérlés • A garancia nem olyan erős mint az előzőben • pl., mérés alapú belépés engedélyezés • Legjobb szándék szerinti

23. Szolgáltatás interfész • A viszonyban definiálni kell a QoS paramétereket és a forgalom karakterisztikáját • R-spec: a QoS igény (pl:sebesség r) • T-spec: az adó forgalom karakterisztikáját specifikálja • Jelzés protokoll szükséges az R és T specifikáció átvitelére: • RSVP

24. Engedélyezés • A forgalomirányítók a T és az R specifikáció alapján eldöntik, hogy tudják-e vállalni az új folyamot

25. Erőforrás lefoglalás Hívás felépítés, jelzés (RSVP) forgalom, QoS deklarálás elemenkénti engedélyezés • QoS-sensitive scheduling (e.g., WFQ) Intserv: QoS request/ reply

26. Differenciált Szolgáltatások • Megpróbálja kiküszöbölni az alábbi hiányosságokat: • Skálázhatóság: nagy sebességű hálózatoknál, nagy mennyiségű folyam esetén a forgalomirányítókon nem nagyon jó állapotot karbantartani • Flexibilis Szerviz Modellek: Az Intserv-nek csak két modellje volt; több relatív osztályt kell definiálni (Platinum, Gold, Silver, …) • Egyszerűbb jelzés: (mint az RSVP) sokan csak egy minőségi jellemzőt szeretnének meghatározni

27. Diffserv - Motiváció • Csak a hálózatok szélein lehet finomhangolni • Lassabb vonalak • Pl.: levél szelektálás a postán • Megjelöli a csomagokat egy mezővel. • Pl.:prioritás bélyeg • A mag hálózat csak a mező alapján határozza meg a QoS paramétereket • Kevés típus, jól definiált viselkedés • Gyorsan kezelhető • Evolution rather than revolution

28. Diffserv • Egy architetúrát definiál és egy halmaz továbbító viselkedést • A szolgáltatókon múlik, hogy hogyan definiálják és implementálják a szolgáltatásokat ezen architektúrán • Sokkal flexibilisebb szolgáltatás modell, különböző szolgáltatók, különböző szolgáltatások • A fő motiváció a Diffserv mögött a skálázhatóság • A gerinc hálózatot egyszerűnek tartja • Folyam aggregátumokat kezel

29. Határ forg. ir. / Host funkciók • Osztályozás: Megjelöli a csomagokat az osztályozási szabályok alapján. • Mérés: megméri, hogy egy adott folyam adott profilba esik-e. • Jelölés: az adott profilba eső folyamot megjelöli. • Kondícionálás: késleleti és ezután továbbítja vagy eldobja vagy átírja a jelölést a forgalmon

30. Osztályozás és kondicionálás • A csomag Type of Service (TOS) mezője IPv4, vagy Traffic Class mezője IPv6. • 6 bit a Differentiated Service Code Point (DSCP) ez eldönti a PHB-t amit a csomag kapni fog • 2 bitet nem használnak

31. Gerinc funkciók • Továbbítás: a “Per-Hop-Behavior” vagy PHB alapján az egyes csomagokat minden ugrásnál a TOS mezők alapján kezelik • ELŐNY: Nincs állapot kezelés a gerinc forgalomirányítókon!

32. Továbbítás (PHB) • PHB több különböző eredményre vezethet. • PHB nem specifikálja a használandó mechanizmust • Példa: • Class A x%-ot kap a kimenő vonalból • Class A csomagok mindég Class B csomagok előtt mennek ki

33. Továbbítás (PHB) • Gyorsított továbbítás Expedited Forwarding (EF): • Garantál egy minimális sebességet az EF forgalomnak • Garantálja az izolációt (az EF forgalmaz nem zavarhatja meg más) • Csúcs sebesség alapján döntik el az engedélyezést • Lehetséges szolgáltatás: virtuális drót

34. Továbbítás (PHB) • Biztos továbbítás, Assured Forwarding (AF): • AF 4 osztályt definiál bizonyos sebességgel és pufferekkel • Relatív szolgáltatások definiálására (gold,…) • Minden szolgáltatáson belül 3 eldobó prioritás • Hogyan hat ez ki a TCP-re? • A nem megfelelő forgalom át lesz osztályozva

35. Virtuális bérelt vonal • A felhasználóknak egy dedikált forgalmi csatorna • Garantált sávszélesség a két pont között • Alacsony késleltetés, jitter. • A belépés vezérlés teszi ezt lehetővé (EF)

36. Differenciált Szolgáltatások kérdések • AF és EF kutatási terület. • Diffserv működéséhez sávszélesség menedzsment kell a gerincen. • Egyszerű az egyszerű szolgáltatásokhoz (EF), de nagyon komplex s lehet (egyezmények) • Sávszélesség bróker • Mit kezdjenek olyan hálózatokkal melyek ezt nem támogatják, máshogyan támogatják

37. Az RSVP szerepe • Az unicast/multicast forgalomirányító protokollok információit használja • Minden résztvevőnél jelen van. • Erőforrás foglalásokat továbbít. • Minden ugrásnál ellenőrzik a teljesíthetőséget, a sikertelen kísérletről értesíti a kezdeményezőt

38. Reservation Protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules

39. RSVP célok • Kapcsolatmentes hálózat: • Nem célja a forgalomirányítás. • Együtt kell élnie az útvonal változásokkal. • Támogatnia kell a multicast-ot. • Különböző vevők különböző kepeségekkel rendelkeznek és más-más QoS-t szeretnének • A csoport tagság változás ne legyen költséges • A foglalások aggregálhatóak • Át tudja adni a foglalásokat más küldőknek • Vezérlés költség csökkentés. • Moduláris felépítés • Eredmény: • Vevő orientált • Soft-state

40. Vevő kezdeményezésű • A vevő kezdeményezi a foglalás a fa mentén • A multicast fa meglétét feltételezi • Az, hogy meddig kell a kérésnek utazni a kérés tartalmától függ • Tulajdonságok: • Jól skálázható: párhuzamos műveletek (csatlakozás/lecsatlakozás). • Heterogén vevő állomány

41. Soft State • A forgalomirányítók ideiglenes állapotot tartanak fenn. • Periodikusan frissíteni kell. • Alternatíva: Hard state • Nincs periodikus frissítés. • Az állapot megmarad. • Expliciten el kell távolítani. • Problémás… • Soft state: • Alkalmazkodik az útvonal változásokhoz • Hibatűrő

42. RSVP Szolgáltatás modell • Minden adatfolyamra külön. • PATH/RESV üzenetek periodikusan. • Egy irány: • Ha nem sikerült akkor hiba üzenet. • Nincs ack üzenet. • Üzenet típusok: • PATH message • T-Spec • RESV message • R-Spec • Szűrő • CONFIRMATION message • Generated only upon request. • Unicast to receiver when RESV reaches node with established state. • TEARDOWN message • ERROR message (if PATH or RESV fails)

43. Az előadás tartalma • QoS • Intserv • Diffserv • RSVP

44. A következő előadás tartalma • VoIP • PSTN alapok • PSTN vs. VoIP • Vállalati telefon rendszer • SSN7 • PSTN szolgáltatások • VoIP technológia • Előnyök, hátrányok • QoS • IP jelzés protokollok • H.323 • SIP • GCP • VSC