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

Az előadások a következő témára: "1 IP alapú hálózatok tervezése és üzemeltetése II. 15/7."— Előadás másolata:

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

2 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 3 Az előadás tartalma QoS Intserv Diffserv RSVP

4 IP alapú hálózatok tervezése és üzemeltetése II. 4 Források http://www.cs.huji.ac.il/course/2005/com1/Pres entations/Lessons/qos.pdf http://www.cs.huji.ac.il/course/2005/com1/Pres entations/Lessons/qos.pdf http://www.cs.cmu.edu/afs/cs/academic/class/1 5441f01/www/lectures/lecture22.ppt http://www.cs.cmu.edu/afs/cs/academic/class/1 5441f01/www/lectures/lecture22.ppt

5 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 7 A QOS javítása IP hálózatokban IETF csoportok dolgoznak néhány javaslaton a jobb QOS vezérlés érdekében az IP hálózatokon RSVP, Differentiated Services, és Integrated Services.

8 IP alapú hálózatok tervezése és üzemeltetése II. 8 Áttekintés A QoS alapjai Integrated Services (Intserv) Differentiated Services (Diffserv) Resource ReSerVation Protocol (RSVP)

9 IP alapú hálózatok tervezése és üzemeltetése II. 9 A QOS garanciák szabályai Egyszerű modell a torlódás tanulmányozására (“Súlyzó Topológia”):

10 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 14 Összefoglaló

15 IP alapú hálózatok tervezése és üzemeltetése II. 15 Internet QoS rövid története Komoly kutatás a 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 IP alapú hálózatok tervezése és üzemeltetése II. 16 Csomag időzítés Fifo Prioritásos Round Robin Súlyozott Round Robin

17 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 18 Szabály mechanizmusok Token Bucket: Burst Size,Average Rate. A kosár b zsetont tartalmaz r token/sec sebességgel gyártódnak amíg tele nem lesz a kosár

19 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 25 Intserv: QoS 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) request/ reply

26 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 38 Reservation Protocol: RSVP Upper layer protocols and applications IP Link layer modules ICMPIGMPRSVP IP service interface Link layer service interface

39 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 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 IP alapú hálózatok tervezése és üzemeltetése II. 43 Az előadás tartalma QoS Intserv Diffserv RSVP

44 IP alapú hálózatok tervezése és üzemeltetése II. 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