Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO

Transkript

1 FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Garant předmětu: Doc. Ing. Vladislav Škorpil, CSc. Autoři textu: Doc. Ing. Vladislav Škorpil, CSc. Ing. Petr Vychodil Doc. Ing. Vladimír Kapoun, CSc. BRNO * 2014 Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/ Evropského sociálního fondu a státním rozpočtem České republiky.

2 2 FEKT Vysokého učení technického v Brně Autor Doc. Ing. Vladislav Škorpil, CSc., Ing. Petr Vychodil Doc. Ing. Vladimír Kapoun, CSc. Název Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Vydavatel Vysoké učení technické v Brně Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací Technická 12, Brno Vydání první Rok vydání 2014 Náklad elektronicky ISBN Tato publikace neprošla redakční ani jazykovou úpravou.

3 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 3 Obsah 1 ÚVOD TELEKOMUNIKAČNÍ SLUŽBY HLEDISKA KATEGORIZACE 2.2 RŮZNÉ MOŽNOSTI DĚLENÍ 2.3 POHLED VYBRANÝCH ZÁKONŮ 2.4 INTEGROVANÉ SLUŽBY DIGITÁLNÍCH SÍTÍ 2.5 ASYNCHRONNÍ PŘEPRAVNÍ ZPŮSOB TECHNOLOGIE XDSL TELEKOMUNIKAČNÍ SLUŽBY POSKYTOVANÉ INTERNETEM Voice over IP IPTV (Internet Protocol Television) VYBRANÉ TOPOLOGIE SÍTÍ IP TELEFONIE AUDIO KODEKY PRO IP TELEFONII Terminály internetové telefonie Kvalita hovorů Doporučení ITU-T pro kodeky ANALÝZA KODEKŮ Analýza pomocí analyzátoru LE-580FX Analýza pomocí síťového analyzátoru FLUKE SIMULACE MULTICASTOVÉHO PŘENOSU PŘÍPRAVA VIRTUÁLNÍHO STROJE Instalace VMware Playeru VYTVOŘENÍ VIRTUÁLNÍHO OPERAČNÍHO SYSTÉMU LINUX INSTALACE OMNET IMPLEMENTACE PROJEKTU INET-HNRL SIMULACE MULTICASTOVÉHO PROVOZU Otevření simulačního modelu a popis souborů SIMULACE TECHNOLOGIE DIFFSERV POSTUP ŘEŠENÍ 5.2 VÝSLEDKY GENERÁTOR SÍŤOVÉHO PROVOZU VYPRACOVÁNÍ ZADÁNÍ SIMULACE BEZDRÁTOVÉ SÍTĚ POSTUP IMPLEMENTACE SLUŽEB QoS Bez QOS DOSAŽENÉ VÝSLEDKY 8 MULTIMÉDIA NA INTERNETU METODY VYSÍLÁNÍ MULTIMÉDIÍ Unicast Broadcast... 75

4 4 FEKT Vysokého učení technického v Brně Multicast RealMedia QucikTime Windows media Youtube live video streaming Black Magic Video Streaming Audio data Audio a snímky Video Animace Živé vysílání Komprese statistických obrazových dat Popis standardu JPEG (Joint Photographic Experts Group) MPEG Moving Picture Experts Group Komprimační technologie ve zkratce Streamování multimediálního přenosu pomocí síťového Enkodéru Popis programu VideoLanClient Technologie vytvoření streamovacího serveru Popis CGI skriptu STREAMOVACÍ FORMÁTY 8.3 OBSAH MULTIMEDIÁLNÍCH DAT 8.4 KOMPRESE OBRAZOVÝCH DAT 9 METODOLOGIE TESTOVÁNÍ V TELEKOMUNIKAČNÍCH SÍTÍCH ÚVOD DOPORUČENÍ ITU-T Y.1564, TESTOVACÍ METODOLOGIE AKTIVACE SLUŽEB ETHERNET Shrnutí Úvod Rozsah Reference Definice termíny definované v tomto doporučení Konvence Síťová architektura Ethernet Atributy služby Ethernet Profil šířky pásma Testovací metodologie aktivace služeb Ethernet REQUEST FOR COMMENTS: 2544, SROVNÁVACÍ METODIKA PRO SÍŤOVÁ PROPOJOVACÍ ZAŘÍZENÍ Abstrakt Úvod Testy, které mají být provedeny Vyhodnocení výsledků Požadavky Testovací zapojení Zapojení DUT Formáty rámců Velikosti rámců Velikosti rámců pro použití v Ethernet Velikosti rámců pro použití v 4Mb a 16Mb Token Ring

5 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Velikosti rámců pro použití v FDDI Velikosti rámce v přítomnosti nesourodých MTUs Modifikátory Broadcast rámce Řídící rámce Rámce aktualizace směrování Filtry Adresy filtru Adresy protokolu Nastavení trasy Obousměrný provoz Jednosměrný tok Více portů SEZNAM POUŽITÉ LITERATURY

6 6 FEKT Vysokého učení technického v Brně 1 Úvod Předkládaná skripta Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO jsou určena především pro předmět Služby telekomunikačních sítí, který je zařazen jako odborný volitelný do letního semestru prvního ročníku magisterského studia oboru Telekomunikační a informační technika. Hlavní specifickou vlastností těchto skript je, že byla zpracována s podporou vzájemných diskusí mezi pojetím tohoto předmětu na Vysokém učení technickém v Brně a na Vysoké škole báňské Technické univerzitě Ostrava. Předmět Služby telekomunikačních sítí (MSTS, LSTS) je zařazen v letním semestru prvního ročníku řádného denního i kombinovaného magisterského studia oboru Telekomunikační a informační technika jako volitelný oborový a každoročně si jej zapisuje okolo 50 studentů. Partnerský předmět na VŠB-TUO se jmenuje Komunikační systémy v korporátních sítích pro integrovanou výuku VUT a VŠB-TUO [1]. Skripta se zabývají telekomunikačními službami z hlediska kategorizace, vybraných zákonů, popisuje základy ISDN, ATM, xdsl a zmiňuje se o telekomunikačních službách poskytovaných Internetem. Další kapitola je věnována IP telefonii se zaměřením na audiokodeky. Problematika je oživena simulacemi multicastového přenosu, technologie Diffserv a bezdrátové sítě. Nejrozsáhlejší rozbor obsahují závěrečné dvě kapitoly. Předposlední kapitola se věnuje multimédiím na Internetu s uvedením metod vysílání multimédií, streamovacích formátů, obsahu multimediálních dat a komprese obrazových dat. Poslední kapitola je určena pro metodologii testování v telekomunikačních sítích s rozborem doporučení ITU-T Y.1564 pro aktivaci služeb Ethernet a RFC 2544 pro síťová propojovací zařízení.

7 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 7 2 Telekomunikační služby Tato kapitola byla zpracována především za přispění [2], [3], [4], [5]. Telekomunikační službou nazýváme přenos informací v podobě signálů, které nesou zvukové, textové nebo obrazové informace telekomunikačním systémem, který se skládá ze tří základních částí. První částí je vysílač, který zpracovává informace pro přenos telekomunikačním kanálem. Druhou částí je přenosová cesta charakterizovaná především přenosovým médiem, obvykle jde o metalický kabel, optické vlákno nebo bezdrátový přenos. Třetí částí je přijímač určený k příjmu signálu a jeho zpracování do uživatelsky přijatelné podoby. Aby bylo možno hovořit o telekomunikační službě, musí být uvažovaný přenos informací určen k uspokojení nějakých potřeb uživatelů. Služby telekomunikačních sítí postupně přecházejí ve služby konvergovaných sítí, protože již delší dobu probíhá v této oblasti integrace a konvergence klasických telekomunikačních sítí, kde byl hlavní službou telefonní hovor v telefonní síti s přepínáním okruhů a počítačových sítí, kde je hlavní současnou technologií vysokorychlostní Ethernet a sním související paketový přenos dat. Přenos po metalickém páru zůstává v podstatě už jenom na poslední míli kdežto jinde i v přenosové síti a především v síti transportní významně převládá přenos po optických vláknech. Kromě toho se významně využívá bezdrátový přenos a např. rozvoj mobilních telefonů je obrovský. Za definici telekomunikační služby lze pokládat, že jde o schopnost komunikačního systému poskytovatele telekomunikačních služeb a jeho přenosového systému poskytnout koncovému odběrateli služeb předem stanovené informace prostřednictvím telekomunikačního systému ve stanovené kvalitě a dostupnosti. Rozlišují se služby základní (nosné), přídavné a doplňkové. V současnosti samostatná telekomunikační síť založená na propojování okruhů pozvolna zaniká a je nahrazována sítí konvergovanou, která je založena na propojování paketů. Hlavní klasickou telekomunikační sítí je síť telefonní, která má základní neboli nosnou službu přenos telefonního hovoru. Její přídavnou službou může být datový přenos pomocí modemů, doplňkovou službou např. identifikace volajícího. Jiné dělení služeb je na bázi vztahu poskytovatel účastník. Jde o služby veřejné, které může využívat kdokoli. Poskytovat je může pouze poskytovatel, který splňuje předepsaná kritéria a kterému Český telekomunikační úřad udělil patřičnou licenci. Dále jde o služby uživatelské, které může využívat pouze uživatel, který je členem uživatelské skupiny. Často je

8 8 FEKT Vysokého učení technického v Brně tento druh služeb je poskytován v rámci počítačových sítí (LAN, MAN), pro jejich poskytování nemusí být vždy nezbytně nutné předem získat potřebou licenci a dostupnost těchto služeb je limitována sítí, ve které je poskytována. 2.1 Hlediska kategorizace Hledisko způsobu zpracování informace: analogové (např. klasická telefonní síť, modem). Analogové služby stále ztrácejí na významu a jsou nahrazovány službami digitálními, digitální (např. datová síť, VoIP-Voice over Internet Protocol, ISDN-Integrated Services Digital Network) a v současnosti téměř všechny služby, se kterými se uživatel setká, jsou digitální. Hledisko telekomunikačního regulačního úřadu (v České republice ČTU-Český telekomunikační úřad): pevně vymezené (rezervované) služby telefonního charakteru, oblast regulovanou licenčními podmínkami, především regulaci rádiových kmitočtů licenčními ujednáními (televizní a rozhlasové vysílání, mobilní komunikace), oblast volného působení při dodržení norem a předpisů (uživatelské sítě a jejich služby). Hledisko vyvíjejících se potřeb uživatelů: základní telefonní služby, kam patří především služba klasického telefonního hovoru v telekomunikační síti, rozšířené telefonní služby, které jsou nadstavbou základní telefonní služby a jedná se o služby s přidanou hodnotou, což jsou nové služby, které využívají principy služby základní (např. datové služby přenášené v telefonní síti) a služby doplňkové, které zdokonalují základní službu (např. přenos a zobrazení čísla volajícího a volaného, volání na účet volaného, přesměrování hovoru, zaznamenání hovoru, atd.), telematické datové služby, které integrují principy telefonní a počítačové sítě. Telematické služby se uplatňují pro libovolné účastníky, ale často se nepřesně telelematickými službami rozumí služby v dopravě. Jedná se o služby textové (již nepoužívaný teletex neboli dálnopis překonaný a nahrazený především em), obrazové (přenos dokumentů a statických obrazů, telefax), audiovizuální (přenos

9 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 9 zvuku a obrazu, např. videokonference), kombinované (kombinují textové a obrazové služby) a ostatní (např. telemetrie, tedy přenos výsledků měření). Moderní součástí telematických služeb jsou multimediální datové služby, jejichž rozmach nastal s rozvojem počítačových sítí (LAN-Local Area Network, WAN- Wide Area Network, MAN-Metropolita Area Network) a má vyšší přenosové nároky na dostupnost služeb. Příkladem multimediálních datových služeb je internetová telefonie (VoIP- Voice over Interent Protocol), internetové televizní vysílání (IPTV- Internet Protocol Television), poskytování internetového připojení (ISP Internet Service Provider) a další. Hledisko možnosti počtu současně komunikujících uživatelů: bod-bod, tedy běžná komunikace dvou uživatelů, bod-více bodů (centralizované) neboli broadcasting (televizní a rozhlasové vysílání, hromadná korespondence apod., více bodů-více bodů (decentralizované), např. P2P (peer to peer) sítě, videokonference, počítačové hry apod. Hledisko dostupnosti služeb: pevné, např. služby poskytované v sítích LAN, internetové služby, digitální služby integrovaných sítí ISDN, služby asynchronních sítí ATM, mobilní, např. služby GSM, služby bezdrátových paketových sítí (WiFi).

10 10 FEKT Vysokého učení technického v Brně 2.2 Různé možnosti dělení Na obr. 2.1 vidíme jedno z možných dělení, a to na telekomunikační služby prostřednictvím pevné sítě, mobilní a bezdrátové telekomunikační služby a satelitní telekomunikační služby. Všechny mohou být typu on-line nebo off-line. Obr. 2.1: Možnost dělení telekomunikačních služeb. Obr. 2.2 rozděluje telekomunikační služby prostřednictvím pevné sítě, obdobně však platí i pro mobilní a bezdrátové i satelitní telekomunikační služby. Ty mohou být hlasové, telematické a přenosu dat. Nejzajímavější jsou telematické služby, které v sobě sdružují původní služby telekomunikační mimo služby telefonní a přenosu dat (a také služby telegrafní, které již byly v ČR zrušeny). Pod pojmem telematická služba rozumíme služby společné pro komunikace a informatiku, tedy služby konvergovaných sítí. Telematické služby mohou být textové (např. teletex (dříve dálnopis) v ČR též již neposkytovaný), obrazové (např. telefax neboli fax, dříve velmi populární, dnes nahrazován em), kombinované (telewriting neboli psaní na dálku, příliš se nevžilo), audio-vizuální (telekonference a videokonference jsou velmi populární a jejich význam stále roste, nahrazují dražší klasické konference a workshopy) a další služby, vesměs multimediálního charakteru.

11 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 11 Obr. 2.2: Telekomunikační služby prostřednictvím pevné sítě. Na obr. 2.3: jsou telekomunikační služby děleny na základní (tedy nosné) a přídavné a na služby doplňkové. V dnešní době existují v ČR v oblasti sítí a služeb v klasických komunikacích (s přepínáním okruhů), tedy bez uvažování informačních sítí tři sítě a to telefonní, veřejná datová a digitální integrovaných služeb. Dříve se provozovala ještě integrovaná telegrafní síť. Základní (nosná) služba je ta, pro kterou je síť primárně určena (tedy např. v telefonní síti služba telefonního hovoru), přídavná služba představuje další služby, které lze v síti provozovat, ačkoli pro ně nebyla primárně určena (např. v telefonní síti přenos dat) a doplňkové služby jsou další služby, které poskytovatel zavádí zejména podle zájmu uživatelů (např. volání na účet volaného, identifikace čísla volajícího nebo volaného, rychlá volba, informace o zpoplatnění a mnohé další). Tyto doplňkové služby jsou velmi rozšířeny především u mobilních operátorů, ale postupně jsou zaváděny i v pevné síti.

12 12 FEKT Vysokého učení technického v Brně Obr. 2.3: Základní, přídavné a doplňkové služby. Na obr. 2.4 je znázorněno propojování služeb mezi operátory. Obr. 2.4: propojování služeb mezi operátory.

13 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Pohled vybraných zákonů Podle Zákona o dani z přidané hodnoty č.235/2004 ze dne , paragraf 10h, je telekomunikační služba spojená s přenosem, vysíláním nebo příjmem signálů, textových dokumentů, obrazů a zvuků nebo jakékoliv informace s využitím kabelu, rádia, optických nebo elektromagnetických systémů spolu s příslušným přenosem nebo stanovení práva využívat kapacitu pro tento přenos, vysílání nebo příjem nebo přístup k informačním sítím. Lze také konstatovat, že jsou to služby přenosu uživatelské informace mezi dvěma (či více) koncovými uživateli sítě, případně přenos mezi koncovým uzlem a informačním centrem. Přenos je uskutečňován prostřednictvím elektromagnetických vln. Telekomunikační služby jsou většinou poskytovány operátorem, který příslušné služby poskytuje koncovému uživateli. Jednotlivé služby jsou charakterizované svými vlastnostmi, jako např.: dostupnost služby (prostorová a časová), věrnost přenášené informace, bezpečnost přenášené informace, cena služby, spolehlivost služby, atd. Doplňkové služby rozšiřují možnosti služeb základních a zvyšují uživatelský komfort. Fungují výhradně ve spojení se základními službami a nemohou se vyskytovat bez nich samostatně. Příklady doplňkových služeb (Supplementary Services) ISDN: MSN vícenásobné účastnické číslo (Multiple Subscriber Number). CLIP předání identifikace volajícího (Calling Line Identification Presentation). CLIR zamezení předání identifikace volajícího (Calling Line Identification Restriction). HOLD přidržení spojení (Call Hold) a mnohé další. Podle paragrafu 2 zákona č. 127/2005 Sb. o elektronických komunikacích jsou definovány některé pojmy spojené se službami komunikačních sítí.

14 14 FEKT Vysokého učení technického v Brně Služba elektronických komunikací Služba elektronických komunikací je služba obvykle poskytovaná za úplatu, která spočívá zcela nebo převážně v přenosu signálů po sítích elektronických komunikací, včetně telekomunikačních služeb a přenosových služeb v sítích používaných pro rozhlasové a televizní vysílání a v sítích kabelové televize. Veřejně dostupná služba elektronických komunikací Veřejně dostupnou službou elektronických komunikací se rozumí služba elektronických komunikací, z jejíhož využívání není nikdo předem vyloučen. Síť elektronických komunikací Síť elektronických komunikací tvoří přenosové systémy, popřípadě spojovací nebo směrovací zařízení a jiné prostředky, které umožňují přenos signálů po vedení, rádiem, optickými nebo jinými elektromagnetickými prostředky, včetně družicových sítí, pevných sítí s komutací okruhů nebo paketů a mobilních pozemských sítí, sítí pro rozvod elektrické energie v rozsahu, v jakém jsou používány pro přenos signálů, sítí pro rozhlasové a televizní vysílání a sítí kabelové televize, bez ohledu na druh přenášené informace. Zajišťování sítě elektronických komunikací Zajišťování sítě elektronických komunikací představuje zřízení sítě elektronických komunikací, její provozování a dohled nad ní nebo její zpřístupnění. Veřejná komunikační síť Veřejná komunikační síť je síť elektronických komunikací, která slouží zcela nebo převážně k poskytování veřejně dostupných služeb elektronických komunikací. Operátor Operátor je podnikatel, který zajištuje nebo je oprávněn zajišťovat veřejnou komunikační síť nebo přiřazené prostředky Účastník Účastník je každý, kdo uzavřel s podnikatelem poskytujícím veřejně dostupné služby elektronických komunikací smlouvu na poskytování těchto služeb.

15 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 15 Koncový uživatel Koncový uživatel je uživatel, který nezajišťuje veřejné komunikační sítě nebo veřejně dostupné služby elektronických komunikací. Spotřebitel Spotřebitel je každá fyzická osoba, která využívá nebo žádá veřejně dostupnou službu elektronických komunikací pro účely nebo mimo rámec její podnikatelské činnosti. Veřejně dostupná telefonní služba Veřejně dostupná telefonní služba je veřejně dostupná služba elektronických komunikací umožňující uskutečňování národních a mezinárodních volání a přístup k číslům tísňového volání prostřednictvím jednoho nebo více čísel číslovacího plánu. Veřejná telefonní síť Veřejná telefonní síť je síť elektronických komunikací, která slouží k poskytování veřejně dostupných telefonních služeb a která umožňuje mezi koncovými body sítě přenos mluvené řeči a také i jiných forem komunikace, jako je faximilní a datový přenos. Volání Volání je spojení uskutečněné prostřednictvím veřejně dostupné telefonní služby, která umožňuje obousměrnou komunikaci v reálném čase 2.4 Integrované služby digitálních sítí Základem Integrovaných služeb digitálních sítí ISDN (Integrated Services Digital Network) je digitální technologie použitá již od účastníka a tedy v přístupové síti. K A/D a následně D/A přenosu dochází tedy u účastníka, zatímco u jiných technologií přenosu dat od účastníka vlastnícího klasickou telefonní přípojku Hz (např. xdsl) se digitalizuje až v první veřejné telefonní ústředně. Myšlenkou ISDN je integrace všech služeb do jediné univerzální sítě. K základní ISDN přípojce lze připojit až 8 terminálů. Z toho plyne výhoda této technologie, možnost využívat všechny telekomunikační služby na jediné přípojce. V dnešní době se základní přípojka ISDN příliš nevyužívá, protože se rozvíjejí vhodnější technologie, např. xdsl, které jsou především mnohem levnější a dosahují vyšší přenosové rychlosti.

16 16 FEKT Vysokého učení technického v Brně Přesto nelze ISDN považovat za mrtvou technologii, neboť je vhodná k připojení pobočkových ústředen. Zde se nabízí především primární přípojka 2,048 Mbit/s. Výhodou ISDN je právě propracovanost služeb, které lze jinak zajistit jen obtížně nebo vůbec. ISDN používá klasickou metalickou dvoudrátovou telefonní přípojku Hz. Existují dva typy ISDN rozhraní neboli přístupů a sice základní 2B+D označovaný zkratkou BRI (Basic Rate Interface) nebo BRA (Basic Rate Access) a primární 30B+D označovaný zkratkou PRI (Primary Rate Interface) nebo PRA (Primary Rate Access). U uživatele je ISDN přípojka zakončeno blokem NT (Network Termination), které mění 2-drátové U rozhraní, přes které ISDN linka přichází od veřejné telefonní ústředny, na 4-drátové S/T rozhraní, ke kterému se přímo připojují digitální koncová ISDN zařízení (Terminal). Pro připojení analogových koncových zařízení, která neodpovídají ISDN, je třeba užít terminálový adaptér (TA Terminal Adapter). V síti ISDN jsou definovány dva druhy kanálů. Kanál B, jehož přenosová rychlost je 64 kbit/s je digitální přenosový kanál, schopný přenášet digitalizovaný telefonní hovor i data z jiných zdrojů, např. terminálů, počítačů apod. Kanál D, jehož přenosová rychlost je 16 kbit/s u základní přípojky a 64 kbit/s u primární přípojky. Kanál D je určen pro přenos služebních dat, především signalizace, ale částečně může být využit i pro přenos užitečných dat. Datové B kanály lze sdružovat a to až do přenosové rychlosti kbit/s v násobcích 64 kbit/s. Zmiňme se ještě o vrstvách modelu OSI a doporučení ITU-T pro technologii ISDN, která využívá první tři vrstvy modelu OSI: Fyzická, doporučení I.430 pro BRI a I-431 pro PŘI Spojovací, doporučení Q.921 Síťová, doporučení Q Asynchronní přepravní způsob Další, bohužel především dříve propagovanou technologií, je Asynchronní přepravní způsob ATM (Asynchronous Transfer Mode). ATM má pro potřeby služeb výtečné vlastnosti, zejména progresivně zajišťuje kvalitu služby QoS (Quality of Service), ale v současné praxi je téměř zcela nahrazeno vysokorychlostním Ethernetem (10, 40, 100 Gbit/s) a to z důvodů ceny a také dřívější rozšířenosti Ethernetu od 10 Mbit/s, se kterým se odborná veřejnost více sžila,

17 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 17 Charakteristickou vlastností ATM je skutečnost, že přenos probíhá po buňkách pevné délky 53 bajtů, z čehož je 5 bajtů záhlaví a 48 bajtů informačního pole (payload). Šířka pásma je efektivněji využita pro spojení s více požadavky a vytvářet ATM tok lze z různě kapacitních zdrojů. Za nevýhodu ATM lze považovat, že vlivem konstantní délky buněk, které přibližně z 10% tvoří záhlaví, a proto v případě, že je potřeba přenést větší blok dat dochází k ke zvýšené redundanci. Další nevýhodou je, že pokud je potřeba přenést méně než 48 bajtů, musí se užitečná informace doplnit, čímž klesá účinnost. 2.6 Technologie xdsl xdsl (x Digital Subsriber Line) jsou širokopásmové přenosové technologie, které zahrnují vedle ADSL celou řadu dalších alternativ. Hlavní rozdíl principu xdsl oproti ISDN je, že ISDN uskutečňuje A/D a D/A převod přímo v terminálu, kdežto xdsl zachovává přenos analogového telefonního hovoru Hz a data pomocí modulací převádí do vyšší kmitočtové polohy, kterou je telefonní přípojka schopná přenést. Nejčastěji se využívá diskrétní vícetónová modulace (DMT Discrete Multi Tone). Systémy xdsl existují ve více verzích, které se odlišují přenosovou rychlostí, šířkou využívaného frekvenčního pásma, typem modulace nebo linkového kódu, místem vhodného využití atd. Technologie ADSL (Asymetric Digital Subscriber Line) byla v nedávných letech hlavní technologií používanou pro přenos dat na poslední míli a v podstatě vytlačila starší a dražší ISDN. ADSL vychází z myšlenky, že přenos ze sítě, obvykle Internetu (downlstream) je obvykle co do objemu dat mnohem větší, než přenos od účastníka do sítě (upstream). Proto je ADSL asymetrické, Reálně dosažitelné přenosové rychlosti nejsou uvedeny obecně, protože jsou závislé na délce a kvalitě telefonní přípojky. Kvalita přenosu je u ADSL průběžně v každém dílčím kanálu monitorována (útlum, chybovost, atd.), a na podkladě získaných hodnot se systém snaží adaptivně rozkládat souhrnný datový tok do těch kanálu, které má k dispozici, a které jsou v daný okamžik vhodné pro přenos. Hlasový signál 300 až 3400 Hz je sloučen s modulovaným nosným signálem nesoucím datový tok a oba typy služeb jsou přenášeny po jednom páru vedení. K jejich oddělení dochází v místě příjmu v zařízení nazývaném splitter. ADSL2+ je další vývojovou verzi ADSL. Využití přenosového pásma na metalickém vedení je rozšířeno na dvojnásobek (2,2 MHz). Data ve směru downstream lze směrem k uživateli přenášet rychlostí až 25 Mbps. Realizace vyšších přenosových rychlostí závisí na

18 18 FEKT Vysokého učení technického v Brně útlumu, který s rostoucí délkou vedení pro uvažované rychlosti rychle roste, a proto se ADSL2+ hodí pro kratší účastnické přípojky, které lze očekávat spíše ve městech. HDSL (High Bit-Rate Digital Subscriber Line) je určeno především k propojování telefonních ústředen po metalickém vedení. Přenášené pásmo je pro oba směry přenosu rozděleno symetricky. Realizuje přenosové rychlosti E1 (2,048 Mbit/s) a T1 (1,544 Mbit/s), přenos se uskutečňuje po dvou nebo třech symetrických párech, které jsou využívány souběžně pro oba směry přenosu. Směry přenosu jsou odděleny metodou potlačení ozvěn. Systémy HDSL pracují v základním pásmu a přenášený signál je kódován pravidlem 2B1Q. SDSL (Symmetric Digital Subsriber Line) je vývojovým pokračováním HDSL, ale se zlepšeným linkovým kódem a s omezením na přenos po jednom páru účastnického vedení. c Přenosové rychlosti se pohybují od 192 kbit/s do 2,312 Mbit/s po krocích 8 kbit/s. VDSL (Very High Bit-Rate Digital Subscriber Line) umožňuje asymetrický i symetrický způsob přenosu. Při asymetrickém přenosu se rychlost dosažitelná pro downstream pohybuje v rozmezí Mbit/s a pro upstreamu 1,5 2,3 Mbit/s. Nezávislé informační kanály jsou tříděny pomocí frekvenčního multiplexu. K docílení maximální přenosové rychlosti je žádoucí, aby délka přípojného vedení nepřesáhla 300 m, maximální délka přípojného vedení pro využitelnost VDSL je přibližně 1500 metrů. V systémech VDSL se užívají modulace DMT (Discrete Multi Tone), CAP (Carrierless Amplitude Phase) a DWMT (Discrete Wavelenght Multi Tone). Tab. 2.1 přehledně uvádí vybrané parametry systémů xdsl. Tab. 2.1: Parametry systémů xdsl. Označení Typ Rychlost Dosah Frekvenční Požitá Metoda provozu (up/down) [Mbit/s] [km] pásmo [khz] modulace, kódování duplex. přenosu HDSL DSL (IDSL) symetrický, duplexní symetrický, duplexní 2/2 2 až 3 40 až 292 2B1Q EC 0,128/0,128 cca 3 0 až 50 2B1Q EC ADSL asymetrický 1/8 cca 8 25 až 138 DMT, QAM, FDD EC ADSL 2 asymetrický 1/12 cca až 1104 DMT, FDD

19 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 19 QAM ADSL 2+ asymetrický 1/24 cca až DMT, QAM EC FDD EC ADSL Lite asymetrický 0,5/1,5 cca 7 25 až až 552 DMT FDD EC SDSL symetrický, 2,3/2,3 2 až 5 0 až 384 2B1Q EC SHDSL duplexní 3 až 6 16-PAM VDSL asymetrický, 6,4/52 0,3 až 1,5 300 až 900 QAM., DMT FDD VDSL symetrický, 34/34 0,3 až 1, až QAM., FDD duplexní DMT HDSL High Bit_Rate_Digital Subsribe Line IDSL IDSL Digital Subsribe Line ADSL Asymmetric Digital Subsribe Line SDSL Symmetric Digital Subsribe Line SHDSL Symmetric High Bit Rate Digital Subsribe Line VDSL - Very High Speed Digital Subsribe Line 2B1Q Two Binary One Quaternary (code) DMT - Discrete Multi Tone (modulation) QAM Quadrature Amplitude Modulation 16-PAM 16 discrete levels Pulse Amplitude Modulation EC Echo Cancellation FDD Frequency Divisin Duplex

20 20 FEKT Vysokého učení technického v Brně 2.7 Telekomunikační služby poskytované Internetem Voice over IP Klasická analogová telefonie sice ještě stále v praxi existuje a počet účastníků je celosvětově velký, ale stále více je nahrazována telefonií přes Internet - VoIP (Voice over IP). VoIP je levnější než klasická telefonie, poměrně jednoduše může být doplněna obrazem a má další nezanedbatelné výhody. Pracuje na principu s přepojováním paketů, které musí mít maximální prioritu, aby mohl být realizován duplexní provoz v reálném čase. Pro přenos pomocí IP je důležité využít nabízené pásmo v maximálně možné míře. Používají se vzorkovací algoritmy, které vycházejí ze zákonitostí hlasového signálu (např. ADPCM Adaptive Diferential Pulse Code Modulation) a různé kompresní metody. Vhodná jsou další zařízení, která rozzšířují funkce a dostupnost různých služeb. Jde např. o hlasové brány (VoIP gateway pro SIP), gatekeeper pro H323, konferenční jednotka (MCU) atd. Kvalita a celková spolehlivost telefonního spojení přes VoIP velmi závisí na spolehlivosti a rychlosti použitého internetového připojení. Zejména vysoké zpoždění v sítích může vést k výraznému snížení kvality hovoru a způsobit problémy (např. ozvěny) IPTV (Internet Protocol Television) K příjmu Imternet Protocol Television (IPTV) je potřeba přípojka vysokorychlostního internetu, modem a set-top-box. Všechny televizní kanály se přivádějí do sběrných centrálních míst (DSLAM Digital Subscriber Line Access Multiplexer), odkud je po vysokorychlostním internetu přenášen ke koncovému uživateli pouze jeden jím vybraný program. IPTV umožňuje komunikaci v obou směrech, kromě obvyklého sledování vybraného televizního kanálu poskytuje další služby jako video na přání (Video on Demand), archivy televizních stanic, atd. Výhodou IPTV je také interaktivita (např. hlasování v anketách, sdílení videa a fotografií, apod.). 2.8 Vybrané topologie sítí Kruhová Přenos dat v kruhové síti (Obr. 2.4) je jednoduchý a přidání dalšího uzlu nemá velký vliv na přenášenou šířku pásma. V této topologii nevznikají kolize a náklady jsou menší než u

21 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 21 jiných topologií. Za nevýhody lze pokládat delší dobu trvání přenosu dat, při poruše jednoho počítače se kruh rozpadne a ztížená je lokalizace poruchy. Obr. 2.4: Kruhová topologie. Hvězdicová Na rozdíl od kruhové sítě při poruše jednoho počítače v hvězdicové síti (Obr. 2.5) nepřestává fungovat celá síť. Nedochází zde ke kolizím a data mohou být současně přenášena více počítači. Síť hvězdicové topologie se snadno nastavuje a rozšiřuje, závady lze snadno identifikovat. Za nevýhody lze považovat vyšší nároky na kabeláž a v případě selhání centrálního síťového prvku přestane fungovat celá síť. Obr. 2.5: Hvězdicová topologie.

22 22 FEKT Vysokého učení technického v Brně Stromová Stromová topologie (Obr. 2.6) má nižší potřebu kabeláže, vyznačuje se vyšší mírou bezpečnosti proti odposlouchávání, porucha jednoho počítače se projeví pouze ve větvi, ke které porouchaný počítač patří. Obr. 2.6: Stromová topologie.

23 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 23 3 IP telefonie Kapitola je zpracována za přispění [3], [6], [7], [8]. 3.1 Audio kodeky pro IP telefonii Audio kodeky jsou na vysílací straně určeny k převodu analogového audio signálu na signál digitální a k následné kompresi a jiným úpravám nutným pro přenos. Na přijímací straně jsou pak nutné inverzní procesy, jako např. dekomprese, převod na analogový signál atd. Komprese je u audio kodeků navržena zpravidla podle vlastností lidského sluchu a pomocí různých více či méně sofistikovaných metod zpracování signálu. Výsledkem je snížená šířka přenosového pásma při zachování požadované kvality hovoru a přijatelné výpočetní náročnosti. Pro internetovou telefonii se vžila zkratka VoIP (Voice over Interent Protocol). Jde o technologii, která umožňuje přenos hlasu po celosvětovém Internetu a zároveň o službu, která postupně vytlačuje klasickou telefonii po klasické telekomunikační síti, neboť VoIP je zejména levnější při zachování požadavků uživatelů na kvalitu služby. Uživatel k využití služby VoIP potřebuje softwarový nebo hardwarový IP telefon. Mohl by využít také klasický analogový telefon s VoIP bránou, ale tato alternativa je zpravidla méně výhodná. Podstatné je, že klasická telefonní síť využívá spojování okruhů (spojově orientovaný způsob), kdy okruh je vytvořen na začátku spojení a hovor pak po tomto okruhu probíhá, kdežto VoIP využívá spojování paketů (nespojově orientovaný způsob), při kterém jsou pakety přenášeny sítí podle okamžité situace v síti. Hlavní nevýhodou spojování okruhů je zejména nepružné přidělení pásma, výhodou naopak neměnnost vlastností vytvořeného kanálu během celé délky trvání hovoru. Nevýhodou spojování paketů je možnost ztráty či přílišného zpoždění paketu a přijetí paketů v jiném pořadí, než byly vyslány. Přenos zvuku popřípadě videa nebo obecně dat v reálném čase podporují různé protokoly: Multicast Internet Protocol, který je určen pro přenos informace z jednoho zdroje více cílům, Real-Time Transport Protocol (RTP), který zavádí číslování paketů, časové známky, označení typu obsahu a další. RTP Control Protocol (RTCP), který monitoruje kvalitu RTP spojení.

24 24 FEKT Vysokého učení technického v Brně Resource Reservation Protocol (RSVP) rezervuje síťové prostředky mezi odesílatelem a příjemcem. Real-Time Streaming Protocol (RTSP) podporuje doručení dat v reálném čase. Session Description Protocol (SDP) popisuje vlastnosti relace multimediálního přenosu, obsahuje např. název relace, čas aktivity relace, zda se jedná o hlas, video, nutnou šířku pásma apod. Session Announcement Protocol (SAP), identifikuje otevřené relace. Výše uvedené protokoly mají kladný vliv na aplikace v reálném čase a na koexistenci původně spojově a nespojově orientovaných způsobů propojování Terminály internetové telefonie Hardwarový telefon, který se většinou nazývá VoIP telefon nebo SIP telefon. Jeho vzhled je podobný běžnému analogovému telefonu, ale je vybaven pro přenos pomocí IP. Softwarový telefon představuje obvykle běžný počítač, notebook apod. s nainstalovaným software telefonu a možností vysílat a přijímat zvuk.. Brána (Gateway), převádí klasický analogový telefonní provoz PSTN do protokolu IP. Umožní to využít stávajících analogových telefonů ve funkci VoIP telefonu a naopak. Brána VoIP má buď formu externího zařízení nebo karty do počítače. Správce (Gatekeeper). Na několik terminálů lze pohlížet jako na skupinu terminálů, neboli zónu, pro kterou je vhodné vyhradit funkci správce. Správce sbírá informace o všech terminálech zóny, které využívá k sestavování hovorů. Správce obvykle za pomoci signalizace sestavuje spojení a řídí hovor. Vlastní datový přenos (hovor) je uskutečněn přímo mezi terminály způsobem peer-to-peer (tedy bez serveru), pokud si např. velké zatížení nevyžádá přesměrovat hovor přes správce. Správce existuje v hardwarové i softwarové formě a především udržuje a překládá IP adresy terminálů, hovory směruje a přiděluje přenosové pásmo. Lze tím lépe využít přenosovou kapacitu sítě, což se s výhodou využije zejména u rozsáhlých telekomunikačních sítí. V případě, že správce není nasazen, komunikují terminály přímo mezi sebou (to je u rozsáhlých sítí značně neefektivní Kvalita hovorů Kodeky navržené podle různých doporučení dosahují různou kompresi bitového toku, čímž je ovlivněna výsledná kvalita hovoru, a tím i parametr MOS (Mean opinion score), který slouží k subjektivnímu hodnocení kvality. Parametr MOS může dosáhnout maximálně

25 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 25 hodnoty 5 a hraniční hodnotou pro nasazení v oblasti VoIP je 2,6. Kvalita hovoru, která je ohodnocena nižším číslem, se tedy považuje za neuspokojivou (Tab. 3.1., Tab. 3.2) Tab. 3.1: Přehled kvality hovorů a odpovídající hodnoty MOS. MOS Kvalita Hodnocení 5 Vynikající Nepostřehnutelné chyby 4 Dobrá Postřehnutelné, ale nerušící 3 Ucházející Lehce rušící 2 Špatná Rušící 1 Velmi špatná Velmi rušící Tab. 3.2: Porovnávané kodeky, potřebná šířka pásma a kvalita hovoru. Doporuče Algoritmu CBR NEB MOS ní s [kbit/s] [kbit/s] [-] G.711 PCM 64 87,2 4,1 G.729 CSACEL P 8 31,2 3,92 ilbc LPC 15 27,7 4,14 PCM Pulse Code Modulation ACELP Conjugate Structure Algebraic Code Excited Linear Prediction LPC Linear Predictive Coding CBR Constant Bit Rate NEB Nominal Ethernet Bandwidth MOS - Mean Opinion Score

26 26 FEKT Vysokého učení technického v Brně G.107) Místo parametru MOS lze používat též tzv. R-factor (Rating factor dle doporučení R-faktor lépe vystihuje komplexnost a složitost soudobých moderních sítí a systémů. Lineární prediktivní kódování (Linear Predictive Coding LPC) představuje kódovací algoritmus ztrátové komprese. Pomocí LPC je možno významně snížit přenosovou rychlost. Využívá se skutečnost, že lidská řeč se skládá ze zvukových elementů, které se opakují, a proto je možno sestavit kódovací knihu, tedy databázi jednotlivých zvukových elementů. Hlas se pak porovnává s uvedenou databází a přenáší se odkazy na příslušné elementy s vybranými charakteristickými informacemi o hlasu. Zpětná syntéza pak vykazuje velkou shodu s původním hlasem. Protokol SCCP (Skinny Client Control Protocol) je jedním z mnoha protokolů využívaných pro VoIP (SIP, rodina H.323, MGCP Media Gateway Control Protocol). Jedná se o proprietární protokol společnosti Cisco typu klient-server. Používán je pro komunikaci koncových zařízení s aplikací Cisco UCM (Unified Communications Manager), využití je tedy především pro zařízení Cisco. Každá událost koncového zařízení (vyzvednutí mikrotelefonu, volba apod.) je jako zpráva odeslána do aplikace UCM, které ji vyhodnotí a odpovídající instrukci pošle zpět koncovému zařízení. Protokol je kompatibilní s protokolem H.323. Protokol SIP (Session Initiation Protocol) představuje na principech www postavenou alternativu k rodině H.323. SIP se výhodně používá u bran a proxy serverů, je typu peer-topeer. Protokol se velmi snadno implementuje a odstraňují se eventuální komplikace, neboť využívá ASCII kódu. Aplikace UCM pouze potvrzuje, jestli existuje komunikace mezi ní a branou SIP a neřídí tedy zařízení založená na SIP Doporučení ITU-T pro kodeky Kodek dle doporučení ITU-T G.711 je v klasické digitální telefonii využíván nejvíce. Kódování a dekódování je zajištěno Pulsně kódovou modulací (Pulse Code Modulation PCM) a byl navržen pro hovorový signál, hodí se tedy pro potřeby VoIP. Pro kompresi G.711 je v Evropě používaná charakteristika typu A (A-law, a=84,7) a Americe charakteristika typu mí (mí-law, mí=100), obě s logaritmickým kódováním, které vychází ze skutečnosti, že lidské ucho je na změnu intenzity citlivější při nižších úrovních

27 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 27 signálu než při vyšších. Jeden digitalizovaný hovorový kanál je přenášen osmibitovým kódem s rychlostí 64 kbit/s. Kodek dle doporučení G.718 byl schválen v roce Je určen pro úzkopásmové (Narrow-band NB) a širokopásmové (wide-band WB) kódování řeči a obecně zvuku o proměnné bitové rychlosti 8-32 kbit/s s odolností proti chybám rámců. Zajišťuje vysokou kvalitu přenosu hlasu v pevných, bezdrátových i mobilních sítích. Kodek G.718 se vyznačuje rozšiřitelnou strukturou, která umožňuje velkou pružnost splnit různé požadavky. Kodér vytváří pevně daný bitový tok, který je strukturován do pěti vrstev pevně daných rychlostí 8, 12, 16, 24 a 32 kbit/s. Kodek G.722 je využitelný pro audio signál 50Hz 7000 Hz a operuje s třemi módy, které odpovídají přenosovým rychlostem 64, 56 a 48 kbit/s. Maximální přenosová rychlost je tedy 64 kbit/s a dvě nižší rychlosti lze doplnit pomocným datovým kanálem 8 a 16 kbit/s. Použita je subpásmová adaptivní diferenční pulsně-kódová modulace (SB-ADPCM). Kodek G.722 je poměrně oblíbený, i když již starší (1988) a jeho použití je bezplatné. Kodek dle doporučení G je určen pro přenos hlasu s kompresí při multimediální komunikaci dvěma rychlostmi a sice 5,3 a 6,3 kbit/s. Také nižší přenosová rychlost se vyznačuje dobrou kvalitou a mezi oběma rychlostmi lze mezi nimi kdykoli přepínat. Kodér je vhodný zejména pro kódování řeči ve vysoké kvalitě při omezené složitosti, jiné audio signály lze kódovat také, i když kodér G pro ně není primárně určen. Kodér používá lineární predikci s minimalizací vjemově váženého chybového signálu. Rámce využité v kodéru obsahují 240 vzorků, délka rámce je 30ms, vzorkovací frekvence 8 khz. Rámec se rozděluje na 4 subrámce po 60 vzorcích, na každý subrámec je aplikován LPC filtr 10 řádu. Kodek dle doporučení G.726 využívá adaptivní diferenční pulsně kódovou modulaci ADPCM a poskytuje přenosové rychlosti 16, 24, 32 a 40 kbit/s na jeden kanál. Doporučení nahrazuje starší doporučení G.721 a G.723. Hlavní využití je předpokládáno ve snížení přenosové rychlosti 64kbit/s podle doporučení G.711 a kompresí typu A (A-law) nebo mí (mí-law) do kanálu (nebo z kanálu) 16, 24, 32, 40 kbit/s. Nejvyužívanější je přenosová rychlost 32 kbit/s, která zdvojnásobí kapacitu kodeků G.711 při téměř nezměněné kvalitě (kvantizačním zkreslení).

28 28 FEKT Vysokého učení technického v Brně Kodek dle doporučení G.727 opět využívá ADPCM a to se vzorky kódované 2, 3, 4 nebo 5 bity a rozšiřuje doporučení G.726. Přenosová rychlost vycházející z počtu bitů (2, 3, 4, 5) při vzorkovací frekvenci 8 khz je stejně jako u doporučení G.726 rovna 16, 24, 32, 40 kbit/s. Použité algoritmy ADPCM jsou rozšířením algoritmů ADPCM používaných v doporučení G. 726 a jsou vhodné pro paketové řečové systémy PVP (Packetized Voice Protocol) specifikované především v G.764. PVP odstraňuje zahlcení systému pomocí změny velikosti řečového paketu. Děje se tak zjednodušeně řečeno neuvažováním nejméně významného bitu (bitů) každého zakódovaného vzorku. Tato metoda vykazuje lepší výsledky než zahazování celých paketů při zahlcení, není potřebná ani koordinace vysílače s přijímačem. Kodek dle doporučení G.728 dosahuje přenosovou rychlost 16 kbit/s při použití LD- CELP (Low-delay Code Excited Linear Prediction), tedy kódování s nízkým zpožděním opět s využitím lineární predikce. Užita je zpětná modifikace prediktorů a zisku k dosažení algoritmického zpoždění 63,5 mikrosekundy. Kodek dle doporučení G.729 je určen pro kódování audio signálu 20 Hz 20 khz s vysokou kvalitou včetně vícekanálového zvuku při celkově zjednodušeném uspořádání, kvalitu lze srovnávat např. s MP3. Přenosová rychlost je kbit/s. G.719 vychází z G a je licencováno. Kodek ilbc (Internet Low Bit Rate Codec)je ztrátový open source kodek pro kompresi hlasu s konstantní přenosovou rychlostí CBR (Constant Bit Rate) 15,2 nebo 13,3 kbit/s, vzorkovací kmitočet je 8kbit/s. 3.2 Analýza kodeků Výše uvedené kodeky mohou být analyzovány. K analýze je možné použít různé softwarové i hardwarové analyzátory, zde se zmíníme o využití LAN analyzátoru LE-580FX (obr.3.1) spolu s programem Wireshark a alternativou bude síťový tester Fluke NetTool Series 2 (obr. 3.3). Nepřekvapuje, že nejefektivnější byla analýza pomocí oblíbeného nástroje Wireshark.. Porovnáváme zpoždění, jiter, ztrátovost, ozvěnu a věrnost reprodukce. Zpoždění (Latency) představuje celkové zpoždění od zahájení řeči v místě A a přijetím řeči v místě B. Podle příslušného doporučení je bez výhrad přijatelné zpoždění do 150 ms, mezi 150 ms a 400 ms je třeba věnovat otázce zpoždění zvýšenou pozornost a nad 400 ms je

29 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 29 zpoždění nepřijatelné. Zpoždění se dělí na pevné a proměnné. Pevné zpoždění se v průběhu hovoru prakticky nemění, protože vychází z A/D převodu, komprese, paletizace, paralelněsériového převodu, zpoždění na síťových prvcích apod. Proměnné zpoždění vychází z aktuálního stavu sítě, tedy ze zpoždění ve frontách vyrovnávacích pamětí, ze vzdálenosti, kterou musí paket urazit apod. Jitter (časová nestálost, chvění). Jedná se o odchylku okamžiku aktuálního přijetí paketu od očekávaného okamžiku přijetí. To, že se skutečný okamžik přijetí paketu liší od okamžiku teoreticky očekávanému je způsobeno různými vlivy, např. zahlcením sítě, různou vzdáleností, kterou paket urazí. Jitter se nejsnáze eliminuje vyrovnávací pamětí. Ztrátovost je patrně nejdůležitější parametr. Hlasové pakety jsou ztráceny kvůli zahlcení sítě, velkému jitteru apod. Ozvěna je dána různými odrazy, impedančním nepřizpůsobením apod. Ozvěna je přítomna vždy, obvykle však není rušivá. Věrnost reprodukce zvuku je dána porovnáním vstupního a výstupního zvukového signálu. Šířka přenosového pásma omezuje šířku pásma zvuku. Obvykle je věrnost reprodukce zvuku přijatelná Analýza pomocí analyzátoru LE-580FX LE-580FX je analyzátor sítě, pomocí kterého lze zachytit celkovou kopii provozu procházejícího porty analyzátoru, tedy jedním vstupním a jedním výstupním portem RJ-45. K počítači lze analyzátor připojit pomocí rozhraní USB. Obr. 3.1: Analyzátor sítě LE-580FX.

30 30 FEKT Vysokého učení technického v Brně Analyzátor sítě LE-580FX umožňuje kontrolovat použité protokoly a data, analyzovat provoz, zprostředkovávat statistické informace, zejména chybovost, šířku pásma, generování testovacích paketů, měření parametrů kvality služby QoS (Quality ofservice) atd.. Provoz lze zachytávat pomocí softwarového protokolového analyzátoru Wireshark, při jehož využití se LE-580FX projevuje jako klasická síťová karta. V našem případě byla nutná Wireshark verze Obr. 3.2: Zapojení analyzátoru LE-580FX. Předpokládejme zapojení dle obr Provoz řídí konfigurační počítač, pořadí bloků je telefon 7975G, směrovač CE-VoIP, analyzátor FE-580FX a druhý telefon 7975G. Analyzátor se v programu Wireshark chová jako síťová karta. Zachytávání provozu bylo aktivováno nejjednodušším možným způsobem, tedy běžným hovorem mezi oběma telefony. Pro komunikaci mezi IP Cisco telefony a UCM (Unified Call Manager) byl použit protokol SCCP, provoz byl sledován programem Wireshark. Po ukončení provozu byly zachycené pakety analyzovány a následně byl změněn využitý kodek (na směrovači VoIP) a vše se znovu opakovalo. Pomocí programu Wireshark byly vytvořeny výstupní průběhy vybraných parametrů, např. využití šířky pásma v závislosti na čase pro kodeky dle doporučení G.711, G.729 a ilbc. Výsledky odpovídají předpokladům, větší režie daná kratší délkou použitého rámce se projevila poněkud zvýšenou šířkou přenášeného pásma hovoru.

31 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 31 Jako další byla realizována analýza toku paketů RTP (Real-time Transport Protocol), pochopitelně také pomocí programu Wireshark. Obdrželi jsme tak časové průběhy zpoždění a jitteru pro kodeky dle doporučení G.711 a G.729, kodek ilbc není implementován do programu Wireshark, a proto není ve výsledcích uveden. Výpis toků RTP je realizován pro oba směry provozu každého kodeku (G.711 a G.729) s uvedením IP adresy a portů zdroje i cíle, počtu přenesených a zahozených paketů, maximální zpoždění a maximální jitter. Zpoždění je prakticky konstantní, protože měření bylo realizováno v lokální síti, a neprojevila se např. ztráta paketů způsobená zahlcením sítě, doručení paketů v odlišném pořadí než v pořadí vyslání, proměnné zpoždění při průchodu sítí WAN apod. Vzhledem k dříve uvedeným limitům pro zpoždění (do 150 ms bez omezení, nad 400 ms nepřijatelné) je možno naměřené celkové zpoždění okolo 20ms uvažovat jako zanedbatelné Analýza pomocí síťového analyzátoru FLUKE Fluke NetTool Series 2 Inline network tester (obr. 3.3) je určen k vyhledávání poruch v síti a v zařízeních do sítě zapojených včetně přenosového média. V tzv. reportu na připojeném počítači zobrazuje sledované parametry hovoru a to jak v reálném čase tak pro pozdější zpracování. Obr. 3.3: Síťový analyzátor Fluke NetTool Series 2 Inline.

32 32 FEKT Vysokého učení technického v Brně Co se portů týče, má analyzátor Fluke NetTool Series 2 Inline dva porty RJ-45 a jeden port mikro USB pro připojení k počítači. Jeden port RJ-45 byl využit k připojení IP telefonu, druhý k připojení směrovače CE-VOIP. Pro měření je nejprve IP telefon restartován, proběhne úvodní inicializace a následně je spuštěna funkce AutoTest. V položce Applications je nutno zvolit aplikaci VoipLog, která je určena pro sledování parametrů VoIP hovorů. V reálném čase můžeme sledovat kvalitu hovorů pomocí měření RTP toku, jsou tedy zobrazeny počty rámců, zahozených rámců, jiter, čas sestavení hovoru, použitý kodek apod. To vše lze sledovat pro stranu telefonu i stranu sítě a to buď jako reporty ve formátu.pdf nebo na počítači graficky (s použitím přídavného software). Report VoIP Monitor slouží k zobrazení počtu odeslaných RTP a RTCP paketů, počtu zahozených paketů a jejich jitteru. Měření bylo realizováno v LAN, lepší by bylo zapojit WAN, kde již ztráta paketů a jitter ovlivňují kvalitu hovoru. Vhodné je zapojit v sérii analyzátor FLUKE s LAN analyzátorem LE-580FX, protože každý se dívá na síť a její parametry poněkud jinak, takže monitorování a odstranění problémů v síti s VoIP je pak snadnější. FLUKE je výhodný pro nižší vrstvy (zjistí se např. problémy s kabeláží na fyzické vrstvě), LAN analyzátor spolu s programem Wireshark může zobrazovat jednotlivé pakety, zjistit důvody zahazování, apod. Subjektivním poslechem věrnosti reprodukce kodeků dle doporučení G.711, G.729 a ilbc nebyl identifikován žádný rozdíl, i když využitá šířka pásma je rozdílná. Kodek ilbc odolává z analyzovaných nejlépe ztrátě paketů, je tedy vhodný pro VoIP. Za nejpoužívanější ze sledovaných tří kodeků je nutno označit základní kodek dle doporučení G.711.

33 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 33 4 Simulace multicastového přenosu V rámci této kapitoly se čtenáři seznámí s přípravou svého virtuálního počítače s operačním systémem Linux, instalací OMNeT++ simulátoru a implementací balíčku INET- HNRL. Kapitola vychází z literatury [9], [10] a [11]. 4.1 Příprava virtuálního stroje Dříve než dojde k samotným simulacím, je nezbytné připravit virtuální počítač s operačním systémem Linux. Konkrétní volba Linuxové distribuce je záležitosti samotných uživatelů. V tomto případě byla vybrána nejnovější verze Kubuntu ve verzi x64. Čtenáři by měli mít na paměti, že výběr distribuce by se měl odvíjet i od jejich nároků na hostitelský počítač Instalace VMware Playeru Samotná virtualizace může probíhat za pomocí různých aplikací. V tomto případě byla zvolena aplikace VMware Player, který je zdarma k dispozici na stránkách společnosti VMware. Systémové požadavky: Procesor 64-bit x86, 1,3 GHz nebo rychlejší. Operační systém Windows nebo Linux. Minimálně 1GB RAM, doporučeno je 2GB a více. Minimálně 1GB volného místa na pevném disku, podporovány jsou i SSD disky. Instalace bude popsána pouze pro operační systémy Windows, neboť při využívání operačního systému Linux, není zapotřebí cokoliv virtualizovat. Instalace VMware Playeru probíhá v následujících krocích: Přihlásit se do uživatelského účtu s dostatečnými právy pro instalaci (nejlépe administrátorský účet). Stáhnout potřebné instalační soubor. Po stažení poklepáním otevřít daný instalační soubor VMware-player-xxxxxxxx.exe, kde xxxx představuje aktuální verzi. Následovat výzvy instalátoru až po Finish.

34 34 FEKT Vysokého učení technického v Brně 4.2 Vytvoření virtuálního operačního systému Linux Po dokončení instalace VMware Playeru je vhodné si připravit instalaci operačního systému Linux ve vybrané distribuci. V našem případě byla zvolena distribuce kubuntu desktop-amd64.iso. Jedná se o distribuci Kubuntu ve verzi x64, tedy určenou pro 64bit hostitelské systémy. Instalaci operačního systému lze shrnout do následujících kroků: 1) Kliknout na Create a New Virtual Machine. 2) Vybrat instalaci z obrazu iso (v našem případě kubuntu desktopamd64.iso) a zvolit pomocí tlačítka Browse cestu k staženému souboru. 3) Vyplnit informace o uživatelském účtu jako jméno, název účtu a heslo. Pro zjednodušení mohou být všechny stejné např. omnetpp. 4) Zadat název virtuálního počítače (např. Kubuntu 64bit) a místo, kde budou jeho soubory uložené na pevném disku. 5) Zvolit velikost pevného disku a vybrat jednu z možností. Poznámka: Pevný disk jako jeden velký soubor, nebo rozdělení pevného disku na několik menších souborů. Druhá možnost je výhodnější, protože takový virtuální pevný disk bude využívat místo reálném pevném disku podle potřeby a nezkonzumuje tak najednou velké množství volného prostoru. 6) Upravit nastavení hardwaru pomocí tlačítka Customize Hardware. 7) Nastavit požadované položky podle potřeby. Pokud pracujeme s vícevláknovým procesorem je vhodné nastavit používání více jader. Rovněž je možné přidělit více operační paměti RAM, pokud je k dispozici dostatek. Poznámka: To pomůže zrychlit kompilaci projektů v programu OMNeT ++, protože ten dokáže pracovat ve více vláknech. Shrnutí nastavení všech parametrů zobrazuje obr Nastavené parametry se mohou v jednotlivých případech lišit, a to zejména: ve velikosti operační paměti, počtu přidělených centrálních výpočetních jednotek a velikosti disku. Po splnění těchto kroků začne automatická instalace operačního systému, která bude trvat přibližně 15 minut (dobu instalace lze několikanásobně snížit přidělením více vláken procesoru, vyšší operační pamětí a v neposlední čadě instalací virtuálního počítače na SSD disk).

35 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 35 Obr. 4.1: Přehled nastavených parametrů před spuštěním instalace virtuálního systému. Během této doby virtuální počítač nebude reagovat a na obrazovce bude zobrazeno pouze základní pozadí bez jakýchkoliv výzev. Proto instalaci nepřerušujte, byť se zdá, že instalace samotná neprobíhá. Nedočkaví uživatelé mohou sledovat vytížení disku, čímž uvidí, že instalace vskutku probíhá. Po instalaci se virtuální systém automaticky restartuje a následně je připraven na používání (dojde k zobrazení okna s uživatelskými účty, kde je možno se ihned přihlásit, viz obr. 4.2). Obr. 4.2: Obrazovka po dokončení instalace virtuálního operačního systému Kubuntu.

36 36 FEKT Vysokého učení technického v Brně 4.3 Instalace OMNeT++ Tato podkapitola vychází z [návod] a [matej]. V této části je popsán postup pro instalaci simulačního programu OMNeT ++ ve verzi 4.6 v operačním systému Ubuntu. Pro tento účel je možné použít virtuální počítač připravený v rámci předchozí kapitoly tohoto učebního textu. Instalace je popsána v krocích, které je třeba provést: 1) Přihlásit se do uživatelského účtu, ve kterém plánujeme program OMNeT ++ používat (pro náš případ bude využit účet omnetpp). 2) Stáhnout archiv s instalačními soubory programu OMNeT (omnetpp-4.6- src.tgz) pomocí odkazu [BALÍČEK]. 3) Zkopírovat/přesunout stažený archiv do ožadovaného adresáře (např. /Home/mnetpp). Před samotnou instalací programu je ještě nutné nainstalovat nezbytné balíky. V následujících krocích je popsána instalace pomocí příkazového řádku (bash shell): 1) Spustit Terminal (konzoli) a zadat: sudo apt-get update Po potvrzení příkazu se objeví hlášení o zadání hesla: [sudo] password for omnetpp: 2) Další krok pro aktualizace systémy patří následující příkaz: sudo apt-get install build-essential gcc g++ bison flex perl \ tcl-dev tk-dev libxml2-dev zlib1g-dev default-jre \ doxygen graphviz libwebkitgtk openmpi-bin \ libopenmpi-dev libpcap-dev 3) Po zobrazení odpovědi v konzoli: After this operation, 182 MB of additional disk space will be used. Do you want to continue? [Y/n] Potvrdíme zapsáním Y. Jakmile proběhne instalace nezbytných balíčků, je možné pokračovat v instalaci programu OMNeT++ pomocí následujících příkazů: 1) Rozbalíme instalační archiv (omnetpp-4.6-src.tgz) příkazem přímo do domovského adresáře: tar xvfz omnetpp-4.6-src.tgz

37 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 37 2) Před spuštěním kompilace OMNeT++ aplikace je zcela nezbytné správně nastavit proměnné do souboru.bashrc v domovském adresáři (např. za použití editoru nano). Zadáním příkazu se dostaneme do domovského adresáře: cd Pro editaci souboru.bashrc použijeme příkaz: nano.bashrc Aby došlo k uplatnění změn v zapsaném souboru je nezbytné restartovat terminál. Po otevření souboru.bashrc vyhledáme následující zápis: # enable programmable completion features (you don't need to enable # this, if it's already enabled in /etc/bash.bashrc and /etc/profile # sources /etc/bash.bashrc). if! shopt -oq posix; then if [ -f /usr/share/bash-completion/bash_completion ]; then. /usr/share/bash-completion/bash_completion elif [ -f /etc/bash_completion ]; then. /etc/bash_completion fi fi a vložíme pod něj následující dva řádky: export PATH=$PATH:/home/omnetpp/omnetpp-4.6/bin export TCL_LIBRARY=/usr/share/tcltk/tcl8.6 3) Nyní je možné spustit kompilaci balíčku OMNeT++: cd omnetpp-4.6. setenv./configure Poznámka: Nebudou-li proměnné nastaveny správně, zobrazí se následující hlášení během kompilace: WARNING: your PATH doesn't contain /home/omnetpp/omnetpp- 4.6/bin! Add the following line to your.profile or.bash_profile (provided you use bash): export PATH=$PATH:/home/omnetpp/omnetpp-4.6/bin 4) Po dokončení konfigurace dokončíme instalaci příkazem: make

38 38 FEKT Vysokého učení technického v Brně 5) Pokud si uživatel přeje instalovat zástupce na plochu a v nabídce aplikací, pak použije: make install-menu-item make install-desktop-icon Tímto je instalace programu OMNeT++ ukončená. 4.4 Implementace projektu INET-HNRL Na začátku je třeba stáhnout archiv se zdrojovými soubory projektu INETHNRL [odkaz]. Podle instrukcí v souboru INSTALL_INET-HNRL.md je správné fungování Projekt třeba do systému doinstalovat knihovnu sqlite3 (odkaz na stažení zde) a správně nastavit proměnné prostředí v programu OMNeT ++. Postup jak toto docílit je popsán v následujících krocích: 1) Rozbalit stažený instalační archiv balíku SQLite3 a přesunout se do rozbaleného adresáře: cd tar xvfz sqlite-autoconf tar.gz cd sqlite-autoconf / 2) Nainstalovat balíček pomocí:./configure make sudo make install Poznámka: Příkaz make nevytváří žádnou posloupnost výpisů, zdá se, že příkaz nic nedělá, ale probíhá postupný překlad. Níže uvedený výpis je poslední po úspěšném provedení překladu a konfigurace SQLitu: /bin/bash./libtool --tag=cc --mode=link gcc -D_REENTRANT=1 - DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_FTS3 - DSQLITE_ENABLE_RTREE -g -O2 -o sqlite3 shell.o./libsqlite3.la -ldl -lpthread libtool: link: gcc -D_REENTRANT=1 -DSQLITE_THREADSAFE=1 - DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -g -O2 -o.libs/sqlite3 shell.o./.libs/libsqlite3.so -ldl -lpthread Poznámka2: Příkaz sudo make install vyžaduje zadání hesla. Instalace je dokončena po zobrazení následujícího výpisu: /bin/mkdir -p '/usr/local/bin'

39 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 39 /bin/bash./libtool --mode=install /usr/bin/install -c sqlite3 '/usr/local/bin' libtool: install: /usr/bin/install -c.libs/sqlite3 /usr/local/bin/sqlite3 /bin/mkdir -p '/usr/local/include' /usr/bin/install -c -m 644 sqlite3.h sqlite3ext.h '/usr/local/include' /bin/mkdir -p '/usr/local/share/man/man1' /usr/bin/install -c -m 644 sqlite3.1 '/usr/local/share/man/man1' /bin/mkdir -p '/usr/local/lib/pkgconfig' /usr/bin/install -c -m 644 sqlite3.pc '/usr/local/lib/pkgconfig' make[1]: Leaving directory `/home/omnetpp/sqlite-autoconf ' 3) Dalším krokem je rozbalení staženého archivu, přejmenování a zkopírování jej do pracovního adresáře programu OMNeT++: cd unzip inet-hnrl-master.zip cp -irv inet-hnrl-master/ omnetpp-4.6/samples/inet-hnrl/ 4) Nyní lze program OMNeT++ spustit: omnetpp nebo spuštěním pomocí ikony na ploše. 5) Z hlavní nabídky vybereme File > Import 6) Následně zvolíme General > Existing Projects into Workspace (obr. 4.3): Obr. 4.3: Výběr existujícího projektu.

40 40 FEKT Vysokého učení technického v Brně 7) Vybereme cestu k balíčku INET-HNRL: /home/omnetpp/omnetpp-4.6/samples/inet-hnrl 8) Možnost Copy projects into workspace musí zůstat prázdná. Volitelně lze vybrat položku Search for nested projects a potvrdit tlačítkem Finish. Dalším krokem podle instrukci je přidat proměnnou prostředí OMNETPP_ROOT, která má ukazovat na kořenový adresář omnetpp-4.6. Tuto proměnnou však kompilátor nepoužije správně a je nutná malá úprava ručním dopsáním cest a také úprava verze GCC v cestách k hlavičkovým souborům. Tento proces je popsán v krocích, které je třeba provést následovně: 9) Označit projekt inet-hnrl v Project Explorer okně a klávesovou zkratkou [Alt] + [Enter] otevřít vlastnosti. 10) Otevřít C/C++ General > Paths and Symbols. 11) Otevřít záložku Includes a v ní jazyk GNU C ) Změnit v položkách, které obsahují ${OMNETPP_ROOT} tuto proměnnou na cestu /home/omnetpp/omnetpp-4.6. Pro vizualizaci slouží obr Obr. 4.4: Nahoře: Původně nastavené proměnné. Dole: Upravené proměnné.

41 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 41 13) Změnit v položkách obsahujících verzi GCC kompilátoru 4.7 tuto verzi na 4.8. Posledním (volitelným ale vhodným) nastavením je nastavení běhu kompilačních procesu ve více vláknech. V menu vlastností je třeba: 14) Kliknout na položku C/C ++ Build. 15) V řádku s příkazem kompilace Build command: přidat k příkazu make parametr -jx, kde X je počet vláken. Nastavení zobrazuje obr Obr. 4.5: Úprava procesu pro kompilace na více jádrech procesoru. Případně přepsání následujícího ukázkového příkazu pro využití 4 jader: make MODE=debug CONFIGNAME=${ConfigName} 16) Následně je potřeba počkat, dokud C ++ indexer načte všechny soubory ze zadaných cest a projekt zkompilovat. To je možné udělat kliknutím pravým tlačítkem na projekt v části Project Explorer a vybrat Build Project. Poznámka: Pokud tato položka není dostupná, je třeba nejprve kliknout na Clean Project a následně na Build Project.

42 42 FEKT Vysokého učení technického v Brně 4.5 Simulace multicastového provozu Po dokončení instalace virtuálního počítače, implementace OMNeT++ simulátoru, doinstalování INET-HNRL a SQLite balíčku, můžeme nyní vytvořit velmi jednoduchý model multicastového přenosu mezi 4 počítači a jedním směrovačem Otevření simulačního modelu a popis souborů Simulace bude vycházet z ukázkového modelu, který jsme nainstalovali v rámci instalace OMNeT++ aplikace. V okně Project Explorer vybereme záložku INET, rozklikneme examples a najdeme složku pro RTP protokol s obsahem multicast1. Po otevření této složky uvidíme 4 soubory. Klíčové jsou první dva multicast1.ned a omnetpp.ini. Soubor.ned jsou tzv. popisující soubory pro jednotlivé simulace. Není výjimkou, pokud má jeden model vytvořen více scénářů, aby se předcházelo složitým strukturám, soubor.ned může obsahovat několik scénářů. Následně je zapotřebí načíst konfigurační soubor (v drtivé většině případů pojmenován jako omnetpp.ini), který obsahuje parametry modulů, nastavení simulace, maximální čas běhu, podmínky pro zastavení simulace aj. Konfigurační soubor může rovněž obsahovat více nastavení pro jednu topologii. Námi simulovanou topologii zobrazuje obr Obr. 4.4: Simulovaná topologie v prostředí OMNeT++. Výsledky simulace v podobě vektorových hodnot a skalárních hodnot se ukládají do výstupních souborů.vec a.sca. Tyto výstupní soubory jsou řádkově orientované textové soubory, které je možné dále zpracovat libovolným nástrojem nebo programovacím jazykem jako Matlab, Perl, Python nebo tabulkovým procesorem. Samotné IDE (Integrated Development Environment) programu OMNeT++ nabízí nástroje pro zpracování těchto

43 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 43 souborů. Otevřením kteréhokoliv z výstupních souborů se automaticky vytvoří Analyzační soubor.anf, ve kterém je možné vytvářet a zpracovávat jednoduché ale i složitější datové soubory. Z těchto datových souborů je pak možné jako výstup generovat různé grafy. Program OMNeT++ umožňuje i ukládání tzv. evet logu ze simulace, co vlastně představuje záznam všech nebo jen části zpráv, které se v simulaci vyskytly, uložený v souboru s příponou.elog. Pro analýzu těchto zpráv OMNeT++ poskytuje zobrazení v podobě stavového diagramu. Nastavení klientů a směrovače Nyní je zapotřebí nakonfigurovat aktivní prvek a koncové uzly. Host1, 2, 3 a 4 je zvolení jako zdroj vysílaného toku. Popis kompletního kódu pro jednotlivé stanice je nad rámec tohoto textu. Níže následují nejdůležitější informace Host1: Source: host1: RTPHost { parameters: IPForward = false; profilename = "inet.transport.rtp.rtpavprofile"; destinationaddress = " "; portnumber = 5004; bandwidth = } Host1, 2, 3 a 4 slouží jako klienti: Client: host4: RTPHost { parameters: IPForward = false; profilename = "inet.transport.rtp.rtpavprofile"; destinationaddress = " "; portnumber = 5004; bandwidth = } Pro směrovač si vystačíme s následujícím: Source: router1: Router { parameters: forwardmulticast = gates: pppg[];

44 44 FEKT Vysokého učení technického v Brně } Globální konfigurační soubor omnetpp.ini upravíme pomocí následujícího kódu: [General] network = RTPMulticast1 total-stack = 28MiB tkenv-plugin-path =../../../etc/plugins **.host1.filename = "../data/alien.mpg.gdf" **.host2.filename = "../data/chicklets.mpg.gdf" **.host3.filename = "../data/lego_video.mpg.gdf" **.host4.filename = "../data/bserver10.mpg.gdf" **.payloadtype = 32 **.autooutputfilenames = true **.sessionenterdelay = 10s **.transmissionstartdelay = 20s **.transmissionstopdelay = 5s **.sessionleavedelay = 60s Nyní máme hotovou topologii, nastavení služby (zdroje a cílů) a můžeme spustit simulaci. Pomocí příkazového řádku: #!/bin/sh../../../src/run_inet $* Nebo pomocí tlačítka run. Spustí se nové okno a v něm bude topologie z obr. 4.4 upravena na obr Jinými slovy dojde k přiřazení IP adres a pojmenování portů na straně směrovače. Obr. 4.5: Simulovaná topologie s přiřazenými IP adresami.

45 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 45 Odstartováním simulace dojde poprvé k odeslání zprávy IGMPv2 query koncovým stanicím, tedy hostům (proto se zde vyskytuje IP adera , která obecně definuje všechny systémy na dané podsíti). V rámci konzolového výpisu lze sledovat následující zprávy: router1 --> host1 IGMPv2 query IPv4: > router1 --> host2 IGMPv2 query IPv4: > router1 --> host3 IGMPv2 query IPv4: > router1 --> host4 IGMPv2 query IPv4: > Výše uvedené zprávy uvádějí, že směrovač potenciální klienty streamu detekoval a informoval o možnosti odběru toku. Na jeho zprávu musí koncové uzly odpovědět zprávou IGMPv2 report, pokud mají o příjem streamu zájem. Aktivní prvek potvrdí zprávu IGMv2 report a dojde k distribuci streamu pro koncové uzly. I tyto zprávy jsou zachyceny uvnitř konzolového okna, které informuje o všech událostech: host1 --> router1 IGMPv2 report IPv4: > host2 --> router1 IGMPv2 report IPv4: > host3 --> router1 IGMPv2 report IPv4: > host4 --> router1 IGMPv2 report IPv4: > router1 --> host1 IGMPv2 report IPv4: > router1 --> host2 IGMPv2 report IPv4: > router1 --> host3 IGMPv2 report IPv4: > router1 --> host4 IGMPv2 report IPv4: > Jakmile jsou veškeré potvrzení doručeny, dochází k přenosu videa: host2 --> router1 UDP: > : (47) IPv4: > router1 --> host1 UDP: > : (47) IPv4: > router1 --> host3 UDP: > : (47) IPv4: > router1 --> host4 UDP: > : (47) IPv4: > host1 --> router1 UDP: > : (47) IPv4: > router1 --> host2 UDP: > : (47) IPv4: > router1 --> host3 UDP: > : (47) IPv4: > router1 --> host4 UDP: > : (47) IPv4: > host4 --> router1 UDP: > :(47)IPv4: > router1 --> host1 UDP: > : (32)IPv4: >

46 46 FEKT Vysokého učení technického v Brně router1 --> host2 UDP: > : (32)IPv4: > router1 --> host3 UDP: > : (32)IPv4: > host3 --> router1 UDP: > : (29) IPv4: > router1 --> host1 UDP: > : (29) IPv4: > router1 --> host2 UDP: > : (29) IPv4: > router1 --> host4 UDP: > : (29) IPv4: > Výše uvedeným výpisem je potvrzeno nastavení šíření multicastového toku od jednoho hosta k ostatním, a to s postupnou reciprocí. Uvedený výpis byl zkrácen z důvodu úspory místa. Po skončení simulace jsou vytvořeny soubory.vci a.vec, které mohou sloužit k další analýze. Jejich využití je obdobné jako souboru.pcap. Otevřením vhodným nástrojem (Matlab, Python atd.), lze z těchto dat zpracovávat další statistiky, grafy a vyhodnocení. Pokud by některá ze stanic chtěla opustit multicastovou skupinu, do které se přihlásila, musela by odeslat zprávu IGMPv2 Leave Group. Směrovač by tuto zprávu vyhodnotil tak, že koncová stanice si již nepřeje daný tok přijímat, proto by nebyl tok na příslušný port dále vysílán. Tato situace by se mohla teoreticky opakovat tolikrát, kolik je celkový počet klientů. Po odeslání IGMPv2 Leave Group posledním klientem by došlo ke zrušení multicastové skupiny s IP adresou úplně.

47 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 47 5 Simulace technologie DiffServ Tato kapitola vychází z literatury [12]. [13], [14] a [15]. Cílem této kapitoly je seznámit čtenáře s návrhem topologie za účelem simulace DiffServ kvality služeb s přesným počtem aktivních prvků, vhodně je propojit, nakonfigurovat tři aplikace (http, FTP a VoIP) dle daných parametrů a aplikovat QoS technologii DiffServ. Zároveň počet zahozených paketů na jednotlivých prvcích z DiffServ nesmí překročit hodnotu 20 paketů. Na závěr provést simulaci a vhodně zvolit výsledné statistiky. Čtenář by si měl závěrem textu uvědomit rozdíl mezi QoS a diffserv technikou pro zajištění kvality služeb. Bude-li uvažována klasické nasazení kvality služeb, pak každý paket bude obsahovat značku a přesnou definici jak s ním má být zacházeno v aktivních prvcích. Pro diffserv techniku pakety budou obsahovat značku ToS (Type of Service), tedy typ služby, která udává způsoby zacházení s těmito paketu. Nejčastější značky ToS jsou následující: 0 Best Effor maximální snaha o doručení, DSCP (DiffServ Code Points) = 0. 1 Prioritní označuje prioritní provoz, který by neměl být příliš odkládán před odesláním, DSCP = 8, 10, 12, naléhavé není tolerována žádná prodleva před přenosem, DSCP = 16, 18, 20, Flash (hlas) priorita pro hlasový přenos, DSCP = 24, 26, 28, Flash Override obdoba flash (hlas), DSCP = 32,34,36, Kritická nejčastěji používáno pro přenos RTP (Real Time Protocol), DSCP = 40, Internet běžný provoz, DSCP = Síť obdoba 6, DSCP = 56. Veškeré uvedené hodnoty DSCP jsou v dekadické podobě. Výpis hodnot pro jednotlivé pakety lze zobrazit pomocí síťového analyzátoru WireShark. 5.1 Postup řešení Vytvoření topologie topologie byla vytvořena podle obr. 5.1, musela však obsahovat 10 směrovačů libovolného typu (v našem případě ethernet4_slip8_gtwy), 4 přepínače rovněž

48 48 FEKT Vysokého učení technického v Brně libovolného typu (v našem případě eth16_ethch16_fddi16_tr16_switch), 5 serverů (v našem případě ethernet_server_adv) a 20 stanic (v našem případě ethernet_wkstn_adv). Výběr stanic je vhodný provést v záložce advance,neboť základní stanice není možné zcela konkrétně nakonfigurovat v pokročilých funkcích. Námi navrženou topologii ilustruje obr Směrovače jsou propojené linkou PPP_DS3 a přístupové přepínače, pak pomocí linek 100BaseT. Nakonfigurovali jsme si směrovací protokol OSPF, ceny linek jsou zaznamenány na obrázku, pak je tady jasné kudy povede hlavní trasa. Tedy Edge_Router_1 Core_Router_2 Core_Router_3 Core_Router_4 Edge_Router_2 a opačně. V neposlední řadě byl kladen důraz, aby tyto linky byly vytížené nad 50 %. Vytížení linky si lze zvolit. Pro tento případ bylo vybráno 50% zatížení. Obr. 5.1: Navržená topologie pro aplikace technologie DiffServ. Konfigurace aplikací v objektu AppConfig dle zadání jsme nadefinovali tři aplikace http, FTP a VoIP. Jméno aplikace bylo zvoleno dle následujícího schéma, název aplikace_náhodné číslo, tedy FTP_9, HTTP_9 a VoIP_9. Nastavení aplikací viz obr. 5.2, obr. 5.3 a obr Aplikace FTP měla nakonfigurovány následující vlastnosti: poměr požadavků a odpovědí byl stanoven na 100 % (každý požadavek měl být zpracován a očekávala se odpověď), rozložení v čase pro službu bylo vybráno exponenciální, tedy služba

49 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 49 měla exponenciální charakter zatížení, velikost souboru je rovna 10,48 MB, symbolické označení serveru FTP Server (nepovinné, ale doporučeno), typ služeb Best Effort. Podle typu a uvedené teorie je zřejmé, že dojde pouze k maximální snaze doručit datové jednotky. Nastavení http aplikace, specifikace http protokolu 1.1, charakter služby exponenciální, typ služby Best Effort. Nastavení aplikace přenosu hlasu po internetovém protokolu. Vidíme podle obr. 5.4 bohatá nastavení této služby. Počáteční ticho nebylo použito. V praxi tato část může být reprezentována prvotní reakcí protistrany, symbolické označení cílového jména (dobrovolná, ale doporučována mořnost) Voice Destination, zvukový kodek G.729.A (nenáročný zvukový kodek s výbornými kompresními hodnotami a nízkou přenosovou rychlostí), typ služby best effort (prvotní nastavení), doba komprese/dekomprese hlasových paketů 200 ms. Zde bylo záměrně vybráno vysoké hodnoty, aby bylo žádoucí nasazení QoS. Obr. 5.2: Nastavení FTP aplikace.

50 50 FEKT Vysokého učení technického v Brně Obr. 5.3: Nastavení HTTP aplikace. Obr. 5.4: Nastavení VoIP. Konfigurace profilů aplikací v objektu ProfileConfig každá aplikace byla tvořena samostatným profilem, jména profilu jsou zvolena výstižně, název služby, libovolné číslo a klíčové slovo Profile (FTP_9_Profile, HTTP_9_Profile a VoIP_9_Profile) viz obr. 5.5,

51 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 51 který spustí danou aplikaci v rozmezí sekund, aplikace ukončí až samotný konec simulace. Volba času není náhodná, jelikož předpokládáme, že prvních 60 vteřin bude potřeba na konvergenci vytvoření směrovacích tabulek na jednotlivých směrovačích. Obr. 5.5: Nastavení profilů aplikací v ProfileConfig. Přiřazení profilů aplikací uzlům sítě předem uvažujme celkem 10 toků VoIP, tudíž bude potřeba realizovat VoIP na každé pracovní stanici. Musíme tedy na 20 pracovních stanicích, kde bude potřeba v záložce Applications->Application: Supported Services zvolit VoIP jako podporován a pak na zbylých 10 nastavit v Applications->Application: Supported Profiles profil VoIP_9_Profile, protože navázání spojení je oboustranné. Tímto vznikne 10 obousměrných VoIP toků podle očekávání a charakteru služby přenosu hlasu po internetovém protokolu. Program OPNET nám přímo umožňuje nastavit, která stanice bude

52 52 FEKT Vysokého učení technického v Brně navazovat spojení s jinou stanici, dle Application: Destination Preferences, tímto nastavíme cílový uzel, viz obr. 5.6 a obr Zároveň jsme nastavili do Supported Services podporu služeb HTTP, FTP a VoIP pro 5 serverů. Konfiguraci serveru zachycuje obr V neposlední řadě jsme nastavili vybraným stanicím do Supported Profiles běh profilu http nebo FTP, případně obojí a do Destination Preferences cílový server. Pro Load Balancing (Load Balancing umožní rozložení zátěže a tím nebude jedna linka vytížená, kdežto druhá by mohla zůstat prázdná ) bylo vybráno na jistých stanicích více zdrojových serverů. Tab. 5.1 definuje rozpis uzlů a použitých aplikací a zdrojů. Obr. 5.6: Nastavení aplikace na uzlu Wrkstn_1_VoIP_HTTP.

53 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 53 Obr. 5.7: Nastavení uzlu Wrkstn_2_VoIP. Obr. 5.8: Konfigurace Supported Services na uzlu Server_2_HTTP_FTP.

54 54 FEKT Vysokého učení technického v Brně Tab. 5.1: Nastavení profilů aplikací a podporovaných služeb jednotlivých uzlů Uzel Pod. služba 1 Nastavení cíle 1 Pod. služba 2 Nastavení cíle 2 Server_1_HTTP HTTP Server_2_HTTP_FTP HTTP - FTP - Server_3_HTTP_FTP HTTP - FTP - Server_4_FTP FTP Server_5_FTP FTP Wrkstn_1_VoIP_HTTP VoIP Wrkstn_15_VoIP_FTP HTTP Server_3_HTTP_FTP Wrkstn_2_VoIP VoIP Wrkstn_14_VoIP_FTP - - Wrkstn_3_VoIP_FTP VoIP Wrkstn_13_VoIP_HTTP FTP Server_3/4/5 Wrkstn_4_VoIP VoIP Wrkstn_16_VoIP_HTTP - - Wrkstn_5_VoIP_FTP VoIP Wrkstn_11_VoIP_FTP FTP Server_3_HTTP_FTP Wrkstn_6_VoIP_HTTP VoIP Wrkstn_12_VoIP HTTP Server_3_HTTP_FTP Wrkstn_7_VoIP_FTP VoIP - FTP Server_3/4/5 Wrkstn_8_VoIP VoIP Wrkstn_9_VoIP_HTTP VoIP - HTTP Server_3_HTTP_FTP Wrkstn_10_VoIP_HTTP VoIP - HTTP Server_3_HTTP_FTP Wrkstn_11_VoIP_FTP VoIP - FTP Server_2_HTTP_FTP Wrkstn_12_VoIP VoIP Wrkstn_13_VoIP_HTTP VoIP - HTTP Server_1_HTTP Wrkstn_14_VoIP_FTP VoIP - FTP Server_2_HTTP_FTP Wrkstn_15_VoIP_FTP VoIP - FTP Server_2_HTTP_FTP Wrkstn_16_VoIP_HTTP VoIP - HTTP Server_1/2 Wrkstn_17_VoIP VoIP Wrkstn_7_VoIP_FTP - - Wrkstn_18_VoIP_HTTP VoIP Wrkstn_8_VoIP HTTP Server_1/2 Wrkstn_19_VoIP VoIP Wrkstn_9_VoIP_HTTP - - Wrkstn_20_VoIP_FTP VoIP Wrkstn_10_VoIP_HTTP FTP Server_2_HTTP_FTP Aplikace technologie DiffServ diffserv doména je ohraničená hraničními směrovači Edge_Router_1 a Edge_Router_2. Zde také bude probíhat klasifikace a značení paketů na základě protokolu a portů pomocí Extended ACL (IP->IP Routing Parameters->Extended ACL Configuration). Ukázka nastavení ACL (Access Control List) s dvěma pravidly pro HTTP Destination Port 80 zobrazuje obr Vytvořili jsme celkem tři ACL pro jednotlivé aplikace TCP protokolu (HTTP port 80 a FTP porty 20 a 21) a UDP protokol (VoIP). Každý ACL obsahuje zvlášť pravidlo pro zdrojový a cílový port. Aplikace VoIP tvoří výjimku, zde je využíván protokol UDP, a proto je každý IP paket obsahující UDP diagram klasifikován přiřazením VoIP aplikaci.

55 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 55 Obr. 5.9: Konfigurace Extended ACL na hraničním směrovači Edge_Router_1. Po nakonfigurování Extended ACL jsme na obou hraničních směrovačích nastavili tři Traffic Classes (IP->IP QoS Parameters->Traffic Classes) FTP_Class, HTTP_Class a VoIP_Class. Pro každou třídu každou třídu jsme nastavili do Match Info položku Match Property jako ACL, Match Condition jako Equals a do Match Value příslušný ACL. Na obr je zobrazené toto nastavení pro Traffic Class FTP_Class. Následně bylo potřebné ještě nastavit na obou hraničních směrovačích novou Traffic Policy (IP->IP QoS Parameters->Traffic Policies) s názvem traffic_policies, na základě, které budou jednotlivým klasifikovaným paketům podle třech definovaných Traffic_Classes do hlavičky přiřazená DSCP značka. Samotné nastavení ilustruje obr

56 56 FEKT Vysokého učení technického v Brně Obr. 5.10: Nastavení Traffic Classes na hraničním směrovači Edge_Router_1. Obr. 5.11: Nastavení Traffic Policies na hraničním směrovači Edge_Router_1. Protože chceme, aby rozhraní všech směrovačů namísto front FIFO (First In First Out) používaly fronty typu WFQ (Weighted Fair Queue) s prevencí zahlcení WRED, museli jsme před konfigurací těchto rozhraní ještě nastavit správné WFQ Profiles v objektu QoSAttbirConfig, který slouží na konfiguraci QoS front. Protože jsme chtěli pakety řadit do

57 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 57 front na základě značky DSCP, kterou přiřazuje námi vytvořený Traffic_Policy, nakonfigurovali jsme v WFQ Profiles->DSCP Based tři fronty s váhou 5.0, 15.0 a 25.0, přičemž do první fronty budou řazeny pakety s DSCP značkou Best Effort (FTP provoz), do druhé se značkou AF21 (HTTP provoz) a do třetí se značkou AF31 (VoIP provoz). Každá fronta má nastavené RED Parameters na hodnotu WRED jako prevenci zahlcení. Maximální délka fronty pro jednotlivé váhy je postupně 100, 200 a 500 paketů. Samotné nastavení zobrazuje obr Nakonec bylo nutné nastavit ještě samotné rozhraní na směrovačích tak, aby na rozhraních hraničních směrovačů, ke kterým jsou připojené přepínače s pracovními stanicemi a servery, docházelo ke klasifikaci a označovaní paketů a aby se na všech rozhraních (včetně těch hraničních) využívali směrovače namísto předvolených front typu FIFO fronty WFQ (Class Based) DSCP Based. Obr. 5.12: Konfigurace WFQ front v objektu QoSAttribConfig. Konfigurace a běh simulace pro běh simulace nebylo potřeba nijak zvláštního nastavení. Použili jsme délku 30 minut (libovolná doba neovlivní reálnou dobu, tedy 1 den simulace nezabere 24 hodin). V tomto případě bylo nastavení mnoho složitých nastavení a OPNET modeler simuloval topologii značnou dobu. Zde se projevuje základní nedostatek

58 58 FEKT Vysokého učení technického v Brně aplikace, a to absence x64 optimalizace pro rozdělení zátěže na jednotlivá jádra systému. Simulation Kernel: Optimized a hodnotu Values per statistic Běh simulace trval velmi dlouho. 5.2 Výsledky Zadání definovalo, abychom dosáhli využití linky nad 50 %. Stačilo nám k tomu 10 VoIP toků (naše volba), 7 FTP toků a 7 HTTP toků. Přičemž podle dosažených výsledky obr bychom dosáhli splnění zadání i při nižších počtech toků. Modrou barvou je zobrazena závislost při komunikaci mezi Core_Router_3 a Core_Router_4 pro směr v udaném pořadí. Červená barva reprezentuje obrácený směr. Špičkové hodnoty toků si jsou rovny. Maximální vytížení dosahuje cca 46 Mb/s, přičemž mělo být dosaženo minimálně 30 Mb/s. Obr. 5.16: Statistika vytížení linky mezi směrovači Core_Router_3 a Core_Router_4 v doméně DiffServ. Přítomnost a funkčnost protokolu OSPF dokazuje statistika na obr Zpočátku vysoká aktivita-konvergenci a následně mírná aktivita udržováním spojení mezi směrovači. Povahou směrovacího protokolu je dána vyšší režie zpočátku simulace. Každý směrovač musel přenést svým sousedům informace o svých sousedech a přímopřipojených sítích. Podle časové osy lze odhadovat čas konvergence během prvních 2 minut. Kontinuální a nulová aktivita směrovacího protokolu po zbytek simulace je dána tím, že směrovače byly stále připojené a nebyl simulován výpadek linky. Pokud by došlo k nasimulování výpadku, byla by zřejmá aktivita směrovacího protokolu OSPF v daném čase. Pravidelné odesílání zpráv protokolem OSPF vygenerovalo zanedbatelnou režii v síti, proto je také zbylá aktivita rovna nule.

59 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 59 Obr. 5.17: Statistika celkového provozu OSPF protokolu. Následující graf na obr poskytuje informace k simulaci spolehlivého a potvrzovaného přenosu služby FTP. Přenos souboru o velikosti 10,48 MB byl neustále opakován, čímž je dán charakter závislosti na uvedeném obrázku. Jedná se o pravidelné zatížení přenosových linek okolo 9,40 Mb/s. Špičky v závislosti udávají znovu navázání spojení, případně jsou dány exponenciálním charakterem služby (ten jsme si sami zvolili). Obr. 5.18: Statistika celkového provozu FTP protokolu.

60 60 FEKT Vysokého učení technického v Brně Obr. 5.19: Statistika celkového provozu HTTP protokolu. Simulace komunikace klienta s webových serverem na obr dopadla podobně jako přenos dat na předešlém obrázku. I webová stránka je stahována neustále dokola. Po skončení přenosu celého obsahu dojde k zopakování. Tímto je vysvětlena povaha kontinuálního zatížení linky okolo 2,9 Mb/s jak pro sestupný, tak vzestupný směr. Špičky v grafu jsou dány exponenciálním typem služby. Námi zvolený exponenciální typ (20) je náhodně zopakován s exponenciální zátěží. Lineární zátěže není v praxi prakticky nikdy docílené, neboť je skoro nemožné zajistit postupné připojování klientů (výjimkou mohou být sportovní přenosy, kdy se před zahájením přenosu postupně připojují klienti). Z tohoto důvodu bylo vybráno exponenciální zatížení. Předposlední zobrazenou závislostí je kolísání zpoždění během hovoru (viz obr. 5.20). Počáteční vysoké hodnoty zpoždění jsou dány konvergencí sítě, protože VoIP byla spuštěna pouze s malým zpožděním zpočátku spuštění simulace. Následně od 9. minuty simulace dosahuje hodnota kolísání zpoždění výborné, téměř nulové hodnoty. Komunikující strany nemohou poznat rozdíl mezi telefonováním po pevné síti a telefonováním po Internetu. Poslední uvedená statistika na obr. 20. Předem jsme si nadefinovali, že míra zahozených paketů nesmí dosáhnout vyšší hodnoty než je hodnota 20 paketů v průběhu simulace. Tento cíl je splněn v plném rozsahu, neboť maximální hodnota zahozených paketů v průběhu celé simulace dosáhla maximálně 11 paketů. Jinými slovy jsme dosáhli téměř poloviční hodnoty zahozených paketů v průběhu simulace.

61 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 61 Obr. 5.20: Statistika hodnot Jitter provozu VoIP.. Obr. 5.21: Statistika zahozených IP paketů za sekundu. Závěrem vytvořením simulačního modelu, přiřazení aplikací a odsimulování lze konstatovat, že diffserv služby mohou být velice spolehlivě nasimulovány v prostředí OPNET Modeleru. Nastavení a implementace služeb je však časově velice náročné, jako aplikace samotná. Předem nadefinované cíle pro výsledky simulací byly splněny v maximálním rozsahu.

62 62 FEKT Vysokého učení technického v Brně 6 Generátor síťového provozu Tato kapitola vychází z literatury [16] a [17]. Implementujte do prostředí OPNET Modeler generátor síťového podle zadání na obr Vhodnou volbou konfigurace a profilu lze docílit podle uvedeného obrázku. Dále máme specifikován typ transportního protokolu: TCP spolehlivý a spojově orientovaný přenos, celková délka simulace je stanovena na 4 hodiny, doba trvání jedné periody opakování t m 20 minut, rychlost datového toku v rámci jednoho shluku konstantní rozložení s rychlostí 1 Mb/s, počet shluků na začátku periody N z konstantní, 0, počet shluků na konci periody N rovnoměrně rozložená pravděpodobnost počtů 4 a 8, doba trvání jednoho shluku t s konstantní; 5 sekund, interval mezi jednotlivé shluky dat ti NEZÁVISLÉ doby s průměrným trváním 10 s. Výstupem simulace bude naprogramovaná závislost počtu přenesených datových shluků na době simulace a závislost počtu přenesených datových shluků N z a N k na době simulace. Obr. 6.1: Očekávaný průběh síťového provozu. 6.1 Vypracování zadání Zpočátku je nezbytné zvolit vhodnou topologii sítě. Pro náš případ bude dostačovat modelový případ aplikační server a koncová stanice. Definované parametry podle zadání budou implementovány do aplikačního a profilového nastavení. Topologie byla složena z následujících prvků, které OPNET Modeler v sobě již v základní instalaci obsahuje:

63 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 63 topologie - pracovní stanice (ethernet_wkstn_adv) připojena na server (ethernet_srv_adv) linkou ethernet 100BaseT; objekty Application Configuration a Profile Configuration - obr Obr. 6.2: Navržená topologie simulace. Již v našem zadání je specifikováno, že lze použít vhodné nastavení aplikačního a profilového konfigurátoru k docílení nadefinovaných parametrů. Konfigurace Application Configuration: definice 1 aplikace "PulseTraffic" (jméno aplikace v uvozovkách je zcela libovolné, můžete si zvolit své vlastní označení), viz obr. 6.3, která využívá FTP protokol pro přenos dat, a tím i transportní protokol TCP. Abychom dosáhli konstantní rychlosti datového toku v rámci jednoho shluku o hodnotě 10 Mb/s, zvolili jsme tuto konfiguraci FTP. Právě druhými dvěma parametry, posíláním 895 bajtové paketů (plus hlavička TCP, IP, ) konstantně každých 0.01 sekundy, dosahujeme potřebný ~1 Mbit / s, jak definuje zadání. Nevýhodou tohoto řešení je vysoká režie protokolu TCP, která způsobuje v opačném směru potvrzováním přijatých paketů datový tok asi na hodnotě 700 kb/s. Výhodou je však dosažení téměř úplně obdélníkového průběhu, přičemž je zároveň nutné zvýšit počet hodnot generovaných pro jednotlivé statistiky, jinak se průběh bude jevit jako pilovitý - více v části o konfiguraci simulace. Navržený typ služby Best Effort bude mít pouze maximální snahu o doručení datových jednotek. Dojde-li k maximálnímu zatížení sítě, pak budou zahazovány pakety právě s tímto nastavením typu služby. Na druhou stranu zadání zadává datový tok pouze 1 Mb/s. Povaha zapojení topologie je zřejmá (Server > koncová stanice), nebude

64 64 FEKT Vysokého učení technického v Brně docházet k dalším přenosům mezi jinými stanicemi, či páteřní síť. Symbolické jméno FTP Server je zcela volitelná položka, ale doporučuje se její využití. Při vhodném pojmenování služeb bude docíleno snadné identifikace. Obr. 6.3: Nastavení Application Configuration. Konfigurace Profile Configuration: v nastavení Profile Config (obr. 6.4) využíváme tři profily "PulseProfile2" a "PulseProfile4", které využívají aplikaci "PulseProfile8". Perioda opakování obou profilů je 15 minut (trojnásobek zadaných 5 minut) a střídáním těchto trech profilů se správně zadaným ofsetem generujeme síťový provoz s nulovým počtem shluků (Nz) na začátku periody a rovnoměrně rozloženou pravděpodobností počtů 2, 4 a 8 shluků (Nk) na konci periody (zadaných 5 min.). Ve všech profilech je nastavena délka běhu aplikace na konstantních 5 sekund. Čas mezi opakováními je nastaven na exponenciálně rozložení s hodnotou 10, opět tak, aby byly dosaženy nezávislé doby s průměrným trváním 10 sekund. konfigurace Application Server a Workstation: na serveru jsme nastavili do "Supported Services" položku "DefinicePulsu" a na pracovní stanici do "Supported Profiles" tři položky "PulseProfile2", "PulseProfile4" a "PulseProfile8". Naprogramování vlastních statistik: při programování statistik jsme použili obecní návod k vytváření statistik v OPNET Modeleru, který je dostupný při vyvolání nápovědy aplikace. Ukázkový případ byl přesně krok po kroku implementován do našeho projektu, čímž jsme si přidali lokální a globální statistiku závislosti počtu přijatých paketů na době simulace. Tento návod využívá modifikaci modelů ethernet_wkstn_adv a ip_dispatch, které jsme my dále modifikovali na počítání shluků.

65 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 65 V tomto případě využíváme fakt, že pomocí funkce op_sim_time () je možné v době příjetí paketu zjistit aktuální čas simulace. Pokud je tento časový rozestup mezi pakety delší než určitá námi stanovená hodnota (např. 0,5 sekundy nebo 5 sekund) můžeme říci, že tento paket patří již do dalšího shluku a tuto informaci si můžeme uložit do statistiky závislosti počtu přenesených datových shluků na době simulace. Podobně víme určit, zda přišel paket v první polovině periody, resp. v druhé, a na základě této informace si můžeme vést statistiku o závislosti počtu přenesených datových shluků N z a N k na době simulace. Pozn.: Zdrojový kód je možné najít v upravených modelech ethernet_wkstn_adv_modstat a ip_dispatch_modstat. Jeho momentální nevýhodou je fakt, že předpokládá délku periody 20 minut, která je zadána pevně ve zdrojovém kódu. Konfigurace a běh simulace nebylo nutné nijak podrobně nastavovat, použili jsme 4 hodinovou délku simulace dle zadání, "Simulation Kernel: Optimized", ale zároveň bylo velmi důležité zvýšit hodnotu "Values per statistic" na hodnotu v rozmezí , čímž se zvýšil počet zaznamenaných bodů v jednotlivých statistikách a tedy zvýšila se jejich "jemnost". Jinak by docházelo k vykreslování obdélníkových průběhů jako pilovitých. Běh simulace zabírá čas podle hardwarové konfigurace jednotlivých počítačů. Obr. 6.4: Nastavení aplikačního profilu.

66 66 FEKT Vysokého učení technického v Brně Výsledky simulace můžeme pozorovat na statistikách linky 100BaseT mezi pracovní stanicí a serverem, a zároveň na vlastně naprogramovaných statistikách, viz Results Browser na obr 6.5. V položce results browser vidíme všechny statistiky, které byly zvoleny pro simulaci. Výhodou této aplikace je možnost porovnávání výsledků mezi dílčími simulacemi, jejich proložení křivkou, nebo použití různých matematických funkcí pro výsledné průběhy grafů. Doba simulace je zároveň úměrná počtu potřebných statistik, tím vyšší počet statistik na ukládání, tím je delší čas potřebný pro dokončení simulace. Obr. 6.5: Results Browser s výběrem statistik, které jsou zaznamenávány během simulace. Obrázky 6.6 a 6.7 (detaily) zobrazují statistiku propustnosti linky mezi pracovní stanicí a serverem, na níž probíhá komunikace mezi těmito uzly, a na které je možné ověřit správnost nastavení topologie a splnění zadání. Podle obr. 6.6 je zřejmé správné nastavení jednotlivých parametrů podle zadání. Dosažený výsledek propustnosti zcela odpovídá zadání, tedy propustnosti 1 Mb/s. Vidět můžeme rovnoměrné rozložení pravděpodobnosti počtů 4 a 8 shluků na konci periody a 0 na začátku, periodu opakování 20 minut, délku simulace o délce 4 hodin, rychlost datového toku cca. 1 Mb/s. Obrázek vlevo lze vidět i přibližně konstantní dobu trvání shluku 5 sekund a interval mezi shluky jako nezávislé doby s průměrným trváním 10 sekund. Na obr. 6.8 vidíme průběh námi naprogramované statistiky - závislost počtu přenesených datových shluků na době simulace. Jednoduchým výpočtem dokážeme určit, že pokud délka simulace je 240 min. a perioda opakování 20 min., přičemž se rovnoměrně střídá počet shluků 4 a 8, tak na konci simulace by jich mělo být:

67 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 67. V grafu vidíme počet 70. To můžeme jednoduše odůvodnit tím, že při intervalu mezi shluky zvoleném jako nezávislé doby s průměrným trváním 10 sekund může docházet k tomu, že bude tento interval natolik krátký, že některé shluky splynou částečně dohromady a my tak nebudeme schopni tyto shluky od sebe rozlišit. Pozn.: Citlivost závisí na podmínky if (time_diff <0.5) v modelu ip_dispatch_modstat, stavu idle. Na obr. 6.9 vidíme průběh druhé námi naprogramované statistiky - závislost počtu přenesených datových shluků N z a N k na době simulace. Tato statistika je téměř identická s předchozí, avšak počítá nezávisle shluky na začátku periody a na jejím konci, přičemž hranice je stanovena jako polovina trvání periody (10 min.). Obr. 6.6: Statistika propustnosti linky 100BaseT mezi serverem a pracovní stanicí.

68 68 FEKT Vysokého učení technického v Brně Obr. 6.7: Detail na 4 a 8 shluků po dobu jedné periody. Obr. 6.8: Vlastní statistika počítání shluků. Vytvořený generátor síťového provozu zcela plní veškeré zadání. Propustnost mezi linkami vyšla podle zadaného parametru 1 Mb/s, detaily shluků rovněž odpovídají definovaným parametrům. Největší potíže mohou tvořit vytvoření vlastních statistik. V tomto textuje zobrazena pouze jedna statistika, druhá by odpovídala právě výše uvedené. OPNET Modeler je velice robustní aplikací, která vyžaduje mnoho času pro implementaci vlastních statistik, aplikací, provozů a jiných služeb.

69 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 69 7 Simulace bezdrátové sítě Tato kapitola vychází z literatury [18], [19] a [20]. V rámci simulačního modelu je nezbytné vytvořit simulační, jenž je zobrazen na obr Jak je zřejmé síť obsahuje 2 přístupové body, které jsou mezi sebou propojeny pomocí přepínače. Přítomnost app_conf a profile_conf slouží k nadefinování služeb mezi jednotlivými stanicemi. Síť je tvořena dvěma přístupovými body a osmi bezdrátovými stanicemi, jedním Ethernetovým přepínačem a třemi servery. Ethernetová část sítě je propojena pomocí linek 100BaseT. Je třeba nakonfigurovat jednotlivé aplikace FTP, VOIP, Database, tak aby vytěžily dostatečně bezdrátovou síť. Jednotlivým aplikacím byly nastaveny třídy služby TOS, VOIP ToS6, FTP ToS 1, Database ToS 4. Zkratka ToS představuje, Type of Services, tedy typ služby. Jednotlivé typy služeb mají rozdílnou priority a bude s pakety zacházeno rozdílným způsobem. Podporu aplikací a profilů na serverech jsme nakonfigurovali tak, aby každý server obsluhoval 1 aplikaci. Obr. 7.1: Topologie bezdrátové sítě. Na přístupovém bodě QoS_AP1 a přilehlých bezdrátových stanicích jsme nakonfigurovali standard e, který zajišťující kvalitu služeb (QoS). Konkrétně hybridní koordinační funkci (HCF). Pomocí tohto anstavení lze očekávat výrazně lepší výsledky

70 70 FEKT Vysokého učení technického v Brně parametrů v případě použití QoS. V případě QoS očekáváme nižší kolísání zpoždění, nižší zpoždění, méně zahozených paketů. 7.1 Postup implementace služeb Úkolem je změřit vliv parametrů QoS na síť. Měřit bude nezbytné následující parametry: Kolísaní zpoždění (Jitter) Propustnost (Throughput) Celkové zpoždění (Packet end-to-end delay) Zahazování paketů (Data Dropped) Celkově vytížení sítě (load bits / sec) Zpoždění přenosu paketů v síti (packet delay variation) Na jednotlivých stanicích byly nastavené podpory aplikací. Aplikace byly přiřazeny podle následujících definic: QoS PC 1 FTP (přenos souborů je nezbytné realizovat pomocí Best Effort, jinými slovy mít pouze maximální snahu o doručení paketů ke svému cíli. Z FTP serveru k PC4). PC 2 Databáze (stahování databázových odpovědí podle požadavků). PC 3 VoIP (na zpoždění, kolísání zpoždění a ztrátovost velice citlivá služba. Každá prodleva v přenosu paketů může znamenat ztrátu konkrétního paketu a degradaci kvality přenášeného zvuku) PC 4 VoIP + FTP (kombinací dvou služeb je docíleno povinného značkování paketů pro přenos hlasu po internetovém protokolu. Pakety přenášející data pomocí spolehlivého a potvrzovaného přenosu TCP nebudou obsahovat žádnou prioritu). Podle výše uvedeného popisu je zřejmé, že není nezbytné značkovat všechny pakety. Prioritní značkování ToS(em) budou obsahovat pakety pro přenos hlasu. Přenos hlasu je nejcitlivější na změnu libovolného parametrů přenášených služeb (zpoždění, kolísání zpoždění či ztrátovost). Již zpoždění během přenosu na 150 ms vede k mírné degradaci přenášeného hlasu. Dvojnásobná hodnota zapříčiní hovor téměř nerealizovatelným, jinými slovy zpoždění bude tak vysoké, že si jednotlivé strany budou myslet, že je druhá strana neslyší a vše zopakují. Vlivem zpoždění bude vytvořena zpětná vazba.

71 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Bez QOS PC 5 FTP PC 6 Databáze PC 7 VoIP PC 8 VoIP + FTP Přenos všech služeb je realizován i bez QoS za účelem porovnání výsledků. Příklad nastavení služby FTP je zobrazen na obr Bylo vybráno konstantní zatížení, velikost souboru 5 MB (stahována neustále ve smyčkách), symbolické jméno pro lepší identifikaci FTP Server, typ služby (ToS) služba na pozadí nejnižší priorita. Délka simulace byla stanovena na 30 min (jedná se o simulační čas, nikoli potřebný čas k vykonání simulace, ten je podstatně nižší). Obr. 7.2: Příklad nastavení FTP služby. 7.2 Dosažené výsledky V grafu Obr. 7.3 jsou zobrazeny výsledky simulace kolísání zpoždění měřené na PC4 a PC8 použité aplikace VoIP a FTP. Jak již bylo dříve uvedeno pro PC4 byla nastavena podpora kvality služeb, kdežto PC8 provoz neprioritizoval. Srovnáním výsledků bez kvality služby s kvalitou služby, je patrné, že není-li implementována kvalita služby, jitter parametr má značný rozkmit po celou dobu telefonního hovoru (po datové síti). Nejvyšší zaznamenaná hodnota dosáhla cca 250 ms. S touto hodnotou by volající ani volaný nepozorovali žádný pokles kvality hovoru. Zpoždění nedosáhlo kritické hranice 300 ms. Pokud se zaměříme na

72 72 FEKT Vysokého učení technického v Brně modrý průběh. Kvalita služby dokázala hodnotu parametru jitter minimalizovat na hodnotu téměř 0 ms. Upřednostnění paketů s hlasovou službou je nezbytné zavádět již na stanicích, které provoz generují a zároveň dodržet jejich prioritní přenos na aktivních prvcích. Obr. 7.3: Kolísání zpoždění pro VoIP modrá QoS červená bez QoS. V grafu Obr. 7.4 je znázorněn celkový počet zahozených paketů v síti. Měření probíhalo na nadřazeném prvku, routeru. Na směrovači bez použití QoS bylo více zahazování paketů, jako při použitý QoS. Během vytížení sítě bez kvality služby dochází k rychlému naplnění vyrovnávací paměti routeru, proto dochází k častějšímu a dřívějšímu zahazování paketů. Prioritizace umožňuje snížit tuto hodnotu o cca 25 %.

73 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 73 Obr. 7.4: Zahozené pakety v síti měřeno na routerech modrá - bez QoS červená QoS. V grafu obr. 7.5 je zobrazena propustnost sítě. V případě QoS je propustnosti nižší. Čímž je dokázána přítomnost kvality služby, neboť aktivní prvek dokáže upřednostnit přenos hlasu nad přenosem dat. Přenos dat (FTP) by měl vykazovat vyšší přenosové rychlosti, než přenos hlasu. Pro přenos hlasu byl zvolen kodek G.711, který pracuje s přenosovou rychlosti 64 kb/s. Přenos dat probíhal několikanásobně vyšší rychlostí.

74 74 FEKT Vysokého učení technického v Brně Obr. 7.5: Propustnost měřená na routeru bez QoS červená QoS V dané topologii byl otestován vliv parametrů QoS na síť. Z výsledků měření je zřejmé, že použití parametrů QoS v nastaveních routeru výrazně zmenší kolísání zpoždění obr Dále nastavení QoS zmenší celkové ztrátovost (zahazování datových jednotek). Standard e plní svou funkci správně a pole očekávání z teoretických poznatků. Mechanismus pro zajištění QoS funguje velmi efektivně a je schopen zajistit správnou funkci pro multimediální služby, především pro VoIP. Standard e je dobrým řešením, jak zajistit požadovanou kvalitu služeb v bezdrátových sítích WLAN typu

75 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 75 8 Multimédia na internetu Tato kapitola vychází z literatury [21], [22]. Díky obrovskému množství multimediálních dat z velkého množství zdrojů je nutné tyto data určitým způsobem třídit a řadit. Kvůli těmto požadavkům byly specifikovány jisté druhy multimediálních dat a možností přenosů které je možné na internetu či v lokální síti vytvořit. Jsou specifikovány jisté modely, které se hodí do určitých sítí a určitých procesů. Jedná se například o Broadcastový a Multicastový druh přenosu. Tyto přenosy jsou vhodné například do sítí, kde jsou především aktivní prvky a jeden správce. Další možností přenosu multimediálních dat je Unicastový přenos, ten je především využit pro přenos skrz internet kdy není třeba aktivních prvků sítě. Je možné využít i Multicastového přenosu, ale při přenosu multicastu internetem je nutné aby byly zajištěny aktivní prvky a to znamená obrovskou finanční náročnost. Streamování multimediálních dat pro neurčený počet uživatelů které specifikuje multicast je velice složité. Režie, která zajišťuje tento přenos spoléhá plně na přenosovou soustavu. Směrovače vytváří přenosovou soustavu, která zajišťuje efektivní přenos dat od zdroje multimediálního vysílání k jeho příjemcům. 8.1 Metody vysílání multimédií Unicast Jedná se o metodu, kdy jsou pakety přenášeny z jednoho zdroje k jednomu příjemci. Toto vysílání je pravým opakem broadcastu, který vysílá do všech směrů. Tento přenos je nenáročný na přenosovou soustavu, díky tomu, že se jedná jen o přenos mezi dvěma uživateli. Náročnost na síť může stoupnout, pokud je přenášen například multimediální soubor videa ve 4K rozlišení. (Jedná se o ultravysoké rozlišení) Broadcast Příkladem Broadcastového přenosu který již byl popsán stručně výše může být sdílení v sítích Microsoft, nebo například identifikace zařížení kdy toto využívá CDP protocol. Broadcasty mohou také způsobit zahlcení sítě kdy mají špatný vliv na firewall a rozdělení sítě na podsítě. Principem broadcastu je rozdělení na jeden zdroj vysílání a více příjemců tohoto vysílání.

76 76 FEKT Vysokého učení technického v Brně Multicast Multicast pracuje někde na rozhraní unicastu a broadcastu, využívá také multicasting, to znamená paralelní zpracování informací. Jedná se o přeposílání dat z jednoho zdroje k větší skupině příjemců, těchto skupin může být i více. Využívá speciální třídu adres která je rezervována na internetu a to třída D. Její rozsah je od ip adresy až Jedná se o posílání paketu který je duplikován pro skupinu příjemců. Tato technologie má za cíl doplnit technologii unicast a broadcast, protože tyto technologie jsou již zastaralé a nezvládají moderní aplikace. Data která jsou přenášeny multicastem mají podobu například videa, či internetového rádia. Tato technologie nevyžaduje přesně specifikované pořadí přijatých paketů. Multicast vyžaduje adresu vysílače a adresu skupiny příjemců. Informace putuje ze zdrojového uzlu přes spojeníé k síti, která je tvořena datovým tokem, pokud informace v lokální sítí vyžaduje tak se do ní replikuje. Hlavním přínosem multicastového přenosu je snížení zátěže vysílacího uzlu a dále samotné přenosové sítě. Protokoly pro zajištění multimediálních přenosů V dnešní době kdy je maximálním způsobem využíváno video serverů jako je například youtube je důležité definovat přenosy které tento server využívá a nejen tento server, ale například i videokonference atd.. Nejpoužívanější multimediální protokoly pro přenos: RTP (Real-time Transport Protocol) přenosy dat které jsou v reálném čase RTCP (Realtime Control Protocol) tento typ protokolu spolupracuje s protokolem RTP RTSP (Realtime Streaming Protocol) tento protokol je navázán k řízení zvykových a obrazových streamů mezi klientem tedy příjemce a serverem SDP (Session Description Protocol) tento protokol souží k popisu vlastností relací multimediálního přenosu dat

77 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Streamovací formáty Díky narůstajícímu množství technologií, rozlišení, kvality přenosu musely na tyto změny také reagovat různé firmy a jejich zařízení. Dá se říci, že jde o jistý konkurenční boj mezi nimi, bohužel jako poražený odchází konečný uživatel, který si chce přehrát daný videosoubor a zjistí, že jeho počítat jej nepodporuje. Tím pádem nastane dlouhý koloběh zjišťování potřebného kodeku. Formáty, které jsou dále v textu popsány odpovídají systému ve kterém jsou používány. Windows media video převážné využívá firma Microsoft ve svých systémech a tím pádem je jeho převaha vidět i na internetu. Producenti multimediálního obsahu vychází z toho, že většina uživatelů internetu používá operační systém od Microsoftu a proto s radostí tyto formáty využívají. Dalším tahounem ve světe multimedií je firma Apple, ta vytvořila svůj formát QuickTime. Ve svých začátcích byl tento formát jen těžce spustitelný na zařízeních Microsoft a bohužel i naopak. S postupem času se tyto formáty provázaly a tyto problémy byly odbourány. Dnes tyto formáty spolu komunikují a je možné je přehrávat v obou systémech. V posledních letech ale světem multimediálních formátů zahýbala ta skutečnost, že nastala nutnost přenášet obraz ve vysokém rozlišení, a nejen to, ale dokonce i v ultravysokém rozlišení 4K. To znamená u vysokého rozlišení datový tok minimálně 30 Mbit/s a u ultravysokého rozlišení minimálně 120 Mbit/s. Rozbor streamovacích formátu ale začneme dá se říci neutrálním formátem který je již historický formát RealMedia RealMedia Jedna z prvních verzí, která zahýbala, vodami internetu byla vydána počátkem dubna roku Jednalo se o přehrávač zvukového obsahu s názvem RealAudio Player. Byl to ve svém počátku jeden z prvních přehrávačů hudebního obsahu. Tento formát hudebního obsahu pužívá již dnes neznámou koncovku.rm. Nasazení toho formátu bylo dříve jen v internetovém vysílání, protože jeho struktura byla nepřekonatelná. Tato struktura pracuje s takzvanými objekty. Ještě hojněji je využívaná možnost procovat a využívat proměnný tok a to navíc i v tom případě kdy dojde k poškození souboru vlivem špatného přenosu, který může nastat na internetu. Díky přenosu může nastat také přerušení toku objektů a díky výše popsané vlastnosti je možné také určitý objekt přeskočit a pokračovat dále v přenosu. Původní název tohoto streamovacího formátu byl Helix až později se přejmenoval na RealMedia. Formát Real využívá RealAudio a RealVideo. Lety prověřený formát v dnešní době podporuje už i formáty MP3 dále MPEG-4 samozřejmě také QuickTime a v neposlední

78 78 FEKT Vysokého učení technického v Brně řadě i formát Windows Media. Tento formát, který vznikal jako opensource je dnes bezplatný a je třeba jen registrace na webu výrobce. Placená verze, která je dostupná se nazývá RealPlayer Plus a obsahuje více rozšířených možností než standardní verze. Rozdíl v placené a neplacené verzi nastává v tom, že u verze zdarma je možné pro daný záznam zvoli současně pouze dvě hodnoty datového toku přenosu. Tímto je redukována kvalita, která je maximální možná. Tím pádem je to maximum co dokáže klientský systém využít. V dnešní době je prostředkem přehrávání těchto záznamů takzvaný RealOne a nebo také RealPlayer. K vytváření multimediálního obsahu slouží program RealProducer. Dříve byl také využíván program RealPresenter, který byl schopen doplnit záznam o prezentaci. Toho bylo hojně využíváno při streamování různých výukových materiálu nebo při konferencích. Postupem času firma RealMedia začala spolupracovat také s firmou Helix media a tím pádem programy začaly dostávat nové názvy a to HelixProducer a Helix Player. Formát RealMedia donedávna využívala i česká televize ke svému archivu vysílání které má na internetu. Tento archiv je velice obsáhlý a je velice využíván protože je bezplatný oproti konkurenčním stanicím. Nová verze programu RealMedia již dnes podporuje formáty MPEG 2 který je využíván k zápisu na DVD a také Flash video které je běžně dostupné na internetu. Výhodou flash videa je, že nepotřebuje žádný video kodek, jen přehrávač animovaného obrazu flash player QucikTime Tento formát který vyvinula firma Apple v roce 1990 se stal obrovskou konkurencí pro AVI které v té době ovládalo vody multimediálních obrazových souborů. Tento formát používá příponu.mov nebo také příponu.qt. V době svého vzniku to byl velmi propracovaný formát multimediálního souboru. Tento formát zachází s daty jako s atomy. To znamená, že je rozdělí na dále nedělitelné bloky dat. Tento formátový soubor je jádrem mnoha aplikací. Například jej využívá program pro úpravu a střih videa který využívají zařízení firmy Apple s názvem Final Cut Pro, případně také itunes to je takzvaná multimediální banka pro zařízení firmy Apple. Jsou zde uložená obrovská kvanta multimediálního obsahu počínaje fotografiemi, konče nejnovějšími filmy. QuickTime využívá i speciální placenou verzi která má specifická rozšíření, podporuje i základní editování zvuku či videa a různé kvality komprese kdy využívá základní kodek MPEG-4. Quicktime je zcela otevřená aplikace to znamená, že je možné nahlédnout do jeho kódu. Nádstavbu toho programu je možné zakoupit.

79 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 79 Vychází se z toho, že uživatelské nároky splní bezpečně základní verze a náročnější uživatel sáhne po placené které dokáže video i upravovat. Obecně se ale QuickTime nevažuje za rychlou a jednoduchou aplikaci pro běžného uživatele, neposkytuje takové možnosti komprese jako program od Microsoftu Windows Media Video. Apple se také snažil vytvořit nástroj nazvaný Compressor, ten dále rozšiřoval QuickTime Pro. Ten nabízel nové možnosti komprese do DVD MPEG2 a také populární formát H.264. V dnešní době, jsou ale tyto programy postupně vytlačovány freeprogramy putujícími po internetu. Pro profesionální práci je lepší využít aplikaci Final Cut Pro. QuickTime za celou dobu své existence urazil dlouhou cestu a jeho vývoj byl velice rychlý. V posledních letech se již tak nevyužívá díky jeho složitosti, je třeba jen pro některé výše zmíněné programy které jej mají stále zařazeny Windows media Formát windows media video není třeba představovat, jedná se o nejpoužívanější formát pro videosoubory vůbec. Tato skutečnost vychází z toho, že je automaticky instalován a podporován operačním systémem Microsoft. To znamená, že producenti multimediálního obsahu se snaží aby bylo jejich dílo maximálně dostupné všem uživatelům tak tento formát plně využívají. Program pro zpracování multimediálních dat nese název Windows Media Encoder. Nejčastěji je využíván k převodu audio a video formátů, dále pro digitalizaci audio záznamu případně videozáznamu z připojeného zařízení. U audiosouborů je možné nahrávat z mikrofonu u video souborů z webkamery která je připojena po USB nebo FIREWIRE. Tento program je také využíván pro přímé streamování obrazu do internetu. Jeho výhodou je dostatečná podpora všech multimediálních souborů a formátů. Jedná se například o podporu MP3, WAV, JPG, ASF, MPEG, AVI, WMV, WMA. Program je také využíván pro záznam pracovní plochy počítače, automaticky je schopen všechna data zaznamenat a streamovat, případně uložit do souboru. Bohužel nevýhodou všech těchto procesů je náročnost na výpočetní výkon pracovní stanice. V posledních letech s nástupem vícejádrových procesorů a obrovských rezerv v operačních pamětích a rychlosti disku je to bezvýznamná připomínka. Jak již bylo zmíněno na začátku, při přenosu živého multimediálního streamu je nejčastěji využíván právě Windows Media Encoder a Windows media Video. V posledních letech je ale i tento gigant vytlačován pro svou špatnou kompatibilitu a složitost.

80 80 FEKT Vysokého učení technického v Brně Uživatelé nechtějí instalovat složité programy a studovat dlouhé manuály. Proto se vývojáři snaží všemi způsoby zjednodušit přenos dat a multimediální streamování Youtube live video streaming Stránku youtube není třeba představovat. Obsahuje neuvěřitelné množství multimediálního obsahu z celého světa. Vývojáři této stránky se snaží uživatelům usnadnit život a tím pádem je odpostit od náročnosti video streamingu podle konvenčních metod. Kdy je třeba zařídit adresu serveru viditelnou na internetu, dostatečnou kapacitu linky a další již nezmiňované složitosti. Při využití Youtube video streamu je třeba jen kvalitní webkamera připojená k počítači a o vše ostatní se postará samotné youtbe. Tato aplikace má také možnost využít zdroj vysílání případnou střihovou kartu připojenou do počítače ale bohužel i tato aplikace a naprostá jednoduchost nedosahuje profesionálních rozměrů Black Magic Video Streaming Až firma Black Magic přisla s převrátným zařízením, které je schopno připojit až desítku kamer a obraz z těchto kamer živě zpracovat a streamovat na internet. Bohužel stabilita tohoto systému a jeho jednoduchost je vykoupena cenou tohoto hardwarového a softwarového řešení. 8.3 Obsah multimediálních dat Audio data Jedná se o nejjednodušší a tím pádem i nejspolehlivější formát multimediálních dat který je složen z audio nahrávek případně se může jednat o živý přenos zvuku. Tento datový proud může sloužit jako komunikace mezi účastníky či například k jazykovému vzdělávání. Tento audio formát je schopen upravovat svůj datový tok na základě přenosu pomocí pomalé sítě. Samozřejmě tím pádem se degraduje i kvalita přenosu.

81 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Audio a snímky Přenos těchto dat je využíván nejčastěji při výuce. Jedná se například o přednášky či konference. Data obsahují zvukovou stopu a prezentaci. V posledních letech systémy umožňují připojit i videopřenos kde je snímán mluvčí Video Při přenosu videodat se nejčastěji přenáší obrazové klipy, tato služba nesmí být respektive neměla by být provozována na sítích s nedostatečným zabezpečením aby nedošlo ke zneužití obsahu. Dále jsou kladeny požadavky na přenosovou kapacitu sítě, například při přenosu video souborů ve vysokém rozlišení. Video je v neposlední řadě také náročné na přípravu pro přenos Animace V tomto případě se jedná nejčastěji o soubory, které jsou ve formátu Macromedia Flash kdy jsou přenášeny například animace textu nebo grafické obrazce Živé vysílání Tato technologie je také nazývána webcast neboli online vysílání kdy je přenášen obraz i zvuk. Je to jinak řečeno živé vysílání, které je doplněno o prezentaci a dále také o živý chat. 8.4 Komprese obrazových dat Další nedílnou součástí je komprese obrazových dat, kdy je důležité všechny tyto kompresní algoritmy sjednotit protože vychází například z různých zařízení atd. Jedná se o proces normalizace a tím pádem vzniká multimediální informace která má dané přesné specifikum prostřednictvím uživatelské aplikace. Komprese statistických obrazových dat Rok 1986 znamenal přelom v kompresi obrazových dat, protože skupina Joint Photographic Experts Group vytvořili standard JPEG který je v obrazové kompresi používán v aktualizovaném formátu dodnes. Vývin tohoto formátu zaštítila organizace ISO neboli

82 82 FEKT Vysokého učení technického v Brně International Standards Organisation a dále také ITU-T neboli International Telecommunication Union. Výsledkem byl standard, který měly používat všechny aplikace, které se zabývali prací s obrazem, jednalo se především o jeho kompresi. JPEG byl převážně využit pro víceúrovňové kódování především barevných obrazů Popis standardu JPEG (Joint Photographic Experts Group) Tento standard zahrnuje několik typů komprese digitálních barevných a černobílých obrazů. Dále jsou v tom standardu definovány čtyři režimy procesu. Norma, která jej specifikuje se nazývá JPEG ISO/IEC Sekvenční zpracování obrazu Tento způsob zpracování obrazu kóduje zleva doprava a shora dolů. Algoritmus je implementován jak hardwarově tak i softwarově. Progresivní zpracování obrazu Jedná se o zobrazení a následné kódování v násobném snímání. Snímání je výhodné pro ty aplikace které při přenosu mají svůj čas příliš dlouhý. Obraz se vykreslí nejdříve hrubě a v dalším načítání se dovykreslí naprosto přesně. Bezeztrátové zpracování obrazu Hlavním bodem tohoto kódování je dodržení přesné hodnoty vzorkování obrazu. Je zapojeno v těch aplikacích ve kterých by ztráta jednoho bodu znamenala chybu pro další zpracování. Je to například v lékařství či stavebnictví a dalších. Hierarchické zpracování obrazu Tento způsob kóduje do více rozlišení, které je poté možné dekódovat do stejné úrovně aniž by docházelo ke kódování všech úrovní. Je zde využito i multicastového přenosu dat. Při přenosu těchto obrazových dat pomalou sítí také dochází k vypuštění nějkterých dat.

83 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 83 Komprese pohyblivých obrazových dat Tato kapitola popisuje ve stručnosti velice ožehavé téma a to je komprese obrazových dat. V dnešních letech už i obyčejné hodinky dokáží nahrát video ve full HD rozlišení konče 4K kamerovými řetězci které vyprodukují několik GB dat za vteřinu. Jak tyto všechny data archivovat, jak je přenášet po internetu. Budou tyto data dostupná i za několik let? To jsou otázky, které hýbou vodami internetu. Proto je třeba velikost videosouborů redukovat a tím tak alespoň přispět k možnosti uchovávání dat na více médiech, počínaje flash disky, a konče datovými centry MPEG Moving Picture Experts Group Tento standard popisuje nejpoužívanější obrazovou kompresi videosouborů a audiosouborů na světě. Je vyvíjen organizací ITU-T Video Coding Experts Group (VCEG). Jedná se o standardizaci kodeků H.261, H.263, H.264. Dále se jedná o standard MPEG Moving Picture Experts Group a kodeky MPEG-1, MPEG-2, MPEG-4. U všech těchto standardů je dodržen stejný princip kódování. Skupina MPEG je obsažena v organizaci Joint Technical Commitee (JTC1) která spadá pod organizaci International Standarsd Organization a Internation Electrotechnical Commision. Ve zkratkách ISO a IEC. MPEG-1 Ke standardizaci tohoto formátu došlo v roce Využívá progresivní to znamená neprokládané řádkování, kdy dochází ke kompresi video signálu na malou bitovou rychlost přibližně 1,5 Mbit/s. Obecným faktem u komprese videa je to, že komprese je výpočetně náročnější než dekomprese, protože dochází obecně řečeno ke zmenšování velikosti a ke zjednodušování obrazu. Formát MPEG-1 je využit pro kompresi video záznamů, které jsou přenášeny na nosiči CD-ROM. Normou pro tento formát je standard ISO/IEC Tento formát se už v posledních letech úplně přestal používat protože byl vytlačen formátem H.264 případně MPEG-2.

84 84 FEKT Vysokého učení technického v Brně MPEG-2 Rok 1995 byl přelomový pro kompresi videa, nejen že přicházely na trh procesory Pentium 1s technologií MMX se speciální podporou videa ale byl také vytvořen standard MPEG-2. Začal se také využívat pro distribuci digitálního televizního vysílání. Jedná se o speciální upravenou a nadstavenou verzi MPEG-1. Kóduje prokládané snímky rychlostí přenosu až 7 Mbit/s. Tento formát dokáže záznamy kvalitněji kódovat jak MPEG-1. V posledních letech je na této normě postaveno digitální televizní vysílání v České republice a v neposlední řadě tuto technologii využívají také DVD video disky. Obě tyto technologie jsou ale postupně nahrazovány u digitálního vysílání technologií MPEG-4, které pracuje v HD rozlišení a DVD disky BLU-RAY disky které také pracují ve vysokém rozlišení. MPEG-2 je standardizován jako ISO/IEC MPEG-3 Původním nápadem při standardizaci tohoto formátu bylo jen rozšíření formátu MPEG-2 pro vysoké rozlišení, ale jak plynul čas tak norma pro tento standard nakonec nebyla vytvořena a byl vytvořen úplně nový formát s názvem MPEG-4. MPEG-4 Tento standard poskytuje velkou flexibilitu a možnosti interaktivního přístupu k multimediálním datům. Je schopen scénu rozložit na objekty a ty odděleně kódovat pro ně nejvhodnějším algoritmem. S příchodem tohoto standardu se objevily nové techniky obrazové komprese, nejvýznamější je dnes například technika 3D. Tento standard se dnes začíná uchycovat v digitálním terestriálním vysílání. Normou toho standardu je ISO/IEC H.264 Tento standard je odvozen od formátu MPEG-4 AVC. Jedná se o zatím nejmodernější a nejlépe propracovanější kompresní formát který je využíván moderními kamerovými systémy, mobilními telefony a v neposlední řadě také Blu-ray přehrávači. Tento standard je

85 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 85 schopen nejúčinněji ze všech dosud představených formátů komprimovat obrazová data. Při kompresi je možné zredukovat obrazový videosoubor na více jak polovinu původní velikosti a to při dodržení podobné kvality obrazu. Formát H.264 je využíván především u megapixelových kamer a bezpečnostích kamer které tím pádem velice málo zatěžují síť. Normou toho standardu je ISO/IEC MJPEG (Motion JPEG) Standard je popsán jako hýbající se obrázky. Využívají jej digitální kamery, případně starší webkamery a IP kamery. Každý snímek je komprimován zvlášť pomocí formátu JPEG. Zajímavé je, že tento formát není oficiálně standardizován. Tento formát je součástí více kodeků například libavcodec z frameworku FFmpeg. Bohužel při bližším využití je vidět chyba nestandardizace toho formátu protože nastávají chyby komprese. Snímky, které projdou kompresí jsou klíčové a tím pádem dochází k rychlému posunu videa. Proto je možné tento formát použít ke kompresi videa a případně i k jeho úpravě. Nevýhodou práce s tímto formátem je velikost videa, pokud jej srovnáváme s MPEG- 4. Princip práce MJPEG spočívá v tom, že člověk vnímá frekvenci snímků 16 fps už jako video, takže je možné při této rychlosti posílát sérii snímků JPEG. WMV Formát Windows media Video byl již výše popsán, vyvinula jej společnost Microsoft, kdy to byl jeji první záchvěv v oblasti zpracování a přehrávání videa a dá se říci i multimediálního obsahu. Další postup byl začlěnění do operačního systému a tím následovalo rychlé rozšíření k obrovskému množství uživatelů a tím pádem rozšíření tohoto kompresního formátu Komprimační technologie ve zkratce Výše uvedené komprimační technologie jsou v posledních letech velice rychle obměňovány a updatovány. Dá se říci že formát MPEG-1 postupně mizí ze světa s koncem

86 86 FEKT Vysokého učení technického v Brně CD disků. Postupem času se to stejné stane s formátem MPEG-2 s koncem DVD disků a nástupem flash disků. Záměrně nejsou uvedeny BLU-RAY disky které měly být nástupcem DVD disků, ale pro jejich cenu a pořizovací náklady na přehrávač se dosud tak široce nerozšířili. Dochází spíše k rozšíření flash disků, které přehrávají chytré televize hned po připojení do jejich USB portu. Pro přenos dat po internetu a případně i pro jejich ukládání je využíván formát H.264, který využívá Youtube i Vimeo Streamování multimediálního přenosu pomocí síťového Enkodéru Tyto zařízení jsou jinak také nazývány webové videoservery. Jsou schopny převést určitý analogový signál například z videokamery, či videorekordéru do počítačové digitální podoby. Tyto videoservy obsahují několik analogových vstupů kdy se jedná například o BNC konektor a po připojení kamery a internetového rozhraní a následném připojené do sítě dokáží tento obraz streamovat. Tato zařízení tedy provádí proces komprese a streamování analogového signálu v reálném čase. Také je dokáže zároveň posílat do internetu, kde je možné, aby jej sledovalo několik tisíc uživatelů. Všechny tyto parametry ale závisí na typu zařízení. Tato zařízení také bosahují webové rozhraní které slouží jak pro řízení tak i pro připojení uživatelů například pomocí internetových prohlížečů jak již bylo zmíněno výše. Jednoduchost těchto zařízení je ohromující, ale samozřejmě zde platí pravidlo, že kvalita odpovídá ceně, takže u některých levnějších zařízení může docházet k zasekávání a chybovosti přenášeného obrazu. Tyto video servery také umožňují připojení filmových kamer, při přenosech z více kamer, dokáží tento obraz digitalizovat do počítače, v něm zpracovat a dále streamovat do internetu. Některé video servery také obsahují pevný disk, na který je možné data ukládat, archivovat atd. Zařízení také obsahuje komunikační porty RS-232 pomocí kterých je možné ovládat speciální bezpečnostní kamery jako je například poloha polohovací hlavice, ovládat zoom či infra přísvit. Výrobci také podporují zpětnou konverzi na analogový signál. To znamená že je možné přenést obraz internetem a potém jej přenést přes další zařízení zpět na analogovou telivizi či monitor a to vše bez nutnosti počítače. Záznam videa je umožněn pomocí nadstavbového softwaru který je dodáván spolu s videoenkodéry, je možné jej využít také pro management IP kamer. Nevýhodou těchto zařízení je obrovská složitost systému a nutnost kvalifikované obsluhy a její pořízovací náklady jsou vysoké. Oproti klasická webová kamera poskytne podobné funkce, ale ne

87 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 87 v takové kvalitě. Pokud dojdeme k výhodám a nevýhodám tak při porovnání s IP kamerou je možné takřka žádné rozdíly neshledat Popis programu VideoLanClient VLC Media Player je jedním z nejpoužívanějších multimediálních přehrávačů. Jde o volně šiřitelný program s otevřeným zdrojovým kódem, který disponuje spoustou užitečných funkcí. Oblíbený je zejména díky velkému množství podporovaných formátů, které zvládá přehrát bez nutnosti instalace jakýchkoli dodatečných kodeků. Bez problémů si poradí s MPEG-1, MPEG-2, MPEG-4, DivX, XviD, H.264, WebM, WMV, MKV, mp3, ogg a pod. Kromě toho také přehrává DVD, Audio CD a VCD. Podpora titulků je samozřejmostí. Kromě standardního přehrávání je možné využít také přehrávání z různých streamovacích protokolů. VLC Media Player dokáže vytvořit stream server v unicast, multicast, IPv4 a IPv6. Spolehlivě funguje také konverze médií do požadovaných formátů. Je to velmi jednoduchý, rychlý, výkonný, ale zároveň hardwarově nenáročný přehrávač. Jednou z výhod programu je také rozsáhlá dokumentace velkého množství funkcí, které přehrávač zvládá. Samotný program, ale i šablony a jiné doplňky do VLC si můžete stáhnout zcela zdarma. Projekt začal jako práce studentů franckouzské technické školy Écolé Centrale Paris. Bylo to ve městě Chatenay Malabry. Cílem bylo vytvoření programu, který by uměl uživatelů sítě poskytnou videa. A v neposlední řadě bylo třeba také vytvořit klienta který by tato videa přehrával. V počátečních fázích měl tento výtvor obrovský ohlas a tím pádem došlo k tomu, že se přehrávač a server mohli zaštítit licencí GPL. Server, který byl integrován do klienta se přejmenoval na VLC media player. Jedna z prvních verzí tohoto programu pracovala jen pod operačním systémem Linux. Dále se převedla s postupem času na vícesystémovou. V roce 2009 byla vydána první verze. Tuto verzi již vytvářelo asi 20 programátorů z celého světa. Program VLC má více jak 380 modulů a je postaven na FFmpeg, tím pádem již obsahuje nepřeberné množství kodeků. Důležité body ve zkratce:

88 88 FEKT Vysokého učení technického v Brně Název projektu: VideoLAN Projekt Web: Velikost: 9 MB Licence: Freeware Jazyk: Angličtina, Čeština, a další Formáty: MPEG, DivX, XviD, Windows Media, H.264, QuickTime, MP3, WMA, Ogg Vorbis, AAC, FLAC, AC3, DTS OS: Win 98/ME/NT/2000/XP/2003/Vista Technologie vytvoření streamovacího serveru Tato technologie využívá CGI skript, který odesílá obrazová data aplikace která je speciálně naprogramovaná. Příkladem tohoto procesu může být aplikace, která pracuje na formátu JAVA. Popis CGI skriptu CGI skript si lze představit jako program, který na základě požadavku uživatele spustí příslušný webový server který je veden jako samotný proces. Internetová stránka je výsledek dat, které přebere CGI skript z uživatelských dat. A tyto stránky zpětně shlédne uživatel. Jedná se vlastně o spustitelný soubor například i s příponou EXE nebo dávkové označení BAT. Výhodou skriptu CGI je jeho jednoduchost a přehlednost. Nevýhodou je ale rychlost startu aplikace pokud je nutnost založení nového procesu, ve kterém je poté spuštěná aplikace kterou vyžaduje uživatel. CGI skript byl vytvořen k tomu, aby pomocí webového serveru umožnil jeho klientům zasílat statistické dokumenty, kterou jsou již připraveny a mohou být vystaveny na internet. Dalším krokem bylo upravovat data dokumentů a zase je postupně aktualizovat na web. Příkladem těchto skriptů jsou databázové aplikace. Nevýhodou bylo předpřipravení všech výstupu ve statické formě, díky množství a proměnlivosti dat. Proto bylo vždy výhodnější tato data upravovat dle odpovědi požadavku. Tento problém řeší funkce dynamických virtuálních dokumentů. Žádost o virtuální dokument je vlastně URL, které je v dotazu. CGI programy nebo také CGI skripty řeší tyto virtuální dokumenty. Je to vlastně externí program který je spuštěn na základě uživatele a ovlivňuje webový server kde je vytvořen proces.

89 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 89 Pravidlem, komunikace jsou normy CGI skriptu. Díky tomu je možné tyto skripty využívat na více serverech. Bezpečnostní hlediska CGI skriptů: Pravidla, která je nutné dodržovat při tvorbě skriptu o Kontrolovat data, která zašle klient o Kontrolovat cesty a jména o Neukládat skript do adresáře, ke kterému mohou přistupovat uživatelé Skript je velice dobrým interaktivním nástroje při komunikaci uživatele se serverem. Ale jako vše i tato interakce představuje možné riziko. Spuštění skriptu a jeho provoz. Při spuštění je nutná kontrola dotazu a druh požadovaného dokumentu. Je nutné ověřit, zda je tento soubor spustitelný případně, zda je to jen statický dokument. Při specifikaci MIME je skript uložen do html souborů a následné spuštění souborů CGI. Varianta je velice rychlá a pružná ale je nutné dodržet větší zabezpečení, které je v rámci přístupu dat klientům. Při specifikaci adresářové struktury, která obsahuje, skript je nutné určit přesnou pozici požadovaných dat. Tato metoda je rychlejší a poskytuje větší kontrolu dat.

90 90 FEKT Vysokého učení technického v Brně 9 Metodologie testování v telekomunikačních sítích Kapitola je zpracována za přispění [23], [24], [25], [26]. 9.1 Úvod RFC 2544 je nejkomplexnější test. Specifikace byla vyvinutá společností Internet Engineering Task Force (stejní lidé, kteří vynalezli web, atd.). RFC 2544 definuje způsob, jak měřit všechny kritické výkonové charakteristiky obvodu. Prvním z nich je měření propustnosti, v podstatě maximální přenosová rychlosti rámců, který pro Ethernet může být v rozmezí od 2 megabitů za sekundu po jeden gigabit za sekundu a dále. Druhým je ztrátovost, tj. kolik rámců síť ztrácí mezi jedním koncem a dalším. Burst testování je třetí a charakterizuje schopnost obvodu zvládnout rychlosti rámců nad zadané maximum. Například, poskytovatel služeb poskytuje 20 megabitů, který má schopnost propustit 50 megabitů za sekundu na krátkou dobu (méně než jednu sekundu). Tak zákazník nemusí platit navíc za šířku pásma, kterou potřebuje jen zřídka. Čtvrtým parametrem je zpoždění nebo latence. S globálním nasazováním multi třídových Ethernetových služeb, starší zkušební normy, jako RFC 2544 již nejsou dostatečné k ověření dnešních dohod o úrovni služeb (SLA). S rostoucími požadavky zákazníků na novou metodiku testování, kvůli agresivním plánům výstavby, z velké části poháněné přechodem na celosvětovou paketově orientovanou mobilní páteřní infrastrukturu, EXFO bylo první, kdo zavedl nově schválenou normu ITU-T Y.1564 (dříve známou jako Y. 156sam) na trh na své modulární testovací platformě Ethernetu. Dokonce ještě předtím, než byl standard oficiálně schválen. Během zahájení konceptu nového standardu ITU-T Y.1564, v červnu 2009, EXFO úzce spolupracovalo s odborníky z průmyslu a během schvalovacího procesu rozpoznalo naléhavou potřebu účinnějšího a kompletního způsobu uvedení do provozu, a odstraňování problémů mobilní páteřní sítě a obchodních služeb Ethernet. V následujících kapitolách budou představeny vybrané části obou doporučení, jak RFC 2544 [3], tak ITU-T Y.1564 [4]. Pro bližší a aktuální informace je vždy nutné stáhnout a prozkoumat poslední schválenou verzi doporučení.

91 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Doporučení ITU-T Y.1564, testovací metodologie aktivace služeb Ethernet Shrnutí Doporučení ITU-T Y.1564 definuje zkušební metodiku, která může být použita při posuzování správné konfigurace a výkonnosti sítě Ethernet pro doručení služeb Ethernet. Tato out-of-service metodologie testování byla vytvořen tak, aby poskytovatelé služeb mohli mít standardní způsob měření výkonu služeb na bázi Ethernetu. ITU-T Y.1564, schváleno , edice 1, studijní skupina Úvod Ethernetové služby se výrazně vyvíjely s nasazením Ethernetu v sítích poskytovatelů služeb. Ethernet se nachází nejen na uživatelském rozhraní sítě (UNI), ale může být umístěn kdekoliv v síti. Díky schopnosti priority provozu, jeho vestavěné odolnost a vysoké dostupnosti, poskytovatelé služeb nyní používají tuto technologii k poskytování pokročilých služeb. Bohužel, v současné době neexistují žádné standardizované metodiky zkoušek, které mohou přinést očekávané měření výkonových parametrů, jak je uvedeno v ITU-T Y Před tímto doporučením, jedinou metodikou široce používanou pro posouzení výkonnosti služeb síti založených na Ethernetu bylo IETF " Srovnávací metodika pro síťová propojovací zařízení ", známé také jako IETF RFC RFC 2544 byl vytvořen s cílem vyhodnotit výkonnostní charakteristiky síťových zařízení v laboratoři. To bylo široce upraveno pro výkonnostní metriku síťových služeb na bázi Ethernetu, protože neexistovala jiná metodika pro měření množství definovaných v IETF RFC Díky své schopnosti měřit propustnost, zpoždění, ztrátovost rámců a špiček (back-to-back test), IETF RFC 2544 by mohlo být pravděpodobně použito k poskytnutí výkonnostní metriky. Nicméně, to by bylo za zamýšleným rozsahem IETF RFC Toto doporučení vyplňuje metodickou mezeru pro měření provozních síťových služeb Ethernet. Také služby na bázi Ethernetu se vyvinuly a zahrnovaly více funkcí a složitostí, než ty, které se vztahují k rozsahu IETF RFC Srovnávací metodika IETF RFC 2544 není použitelná pro aktivaci služeb Ethernet, protože: IETF RFC 2544 neuvažuje testy více časových trvání, protože jsou často prováděny v provozních sítích s časově proměnným postižením. Jeho postupy našly absolutní hranice výkonu síťového prvku v laboratorním prostředí, spíše než ověření, že služba je dodávána na dohodnuté úrovni.

92 92 FEKT Vysokého učení technického v Brně Latence se měří v omezené míře, pouze na jednom rámci každé dvě minuty, a to pouze na maximálním přenášeném zatížení bez ztráty rychlosti, což je velmi pravděpodobně mnohem vyšší, než je dohodnutá rychlost informace. Neposkytuje ověření konfigurace a výkonu CIR, CBS, EIR, EBS a CM, všech důležitých složek profilu šířky pásma. A konečně, důležité atributy služeb Ethernet, jako je například odchylka zpoždění rámce, nejsou součástí metodiky Rozsah Toto doporučení definuje zkušební metodiku out-of-service pro ověření správného nastavení a výkonnosti služby Ethernet pro oznámení a doručení zákazníkovi. Testovací metodologie se vztahuje na bod-bod (point-to-point) a bod-více bodů (point-to-multipoint) připojení (pomocí párové konfigurace) ve vrstvě Ethernet a síťové části, které poskytují nebo přispívají k dotování těchto služeb. Toto doporučení nedefinuje síťové architektury nebo služby Ethernet, ale definuje metodiku pro testování služby na bázi Ethernetu ve fázi aktivace služby. Zejména se zabývá testováním mimo rozsah metody IETF RFC 2544, jak je uvedeno výše. Toto doporučení předpokládá specializované testovací zařízení v metodice testu. Má se za to, že tato zkušební metodologie může být implementována jako testovací funkce uvnitř síťového prvku Reference Následující doporučení ITU-T a další odkazy obsahují ustanovení, která tvoří ustanovení tohoto doporučení. V době uveřejnění byla platná uvedená vydání. Všechna doporučení a další odkazy jsou předmětem revize. Uživatelé tohoto doporučení se proto vyzývají, aby prozkoumaly možnosti použití nejnovějších vydání doporučení a dalších odkazů uvedených níže. Seznam aktuálně platných doporučení ITU-T je pravidelně publikován. Odkaz na dokument v tomto doporučení nedává, jako samostatný dokument, status doporučení. Pro relevanci jsou doporučení a další odkazy ponechány nepřeloženy. [ITU-T G.8010] Recommendation ITU-T G.8010/Y.1306 (2004), Architecture of Ethernet layer networks, plus Amendment 1 (2006) and Amendment 2 (2010).

93 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 93 [ITU-T G.8011] [ITU-T G ] [ITU-T G ] [ITU-T G.8012] [ITU-T M.2110] [ITU-T Y.1543] [ITU-T Y.1563] [ITU-T Y.1730] [ITU-T Y.1731] [IEEE 802.1Q] [MEF 10.2] Recommendation ITU-T G.8011/Y.1307 (2009), Ethernet service characteristics. Recommendation ITU-T G /Y (2009), Ethernet private line service. Recommendation ITU-T G /Y (2009), Ethernet virtual private line service. Recommendation ITU-T G.8012/Y.1308 (2004), Ethernet UNI and Ethernet NNI, plus Amendment 1 (2006). Recommendation ITU-T M.2110 (2002), Bringing into service international multi-operator paths, sections and transmission systems. Recommendation ITU-T Y.1543 (2007), Measurements in IP networks for inter-domain performance assessment. Recommendation ITU-T Y.1563 (2009), Ethernet frame transfer and availability performance, plus Amendment 1 (2009). Recommendation ITU-T Y.1730 (2004), Requirements for OAM functions in Ethernet-based networks and Ethernet services. Recommendation ITU-T Y.1731 (2008), OAM functions and mechanisms for Ethernet based networks, plus Amendment 1 (2010). IEEE 802.1Q-2003, IEEE Standards for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks. Technical Specification MEF 10.2 (2009), Ethernet Services Attributes, phase Definice termíny definované v tomto doporučení Virtuální spojení Ethernet (EVC), (odvozeno z [MEF 10.2]: sdružení dvou nebo více uživatelských síťových rozhraní (UNIs), která omezuje výměnu rámců služby mezi těmito rozhraní. Rychlost informace: Průměrná přenosová rychlost Ethernet servisních rámců v místě měření začínající prvním bitem MAC adresy a konče posledním FCS bitu.

94 94 FEKT Vysokého učení technického v Brně POZNÁMKA v [MEF 10.2] naleznete jasné diskuse rámců Ethernetových služeb a konkrétní příklady informačních rychlosti rychlosti committed information rate (CIR) a excess information rate (EIR). Například, Port Ethernet 100 Mbit/s zvládne celkovou informační rychlost asi od 77 Mbit/s do 99 Mbit/s v závislosti na průměrné velikosti rámce přenášených Ethernetových rámců. Aktivace služby: krok přináší síťové funkce do provozu pro případné použití zákazníkem před oznámením zákazníkovi, že funkce je připravena k použití. Testovací metodologie aktivace služby: Postupy prováděné po aktivaci služby za účelem ověření, že nové volitelné síťové služby používané zákazníkem pracují správně před oznámením zákazníkovi, že funkce je připravena k použití. Kritéria přijatelnosti služby: Sada kritérií užívaných k zajištění toho, aby služba splňovala požadavek na funkčnost a kvalitu, a že služba je připravena k provozu, kdy byla nasazena. Tok testu: protokol vyhovující vzorku velikosti rámce použitého k simulaci proudu servisních rámců a poskytují základ pro měření a výsledky testů. Každý jedinečný tok testu musí být kategorizován podle jeho zdrojové a cílové adresy a dalších informací záhlaví, jako je například QoS/CoS ve vrstvě Ethernet (všech osm [IEEE 802.1Q] priorit) a případně IP vrstvu. Konfigurace vrstvy protokolu nad IP vrstvou může být použita jako součást konfigurace toku, protože testovaná síť může požadovat tyto vrstvy pro přenos dat mezi SRC a DST. Využitá rychlost linky: Průměrná přenosová rychlost Ethernet linky v místě měření, včetně bitů a) rozvržitelné na minimální dobu trvání každé mezi-rámcové mezery (ale ne počet bitů přiřaditelný části každé mezi-rámcové mezery delší, než je minimální doba trvání), b) v preambuli, c) v začátku oddělovače rámce, a d) v rámci Ethernet služby počínaje prvním bitem MAC adresy a konče posledním bitem FCS. POZNÁMKA Tato rychlost se počítá před expanzním efektem použité substituce kódu na fyzické vrstvě. Tak například, 1 Gbit/s port Ethernet má 1 Gbit/s maximálně využitelnou rychlosti linky, i když bitový kód 8/10 substituce běží na skutečném fyzickém rozhraní 1,25 Gbit/s.

95 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Konvence Toto doporučení používá následující pojmy pro označení úrovní požadavků: MUSÍ nebo POŽADUJE znamená, že specifikace je nezbytnou podmínkou testovací funkce, která požaduje dodržování tohoto doporučení. MĚL BY znamená, že mohou existovat pádné důvody, proč vynechat tuto specifikaci, ale důvody musí být plně pochopeny, jinak je to silný návrh na testovací funkce, která požaduje dodržování tohoto doporučení. MŮŽE znamená, že specifikace je opravdu volitelná a nemusí být provedena v testovacích funkcích, které požadují dodržování tohoto doporučení Síťová architektura Ethernet Ethernet služby jsou poskytovány prostřednictvím vrstvené architektury. Informace pro uživatele budou přepravovány na vyšší vrstvy (obvykle IP), které pak budou zapouzdřeny ve vrstvě Ethernet a konečně přenášeny přes síť k cíli. Pro zajištění přenosu end-to-end informací uživateli, vyšší vrstva ve zdrojovém CE použije vrstvu Ethernet pro přístup k síti. Vrstva Ethernet má end-to-end význam jen pro pár zdrojových a cílových MAC adres. Síť se skládá ze spojově orientovaných nebo nespojovaných linek, které jsou připojeny k mostům, které zpracovávají Ethernet vrstvu uvnitř sítě. Pokaždé Ethernetový rámec prochází vrstvou Ethernet, bude zpracován pro integritu a poslán do dalšího mostu přes připojení nižší vrstvy. Nižší vrstvy jsou založeny na různých technologiích, například, SDH, OTN, PDH, MPLS, ATM a ETY. Výkon všech vrstev Ethernet a nižších vrstev, bude mít vliv na výkon end-to-end sítě sloužící k poskytování služeb. Vyšší vrstvy mohou být použity k tomu umožnění end-to-end komunikace. Vyšší vrstvy mohou obsahovat protokoly jako IP, které umožňují větší škálovatelnost pro nasazení v síti. Ostatní protokoly, jako TCP, poskytují možnost znovu přenášet rámce, pokud by mělo dojít ke ztrátě rámce. Bohužel, dvě z nevýhod TCP jsou (1) přidané zpoždění v přenosu uživatelských informací a (2) možné omezení propustnosti v důsledku interakce maximální inzerované velikosti okna, zpožděné šířce pásma produktu, ztrát rámce a zpoždění přenosu rámce. Vzhledem k tomu, že doporučení zahrnuje zkušební metodiku, která se použije při aktivaci služeb na bázi Ethernetu, výkonnost a podrobnosti součinnosti s jinými protokoly, jako jsou LACP, IP, TCP a UDP, jsou mimo oblast působnosti tohoto doporučení.

96 96 FEKT Vysokého učení technického v Brně Atributy služby Ethernet Jak již bylo zmíněno v úvodu, atributy služby Ethernet nejsou definovány v ITU-T Y Proto tato klauzule shrnuje důležité pojmy nalezené v rodině doporučení ITU-T G Obr. 9.1: Oblastech služeb Ethernet z pohledu jednoho poskytovatele. Jednoduchý příklad oblasti služeb Ethernet je uveden na Obrázek 1. Tato síť, částečně reprodukována z ITU-T G.8011, ukazuje různé části sítě, které podporují instance služby Ethernet. Dále je prokázáno, že UNI hraniční bod se vyskytuje ve středu přístupové linky, nebo přesněji, že UNI je referenční bod, který rozděluje související funkce UNI na komponenty zákazníka (UNI-C) a sítí (UNI-N). Další podrobnosti o UNI jsou definovány v ITU-T G Z pohledu poskytovatele služby, který potřebuje doručit služby z UNI-C do UNI-C, a to je z tohoto pohledu, testovací metodika byla vytvořena. Ethernet síť zákazníka obsahuje poslední kus zařízení, které se připojuje k síti operátora. Tato poslední část zařízení se nazývá Customer edge (CE). Port na CE, který se připojuje k síti operátora přes UNI se nazývá UNI-C. Stejně tak port provozovatele, který je prezentován zákazníkovi v UNI se nazývá UNI-N. CE a síť operátora si vyměňují rámce služeb přes UNI, mezi UNI-C a UNI-N. Rámec služeb rámec Ethernetu přenášený přes UNI k poskytovateli služeb (tzv. vnikající rámec služeb) nebo Ethernetového rámce přenášeného přes UNI k CE (zvaný hraniční rámec služby). Mnohé služby pracují na každém UNI, které jsou roztříděny podle jejich atributů, které zahrnují mimo jiné (viz např. MEF 10.2): Typ spojení. QoS (zahrnující VLAN informace), typ provozu (data vs. management), atd. Profil šířky pásma: CIR, CBS, EIR, EBS, CF, a CM. Kritéria propustnosti: FTD, FDV, FLR, AVAIL, atd.

97 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Profil šířky pásma Dle ustanovení 7.10 [ITU-T G.8011], profil šířky pásma je použitelný na instanci služby a je použitelný na vstupní a výstupní UNI. Definuje horní mez objemu očekávaných rámců služeb patřící k určité instanci služby. Profil šířky pásma definuje následující čtyři parametry provozu: 1. Committed Information Rate (CIR), 2. Committed burst size (CBS), 3. Excess information rate (EIR), 4. Excess burst size (EBS). CIR a CBS jsou spojeny takovým způsobem, že CBS musí být definován, pokud je CIR nastaven na hodnotu, která je větší než nula. EIR a EBS jsou spojeny stejným způsobem jako CIR a CBS. CIR může být interpretován jako maximální trvalá informační rychlost (IR), kterou se síť zavázala převést, při splnění úrovní výkonu, zaručený v dohodě o úrovni služeb (SLA - service level agreement). Výkonnostní metriky, pokud jde o FTD, FDV a FLR se vztahují pouze na ty rámce, které jsou přenášeny v nebo pod CIR. CBS je počet alokovaných bytů k dispozici pro dávky vnikajících rámců služeb vysílaných dočasnými rychlostmi nad CIR, při splnění záruk SLA poskytovaných CIR. EIR mohou být interpretovány jako maximální trvalé IR, kterým může uživatel překročit dané CIR s nějakým očekáváním, že přebytek provozu může být proveden v síti. EBS je počet alokovaných bytů k dispozici pro dávky vnikajících rámců služeb vysílaných dočasnými rychlostmi nad CIR + EIZ při zachování EIR-konformní. Výkonnostní metriky, pokud jde o FTD, FDV a FLR se nevztahuje na rámce, které jsou přenášeny rychlostmi nad CIR, ale v rámci služby EIR. Parametry provozu profilu šířky pásma jsou vynuceny pomocí dávkovacího algoritmu, jako součást podmínění provozu. Jsou zavedeny dva další parametry týkající se provozu dávkovacích algoritmů. Tyto parametry jsou Coupling flag (CF), Colour mode (CM). CF a CM jsou označovány jako parametry profilu šířky pásma. Ty umožňují výběr mezi různými druhy provozu pro dávkovací algoritmus. CF a CM nabývají pouze hodnot 0 nebo 1. Více informací lze nalézt v MEF 10.2, části 7.11 na profilech šířky pásma.

98 98 FEKT Vysokého učení technického v Brně Vnikající rámce služeb jsou zpracovány na základě jejich shody s CIR/CBS/EIZ/EBS. Vyšší priorita zahazování je přiřazena rámcům, které jsou konformní k EIR (tj. rámce žluté barvy), než rámcům, které jsou konformní k CIR (tj. rámce zelené barvy). Žluté rámce se očekává, že budou zahazovány jako první, když dojde k zahlcení v servisní vrstvě. Rámce, které jsou nekonformní buď k CIR, nebo EIR (tj. červené rámce) jsou zahozeny na rozhraní. Pravidla provozu je termín, který popisuje proces zahazování červených rámců na rozhraní. Obrázek 1 ukazuje vztah mezi CIR, EIR a barevným kódování provozu. Obr. 9.2: Profil šířky pásma Testovací metodologie aktivace služeb Ethernet Cílem této zkušební metody je ověřit výkonnostní parametry přenosu rámce Ethernet, jak jsou definovány v ITU-T Y Metodika má dva hlavní cíle, 1. ověřit, že každá služba na bázi Ethernetu je správně nakonfigurována 2. ověřit kvalitu služeb, jak jsou dodávány koncovému uživateli. Proto metodologie uvedené v tomto doporučení jsou dvoufázového přístupu, jak je ukázáno na obrázku Obrázek 2. Vysoko-úrovňová testovací metodologie aktivace služeb.. Test konfigurace služby testuje každou stanovenou službu Ethernetu, aby se ujistil, že je konfigurace správná. Každý z důležitých parametrů (IR, FTD, FDV a FLR), MUSÍ být vyzkoušen. Tento test je velmi krátký v délce, na úsudek osoby provádějící zkoušku, a je navržen tak, aby se zabránilo plýtvání času způsobeným neúspěšnými testy služeb.

99 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 99 Zkouška výkonnosti služby se provádí k ověření kvality služeb Ethernet ve střednědobém až dlouhodobém časovém trvání. Obr. 9.3: Vysoko-úrovňová testovací metodologie aktivace služeb. Doporučení dále popisuje: Testovací architekturu a úvahy, zahrnující Měřicí body a měřitelné sekce, Referenční akce přenosu rámce Ethernet a Požadované schopnosti zkušebního zařízení. Dále Testovací metodologie aktivace služeb Ethernet a jednotlivé přílohy doporučení. Všechny informace uvedené v kapitole výše vychází z doporučení ITU-T Y Vzhledem k rozsáhlosti standardu, není možné zde uvést všechny kapitoly standardu. Pro bližší a

100 100 FEKT Vysokého učení technického v Brně aktuální informace je vždy nutné stáhnout a prozkoumat poslední schválenou verzi doporučení. 9.3 Request for Comments: 2544, srovnávací metodika pro síťová propojovací zařízení Pozn.: RFC 2544 je opětovné publikování RFC 1944 opravující hodnoty IP adres, které byly přiřazeny k používání jako výchozí adresy pro síťová testovací zařízení. RFC 2544 nahrazuje zastaralou RFC Abstrakt Dokument RFC 2544 popisuje a definuje celou řadu testů, které mohou být použity k popisu výkonových charakteristik síťových testovacích zařízení. Kromě definování testů, tento dokument také popisuje konkrétní formáty pro vykazování výsledků testů. Příloha A (Appendix A) doporučení RFC 2544 uvádí testy a podmínky, které by měly být zahrnuty ve zvláštních případech, a poskytuje další informace o zkušebních postupech. Příloha B (Appendix B) doporučení RFC 2544 je referenční seznam maximálních obnovovacích kmitočtů pro použití s konkrétními velikostmi rámců pro různá média a Příloha C (Appendix C) uvádí některé příklady rámcových formátů pro použití při testování Úvod Dokument RFC 2544 definuje specifickou sadu testů, které mohou dodavatelé použít k měření a vykazování výkonnostních vlastností síťových zařízení. Výsledky těchto testů budou poskytovat uživatelsky srovnatelné údaje od různých výrobců, které vyhodnotí tato zařízení. Předchozí dokument, Srovnávací technologie pro síťová propojovací zařízení (RFC 1242), definoval mnoho termínů použitých v RFC 2544, proto by daná terminologie měla být konzultována před použitým tohoto doporučení Testy, které mají být provedeny Existuje celá řada testů popsaných v dokumentu RFC Ne všechny zkoušky se však vztahují na všechny typy testovaných zařízení (Devices under test DUTs). Prodejci by měli provádět všechny testy, které mohou být podporovány konkrétním typem výrobku. Autoři

101 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 101 doporučení chápou, že budou trvat značnou dobu provést všechny doporučené zkoušky v rámci všech doporučených podmínek. Věří však, že výsledky stojí za námahu. Příloha A uvádí některé ze zkoušek a podmínek, které by měly být zahrnuty ve zvláštních případech Vyhodnocení výsledků Provedení všech doporučených testů bude mít za následek velké množství dat. Mnohé z těchto údajů se nevztahují na hodnocení zařízení za všech okolností. Například, rychlost s jakou směrovač přeposílá IPX rámce nebude příliš užitečná při výběru směrovače pro prostředí, které nepodporuje (a nebude podporovat) tento protokol. Vyhodnocení údajů, které jsou relevantní pro konkrétní síťovou instalaci, bude vyžadovat zkušenosti, které nemusí být snadno dostupné. Navíc, výběr testů, které mají být spuštěny a vyhodnocení dat z testů musí být provedeno s pochopením všeobecně uznávaných zkušebních postupů v oblasti opakovatelnosti, rozptylu a statistické významnosti malého počtu pokusů Požadavky V dokumentu RFC 2544 jsou slova, která se používají k definování významu každého konkrétního požadavku, zdůrazněna kapitálkami. Tato slova jsou: MUSÍ - toto slovo nebo slovo VYŽADUJE znamená, že položka je naprosto vyžadována specifikací. MĚL BY - toto slovo nebo přídavné jméno "DOPORUČENO" znamená, že mohou existovat pádné důvody, proč za určitých okolností lze ignorovat tuto položku, ale plné důsledky by mělo být chápány a pečlivě zváženy před výběrem jiného směru. MŮŽE toto slovo nebo přídavné jméno "VOLITELNÉ" znamená, že tento bod je opravdu volitelný. Firma se může rozhodnout pro danou věc, protože to vyžaduje její trh, nebo proto, že podporuje výrobek, například: jiná firma, která nabízí stejnou věc. Implementace není kompatibilní, pokud nesplní jeden nebo více požadavků MUSÍ pro prováděné protokoly. Implementace, která splňuje všechny požadavky MUSÍ a všechny požadavky MĚL BY svých protokolů se označuje jako "bezpodmínečně v souladu"; ta, která splňuje všechny požadavky MUSÍ, ale ne všechny požadavky MĚL BY ve svých protokolech, se označuje jako "podmíněně vyhovující" Testovací zapojení Ideální způsob, jak provádět tuto sérii testů, je použít tester, jak s vysílacími porty, tak s přijímacími porty. Spojení jsou vytvořena z vysílacích portů testeru do přijímacích portů

102 102 FEKT Vysokého učení technického v Brně DUT, a z vysílacích portů DUT zpět do testeru (viz obrázek 1). Vzhledem k tomu, že tester jak pošle testovací provoz, tak i přijme zpět, poté, co provoz byl předán DUT, tester může snadno zjistit, zda byly přijaty všechny přenášené pakety, a ověřit, zda byly přijaty správné pakety. Stejné funkcionality lze dosáhnout s oddělenými vysílacími a přijímacími zařízeními (viz obrázek 2), ale pouze pokud jsou dálkově řízeny nějakým počítačem způsobem, že simuluje jediný tester; práce vyžadující přesné provedení některých zkoušek (zejména test propustnosti) může být neúnosná. Obr. 9.4: Schéma zapojení systému Obr. 9.5: Schéma zapojení systému Dvě rozdílné nastavení by mohly být použity k testování DUT, které se používá v reálných sítích pro připojení sítí různých typů médií, například lokální sítě Ethernet na páteřní FDDI okruh. Tester by mohl podporovat oba typy médií, v tomto případě nastavení uvedené na obrázku 1 by bylo použito. Dvě identické DUTs jsou použity v dalším testovacím setu (viz obrázek 3). V mnoha případech to zapojení může přesněji simulovat reálný svět. Například spojení dvou LAN spolu s WAN nebo páteřní sítí. Toto zapojení by nemělo být příliš vhodné pro simulování systému, kde klienti na Ethernet LAN interagovali se serverem na páteřní FDDI.

103 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 103 Obr. 9.6: Schéma sítě Zapojení DUT Předtím, než začnete provádět testy, BUT určené k testování MUSÍ být konfigurován podle návodu pro uživatele. Konkrétně se předpokládá, že všechny podporované protokoly budou nakonfigurovány a povoleny během tohoto nastavení (viz Příloha A). Očekává se, že všechny testy proběhnou bez změny konfigurace nebo nastavení DUT jakýmkoli jiným způsobem, než jak je požadováno pro provedení specifických testů. Například není přijatelné měnit velikost rámce vyrovnávací paměti mezi testy vyrovnávací paměti, nebo zakázat vše kromě jednoho transportního protokolu při testování propustnost tohoto protokolu. Je třeba změnit konfiguraci při zahájení testu pro stanovení účinku filtrů na propustnost, ale MUSÍ být pouze konkrétního filtru. DUT nastavení BY MĚLA obsahovat běžně doporučované intervaly aktualizace směrování a zachovat frekvenci. Specifická verze softwaru a přesné nastavení DUT, včetně zakázaných funkcí, použitých při zkouškách, MUSÍ být zahrnuto jako součást výsledné zprávy Formáty rámců Formáty testovaných rámců použitých pro protokol TCP/IP přes Ethernet jsou uvedeny v Příloze C: Formáty zkušebních rámců. Tyto přesné formáty rámce BY MĚLY být použity při testech popsaných v tomto dokumentu pro tento protokol/média kombinace, a že tyto rámce budou použity jako šablona pro testování jiné kombinace protokol/média. Konkrétní

104 104 FEKT Vysokého učení technického v Brně formáty, které se používají k definování testovaných rámců pro konkrétní sérii zkoušek MUSÍ být zahrnuty do výsledné zprávy Velikosti rámců Všechny popsané testy BY MĚLY být provedeny v několika velikostech rámců. Konkrétně, velikosti BY MĚLY zahrnovat minimální a maximální oprávněné velikosti pro testovaný protokol v testovaném médiu a dostatečné velikosti mezi, aby bylo možné získat úplný popis výkonu DUT. Není-li uvedeno jinak, alespoň pět velikostí rámců BY MĚLO být testováno pro každou testovací podmínku. Teoreticky minimální velikost UDP Echo žádosti rámce se bude skládat z IP hlavičky (minimální délka 20 oktetů), UDP hlavičky (8 oktetů) a bez ohledu na MAC hlavička úrovně je vyžadována testovaným médiem. Teoretická maximální velikost rámce je určen velikostí délky pole v záhlaví IP. Téměř ve všech případech jsou skutečné maximální a minimální rozměry určeny omezením médií. Teoreticky by bylo ideální distribuovat velikosti rámců tak, že by se rovnoměrně rozprostřely teoretické rámcové frekvence. Toto doporučení zahrnuje tuto teorii, ale definuje velikosti rámců, které jsou snadno srozumitelné a zapamatovatelné. Kromě toho, mnoho stejných velikostí rámců jsou uvedeny pro každý typ média pro snadné srovnání výkonů. Poznámka: Zahrnutí nerealisticky malých velikostí ráme na některých typech médií (např. s malým nebo žádným prostorem pro data) slouží pro pomoc při charakterizaci režie zpracování jednotlivých snímků DUT Velikosti rámců pro použití v Ethernet 64, 128, 256, 512, 1024, 1280, 1518 Tyto velikosti zahrnují minimální a maximální velikosti rámců povolené normou Ethernet a výběr velikostí mezi těmito extrémy s jemnějším krokem pro menší velikosti rámců a vyšší opakování rámců Velikosti rámců pro použití v 4Mb a 16Mb Token Ring 54, 64, 128, 256, 1024, 1518, 2048, 4472 Doporučení pro velikosti rámců Token Ring předpokládá, že neexistuje RIF pole rámcích směrovacích protokolů. RIF pole by mělo být přítomno v každém zátěžovém testu přímého zdroje směrovacího mostu. Minimální velikost rámce pro UDP na Token Ring je 54 oktetů.

105 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 105 Maximální velikost 4472 oktetů se doporučuje pro 16MB Token Ring místo teoretické velikosti 17,9 Kb kvůli omezení velikosti stanovených řadou Token Ring rozhraní. Připomínkou velikosti jsou vybrány, aby umožnily přímé srovnání s ostatními typy médií. IP (tedy ne UDP), rámec může být použit navíc v případě, že vyšší rychlost přenosu dat je žádoucí, přičemž v tomto případě je minimální velikost rámce 46 oktetů Velikosti rámců pro použití v FDDI 54, 64, 128, 256, 1024, 1518, 2048, 4472 Minimální velikost rámce pro UDP na FDDI je 53 oktetů, minimální velikost 54 se doporučuje pro přímé srovnání výkonu s Token Ring. Maximální velikost 4472 se doporučuje namísto teoretické maximální velikosti 4500 oktetů pro možnost srovnání stejného typu. IP (tedy ne UDP) rámec může být použit navíc v případě, že vyšší rychlost přenosu dat je žádoucí, přičemž v tomto případě je minimální velikost rámce 45 oktetů Velikosti rámce v přítomnosti nesourodých MTUs Když propojovací DUT podporuje připojení linek s různorodými MTU, velikosti rámců pro linky s větší MTU BY MĚLY být použity, a to až do výše limitu testovaného protokolu. V případě, že propojovací DUT nepodporuje fragmentaci rámců za přítomnosti MTU nesouladu, rychlost přesměrování na danou velikost rámce se hlásí jako nula Modifikátory Mohlo by být užitečné znát výkon DUT za různých podmínek; některé z těchto podmínek jsou uvedeny níže. Uváděné výsledky BY MĚLY zahrnovat tolik z těchto podmínek kolik zkušební zařízení je schopno generovat. Sada testů BY MĚLA být první spuštěna bez úpravy podmínek a pak zopakována v rámci každé z podmínek samostatně. Chcete-li zachovat možnost porovnat výsledky těchto testů, všechny rámce, které jsou nezbytné pro vytvoření pozměňujících podmínek (např. řídící dotazy) budou zahrnuty ve stejném datovém toku, jako běžné testovací rámce na místě jednoho ze zkušebních rámců, a nebudou předány DUT na samostatný síťový port.

106 106 FEKT Vysokého učení technického v Brně Broadcast rámce Ve většině návrhů směrovačů je zapotřebí speciální zpracování pro příjem rámců určených hardwarové boadcastové adrese. V mostech (nebo v režimu most na směrovačích) tyto vysílací rámce musí být zaplaveny na řadu portů. Proud zkušebních rámců BY MĚL být rozšířen o 1 % rámců adresovaných broadcastové adrese hardwaru. Rámce zaslané na adresu broadcastu by měly být takového typu, aby směrovač nemusel zpracování. Cílem této zkoušky je zjistit, zda existuje nějaký vliv na rychlost přesměrování ostatních dat ve streamu. Konkrétní rámce, které by měly být použity, jsou zahrnuty v dokumentu test formátu rámce. Všesměrové rámce BY MĚLY být rozloženy rovnoměrně v toku dat, například každý 100.rámec. Stejný test by měl být proveden na DUT typu most, ale v tomto případě budou všesměrové pakety zpracovány a zaplaveny na všechny výstupy. Má se za to, že úroveň 1 % všesměrových rámců je mnohem vyšší, než jsou mnohé síťové zkušenosti, ale stejně jako je v hodnocení toxicity léčiva, vyšší úroveň je vyžadována, aby bylo možné měřit účinek, který by jinak často spadal do normální variability výkonu systému. Vzhledem k návrhovým faktorům, některá testovaná zařízení nebudou schopna generovat tak nízkou úroveň alternativních rámců. V těchto případech procento BY MĚLO být tak malé, jak zařízení může poskytnout, a skutečná úroveň popsána ve výsledné zprávě Řídící rámce Většina datových sítí nyní využívá protokolů pro správu, jako je SNMP. V mnoha prostředích může být řada řídících stanic vysílajících dotazy Stejnému DUT ve stejnou dobu. Proud testovacích rámců BY MĚL být navýšen o jeden řídící dotaz, jakmile je první rámec poslán každou sekundu po dobu trvání procesu. Výsledek dotazu se musí vejít do jednoho rámce odezvy. Rámec odezvy BY MĚL být ověřen pomocí zkušebního zařízení. Jedním z příkladů konkrétního dotazu rámce, který má být použit, je uveden v Příloze C Rámce aktualizace směrování Zpracování aktualizace dynamických směrovacích protokolů by mohlo mít významný dopad na schopnost směrovače při předání datových rámců. Proud testovacích rámců BY MĚL být rozšířený jedním rámcem aktualizace směrování přenášeným v průběhu řízení. Rámce aktualizace směrování BY MĚL být zaslán ve výši stanovené v Příloze C pro konkrétní směrovací protokol použitý v testu. Dva rámce aktualizace směrování jsou

107 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO 107 definovány v Příloze C např. pro TCP/IP přes Ethernet. Směrovací rámce jsou navrženy tak, aby změnili směrování k řadě sítí, které nejsou zapojeny do předávání testovacích dat. První snímek nastaví směrovací tabulku stavu na "A", druhý změní stav na "B". Rámce se MUSÍ střídat v průběhu řízení. Test BY MĚL ověřit, zda aktualizace směrování byla zpracována DUT Filtry Filtry jsou přidány do směrovačů a mostů k selektivní filtraci předávaných rámců, které by za normálních okolností byly předány. To se obvykle provádí pro implementaci bezpečnostních kontrol na datech, která jsou přijata mezi jednou oblastí a další. Různé výrobky mají různé způsoby implementace filtrů. DUT BY MĚLO být nejprve nakonfigurováno k přidání jedné podmínky filtru a měly by být provedeny zkoušky. Tento filtr BY MĚL umožnit předání zkušební datového toku. Ve směrovačích BY MĚL filtr být ve formě: forward input_protocol_address to output_protocol_address V mostech BY MĚL filtr být ve formě: forward destination_hardware_address DUT BY MĚLO být překonfigurováno pro implementaci celkem 25 filtrů. Prvních 24 těchto filtrů BY MĚLO být ve tvaru: block input_protocol_address to output_protocol_address 24 vstupních a výstupních adres protokolu BY NEMĚLY být takové adresy, které jsou zastoupeny v datovém toku testu. Poslední filtr BY MĚL umožnit předání testovacího datového toku. "Prvním" a "Posledním" je myšleno zajištění, že v druhém případě 25 podmínek musí být zkontrolováno, než datové rámce budou odpovídat podmínkám, které umožňují předání rámců. Samozřejmě, v případě, že DUT změní pořadí filtrů nebo nepoužívá lineární skenování pravidel filtru, účinek pořadí, ve kterém jsou filtry vloženy je správně ztracen. Konkrétní použité konfigurační příkazové řádky filtru BY MĚLY být součástí výsledné zprávy Adresy filtru Dvě sady filtračních adres jsou nutné, jedna pro případ jednoho filtru a jedna pro případ 25 filtrů.

108 108 FEKT Vysokého učení technického v Brně Jediný filtr by měl umožnit provoz IP adres od do a zakázat všechen ostatní provoz. Případ 25 filtrů by měl dodržovat následující pořadí. zakaž od aa.ba.1.1 do aa.ba zakaž od aa.ba.2.2 do aa.ba zakaž od aa.ba.3.3 do aa.ba zakaž od aa.ba do aa.ba zakaž od aa.bc.1.2 do aa.bc.65.1 zakaž od aa.ba do aa.ba zakaž od aa.ba do aa.ba zakaž od aa.ba do aa.ba zakaž vše ostatní. Všechny předchozí podmínky filtru by měly být vymazány ze směrovače před zadáním této sekvence. Sekvence je zvolena tak, aby otestovala, zda směrovač řadí filtrační podmínky nebo je přijímá v pořadí, v jakém byly zadány. Oba tyto postupy budou mít větší vliv na výkon, než nějaká forma hash kódování Adresy protokolu Je jednodušší implementovat tyto testy pomocí jediného logického toku dat, s jednou zdrojovou adresou protokolu a jednou cílovou adresou protokolu, a za určitých podmínek, jako jsou filtry popsané výše, praktický požadavek. Sítě v reálném světě nejsou omezeny jediným tokem dat. Zkušební sestava BY MĚLA být nejdříve spuštěna s jedním protokolem (nebo hardwarem pro testy mostu) páru zdrojové a cílové adresy. Testy BY MĚLY být opakovány za pomoci náhodných cílových adres. Při testování směrovačů, adresy BY MĚLY být náhodné a rovnoměrně rozdělené v rozsahu 256 sítí a náhodně a rovnoměrně distribuovány v celém rozsahu MAC pro mosty. Konkrétní rozsahy adres použití v IP jsou uvedeny v Příloze C.

109 Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO Nastavení trasy Není vhodné, aby všechny směrovací informace nezbytně předávaly testovací stream, zejména v případě vícenásobné adresy bude ručně nastaven. Na začátku každého testu MUSÍ být aktualizace směrování zasláno do DUT. Tato aktualizace směrování MUSÍ obsahovat všechny síťové adresy, které budou potřebné pro test. Všechny adresy BY MĚLY vyřešit stejně "next-hop (další skok)". Obvykle to bude adresa přijímací strany zkušebního zařízení. Tato aktualizace směrování se bude muset opakovat v intervalu požadovaném směrovacím protokolem. Příklad formátu a intervalu opakování aktualizace rámců je uveden v Příloze C Obousměrný provoz Normální aktivita sítě neprobíhá v jednom směru. Pro vyzkoušení obousměrné výkonnosti DUT, série testů BY MĚLA být spuštěna se stejnou rychlostí dat z každého směru. Součet rychlostí přenosu dat by neměla překročit teoretický limit média Jednosměrný tok Kompletní sada testů BY MĚLA být spuštěna spolu s modifikačními podmínkami, které jsou relevantní k použití jednoho vstupního a výstupního síťového portu na DUT. V případě, že vnitřní konstrukce DUT má více vnitřních cest, například více karet rozhraní a každý s více síťovými porty, pak všechny možné typy cest by měly být testovány odděleně Více portů Mnoho současných směrovačů a mostů poskytují mnoho síťových portů ve stejném modulu. Při provádění těchto zkoušek, první polovina portů je označena jako vstupní porty a polovina je označena jako výstupní porty. Tyto porty BY MĚLY být rozloženy rovnoměrně po celé architektuře DUT. Například, pokud DUT má dvě karty rozhraní a každá z nich má čtyři porty, dva porty na každé kartě rozhraní jsou označeny jako vstup a dva jsou určeny jako výstup. Uvedené testy jsou provozovány s použitím stejné rychlosti přenosu dat nabízené každému z vstupních portů. Adresy ve vstupních datových tocích BY MĚLY být nastaveny tak, že rámec bude směrován ke každému z výstupních portů v takovém pořadí, že všechny výstupní porty budou mít rovnoměrné rozdělení paketů z tohoto vstupu. Stejná konfigurace MŮŽE být použita k provedení obousměrného multi-stream testu. V tomto

110 110 FEKT Vysokého učení technického v Brně případě všechny porty jsou považovány, jak za vstupní, tak i výstupní porty, a každý datový proud se MUSÍ skládat z rámců určených všem ostatním portům. Předpokládejme následujících 6 portů DUT: Obr. 9.6: Vstupy a výstupy systému Adresování datových toků pro každý ze vstupů by mělo být: proud zaslán na vstup A: paket na výstup X, paket na výstup Y, paket na výstup Z, proud zaslán na vstup B: paket na výstup X, paket na výstup Y, paket na výstup Z, proud zaslán na vstup C: paket na výstup X, paket na výstup Y, paket na výstup Z. Všimněte si, že tyto proudy následují stejnou sekvenci tak, že 3 pakety dorazí na výstup X ve stejnou dobu, pak 3 pakety na Y, a potom 3 pakety na Z. Tento postup zajišťuje, že stejně jako v reálném světě, DUT se bude muset vypořádat s více pakety adresovanými na stejnému výstupu ve stejnou dobu. Doporučení dále popisuje: Testování výkonu nad rámec jednoho DUT, popis pokusu, trvání pokusu, rozlišení adres, propustnost, latenci, ztrátovost rámců, obnovu systému a jednotlivé přílohy. Všechny informace uvedené v kapitole výše vychází z doporučení RFC Vzhledem k rozsáhlosti standardu, není možné zde uvést všechny kapitoly standardu. Pro bližší a aktuální informace je vždy nutné stáhnout a prozkoumat poslední schválenou verzi doporučení.