VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ
Ústav telekomunikací
Modelování chování páteřních směrovačů DiffServ domény bakalářská práce
Obor: Teleinformatika Jméno studenta: Otto ZEMAN Vedoucí bakalářské práce: Ing. Karol Molnár, Ph.D.
Brno University of Technology Faculty of Electrical Engineering and Communication Department of Telecommunications
Modelling the behaviour of core routers in a Diffserv domain Bachelor Thesis
Specialization of study: Teleinformatics Author: Otto ZEMAN Supervisor: Ing. Karol Molnár, Ph.D.
ABSTRACT The aim of this work is to study the components and functions of the differential services technology (DiffServ) with a detailed focus on the functions of core routers used in a DiffServ domain. The next concern of this work is to study the characteristics of basic features offered by the OPNET Modeler simulation environment, which are designed to support quality of services in data networks. The main result achieved during the solution of this work is a simulation model of a DiffServ domain with fully configured core routers built-up in the OPNET Modeler environment. The core routers support the Expedited Forwarding, two classes of Assured Forwarding and the Best-Effort packet treatment. The correct function of the core routers was verified by numerous simulations.
Obsah 1
Kvalita služeb v IP sítích (QoS) ................................................................ 4 1.1 1.2 1.3 1.4
2
Základní parametry přenosu................................................................... 10 2.1 2.2 2.3 2.4 2.5
3
Definice ................................................................................................. 4 Historie a současnost............................................................................... 5 Třídy služby ........................................................................................... 5 Naměřené hodnoty v reálné síti CRFreeNet – Chrudim .................................. 7
Definice ............................................................................................... 10 Ztráta paketů ....................................................................................... 10 Zpoždění - latence ................................................................................ 11 Kolísání zpoždění - jitter......................................................................... 11 Šířka pásma - bandwith ......................................................................... 11 Mechanismy IntServ a DiffServ .............................................................. 12
3.1 Integrované služby................................................................................ 12 3.2 Diferencované služby............................................................................. 15 3.2.1 Referenční model technologie diffserv................................................ 17 3.2.2 Třídič - Classifier ............................................................................ 17 3.2.3 Značkování – Marker....................................................................... 18 3.2.3.1 Urychlené doručení - Expedited Forwarding (EF) .......................... 19 3.2.3.2 Zaručené doručení - Assured Forwarding (AF) ............................. 20 3.2.4 Měřič - Meter ................................................................................. 22 3.2.4.1 Token bucket.......................................................................... 23 3.2.5 Přeznačení - Remarker .................................................................... 24 3.2.6 Tvarovač – Shaper.......................................................................... 24 3.2.7 Zahození - Dropper......................................................................... 24 4
Opnet Modeler ........................................................................................ 25 4.1 Úvod – základní charakteristiky simulátoru Opnet Modeler .......................... 25 4.2 Základní prvky OPNET Modeler................................................................ 25 4.3 Editory ................................................................................................ 26 4.3.1 Editor projektu (Project Editor) ......................................................... 26 4.3.1.1 Editor projektu - pracovní plocha ............................................... 27 4.3.2 Editor uzlu (Node Editor) ................................................................. 28 4.3.3 Editor procesu (Process Editor) ......................................................... 29 4.3.3.1 Editor procesu – základní pravidla ..................................................... 30
5
Modelování chování páteřních směrovačů DiffServ domény ................... 31 5.1 Úvod ................................................................................................... 31 5.2 Vzorová síť........................................................................................... 32 5.3 Obecný návrh vzorové sítě ..................................................................... 33 5.4 Nastavení aplikací ................................................................................. 34 5.4.1 Application Config – Definice aplikací ................................................. 34 5.4.1.1 Application Config – Předdefinované hodnoty .............................. 36 5.4.2 Profile Config – Profil aplikace........................................................... 38 5.5 Nastavení aplikací na klientech a serverech............................................... 39 5.5.1 Nastavení serveru pro podporu aplikací.............................................. 40 5.5.2 Nastavení spojení klient – server ...................................................... 41
2
5.5.2.1 Příklad nastavení spojení klient – server ..................................... 41 5.6 Nastavení páteřního směrovače pro podporu kvality služeb ......................... 43 5.6.1 QoS Atrribute Config ....................................................................... 44 5.6.1.1 WFQ Profile ............................................................................ 45 5.6.2 Algoritmus RED (Random Early Detection) ......................................... 47 5.6.3 Nastavení kvality služeb na směrovači ............................................... 48 5.6.4 Nastavení provozu v pozadí na lince .................................................. 49 5.7 Nastavení sledovaných parametrů – statistik............................................. 50 5.8 Simulace.............................................................................................. 51 5.8.1 Nastavení a průběh simulace (jednoho scénáře).................................. 51 5.8.2 Nastavení a průběh simulace (více scénářů) ....................................... 52 5.9 Výsledky simulace ................................................................................. 52 5.9.1 Výsledky simulace - zpoždění ........................................................... 53 5.9.2 Výsledky simulace – využití bufferu ................................................... 53 5.9.3 Porovnání scénářů – zpoždění .......................................................... 53 5.9.4 Porovnání scénářů – využití bufferu................................................... 54 5.9.5 Porovnání scénářů – odeslaná data z fronty Q1 ................................... 54 6
Závěr ...................................................................................................... 55
7
Přílohy.................................................................................................... 56 7.1 7.2 7.3 7.4 7.5 7.6 7.7
Výsledky naměřených hodnot ................................................................. 56 Seznam obrázků ................................................................................... 62 Seznam tabulek .................................................................................... 64 Seznam zkratek .................................................................................... 65 Použitá literatura................................................................................... 67 Prohlášení ............................................................................................ 69 Poděkování .......................................................................................... 70
3
1 Kvalita služeb v IP sítích (QoS) 1.1 Definice Internet byl vybudován s cílem poskytovat přenosovou službu, bez zajištění parametrů spojení, jako např. doručení paketů do určité doby (s minimalizací zpoždění způsobený přenosem sítí), případně zajištění předem definované šířky pásma po dobu trvání přenosu, atd. Přitom v dnešních sítích je stále častěji potřeba rozlišovat různé požadavky na kvalitu služeb (QoS - Quality of Service) [7]. Kvalita služby je definována jako výsledek výkonnosti služby, který určuje stupeň spokojenosti uživatele. Stupeň spokojenosti uživatele je těžce definovatelný. Kvalita služby v IP sítích charakterizuje výkonností toku paketů jednou nebo více sítěmi. Snahou je doručit pakety mezi koncovými uživateli dle určitých kritérií. Základní pravidla pro provoz Internetu [7], která byla definována již v 70. letech, jsou: •
žádnému typu provozu nebude odmítnut přístup do sítě,
•
s jakýmkoliv provozem se bude zacházet stejně,
•
jediná garance pro provoz je, že bude přenesen co nejlepším způsobem (Best Effort) v závislosti na dostupných prostředcích tzn., že nebude zbytečně a zcela uměle docházet ke zpoždění nebo nebude docházet ke ztrátám paketů. Na přenos datových souborů nebo elektronické pošty nemá velký vliv zpoždění
nebo jeho kolísání. Pokud přejdeme k interaktivní komunikaci dozvíme se, že zpoždění nebo jeho kolísání může mít nežádoucí vliv. Přesněji, zpoždění a jeho kolísání nemá velký vliv do té doby, do kdy nedojde k přetížení komunikační cesty mezi komunikujícími stranami. Neexistuje ale žádná jistota, že potřebná úroveň přenosové služby bude zajištěna celou dobu spojení, protože zátěž sítě může zapříčinit větší zpoždění paketů nebo dokonce jejich ztrátu. Zpoždění a jeho kolísáni jsou u Best Effort provozu nepředvídatelné, tedy nijak neošetřené – nezajištěné. Jedním řešením by bylo zvýšení přenosové kapacity datových linek Internetu. Nedocházelo by ke ztrátám paketů a zpoždění bychom docílili velmi malé. Ale dostatek kapacity v páteřní síti neřeší problém s nedostatkem šířky pásma v okrajových částech sítě. Hraniční směrovače páteřní sítě Internetu (edge routers) dnes zpracovávají milióny datových toků přicházejících rychlostí Gbit/s. Fyzické limity těchto zařízení pak mají často
4
mnohem výraznější vliv na objem přenesených dat a parametry přenosu, než fyzická omezeni způsobená samotným přenosovým mediem. Chování distribuovaných aplikací je závislé na časových charakteristikách spojení, jako je propustnost a zpoždění. Patří sem služby – aplikace jako např. videokonference po IP, IP telefonie, telnet, ftp nebo www. Uživatel zde samozřejmě čeká určitou úroveň služby (např. načtení obrázku, či webové stránky apod. za akceptovatelnou dobu). Síťová aplikace může poskytnout očekávanou kvalitu služby, pokud propojující komponenty poskytují propojení s tou určitou definovanou nebo lepší kvalitou.
1.2 Historie a současnost Technologie pro lokální počítačové sítě (LAN) historicky nepodporovali QoS, protože byly zaměřeny na přenos “obyčejných“ dat. Pro tato obyčejná data tento způsob přenosu plně vyhovoval. S příchodem nových aplikací (přenášející video, hlas, atd.) do LAN již začalo být nutností mít možnost dát provozu citlivému na zpoždění přednost před standardním přenosem. Jako doplňkový mechanismus v LAN se začala používat kombinace značení rámců a následně jejich řazení do front dle jejich priorit podle standardů IEEE 802.1 Q/p. Protokol IP byl navrhnut v době, kdy ještě nebyly definované mechanismy pro zjištění kvality služeb. Hlavička IP paketu sice obsahuje položku ToS (Type of Service),
ale
ta
se
prakticky
nepoužívá
kvůli
zvýšení
nároků
na
zpracování
ve směrovačích. Další možností jsou zde hodnoty priorit (IP precedence), které díky 3 bitům položky ToS umožňují roztřídit provoz do 8 tříd. IP precedence byla nahrazena DSCP (Differentiated Service Code Point), který na rozdíl od IP precedence využívá 6 bitů položky
ToS
a
umožňuje
rozřazení
paketů
do
64
tříd
v rámci
mechanismu
diferencovaných služeb (DiffServ). Zajištění QoS se nejčastěji řeší pomocí doplňkových mechanismů diferencovaných služeb (DiffServ), protokolu RSVP (Resource reSerVation Protocol) a technologie MPLS (Multiprotocol Label Switching). Dosažení požadované kvality služby tedy předpokládá spolupráci všech vrstev referenčního modelu a spolupráci síťových prvků. To znamená, že maximální kvalita služby bude záviset na nejslabším článku sítě viz [7].
1.3 Třídy služby Kapitola popisuje nejčastější - doporučený způsob dělení síťového provozu do tříd a to pomocí Behavior Aggregate (BA) a MultiField (MF), viz kap. 3.2.2. Pro třídění síťového provozu jsou běžně definovány následující třídy:
5
•
Real-time (VoIP) - Tato třída je zaměřena na aplikace jako je VoIP a video. Třída požaduje nízké ztráty (méně než 0,25%), nízké zpoždění a minimální jitter (typicky 5ms uvnitř páteře) a má předepsanou šířku pásma a dostupnost. Dosažitelný výkon je odvozen ze šířky pásma a ztráty paketů.
•
Obchodní data (Business) - Tato třída představuje interaktivní aplikace jako je např. telnet a intranetové webové aplikace. Třída má specifikované požadavky na zpoždění, které by měly být menší než 250ms, ztráty menší než 1% a dále je specifikována šířka pásma a dostupnost. Jitter není důležitý pro tuto třídu služby a proto ani není definován.
•
Best effort (BE) - Tato třída představuje celý zbylý provoz, který nebyl klasifikován jako Real-time nebo Business. Definuje podmínky na míru ztrát a specifikuje šířku pásma a dostupnost. Dosažitelný výkon je odvozen ze ztrát. Zpoždění a jitter nejsou důležití pro tuto službu a nejsou stanoveny. Třída připouští zpoždění paketů ve vyrovnávací paměti směrovače.
V některých případech pro provoz související se správou a provozováním sítě (směrovací protokoly, SNMP, atd.) je vyhrazena samostatná třída. Tab. 1 - Příklady a zařazení služeb Typ služby Best effort
Real-time (VoIP)
Business
WWW (World Wide Web)
IP telefonie
WWW (World Wide Web)
Komunikační programy (ICQ,MSN,AIM,IRC)
On-line web kamery
Vzdálená správa PC (Real VNC, Remote Administrator)
E-mail
On – line TV
FTP (File Transfer Protokol) Výměnné sítě (P2P) (DC++, Bittorrent, eDonkey2k, Kazaa)
6
1.4 Naměřené hodnoty v reálné síti CRFreeNet – Chrudim Zde jsou přiložené naměřené hodnoty, které jsem pořizoval za účelem zjištění provozu v reálné síti. Statistika byla provedena na hlavním směrovači občanského sdružení CRFreeNet - Chrudim, na místě které předává pakety a tudíž nezachytává ARP protokol. Tato síť nemá žádná datová omezení, ani nijak zakázané porty, vše je dovoleno. Síť má 2Mbps směrem do Internetu a sdílí ji 70 lidí. Statistiky byly pořízeny za časový interval 24hodin. Sledoval jsem jednotlivé parametry pro jednotlivé služby (počet přenesených paketů, objem přenesených dat, velikost průměrného paketu a využití jednotlivých protokolů), viz. Tab.2 Popis jednotlivých aplikací – protokolů, které jsem zachytil • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Auth – Authentication Service Bootpc – Bootstrap Protocol Client - zaváděcí protokolový klient Csnet –ns - Mailbox Name Nameserver Domain - Domain Name Server Echo – Ftp – File Transfer Protocol [Control] – přenášení souborů Ftp – data - File Transfer Protocol [Default Data] Gopher – Http - World Wide Web Http Https – World Wide Web Security ICQ – I seek you - protokol pro chatování Iso – tsap – Jabber – Otevřený protokol pro chatování Kerberos - Autentizační mechanismus Link – MSN - MSN Messenger MySQL - Relační databázový systém Ntp - Network time protokol – slouží ke synchronizaci času Ostatní – většinou P2P sítě Pop3 - Post Office Protocol – protokol příchozí pošty v3 Pop3s - Post Office Protocol Security – zabezpečený protokol Sftp - Simple File Transfer Protocol Smtp - Simple Mail Transfer Protocol Ssh - Protokol pro vzdálený přístup ke konzoly serveru po síti Sunrpc - SUN Remote Procedure Call Systat - Active Users Tcpmux - TCP Port Service Multiplexer Telnet - slouží k navázání spojení s jiným počítačem Tftp - Trivial File Transfer Protocol
7
[port] [113] [68] [105] [53] [7] [21] [20] [70] [80] [443] [5190] [102] [5222] [88] [245] [1863] [3306] [123] [110] [995] [115] [25] [22] [111] [11] [1] [23] [69]
Tab. 2– Naměřené hodnoty v reálné síti CRFreeNet
Port
Přeneseno paketů
Přeneseno dat [kB]
[MB]
Velikost průměrného paketu [B]
Využití protokolů
Auth
65
5,68
0,01
89,51
0,00%
Bootpc
56
5,56
0,01
101,64
0,00%
csnet-ns
2
0,27
0,00
139,00
0,00%
Domain
2749
383,62
0,37
142,90
0,00%
892
1168,82
1,14
1341,78
0,01%
14304
10567
10,32
756,54
0,05%
ftp-data
14
1,18
0,00
86,43
0,00%
Gopher
18
1,43
0,00
81,56
0,00%
http
3768083
3407151,00
3327,00
925,91
15,66%
https
44993
15080,00
14,73
343,21
0,07%
ICQ
30313
4909,68
4,79
165,85
0,02%
3
0,23
0,00
77,67
0,00%
1787
116,22
0,11
66,60
0,00%
Kerberos
1
0,14
0,00
139,00
0,00%
Link
2
0,27
0,00
139,00
0,00%
MSN
36
2,73
0,00
77,75
0,00%
Mysql
2144
1699,00
1,66
811,68
0,01%
Ntp
2613
503,00
0,49
197,26
0,00%
33418417 17884638,00
17465,00
548,02
82,23%
Echo ftp
iso-tsap Jabber
Ostatní pop3
297927
423206,00
413,00
1454,60
1,95%
pop3s
1131
413,04
0,40
373,96
0,00%
2
0,27
0,00
139,00
0,00%
9474
401,64
0,39
43,41
0,00%
Ssh
46
6,57
0,01
146,24
0,00%
Ssh
2
0,27
0,00
139,00
0,00%
Sunrpc
180
12,94
0,01
73,61
0,00%
Systat
2
0,18
0,00
93,00
0,00%
81
6,10
0,01
77,06
0,00%
7719
350,67
0,34
46,52
0,00%
6
0,28
0,00
47,00
0,00%
37603062
21750635
21240
592,31
100,00%
Sftp Smtp
Tcpmux telnet Tftp Celkem
8
Graf 1. - V yužití služeb v síti CRFreeNet pop3
http
2%
16%
ostatní 82%
http
ostatní
pop3
Graf 1. zobrazuje využití služeb v reálné sítí. Je zde vidět, že je markantní 82% využití ostatních služeb, což je způsobené většinou P2P programy (DC++, Kazaa, BitTorrent, atd.). Je to způsobeno tím, že v síti CRFreeNet nejsou žádné limity, ani blokované porty. Graf 2. - Využití služeb v síti CRFreeNet bez 3 nejvíce zastoupených parametrů (http,pop3 a ostaní) ntp mysql 1% 5% ICQ 14%
domain
echo
ftp
pop3s 1%
smtp telnet domain 1% 1% 1% echo 3% ftp 30%
https 42%
https
ICQ
mysql
ntp
pop3s
smtp
telnet
Graf 2. zobrazuje využití služeb v síti CRFreenet bez 3 nejvíce zastoupených služeb (http, pop3 a ostatní). Je zde patrné, že je nejvíce využito protokolu https 42%, ftp 30% a také ICQ 14%. Ostatní protokoly jsou už vzhledem k ostatním zanedbatelné. Graf 3. - Rozdělení do tříd služeb v reálné síti CRFreeNet Chrudim
Business; 0,1%
Best Effort ; 99,9%
Best Effort
Business
9
Graf 3. zobrazuje rozdělení do tříd v síti CRFreeNet. Je zde jasně vidět, že skoro veškerý provoz probíhá ve třídě Best Effort. Je to dáno tím, že tato síť nemá žádné omezení, a proto zhruba 80% provozu představuje využití P2P programů, který je přenášen ve třídě BE.
2 Základní parametry přenosu 2.1 Definice Kvalita služby záleží na kombinaci následujících parametrů: •
ztráta paketů - souvisí se spolehlivostí – [viz kap. 2.2],
•
zpoždění – latence - souvisí se šířkou pásma - [viz kap. 2.3],
•
kolísání zpoždění – jitter - souvisí se zpožděním – včasném doručení paketů – [viz kap. 2.4],
•
šířka pásma – bandwith - jedná se o kapacitu spoje, udává se např. v kbps - [viz kap. 2.5].
Tab. 3 - Citlivost různých typů služeb na parametry sítě Citlivost na Služba šířku pásma
ztrátu paketů
zpoždění
kolísání
velmi nízká
střední
vysoká
vysoká
Elektronický obchod
Nízká
vysoká
vysoká
nízká
Transakce
nízká
vysoká
vysoká
nízká
e-mail
nízká
vysoká
nízká
nízká
telnet
nízká
vysoká
střední
nízká
Občasné prohlížení webu
nízká
střední
střední
nízká
Časté prohlížení webu
střední
vysoká
vysoká
nízká
Přenos souborů
vysoká
střední
nízká
nízká
Videokonference
vysoká
střední
vysoká
vysoká
Skupinové vysílaní
vysoká
vysoká
vysoká
vysoká
Hlas
2.2 Ztráta paketů Ztrátu paketů [7] v síti můžeme hledat v různých příčinách. Nejvíce je to kvůli přetížení či zahlcení síťového uzlu, kdy některé směrovače nebo přepínače nestačí odbavovat příchozí pakety dostatečně rychle. Fronty ve vyrovnávacích pamětích směrovačů přetečou a proto jsou další pakety zahozeny. Tato ztráta je pro aplikace, které neprobíhají v reálném čase není zase tak kritická, protože aplikace založené na TCP protokolu se mohou spolehnout na jejich opětovné vyslání.
10
Kdežto aplikace pracující v reálném čase, používají zpravidla nespolehlivý transportní protokol UDP. Tyto aplikace jsou citlivější na ztrátu paketů, protože nemají mechanismus na opětovné vysílání paketů a to proto, že jim pozdější doručení paketů by nebylo moc platné. Na druhé straně z charakteru přenášeného signálu vyplývá tolerance určité míry ztrát.
2.3 Zpoždění - latence Zpožděním čili latencí se rozumí čas, za který data doputují od zdroje do cílového místa. Zpoždění se skládá z několika dílčích zpoždění: •
zpoždění kódováním a serializací (přípravou paketů na přenos médiem),
•
zpoždění při přenosu ze vzdálenosti),
•
zpoždění způsobené čekáním ve frontě na odbavení,
•
zpoždění při přepínání v síti (nalezení další cesty v síti a odpovídajícího výstupního portu).
(odvozené
z rychlosti
šíření
signálu
v
médii
a
2.4 Kolísání zpoždění - jitter Kolísání zpoždění je způsobeno zpožděním při serializaci paketů, rozdílem délek front, které souvisejí s mírou zahlcení sítě. Důsledkem uvedených faktorů je, že pakety v rámci dané konverzace nemusejí přicházet od zdroje se stejným zpožděním. Kolísání zpoždění má nejhorší dopad na VoIP služby. Při rychlosti vysílání 20 ms/paket se očekává, že pakety budou doručeny k cíli pravidelně po 20 ms. To ale nemusí být vždy dodrženo kvůli dynamickým změnám zatížení sítě. Tento problém je řešen vyrovnávacími pamětmi v telefonech, nebo branách.
2.5 Šířka pásma - bandwith Šířka pásma [7] je šířka kmitočtového pásma postačujícího při daném druhu vysílání pro zajištění přenosu informace požadovanou rychlostí a s požadovanou jakostí v daných podmínkách. Analogová šířka pásma je měřena v jednotkách Hertz (Hz) neboli cyklech za sekundu. Obvykle je vyjádřena třemi číslicemi a jedním písmenem. Písmeno označuje umístění desetinné čárky a udává jednotku potřebné šířky pásma Hz, kHz, MHz (Např. 12,5 kHz = 12K5). Digitální šířka pásma je měřena v bitech za sekundu. Šířku pásma nelze zaměnit s pásmem. Pokud například mobilní přístroj pracuje v pásmu 900
11
MHz, šířka pásma je prostor, který zaujímá v tomto pásmu. Šířka pásma kanálu ovlivňuje přenosovou rychlost. Tab. 4 - Přehled nejdůležitějších parametrů síťových služeb
Typ provozu
Max. ztráty paketů
Max. jednosměrná latence
Max. kolísání
Garantovaná prioritní šířka pásma na relaci
Hlas po IP
1%
200 ms
30 ms
12 – 106 kbit/s (v závislosti na rychlosti vzorkování, kodeku apod.)
Videokonference
1%
200 ms
30 ms
Objem relace plus 20%
Streamované video
2%
5s
-
Závisí na formátu kódování a rychlosti toku videa
různé
různé
různé
různé
data
3
Mechanismy IntServ a DiffServ Abychom splnili požadavky uživatelů na kvalitu poskytovaných služeb, nebo
aplikací můžeme použít dva způsoby zajištění QoS: •
Integrovaných služeb – Integrated Services (IntServ)
•
Diferencované služby – Differentiated Services (DiffServ)
3.1 Integrované služby U integrovaných služeb aplikace oznámí počítačové síti své požadavky na přenos dat. To znamená, že definuje určité vlastnosti, které by při přenosu paketů měli být dodrženy. Počítačová síť ověří, zda požadavku může vyhovět. Pokud nelze vyhovět, aplikace může snížit svoje požadavky na QoS nebo odložit přenos. Pokud síť požadavkům vyhoví musí informovat všechny komponenty, např. směrovače v uzlech počítačové sítě, přes které bude probíhat přenos, aby mohly pro dané spojení rezervovat odpovídající objem prostředků. Zpravidla se rezervuje určitá šířka pásma pro spojení mezi dvěma směrovači, určitá velikost vyrovnávací paměti pro tvorbu front uvnitř směrovače, apod. K tomuto účelu slouží rezervační protokol RSVP (Resource reSerVation Protocol) [1]. Protokol RSVP není vhodné pro použití v Internetu, protože přináší velkou časovou režii. Řada aplikací nepotřebuje nutně zajistit určitou konkrétní průchodnost nebo minimální zpoždění. Postačí, když bude zajištěno, že tyto parametry nebudou výrazně zhoršeny
12
vlivem jiné komunikace současně probíhající v téže počítačové síti. Například, aby spuštění
přenosu
velkého
souboru
nezpůsobilo
podstatné
zpomalení
interaktivní
komunikace, kde je odezva vnímána uživatelem mnohem citlivěji. Navíc, při stále se zvyšujících rychlostech průchodu paketů směrovači je třeba maximálně zjednodušit zpracování jednotlivých procházejících paketů a minimalizovat objem stavových informací (jakou je například rezervace síťových prostředků), které musí směrovače o jednotlivých spojeních udržovat. Proto se v poslední době pozornost obrací více k jinému přístupu k implementaci QoS do počítačové sítě - k diferencovaným službám. DiffServ poskytne zajištění QoS na základě klasifikace paketů do různých tříd s podobnými vlastnostmi. Třídit provoz můžeme dle různých hodnot: •
MAC adresa,
•
identifikátor portu přepínače,
•
adresa IP,
•
typ aplikace (identifikovaný podle čísel portů TCP/UDP). Model integrovaných služeb je definován v [9]. V následujícím textu je blokově
popsán referenční model technologie InterServ (Obr. 1). Řízení přístupu - Admission Control - Na žádost aplikace jsou podle dostupnosti síťových prostředků tyto prostředky (požadovaná šířka pásma a vyrovnávací paměti), buď poskytnuty a zpět je zasláno pozitivní potvrzení nebo zamítnuty a vrácena negativní odpověď. Bez této funkcionality by model IntServ zaručoval všechny dostupné zdroje všem třídám provozu a mohl by poskytovat opět jen služby typu best-effort. RSVP (Resource reSerVation Protocol) [1] – Signalizační protokol určený pro rezervaci síťových prostředků pomocí zpráv PATH a RESV. Generuje několik typů zpráv, které se rozlišují pomocí osmibitového pole v hlavičce protokolu. Kromě vlastní hlavičky může RSVP přenášet další údaje ve formě tzv. objektů. Klasifikátor - Packet classifier – Třídič paketu - plní funkci mapování paketu do servisních tříd. Třídič paketů je součástí směrovačů i koncových zařízení. Plánovač paketů - Packet scheduler - řídí odesílání paketu podle odpovídající servisní třídy, tj. datového toku.
13
Popis zpráv PATH a RESV [15] Zdroj datového toku vysílá v pravidelných intervalech zprávy typu PATH, které jsou dále šířeny po trase směrem k příjemci od jednoho směrovače k následujícímu. V případě multicastových toků se zprávy PATH samozřejmě šíří od zdroje ve více větvích. Zprávy PATH obsahují zejména tyto objekty: •
RSVP_HOP: Každý směrovač na trase od zdroje k příjemci sem zapíše sebe jakožto původce zprávy.
•
SENDER_TSPEC: Do tohoto objektu zapíše zdroj parametry toku, který generuje jde v podstatě o specifikaci průměrné a špičkové přenosové rychlosti. Dalšími směrovači na trase je tento objekt ve zprávách PATH předáván beze změny. Příjemce z něho proto získá originální informace o parametrech datového toku.
•
ADSPEC: Tento objekt umožňuje příjemci poté, co k němu doputuje, zjistit vlastnosti trasy od zdroje (dostupnost funkcí potřebných pro specifikaci QoS, šířku pásma, MTU, atd.). Na rozdíl od SENDER_TSPEC je objekt ADSPEC po cestě od zdroje k příjemci postupně modifikován tak, aby odrážel vlastnosti celé trasy.
Příjemce posílá periodicky objekty (FLOWSPEC, FILTERSPEC) zabalené ve zprávě typu RESV (rezervační požadavek) proti směru datového toku - jednotlivé uzly na této cestě lze totiž určit z předcházejících zpráv typu PATH [15]. Na základě těchto informací pak příslušné směrovače udržují rezervaci síťových prostředků.
Obr. 1 - Referenční model technologie InterServ – [9]
14
3.2 Diferencované služby Tato technologie [7] slouží k rozdělení služeb do tříd dle jejich nároků na síť. Hledání jiné cesty než je IntServ vychází z náročnosti protokolu RSVP. Pokud by IntServ se realizoval v celém Internetu, zatěžoval by extrémně směrovače. Ty přenášejí i statisíce toků a jejich nároky na paměť a výpočetní kapacitu by tak byly opravdu veliké. Proto pracovní skupina IETF se snažila vyvinout jednodušší model QoS. Jeho hlavním principem je rozdělení datového toku do malého počtu tříd (CoS - Class of Service), kterým odpovídá určitá kvalita služeb. K roztřídění paketů do jednolité třídy se využívá oktet ToS (Type of service) v hlavičce IPv4 nebo oktet Traffic Class v hlavičce IPv6, viz Obr. 2. DS - rozlišované služby (differentiated service) DSCP – značka rozlišované služby CU – nepoužito (currently unused)
DSCP
CU
DS
Délka Verze
TOS
hlavičky
Celková délka
Verze
paketu Ofset
Identifikace
Příznaky
fragmen tu
TTL
Protokol
Třída
Označení toku
přenosu
dat
Délka datové části paketu
Typ následující hlavičky
Kontrolní součet
.
hlavičky
. .
Adresa odesílatele Cílová adresa
. . . IP v 4
IP v 6
Obr. 2 – Položky ToS a Traffic Class v hlavičce IP paketu
15
Hop limit
Model Diffserv pro dělení komunikační sítě na menší části využívá DS-domény, což je část sítě analogická autonomnímu systému. V DS doméně je jednotná administrace, která zajišťuje: •
vyhodnocování oprávněnosti požadavků,
•
přiřazení toků do tříd,
•
označení paketů.
Obr. 3 – Schéma diffserv – dělení na DS domény V DiffServ doméně se rozlišují tři typy uzlů – směrovačů •
Okrajový směrovač – ten leží na rozhraní DS domény a části sítě, která neznačkuje pakety. Tento uzel je nejdůležitější, protože provádí klasifikaci vstupních toků – označuje pakety a posílá je do své DS-domény.
•
Páteřní směrovač – (core router) neprovádí žádnou klasifikaci paketů, pouze naloží s daným paketem dle jeho značky.
•
Hraniční směrovač – (edge router) leží na rozhraní dvou DS-domén, které mohou mít různá klasifikační pravidla. Způsob jak se naloží s přicházejícími pakety z jiné DS-domény zaleží na dohodě mezi oběmi DS-domény. Obyčejně se provede
16
reklasifikace na základě značky v příchozím paketu a cílové adrese. Poté se přiřadí nová značka.
3.2.1 Referenční model technologie diffserv Referenční model technologie diffserv viz Obr. 4 se skládá z jednotlivých částí, kterým se věnují další části textu viz níže.
Přeznačení Remarker Třídič Classifier
Značkování Marker
Měřič Meter
Klasifikace - Classification
Zahození Dropper Tvarování Shaper Zacházení Conditionig
Obr. 4 – Referenční model technologie diffserv
3.2.2 Třídič - Classifier Třídič dělí přicházející tok paketů do několika skupin podle předdeklarovaných pravidel. Máme dva základní druhy třídičů: •
Behavior Aggregate (BA),
•
MultiField (MF).
BA třídič patří mezi nejjednodušší diffserv třídiče. Ten třídí pakety pouze na základě hodnoty pole DSCP v hlavičce paketu. BA třídič se používá tehdy, kdy je DSCP určené (paket označovaný) už dříve. DSCP hodnota paketu může být označena v mnoha různých cestách. Pokud podporuje zákazníkova síť diferencované služby, je žádoucí, aby byly pakety označeny již ve vstupním směrovači. U mnoha zákaznických sítí se ale dá očekávat, že nebude prováděno toto označení. Takoví zákazníci pak mohou přenechat označování paketů na svoje poskytovatele připojení.
17
MF třídič užívá kombinaci jednoho nebo více polí z pětic:
•
zdrojová adresa,
•
cílová adresa,
•
zdrojový port,
•
cílový port,
•
identifikátor protokolu zapouzdřeného do IP paketu.
Tato pětice je umístěna v IP hlavičce paketu a TCP/UDP datagramu. MF třídič můžeme použít pro komplikovanější zdrojovou alokační politiku u zákazníků. např.: •
značkování paketů podle druhu aplikace (čísla portu), jako TELNET nebo FTP,
•
značkování paketů podle n-tice, který určí aplikační tok, jako např. datový tok videa.
3.2.3 Značkování – Marker Jsou definovány dva typy mechanismů diferencovaného zacházení s pakety různých tříd, označované zkratkou PHB (Per Hop Behavior). Jinými slovy PHB označuje zpracování paketů směrovačem na základě značky paketu. •
Expedited forwarding (EF) – urychlené předávání [2], které nabízí absolutní záruky velikosti kolísání zpoždění pro danou třídu. Je proto velmi složité na zajištění a neefektivní. Když poskytneme EF danému toku dat, tak to skoro odpovídá poskytnutí virtuálního okruhu, což vede k nižšímu využití síťových prostředků. EF lze poskytovat jen omezenému počtu toků. Závěr: složité a aplikovatelné na omezený počet toků.
•
Assured forwarding (AF) – zajištěné předávání [3] – služba je navržena tak, aby zajistila přenos garantovanou rychlostí. Používá se především pro transportní protokol TCP. AF pracuje na základě stanovení priorit pro různé kategorie provozu. V případě zahlcení sítě budou zahozeny pakety, které patří nejnižší třídě QoS. Závěr: zajišťuje pouze slabší garance QoS.
Vedle EF a AF existuje ještě služba základní (BE – Best Effort), která je vhodná pro nenáročné datové přenosy.
18
3.2.3.1
Urychlené doručení - Expedited Forwarding (EF)
Urychlené doručení [18] je specifikováno ve standardu RFC 2598 [14], který byl později přepracován na standard RFC 3246 [3]. Doporučená hodnota DSCP pro urychlené předávaní je “101110”. Urychlené předávání spočívá v předávaní paketů s nízkou měrou ztrátovostí, nízkým zpožděním a nízkým kolísáním zpoždění. EF vyžaduje garantovaný počet výstupních portů s určitou šířkou pásma pro zajištění požadovaných vlastností. Každý směrovač v diffserv doméně odesílá pakety zařazené do EF PHB průměrnou rychlostí,
alespoň
rovnou
stanovené
rychlosti.
Tato
průměrná
rychlost
se
měří
v jakémkoliv časovém intervalu delším nebo rovném době potřebné pro odeslání paketu maximální délky stanovenou rychlostí. EF PHB je vhodný pro emulaci okruhů, soukromé smluvní emulované sítě a pro využití multimediálních služeb jako např. audio nebo videopřenosy, které netolerují zpoždění a kolísání zpoždění. Obr. 5 ukazuje příklad implementace EF. Je to příklad jednoduchého zacházení dle priority paketu (Priority Queuing).
Obr. 5 – Příklad implementace EF Na okraji diffserv domény je tok paketů označen dle dohodnutých pravidel. Fronta EF by měla mít dostatek šířky pásma výstupního portu na zprostředkování služby. Po označení paketu musí páteřní směrovače (core routers) být nastavené tak, aby s označenými pakety bylo zacházeno stejně, jako u okrajových směrovačů (edge
19
routers). To zajistí, že paket bude doručen s požadovanými vlastnostmi. Na obrázku jsou pakety řazeny dle priority. To znamená, že pokud máme ve frontě EF nějaký paket, jsou ostatní fronty blokovány, tudíž nemůže odejít žádný paket jiného PHB. EF se používá především pro multimediální služby probíhající v reálném čase. Protože tyto služby pro přenos zpravidla využívají protokol UDP místo TCP, algoritmus RED (Random Early Detection, Random Early Drop) není vhodný pro použití v EF frontách. RED je především určen pro vytížené páteřní linky. Tento algoritmus snižuje zátěž zahazováním paketů před zahlcením linky. Čím více se blíží celkový datový limit maximální hodnotě, tím více jsou pakety zahazovány. Zahazování paketů v rámci TCP relace pak vyvolá snížení rychlosti odesílání a tak RED může předejít zahlcení uzlu. Další vlastností RED je, že ke všem datovým proudům se chová stejně. Výhodou je, že na vytížených strojích nemá vysoké výpočetní nároky a proto udržuje co největší průchodnost a nejnižší zpoždění linky. Na druhé straně RED by neměla být použita ve EF frontách, protože aplikace používající UDP protokol nereagují na náhodně zahozené pakety. Na závěr je vhodné říci, že u EF je dodržováno striktní omezení rychlosti příchozích dat. Data, která vstoupí do DiffServ domény a překročí sjednanou šířku pásma, jsou zahozena.
3.2.3.2
Zaručené doručení - Assured Forwarding (AF)
Zaručené doručení (AF) [18] je specifikováno ve standardu RFC 2597 [3]. Komponenty AF zaručí spolehlivé doručení paketů a místo zpoždění a kolísání zpoždění klade větší důraz na minimalizaci ztráty paketů. Proto AF není vhodné pro multimediální aplikace běžící v reálném čase. Ve standardu, PHB je specifikováno popisem chování, ale způsob implementace je ponechán na výrobci síťových komponentů. AF se již implementuje na hraničním směrovači DS domény. Chování celého systému závisí na paketech vně a mimo sjednaného profilu, tudíž jestli pakety vyhovují dohodnutým pravidlům nebo ne a proto budou příslušně označeny. Funkce RED ve směrovači se používá pro značkování paketů vně a mimo sjednaného profilu, kdy v případě velkého zatížení je náhodně vybrán paket pro zahození. Pakety mimo profil mají zpravidla nízkou pravděpodobnost doručení protože jsou zařazeny do třídy s větší prioritou zahození. AF nejdříve definovalo 4 doručovací třídy AF1, AF2, AF3 a AF4. Uvnitř každé této definované třídy jsou
20
klasifikovány pakety ještě do 3 podtříd dle pravděpodobnosti zahození. Proto pro AF máme celkem 12 podtříd.
Obr. 6 – Příklad AF Tab. 5 ukazuje čtyři třídy AF a 12 podtříd s hodnotami DSCP dle standardu RFC 2597 [3]. AF zajišťuje, že pakety s vysokou pravděpodobností budou doručeny dle dohodnutých pravidel. Dohodnuté parametry provozu AF jsou shrnuty do tzv. dohody o úrovni služby SLA (Service Level Agreement). Když AF datový tok na vstupním portu překročí přidělený limit, tak tento datový tok nevyhovuje, resp. je mimo profil a tudíž data jsou zařazeny do podtřídy s nižší prioritou doručení. Když dojde k zahlcení sítě, směrovač začne zahazovat pakety mimo profil před vyhovujícími pakety. Alternativně může také být použito tvarování provozu, kdy se nevyhovující pakety uloží do paměti a v době, kdy není co posílat, jsou odeslány (více viz kap. 3.2.6). Tab. 5 – Hodnoty DSCP pro AF dle RFC 2597 Třída PHB AF4
AF3
AF2
AF1
Pravděpodobnost zahození Nízká Střední Velká Nízká Střední Velká Nízká Střední Velká Nízká Střední Velká
Podtřída PHB AF41 AF42 AF43 AF31 AF32 AF33 AF21 AF22 AF23 AF11 AF12 AF13
21
DSCP 100010 100100 100110 011010 011100 011110 010010 010100 010110 001010 001100 001110
Standard RFC 2597 nespecifikuje pro který druh služby jaké PHB je vhodné použit. Podle standardu mezi AF1, AF2 a AF3 zpravidla není prioritní rozlišení. Toto rozlišení se vztahuje na podtřídy AFx1, AFx2 a AFx3. Nicméně AF poskytuje mechanismy s kterými můžeme provádět návrh např. DiffServ služeb. Jeden příklad je uveden v normě RFC 2597 jako “Olympic model”, kde jsou pakety klasifikovány do tří tříd služeb (Gold, Silver, Bronz) využité pro tři ze čtyřech AF profilů (AF3, AF2, AF1). Tento příklad využívá tři třídy AF označené dle olympijských medailí. Pro třídu AF4 může být použit pojem Platinum. Každý stupeň třídy AF definuje určitou kvalitu a kvantitu přidělených prostředků, rozdělenou mezi třídami. Jako příklad můžeme uvést např. šířku pásma, velikost bufferu apod. Stejně jako u EF, potřebujeme jednotlivé datové toky rozřadit do tříd AF již na okraji DS domény. Přidělení síťových prostředků jednotlivým třídám v DS doméně se provádí manuálně. Na rozdíl od EF, většina datového toku AF je tvořena aplikacemi nepracujícími v reálném čase, které používají TCP protokol a proto umožňují řízení provozu pomocí algoritmu RED, který je pro AF použitelný. Čtyři třídy AF PHP mohou být implementované jako čtyři individuální fronty. Šířka pásma výstupního portu je pak rozdělena mezi čtyři fronty AF. Uvnitř každé AF fronty jsou pakety označeny určitou “barvou”, která označuje pravděpodobnost zahození paketu.
3.2.4 Měřič - Meter Pro každou třídu změří měřič [4] datový tok od zákazníka a změřené hodnoty zkonfrontuje s jeho datovým profilem. Datovým profilem rozumíme dohodnuté podmínky mezi zákazníkem a poskytovatelem. Ty pakety, které odpovídají danému profilu mohou vstoupit do sítě, zatímco ty, které neodpovídají jsou podmíněné podle TCS (Transparent Cache Switching). Akce, které mohou být provedeny jsou tvarování, přeznačení a zahození těchto paketů. Datové profily jsou typicky popisované v rámci definovaných token bucket parametrů. Většina měřičů je implementovaná jako token bucket. Token bucket je vysvětleno v kapitole 3.2.4.1.
22
3.2.4.1
Token bucket
r - rychlost doplňování tokenů Token bucket
b – velikost nádoby
pakety, jejichž odchod byl povolen tokeny
přicházející pakety
zahozené pakety Obr. 7 - Token bucket Token bucket je nejvíce využívaným mechanismem pro řízení toku dat. Tato technologie slouží k vyrovnávání různě velkého objemu dat přicházející nepravidelnými rychlostmi na vstupní porty směrovače tak, aby nemohlo dojít k překročení výstupní kapacity linky, tj. k jejímu zahlcení. Metoda token bucket patří do komponentu měření a může být použita pro ovlivnění značkování nebo rozhodnutí o zahození, předávání či pozdržení paketu ve vyrovnávací paměti. Token bucket si můžeme představit jako nádobu, která obsahuje v každém okamžiku určitý počet tokenů. Každý z nich je povolením k odeslání určitého objemu dat. Na počátku je nádoba plná. Po příchodu paketu se ověří, zda počet tokenů v nádobě alespoň odpovídá velikosti paketu. Pokud ano, je paket zařazen do fronty a odeslán na výstupní port, nebo může být příslušným způsobem označen. Zároveň je z nádoby odebrán určitý počet tokenů, který odpovídá velikosti paketu. Pokud v nádobě není dostatečný počet tokenů, paket může být zahozen, uložen do vyrovnávací paměti, kde bude pozdržen do doby, než se nádoba naplní dostatečným počtem tokenů, nebo označen jiným způsobem. Tokeny jsou do nádoby plynule doplňovány stálou rychlostí, dokud není nádoba plná. Token bucket lze tedy popsat dvěma parametry: rychlostí doplňování tokenů r a velikostí nádoby b. Největší povolený shluk přicházejících paketů tedy odpovídá hloubce token bucketu b a dlouhodobá průměrná rychlost zpracování příchozích dat odpovídá rychlosti doplňování tokenů do nádoby r. Dlouhodobý průměr rychlosti přicházejících dat tedy nesmí překročit rychlost doplňování tokenů a krátkodobé špičky nesmí překročit velikost nádoby, jinak může dojít k zahození paketů nebo jiné odpovídající akci.
23
3.2.5 Přeznačení - Remarker Přeznačení [4] provádíme u těch paketů, které již předtím byly označené. Označení paketů můžeme provádět v různých částech sítě. Pokud zákazník sítě podporuje diffserv značení, poté pakety mohou být značené jeho přepínačem nebo směrovačem. Poskytovatel připojení pak provádí přeznačení takto označených paketů. Přeznačení je také akce, které můžeme použít při paketech nesplňujících předem sjednané limity. Pakety mohou projít mnoha různými doménami, pakety které byly předtím označeny mohou být přeznačeny. Když tok paketů poruší datové profily v nějaké správní hranici, poté mohou být pakety přeznačeny k různým DSCP. Přeznačení je také nezbytné na rozhraní dvou administrativních domén, které využívají různé DSCP. DSCP musí být také přeložen, když paket přechází přes hranici domény.
3.2.6 Tvarovač – Shaper Tvarovač [4] má za úkol přenést datový tok do souladu se sjednaným datovým profilem. Rozdíl mezi tvarovačem a značkovačem je v tom, že značkovač jednoduše označí paket a nechá je projít do sítě. Zatímco tvarovač zabrání paketům projít sítí do té doby, dokud se datový tok nepřizpůsobí danému profilu. Tvarování je méně náročná forma zacházení s pakety než značení. Pro nějaké služby je přísná přijímací kontrola nezbytná. Tvarování také může být potřebné v hraničním uzlu mezi dvě diffserv domény. Koncový uzel může potřebovat upravit odcházející datový tok, tak aby odpovídal sjednanému datovému profilu pro další doménu. Tvarovací modul má konečnou velikost vyrovnávací paměti a proto může korigovat pouze krátkodobé překročení sjednaných parametrů.
3.2.7 Zahození - Dropper Zahození [4] je další možná akce, kterou můžeme použít na pakety, které nesplňují sjednaný datový profil. Ve srovnání s tvarováním, kde tvarovač musí mít vyrovnávací paměť, je zahození jednodušší.
24
4 Opnet Modeler 4.1 Úvod – základní charakteristiky simulátoru Opnet Modeler Program OPNET Modeler (OM) je simulační program, který slouží pro návrh, simulaci
a
analýzu
sítí.
Tento
program
dokáže
modelovat
velmi
rozsáhlé
sítě
s vynikajícími vlastnostmi. Hlavní výhodou programu je jeho efektivnost a výkonnost. OPNET Modeler vyvinula firma OPNET Technologies Inc. Program umožňuje modelovat a zároveň simulovat jakékoliv architektury sítí. Základním kamenem OM je jeho grafické prostředí, díky kterému je práce v něm efektivnější a rychlejší. Velmi důležitou vlastností OM je široká možnost tvorby různých statistik z dané simulace. Tato vlastnost nabádá k použití OM všude tam, kde je třeba ověřit chování reálného objektu v různých extrémních podmínkách (např. chování serveru při vysoké zátěži apod.). S tím i souvisí, že někdy nemůžeme na reálnému objektu ověřit chování, které ani nemusí nastat, ale díky OM si jej můžeme nasimulovat, abychom znali výsledek chování reálného objektu v určité situaci a mohli díky této znalosti předcházet určitým popř. nežádoucím stavům. Výsledek určité statistiky můžeme generovat do zprávy ve formátech XML (Extensible Markup Language) nebo HTML (Hyper Text Markup Language), nebo uložit data do tabulek. Opačně aplikace umí z těchto formátů načíst vstupní data. Dále OM obsahuje prohlížeč animací, díky kterému můžeme názorně vidět průběh proběhlé simulace. Simulace probíhá s určitým zrychlením, takže je možné nasimulovat měsíční chování sítě v řádu hodin. Největší výhoda OM tkví v jeho objemných knihovnách, které mají dostupný zdrojový kód, z čehož plyne, že kód můžeme dále upravovat.
4.2 Základní prvky OPNET Modeler Opnet Modeler má několik základních prvků a to: •
subnet – podsíť (spojené stanice, servery, huby, switche apod.)
•
node model – model uzlu (model stanice, serveru, hubu, switche apod.)
•
process model – model procesu zde jsou definovány jednotlivé procesy modelu uzlu (např. vysílání řídících informací apod.)
Podrobnější informace o jednotlivých prvcích jsou uvedeny v kapitole 4.3.
25
4.3 Editory OM
využívá
objektově
orientovaného
programování
a
grafických
editorů
s aktuálními strukturami sítí. OM je “jednoduchý“ hierarchický editor, který přesně popisuje spojení struktur reálné sítě a protokolů. OM je tvořen z třech základních editorů:
4.3.1
•
Project Editor – editor projektu viz kap. 4.3.1,
•
Node Editor – editor uzlu viz kap. 4.3.2,
•
Process Editor – editor procesu viz kap. 4.3.3.
Editor projektu (Project Editor) Editor projektu je grafický editor modelující topologii a komunikaci v síti. Síť
obsahuje uzly (node) a odkazy na objekty konfigurovatelné přes dialogový box. Drag and drop funkce (táhni a pusť) editoru slouží k sestavení sítě. Dále je možné použití objektů z knihovny OM (Model Libary), nebo si vytvořit vlastní uzly a modely. Editor projektu má v sobě mapu, na které názorně představuje fyzické rozložení sítě. Editor projektu je zobrazen na Obr. 8.
Obr. 8 - Síťový model v editoru projektu
26
4.3.1.1
Editor projektu - pracovní plocha
V okně editoru projektu, viz Obr. 8 je několik oblastí, které jsou důležité pro výstavbu a provedení modelu: •
hlavní menu,
•
tlačítka,
•
textová oblast,
•
tipy.
Hlavní menu - Každý editor má hlavní menu. Hlavní menu editoru projektu ukazuje názorné rozložení jednotlivých nabídek, viz Obr. 9.
Obr. 9 - Hlavní menu editoru projektu Tlačítka - Pod hlavním menu se nacházejí tlačítka, neboli buttons. Díky nim můžeme rychle aktivovat vybrané funkce editoru. Obr. 10 ukazuje rozložení tlačítek pro editor projektu.
Obr. 10 - Tlačítka projektového editoru Vysvětlení tlačítek: 1.
otevřít paletu objektů,
2.
ověřit shody odkazu,
3.
chybně vybraný objekt,
4.
odebrat vybraný objekt,
5.
zpět k rodičovské podsíti,
6.
zvětšit náhled,
7.
zmenšit náhled,
8.
konfigurovat jednotlivé události simulace,
9.
ukázat výsledek simulace,
10. ukázat základní webové zprávy, 11. skrýt nebo zobrazit grafy.
27
Textová oblast - Je umístěna dole v okně modeleru. Zprostředkovává informace o stavu provedené akce. Dále se tato ikona
využívá pro zjištění poslední provedené operace,
viz Obr. 11.
Obr. 11 – Textová oblast editoru projektu
Tipy - Pokud najedete kursorem na tlačítka nebo na položky menu, zobrazí se Vám bublina s kontextovou nápovědou, viz Obr. 12.
Obr. 12 – Zobrazení tipů v editoru projektu
4.3.2 Editor uzlu (Node Editor) Editor uzlu představuje rozhraní nižší úrovně než editor projektu. Ukazuje např. architekturu síťového zařízení nebo systému a vzájemné vztahy mezi funkčními moduly a volanými funkcemi. Uzel se skládá z modulů. Moduly typicky představují aplikace, protokolové vrstvy, algoritmy a fyzické prostředky takové jako jsou buffery, porty a sběrnice. Každý modul může generovat, posílat a přijímat pakety od ostatních modulů uvnitř celého uzlu. Dále je možné komunikovat mezi uzly i jinak než pomocí znázorněných vazeb (viz Obr. 13). Komunikaci mezi uzly jinak, než klasicky, zajistíme pomocí signálu zasílaného přímo konkrétnímu uzlu (procesu). Z vlastnosti OM vyplívá, že prvky všech úrovní jsou řazeny do stromové struktury celého modelu. Proto pokud chci poslat zprávu nějakému procesu, s kterým nejsem přímo propojen a znám jeho jméno, zjistím si ID rodičovského prvku a díky němu pak zjistím ID prvku, kterému pak zprávu pošlu. Další důležitou vlastností, která je užívaná v OM, je předávání hodnot atributů do vyšších úrovní. Díky této vlastnosti mohu klíčové parametry simulace, zobrazit u objektů nejvyšší úrovně a není nutné složitě "proklikávat" k objektu, kterého se daný parametr konkrétně týká (např. IP adresy definované na procesním modelu popisujícím proces IP vrstvy) [16].
28
Obr. 13 – Editor uzlu – model pracovní stanice
4.3.3 Editor procesu (Process Editor) Editor procesu je rozhraní nejnižší úrovně. Slouží pro tvorbu konečného stavového automatu (FSM - Finite State Machines) přizpůsobeného snaze specifikovat všechny úrovně modelu do detailu (protokolu, prostředku aplikaci a algoritmu). Stavy a přechody jsou definovány v grafickém diagramu, viz Obr. 14. Každý stav a proces modelu obsahuje kód v C/C++ podporovaný rozsáhlou knihovnou s funkcemi vytvořenými pro protokolové programování.
Obr. 14 – Editor procesu
29
4.3.3.1
Editor procesu – základní pravidla
Zde jsou uvedeny základní pojmy, které jsou potřebné k práci v proces editoru. Jedná se hlavně o pojmy stav a přechod. Jak vypadá okno editoru procesu je možné vidět na Obr. 15. Hlavní prvky, editoru procesu jsou: •
Stav (state) - představuje stav procesu. Proces může být např. ve stavu čekání na zprávu od vysílače.
•
Přechod (transition) - je změna stavu v odpovědi na událost.
OM vždy přidává do každého stavového automatu fragment kódu C/C++. Máme 3 základní místa, kam můžeme vložit C/C++ kód v reprezentaci stavu. A to: •
Vstupní
pozice
(Enter
Executive)
-
kód,
který
je
vykonán
ihned
po přechodu do nového stavu procesu. •
Výstupní pozice (Exit Executive) - kód, který je proveden když proces opouští stav při přechodu do jiného stavu.
•
Přechodová pozice (Transition Executive) - kód, který je proveden v odpovědi na specifickou událost.
V prvních dvou případech je kód vykonán nezávisle na typu události, ale v posledním případě pouze při výskytu specifické události.
Obr. 15 – Editor procesu – vstupní a výstupní pozice
30
Dále definujeme typ stavu procesu. Ten může být dvojího typu: •
Vynucený (Forced) [v OM - zelený] - při přechodu procesu do tohoto stavu se vykoná kód, který tento stav obsahuje, a automaticky dojde k přechodu do dalšího stavu.
•
Nevynucený (Unforced) [v OM - červený] - po přechodu do tohoto stavu v něm proces zůstává tak dlouho, dokud nedojde k další události. Každá událost je definována přerušením.
Obr. 16 – Editor procesu – vynucený a nevynucený stav Dále definujeme přechod procesu. Ten může být taktéž dvojího typu: •
Podmíněný (Conditional) - je stanovena podmínka, která určuje pravidla přechodu do nového stavu, je-li splněna, uskuteční se přechod do dalšího stavu.
•
Nepodmínění (Unconditional) - stav přechází okamžitě do dalšího stavu.
5 Modelování chování páteřních směrovačů DiffServ domény 5.1 Úvod
Modelování chování páteřních směrovačů DiffServ domény (zajištění QoS) bude vysvětleno v projektu, kde vytvořím několik různých aplikací jako např. http, ftp či VoIP. Těmto aplikacím bude na okrajových směrovačích přisouzena určitá DSCP značka a na páteřních směrovačích bude dle těchto značek provedeno řazení do front. Výsledkem simulace budou statistiky, které potvrdí nastavení a teoretické předpoklady. Dále bude provedeno porovnání výsledků dvou scénářů s tím, že jeden bude mít v páteřní síti vložen provoz v pozadí a druhý nikoliv. Výsledkem této simulace bude dokázat, jak ovlivní vložený provoz vlastnosti (zpoždění, využití bufferu apod.) páteřní linky.
31
5.2 Vzorová síť
Vzorová síť obsahuje 3 podsítě, které představují určité rozložení klientů, přepínačů, směrovačů a serverů. Každá podsíť může obsahovat tyto objekty: •
LAN Client – jde o objekt, díky němuž můžeme definovat více stanic se stejnými vlastnostmi. Příklad je uveden na Obr. 17.
Obr. 17 – Vzorový příklad pro LAN Client Jednotlivé pracovní stanice v LAN Clientu bude podporovat tyto aplikace
o
HTTP
-
Zde
bude
provozován
klient
služby
http.
Půjde
tedy
o “brouzdaní” po internetu. o
Intranet - Zde bude provozován klient služby intranet.
o
FTP - Zde bude provozován klient aplikace ftp. Bude proveden upload a download souborů ze serveru.
o
Voice - Půjde o telefonování pomocí VoIP klienta.
o
Other – Ostatní aplikace.
•
Workstation – Tento objekt představuje jedinou pracovní stanici.
•
Switch – Pro připojení jednotlivých klientů.
•
Router – Pro spojení jednotlivých podsítí.
•
Server – Poskytuje serverové služby pro dané aplikace (HTTP, FTP, Voice, Other).
Výsledný vzorový příklad modelu síťových aplikací je možné vidět na Obr. 19.
32
5.3 Obecný návrh vzorové sítě
Nejdříve si v OM vytvoříme nový projekt a na jeho plochu umístíme tyto objekty: •
Application Config,
•
Profile Config,
•
QoS Attribute Config.
Objekty vložíme na plochu po kliknutí na ikonu
Object Palette - Configure
Palette a vybereme položku internet_toolbox. Poté co máme na ploše konfigurační objekty vložíme na plochu modely: •
ethernet_server – model serveru (server),
•
ethernet16_switch – model přepínače (switch),
•
ethernet4_slip8_gtwy – model směrovače (router),
•
ethernet_wkstn – model klienta – počítačové stanice (workstation).
Po té tyto objekty, propojíme síťovou technologií 100BaseT a to objektem z položky Object Palette - 100BaseT. Nyní je konfigurace sítě hotova. Výsledná síť je zobrazena na Obr. 18 a na Obr. 19 je zobrazena tatáž síť vytvořená v OM.
Obr. 18 – Model diffserv domény
33
Obr. 19 – Model diffserv domény vytvořený v OM
5.4 Nastavení aplikací Každá aplikace je v OM tvořena dvěma objekty a to: •
Application Config – uvedení aplikací, které se budou v síti provozovat, čili definice aplikací, viz kap. 5.4.1.
•
Profile Config – aplikacím se zde přiřadí hodnoty, dle kterých např. aplikace budou spouštěny apod., viz kap. 5.4.2.
5.4.1 Application Config – Definice aplikací Pro definici aplikací se v OM používá objekt Application Config, který jsme si již umístili na plochu. Tento objekt je zobrazen na Obr. 20.
Obr. 20 – Objekt Application Config Abychom mohli editovat jednotlivé aplikace, musíme kliknout pravým tlačítkem na objekt Application Config a z kontextového menu zvolit Edit Attributes. Dále budeme
34
editovat položku s názvem Application Definitions. Zde se zobrazí položka rows, která udává maximální počet námi definovaných aplikací. V položce name definujeme jméno aplikace. Jméno by mělo co nejlépe vystihovat danou aplikaci. Můžeme mít např. více FTP aplikací, proto vytvořenou aplikaci pojmenujeme např. FTP High Load. Abychom mohli definovat podrobnější chování aplikace klikneme na položku description. Pro standardní aplikace jako FTP, HTTP, E-mail apod. jsou již předdefinované hodnoty jako např. Low Load, Medium Load a High Load. Při výběru provozovaných aplikací máme na výběr z těchto možností: •
Custom – vytvoření vlastní aplikace,
•
Database,
•
Email,
•
FTP,
•
HTTP,
•
Print,
•
Remote Login,
•
Video Conferencing,
•
Voice.
Tyto aplikace mají určité předdefinované hodnoty. Ty jsou více rozebrány v kap. 5.4.1.1.
Obr. 21 – Příklad nastavení ftp aplikace V dalších kapitolách bude rozebrána nabídka předdefinovaných hodnot a také vytvoření vlastních hodnot, čili specifické nastavení aplikace. V této práci budou provozovány aplikace dle kap. 5.2. Nastavené aplikace v OM pro tento projekt jsou zobrazeny na Obr. 22.
35
Obr. 22 – Nastavené aplikace provozované v projektu
5.4.1.1
Application Config – Předdefinované hodnoty
Pokud nebudeme chtít tvořit jedinečné aplikace, můžeme použít předdefinované hodnoty aplikací. OM má 16 předdefinovaných aplikací. Jsou to: •
Database Access (Heavy),
•
Database Access (Light),
•
E-Mail (Heavy),
•
E-mail (Light),
•
File Transfer(Heavy),
•
File Transfer (Light),
•
File Print (Heavy),
•
File Print (Light),
•
Telnet Session (Heavy),
•
Telnet Session (Light),
•
Video Conferencing (Heavy),
•
Video Conferencing (Light),
•
Voice over IP Call (PCM Quality),
•
Voice over IP Call (GSM Quality),
•
Web Browning (Heavy HTTP 1.1),
•
Web Browning (Light HTTP 1.1).
36
U každé předdefinované aplikace lze samozřejmě editovat její charakteristické hodnoty. V dalším textu bude u 3 základních aplikací (e-mail, FTP, HTTP) podrobněji rozebráno editování charakteristických hodnot. E-mail – tato aplikace dovoluje nastavit následují hodnoty: •
Send Interarrival Time (seconds) – čas mezi dvěma poslanými emaily,
•
Send Group Size – počet emailů ve skupině před odesláním,
•
Receive Interarrival Time (seconds) - čas mezi dvěma přijatými emaily,
•
Receive Group Size - počet emailů ve skupině před přijmutím,
•
E-mail Size (bytes) – průměrná velikost emailu,
•
Symbolic Server Name – symbolické jméno serveru s kterým klient komunikuje,
•
Type of Service – parametr QoS, kterým se určuje priorita provozovaných aplikací (v případě projektu není nastaven, protože je využit jiný způsob řízení QoS),
•
RSVP Parameters – parametr pro rezervování šířky pásma,
FTP - tato aplikace dovoluje nastavit následují hodnoty: •
Command Mix (Get/Total) – poměr mezi příkazy pro download a všemi příkazy,
•
Inter-Request Time (seconds) – doba, mezi dvěma žádostmi,
•
File size (bytes) – průměrná velikost souboru,
•
Symbolic Server Name - symbolické jméno serveru s kterým klient komunikuje,
•
Type of Service - parametr QoS, kterým se určuje priorita provozovaných aplikací (v případě projektu není nastaven, protože je využit jiný způsob řízení QoS),
•
RSVP Parameters - parametr pro rezervování šířky pásma,
HTTP - tato aplikace dovoluje nastavit následují hodnoty: •
HTTP Specification > o
HTTP Version – jméno podporované verze protokolu HTTP,
o
Max Connections – maximální počet HTTP připojení na server,
o
Max Idle Period (seconds) – maximální doba otálení po spojení,
37
o
Pipeline Buffer Size (requests) – maximální počet žádostí, které můžou být společně “buffrovány“ jednou aplikací,
o
Page Interarrival Time (seconds) – doba mezi dvěma staženými stránkami,
•
•
Page Properties > o
Object size (bytes/object) – průměrná velikost objektu,
o
Number of Objects (objects/page) – počet objektů na stránce,
o
Location – symbolické jméno serveru, kde je objekt uložen,
Type of Service – parametr QoS, kterým se určuje priorita provozovaných aplikací (v případě projektu není nastaven, protože je využit jiný způsob řízení QoS),
•
RSVP Parameters – parametr pro rezervování šířky pásma.
5.4.2 Profile Config – Profil aplikace Pro definici profilu aplikace se používá objekt Profile Config. Ten už máme také na ploše. Tento objekt je zobrazen na Obr. 23.
Obr. 23 – Objekt Profile Config Opět přes položku Edit Attributes se dostaneme hlouběji do menu. Zde zvolíme položku rows, která nám nyní udává počet profilů. Důležité je, že počet profilů se nemusí rovnat počtu aplikací. Je tudíž možno, aby jeden profil měl v sobě více aplikací. Po zadání rows např. 1 se ukáží další položky, které platí pro námi vytvořený profil. Položky tohoto menu jsou: •
Profile Name – jméno profilu,
•
Application – zde vložíme aplikaci, kterou jsme vytvořili v objektu Application config: o
Rows – počet aplikací, které se budou spouštět s tímto profilem,
o
Name – jméno aplikace, které jsme vytvořili v objektu Application config,
38
o
Start Time Offset (seconds) – zde nastavíme čas kdy se daná aplikace spustí. Když nastavíme např. hodnotu 0, tak aplikace se bude spouštět ihned po začátku profilu. Tedy tento parametr závisí také na volbě Start Time profilu,
o
Duration – doba trvání dané aplikace,
o
Reapeatability – udává počet opakování a časový odstup k dalšímu zopakování,
•
Operation Mode - definuje jak se budou dané aplikace spouštět: o
Serial (Ordered - spořádaný) - může být spuštěna nejdříve jedna pak další aplikace, pořadí je přesně dáno pozicí aplikace v seznamu,
o
Serial (Random - náhodný) - může být spuštěna nejdříve jedna pak další aplikace, pořadí je náhodně určené,
o
Simultaneous - všechny aplikace startují ve stejný čas,
•
Start Time (sec) – definuje, kdy bude profil spuštěn,
•
Duration (sec) - definuje dobu trvání profilu,
•
Reapeatability - udává se zde počet opakování a časový odstup k dalšímu zopakování.
U položky Start Time Offset je možné nastavit buď, aby aplikace začínala v přesně stanovený okamžik volbou typu constant, nebo např. start v určitém časovém rozmezí, které je vyjádřené pravděpodobnostní funkcí. Samozřejmě je zde velké množství nastavení položky Start Time Offset – Distribution name např. (poisson, geomteric, lognormal, bernoulli atd.). Rovnoměrné rozložení pravděpodobnosti, které je využívané v simulačním modelu, je nastaveno funkcí Distribution name = uniform.
5.5 Nastavení aplikací na klientech a serverech
Pokud máme již nastavené definice a profily aplikací můžeme přejít k nastavení aplikací na klientech popř. serverech. Přejdeme tedy k editaci atributů klienta kliknutím na klienta a pravým tlačítkem vyvoláme menu, kde zvolíme položku Edit Attribites. Zde rozklikneme položku Application: Supported Profiles. Přidáme požadovaný počet položek v rows a zvolíme námi předem vytvořený profil aplikace.
39
Obr. 24 – Příklad nastavení aplikace FTP na klientu FTP V položce Application: Destination Preference můžeme definovat, s jakým objektem v síti bude tento klient komunikovat. Tato položka je podrobněji vysvětlena v kap. 5.5.2.
5.5.1 Nastavení serveru pro podporu aplikací Objekt server máme již vložený na pracovní ploše. Budeme editovat jeho atributy a
to
položku
Application:
Destination
Preference
a
Application:
Services.
U poslední položky vložíme do Name jméno naší podporované služby (FTP) a pole Description field nastavíme na Supported čili (podporováno) viz Obr. 25.
Obr. 25 – Příklad nastavení podporovaných služeb na serveru FTP Nyní je konfigurace serveru pro podporu aplikací hotova a obdobným způsobem se provede i konfigurace serverů pro služby http apod.
40
5.5.2 Nastavení spojení klient – server Toto nastavení je důležité pokud chceme nastavit konkrétní spojení mezi serverem a klientem (popř. lze použít i pro nastavení komunikace klient – klient). Pokud toto nastavení neprovedeme, OM zvolí náhodně vybraný server a klienta v síti a provede na nich zvolené procesy. Proto tedy pokud chceme, aby určitý klient pracoval s určitým serverem musíme mu nastavit atribut Application: Destination Preference. Ten umožňuje mapovat symbolické jméno serveru na aktuální jméno serveru. Jelikož každá aplikace používá symbolické jméno k odvolání se na určitý server. Server může zároveň mapovat více symbolických jmen. Proto pro výběr serveru je zde položka Selection Weight. Hodnota této položky řídí pravděpodobnost výběru serveru. Hodnota Server address identifikuje server podle jména, tato hodnota musí být pro každý server unikátní. Jestliže nespecifikujeme
žádný
cílový
server,
bude
vybrán
náhodný
server
podporující
požadovanou aplikaci. Přidělíme unikátní jméno pro server nebo klienta nastavením jeho TPAL adresy. Tato adresa se přiřazuje editováním atributu pro server Server address, pro klienta Client address a LAN Server name pro LAN.
5.5.2.1
Příklad nastavení spojení klient – server
Nyní jednoduchý příklad jak nastavit spojeni klient – server. Jelikož podrobně vysvětlený popis, jak nastavit aplikace a vytvoření jednoduché sítě je vysvětleno výše, bude zde popsán jenom problém spojení klient – server. Další potřebnosti budou uvedeny později. Vytvoříme nyní nový projekt a na plochu umístíme dva objekty typu LAN Client. Každý LAN Client obsahuje 10 PC. Dále vložíme na plochu dva objekty typu server a jeden objekt typu směrovač. Aplikace, která bude v sítí provozována je HTTP. Vytvořenou síť je možné vidět na Obr. 26.
41
Obr. 26 – Spojení klient – server – příkladová síť V této sítí se budeme snažit, aby sk1 (skupina stanic 1) a sk2 (skupina stanic 2) komunikovala s objektem server1 a objekt server2 nebyl využíván. To zajistíme nastavením atributu Application: Destination Preference. Nejprve, ale musíme nastavit hodnoty Server Address na jednotlivých serverech. To nastavíme pomocí položky Edit Attributes - Server Address. Pro náš případ je hodnota server1 nastavena na adNode3 a pro server2 na adNode4. Příklad nastavení unikátní adresy je na Obr. 27.
Obr. 27 – Příklad nastavení unikátní adresy serveru Nyní můžeme kliknout pravým tlačítkem myši na objekt sk1 (skupina stanic 1 – LAN Klient)
a vybereme položku Edit Attributes. Zde zvolíme položku Application:
Destination Preference a díky této volbě budeme moci editovat položky: •
Application – vybereme aplikaci, kterou chceme provozovat na sk1 (skupina stanic 1). V našem případě je to aplikace http.
•
Symbolic Name – zde vložíme symbolické jméno serveru, např. HTTP Server.
42
•
Actual Name – zde zvolíme položku Edit a tím se dostaneme do dalšího menu o
Name – zde vložíme adresu serveru, s kterým náš klient bude pracovat. V našem případě tedy adNode3.
o
Selection Weight – zvolíme hodnotu, např. 10.
Příklad tohoto nastavení je zobrazen na Obr. 28.
Obr. 28 – Příklad nastavení Application: Destination Preference Toto samé nastavení provedeme i pro objekt sk2. Dále je nutné vybrat na objektu serveru statistiky, které budeme sledovat. Vybereme proto pro každý server položkou Choose Individulal DES Statistic statistku Server HTTP. Nyní můžeme celý projekt odsimulovat. v hlavní nabídce DES nebo kliknutím na ikonu
To provedeme tlačítkem Run
. Poté co proběhla simulace můžeme se
podívat na její výsledky. Ty pro každý server zobrazíme položkou View Result. Naměřené hodnoty – grafy jsou zobrazeny v Příloze 1 na Obr. 37. Výsledek simulace dokazuje, že klienti ze sk1 a sk2 komunikovali pouze s objektem server1. Drobný přenos dat má i objekt server2, ale to je dáno pouze dotazy na server. Celkové zhodnocení zní, že se nám povedlo spojit určené klienty s určeným serverem.
5.6 Nastavení páteřního směrovače pro podporu kvality služeb V této části textu bude rozebráno nastavení páteřního směrovače, na kterém se bude
provádět
řazení
do
front
již
označených
paketů,
které
budou
přicházet
od hraničních směrovačů. Nastavení kvality služeb, které bude potřeba provést, se v OM provádí pomocí objektu
43
•
QoS Attribute Config – konfigurace požadovaného mechanismu pro zajištění kvality služeb, viz kap. 5.6.1.
5.6.1 QoS Atrribute Config Pro definování globálních parametrů kvality služeb slouží v OM objekt QoS Attribute Config. Ten je zobrazen na Obr. 29.
Obr. 29 – Objekt QoS Attribute Config
Pro konfiguraci parametrů QoS klikneme pravým tlačítkem na tento objekt a vybereme položku Edit Attributes. Nyní máme možnost si vybrat, jaké mechanismy budeme pro zajištění QoS v síti používat. OM nám nabízí výběr z těchto modelů: •
CAR Profiles – využívá se pro klasifikaci a řízení šířky pásma, využívá CoS v hlavičce v IPv4,
•
Custom Queuing Profiles – uživatelsky definovaný způsob řízení fronty,
•
FIFO Profiles - řazení do front bez priorit (první přisel, první odejde),
•
MWRR/MDRR/DWRR Profiles –profily založené na principu Round-Robin,
•
Priority Queuing Profiles - řazení do prioritních front, všechny fronty jsou stejně velké,
•
RSVP Flow Specification, specifikace provozu dle RSVP FlowSpec,
•
RSVP Profiles – rezervace šířky pásma dle profilů RSVP, využívá se u technologie IntServ,
•
WFQ Profiles - řazení do front dle priorit, fronty jsou různě veliké a každá fronta má určitou svoji váhu.
Pro model diffserv domény je nejvhodnější použít mechanismus WFQ, proto dále bude podrobněji vysvětlen jen tento mechanismus, kap. 5.6.1.1.
44
5.6.1.1
WFQ Profile
Po rozkliknutí nabídky WFQ Profiles máme na výběr více typů front (dle čeho se naše fronty budou řídit). Přednastavené jsou tyto profily: •
ToS – třídění do front dle položky ToS v hlavičce IP paketu v4,
•
Protocol - třídění do front dle použitého protokolu,
•
Port - třídění do front dle použitého portu,
•
DSCP – třídění do front dle hodnot DSCP.
V našem modelu značkování provádí okrajové směrovače a přisuzují paketům určitou hodnotu DSCP, proto bude vhodné použít profil DSCP. Položka Queues Configuration slouží pro nastavení jednotlivých front. Je zde opět položka rows, která nám v tomto případě udává počet front, které budeme používat. Dále po rozkliknutí položky row0 můžeme nastavit tyto hodnoty: •
Weight – váha fronty – udává se pro každou frontu zvlášť. Tato hodnota odpovídá relativní velikosti šířky pásma přiřazené dané frontě. Větší hodnota udává vyšší šířku pásma a nižší zpoždění paktů ve frontě.
•
Maximum Queue Size [pkts] – udává maximální počet paketů ve frontě.
•
Classification Scheme: o
rows – zde udává počet kriterií (např. značek) přiřazené jedné frontě:
ToS – zařazení do fronty dle hodnoty ToS nebo DSCP, viz Obr. 30,
Protocol – zařazení do fronty dle protokolu,
Source Address - zařazení do fronty dle zdrojové adresy,
Destination Address - zařazení do fronty dle cílové adresy,
Source Port - zařazení do fronty dle zdrojového portu,
Destination Port - zařazení do fronty dle cílového portu,
Incoming Interface – zařazení do fronty dle příchozího rozhraní.
45
Obr. 30 – Příklad nastavení hodnoty DSCP •
•
RED Paramaters – nastavení parametrů RED/WRED, více o RED v kap. 5.6.2: o
RED Status,
o
Exponential Weight Factor,
o
Minimum Threshold,
o
Maximum Threshold,
o
Mark probability factor,
o
CE Marking.
Queue Category – tato hodnota udává, zda je použita fronta Default Queue, None nebo Low Latency Queue (fronta s nízkým zpožděním). Fronta s nízkým zpožděním představuje přesně dané priority ve WFQ mechanismu. Tuto frontu lze použít pouze jednou stejně jako frontu Default Queue. Datový tok, který vstupuje do fronty Low Latency Queue má nejvyšší prioritu. Když tato fronta je prázdná, mohou se odesílat data z jiných front. Příklad nastavení front používaných v simulačním modelu diffserv domény
zobrazuje Obr. 31 a Tab. 6.
46
Tab. 6 – Nastavení front v projektu diifserv domény Fronta v OM
Podtřída PHB
Váha
AF11
1
AF12
1
AF13
1
Q1 – ftp1
AF21
30
Q2 – ftp2
AF22
20
Q3 – ftp3
AF23
10
Q4 – intranet
AF31
40
Q5 – voip
EF
50
Q0 - default
Obr. 31 – Nastavení front v projektu domény diffserv v OM
5.6.2 Algoritmus RED (Random Early Detection) RED [17] nebo WRED jsou metody prevence zahlcení. Pokud bychom nechali fronty naplnit pakety a teprve potom začali zahazovat další příchozí pakety, mohlo by dojít k synchronizaci zahlcení mezi více směrovači a vytvoření vln střídajícího se zahlcení s okamžiky, kdy je snížen objem dat posílaných do sítě tak, že není využita kapacita linek. Příčinou tohoto jevu je chování protokolu TCP, kterým se dnes přenáší významná část všech dat v síti Internet. Pokud totiž protokol TCP na straně odesílatele detekuje ztrátu paketu, odešle ztracený paket znovu a zároveň sníží rychlost odesílání paketů k příjemci neboť předpokládá přetížení přenosové cesty a snížením rychlosti chce předejít dalším ztrátám paketů. Protože směrovačem obvykle prochází řada různých TCP spojení současně od různých odesílatelů, dojde při zahlcení směrovače ke snížení rychlosti
47
na řadě odesílatelů a tím i k následnému nevyužití kapacity výstupní linky směrovače. Jednotliví odesílatelé postupně obnoví původní rychlost přenos a dojde znovu k zahlcení směrovače. Tomuto jevu se snaží předejít metoda RED. Přesáhne-li naplnění fronty určitou mez,
začne
směrovač
zahazovat
pakety
z
náhodně
vybraných
TCP
spojení.
Pravděpodobnost zahození paketu se zvyšuje se zvyšujícím se naplněním fronty (Obr. 32). Tím dojde ke snížení objemu dat od některých odesílatelů a plynulému vyrovnání celkového objemu přicházejích dat s kapacitou odchozí linky. U modifikované metody WRED závisí pravděpodobnost zahození paketu též na značce paketu přidělené klasifikací. Limit naplnění fronty při jehož překročení může být paket zahozen je různý pro pakety s různými značkami (Obr. 33).
Obr. 32 – Pravděpodobnost zahození paketu pro algoritmus RED
Obr. 33 – Pravděpodobnost zahození paketu pro algoritmus WRED
5.6.3 Nastavení kvality služeb na směrovači Pro správnou funkci podpory QoS je nutné, aby na směrovači, který provádí klasifikaci, nebo řazení do front bylo nastaveno QoS Schema. Jelikož v předchozí kapitole, kap. 5.6.1.1, je vysvětleno nastavení front, bude zde vysvětlen pouze postup jak nastavit směrovač pro podporu již vytvořených front. Opět abychom mohli měnit vlastnosti objektu páteřního směrovače a zadat námi požadované údaje, zvolíme menu Edit Attributes – IP – IP QoS Parameters. Nyní
48
potřebujeme na určitý port směrovače nakonfigurovat námi vytvořený QoS schema (WFQ Profil). To provedeme kliknutím na položku Interface Information. Zde již provádíme konfiguraci parametrů: •
row – udává počet rozhraní na kterých budeme aplikovat QoS schema. •
Name – udává jméno rozhraní (portu). V OM většinou značeno IFxx. Pro zjištění aktuálního použitého portu slouží při označení linky položka Edit Ports.
•
QoS Schema: o
Type – specifikace typu profilu. V našem případě volíme WFQ Profile. Přednastavená hodnota je FIFO Profile. FIFO (First In - First Out).
o •
Name – jméno námi vytvořeného profilu. Volíme DSCP.
Subinterface Information – slouží pro rozdělení portu na sub-porty, např. u technologii ATM (Asynchronous Transfer Mode).
•
Buffer Size – velikost vyrovnávací paměti rozhraní. Přednastavená hodnota je 1MB.
•
Reserved Bandwidth Type – typ rezervované šířky pásma. Můžeme volit mezi relativní nebo absolutní velikostí.
•
Maximum Reserved Bandwidth – tato položka slouží, pokud v Reserved Bandwidth Type máme nastaveno “Relative” a udává maximální šířku rezervovaného pásma.
•
Hold Queue Capacity - speciální nastavení pro Cisco směrovače.
•
Interface
Transmit
Ring
Limit
–
tato
položka
není
v OM
zatím
podporována.
5.6.4 Nastavení provozu v pozadí na lince Jelikož budeme vytvářet dva scénáře, kde v jednom budeme chtít vložit na linku provoz v pozadí je nutné nejprve vytvořit dva scénáře. Pro tento případ nám poslouží příkaz, který vybereme z hlavní nabídky Scenarios – Duplicate Scenario… nebo můžete jen použít klávesovou zkratku Ctrl + Shift + D. Tímto příkazem jsme si vytvořili dva stejné scénáře. Je vhodné scénáře vždy pojmenovávat dle jejich charakteristických hodnot (např. no background traffic – backgroud traffic), to nám umožní lepší orientaci v modelu. Pro pohyb mezi scénáři slouží příkaz Scenarios – Switch To Scenario nebo opět můžete použít klávesovou zkratku Ctrl + <číslo scénáře>. Zjištění aktuálního scénáře je jednoduché, protože aktuální scénář je vždy vypsán v hlavičce okna, viz Obr. 34.
49
Obr. 34 – Zobrazení aktuálního scénáře Dalším krokem je ve scénáři, který jsme vytvořili a pojmenovali např. background traffic, přidat na páteřní síti provoz v pozadí. Pro tento úkon klikneme pravým tlačítkem myši na linku a vybere z menu Edit Attributes. Zde se nám již otevře známé okno. Najdeme položku Background Load – Intensity (bps)[1->2] a zvolíme položku Edit pro její editování. Náš profil pojmenujeme např. my_load a zvolíme hodnoty dle Obr. 35. Nakonfigurovali jsme provoz v pozadí o velikosti 1300kbit/s na dobu jedné hodiny. Dále vybereme položku Intensity (bps)[2->1] a zvolíme položku Select, díky které již vybereme jen námi vytvořený provoz my_load. Tento postup opakujeme na zbylé části páteřní sítě.
Obr. 35 – Nastavení provozu v pozadí na lince
5.7 Nastavení sledovaných parametrů – statistik Jde o nastavení výstupu simulace, čili zachycení nasimulovaných hodnot. Tyto hodnoty jsou zobrazovány v grafech, kde na ose x je vynášen čas a na ose y je vynášena měřená veličina. Abychom mohli zobrazit výsledek (určitý graf) musíme nejprve přes položku Choose Individual DES Statistic vybrat jednotlivé sledované parametry. Tyto parametry můžeme nastavovat dvěma způsoby: •
Globálně – pokud vybereme parametry v této sekci, budeme sledovat vybrané parametry na každém objektu v sítí.
50
•
Lokálně - pokud vybereme parametry v této sekci, budeme sledovat vybrané parametry jen na určitém objektu v sítí. Příklad jednotlivých nastavení i s ukázkami bude uveden v kap. 5.8.
5.8 Simulace Pokud již máme celou síť nastavenou (definované aplikace, profily aplikací, podporované profily na straně klientů a serveru a vybrané sledované parametry – statistiky), můžeme přejít k simulaci vytvořené sítě.
5.8.1 Nastavení a průběh simulace (jednoho scénáře) Pro nastavení parametrů simulace zvolíme v hlavní nabídce položku DES Configure/Run DES Event Simulation. Vždy jsou využity tyto hodnoty: •
Duration (sec) - doba, kterou chceme odsimulovat v síti. V našem případě nastavíme hodnotu 120 seconds.
•
Seed – inicializace generátoru náhodného čísla. Tato hodnota se mění v různých simulacích než dosáhne požadované statistické hodnoty ve výsledku.
•
Values per statistic – počet naměřených hodnot, které budou sloužit k vykreslení statistky tj. grafu. Čím větší zadáme tuto hodnotu, tím naše charakteristiky budou přesnější, ale simulace bude déle trvat a také výstupní soubor po simulaci bude větší. Proto vždy volíme kompromis mezi přesností a rychlostí simulace. Pro náš jednoduchý model postačí hodnota např. 200. Přednastavená hodnota je 100.
•
Update interval - při simulaci udává, jak často se bude měnit křivka počtu událostí probíhající simulace (viz Obr. 36). Zvolíme přednastavenou hodnotu 500 000 událostí.
Poté co již máme nastavené tyto parametry spustíme simulaci tlačítkem Run. Průběh simulace je zobrazen na Obr. 36. Na Obr. 36 je možné vidět čas od spuštění simulace (Elapsed Time) a odsimulovaný čas (Simulated Time) v modelu síti.
51
Obr. 36 – Průběh simulace
5.8.2 Nastavení a průběh simulace (více scénářů) Jelikož v projektu máme vytvořené dva scénáře využijeme odsimulování obou scénářů zároveň. Mohli bychom samozřejmě ručně odsimulovat oba scénáře dle kap. 5.8.1, ale možnost odsimulování více scénářů zároveň je určité ulehčení - zrychlení, proto je o této funkci zmíněno. Prvním důležitým krokem je výběr z menu Scenarios – Manage Scenarios. Po této volbě se nám otevře okno, kde nastavíme hodnoty pro oba scénáře zároveň. Oba scénáře necháme odsimulovat 120sec a do položky Result vložíme hodnotu collect, pro zahrnutí scénáře do simulace. Posledním krokem je kliknutí na tlačítko OK čím spustíme simulaci. Okno které se nám zobrazí je stejné jako na Obr. 36, s tím rozdílem, že proběhne dvakrát.
5.9 Výsledky simulace V této části textu budou shrnuty výsledky získané simulací. Cílem simulace bylo dokázat, že páteřní směrovače jsou nakonfigurovány pro podporu kvality služeb. Dále bylo za úkol nakonfigurovat páteřní směrovače tak, aby přijatý označkovaný datový tok byl správně řazen do front. Následně zde bude předveden rozdíl mezi scénářem, kdy v pozadí páteřní sítě bude probíhat určitý provoz a scénářem bez provozu v pozadí. Abychom mohli usuzovat jestli naše simulace proběhla správně je nutné mít k dispozici Tab 6., kde je uvedeno dle jaké hodnoty DSCP řadí provoz do front.
52
5.9.1 Výsledky simulace - zpoždění Jelikož máme fronty vloženy na výstupech páteřních směrovačů, budou v jednom grafu porovnány hodnoty z dvou výstupních portů. Obecně předpokládáme, že fronta s nejvyšší prioritou (v našem případě EF) bude mít nejnižší zpoždění v sítí. Dále také předpokládáme, že ve skupině AF2x, kde jsou provozovány tři nezávislé aplikace ftp, bude mít nejmenší zpoždění ta aplikace, která má nejvyšší hodnotu DSCP, tedy AF21. Výsledek této simulace je zobrazen na Obr. 38. Ze získaného grafu simulace je vidět, že naše teoretické předpoklady se potvrdily. Aplikace VoIP má nejnižší zpoždění, protože je provozována ve režimu EF. Dále také aplikace ftp1 (AF21 – nejvyšší priorita) ve skupině AF2x má nejnižší zpoždění ze všech tří ftp aplikací, což opět potvrdil naše teoretické předpoklady. Tyto charakteristiky také ukazují, že simulace se podařila a jednotlivé aplikace jsou rozřazeny do front správně.
5.9.2 Výsledky simulace – využití bufferu Obecné předpoklady jsou podobné jako u simulace zpoždění proto předpokládáme, že fronta s nejvyšší prioritou (v našem případě EF) bude mít nejnižší využití bufferu v sítí. Dále také předpokládáme, že ve skupině AF2x, kde jsou provozovány tři nezávislé aplikace ftp, bude mít nejmenší využití bufferu ta aplikace, která má nejvyšší hodnotu DSCP, tedy AF21 – ftp1. Výsledek této simulace je zobrazen na Obr. 39. Ze získaného grafu simulace je vidět, že naše teoretické předpoklady se potvrdily. Aplikace VoIP má nejnižší využití bufferu, protože je provozována ve režimu EF. Dále také aplikace ftp1 (AF21) ve skupině AF2x má nejmenší využití bufferu ze všech tří ftp aplikací, což opět potvrdil naše teoretické předpoklady.
5.9.3 Porovnání scénářů – zpoždění Zde jsme chtěli zjistit, jaký vliv na zpoždění bude mít vložení určitého provozu do páteřní sítě (1300kb/s). Toto zjištění nám může sloužit např. při rozhodování jestli můžeme do páteřní sítě připojit ještě nějaké další přístupové sítě, při zachování přijatelného zpoždění.
53
Výsledek této simulace je zobrazen na Obr. 40. K porovnání scénářů s provozem a bez provozu v pozadí, jsme vybrali pouze fronty aplikace ftp3, kde by měl být rozdíl obou zpoždění nejvyšší. Ze získaného grafu simulace je vidět, že naše teoretické předpoklady se potvrdily, čili zpoždění vzroste v důsledku vyššího využití linky.
5.9.4 Porovnání scénářů – využití bufferu Zde jsme chtěli zjistit, jaký vliv na využití bufferu bude mít vložení určitého provozu do páteřní sítě (1300kb/s). Výsledek této simulace je zobrazen na Obr. 41. K porovnání scénářů s provozem a bez provozu v pozadí jsme vybrali pouze fronty aplikace ftp3, kde by měl být rozdíl obou hodnot využití bufferu nejvyšší. Ze získaného grafu simulace je vidět, že naše teoretické předpoklady se potvrdily, čili využití bufferu vzroste v důsledku vyššího využití linky.
5.9.5 Porovnání scénářů – odeslaná data z fronty Q1 Zde jsme chtěli zjistit, jaký vliv bude mít vložení určitého provozu do páteřní sítě (1300kb/s) na počet odesílaných dat z fronty Q1. Frontu Q1 jsme opět vybrali záměrně, kvůli nevětšímu patrnému rozdílu. Výsledek této simulace je zobrazen na Obr. 42. K porovnání scénářů s provozem a bez provozu v pozadí jsme vybrali pouze fronty aplikace ftp1, kde by měl být rozdíl obou hodnot odeslaných dat nejvyšší. Ze získaného grafu simulace je vidět, že naše teoretické předpoklady se potvrdily, čili hodnota počtu odeslaných dat klesne u scénáře s provozem v pozadí v důsledku vyššího využití linky jiným provozem a upřednostněním aplikací s vyšší prioritou (VoIP).
54
6
Závěr Jedním z cílů této práce bylo získat potřebné znalosti v oblasti zajištění kvality
služeb a dále se blíže seznámit s technologií DiffServ a jejími základními bloky. Tuto část se podařilo úspěšně zvládnout a nejdůležitější poznatky jsou shrnuty v kap 1 - Kvalita služeb v IP sítích (QoS). Dalším úkolem této práce bylo změřit určitý datový tok v reálné síti a jednotlivé naměřené data rozřadit do patřičných tříd kvality služeb. Z naměřených hodnot můžeme říci, že v síti CZfreenet se nejvíce využívá aplikací ve třídě BE. Všechny další poznatky jsou shrnuty v kap 2 - Základní parametry přenosu. Ve třetím kroku je podrobněji rozebrán model IntServ a DiffServ. Nejdůležitější částí tohoto kroku bylo podrobné rozebrání mechanismu DiffServ a jeho základních částí. Po nabytí potřebných teoretických znalostí z oblasti zajištění kvality služeb, bylo hlavním cílem nasimulovat DiffServ doménu a zvláště pak chování páteřních směrovačů v prostředí OPNET Modeler. Jedním ze základních cílů v tomto kroku bylo podrobně se seznámit se základními editory prostředí OPNET Modeler s následným prozkoumáním, modelování síťových aplikací a nastavením páteřních směrovačů. Výsledky této práce jsou shrnuty v kap 5.9 – Výsledky simulace. Celkově lze říci, že simulace se v každé části povedla, protože se nám potvrdili teoretické předpoklady.
55
56
0
100000
200000
300000
400000
500000
600000
700000
800000
900000
0
20
60
80
100 time [s]
120
140
160
Obr. 37 – Zatížení serveru 1 a serveru 2 pro projekt klient – server
server2.Server Http.Traffic Received (bytes/sec) <Web Browsing (Heavy HTTP1.1)>.none
server2.Server Http.Traffic Sent (bytes/sec) <Web Browsing (Heavy HTTP1.1)>.none
server1.Server Http.Traffic Received (bytes/sec) <Web Browsing (Heavy HTTP1.1)>.none
server1.Server Http.Traffic Sent (bytes/sec) <Web Browsing (Heavy HTTP1.1)>.none
40
Zátížení serveru 1 a serveru 2
180
200
7 Přílohy
7.1 Výsledky naměřených hodnot
traffic sent [bytes/s]
Obr. 38 – Zpoždění ve frontách na páteřním směrovači 2
57
delay [sec]
0
0,002
0,004
0,006
0,008
0,01
0,012
0,014
0,016
0
20
time [sec]
60
80
core_router_2.IP Interface.WFQ Queuing Delay (sec) IF4 Q5.none
core_router_2.IP Interface.WFQ Queuing Delay (sec) IF4 Q4.none
core_router_2.IP Interface.WFQ Queuing Delay (sec) IF10 Q3.none
core_router_2.IP Interface.WFQ Queuing Delay (sec) IF10 Q2.none
core_router_2.IP Interface.WFQ Queuing Delay (sec) IF10 Q1.none
core_router_2.IP Interface.WFQ Queuing Delay (sec) IF4 Q0 (Default Queue).none
40
Zpoždení ve frontách na páteřním směrovači 2
100
120
Obr. 39 – Využití bufferu jednotlivými frontami na páteřním směrovači 2
58
Buffer Usage [bytes]
0
50
100
150
200
250
300
350
400
450
500
0
20
core_router_2.IP core_router_2.IP core_router_2.IP core_router_2.IP core_router_2.IP core_router_2.IP
40
Interface.WFQ Interface.WFQ Interface.WFQ Interface.WFQ Interface.WFQ Interface.WFQ
Buffer Buffer Buffer Buffer Buffer Buffer
Usage Usage Usage Usage Usage Usage
(bytes) (bytes) (bytes) (bytes) (bytes) (bytes)
Time [sec]
60
IF4 Q0 (Default Queue).none IF10 Q1.none IF10 Q2.none IF10 Q3.none IF4 Q4.none IF4 Q5.none
80
Využití bufferu jednotlivými frontami na páteřním směrovači 2
100
120
Obr. 40 – Zpoždění paketů na páteřním směrovači 1 s/bez provozu v pozadí na páteřní lince
59
delay [sec]
0
0,002
0,004
0,006
0,008
0,01
0,012
0,014
0
20
60
time [sec]
80
100
backroundTraffic: core_router_1.IP Interface.WFQ Queuing Delay (sec) IF11 Q3.none
noBackgroundTraffic: core_router_1.IP Interface.WFQ Queuing Delay (sec) IF11 Q3.none
40
Zpoždění paketů ve frontě Q3 na páteřním směrovači 1 (s provozem v pozadí na páteřní lince a bez provozu v pozadí)
120
Obr. 41 – Využití bufferu na páteřním směrovači 1 s/bez provozu v pozadí na páteřní lince
60
Buffer Usage [bytes]
0
50
100
150
200
250
300
350
0
20
time [sec]
60
80
100
noBackgroundTraffic: core_router_1.IP Interface.WFQ Buffer Usage (bytes) IF11 Q3.none backroundTraffic: core_router_1.IP Interface.WFQ Buffer Usage (bytes) IF11 Q3.none
40
Porovnání využití bufferu na páteřním směrovači 1 (s provozem v pozadí na páteřní lince a bez provozu v pozadí)
120
Obr. 42 – Porovnání odesílaných dat z fronty Q1 na páteřním směrovači 2
61
Traffic Sent [bit/s]
0
50000
100000
150000
200000
250000
0
40
time [sec]
60
80
100
backroundTraffic: core_router_2.IP Interface.WFQ Traffic Sent (bits/sec) IF10 Q1.none
noBackgroundTraffic: core_router_2.IP Interface.WFQ Traffic Sent (bits/sec) IF10 Q1.none
20
Porovnání odesílaných dat z fronty Q1 na páteřním směrovači 2
120
7.2 Seznam obrázků Obr. 1 - Referenční model technologie InterServ – [9] ............................................. 14 Obr. 2 – Položky ToS a Traffic Class v hlavičce IP paketu ......................................... 15 Obr. 3 – Schéma diffserv – dělení na DS domény................................................... 16 Obr. 4 – Referenční model technologie diffserv ....................................................... 17 Obr. 5 – Příklad implementace EF ......................................................................... 19 Obr. 6 – Příklad AF ............................................................................................. 21 Obr. 7 - Token bucket ......................................................................................... 23 Obr. 8 - Síťový model v editoru projektu................................................................ 26 Obr. 9 - Hlavní menu editoru projektu ................................................................... 27 Obr. 10 - Tlačítka projektového editoru ................................................................. 27 Obr. 11 – Textová oblast editoru projektu.............................................................. 28 Obr. 12 – Zobrazení tipů v editoru projektu ........................................................... 28 Obr. 13 – Editor uzlu – model pracovní stanice ....................................................... 29 Obr. 14 – Editor procesu ..................................................................................... 29 Obr. 15 – Editor procesu – vstupní a výstupní pozice ............................................... 30 Obr. 16 – Editor procesu – vynucený a nevynucený stav.......................................... 31 Obr. 17 – Vzorový příklad pro LAN Client ............................................................... 32 Obr. 18 – Model diffserv domény .......................................................................... 33 Obr. 19 – Model diffserv domény vytvořený v OM ................................................... 34 Obr. 20 – Objekt Application Config ...................................................................... 34 Obr. 21 – Příklad nastavení ftp aplikace................................................................. 35 Obr. 22 – Nastavené aplikace provozované v projektu ............................................. 36 Obr. 23 – Objekt Profile Config............................................................................. 38 Obr. 24 – Příklad nastavení aplikace FTP na klientu FTP ........................................... 40 Obr. 25 – Příklad nastavení podporovaných služeb na serveru FTP ............................ 40 Obr. 26 – Spojení klient – server – příkladová síť .................................................... 42 Obr. 27 – Příklad nastavení unikátní adresy serveru ................................................ 42 Obr. 28 – Příklad nastavení Application: Destination Preference ................................ 43 Obr. 29 – Objekt QoS Attribute Config................................................................... 44 Obr. 30 – Příklad nastavení hodnoty DSCP ............................................................. 46 Obr. 31 – Nastavení front v projektu domény diffserv v OM...................................... 47 Obr. 32 – Pravděpodobnost zahození paketu pro algoritmus RED .............................. 48 Obr. 33 – Pravděpodobnost zahození paketu pro algoritmus WRED............................ 48 Obr. 34 – Zobrazení aktuálního scénáře................................................................. 50 Obr. 35 – Nastavení provozu v pozadí na lince........................................................ 50 Obr. 36 – Průběh simulace .................................................................................. 52 Obr. 37 – Zatížení serveru 1 a serveru 2 pro projekt klient – server .......................... 56
62
Obr. 38 – Zpoždění ve frontách na páteřním směrovači 2......................................... 57 Obr. 39 – Využití bufferu jednotlivými frontami na páteřním směrovači 2 ................... 58 Obr. 40 – Zpoždění paketů na páteřním směrovači 1 s/bez provozu v pozadí na páteřní lince ................................................................................................................. 59 Obr. 41 – Využití bufferu na páteřním směrovači 1 s/bez provozu v pozadí na páteřní lince ................................................................................................................. 60 Obr. 42 – Porovnání odesílaných dat z fronty Q1 na páteřním směrovači 2 ................. 61
63
7.3 Seznam tabulek Tab. 1 - Příklady a zařazení služeb......................................................................... 6 Tab. 2– Naměřené hodnoty v reálné síti CRFreeNet ................................................... 8 Tab. 3 - Citlivost různých typů služeb na parametry sítě .......................................... 10 Tab. 4 - Přehled nejdůležitějších parametrů síťových služeb...................................... 12 Tab. 5 – Hodnoty DSCP pro AF dle RFC 2597.......................................................... 21 Tab. 6 – Nastavení front v projektu diifserv domény................................................ 47
64
7.4 Seznam zkratek AF - Assured Forwarding - Zaručené doručení ATM - Asynchronous Transfer Mode – Asynchronní přenosový mód BE – Best Effort - Provoz bez priority BA - Behavior Aggregate - Druh třídiče Core Routers – Páteřní směrovač CU - Currently Unused - Nepoužito DiffServ - Differentiated Service- Diferencovaná služba DS - Differentiated Service - Rozlišované služby DSCP - Differentiated Service Code Point – Diferencovaný servisní kód EF - Expedited Forwarding - Urychlené doručení Edge Routers – Hraniční směrovač FIFO - First In First Out – První dovnitř – první ven FSM - Finite State Machines – Konečný stavový automat FTP – File Transfer Protocol - Interaktivního přenosu souborů HTML - Hyper Text Markup Language – Jazyk pro tvorbu www HTTP - Hyper Text Transfer Protocol - Internetový protokol pro výměnu hypertextových dokumentů ve formátu HTML IEEE - Institute of Electrical and Electronics Engineers - Instituce definující elektrické normy a standardy IETF - Internet Engineering Task Force - Významná a rozsáhlá mezinárodní komunita působící v oblasti Internetu IntServ - – Integrated Services - Integrované služeby IP – Internet Protocol – Internetový protokol LAN – Local Area Network - Lokální počítačová síť MF - MultiField - Druh třídiče MPLS - Multiprotocol Label Switching - Protokol pro zajištění podpory kvalit služeb OM - Opnet Modeler – Simulační prostředí firmy OPNET QoS - Quality of Service – Kvalita služeb
65
RED - Random Early Detection, Random Early Drop - Algoritmus pro zamezení zahlcení linky RFC - Request for Comments - Standardy vytvářené organizace IETF RSVP - Resource reSerVation Protocol – Rezervační protokol pro zajištění podpory kvalit služeb RTT - Round-Trip Time – Doba udávající přenos informace od zdroje k cíli a zpět SLA - Service Level Agreement – Dohoda o úrovni služby SNMP - Simple Network Management - Standardní řídící protokol sítě TCP - Transmission Control Protocol - Protokol zaměřený na konektivitu, pracující ve čtvrté vrstvě OSI modelu ToS - Type of Service – Typ služby UDP - User Datagram Protocol - Transportní protokol zajišťující nespolehlivou datagramovou službu VoIP – Voice over IP – Telefonování přes internet XML - eXtensible Markup Language - Rozšiřitelný značkovací jazyk WFQ – Weighted Fair Queuing - Vážené řazení do front WRED - Weighted Random Early Detection - Algoritmus pro zamezení zahlcení linky WWW - World Wide Web – “Celosvětová pavučina“ - zkráceně web
66
7.5 Použitá literatura [1]
BRANDEN R., ZHANG L., et al., Resource ReSerVation Protocol (RSVP), RFC 2205, Version 1 Functional Specification IETF [cit. 2001-03-23] Dostupný z WWW: < http://www.ietf.org/rfc/rfc2205.txt?number=2205>.
[2]
DAVIE B., CHARNY A., et al., An Expedited Forwarding PHB (Per-Hop Behavior), RFC 3246, [cit. 2001-03-23] Dostupný z WWW: < http://www.ietf.org/rfc/rfc3246.txt?number=3246 >.
[3]
HEINANEN J., BAKER F., et al., Assured Forwarding PHB Group, RFC 2597, [cit. 2001-03-23], Dostupný z WWW: < http://www.ietf.org/rfc/rfc2597.txt?number=2597 >.
[4]
BLAKE S., BLACK D., et al., An Architecture for Differentiated Services, RFC 2475, [cit. 2001-03-23] Dostupný z WWW: < http://www.ietf.org/rfc/rfc2475.txt?number=2475 >.
[5]
WANG Z.,, Ineternet QoS - Architectures and Mechanisms for Quality of Service, 2001
[6]
BERKA P., QoS v prostředí IP sítí, [cit. 2001-03-23] Dostupný z WWW: < http://www.elektrorevue.cz/clanky/04036/.iso-8859-1 >.
[7]
PUŽMANOVÁ R., TCP/IP v kostce, ISBN 80-7232-236-2, Praha 2004
[8]
UBIK S., : QoS a diffserv - Úvod do problematiky, [cit. 2000-06-01] Dostupný z WWW: < http://www.cesnet.cz/doc/techzpravy/2000-6/diffserv.html >.
[9]
BRADEN R., CLARK D., et al.: Integrated Services in the Internet Architecture: an Overview, RFC 1633, [cit. 2000-06-01] Dostupný z WWW: < http://www.ietf.org/rfc/rfc1633.txt?number=1633 >.
[10] OPNET TECHNOLOGIES, OPNET Modeler Product Documetation Release 11.0, součást instalace simulačního prostředí OPNET Modeler, 2005 [11] OPNET TECHNOLOGIES, OPNET Modeler, General Tutorials, součást instalace simulačního prostředí OPNET Modeler, 2005
67
[12] BROWNLEE N., MILLS C., RUTH G., Traffic Flow Measurement Architecture, RFC 2722, The Internet Engineering Task Force, 1999 Dostupný z WWW: < http://www.apps.ietf.org/rfc/rfc2722.html >. [13] DOLEJŠ O., OPNET Modeler – Networks Simulation [14] JACOBSON V., NICHOLS K., et al., An Expedited Forwarding PHB, RFC 2598, [cit. 2005-04-14] Dostupný z WWW: < http://www.ietf.org/rfc/rfc2598.txt?number=2598 >. [15] LHOTA L., Internet se zaručenou kvalitou služby,[cit. 2005-04-20] Dostupný z WWW:< http://www.cesnet.cz/doc/seminare/ei2000liberec/lhotka.html >. [16] CIGÁNEK T., et al., Simulace real-time komunikace pomocí OPNET Modeler, Praha 2004 [17] UBIK S., Technická zpráva TEN-155 CZ číslo 6/2000,[cit. 2005-04-3] Dostupný z WWW:< http://www.cesnet.cz/doc/techzpravy/2000-6 >. [18]
KUN I. PARK, QoS In Packet Networks, ISBN: 0-387-23389-X, 2005 Boston
68
7.6 Prohlášení Prohlašuji, že bakalářskou práci na téma „Modelování chování páteřních směrovačů DiffServ domény“ jsem vypracoval samostatně pod vedením svého vedoucího bakalářské práce s použitím odborné literatury, kterou jsem všechnu citoval v seznamu literatury.
V Brně dne 18.května 2006
_______________ (podpis autora)
69
7.7 Poděkování Touto větou bych zde chtěl poděkovat Ing. Karolu Molnárovi, Ph.D. za jeho vstřícný přístup, motivaci a velkou ochotu konzultovat naše poznatky. Dále bych poděkoval své rodině, která mi poskytla dostatek času k vypracování této práce a v neposlední řadě přítelkyni za její trpělivost a motivaci.
70
