VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ

Transkript

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS NOVÉ METODY ZAJIŠTĚNÍ KVALITY SLUŽEB V DATOVÝCH SÍTÍCH DIZERTAČNÍ PRÁCE DOCTORAL THESIS AUTOR PRÁCE AUTHOR Ing. JIŘÍ HOŠEK BRNO 2011

2 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS NOVÉ METODY ZAJIŠTĚNÍ KVALITY SLUŽEB V DATOVÝCH SÍTÍCH NEW METHODS OF QUALITY OF SERVICE ASSURANCE IN DATA NETWORKS DIZERTAČNÍ PRÁCE DOCTORAL THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR Ing. JIŘÍ HOŠEK doc. Ing. KAROL MOLNÁR, Ph.D. BRNO 2011

3 ABSTRAKT Dizertační práce je zaměřena na výzkum v oblasti technologií pro zajištění kvality služeb v datových sítích. Moderní komunikační sítě se v dnešní době již neobejdou bez kvalitního nástroje pro poskytování odlišného zacházení různým třídám provozu. Jak studie ukázaly, v současnosti nejpoužívanější QoS mechanizmus v datových sítích je technologie diferencovaných služeb. Stěžejní částí práce je návrh nového QoS systému, který nabízí řešení jednoho z hlavních problémů technologie DiffServ. Nedostatkem tohoto mechanizmu je chybějící spolupráce mezi koncovou stanicí a hraničním prvkem DiffServ domény. Navržený systém proto nabízí síťové aplikaci možnost podílet se na procesu zajištění požadované úrovně kvality služby tím, že sama nastaví hodnotu DSCP v hlavičce svých paketů. Základem tohoto systému je znalost konfigurace technologie DiffServ na hraničním směrovači. Za tímto účelem používá koncová stanice protokol SNMP, pomocí kterého vyčítá potřebné konfigurační informace z MIB databáze síťového prvku. Navržený QoS systém byl ověřen v simulačních podmínkách. Výsledky simulací ukázaly, že navržený systém představuje efektivní řešení zmíněného problému technologie DiffServ, což dává dobrý předpoklad pro jeho úspěšné nasazení v reálných podmínkách. KLÍČOVÁ SLOVA DiffServ, DSCP, IntServ, IxChariot, kosimulace, MIB, MPLS, OPNET Modeler, QoS, SNMP ABSTRACT The doctoral thesis is focused on a research in the area of the quality-of-service support technologies in data networks. The current modern communication networks cannot operate correctly without an effective tool allowing differentiated treatment for various network traffic classes. Looking at the current trends in this area it turns out that the technology of Differentiated services is currently the most widely used mechanism for QoS assurance in data networks. The major part of this doctoral thesis concerns the design of a novel QoS system which offers a solution for one of the main problems of DiffServ technology. This disadvantage lies in the missing cooperation between the end station and edge node of the DiffServ domain. To overcome this limitation the system proposed introduces an improvement which enables the user application to actively participate in the resource reservation process by direct configuration of the DSCP value in the IP header of its own packets. This functionality is based on the identification of DiffServ configuration parameters available in the edge router. To retrieve the information required from network component the well-known SNMP protocol has been chosen, which has direct access to the components s configuration stored in the MIB database. On the basis of this theoretical proposal several simulation scenarios have been created and analysed. The results show that the system designed presents an efficient solution for the mentioned problem of DiffServ. They also give good assumptions for the successful implementation of this system into a real environment. KEYWORDS DiffServ, DSCP, IntServ, IxChariot, cosimulation, MIB, MPLS, OPNET Modeler, QoS, SNMP

4 HOŠEK, Jiří Nové metody zajištění kvality služeb v datových sítích: doktorská práce. Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, Ústav telekomunikací, s. Vedoucí práce byl doc. Ing. Karol Molnár, Ph.D.

5 PROHLÁŠENÍ Prohlašuji, že svou doktorskou práci na téma Nové metody zajištění kvality služeb v datových sítích jsem vypracoval samostatně pod vedením vedoucího doktorské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou všechny citovány v práci a uvedeny v seznamu literatury na konci práce. Jako autor uvedené doktorské práce dále prohlašuji, že v souvislosti s vytvořením této doktorské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení S 11 a následujících autorského zákona č. 121/2000 Sb., včetně možných trestněprávních důsledků vyplývajících z ustanovení S 152 trestního zákona č. 140/1961 Sb. Brno (podpis autora)

6 PODĚKOVÁNÍ Velice děkuji svému školiteli doc. Ing. Karolu Molnárovi, Ph.D. za velmi cenné rady, vždy optimistický přístup a odborné vedení při psaní této dizertační práce. Dále bych rád poděkoval také své rodině a kolegům za podporu při tvorbě této práce. V Brně dne (podpis autora)

7 Všem mým blízkým...

8 OBSAH Úvod 11 1 Cíle dizertační práce 13 2 Přehled současného stavu problematiky Parametry síťového provozu Zpoždění paketů Třídy služeb Dohoha o úrovni poskytované služby SLA Přehled současných mechanizmů pro zajištění kvality služeb Technologie Integrovaných služeb (IntServ) RSVP protokol Referenční model IntServ Modely služeb Technologie Diferencovaných služeb (DiffServ) DiffServ doména Indentifikátor DSCP (DiffServ Code Point) Způsob zacházení PHB (Per-Hop Behavior) Referenční model DiffServ Plánované odesílání paketů Aktivní správa front Technologie MPLS MPLS návěstí Architektura MPLS sítě Distribuce MPLS návěstí Signalizační protokoly mechanizmu MPLS Směrování v sítích MPLS Řízení provozu v MPLS sítích Traffic Engineering v sítích MPLS Taffic Engineering z hlediska zajištění kvality služeb Celkové zhodnocení QoS mechanizmů Simulace a analýza vybraných QoS technologií Parametry simulačního modelu datové sítě Význam konfiguračních prvků Nastavení síťového provozu

9 3.2 Simulace technologie IntServ Rozbor výsledků simulace mechanizmu IntServ Simulace technologie DiffServ Rozbor výsledků simulace mechanizmu DiffServ Simulace technologie MPLS Analýza výsledků simulace technologie MPLS Návrh nového QoS systému s uživatelskou interakcí Obecné požadavky kladené na nově navrhovaný QoS sytém Analýza požadavků a definice základních vlastností navrženého QoS systému Komunikace mezi koncovým zařízením a hraničními prvky sítě Minimální zatížení síťových prvků Minimální zásahy do stávající infrastruktury a nezávislost na fyzické implementaci Dodržování dohodnutých pravidel a zásad Koexistence se stávajícími technologiemi Jednoduchá ověřitelnost Základní princip navrženého QoS systému Protokol SNMP (Simple Network Management Protocol) Základní model správy síťových zařízení pomocí protokolu SNMP Struktura řídících informací Základní operace protokolu SNMP Databáze MIB (Management Information Base) Vazby mezi objekty MIB Databáze MIB Databáze DiffServ-MIB Databáze Cisco CBQoS (Class-Based QoS) MIB Algoritmus pro vyčítání konfiguračních informací z databáze MIB Funkční bloky navrženého QoS systému Detekce konfiguračních parametrů technologie DiffServ Zpracování dostupných tříd provozu a souvisejících parametrů Proces výběru vhodné třídy provozu Způsob nastavení zvolené DSCP značky Přenos paketů označených DSCP značkou

10 5 Ověření navrženého QoS systému v laboratorních podmínkách Ověření mechanizmu získávání konfiguračních parametrů z databáze MIB Implementace SNMP protokolu do simulačního prostředí OM Způsob zpracování a ukládání přijatých informací z MIB Propojení simulačního prostředí s externím systémem Externí aplikace Ověření vlivu nastavení DSCP značky síťovou aplikací Model pracovní stanice v simulačním prostředí OM Externí aplikace IxChariot API Analýza výsledků simulace navrženého systému Závěr 133 Literatura 135 Seznam zkratek 143 Seznam symbolů a veličin 149 Seznam příloh 150 A Princip provázání QoS objektů v databázi Cisco CBQoS MIB 151 B Algoritmus vyčítání potřebných konfiguračních parametrů z databáze Cisco CBQoS MIB 152

11 ÚVOD V počátcích vývoje komunikačních sítí existovaly jednotné požadavky na přenos dat. Díky malé rozmanitosti síťových služeb a nízkému vytížení přenosových linek nebylo nutné řešit úroveň kvality poskytované přenosové služby. I přes neustálé rozrůstání a zvyšování přenosové kapacity zůstala základní architektura Internetu stejná. Internet již od svého vzniku pracuje jako paketově-orientovaná síť, kde je každý paket přenášen samostatně přes celou síť. Čas doručení paketu není nijak garantován a stejně tak může být paket v kterémkoli síťovém uzlu zahozen z důvodu jeho zahlcení. Masový rozvoj komunikačních technologií výrazným způsobem ovlivnil současnou skladbu síťových služeb a také přinesl vyšší uživatelské požadavky na jejich přenos. Množství síťových aplikací stále roste a nejvýraznější je to u služeb pracujících v reálném čase, jejichž podíl v síťovém provozu se neustále zvyšuje. Podle některých studií [97] byl tento podíl v roce 2010 v Evropě více než 30% a v USA dokonce více než 40% z celkového síťového provozu. Odhady pro rok 2012 udávají [36], že by síťové služby pracující v reálném čase měly tvořit více jak polovinu z celkového množství přenesených dat. Nárůst množství síťových služeb je spojen s rozdílnými požadavky na jejich přenos. Každý typ síťové služby je jinak citlivý na parametry přenosu. Na takovýto vývoj nebyl základní koncept Internetu připraven, a proto bylo nutné vyvinout dodatečné mechanizmy, jejichž hlavním cílem je nabídnout možnost rozdílného zacházení a dodržení předem stanovených parametrů při přenosu dat v závislosti na jejich typu [82], [68]. Hlavní důraz je tedy kladen na schopnost sítě rozlišit tok dat podle zdrojových aplikací a rozdělit ho na jednotlivé třídy provozu. V závislosti na statistických údajích o vytvořených třídách je možné určit optimalizovanou politiku provozu, která bude co nejvíce zaručovat dodržení požadované kvality služeb pro aplikace vyžadující rozdílný způsob zacházení. Tato úloha je určená převážně pro aktivní síťově prvky, kterými jsou nejčastěji hraniční směrovače [100], [105]. Postupem času se vyvinuly různé typy řešení a návrhy architektur, které zavádějí úrovně kvality služeb a třídí datové jednotky síťového provozu podle stanovených priorit. Kvalita služeb v referenčním modelu počítačové sítě může být implementována na různých vrstvách. Nejčastěji se používá implementace na úrovni linkové nebo síťové vrstvy. Na linkové vrstvě se zajištění kvality služeb (QoS - Quality of Service) řeší zejména pro technologie Ethernet a ATM (Asynchronous Transfer Mode). Na úrovni síťové vrstvy pak pro klasické IP (Internet Protocol) sítě. Při implementaci na úrovni IP protokolu existuje několik mechanizmů, avšak nejvíce se prosadily tři řešení a těmi jsou Integrované služby (IntServ - Integrated Services), Diferencované služby (DiffServ - (Differentiated Services) a technologie MPLS (Multi-Protocol Label Switching) [100], [93]. 11

12 Každá z výše uvedených technologií má svoje výhody i nevýhody, avšak žádná z nich není zcela ideální. Některé technologie (např. IntServ) se postupem času staly neefektivními, a proto se od jejich praktického použití v přístupových sítích zcela ustoupilo. Naproti tomu mechanizmy jako DiffServ nebo MPLS jsou v současnosti často využívaným nástrojem pro zajištění QoS. Neustálý výzkum a vývoj v této oblasti je však velmi důležitý, neboť i tyto technologie mají svoje omezení a při rychlosti nárůstu počtu síťových služeb a celkově přenesených dat se mohou i aktuálně využívané technologie stát brzy neefektivními a nedostačujícími. A právě proto vznikla tato práce, která si klade za obecný cíl vytvoření návrhu nového mechanizmu pro zajištění QoS, který bude řešit nedostatky současných technologií a umožňovat tak jejich globálnější rozšíření. Konkrétně se jedná o návrh systému, který bude rozšiřovat mechanizmus diferencovaných služeb o možnost ovlivnění procesu přidělování síťových prostředků samotnou koncovou aplikací. V první části práce jsou nejprve v rámci teoretického základu rozebrány v současné době nejpoužívanější technologie (IntServ, DiffServ a MPLS) zajišťující kvalitu služeb v datových sítích. Pro každou technologii je uveden její základní princip a funkční bloky. Následně je v simulačním prostředí OPNET Modeler vytvořen síťový model, v kterém je nakonfigurována a následně odsimulována daná technologie. Hlavní důraz je kladen na technologii DiffServ, neboť ta je předmětem dalšího zkoumání. V další části práce je pak uveden návrh uživatelsky-řízeného QoS systému, který umožňuje koncové aplikaci v rámci mechanizmu DiffServ definovat svoje požadavky na parametry přenosu. Podrobný rozbor koncepčních prvků tohoto systému je následován popisem jeho implementace a ověření v simulačním nástroji OPNET Modeler. 12

13 1 CÍLE DIZERTAČNÍ PRÁCE Hlavním cílem dizertační práce je navrhnout a ověřit funkčnost nového a efektivnějšího mechanizmu pro zajištění kvality služeb v datových sítích. Pro dosažení tohoto cíle bude navrženo komplexní řešení, které rozšíří možnosti mechanismu diferencovaných služeb (DiffServ) o užší spolupráci mezi uživatelskou aplikací a hraničním prvkem technologie DiffServ. U této technologie je počátečním místem, kde se aplikují QoS mechanizmy, hraniční směrovač dané sítě. Právě tato vlastnost je jedním z hlavních nedostatků technologie DiffServ, neboť zde chybí přímá interakce s uživatelskou aplikací, která dokáže nejlépe definovat svoje QoS požadavky. Úkolem navrženého řešení tedy bude umožnit koncové aplikaci, aby ovlivnila proces přidělování síťových prostředků v rámci zajištění kvality služeb tím, že sama navrhne u odesílaných paketů nejvhodnější třídu provozu. V souvislosti s tímto řešením samozřejmě vyvstává řada důležitých otázek, které je nutné vyřešit. Mezi tyto otázky patří například definování mechanizmu, který bude umožňovat koncové stanici získat z hraničního směrovače DiffServ domény potřebné informace týkající se definovaných tříd provozu. Dalším úkolem bude definovat způsob, jakým uživatelská aplikace získané informace zpracuje a uplatní při zařazování svých dat do požadované třídy provozu. Proto, aby bylo možné všechny tyto otázky vyřešit, bude v simulačním prostředí OPNET Modeler vytvořen komplexní model navrženého systému. S pomocí tohoto simulačního modelu bude navržené řešení detailně analyzováno. Dále následuje kompletní souhrn stanovených cílů dizertační práce. Pro větší přehlednost jsou cíle dizertační práce zformulovány do 3 hlavních bodů a v rámci každého bodu jsou definovány 3 dílčí cíle. Analýza stávajících technologií pro zajištění kvality služeb v datových sítích Zaměřit se zejména na vlastnosti QoS mechanizmů pracujících na síťové vrstvě referenčního modelu TCP/IP (Transmission Control Protocol/Internet Protocol). V simulačním prostředí OPNET Modeler vytvořit model, který bude umožňovat srovnání technologií IntServ, DiffServ a MPLS. Analyzovat výsledky simulací se zaměřením na mechanizmus DiffServ, který je předmětem dalšího zkoumání. 13

14 Návrh nového efektivnějšího mechanizmu pro zajištění QoS v datových sítích, který bude umožňovat užší spolupráci koncové stanice a hraničního prvku technologie DiffServ Definovat základní požadavky na nový QoS systém Popsat základní princip a funkční bloky navrženého mechanizmu rozšiřujícího technologii DiffServ. Navrhnout optimální způsob komunikace a získávání potřebných informací z hraničního prvku DiffServ domény Ověření navrženého QoS systému v simulačním prostředí V simulačním prostředí OPNET Modeler vytvořit testovací scénář a implementovat do něj navržený QoS mechanizmus. Provést základní simulace navrženého systému s cílem celkově zhodnotit reálný přínos navrženého systému. Provést analýzu výsledků simulace navrženého systému a definovat základní požadavky pro jeho nasazení v reálném prostředí. 14

15 2 PŘEHLED SOUČASNÉHO STAVU PROBLEMATIKY Klasické IP sítě jsou od své podstaty sítě typu best-effort, což znamená, že každý paket zpracovávají stejným způsobem a nezávisle na ostatních a tím pádem zachovávají pro všechny pakety jednotnou úroveň zacházení [45], [105]. Tento způsob je dostačující pro klasický přenos souborů, ne však pro moderní síťové služby pracující v reálném čase nebo obecně služby vyžadující od sítě specifickou úroveň zacházení. Mezi tyto služby je možné zařadit například přenos hlasu přes IP síť označovaný jako VoIP (Voice over Internet Protocol) [4], videokonference, služby využívané v rámci telemedicíny, vzdálený dohled, bankovní a finanční operace a různé druhy záchranných a bezpečnostních systémů. IP sítě dlouho nebyly připraveny na přenos a zajištění požadované úrovně kvality takového typu dat. Velký uživatelský zájem o tyto služby však vedl k návrhu a implementaci mechanismů, které v různé míře umožňují zajištění kvality služeb, tzv. QoS. Pojem QoS lze vyjádřit různými způsoby, záleží totiž na úhlu pohledu. Z pohledu koncového uživatele je vnímání QoS subjektivní, relativní a těžko měřitelné. Koncový uživatel vnímá kvalitu služby skrz jeho koncová zařízení a má určitá očekávání o odpovídající úrovni kvality [100]. Zjednodušeně lze tedy říci, že uživatel hodnotí zajištění QoS podle subjektivní kvality zvuku během VoIP přenosu nebo kvality obrazu během videokonference. I přesto, že je objektivní hodnocení uživatelského vnímání kvality služeb poněkud problematické, pro hodnocení kvality lidské řeči bylo definováno několik nástrojů. Jedním z nich je stupnice MOS (Mean Opinion Score) nabývající hodnot od 1 do 5, kdy 1 = špatná, 2 = nízká, 3 = uspokojivá, 4 = dobrá, 5 = excelentní kvalita [58]. MOS je stanoven subjektivní metodou hodnocení. Uživatel hodnotí úroveň kvality přenášené řeči a definuje odpovídající MOS hodnocení. Hraniční hodnotou MOS pro použití v oblasti VoIP je hodnota 2.6 [103]. Subjektivní hodnocení je poměrně drahé a časově náročné, proto byl dle doporučení ITU-T G.107 [61] definován tzv. E-model, jehož výstupem je R-factor (Quality Rating Factor). E-model je výpočetní model, kterým je možné nahradit subjektivní hodnocení využívající stupnici MOS. E-model v sobě zahrnuje kombinaci účinků různých variant přenosových parametrů působících na kvalitu hovoru. Výstupem je pak metrika nazvaná R-faktor, která je numerickým vyjádřením hlasové kvality. R-faktor nabývá hodnot 0 až 100, kde hodnota nula reprezentuje extrémně špatnou kvalitu a hodnota 100 velmi vysokou kvalitu [82], [103]. Tabulka 2.1 [82] ukazuje vzájemnou provázanost hodnot MOS a R-factor. Naproti tomu je definice QoS z pohledu sítě poněkud odlišná. Jedná se o schop- 15

16 Tab. 2.1: Vzájemný vztah mezi hodnotami R-factor a MOS R-factor MOS Uživatelské hodnocení Velká spokojenost Spokojenost Někteří uživatelé nespokojeni Mnoho uživatelů nespokojeno Téměř všichni uživatelé nespokojeni Není doporučeno nost sítě poskytovat odlišné zacházení různým typům síťového provozu. QoS tedy umožňuje přidělování rozdílných priorit provozu různým datovým tokům a zvýhodňovat tak určitý typ provozu před ostatními. Zajištění QoS z pohledu sítě lze tedy jednoznačně definovat pomocí objektivních parametrů provozu jako je ztrátovost paketů nebo jejich zpoždění [68]. Tyto dva odlišné pohledy na problematiku QoS - uživatelský a síťový však nemusí být vždy v souladu. V některých případech může být sítí garantováno spojení s jasně definovanými objektivními parametry, avšak uživatel nemusí pocítit subjektivní zlepšení nebo zhoršení kvality služby [15]. Nasazení technologie pro zajištění kvality služeb tedy nemusí vždy nutně vést ke spokojenosti koncového uživatele. Z pohledu síťových operátorů je tedy nutné jednak zvolit efektivní QoS mechanizmus, jeho konfiguraci přizpůsobit konkrétním požadavkům a skladbě síťového provozu v dané síti a v neposlední řadě také získat zpětnou vazbu od koncových uživatelů. V další části práce budou popsány jednotlivé QoS parametry a mechanizmy a problematika zajištění kvality služeb bude tedy rozebírána ze síťového pohledu. 2.1 Parametry síťového provozu Aby bylo možné v sítí zavést diferenciaci datových toků a odlišné úrovně priority, je nutné jednotlivé úrovně zacházení popsat pomocí jasně definovaných a snadno měřitelných parametrů. Mezi základní QoS parametry, které ovlivňují kvalitu služeb, patří: zpoždění paketů, kolísání zpoždění, ztrátovost paketů, propustnost. 16

17 2.1.1 Zpoždění paketů Zpoždění neboli latence je definováno jako doba potřebná k přenosu paketu od zdroje k cíli. Celkové zpoždění se skládá z dílčích složek. Mezi hlavní zdroje zpoždění patří [82]: zdrojové kódování (A/D a D/A převod, doba trvání jednoho rámce), paketizační zpoždění, kanálové kódování (detekce a opravy chyb, prokládání), jitter buffer (pokud je využíván), zpoždění způsobené čekáním paketů ve frontě aktivního prvku, propagační zpoždění (odvozené od rychlosti šíření signálu v médiu a ze vzdálenosti). Hodnoty zpoždění způsobené zdrojovým kódováním, paketizací, kanálovým kódováním a jitter bufferem jsou závislé na použitém kodeku, naproti tomu zpoždění způsobené čekáním paketů ve frontách síťových prvků nebo samotných přenosem jde na vrub samotné síti [82]. Kolísání zpoždění Kolísání zpoždění, označováno také jako jitter, zachycuje změnu zpoždění během přenosu jednotlivých paketů od zdroje k cíli. Pakety jsou ze zdroje odesílány s určitými časovými rozestupy. V ideálním případě by se stejnými časovými rozestupy byly také přijaty a hodnota jitteru by tedy byla nulová. V reálném prostředí však často vlivem různého stupně zahlcení síťových prvků dochází ke změně tohoto intervalu a tím pádem mohou pakety dorazit do cíle s různým zpožděním [102]. Ztrátovost paketů Ztrátovost paketů udává množství paketů, které nedorazí do cíle. Nejčastěji se udává v procentech a vypočítá se jako poměr počtu ztracených paketů k celkovému počtu odeslaných paketů. Ke ztrátě paketů může dojít hned z několika důvodů. Nejčastěji je to z důvodu zahlcení či přetížení síťového uzlu, kdy některé směrovače nebo přepínače nestačí odbavovat příchozí pakety dostatečně rychle. Dojde tedy k zaplnění front v jejich vyrovnávacích pamětích a další příchozí pakety musí být zahozeny [102]. 17

18 Propustnost Propustnost v oblasti počítačových sítí označuje maximální množství dat, které je možné přenést přes danou linku za jednotku času. Propustnost je nejčastěji udávána v bitech za sekundu Třídy služeb Na začátku této kapitoly byly uvedeny některé příklady síťových služeb, který vyžadují rozdílný způsob zacházení a je pro ně vhodné použít některý z mechanizmů zajištění kvality služeb. Každá z těchto služeb má však odlišný charakter provozu a vyžaduje tedy specifickou úroveň QoS. Například klasický přenos souborů nebo elektronická pošta, což byly jedny z prvních síťových služeb, jsou vysoce citlivé na ztrátu nebo chybný příjem paketů, ale nejsou tolik citlivé na zpoždění nebo jitter. Naproti tomu, služba VoIP je vysoce citlivá na zpoždění a jeho proměnlivost, ale naopak je schopná si poradit s malou mírou ztrátovosti paketů. Aby tedy bylo možné každý typ aplikace nějak zařadit a určit pro ni konkrétní hodnoty požadovaných parametrů provozu, byly definovány tzv. kategorie služeb, někdy označované také jako QoS třídy nebo třídy služeb. Jedna z používaných klasifikací pro IP sítě, viz tab. 2.2, je definována v doporučení ITU-T Y-1541 [62]. Jinou, alternativní, klasifikaci QoS tříd navrhla organizace ETSI v rámci projektu TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks) [42], [43]. Tab. 2.2: Klasifikace QoS tříd podle ITU-T Y.1541 QoS třída Charakteristika 0 Aplikace pracující v reálném čase, citlivost na jitter, vysoce interaktivní 1 Aplikace pracující v reálném čase, citlivost na jitter, interaktivní 2 Transakční data, vysoce interaktivní 3 Transakční data, interaktivní 4 Pouze nízká ztrátovost (krátké transakce, shluková data, streamování videa 5 Tradiční aplikace původních IP sítí Zařazení síťové aplikace do některé z výše uvedených QoS tříd je základním předpokladem pro efektivní zajištění požadované úrovně služby [93]. 18

19 2.1.3 Dohoha o úrovni poskytované služby SLA Výsledná úroveň zajištění QoS je závislá na všech prvcích, přes které prochází uživatelský datový tok. Vzhledem k tomu, že data často prochází přes síťové domény spravované různými poskytovateli síťového připojení SP (Service Provider), je potřeba určitým standardním formálním způsobem definovat vztah mezi těmito poskytovateli a koncovými uživateli. Proto je nedílnou součástí systému pro zajištění kvality služeb dohoda o úrovni poskytované služby, označovaná zkráceně jako SLA (Service Level Agreement). Podle standardu ITU-T E.860 [59] je SLA formální dohoda mezi dvěma nebo více entitami, které je dosaženo po vzájemném vyjednávání za účelem definování konkrétních parametrů přenosu a příslušných práv a povinností. Zmíněnými entitami jsou nejčastěji dva poskytovatelé síťového připojení nebo poskytoval připojení a koncový uživatel. Na obr. 2.1 je zobrazeno rozhraní a soubor bodů interakce mezi poskytovatelem síťového připojení a koncovým uživatelem [59]. OBJEKT ROZHRANÍ OBJEKT Uživatel Vyjednávání Úroveň kvality Měření Požadavek na službu Poskytnutí služby Poskytovatel Obr. 2.1: Vzájemný vztah mezi uživatelem a poskytovatelem služby Dohoda SLA jasně vymezuje úroveň poskytované služby, způsob kontroly jejího dodržování a také situace, kdy sjednané parametry nejsou dodrženy. SLA definuje nejen povinnosti poskytovatele síťového připojení, ale také formát a parametry provozu, který smí koncový uživatel do sítě vysílat. SLA vymezuje také podmínky tarifikace a účtování. Na základě této dohody tedy uživatel ví, jaké parametry jsou mu garantovány, a může podle toho posoudit využití různých sítových služeb případně se rozhodnout pro jiného SP. Na druhé straně, také poskytovatel připojení má informace o charakteru příchozího provozu a tyto informace pak může využít při návrhu a optimalizaci přenosové sítě. Zpravidla sjednané parametry se vztahují na provoz určité kategorie služeb a ne na konkrétní toky dat. 19

20 2.2 Přehled současných mechanizmů pro zajištění kvality služeb Základní způsob zpracovávání datových jednotek v IP sítích, označovaný jako Besteffort, zajišťuje všem tokům stejnou pravděpodobnost přenosu, avšak zároveň není schopný garantovat specifické parametry síťového provozu. Proto bylo nutné vyvinout mechanizmus, který bude schopný zajistit klasifikaci datových toků podle typu služby a následné odlišné zacházení pro jednotlivé třídy služeb uvnitř sítě, což jsou dva základní úkoly všech technologií pro zajištění QoS [82]. Existuje poměrně velké množství teoretických návrhů systémů pro zajištění QoS v datových sítích, avšak jen malé množství z nich se skutečně podařilo prakticky realizovat a ve větší míře prosadit. V následujícím textu budou popsány dvě základní technologie pro zajištění kvality služeb - IntServ a DiffServ, které se prosadily v praxi. Každá z těchto mechanizmů řeší problematiku QoS odlišným způsobem. Na obr. 2.2 jsou srovnány jednotlivé metody zacházení s datovými toky aplikované v mechanizmech best-effort, IntServ a DiffServ. Při metodě best-effort jsou všechny pakety koncentrované do jednoho výsledného toku nezávisle na zdroji a typu dat. V mechanizmu IntServ jsou jednotlivé toky rozlišovány a je s nimi individuálně zacházeno po celé trase spojení. Třetí způsob zacházení přináší architektura DiffServ, kdy jsou vstupní datové toky rozřazeny do menšího počtu předem definovaných tříd a je s nimi dále zacházeno podle pravidel definovaných pro danou třídu provozu [82]. Místem, kde jsou v IP síti implementovány funkce pro vykonávání základních úkolů při zajišťování QoS, jsou aktivní síťové prvky. Tuto pozici zastávají nejčastěji směrovače nebo inteligentní přepínače. 2.3 Technologie Integrovaných služeb (IntServ) Technologie Integrovaných služeb (IntServ - Integrated Services), byla první technologie používaná v IP sítích, která umožňovala klasifikaci datových toků a přidělování síťových zdrojů podle typu služby a splnila tak oba výše popsané základní úkoly obecného QoS mechanizmu. Koncept Integrovaných služeb byl definován v roce 1994 v dokumentu RFC 1633 [24]. Základní myšlenka architektury IntServ vychází z okruhově-spínaného typu komunikace, kdy jsou síťové zdroje alokovány zvlášť pro každý vybraný tok dat. Aby aplikace získala požadované parametry přenosu, musí před samotným přenosem dat proběhnout proces rezervace. Rezervace síťových zdrojů se skládá z několika kroků. Nejprve musí aplikace definovat charakter odesílaných dat a také požadavky na síťové zdroje. Síť poté použije směrovací protokol pro nalezení vhodné trasy, 20

21 Datové toky Tok 1 Tok 2 Tok 3 Tok 4 Tok 5 IP IntServ Datové toky Tok 1 Tok 2 Tok 3 Tok 4 Tok 5 IP Všechny toky Best Effort Datové toky Tok 1 Tok 2 Tok 3 Tok 4 Tok 5 IP Třída 1 Třída 2 Třída 3 DiffServ Obr. 2.2: Způsoby zacházení s datovými toky pro technologie IntServ, DiffServ a Besteffort která umožní uspokojení požadavků uživatelské aplikace. Následně je použit rezervační protokol pro vytvoření tzv. rezervačního stavu, který zajištuje garanci síťových zdrojů na všech zúčastněných uzlech podél celé trasy. Je tedy nutné vyjednat, zda jsou všechny prvky sítě schopné garantovat požadované parametry přenosu [105]. Jestliže poskytnuté síťové zdroje nejsou na některém z uzlů dostačující, spojení bude odmítnuto a zdrojová aplikace se může rozhodnout, zda se spokojí s mírnějšími požadavky, nebo odloží přenos. Pokud je však proces rezervace jednou schválen a řádně dokončen, aplikace může začít vysílat svoje data po rezervované trase RSVP protokol K zajištění informovanosti prvků sítě a tím pádem k rezervaci prostředků v síti slouží u mechanizmu IntServ tzv. rezervační protokoly. V praxi je používán především protokol RSVP (Resource Reservation Protocol), jehož podrobný popis je uveden v [26]. RSVP protokol poskytuje mechanizmus pro vytváření a správu rezervačního stavu podél celé trasy mezi zdrojem a cílem datového toku. Samotné rozhodnutí, 21

22 která trasa bude pro přenos dat vybrána, je však provedeno směrovacím protokolem. RSVP proces se jednoduše řídí informacemi ve směrovací tabulce a na základě těchto informací posílá RSVP zprávy. Díky tomu je RSVP protokol nezávislý na použitém směrovacím protokolu [105]. Protokol RSVP definuje dva typy zpráv: PATH a RESV (viz obr. 2.3) [82]. Aplikace působící jako zdroj datového toku vysílá v pravidelných intervalech zprávy typu PATH. Tato zpráva putuje směrem k příjemci přes jednotlivé směrovače. Zpráva obsahuje záznam o charakteru vysílané informace a je do ní zaznamenávána cesta mezi zdrojem a příjemcem dat. Tyto informace dále slouží k rezervaci výše zmíněných síťových prostředků [85]. Po přijetí zprávy PATH aplikace na straně příjemce odpoví zprávou typu RESV, kterou potvrdí přidělení požadovaných síťových zdrojů. Zprávu RESV zašle směrem ke zdroji po cestě definované v přijaté zprávě PATH. RESV zprávy specifikují požadavky na síťové zdroje a vytváří rezervační stav ve směrovačích podél zvolené trasy [105]. Zdroj Host IP IntServ síť PATH PATH PATH PATH Cíl Host RESV RESV RESV RESV DATA DATA DATA DATA Obr. 2.3: Základní operace RSVP protokolu Zpráva typu PATH obsahuje následující objekty PHOP (Previous Hop), Sender template, Sender TSpec a AdSpec, jejichž význam je blíže popsán v [26], [105]. Zpráva typu RESV figuruje v protokolu RSVP jako rezervační žádost a je tvořena objekty Flow Spec a Filter Spec, které jsou společně označované jako Flow Descriptor [26]. Rezervační stav vytvořený protokolem RSVP má definovanou dobu trvání a pokud tato doba vyprší, dojde k automatickému zrušení tohoto stavu. Z tohoto důvodu musí být rezervační stav pravidelně, standardně každých 30 sekund, aktualizován pomocí RSVP zpráv [57]. Tyto aktualizace zároveň umožňují protokolu RSVP reagovat na změny v topologii sítě. RSVP protokol provádí rezervaci pouze v jednom směru. Přestože aplikace většinou pracuje současně jako vysílač i přijímač, RSVP tyto dvě entity logicky odděluje. 22

23 Proto je nutné při obousměrné komunikaci provést rezervaci pro oba směry zvlášť [105] Referenční model IntServ Na obr. 2.4 [24] je znázorněný referenční model technologie IntServ, který se skládá z několika funkčních bloků, které jsou třeba pro správnou funkci mechanizmu Integrovaných služeb. Tyto komponenty musí být implementovány ve směrovačích i koncových uzlech podílejících se na zajištění QoS pro dané spojení. Řízení PATH RESV Směrovací agent Rezervační agent RSVP Správce řízení Řízení PATH RESV Řízení přístupu Směrovací databáze Kontrolní databáze datových toků Řídící rovina Datová cesta Klasifikátor Plánovač paketů Výstupní fronta(y) Vstupní ovladač Přeposílání datového toku Výstupní ovladač Datová rovina Obr. 2.4: Referenční model technologie IntServ Referenční model technologie IntServ je možné rozdělit na dvě základní části - řídící rovinu a datovou rovinu [105]. Řídící rovina zajišťuje proces rezervace síťových zdrojů a datová rovina provádí předávání datových paketů na základě vytvořeného rezervačního stavu. V následujícím textu budou popsány základní funkce čtyř hlavních bloků referenčního modelu IntServ, kterými jsou rezervační agent, řízení přístupu, klasifikátor a plánovač paketů. Detailnější popis je uveden v [24], [57], [105]. Rezervační agent - tento blok vykonává veškeré funkce spojené s rezervací síťových zdrojů. Za účelem rezervace dosažení požadované úrovně služby je 23

24 potřeba v každém směrovači vytvořit a následně spravovat rezervační stav. K tomuto účelu se využívají dříve popsané zprávy protokolu RSVP. Na základě sestaveného rezervačního stavu jsou řízeny funkce v blocích klasifikátor a plánovač paketů. Řízení přístupu - funkce řízení přístupu slouží k rozhodnutí, zda bude požadavek na rezervaci zdrojů schválen nebo zamítnut. Každý síťový uzel podél celé trasy musí provést lokální rozhodnutí, zda má dostatečné množství zbývajících síťových zdrojů pro uspokojení požadavků definovaných v rezervačním profilu. Mezi síťové prostředky patří zejména požadovaná velikost vyrovnávacích pamětí a propustnost. Blok řízení přístupu v sobě může zahrnovat autentizaci žádosti o rezervaci nebo některé prioritní funkce pro zamezení situace, kdy by rezervované zdroje byly v rozporu s definovanou lokální politikou provozu [57]. Klasifikátor - jedná se o blok patřící do datové roviny, která slouží ke zpracovávání jednotlivých paketů. Hlavní funkcí klasifikátoru je rozhodování, zda patří daný paket k některému z datových toků s garantovaným zacházením a pokud ano, tak ke kterému. Každý příchozí paket musí být přiřazen některému datovému toku s rezervovanými prostředky, příp. zůstat mezi datové toky zpracované metodou Best-effort. Parametry, s kterými klasifikátor pracuje, jsou nejčastěji zdrojová a cílová IP adresa, ID (Identifikátor) protokolu vyšší vrstvy a čísla portů transportního protokolu, což jsou informace uložené v hlavičce přicházejícího paketu. Pokud je paket úspěšně přiřazen k některému z rezervovaných RSVP toků, je z kontrolní databáze datových toků získána informace o rezervačním stavu a paket je následně předán do bloku plánovače odesílání. Plánovač paketů - řídí řazení paketů do front a jejich následné odesílání na výstupní port směrovače. Plánovač paketů je ve skutečnosti zodpovědný za realizaci dojednané rezervace síťových zdrojů, proto je často považován za nejdůležitější část referenčního modelu architektury IntServ. Řazením paketů do front na základě jejich předešlé klasifikace a podle použité metody řízení jejich odesílání je plánovač schopný přímo ovlivňovat dobu, kterou paket stráví ve frontě, nebo prioritu zahození paketu při zaplnění vyrovnávací paměti [105]. Obecným úkolem plánovače paketů je tedy opakovaný výběr paketu k odeslání, v případě volné odchozí linky Modely služeb Modely služeb popisují rozhraní mezi sítí a jejími uživateli v rámci architektury rezervace zdrojů. Model služby tedy definuje, co uživatel služby může žádat od sítě a 24

25 jaký typ zdrojů může síť poskytnout [105]. Technologie IntServ definuje dva základní modely služeb - službu s řízenou zátěží a službu s garantovanými parametry, jejichž bližší popis je možné najít např. v [24], [57], [93], [105]. 2.4 Technologie Diferencovaných služeb (DiffServ) Architektura IntServ využívající protokol RSVP pro rezervaci síťových zdrojů byla dokončena v roce Téměř okamžitě se však objevily problémy s její implementací. Poskytovatelé internetového připojení argumentovali zejména vysokou složitostí a neefektivním fungováním této technologie na nízko-kapacitních linkách [45]. Mezi jednotlivými ISP platila obecná shoda, že masové nasazování mechanizmu IntServ spolu s protokolem RSVP je nepraktické a neekonomické a že je nutné hledat jednodušší a efektivnější řešení. Některé z hlavních implementačních problémů jsou rozebrány v dokumentu RFC 2208 [67]. Bylo tedy nutné nalézt řešení, které bude nabízet jednoduchý způsob rozlišení síťového provozu a zároveň nebude vyžadovat vytváření rezervačních stavů pro jednotlivé toky dat, což výrazným způsobem zatěžuje síťové uzly. V počáteční fázi tohoto hledání vznikly dva prvotní návrhy [39], [81]. Základní myšlenkou obou těchto dokumentů byl předpoklad, že každý IP paket je individuálně označen v závislosti na jeho prioritě, což umožní odlišný způsob zacházení pro pakety různých síťových služeb. Tento princip se později stal základem pro mechanizmus DiffServ [57]. Technologie DiffServ tedy využívá zcela odlišný způsob zajištění kvality služeb v IP sítích v porovnání s technologií IntServ. Základní myšlenka Diferencovaných služeb [22] je velmi jednoduchá. Jednotlivé datové toky jsou sdruženy do několika tříd podle základního charakteru služeb (viz obr. 2.5), takže síťové prvky (s výjimkou hraničních) se nemusí starat o každý datový tok zvlášť [68]. Každý IP paket vstupující do datové sítě je označen značkou, která říká, jak má být s paketem zacházeno - neboli určuje třídu přenosu poskytnutou paketu. Toto značení paketů probíhá pouze na vstupu do datové sítě. Během přenosu paketů datovou sítí další směrovače pouze přečtou značku každého paketu a dle této značky se řídí při zacházení s paketem. Značka je uložena přímo v hlavičce IP paketu, takže není potřeba žádný signalizační protokol pro vytvoření rezervačního stavu. Dále, jelikož je síťový provoz sdružován a následně zpracováván v rámci tříd, odpadá potřeba složitého třídění a plánování síťových zdrojů pro jednotlivé datové toky, jako je tomu u technologie IntServ. Počet značek, a tedy i definovaných tříd provozu, je relativně malý, obvykle jednotky, maximálně desítky. Zatímco u technologie integrovaných služeb (IntServ) udržuje každý směrovač informaci o prostředcích přidělených každému jednotlivému spojení, u rozlišovaných služeb směrovače pouze přidělí určité prostředky každé třídě 25

26 A Agregovaný datový tok B DiffServ směrovač Agregovaný datový tok C D Obr. 2.5: Základní princip technologie DiffServ přenosu a zajistí určitý vztah mezi jednotlivými třídami [100]. Např. může být stanoveno, že pakety s určitou značkou budou ve směrovači obslouženy pouze tehdy, pokud ve frontě nebudou stát pakety s jinou značkou odpovídající vyšší prioritě. V následujícím textu budou popsány dílčí bloky a funkce mechanizmu diferencovaných služeb DiffServ doména Rozsáhlé počítačové sítě se obvykle tvoří propojením menších sítí, přičemž každá síť může být řízena jiným subjektem, organizačně jinak uspořádaná a vybavená různými síťovými prvky. Proto v každé síti může docházet i k odlišnému způsobu zpracování paketů pro zajištění požadované kvality služeb. Z tohoto důvodu se rozsáhlé sítě dělí na více oblastí se samostatnou správou. Z pohledu mechanizmu diferencovaných služeb se tyto oblasti nazývají DS (DiffServ) domény [3]. Příklad DiffServ domény je zobrazen na obr Každá DS doména je spravována jedním poskytovatelem připojení ISP (Internet Service Provider) a probíhá v ní jednotná administrace, která zajišťuje vyhodnocování oprávněnosti požadavků, přiřazení toků do jednotlivých tříd a označování paketů. V rámci DS domény jsou rozlišovány dva typy směrovačů [22]: Hraniční směrovač (Edge / Boundary Router) - hraniční směrovač leží mezi dvěma DS doménami nebo na rozhraní mezi DS doménou a částí sítě, která nepodporuje mechanizmus DiffServ. Tento směrovač tedy provádí klasifikaci vstupních toků a následné označování paketů, které jsou pak dále po- 26

27 sílány do DS domény. Hraniční směrovač může v závislosti na svém umístění pracovat buď jako vstupní (Ingress) nebo výstupní (Egress) prvek. Jsou-li dvě DiffServ domény propojeny jedním směrovačem, pracuje výstupní směrovač jedné DS domény zároveň jako vstupní směrovač druhé DS domény a plní i opačné funkce pro pakety procházející v opačném směru. Páteřní směrovač (Core / Interior Router) - páteřní směrovač se nachází uvnitř DS domény a nároky na tento prvek jsou podstatně menší v porovnání s hraničním směrovačem. Páteřní směrovač neprovádí žádnou klasifikaci paketů, zajišťuje pouhé předávání označených paketů a garantuje určitou kvalitu služby definovanou značkou v hlavičce paketu. V rámci každé DS domény musí být jasně definována úroveň služby, kterou může koncový uživatel očekávat od sítě, respektive od ISP. K tomuto účelu slouží dohoda o úrovni poskytované služby - SLA, popsaná v kapitole SLA je aplikována na rozhraních mezi uživatelem a DS doménou nebo dvěma DS doménami spravovanými různými ISP (viz obr. 2.6) a jasně vymezuje povolené profily síťového provozu, podmínky zacházení s datovými toky, konkrétní síťové parametry pro jednotlivé třídy provozu atd. [105]. End-to-End DiffServ DiffServ region Hraniční směrovač Páteřní směrovač DiffServ doména 1 Hraniční směrovač SLA Hraniční směrovač DiffServ doména 2 Páteřní směrovač Hraniční směrovač SLA Páteřní směrovač Páteřní směrovač SLA Koncový uživatel Koncový uživatel Obr. 2.6: DiffServ doména 27

28 2.4.2 Indentifikátor DSCP (DiffServ Code Point) Mechanizmus DiffServ je postaven na předpokladu odlišného zacházení pro jednotlivé pakety. Aby to bylo možné, je třeba pakety nějakým způsobem od sebe odlišit. K tomu slouží jedinečný identifikátor, značka, označovaný jako DSCP. Tato značka je uložena v hlavičce IP paketu v 8-bitovém poli původně označovaném jako ToS (Type of Service) pro verzi IPv4 nebo TC (Traffic Class) pro verzi IPv6. Původní význam pole ToS včetně jeho struktury je uveden v dokumentu RFC 791 [86]. První 3 bity se označují jako IP precedence a udávají prioritu obsloužení daného paketu neboli definují pravděpodobnost jeho zahození a ovlivňují zpoždění způsobené řazením paketu do front síťového prvku [45]. Další 3 bity označují očekávanou úroveň přednostního zpracování daného IP paketu. Konkrétně se jedná o zpoždění (D - Delay), propustnost (T - Throughput) a spolehlivost (R - Reliability) zvolené trasy. Zbylé dva bity (č. 6 a 7) jsou rezervovány pro budoucí použití nebo pro experimentální účely. V případě, že je v síti použita technologie DiffServ, pak jsou původní pole ToS a TC využita pro uložení značky DSCP, která definuje způsob zacházení s daným paketem během jeho průchodu DiffServ doménou. V takovém případě se změní struktura pole ToS (TC) a toto pole je označováno jako DS pole. Velikost DS pole zůstává 8 bitů, avšak pro uložení DSCP značky se používá pouze prvních 6 bitů, zbylé dva jsou momentálně nevyužité - CU (Currently Unused), viz obr V současnosti však již existují řešení, která využívají právě tyto poslední dva bity z DS pole pro detekci blížícího se zahlcení sítě. CU bity se pak označují jako ECN (Explicit Congestion Notification) identifikátor [91], [92]. DS pole (8 bitů) DS Code Point (DSCP) 6 bitů CU 2 bity Obr. 2.7: DS pole Struktura DSCP značky je definována v RFC 2474 [80]. Díky kombinaci 6 bitů je možné získat celkem 64 jedinečných identifikátorů udávaných ve formátu xxxxxx, kde x může nabývat hodnoty 0 nebo 1. Rozsah hodnot DSCP byl rozdělen do 3 skupin. První skupina obsahuje prvních 32 DSCP hodnot, které jsou standardizované a určené pro běžné použití. Druhá skupina obsahuje dalších 16 hodnot, které jsou určené pro experimentální nebo lokální použití. Zbývajících 16 DSCP hodnot je vyhrazeno taktéž pro výzkumné nebo lokální účely, avšak může být standardizováno v případě, že dojde k vyčerpání hodnot z první skupiny [105]. 28

29 DSCP hodnota označuje konkrétní třídu provozu a zároveň označuje způsob zacházení, který je poskytnut všem paketům patřícím do této třídy. Mapování DSCP hodnot na třídy provozu je závislé na konkrétní implementaci mechanizmu DiffServ, existuje však několik doporučení uvedených např. v [18] nebo [49]. V následující tab. 2.3 je uveden jeden z možných způsobů přidělení DSCP značek jednotlivým třídám provozu [68] Způsob zacházení PHB (Per-Hop Behavior) Značka DSCP definuje konkrétní třídu provozu a na ni je navázán definovaný způsob zacházení s pakety patřícími do dané třídy. V rámci architektury Diferencovaných služeb se způsob zacházení s pakety označuje zkratkou PHB. PHB nedefinuje přímo konkrétní mechanizmy nebo způsob jejich implementace, ale obsahuje spíše obecný popis způsobu zacházení s pakety (v závislosti na DSCP) nebo specifikaci parametrů požadované služby v rámci dané DS domény [93]. Pro dosažení stejné úrovně zacházení v rámci konkrétního PHB je tedy možné použít různé fyzické implementace metod řízení front a plánování odesílání paketů [105]. V rámci technologie DiffServ jsou organizací IETF definovány čtyři typy způsobu zacházení PHB. Výchozí PHB Výchozí PHB [80] je definován pro zpětnou kompatibilitu s tradičním způsobem zacházení typu best-effort, který poskytuje všem paketům stejnou úroveň QoS. Tento způsob zacházení musí podporovat všechny DiffServ prvky. Výchozímu PHB odpovídá hodnota DSCP ve formátu Výchozí způsob zacházení PHB je nejčastěji přidělen paketům, které nespadají do žádné z definovaných tříd provozu. Class Selector PHB Druhým způsobem zacházení je CS (Class Selector) PHB, který je definován v [80]. CS PHB je definován kvůli snaze o zpětnou kompatibilitu s původní strukturou pole IP ToS a zejména pak s jeho částí označovanou jako IP precedence. Jak již bylo popsáno v kapitole 2.4.2, IP precedence je 3-bitové pole udávající prioritu obsloužení daného paketu. Aby byla zajištěna koexistence starších QoS implementací, které využívají pole IP precedence, spolu s technologií DiffServ, byl definován Class Selector PHB, kterému odpovídají DSCP ve formátu xxx000, kde x reprezentuje hodnotu 0 nebo 1. 29

30 Pro CS PHB je tedy vyhrazeno 8 DSCP značek. Mapování mezi těmito 8 DSCP značkami a konkrétními třídami provozu je závislé na dané implementaci, avšak hodnoty a musí mít vždy zajištěnu vyšší prioritu zacházení v porovnání s defaultním PHB. Tyto dvě hodnoty DSCP odpovídají hodnotám IP precedence 111 a 110, které se běžné používají pro služby typu řízení sítě nebo signalizace. Přednostní zacházení definované pro tyto dvě DSCP značky zachovává původní způsob použití hodnot IP precedence [82]. Expedited Forwarding PHB Způsob zacházení EF (Expedited Forwarding) je definován v RFC 2598 [53]. EF PHB je určen pro síťové služby vyžadující nízké zpoždění, jitter a ztrátovost. Je tedy vhodný zejména pro služby pracující v reálném čase, neboť představuje nejvyšší úroveň zacházení. EF PHB je však poměrně složitý na řízení a konfiguraci, proto se využívá pro zajištění QoS pouze u vybraných kritických aplikací. V současnosti nejčastějším typem služby, pro který je využíván EF PHB je VoIP. Aby bylo možné splnit přísné požadavky na zmíněné parametry provozu, je třeba pro PHB typu EF zajistit prioritní obsluhu odpovídající fronty DS směrovače. Nejčastěji je tato prioritní obsluha implementována formou prioritní fronty, jejíž pakety budou vždy obslouženy přednostně [57]. Poskytnutí PHB typu EF danému toku však současně znamená vyhrazení téměř všech síťových prostředků, což pak může vést k neefektivnímu využívání prostředků sítě. Urychlené doručení, jak je EF někdy překládán, by tedy mělo být využíváno jen pro datové toky, které tvoří malou část z celkové síťového provozu. Z hlediska praktické implementace je dále velice žádoucí, aby tato prioritní fronta měla uměle omezenou propustnost, např. využitím mechanismu rate-limiting. Assured Forwarding PHB AF (Assured Forwarding) PHB je definován v dokumentu RFC 2597 [53]. Hlavním cílem způsobu zacházení Assured Forwarding je doručení paketů, a proto zpoždění paketů nebo jitter nejsou tak důležité jako míra ztrátovosti, což je zásadní rozdíl oproti EF PHB. Způsob zacházení AF tedy představuje vysokou úroveň garance, že daný paket bude doručen, pokud agregovaný provoz nevybočuje z podmínek dohodnutých v SLA. Síťový provoz překračující dohodnuté podmínky má vysokou pravděpodobnost zahození. Pokud je však i přesto přenesen přes síť, pak vždy zůstává zachováno pořadí všech přenesených paketů, což představuje další rozdíl oproti způsobu zacházení EF, kde mohou být pakety vybočující z daného profilu provozu zahozeny nebo doručeny mimo pořadí [57]. 30

31 Tab. 2.3: Příklad mapování DSCP hodnot na konkrétní typy síťových služeb Typ služby Třída provozu DSCP Vzorová aplikace (PHB) hodnota Telefonie EF IP telefonie AF Multimediální AF Videokonference konference AF AF Multimediální streamování AF Audio a video streaming AF Data vyžadující AF Webové služby typu nízké zpoždění klient-server AF AF AF Data vyžadující AF Webové služby typu vysokou propustnost klient-server AF Standardní data BE (výchozí) Není specifikováno Z tohoto pohledu je tedy AF PHB vhodnější pro služby, které nepracují v reálném čase, jako například aplikace využívající protokol TCP [82]. AF PHB se dále dělí na čtyři třídy - AF1, AF2, AF3 a AF4. V rámci každé třídy jsou pakety zařazeny do některé ze tří podtříd s odpovídající úrovní pravděpodobnosti zahození [50]. Rozdíly mezi třídami jsou nejčastěji dány propustností garantované pro jednotlivé třídy. Třída AF4 by tedy měla mít garantovánu největší propustnost a naopak třída AF1 nejmenší, tím pádem pakety zařazené do třídy AF1 mají menší pravděpodobnost doručení než pakety ve třídě AF4 [93]. Obecný formát značení AF tříd je AFxy, kde x označuje třídu doručení (1 až 4) a y označuje prioritu zahození v rámci dané třídy. Priorita zahození je definována hodnotami 1, 2 nebo 3, kdy 1 představuje nízkou a 3 vysokou pravděpodobnost zahození [53]. Podtřída AF33 má tedy větší prioritu zahození než podtřída AF31. 31

32 2.4.4 Referenční model DiffServ Referenční model technologie DiffServ je definován v RFC 2475 [22] a také v RFC 3290 [22]. Model diferencovaných služeb se skládá z několika bloků, které jsou stavebními kameny celého mechanizmu. Referenční model DiffServ je zobrazen na obr. 2.8 a je možné jej rozdělit na dvě základní části. Na část klasifikace, kde probíhá třídění a značkování paketů a část pro úpravu provoz, která na základě parametrů provozu a DSCP značek přidělených jednotlivým paketům rozhoduje o jejich dalším zpracování [105]. Přeznačovač Vstupní rozhraní přicházející pakety Třídič Značkovač Klasifikace provozu Měřič Tvarovač Zahazovač Výstupní rozhraní zpracované pakety Úprava provozu zahozené pakety Obr. 2.8: Referenční model technologie DiffServ Třídič (Classifier) Hraniční prvky DiffServ sítě jsou zodpovědné za mapování paketů do některé z podporovaných tříd provozu. Tuto funkci vykonává blok třídič, který provádí identifikaci přicházejících paketů a jejich následné dělení do několika skupin podle předem definovaných pravidel. Existují dva základní druhy třídičů [22]: BA (Behavior Aggregate) - patří mezi nejjednodušší DiffServ třídiče. Tento třídič vybírá pakety pouze na základě DSCP značky umístěné v DS poli v hlavičce IP paketu. Tento typ klasifikace se implicitně používá v případě, kdy byl paket označen dříve, než dorazil na vstupní rozhraní směrovače [22]. MF (Multifield) - druhý typ třídiče vybírá pakety na základě jednoho nebo více kritérií, jako může být například IP zdrojová adresa, cílová IP adresa, zdrojový a cílový TCP/UDP port nebo identifikátor zapouzdřeného protokolu, 32

33 atd. MF třídič je flexibilnější a je možné jej použít pro složitější politiku alokace síťových zdrojů [22]. Značkovač (Marker) Jakmile jsou pakety roztříděny do jednotlivých tříd, přicházejí do bloku značkovače, kde jsou označeny DSCP značkou odpovídající dané třídě provozu [22]. Podle přidělené hodnoty DSCP má každý paket definován způsob zacházení PHB, který určuje úroveň zajištění QoS. Jednotlivé typy PHB byly popsány v kapitole Měřič (Meter) Funkce části referenčního modelu DiffServ označené jako úprava provozu zajišťují dohled nad síťovým provozem. Hraniční směrovače musí provádět kontrolu, zda síťový provoz přicházející od zákazníka je v souladu s předem dohodnutými podmínkami definovanými mezi koncovým zákazníkem a poskytovatelem služby. Ty pakety, které odpovídají dohodnutému profilu služby, jsou odeslány na výstup směrovače směrem do sítě. Při překročení dohodnutých podmínek pro daný typ provozu jsou pakety dále zpracovávány, přičemž může nastat jejich přeznačení (Remaker), tvarování (Shaper) nebo zahození (Dropper) [22]. Aby mohla být prováděna kontrola přicházejících datových toků, je třeba definovat konkrétní síťové parametry a také způsob jejich měření. Nejčastěji se jedná o následující dva parametry provozu: Maximální okamžitá přenosová rychlost PIR (Peak Information Rate) - označuje maximální povolený (na základě SLA) počet bitů, které mohou být uživatelem vyslány v daný okamžik. Nejčastěji PIR odpovídá maximální přenosové rychlosti zákaznické linky. PIR je udávána v bajtech za sekundu. Převrácená hodnota 1/PIR udává minimální dobu mezi příchody dvou po sobě jdoucích paketů [82]. Garantovaná průměrná přenosová rychlost CIR (Commited Information Rate) - označuje průměrnou přenosovou rychlost, kterou poskytovatel připojení garantuje zákazníkovi. Stejně jako PIR, i CIR je udávána v bajtech za sekundu. PIR i CIR se měří pouze na úrovni síťové vrstvy, což znamená, že se do výpočtu nezahrnují hlavičky nižších vrstev [82]. Spolu s maximální okamžitou a garantovanou průměrnou přenosovou rychlostí jsou definovány další tři parametry provozu, které slouží jako pomocné parametry při měření PIR a CIR. Konkrétně se pak jedná o velikost garantovaného shluku CBS (Committed Burst Size), velikost nadměrného shluku EBS (Excess Burst Size) a velikost maximálního shluku PBS (Peak Burst Size) [82]. 33

34 CBS tedy udává maximální množství paketů udávané v bajtech, které může být přeneseno rychlostí PIR v rámci jednoho shluku, aniž by došlo k překročení CIR. EBS označuje prahovou hodnotu pro shluk, který překročí velikost CBS, to znamená, že CBS < EBS. CBS a EBS jsou používány ve spojení s měřením přenosové rychlosti CIR. Parametr PBS má obdobný význam jako CBS, avšak je definován ve spojitosti s rychlostí PIR. Parametry CBS, EBS i PBS jsou udávány v bajtech [82]. Mechanizmus Token Bucket Základním algoritmem většiny implementací části úpravy provozu v architektuře diferencovaných služeb je mechanizmus TB (Token Bucket). Jedná se o algoritmus využívající principu kreditů (tokenů) pro tvarování provozu a řízení objemu dat, který může být přenesen přes síťový prvek [48]. TB je nejčastěji popisován jako virtuální nádoba, která obsahuje určitý počet tokenů. Tokeny jsou do nádoby doplňovány konstantní rychlostí. Přicházející paket může být odeslán na výstupní rozhraní směrovače pouze v případě, že je v nádobě dostatečný počet tokenů, který je roven minimálně velikosti příchozího paketu. Jinými slovy, token představuje povolení pro odeslání určitého množství dat dále do sítě [57]. Při každém zpracování jednoho paketu je z nádoby odebráno množství tokenů odpovídající velikosti paketu. Token Bucket, viz obr. 2.9, je tedy definován rychlostí doplňování tokenů r a velikostí nádoby b. Největší povolený shluk přicházejících paketů pak tedy odpovídá objemu nádoby a průměrná rychlost příchodu paketů odpovídá rychlosti doplňování tokenů [98]. Pokud průměrná rychlost paketů překročí rychlost doplňování tokenů do nádoby nebo velikost shluku přicházejících paketů překročí velikost nádoby, dojde k dočasnému vyprázdnění nádoby, což vede k pozdržení nebo přímému zahození zpracovávaného paketu [57]. Proces měření a následné označování (nebo přeznačování) paketů na základě výsledků měření spolu velmi úzce souvisí a proto bývají často implementovány v rámci jednoho mechanizmu. Kombinace procesů měření a nastavení odpovídající značky je označována pojmem barvení. V současnosti jsou nejčastěji využívány dvě metody barvení: jedna rychlost - 3 barvy (srtcm - Single Rate Three Color Marker) a dvě rychlosti - 3 barvy (trtcm - Two Rate Three Color Marker). Základem obou těchto metod je mechanizmus Token Bucket. Metoda barvení paketů srtcm (Single Rate Three Color Marker) Metoda barvení paketů srtcm je definována v RFC 2697 [54]. Základní princip metody srtcm spočívá v tom, že je prováděno měření IP toku a na základě výsledků tohoto měření jsou jeho pakety označeny (obarveny) zelenou, žlutou nebo červenou barvou. Barvení je založená pouze na jedné rychlosti CIR a dvou přidružených parametrech CBS a EBS. 34

35 Tokeny jsou doplňovány konstantní rychlostí Velikost nádoby udávající maximální velikost shluku Nepravidelně přicházející pakety Přenesené pakety a odpovídající počet odebraných tokenů Zahozené pakety překročující sjednané parametry na rychlost Obr. 2.9: Mechanizmus Token Bucket Paket je označen jako zelený, pokud nepřesáhne definovanou velikost CBS. Žlutá barva je použita pro pakety, které překročí CBS, ale současně nepřekročí velikost EBS. Všechny ostatní pakety jsou obarveny červeně [54]. Metoda srtcm pracuje ve dvou režimech - nezohledňující barvu a zohledňující barvu. Režim nezohledňující barvu předpokládá, že pakety vstupující do měřiče nejsou obarvené. Naproti tomu režim zohledňující barvu předpokládá, že paket již byl obarven některým z předcházejících síťových prvků. Hlavním cílem metody srtcm je dohled, aby dlouhodobá průměrná rychlost příchodu dat od uživatele byla v souladu s CIR. K tomuto účelu jsou použity dva pomocné parametry - CBS a EBS. Každý z těchto parametrů představuje velikost nádoby u jednoho mechanizmu Token Bucket. Metoda srtcm tedy využívá dvě TB implementace, Token Bucket C a Token Bucket E. Maximální velikosti nádob jsou pak analogicky T c = CBS (pro Token Bucket C) a T e = EBS (pro Token Bucket E). Rychlost doplňování tokenů do obou nádob je rovna rychlosti CIR. Proces vyhodnocování příchozích paketů pro režim nezohledňující barvu je zobrazen na obr a pro režim zohledňující barvu na obr [82]. Výsledná barva paketu zpracovaného metodou srtcm je zakódována do DSCP značky uložené v DS poli. V případě způsobu zacházení AF PHB může barva představovat prioritu zahození paketu [54]. 35

36 Označený odchozí paket Neoznačený příchozí paket T c < B B bajtů Porovnání B s T c a T e T c B T e B T e < B Zelená Žlutá Červená Obr. 2.10: Metoda barvení paketů srtcm - režim nezohledňující barvu Výstupní barva Vstupní barva T c B T e B T c < B T e < B Červená Červená Červená Červená Žlutá Žlutá Žlutá Červená Zelená Zelená Žlutá Červená Obr. 2.11: Metoda barvení paketů srtcm - režim zohledňující barvu Metoda barvení paketů trtcm (Two Rate Three Color Marker) Metoda barvení paketů trtcm je definována v RFC 2698 [55]. Jedná se o rozšíření metody srtcm, které umožňuje kontrolu dodržování nejen průměrné rychlosti CIR ale také maximální okamžité rychlosti PIR. Metoda trtcm pracuje také v režimu nezohledňujícím barvu a režimu zohledňujícím barvu. Pro měření jsou kromě rychlostí CIR a PIR použity také pomocné parametry CBS a PBS. Metoda barvení paketů trtcm stejně jako metoda srtcm využívá dva Token Buckety. První je Token Bucket C s maximální velikostí nádoby T c = CBS a rychlostí doplňování tokenů odpovídající rychlosti CIR. Druhý je Token Bucket P s velikostí nádoby T p = PBS a rychlostí doplňování PIR. Paket je označen jako červený, pokud je překročena hodnota PIR. Jinak je paket označen žlutě nebo zeleně v závislosti, zda je překročena rychlost CIR [55]. Proces 36

37 vyhodnocování příchozích paketů metodou trtcm pro režim nezohledňující barvu je zobrazen na obr a pro režim zohledňující barvu na obr [82]. Barevně neoznačený příchozí paket Barva ochozího paketu T p B T p < B B bajtů Porovnání s T p Porovnání s T c T c < B Žlutá Červená T c B Zelená Červená Obr. 2.12: Metoda barvení paketů trtcm - režim nezohledňující barvu Vstupní barva T c B T p B T c < B T p < B Červená Červená Červená Červená Žlutá Žlutá Žlutá Červená Zelená Zelená Žlutá Červená Obr. 2.13: Metoda barvení paketů trtcm - režim zohledňující barvu Přeznačovač (Remaker) Funkce přeznačovače byla částečně rozebrána již v předchozím textu. K přeznačení paketu může dojít na základě nesplnění kritérií pro definovanou třídu provozu. Většinou se tedy pro tyto nevyhovující pakety nastaví jiná DSCP značka představující vyšší prioritu zahození při případném zahlcení sítě v dalších směrovačích. Dalším důvodem k přeznačení paketů může být jejich přechod mezi dvěma DS doménami, které používají odlišný způsob třídění provozu [22]. Tvarovač (Shaper) Tvarovač má za úkol přenést datový tok v souladu se sjednaným datovým profilem. To se nejčastěji provádí pozdržením nevyhovujících paketů v paměti síťového prvku za účelem vytvarování datového toku do podoby vyhovující definovaným podmínkám. Rozdíl mezi tvarovačem a značkovačem je v tom, že značkovač jednoduše označí 37

38 paket a nechá jej 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 [105]. Vlivem pozdržení paketů ve frontě narůstá zpoždění přenosu a jitter, což však může mít nepříznivý vliv na služby pracující v reálném čase. Stejně jako přeznačení, tak i tvarování je důležitý proces v hraničním uzlu mezi dvěma DiffServ doménami [21]. Zahazovač (Dropper) Výsledkem barvení může být rozhodnutí, že daný paket odporuje dohodnutým parametrům provozu a má být zahozen. Tuto funkci provádí blok zahazovače. Zahazovač realizuje jednodušší metodu zpracování paketů než tvarovač, neboť nepotřebuje vyrovnávací paměť [21] Plánované odesílání paketů Plánované odesílání paketů umožňuje prioritní zacházení pro vybrané třídy síťového provozu, což je základní myšlenka téměř všech technologií pro zajištění kvality služeb. Proto je plánované odesílání paketů srdcem každého QoS mechanizmu, neboť právě tento proces má zásadní vliv na výslednou úroveň kvality uživatelské aplikace [82]. Pojmem plánované odesílání paketů jsou většinou označeny dva úzce související procesy - proces řazení paketů do front a proces řízeného odesílání, který rozhoduje, který paket bude odeslán na výstupní rozhraní síťového prvku [100]. Plánované odesílání paketů je u technologie DiffServ prováděno na základě DSCP značky a k ní přidruženému způsobu zacházení PHB. Proces řízeného odesílání paketů není standardizovaný, ale je závislý na typu zařízení od určitého výrobce. Je definováno pouze několik základních požadavků, které by měla každá metoda plánovaného odesílání paketů splňovat. Jedním ze základních požadavků je spravedlivé rozdělování dostupné šířky pásma mezi datové toky v souladu s prioritním systémem implementovaným do správy front [82]. Funkce plánovaného odesílání paketů je aplikována na každém výstupním rozhraní DiffServ směrovače. V následujícím textu budou rozebrány základní principy nejčastěji používaných metod plánovaného odesílání paketů. FIFO (First In First Out) FIFO je nejstarší a nejjednodušší metoda řazení a následného odesílání paketů, která je založená na jednoduchém algoritmu, který řadí přicházející pakety podle času jejich příchodu [48]. Jak je již z názvu zřejmé, paket, který první přijde, je také jako první odeslán na výstup, viz obr [82]. 38

39 Klasifikace paketů Fronta FIFO Řízení odesílání paketů Výstupní port Obr. 2.14: Algoritmus First In First Out Metoda FIFO je také někdy označovaná jako FCFS (First Come First Serve). Jedná se o nejrozšířenější metodu obsluhy paketů uvnitř síťových prvků, která však neposkytuje možnost zvýhodnění některého typu provozu, neboť poskytuje všem paketům stejný způsob zacházení [57]. Z tohoto důvodu se FIFO nejlépe hodí pro výchozí způsob zacházení Best-effort. Jedinou výhodou tohoto mechanizmu je jednoduchá implementace. PQ (Priority Queuing) Metodou, která již přináší možnost prioritizace vybraného typu provozu, je PQ. V rámci tohoto algoritmu je definováno několik FIFO front s přidělenou úrovní priority. Pakety z vybrané fronty s určitou úrovní priority mohou být odeslány na výstupní rozhraní směrovače pouze tehdy, pokud jsou všechny fronty s vyšší prioritou prázdné. Princip algoritmu PQ je zobrazen na obr [82]. Výhodou metody PQ je, podobně jako u FIFO, její jednoduchá implementace. Naproti tomu, hlavní nevýhodou je fakt, že pokud je vysoce prioritní provoz zastoupen v síti velkým dílem, pak fronty s nízkou prioritou nemusí být nikdy obslouženy. Prioritní systém front by tedy měl být používán velmi opatrně a fronty s vysokou prioritou by měly být vyhrazeny pouze pro menšinový typ síťového provozu [45]. Priorita 1 Priorita 2 Řízení odesílání paketů Klasifikace paketů Priorita M Výstupní port Obr. 2.15: Algoritmus Priority Queuing 39

40 FQ (Fair Queuing) U algoritmu FQ, někdy také označovaného jako RR (Round Robin), jsou pakety řazeny do N front. Každé z těchto front je přidělena část celkové propustnost výstupního portu o velikosti 1/N. Všechny fronty jsou pak cyklicky obsluhovány v pevně daném pořadí (prázdné fronty jsou přeskakovány). Z každé navštívené fronty je vždy odeslán jeden paket. Princip metody spravedlivé obsluhy je zobrazen na obr [82]. Pevně dané pořadí cyklické obsluhy Fronta 1 Fronta 2 Řízení odesílání paketů Klasifikace paketů Fronta M Výstupní port Obr. 2.16: Algoritmus Fair Queuing Implementace algoritmu FQ je jednoduchá, neboť není vyžadován speciální mechanizmus pro alokaci přenosové kapacity. Pokud je přidána nová fronta k N existujícím frontám, plánovač automaticky nastaví pro každou frontu novou velikost propustnosti, která bude odpovídat 1/(N + 1) z celkové propustnosti výstupního portu. Spravedlivá obsluha má však také dvě hlavní nevýhody. První nevýhoda vychází právě ze spravedlivého dělení celkové propustnosti mezi jednotlivé fronty. Není totiž možné poskytnout odlišnou propustnost pro služby s různými požadavky [82]. Druhá nevýhoda spočívá v tom, že metoda FQ bude skutečně spravedlivá jen v případě, že budou ve všech frontách pakety se stejnou velikostí. To je však pouze ideální situace a praxe je poněkud odlišná. Fronty obsahující pakety s větší velikostí ve skutečnosti zaberou větší přenosovou rychlost než je původně přidělená část 1/N [48]. WRR (Weighted Round Robin) První uvedenou nevýhodu algoritmu FQ řeší algoritmus WRR, který je schopný vyhradit rozdílnou část celkové kapacity výstupního portu pro třídy provozu s odlišnými požadavky. Tento mechanizmus je někdy označován také jako CBQ (Class- Based Queuing) nebo také CQ (Custom Queuing) [82]. 40

41 Mechanizmus vážené spravedlivé obsluhy je zobrazen na obr Vstupní datové toky jsou rozděleny do m tříd, kdy je každé třídě přidělena určitá část celkové propustnosti výstupního portu v závislosti na váze přidělené dané třídě. Jednotlivé váhy jsou odvozeny od skutečných požadavků konkrétní třídy. Součet váhových hodnot všech tříd je roven 100% dostupné šířky pásma, tj. (2.1) m w i = 100%, (2.1) i=1 kde m je celkový počet tříd a w i je váhová hodnota přiřazená i-té třídě [82]. Alokace šířky pásma pro každou třídu může být provedena pomocí procentuálního rozdělení času, který je použit pro obsluhu dané třídy. V rámci každé třídy je definováno N front se spravedlivou obsluhou FQ. Algoritmus WRR tedy využívá dvojitý systém obsluhy typu Round Robin. První RR je použit pro výběr třídy od 1 až do m a druhý RR slouží pro obsluhu front uvnitř dané třídy. Mechanizmus WRR sice řeší jeden z nedostatků algoritmu FQ, kterým je neschopnost rozdělit celkovou propustnost podle skutečných požadavků jednotlivých tříd, avšak problém s velikostí paketů zůstal. Pokud některá z front bude obsahovat delší pakety v porovnání s ostatními, pak tato fronta získá vyšší přenosovou rychlost, než jí bylo původně přiděleno [48]. WFQ (Weighted Fair Queuing) Zmíněný vliv délky paketu na skutečně přidělenou část celkové propustnosti řeší až algoritmus WFQ. U tohoto mechanizmu jsou vstupující pakety rozděleny do N front. Na základě váhových hodnot jednotlivých front je jim přidělena odpovídající část celkové propustnosti. Součet všech váhových hodnot je opět na základě rovnice (2.1) roven 100%. Zatímco u algoritmu FQ je z právě obsluhované fronty odeslán vždy jeden celý paket, u WFQ se plánovač snaží odesílat pakety z front tak, aby odesílání skončilo v době vypočítané dle teoretického modelu zohledňujícího délku paketů. Tento teoretický model se označuje jako vážená bitová cyklická obsluha WBBRR (Weighted Bit-by-Bit Round Robin). WBBRR využívá mechanizmu, kdy jsou cyklicky obsluhovány jednotlivé fronty, ale pakety nejsou na výstup odesílány v celku, ale bit po bitu. Tyto bity jsou pak zachyceny v bloku složení paketu a odtud jsou teprve odeslány na výstup. Větší paket tedy musí cekat delší dobu, aby byl znovu složen. [82]. Jak je vidět z obr. 2.18, WFQ se snaží vypočítat dobu (na základě modelu vážené bitové cyklické obsluhy), kdy má skončit přenos daného paketu a vlastní odesílání pak řídí tak, aby pakety byly odesílány právě v souladu s touto vypočítanou dobou konce odesílání [82]. Tento systém spravedlivé alokace kapacity rozhraní zohledňující velikost paketů však s sebou přináší také výraznou výpočetní náročnost a složitou 41

42 Počet front se spravedlivou obsluhou Pevně dané pořadí cyklické obsluhy Třída 1 N 1 W 1 Třída i Řízení odesílání paketů Klasifikace paketů N i W i Třída m N m W m Výstupní port Obr. 2.17: Algoritmus Weighted Round Robin implementaci. I přesto se však jedná o jeden z nejpoužívanějších algoritmů pro plánované odesílání paketů v rámci technologie DiffServ. Datový tok Fronta 1 Klasifikace paketů P 1,k P 1,1 Fronta 2 P 2,l P 2,1 Řízení odesílání paketů Odhad doby ukončení přenosu paketů P i,j Fronta M P N,M P N,1 Výstupní port Obr. 2.18: Algoritmus Weighted Fair Queuing 42

43 2.4.6 Aktivní správa front Výše popsané mechanizmy pro plánované odesílání paketů využívají front s pevně danou délkou. Pokud dojde k zaplnění fronty, jsou nově příchozí pakety zahazovány. Jsou definovány dva přístupy, jak tento stav řešit - pasivní a aktivní správa front [82]. Pasivní správa front je nejstarší a zároveň také nejjednodušší způsob řešení problému se zaplněním front síťových prvků. Je využíváno jednoduchého mechanizmu, označovaného jako tail-drop, kdy jsou v případě zaplnění fronty zahazovány pakety, které dorazily do směrovače jako poslední [23]. Strategie zahazování typu tail-drop má však nepříznivý vliv na služby využívající TCP protokol. Vzhledem k schopnostem protokolu TCP reagovat na zahlcení sítě a mechanizmu opakovaného vysílání ztracených segmentů může dojít k jevu, který se označuje jako globální synchronizace protokolu TCP. Tento jev pak způsobuje neefektivní využívání síťových zdrojů [82]. Jako prevence proti globální synchronizaci TCP protokolu se používá aktivní správa front AQM (Active Queue Management). Mechanizmy AQM se snaží detekovat vznik blížícího se zahlcení a reagovat na tuto situaci ještě předtím, než dojde k úplnému zaplnění front síťového prvku. V následujícím textu jsou popsány dva základní algoritmy aktivní správy front používané ve spojení s mechanizmem DiffServ. RED (Random Early Detection) Algoritmus předčasné detekce s náhodným zahazováním RED se snaží detekovat blížící se stav zahlcení a reagovat na to tím, že zahazuje pakety dříve, než dojde k úplnému zaplnění front směrovače. Mechanizmus RED provádí v pravidelných časových intervalech výpočet vážené průměrné velikosti fronty η N podle rovnice (2.2) η i = (η i 1 * (1 2 x )) + (v i * 2 x ), (2.2) kde η i je vážená průměrná velikost fronty, η i 1 je předchozí hodnota průměrné velikosti fronty, x je exponenciiální váhový faktor a v i je aktuální velikost fronty. Na základě výsledků tohoto měření je vypočítáno podle rovnice (2.3) α = η i 1 (2.3) B procentuální využití vyrovnávací paměti daného síťového prvku. B označuje celkovou kapacitu vyrovnávací paměti. Velikost procentuálního využití vyrovnávací paměti α je předána do bloku profilu zahazování, kde je stanovena pravděpodobnost zahození paketu p. Základem funkce pro výpočet pravděpodobnosti zahození je míra 43

44 využití celkové propustnosti daného spojení. Princip fungování mechanizmu RED je zobrazen na obr [82]. Procentuální využití vyrovnávací paměti α Modul predikce úrovně zahlcení Profil zahazování paketů Okamžitá délka fronty N Náhodně vybraný paket k zahození Blok zahazování paketů Pravděpodobn ost zahození paketů p Přichozí pakety Délka fronty - N Kapacita vyrovnávací paměti - B Obr. 2.19: Princip fungování mechanizmu RED Na obr je ukázka profilu zahazování paketů. Oranžová křivka udává závislost pravděpodobnosti zahození paketu na míře zaplnění vyrovnávací paměti. K zahazování paketů nedochází v případě, kdy se vypočítané procentuální využití vyrovnávací paměti α nachází pod stanovenou minimální hodnotou α min. Pokud je α v rozmezí daném rovnicí (2.4): α min < α < α max, (2.4) pak je aktivován mechanizmu náhodného zahazování. Pokud α překročí hodnotu α max, aktivuje se algoritmus zahazování tail-drop [82]. WRED (Weighted Random Early Detection) Mechanizmus RED používá pro všechny třídy provozu stejný profil zahazování paketů, což není z pohledu zajištění QoS příliš vhodné [11]. Proto byl navržen algoritmus předčasné detekce s váženým náhodným zahazováním WRED. Jedná se o rozšíření mechanizmu RED, které umožňuje definovat pro každou třídu provozu 44

45 p 1 Aktuální pravděpodobnost zahození paketu p i 0 0% α min Aktuální α max Aktivace metody WRED využití paměti α i Ukončení metody WRED a aktivace metody tail-drop 100% α Obr. 2.20: Profil zahazování mechanizmu WRED samostatný profil zahazování paketů. Díky tomu je možné dosáhnout rozdílné pravděpodobnosti zahození paketů v rámci jedné fronty [82]. Na obr je ukázán příklad tří WRED profilů zahazování paketů pro tři různé způsoby zacházení AF1x. Algoritmy RED a WRED zabraňují vzniku globální synchronizace protokolu TCP, avšak na UDP toky nemají tyto způsoby zahazování žádný vliv, neboť protokol UDP není schopný regulovat rychlost odesílání datagramů. Pokud je tedy síťový provoz tvořen převážně službami využívajícími UDP protokol, pak použití mechanizmů aktivní správy front ztrácí smysl [45]. 2.5 Technologie MPLS Technologie MPLS (Multi-Protocol Label Switching) je dalším velice perspektivním řešením pro zajištění kvality služeb. MPLS spojuje efektivitu paketového přenosu s vysokou rychlostí přepojování datových jednotek na základě jednoduchých a krátkých záznamů v přepojovacích tabulkách. Řadu let byly pro datové sítě vyvíjeny přenosové technologie, které se soustředily na co nejefektivnější využití sdílených přenosových médií. U těchto technologií však měla míra využití sdílených prostředků jednoznačnou prioritu nad přenosovými parametry zajišťovanými komunikační sítí. 45

46 Pravděpodobnost zahození paketu p [-] 1 AF13 AF12 AF11 0,25 0,2 0, Průměrná délka fronty η N [pakety] Obr. 2.21: Ukázka WRED profilů pro 3 různé třídy provozu AF11, AF12 a AF13 Většina prvních síťových aplikací tento charakter přenosu také plně respektovala. Nárůstem výkonu koncových stanic a přenosových kapacit síťových spojení se začínaly objevovat služby, kterým klasický "best-effort"způsob zpracování paketů přestal být vyhovujícím. Iniciativy na sloučení efektivity paketového přenosu s rostoucími požadavky na zajištění kvality služeb postupně vedly k rozšíření technologií Frame-Realy, ATM (Asynchronous Transfer Mode) a MPLS. Společnou vlastností všech těchto konvergovaných technologií je, že jsou datové jednotky přenášeny po předem vybudovaných virtuálních cestách. Tyto cesty jsou reprezentovány jednoduchými záznamy v přepojovacích tabulkách síťových uzlů. Oproti klasickému směrování v paketových sítích eliminují tyto tabulky potřebu zdlouhavé analýzy hlavičky paketů a následného hledání cesty k cíli. Zjednodušené hledání vhodného výstupního rozhraní má za následek rychlejší zpracování datových jednotek a navíc umožňuje sestavit různé virtuální cesty pro různé datové toky. V současnosti je nejpokročilejší technologií pracující na tomto principu technologie MPLS neboli přepojování podle návěstí. MPLS je mechanizmus umožňující přepojování a přenos paketů a rámců na základě předem definovaného návěstí. Standard technologie MPLS je definován v [95]. MPLS pracuje v rámci referenčního modelu OSI/ISO mezi linkovou a síťovou vrstvou a je možné ho využívat pro různé síťové technologie jako např. Ethernet, Frame Relay, PPP (Point to Point Protocol) nebo ATM. Mezi hlavní výhody této tech- 46

47 nologie patří možnost vytváření virtuálních privátních sítí VPN (Virtual Private Network), zajištění kvality služeb [83] a relativně jednoduchá správa přepojovacích tabulek MPLS návěstí Na vstupu do MPLS sítě je každý paket doplněn 32 bitovým polem, uvnitř kterého se nachází 20 bitové návěstí. Na základě tohoto návěstí probíhá přepojování paketu v rámci celé sítě. Mechanizmus přepojování podle návěstí bývá často spojen s řídícími moduly, které umožňují poskytnout určitému typu síťového provozu požadovanou prioritu a úroveň kvality služby. Na obr je zobrazena struktura MPLS návěstí [95] L EXP S TTL Ethernet / PPP MPLS IP Data Obr. 2.22: Struktura MPLS návěstí L (Label) - 20 bitové návěstí, na základě kterého probíhá přepojování paketů. EXP (Experimental) - 3 bitové pole určené pro experimentální použití. Často ho využívají mechanismy pro zajištění kvality služeb. S (Bottom of Stack) - 1 bitový identifikátor hlavičky zapouzdřeného MPLS rámce v druhém MPLS rámci. TTL (Time To Live) - 8 bitové pole udávající dobu života paketu MPLS Architektura MPLS sítě Uzavřená síť směrovačů, přes které je možné vybudovat virtuální spojení technologie MPLS, je označena pojmem MPLS doména. Funkce směrovačů se v MPLS doméně liší podle toho, zda pracují na hranici nebo uvnitř MPLS domény. Na vstupu resp. výstupu MPLS domény se nacházejí hraniční směrovače LER (Label Edge Router), které generují jednotlivá návěstí, přiřazují je přicházejícím paketům a odstraňují je z paketů, které opouštějí doménu. Základní mechanizmus přepojování podle návěstí je 47

48 uvnitř domény zajišťován pomocí páteřních směrovačů LSR (Label Switched Router). Směrovače LSR provádějí přepojování síťového provozu po předem definované trase označované jako LSP (Label Switched Path). Trasa LSP tak určuje sekvenci MPLS směrovačů, přes které prochází datový tok od zdroje k cíli [95]. Tyto cesty jsou přidružené ke konkrétním MPLS návěstím. Z praktického hlediska představují trasy LSP spojově orientovanou překryvnou síť vybudovanou nad klasickou datovou, zpravidla IP, sítí. Na obr je zobrazen příklad architektury MPLS sítě. Koncové stanice Koncové stanice LSR LSR Zdroj LER LER LSR LSR LSP LSR Cíl MPLS doména Obr. 2.23: Architektura MPLS sítě Při vstupu do MPLS sítě hraniční směrovač LER zařadí paket do některé třídy FEC (Forwarding Equivalence Class) a na základě této třídy je mu přiděleno odpovídající MPLS návěstí. Návěstí tedy označuje FEC skupinu, do které je paket zařazen. Volba FEC skupiny je nejčastěji prováděna na základě cílové IP adresy analyzovaného paketu, případně podle třídy služby QoS nebo VPN sítě. Klasifikace paketů a přidělování návěstí probíhá pouze na vstupu do sítě. Páteřní směrovače pouze zajišťují přepojování paketů na základě návěstí a definované cesty LSP. V rámci MPLS sítě se tedy páteřní směrovače již dále nezajímají o cílovou IP adresu paketu, ale pracují pouze s přiřazeným návěstím. Páteřní směrovač přijme paket s návěstím, v přepojovací tabulce označované jako LFIB (Label Forwarding Information Base) vyhledá záznam odpovídající danému návěstí a podle tohoto záznamu odešle paket na příslušné výstupní rozhraní. Směrovač přitom může provést změnu hodnoty návěstí. Tímto způsobem je paket přenesen přes celou MPLS síť až k jejímu okraji, kde je návěstí hraničním směrovačem odejmuto. Trasa přes MPLS doménu je reprezentována příslušnými dvojicemi vstupní a výstupní hodnoty návěstí uloženými v přepojovací tabulce MPLS směrovačů. Mimo MPLS doménu je pak paket směrován klasickým způsobem, tedy nejčastěji na základě cílové IP adresy [95], viz obr []. 48

49 Vyhledávání cesty k odchozímu směrovači a nastavení značky /8 L =5 Přepojení na výstupní port a změna návěstí L=5 L=3 Odstranění značky a pokračování v klasickém směrování LER L=5 LSR L=3 LER Obr. 2.24: Přepojování datové jednotky v MPLS síti Technologie MPLS je perspektivním síťovým řešením zejména díky tomu, že klasifikace paketů probíhá pouze v hraničních směrovačích sítě a přepojování přes MPLS směrovače je řízeno pouze na základě přiděleného návěstí. Z hlediska zajištění kvality služeb je MPLS také velice perspektivní, neboť obsahuje řadu nástrojů pro zajištění odlišného zacházení s různými datovými toky [83]. Tyto nástroje budou postupně představeny v následujících kapitolách Distribuce MPLS návěstí Trasa LSP, propojující logicky vstupní hraniční směrovač s výstupním, je definována posloupností návěstí označujících úseky mezi sousedními směrovači. Technologie MPLS vyžaduje, aby směrovače LSR kromě klasických směrovacích informací posílaly svým sousedním směrovačům i informace o návěstích přiřazených jednotlivým vstupním a výstupním rozhraním. Rozesílání těchto informací je označeno pojmem distribuce MPLS návěstí. Existují dvě základní metody distribuce MPLS návěstí. První metoda je analogická statickému směrování v klasických paketových sítích a spočívá v pevně nastavených trasách LSP mezi jednotlivými směrovači. Jde o jednoduché řešení, které ale neumožňuje dynamické nastavování a správu tras. Z praktického hlediska nabízí mnohem flexibilnější řešení dynamická signalizace a distribuce návěstí. Specifikace technologie MPLS dává výrobcům a administrátorům sítě volnost při výběru konkrétního protokolu pro distribuci MPLS návěstí, což umožňuje využívat různé typy signalizačních protokolů. Záznamy v přepojovacích tabulkách LFIB lze vytvářet decentralizovaně i centralizovaně. V případě decentralizovaného řízení každý směrovač nezávisle buduje svoji tabulku LFIB na základě informací získaných ze směrovací tabulky. Informace o záznamech v přepojovací tabulce pak posílá svým sousedům. V tomto případě mohou směrovače pracovat zcela nezávisle na ostatních. Každý směrovač je schopen zpracovat zprávy příslušného směrovacího protokolu, vytvářet záznamy ve vlastní přepojovací tabulce a distribuovat je v síti. V tomto případě není v MPLS doméně 49

50 potřebný žádný vyhrazený směrovač, který by byl zodpovědný za centrální správu MPLS návěstí. V případě centralizovaného řízení existuje jeden směrovač, typicky výstupní hraniční směrovač LER, který je zodpovědný za distribuci návěstí. Tento směrovač je běžně označen jako správce návěstí (Label Manager) a má za úkol informovat všechny další směrovače v síti o tom, jaké návěstí mají používat pro jednotlivé trasy. Distribuce návěstí může být v tomto případě iniciována přímo správcem návěstí (metoda pushed ) v rámci reakce na určité události, jako např. vypršení časovače, změna cesty ve směrovací tabulce atd., nebo může proběhnout na žádost jiného směrovače (metoda pulled ). Např. vstupní hraniční směrovač může po přijetí paketu zažádat správce návěstí o vytyčení trasy a přidělení příslušných návěstí pro jednotlivé úseky Signalizační protokoly mechanizmu MPLS Signalizační protokoly zajišťují distribuci MPLS návěstí mezi jednotlivými směrovači. Pro spolehlivý chod sítě je nutné zajistit, aby se zprávy signalizačního protokolu dostaly ke všem směrovačů MPLS domény rychle, spolehlivě a konzistentně. Pomocí signalizačního protokolu může daný MPLS směrovač požádat svého souseda o návěstí, aby tuto značku mohl přiřadit příslušné třídě FEC. Využitím signalizačního protokolu předávají směrovače tuto žádost postupně až k odchozímu hraničnímu směrovači. Ve zpětném směru zajistí signalizační protokol distribuci návěstí. Po obdržení návěstí může každý směrovač přiřadit danou hodnotu příslušnému rozhraní. Mezi nejčastěji využívané signalizační protokoly patří: LDP (Label Distribution Protocol) [51], CR-LDP (Constrained Routing LDP) [16], RSVP-TE (Resource Reservation Protocol - Traffic Engineering) - protokol RSVP rozšířený o podporu MPLS TE (Traffic Engineering) [17], Distribuce značek pomocí BGP-4 (Border Gateway Protocol), OSPF-TE (Open Shortest Path First - Traffic Engineering) Směrování v sítích MPLS V MPLS doméně si každý směrovač vytváří svoji tabulku návěstí, která udává, jak směrovat přicházející datové jednotky. Tabulka obsahuje informace o tom, které třídě FEC jednotlivé značky patří a kterému výstupnímu portu jsou přiřazeny. Samotné 50

51 směrování v MPLS doméně je nejčastěji založeno na postupném směrování (hopby-hop) nebo explicitním směrování založeném na předem definovaném seznamu směrovačů. V případě postupného směrování každý MPLS směrovač nezávisle vyhledává následující úsek trasy pro danou třídu FEC. Každý paket patřící do této třídy je pak směrován po stejné trase. Informace o topologii sítě je distribuována mezi směrovači pomocí standardních IGP (Interior Gateway Protocol) směrovacích protokolů jako např. OSPF. Tento způsob směrování je velice blízký standardnímu směrování v IP sítích, viz obr [87]. Řídicí rovina OSPF: /8 LDP: /8 - návěstí 5 Paket L=5 Směrovací protokol OSPF MPLS signalizace LDP Uživatelská rovina LFIB 5 9 OSPF: /8 LDP: /8 - návěstí 9 Paket L=9 LSR Obr. 2.25: Směrování a distribuce návěstí v MPLS síti Explicitní směrování využívá předem definovaný seznam směrovačů, přes které vede trasa LSP. Tato trasa nemusí být vždy optimální, ale na druhé straně je možné pro ni předem zajistit rezervaci síťových prostředků Řízení provozu v MPLS sítích Cílem řízení provozu v MPLS sítích je zvýšení propustnosti sítě, zvýšení dostupnosti síťových prostředků a zajištění vyšší spolehlivosti pro síťové služby. Tyto pozitivní vlastnosti jsou dosaženy využitím různých alternativních tras pro různé třídy FEC. Klíčovým prvkem řízení provozu jsou vnitřní směrovací mechanizmy, které jsou schopny najít a vyhradit pro datový tok trasu LSP zohledňující požadavky na kvalitu služeb. Rezervace síťových prostředků sice nezaručí nalezení optimální trasy, ale zajišťuje dodržení požadovaných parametrů přenosu. Pro rezervaci síťových prostředků se zpravidla využívá signalizační protokol RSVP-TE. Pro tento účel lze však 51

52 využít i jiné směrovací protokoly, které jsou schopny přenášet doplňkové informace např. o propustnosti či zpoždění linky atd. Přenos datové jednotky přes MPLS doménu při využití řízení provozu probíhá následujícím způsobem. V případě, že hraniční směrovač LER obdrží paket, pro který zatím nemá odpovídající návěstí, požádá svého sousedního směrovače LSR o značku. Tento požadavek je propagován přes MPLS doménu až k výstupnímu LER směrovači, který přidělí značku pro danou třídu FEC. Následně je značka, jejíž hodnota se může měnit pro jednotlivé úseky, distribuována zpět k žadateli. Během tohoto procesu směrovače LSR postupně předávávají informaci o FEC a příslušném návěstí zpět až ke vstupnímu směrovači LER. Současně každý LSR vytvoří ve své přepojovací tabulce LFIB patřičný záznam. Protože se návěstí může na každém úseku trasy lišit, musí tyto záznamy vždy jasně identifikovat třídu, rozhraní a návěstí na vstupu a odpovídající rozhraní a návěstí na výstupu. Po doručení návěstí vstupnímu směrovači LER je trasa sestavena. Po obdržení návěstí už může hraniční směrovač připojit k paketu MPLS hlavičku a pustit ho do MPLS sítě. Směrovače LSR na základě návěstí v hlavičce a záznamu v přepojovací tabulce předávají datovou jednotku na odpovídající výstupní port, aktualizují hodnotu návěstí a posílají datovou jednotku k sousednímu LSR. Po doručení datové jednotky na výstupní směrovač LER je odstraněna MPLS hlavička a paket je předán do přístupové sítě pro doručení k cílové stanici, viz obr LER LSR LER Směrovač A (ingress) Žádost o značku (cíl: směrovač C) Směrovač B Žádost o značku (cíl: směrovač C) Směrovač C (egress) Distribuce značky (např. 6) Distribuce značky (např. 18) Obr. 2.26: Využití signalizačního protokolu pro distribuci MPLS návěstí Hraniční směrovač v rámci vytváření MPLS hlavičky provádí třídění provozu na základě nastavení administrátora sítě. Tato klasifikace má za následek, že datové toky mezi stejnými koncovými zařízeními, ale patřící různým službám, např. VoIP a FTP (File Transfer Protocol), mohou být přenášeny po různých trasách. 52

53 2.5.7 Traffic Engineering v sítích MPLS Technologie MPLS umožňuje řadit datové toky splňující určité podmínky do společných tříd FEC a využívat pak dedikované trasy pro tyto třídy. Signalizační protokoly typu LDP-CR či RSVP-TE navíc zajišťují, že tyto trasy budou splňovat přenosové požadavky definované pro dané třídy. Dedikované trasy vedené přes různá alternativní fyzická spojení mohou navíc výrazně zvýšit efektivitu přenosu. Volbou takového řešení lze předejít situacím, kdy cesty vybrané směrovacím protokolem jsou zahlceny, přičemž alternativní záložní trasy zůstanou nevyužity. Implementace technologie Traffic Enginnering do MPLS sítí zajišťuje, že síťový provoz bude veden po trasách, které mají dostatečné zdroje. Takové rozložení zátěže eliminuje řadu nežádoucích vlivů vznikajících při přepojování paketů, jakými jsou např. proměnlivé zpoždění či výrazné kolísání zpoždění [47]. Traffic Enginnering vyžaduje čtyři základní kroky pro zajištění efektivního provozu: Prvním krokem je měření a analýza síťového provozu, která spočívá se sběru charakteristických informací o třídách FEC. Takovými parametry mohou být např. počet přenesených paketů za určitý časový interval, průměrná velikost paketů, počet paketů během nejvytíženějšího časového úseku dne, trendy v přenosu paketů (narůstající, klesající, opakující se vzory), výkonnostní parametry (propustnost, rychlost zpracování dat), atd. Druhým krokem je popis provozu, v rámci kterého je vytvořen statistický model na základě parametrů zjištěných v prvním kroku. Třetím krokem je modelování datových toků založené na měřených parametrech tříd FEC a na statistických modelech. Cílem modelování je vytvořit parametrizované modely na základě aktuálního chování síťového provozu. Tyto modely jsou podkladem pro návrh a ověření alternativních simulačních scénářů. Simulační scénáře slouží především pro ověření výkonnosti, efektivity a spolehlivosti sítě během normálního provozního stavu i v případě mimořádných událostí, jakými jsou např. výpadky linek či síťových prvků. Výsledkem je analýza optimálního rozložení tras přes MPLS sítě. Čtvrtým krokem je implementace závěrů získaných z modelování, tj. vedení provozu po nejlepších trasách LSP tak, aby byla dosažena maximální efektivita při využití síťových prostředků, ale byla zachována i odolnost síťové infrastruktury proti výpadkům spojení či aktivních síťových prvků. 53

54 2.5.8 Taffic Engineering z hlediska zajištění kvality služeb Jak bylo uvedeno na začátku kapitoly, technologie MPLS kombinuje funkce ze síťové a linkové vrstvy. Tím MPLS umožňuje signalizaci požadované kvality služeb přes celou MPLS doménu, přičemž při přenosu datových jednotek vystačí se zpracováním návěstí na úrovni linkové vrstvy. MPLS nabízí dvě odlišné možnosti řízení kvality služeb. V prvním případě se využívá 3 bitové pole EXP v návěstí MPLS. Toto pole je určeno pro nastavení priority pro trasu LSP. Zavedení prioritního systému mezi jednotlivými trasami nám umožňuje splnění následujících požadavků: 1. V případě, že síťové prostředky nejsou zabrány FEC třídou s vysokou prioritou, mohou je využít FEC třídy s nižší prioritou. 2. Trasa pro FEC třídu s vysokou prioritou bude vždy sestavena po nejlepší cestě přes MPLS síť a to nezávisle na aktuálních rezervacích. 3. V případě, že je třeba modifikovat trasu LSP, např. po výpadku linky, FEC třídy s vysokou prioritou budou mít větší pravděpodobnost nalezení vhodné alternativní trasy, než třídy s nižší prioritou. Řízení kvality služeb pomocí pole EXP je řešeno mapováním priority 802.1Q do tohoto pole. Tři bity umožňují mapování 8 různých tříd, což je pro praktické využití většinou dostačující. Tato metoda řízení kvality služeb je označována jako E-LSP (EXP-inferred Label Switch Path). Druhou možností řízení QoS je vyčlenění určitého rozsahu návěstí pro jednotlivé třídy služeb, což zajistí oddělení datových toků určitého charakteru, např. VoIP, od jiných. Rezervací dostatečných síťových prostředků pro trasu LSP, po kterou bude daná třída vedena, lze garantovat dodržení požadovaných QoS parametrů. Tato metoda řízení QoS je označována jako L-LSP (Label-only-inferred Label Switched Path). Vzhledem k větší náročnosti se metoda L-LSP využívá pouze v případech, kdy je vyžadováno víc než 8 tříd či prioritních úrovní, což v praxi není příliš časté. Metoda L-LSP je vhodná v případě, kdy koncoví uživatelé neznačkují svoje pakety a proto ke značkování dochází až v hraničním směrovači LER. Tento směrovač může roztřídit přicházející datové jednotky např. podle portů transportní vrstvy. Tento proces ovšem nedokáže eliminovat náhodný charakter přicházejících datových toků a tak nezajistí ani absolutní garanci QoS parametrů. V případě metody E-LSP se předpokládá, že prvotní zpracování provozu provádí uživatel či zákaznická síť. Tehdy lze provést mapování značky přidělené na úrovni linkové či síťové vrstvy do pole EXP v návěstí. Mapování značky do tříbitového pole EXP nemusí být jednoznačné v případě mechanismu DiffServ, protože pole DSCP má délku 6 bitů. Naštěstí lze často v takovém případě využít skutečnost, že pole 54

55 DSCP lze rozdělit na první tři bity, které definují třídu a na další tři bity udávající pravděpodobnost zahození paketu v rámci dané třídy. Operátoři pak při mapování zohledňují pouze bity označující třídu, do které byl paket zařazen. MPLS DiffServ-TE (Differentiated Services - Traffic Engineering) V předchozích kapitolách bylo popsáno, jakým způsoben řadí mechanizmu DiffServ datové toky do tříd provozu a jak zajišťuje odlišné zacházení a odlišné přenosové parametry pro jednotlivé třídy. Samotné řazení provozu do tříd však nemusí zajistit za všech okolností požadované QoS parametry a to ani v případě naddimenzované sítě. V kapitole bylo popsáno, jak MPLS Traffic Engineering zajišťuje, aby trasy LSP byly vybudovány po komunikačních linkách, které disponují s dodatečnými síťovými prostředky, a jakým způsobem řeší TE, aby požadovaná kapacita byla k dispozici jak v běžném provozním stavu tak i v případě výpadků. Na druhé straně však MPLS Traffic Engineering pracuje na úrovni FEC, což nemusí vždy odpovídat řazení datových toků do QoS tříd. Proto virtuální spojení LSP může často agregovat provoz ze všech QoS tříd a může to vést k jejich nežádoucímu vzájemnému ovlivňování. Technologie MPLS DiffServ-TE, neboli Traffic Engineering na úrovni mechanizmu DiffServ [74], spojuje mechanizmy DiffServ a MPLS-TE dohromady s cílem kombinovat jejich výhody a eliminovat nevýhody. Konkrétně DiffServ-TE rozšiřuje MPLS Traffic Engineering o možnost alokace síťových zdrojů a řešení výpadků až na úrovni tříd služeb. Základním požadavkem DiffServ-TE je schopnost provádět rezervaci síťových prostředků na úrovni jednotlivých tříd. Tato schopnost vyžaduje, aby směrovače udržovaly informace o dostupných síťových prostředcích až na úrovni tříd služeb. Tyto třídy služeb jsou v terminologii DiffServ-TE označovány jako typy třídy CT (Class Type). Podle dokumentu RFC 3564 [64] lze definovat až 8 různých typů tříd označených jako CT0, CT1 až CT7. Po jedné trase LSP lze přenášet pouze provoz patřící jednomu CT. Během rezervace prostředků pro dané LSP je pak informace o příslušném typu třídy přenášena přímo ve zprávách protokolu RSVP. Výjimkou z důvodu zpětné kompatibility je pouze typ CT Celkové zhodnocení QoS mechanizmů V předchozích kapitolách byly rozebrány tři hlavní mechanizmy sloužící pro zajištění kvality služeb v současných datových sítích. Historicky nejstarší je technologie Integrovaných služeb, jejíž základní myšlenka spočívá v zajišťování QoS pro jednotlivé 55

56 datové toky (per-flow). Výhodou tohoto mechanizmu je jeho end-to-end zaměření, což znamená, že QoS je poskytováno mezi koncovými stanicemi napříč celou sítí. Mechanizmus IntServ se však brzy po jeho představení ukázal jako příliš složitý a ekonomicky nevýhodný pro implementaci do rozsáhlých sítí spravovaných jednotlivými ISP. Jeho složitost je dána zejména požadavkem na vytvoření a udržování rezervačního stavu v každém síťovém prvku, přes který je daný tok přenášen. Při větším počtu datových toků tento požadavek vytvářel vysoké nároky na výkon síťových prvků. Díky těmto problémům se technologie IntServ nikdy příliš nerozšířila a v dnešní době se již prakticky v rozsáhlejších sítích nepoužívá. V reakci na nedostatky mechanizmu IntServ byl vytvořen koncept Diferencovaných služeb. Cílem této technologie je zejména eliminovat celkovou složitost a vysoké požadavky kladené mechanizmem IntServ na síťové uzly. Toho se podařilo dosáhnout tím, že síťový provoz není zpracováván na základě jednotlivých toků, jak je tomu u IntServ, ale podle tříd (per-class), do kterých jsou pakety řazeny na základě předem definovaných pravidel. Tato klasifikace je prováděna na hraničních prvcích sítě. Páteřní uzly pak pouze zpracovávají již označené pakety, což snižuje míru jejich zatížení. Klasifikace a následné zpracovávání síťového provozu podle tříd s definovanou úrovní priority se ukázalo jako perspektivní řešení pro zajištění QoS v IP sítích. Mechanizmus DiffServ je také v porovnání s IntServ jednodušší z pohledu implementace do síťových prvků. Jedním z často zmiňovaných nedostatků technologie DiffServ je rozsah podpory QoS omezený pouze na oblast DiffServ domény a chybějící zpětná odezva. Počátečním místem, kde jsou aplikovány QoS algoritmy, je hraniční prvek DiffServ domény, což může v některých případech způsobit rozpor v přidělené úrovni QoS a skutečnými požadavky koncové aplikace. Uživatel tak předem neví, jakou úroveň kvality služby mu síť skutečně poskytne. I přes tyto nedostatky se však technologie DiffServ stala v současné době nejpoužívanější technologií pro zajištění QoS a její upřednostnění před IntServ se ukázalo jako správný krok, což potvrzuje i řada studií, např. [52], [99], [106], nebo praktických zkušeností síťových administrátorů. Srovnání základních vlastností mechanizmů IntServ a DiffServ je uvedeno v tabulce 2.4 [68]. Třetím z popisovaných mechanizmů je MPLS. Původním cílem technologie MPLS nebylo přímo zajištění kvality služeb, ale spíše zefektivnění přenosu datových jednotek. MPLS využívá principu přepojování a přenosu datových jednotek na základě návěstí. Přepojování na základě návěstí podstatně zrychlí proces zpracování paketů v síťových uzlech, což má ve výsledku pozitivní vliv na úroveň poskytované služby. Mimo to však MPLS obsahuje také řadu nástrojů pro zajištění odlišného zacházení s různými třídami síťového provozu. Jedním z těchto nástrojů je možnost směrování 56

57 Tab. 2.4: Srovnání mechanizmů IntServ a DiffServ Vlastnost IntServ DiffServ Stupeň dělení Jednotlivé toky Jenotlivé třídy provozu Klasifikace provozu MF (Multifield) BA (Behavior Aggregate) nebo MF (Multifield) Typy služeb Služba s řízenou zátěží, služba PHB AF, PHB EF, Best-effort s garatovanými parametry Rezervace zdrojů Dynamicky řízena aplikací Staticky nakonfigurována na hraničních směrovačích Signalizace RSVP protokol Na základě hodnoty DSCP Rozsah zajištění Mezi koncovými body V rámci DS domény QoS Složitost Vysoká Nízká dat patřící do vybrané FEC třídy po optimální trase. Je tak tedy např. možné zvolit pro přenosy v reálném čase trasu, která bude schopna zajistit požadované parametry provozu. V současnosti je poměrně rozšířený mechanizmus MPLS DiffServ-TE, který spojuje oba zmíněné mechanizmy a kompenzuje jejich dílčí nevýhody. DiffServ-TE tak výrazně rozšiřuje možnosti zajištění kvality služeb v MPLS sítích a nabízí garanci dostupnosti síťových prostředků až na úrovni jednotlivých tříd [65]. Tento způsob nastavení garance kvality služeb poskytuje spolu s vysokými rychlostmi dosahovanými mechanizmem MPLS dostatečný technologický základ pro páteřní sítě nových generací [66], [96]. Aby bylo srovnání výše uvedených QoS technologií kompletní, byl v simulačním prostředí OPNET Modeler navržen model sítě, v kterém byly formou několika scénářů nakonfigurovány postupně mechanizmy IntServ, DiffServ a MPLS. Následující kapitola tedy obsahuje nejprve popis základních parametrů navrženého simulačního modelu a poté jsou uvedeny a analyzovány výsledky simulací. Na těchto výsledcích jsou názorně vidět rozdílné způsoby zajišťování QoS u uvedených technologií. 57

58 3 SIMULACE A ANALÝZA VYBRANÝCH QOS TECHNOLOGIÍ Za účelem podrobného srovnání technologií pro zajištění kvality služeb v IP sítích, které byly popsány v předchozích kapitolách, byl vytvořen simulační model datové sítě, v kterém byly postupně nakonfigurovány technologie IntServ, DiffServ a MPLS. Cílem provedených simulací bylo mimo jiné také poukázat na některé problémy těchto technologií. Jako simulační prostředí byl zvolen nástroj OM (OPNET Modeler). OM slouží jako vývojové prostředí vhodné pro návrh, simulaci a analýzu komunikačních sítí. Díky velkému množství již vytvořených knihoven prvků převážně pro technologie Ethernet, IP, TCP, FDDI (Fiber Distributed Data Interface), ATM dokáže věrně napodobit a flexibilně otestovat chování všech částí a prvků datové sítě [101]. Zdrojové kódy jednotlivých síťových prvků jsou psané v jazyce C/C++ a jsou volně editovatelné, což ještě více rozšiřuje flexibilitu tohoto simulačního prostředí, neboť si uživatel může v případě potřeby jednotlivé modely rozšiřovat o nové funkce [101]. 3.1 Parametry simulačního modelu datové sítě V simulačním prostředí OM byl vytvořen model datové sítě. Aby bylo možné objektivně srovnat technologie IntServ, DiffServ a MPLS, bylo snahou, aby byl vytvořený model sítě dostatečně univerzální a použité prvky podporovaly všechny tři zmíněné QoS technologie. Vytvořený simulační model, viz obr. 3.1, umožňuje formou scénářů analyzovat jednotlivé technologie pro zajištění kvality služeb, aniž by bylo nutné nějak zásadně měnit základní síťovou topologii nebo komponenty. Úpravy modelu prováděné v jednotlivých simulačních scénářích se vždy týkaly pouze konfigurace daného QoS mechanizmu. Jak je vidět na obr. 3.1, základní verze simulačního modelu je tvořena celkem 12 IP směrovači vybavenými 4 ethernetovými a 8 sériovými rozhraními s volitelnou rychlostí. Koncové uzly byly tvořené pracovními stanicemi nebo servery s podporou technologie ethernet. Modely ethernetových stanic i serverů umožňují provoz síťových aplikací typu klient-server a využívající protokolovou sadu TCP/IP. Aplikační servery i koncové stanice jsou vybaveny jedním ethernetovým rozhraním s volitelnou rychlostí 10 Mb/s, 100 Mb/s nebo 1 Gb/s. Koncové stanice a servery byly do sítě připojeny přes 2 ethernetové přepínače vybavené 16 rozhraními s volitelnou rychlostí 10 Mb/s, 100 Mb/s nebo 1 Gb/s. Jako 58

59 QoS Attribute Config Application Config Application Profile Config Database server Core Router 3 Database client FTP client FTP server Core Router 1 Core Router 5 HTTP server Switch 1 Edge Router 1 Core Router 4 Core Router 2 Core Router 6 Edge Router 2 Switch 2 HTTP client VoIP client 1 Core Router 7 Core Router 8 Core Router 9 Core Router 10 VoIP client 2 VoIP client 4 VoIP client 3 Obr. 3.1: Topologie simulačního scénáře přenosová technologie byl zvolen ethernet. Pro propojení serverů a koncových stanic s přepínači a také přepínačů s hraničními směrovači byla použita duplexní linka 100BaseT s rychlostí 100 Mb/s. Mezi jednotlivými směrovači uvnitř sítě pak byla použita duplexní linka 10BaseT s rychlostí 10 Mb/s. Propojení směrovačů uvnitř páteřní sítě pomocí linky s nižší přenosovou rychlostí bylo záměrné, i když to neodráží podmínky reálné sítě. Důvodem byla snaha o co nejvyšší zatížení páteřních linek, neboť přínos technologií pro zajištění QoS je znatelný zejména ve vysoce zatížených sítích. Místo toho, aby bylo nutné v síťovém modelu definovat velké množství zdrojů dat, což by mohlo zvýšit složitost a nepřehlednost vytvořeného modelu, byla omezena propustnost páteřních linek Význam konfiguračních prvků Kromě výše uvedených síťových prvků obsahuje vytvořený simulační model také několik konfiguračních prvků. Konkrétně se jedná o: Application Config - objekt pro nastavení aplikací, které jsou využity v simulačním modelu. Pomocí tohoto prvku je možné definovat jednotlivé síťové aplikace, jako je například VoIP, HTTP, FTP a další. Application Profile Config - objekt pro přiřazení profilů jednotlivým aplikacím. Pomocí profilu je možné definovat parametry dané aplikace, jako je například doba spuštění, délka trvání, nastavení opakování, atd. item QoS Attribute Config - objekt pro nastavení globálních parametrů řízení kvality služeb. V tomto prvku byly vytvořeny fronty pro řazení paketů podle jejich priority. item MPLS Config - objekt pro nastavení parametrů MPLS technologie, jako 59

60 je konfigurace FEC tříd nebo mapování mezi hodnotami pole EXP a způsoby zacházení PHB. Objekt MPLS Config není zobrazen v základní verzi simulačního modelu Nastavení síťového provozu V simulačním modelu byly nakonfigurovány celkem 4 odlišné typy síťového provozu - přenos souborů pomocí FTP (představitel typické datové služby), přístup k webovým stránkám pomocí protokolu HTTP (představitel interaktivní služby, typu člověk-stroj), obecný databázový přístup (představitel interaktivní služby typu stroj-stroj) a přenos hlasu pomocí VoIP technologie (představitel služby pracující v reálném čase). První tři zmíněné síťové aplikace využívají na transportní vrstvě protokol TCP a zbývající VoIP využívá UDP protokol. Pro každý typ provozu byly nakonfigurovány specifické parametry a také časový profil. Následující tab. 3.1 uvádí nastavené parametry pro jednotlivé typy síťového provozu. Jak je vidět z tab. 3.1, jednotlivé typy síťového provozu byly spouštěny postupně s 50 sekundovými rozestupy. První aplikace (FTP přenos) byla spuštěna 200 s po startu simulace. Tato doba byla zvolena záměrně, neboť během prvních přibližně 150 s od spuštění simulace probíhá inicializace simulačních procesů, jako např. výměna zpráv směrovacích protokolů za účelem vytvoření směrovacích tabulek. Síťová aplikace spuštěná během této inicializační fáze by tedy mohla být ovlivněna těmito procesy a její výsledné statistiky by mohly být zkreslené [101]. Síťové aplikace typu FTP, HTTP a databázový přístup jsou postavené na modelu klient-server, proto se v simulačním modelu nachází pro každý tento typ provozu jeden pár uzlů klient-server. Aplikace VoIP byla nakonfigurována na 4 koncových stanicích, kdy spolu stanice komunikují v párech (Client_VoIP_1 s Client_VoIP_2 a Client_VoIP_3 s Client_VoIP_4). Jako směrovací protokol byl zvolen RIP a jednotlivým síťovým prvkům byly automaticky přiděleny adresy IPv4. Bylo ověřeno, že volba směrovacího protokolu nemá na mechanizmy zajištění kvality služeb žádný vliv, a proto byl směrovací protokol RIP z důvodu zvýšení rychlosti simulace a snížení paměťových nároků vypnut po 300 s od spuštění simulace. Tato funkce je doporučena v [101], avšak její použití je vhodné pouze pro sítě s neměnnou topologií. 3.2 Simulace technologie IntServ První QoS technologie, která byla v síťovém modelu nakonfigurována a odsimulována, byla technologie Integrovaných služeb. V rámci analýzy tohoto mechanizmu 60

61 Tab. 3.1: Simulační parametry pro jednotlivé typy provozu Parametr FTP HTTP Databázový přístup Podíl příkazu Get vůči celkovému počtu příkazů Podíl dotazů vůči celkovému počtu příkazů 50% Verze protokolu HTTP 1.1 Velikost objektu webové stránky Počet objektů na webové stránce Počet stránek na serveru Délka intervalu ticha Délka nepřerušeného úseku řeči Použitý kodek Počet hlasových rámců v paketu Zpoždění způsobené (de)kompresí řeči Konverzační prostředí Interval mezi jednotlivými požadavky na stažení souboru Velikost souboru přenášeného 36 s (exp. rozložení) Čas spuštění aplikace 200 s po startu simulace Doba trvání aplikace Do konce simulace 2 MB 5 20 (exp. rozložení) 20 s (exp. rozložení) 50% 20 MB 5 MB 250 s po startu simulace Do konce simulace 15 s (exp. rozložení) 300 s po startu simulace Do konce simulace VoIP exp. rozložení se střední hodnotou 0,65 s exp. rozložení se střední hodnotou 0,352 s G.729A s Tichá místnost 350 s po startu simulace V 300 s cyklech do konce simulace byly vytvořeny 2 scénáře. V prvním scénáři, s názvem Best-effort, byl veškerý síťový provoz přenášen způsobem best-effort a tento scénář poskytoval referenční data při posuzování vlivu mechanizmu IntServ na jednotlivé parametry provozu. V druhém scénáři, s názvem IntServ, pak byla nakonfigurována technologie IntServ, 61

62 která využívala signalizační protokol RSVP pro vytváření rezervačních stavů uvnitř jednotlivých směrovačů. Jako prioritní typ provozu byl zvolen VoIP, kterému byla přidělena hodnota ToS pole 6 (Interactive voice). Zbývající provoz byl síťovými prvky zpracováván způsobem best-effort. V objektu QoS Attribute Config byly definovány parametry datového toku generovaného VoIP klienty, viz tab Hodnoty těchto parametrů byly pravidelně vysílány ze zdroje dat v podobě RSVP zprávy typu PATH za účelem sestavení rezervačních stavů uvnitř všech směrovačů podél celé trasy [25]. Tab. 3.2: Simulační parametry RSVP toku Parametr RSVP toku Požadovaná propustnost Požadovaná velikost vyrovnávací paměti Hodnota 50 kb/s 10 kb Na všech aktivních rozhraních směrovačů byl povolen RSVP protokol a maximální velikost rezervované propustnosti pro jednotlivé RSVP toky byla nastavena na 75% celkové propustnosti síťového rozhraní. Hodnota 75% byla zvolena s ohledem na režijní data generovaná nižšími vrstvami. Rychlost síťového rozhraní je totiž v OM definována na úrovni síťové vrstvy, a proto je nutné při definování velikosti rezervované šířky pásma uvažovat i režijní data generovaná především linkovou vrstvou, jinak by mohlo dojít k zahlcení fyzického rozhraní. Množství dat na úrovni fyzické vrstvy je tedy větší než na IP vrstvě. Tento jev je výraznější pro pakety s malou velikostí, jako jsou například VoIP pakety. Např. při použití kodeku G.729 může být nárůst dat na fyzické vrstvě až 19% v porovnání se síťovou vrstvou. Hodnota 75% se tedy z dlouhodobého hlediska jeví jako vhodná [101]. Na směrovačích byl dále aktivován algoritmus WFQ zohledňující hodnotu ToS pole, který zajišťoval plánované odesílání paketů a zároveň zajišťoval prioritní zacházení pro VoIP toky Rozbor výsledků simulace mechanizmu IntServ Oba výše popsané scénáře byly odsimulovány s délkou simulace 3600 sekund. Po této době byly získány výstupní charakteristiky v podobě grafů. Během simulací byla komunikační síť záměrně nadměrně zatížena, což umožnilo snadněji analyzovat vliv použití mechanizmu IntServ na vybrané parametry provozu. Na obr. 3.2 je zobrazen průběh end-to-end zpoždění pro VoIP tok mezi VoIP klientem č. 3 a č. 4. Z grafu je zřetelný pozitivní vliv na zpoždění VoIP toku při implementaci mechanizmu IntServ. Hodnoty end-to-end zpoždění se pro scénář IntServ 62

63 End-to-End zpoždění [s] pohybují okolo hodnoty 65 ms, což je uspokojivá hodnota pro přenos hlasu v reálném čase. Naproti tomu u scénáře Best-effort se vyskytují vyšší hodnoty end-to-end zpoždění (téměř 100 ms), které by v některých případech mohly způsobit zhoršenou kvalitu přenášeného hlasu. Nárůst zpoždění ve scénáři Best-effort je evidentní zejména ke konci simulace, kdy vlivem vysokého vytížení linek došlo v síťových prvcích k většímu zaplnění vyrovnávací paměti. Jelikož ve scénáři Best-effort nebylo definováno žádné prioritní zacházení, postihl se tento stav zahlcení všechny typy provozu včetně VoIP. Z průběhu grafu je také patrný časový profil VoIP aplikace, která byla spuštěna v pravidelně se opakujících cyklech s délkou 300 s. 0,095 0,09 0,085 0,08 0,075 0,07 0,065 Best-effort IntServ 0,06 0,055 0, Čas simulace [s] Obr. 3.2: End-to-end zpoždění pro VoIP tok mezi VoIP klientem č. 3 a č. 4 Na obr. 3.3 je zobrazena závislost parametru jitter na času simulace pro oba sledované scénáře. Simulační prostředí OM počítá parametr jitter podle rovnice 3.1 jitter = (t 4 t 3 ) (t 2 t 1 ), (3.1) kde t 1 je čas vyslání prvního paketu, t 2 je čas vyslání druhého paketu, t 3 je čas příchodu prvního paketu a t 4 je čas příchodu druhého paketu. V případě, že rozdíl hodnot t 3 a t 4 je nižší než rozdíl hodnot t 2 a t 1, pak může být výsledná hodnota parametru jitter záporná [101]. I přesto, že hodnoty jitter jsou pro oba scénáře velmi nízké (jednotky mikrosekund), je z obr. 3.3 patrný pozitivní vliv použití mechanizmu IntServ. Průběh jitteru je pro scénář s prioritizací VoIP provozu vyrovnanější a průměrná hodnota je nižší než u scénáře Best-effort. Ve scénáři IntServ byl na směrovačích aplikován algoritmus WFQ zohledňující hodnotu pole ToS. Síťový provoz byl tedy řazen do 2 front - fronta s vysokou prioritou obsahující VoIP (ToS = 6) pakety a fronta s nízkou prioritou obsahující 63

64 Počet zahozených paketů [pakety] Jitter [s] 0, , , , ,00001 Best-effort IntServ -0, , , Čas simulace [s] Obr. 3.3: Jitter pro VoIP tok mezi VoIP klientem č. 3 a č. 4 všechny ostatní pakety (ToS = 0). V případě zaplnění vyrovnávací paměti síťového prvku, byly zahazovány nejprve pakety z fronty s nízkou prioritou. Množství takto zahozených paketů v hraničním směrovači Edge_Router_1 je vidět na obr Čas simulace [s] Obr. 3.4: Počet zahozených paketů pro frontu s nízkou prioritou na hraničním směrovači Edge_Router_1 Jedním z důvodů, proč není mechanizmus Integrovaných služeb v praxi příliš rozšířen, jsou vysoké požadavky kladené na síťové uzly při vytváření a udržování RSVP rezervačních stavů. Počet těchto stavů je vždy závislý od celkového počtu datových toků, kterým má být poskytnuta rezervace síťových zdrojů. Na obr. 3.5 je zobrazeno celkové množství RSVP rezervačních stavů uskutečněných na směrovači Core_Router_9 v závislosti na čase. Průměrné množství RSVP zpráv přenesených přes síť se pohybovalo okolo 15 zpráv/s. V případě velkého množství spojení (např. stovky) by již docházelo k poměrně výraznému zatížení procesoru a pamětí směro- 64

65 Počet RSVP rezervačních stavů [-] vače. Stejně tak by zprávy protokolu RSVP zabraly poměrně výraznou část celkové propustnosti linky Čas simulace [s] Obr. 3.5: Počet RSVP rezervačních stavů vytvořených na páteřním směrovači Core_Router_9 3.3 Simulace technologie DiffServ Technologie Diferencovaných služeb je v současnosti nejrozšířenější technologií pro zajištění QoS v datových sítích, a proto jí byla v této práci věnována největší pozornost. Dalším důvodem je také to, že v další části práce je mechanizmus DiffServ použit jako základ pro nově navržený QoS systém. Základní model sítě, viz obr. 3.1, je stejný jako u simulací technologie IntServ, proto bude následující popis věnován pouze nastavení jednotlivých komponent DiffServ. Jako referenční scénář byl opět použit model s Best-effort zacházením aplikovaným pro všechny typy provozu. Nastavení síťových aplikací zůstalo stejné jako u IntServ. Podpora technologie DiffServ je v simulačním prostředí OM na dobré úrovni, což umožňuje detailně analyzovat vliv nastavení jednotlivých prvků této technologie. Vytvořený simulační model datové sítě je tvořen celkem 12 směrovači, které pro účely modelování mechanizmu DiffServ tvoří jednu DS doménu. Směrovače Edge_Router_1 a Edge_Router_2 pracují jako hraniční směrovače a ostatní uzly plní úlohu páteřních směrovačů DS domény. Jak již vyplývá z teoretického popisu DiffServ technologie uvedeného v kap. 2.4, hlavní funkce pro zpracování datových toků jsou aplikovány na hraničních směrovačích. Tyto prvky tedy byly nakonfigurovány tak, aby prováděly klasifikaci a značkování příchozích paketů. Každý paket byl 65

66 zařazen do některé ze 4 definovaných tříd a na základě výsledku třídění mu byla přidělena DSCP značka, která byla uložena do DS pole v hlavičce IP protokolu. Každé přidělené DSCP značce odpovídá definovaný způsob zacházení typu BE, AF nebo EF a s ním spojená priorita, který byla paketům poskytována během jejich průchodu sítí. V tab. 3.3 jsou uvedeny konkrétní hodnoty DSCP značek přidělovaných jednotlivým třídám provozu. Dále tabulka obsahuje označení fronty, do které byly příslušné pakety ukládány ve směrovačích. Veškerý ostatní síťový provoz, který nesplňoval parametry definovaných tříd provozu, byl automaticky zařazen do výchozí třídy s nejnižší prioritou a odpovídajícím způsobem zacházení BE. Tab. 3.3: Mapování DSCP hodnot na třídy provozu v simulačním scénáři DiffServ Typ provozu Přidělená Definovaný Použitá fronta DSCP značka způsob zacházení FTP = 0 BE Q0 (výchozí) Databázový přístup = 10 AF11 Q1 HTTP = 18 AF21 Q2 VoIP = 46 EF Q3 Vzájemné závazky mezi koncovým uživatelem a poskytovatelem připojení ISP jsou definovány v podobě smlouvy SLA. Součástí dohody SLA je také dohoda o způsobu zpracování provozu TCA Traffic Conditioning Agreement, která definuje parametry samotného přenosu. Hlavním cílem této dohody je zabránění vstupu síťového provozu, který jakkoli vybočuje z dohodnutých pravidel. Mezi základní parametry TCA patří především popis přenosové sítě (propustnost, zpoždění, jitter, ztrátovost atd.) a také profily provozu, které jsou používané měřiči provozu implementovanými uvnitř hraničních směrovačů [44]. Na hraničních směrovačích proto byl pro každou QoS třídu vytvořen profil provozu obsahující parametry CIR, CBS a EBS používané mechanizmem Token Bucket pro měření příchozího provozu a ověřování, zda tento provoz splňuje parametry stanovené v TCA. Konkrétní hodnoty parametrů CIR, CBS a EBS, viz tab. 3.4, byly stanoveny na základě doporučení uvedených v [104]. Pro každou třídu provozu byla stanovena garantovaná průměrná přenosová rychlost CIR a poté podle rovnice 3.2 uvedené v [35] CBS = (CIR/8) * 2 = CIR/4, (3.2) byla spočítána velikost garantovaného shluku dat. Hodnota nadměrného shluku 66

67 EBS byla určena jako dvojnásobek CBS [35]. Tabulka 3.4 také popisuje způsob zacházení s paketem, který překročí definované parametry. Konkrétní přenosové rychlosti CIR by měly být síťovým administrátorem vždy definovány s ohledem na reálnou propustnost síťových prvků, přenosovou kapacitu použitých linek a sktrukturu provozu v dané síti. Současná verze prostředí OM (verze 16.0A) podporuje pouze měřič provozu typu srtcm, proto nebyla definována také maximální okamžitá přenosová rychlost PIR. Tab. 3.4: Parametry profilu provozu definovaného pro každou QoS třídu Třída provozu CIR [b/s] CBS [b] EBS [b] Akce v případě překročení BE Zahození paketu AF11, AF Přeznačení na jinou hodnotu DSCP EF Přeznačení na jinou hodnotu DSCP Konfigurace páteřních směrovačů byla jednodušší, neboť tyto prvky zpracovávají již označené pakety a pouze jim poskytují prioritu a způsob zacházení definovaný DSCP značkou. Z důvodu zabránění zahlcení výstupních portů směrovačů vlivem režijních dat generovaných nižšími vrstvami byla stejně jako v případě simulace technologie Int- Serv omezena maximální velikost přenosové rychlosti jednotlivých rozhraní na 75%. V případě 10 Mb/s linek byla tedy využitelná rychlost síťového rozhraní 7,5 Mb/s Rozbor výsledků simulace mechanizmu DiffServ Mechanizmus DiffServ byl v simulačním prostředí OPNET Modeler analyzován pomocí několika scénářů, kdy byl každý scénář zaměřen na sledování vybraného parametru. Délka simulace byla opět 3600 sekund. Prvním sledovaným parametrem byla velikost jitteru pro VoIP provoz. Jak je vidět z obr. 3.6, hodnoty jitteru dosažené ve scénáři s mechanizmem DiffServ jsou v porovnání se scénářem Best-effort nižší a průběh vykazuje méně výrazné kolísání. Z uvedeného grafu je také patrné, že nejstabilnější průběh jitteru je dosažen díky technologii IntServ. Na druhou stranu je však třeba také zdůraznit, že hodnoty dosažené ve všech scénářích jsou velmi nízké a tudíž při běžném VoIP hovoru akceptovatelné a uživatelem nepostřehnutelné. Pro plánované odesílání paketů z front DiffServ směrovačů je možné použít různé algoritmy. Nejpoužívanější z nich byly popsány v kap Každý algoritmus správy 67

68 Jitter [s] 0, , , , , ,00002 Best-effort DiffServ IntServ -0, , Čas simulace [s] Obr. 3.6: Jitter pro VoIP tok mezi VoIP klientem č. 3 a č. 4 front řeší obsluhu paketů odlišným způsobem, a proto byl při simulacích zkoumán vliv těchto mechanizmů na výsledné síťové parametry pro jednotlivé třídy provozu. Na směrovačích DS domény byly postupně ve třech scénářích nakonfigurovány algoritmy plánovaného odesílání paketů PQ, WRR a WFQ. Všechny tři algoritmy byly nakonfigurovány tak, aby zohledňovaly DSCP značku (DSCP-based) uloženou v hlavičce paketu. V rámci algoritmu PQ bylo v prvním scénáři použito výchozí klasifikační schéma poskytované prostředím OPNET Modeler. Toto schéma obsahuje celkem 5 různě dlouhých front, do kterých jsou pakety řazeny na základě jejich DSCP značky, viz tab Tab. 3.5: Nastavení parametrů mechanizmu PQ Úroveň priority Velikost fronty v paketech Třída provozu (DSCP) 0 20 BE, AF1x 1 40 AF2x 2 60 AF3x 3 80 AF4x 4 10 EF Parametry uvedené v tab. 3.5 jsou konfigurovatelné, proto byl vytvořen další scénář, v kterém byl definován také algoritmus PQ avšak se stejně dlouhými frontami pro všechny třídy provozu. Klasifikační schéma zůstalo stejné, pouze byla velikost každé fronty nastavena na 200 paketů. Na obr. 3.7 je znázorněno množství zahazovaných paketů pro frontu BE pro scénář PQ s rozdílnými velikostmi front a pro scénář 68

69 Množství zahozených paketů pro frontu BE [pakety] PQ se stejně velkými frontami. Fronta pro třídu provozu Best-effort byla v prvním scénáři schopna pojmout maximálně 20 paketů, proto u ní docházelo k rychlejšímu zaplnění a tím pádem i k zahazování nově příchozích paketů. Naproti tomu do BE fronty ve scénáři se stejnými velikostmi bylo možné uložit až 200 paketů, proto u ní docházelo k zahazování paketů až od 2200 sekund. Ve frontách definovaných pro ostatní třídy provozu nedocházelo ani v jednom scénáři k zahazování paketů, ž čehož plyne, že nedostatek síťových zdrojů postihl pouze provoz s nejnižší prioritou zacházení. Z grafu na obr. 3.7 je také možné odvodit čas, kdy dojde k úplnému zaplnění front, což může vést k prudkému nárůstu doby, kterou stráví pakety ve frontě. Extrémní velikost této doby pak může způsobit rozpad TCP spojení. Tento stav je zásadní zejména pro třídy provozu s nižší prioritou zacházení PQ (stejná velikost front) PQ (různá velikost front) Čas simulace [s] Obr. 3.7: Počet zahozených paketů pro frontu BE pro scénáře PQ se stejnými a rozdílnými velikostmi front Dalším analyzovaným algoritmem pro plánované odesílání paketů byl mechanizmus WRR. Pro něj bylo definováno klasifikační schéma obsahující 4 třídy provozu, viz tab Každá třída má definovanou váhu, která určuje podíl šířky pásma alokované pro danou frontu. Třetím simulovaným algoritmem pro správu front byl algoritmus WFQ. Pro něj byl opět definován konfigurační profil, který je stejný jako u algoritmu WRR (viz tab. 3.6). Rozdíl mezi oběma způsoby plánovaného odesílání paketů spočívá v tom, že WFQ je schopný zohledňovat velikost paketů a umožňuje tak spravedlivou alokaci síťových zdrojů i pro datové toky tvořenými pakety různých velikostí. Na obr. 3.8 je uvedeno srovnání end-to-end zpoždění pro VoIP provoz mezi klienty č. 2 a 4 pro jednotlivé algoritmy správy front. Jak je z grafu zřejmé, všechny 3 69

70 End-to-End zpoždění [s] Tab. 3.6: Nastavení parametrů mechanizmů WRR a WFQ Váha Velikost fronty v paketech Třída provozu (DSCP) BE AF AF EF simulované algoritmy jsou schopné zajistit VoIP provozu podobné hodnoty end-toend zpoždění pohybující se v rozmezí ms. 0,1 0,095 0,09 0,085 0,08 0,075 0,07 0,065 0,06 0,055 0, Čas simulace [s] Best-effort WFQ PQ WRR Obr. 3.8: End-to-end zpoždění pro VoIP tok mezi VoIP klientem č. 3 a č. 4 Jedním ze základních požadavků na algoritmy pro plánované odesílání paketů je schopnost efektivně obsloužit také pakety uložené ve frontách s nejnižší prioritou. Na obr. 3.9 je zobrazen průběh času, který stráví pakety FTP provozu, tedy provozu s nejnižší prioritou zacházení, ve frontě hraničního směrovače Edge_Router_1. Jak je na grafu vidět, nejvyšší zpoždění způsobuje algoritmus WRR, naproti tomu nejrychleji jsou odbaveny pakety ve frontě algoritmu PQ. Tento výsledek může být poněkud překvapující, protože právě mechanizmus PQ se vyznačuje tím, že u něj může docházet k blokování paketů s nižší prioritou v důsledku neustálého zaplňování front s vyšší prioritou. Na obr. 3.9 je však nutné se dívat také v souvislosti s celkovým charakterem provozu v dané sítí a množstvím dat, které generují jednotlivé zdroje dat. Ve vytvořeném simulačním modelu jsou sice VoIP toky řazeny do front s nejvyšší prioritou, avšak současně tento typ provozu generuje nejmenší množství dat v porovnání např. s třídou provozu FTP. Dále VoIP provoz není generován souvisle, ale pouze v cyklech 70

71 Počet paketů ve WFQ frontě [pakety] Zpoždění způsobené řazením paketů do BE fronty [s] s délkou 300 s. Z těchto uvedených důvodů tedy nedochází v dané síti u algoritmu PQ k blokování FTP provozu, neboť VoIP pakety jsou z prioritní fronty rychle odbaveny a tak se dostanou na řadu i pakety uložené ve frontách s nižší prioritou. 0,35 0,3 0,25 0,2 0,15 0,1 PQ WRR WFQ 0, Čas simulace [s] Obr. 3.9: Doba strávená pakety ve frontě typu Best-effort Posledním sledovaným parametrem z pohledu algoritmů pro plánované odesílání paketů byla míra obsazení jednotlivých front u algoritmu WFQ [8]. Na obr je vidět, že zaplnění front je největší pro třídu provozu s nejnižší prioritou (FTP). Ostatní fronty jsou využívané jen minimálně. Tento fakt vyplývá především z úrovně priority poskytnuté jednotlivým třídám provozu (viz tab. 3.6) a pak také z parametrů provozu, který generují jednotlivé zdroje dat Čas simulace [s] FTP Databáze HTTP VoIP Obr. 3.10: Obsazenost WFQ front pro jednotlivé třídy provozu Důležitou součástí technologií pro zajištění kvality služeb jsou mechanizmy pro aktivní správu front schopné předcházet stavu zahlcení síťových prvků. V kap

72 byly popsány mechanizmy RED a WRED. Tyto algoritmy byly také nakonfigurovány a odsimulovány v prostředí OM. Při konfiguraci mechanizmů RED a WRED je v prostředí OPNET Modeler možné editovat tyto základní parametry [101]: Exponenciální váhový faktor x - je používán pro výpočet vážené průměrné velikosti fronty v závislosti na předchozí hodnotě průměrné velikosti a aktuální velikosti fronty. Výpočet je prováděn podle již zmiňované rovnice (2.2) [104]. Pokud je velikost exponenciálního váhového faktoru x vysoká, pak má předchozí hodnota průměru větší váhu [23]. Při příliš vysoké hodnotě x by algoritmus RED nebo WRED nemusel být schopný zareagovat na blížící se stav zahlcení, proto je volba správné hodnoty velmi důležitá. Naopak při nízké hodnotě váhového faktoru je vážená průměrná velikost fronty ovlivněna zejména aktuální velikostí fronty, což vede k tomu, že je výpočet negativně ovlivněn shlukovým charakterem provozu a mechanizmy RED a WRED mohou zahazovat pakety, i když to není zcela nutné [33]. Minimální a maximální prahová hodnota α min a α max - jedná se o hodnoty určující moment aktivování a deaktivování algoritmů RED a WRED. Pokud je α i < α min, (3.3) pak nedochází k zahazování paketů. Pokud je α min < α i < α max, (3.4) pak je aktivován algoritmus zahazování RED nebo WRED. Pokud vážená průměrná velikost front překročí prahovou hodnotu α max, pak jsou pakety zahazovány způsobem tail-drop [34]. Faktor pravděpodobnosti zahození MPD (Mark Probability Denominator) - jedná se o podíl paketů zahozených v případě, že vážená průměrná velikost fronty η i dosáhne maximální prahové hodnoty α max. Například, pokud MPD = 10, pak vždy jeden z 10 paketů je zahozen, když η i = α max. Hodnota MPD specifikuje pravděpodobnost zahození pro rozdílné způsoby zacházení PHB [101]. Implementace mechanizmů RED a WRED v simulačním prostředí OPNET Modeler vychází ze společného základu a společných počátečních hodnot výše popsaných parametrů. Jediný rozdíl je v tom, že algoritmus WRED umožňuje definovat pro každou třídu (frontu) provozu samostatný profil zahazování paketů. Ve výchozím stavu jsou však pro všechny třídy provozu nastaveny stejné hodnoty parametrů mechanizmu WRED, takže se chová stejně jako mechanizmus RED, což potvrdily i 72

73 výsledky simulací. Proto byly výchozí hodnoty atributů WRED upraveny podle doporučení v [35] a [34]. V tab. 3.7 jsou uvedeny výchozí i upravené hodnoty parametrů WRED. Tab. 3.7: Nastavení parametrů mechanizmu WRED Parametr Výchozí hodnota (společná Upravená hodnota pro všechny třídy provozu) BE AF11 AF21 EF Exponenciální faktor x Minimální práh α min [pakety] Maximální práh α max [pakety] Faktor pravděpodobnosti zahození MPD Volba a nastavení konkrétních hodnot WRED parametrů by se vždy mělo odvíjet od úrovně vytížení přenosových linek a skladby síťového provozu [46]. Podle [34] není příliš efektivní měnit hodnoty exponenciálního faktoru x a faktoru pravděpodobnosti zahození MPD, neboť to na výsledné parametry přenosu nemá zásadní vliv. Naopak, velmi důležité je správné nastavení hodnot minimálního a maximálního prahu α min a α max. Z tohoto důvodu byly v simulačním scénáři upravovány pro jednotlivé třídy provozu pouze minimální a maximální prahová hodnota vážené průměrné velikosti fronty. Na obr je zobrazeno srovnání vážené průměrné velikosti fronty pro třídu provozu BE pro scénáře s výchozími a s upravenými WRED parametry. Výpočet je prováděn podle rovnice (2.2). Z grafu je vidět, že vážená průměrná velikost fronty α i je ve scénáři s výchozími WRED parametry větší, což je způsobeno různě nastavenými prahovými hodnotami α min a α max. U scénáře s výchozími hodnotami může aktuální velikost fronty dosahovat vyšších hodnot, protože práh zahazování je také vyšší. Z průběhu grafu je jasně vidět, že na začátku simulace narůstala vážená průměrná velikost fronty u obou scénářů téměř stejně, avšak ve scénáři s upravenými hodnotami bylo zahazování paketů aktivováno již při hodnotě 50 paketů, naproti tomu, ve scénáři s výchozími hodnotami při dosažení úrovně zaplnění 100 paketů. Z grafu je také vidět, že v žádném scénáři nedošlo k překročení maximální prahové 73

74 [pakety] hodnoty α max, takže nebylo nutné aktivovat zahazování paketů pomocí algoritmu tail-drop. 160 Vážená průměrná velikost WRED fronty η i Čas simulace [s] WRED (výchozí) WRED (upraveno) Obr. 3.11: Velikost vážené průměrné velikosti WRED fronty pro třídu provozu BE Na dalším obr je vidět množství zahozených paketů pro třídu provozu Best-effort u obou sledovaných scénářů. Průběh grafu ukazuje, že zatímco ve scénáři s optimálními hodnotami parametrů WRED docházelo pouze k minimálnímu zahazování paketů, ve scénáři s výchozími hodnotami atributů WRED byla míra zahozených paketů podstatně vyšší. Prudký nárůst množství zahozených paketů je patrný zejména ke konci simulace, což je způsobeno vznikem jevu označovaného jako globální synchronizace TCP protokolu. Ke konci simulace bylo zatížení přenosových linek velmi vysoké, proto docházelo k zahazování paketů s nižší prioritou, jejichž zdroji byly právě aplikace využívající na transportní vrstvě protokol TCP (FTP, HTTP, databázový přístup). V momentě, kdy TCP entity detekují větší množství nepotvrzených segmentů, sníží v rámci ochrany proti zahlcení rychlost odesílání segmentů. K tomuto snížení však dojde u všech TCP zdrojů přibližně ve stejnou dobu, což může způsobit další zaplnění front a navýšení množství zahozených paketů. Ochranou proti globální synchronizaci TCP protokolu jsou mechanizmy jako RED nebo WRED, avšak výsledky simulací ukázaly, že pokud jsou parametry těchto mechanizmů nevhodně nastaveny, pak může i přesto dojít k tomuto nežádoucímu jevu. Vlivem zahlcení linek a zahazování paketů s nejnižší prioritou automaticky narůstá množství nepotvrzených TCP segmentů, které je nutné vyslat znovu. Díky tomu tak klesá celková propustnost a efektivita přenosu, což se odrazilo i na době stažení jednoho souboru z FTP serveru, viz obr Nejrychleji byl soubor o velikosti 20 MB stažen ve scénáři bez implementace technologie DiffServ, což potvrdilo teoretické předpoklady, že pokud v síti není aplikován mechanizmus pro zajištění 74

75 Doba stažení souboru z FTP serveru [s] Množství zahozených paketů pro frontu BE [pakety] WRED (výchozí) WRED (upraveno) Čas simulace [s] Obr. 3.12: Počet zahozených paketů pro třídu provozu Best-effort při použití mechanizmu WRED QoS, pak jsou některé typy provozu (např. FTP) schopné do určité míry monopolizovat síťové zdroje na úkor ostatních tříd provozu. Naopak nejdelší doba odezvy byla u scénáře DiffServ bez algoritmu WRED Best-effort DiffServ WRED (upraveno) Čas simulace [s] Obr. 3.13: Doba stažení souboru z FTP serveru Z výsledků simulací technologie DiffServ lze usoudit obecný závěr, že implementace jakýchkoli mechanizmů pro zajištění QoS je efektivní pouze tehdy, pokud se nastavení parametrů těchto mechanizmů provede na základě kapacity a vytížení přenosových linek a také skladby síťového provozu v konkrétní síti. Při nevhodném nastavení priorit pro jednotlivé třídy provozu může docházet k nepřiměřenému omezení propustnosti pro třídy s nízkou prioritou zacházení. Např. klasická datová služba je ve většině případů zařazena do výchozí třídy (Best-effort) s nejnižší prioritou. To 75

76 však v některých situacích nemusí být žádoucí. Řešení tohoto problému nabízí nový QoS systém, jehož návrh je popsán v kapitole 4. Navržený systém umožní síťové aplikaci zvolit pro svůj typ provozu (např. datová služba) vhodnou QoS třídu, která nejlépe odpovídá jejím požadavkům. 3.4 Simulace technologie MPLS Při simulaci technologie MPLS byl základní model sítě doplněn o prvek MPLS Config, který umožňuje konfiguraci globálních MPLS parametrů. MPLS technologie definuje dva základní typy směrovačů. Na okraji sítě to jsou LER a uvnitř sítě pak LSR. Z tohoto důvodu byly směrovače Edge_Router_1 a Edge_Router_2 nakonfigurovány jako LER tak, aby na nich probíhala klasifikace přicházejících paketů a následné přidělování odpovídajícího návěstí. Zbývající směrovače pak byly nakonfigurovány jako LSR. Na všech směrovačích byl použit algoritmus plánovaného odesílání paketů WFQ [9]. V simulačním modelu byly na hraničních směrovačích LER příchozí pakety zařazeny do některé ze dvou definovaných FEC tříd. Jedna FEC třída byla definována pro provoz typu FTP a druhá pro VoIP toky. V rámci každé FEC třídy pak byly definovány dva profily provozu - jeden s nízkou prioritou a druhý s vysokou prioritou zacházení. Tabulka 3.8 shrnuje vytvořené FEC třídy a k nim přidružené profily provozu. Každý profil provozu je charakterizován parametry CIR, PIR, CBS a EBS. Tab. 3.8: Parametry provozu pro jednotlivé FEC třídy FEC třída Profil provozu Způsob zacházení PHB CIR [b/s] PIR [b/s] CBS [b] EBS [b] FEC_FTP FTP_low_priority AF FTP_high_priority AF FEC_VoIP VoIP_low_priority AF VoIP_high_priority EF V případě, že datový tok překročil limity dané v profilu provozu, pak byl odpovídající paket zahozen. Pro každou FEC třídu byla definována samostatná cesta LSP. V rámci prvku MPLS Config bylo definováno mapování mezi hodnotou EXP pole a způsobem zacházení PHB, které umožnuje přenášet přes jednu cestu LSP více toků s různou úrovní priority zacházení [65]. Typ PHB přidružený ke konkrétnímu profilu síťového provozu v rámci dané FEC třídy je uveden také v tab

77 End-to-End zpoždění [s] Konfigurace ostatních síťových prvků včetně nastavení aplikací a jejich profilů zůstalo stejné jako při simulacích technologií IntServ a DiffServ. Délka simulace byla opět 60 minut Analýza výsledků simulace technologie MPLS Simulace technologie MPLS byly zaměřeny zejména na situaci, kdy jsou přes jednu LSP cestu přenášeny dva obsahově totožné datové toky avšak s různou prioritou zacházení. Na obr je zobrazen průběh end-to-end zpoždění pro dva VoIP toky přenášené po stejné LSP. Jak je z grafu vidět, VoIP tok s vysokou prioritou zacházení byl v síťových prvcích zpracováván přednostně a tím pádem jsou jeho hodnoty end-to-end zpoždění nižší v porovnání s VoIP tokem s nízkou prioritou. Hodnoty zpoždění pro VoIP tok s nízkou prioritou okolo 80 ms jsou však stále z pohledu koncového uživatele akceptovatelné, což bylo způsobeno tím, že všechen ostatní provoz v síti byl přenášen způsobem Best-effort, takže ve výsledku byl VoIP tok s nízkou prioritou (AF11) určitým způsobem zvýhodněn. Vyrovnaný průběh zpoždění u obou VoIP toků potvrzuje velmi dobrou schopnost technologie MPLS rezervovat síťové prostředky pro vybrané typy provozu a zároveň také odráží skutečnost, že linky mezi páteřními směrovači byly vytížené v průměru jen kolem 30% [10]. 0,09 0,08 0,07 0,06 0,05 0,04 0,03 0,02 VoIP tok s nízkou prioritou VoIP tok s vysokou prioritou 0, Čas simulace [s] Obr. 3.14: End-to-end zpoždění pro VoIP toky s nízkou a vysokou prioritou Velikost end-to-end zpoždění má vliv také na hodnotu MOS, která udává uživatelskou spokojenost s výsledným přenosem hlasu. Na obr je vidět, že pro VoIP tok s vysokou prioritou se hodnota MOS blíží 3,6, což odráží situaci, kdy někteří uživatelé mohou být nespokojeni. Pro VoIP tok s nízkou prioritou klesla hodnota MOS pod 3,1, což představuje situaci, kdy jsou téměř všichni uživatelé nespokojeni 77

78 End-to-End zpoždění [s] Mean Opinion Score [-] [82]. Podle [103] je však hraniční hodnota MOS pro VoIP technologii 2,6, takže z tohoto pohledu je kvalita obou toků stále akceptovatelná. 3,6 3,5 3,4 VoIP tok s nízkou prioritou 3,3 3,2 VoIP tok s vysokou prioritou 3, Čas simulace [s] Obr. 3.15: Hodnota MOS pro VoIP toky s nízkou a vysokou prioritou Ve druhém MPLS scénáři byla opět simulována situace, kdy jsou přes jednu cestu LSP přenášeny dva datové toky s různou prioritou. Tentokrát se však jednalo o provoz typu FTP. Na obr je vidět průběh end-to-end zpoždění pro pakety FTP toků s vysokou (AF41) a nízkou prioritou (AF11). Jak je z grafu vidět, hodnoty zpoždění pro vysoce-prioritní FTP tok jsou nižší a výrazně vyrovnanější s průměrnou hodnotou okolo 1 s. Naproti tomu end-to-end zpoždění paketů FTP toku s nízkou prioritou je nestabilní a dosahuje hodnot až 9 s Čas simulace [s] FTP tok s nízkou prioritou FTP tok s vysokou prioritou Obr. 3.16: End-to-end zpoždění pro FTP toky s nízkou a vysokou prioritou 78

79 4 NÁVRH NOVÉHO QOS SYSTÉMU S UŽIVATELSKOU INTERAKCÍ Trend v oblasti síťových komunikací a zejména pak skladba síťového provozu jasně ukazují, že moderní datové sítě se neobejdou bez mechanizmů pro odlišné zacházení s různými typy dat. Původní účel a také počet uživatelů IP sítí se od jejich vzniku výrazně změnil. V dnešní době je dominantní přenos multimediálních dat v reálném čase, na který nejsou IP sítě ve své původní podobě připraveny. Klasický způsob zpracování datových toků označovaný jako Best-effort, který dává všem paketům stejnou prioritu při průchodu sítí, je sice z pohledu implementace v síťových prvcích velmi jednoduchý, avšak pro přenos dat citlivých zejména na zpoždění a jeho proměnlivost je velice neefektivní. Z těchto důvodů jsou do současných datových sítí implementovány dodatečné mechanizmy, jejichž základním cílem je klasifikace síťového provozu a následná rezervace síťových zdrojů v závislosti na míře priority daného typu služby. Existuje poměrně velké množství návrhů těchto mechanizmů, avšak většinu z nich se nikdy nepodařilo rozšířit nějakým zásadním způsobem. Jednou z mála technologií, která byla skutečně implementována do síťových zařízení a stala se v současnosti nejrozšířenější technologií pro zajištění kvality služeb, je technologie DiffServ. Principy fungování tohoto mechanizmu byly popsány v kapitole 2.4. Při vývoji technologie DiffServ byl kladen velký důraz na její maximální jednoduchost a také transparentnost z pohledu koncových uživatelů. Paradoxně se však právě tyto vlastnosti staly zdrojem jednoho z hlavních nedostatků mechanizmu DiffServ, kterým je chybějící spolupráce s koncovým zařízením. Jako jedno z možných řešení tohoto problému je v této práci navržen nový systém, který rozšiřuje mechanizmus DiffServ o funkce umožňující uživatelské stanici definovat svoje požadavky na parametry přenosu. Následující kapitola tedy obsahuje popis návrhu tohoto nového QoS systému. Nejprve jsou však definovány obecné požadavky kladené na nový systém podpory zajištění kvality služeb. Na základě analýzy těchto požadavků je pak představen konkrétní návrh QoS systému umožňujícího interakci mezi koncovou aplikací a hraničním síťovým prvek. V dalším textu jsou pak popsány základní principy a funkční bloky navrženého mechanizmu. 79

80 4.1 Obecné požadavky kladené na nově navrhovaný QoS sytém Při návrhu jakéhokoli systému je nutné nejprve stanovit základní požadavky na daný systém, z nichž se pak odvodí konkrétní princip, základní funkce a jednotlivé funkční bloky. V následujícím textu tedy budou popsány obecné požadavky, které byly definovány před návrhem nového systému pro zajištění QoS v datových sítích. 1. Komunikace mezi koncovým zařízením a hraničními prvky sítě - jak již bylo uvedeno, jedním ze základních problémů současných technologií pro zajištění QoS je chybějící komunikační kanál mezi uživatelskou aplikací, obecně koncovým zařízením, a hraničním prvkem sítě, což je počáteční místo, kde jsou aplikovány QoS mechanizmy. Při současném stavu koncová stanice vyšle svoje data směrem do sítě a předpokládá určitou úroveň kvality služby. Avšak až hraniční prvek sítě určí na základě své konfigurace a dostupných síťových zdrojů skutečnou úroveň poskytnuté QoS. Tento stav tedy může v řadě případů vést k rozporu v tom, co uživatelská aplikace vyžaduje (potřebuje) a co je jí poskytnuto. Z tohoto důvodu je prvním požadavkem na nový systém pro zajištění kvality služeb vytvoření komunikačního kanálu, který bude umožňovat vzájemnou interakci mezi koncovým zařízením a hraničním prvkem sítě. Uživatelská aplikace tak bude schopna přesně definovat svoje požadavky na síťové zdroje a výslednou úroveň kvality služby. 2. Minimální zatížení síťových prvků - dalšími ze základních požadavků jsou jednoduchost a minimální zatížení síťových prvků. Historie ukázala, že pokud je navržený mechanizmus příliš složitý a klade vysoké nároky na zúčastněná síťová zařízení, tak i přes jeho možnou vysokou účinnost je nevhodný pro masové rozšíření. Příkladem toho je technologie IntServ, která sice nabízí zajištění end-to-end QoS, ale současně příliš zatěžuje síťové uzly, což je zejména v páteřních sítích, kde musí směrovače zpracovávat velké množství datových toků v minimálním čase, nežádoucí. Z tohoto důvodu se mechanizmus IntServ nikdy zásadně nerozšířil. Na základě prvního požadavku je jasné, že v rámci nově navrženého QoS systému bude nutná komunikace mezi uživatelskou stanicí a síťovým prvkem. Použitý komunikační model však má být co nejjednodušší, aby síťové prvky a přenosové linky zatěžoval jen minimálně. 3. Minimální zásahy do stávající infrastruktury - navržený systém pro 80

81 podporu kvality služeb má v maximální míře využívat stávající síťové infrastruktury. Jednotlivé funkční bloky navrženého mechanizmu mají využívat výhradně standardizovaných prostředků, které jsou běžně dostupné v aktivních síťových prvcích. Jakýkoli zásah do architektury běžně používaných síťových mechanizmů a protokolů výrazným způsobem snižuje šance na globální rozšíření nové metody. 4. Nezávislost na fyzické implementaci - v dnešní době existuje velké množství výrobců síťových zařízení, a proto je velmi důležité, aby byl nově navržený mechanizmus nezávislý na fyzické implementaci standardních síťových mechanizmů. Většina současných síťových technologií je definována na logické úrovni, kdy je uveden pouze koncepční model doplněný popisem základních operací jednotlivých funkčních bloků, avšak fyzická implementace je již ponechána na konkrétním výrobci. Z tohoto důvodu je nutné, aby nový QoS systém umožňoval spolupráci s jakýmikoli síťovými zařízeními nezávisle na jejich výrobci. Použité metody tedy mají vycházet z obecných zásad a vlastností referenčních modelů jednotlivých QoS mechanizmů. 5. Dodržování dohodnutých pravidel a zásad - síťový provoz přenášený přes datové sítě musí ve většině případů splňovat předem dohodnutá pravidla a zásady. Místem pro aplikaci těchto zásad je nejčastěji rozhraní mezi koncovým uživatelem a sítí zastoupenou poskytovatelem připojení ISP, anebo dvěma sítěmi spravovanými různými ISP. Z pohledu návrhu systému umožňujícího spolupráci koncové stanice s hraničním prvkem sítě jsou důležitá pravidla definována právě na tomto rozhraní. Jednou z nejčastějších forem zápisu pravidel provozu je dohoda SLA uzavřená mezi zákazníkem a poskytovatelem služby. Nově navržený systém tedy má ovlivňovat síťový provoz generovaný koncovou stanicí pouze do takové míry, aby nepřekračoval dojednané parametry. Datové toky, které nesplňují definované podmínky, jsou většinou na hraničních uzlech degradovány na nižší prioritu zacházení nebo přímo zahazovány, což výrazně snižuje celkovou propustnost a efektivitu přenosu. 6. Koexistence se stávajícími technologiemi - navržený systém musí zajistit plnou koexistenci se všemi standardními technologiemi. Pokud se tedy síťová služba rozhodne nevyužívat funkcí navrženého mechanizmu, musí jí být poskytnut standardní způsob zacházení odpovídající základní implementaci použitých technologií. 7. Jednoduchá ověřitelnost - každý nově navržený mechanizmus prochází nejprve fází testování, a pokud je tato fáze úspěšně dokončena, tak až poté se přistupuje k implementaci do reálného prostředí. Proto má být nový systém 81

82 snadno implementovatelný a následně ověřitelný ve vhodném simulačním nástroji nebo v laboratorní síti. Testování v simulačním prostředí umožní analyzovat a následně odstranit případné nedostatky a také definovat požadavky pro nasazení v reálných podmínkách. 4.2 Analýza požadavků a definice základních vlastností navrženého QoS systému Na základě podrobné analýzy výše uvedených obecných požadavků bylo nalezeno optimální řešení jednotlivých požadavků. Z těchto dílčích řešení pak vzešel soubor základních vlastností a dílčích funkcí nového QoS systému umožňujícího spolupráci koncového zařízení s hraničním prvkem vybrané QoS technologie. V následujícím textu bude popsán způsob analýzy požadavků uvedených v kapitole 4.1 a jejich navrhované řešení Komunikace mezi koncovým zařízením a hraničními prvky sítě Prvním z analyzovaných požadavků byla potřeba vytvoření komunikačního rozhraní mezi uživatelským zařízením a hraničním prvkem sítě, které má umožnit efektivnější definici QoS požadavků ze strany samotné aplikace. Samotná možnost definování QoS požadavků však není nic nového. V současné době již existuje řada způsobů, jak na koncových stanicích nastavit hodnotu ToS nebo DSCP v hlavičce IP paketu, ať už v podobě konkrétních síťových aplikací nebo hardwarových zařízení, které tuto funkci umožňují, anebo prostřednictvím QoS API, které je součástí operačního systému [40]. Toto nastavení je však prováděno bez znalosti reálné konfigurace QoS mechanizmů uvnitř síťových uzlů, což ve většině případů vede k tomu, že hraniční směrovač provede přeznačení paketu na jinou úroveň priority zacházení, která odpovídá nastavení QoS parametrů v rámci dané sítě. Z tohoto důvodu bylo nutné definovat mechanizmus pro získávání informací o nastavení parametrů QoS technologie přímo z hraničního prvku. Získané informace jsou na koncovém zařízení následně použity pro nastavení úrovně požadované priority zacházení. Vzhledem k dalším požadavkům týkajících se minimálních zásahů do stávající infrastruktury a nezávislosti na fyzické implementaci bylo třeba nalézt standardizovaný mechanizmus podporovaný v běžných síťových zařízeních. Jako řešení se nabízí použití protokolu SNMP (Simple Network Management Protocol), který je primárně určen pro vzdálenou správu síťových zařízení [73]. Jedná se o protokol běžně implementovaný v každém pokročilejším aktivním síťovém prvku [75]. SNMP 82

83 byl vybrán zejména proto, jelikož umožňuje přístup ke konfiguračním informacím jednotlivých síťových zařízení. Právě této vlastnosti bude využito při získávání informací o nastavení podporovaných tříd provozu, množství přidělených síťových zdrojů, apod. Zmíněné konfigurační údaje jsou na síťových zařízeních standardně uloženy v podobě objektů specializované databáze označované jako MIB (Management Information Base). Volba protokolu SNMP tedy splňuje požadavek na komunikační rozhraní mezi koncovou stanicí a síťovým prvkem a zároveň také umožňuje přístup do databáze MIB obsahující konfigurační parametry daného síťového zařízení a jím podporovaných technologií. Způsob použití protokolu SNMP v nově navrženém systému včetně algoritmů práce s databází MIB bude podrobněji popsán v dalších kapitolách Minimální zatížení síťových prvků Druhým požadavkem bylo minimální zatížení síťových prvků. V rámci analýzy této potřeby bylo nutné nejprve zvolit základní mechanizmus pro zajištění kvality služeb, který bude rozšířen o navrhovaný systém. Potřeba základního mechanizmu vyplynula z úvahy, že vývoj nového systému pro zajištění QoS, který by zcela nahradil současné technologie, je značně neefektivní. Takový systém by totiž vyžadoval podporu ze strany výrobců síťových zařízení v podobě úpravy firmwaru stávajících síťových prvků, což je v dnešní době v globálním měřítku jen těžko proveditelné. Druhým důvodem je to, že současné technologie pro podporu QoS, např. DiffServ, pracují na úrovni sítě poměrně uspokojivým způsobem, avšak chybí jim již zmíněná interakce s koncovými zařízeními. V současnosti přichází v úvahu dvě QoS technologie, které by se mohly stát stavebním kamenem navrhovaného systému. První je technologie IntServ (viz kap. 2.3) a druhá je DiffServ (viz kap. 2.4). Technologie IntServ však představuje vysokou zátěž pro aktivní síťové prvky a klade vysoké nároky zejména na výpočetní výkon procesoru síťových zařízení. Právě z tohoto důvodu se tato technologie nikdy ve větší míře neprosadila. Naopak technologie DiffServ přistupuje k zajišťování kvality služeb odlišným způsobem a síťové prvky zatěžuje podstatně méně. Proto se mechanizmus DiffServ stal velice oblíbenou a podporovanou QoS technologií u poskytovatelů síťových služeb i výrobců zařízení. Na základě těchto zjištění byla zvolena technologie diferencovaných služeb jako základní mechanizmus, kterého bude nově navržený systém využívat a rozšiřovat jej o možnost účasti koncové stanice na procesu vyjednávání úrovně QoS. Další popis nového QoS systému tedy bude zaměřen na spolupráci s technologií DiffServ. Architektura DiffServ ponechává většinu úkolů spojených se zajištěním QoS na 83

84 hraničních směrovačích, čím snižuje míru zatížení páteřních prvků. V rámci navrhovaného rozšíření se předpokládá komunikace výhradně s hraničním uzlem, takže páteřní směrovače nebudou daným systémem nijak ovlivněny. Komunikace s hraničním prvkem bude omezena na pouhé vyčítání potřebných informací z jeho konfigurační databáze MIB, takže i zatížení hraničních směrovačů bude minimální. Tím je tedy splněn tento druhý požadavek Minimální zásahy do stávající infrastruktury a nezávislost na fyzické implementaci Analýzu požadavků na minimální zásahy do stávající síťové infrastruktury a nezávislost na fyzické implementaci síťových prvků je možné spojit, neboť spolu úzce souvisí. Tyto požadavky už byly částečně rozebrány při výběru komunikačního protokolu pro získávání dat z hraničního směrovače. Při předpokladu, že bude navržený systém fungovat jako rozšíření mechanizmu DiffServ, je třeba zajistit, aby tento systém zcela využíval standardizovaných funkcí a komponent mechanizmu DiffServ bez nutnosti jakékoli jejich úpravy. Jednotlivé bloky a jejich funkce mechanizmu diferencovaných služeb jsou popsány v dokumentu RFC 2475 [22]. Uvedená architektura je popsána se snahou o maximální jednoduchost a efektivitu. Popis jednotlivých funkčních bloků je dostatečně abstraktní, což dává výrobcům síťových prvků volnost při jejich implementaci. Nereálnost požadavku na globální úpravu firmwaru stávajících aktivních síťových prvků již byla rozebrána, proto je nutné, aby funkce navrženého QoS systému nebyly závislé na konkrétním typu síťového zařízení, ale naopak byly aplikovatelné u většiny používaných prvků. Uvedené požadavky již byly prakticky uspokojeny tím, že jako základní mechanizmus byla vybrána technologie DiffServ a pro získávání informací o konfiguraci této technologie byl vybrán protokol SNMP umožňující přístup do MIB databáze síťových prvků. Všechny tyto uvedené síťové komponenty jsou totiž běžně podporovány ve většině síťových zařízení používaných v dnešních datových sítích. Navržený systém tedy nebude nijak měnit stávající mechanizmy, pouze je bude využívat v takové podobě, jak jsou standardizovány a implementovány Dodržování dohodnutých pravidel a zásad Další požadavek se týkal dodržování definovaných zásad síťového provozu. Téměř v každé síti je jejím správcem nastavena určitá politika provozu, která vymezuje typy provozu a jejich parametry, které smějí být v dané síti provozovány. Dále je v této dohodě o poskytování služeb SLA, jak se často politika provozu označuje, popsáno 84

85 řešení situace, kdy některý z datových toků vybočuje z dohodnutých podmínek. Aby byl navržený systém efektivní, je třeba, aby jím zpracovaný provoz splňoval parametry dané v SLA nebo TCA dohodě. Pokud by datový tok označkovaný již na úrovni koncové stanice nesplňoval podmínky SLA, došlo by na hraničním prvku k přeznačení DSCP hodnot paketů nebo jejich přímému zahození. Řešení tohoto požadavku spočívá v tom, že budou z hraniční směrovače DiffServ domény získávány kromě informací, jako podporované třídy služeb, definované způsoby zacházení atd., hodnoty parametrů používané v měřičích provozu. Konkrétně se jedná nejčastěji o garantovanou průměrnou přenosovou rychlost CIR, maximální okamžitou přenosovou rychlost PIR a povolené velikosti garantovaného (CBS), nadměrného (EBS) a maximálního shluku (PBS). V rámci navrženého systému pak bude síťový provoz generovaný uživatelskou aplikací zpracováván v souladu s těmito zjištěnými informacemi tak, aby při příchodu na hraniční prvek prošel mechanizmem měření a vyhověl dohodnutým pravidlům. Kdyby přeci jen náhodou došlo k situaci, že datový tok překročí dojednané parametry, hraniční směrovače bude mít vždy právo provoz přeznačit na jinou prioritu zacházení, či provést jeho přímé zahození Koexistence se stávajícími technologiemi Je velmi důležité, aby navržený systém umožňoval současné fungování stávajících síťových technologií bez sebemenších omezení. Pokud se tedy koncová aplikace rozhodne z nějakého důvodu nevyužít funkcí navrženého systému, musí jí být umožněno použití standardních síťových mechanizmů. Pokud tedy jde o proces získávání konfiguračních informací z hraničního DS směrovače a nastavení hodnoty DSCP na základě těchto informací, pak musí být umožněno odesílat data z koncového zařízení neoznačená (běžný stav), případně označená jiným způsobem. Splnění tohoto požadavku bude zajištěno tím, že popsaný QoS systém bude na koncovém zařízení implementován v podobě systémového rozhraní API (Application Programming Interface) a uživatelské aplikaci budou tedy funkce tohoto API pouze nabídnuty. Rozhodnutí, zda této nabídky využije, je zcela na aplikaci Jednoduchá ověřitelnost Požadavek na jednoduchou ověřitelnost vychází spíše z procesu vývoje tohoto systému než z podstaty jeho fungování ve finální podobě. Před vlastní implementací systému v koncových zařízeních je třeba absolvovat fázi testování a ladění navrženého systému. Systém by měl tedy umožňovat jednoduché ověření jeho funkčnosti. Jedním z nejčastějších způsobů testování nově navržených mechanizmů jsou v současné době simulační nástroje. Pro ověření a funkční analýzu navrženého sys- 85

86 tému bylo vybráno simulační prostředí OPNET Modeler. Toto prostředí disponuje velkým množstvím předpřipravených knihoven síťových technologií, protokolů a zařízení, čímž umožňuje modelování široké škály síťových mechanizmů. Kromě toho je možné vytvářet uživatelské modely a implementovat tak do simulačního prostředí jakoukoli novou technologii. Této vlastnosti bude právě využito při vytváření modelu nově navrženého QoS systému. Aby však testování systému nebylo omezené čistě na simulační prostředí, byl do simulačního procesu začleněn také reálný síťový prvek. Konkrétně se jednalo o IP směrovač od firmy Cisco. Z tohoto důvodu byl návrh systému v první fázi uzpůsoben tak, aby podporoval získávání konfiguračních dat z MIB databáze implementované v Cisco zařízeních, která je označována jako Cisco CBQoS (Class-Based QoS) MIB [38]. I přesto, že aktivní síťová zařízení od firmy Cisco v polovině roku 2010 tvořila téměř polovinu trhu s podnikovými směrovači [41], tak bude navržený QoS systém samozřejmě v další fázi vývoje rozšířen na podporu obecné databáze MIB určené pro technologii diferencovaných služeb specifikované v dokumentu RFC 3289 pod názvem DIffServ-MIB [19] Základní princip navrženého QoS systému Na základě analýzy obecných požadavků byl vytvořen soubor konkrétních řešení a podle něj pak byly stanoveny postupy pro splnění základních vlastností nového QoS systému. Pro větší přehlednost jsou zvolené postupy a shrnuty do bodů. Motivace: odstranění jednoho ze základních nedostatků současných QoS technologií v podobě chybějící interakce mezi hraničním prvkem sítě a koncovým zařízením. Hlavní myšlenka: umožnění koncové aplikaci efektivnější definici svých QoS požadavků na základě konfiguračních informací získaných z hraničního prvku sítě. Zaměření: technologie Diffserv, navržený systém bude tvořit její rozšíření. Využití stávajících síťových komponent: SNMP (komunikace mezi koncovým zařízením a síťovým uzlem), MIB (přístup ke konfiguračním informacím). Potřeba úpravy stávajících zařízení nebo technologií: ne. Bezpečnost: na síťových prvcích bude docházet pouze k vyčítání požadovaných informací, systém nebude obsahovat funkce pro jejich úpravu. Provoz bude zpracováván v souladu se zjištěnými parametry definovanými v SLA. Předpokládaná oblast nasazení: uživatelské stanice v podobě rozhraní API. 86

87 4.3 Protokol SNMP (Simple Network Management Protocol) Protokol SNMP byl vybrán jako komunikační mechanizmus pro vzájemnou výměnu dat mezi koncovou stanicí a hraničním směrovačem DiffServ domény. Aby bylo možné v dalším textu popsat využití tohoto protokolu v navrženém QoS systému, bude v této kapitole uveden základní popis SNMP protokolu a jeho komponent. Protokol SNMP byl původně představen organizací IETF v roce 1988 v dokumentu RFC 1067 [27], který byl postupně nahrazen dokumenty RFC 1098 [28] a RFC 1157 [29]. V současné době existují tři verze SNMP protokolu - SNMPv1 [29], SNMPv2 (někdy označovaná jako SNMPv2c) [88] a SNMPv3 [31]. Protokol SNMP vznikl na základě požadavku na vzdálený dohled a správu síťových zařízení v IP sítích. Jádro protokolu SNMP je tvořeno jednoduchou sadou operací, která dává administrátorovi schopnost kontrolovat a konfigurovat stav síťových zařízení [69]. Protokol SNMP se stal velmi oblíbeným a rozšířeným nástrojem pro správu síťových komponent také kvůli jeho univerzálnosti, velmi jednoduché implementaci a možnosti budoucího rozšíření, čehož využívají výrobci síťových zařízení Základní model správy síťových zařízení pomocí protokolu SNMP Protokol SNMP je postaven na modelu dvou entit - agenta a manažera. Agent v podobě SNMP softwarového modulu je implementován do spravovaného zařízení (např. směrovače, servery, síťové mosty, atd.). Agent zajišťuje přístup do MIB databáze, která obsahuje konfigurační informace daného síťového zařízení. Manažer je nejčastěji pracovní stanice nebo server vybavený softwarovým modulem umožňujícím centralizovanou správu a dohled síťových prvků (agentů). Komunikace mezi SNMP manažerem a agentem funguje na principu dotaz-odpověď, kdy manažer zasílá pravidelné dotazy agentovi a ten na ně odpovídá. Jediná situace, kdy komunikaci iniciuje agent, je případ naléhavých zpráv (např. porucha zařízení), které jsou agentem posílány manažerovi bez předchozí výzvy. Tyto naléhavé zprávy se označují jako Trap [32]. Při vývoji protokolu SNMP byl kladen velký důraz na jeho jednoduchost a minimální zátěž síťových prvků, z tohoto důvodu pro přenos SNMP zpráv využívá nespolehlivý transportní protokol UDP. Jelikož protokol UDP neřeší potvrzování vyslaných datagramů, musí si řádné doručení datagramu ošetřit samotná aplikace. Protokol SNMP využívá pro detekci ztracených zpráv mechanizmus časovačů. Ko- 87

88 munikace na úrovni transportní vrstvy probíhá na UDP portech 161 (standardní výměna zpráv) a 162 (příjem zpráv trap od agentů) [73]. Aby byla zajištěna určitá úroveň bezpečnosti při správě síťových prvků pomocí protokolu SNMP, jsou definovány textové řetězce (community string), které plní úlohu hesla při přístupu manažera k informacím uloženým na agentovi. Jsou definovány tři základní typy komunit: pouze pro čtení, čtení i zápis a trap. Každý typ definuje rozsah činností, které může manažer provádět s daty na straně agenta. Problém tohoto způsobu autentizace je v tom, že řetězec komunity je přenášen v otevřené podobě, takže může být snadno odchycen a zneužit. Tento problém řeší až poslední verze SNMPv3, které kromě jiného přidává funkci zabezpečené autentizace a komunikace mezi SNMP entitami [69] Struktura řídících informací V rámci SNMP architektury se manažeři připojují k agentům za účelem získávání jejich konfiguračních parametrů. Tyto parametry jsou na síťovém zařízení uloženy v podobě řízených objektů uvnitř logické databáze MIB. Aby byl manažer schopný přistoupit ke konkrétnímu objektu, musí být definován standardizovaný způsob interpretace řízených objektů. K tomuto účelu se využívá struktura řídících informací SMI (Structure of Management Information). V návaznosti na vývoj jednotlivých verzí protokolu SNMP vznikly také dvě verze struktury řídících informací - SMIv1 definovaná v RFC 1155 [94] a SMIv2 definovaná v RFC 2578 [70]. Popis spravovaných objektů stromové struktury je možné rozdělit na tři atributy [69]: Název - tento parametr slouží k jednoznačné identifikaci spravovaného objektu. Častěji se označuje jako identifikátor objektu OID (Object Indetifier). Název objektu může být jmenný, což je pro člověka snadněji zapamatovatelné, nebo číselný. Např. OID v číselné podobě může mít tvar a ve jmenné podobě iso.org.dod.internet.mgmt.mib-2.system. Typ a syntaxe - typ a syntaxe spravovaného objektu je definována pomocí jazyka ASN.1 (Abstract Syntax Notation One). ASN.1 popisuje, jakým způsobem jsou data reprezentována a přenášena mezi manažery a agenty. Notace jazyka ASN.1 je nezávislá na platformě, takže spolu mohou komunikovat různá zařízení využívající odlišný operační systém. Kódování - tento atribut určuje, jak má být fyzicky vyjádřena konkrétní instance spravovaného objektu. Pro tento účel se používá kódování BER (Basic Encoding Rules), které definuje, jak mají být objekty kódovány a dekódovány za účelem přenosu přes komunikační kanál. 88

89 Struktura SMIv1 je zobrazena na 4.1. Druhá verze struktury řídících informací SMIv2 rozšiřuje původní verzi SMIv1 o novou větev stromové struktury snmpv2, jejíž OID je (iso.org.dod.internet.snmpv2.). Spolu s novou větví byly doplněny také nové datové typy spravovaných objektů. Definice objektů je ve verzi SMIv2 také mírně odlišná od původní verze. Přibylo několik nových volitelných polí, které umožňují lepší definici možností přístupu k danému objektu, přidávání nových sloupců do tabulek nebo lépe popsat spravovaný objekt (např. definovat použitou jednotku hodnoty spravovaného objektu) [30], [70]. SMIv2 také definuje nový způsob textového popisu, který umožňuje definovat spravované objekty na více abstraktní úrovni, což usnadňuje čtení MIB databází [71]. Kořenový uzel ccitt(0) iso(1) joint(2) org(3) dod(6) internet(1) directory(0) mgmt(1) experimental(3) private(4) Obr. 4.1: Struktura řídících informací SMIv1 Kódování BER Spravované objekty popsané prostřednictvím jazyka ASN.1 je nutné převést do podoby toku bitů, které mohou být přeneseny přes fyzické médium. Pro tento účel se u architektury SNMP využívá kódování BER, což je sada kódovacích pravidel, které převádí zápis jazyka ASN.1 do strojově čitelného formátu. BER je definováno jako jeden z kódovacích formátů pro jazyk ASN.1 v doporučení ITU-T X.690 [60]. Základní princip kódování BER spočívá v tom, že každý přenášený objekt je zakódovaný pomocí tří polí: typ (Type), délka (Length) a hodnota (Value). Výsledkem kódování pomocí modelu TLV (Type-Length-Value) je pak sled bajtů skládajících se z uvedených tří polí. Pole typ určuje typ dat uložených v poli Value a je vyjádřeno 89

90 pomocí jedno-bajtového identifikátoru. Pole délka pak určuje délku přenášených dat v bajtech a část hodnota obsahuje vlastní hodnotu objektu (číslo, řetězec, OID atd.). Popis kódování pomocí pravidel BER je poměrně složitý, a proto zde nebude tato problematika více rozebírána. Podrobný popis lze však nalézt např. v [73] Základní operace protokolu SNMP V předchozím textu byl uveden způsob abstraktního popisu spravovaných objektů a také jejich transformace do podoby vhodné pro přenos po fyzickém médiu. Tato kapitola se bude zabývat samotným procesem získávání konfiguračních informací ze spravovaných zařízení. Protokol SNMP za tímto účelem definuje několik typů operací. Pro každou operaci je definována datová jednotka PDU (Protocol Data Unit) s odpovídající strukturou. Zpráva SNMP protokolu je tvořena dvěma částmi. První část tvoří identifikátor verze SNMP protokolu a řetězec komunity. Někdy je tato část označovaná jako SNMP autentizační hlavička [73]. Druhá část je pak tvořena zmíněnou datovou jednotkou PDU, jejíž struktura je závislá na typu přenášeného dotazu nebo odpovědi. V první verzi protokolu SNMPv1 bylo definováno pět typů PDU: GetRequest, Get- NextRequest, GetResponse, SetRequest a Trap. Další verze SNMPv2c pak přidala další čtyři: GetBulk, Notification, Inform a Report. Na obr. 4.2 je zobrazena struktura SNMP zprávy včetně obecného formátu PDU společného pro základní zprávy typu Get a Set. Číslo verze zajišťuje, že agent i manažer využívají stejnou verzi SNMP protokolu, protože zprávy zasílané mezi agentem a manažerem, které obsahují odlišný identifikátor verze, nejsou zpracovávány, ale rovnou zahazovány. Komunity je již zmíněný řetězec pro ověření manažera před jeho přístupem k datům agenta. Pokud je úspěšně provedena kontrola hlavičky SNMP zprávy (verze i komunity souhlasí), pak je přistoupeno ke zpracování části SNMP PDU [73]. Vnitřní struktura datové jednotky PDU je pro operace typu Set, Get a Response blíže popsána v [29]. Zpráva typu Trap má mírně odlišný formát PDU. Význam jednotlivých polí je uveden např. v [73]. V následujícím textu budou stručně popsány základní SNMP operace [69], [73]: Operace GetRequest - je základní operací protokolu SNMP a slouží k získání hodnoty určitého spravovaného objektu. Dotaz typu GetRequest je vysílán manažerem směrem k agentovi. Agent tento dotaz přijme, zpracuje (vyčte OID dotazovaného objektu), a pokud na něj najde ve své MIB databázi odpověď, tak ji zašle ve formě GetResponse PDU. Operace GetNextRequest - umožňuje postupné vyčítání sekvence hodnot 90

91 Zpráva protokolu SNMP Verze Komunita Datová jednotka operace (PDU) Typ Identifikátor požadavku Indikátor chyby Index chyby Objekt 1, Hodnota 1 Objekt 2, Hodnota 2 Objekt n, Hodnota n Proměnná část jednotky Obr. 4.2: Struktura datové jednotky SNMP PDU spravovaných objektů. Předchozí operace GetRequest umožňuje získání pouze jedné konkrétní hodnoty spravovaného objektu, což může být obtížné např. v případě, že daný objekt je tabulka a manažer nezná její přesnou velikost. Pomocí dotazu GetNext tak může vyčíst všechny hodnoty této tabulky. Postupné vyčítání hodnot objektů z MIB databáze v lexikografickém pořadí je spuštěno zasláním první zprávy GetNextRequest, která obsahuje OID objektu, odkud začne vyčítání. Poté je pro každé následující OID automaticky vygenerována dvojice zpráv GetNextRequest a GetResponse. Tento proces postupného procházení a vyčítání struktury MIB tabulky končí v momentě, kdy je dosaženo konce MIB. Operace GetBulk - byla přidána ve verzi SNMPv2c. Tato operace umožňuje manažerovi vyčíst větší část MIB tabulky v rámci jednoho dotazu. Standardní dotaz typu Get sice také umožňuje současně získat více než jeden MIB objekt, ale velikost odpovědi je omezená možnostmi agenta. Pokud tedy agent není schopný zaslat v odpovědi všechny požadované hodnoty, pak zašle pouze chybovou zprávu bez dat. Naproti tomu operací GetBulk říká manažer agentovi, aby odeslal tolik požadovaných hodnot, kolik je schopen. Může se tedy stát, že odpověď nebude obsahovat všechna požadovaná data, nicméně manažer získá alespoň část požadovaných objektů. Operace SetRequest - předchozí typy SNMP operací sloužily pro získávání hodnot z MIB databáze. Operace SetRequest umožňuje zapsat konkrétní hodnoty objektů. Je možné jednak upravovat hodnoty stávajících objektů, ale také přidávat nové řádky do tabulky. Pokud má SNMP agent právo zápisu do MIB, pak agent provede požadovanou úpravu objektu a odpoví zprávou typu 91

92 GetResponse. Operace Trap - je jedinou operací, kterou vysílá agent bez předchozí výzvy od manažera. Důvodem vzniku této operace byla potřeba informovat manažera o naléhavé situaci, která vznikla na straně agenta a je třeba ji oznámit okamžitě bez čekání na pravidelný dotaz typu GetRequest. Operace Notification - zprávy typu Trap mají v první verzi protokolu SNMPv1 odlišný formát od PDU používaných pro operace Get a Set. V rámci snahy o sjednocení těchto struktur byla ve verzi SNMPv2c zavedena zpráva Notification, která má stejnou strukturu jako Get a Set a plní funkci varovných zpráv Trap. Operace Inform - druhá verze SNMP protokolu nabízí informační mechanizmus pro zasílání potvrzovaných varovných zpráv. Protokol SNMP využívá na transportní vrstvě nepotvrzovaný protokol UDP. V případě zasílání varovných zpráv z agenta směrem k manažerovi je však vhodné, aby bylo doručení těchto zpráv potvrzeno. Proto byla definována zpráva Inform, jejíž přijetí musí síťový uzel vždy potvrdit. Agent tak ví, zda byla varovná zpráva skutečně doručena manažerovi. Operace Report - tato operace byla definována v rámci SNMPv2c, avšak skutečně implementována byla až ve verzi SNMPv3, kde umožňuje SNMP entitám komunikovat vzájemně mezi sebou. 4.4 Databáze MIB (Management Information Base) Databázi MIB je možné interpretovat jako virtuální úložiště spravovaných objektů uspořádaných do hierarchické stromové struktury SMI. Jednotlivé objekty jsou adresovatelné pomocí unikátního identifikátoru OID. MIB databáze jsou spravovány SNMP agenty. Pro přístup k objektům MIB databáze využívá manažer v předchozím textu popsané operace SNMP protokolu Vazby mezi objekty MIB Předtím, než budou popsány vazby mezi objekty databáze MIB, je třeba vysvětlit význam několika základních pojmů: Funkční blok - objekt databáze MIB (tvořící rámec), je složen ze strukturálního a parametrického elementu. 92

93 Strukturální element - konkrétní typ funkčního bloku (např. měřič provozu). Parametrický element - vlastnost funkčního bloku (např. konkrétní typ měřiče - Token Bucket). Cesta zpracování provozu - soubor funkčních bloků, které cestu zpracování konkrétního paketu. Jednotlivé záznamy v databázi MIB identifikované pomocí OID jsou koncipovány tak, že mohou představovat konkrétní hodnotu definovaného typu (např. string, integer, IP Addres, Gauge), nebo představují ukazatel na tabulku, či řádek tabulky. Tyto řádky jsou pak plněny hodnotami požadovaných typů. Pro odkazování na jednotlivé elementy systému byl proto definován speciální ukazatel (index). Tento ukazatel je koncipován tak, aby mohl odkazovat na položky v jednotlivých tabulkách. Podle struktury funkčního bloku může mít ukazatel dvě mírně odlišné funkce. V prvním případě ukazatel zajišťuje pospojování funkčních bloků do cesty zpracování provozu. V tomto případě tedy index funguje jako konektor mezi sousedními funkčními elementy. Druhý způsob využití je odkazování na sadu parametrů pro daný strukturální element. V takovém případě má ukazatel upřesňující funkci. Výhodou využití ukazatele je možnost dodatečného definování dalších funkčních bloků či jiných sad parametrů, které nejsou obsaženy v původní definici databáze MIB. Protože ukazatel může ukazovat i do jiné větve databáze MIB, je možné, aby byly v případě potřeby definovány vlastní bloky úpravy provozu a ty pak provázány s komponentami jiné databáze MIB. To ve svém důsledku znamená, že vazby uvnitř databáze MIB nemusí být vždy jednoduchými vazbami, ale mohou být vytvořeny vazby komplexnějšího charakteru, jak ukazuje obr. 4.3 [84]. Jelikož jsou hodnoty vazeb ve fyzických zařízeních tvořeny dynamicky, na základě v zařízeních nastavených parametrů, je práce s nimi (čtení, zápis) komplikovanější, neboť je potřeba přečíst všechny parametry, aby bylo možné získat a následně správně interpretovat kompletní informaci Databáze MIB-2 Každý agent může spravovat více MIB databází, avšak vždy spravuje MIB databázi definovanou v RFC 1213 a označovanou jako MIB-2 [72], která je implementována v každém současném síťovém zařízení s podporou protokolu SNMP. Tato databáze MIB obsahuje objekty udávající základní informace o daném prvku a o jeho rozhraních. Další databáze MIB, implementované v síťovém zařízení, mohou sloužit pro 93

94 Obr. 4.3: Vnitřní vazby databáze MIB popis dalších základních či jiných proprietárních vlastností, které jsou implementovaná konkrétním výrobcem. Umístění databáze MIB-2 ve stromové struktuře SMI a její hlavní větve jsou ukázány na obr OID základních větví umístěných pod uzlem MIB-2 je x, kde x je číslo od 1 do 11 v závislosti na konkrétní větvi. Databáze MIB-2 je důležitá i z pohledu navrženého QoS systému. Zásadní je zejména větev interfaces(2), která poskytuje informace o hardwarových rozhraních spravovaného zařízení. Parametry jednotlivých síťových rozhraní jsou uložené v tabulce iftable. Tato tabulka je tvořena 22 sloupci, které poskytují specifické parametry rozhraní jako je rychlost rozhraní, fyzická adresa, stav rozhraní nebo statistiku přenesených paketů. Počet řádků tabulky iftable pak odpovídá počtu rozhraní konkrétního síťového prvku [72], [73]. Kořen internet(1) mgmt(2) snmpv2(6) mib-2(1) system(1) interfaces(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) oim(9) transmission (10) snmp(11) Obr. 4.4: Stromová struktura databáze MIB-2 94

95 4.4.3 Databáze DiffServ-MIB Příkladem MIB databáze, které je připojena pod uzel MIB-2 a definuje konkrétní síťový mechanizmus je také databáze DiffServ-MIB. Tato MIB musí být implementována na všech zařízeních, které podporují technologii DiffServ. Je identifikován pomocí OID = Struktura databáze DiffServ-MIB odpovídá modelu řízení DiffServ mechanizmu navrženém v dokumentu RFC 3290 [21]. Jedná se o koncepční model popisující funkce jednotlivých bloků zpracování provozu v rámci mechanizmu DiffServ. Rozdíl mezi tímto modelem a databází DiffServ-MIB spočívá v tom, že koncepční model slouží pouze pro abstraktní popis požadovaného chování a u databáze DiffServ-MIB se předpokládá fyzická implementace v síťových prvcích podporujících mechanizmus DiffServ. Abstrakce použitá v modelu řízení mechanizmu DiffServ je pro fyzickou implementaci příliš složitá, proto databáze DiffServ-MIB, definovaná v RFC 3289 [19], popisuje pouze základní objekty jako třídič paketů, měřič provozu, fronty, plánovače odesílání paketů, zahazovače atd., které jsou nezbytné k ovládání příslušných funkčních bloků DiffServ mechanizmu. Tyto bloky pak tvoří hierarchický systém, kde jsou jednotlivé funkční bloky spojované do bloků úpravy provozu. Výhodou této struktury je možnost opakovaného využívání jednotlivých objektů, které je možné použít ve více funkčních blocích, např. definice klasifikačních pravidel pro jednotlivá síťová rozhraní směrovače. Seřazením jednotlivých funkčních bloků za sebe je definována cesta zpracování dat uvnitř konkrétního síťového rozhraní s podporou technologie DiffServ. Podrobný popis celé struktury databáze DiffSev MIB je nad rámec této práce, je možné jej však nalézt v [19] Databáze Cisco CBQoS (Class-Based QoS) MIB Kromě standardizovaných MIB databází jsou jednotlivými výrobci síťových zařízení vyvíjeny privátní MIB implementované v přepínačích, směrovačích, serverech a dalších komponentech od daného výrobce. Tyto privátní MIB jsou umístěny pod uzlem enterprise a mají OID = x, kde x je unikátní kód výrobce přidělený organizací IANA. V případě firmy Cisco Systems Inc., je její kód pro implementaci privátní MIB roven číslu 9 (OID = ). Vzhledem k tomu, že navržený QoS systém bude ve fázi testování komunikovat právě se síťovým zařízením firmy Cisco, bude následující text zaměřen na popis databáze Cisco CBQoS MIB, které obsahuje veškeré informace týkající se nastavení QoS pravidel na Cisco zařízeních [38]. Tato MIB má OID =

96 Cisco CBQoS MIB poskytuje přístup ke konfiguračním informacím a statistikám týkajícím se QoS mechanizmů implementovaných na zařízeních Cisco. V této MIB se tedy nachází také konfigurace jednotlivých komponent DiffServ technologie na Cisco prvcích. Databáze Cisco CBQoS MIB přistupuje k vnitřní definici komponent technologie DiffServ mírně odlišným způsobem v porovnání se standardní DiffServ- MIB, avšak základní myšlenka zůstává zachována. Opět je využíváno základních funkčních bloků, které svým spojením tvoří komplexnější bloky pro úpravu provozu. Databáze Cisco CBQoS MIB je složena z celkem 21 základních a 12 doplňkových větví [38]. Každá z těchto větví obsahuje skalární objekty nebo tabulky s konfiguračními nebo statistickými údaji. Pro správné pochopení struktury a provázání výše uvedených tabulek je třeba popsat vztah mezi základními QoS objekty, kterými jsou skladba tříd provozu (ClassMaps), přehled klasifikačních pravidel (Match Statements), podle kterých jsou pakety řazeny do tříd, a uživatelsky definované politiky provozu (PolicyMaps) přidružené k třídám provozu. V momentě, kdy je politika provozu přiřazena ke konkrétnímu síťovému rozhraní, stává se z ní servisní politika (Service Policy). Každá Service Policy je identifikována pomocí indexu označovaného jako cbqospolicyindex [38]. Způsob provázání objektů databáze Cisco CBQoS MIB je zobrazen na obr Síťová rozhraní Servisní politika (Service Policy) Politika provozu (Policy Maps) Třída provozu 1 (Class Map 1) Třída provozu 2 (Class Map 2).. Třída provozu N (Class Map N) Klasifikační pravidlo 1 (Match Statements 1) Klasifikační pravidlo 2 (Match Statements 2).. Klasifikační pravidlo N (Match Statements N) Obr. 4.5: Způsob provázání objektů databáze Cisco CBQoS MIB Každý QoS objekt definovaný v rámci Cisco CBQoS MIB má definovány dvě sady chování - konfigurační instance a funkční instance. Konfigurační instance udává sadu nastavení svázanou s konkrétním QoS objektem. Tyto konfigurační informace se při použití QoS objektu nemění. Každý QoS objekt se stejnou konfigurací je 96

97 označen stejným indexem cbqosconfigindex. Tento index je pak používán v rámci celé struktury MIB. Druhou instancí je funkční, která obsahuje statistické informace daného QoS objektu. Tyto informace se mění s každým použitím objektu. Každá funkční instance QoS objektu je označena pomocí indexu cbqosobjectsindex, který je unikátní pro každou instanci stejného objektu. Kromě těchto dvou indexů je třeba ještě definovat také tzv. rodičovský index cbqosparentobjectsindex, který udává hierarchický vztah každé QoS entity. Indexy cbqospolicyindex a cbqosobjectsindex jsou systémově přiřazená čísla, která identifikují každou samostatnou instanci QoS objektu. Index cbqospolicyindex je navržen pro identifikaci servisních politik přiřazených k logickým rozhraním, zatímco cbqosobjectsindex je navržen pro identifikaci každé QoS vlastnosti (entity) na konkrétním síťovém zařízení. Pomocí výše popsaných indexů je možné přistupovat k jednotlivým objektům databáze Cisco CBQoS MIB [38]. Základní tabulkou je cbqosservicepolicytable, kde je možné nalézt vazby mezi uživatelsky definovanými politikami provozu a síťovými rozhraními, na kterých jsou tyto politiky aplikovány. Každý záznam této tabulky je přístupný přes odpovídající index cbqospolicyindex. Základní dva objekty (listy) tabulky cbqosservice- PolicyTable jsou cbqosiftype, který definuje typ rozhraní, ke kterému je politika přidělena, a cbqospolicydirection, který udává směr provozu, v jakém je politika uplatňována. Druhou velmi důležitou tabulkou je cbqosobjectstable, kde jsou uloženy jednotlivé indexy konkrétních objektů. Princip indexování objektů databáze Cisco CBQoS MIB a provázání jednotlivých tabulek je zobrazen v přloze A na obr. A.1. V předchozím textu byla představena základní podoba struktury databáze Cisco CBQoS MIB a způsob procházení a vyhledávání konkrétních konfiguračních nastavení (objektů) v této databázi. Popis celé databáze je však nad rámec této práce Algoritmus pro vyčítání konfiguračních informací z databáze MIB Jednou z klíčových fází navrženého systému pro rozšíření technologie DiffServ je získávání konfiguračních informací z hraničního směrovače. Jak již bylo uvedeno dříve, pro tento účel byl zvolen protokol SNMP. Standardní uspořádání systémů vzdálené správy pomocí SNMP využívá centralizované řízení a monitorování síťových prvků. Použití protokolu SNMP v navrženém systému však bude mírně odlišné. Navržené řešení se opírá o modifikované logické uspořádání protokolu SNMP. V navrženém řešení se monitorovacím prvkem protokolu SNMP stane každá koncová stanice, která bude chtít využívat navrženého mechanizmu. Každá takováto koncová stanice bude využívat velice jednoduchého manažeru protokolu SNMP a pomocí něj 97

98 získávat potřebné informace. Modifikovaný způsob použití je znázorněn na obr. 4.6 [7]. Tento jednoduchý manažer bude implementovat jen velice malou část z komplexního protokolu SNMP. Z celkové analýzy vyplynulo, že tento jednoduchý manažer musí implementovat pouze funkce pro získání dat z databáze MIB. To znamená, že musí být schopen čtení parametrů z databáze MIB. Co se týká samotné interpretace přečtených dat, analýza ukázala, že postačující podmínkou bude podpora pouze několika málo větví databází MIB. Navíc podpora těchto několika málo větví nemusí být v jednoduchém manažeru úplná, protože stanici bude postačovat získání pouze několika vybraných údajů z větví databáze MIB [78]. Konkrétně by se mělo jednat zejména o větev interfaces (OID ), zkráceně označované jako IF-MIB, která je součástí již zmíněné databáze MIB-2 definované v RFC Tato větev obsahuje základní informace o jednotlivých rozhraních. Další větví je zmiňovaná DIFFSERV-MIB (OID ) definovaná ve standardu RFC Tato větev obsahuje informace o konfiguraci technologie DiffServ. Poslední databází MIB je již také zmiňovaná Cisco CBQoS MIB (OID ) definovaná firmou Cisco. Tato větev obsahuje informace o konfiguraci technologie DiffServ na síťových prvcích firmy Cisco. Takto navržené řešení umožní dynamické zjišťování parametrů technologie Diff- Serv, které bude probíhat mezi koncovou stanicí a okrajovým směrovačem, viz obr Praktické zkušenosti ukazují, že v sítích s implementovanou technologií DiffServ nedochází k častým změnám v konfiguraci této technologie a ani k častým změnám v konfiguraci jednotlivých síťových rozhraní. Z toho plyne, že implementovaný jednoduchý manažer nebude muset získávat potřebné informace z databází MIB často, což ústí v minimální komunikaci mezi manažerem a stanicí a tím pádem i minimálnímu zvýšení provozu v síti, což je jeden z požadavků návrhu. V rámci navrženého řešení byl vyvinut univerzální postup, který umožňuje dynamické zjišťování parametrů technologie DiffServ. Z důvodu potřeby dodržet dříve stanovené obecné požadavky a z důvodu limitace omezujícími faktory, vyžaduje vyvinutý postup dodržení následujících předpokladů: koncová stanice dokáže zjistit IP adresu výchozí brány, výchozí brána je prvním aktivním prvkem DiffServ domény, výchozí brána funguje současně jako okrajový směrovač DiffServ domény, okrajový směrovač DiffServ domény implementuje požadované databáze MIB, koncové stanice mají oprávnění pro čtení z požadovaných MIB databází, síťové rozhraní koncové stanice je připojeno k jedné DiffServ doméně, 98

99 vstupní rozhraní okrajového směrovače je nastaveno tak, že důvěřuje příchozím DSCP značkám, které přicházejí z vnějšku DiffServ domény, vstupní rozhraní okrajového směrovače provádí pouze klasifikaci provozu, item výstupní rozhraní okrajového směrovače provádí úpravu provozu, uvnitř celé DiffServ domény jsou definovány jednotné politiky úpravy provozu, které mají jednotné nastavení jak na okrajových směrovačích, tak na páteřních směrovačích, garance kvality služeb je zajišťována v páteřní části sítě (uvnitř DiffServ domény), v rámci přístupové části sítě se předpokládá dostatečná propustnost bez garance kvality služeb. Pojmy přístupová a páteřní síť jsou vysvětleny na obr Přístupová síť Páteřní síť (DiffServ doména) Koncová stanice Koncová stanice Detekce DiffServ parametrů pomocí protokolu SNMP Hraniční směrovač Páteřní směrovač DiffServ doména Koncová stanice MIB Páteřní směrovač SNMP manažer GetRequest, GetNextRequest GetResponse SNMP agent Obr. 4.6: Způsob využití protokolu SNMP pro vyčítání potřebných informací z databáze MIB Jednotlivé dílčí kroky univerzálního postupu lze rozdělit do dvou velkých skupin. První skupina kroků, viz obr. 4.7, je činěna proto, aby byly zjištěny potřebné informace o konfiguraci síťového rozhraní koncové stanice a konfiguraci všech síťových rozhraní hraničního směrovače DiffServ domény. Jak je vidět z obr. 4.7, koncová stanice musí nejdříve zjistit IP adresu své výchozí brány. Jelikož základním požadavkem je splnění uvedených předpokladů, tato adresa zároveň určuje první aktivní prvek DiffServ domény. Jedná se tedy o IP adresu 99

100 Koncová stanice: zjištění IP adresy výchozí brány Hraniční směrovač: zjištění identifikátorů všech rozhraní Hraniční směrovač: zjištění IP adres příslušejících jednotlivým rozhraním Hraniční směrovač: identifikace fyzických rozhraní a jejich stavů Hraniční směrovač: zjištění přenosové rychlosti fyzických rozhraní Obr. 4.7: Cyklus pro vyčítání informací o konfiguraci síťových rozhraní koncové stanice a hraničního směrovače vstupního rozhraní hraničního směrovače. Na základě znalosti IP adresy hraničního směrovače lze pomocí SNMP dotazů zaslaných do příslušné MIB větve ifnumber získat identifikátory všech rozhraní na hraničním směrovači. Dalším krokem je zjištění IP adres jednotlivých rozhraní. Toho je dosaženo pomocí SNMP dotazů zaslaných do příslušné větve ipadentifindex. Takto získané IP adresy je potřeba svázat s proměnnými jednotlivých rozhraní. Další krok slouží ke zjištění fyzického stavu rozhraní. Jedná se o větev ifoperstatus, která říká, zda je zkoumané rozhraní v činnosti nebo je vypnuté. Pro pozdější správné vyhodnocení nastavených parametrů technologie DiffServ je třeba znát přenosovou rychlost jednotlivých rozhraní. Tato informace je uložena ve větvi ifspeed. V rámci druhé skupiny kroků, viz 4.8, jsou na hraničním směrovači zjišťovány potřebné parametry konfigurace technologie DiffServ. Jelikož se přesný postup u jednotlivých implementací (v závislosti na typu implementované MIB) mírně liší, je na obr. 4.8 uveden pouze obecný náčrt používaného postupu. Prvním krokem je nalezení hodnot identifikátorů politik úprav provozu. Jak bylo uvedeno výše, každá použitá politika úprav provozu je přiřazena k rozhraní a je jí určen směr aplikace. Proto následuje krok, kdy je v databázi MIB hledána hodnota, která určuje propojení zjiš- 100

101 těného identifikátoru politiky úprav provozu a identifikátoru rozhraní okrajového směrovače. Následně je hledáno propojení, které určuje, v jakém směru (sestupný či vzestupný) je politika úprav provozu aplikována na daný port okrajového směrovače. Zjištění hodnot identifikátorů politik úpravy provozu a příslušnost těchto politik k jednotlivým rozhraním Zjištění směru aplikace politiky úpravy provozu na jednotlivých rozhraních prozkoumej další třídu, dokud nebude konec prozkoumej další třídu, dokud nebude konec Zjištění hodnoty propustnosti pro nalezenou třídu provozu a určení rozměru jednotek, ve kterých je tato hodnota uváděna Zjištění typů aplikovaných front u nalezené třídy provozu Zjištění k jaké politice úpravy provozu přísluší nalezená třída provozu Zjištění hodnoty značky DSCP pro nalezenou třídu provozu Obr. 4.8: Cyklus pro vyčítání informací o konfiguraci mechanizmu DiffServ Kroky, které jsou vyjmenovány v tomto odstavci, se cyklicky opakují, dokud nejsou nalezeny a pomocí identifikátorů popsány všechny třídy provozu. Počátečním krokem je zjištění propustnosti, které je rezervováno pro danou třídu. Následuje určení jednotky, ve které je hodnota uvedena (např. b/s nebo procentuálně). V závislosti na implementaci jednotlivých výrobců a konfiguraci dané třídy, je někdy možné z databáze MIB vyčíst, zda jsou na danou třídu aplikovány nějaké mechanizmy správy a plánování front. Následuje zjištění, k jaké politice úpravy provozu zkoumaná třída přísluší. Tato příslušnost rovněž implikuje, v jakém směru a na jakém portu je třída provozu provozována. Posledním krokem je zjištění hodnoty značky DSCP, která je danou třídou používána. Po prozkoumání všech potřebných informací příslušejících dané třídě se přechází ke zjišťování hodnot u další třídy (pokud má hraniční směrovač nějakou další třídu nakonfigurovánu). Jádro univerzálního postupu zjišťování dynamických parametrů technologie DiffServ tedy tvoří algoritmus, pomocí kterého koncová stanice zjišťuje informace za 101

102 pomoci využití protokolu SNMP. Díky pevně dané základní stromové hierarchii jednotlivých databází MIB a s pomocí definovaných hierarchických vztahů mezi jednotlivými větvemi a položkami stromu, je algoritmus schopen ve stromové hierarchii dohledat dynamicky vytvářené položky. K tomuto hledání využívá algoritmus opakovaného pokládání dotazů v dané větvi, dokud nejsou vyčteny všechny položky této větve. S výhodou je pro tuto činnost využito SNMP žádosti typu GetNext. Tento typ žádosti umožňuje procházení a získávání informací ze stromové hierarchie od zadaného OID, bez znalosti přesných hodnot OID, postupným procházením celým hierarchickým stromem. V použitém algoritmu je stromová struktura procházena tak dlouho, dokud žádost typu GetNext nevrátí hodnotu OID, která již přísluší další větvi. Na základě všech takto získaných informací může koncová stanice sestavit a interpretovat nastavení, které je provedeno na hraničním směrovači a příslušně s touto informací naložit. 4.5 Funkční bloky navrženého QoS systému Na základě dříve stanovených předpokladů a analýzy základních požadavků byl vytvořen koncepční model QoS systému rozšiřujícího mechanizmus diferencovaných služeb o možnost interakce mezi koncovou stanicí a hraničním směrovačem Diff- Serv domény [6]. Cílem této interakce je získání konfiguračních parametrů DiffServ technologie z hraničního prvku a následně na základě analýzy získaných informací provést na straně koncové stanice přidělení DSCP značky aplikačním paketům. Vytvořený model, viz obr. 4.9, je rozdělen do několika funkčních bloků, které budou v následujícím textu podrobněji popsány Detekce konfiguračních parametrů technologie DiffServ Z uvedeného obr. 4.9 je vidět, že v předchozí kapitole popsaný algoritmus pro vyčítání konfiguračních parametrů z MIB databáze hraničního směrovače DiffServ domény je pouze první fází navrženého systému. Nicméně, tato fáze je velmi důležitá, neboť se od ní odvíjí procesy dalších funkčních bloků modelu. Obecný algoritmus detekce konfiguračních nastavení včetně používaných nástrojů byl popsán v předchozích kapitolách. I přesto, že jedním z požadavků na navržený systém byla nezávislost na fyzické implementaci jednotlivých síťových zařízení, je nutné v tomto místě uvedený požadavek mírně upravit. Je to z důvodu odlišných typů databází MIB implementovaných v síťových prvcích. Dříve popsaný detekční algoritmus proto popisuje spíše obecný způsob získávání požadovaných informací z databáze MIB. První část algoritmu týkající se zjišťování parametrů síťových rozhraní bude vždy stejná pro všechny zařízení, neboť se jedná o práci s objekty 102

103 Koncová stanice Síťová aplikace Generování dat 3. fáze: výběr vhodné třídy provozu DSCP značka zvolené třídy provozu DSCP Filtrovaný seznam dostupných tříd a jejich parametrů provozu Operační systém (API) 4. fáze: přidělování DSCP značky DSCP. Značkování paketů zvolenou DSCP značkou Seznam dostupných tříd a jejich parametrů provozu 2. fáze: filtrování získaných informací Koncová stanice (SNMP manažer) 5. fáze: přenos označených paketů 1. fáze: detekce konfiguračních parametrů technologie DiffServ Hraniční směrovač (SNMP agent) MIB Hraniční směrovač MIB (MIB-2, DiffServ-MIB, Cisco CBQoS MIB, ) Obr. 4.9: Funkční model navrženého QoS systému databáze MIB-2, která musí být implementována na všech zařízeních. Druhá část, která slouží k získávání konfiguračních atributů mechanizmu DiffServ, se již bude mírně lišit v závislosti na struktuře použité MIB, v které jsou tyto informace ulo- 103

104 ženy. V předchozím textu byly uvedeny dvě z nejčastěji používaných MIB databází - obecná standardizovaná DiffServ-MIB a Cisco CBQoS MIB vytvořená firmou Cisco Systems Inc. Jedna z těchto databází MIB je ve většině případů implementována v současných směrovačích používaných v páteřních sítích pro podporu mechanizmu DiffServ. V případě, že bude použit směrovač od jiného výrobce s jiným typem implementované databáze MIB, pak bude nutné navržený algoritmus upravit, což však vzhledem k jeho modularitě by neměl být zásadní problém. Před spuštěním samotného procesu detekce konfiguračních parametrů tedy musí koncová stanice zjistit typ implementované MIB. To lze provést jednoduchým dotazem do dané větve MIB. Pokud SNMP agent vrátí smysluplnou odpověď, pak lze předpokládat, že je daná MIB skutečně implementována v síťovém zařízení. Poté je tedy zahájen vlastní proces dotazování. Výsledkem tohoto procesu je seznam dostupných tříd provozu a souvisejících QoS parametrů. Mechanizmus detekce parametrů DiffServ může být na koncové stanici obsažen přímo v uživatelské aplikaci. Tento způsob však není příliš vhodný zejména proto, že by musely být upraveny zdrojové kódy samotné aplikace, což ve většině případů není možné a vyžaduje to také určitou úroveň znalostí uživatele. Proto z pohledu možnosti většího rozšíření navrhovaného systému je efektivnější, aby funkci detekce nastavení hraničního směrovače prováděla samostatná služby běžící v OS (Operační systém) koncové stanice. Tak mohou být získané informace poskytnuty více síťovým aplikacím Zpracování dostupných tříd provozu a souvisejících parametrů Tento funkční blok je přímo závislý na výstupu předchozího bloku. Pokud je totiž fáze detekce QoS parametrů neúspěšná, pak jsou další fáze zbytečné, neboť jim chybějí požadovaná vstupní data. Pokud je však proces detekce úspěšný, pak druhý funkční blok provede analýzu získaných informací a zpracuje je do přehledné formy. Síťová aplikace se pak v další fázi na základě těchto dat rozhodne, kterou z podporovaných tříd provozu využije pro svoje data. Proces výběru optimální třídy provozu je postaven na několika základních parametrech. Klasifikační profil - tento parametr popisuje způsob klasifikace paketů do jednotlivých tříd provozu. V rámci technologie DiffSev jsou definovány dva základní typy třídičů - BA (Behavior Aggregate), který předpokládá, že paket již byl označen DSCP značkou a třídí jej na základě této hodnoty, a MF (Multifield), který třídí pakety na základě jednoho nebo více kritérií (např. IP 104

105 adresa, číslo TCP/UDP portu nebo typ aplikačního protokolu). Garantovaná minimální přenosová rychlost CIR - jedná se o minimální přenosovou rychlost definovanou pro konkrétní třídu provozu. Jedná se o jednu z nejdůležitějších charakteristik jednotlivých tříd provozu. Tento parametr je nejčastěji spojen s výstupním portem síťového zařízení. Je tedy nutné správně identifikovat vstupní a výstupní rozhraní hraničního směrovače. Proto je tedy třeba kromě analýzy DiffServ parametrů provést také vyčtení informací ze směrovací tabulky. MIB databáze obsahuje kromě konfiguračních parametrů také statistické informace, tak je možné vyčíst aktuální přenosovou rychlost. Na základě této hodnoty je pak možné vypočítat poměr aktuální přenosové rychlosti ke garantované přenosové rychlosti. Síťová aplikace tak bude moci volit vhodnou třídu provozu i na základě jejího obsazení datovými toky generovanými jinými aplikacemi nebo koncovými stanicemi. Maximální povolená přenosová rychlost PIR - maximální přenosová rychlost povolená pro danou třídu. Pokud datový tok překročí tuto hodnotu, pak je zpracován způsobem definovaným v politice provozu. Minimální garantovaná i maximální povolená rychlost mohou být někdy uváděny jako procentuální hodnoty. Je tedy nutné nejprve zjistit celkovou přenosovou rychlost síťového rozhraní a poté vypočítat absolutní hodnotu povolených rychlostí pro jednotlivé třídy. Politika provozu pro pakety překračující povolenou rychlost - tento parametr popisuje akci, která je provedena s pakety překračujícími maximální povolenou rychlost. Nejčastějším způsobem zpracování je přeznačení paketu na hodnotu značky pro třídu s nižší prioritou, anebo přímé zahození paketu. Typ mechanizmu plánovaného odesílání paketů - tento parametr udává jaký mechanizmus je v rámci dané třídy použit pro řazení/odesílání paketů do/z front. Jedná se důležitý parametr, který má zásadní vliv na výslednou úroveň zajištění QoS. Tento parametr je svázán s výstupním rozhraním směrovače. Hodnota DCSP - hodnota DSCP značky udává úroveň priority zacházení poskytnutou paketů zařazeným do dané třídy provozu. Každé DCP značce odpovídá určitý způsob zacházení PHB, který je paketům poskytován během jejich přenosu přes DiffServ doménu. Zpracování výše uvedených parametrů je prováděno na úrovni operačního systému koncové stanice. Některé zjištěné parametry a zejména pak klasifikační profily mohou být závislé na konkrétní IP adrese. Jelikož OS zná svoji vlastní IP adresu, tak 105

106 může provést filtraci zjištěných parametrů a síťové aplikaci pak poskytnout filtrovaný seznam dostupných tříd a parametrů provozu týkajících se pouze dané koncové stanice. Další filtraci může provést OS v případě, že mu aplikace formou žádosti o vytvoření socketu poskytne parametry svého provozu (protokol, číslo cílového portu, cílová IP adresa atd.) Proces výběru vhodné třídy provozu V momentě, kdy jsou získány požadované konfigurační informace z MIB databáze hraničního směrovače a OS je zpracuje do podoby filtrovaného seznamu dostupných tříd a jejich parametrů, se spouští proces výběru vhodné třídy provozu. Tento proces probíhá mezi síťovou aplikací a API (Application Programming Interface) operačního systému, které spravuje seznam detekovaných QoS tříd a pravidel. Zpřístupnění seznamu tříd jednotlivým síťovým aplikacím bude zajištěno stejným API, které daný seznam spravuje. Celý proces bude tedy probíhat automatizovaně. Aplikace bude moci kdykoli poslat dotaz na dostupné třídy provozu a OS prostřednictvím vytvořeného API mu vrátí příslušný seznam. Tento způsob výběru vhodné třídy provozu vyžaduje určitou pokročilost síťové aplikace. Aplikace musí mít totiž implementovány mechanizmy umožňující nastavení DSCP značky. V dnešní době existuje již velké množství takovýchto aplikací. Pokud by se však jednalo o starší typ síťové aplikace, která nedisponuje mechanizmy pro definování úrovně QoS, pak navržený systém poskytuje možnost ručního výběru vhodné třídy provozu. Tento manuální způsob provádí sám uživatel pomocí jednoduchého řídícího programu, který zasílá obecné dotazy. Odpovědí na tento dotaz je seznam všech dostupných tříd a síťových parametrů na daném hraničním směrovači DiffServ domény. Při obou dvou způsobech výběru vhodné třídy provozu je vždy výsledkem DSCP značka zvolené třídy Způsob nastavení zvolené DSCP značky Po fázi výběru vhodné třídy provozu je provedeno nastavení odpovídající DSCP značky v DS poli IP hlavičky paketů generovaných síťovou aplikací. Podobně jako u předchozí fáze, i zde jsou možné dva způsoby v závislosti na typu aplikace. Základní metoda je určená pro sofistikovanější síťové aplikace a pro nastavování DSCP značky je v takovém případě používáno API implementované v operačním systému [90]. V případě OS typu Windows to může být WinSock (Windows Sockets) API a konkrétně pak jeho části TCtrl (Traffic Control) API a GQoS (Generic QoS) API používané v OS Windows XP a Windows Server 2003, nebo QoS2 API nahrazující 106

107 TCtrl a GQoS API pro systémy Windows Vista, Windows Server 2008 a novější. QoS2 API, někdy označované jako qwave (Quality Windows Audio-Video Experience), zdokonaluje a zároveň zjednodušuje programátorům práci při vývoji QoS komponent v nových verzích operačního systému Windows. [40]. TCtrl, GQoS případně QoS2 API jsou standardní rozhraní definované v OS Windows, která umožňují přidávat nové QoS komponenty bez nutnosti úpravy existujících síťových aplikací [5]. Voláním standardních funkcí těchto rozhraní mohou aplikace definovat vlastní politiky provozu pro jednotlivé QoS mechanizmy bez nutnosti znalosti jejich kompletní struktury [40], [56]. Je tak tedy možné poměrně jednoduchým způsobem provádět nastavení hodnoty DSCP pro pakety odpovídající danému datovému toku. Podobný mechanizmus nastavení DSCP značky je možné použít i v OS unixového typu, neboť princip tvorby socketů pochází právě odsud. Z důvodu zpětné podpory pro starší síťové aplikace je v navrženém systému definován i druhý způsob nastavování DSCP značky. V případě, že aplikace neumí pracovat s QoS API a funkcemi integrovanými přímo v operačním systému, je nutné pakety značkovat dodatečně pomocí speciálního filtru. Tento filtr bude zachytávat pakety generované síťovou aplikací, vkládat do DS pole v IP hlavičce značku DSCP a poté pakety předávat ke zpracování (odeslání) síťovému rozhraní. Pro vytvoření takového specializovaného filtru je možné v OS Windows použít speciální ovladač NDIS (Network Driver Interface Specificationt). Pomocí knihoven a funkcí tohoto ovladače je možné zachytávat datové jednotky podle předem definovaných pravidel a vkládat do jejich hlaviček DSCP nebo 802.1Q/p značek [5]. NDIS vytváří standardní rozhraní mezi ovladači jednotlivých síťových vrstev, čímž odděluje ovladače nižších vrstev, které zajišťují správu hardwaru, od ovladačů vrstev vyšších Přenos paketů označených DSCP značkou Poslední fází navrženého systému je samotný přenos paketů označených DSCP značkou odpovídající vybrané třídě provozu. Navržený systém je síťovým aplikacím nabízen pouze jako možnost, kterou mohou využít při odesílání svých dat. Pokud však aplikace z nějakého důvodu nechce vytvořený systém značkování použít, pak jí musí být umožněno svoje pakety odeslat standardním způsobem, tedy s DSCP hodnotou (Best-effort). Předpokladem pro efektivní používání popsaného systému je nastavení hraničního směrovače DiffServ domény tak, aby důvěřoval DSCP hodnotě již označených paketů. Pokud by totiž směrovač nedůvěřoval nastavené značce, pak by vždy přeznačil paket na jinou DSCP značku. Aby však bylo zabráněno tzv. slepé důvěře, kdy by mohla nastat situace, že předznačené pakety, jejímž značkám bude směrovač 107

108 důvěřovat, budou nějakým způsobem vybočovat z definovaných parametrů provozu nebo budou způsobovat určité bezpečnostní riziko, je hraničnímu směrovači ponecháno právo posledního rozhodnutí. To znamená, že i když směrovač považuje síťovou aplikaci generující označené pakety za věrohodný zdroj a důvěřuje jejím DSCP značkám, má vždy právo paket přeznačit na jinou značku na základě svých měření parametrů provozu. 108

109 5 OVĚŘENÍ NAVRŽENÉHO QOS SYSTÉMU V LABORATORNÍCH PODMÍNKÁCH Ověřování navrženého systému, který rozšiřuje mechanizmus DiffServ o možnost ovlivnění procesu řízení QoS samotnou síťovou aplikací, bylo rozděleno na dvě části. Pro každou část byl v simulačním prostředí OPNET Modeler vytvořen samostatný scénář. Základem obou těchto scénářů jsou funkce a mechanizmy popsané v předchozích kapitolách v rámci návrhu nového QoS systému. Rozdělení ověřování navrženého systému na dvě části je výhodné zejména kvůli přehlednosti a snadnější analýze případných chyb či nedostatků během simulace. Cílem prvního simulačního scénáře bylo zejména ověření funkčnosti mechanizmů pro získávání potřebných konfiguračních parametrů DiffServ technologie z hraničního směrovače, což je zásadní funkce navrženého QoS systému. Druhý scénář pak slouží k ověření vlivu nastavení DSCP značky samotnou koncovou stanicí na výsledné parametry provozu. V následujícím textu budou popsány oba zmíněné simulační modely. 5.1 Ověření mechanizmu získávání konfiguračních parametrů z databáze MIB Architektura vytvořeného simulačního modelu, viz obr. 5.1, vychází z návrhu blokového modelu popsaného v předchozí kapitole. Jako základní nástroj pro vytvoření simulačního modelu bylo zvoleno simulační prostředí OPNET Modeler, které již bylo použito pro simulace technologií pro zajištění kvality služeb uvedených v kap. 3. Aby však analýza navrženého mechanizmu neprobíhala pouze v simulačním prostředí, byl do simulačního modelu začleněn reálný síťový prvek, který plnil roli hraničního směrovače DiffServ domény [6]. Jak je vidět z obr. 5.1, simulační model je tvořen dvěma fyzickými prvky: koncovou stanicí a síťovým zařízením. Jako reálný síťový prvek byl použit směrovač Cisco C1841. Jedná se síťové zařízení určené pro menší podnikové sítě. Směrovač využívá modulární architekturu, takže je možné jednoduše formou modulů přidávat nové funkce nebo zvyšovat výkon zařízení [37]. V rámci tohoto směrovače je implementována databáze CBQoS MIB, která je vyvinutá firmou Cisco Systems Inc. pro podporu mechanizmů podpory kvality služeb v jejích zařízeních. Vytvořený simulační model byl tedy uzpůsoben pro práci s tímto typem MIB databáze. Na směrovači byla provedena testovací konfigurace mechanizmu DiffServ, která zahrnovala vytvoření čtyř tříd provozu se specifickými parametry. Atributy tohoto nastavení pak byly 109

110 ESYS rozhraní Simulační model v prostředí OPNET Modeler Externí aplikace (API) Databáze MIB (Cisco CBQoS MIB) SNMP Síťové zařízení (směrovač Cisco C1841) Koncová stanice Obr. 5.1: Simulační model pro ověření mechanizmu získávání informací z databáze MIB a jejich následného zpracování použity jako cílová data při dotazování koncovou stanicí. Druhým fyzickým prvkem je koncová stanice, na které běží simulační prostředí OM. V simulačním prostředí byl vytvořen model pracovní stanice, který generuje SNMP dotazy, předává je externí aplikaci, která s využitím funkcí síťového API provede zapouzdření SNMP dotazu do UDP datagramu a předá jej síťovému rozhraní k odeslání. SNMP dotaz je poté odeslán ke směrovači, kde je zpracován a zpět je zaslána odpověď obsahující požadovanou hodnotu definovanou OID objektu MIB databáze. Na koncové stanici je SNMP odpověď zpracována externí aplikací (API) a předána do simulačního prostředí. Pro komunikaci mezi simulačním prostředím OM a externí aplikací je využito specializované rozhraní ESYS (External System), které je součástí nástroje OM [12] Implementace SNMP protokolu do simulačního prostředí OM Simulační scénář vytvořený v prostředí OPNET Modeler byl tvořen pouze jednou pracovní stanicí, která plnila roli SNMP manažera. Mnohem zásadnější než počet prvků scénáře však byly funkce a procesy definované uvnitř modelu této stanice. Jako základ byl použit standardní model ethernetové stanice, který byl rozšířen o nové procesní modely a funkce vyplývající z navrženého QoS systému. Prvním úkolem bylo implementování funkcí SNMP protokolu [77]. Většina aplikačních protokolů je v simulačním prostředí OM reprezentována pomocí parametrizovaného generátoru provozu, který vytváří matematicky popsaný průběh síťového provozu. To znamená, že komunikace na aplikační vrstvě je simulována použitím datových jednotek konkrétních aplikací [14]. I přes podporu velkého 110

111 množství aplikačních protokolů, v aktuální verzi nástroje OPNET Modeler v16.0a není protokol SNMP implementován. Tento nedostatek tedy bylo třeba vyřešit dodatečnou implementací základních funkcí systému SNMP. Jednou z funkcí prostředí OM je možnost úpravy zdrojových kódů standardních modelů, které jsou napsány v programovacím jazyce C/C++. Na obr. 5.2 je zobrazena vnitřní struktura upraveného modelu pracovní stanice v roli SNMP manažera. Standardní model byl rozšířen o dva procesní modely: snmp_manager a esys. Procesní model snmp_manager zajišťuje generování SNMP zpráv. Procesní model esys pak vzájemnou výměnu dat (SNMP zpráv) mezi simulačním prostředím a externí aplikací [76]. Následující text bude věnován popisu procesního modelu snmp_manager a v něm implementovaných mechanizmů. Obr. 5.2: Vnitřní struktura uzlu snmp_manager Procesní model snmp_manager Vnitřní struktura (stavový automat) procesního modelu snmp_manager, je zobrazena na obr Procesní modely jsou v simulačním prostředí OM modelovány pomocí stavových automatů. Každý procesní model je tedy tvořen několika stavy s 111

112 definovanými podmínkami přechodů mezi nimi. Stavy procesu se dělí na dvě kategorie: vynucené a nevynucené. Při přechodu procesu do vynuceného stavu (zelená barva) je vykonán kód, který tento stav obsahuje, a poté automaticky dojde k přechodu do následujícího stavu. Pokud proces přejde do nevynuceného stavu (červená barva), tak je opět vykonán kód, který tento stav obsahuje, ale proces v tomto stavu zůstává tak dlouho, dokud nedojde k vyvolání nové události. Každá událost je definována přerušením [101]. Přechody mezi stavy jsou také dvojího typu: podmíněný a nepodmíněný. Podmíněný stav je definován podmínkou (pravidly) přechodu. Je-li podmínka splněna, proces přejde do nového stavu. Podmínky přechodů jsou v procesním modelu značeny názvy funkcí zobrazenými u spojnic jednotlivých stavů. Naopak při nepodmíněném přechodu přechází proces do nového stavu okamžitě bez nutnosti splnění nějaké podmínky. Obr. 5.3: Vnitřní struktura procesního modelu snmp_manager Vytvořený procesní model je složen ze čtyř stavů (2 nevynucené a 2 vynucené). Význam jednotlivých stavů je následující. Stav init - jedná se o počáteční stav, do kterého proces vstoupí ihned po spuštění simulace. Jedná se o nevynucený stav, takže po vykonání zdrojového kódu čeká na signál přerušení. Tento stav slouží pro inicializaci proměnných modelu a sledovaných statistik. Dále je v něm také provedena kontrola parametrů spojení se sousedním procesním modelem, kterým je UDP modul (viz obr. 5.2). Po příchodu přerušení přejde proces do stavu idle. Stav idle - jedná se o výchozí stav tohoto procesního modelu. Proces v něm 112

113 čeká na příchod přerušení, které může být vyvoláno buď požadavkem na odeslání paketu anebo příchodem paketu. Stav SEND - stav SEND je určen pro vytvoření a odeslání SNMP zprávy. Jak již bylo uvedeno, SNMP protokol není v prostředí OPNET Modeler podporován, proto byla v tomto stavu vytvořena pomocí programovacího jazyka C obecná struktura SNMP zprávy. Vytvořená struktura odpovídá verzi protokolu SNMPv2. Při vzniku požadavku na odeslání SNMP zprávy je tato struktura naplněna uživatelskými daty. Každá SNMP zpráva je vytvářena dynamicky. Nejprve je definován typ SNMP operace (PDUtype). V současné době jsou podporovány operace typu Get a GetNext, které slouží pro vyčítání hodnot z databáze MIB. Po definici typu PDU je do zprávy doplněna hodnota OID požadovaného objektu. Aby mohla být naplněná SNMP zpráva odeslána v souladu se standardem RFC 1067 [27], je třeba ji zakódovat pomocí kódovacích pravidel BER. Výsledkem kódování pomocí BER je řetězec bajtů. V rámci stavu SEND byly tedy na základě doporučení X.690 [60] vytvořeny C funkce pro zakódování každé SNMP zprávy před jejím odesláním. Každé pole SNMP zprávy je zakódováno podle modelu TLV a jednotlivé zakódované sekvence jsou pak složeny do výsledného řetězce. Po vytvoření SNMP zprávy, jejím naplnění, zakódování a odeslání do UDP modulu, se proces vrátí do výchozího stavu idle. Stav RECEIVE - vynucený stav RECEIVE je určen pro zpracování SNMP zpráv přicházejících z procesního modelu UDP. Když je vyvoláno přerušení typu RECEIVE_PACKET, přejde proces ze stavu idle do stavu RECEIVE. Přicházející SNMP zpráva je zakódována pomocí pravidel BER, proto je nutné ji nejprve dekódovat. Pro dekódování byly opět vytvořeny C funkce, které mají inverzní význam k funkcím pro kódování pomocí BER. Po dekódování SNMP zprávy jsou získané hodnoty uloženy do vytvořené databáze, kde jsou dostupné pro další zpracování. Databáze pro ukládání přijatých informací je popsána v dalším textu. Po vykonání celého kódu obsaženého ve stavu RECEIVE se proces vrátí do stavu idle, kde čeká na příchod dalšího přerušení. Algoritmus vyčítání atributů databáze Cisco CBQoS MIB V předchozím textu byl popsán stav SEND, což je jeden ze stavů procesního modelu snmp_manager, který slouží pro vytváření a odesílání SNMP dotazů. V tomto stavu 113

114 však bylo nutné také definovat mechanizmus spravující samotný proces odesílání SNMP dotazů. Je totiž nutné určit konkrétní hodnotu OID požadovaných objektů v MIB databázi a také pořadí, v jakém budou tyto objekty vyčítány. V úvodu této kapitoly bylo řečeno, že simulační model byl napojen na směrovač od firmy Cisco s implementovanou databází CBQoS MIB, proto bude dále popsaný mechanizmus určen pro práci právě s tímto typem MIB. Implementovaný mechanizmus vyčítání MIB vychází z teoretického návrhu uvedeného v kapitole Základem vytvořeného mechanizmu jsou funkce obsažené v balíku NET-SNMP [79]. Nástroje obsažené v tomto balíku slouží pro implementaci protokolu SNMPv1, SNMPv2 a SNMPv3. Pomocí funkcí jednoho z nástrojů tohoto balíku, označovaného jako SNMPWALK, je možné vyčítat obsah MIB databáze prostřednictvím SNMP protokolu. Nástroj využívá zejména SNMP operace typu Get a GetNext. Výhodou celého balíku NET-SNMP je jeho otevřenost a dostupnost zdrojových kódu, díky čemuž bylo možné upravit vybrané funkce pro potřeby navrženého QoS systému a implementovat je do stavu SEND v procesním modelu SNMP manažera v simulačním prostředí OM. Popis implementovaného procesu vyčítání potřebných informací z databáze MIB je z důvodu jeho rozsáhlosti umístěn v příloze B. Uvedený popis může působit poměrně složitě, avšak je to dáno zejména relativně složitými vazbami mezi jednotlivými objekty MIB databáze. Počet kroků vytvořeného algoritmu je závislý na množství definovaných tříd provozu a také na množství parametrů, které jsou na hraničním směrovači nakonfigurovány. V případě potřeby je možné tento algoritmus rozšířit o nové kroky pro vyčítání dalších parametrů. Vždy je však důležité správně provést vyčtení jednotlivých indexů objektů (krok 18), jinak by mohlo dojít k chybnému seřazení a interpretaci vyčtených informací Způsob zpracování a ukládání přijatých informací z MIB V předchozím textu byl popsán algoritmus vyčítání požadovaných QoS parametrů z databáze Cisco CBQoS MIB. SNMP dotazy byly vytvářeny ve stavu SEND. Odpovědi na tyto dotazy jsou pak přijímány ve stavu RECEIVE, který je také součástí procesního modelu SNMP manažera v prostředí OPNET Modeler (viz obr. 5.3). Informace získané z každé SNMP odpovědi je nutné průběžně ukládat. Proto byla do stavu RECEIVE implementována datová struktura, která je zjednodušenou kopií MIB tabulky v hraničním směrovači. Vytvořená struktura je tvořena pomocí 4 základních funkcí: vyhledávání položky ve struktuře, přidání nové položky do struktury, 114

115 vymazání položky ze struktury, zrušení (dealokace) celé struktury. Celá struktura je pak popsána pomocí 2 proměnných: ukazatel na první prvek v tabulce a hodnota určující celkový počet prvků v tabulce. Každý prvek je ve vytvořené tabulce reprezentován pomocí 4 ukazatelů, díky kterým je provázán s ostatními prvky v tabulce. Dále každý prvek obsahuje celočíselnou hodnotu pro uložení OID a řetězec obsahující celé OID. Poslední proměnná ve struktuře prvku je struktura pro uložení vlastní hodnoty prvku. Tato struktura obsahuje proměnné pro všechny možné datové typy, které se mohou nacházet v databázi MIB. Identifikace objektů pomocí OID je implementována pomocí proměnných typu integer, obsažených ve strukturách jednotlivých prvků. V této proměnné není udržováno celé OID prvku, ale pouze jeho poslední část, která náleží danému prvku (tj. pouze jedno číslo). Tento způsob byl zvolen kvůli jednoduššímu a rychlejšímu prohledávání hierarchicky uspořádané tabulky. Koncové prvky pak mají navíc i řetězec obsahující jejich celé OID. Provázání objektů ve vytvořené MIB tabulce je provedeno pomocí vícerozměrného oboustranně vázaného lineárního seznamu. Každý prvek může obsahovat odkaz na souseda po své levici a pravici (odkazy v rámci jedné úrovně) a také na svého rodiče, případně potomka (odkazy mezi úrovněmi). Důvodem použití oboustranné vázanosti je problém dealokace, která musí být provedena od konce tabulky směrem na začátek (reverzní dealokace) Propojení simulačního prostředí s externím systémem V kapitole byl popsán procesní model SNMP manažera včetně algoritmů a funkcí, které do něj byly implementovány. Standardní model pracovní stanice v simulačním prostředí OPNET Modeler byl však rozšířen ještě o jeden procesní model s názvem ESYS (viz obr. 5.2). Tento procesní model slouží k propojení a vzájemné výměně dat mezi simulačním prostředím OM a externím systémem (aplikací) [13]. Funkce propojení simulačního nástroje OM s externí aplikací umožňuje začlenit do simulačního procesu reálné systémy nebo zařízení. Toto propojení je označováno jako kosimulace. Za účelem předávání řízení a také vlastních dat mezi OM a externím systémem, je v OM definováno rozhraní ESYS (External System). Rozhraní ESYS je součástí komplexního systému ESD (External System Definition) [12]. Pomocí ESD systému je externí systém definován jako model, jehož chování je závislé na externím kódu. Tímto externím systémem pak může být cokoli od mikročipu po uživatelskou aplikaci. OPNET Modeler předává data do nebo z externího systému pomocí rozhraní ESYS, aniž by se staral o vnitřní strukturu externího 115

116 systému. Tato vlastnost otevírá zcela nové možnosti využití simulačního prostředí. Zásadní výhoda je ta, že není třeba složitě uvnitř simulačního prostředí vytvářet nový model existujícího systému, který je třeba zahrnout do simulace. Existující systém je pouze potřeba zmodifikovat tak, aby implementoval pomocí knihovních funkcí rozhraní ESYS a pomocí těchto funkcí skrze rozhraní ESYS následně předával data do simulačního prostředí. Celá tato konstrukce pak funguje na principu předávání řízení mezi OPNET Modelerem a externím systémem [101]. Na obr. 5.4 je uveden základní princip kosimulace v prostředí OM. Kosimulace je dostupná pouze ve verzi jádra OPNET Modeleru se sekvenčním zpracováním, kdy hlavní vlákno zpracování může volat OPNET APIs. Mezi nevýhody kosimulace patří nutnost doprogramování funkcí pro implementaci ESYS rozhraní, jak na straně OPNET Modeleru, tak na straně externího systému. Dále pak u složitějších simulací vyšší paměťové nároky. Základní prvky kosimulace Kosimulace využívá následujících komponent [101]: deskriptor simulace, modul systému ESD, rozhraní ESYS, kosimulační kód - funkce ESA (External Simulation Access) API, kód externího systému (aplikace). Rozhraní ESYS OPNET Modeler simulační prostředí OPNET Modeler knihovny Simulační jádro Eterní aplikace (kód) Obr. 5.4: Základní princip kosimulace v prostředí OPNET Modeler Deskriptor simulace Deskriptor simulace je textový soubor s příponou *.sd, který definuje seznam objektových souborů, knihoven a dalších atributů, které budou použity v OM při 116

117 procesu kosimulace. Pomocí tohoto deskriptoru je OM schopen najít soubory externího systému. V tomto souboru jsou také uvedeny další informace, jako kompilační volby, jména objektových souborů apod. Mezi volby patří např. typ platformy (Windows, Solaris atd.), typ simulačního jádra (development, optimized), nebo informace o tom, která strana v rámci kosimulačního procesu vyvolá hlavní funkci Esa_main(). Deskriptor se skládá z jednoho nebo více bloků uzavřených mezi identifikátory start_definition a end_definition. Modul systému ESD Pomocí ESD modulu jsou definovány vlastnosti a počet jednotlivých rozhraní, skrz které komunikuje externí systém a kosimulační kód implementovaný v OPNET Modeleru. Pro snadné vytvoření ESD rozhraní existuje v OM ESD editor, který poskytuje prostředí pro vytvoření a editaci ESD rozhraní. ESD specifikuje jméno rozhraní, které se stává součástí hierarchického jména a je uživatelsky definovatelné [1]. Dále pak datový typ hodnoty, která bude přes rozhraní předávána. Jedno rozhraní dokáže předávat pouze jeden zvolený datový typ. Většina datových typů, které poskytuje OM, vychází z datových typů jazyka C/C++. Dále je v ESD editoru určen způsob, jakým budou data na rozhraní mezi OM a externím systémem předávána. Je možné zvolit mezi těmito 3 směry: z OM směrem do externího systému, z externího systému do OM, obousměrně. Hodnota dat předaných na rozhraní je platná, dokud nejsou stará data přepsána daty novými. Položka rozměr (dimension) v ESD modulu definuje, zda je na rozhraní předávána jen jedna hodnota anebo pole hodnot. Jakékoli jiné číslo než 0 u rozměru rozhraní říká, že se jedná o vektor dané délky. ESYS rozhraní Jak již bylo zmíněno výše, ESYS je komponenta simulačního prostředí OM, která reprezentuje rozhraní s externím systémem. Díky tomu, že je ESYS procesní modul, lze toto rozhraní začlenit do struktury modelu konkrétního síťového prvku mezi ostatní procesy přesně tam, kde je to z pohledu funkčnosti modelu potřebné. K procesnímu modulu je v podobě atributu přiřazen ESD modul, který definuje komunikační rozhraní s externím systémem. Výhodou tohoto přístupu je, že ESYS nemusí mapovat externí systém na konkrétní element modelovaného systému. Uvnitř procesního modulu ESYS je vytvořen procesní algoritmus, který má na starost vlastní interakci s 117

118 externím systémem. Struktura a uspořádání procesního algoritmu (vnitřní logika) říká, jakým způsobem si OM s externím systémem předávají informace. Procesní model využívá různé procedury jádra OM, které umožňují předávaní a konverzi dat mezi OM a externím systémem [13]. Potřeba konverze dat závisí na okolnostech komunikace mezi OM a externím systémem. Častým příkladem je potřeba transformace objektu OM (jako jsou pakety) do formy dat, které je externí systému schopen zpracovat. Toto platí také v opačném směru. Existují obecné mechanizmy, které tuto konverzi na ESYS rozhraní zjednodušují (např. lze použít vektorů, které jsou v podstatě reprezentací pole s proměnným počtem prvků) [101]. Kosimulační kód - funkce ESA API Kosimulační kód váže jádro OM a kód externího systému dohromady. Za tímto účelem obsahuje OM procedury jádra, které umožňují zapisovat a číst data na ESYS rozhraní. Tyto procedury umožňují předat buď jednu hodnotu, nebo pole hodnot. Procedury jádra OM jsou podrobně popsány v dokumentaci OM [101]. Pro podporu ESYS rozhraní na straně externího systému existuje sada funkcí ESA API. Tyto funkce, vytvořené v jazyce C, jsou definovány v hlavičkovém souboru esa.h. Tento hlavičkový soubor je dodáván jako standardní systémová knihovna prostředí OM. Funkce ESA API se starají o inicializaci a načtení simulace, řídí tok dat mezi externím systémem a OM a zajišťují výměnu dat pomocí ESYS rozhraní. Operace prováděné při inicializaci kosimulace lze popsat takto. Po spuštění simulace se inicializují základní služby jádra OM. Následně je inicializován simulační subsystém OM. Během této operace jsou načteny předvolby zpracování a jsou specifikovány nastavení prostředí (např. zaznamenávání událostí pro statistiky, zda je použit optimalizovaný nebo debuger mód atd.). Poté je načtena síť a s ní asociované modely. Na straně kosimulace je nastaven simulační čas na hodnotu 0. Výměna dat přes rozhraní ESYS Zápis dat na rozhraní ESYS ve směru z OM do externího systému je realizován pomocí procedur jádra simulačního prostředí OM. Po zápisu dat na ESYS rozhraní z OM je v externím systému vyvolána callback funkce (viz obr. 5.5). Callback funkce je funkce, která má na starost zpracování dat z OM. Proto musí být v externím systému vhodně implementována. To, která funkce z kódu externího systému bude callback funkcí, je určeno pomocí Esa_Interface_Callback_Register() funkce z ESA API. V případě zápisu dat ve směru z externího systému do OM je využíváno obsluhy rozhraní pomocí callback funkce, která je součástí sady funkcí ESA API. Externí 118

119 systém nemá přístup k procedurám jádra OM, a proto může využít pouze funkcí definovaných ESA API. ESA API dovoluje při zápisu dat na ESYS rozhraní z externího systému do OM zvolit jednu ze dvou strategií. První je strategie odloženého zápisu. Pro zápis dat na ESYS rozhraní je využito funkce z ESA API, která neinformuje OM o nových datech okamžitě, ale se zpožděním. Velikost zpoždění je jedním z parametrů této funkce. Druhá strategie je zápis dat na rozhraní ESYS a okamžité upozornění OM o příchodu dat. Aby se OM dozvěděl, že ze strany externího systému došlo k zápisu dat na ESYS rozhraní, je využito principu přerušení pomocí události. Jakmile jsou data na rozhraní zapsána, je v OM vyvoláno přerušení indikující příchod dat (viz obr. 5.5). Přerušení je doručeno procesnímu modelu ESYS rozhraní. Procesní model získá pomocí funkcí jádra identifikátor rozhraní, na které byla data zapsána, a následně přečte přijatá data. Při čtení dat z rozhraní je opět použito procedur jádra OM. Poté následuje zpracování dat vnitřní logikou ESYS modelu. Procesní model op_esys_interface...set() Přerušení pro rozhraní ESYS Externí systém Esa_Interface...Set() ESA callback ESYS Obr. 5.5: Mechanizmus předávání přerušení při zápisu dat na ESYS rozhraní Procesní model esys Na obr. 5.6 je zobrazen procesní model esys sloužící k předávání zakódovaných SNMP zpráv do externí aplikace. Procesní model je tvořen 4 stavy: Stav INIT Jedná se o počáteční stav, do něhož se proces dostane ihned po startu simulace. Jeho kód slouží pro inicializaci některých globálních proměnných a pro kontrolu spojení se sousedním procesním modelem udp. Stav IDLE Jedná se výchozí stav celého procesního modelu esys. Proces v tomto stavu čeká na příchod přerušení. Ve vytvořeném modelu mohou nastat dvě základní přerušení: 119

120 Obr. 5.6: Vnitřní struktura procesního modelu esys příchod udp datagramu obsahujícího zakódovaný SNMP dotaz nebo příchod dat z externí aplikace na ESYS rozhraní. Podle typu přerušení přechází proces do některého z vynucených stavů. Stav SEND Stav SEND slouží pro odeslání dat přes ESYS rozhraní směrem do externí aplikace. Proces do něj přechází po příchodu UDP datagramu ze sousedního procesu udp. Příchozí UDP datagram obsahuje řetězec bajtů, který vznikl jako výsledek zakódování SNMP dotazu pomocí BER kódování ve stejnojmenném stavu SEND v procesním modelu snmp_manager. Ve stavu SEND jsou implementovány funkce, které zajistí zápis přijatého řetězce bajtů na ESYS rozhraní. Při zápisu dat na ESYS rozhraní však může nastat jeden problém. Ve chvíli, kdy je v externím kódu vygenerováno přerušení (zápis dat na ESYS rozhraní), je řízení kosimulace předáno tomuto kódu a veškeré procesy uvnitř OM jsou zastaveny. Proces je tak zastaven ve stavu zápisu dat na ESYS rozhraní. Ve chvíli, kdy dojde ke zpětnému zápisu dat z externí aplikace a řízení kosimulace je předáno zpět do OM, není tento proces schopen zpracovávat příchozí data (aby mohl korektně zpracovat data, musí se nacházet ve stavu IDLE). Řešením tohoto problému je vytvoření nového procesu, který bude volán hlavním procesem a který zapíše data na rozhraní. Hlavní proces tak bude mít po vyvolání sekundárního procesu dostatek času pro návrat do stavu IDLE a bude schopen zpracovat příchozí přerušení z ESYS rozhraní a následně provést operaci načítání dat. Sekundární proces je v terminologii prostředí OM nazýván dceřiným procesem (child process). Jeho podoba je totožná se všemi normálními procesy s jediným roz- 120

121 dílem, že není napevno svázán s konkrétním procesním modelem. Pokud je vhodné použít dceřiný proces, pak musí být v rámci rodičovského (hlavního) procesu deklarován v jeho seznamu dceřiných procesů. Funkce pro vytvoření a volání dceřiného procesu jsou následující: op_pro_create - vytvoření instance procesu a sdílené paměti, op_pro_invoke - spuštění (volání) procesu, op_intrpt_schedule_process - naplánování přerušení běžícímu procesu. Pro předávání dat mezi mateřským a dceřiným procesem slouží sdílená paměť. Její obsah je definován druhým parametrem ve funkci op_pro_create. Vlastní funkce pro zápis dat na ESYS rozhraní tedy nejsou definovány přímo ve stavu SEND, ale v nově vytvořeném dceřiném procesu esys_child. Tento dceřiný proces obsahuje dva stavy (viz obr. 5.7). První nevynucený stav START sice neobsahuje žádný zdrojový kód, ale jeho použití je nutné kvůli zachování základní struktury procesních modelů definované v OM. Ve druhém vynuceném stavu EXEC jsou načtena data ze sdílené paměti rodičovského procesu a jsou pomocí funkce op_esys_interface_value_set zapsána na ESYS rozhraní. Před voláním je potřeba získat ukazatel na dané ESYS rozhraní pomocí jeho hierarchického jména. Tento ukazatel je předáván jako argument funkci zapisující data. Dalším důležitým argumentem funkce je příznak OP_ESYS_NOTIFY_ IMMEDIATELY, který definuje, že ihned po zápisu dat je v externím kódu vyvoláno přerušení. Po úspěšném volání této funkce je tedy řízení kosimulace předáno externímu kódu. Obr. 5.7: Vnitřní struktura modelu child_process Stav RECEIVE Posledním stavem procesního modelu esys je stav RECEIVE, který slouží pro příjem SNMP odpovědí z reálné aplikace. Jelikož se proces vždy nachází (čeká) ve stavu IDLE (díky použití dceřiného procesu ve stavu SEND), není při čtení dat z rozhraní ESYS nutné používat dceřiný proces. Při příchodu dat na rozhraní ESYS je vyvoláno přerušení, které způsobí, že proces přejde ze stavu IDLE do stavu RE- CEIVE. V tomto stavu je pak samotné vyčtení hodnoty provedeno pomocí funkce 121

122 op_esys_interface_value_get. Po vykonání kódu implementovaného ve stavu RE- CEIVE přechází proces samovolně zpět do stavu IDLE, kde bude čekat na další přerušení. Definice ESD modulu K procesnímu modelu esys byl definován ESD modul, pomocí něhož bylo popsáno vytvořené ESYS rozhraní. V rámci modelu ESD byla definována celkem čtyři rozhraní: Data_To_Ext - rozhraní pro přenos dat (řetězce bajtů) z OM do externí aplikace, typ rozhraní byl nastaven na char a velikost na 1500 znaků. Data_To_Ext_Size - rozhraní pro přenos hodnoty udávající velikost řetězce přenášeného přes rozhraní Data_To_Ext. Typ byl nastaven na integer a velikost 0 (pouze 1 hodnota). Data_To_OM - rozhraní pro přenos dat (řetězce bajtů) z externí aplikace do OM, typ rozhraní byl nastaven na char a velikost na 1500 znaků. Data_To_OM_Size - rozhraní pro přenos hodnoty udávající velikost řetězce přenášeného přes rozhraní Data_To_OM. Typ byl nastaven na integer a velikost 0 (pouze 1 hodnota). Deskriptor simulace Kromě definice rozhraní ESD modulu bylo nutné vytvořit ještě deskriptor simulace v podobě souboru s příponou *.sd. Vytvořený kosimulační systém byl navržen tak, aby OPNET Modeler byl řídícím prvkem a inicializoval spouštění externí aplikace. Externí aplikace byla tedy do OM připojena v podobě dynamické knihovny, tedy v podobě souboru s příponou *.dll. Tato skutečnost byla definováno vhodným příkazem uvnitř deskriptoru simulace Externí aplikace Jak již bylo zmíněno, v OM existují dva přístupy ke kosimulaci. Rozdílnost těchto přístupů spočívá v určení řídící aplikace pro kosimulaci. První možností přístupu je, že OM je součástí rozsáhlejšího programu. V tomto případě je kód modelů z OM linkován do externího systému. Druhou možností přístupu, která je uvedena na obr. 5.8, je, že externí systém je v podobě knihovny při kompilaci dynamicky linkován do simulace v OM. Pro účely ověření funkčnosti navrženého QoS systému bylo vhodnější použití druhé varianty. Kód externí aplikace byl do prostředí OM přilinkován v podobě DLL (Dynamic Loaded Library) knihovny, tedy v souboru s příponou.dll. Výhodou 122

123 tohoto typu souborů spočívá v tom, že jeho kód je nahrán do operační paměti pouze tehdy, je-li momentálně používán. V opačném případě je knihovna uložena na disku a nezabírá tedy místo v operační paměti. Cesta předávání řízení OPNET Modeler simulace Externí systém (aplikace) Časová osa Obr. 5.8: Předávání řízení v průběhu kosimulace Vytvořená externí aplikace pracuje jako prostředník mezi simulačním prostředím OPNET Modeler a reálným síťovým prvkem (směrovač Cisco C1841). Jejím hlavním úkolem je získat z OM přes rozhraní ESYS sekvenci bajtů (zakódovaný SNMP dotaz), zabalit jej do UDP datagramu a poslat přes síťové rozhraní koncové stanice do směrovače. V opačném směru pak přijmout přes síťové rozhraní odpověď ze směrovače, rozkódovat UDP datagram a SNMP zprávu (zakódovanou pomocí BER) předat přes ESYS rozhraní do simulačního prostředí OM. Za tímto účelem byly v externí aplikaci vytvořeny dvě hlavní funkce: callback a esa_main. Funkce callback je volána při příchodu dat na ESYS rozhraní a funkci esa_main je volána při inicializaci kosimulace. Protože byla externí aplikace vytvářena jako DLL knihovna, těla obou funkcí musela začínat příkazem extern C DLLEXPORT, který umožňuje externímu programu, který knihovnu využívá, volat danou funkci. Pokud by nebyl tento příkaz použit, funkce by byly považovány za vnitřní a bylo by možné je volat pouze funkcemi uvnitř dynamické knihovny. Funkce esa_main Funkce esa_main slouží k inicializaci kosimulace a je volána při spouštění simulace v OM. Tato funkce musí vždy volat incializační funkce Esa_Init a Esa_Load, které jsou součástí balíku ESA API. Kromě těchto dvou funkcí je v kódu funkce esa_main obsažena také inicializace socketů (funkce WSAStartup) pro komunikaci přes reálnou síť. Pro programování aplikace zpracovávající síťovou komunikaci se v operačním systému Windows používají funkce z hlavičkových souborů winsock.h a winsock2.h, které jsou součástí balíku WinSock API. Tyto knihovny vytvářejí síťovou komunikaci pomocí tzv. socketů. 123

124 Socket můžeme chápat jako virtuální tunel, který se vytvoří mezi dvěma komunikujícími stanicemi. Data, která jsou poslána na jedné straně tohoto tunelu, lze přečíst na straně druhé a naopak. Dalším úkolem funkce esa_main je registrace callback funkce (funkce Esa_ Interface_Callback_Register). Při její registraci je mimo jiné nutno zahrnout do argumentů i ESYS rozhraní, ke kterému bude daná callback funkce přiřazena. Funkce callback bude volána pouze tehdy, budou-li na jí přiřazené rozhraní zapsána nějaká data ze strany OM. Poslední dílčí funkcí je Esa_Interface_Get, která slouží pro získání ukazatele na ESYS rozhraní v OM. Jejími parametry jsou identifikátor simulace a hierarchický název hledaného rozhraní. V případě, že funkce navrátí hodnotu ESAC_ INTER- FACE_NULL, což znamená neúspěch, je vypsána chybová zpráva a celá kosimulace se ukončí. Na konci funkce esa_main je volána funkce Esa_Execute_Until, která předá řízení kosimulace zpět do OPNETu, kde dojde ke pokračování simulace. Funkce callback Druhá funkce, která bude volána OM, je funkce callback. Tato funkce bude volána pokaždé, když dojde k zápisu dat na ESYS rozhraní, které k ní bylo přiřazeno funkcí Esa_Callback_Register. Tato funkce má za úkol přijímat data posílaná od směrovače a předávat je do OM. Dále je pomocí funkce socket otevřen nový socket, na kterém bude aplikace poslouchat. Prvním argumentem funkce socket je internet_family, který má stejnou hodnotu jako proměnná family ve struktuře sockaddr_in. Druhý argument určuje protokol pro komunikaci. Byla zvolena hodnota SOCK_DGRAM, která označuje nespojově orientovanou komunikaci na bázi protokolu UDP. Funkce vrací hodnotu integer, která slouží jako ukazatel na nově otevřený socket. V případě chyby je vrácena hodnota záporná a program vypíše chybu a poté pošle do OM příkaz k ukončení simulace pomocí funkce Esa_Terminate. Další volanou funkcí už je přímo funkce sloužící pro ukládání přijatých dat recvfrom. Jejím prvním argumentem je ukazatel na socket, na kterém bude přijímat data. Druhý argument je proměnná, do které se budou přijatá data ukládat. Dalšími argumenty jsou velikost proměnné pro uložení přijatých dat, struktura sockaddr_in s daty, které byly přiděleny danému socketu, a velikost této struktury v paměti. Velikost proměnné v paměti se získává pomocí funkce sizeof. Po přijetí dat už zbývá pouze uzavřít socket pomocí funkce closesocket a poté předat přijatá data OM pomocí funkce Esa_Interface_Value_Set. 124

125 5.2 Ověření vlivu nastavení DSCP značky síťovou aplikací V předchozí kapitole byl popsaný simulační scénář, který sloužil zejména pro ověření mechanizmu získávání požadovaných konfiguračních parametrů z databáze Cisco CBQoS MIB a jejich následné zpracovávání na koncové stanici. V této kapitole bude popsán druhý simulační scénář, jehož hlavním cílem bylo ověření mechanizmu přidělování DSCP značky a vlivu uživatelského nastavení této značky na výsledné parametry provozu. Architektura vytvořeného scénáře je uvedena na obr Scénář je složen ze 4 fyzických prvků: 2 koncových stanic a 2 směrovačů Cisco C1841. K propojení jednotlivých zařízení byla použita ethernetová linka s rychlostí přenosu 10 Mb/s. Na obou směrovačích byla provedena stejná konfigurace technologie DiffServ (mechanizmy třídění, měření, plánovaného odesílání atd.). Koncové stanice pak sloužily pro generování síťového provozu. Simulační model v prostředí OPNET Modeler ESYS rozhraní Externí Aplikace IxChariot C API (DLL knihovna) IxChariot 10 Mb/s Ethernet Koncová stanice (PE 1) Generovaný tok paketů označených DSCP značkou Cisco C1841 Cisco C1841 Koncová stanice (PE 2) Obr. 5.9: Simulační scénář pro ověření vlivu nastavení DSCP značky síťovou aplikací Aby bylo možné ověřit funkčnost navrženého mechanizmu značkování paketů pomocí DSCP značky přímo na reálném provozu, byl použit specializovaný generátor provozu IxChariot od firmy Ixia. IxChariot je softwarový nástroj určený pro testování a simulaci chování reálných síťových aplikací [63]. IxChariot využívá modelu tvořeného koncovými body PE (Performance Endpoint), které se starají o vlastní generování síťového provozu. Pro nastavení parametrů generovaného datového toku slouží konzole IC (IxChariot Console), což je řídící aplikace disponující grafickým uživatelským rozhraním, v kterém je možné řídit simulace a vyhodnocovat dosažené výsledky. IC slouží také pro ovládání jednotlivých bodů PE, které na základě řídících informací přijatých od konzole IC generují datový tok a posílají pakety do sítě, sbírají statistiky a ty následně odesílají zpět do IC [20]. Výhodou této architektury 125

126 je možnost umístění koncových bodů PE na různé typy koncových stanic. Pro vytvoření komunikačního spojení je třeba nejméně dva PE body a jednu řídicí konzoli IC. Dva vzájemně propojené body PE se označují jako komunikační pár. Přes tento komunikační pár je pak přenášen generovaný tok. Jeden koncový bod PE může být použit pro vytvoření více komunikačních párů. Na koncových stanicích v simulačním scénáři byly tedy instalovány koncové body PE, mezi kterými byl generován datový provoz. Jako řídící stanice byla zvolena koncová stanice s PE 1. Na této stanici bylo definováno několik simulačních komponent, jejichž společným cílem bylo vygenerovat tok paketů označených vybranou DSCP značkou a tento tok zaslat přes připojené směrovače na druhou koncovou stanici PE 2. V následujícím textu budou tyto komponenty blíže popsány Model pracovní stanice v simulačním prostředí OM V OPNET Modeleru byl, podobně jako u simulačního scénáře popsaného v kap. 5.1, vytvořen základní simulační scénář tvořený jedním modelem pracovní stanice. Uvnitř tohoto modelu stanice byly implementovány funkce umožňující předávání vybrané hodnoty DSCP přes ESYS rozhraní do externí aplikace [2]. Procesní model snmp_manager_ixchariot Vnitřní struktura modelu pracovní stanice byla totožná s obr Jediný rozdíl byl ve funkcích implementovaných uvnitř procesních modelů snmp_manager a esys. V procesním modelu snmp_manager, viz obr byl odstraněn stav RECEIVE, neboť z tohoto procesního modelu bude DSCP hodnota pouze odesílána. Celý simulační scénář popisovaný v této kapitole přímo navazuje na scénář popsaný v kap. 5.1, jehož výstupem je zjištěná DSCP hodnota. Tato DSCP značka tedy bude zpracována ve stavu IDLE a následně předána do stavu SEND, odkud bude odeslána přes procesní model udp do procesního modelu esys (viz obr Jelikož se jedná o prvotní testování navrženého systému, pro přenos hodnoty DSCP v rámci simulačního prostředí OM byly použity stejné struktury a funkce, které byly implementovány za účelem vytvoření a zakódování SNMP dotazu. Tyto funkce byly popsány v kapitole Hodnota DSCP byla z experimentálních důvodů uložena do položky Version vytvářeného SNMP dotazu. Procesní model esys_ixchariot Z procesního modelu popsaného v kap byl odstraněn stav RECEIVE, neboť předávání dat (DSCP značky) probíhá pouze ve směru z OM do externí aplikace. Předávání DSCP značky probíhá opět formou kosimulace, jejíž základní princip včetně 126

127 Obr. 5.10: Vnitřní struktura procesního modelu snmp_manager určeného pro komunikaci s nástrojem IxChariot definice jejich jednotlivých komponent byl již popsán v kap , proto zde nebudou znovu popisovány. Jediný rozdíl mezi procesy kosimulace v obou scénářích je v tom, že v tomto druhém scénáři byla použita jiná externí aplikace (popsána dále) a v modulu systému ESD bylo definováno pouze jediné rozhraní Data_To_Ext pro předávání DSCP hodnoty Externí aplikace Použitá externí aplikace byla opět vytvořena v jazyce C a zkompilována do podoby dynamické knihovny DLL. Aplikace je tvořena dvěma hlavními funkcemi - esa_main a callback. Zdrojový kód funkce esa_main, která zajišťuje inicializaci a v procesu kosimulace je volána pouze na počátku simulace, je prakticky totožný s externí aplikací použitou při simulaci prvního scénáře. Odlišná je však callback funkce, která je volána pokaždé, když jsou na ESYS rozhraní zapsána data z OM. Funkce callback obsahuje kód pro zpracování příchozí DSCP značky a jejího předání dalšímu článku v řetězci. Tímto dalším článkem je zmíněný generátor síťového provozu IxChariot, který je s externí aplikací propojen přes rozhraní IxChariot C API. Význam tohoto rozhraní je popsaný dále IxChariot API V rámci generátoru síťového provozu je definována sada funkcí IxChariot API, která umožňuje ovlivnit proces generování testovacího datového toku. IxChariot API se dělí na dvě části: TCL (Tool Command Language) API a C API. TCL API slouží pro externí ovládání testů (vysvětleno dále) popisujících generovaný datový tok vytvořených ve skriptovacím jazyce TCL a C API pro řízení testů z aplikací vytvořených v jazyce C [63]. Jelikož je použitá externí aplikace naprogramována v jazyce C, bylo 127

128 pro účely testování zvoleno programové rozhraní C API, díky němuž je možné volat funkce pro řízení generátoru datového toku přímo z vytvořené externí aplikace. Komunikační skript Jednou z možností definice parametrů generovaného datového toku v síťovém generátoru IxChariot jsou komunikační skripty. Jedná se o speciální typ skriptu, který slouží k popisu požadovaného chování aplikací emulovaných na jednotlivých koncových bodů PE. V tomto skriptu je možné definovat např. velikost paketů, časové charakteristiky odesílání paketů, atd. Každý skript se skládá ze dvou částí - každá pro jeden PE. QoS šablony Kromě základních parametrů generovaného toku je možné v nástroji IxChariot definovat i QoS parametry, což se provádí pomocí tzv. šablon. IxChariot obsahuje několik výchozích šablon (např. VoIP), ale umožňuje vytvářet také nové šablony. Na obr je zobrazena vytvořená QoS šablona s názvem OpnetTOS sloužící pro nastavování DSCP značky přijaté z OM. Obr. 5.11: QoS šablona OpnetTOS vytvořená v generátoru provozu IxChariot Z komunikačního skriptu a QoS šablony je možné vytvořit výsledný test, který proběhne mezi definovanými koncovými body PE. Konfigurace testů včetně jejich výsledků jsou ukládány do souborů *.tst. 128