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 Definice... 4 1.2 Historie a současnost... 5 1.3 Třídy služby... 5 1.4 Naměřené hodnoty v reálné síti CRFreeNet Chrudim... 7 2 Základní parametry přenosu... 10 2.1 Definice... 10 2.2 Ztráta paketů... 10 2.3 Zpoždění - latence... 11 2.4 Kolísání zpoždění - jitter... 11 2.5 Šířka pásma - bandwith... 11 3 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 Výsledky naměřených hodnot... 56 7.2 Seznam obrázků... 62 7.3 Seznam tabulek... 64 7.4 Seznam zkratek... 65 7.5 Použitá literatura... 67 7.6 Prohlášení... 69 7.7 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) E-mail On-line web kamery On line TV Vzdálená správa PC (Real VNC, Remote Administrator) 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 [port] Auth Authentication Service [113] Bootpc Bootstrap Protocol Client - zaváděcí protokolový klient [68] Csnet ns - Mailbox Name Nameserver [105] Domain - Domain Name Server [53] Echo [7] Ftp File Transfer Protocol [Control] přenášení souborů [21] Ftp data - File Transfer Protocol [Default Data] [20] Gopher [70] Http - World Wide Web Http [80] Https World Wide Web Security [443] ICQ I seek you - protokol pro chatování [5190] Iso tsap [102] Jabber Otevřený protokol pro chatování [5222] Kerberos - Autentizační mechanismus [88] Link [245] MSN - MSN Messenger [1863] MySQL - Relační databázový systém [3306] Ntp - Network time protokol slouží ke synchronizaci času [123] Ostatní většinou P2P sítě Pop3 - Post Office Protocol protokol příchozí pošty v3 [110] Pop3s - Post Office Protocol Security zabezpečený protokol [995] Sftp - Simple File Transfer Protocol [115] Smtp - Simple Mail Transfer Protocol [25] Ssh - Protokol pro vzdálený přístup ke konzoly serveru po síti [22] Sunrpc - SUN Remote Procedure Call [111] Systat - Active Users [11] Tcpmux - TCP Port Service Multiplexer [1] Telnet - slouží k navázání spojení s jiným počítačem [23] Tftp - Trivial File Transfer Protocol [69] 7
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% Echo 892 1168,82 1,14 1341,78 0,01% ftp 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% iso-tsap 3 0,23 0,00 77,67 0,00% Jabber 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% Ostatní 33418417 17884638,00 17465,00 548,02 82,23% pop3 297927 423206,00 413,00 1454,60 1,95% pop3s 1131 413,04 0,40 373,96 0,00% Sftp 2 0,27 0,00 139,00 0,00% Smtp 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% Tcpmux 81 6,10 0,01 77,06 0,00% telnet 7719 350,67 0,34 46,52 0,00% Tftp 6 0,28 0,00 47,00 0,00% Celkem 37603062 21750635 21240 592,31 100,00% 8
Graf 1. - Využití služeb v síti CRFreeNet ostatní 82% pop3 2% http 16% 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í) mysql 5% ICQ 14% ntp 1% pop3s 1% smtp 1% https 42% telnet 1% domain 1% echo 3% ftp 30% domain echo ftp 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ě Služba šířku pásma ztrátu paketů Citlivost na zpoždění kolísání Hlas 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á 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 (odvozené z rychlosti šíření signálu v médii a 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). 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í Hlas po IP 1% 200 ms 30 ms Videokonference Garantovaná prioritní šířka pásma na relaci 12 106 kbit/s (v závislosti na rychlosti vzorkování, kodeku apod.) 1% 200 ms 30 ms Objem relace plus 20% Streamované video 2% 5 s - Závisí na formátu kódování a rychlosti toku videa data různé různé různé různé 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 Celková délka TOS Verze hlavičky paketu Ofset Identifikace Příznaky fragmen tu Kontrolní součet TTL Protokol hlavičky Adresa odesílatele Třída Označení toku Verze přenosu dat Typ Délka datové Hop následující části paketu limit hlavičky... Cílová adresa... IP v 4 IP v 6 Obr. 2 Položky ToS a Traffic Class v hlavičce IP paketu 15
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 Zahození Dropper Klasifikace - Classification 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 Podtřída PHB Pravděpodobnost zahození DSCP AF41 Nízká 100010 AF42 Střední 100100 AF43 Velká 100110 AF31 Nízká 011010 AF32 Střední 011100 AF33 Velká 011110 AF21 Nízká 010010 AF22 Střední 010100 AF23 Velká 010110 AF11 Nízká 001010 AF12 Střední 001100 AF13 Velká 001110 21
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ů: 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. 4.3.1 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 viz Obr. 11. využívá pro zjištění poslední provedené operace, 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