Efektivní využití přenosu informací pro integrovanou výuku VUT

Transkript

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/28.0062
Evropského sociálního fondu a státním rozpočtem České republiky.
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, 616 00 Brno
Vydání
první
Rok vydání
2014
Náklad
elektronicky
ISBN
978-80-214-5126-1
Tato publikace neprošla redakční ani jazykovou úpravou.
Efektivní využití přenosu informací pro integrovanou výuku VUT a VŠB-TUO
3
Obsah
1
ÚVOD ................................................................................................................................. 6
2
TELEKOMUNIKAČNÍ SLUŽBY ................................................................................... 7
2.1
2.2
2.3
2.4
2.5
2.6
2.7
HLEDISKA KATEGORIZACE ............................................................................................... 8
RŮZNÉ MOŽNOSTI DĚLENÍ .............................................................................................. 10
POHLED VYBRANÝCH ZÁKONŮ ...................................................................................... 13
INTEGROVANÉ SLUŽBY DIGITÁLNÍCH SÍTÍ ...................................................................... 15
ASYNCHRONNÍ PŘEPRAVNÍ ZPŮSOB ............................................................................... 16
TECHNOLOGIE XDSL ..................................................................................................... 17
TELEKOMUNIKAČNÍ SLUŽBY POSKYTOVANÉ INTERNETEM ............................................ 20
2.7.1
Voice over IP ............................................................................................. 20
2.7.2
IPTV (Internet Protocol Television) .......................................................... 20
2.8 VYBRANÉ TOPOLOGIE SÍTÍ ............................................................................................. 20
3
IP TELEFONIE ............................................................................................................... 23
3.1 AUDIO KODEKY PRO IP TELEFONII ................................................................................. 23
Terminály internetové telefonie ................................................................. 24
3.1.1
3.1.2
Kvalita hovorů ........................................................................................... 24
3.1.3
Doporučení ITU-T pro kodeky ................................................................... 26
3.2 ANALÝZA KODEKŮ ........................................................................................................ 28
Analýza pomocí analyzátoru LE-580FX ................................................... 29
3.2.1
3.2.2
Analýza pomocí síťového analyzátoru FLUKE ......................................... 31
4
SIMULACE MULTICASTOVÉHO PŘENOSU ......................................................... 33
4.1 PŘÍPRAVA VIRTUÁLNÍHO STROJE.................................................................................... 33
4.1.1
Instalace VMware Playeru ........................................................................ 33
4.2 VYTVOŘENÍ VIRTUÁLNÍHO OPERAČNÍHO SYSTÉMU LINUX ............................................. 34
4.3 INSTALACE OMNET++ ................................................................................................. 36
4.4 IMPLEMENTACE PROJEKTU INET-HNRL....................................................................... 38
4.5 SIMULACE MULTICASTOVÉHO PROVOZU ........................................................................ 42
4.5.1
Otevření simulačního modelu a popis souborů ......................................... 42
5
SIMULACE TECHNOLOGIE DIFFSERV ................................................................. 47
5.1 POSTUP ŘEŠENÍ .............................................................................................................. 47
5.2 VÝSLEDKY ..................................................................................................................... 58
6
GENERÁTOR SÍŤOVÉHO PROVOZU ...................................................................... 62
6.1 VYPRACOVÁNÍ ZADÁNÍ .................................................................................................. 62
7
SIMULACE BEZDRÁTOVÉ SÍTĚ .............................................................................. 69
7.1 POSTUP IMPLEMENTACE SLUŽEB .................................................................................... 70
7.1.1
QoS............................................................................................................. 70
7.1.2
Bez QOS ..................................................................................................... 71
7.2 DOSAŽENÉ VÝSLEDKY ................................................................................................... 71
8
MULTIMÉDIA NA INTERNETU ................................................................................ 75
8.1 METODY VYSÍLÁNÍ MULTIMÉDIÍ .................................................................................... 75
8.1.1
Unicast ....................................................................................................... 75
8.1.2
Broadcast ................................................................................................... 75
4
8.1.3
Multicast .................................................................................................... 76
8.2 STREAMOVACÍ FORMÁTY .............................................................................................. 77
8.2.1
RealMedia ................................................................................................. 77
8.2.2
QucikTime ................................................................................................. 78
8.2.3
Windows media ......................................................................................... 79
8.2.4
Youtube live video streaming .................................................................... 80
8.2.5
Black Magic Video Streaming ................................................................... 80
8.3 OBSAH MULTIMEDIÁLNÍCH DAT .................................................................................... 80
8.3.1
Audio data ................................................................................................. 80
8.3.2
Audio a snímky .......................................................................................... 81
8.3.3
Video.......................................................................................................... 81
8.3.4
Animace ..................................................................................................... 81
8.3.5
Živé vysílání............................................................................................... 81
8.4 KOMPRESE OBRAZOVÝCH DAT ...................................................................................... 81
Komprese statistických obrazových dat................................................................... 81
8.4.1
Popis standardu JPEG (Joint Photographic Experts Group) ................... 82
8.4.2
MPEG – Moving Picture Experts Group .................................................. 83
8.4.3
Komprimační technologie ve zkratce ........................................................ 85
8.4.4
Streamování multimediálního přenosu pomocí síťového Enkodéru.......... 86
8.4.5
Popis programu VideoLanClient .............................................................. 87
8.4.6
Technologie vytvoření streamovacího serveru .......................................... 88
Popis CGI skriptu .................................................................................................... 88
9
METODOLOGIE TESTOVÁNÍ V TELEKOMUNIKAČNÍCH SÍTÍCH ................90
9.1 ÚVOD ............................................................................................................................ 90
9.2 DOPORUČENÍ ITU-T Y.1564, TESTOVACÍ METODOLOGIE AKTIVACE SLUŽEB ETHERNET
...................................................................................................................................... 91
9.2.1
Shrnutí ....................................................................................................... 91
Úvod .......................................................................................................... 91
9.2.2
9.2.3
Rozsah ....................................................................................................... 92
9.2.4
Reference ................................................................................................... 92
9.2.5
Definice – termíny definované v tomto doporučení................................... 93
9.2.6
Konvence ................................................................................................... 95
9.2.7
Síťová architektura Ethernet ..................................................................... 95
9.2.8
Atributy služby Ethernet ............................................................................ 96
9.2.9
Profil šířky pásma ..................................................................................... 97
9.2.10 Testovací metodologie aktivace služeb Ethernet ....................................... 98
9.3 REQUEST FOR COMMENTS: 2544, SROVNÁVACÍ METODIKA PRO SÍŤOVÁ PROPOJOVACÍ
ZAŘÍZENÍ ..................................................................................................................... 100
9.3.1
Abstrakt ................................................................................................... 100
9.3.2
Úvod ........................................................................................................ 100
9.3.3
Testy, které mají být provedeny ............................................................... 100
9.3.4
Vyhodnocení výsledků ............................................................................. 101
9.3.5
Požadavky................................................................................................ 101
9.3.6
Testovací zapojení ................................................................................... 101
9.3.7
Zapojení DUT .......................................................................................... 103
9.3.8
Formáty rámců ........................................................................................ 103
9.3.9
Velikosti rámců ........................................................................................ 104
9.3.10 Velikosti rámců pro použití v Ethernet .................................................... 104
9.3.11 Velikosti rámců pro použití v 4Mb a 16Mb Token Ring ......................... 104
9.3.12
9.3.13
9.3.14
9.3.15
9.3.16
9.3.17
9.3.18
9.3.19
9.3.20
9.3.21
9.3.22
9.3.23
9.3.24
5
Velikosti rámců pro použití v FDDI ........................................................ 105
Velikosti rámce v přítomnosti nesourodých MTUs .................................. 105
Modifikátory............................................................................................. 105
Broadcast rámce ...................................................................................... 106
Řídící rámce ............................................................................................. 106
Rámce aktualizace směrování .................................................................. 106
Filtry ........................................................................................................ 107
Adresy filtru ............................................................................................. 107
Adresy protokolu ...................................................................................... 108
Nastavení trasy ........................................................................................ 109
Obousměrný provoz ................................................................................. 109
Jednosměrný tok ...................................................................................... 109
Více portů ................................................................................................. 109
10 SEZNAM POUŽITÉ LITERATURY ......................................................................... 111
6
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
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
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 e-mailem),
obrazové (přenos dokumentů a statických obrazů, telefax), audiovizuální (přenos
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, WANWide 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
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 e-mailem), 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
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
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.
2.3
13
Pohled vybraných zákonů
Podle Zákona o dani z přidané hodnoty č.235/2004 ze dne 1.4.2004, 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

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
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 300 – 3 400 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
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 300-3400 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 1 920
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:
2.5

Fyzická, doporučení I.430 pro BRI a I-431 pro PŘI

Spojovací, doporučení Q.921

Síťová, doporučení Q.931
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
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 300-3 400 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
ú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í 13–52 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
provozu
(up/down)
[km]
symetrický,
Požitá
pásmo
modulace,
[kHz]
[Mbit/s]
HDSL
Frekvenční
kódování
Metoda
duplex.
přenosu
2/2
2 až 3
40 až 292
2B1Q
EC
0,128/0,128
cca 3
0 až 50
2B1Q
EC
1/8
cca 8
25 až 138
DMT,
FDD
QAM,
EC
DMT,
FDD
duplexní
DSL
symetrický,
(IDSL)
duplexní
ADSL
asymetrický
ADSL 2
asymetrický
1/12
cca 8
138 až 1104
ADSL 2+
ADSL Lite
asymetrický
asymetrický
1/24
0,5/1,5
cca 3
cca 7
138 až 2 208
25 až 138
QAM
EC
DMT,
FDD
QAM
EC
DMT
FDD
138 až 552
SDSL
symetrický,
SHDSL
duplexní
VDSL
asymetrický,
2,3/2,3
2 až 5
0 až 384
3 až 6
6,4/52
0,3 až 1,5
19
EC
2B1Q
EC
16-PAM
300 až 900
QAM.,
FDD
DMT
VDSL
symetrický,
34/34
0,3 až 1,5
duplexní
1200 až
30 000
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
QAM.,
DMT
FDD
20
2.7
2.7.1
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).
2.7.2
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
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

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
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

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í.
3.1.1
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í.
3.1.2
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
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é,
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
ní
Algoritmu
s
CBR
NEB
MOS
[kbit/s]
[kbit/s]
[-]
G.711
PCM
64
87,2
4,1
G.729
CSACEL
8
31,2
3,92
LPC
15
27,7
4,14
P
iLBC
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
ale
26
Místo parametru MOS lze používat též tzv. R-factor (Rating factor dle doporučení
G.107)
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.
3.1.3
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
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 2008. 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.723.1 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.723.1 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
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í LDCELP (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 32 – 128 kbit/s. G.719 vychází z
G.722.1 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
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á.
3.2.1
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
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
1.6.7.
Obr. 3.2: Zapojení analyzátoru LE-580FX.
Předpokládejme zapojení dle obr. 3.2. 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
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é.
3.2.2
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
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
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 INETHNRL. 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č.
4.1.1
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
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 kubuntu14.04.1-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-14.04.1-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. 4.1. 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
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
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 ++ 4.6 (omnetpp-4.6src.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-1.0-0 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
2)
37
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/omnetpp4.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
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-3080702.tar.gz
cd sqlite-autoconf-3080702/
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
/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-autoconf3080702'
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
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 ++.
12)
Změnit v položkách, které obsahují ${OMNETPP_ROOT} tuto proměnnou na
cestu
/home/omnetpp/omnetpp-4.6. Pro vizualizaci slouží obr. 4.4.
Obr. 4.4: Nahoře: Původně nastavené proměnné. Dole: Upravené proměnné.
13)
41
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. 4.5.
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
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.
4.5.1
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. 4.4.
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
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 = "225.0.0.1";
portNumber = 5004;
bandwidth = 8000;
@display("p=150,50");
}
Host1, 2, 3 a 4 slouží jako klienti:
Client:
host4: RTPHost {
parameters:
IPForward = false;
profileName = "inet.transport.rtp.RTPAVProfile";
destinationAddress = "225.0.0.1";
portNumber = 5004;
bandwidth = 8000;
@display("p=50,150");
}
Pro směrovač si vystačíme s následujícím:
Source:
router1: Router {
parameters:
forwardMulticast = true;
@display("p=150,150");
gates:
pppg[];
44
}
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. 4.5. 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
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 224.0.0.1, 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
router1
router1
router1
-->
-->
-->
-->
host1 IGMPv2
host2 IGMPv2
host3 IGMPv2
host4 IGMPv2
query
query
query
query
IPv4:
IPv4:
IPv4:
IPv4:
10.0.0.2 > 224.0.0.1
10.0.0.6 > 224.0.0.1
10.0.0.10 > 224.0.0.1
10.0.0.14 > 224.0.0.1
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
host2 --> router1
host3 --> router1
host4 --> router1
router1 --> host1
router1 --> host2
router1 --> host3
router1 --> host4
IGMPv2 report
IGMPv2 report
IGMPv2 report
IGMPv2 report
IGMPv2 report
IGMPv2 report
IGMPv2 report
IGMPv2 report
IPv4: 10.0.0.1 > 225.0.0.1
IPv4: 10.0.0.5 > 225.0.0.1
IPv4: 10.0.0.9 > 225.0.0.1
IPv4: 10.0.0.13 > 225.0.0.1
IPv4: 10.0.0.2 > 225.0.0.1
IPv4: 10.0.0.6 > 225.0.0.1
IPv4: 10.0.0.10 > 225.0.0.1
IPv4: 10.0.0.14 > 225.0.0.1
Jakmile jsou veškeré potvrzení doručeny, dochází k přenosu videa:
host2 --> router1 UDP:
10.0.0.5 > 225.0.0.1
router1 --> host1 UDP:
10.0.0.5 > 225.0.0.1
10.0.0.5 > 225.0.0.1
10.0.0.5 > 225.0.0.1
10.0.0.1 > 225.0.0.1
10.0.0.1 > 225.0.0.1
10.0.0.1 > 225.0.0.1
10.0.0.1 > 225.0.0.1
10.0.0.13 > 225.0.0.1
10.0.0.13 > 225.0.0.1
10.0.0.5.5005 > 225.0.0.1.5005: (47)
IPv4:
10.0.0.5.5005 > 225.0.0.1.5005: (47)
IPv4:
10.0.0.5.5005 > 225.0.0.1.5005: (47)
IPv4:
10.0.0.5.5005 > 225.0.0.1.5005: (47)
IPv4:
10.0.0.1.5005 > 225.0.0.1.5005: (47)
IPv4:
10.0.0.1.5005 > 225.0.0.1.5005: (47)
IPv4:
10.0.0.1.5005 > 225.0.0.1.5005: (47)
IPv4:
10.0.0.1.5005 > 225.0.0.1.5005: (47)
IPv4:
10.0.0.13.5005
10.0.0.13.5005
>
>
225.0.0.1.5005:(47)IPv4:
225.0.0.1.5005:
(32)IPv4:
46
router1 --> host2 UDP: 10.0.0.13.5005 > 225.0.0.1.5005: (32)IPv4:
10.0.0.13 > 225.0.0.1
router1 --> host3 UDP: 10.0.0.13.5005 > 225.0.0.1.5005: (32)IPv4:
10.0.0.13 > 225.0.0.1
host3 --> router1 UDP: 10.0.0.9.5005 > 225.0.0.1.5005: (29) IPv4:
10.0.0.9 > 225.0.0.1
router1 --> host1 UDP: 10.0.0.9.5005 > 225.0.0.1.5005: (29)
IPv4:
10.0.0.9 > 225.0.0.1
router1 --> host2 UDP: 10.0.0.9.5005 > 225.0.0.1.5005: (29)
IPv4:
10.0.0.9 > 225.0.0.1
router1 --> host4 UDP: 10.0.0.9.5005 > 225.0.0.1.5005: (29)
IPv4:
10.0.0.9 > 225.0.0.1
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 225.0.0.1 úplně.
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, 14.
•
2 – naléhavé – není tolerována žádná prodleva před přenosem, DSCP = 16, 18, 20,
22.
•
3 – Flash (hlas) – priorita pro hlasový přenos, DSCP = 24, 26, 28, 30.
•
4 – Flash Override – obdoba flash (hlas), DSCP = 32,34,36, 38.
•
5 – Kritická – nejčastěji používáno pro přenos RTP (Real Time Protocol), DSCP
= 40, 46.
•
6 – Internet – běžný provoz, DSCP = 48.
•
7 – 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
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. 5.1. 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. 5.4. 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
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
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
který spustí danou aplikaci v rozmezí 90–180 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
navazovat spojení s jinou stanici, dle Application: Destination Preferences, tímto nastavíme
cílový uzel, viz obr. 5.6 a obr. 5.7.
Zároveň jsme nastavili do Supported Services podporu služeb HTTP, FTP a VoIP pro
5 serverů. Konfiguraci serveru zachycuje obr. 5.8. 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.
Obr. 5.7: Nastavení uzlu Wrkstn_2_VoIP.
Obr. 5.8: Konfigurace Supported Services na uzlu Server_2_HTTP_FTP.
53
54
Tab. 5.1: Nastavení profilů aplikací a podporovaných služeb jednotlivých uzlů
Uzel
Server_1_HTTP
Server_2_HTTP_FTP
Server_3_HTTP_FTP
Server_4_FTP
Server_5_FTP
Wrkstn_1_VoIP_HTTP
Wrkstn_2_VoIP
Wrkstn_3_VoIP_FTP
Wrkstn_4_VoIP
Wrkstn_5_VoIP_FTP
Wrkstn_6_VoIP_HTTP
Wrkstn_7_VoIP_FTP
Wrkstn_8_VoIP
Wrkstn_9_VoIP_HTTP
Wrkstn_10_VoIP_HTTP
Wrkstn_11_VoIP_FTP
Wrkstn_12_VoIP
Wrkstn_13_VoIP_HTTP
Wrkstn_14_VoIP_FTP
Wrkstn_15_VoIP_FTP
Wrkstn_16_VoIP_HTTP
Wrkstn_17_VoIP
Wrkstn_18_VoIP_HTTP
Wrkstn_19_VoIP
Wrkstn_20_VoIP_FTP
Pod.
služba 1
HTTP
HTTP
HTTP
FTP
FTP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
VoIP
Nastavení cíle 1
Wrkstn_15_VoIP_FTP
Wrkstn_14_VoIP_FTP
Wrkstn_13_VoIP_HTTP
Wrkstn_16_VoIP_HTTP
Wrkstn_11_VoIP_FTP
Wrkstn_12_VoIP
Wrkstn_7_VoIP_FTP
Wrkstn_8_VoIP
Wrkstn_9_VoIP_HTTP
Wrkstn_10_VoIP_HTTP
Pod.
služba 2
FTP
FTP
HTTP
FTP
FTP
HTTP
FTP
HTTP
HTTP
FTP
HTTP
FTP
FTP
HTTP
HTTP
FTP
Nastavení cíle 2
Server_3_HTTP_FTP
Server_3/4/5
Server_3_HTTP_FTP
Server_3_HTTP_FTP
Server_3/4/5
Server_3_HTTP_FTP
Server_3_HTTP_FTP
Server_2_HTTP_FTP
Server_1_HTTP
Server_2_HTTP_FTP
Server_2_HTTP_FTP
Server_1/2
Server_1/2
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. 5.9. 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
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.
5.10 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. 5.11.
56
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
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. 5.12.
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
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 5000. 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.
5.16 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. 5.17. 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
Obr. 5.17: Statistika celkového provozu OSPF protokolu.
Následující
graf
na
obr. 5.18
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
Obr. 5.19: Statistika celkového provozu HTTP protokolu.
Simulace komunikace klienta s webových serverem na obr. 5.19 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
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
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. 6.1. 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í tm 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 Nz – 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 ts
– 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ů Nz a Nk 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
topologie - pracovní stanice (ethernet_wkstn_adv) připojena na server
(ethernet_srv_adv) linkou ethernet 100BaseT; objekty Application Configuration
a Profile Configuration - obr. 6.2.
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
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
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ů Nz a Nk 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í 5000–10000, čí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
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
.
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ů Nz a Nk 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
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
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.
7.1. Jak je zřejmé síť obsahuje 2 přístupové body, které jsou mezi sebou propojeny pomocí
přepínače.
Přítomnost
jednotlivými stanicemi.
app_conf
a profile_conf
slouží
k nadefinování
služeb
mezi
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 802.11e, 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
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:
7.1.1
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.
7.1.2
71
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. 7.2. 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
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
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
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. 7.3.
Dále nastavení QoS
zmenší celkové ztrátovost (zahazování datových jednotek).
Standard 802.11e 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 802.11e je dobrým řešením, jak
zajistit požadovanou kvalitu služeb v bezdrátových sítích WLAN typu 802.11.
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
8.1.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í).
8.1.2
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
8.1.3
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 224.0.0.0 až
239.255.255.255. 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
8.2
77
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.
8.2.1
RealMedia
Jedna z prvních verzí, která zahýbala, vodami internetu byla vydána počátkem dubna
roku 1995. 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
ř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.
8.2.2
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
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.
8.2.3
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
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í.
8.2.4
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ů.
8.2.5
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
8.3.1
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.
8.3.2
81
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čí.
8.3.3
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.
8.3.4
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.
8.3.5
Ž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
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ů.
8.4.1
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 10918-1.
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
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.
8.4.2
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 1993. 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 11172. 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
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 13818.
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 14496.
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
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 14496-10.
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 MPEG4. 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.
8.4.3
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
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.
8.4.4
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
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.
8.4.5
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
• Název projektu: VideoLAN Projekt
• Web: http://www.videolan.org
• 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.
8.4.6
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
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
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, e-mail 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í.
9.2
91
Doporučení ITU-T Y.1564, testovací metodologie aktivace služeb
Ethernet
9.2.1
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 01. 03. 2011, edice 1, studijní skupina 12.
9.2.2
Ú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.1563.
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 2544“. 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 1242.
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 2544.
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 2544. 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
• 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.
9.2.3
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.
9.2.4
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).
[ITU-T G.8011]
93
Recommendation ITU-T G.8011/Y.1307 (2009), Ethernet service
characteristics.
[ITU-T G.8011.1]
Recommendation ITU-T G.8011.1/Y.1307.1 (2009), Ethernet
private line service.
[ITU-T G.8011.2]
Recommendation ITU-T G.8011.2/Y.1307.2 (2009), Ethernet virtual
private line service.
[ITU-T G.8012]
Recommendation ITU-T G.8012/Y.1308 (2004), Ethernet UNI and
Ethernet NNI, plus Amendment 1 (2006).
[ITU-T M.2110]
Recommendation ITU-T M.2110 (2002), Bringing into service
international multi-operator paths, sections and transmission
systems.
[ITU-T Y.1543]
Recommendation ITU-T Y.1543 (2007), Measurements in IP
networks for inter-domain performance assessment.
[ITU-T Y.1563]
Recommendation ITU-T Y.1563 (2009), Ethernet frame transfer and
availability performance, plus Amendment 1 (2009).
[ITU-T Y.1730]
Recommendation ITU-T Y.1730 (2004), Requirements for OAM
functions in Ethernet-based networks and Ethernet services.
[ITU-T Y.1731]
Recommendation ITU-T Y.1731 (2008), OAM functions and
mechanisms for Ethernet based networks, plus Amendment 1 (2010).
[IEEE 802.1Q]
IEEE 802.1Q-2003, IEEE Standards for Local and Metropolitan
Area Networks – Virtual Bridged Local Area Networks.
[MEF 10.2]
Technical Specification MEF 10.2 (2009), Ethernet Services
Attributes, phase 2.
9.2.5
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
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.
9.2.6
95
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í.
9.2.7
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
9.2.8
Atributy služby Ethernet
Jak již bylo zmíněno v úvodu, atributy služby Ethernet nejsou definovány v ITU-T Y.1563.
Proto tato klauzule shrnuje důležité pojmy nalezené v rodině doporučení ITU-T G.8011.
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.8012.
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.
9.2.9
97
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
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.
9.2.10 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.1563. 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
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.1564. Vzhledem
k rozsáhlosti standardu, není možné zde uvést všechny kapitoly standardu. Pro bližší a
100
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 1944.
9.3.1
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í.
9.3.2
Ú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í.
9.3.3
Testy, které mají být provedeny
Existuje celá řada testů popsaných v dokumentu RFC 2544. 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
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.
9.3.4
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ů.
9.3.5
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í".
9.3.6
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
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
Obr. 9.6: Schéma sítě
9.3.7
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.
9.3.8
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
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.
9.3.9
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.
9.3.10 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ů.
9.3.11 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
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ů.
9.3.12 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ů.
9.3.13 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.
9.3.14 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
9.3.15 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ě.
9.3.16 Ří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.
9.3.17 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
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.
9.3.18 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.
9.3.19 Adresy filtru
Dvě sady filtračních adres jsou nutné, jedna pro případ jednoho filtru a jedna pro případ 25
filtrů.
108
Jediný filtr by měl umožnit provoz IP adres od 198.18.1.2 do 198.19.65.2 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.100.1
...
zakaž od aa.bc.1.2 do aa.bc.65.1
...
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í.
9.3.20 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
9.3.21 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.
9.3.22 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.
9.3.23 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ě.
9.3.24 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
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 2544. 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í.
111
10 Seznam použité literatury
[1]
VOZŇÁK, M. Komunikační systémy v korporátních sítích pro integrovanou výuku VUT
a VSB-TUO. Elektronická skripta, VŠB-TUO, Ostrava 2014
[2]
PUŽMAN, J. Datové sítě a služby. ČVUT, Praha 1994
[3]
[4]
ITU-T. Reccomendations. Dostupné na Internetu:
http://www.itu.int/en/ITUT/publications/Pages/recs.aspx, Geneva 1993 - 2014
KAPOUN,V.: Digitální ústředny. Skriptum VUT, CERM, Brno 2000
[5]
PUŽMANOVÁ, R.. Moderní komunikační sítě od A do Z. Computer Press, Brno 2007
[6]
HLAVICA, M. Analýza audio kodeků užívaných při IP telefonii. DP, VUT, Brno 2012
[7]
ŠKORPIL, V., HLAVICA, M. Codecs for VoIP Comparison. Proceedings of the 16th
International Conference on Research in Telecommunication Technologies. pp.29-31,
ČVUT, Praha 2014
[8]
ŠKORPIL, V. Vysokorychlostní komunikační systémy. Elektronická skripta, VUT, Brno
2013
PUCHRÍK, Matej. Simulace Triple play služeb v pasivních optických sítích v prostředí
[9]
OMNeT++. Brno, 2014. Semestrální projekt. Vysoké učení technické v Brně. Vedoucí
práce Ing. Tomáš
[10] WEHRLE, Klaus, Mesut GÜNES a James GROSS. Modeling and Tools for Network
Simulation. 1., st Edition. Berlin: Springer Berlin, 2010. ISBN 36-421-2330-9.
[11] CHAMBERLAIN, Thomas. Learning OMNeT: make realistic and insightful network
simulations with OMNeT. New Edition. Birmingham: Packt Publ, 2013. ISBN 18-4969714-0.
[12] LATIF, Fasil a Imitaz AHMAD BHAT. ANALYSIS OF QUALITY OF SERVICE
PROTOCOLS (QOS): Analysis of QoS Protocols:INTSERV and DIFFSERV. Pakistan:
LAP LAMBERT Academic Publishing, 2011. ISBN 978-384430151
[13] GIAMBENE, Giovanni. Queuing theory and telecommunications. xxi, 516 pages. ISBN
978-1461440833.
[14] LU, Zheng a Hongji YANG. Unlocking the power of OPNET modeler. New York:
Cambridge University Press, 2012, xiv, 238 p. ISBN 05-211-9874-7.
[15] SETHI, Adarshpal S a Vasil Y HNATYSHIN. The practical OPNET user guide for
computer network simulation. Boca Raton: CRC Press, xxiii, 503 s. ISBN 978-1-43981205-1.
[16] LU, Zheng a Hongji YANG. Unlocking the power of OPNET modeler. New York:
Cambridge University Press, 2012, xiv, 238 p. ISBN 05-211-9874-7.
112
[17] SETHI, Adarshpal S a Vasil Y HNATYSHIN. The practical OPNET user guide for
computer network simulation. Boca Raton: CRC Press, xxiii, 503 s. ISBN 978-1-43981205-1.
[18] BEURAN, Edited by Razvan. Introduction to network emulation. Singapore: Pan
Stanford, 2013. ISBN 978-981-4310-918.
[19] SIMPSON, Wes. Video over IP: a practical guide to technology and applications.
Burlington: Focal Press, 2006, 493 s. ISBN 978-0-240-80557-3.
[20] FOTHERINGHAM, Vern a Chetan SHARMA. Wireless broadband: conflict and
convergence. Hoboken, N.J: Wiley, c2008, xxiii, 253 p. IEEE series on mobile. ISBN
04-702-2762-1.
[21] NILSSON, Frederik. Intelligent Network Video : Understanding Modern Video
Surveillance Systems. Har/Dvdr edition. [s.l.] : CRC Press, 2008. 416 s. ISBN
1420061569, 978-1420061567. [y] SIMPSON, Wes. Video over IP: a practical guide to
technology and applications. Burlington: Focal Press, 2006, 493 s. ISBN 978-0-24080557-3.
[22] BEACH, A. Real world video compression. Berkeley: Peachpit Press, 2008. 320 s.
ISBN 978-0-321-51469-1.
[23] Carrier Ethernet Testing. Fluke Corporation [online]. [cit. 15.3. 2014]. Dostupné
z:http://www.flukenetworks.com/Expertise/Learn-About/carrier-ethernet-testing
[24] New Ethernet Standard: EtherSAM. EXFO Inc. [online]. 2014 [cit. 2.3. 2014]. Dostupné
z:http://www.exfo.com/solutions/metro-core-networks/carrier-ethernet/ethersam
[25] Request for Comments: 2544. Benchmarking Methodology for Network Interconnect
Devices. Network Working Group, 1999.
[26] Doporučení ITU-T Y.1564. Ethernet service activation test methodology. ITU-T,
2011.

Efektivní využití přenosu informací pro integrovanou výuku VUT

Transkript

Podobné dokumenty

Virtualizace počítačových sítí - Fakulta informatiky a managementu

Dynamips, Dynagen, GNS3

služby a kvalita služeb

Přenos dat: Zkouška 2005

Sítě nové generace – Vybrané kapitoly - IMProVET

5. Počítačové sítě

CCNA Exploration - Základy sítí

CCNA_Exploration_1_1_CZ

KX-TS560FX

Sablona prezentace - SmartCard Forum 2009