Využití mechanismů QoS při poskytování služeb Triple Play

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Využití mechanismů QoS při poskytování služeb Triple Play Bakalářská práce Vedoucí práce: Ing. Petr Zach Miroslav Kleinhampl Brno 2013

2

3 Tímto bych chtěl poděkovat svým kamarádům a rodině, ţe mi byli při psaní této práce oporou. Dále bych rád poděkoval svému vedoucímu, za trpělivost a cenné rady, bez kterých by tato práce nemohla vzniknout.

4

5 Čestné prohlášení Prohlašuji, ţe jsem tuto práci: Vyuţití mechanismů QoS při poskytování sluţeb Triple Play vypracoval samostatně a veškeré pouţité prameny a informace jsou uvedeny v seznamu pouţité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, ţe se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a ţe Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a uţití této práce jako školního díla podle 60 odst. 1 Autorského zákona. Dále se zavazuji, ţe před sepsáním licenční smlouvy o vyuţití díla jinou osobou (subjektem) si vyţádám písemné stanovisko univerzity o tom, ţe předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to aţ do jejich skutečné výše. V Brně dne 1. prosince 2013

6

7 Abstract Kleinhampl M. The use of QoS mechanism in the provisioning of Triple Play. Bachelor thesis. Brno: Mendelu, This thesis is focused on triple play and possibilities of setting with mechanism of QoS. In practice part are checking of possibilities of implementation on laboratory network. Keywords QoS, Triple Play, DiffServ, IntServ. Abstrakt Kleinhampl M. Vyuţití mechanismů QoS při poskytování sluţeb Triple Play. Bakalářská práce. Brno: Mendelu v Brně, Práce je zaměřena na sluţby triple play a moţnosti jejího nastavení pomocí mechanismů QoS. V praktické části jsou ověřovány moţnosti implementace na laboratorní síti. Klíčová slova QoS, Triple Play, DiffServ, IntServ.

8

9 Obsah 9 Obsah 1 Úvod a cíl práce Úvod Cíl práce QoS Historie sítí a vztah ke QoS Parametry QoS Mechanismy QoS Největší úsilí (Best Effort, BE) Integrované sluţby (Integrated Services, IS, IntServ) Diferencované sluţby (Differentiated Services, DS, DiffServ) Triple play Pojem triple play Protokoly Přenos hlasu Přenos videa Přenos dat Parametry QoS na sluţby triple play Obecný postup pro nastavení QoS Moţnosti nastavení Postup nastavení Nasazení a kontrola Praktická část Laboratorní síť Pouţité nástroje Synchronizace času Nastavení laboratorní sítě Metodika měření... 40

10 10 Obsah 6.6 Nastavení QoS Výsledky měření Bez QoS S QoS Ekonomické zhodnocení 52 9 Diskuse a závěr Zhodnocení Závěr Literatura 54 A Topologie 57 B Konfigurace síťových zařízení 58 C Ukázky skriptů 60

11 Seznam obrázků 11 Seznam obrázků Obr. 1 Šířka pásma 17 Obr. 2 Zpoždění 18 Obr. 3 Variace zpoždění 18 Obr. 4 Modely 19 Obr. 5 IntServ 20 Obr. 6 Mechanismy DiffServ 21 Obr. 7 ToS, CT, DSCP pole 22 Obr. 8 Traffic policing a traffic shaping 24 Obr. 9 Priority Queues 26 Obr. 10 Princip LLQ 27 Obr. 11 Mechanismus WRED 28 Obr. 12 RTP hlavička 30 Obr. 13 QoS Baseline 34 Obr. 14 Topologie sítě 36 Obr. 15 Graf rychlostí 37 Obr. 16 VLC a wireshark 38 Obr. 17 Video bez formátu a s MPEG4, SD 43 Obr. 18 Video bez formátu a s MPEG4, HD 44 Obr. 19 Bez QoS, MPEG4, SD 44 Obr. 20 Bez QoS, MPEG4, HD 45 Obr. 21 QoS, 30 %, MPEG4, SD 46 Obr. 22 QoS, 30 %, MPEG4, HD 47

12 12 Seznam obrázků Obr. 23 QoS, 60 %, MPEG4, SD 47 Obr. 24 QoS, 60 %, MPEG4, HD 48 Obr. 25 QoS, 30 %, bez kódování, HD 50 Obr. 26 QoS, 60 %, bez kódování, HD 50

13 Seznam tabulek 13 Seznam tabulek Tab. 1 Tabulka IP precedence, tříd a DSCP kódů 23 Tab. 2 Hodnoty a typické aplikace 23 Tab. 3 Formáty hlasu pro VoIP a MP3 31 Tab. 4 Šířka pásma 31 Tab. 5 Parametry QoS 32 Tab. 6 Nastavení QoS 42 Tab. 7 Bez QoS, MPEG4 45 Tab. 8 QoS, MPEG4, 30 % 48 Tab. 9 QoS, MPEG4, 60 % 49 Tab. 10 QoS, bez kódování 51

14

15 Úvod a cíl práce 15 1 Úvod a cíl práce 1.1 Úvod Všechny pakety mají stejnou šanci na doručení, ale pokud dojde k zahlcení sítě, tak mají i stejnou šanci k zahození. Takovéto sítě nemají ţádné mechanismy, jak zaručit kvalitu jakékoliv uţivatelské sluţby. Ke zvýhodnění více platících zákazníků nebo upřednostnění multimediálních sluţeb před ostatním provozem, je nutné implementovat do sítě další nadstavbové mechanismy. Mezi tyto mechanismy patří zajištění kvality sluţeb (QoS Quality of Service). Pomocí QoS jsou vybrány jednotlivé datové toky a upřednostněny podle jejich důleţitosti před ostatními. 1.2 Cíl práce Cílem této práce je ověření nastavení mechanismů QoS na sluţbách triple play v rámci laboratorní sítě.

16 16 QoS 2 QoS 2.1 Historie sítí a vztah ke QoS Vznik počítačových sítí a Internetu se datuje do poloviny minulého století. Na počátku byla jen myšlenka komunikace na dálku, která by dala americké armádě výhodu v boji proti nepříteli. V dnešní době fungují sítě jiţ nejen ke komunikaci, ale také k zábavě v podobě online her, poslouchání hudby a sledování videa. Původní koncept Internetu i počítačových sítí byl, ţe všechna data posílaná po síti mají stejnou důleţitost a není potřeba některá z nich upřednostňovat před ostatními. Tento koncept není vhodný pro multimediální data a zde přichází Quality of service (QoS), neboli kvalita sluţeb. Některé aplikace potřebují, aby jejich pakety byly doručeny s určitými parametry. Například telefonní hovor přes počítačovou síť vyţaduje co nejmenší zpoţdění, abychom správně porozuměli jejímu obsahu. Toto má za úkol zajistit právě sluţba QoS, která se stará o zajištění parametrů aplikacím, které to potřebují. V počítačových sítích je definován podle Puţmanové (2009), jako souhrnný výsledek výkonosti sluţby, který určuje stupeň spokojenosti uţivatele sluţby. 2.2 Parametry QoS Mezi parametry, podle kterých můţeme určit výkonnost toku paketů, patří: Šířka pásma neboli bandwidth (BW) schopnost sítě přenášet informace za čas. Udává se v bitech za sekundu. Je definována v RFC Podle Hens a Caballero (2008) šířku pásma můţeme chápat jako dvě hodnoty. Propustnost a kapacita. Kapacita udává maximální moţné mnoţství přenosu informace za čas, zatímco propustnost udává aktuální moţné mnoţství přenosu informace za čas. Dále platí, ţe propustnost je rovna násobku celkové kapacity a odečtením vytíţenosti linky od jedné (propustnost = kapacita * (1 - vytížení)). Propustnost a kapacita se definují, jak pro jednu linku, tak pro celou cestu. Na celé cestě je kapacita rovna nejniţší moţné kapacitě linky. Vše názorně popisuje obr. 1, kde R je celková kapacita celé cesty a R1 aţ R4 jsou kapacity jednotlivých linek po cestě.

17 QoS 17 Obr. 1 Šířka pásma Zdroj: Hens a Caballero, 2008 Ztrátovost paketů neboli packet loss udává se v procentech. Specifikováno v RFC A je definována jako poměr počtu úspěšně doručených paketů a počtu celkově vyslaných paketů (Szigeti a Hatting, 2005). Jestliţe je ztrátovost rozloţena po celé vysílání, nemá to velké následky, ale pokud se ztratí pakety následující po sobě, můţe to mít následky v podobě výpadku hovoru nebo filmu. Jednosměrné zpoždění neboli one-way delay udává se v milisekundách. Specifikováno v RFC Puţmanová (2009) ho popisuje jako dobu, kterou paketu trvá dostat se od zdroje k příjemci, tedy překonat cestu sítí mezi koncovými zařízeními. Je to tedy součet zpoţdění na všech linkách a zařízeních, kterými paket při průchodu sítí prochází. Podle Hens a Caballero (2008) se skládá ze zpoţdění na zařízeních neboli processing delay (TPi), které popisuje čas nutný k přesunu z vstupního interface na výstupní interface a čas strávený ve frontě. Dále se skládá ze serialization delay (TSi), coţ je zpoţdění mezi vysláním prvního a posledního bitu paketu. Některá zařízení nedokáţí přeposílat pakety, dokud nemají celý obsah. A posledním zpoţděním je propagation delay (TCi), které je popsáno jako zpoţdění, kdy byl paket vyslán na jednom zařízení a doručen na druhém zařízení. Vše shrnuje obr. 2. V některých případech je zpoţdění neměnné a tak malé, ţe si ho můţeme dovolit ignorovat. V jiném případě se zpoţdění mění na základě zatíţení linky a můţe způsobit výpadky hovoru nebo videa.

18 18 QoS Obr. 2 Zpoţdění Zdroj: Hens a Caballero, 2008 Rozptyl zpoždění také variace zpoţdění neboli jitter zpoţdění nemusí být pokaţdé stejné, ale většinou se mění podle toho, kterou cestou paket prochází nebo podle vytíţení dané linky či zařízení. Podle Szigeti a Hatting (2005) je variace zpoţdění definován jako rozdíl zpoţdění dvou po sobě jdoucích paketů. Udává se v milisekundách. Specifikován je v RFC Přehledně je to znázorněno na obr. 3. Obr. 3 Variace zpoţdění Zdroj: Hens a Caballero, 2008

19 Mechanismy QoS 19 3 Mechanismy QoS Od poloviny 90. let nastává obrovský rozmach ve světě moderních technologií, počítačových sítích a internetu. Původní koncept internetu a počítačových sítí se pomalu mění a zavádí se nové modely (Szigeti a Hatting, 2005). Z počátku celý internet a sítě fungovali jen podle jednoho modelu Best Effort. Mezi další modely, které vznikly, patří IntServ, DiffServ a další. V této práci budou popsány pouze tyto tři modely, protoţe cílem této práce je popsat nastavení QoS na hraničních zařízeních. 1 Přehled nejvýznamnějších modelů je na obr. 4. Obr. 4 Modely Zdroj: Szigeti a Hatting, Největší úsilí (Best Effort, BE) Prvním modelem je Best Effort, podle kterého vznikaly počítačové sítě i celý Internet. Tento model má za úkol přenést pakety z jednoho místa sítě na druhé co nejrychleji a nejefektivněji. Tento model nemá implementován QoS a neupřednostňuje ţádný provoz a odesílá pakety ve stejném pořadí, ve kterém přišly. Pokud chceme zajistit upřednostnění provozu, pouţijeme jiné modely. 3.2 Integrované služby (Integrated Services, IS, IntServ) Model IntServ byl prvním modelem, který reagoval na vývoj moderních aplikací vyţadující různé parametry doručení. Tento model vyuţívá sluţeb protokolu RSVP neboli Resource reservation Protocol (Odom a Cavanaugh, 2005). Pomocí tohoto protokolu si aplikace nejdříve podají ţádost o rezervaci zdrojů, které potřebují pro svůj přenos, a které budou mít k dispozici po celou dobu přenosu 1 Více informací k dalším modelům lze najít v knize End-to-End QOS Network Design.

20 20 Mechanismy QoS dat. Pokud jim není vyhověno, musí své nároky sníţit nebo přenos neproběhne. Pokud na všech uzlech dojde ke kladnému potvrzení, dojde k rezervování cesty a následně můţe být zahájen přenos. Celý proces rezervace je znázorněn na obr. 5. Většinou se při rezervaci vyuţívá rezervace šířky pásma nebo pamětí na uzlech, přes které přenos prochází. Pokud některý prvek nepodporuje model IntServ, tak je zde přenos přerušen. Pakety se pošlou modelem, který prvky podporují aţ k prvku, který znovu podporuje tento model a odtud dále probíhá rezervace podle domluvy mezi prvky. Z toho plyne první nevýhoda tohoto modelu, všechny prvky na cestě tento model musí podporovat. Jestliţe některý z nich tento model nepodporuje, tak není zaručena rezervace na celé cestě a u některých aplikací to můţe vést k jejímu výpadku. Mezi další podstatnou nevýhodu patří vysoká reţie. Kaţdý uzel, přes který data prochází, musí udrţovat informace o rezervaci a mít tyto prostředky vyhrazeny. Ve velkých sítích podobných například internetu je toto nerealizovatelné. IntServ zajišťuje tři moţnosti rezervace (Hens a Caballero, 2008). První moţností je bez rezervace, která je stejná jako model Best Effort. Druhou je kontrolovaná zátěţ, která nezpůsobí zahození paketů při přetíţené síti jako Best Effort. Tato moţnost je mezistupněm mezi Best Effort a poslední moţností rezervace, garantovanou sluţbou. Tato sluţba poskytuje garanci zpoţdění mezi koncovými zařízeními. Obr. 5 IntServ Zdroj: Odom a Cavanaugh, Diferencované služby (Differentiated Services, DS, DiffServ) Díky svým nevýhodám a hlavně kvůli velké reţii se model IntServ neuchytil a byl nahrazován modelem diferenciovaných sluţeb, neboli DiffServ. V dnešní době se pouţívá především model DiffServ a model IntServ se pouţívá pro menší sítě, ale i zde bývá nahrazován modelem DiffServ. Mezi hlavní tři body Modelu Diff- Serv podle Boušky (2009) patří identifikace provozu, rozdělení do tříd a definování politik pro jednotlivé třídy. V této metodě se provoz identifikuje a rozdělí do tříd. Tato klasifikace se uloţí do hlavičky paketu a dále se s tímto provozem zachází podle pravidel definovaných v politice dané třídy. Pokud router nebo

21 Mechanismy QoS 21 zařízení nepodporuje tento model, předá provoz dalšímu zařízení a to zase podle hlavičky předá paket dále podle politiky aplikované na daný provoz. Základní akce provádějící se při aplikaci tohoto modelu znázorňuje obr. 6. Obr. 6 Mechanismy DiffServ Zdroj: Cisco Systems, Inc., SRND, Klasifikace (Classification) Prvním krokem k definování modelu DiffServ je klasifikace. Klasifikace znamená rozpoznání provozu. Bývá velice často spojena s dalším krokem, kterým je značkování. Podle Odom a Cavanaugh (2005) paket přicházející na zařízení podporující QoS, můţeme určit pomocí několika moţností. První z nich rozlišuje pakety patřící do nějaké třídy. Můţe to být například pomocí zdrojové a cílové MAC adresy, rozhraní odkud paket přišel, pomocí protokolu nebo pomocí ACL, které můţe zahrnovat další moţnosti určení paketu, například pomocí zdrojové nebo cílové IP adresy. Druhou moţností je Network Based Application Recognition (NBAR), který rozpoznává automaticky provoz podle hlavičky paketu. Pozná RTP audio a video, URL adresu a některé aplikace. Poslední moţností je důvěra v nastavené hodnoty DSCP, IP precedence v hlavičce paketu. S poslední moţností souvisí pojem trusted boundaries, neboli hranice důvěryhodnosti (Adámek, 2008). Je to místo odkud věříme nastaveným hodnotám, tzv. DiffServ doména. Na jedné straně jsou nedůvěryhodná zařízení, kde nastaveným hodnotám nevěříme. Jsou to převáţně koncová zařízení, ale můţou to být i routery, které jsou na hranici dvou DiffServ domén nebo router mezi koncovým zařízením a danou DiffServ doménou. Na druhé straně jsou to potom důvěryhodná zařízení, jako jsou routery uvnitř DiffServ domény nebo také IP telefony, servery nebo telefonní ústředny.

22 22 Mechanismy QoS Značkování (Marking) Dalším krokem po klasifikaci provozu je jeho označení. Pro TCP/IP protokol slouţí k označení 6 bitové pole DSCP (DiffServ Code Point), které je obsaţeno v záhlaví IP paketu (Hens a Caballero, 2008). V případě IPv4 v poli ToS (Type of Service) nebo v případě IPv6 v poli TC (Traffic Class). Obě tato pole mají 8 bitů, 2 bity jsou prozatím nevyuţity. Dříve bylo pole ToS rozděleno na IPP IP precedence) a ToS, jak je vidět na obr. 7. Bylo zde implementováno kvůli jednoduchému zavedení priority, ale nikdy nebylo hojně uţíváno. Obr. 7 ToS, CT, DSCP pole Zdroj: Hens a Caballero, 2008 Jak jiţ bylo řečeno, DSCP pole má 6 bitů a můţeme rozdělit provoz celkem do 64 tříd. I kdyţ pole IP precedence nebylo pouţíváno tak je kompatibilní s polem DSCP. Těchto 64 tříd se rozděluje na 3 podtřídy známé jako PHB (Per Hop Behavior). Mezi tyto podtřídy patří EF (Expedited forwarding), AF (Assured forwarding) a BE (Best Effort) (Bouška, 2009). Podtřída EF zajišťuje rychlé předávání. Vyuţívá se pro přeposílání paketů, které potřebují nízké zpoţdění, jitter a nízkou ztrátovost. Pro tuto podtřídu se garantuje určitá šířka pásma a upřednostňuje provoz před ostatním, proto se tato podtřída pouţívá jen pro opravdu důleţitý provoz. Další podtřídou je AF, ta je dále rozdělena na 4 třídy a ty jsou rozděleny na další 3 podtřídy, tedy dohromady 12 tříd. Poslední podtřídou je BE, která nezaručuje ţádné záruky upřednostnění provozu. V tab. 1 jsou znázorněny jednotlivé IP precedence, třídy a jejich DSCP kód. Tab. 2 znázorňuje doporučené hodnoty DSCP pro typické aplikace.

23 Mechanismy QoS 23 Tab. 1 Tabulka IP precedence, tříd a DSCP kódů Tabulka IP precedence, tříd a DSCP kódů IPP Per Hop Behavior / DSCP 0 BE 0 1 CS1 AF11 AF12 AF (8) (10) (12) (14) 2 CS2 AF21 AF22 AF (16) (18) (20) (22) 3 CS3 AF31 AF32 AF (24) (26) (28) (30) 4 CS4 AF41 AF42 AF (32) (34) (36) (38) 5 EF (46) Zdroj: Bouška, 2009 Tab. 2 Hodnoty a typické aplikace Hodnoty IPP, DSCP, PHB a jejich typické aplikace typická aplikace IPP DSCP PHB Zdroj: Bouška, 2009 Rezervováno 7 Routing 6 48 CS6 Hlas 5 46 EF Video konference 5 34 AF41 Streamované video 4 32 CS4 Mission critical data 3 26 AF31 Call Signaling 3 24 CS3 Transactional data 2 18 AF21 Tetwork management 2 16 CS2 Bulk data 1 10 AF11 Scavenger 1 8 CS1 Best Effort Data Dalšími moţnostmi označení jsou pole na vrstvě L2 závislé na pouţité technologii. Pro technologii ethernet je to 3bitové pole CoS. Nachází se v rámci etherne-

24 24 Mechanismy QoS tové hlavičky v poli 802.1Q/p. Pro technologii Frame Relay je to pole DE bit, pro ATM pole CLP bit a pro MPLS je to pole EXP Omezování (Policing) Mezi první mechanismus správy provozu modelu DiffServ patří omezování. V tomto mechanismu se rozhoduje, zda daný paket nepřesahuje parametry vyhrazené v určité politice. Tyto podmínky bývají dohodnuty mezi zákazníkem a poskytovatelem ve smlouvě zvané SLA (Service Level Agreement). Pro zajištění parametrů se pouţívá rozloţení provozu (traffic shaping) a omezení provozu (traffic policing). Rozloţení provozu, jiţ podle názvu provoz rozkládá v čase a zmírňuje tak zatíţení na maximální přenosovou kapacitu. Toto není vhodné pro komunikaci v reálném čase. Omezení provozu omezuje vstupní tok zahozením paketů, které překročily maximální povolenou přenosovou kapacitu. Vše názorně popisuje obrázek. Z obr. 8 je patrné, ţe hlavní rozdíl je v pouţití vyrovnávací paměti u shapingu. Ten vyuţívá vyrovnávací paměť k uloţení přesahujících dat a následné vyhlazení průběhu při vyprazdňování této paměti. Policing tuto paměť nepouţívá a tudíţ zde nedochází k ţádnému zpoţdění provozu (Joseph a Chapman, 2009). Obr. 8 Traffic policing a traffic shaping Zdroj: Bouška, 2009 K omezení provozu se pouţívá algoritmus kbelíku kupónů (Token Bucket). V kbelíku jsou kupóny, které se do něj přidávají zadanou rychlostí. Z kbelíku se 2 Více informací k jednotlivým technologiím a polím popisuje kniha Szigeti a Hatting, 2005

25 Mechanismy QoS 25 odebírají kupóny podle toho, kolik má být přeneseno bytů (1 kupón za 1 byte). Pokud zde není dostatek kupónů, tak se data zahodí. Najednou můţe být přenesen shluk bytů o velikosti kbelíku. Toto je z důvodu, ţe provoz je spíše nárazový a jednou za čas potřebujeme poslat shluk bytů (Hens a Caballero, 2008) Plánování (Scheduling) Plánováním se rozumí řazení a vybíráním paketů z front. Fronta (queue) je vlastně paměť, která se vyuţije ve chvíli, kdy je rychlost příchozích paketů větší, neţ rychlost odchozí. Tehdy se pakety ukládají do fronty, a podle algoritmu fronty se odebírají a odesílají. Pokud by fronta neexistovala, tak by se pakety rovnou zahazovaly. Pokud je příchozí rychlost menší, tak se fronta nepouţije (Boušek, 2009). Kaţdé rozhraní na prvcích v síti má HW frontu, která je řešena algoritmem FIFO. Dále můţe mít kaţdé rozhraní libovolný počet SW front. Na počátku byly 4 fronty FIFO, Priority Queues (PQ), Custom Queuing (CQ), Round Robin Queues (RRQ). Z těchto front potom vznikly další, které jsou dnes pouţívanější neţ původní, protoţe obsahují kombinace výhod původních front. Patří mezi ně Weighted Fair Queuing (WFQ), Class Based Weighted Fair Queuing (CBWFQ) a Low Latency Queuing (LLQ). First In First Out (FIFO) jiţ z názvu vyplývá princip této fronty. Pakety, které první přijdou do fronty, ji první opustí. Tato fronta je jedna z nejstarších a vyuţívá se díky své jednoduchosti implementace. Její nevýhodou je, ţe nedokáţe upřednostnit důleţitý provoz (Hens a Caballero, 2008). Priority Queues (PQ) tento typ fronty jiţ zavádí upřednostnění provozu podle priority uloţené například v poli DSCP. Příchozí provoz je rozdělen do několika front podle důleţitosti, znázorněny na obr. 9. Tyto fronty jsou na principu FIFO. Nejdůleţitější data jsou odbavena první a poté co jsou všechna důleţitá data odbavena, se obsluhují další fronty. Nevýhodou je, ţe nejméně důleţité fronty mohou čekat na odbavení velmi dlouho a mezitím pakety, které se nevejdou do fronty, se zahodí (Odom a Cavanaugh, 2005).

26 26 Mechanismy QoS Obr. 9 Priority Queues Zdroj: Vozňák a Hromek, 2007 Custom Queuing (CQ) tento typ fronty částečně odstraňuje problém PQ. Rozděluje provoz do několika front, jako PQ, ale jednotlivé fronty nejsou obsluhovány podle priority, ale podle šířky pásma vyděleným počtem všech front. To má za následek, ţe nedojde k neodbavení fronty s nejniţší prioritou (Odom a Cavanaugh, 2005). Round Robin Queues (RRQ) tento typ fronty je podobný CQ. Rozděluje provoz do několika tříd a ty jsou následně postupně kruhově odbavovány. Můţeme přidat některé třídě větší váhu a tím tuto třídu upřednostníme a bude se z ní odebírat více paketů neţ z tříd ostatních (Bouška, 2009). Weighted Fair Queuing (WFQ) tento typ fronty funguje podobně jako RRQ s tím rozdílem, ţe pakety v podtřídách, které mají malou velikost, jsou odbaveny dříve neţ velké pakety (Joseph a Chapman, 2009). Class Based Weighted Fair Queuing (CBWFQ) tento typ je velice podobný frontě RRQ. Jediný rozdíl je ve zpracování podtříd, které jsou zpracovávány frontou WFQ (Joseph a Chapman, 2009). Low Latency Queuing (LLQ) nejpouţívanější. Podporuje multimediální aplikace. Skládá se z 3 tříd. Jedna ze tříd je řešena pomocí PQ a slouţí hlavně pro multimediální aplikace. Další třída, která se dále dělí na podtřídy je řešena pomocí CBWFQ a poslední třídou je defaultní, která má nejmenší prioritu (Joseph a Chapman, 2009). Přehledně je to znázorněno na obr. 10.

27 Mechanismy QoS 27 Obr. 10 Princip LLQ Zdroj: Cisco Systems, Inc., SRND, Správa front (Queuing) V předchozí kapitole bylo popsáno, jakým způsobem fronty fungují, a jak jsou důleţité pro fungování sítí. Nemůţou být moc velké fronty, protoţe dochází k nárůstu zpoţdění a zase nemůţou být příliš malé fronty, aby nedocházelo k častému zahlcení fronty. V této kapitole budou popsány moţnosti předcházení zahlcení front (Boušek, 2009). Slouţí k tomu mechanismy předčasného a chytrého zahazování. Mezi tyto mechanismy patří Tail drop, Random Early Detection a WRED. Tail drop je nejstarší mechanismus a pouţívaný při úplném zahlcení front. Tento mechanismus zahazuje všechny pakety, které se do fronty jiţ nevejdou. Tento mechanismus vyuţívá vlastností protokolu TCP, kdy se při nedoručení paketů sníţí window size. Pokud se sníţí window size, sníţí se i rychlost vysílaných TCP paketů a následně i k uvolnění fronty. Tento mechanismus má i své nevýhody. První z nich je, ţe pokud se sníţí window size, tak tuto šířku pásma můţe vyuţít UDP tok a tím dojde k dalšímu sníţení window size, aţ dojde k úplnému vyhladovění TCP toku. Další nevýhodou je, ţe můţe dojít k neustálé oscilaci, kdy dochází k uvolnění a následnému zahlcení fronty, stále dokola (Odom a Cavanaugh, 2005). Random Early Detection (RED) tento mechanismus nečeká na zahlcení, ale začíná zahazovat pakety, tak aby se tomuto stavu vyhnul. Pokud počet paketů ve frontě dosáhne předem daného stavu, začnou se pakety náhodně zahazovat. Pokud stále dochází k růstu počtu paketů ve frontě, zvýší se počet paketů, které se zahazují, aţ můţe dojít k úplnému zahlcení fronty a zahazují se všechny pakety, jako při mechanismu tail drop (Hens a Caballero, 2008). Weighted Random Early Detection (WRED) tento mechanismus je vylepšením mechanismu RED. Vyuţívá hodnot v poli DSCP a podle toho provádí

28 28 Mechanismy QoS zahazování. Nejdříve se začnou zahazovat pakety, které mají větší šanci k zahození (Joseph a Chapman, 2009). Princip mechanismu je znázorněn na obr. 11. Obr. 11 Mechanismus WRED Zdroj: Joseph a Chapman, 2009

29 Triple play 29 4 Triple play 4.1 Pojem triple play Zkratku Triple play lze volně přeloţit jako trojitá hra, přičemţ samotný název napovídá, ţe se jedná o spojení tří sluţeb. Jedná se o přenos hlasu, přenos pohyblivého obrazu (videa) a přenos dat. Spojením těchto sluţeb přináší poskytovatelé internetu ISP (Internet Service Provider) výhodný balíček do své nabídky, který je nabízený za zvýhodněnou cenu, oproti zřízení jednotlivých sluţeb odděleně. K provozování všech tří sluţeb najednou je zapotřebí, aby sluţbám byly stanoveny priority. Prioritu nejvyšší získala sluţba přenos hlasu, neboť je důleţité přenášet hlas v reálném čase s co nejmenším zpoţděním. Později přijaté pakety nemají smysl, protoţe konverzace je v jiném bodě. Střední prioritu obdrţela sluţba přenos videa a nejniţší přenos dat (Horváth, Šifta a Münster, 2013). 4.2 Protokoly Při přenosu sluţeb pomocí protokolu IP se vyuţívá dvou základních protokolů TCP a UDP. Při přenosu dat je vyuţit spojovaný a spolehlivý protokol TCP. Tento protokol zaručuje úspěšné doručení všech paketů. Toho dosahuje potvrzováním a znovu vysláním nepotvrzených paketů. Díky těmto vlastnostem dochází ke zpoţdění, které je pro multimediální přenosy nevhodné, proto se pro přenos hlasu a videa pouţívá nespojovaný a nespolehlivý protokol UDP (Puţmanová, 2012). V rámci protokolu UDP však chybí některá specifika pro přenos multimediálních souborů, proto je nad ním pouţit ještě doplňující protokol RTP (Real-time Transport Protocol) (Puţmanová, 2009). Podle Puţmanové (2009) RTP definuje pořadová čísla paketů, podle kterých mohou multimediální aplikace rozpoznat chybějící pakety. Zakládá se na synchronizaci časového přenosu a zjištění ztráty nebo nesprávného pořadí dat. V záhlaví RTP se nachází jiţ zmíněné pořadové číslo, typ obsahu, které v sobě obsahuje informaci o formátu, dále obsahuje synchronizaci pro detekci různého kolísání zpoţdění a indikaci začátku a konce rámce. Všechny poloţky jsou zobrazeny v obr. 12. Protokol RTP můţe úspěšně vyuţít komprese záhlaví a potom se označuje jako crtp (Compressed RTP). Z velikosti 40 B se komprimací hlavičky sniţuje na 2-5 B (Cisco Systems, Inc., crtp, 2012). Blízkým protokolem k protokolu RTP je jeho řídící protokol RTCP (Real-time Transport Control Protocol). Pouţívá se pro řízení výkonnosti a monitoring (Puţmanová, 2009). Mezi další protokoly, které pouţívají multimediální sluţby, patří protokoly pro navazování, ukončování a správu spojení. Mezi tyto protokoly patří SIP, H323 a MGCP (Horváth, 2013).

30 30 Triple play Obr. 12 RTP hlavička Zdroj: Wiki McMaster, Přenos hlasu Počátky přenosu hlasu jsou zakotveny v telefonních ústřednách, kdy hovor probíhal na principu přepojování okruhů. V dnešní době se vyuţívá protokolu IP a přenosu po datových sítích. Tento způsob komunikace nese označení VoIP (Voice over IP). Volání probíhá pomocí bran, kdy je signál převeden např. z paketů na digitální signál případně na spojitý analogový (Horváth, Šifta a Münster, 2013). Při přenosu hlasu po datové síti je potřeba hlas kódovat. Není ţádoucí, aby přenos hlasu zabíral velkou část přenosové šířky média a tím ubíral potřebnou kapacitu linky ostatním sluţbám (Horváth, 2013). Mezi nejpouţívanější formáty ke kódování hlasu v IP telefonii patří standardy G.7XXX. Viz tab. 3. Pro přenos hudby je v dnešní době nejpopulárnější MP3. Mezi další formáty patří např. WMA od společnosti Microsoft, Vorbis nebo AAC (Jícha, 2013). Všechny zmíněné formáty pouţívají ztrátovou kompresi a bitrate se pohybuje od 8-64 b/s u VoIP formátů a b/s u hudebních formátů.

31 Triple play 31 Tab. 3 Formáty hlasu pro VoIP a MP3 Standard Šířka pásma MOS3 G kb/s 4,10 G.723 6,3 kb/s 3,90 G kb/s 3,85 G kb/s 3,61 G kb/s 3,92 MP kb/s - Zdroj: Horváth, Šifta a Münster, Přenos videa Velikost videa je mnohonásobně větší neţ u audia, a proto je kódování nezbytné, aby bylo moţné video přenášet po síti. Video soubor se skládá ze zvuku, videa a případných titulků. Pro rozdělení video souboru je nutné mít splitter (Přikryl, 2011). Tento filtr se stará o rozdělení vstupního souboru na titulky, audio sloţku a video sloţku. Formáty pouţité pro přenos hlasu byly popsány v předchozí kapitole. U videa jsou nejrozšířenější formáty z rodiny MPEG. U videa musíme rozlišovat jeho rozlišení. Následující tab. 4 udává potřebnou šířku pásma pro jednotlivé formáty MPEG2, MPEG4 a pro VC z rodiny Microsoft při rozlišení HD a při rozlišeni SD (Hens a Caballero, 2008). Tab. 4 Šířka pásma Šířka pásma pro SDTV a HDTV Rozlišení MPEG2 MPEG4 VC1 SDTV 704 x 480 3,5 Mbit/s 2-3,2 Mbit/s 2-3,2 Mbit/s HDTV 1920 x Mbit/s 7,5-13 Mbit/s 7,5-13 Mbit/s Zdroj: Hens a Caballero, Přenos dat Poslední sloţkou sluţby triple play je přenos dat, neboli poskytnutí vysokorychlostního internetu. Rychlost připojení můţe být sníţena při přenosu digitální 3 MOS (Mean Opinion Score) hodnocení kvality hovoru. 5 nejlepší, 0 nejhorší

32 32 Triple play televize (Horváth, 2013). Dnešní poskytovatelé nabízejí rychlosti od 30 Mb/s aţ po rychlosti 240 Mb/s (Netbox, 2013; UPC, 2013). Firma O2, která pouţívá technologie ADSL a VDSL nabízí rychlosti od 2 Mb/s po rychlosti 40 Mb/s (O2, 2013). 4.6 Parametry QoS na služby triple play Z předchozích odstavců je jasné, ţe kaţdá ze sluţeb triple play vyţaduje jiné parametry QoS. Přenos zvuku je nejcitlivější na zpoţdění, ztrátovost i jitter, ale nepotřebuje velkou šířku pásma. Druhou nejcitlivější sluţbou je přenos videa, které vyţaduje velkou šířku pásma. Přenos dat je nejméně citlivý. Tyto parametry jsou znázorněny v tab. 5. Zároveň jsou to doporučení firmy Cisco(Cisco Systems, Inc., 2008) a ITU Mezinárodní telekomunikační unie (ITU-T, 2013). Tab. 5 Parametry QoS Požadavky QoS Ztrátovost Zpoždění Jitter Šířka pásma VOIP 1 % 150 ms 30 ms kbps IPTV 5 % 4-5 s Mbps Data 0 % Zdroj: Cisco Systém, Inc., SRND, 2008

33 Obecný postup pro nastavení QoS 33 5 Obecný postup pro nastavení QoS 5.1 Možnosti nastavení V praktické části jsou pouţity zařízení firmy Cisco, díky svému dominantní postavení na trhu a rozšířenosti síťových zařízení. V dalších částech této práce budou popisovány moţnosti nastavení právě na těchto zařízeních. Pro nastavení existuje několik moţností. Firma Cisco umoţňuje nastavení QoS třemi způsoby. Prvním způsobem je automatické nastavení pomocí AutoQoS. Po povolení této moţnosti dostáváme základní nastavení QoS. Další nastavení musíme nastavovat podle našich poţadavků. Tato varianta je vhodná hlavně pro nastavení QoS při přenosu hlasu. Při přenosu videa nedosahuje kvalitních výsledků a je doporučeno pouţít jinou moţnost nastavení. Další moţností nastavení je pomocí QPM (QoS Policy Manager). Jedná se o nastavení pomocí webového rozhraní na serveru QPM. Odtud se nastavení QoS dále rozešle na příslušná zařízení. Poslední a nejrozšířenější moţností je MQC (Modular QoS CLI - Command Line Interface). Této varianty je vyuţito i v praktické části této práce, a proto zbytek kapitoly bude věnován této moţnosti. Při nastavování je vyuţita příkazová řádka, kam jsou zadávány příkazy, které se hned aplikují (Odom a Cavanaugh, 2005). 5.2 Postup nastavení (Cisco Systems, Inc., SRND, 2008) Definice cílů Správné nastavení QoS probíhá v několika krocích. Prvním krokem je definování cílů. Kaţdá organizace, kaţdý poskytovatel i kaţdý uţivatel má na síť jiné nároky. Administrátor, který nastavuje QoS na jejich síti, musí rozpoznat provoz a rozdělit ho do skupin se stejným účelem. Tyto skupiny sdruţují aplikace se stejnými poţadavky na kvalitu přenosu. Firma Cisco vytvořila za tímto účelem 11vrstvý model pojmenovaný QoS Baseline. Na obr. 13 je tento model znázorněn. Tento model slouţí pouze jako doporučení a nemusí být všechny třídy vyuţity Analýza požadavků Dalším bodem postupu je analýza poţadavků provozu. Jak bylo popsáno výše, kaţdý provoz má jiné nároky a vyţaduje jiné parametry v síti. V rámci tohoto bodu se jednotlivé poţadavky analyzují a v dalších bodech se podle těchto poţadavků nastavují jednotlivé mechanismy, aby byly tyto poţadavky splněny.

34 34 Obecný postup pro nastavení QoS Obr. 13 QoS Baseline Zdroj: Cisco Systems, Inc., SRND, Nastavení politik Třetím bodem je samotné nastavení QoS na jednotlivých zařízeních. Pokud jiţ jsou známy všechny poţadavky, provoz je rozdělen do tříd, začíná se s nastavováním. Tento proces je rozdělen do 3 částí. 1. Class-Map První částí je klasifikace provozu do tzv. class map. Nejprve je vytvořena pojmenovaná třída, do které je provoz zařazen. Pokud je pouţit příkaz match-all musí být splněny všechny podmínky. Jestliţe je pouţit příkaz match-any stačí, aby byla splněna pouze jedna podmínka. Uvnitř třídy je provoz vybrán pomocí příkazu match. Příklad vytvoření pojmenované třídy test: ROUTER(config)#class-map match-all test ROUTER(config)#class-map match-any test Příklady vybrání provozu, všechen, podle ACL, podle IP precedence, vlany, cílové mac adresy, podle rozhraní nebo podle protokolu ROUTER(config-cmap)#match any ROUTER(config-cmap)#match access-group 10 ROUTER(config-cmap)#match ip precedence critical ROUTER(config-cmap)#match vlan ROUTER(config-cmap)#match destination-address mac EA-E4-D0-96 ROUTER(config-cmap)#match input-interface fa1

35 Obecný postup pro nastavení QoS 35 ROUTER(config-cmap)#match protocol ip 2. Policy map Další částí je vytvoření policy map. V této části je provoz označen a jsou na něj aplikovány mechanismy QoS pomocí vytvořených tříd. Pokud není provoz označen je zařazen do defaultní třídy. Přiklad pro vytvoření policy mapy test-policy ROUTER(config)#policy-map test-policy Příklad vybrání class mapy a jejího nastavení. Nastaveno cos, ip precedence, dscp, policing, shaping, prioritizace, vymezení pásma a logování. ROUTER(config-pmap)#class test-class ROUTER(config-pmap-c)#set cos 3 ROUTER(config-pmap-c)#set precedence 3 ROUTER(config-pmap-c)#set dscp 24 ROUTER(config-pmap-c)#police exceed-action drop ROUTER(config-pmap-c)#shape average ROUTER(config-pmap-c)#priority ROUTER(config-pmap-c)#bandwidth 1024 ROUTER(config-pmap-c)#log 3. Service-policy Poslední částí je nastavení aplikování QoS tzv. service-policy na rozhraní zařízení. Důleţité je v tomhle bodě nastavit zda se má QoS aplikovat na provoz příchozí nebo odchozí. Po aplikaci začne být provoz rozdělován do tříd a jsou na něj uplatňována pravidla nastavená v policy mapách. Příklad aplikace policy mapy test policy na gigabitovém rozhraní. ROUTER(config)#interface gigabitethernet1/0/1 ROUTER(config-if)#service-policy input test-policy 5.3 Nasazení a kontrola Posledními kroky nastavení QoS jsou nasazení do ostrého provozu a kontrola správnosti. Pokud se objeví komplikace nebo nastanou neočekávané výsledky, je vhodné vrátit se k původnímu nastavení a zkontrolovat nastavení. Kontrola výsledků je nikdy nekončící proces. Kaţdá firma se vyvíjí a poţadavky na síť s ní. Nastavení, která byla provedena, a která jsou vyhovující dnes, nemusí vyhovovat poţadavkům firmy zítra. Správný administrátor dopředu předvídá jednotlivé nároky na síť a i díky monitoringu, provádí správné nastavení, které firma vyţaduje.

36 36 Praktická část 6 Praktická část 6.1 Laboratorní síť Pro praktické nastavení QoS popsané v předchozích kapitolách, jsme sestavili laboratorní síť v rámci Síťové laboratoře Mendelovy univerzity. Laboratoř disponuje síťovými zařízeními od firem Cisco, Mikrotik a Juniper. V rámci této bakalářské práce byly pouţity zařízení firmy Cisco. Konkrétně to byly 2 switche Catalyst řady 2960 s verzí IOSu 12.4 a 2 routery řady 2801 s verzi IOSu Dále bylo pouţito 6 počítačů vybavených procesorem Intel core i5 s taktem 3,20 GHz a 4 GB RAM. Na 2 počítačích byl spuštěn operační systém linux Centos verze 6. Na zbylých 4 počítačích byl spuštěn operační systém linux Fedora verze 16. Všechny operační systémy byly spuštěny pomocí VirtualBoxu. Struktura této laboratorní sítě je zobrazena na obr. 14. Obr. 14 Topologie sítě Nabídku sluţeb triple play nejčastěji vyuţívají domácnosti, proto jsou v této laboratorní síti nastaveny podobné podmínky jako ve skutečnosti. Bohuţel jsme omezeni počtem zařízení i sloţitostí reálné sítě. V reálné síti se nachází několik desítek síťových zařízení, přes která provoz putuje. V naší síti máme pouze 2 routery. Dále pro jednoduchost přijímáme a odesíláme vţdy jednu sluţbu z jednoho počítače na jeden počítač. V reálné síti můţe na jednom zařízení běţet více sluţeb zaráz například web server a video server. Rychlost linek mezi počítači a switchi v naší síti je nastavena na 100 Mbit/s. Stejná rychlost je nastavena mezi switchi a routery. Rychlost mezi routery je omezena na 10 Mbit/s. Toto nastavení vyplývá z průměrné rychlosti přístupu k internetu od uţivatelů, kteří si zkoušeli test svého připojení na serveru rychlost.cz. Graf těchto rychlostí je zobrazen na obr. 15.

37 Praktická část 37 Obr. 15 Zdroj: Graf rychlostí rychlost.cz V této síti není pouţit ţádný telefon ani televize. Abychom mohli simulovat tento provoz, vyuţili jsme počítačů. Dva počítače slouţí k simulaci telefonního hovoru, dva počítače k simulaci televize a dva počítače k simulaci webového provozu. Vţdy jeden z dvojice počítačů slouţí k vysílání a druhý pro příjem. V reálném světě se také připojujeme k serveru, abychom získali webovou stránku nebo si pustili film. Pro jednoduchost není na síti pouţit ţádný routovací protokol, ale je vyuţito statického routingu. Při reálném zapojení bývá mezi routery několik desítek zařízení a sítí, přes které pakety prochází. Zde se pouţívají routovací protokoly, protoţe udrţet aktuální informace v tolika zařízeních pomocí statického routingu není moţné. V našem případě máme pro jednoduchost pouze dva routery. V tomto případě je nastaven pouze statický routing. 6.2 Použité nástroje V této části jsou popsány nástroje, které jsou vyuţity při praktické části. Některé nástroje jsou nezbytné pro samotné měření (VLC, wget), jiné jsou pro usnadnění měření (bash) a další jsou pro zachycení výsledků (wireshark). VLC prvním z nich je nástroj VLC. Tento nástroj je pouţit pro simulaci telefonního hovoru a IPTV. Zvládne přehrát velké mnoţství audio i video formá-

38 38 Praktická část tů a poskytuje moţnosti streamování z jednoho počítače na druhý viz obr. 15. Jeho licence je freeware 4. wget dalším nástrojem je wget. Tento nástroj je pouţit k simulaci webového provozu. Vyuţívá se pro stahování souborů pomocí protokolu HTTP, HTTPS nebo FTP. Nástroj je freeware licence. bash tento nástroj má více moţností pouţití. První jako interpret příkazů zaloţených na Bourne shellu. Nebo jako programovací nástroj, pro tvorbu jednoduchých skriptů, které byly vyuţity i v této práci. Nástroj bash je standardní součástí kaţdé linuxové distribuce a je volně dostupný 5. Wireshark tento nástroj slouţí k odchytu síťového provozu. V této práci je vyuţit k odchytu provozu a následnému zpracování viz obr. 15. Nástroj je freeware licence 6. Obr. 16 VLC a wireshark 4 Při nastavení streamu jsme postupovali podle návodu na stránkách Computer. 5 Jednoduchý návod a popis k pouţití nástrojů bash a wget lze najít na stránkách 6 Staţení a návody k jeho pouţití lze najít na stránkách

39 Praktická část Synchronizace času V teoretické části byly popsány poţadavky jednotlivých sluţeb na šířku pásma, jitter a zpoţdění. Při telefonním hovoru by zpoţdění nemělo překročit hranici 150 ms (ITU-T, 2013). Abychom zjistili správnost nastavení, musíme synchronizovat čas v síti. V této práci je pouţita synchronizace pomocí protokolu NTP (Network Time Protocol). Cílem tohoto protokolu je zajistit stejný systémový čas na všech zařízeních v síti (Zach, 2012). Zach dále uvádí, ţe protokol NTP je zaloţen na hierarchickém principu, kde nejvyšší vrstvy označovány jako stratum 1 jsou synchronizovány pomocí atomových hodin nebo satelitů. Další vrstvy stratum se pak dotazují na čas předchozích vrstev. Navíc mohou spolupracovat jednotlivé vrstvy mezi sebou a dochází tak ke zpřesnění času. Celkově je definováno 15 vrstev stratum. V praxi se však vyuţívá pouze prvních 5 a občas jiţ ve 3 vrstvě nalezneme firemní NTP servery. Z laboratorní sítě není přístup do internetu pro získání stejného času na všech zařízeních. Pro synchronizaci času na všech počítačích je zvolen jeden jako NTP server, podle kterého ostatní počítače nastaví vlastní čas. Ke kontrole správnosti výsledků není nutný přesný čas, ale jen rozdíly mezi klientem a serverem. Nastavení počítače s operačním systémem linux Centos jako serveru, se provádí v konfiguračním souboru /ntp/ntp.conf. Zde jsou odstraněny řádky, které odkazují na NTP servery v internetu. Místo nich jsou napsány řádky pro nastavení lokálního času. Pro nastavení klienta na operačním systému linux Centos je vyuţit stejný konfigurační soubor. IP adresa internetového NTP serveru je přepsána na adresu počítače nastaveného jako NTP serveru. Spuštění sluţby NTP na obou počítačích se provádí příkazem service ntpd start. Pod operačním systémem linux Fedora od verze 16 byl implementován nástroj chrony, který je kompatibilní s NTP. Podle man stránek by měl být šetrnější k vyuţití procesoru, kdy není potřeba tolika dotazů na NTP server. Nastavení se provádí stejně, jako u NTP jen změny se provádí v konfiguračním souboru /etc/chrony.conf. Spuštění sluţby se provádí příkazem service chronyd start. Kontrola nastavení se provede příkazem ntpq p v prostředí linux Centos. V případě linux Fedora pomocí příkazu chronyc a následnými příkazy sources a sourcestats. V obou případech kontrolní výpis poskytne odchylky od serveru. 6.4 Nastavení laboratorní sítě Nastavení laboratorní sítě probíhalo v několika krocích. Prvním krokem bylo vytvoření návrhu sítě k otestování nastavení QoS na reálných prvcích. Z tohoto důvodu byla síť rozdělena na 2 části. Na část serverů a část klientů. V části serverů jsou 3 počítače, na kterých běţí webový server, IPTV server a VoIP server. V části klientů jsou také 3 počítače, na kterých se jednotlivé sluţby přijímají. Viz obr. 14. Dalším krokem bylo propojení počítačů a síťových zařízení podle schématu. Po spuštění a nabootování jednotlivých stanic byla na počítači označeném PData

40 40 Praktická část spuštěna konzole pomocí, které bylo prováděno nastavení síťových zařízení. Prvním nastavením bylo nastavení statického routingu. Dalším krokem byla synchronizace počítačů, podle postupu popsaného v předchozí kapitole. Jako NTP server byl zvolen počítač s označením PData. Pro usnadnění měření byly napsány jednoduché skripty v programovacím jazyce bash. Na počítačích v klientské části skripty obsahovaly spuštění přehrávání nebo stahovaní. V serverové části slouţily skripty ke spuštění streamingu pomocí programu VLC. Pro simulaci webového provozu byl pouţit webový server a nástroj wget. Z pozorování a dotazů respondentů většina uţivatelů, pokud nečte nějaký článek, tak klikne přibliţně kaţdých 5 vteřin. A u toho často stahují nějaký soubor. Na základě toho probíhala simulace tohoto provozu pomocí stahování velkého souboru s velikostí 50 MB a stahováním malého souboru s velikostí 750 KB. Malý soubor byl stahován kaţdých 5 vteřin. Ke spuštění všech sluţeb byl napsán skript, který se vzdáleně připojil ke všem serverům. Toho bylo docíleno pomocí programu SSH. Pro zrušení zadávání hesla při přihlašování byla vygenerována dvojice klíčů, veřejný klíč a privátní klíč. Veřejný klíč byl zkopírován na ostatní počítače (Linuxproblem, 2008). 6.5 Metodika měření Měření bylo provedeno bez QoS a s různými parametry QoS pro porovnání výsledků. Po nastavení popsané v předchozí kapitole, byl na všech počítačích spuštěn program wireshark a zahájen odchyt pro další zpracování. Následně byl spuštěn skript z počítače PData pro spuštění sluţeb v následujícím pořadí: 5 50 vteřina - spuštění simulace IPTV vteřina - spuštění simulace VoIP vteřina - spuštění simulace prohlíţení webových stránek vteřina - spuštění simulace stahování souboru Po skončení simulace jsou uloţeny výsledky a opakuje se postup s jiným nastavením. Přehrávač VLC neumí kódování do formátů G.7xx, proto jsme vyuţili nejrozšířenějšího formátu MP3. Má větší nároky na šířku pásma neţ formáty G.7xx. Rozlišení videa 7 bylo 854x480 a 1920x1080 bez kódování a s kódováním do formátu MPEG4. 7 Pouţité video lze stáhnout ze stránek Jedná se freeware licenci.

41 Praktická část Nastavení QoS Definice cílů Jak bylo popsáno v předchozích kapitolách, kaţdý má na síť jiné nároky a podle toho se liší nastavení QoS. V této práci je řešeno nastavení QoS při poskytování sluţeb triple play do domácností. V případě triple play se jedná o sluţby internetu, telefonie a televize přes jednu konvergovanou síť. V této práci je pouţit model QoS baseline. V rámci triple play do domácností jsou některé třídy nevyuţity. Mezi vyuţité třídy patří třída pro simulaci VoIP. Další třída pro simulaci IPTV. A jedna třída pro simulaci webového provozu. Při pouţívání VoIP je pouţita třída pro navazování spojení. Poslední třída nebude pouţívána, ale při reálném zapojení nebude nikdy chybět. Jedná se o třídu, pomocí které si routery vyměňují informace o dostupnosti a routovacích tabulkách Analýza požadavků V předchozí kapitole byly nadefinovány třídy, které jsou potřeba pro rozdělení provozu. V této kapitole jsou určeny poţadavky QoS pro jednotlivé třídy. IP routing tato třída slouţí ke komunikaci mezi routery, a proto musí být zajištěno, aby byla tato třída pokaţdé, co nejrychleji obslouţena. Nemá velké nároky na šířku pásma, a proto je jí garantováno 5 % celkové šířky pásma. Call signaling tato třída obstarává vytáčení a navazování spojení. Garantovaná šířka pásma je 5 %. Voice třída slouţící pro telefonní hovory. V kapitoly je napsáno, ţe minimální šířka pásma pro tuto třídu je 8 kbps s pouţitím formátu G.729. Největší šířku pásma zabírá formát G.711, který zabírá 64 kbps. Program VLC neumí kódování do formátu G.7xxx, proto je vyuţit formát MP3, který má poţadavky na šířku pásma větší, 192 kbps. Pro tuto třídu je garantovaná šířka pásma 5 %. Video v této třídě je nastavení pro IPTV. S nejpouţívanějším formátem mpeg4 je potřeba vyhradit 3,5 Mbps pro standardní rozlišení. Pro rozlišení HD je potřeba jiţ 15 Mbps. Pro otestování různých scénářů je nastaveno této třídě 60 % a 30 % garantované šířky pásma. Data poslední třída slouţí pro webový přenos. Díky protokolu TCP, který znovu vysílá zahozené pakety, je garantována zbylá šířka pásma pro tuto třídu. Čím menší tato šířka bude a ostatní provoz větší, tím pomaleji se budou data z internetu stahovat Nastavení politik 8 Pro nastavení politik je vyuţito Modular Quality of Service Command Line Interface (Modular QoS CLI nebo pouze MQC). Toto nastavení se provádí ve třech 8 Nastavení se mohou lišit podle verze IOSu a typu zařízení.

42 42 Praktická část krocích. Rozdělení provozu do class map. Vytvoření politik pomocí policy map a nakonec aplikace policy map na rozhraní (Boušek, 2009). Nastavení je provedeno na switchi a na routeru. Nejprve jsou na switchi vytvořena pojmenovaná ACL (Access Control List) podle, kterých je provoz klasifikován do class map. Následně jsou vytvořeny class mapy a policy mapa. Posledním krokem je aplikace policy mapy na všech rozhraních s variantou input. Pakety přicházející na router jsou označeny a provádí se zde nastaveni mechanismů QoS. Ze správy front je pouţita LLQ s prioritní frontou pro třídu voice. Dále pro třídy video a data je vyuţit mechanismus předcházení zahlcení CBWFQ. Parametry pro nastavení jednotlivých tříd je shrnuto v tab. 6. Aplikace na rozhraní byla pouţita s variantou output. Tab. 6 Nastavení QoS Třída Nastavení Hodnota Ponámky Voice DSCP 46 Klasifikace bandwidth 5 % Šířka pásma priority Prioritní fronta Video DSCP 32 Klasifikace random-detect dscp-based Zahazování bandwidth 60 %, 45 %, 30 % Šířka pásma Data DSCP 0 Klasifikace Signaling DSCP 24 Klasifikace bandwidth 5 % Šířka pásma Routing DSCP 48 Klasifikace bandwidth 5 % Šířka pásma

43 Výsledky měření 43 7 Výsledky měření 7.1 Bez QoS Měření probíhalo v několika variantách. S videem v kvalitě SD (standard definition) a v kvalitě HD (high definition). Dále probíhalo měření s videem s překódováním do formátu MPEG4 a pro srovnání i bez překódování. První měření, které bylo provedeno měřilo šířku pásma videa, které má největší odběr při sluţbách triple play. Na grafu obr. 17 je porovnání videa ve standardní kvalitě (SD) bez kódování a s kódováním do formátu MPEG4. Na druhém grafu obr. 18 je potom video v kvalitě HD. Obr. 17 Video bez formátu a s MPEG4, SD

44 44 Výsledky měření Obr. 18 Video bez formátu a s MPEG4, HD V dalším měření byly změřeny všechny sluţby triple play. V prvním grafu obr. 19 je znázorněna šířka pásma pro jednotlivé sluţby triple play hlasu, videa a webové sluţby. Video je ve formátu MPEG4 a v prvním grafu obr. 19 s kvalitou SD. Druhý graf obr. 20 znázorňuje výsledky s videem v kvalitě HD. Obr. 19 Bez QoS, MPEG4, SD

45 Výsledky měření 45 Obr. 20 Bez QoS, MPEG4, HD V následující tabulce jsou uvedeny hodnoty pro jitter, delay ztrátovost a pro webovou sluţbu je uvedena průměrná doba načtení stránky. Velký soubor se v ţádném z případů nestáhl. A tak je dalším údajem v tabulce, kolik se stáhlo bytů. Poslední poloţka udává rychlost stahování jednotlivých poloţek. V tabulce tab. 7 jsou hodnoty pro oba typy videa SD i HD. Tab. 7 Bez QoS, MPEG4 max jitter (ms) avg. jitter (ms) Bez QoS MPEG4 SD lost (%) delay (ms) avg. web page download time (s) download file (MB) avg. downlad (Mbit/s) Voice 21,21 10,218 0, ,197 Video 44,23 12,416 1, ,197 Data 4,127 40,3 8,832 HD max jitter (ms) avg. jitter (ms) lost (%) delay (ms) avg. web page download time (s) download file (MB) avg. downlad (Mbit/s) Voice 26,13 16,946 0, ,197 Video 88,45 10, ,462 Data 2,314 37,8 8,354