VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ FAKULTA ELEKTROTECHNIKY A KOMUNIKAČÍCH TECHNOLOGIÍ. Ing. Karol Molnár, Ph.D. DIFERENCOVANÉHO ZAJIŠTĚNÍ KVALITY SLUŽEB

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ FAKULTA ELEKTROTECHNIKY A KOMUNIKAČÍCH TECHNOLOGIÍ Ing. Karol Molnár, Ph.D. UŽIVATELEM OVLADATELNÝ MECHANISMUS DIFERENCOVANÉHO ZAJIŠTĚNÍ KVALITY SLUŽEB USER-MANAGEABLE MECHANISM FOR DIFFERENTIATED QUALITY OF SERVICE SUPPORT ZKRÁCENÁ VERZE HABI LITAČNÍ PRÁCE BRNO 2008

Klíčová slova: kvalita služeb, QoS, mechanismus diferencovaných služeb, DiffServ, Simple Network Management Protocol, SNMP, Management Information Base, MIB, DiffServ-MIB, bezdrátové síťové technologie, 802.11a/b/g, 802.11e. Key words: Quality of Service, QoS, Differentiated Services, DiffServ, Simple Network Management Protocol, SNMP, Management Information Base, MIB, DiffServ-MIB, wireless network technologies, 802.11a/b/g, 802.11e. Originál je uložen na vědeckém oddělení FEKT VUT v Brně. Karol Molnár, 2008 ISBN 978-80-214-3669-5 ISSN 1213-418X

AUTOR Ing. Karol Molnár, Ph.D. Narozen: Kontakt: 2. 1. 1974 v Šali, SR ÚTKO, FEKT, Vysoké učení technické v Brně, Purkyňova 118, 612 00 Brno, molnar@feec.vutbr.cz. 1992 1997 Vysokoškolské studium v inženýrském studijním oboru 26-60-8 Elektronika a sdělovací technika na Fakultě elektrotechniky a informatiky Vysokého učení technického v Brně. 1997 Úspěšná obhajoba diplomové práce vypracované na téma Rekonstrukce telefonní sítě v laboratoři sdělovací techniky. 1997 2002 Vysokoškolské vzdělání v doktorském studijním programu P 2643 Elektrotechnika, elektronika a komunikační a řídicí technika ve studijním programu Teleinformatika. 2002 Úspěšná obhajoba disertační práce na téma Aplikace umělých neuronových sítí ve vysokorychlostních aktivních síťových prvcích. Odborné zaměření: zajištění kvality služeb v datových sítích, komunikační a řídicí protokoly bezdrátových a mobilních síťových technologií, moderní vysokorychlostní komunikační technologie, správa a management prvků datových sítí, modelování a simulace chování síťových protokolů.

OBSAH 1 ÚVOD...6 1.1 Cíl habilitační práce...6 1.2 Stručný Přehled současného stavu řešené problematiky...6 2 MECHANISMUS DIFERENCOVANÝCH SLUŽEB...7 2.1 Možnosti zajištění kvality služeb v datových sítích...7 2.2 Značkování paketů...8 2.3 Klasifikace paketů...8 2.4 Dohled nad síťovým provozem...8 2.4.1 Přenosová rychlost...9 2.4.2 Mechanismus Token-Bucket...9 2.4.3 Barvení paketů...9 2.5 Řízené odesílání paketů...10 2.6 Hraniční a páteřní směrovače mechanismu DiffServ...10 2.6.1 Způsob zacházení s pakety...11 3 KONCEPČNÍ MODEL PRO SPRÁVU TECHNOLOGIE DIFFSERV...12 4 PROTOKOL SNMP...13 5 DATABÁZE MIB PRO SPRÁVU NASTAVENÍ PARAMETRŮ DIFFSERV...15 5.1 Obecný popis databáze DiffServ-MIB...15 5.1.1 Cesta zpracování provozu...15 5.1.2 Modelu mechanismu DiffServ...18 6 METODA ZÍSKÁNÍ INFORMACÍ O NASTAVENÍ TECHNOLOGIE DIFFSERV...20 6.1 Klíčové požadavky na spolupráci s mechanismem DiffServ...20 6.2 Analýza možností spolupráce s mechanismem DiffServ...20 7 NÁVRH SYSTÉMU PRO ZPŘÍSTUPNĚNÍ INFORMACÍ O TECHNOLOGII DIFFSERV UŽIVATELSKÝM APLIKACÍM...21 7.1 Proces výběru třídy...22 7.2 Způsoby nastavení DSCP...22 4

8 ŘÍZENÍ KVALITY SLUŽEB V BEZDRÁTOVÝCH SÍTÍCH...23 8.1 Základní mechanismy řízení přístupu k médiu v bezdrátových lokálních sítích...23 8.2 Pokročilé mechanismy zajištění kvality služeb v bezdrátových lokálních sítích...23 8.2.1 Rozšířený distribuovaný přístup ke kanálu (EDCA)...24 8.2.2 Přístup ke kanálu řízený pomocí HCF (HCCA)....24 8.3 Možnosti využívání systému řízení kvality služeb spolupracující s mechanismem DiffServ...24 9 ZÁVĚR...26 10 SEZNAM POUŽITÉ LITERATURY...27 5

1 ÚVOD 1.1 CÍL HABILITAČNÍ PRÁCE Záměrem habilitační práce je navrhnout mechanismus, který umožní stávajícím i budoucím síťovým aplikacím lépe se podílet na řízení zajištění kvality služeb v přenosové síti, a tak zvýšit úroveň síťové komunikace pro koncové uživatele. Potřeba takového řešení je podložena několika fakty. Vzhledem ke shlukovému charakteru komunikace v paketových sítích nelze zcela zabránit krátkodobému vyčerpání dostupných síťových prostředků. Proto nemohou klasické paketové síťové technologie trvale garantovat specifickou úroveň síťové služby. Vzhledem k výrazným finančním tlakům je komerční zájem o propracované řešení zajištění kvality služeb velice omezený. Mnohem větší úspěch zažívají jednoduché mechanismy, které mají nízké hardwarové nároky a jejichž implementace i správa je relativně nenáročná. Největší nevýhoda těchto řešení spočívá v tom, že nejsou určena pro spolupráci s koncovým uživatelem či terminálem, který danou síťovou službu využívá. Přitom právě koncový uživatel provádí hodnocení kvality služeb, a proto může právem vyžadovat možnost určité spolupráce v jejím řízení. Vytýčený záměr habilitační práce je možné rozdělit na několik dílčích cílů: V první řadě je nutné provést důkladnou analýzu stávajících mechanismů pro zajištění kvality služeb a zhodnotit jejich perspektivu a možnosti spolupráce s uživatelem. Následně je třeba definovat základní požadavky na očekávaný systém a rozebrat možnosti realizace navrženého řešení. V dalším kroku je nutné provést důkladnou analýzu alternativních mechanismů a nástrojů, které jsou dostupné ve stávajících síťových prvcích a které je možné využít k dosažení vytýčeného záměru. Pokud chceme nabízet koncovému uživateli možnost podílet se na řízení kvality, musíme také definovat požadavky na koncovou aplikaci a na systém výměny řídicích informací mezi aplikací a sítí. Po definici požadavků lze navrhnout koncepční model, který je založen na vybraných mechanismech a nástrojích a splňuje požadavky záměru. Je třeba podrobně vyhodnotit vlastnosti zvoleného řešení a definovat spolupráci navrženého systému s komponentami okolních systémů. Předložená práce postupně prezentuje výsledky prací spojených se splněním jednotlivých dílčích cílů. 1.2 STRUČNÝ PŘEHLED SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY Základem moderní informační společnosti je kvalitní a spolehlivá komunikační síť s rozsáhlou podporou síťových služeb různého charakteru. Klíčovým požadavkem při provozování různých služeb přes jednu přenosovou síť je zajištění diferencovaného zpracování datových toků přicházejících od služeb s odlišnými požadavky na parametry přenosu. Protože první síťové služby měly velmi podobné požadavky na přenos, historicky starší síťové technologie mohly tento provoz zpracovat jednotným způsobem. Značná diferenciace dnešních služeb však vedla k tomu, že tento jednoduchý přístup již není vyhovující a hledají se alternativní mechanismy, které mohou zajistit odlišný způsob zpracování datových toků, a to jednoduše a efektivně. Protože se jedná o komplexní problematiku, bylo postupem času navrženo několik různých řešení. Některá z nich jsou schopna garantovat i velmi striktní požadavky, ale za cenu náročného zpracování a velkých režijních nákladů. Jiné metody jsou jednodušší a tomu odpovídají i jejich 6

omezené možnosti. Současná analýza vývoje ukazuje, že i přes jejich omezenost komerčně větší úspěch zažívají jednodušší řešení, která jsou jednak levnější a jednak mají menší nároky na správu a údržbu. Pro zachování co největší míry jednoduchosti jsou tyto systémy implementovány zpravidla pouze v aktivních síťových prvcích a pracují pouze na základě pevně nastavených konfiguračních pravidel. Výraznou nevýhodou takového řešení je však ignorování požadavků koncových stanic. Pravidla zpracování provozu jsou definována v uzlech sítě a jejich dopad na celkový síťový provoz pak záleží na znalosti správce sítě o typu a požadavcích provozovaných síťových aplikací. Tato práce vychází z nejrozšířenějšího mechanismu zajištění kvality služeb označeného jako mechanismus diferencovaných služeb (Differentiated Services DiffServ). DiffServ patří do skupiny technologií, které jsou implementovány pouze v síťových uzlech. V předložené práci je navržena metoda, která umožňuje spolupráci uživatelské aplikace či operačního systému s tímto mechanismem, a tak nabízí uživatelům efektivnější a flexibilnější využití tohoto mechanismu. Důležitým požadavkem při návrhu metody pro spolupráci byl minimální zásah do stávajících implementací mechanismu DiffServ. Vyplývá to ze skutečnosti, že vzhledem k velkému počtu výrobců a zařízení je implementace mechanismu DiffServ značně rozsáhlá a různorodá. Přidávání nových funkcí do aktivních prvků by proto vyžadovalo rozsáhlou podporu od všech výrobců. Místo toho byly využity mechanismy, které jsou rovněž dostupné ve stávajících zařízeních a které lze alternativně využít i k danému úkolu. Navržená metoda je určena především pro využívání v pevných datových sítích. Poslední část práce však podrobně rozebírá mechanismy zajištění kvality služeb v současných bezdrátových sítích a nabízí možnosti pro využití navržené metody i u těchto typů komunikačních technologií. 2 MECHANISMUS DIFERENCOVANÝCH SLUŽEB 2.1 MOŽNOSTI ZAJIŠTĚNÍ KVALITY SLUŽEB V DATOVÝCH SÍTÍCH Řada především starších síťových technologií založených na přepínání paketů/rámců poskytuje všem datovým jednotkám stejný způsob zacházení. Pro moderní komunikační sítě využívané pro zajištění různých typů služeb s různými požadavky na parametry přenosu je však takový přístup nevyhovující. Efektivní provozování různých služeb přes jednu síť vyžaduje, aby síť byla schopna rozeznat datové jednotky jednotlivých služeb a následně jim zajistit odpovídající způsob zacházení. Existují dvě základní možnosti, jak řízené zacházení zajistit: Technologie Integrovaných služeb (Integrated Services IntServ) je schopna rozlišit každý datový tok na základě identifikátorů odesílatele a příjemce. Proto je schopna zajistit řízení kvality služeb po celé trase od zdroje až k cílové stanici. Diferencované služby (DiffServ) dělí síťový provoz do několika málo tříd a pak zajišťují odlišné zacházení jednotlivým třídám. DiffServ proto není schopen garantovat parametry pro jednotlivé datové toky, ale mnohem méně zatěžuje procesor aktivního prvku a je výrazně lépe škálovatelný než technologie IntServ. Každá technologie pro zajištění kvality služeb musí zajistit dva základní úkoly: 1) třídění datových jednotek podle parametrů provozu nebo služby, 2) zajištění odlišného zacházení pro jednotlivé třídy pomocí řízeného přidělování síťových zdrojů. Úkol 1) se běžně provádí na rozhraní mezi uživatelem a sítí, příp. na rozhraní mezi síťovými prvky. Tento úkol lze rozdělit na dvě základní funkce: klasifikace paketů na základě identifikátorů provozu či typu třídy, značkování paketů přidělením identifikátoru třídy, kam byl paket zařazen; tento krok zajišťuje rychlejší provedení následujících funkcí. 7

Úkol 2) běžně zajišťují aktivní síťové prvky, především směrovače, a skládá se ze čtyř hlavních funkcí: dohled nad provozem zajišťuje měření přicházejícího provozu a případné vyřazení či přeznačení datových jednotek vybočujících ze sjednaných parametrů, aktivní správa front, pomocí které je zajištěno odlišné zacházení jednotlivým třídám, plánované odesílání paketů, které řídí, ve kterém okamžiku který paket bude vyslán, tvarování provozu, které se snaží vyhladit shlukový charakter přenosu pro lepší využití dostupné kapacity linky. 2.2 ZNAČKOVÁNÍ PAKETŮ Značkování slouží pro označení příslušnosti datové jednotky ke své třídě. Nejčastěji je realizováno nastavením hodnoty určitého pole v hlavičce IP datagramu. Příkladem značky může být IP adresa zdroje, IP adresa cílového uzlu nebo jejich kombinace. Technologie DiffServ nastavuje hodnotu pole DSCP (DiffServ Code Point) hlavičky IP pro identifikaci třídy. Paket vstupující do směrovače už může být označen jiným prvkem sítě nebo zatím neoznačený. Pokud paket už byl označen, daný směrovač ho může přeznačit, např. když paket vybočuje z předem sjednaných parametrů přenosu. Dalším důvodem přeznačkování může být situace, kdy paket přechází z jedné sítě do druhé, kde se používá odlišný způsob či pravidla značkování. U mechanismu diferencovaných služeb je zpracování provozu řízeno relativními prioritami přiřazenými jednotlivým třídám provozu. Specifikace mechanismu Diffserv [9] definuje nový význam pro pole ToS a místo absolutní priority paketu IP toto pole udává pouze identifikátor třídy. Vzájemná priorita tříd je pak nastavena v rámci konfigurace směrovače. Specifikace rovněž uvádí nové označení DS (podle názvu Differentiated Services) pro toto pole, viz Obr. 2.1. Podle této specifikace prvních šest bitů pole DS, tzv. kódové označení diferencované služby (DiffServ Code Point DSCP), je používáno k označení třídy a zbylé dva bity zůstaly nevyužity. Obr. 2.1 Struktura pole DS 2.3 KLASIFIKACE PAKETŮ Klasifikace je proces řazení paketů do skupin podle předem stanovených pravidel. Proces klasifikace v síťových prvcích se provádí na základě informací uložených do hlavičky datové jednotky. Dva nejčastější typy klasifikace jsou: sloučené vyhodnocení (Behaviour Aggregate BA) a vícepoložkové třídění (Multi-Field Calssification MF). BA klasifikace vybírá pakety podle jediného identifikátoru. Tímto identifikátorem je značka umístěná v záhlaví IP paketu v poli DSCP. Vícepoložková klasifikace (MF) vybírá pakety na základě jedné nebo více položek v hlavičce protokolu IP, příp. TCP/UDP, jako jsou: zdrojová adresa, cílová adresa či typ, zdrojový nebo cílový port transportního protokolu, resp. jejich kombinace. 2.4 DOHLED NAD SÍŤOVÝM PROVOZEM Dohled nad provozem má zajistit, aby se datový tok vstupující do sítě pohyboval v mezích dohodnutých mezi zákazníkem a poskytovatelem připojení. Dohled se skládá z měření provozu a na základě výsledků měření se stanoví další způsob zpracování paketů datového toku. Zvolený způsob zpracování může vést k zachování původně přidělené značky, k přeznačení paketů jinou značkou, či k zahození paketu. Proto, značkování odráží výsledek měření. 8

2.4.1 Přenosová rychlost Dohled nad síťovým provozem je založen na kontrole provozu přicházejícího na vstupní porty. Nejčastěji se ověřují následující dva parametry provozu: garantovaná průměrná přenosová rychlost (Committed Information Rate CIR) a maximální okamžitá přenosová rychlost (Peak Information Rate PIR). Měření uvedených přenosových rychlostí vyžaduje sledování dalších parametrů, kterými jsou: velikost garantovaného shluku (Committed Burst Size CBS), velikost maximálního sluku (Peak Burst Size PBS), velikost nadměrného sluku (Excess Burst Size EBS). 2.4.2 Mechanismus Token-Bucket Mechanismus Token-Bucket (TB) je nejčastěji využívaným mechanismem pro měření provozu. Výsledky měření jsou pak zohledněny při procesu značkování nebo rozhodování o zahození paketu. Mechanismus TB na Obr. 2.2 lze popsat dvěma parametry: rychlostí doplňování tokenů r a velikostí nádoby b. Největší povolený shluk přicházejících paketů tedy odpovídá objemu nádoby b a dlouhodobá průměrná rychlost zpracování příchozích dat odpovídá rychlosti doplňování tokenů do nádoby r. Dlouhodobý průměr rychlosti přicházejících dat tedy nesmí překročit rychlost doplňování tokenů a krátkodobé špičky nesmí překročit velikost nádoby, jinak může dojít k zahození nebo jinému alternativnímu způsobu zpracování paketů. Obr. 2.2 Mechanismus Token bucket 2.4.3 Barvení paketů Po identifikaci datového toku, pro který byl sjednán definovaný způsob zacházení, proběhne měření, jestli datový tok splňuje předem určené parametry. Podle výsledku měření je pak paket označen příslušnou značkou. Kombinace procesů měření a přidělení příslušné značky je často označována pojmem barvení. V současnosti jsou specifikovány dva základní mechanismy barvení: 9

jedna rychlost 3 barvy (Single Rate Three Color Marker srtcm) a dvě rychlosti 3 barvy (Two Rate Three Color Marker trtcm). 2.5 ŘÍZENÉ ODESÍLÁNÍ PAKETŮ Klíčem k zajištění odlišného zacházení různých datových toků ve směrovačích je řazení paketů do oddělených front a diferencovaný způsob odesílání paketů z těchto front. Kromě samotného odesílání paketů podle příslušného prioritního mechanismu, dalším důležitým úkolem řízení odesílání je dohled nad dostupnými síťovými prostředky, především nad šířkou pásma odchozího portu. Protože technologie přepínání paketů je založena na statistickém multiplexu paketů, nelze zaručit, aby nedocházelo ke krátkodobému překročení kapacity odchozí linky. V takových případech jsou pakety s nižší prioritou pozdrženy ve frontách. Výběr paketů, které mohou být odeslány a které musí ještě zůstat ve frontách, je úkolem procesu řízení odesílání. Existuje šest základních metod řízení odesílání paketů [37], konkrétně se jedná o: frontu typu FIFO (First-In-First-Out), prioritní systém front (Priority Queuing PQ), systém front se spravedlivou obsluhou (Fair-queuing FQ), systém front s váženou cyklickou obsluhou (Weighted Round Robin WRR), systém front s váženou spravedlivou obsluhou (Weighted Fair Queuing WFQ), systém front založený na třídách s váženou spravedlivou obsluhou (Class-Based Weighted Fair Queuing CB WFQ). 2.6 HRANIČNÍ A PÁTEŘNÍ SMĚROVAČE MECHANISMU DIFFSERV Aby bylo možné co nejvýrazněji optimalizovat výkon potřebný k provozování systému pro zajištění kvality služeb, bylo nutno omezit místa v síti, kde jsou výkonnostně nejnáročnější operace prováděny. U mechanismu DiffSrev bylo zvoleno takové řešení, u kterého jednotlivé funkce byly rozděleny mezi síťové prvky. Byly tak definovány dva typy směrovačů, hraniční a páteřní směrovač, které společně zajišťují ucelený systém podpory kvality služeb. Rozdělení funkcí mechanismu diferencovaných služeb mezi jednotlivé směrovače ovlivňuje i vnitřní architekturu jednotlivých směrovačů. Hraniční směrovače se nacházejí na hranici sítě s podporou mechanismu DiffServ, a proto musí být schopny příchozí tok datových jednotek klasifikovat, kontrolovat dodržení sjednaných parametrů rychlosti a odpovídajícím způsobem značkovat, pozdržet či v krajním případě zahodit tyto pakety. Modelová vnitřní architektura hraničního směrovače je zobrazena na Obr. 2.3. Obr. 2.3 Modelová vnitřní architektura hraničního směrovače 10

Jednotlivé hraniční směrovače jsou vzájemně pospojovány páteřními směrovači. Z hlediska zajištění kvality služeb páteřní směrovače už dostávají značkované pakety, kterým je třeba zajistit diferencované zacházení. Toto zacházení spočívá především v řízeném přidělování šířky pásma a zajištění specifikovaných parametrů zpoždění jednotlivým třídám. Modelová architektura páteřního směrovače je uvedena na Obr. 2.4. Obr. 2.4 Modelová vnitřní architektura páteřního směrovače Modelová vnitřní architektura ukazuje, že pakety přicházející na odpovídající výstup musí být nejdřív klasifikovány na základě hodnoty DSCP, aby bylo možné je řadit do odpovídajících front. Fronty jsou pak obsluhovány plánovačem, který zajišťuje rozdělení šířky pásma mezi jednotlivé fronty a časovou předvídatelnost čekání paketů ve frontě podle nastavené konfigurace. Část sítě složená z hraničních a páteřních směrovačů, které společně zajišťují určitou jednotnou sadu způsobu zacházení s pakety, je označena pojmem DiffServ doména. Styk DiffServ domény se zbytkem síťového prostředí musí být zajištěn hraničními směrovači. 2.6.1 Způsob zacházení s pakety Základem mechanismu diferencovaných služeb je zajišťování definovaného způsobu zpracování paketů jednotlivých tříd a řízené rozdělování sdílených síťových prostředků mezi soutěžícími třídami provozu. Způsob specifikace zpracování provozu ve spojitosti s mechanismem DiffServ je označen pojmem způsob zacházení s pakety (Per-Hop Behaviour PHB). PHB může být definován pomocí objemu potřebných síťových zdrojů, relativní priority způsobu zacházení vůči jiným PHB nebo specifikací vlivu zpracování na provoz. Příslušný způsob zacházení je jednoznačně identifikován hodnotou pole DSCP v hlavičce IP datagramu. Ve spojitosti s mechanismem DiffServ byly definovány tři způsoby zacházení s pakety. Způsob zacházení Best-Effort (BE) PHB typu BE představuje výchozí způsob zpracování paketů, které nebyly zařazeny do žádné z definovaných tříd provozu. U tohoto způsobu zpracování paketů má charakter best-effort, což znamená, že síťový prvek se snaží zpracovat tento provoz, ale negarantuje žádné parametry pro zpracování. Způsob zacházení Expedited Forwarding (EF) Tento způsob zacházení byl poprvé specifikován v dokumentu RFC 2598 [14] a v roce 2002 upraven v dokumentu RFC 3246 [24]. PHB typu EF je určen pro služby se striktním požadavkem na zpoždění a kolísání zpoždění při nízké hodnotě ztrátovosti. Je vhodný především pro zajištění služeb pracujících v reálném čase přes paketovou síť. Nejčastějším představitelem takové služby je v současnosti provoz internetové telefonie. 11

Aby přísné požadavky na zpoždění a kolísání zpoždění bylo možné splnit, je nutné rezervovat pro tento způsob zacházení část šířky pásma výstupního portu směrovače. Dále je nutné zajistit prioritní obsluhu příslušné fronty. U většiny implementací fronta pro PHB typu EF je realizována jako prioritní a má větší prioritu než všechny ostatní fronty. Nevýhodou uvedeného řešení je možnost monopolizace linky. Proto jsou běžně implementovány dva ochranné mechanismy. Nejdříve pakety přicházející na vstup směrovače a požadující zacházení typu EF jsou striktně hlídány a v případě překročení hraniční hodnoty rychlosti jsou zahozeny. Dále je při prioritní obsluze fronty na výstupním portu pevně nastavena maximální rychlost, kterou může být příslušná fronta obsloužena. Způsob zacházení Assured Forwarding (AF) Způsob zacházení typu AF je podrobně popsán v dokumentu RFC 2597 [13]. Oproti EF se v tomto případě využívá systém několika tříd, mezi kterými jsou definovány vzájemné priority a další vztahy důležité pro správnou obsluhu a plánování odesílání paketů. Tento způsob zpracování je určen především pro služby vyžadující spolehlivost, která se projevuje menší mírou ztrátovosti paketů. Cenou za větší spolehlivost je pak větší zpoždění a výraznější kolísání zpoždění. Podle specifikace způsob zacházení typu AF může využívat až čtyři třídy, kde je každá třída dále dělena na tři prioritně oddělené podtřídy. Standard však nedefinuje vzájemný vztah mezi jednotlivými třídami. Předpokládá, že tento vztah bude nastaven správcem sítě, a to tak, aby každá třída měla přidělenou určitou část šířky pásma výstupního portu. Rozdíly mezi třídami vycházejí z velikosti šířky pásma garantovaného pro jednotlivé třídy. Jak už bylo uvedeno, každá třída může být dále dělena na tři podtřídy. Každé podtřídě odpovídá jiná pravděpodobnost zahození v případě zahlcení sítě. Řazení paketů do podtříd je zpravidla řešeno na základě výsledků měření příchozího provozu. 3 KONCEPČNÍ MODEL PRO SPRÁVU TECHNOLOGIE DIFFSERV Popularita mechanismu DiffServ motivovala členy organizace Internet Enginnering Task Force (IETF), aby vypracovali obecný koncepční model pro správu směrovačů podporujících mechanismus diferencovaných služeb. Tento model byl zveřejněn v dokumentu RFC 3290 [30]. Cílem dokumentu nebylo specifikovat referenční architekturu, která by umožnila sjednotit nástroje pro konfiguraci a správu směrovačů od různých výrobců. Základní model směrovače podporujícího mechanismus DiffServ je uveden na Obr. 3.1. Z hlediska mechanismu DiffServ jsou důležité bloky zpracovávající příchozí a odchozí datové toky a samozřejmě řídicí komponenty těchto bloků. Jak bylo uvedeno v předchozí kapitole, mechanismus diferencovaných služeb se skládá z několika dílčích bloků s přesně definovatelným chováním. Tyto bloky se objevují také v tomto koncepčním modelu. Konkrétně se jedná o: klasifikátor síťového provozu, bloky zajišťující měření provozu, bloky realizující zpracování paketů (značkování, zahazování a počítání paketů, multiplexování více datových toků atd.), systémy front vč. modulů pro algoritmické zahazování a plánování odesílání paketů, kombinace předchozích elementárních bloků do komplexnější funkční jednotky. Na základě jednotného modelu je pak možné navrhnout a vytvářet univerzální nástroje pro konfiguraci a správu parametrů mechanismu DiffServ. 12

Obr. 3.1 Obecný model směrovače podporujícího mechanismus DiffServ Klíčovou strukturou celého modelu je cesta zpracování dat, která představuje řetězec funkčních bloků, přes které je veden tok paketů. Cesta zpracování dat je přitom rozvětvená podle podmínek stanovených pro různé třídy provozu. Struktura modelu byla zvolena tak, aby umožnila hierarchickou konfiguraci mechanismu DiffServ. V této hierarchii na nejnižší úrovni stojí jednotlivé funkční bloky, jako např. klasifikátor paketů, měřič provozu atd. Každý funkční blok přitom má svoji sadu parametrů, pomocí kterých lze ovlivnit jeho chování. Následující úroveň v hierarchii představují moduly složené z několika funkčních bloků tak, aby zajistily požadovanou úpravu provozu. Takové moduly jsou označeny pojmem blok úpravy provozu (Traffic Conditioning Block TCB). Nejvyšší úroveň hierarchické konfigurace představuje správa samotných rozhraní. Rozhraní jsou rozdělena na vstupní a výstupní a v každém směru lze modelovat pomocí jednoho nebo více modulů TCB. 4 PROTOKOL SNMP Postupným rozšiřováním datových sítí nabývala na významu také možnost vzdálené konfigurace a nepřetržitého dohledu nad síťovými komponentami. Tato iniciativa uživatelů a výrobců aktivních prvků vedla k návrhu a schválení standardu nabízejícího flexibilní mechanismus pro vzdálenou správu aktivních síťových prvků. Takový mechanismus určený pro využívání v sítích IP byl organizací Internet Engineering Task Force uveden v roce 1990 pod názvem Simple Network Management Protocol (SNMP) [2]. Mechanismus se stal velice oblíbeným a v současnosti je implementován téměř v každém sofistikovanějším síťovém zařízení. Univerzálnost protokolu SNMP umožňuje jeho široké využití. Z tohoto důvodu byl zvolen jako základní komunikační protokol pro navržený systém řízení kvality služeb. Systém vzdálené správy pomocí SNMP využívá dva typy komponent: stanice určené pro správu síťových prvků, tzv. manažery a spravované komponenty sítě, tzv. agenty. Manažer zajišťuje pravidelné dotazování agentů a zpracování varovných zpráv, tzv. trap zpráv, pomocí kterých jsou agenty schopny informovat manažera o výjimečných událostech. Pravidelné dotazování manažerů je vhodné pro dlouhodobé sledování chování síťového prvku. Výjimečné události představují náhlé změny, které vyžadují rychlou reakci. Manažer je zpravidla pracovní stanice vybavená uživatelským programem určeným pro správu a dohled nad sítí. Tento uživatelský program je nejčastěji přímo ovládán lidskou obsluhou. Agent je rovněž specializovaným softwarem běžícím na konkrétním síťovém prvku. Může se jednat např. o samostatnou službu běžného operačního systému nebo o část operačního systému zajišťujícího správný chod aktivního prvku. 13

Aby manažery a agenty od různých výrobců mohly spolu komunikovat, bylo potřeba standardizovat způsob výměny informací. Příslušné standardy zahrnují jak komunikační protokol, tak i způsob popisu přenášených informací. Komunikačním protokolem mezi manažerem a agentem je protokol Simple Network Management Protocol (SNMP). V systému SNMP jsou statické i dynamické parametry síťového prvku a zpracovávaného síťového provozu modelovány pomocí tzv. řízených objektů. Popis objektů a jejich chování je definován využitím standardizované struktury řídicích informací (Structure of Management Information SMI). Databáze objektů popisujících chování síťového prvku, které agent spravuje, je označena termínem databáze řídicích informací (Management Information Base MIB). MIB obsahuje všechny stavové a statistické informace, které manažer může získat od daného agenta. Agent může implementovat více MIB databází, ale každý agent spravuje minimálně jednu MIB databázi definovanou v dokumentu RFC1213 [4]. Tato 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 prvku mohou sloužit pro popis jednotlivých rozhraní a jiných proprietárních vlastností zařízení, která jsou implementovaná konkrétním výrobcem. Protokol SNMP je určen pro využití v sítích založených na sadě protokolů TCP/IP, jak je to vidět na Obr. 4.1. Pro výměnu zpráv využívá transportní protokol UDP. Komunikace na úrovni transportního protokolu UDP probíhá na portech 161 pro standardní výměnu zpráv typu žádostodpověď a 162 pro varovné zprávy trap. Obr. 4.1 Architektura systému vzdálené správy na bázi SNMP 14

5 DATABÁZE MIB PRO SPRÁVU NASTAVENÍ PARAMETRŮ DIFFSERV Specifikace databáze MIB pro mechanismus diferencovaných služeb byla zveřejněna v dokumentu RFC 3289 [29]. V dalším textu je tato větev systémové databáze MIB označena pojmem DiffServ-MIB a její nejdůležitější vlastnosti jsou shrnuty v následujícíh kapitolách. 5.1 OBECNÝ POPIS DATABÁZE DIFFSERV-MIB Definice DiffServ-MIB je založena na základních funkčních elementech jako třídič paketů, měřič provozu, prvky pro zpracování paketů, fronty, plánovače odesílání, algoritmický zahazovač atd. Cesta zpracování provozu je pak definována posloupností příslušných základních funkčních elementů. Specifikace každého funkčního elementu v jazyce ASN.1 obsahuje prvek, který ukazuje na následující funkční element v cestě zpracování provozu. MIB umožňuje přímý přístup ke všem instancím funkčních elementů. Funkční elementy stejného typu, tj. klasifikátory, měřiče, zahazovače atd. jsou vždy řazeny do samostatné tabulky. Záznam funkčního elementu v MIB je složen ze dvou komponent. První komponentou je strukturální a druhou parametrický element. Tato struktura je znázorněna na Obr. 5.1. Obr. 5.1 Struktura funkčního elementu Výhodou uvedené struktury je, že umožňuje opakované využití prvků. Pro odkazování na jednotlivé elementy systému byl definován speciální ukazatel označený názvem RowPointer. Podle struktury funkčního elementu RowPointer může zajišťovat pospojování funkčních elementů do cesty zpracování provozu nebo odkazovat na sadu parametrů pro daný strukturální element. Výhodou využití ukazatele je možnost dodatečného definování dalších funkčních elementů či jiných sad parametrů, které nejsou obsaženy v původní definici DiffServ-MIB. 5.1.1 Cesta zpracování provozu Zpracování dat v modulu rozhraní se obecně liší v jednom a v druhém směru. Provoz vstupující do směrovače je nutné klasifikovat, měřit, počítat a označit přidělením příslušné hodnoty DSCP. Stejný tok před odesíláním může být přeznačkován a je řazen do systému front. V obou případech se však využívají standardní funkční elementy a jednotný způsob jejich provázání. Prvním krokem po obdržení paketu je stanovení začátku cesty zpracování provozu, podle které bude paket zpracován. Tato informace je uložena v tabulce cest zpracování dat s názvem diffservdatapathtable a s OID 1.3.6.1.2.1.97.1.1.1. Tabulka odkazuje využitím ukazatelů RowPointer na první funkční elementy cesty zpracování dat a je indexována pomocí identifikátoru rozhraní a směru toku dat. Co je prvním funkčním elementem, není z hlediska MIB důležité, ale obecně je prvním blokem klasifikátor. Úlohou klasifikátorů je roztřídit příchozí pakety. Podle umístění směrovače v DiffServ doméně jsou kladeny odlišné požadavky na klasifikaci. Uvnitř páteřní sítě jsou už jednotlivé pakety značkovány, a proto k zajištění požadovaného způsobu zacházení stačí sledovat příslušnou 15

hodnotu DSCP. Na hranici DiffServ domény je situace odlišná. Zde do směrovače nejčastěji přichází netříděný provoz, který je nutné klasifikovat. Na tomto rozhraní se nejčastěji využívá vícepoložkový klasifikátor. Vícepoložkový klasifikátor umí třídit pakety i podle hodnot v poli DSCP hlavičky protokolu IP, a tak může nahradit sloučené vyhodnocení BA. Pro implementaci složitějších klasifikačních algoritmů je často vhodné proces klasifikace rozdělit do několika kroků. Taková struktura klasifikátoru je pak modelována řazením více jednodušších klasifikátorů za sebou. Každý klasifikátor je složen z pravidel, která jsou označena pojmem element klasifikátoru. Každý element klasifikátoru pak identifikuje část provozu. Všechny elementy klasifikátoru jsou uloženy v tabulce diffservclfrelementtable s OID 1.3.6.1.2.1.97.1.2.4. Vzhledem ke své funkci je element klasifikátoru strukturálním elementem. Parametrickým elementem pro element klasifikátoru je vícepoložkový klasifikátor. Instance parametrických elementů jsou uloženy v tabulce diffservmultifieldclfrtable s OID 1.3.6.1.2.1.97.1.2.6. Po klasifikaci zpravidla následuje měření příslušné části provozu. Je to důležité z hlediska ochrany směrovače nebo části sítě před zahlcením. Pro měření jsou běžně využívány algoritmy založené na mechanismu Token-Bucket. U těchto mechanismů se zpravidla měří dodržení dlouhodobé průměrné rychlosti s určitou tolerovanou mírou proměnlivosti okamžité rychlosti. V rámci DiffServ-MIB jsou konkrétní instance měřičů dostupné v tabulce diffservmetertable, OID 1.3.6.1.2.1.97.1.3.2. Každý záznam v tabulce obsahuje tři ukazatele. První ukazatel označuje funkční element, kam bude veden provoz, který nepřekročí měřenou rychlost. Druhý ukazatel označuje funkční element, který zpracuje provoz překračující rychlost. Třetí ukazatel označuje parametrický element, který specifikuje parametry pro měření. Parametrické elementy pro měřiče jsou uloženy v samostatné tabulce s názvem diffservtbparamtable a s OID 1.3.6.1.2.1.97.1.4.2. Tyto elementy obsahují parametry pro měřič využívající mechanismus Token-Bucket. Po roztřídění paketů podle informací v hlavičce a podle aktuální rychlosti je možné provádět požadované zpracování paketů. Pro popis zpracování se využívají strukturální elementy, které jsou uloženy v tabulce diffservactiontable. Tabulka má OID 1.3.6.1.2.1.97.1.5.2 a shrnuje všechny strukturální elementy prvků pro zpracování paketů. Jednotlivé elementy mohou být i řetězeny za sebou pomocí pole diffservactionnext, které obsahuje ukazatel RowPointer na následující element. Protože tabulka diffservactiontable obsahuje pouze strukturální elementy, upřesnění jejich funkcí se provádí pomocí parametrických elementů. Konkrétní parametrické elementy jsou uvedeny v tabulkách diffservcountacttable a diffservdscpmarkacttable. Tabulka diffservcountacttable (OID 1.3.6.1.2.1.97.1.5.5) obsahuje položky popisující čítače. Čítače jsou důležité pro generování statistických informací o zpracovávaném provozu. Tyto informace mohou být využity pro účtování, pro analýzu provozu a příp. pro analýzu nastavení funkcí spojených se zpracováním provozu. Další tabulkou parametrických elementů je diffserv- DscpMarkActTable (OID 1.3.6.1.2.1.97.1.5.3), které zajišťují nastavení požadované hodnoty DSCP. V případě DiffServ-MIB jsou zahazovače řazeny mezi prvky zpracování paketů. Absolutní zahazovač je realizován jako speciální případ algoritmického zahazovače, který zahodí každý přijatý paket. Zahazovače jsou shrnuty do zvláštní tabulky diffservalgdroptable s OID 1.3.6.1.2.1.97.1.6.2. Základní funkcí algoritmického zahazovače je identifikace algoritmu pro rozhodování o zahození, zahození paketu a počítání zahozených paketů. V případě zahazování paketů při vstupu nebo při odchodu z fronty nebo u náhodného zahazování musí být mechanismus provázán se sledovanou frontou. Provázanost je zajištěna ukazatelem v poli diffservalgdropqmeasure. U absolutního zahazovače taková provázanost není nutná. Náhodné zahazování spojené s aktivní správou front vyžaduje další upřesňující parametry. Pro náhodné zahazovače byla vyhrazena samostatná tabulka diffservrandomdroptable (OID 1.3.6.1.2.1.97.1.6.4). 16

U náhodných zahazovačů je pravděpodobnost zahození nejčastěji přímo úměrná průměrné délce fronty, viz Obr. 5.2. Často platí, že P min = 0, tj. náhodné zahazování začíná až od prahové hodnoty Q min. Od bodu [Q max,p max ] pravděpodobnost zahození začíná prudce narůstat a nad hodnotou průměrné délky Q clip budou zahozeny všechny pakety. Obr. 5.2 Obecná závislost pravděpodobnosti zahození na průměrné délce fronty Každý algoritmický zahazovač je provázán s frontou a využití ukazatelů umožňuje navázat několik zahazovačů na jednu frontu. Takové řešení může mít význam v případě složitějších mechanismů řízeného zacházení s pakety. Následující modul v cestě zpracování paketů představují bloky správy front a plánování odesílání. Tyto bloky jsou modelovány pomocí elementárních prvků, ze kterých je pak možné sestavit i značně komplexní funkční jednotky. Základem systému front jsou zde fronty typu FIFO. Všechny instance FIFO front jsou řazeny do tabulky diffservqtable s OID 1.3.6.1.2.1.97.1.7.2. S touto tabulkou úzce souvisí tabulka diffservschedulertable (OID 1.3.6.1.2.1.97.1.8.2), která obsahuje plánovače. Právě tyto plánovače sdružují jednoduché FIFO fronty do komplexnějšího celku. Podobně jako v případě jiných funkčních elementů i fronty jsou zapojeny do cesty zpracování provozu pomocí ukazatelů. Přitom více nadřazených funkčních elementů může využívat jednu frontu. Častým požadavkem při zpracování tříd provozu je zajistit určitou minimální či maximální šířku pásma nebo prioritu pro obsluhu fronty. Funkčně takový požadavek zajišťuje plánovač, ale samotné parametry jsou přiřazeny přímo frontě. Tyto parametry jsou uloženy v parametrických elementech, které jsou sdruženy v tabulkách diffservminratetable resp. diffserv- MaxRateTable. Parametry uvedené v tabulkách diffservminratetable a diffservmaxratetable jsou využívány instancemi plánovačů. Tyto instance jsou shrnuty do tabulky diffservschedulertable (OID 1.3.6.1.2.1.97.1.8.2). Struktura plánovače umožňuje příjem paketů z fronty nebo z nadřazeného plánovače. U složitější struktury jsou plánovače provázány pomocí ukazatelů. Implementace kombinované podpory zacházení EF a AF vyžaduje použití dvou plánovačů odesílání. Plánovač pro zacházení AF bude pracovat na základě stanovených rychlostí a výstup z tohoto plánovače je veden do druhého stupně, který bude pracovat na základě priorit, viz Obr. 5.3. 17

Obr. 5.3 Kombinované plánování podle priorit a podle rychlosti 5.1.2 Modelu mechanismu DiffServ Modelu mechanismu DiffServ využívající 3 třídy AF a jednu třídu EF je uveden na Obr. 5.4. Obr. 5.4 Model mechanismu DiffServ na vstupním rozhraní Vstupní rozhraní modelu tvoří vstup do celé DiffServ domény, a proto musí zajistit úplné zpracování přicházejících paketů, tj. klasifikaci, měření provozu a zajištění, aby vyhovující datový tok i provoz překračující sjednané parametry byly zpracovány adekvátně. Pro třídy AF to znamená, že nevyhovující pakety budou označeny odpovídající značkou DSCP a u třídy EF jsou nevyhovující pakety zahozeny. Po zpracování jsou pakety předávány směrovacímu subsystému. 18

Směrovací subsystému dopraví pakety na odpovídající odchozí rozhraní. Toto rozhraní obsahuje další funkční bloky mechanismu DiffServ. Výchozím bodem bude opět tabulka diffserv- DataPathTable. Dá se předpokládat, že přicházející pakety jsou již klasifikovány. Pokud tomu tak není, je třeba provádět klasifikaci na výstupním rozhraní. Úvahy při návrhu a realizaci klasifikátoru a čítačů jsou obdobné jako v případě klasifikátoru na vstupním rozhraní. Systém front může být vybaven mechanismem pro aktivní řízení, jako např. mechanismem Random Early Detection. Proto obecně pro každou třídu a její podtřídy může existovat algoritmický zahazovač. Obsluha front určených pro třídy AF využívá mechanismus, který nezachovává práci, tj. nejčastěji WFQ nebo WRR. Tyto mechanismy garantují dodržení minimální specifikované šířky pásma a podle možností se snaží využít i zbytek volné šířky pásma. Model výstupního rozhraní provádějícího třídění paketů třídy AF a následné měření je znázorněn na Obr. 5.5. Pokud výstupní rozhraní může zpracovávat pakety podle již nastavených hodnot DSCP, lze z modelu vynechat funkční elementy měřiče a značkovače. Obr. 5.5 Model výstupního rozhraní provádějícího třídění paketů třídy AF a měření provozu Model výstupního rozhraní provádějícího třídění a měření paketů třídy EF je znázorněn na Obr. 5.6. Na obrázku je vidět, že měřič je dvouúrovňový a pakety, které překročí sjednanou rychlost, jsou zahozeny. Plánování odesílání musí probíhat na základě priority přidělené dané frontě. Pokud provoz už byl jednou zpracován důvěryhodným prvkem sítě, lze z modelu vypustit měřič, zahazovač i značkovač paketů. Obr. 5.6 Model výstupního rozhraní provádějícího třídění a měření paketů třídy EF Využití prioritní fronty v modelu zajišťuje minimální kolísání zpoždění. V případě, že je definováno několik tříd se zacházením EF, je pro každou třídu vyhrazena samostatná fronta. 19

6 METODA ZÍSKÁNÍ INFORMACÍ O NASTAVENÍ TECHNOLOGIE DIFFSERV 6.1 KLÍČOVÉ POŽADAVKY NA SPOLUPRÁCI S MECHANISMEM DIFFSERV Před samotným návrhem metody pro získání parametrů mechanismu DiffServ bylo definováno několik základních požadavků a omezujících faktorů: Primárním požadavkem je, aby nová metoda umožnila síťovým službám spolupráci při nastavení úrovně kvality služeb, která bude poskytnuta generovanému provozu. Protože implementace mechanismu DiffServ je velice rozšířená a protože fyzická implementace je velice různorodá, nová metoda by měla zasahovat do původního mechanismu minimálním, nejlépe žádným způsobem. Nová metoda má být nezávislá na fyzické implementaci funkčních elementů technologie DiffServ. Vzhledem k velkému počtu výrobců a produktů podmínit správné chování nového mechanismu implementací přídavných funkcí do firmwaru zařízení je nereálné. Provázanost nové metody se stávajícími mechanismy má být řešena pomocí standardních prostředků, které jsou definovány ve specifikaci mechanismu DiffServ či pomocí dalších standardizovaných prostředků běžně dostupných v aktivních síťových prvcích. Nová rozšířená metoda nemá ovlivnit zpracování paketů prováděné tradičním způsobem. Implementace má být jednoduchá a efektivní, která zbytečně nezatěžuje síťové komponenty ani komunikační linky. 6.2 ANALÝZA MOŽNOSTÍ SPOLUPRÁCE S MECHANISMEM DIFFSERV Základním požadavkem na hledanou metodu je, aby síťová služba mohla spolupracovat s komponentami mechanismu DiffServ. Problémem je, že standardně se neprovádí žádná výměna řídicích informací mezi hraničními a páteřními směrovači. Návrh a především implementace nového protokolu by byla velice obtížná. Naštěstí byla nalezena vhodná alternativa, která umožňuje řešit tuto situaci. Touto možností je právě již dříve popsaný protokol SNMP. Volba protokolu SNMP nabízí řešení nejen pro komunikaci mezi koncovým uzlem a hraničním směrovačem, ale také nám zajišťuje přístup ke konfiguračním parametrům mechanismu diferencovaných služeb. Správné a efektivní nasazení protokolu SNMP pro naše účely však vyžaduje mírné úpravy ve způsobu jeho použití. Systém vzdálené správy pomocí SNMP je určen pro centralizované řízení a monitorování síťových prvků. Centrálním prvkem je manažer, který pravidelně dotazuje agenty ve spravovaných síťových prvcích, či zpracovává trap zprávy V našem případě je situace mírně odlišná, protože centrálním prvkem se stane hraniční směrovač, příp. jeho agent a budou se ho dotazovat manažery implementované v koncových stanicích [99], [124]. Pro náš účel může být manažerská aplikace mnohem jednodušší a ani podpora větví v MIB nemusí být tak rozsáhlá. Důležitou vlastností je, že koncová stanice vyžaduje pouze funkce pro získání dat z databáze MIB, tj. pouze funkce čtení. Stanice pracuje pouze s některými informacemi MIB, a proto není nutné implementovat rozsáhlou databázi řídicích informací. Z praktického hlediska ani implementace DiffServ-MIB nemusí být úplná, protože úlohou stanice není kompletní ovládání mechanismu DiffServ, ale pouze získání některých vybraných údajů. Důležitou částí návrhu je výběr sady informací, které budou získány od hraničního směrovače. Můžeme zde rozlišit dvě možnosti podle toho, jestli stanici bude stačit základní sada informací, nebo bude potřebovat ucelený pohled na mechanismus DiffServ. Přitom se dá předpokládat, že často bude stačit základní sada. Zmíněné dvě možnosti souvisejí s modelem řízení mechanismu DiffServ. Podle tohoto modelu jsou jednotlivé funkční elementy mechanismu implementovány do vstupního a výstupního modulu 20

směrovačů. K získání základní sady parametrů budou stačit informace o vstupních rozhraních. Na základě těchto informací může stanice získat obraz o tom, jakým způsobem probíhá klasifikace příchozího provozu a podle jakých parametrů je roztříděný provoz měřen. Po získání informací o pravidlech třídění a o parametrech měření lze detekovat hodnotu DSCP, která se přiděluje jednotlivým třídám. 7 NÁVRH SYSTÉMU PRO ZPŘÍSTUPNĚNÍ INFORMACÍ O TECHNOLOGII DIFFSERV UŽIVATELSKÝM APLIKACÍM Celý systém řízení kvality služeb [97] spolupracující s mechanismem DiffServ je vidět na Obr. 7.1. Z obrázku je zřejmé, že detekce konfigurace je pouze prvním krokem. Aby aplikace mohla využít tyto informace, je nutné je zpracovat a prezentovat uživatelské službě v dostatečně jednoduché formě. Tuto úlohu má zajistit operační systém, přesněji samostatná služba provozovaná v rámci operačního systému. Obr. 7.1 Blokový diagram systému řízení kvality služeb spolupracujícího s mechanismem DiffServ Tato služba poskytuje aplikacím informaci o třídách, které jsou podporovány hraničním směšovačem, a dále udává informace, podle kterých aplikace může provést výběr. O výsledku výběru pak aplikace informuje operační systém, který následně zajišťuje nastavení požadované hodnoty DSCP. Pakety pak budou odcházet z koncové stanice s identifikací zvolené třídy. Po detekci konfiguračních parametrů mechanismu DiffServ je nutné tyto informace zpracovat do přehledné formy. Základní parametry, podle kterých aplikace může vybrat nejvhodnější třídu pro svá data, jsou: minimální garantovaná rychlost obsluhy třídy, maximální povolená rychlost obsluhy třídy, zacházení s pakety překračující maximální rychlost, priorita třídy, hodnota DSCP. 21

Zpracováním získaných konfiguračních údajů mechanismu DiffServ operační systém identifikuje dostupné třídy pomocí jejich DSCP a definuje příslušné hodnoty výše popsaných parametrů. Před zahájením síťové komunikace je zpravidla nutné vytvořit příslušný socket. Sockety vytvářejí operační systém na žádost aplikace. Když v rámci žádosti o vytvoření socketu operační systém získá od aplikace klíčové informace o spojení, může filtrovat získaná třídicí pravidla a aplikaci pak může poskytnout jen ta, která jsou pro dané identifikátory spojení opravdu využitelná. Navržený systém předpokládá dva typy dotazů od síťové aplikace na dostupné třídy. Prvním typem je specifický dotaz, při kterém aplikace uvádí všech pět parametrů socketu a podle těchto informací operační systém zpřístupní filtrovaný seznam tříd, do kterých lze daný provoz řadit. Druhou možností je univerzální dotaz, kdy aplikace zjišťuje možnosti komunikace bez udání bližších informací o cílové stanici. V tomto případě operační systém bude filtrovat seznam dostupných tříd pouze na základě své IP adresy, tj. IP adresy odesílatele. Takový seznam může být užitečný např. tehdy, když má aplikace několik alternativních míst pro navázání spojení. Z charakteru uvedených dvou typů dotazů vyplývá, že univerzální dotaz se používá při rozhodování o výběru protější stanice. Oproti tomu specifický dotaz je určen pro využití během zahajování komunikace, příp. i pro aktivní komunikaci. 7.1 PROCES VÝBĚRU TŘÍDY Zpřístupnění seznamu tříd pro aplikaci lze inicializovat dvěma způsoby. Pro přizpůsobení navržené metody starším aplikacím je určeno manuální nastavení, které je vyvoláno přímo uživatelem. Pomocí tohoto postupu uživatel prostřednictvím jednoduchého řídicího programu může poslat univerzální dotaz. Odpovědí na tento dotaz bude seznam všech podporovaných tříd doplněný o informace spojené s parametry klasifikace. Tento seznam už bude filtrován na základě IP adresy dané stanice. Po vyhodnocení zaslaných informací musí proběhnout výběr nejvhodnější třídy. Výsledek výběru pak uživatel potvrdí pomocí hodnoty DSCP zvolené třídy. Pro nové aplikace může proces výběru probíhat i automatizovaně využitím nového aplikačního programového rozhraní (API), pomocí kterého je možné komunikovat s příslušnou službou. Využitím tohoto API může aplikace kdykoliv poslat dotaz na dostupné třídy a operační systém mu vrátí příslušný seznam. Dotazy v tomto případě budou častěji specifické, kdy před samotným vytvářením socketu aplikace navíc může zjistit seznam dostupných tříd a může zvolit nejvhodnější z nich. Protože u tohoto typu dotazu jsou už známé všechny parametry socketu, je možné provést podrobnější filtrování seznamu tříd. 7.2 ZPŮSOBY NASTAVENÍ DSCP Po fázi výběru třídy může následovat nastavení DSCP. Zde také máme k dispozici dvě možnosti podle toho, o jakou aplikaci se jedná. V případě, že aplikace provedla zjišťování dostupných tříd pomocí API služby, může pak v rámci vytvoření socketu zvolit vybranou hodnotu DSCP. Pro toto nastavení lze využívat standardní funkce operačního systému. U starších aplikací, které nepředpokládaly využití podobného systému, musí výběr třídy provést uživatel manuálně. Protože síťová komunikace je řízena přímo z aplikace, není zde už možné dodatečně implementovat další podpůrné mechanismy. Řešením je zachytit přenášené pakety a modifikovat obsah pole DSCP ještě ve stanici [125]. Jednoduchým nástrojem pro takové zachytávání může být služba, která běží na pozadí a automaticky vyhodnocuje veškeré pakety, které jsou předány z protokolové sady TCP/IP operačního systému do ovladače Network Driver Interface Specification (NDIS). U rámců zachycených na této úrovni komunikace je možné obnovit hlavičku protokolu IP, příp. i TCP či UDP a na základě informací v těchto hlavičkách lze identifikovat datové toky, pro které je třeba provést dodatečné nastavení hodnoty DSCP. Popsaná metoda je označována anglickým názvem NDIS hooking a její funkce je znázorněna na obr. 7.2. 22

Obr. 7.2 Znázornění metody NDIS - hooking 8 ŘÍZENÍ KVALITY SLUŽEB V BEZDRÁTOVÝCH SÍTÍCH 8.1 ZÁKLADNÍ MECHANISMY ŘÍZENÍ PŘÍSTUPU K MÉDIU V BEZDRÁTOVÝCH LOKÁLNÍCH SÍTÍCH Komunikace v sítích WLAN je založena na náhodné přístupové metodě vícenásobného přístupu s detekcí nosné (Carrier Sense Multiple Access CSMA). Standardy technologií řady 802.11 označují přístupové metody pojmem koordinační funkce. Specifikace 802.11 a/b/g definují dva typy koordinačních funkcí, distribuované a centralizované. Distribuováná koordinační funkce (Distributed Coordination Function DCF) je založena na soutěžení. Centralizovaná koordinační funkce (Point Coordiantion Fuction PCF) představuje přístupovou metodu bez soutěžení, kdy přístupový bod během intervalu bez soutěžení (Contention Free Period CFP) pravidelně dotazuje registrované stanice a zjišťuje, zda mají data k vysílání. V komunikaci přes síť WLAN hrají důležitou roli čekací doby označené pojmem mezirámcová mezera. Jak naznačuje i název, jedná se o povinné čekací doby před zahájením pokusu o vyslání nového rámce. Délka této čekací doby ovlivňuje pravděpodobnost toho, že stanice získá přístup k médiu, a proto čekací doba může zajistit prioritní řízení přístupu. V základním standardu se však toto prioritní rozdělení provozu využívá pouze pro oddělení řídicích a uživatelských dat. 8.2 POKROČILÉ MECHANISMY ZAJIŠTĚNÍ KVALITY SLUŽEB V BEZDRÁTOVÝCH LOKÁLNÍCH SÍTÍCH Nedostatečná podpora zajištění kvality služeb v sítích WLAN značně omezovala a omezuje využitelnost této síťové technologie v podmínkách, kde se využívají služby pracující v reálném čase. Silný tlak ze strany uživatelů přiměl výrobce a standardizační organizaci IEEE k tomu, aby zajištění kvality služeb v technologiích WLAN věnovali větší pozornost. Výsledkem těchto prací byl postupný vývoj standardu 802.11e [41], který rozšiřuje původní přístupové metody WLAN o další mechanismy s propracovanější podporou zajištění QoS. Standard 802.11e definuje další koordinační funkce označené jako rozšířená distribuovaná koordinační funkce (Enhanced Distributed Coordination Function EDCF) a hybridní koordinační funkce (Hybrid Coordination Function HCF). EDCF může pracovat pouze během CP. Metoda HCF pracuje v obou režimech, přičemž během CP pro svou funkci využívá metody EDCF. Na základě uvedených koordinačních funkcí byl definován rozšířený distribuovaný přístup ke kanálu (Ehanced Distributed Channel Access EDCA) a přístup ke kanálu řízený pomocí HCF (HCF Controlled Channel Access HCCA). 23

8.2.1 Rozšířený distribuovaný přístup ke kanálu (EDCA) Podpora QoS v rámci tohoto přístupového mechanismu je zajištěna na základě kategorií přístupu (Access Category AC). Každá stanice může mít až 4 kategorie přístupu značené jako AC_BK (přenos na pozadí), AC_BE (přenos typu best-effort), AC_VI (přenos videa) a AC_VO (přenos hlasu). Rámce z jednotlivých kategorií přístupu soutěží o tzv. příležitost přenosu (Transmission Oportunity TXOP), což je časový interval, ve kterém bude možné přenést rámec. Důležitou vlastností TXOP je, že jeho trvání je předem časově omezeno, což eliminuje synchronizační problémy způsobené neznámou délkou rámce. Podle 802.11e má každá kategorie přístupu vlastní mezirámcovou mezeru, kterou může podle potřeby nastavit administrátor. Kromě mezirámcové mezery je možné pro každou kategorii přístupu zvlášť nastavit hodnoty pro parametry okna soutěžení CW min [AC], CW max [AC] a AF[AC]. Při nastavení velikosti okna soutěžení CW platí, že pro přístupovou kategorii s vyšší prioritou je třeba zvolit kratší okno soutěžení, aby pravděpodobnost získání přístupu byla větší. V případě, že aplikace vygeneruje data k odeslání a přitom fronty jednotlivých kategorií přístupu jsou prázdné a přenosové médium je rovněž volné, stanice může bez dalšího čekání odeslat rámec. Pokud médium není volné, rámec musí být vložen do odpovídající fronty a stanice musí čekat na uvolnění média. Po uvolnění média stanice musí čekat interval AIFS podle příslušné kategorie přístupu a následně může začít soutěžení o přístup k médiu, tj. vygenerování náhodného čísla z rozsahu [1, CW[AC]], postupné odpočítávání čekacích intervalů atd., viz Obr. 8.1. Obr. 8.1 Soutěžení o přístup v rámci mechanismu EDCA 8.2.2 Přístup ke kanálu řízený pomocí HCF (HCCA). Mechanismus HCCA vychází z centralizované koordinační funkce PCF, ale nabízí mnohem propracovanější podporu pro zajištění kvality služeb. Řízení přístupu řeší centrální prvek označený jako hybridní koordinátor HC. Běžně se jedná o přístupový bod podporující standard 802.11e. Hlavní funkcí HC je přidělování příležitostí přenosu TXOP kategoriím přístupu. HCCA může zaručit absolutní garanci doby přenosu či zpoždění. Je to řešeno vyšší prioritou HCCA a možností pracovat jak během intervalu bez soutěžení CFP, tak i během intervalu soutěžení CP. Ke správné funkci mechanismu HCCA už nestačí jednoduchá registrace stanic u koordinátora. Stanice musí konkrétně specifikovat své požadavky na síťové prostředky, které jsou pak vyhodnoceny HC a schváleny, příp. odmítnuty. Na základě takto sjednaných parametrů pak HC přiděluje stanicím TXOP o dostačující délce a počtu. 8.3 MOŽNOSTI VYUŽÍVÁNÍ SYSTÉMU ŘÍZENÍ KVALITY SLUŽEB SPOLUPRACUJÍCÍ S MECHANISMEM DIFFSERV Popisovaný systém řízení kvality služeb pracuje s IP diagramy, tj. na síťové vrstvě. Technologie IEEE řady 802 jsou určeny pro linkovou vrstvu. Konkrétně to znamená, že jednotlivé mechanismy mohou pracovat zcela nezávisle, ale samozřejmě lepší výsledky jsou dosaženy při jejich spolupráci. Ke spolupráci přispívá i skutečnost, že lze nalézt řadu podobností mezi mechanismem DiffServ a možností zajištění kvality služeb v technologii 802.11e. 24

V obou případech je provoz řazen do několika kategorií přístupu, resp. tříd, a každé třídě je garantován definovaný způsob zacházení. Nastavení priority u bezdrátových technologií se provádí volbou čekacího intervalu AIFS(x) přístupové kategorie a velikostí okna pro výpočet náhodné čekací doby. Vzájemná priorita jednotlivých přístupových kategorií tak závisí na rozdílu čekacích intervalů AIFS(y) AIFS(x) a na poměru velikostí oken soutěžení, jak je vidět na Obr. 8.2. Obr. 8.2 Příklad soutěžení dvou přístupových kategorií V případě technologie DiffServ jsou pro zajištění odlišného zacházení třídám přiřazeny různě velké části celkové dostupné šířky pásma. Část šířky pásma je přitom ponechána pro nezatříděný provoz, příp. pro provoz, který přesahuje minimální garantovanou rychlost jednotlivých tříd. Při porovnání obou metod je vidět, že rozdělení síťových prostředků je řešeno kombinací absolutní garance a z rozdělení zdrojů na základě soutěžení. Odvození konkrétních analytických vztahů lze nalézt např. v [42] až [45]. Z hlediska využití navrženého systému řízení kvality služeb spolupracujícího s mechanismem DiffServ je bezdrátová síťová technologie zcela transparentní. Stanice může detekovat konfigurační parametry mechanismu DiffServ v hraničním směrovači a může odpovídajícím způsobem nastavovat hodnoty DSCP pro odchozí pakety. Tím je zajištěno diferencované zacházení s pakety v páteřní síti DiffServ domény. Aby bylo označeným datagramům zajištěno řízené zacházení i v přístupové síti, tj. na trase mezi stanicí a hraničním směrovačem, která je v našem případě řešena bezdrátovou síťovou technologií, je nutné vyřešit mapování hodnot DSCP na různé přístupové kategorie. Konkrétní parametry přístupových kategorií rozesílá stanicím přístupový bod. Tyto údaje jsou proto dostupné v ovladači bezdrátové síťové karty. Jednoznačnému překladu hodnot DSCP na přístupové kategorie brání skutečnost, že v obou případech se jedná o manuální volbu parametrů, které odpovídají subjektivním preferencím organizace. Mezi kategoriemi přístupu definovanými v 802.11e a mezi standardně definovanými třídami mechanismu DiffServ je však docela blízká analogie. Čtyři kategorie přístupu: přenos videa, přenos hlasu, přenos typu best-effort a přenos na pozadí často odpovídají třídám mechanismu DiffServ, jako např.: aplikace pracující v reálném čase (VoIP), provoz kritický z hlediska chodu organizace (business), běžný firemní síťový provoz (Internet), obyčejný síťový provoz (best-effort). Kategorie přístupu pro přenos hlasu ve velké míře odpovídá požadavkům na třídu aplikací pracujících v reálném čase. Podle skutečných požadavků lze využít kategorii přístupu pro přenos videa jak pro aplikace pracující v reálném čase, tak i pro aplikace pracující s kritickými daty. Běžný firemní provoz lze mapovat do přístupové kategorie best-effort, pokud je ostatní, např. privátní provoz mapován do přístupové kategorie pracující na pozadí. 25