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

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

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/Pres

entations/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éstAlkalmazkodnak 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 a jobb 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á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ódottA 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 mechanizmusokCé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 mechanizmusokToken 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


IETF Intserv per-flow/ folyam alapú QoS.

Specifikus alkalmazásokat támogat: videó folyam

Matematikai garanciákon alapul Problémák:

KomplexitásSkálázhatóságÜzleti modellDí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ésHogyan elégíti ki a hálózat az igényeket?

A garancia biztosításaHogyan 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-selBest effortPrediktív vagy differenciált szolgáltatásSzigorú garanciák (real-time)

A szolgáltatások halmaza melyet egy hálózat támogat a szolgáltatás modellModell 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


Intserv: QoS Erőforrás lefoglalásHívás felépítés, jelzés (RSVP) forgalom, QoS deklaráláselemenkénti engedélyezés

QoS-sensitive scheduling (e.g., WFQ)

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ólClass 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éstLehetsé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

pufferekkelRelatív szolgáltatások definiálására (gold,…)Minden szolgáltatáson belül 3 eldobó prioritásHogyan 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

csatornaGarantált sávszélesség a két pont közöttAlacsony 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

Link layer modules

ICMP IGMP RSVP

IP service interface

Link layer service interface

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

ip alapú hálózatok tervezése és üzemeltetése ii

Documents