Optimalizácia sieťovej prevádzky

Zadavaci list

Úvod

Quality of Service (QoS^?), alebo v slovenčine kvalita služieb odkazuje na schopnosť siete ponúknuť lepšiu úroveň služieb vybraným sieťovým prevádzkam nad rozličnými technológiami, vrátane Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET a IP-routovanými sieťami, ktoré môžu využívať akúkoľvek z vymenovaných technológií. Primárnym cieľom QoS^? je poskytnúť prioritu vrátane priradenej čírky pásma, kotrolu kolísania oneskorenia a latencie (ktorá je potrebná pre niektoré real-time a interaktívne prevádzky) a zlepšenie stratových charakteristík. Taktiež veľmi dôležitým je zaistenie, aby prioritizáciou jedného alebo viacerých tokov nespôsobí zlyhanie iných tokov.

Tok je definovaný ako množina IP paketov prechádzajúcich pozorovacím bodom v počítačovej sieti počas určitého časového intervalu. Všetky pakety prislúchajúce k určitému toku majú množinu spoločných vlastností. Vlastnosti sú definované nasledovne:

1. Jeden alebo viac polí hlavičky paketu (napr. cieľová IP adresa), transportnej hlavičky (napr. číslo cieľového portu), alebo aplikačnej hlavičky (napr. polia RTP hlavičky)
2. Jedna alebo viac charakteristík samotného paketu. (napr. počet MPLS značiek)
3. Jeden alebo viac charakteristík derivovaných zo spracovania paketu (napr. adresa nasledujúceho smerovača, výstupné rozhranie)

QoS^? umožňuje poskytnúť lepšie služby konkrétnym tokom. To môže byť docielené zvýšenám priority pre daný tok alebo obmedzením priority pre iný tok. Pri použití nástrojov pre správu preťaženia je cieľom zvýšiť prioritu toku frontovaním a obsluhou front rozdielnymi spôsobmi. Nástroje na správu preťaženia sa používaju na predchádzanie preťaženiam tým, že zvýšenie priority sa docieli zahadzovaním paketov z tokov s nižšou prioritov pred paketmi z tokov s vyššou prioritou. Policing a shaping poskytujú prioritu tokom obmedzením priepustnosti iných tokov. nástroje pre efektívnosť linky obmedzujú veľké toky a preferujú malé toky.

Internet pri svojom prvotnom rozvoji, pred mnohými rokmi, neposkytoval možnosť garancie QoS^? z dôvodu obmedzení vo výpočtovom výkone smerovačov. Z tohto dôvodu bežal v základnej úrovni QoS^?, alebo v režime best effort. V tejto úrovni sa nachádzali štyri "Type of Service" . Každá správa obsahovala tri "Precedence" bity, ktoré sa ignorovali. Neskôr sa tieto bity predefinovali na DiffServ^? Code Points (DSCP) a sú prevažne využívané v rovnocenných spojeniach v modernom internete.

Ak sa pozrieme na packet-switched siete, tak QoS^? je ovplyvnená rôznými faktormi, ktoré môžeme rozdeliť na:

1. ľudské
2. technické

• Ľudské faktory zahŕňajú: stabilnosť služby, jej dostupnosť, oneskorenia, informacie pre používateľa.
• Technické fakory zahŕňajú: spoľahlivosť, rozširiteľnosť, účinnosť, udržovateľnosť, Stupeň/Kvalita Služieb, ...

Pri ceste od zdroja k cieľu sa paketom môže stať veľa vecí, ktoré vyústia do nasledujúcich problémov ako pre odosielateľa tak i pre príjmateľa:

• Zahodené pakety : Router môže zlyhat pri doručení, "zahodí" pakety ak prichádzajú keď je zásobník už plný. Niekdy žiaden, alebo i všetky možu byť odhodené, v závislosti na stave siete. Nie je možné ovplyvniť oneskorenia v celkovom prenose.
• Oneskorenie: Môže sa stať, že doručenie paketu zaberie dlhý čas, pretože sa zdržal v dlhých frontách, alebo si vyžiadal kratšiu priamu cestu aby sa vyhol preťaženiu. V niektorých prípadoch, nadmerné oneskorenie môže vytvoriť i aplikácia, ako VoIP^? (Voice over IP)
• Kolísanie oneskorenia : Pakety zo zdroja môžu dosiahnúť cieľ s rôznymi oneskoreniami. Veľkosť oneskorenia závisí od pozície vo fronte smerovača spolu s trasou medzi zdrojom a cieľom, ktorá sa môže nepredvídateľne meniť. Tieto obmeny v oneskorení sú známe ako kolísanie oneskorenia a vážne ovplyvňujú kvalitu prenášaného audio a/alebo video signálu.
• Doručenie mimo poradia : Keď je množina príbuzných paketov smerovaná internetom, iné pakety sa môžu poslať po iných cestách, s iným výsledným oneskorením. Výsledkom tohto je, že pakety prichádzajú v odlišnom poradí ako boli poslané. Tento problém si vyžaduje špeciálnu vlastnosť protokolu (izochrónnosť) pre preusporiadanie neusporiadaných paketov po dosiahnutí cieľa. Preusporiadanie je najmä dôležité pre video a VoIP^? prenos, kde je kvalita dramaticky ovplyvnená oboma oneskoreniami a nedostatkom izochrónnosti.
• Chyba : Niekdy sú pakety poslané zlým smerom a chýbajú, spojené alebo poškodené počas cesty. Prijímač musí tieto nedostatky odkryť a takisto ako keď bol paket odhodený, musí požiadať odosielateľa o jeho opakovanie.

Bližšia špecifikácia zadania

Práca sa zaoberá možnosťami implementácie kvality služieb (QoS^?) na pomalých linkách ako sú napríklad sériové linky za pomoci nástroja, vyvíjaného pri laboratóriu počítačových sietí na FEI TU v Košiciach, Basicmeter. Cieľom práce je navrhnúť model aplikácie, ktorá by na jednej sériovej linke medzi dvoma smerovačmi od firmy Cisco na základe meraní danej linky, získaných z nástroja Basicmeter navrhla a implementovala nástroje QoS^? pre optimálne využitie tejto linky.

Analýza problematiky

Metódy implementácie QoS^?

V zásade rozlišujeme tri metódy implementácie Quality of Service v paketových sieťach. A to :

• Best-Effort - Internet v jeho počiatku, bol navrhnutý pre Best-Effort systém doručovania. Čiže bez garancie doručenia paketov. Aj v dnešnej dobe Internetu je tento systém doručovania najrozšírenejší.
• Model Integrated Services - Uvedený ako náhrada pre Best-Effort doručovanie. Funguje tak, že rezervuje nejakú časť sieťových zdrojov pre aplikácie, ktoré potrebujú garanciu šírky pásma a oneskorenia. Model Intserv (Integrated Services) očakáva, že aplikácie budú svoje požiadavky sieti signalizovať. Na to sa využíva protokol Resource Reservation Protocol (RSVP), ktorý signalizuje QoS^? požiadavky sieti.
• Model Differentiated Services – Bol vytvorený pre poskytnutie väčšej škálovateľnosti pri poskytovaní QoS^? IP paketom. Hlavným rozdielom je, že sieť rozozná paket (nie je potreba signalizácie) a poskytne mu zodpovedajúce služby alebo starostlivosť. Dnešné IP siete môžu použiť všetky tri modely súčasne.

IntServ^? Model

Internet Engineering Task Force (IETF) je organizácia zodpovedná za štandardizáciu protokolov a sieťových architektúr ako ich poznáme z dnešného internetu. IETF je tu preto aby vytvárala štandardy, ktoré by dovoľovali interoperabilitu výrobkov rôznych výrobcov. Podobným spôsobom vznikol aj model Ingerated Services (IntServ^?, RFC1663), ktorý bol navrhnutý ako štandard spolu s Resource Reservation Protokolom (RSVP) ako prostriedkom pre signalizáciu QoS^? požiadaviek sieti.

IntServ^? model stavia na predpoklade, že sieťové zdroje ktoré sú nám k dispozícii majú byť explicitne rezervovateľné, čím sa môže zabezpečiť dostatočná kvalita tej ktorej služby. Takto každé jednotlivé spojenie alebo prúd dát dostane striktne pridelené, ktoré z dostupných zdrojov môže použiť. Preto musí každý smerovač na ceste paketu uchovávať stavové informácie daných tokov a taktiež rozhodovať ktoré dátové toky môžu využiť ktoré QoS^? sieťové zdroje. Toto sa deje práve s použitím protokolu RSVP.

Stavebné bloky IntServ^? modelu sú:

• Rezervácia zdrojov (Resource Reservation) – používa sa na identifikáciu aplikácie (prúdu dát) a signalizuje do siete požiadavky, či je dosť pre ňu dostatok sieťových zdrojov. Rezervácia je implementovaná použitím RSVP.
• Call Admission Control (CAC) – používa sa na určenie, či daná aplikácia (prúd dát) môže dostať pridelené žiadané zdroje. Implementácia je buď lokálna na smerovačoch alebo je centralizovaná na centrálnom serveri. Protokol používaný pre centrálnu správu je tzv. COPS (Common Open Policy Service) štandardizovaný IETF v RFC 2748 a jeho použitie s RSVP je definované s RFC 2749.

DiffServ^? Model

QoS^? model podľa DiffServ^? bol vytvorený IETF a je špecifikovaný v RFC 2474. V základe pracuje presne opačne ako v prípade modelu IntServ^?. Rozdiel je v tom, že sa vopred nerezervujú žiadne sieťové zdroje ako je to v prípade IntServ^?, ale pakety sú počas svojho prenosu priraďované do prenosových tried. Prenosové triedy sú identifikované hodnotou tzv. DiffServ^? Code Point – DSCP (DSCP nahrádza IP Precedenciu v ToS^? poli IP hlavičky). Hlavným cieľom DiffServ^? modelu je poskytnúť škálovatelnosť a podobnú úroveň QoS^? v porovnaní s IntServ^? modelom, bez toho aby sa to muselo robiť na základe jednotlivých prúdov dát. Sieť jednoducho rozozná triedu (nie aplikáciu) a aplikuje vhodný PHB (per hop behavior) QoS^? mechanizmus.

PHP sú metódy diferencovania IP paketov a tieto radia IP pakety do ich zodpovedajúcich prenosových tried (CoS^? Class of Service). Z PHB hodnôt sa teda určia triedy podľa ktorých sa dané pakety potom následne spracujú a to na základe označenia v ToS^? poli (DSCP značka) IP hlavičky. Smerovač získa hodnotu CoS^? cez tabuľky v ktorých sa každej DSCP hodnote priraďuje PHB hodnota.

Pretože každej DSCP hodnote zodpovedá jedna PHB hodnota, sú tieto priradenia jednoznačné a určujú správanie sa smerovačov pri preposielaní jednotlivých IP paketov sieťou.

Tabuľka hodnôt DSCP pre DiffServ^?

DiffServ^? model popisuje služby a dovoľuje v takejto sieti použitie viacej užívateľom definovaných služieb. Tieto služby sú radené do tried. Trieda môže byť identifikovaná ako jedna aplikácia alebo, a to vo väčšine prípadov, môže byť identifikované zdrojovou alebo cieľovou IP adresou. Účelom je aby sieť rozoznala triedy bez toho aby dostávala nejaké požiadavky od aplikácií.

DS (DiffServ^?) doména pozostáva z DS hraničných uzlov a DS interných alebo vnútorných uzlov. Hraničné DS uzly prepájajú DS doménu s inými DS alebo aj nie DS doménami, kým DS vnútorné uzly sa iba pripájajú na iné DS vnútorné alebo hraničné uzly v rámci jednej domény. Tak hraničné ako aj vnútorné uzly musia byť schopné aplikovať vhodné PHB paketom založeným na DS code point, v inom prípade by mohlo nastať nepredvídateľné chovanie siete. DS hraničné uzly sa pre dáta v sieti chovajú aj ako DS ingress aj ako DS egress uzol. Sieťové pakety vstupujú do DS domény v uzle DS ingress a opúšťajú túto doménu v uzle DS egress. DS ingress uzol je zodpovedný za zabezpečenie že všetky dáta vstupujúce do DS domény budú spracované podľa tzv. Traffic Conditionig Agreement (TCA) medzi ním a druhou doménou ku ktorej je ingress uzol pripojený. Aby sa povolili služby ktoré sa tiahnu cez niekoľko DS domén v nejakom DS regióne musí hraničná DS doména vystaviť tzv. Service Level Agreement (SLA) ktorý definuje (buď explicitne alebo implicitne) TCA. TCA potom špecifikuje ako sa prenášané dáta budú spravovať na hraničných uzloch pri prechode z jednej domény do druhej.

Táto práca sa zameriava na impelementáciu QoS^? na DiffServ^? modeloch sietí.

Pre implementáciu QoS^? na sieti sa používajú tri základné kroky:

• Indentifikácia typov prevádzky a ich požiadaviek : Pozorovanie sieti kvôli určeniu typov prevádzky na sieti a následne určenie požiadaviek pre QoS^? pre rôzne typy prevádzky
• Definovane tried prevádzky: Spájanie typov prevádzky s podobnými nárokmi na QoS^? do tried. Napríklad môžu byť definované tri typy prevádzky Hlasové služby, kritická premávka a best effort.
• Definovaie QoS^? politiky: QoS^? politika spĺňa QoS^? požiadavky pre každú triedu

Prvý krok: Indentifikácia typov prevádzky a ich požiadaviek

• Určiť QoS^? problémy pre užívateľov. Merať prevádzku na sieti počas preťažení. Vykonanie hodnotenia použitia počítača na každej sieti počas vyťažených chvíľ na určenie problémov, ktoré môžu nastať resp. nastávajú.
• Určiť podnikový model a ciele a získať zoznam podnikových požiadaviek. Táto aktivita napomáha pri definovaní tried, ktoré sú potrebné a umožňuje určiť podnikové požiadavky pre každú triedu.
• Určiť úrovne služie potrebné pre rôzne druhy prevádzky v zmysle času odozvy a dostupnosti. Pri definovaní úrovne služieb je potrebné zvážiť aký dopad na podnik bude mať oneskorenie sieťových transakcií o dva alebo tri sekundy. Pridelenie úrovne služieb zahŕňa prioritu a spôsob spracovania paketu.

Druhý krok: Definovane tried prevádzky

• Hlasové služby: Absolútna priorita pre VoIP^? prevádzku.
• Mission-critical: Malá skupina lokálne definovaných kritických podnikových aplikácii.
• Transakčné: Databázový prístup, transakčné služby, interaktívna prevádzka a preferované dátové služby. V závislosti na databázovom nasadení v podniku, môže byť databáze poskytnutá veľká šírka pásma a vysoká priorita.
• Best effort: Populárne aplikácie ako e-mail a FTP by mohli každá mať vlastnú triedu. QoS^? politika môže garantovať zamestnancom menšiu šírku pásma pre používanie týchto aplikácií a menšiu prioritu.
• Scavenger: Nešpecifikovaná prevádzka je považovaná za menej ako best-effort. Scavenger aplikácie ako BitTorrent^? a iné point-to-point aplikácie sú obslúžené touto triedou.

Tretí krok: Definovaie QoS^? politiky

Definovaie QoS^? politiky zahŕňa jednu alebo viac týchot aktivít:

• Nastavenie minimálnej garancie šírky pásma
• Nastavenie maximálneho limitu šírky pásma
• Pridelenie priorít jednotlivým triedam
• Použitie QoS^? techník ako rozšírené frontovanie pre zvládnutie preťažení

• LLQ pre aplikácie v reálnom čase pre čo najmenšiu latenciu vo výstupných frontách a zabezpečenie dostatočnej šírky na výstupnej linke pre optimálny výkon. LLQ spracuváva prevádzky klasifikovanú do DiffServ^? Expedited Forwarding (EF) triedy (voice) ako prevádzku s najvyššou prioritou a ukladá ju do separovanej, striktne prioritnej fronty. Zvyšná prevádzka je spracovaná pomocou CBWFQ
• CBWFQ pre dátové aplikácie je utilizované aby poskytovalo dostatok šírky pásma a redukovalo interferencie medzi aplikáciami s vysokou a s nízkou prioritou počas preťaženia. CBWFQ spracuváva prevádzku klasifikovanú do DIffServ^? Assured Forwarding (AF1) tried (video a klasifikované dáta) a implicitná trieda pre neklasifikovanú prevádzku (best effort)
• Weighted round robin (WRR) s prioritným frontovaním (Priority queuing PQ) na Cisco Catalyst prepínačoch spracúvava prevádzku na výstupných portoch použitím DiffServ^? (DSCP je namapované na CoS^? automaticky pri vstupe), aby zabezpečilo prioritu pre prevádzku v relánom čase a predvídateľnú šírku pásma pre iné druhy prevádzky

Predchádzanie preťaženiam

Techniky pre predchádanie preťaženiam monitorujú záťaž sieťovej prevádzky v snahe predpokladať a predchádzať preťaženiam na bežných sieťových úzkych profiloch. Zahadzovanie paketov vedie k predchádzaniu preťaženia. Smerovače štandardne používajú hrubú metódu zahadzovania paketov, ktorý sa volá tail drop (zahadozvanie paketov z chvosta). Pri tail drop, pakety sú zahadzované ak sa nevmestia do vstupnej fronty, ktorá rovnako ovplyvňuje všetky druhy prevádzky, vrátane prevádzky s vysokou prioritou. Globálna synchronizácia je ďalším efektom tail drop-u a objavuje sa ako vrcholy peťaženia nasledovanými útlmom kedy prenosová linka nie je plne využitá. Globálna synchronizácia TCP hostov sa môže vyskytnúť napríklad pri zahodení všetkých paketov naraz. Globálna synchronizácia je evidntná keď viacero TCP hostov redukuje svoje prenosové rýchlosti odozvou na zahadzovanie paketov a potom zvýšením svojich transmisných rýchlostí keď sa preťaženie uvoľní. K zabráneniu zahadzovania a globálnej synchronizácie sa využíva weighted random early detection WRED. WRED spravidla zahadzuje pakety výberovo na základe IP precedencie. Pakety vyšším IP precedence číslom majú menšiu pravdepodobnosť, že budú zahodené ako pakety s nižším IP precedence číslom. Takto prevádzka s vyššou prioritou je doručená s väčšou pravdepodobnosťou ako prevádzka s nižšou prioritou.

Ako je dôležité pochopiť požiadavky sieťových aplikácii, tak isto je dôležité nepredimenzovať administratívnu politiku. Tá by mal byť proaktívna vo svojej podstate a vyžadovať čo najmenej tried kvality. Je dobrým pravidlom obmedziť počet tried pre služby na nie viac než päť. Typická sieť má tieto typy aplikácií:

• Hlasové aplikácie: VoIP^?
• Mission-critical aplikácie: Oracle, SAP
• Transakčné aplikácie: Telnet
• Best-effort aplikácie: e-mail, web

QoS^? požiadavky pre tieto aplikácie môžu byť uspokojené zopár dobre navrhnutými triedami služieb. Čím je implmentovaných viac tried pre služby n podporu administratívnej QoS^? politiky, tým komplexnejšia bude implementácia QoS^?. Komplexita taktiež sťažuje podporu a hľadanie chýb.

Taktiež je dôležité, aby triedy s najvyššou prioritou boli rezervované pre zopár vybraných aplikácií. Označenie 90% sieťovej prevádzky pre vysokú prioritu učiní väčšinu administratívnej QoS^? politiky zbytočnou.

Klasifikácia

Klasifikácia je proces indentifikácie prevádzky a kategorizácia tejto prevádzky do treid. Klasifikácia používa deskriptor prevádzky pre kategorizáciu paketu zo špeciálnej skupiny pre definovanie tohto paketu. Bežne používane deskriptory prevádzky sú

• Vstupné rozhranie
• IP precedencia
• Differentiated services code point (DSCP)
• Zdrojová alebo cieľová adresa
• Aplikácia

Po tom čo bol paket klasifikovaný alebo identifikovaný, je dostupný pre spracovanie pre QoS^? na sieti.

Použitím klasifikácie môže sieťový administrátor rozdeliť sieťovú prevádzku na niekoľko tried pre služby. Ak sú pre klasifikovanie prevádzky používané deskriptor, zdroj implicitne súhlasí s dodržaním stručných podmienok a sieť prisľúbi QoS^?. Rôzne QoS^? mechanizmy ako sú traffic policing, traffic shaping a frontové disciplíny používajú deskriptor prevádzky paketu aby zaistili príslušnosť k tej dohode.

Klasifikácia by sa mal vykonávať na okraji siete, obyčajne v rozvodnej skrini, vo vnútri IP telefónov alebo koncových bodoch siete. Cisco odporúča aby sa klasifikácia uskutočňovala tak blízko zdroja ako sa len dá.

Značkovanie paketov

Značkovanie je spojené s klasifikáciou. Značkovanie umožňuje sieťovým zariadeniam klasifikovať paket alebo rámec na okraji na základe špecifického despriptoru prevádzky. Nástroje pre QoS^? klasifikáciu kategorizujú pakety skúmajúc obsah rámca, bunky a hlavičky paketu, kde značkovacie nástroje dovoľujú QoS^? nástrojom zmeniť hlavičku paketu pre jednoduchšiu klasifikáciu. Veľa QoS^? nástrojov sa spolieha na klasifikačnú funkciu na zistenie ku ktorej prevádzke sa nástoj vzťahuje. Pre umiestnenie hlasovej a dátovej prevádzky do oddelených front, je potrebné použiť druh klasifikácie na rozlíšenie týchto dvoch typov prevádzky a umiestnenie identifikovanej prevádzky do správnej fronty. Značkovanie ponúka pre nástroje QoS^? spôsob na zmenu bitov v hlavičke paketu na indikáciu úrovne služby, ktorá by mala byť pre tento paket pridelená. Napríklad sa značkovanie môže použiť na zmenu značky v hlasových paketoch pre zabezpečenie, že klasifikačný nástroj spoľahlivo odlíši hlasový paket od dátového. Bez značkovacej vlastnosti zostáva rámece alebo paket nezmenený.

Značkovanie zahŕňa umiestnenie hodnoty do jedného malého čísla v dobre navrhnutom rámci, pakete alebo bunke hlavičky špeciálne navrhnutých pre značkovanie QoS^?. Značkovaním paketu môžu ostatné funkcie QoS^? vykonať klasifikáciu na základe označeného poľa v hlavičke. Značkovanie zjednodušuje návrh sieťových QoS^?, konfiguráciu ostatných nástrojov QoS^? a redukuje náklady potrebné pre iné nástroje QoS^? na klasifikáciu paketov

The following table illustrates the DSCP values:

Návrh riešenia

Cieľom projektu je vytvoriť aplikáciu, ktorá by na základe pasívnych hodnôt nameraných nástrojom Basicmeter vedela automaticky a kontinuálne nastaviť a aktualizovať optimálny QoS^? na jednej sériovej linke medzi smerovačmi. Pre funkčnosť aplikácie je potrebné, aby smerovače mali nakonfigurovaný a povolený vzdialený prístup. Kvôli bezpečnosti je vhodné, aby komunikácia medzi aplikáciou a smerovačmi prebiehala krypotovanou formou cez ssh. Aplikácia najprv vykoná inicializačnú konfiguráciu na smerovačoch pozostávajúcu z definovania tried pre QoS^?. Z hľadiska prenositeľnosti a čo najväčšej všeobecnosti aplikácie sa vynechá krok monitorovania sieťovej prevádzky. Návrh tried pre QoS^? bude prevzatý z odporúčaní spoločnosti cisco, ktorá upozorňuje, aby na jednotlivých zariadeniach nebolo vytváraných mnoho tried pre prevádzku. Teda na smerovači bude vytvorených 5 tried pre QoS^? s nastavenými parametrami pre kvalitu služieb, ktoré budú vychádzať z menovitej šírky pásma pre danú linku a požiadaviek pre typ služieb, ktorým má poskytovať služby. Návrh tried je nasledovný:

• Priorita 5 Hlasové služby: LLQ pre zaistenie stálej priority pre hlasové služby
• Priorita 4 Mission-critical: CBWFQ pre prioritozovanie tokov kritickej triedy.
• Priorita 3 Transakčné služby: CBWFQ pre prioritozovanie transakčných tokov .
• Priorita 2 Best-effort: CBWFQ prioritizovanie best-effort prevádzky, ktorá je pod mission-critical and hlasovými službami.
• Priority 1 Scavenger (menej ako best-effort): WRED to drop these packets whenever the network has a tendency toward congestion.

Klasifikačný mechanizmus pre zaradzovanie tokov do jednotlivých tried sa bude konať na základe značkovania paketov na okraji siete. Pakety sa budú značkovať do DSCP poľa hlavičky podľa Per-Hop Behaviour pre DiffServ^? nasledovne:

Názov triedy		Trieda PHB		DSCP hodnota
Hlasové služby		EF		101 11 0
Mission-critical		AF42		100 10 0
Transakčné služby		AF32		011 10 0
Best-effort		AF22		010 10 0
Scavenger		AF11		001 01 0

Po vytvorení tried spolu s pravidlami pre klasifikáciu paketov začne aplikácia v pravidelných intervaloch sledovať premávku zo siete. Akonáhle detekuje nový druh prevádzky, vyhodnotí akú kvalitu služieb mu priradí a na základe priradenej značky upraví značkovací mechanizmus na smerovačoch, aby značkoval pakety tohoto toku zodpovedajúcou značkou. Postupným pribúdanim tokov na linke bude potrebné prehodnotiť zaradenie tokov do jednotlivých tried. Je zrejmé, že nemožno polemizovať o zaradení napríklad hlasových služieb do inej triedy, pretože povaha tejto služby na pomalých linkách vyžaduje špeciálne zaobchádzanie. S istotou taktiež môžeme povedať, že pakety zaradené do triedy Scavenger si nemôžu nárokovať na lepšiu kvalitu služieb. Preto prehodnotenie a preradenie jednotlivých tokov medzi QoS^? triedami je možné iba medzi: Mission-critical, Transakčnou a Best-effort triedou. Zmena zaradenia príslušného toku sa vykoná zmenením značkovania jeho paketov, ktorým sa priradí nová značka a klasifikátor sa postará o preradenie daného toku resp. danej prevádzky do inej triedy.Postupom času by nasadenie QoS^? na danej linke malo konvergovať k optimálnemu nastaveniu.

Je potrebné prehodnotiť nasadenie exportéra do danej topológie. Ako exportér IPFIX záznamov by mohli fungovať oba smerovače na koncoch linky, ktoré by posielali údaje do collectora bežiaceho na samostatnom stroji. Tento model umožňuje merať a vyhodnocovať časové charakteristiky premávky. Otázkou však stále ostáva meranie časových charakteristík pre jednotlivé toky a samotné vyhodnocovanie nameraných údajov. V tomto smere by mohla napomôcť diplomová práca Michala Puchľáka, ktorá však meria časové charakteristiky iba pre celkovú prevádzku na linke. Pre potreby aplikácie je však potrebné poznať časové charakteristiky pre jednotlivé flowy.

Ďalšou možnosťou rozvoja aplikácie je implementácie techník na predchádzanie preťaženiu a konfigurácie WRED (Wighted Random Early Detection) na smerovačoch. Tento zásah si vyžiada zmenu značkovania paketov. Navrhnuté značkovanie je v súlade a podmienkami pre konfiguráciu WRED, ale triedy pre zahadzovanie paketov sú v každej triede nastavené na rovnakú hodnotu. Nastavenie hodnôt pre jednotlivé triedy a s tým súvisiaca zmena značkovania by mohla vyzerať nasldovne

Názov triedy		Trieda PHB		DSCP hodnota
Hlasové služby		EF		101 11 0
Mission-critical		AF42		100 11 0
Transakčné služby		AF32		011 10 0
Best-effort		AF22		010 01 0
Scavenger		AF11		001 01 0

Záver

Navrhovaná aplikácia by mohla priniesť zjednodušenie a automatizáciu v implementácii kvality služieb pre rôzne typy prevádzky a rôzne typy liniek. V súčasnej dobe rozmachu internetizácie a neustálom dopyte po interaktívnych sieťových službách je problematika kvality služieb hlavným bodom návrhu všetkých sietí. V nasledujúcom semestri je potrebné pristúpiť k samotnému vývoju aplikácie a testovaniu, či má navrhovaný model očakávaný prínos ku kvalite prenášaných služieb.

Zoznam použitých zdrojov

[1.] Cisco Systems Inc. Tech Notes: Implementing Quality of Service Policies with DSCP [online], Máj 2006. Dostupné na internete: < http://www.cisco.com/warp/public/105/dscpvalues.html >

[2.] SADASIVAN, G., BROWNLEE, N., CLAISE, B., QUITTEK, J.: Architecture for IP Flow Information Export, Internet Draft, IPFIX Working Group [online], September 2006. Dostupné na internete: < http://www.ietf.org/internetdrafts/draft-ietf-ipfix-architecture-12.txt >

[3.] POTOCKÝ, M.: Analýza, návrh a vlastná implementácia štandardov IPFIX a PSAMP v meracom nástroji BasicMeter. Diplomová práca. Košice: Technická Univerzita v Košiciach, Fakulta elektrotechniky a informatiky,2006. 65 s.

[4.] ROHÁĽ, O.: Vyhodnotenie a návrh optimalizácie sieťovej prevádzky použitím pasívnych meraní prevádzkových parametrov počítačových sietí. Diplomová práca. Košice: Technická Univerzita v Košiciach, Fakulta elektrotechniky a informatiky, 2007, 73 s.

[5.] HADEN, R.:Quality of Service [online], Február 2006. Dostupné na internete: < http://www.rhyshaden.com/qos.htm >

[6.] WIKIPEDIA: Quality of Service [online], September 2007. Dostupné na internete: < http://en.wikipedia.org/wiki/Quality_of_service >

[7.] SMÍTKA, P.:Qos architecture design in IP telephony. Diplomová práca. Žilina: Žilinská univerzita, Fakulta riadenia a informatiky, 2007, 98 s.

Poznamky