hledat:

6.3   QoS pro aplikace

Cílem projektu bylo ověření možností provozu služeb definované kvality (Quality of Service - QoS) v sítích až na úroveň koncových stanic a jednotlivých aplikací. V roce 1999 a v první polovině roku 2000 jsme se zaměřovali na ATM sítě a zejména na vlastnosti ATM adaptérů, zatímco v druhé polovině roku 2000 jsme obrátili pozornost k IP sítím. Tento text tedy přímo navazuje na stejnojmenou kapitolu průběžné zprávy o řešení výzkumného záměru v roce 1999.

6.3.1   Úvod

Pojem kvalita služby (Quality of Service, QoS) vyjadřuje jeden z trendů vývoje počítačových sítí - poskytovat uživatelům služby s definovanou kvalitou. V poslední době dochází k rozvoji služeb, jejichž úspěšnost z pohledu uživatele významně závisí na časových charakteristikách komunikace přes počítačovou síť. Jde například o videokonference, IP telefonii a další interaktivní služby.

Uživatel požaduje, aby mu byla poskytnuta určitá definovaná kvalita služby (QoS). Například videosignál jistého rozlišení o daném počtu snímků za sekundu, zvuk určité šířky pásma nebo přenos souboru v jistém čase. Při pohledu ze strany sítě QoS poskytuje nástroje pro lepší využití síťových zdrojů tím, že od sebe izoluje jednotlivé datové toky nebo jejich skupiny a zabraňuje jejich vzájemnému negativnímu ovlivňování. Pomocí QoS tak lze např. emulovat virtuální okruhy definovaných vlastností.

Požadavky aplikací na QoS lze splnit, pokud se vhodným způsobem mapují na QoS počítačové sítě. Nejvýznamnější parametry, které definují QoS počítačové sítě, jsou následující:

• Průchodnost - objem dat přenesený za jednotku času.
• Ztrátovost paketů - kolik procent paketů nedorazí od odesilatele k  adresátovi.
• Zpoždění - doba potřebná k přenosu paketu od odesilatele k adresátovi.
• Změna zpoždění - jak se mění zpoždění jednotlivých paketů během přenosu; přesně lze definovat různými způsoby.

6.3.2   QoS v ATM

Zaměřili jsme se na sledování možností poskytování QoS až na úroveň koncové stanice uživatele při použití technologie ATM. Práce byly započaty již v loňském roce, v roce 2000 jsme testovali komunikaci třídy ABR.

Testování adaptéru ForeRunner HE

Začátkem roku 2000 se podařilo zajistit nový typ ATM adaptéru - ForeRunner HE. Jeho testy se zaměřily jednak na porovnání vlastností se starším typem ForeRunner 200E a dále na ověření nově implementovaných vlastností.

Vzájemné ovlivňování kanálů s rozdílným PCR

Ve zprávě o řešení projektu za rok 1999 je popsána zásadní závada implementace QoS u adaptéru ForeRunner 200E, kdy současný přenos dat ve dvou kanálech CBR s rozdílným PCR vede k degradaci kapacity kanálu s vyšším PCR. Opakovali jsme tato měření i s adaptérem ForeRunner HE.

V tabulce jsou uvedeny výsledky měření skutečné kapacity CBR kanálu s PCR 100 Mb/s za situace, kdy mezi adaptéry byla přenášena data i druhým CBR kanálem s nižší hodnotou PCR. Z výsledků je zřejmé, že uvedená chyba implementace QoS u ForeRunner 200E byla u nového adaptéru ForeRunner HE odstraněna. Měření jsme prováděli na kanálech typu PVC pomocí programu Netperf, adaptér byl instalován ve stanici Sun ULTRA 10 se systémem Solaris 2.5.1 a ovladačem ForeThought 5.2.

Aplikační využití QoS

Praktickou ukázkou rozdílnosti implementace QoS v adaptérech ForeRunner 200E a ForeRunner HE je použití QoS v aplikaci - FTP server s rozdílnou přenosovou kapacitou podle IP adresy klienta (viz průběžná zpráva za rok 1999). Tuto aplikaci jsme vybrali proto, že k její realizaci stačí konfigurační nástroj lappqos, který dovoluje v LANE specifikovat třídu služby a její parametry v závislosti na typu protokolu, čísle socketu a cílové IP adrese. Umožňuje tedy modifikovat přidělené přenosové pásmo FTP serveru v závislosti na IP adrese klienta.

Pro pokusný FTP server jsme nastavili rychlost 2 Mb/s a 10 Mb/s v závislosti na IP adrese cílové sítě.

Následující dva obrázky ukazují změřenou velikost provozu na ATM adaptéru v případě, kdy byl přenášen soubor o velikosti cca 25 MB nejprve po síti s omezením 2 Mb/s a o něco později byl tentýž soubor požadován klientem ze sítě s omezením10 Mb/s. První graf obsahuje výsledky adaptéru ForeRunner 200E, v druhém jde o adaptér ForeRunner HE.

Z grafu znázorňujícího přenosouvou rychlost je vidět, že při zahájení přenosu druhého souboru došlo ke zvýšení celkového provozu adaptéru ForeRunner 200E jen na 4 Mb/s místo očekávaných 12 Mb/s. Po skončení přenosu prvního souboru pokračuje přenos druhého souboru plnou rychlostí 10 Mb/s. Adaptér ForeRunner HE se při tomto testu choval podle očekávání.

Implementace ABR

Adaptér ForeRunner HE má implementovánu podporu služeb třídy ABR, která je ale omezena na kanály typu PVC. Vzhledem k tomu, že je podporována pouze signalizace UNI3.0 a UNI3.1, není možno vytvořit ABR kanál typu SVC, což vyžaduje signalizaci UNI4.

Naše testy se zaměřily na ověření vlastností ABR - udržení minimální kapacity kanálu podle hodnoty parametru MCR a ověření funkčnosti flow-control. Dodržení hodnoty MCR na rozhraní adaptéru jsme ověřovali způsobem analogickým s výše uvedeným měřením přenosové kapacity dvou kanálů s rozdílným PCR. Pro testování flow-control jsme sestavili nový testovací systém ze dvou ATM přepínačů a čtyř ATM stanic.

Testování funkčnosti flow-control přímo na úrovni ATM jsme prováděli při různém stupni zatížení rozhraní NNI mezi dvěma přepínači LS1010. Testovali jsme programem Netperf při použití protokolu UDP. Při testu byly vytvořeny 3 kanály různých typů a parametrů. Z tabulky je vliv flow-control zcela zřejmý při porovnání kanálů ABR a UBR. K očekávané ztrátě ATM buněk kanálu UBR došlo v důsledku záměrné saturace spoje mezi oběma přepínači.

Dalším ověřením bylo měření toku dat kanálem třídy ABR pomocí analyzátoru, jak ukazuje následující graf. Při tomto testu byl postupně zahajován přenos jednotlivými kanály tříd ABR, CBR a UBR. Parametry těchto kanálů jsou stejné jako v předchozím testu s výjimkou kanálu CBR, kdy PCR bylo zvýšeno na 135 Mb/s.

Pořadí událostí v grafu na obrázku:

• T0 začátek přenosu ABR (PCR 20 Mb/s, MCR 10 Mb/s)
• T1 začátek přenosu CBR (PCR 135 Mb/s)
• T2 začátek přenosu UBR (PCR 20 Mb/s)
• T3 konec přenosu UBR
• T4 konec přenosu CBR
• T5 konec přenosu ABR

Z grafu je zřejmé, že systém udržel přenosové pásmo kanálu ABR v požadovaných mezích. Dále je vidět, že i kanál UBR byl schopen si zabrat určité pásmo. O pásmo, které nebylo pevně přiděleno, se podělily kanály ABR (nad úroveň MBR) a UBR přibližně rovným dílem.

Reálné využití ABR u adaptérů ForeRunner HE je poněkud nepraktické, neboť vzhledem k omezení pouze na PVC je potřeba celý přenosový kanál sestavit "ručně". To je ještě komplikováno tím, že jsou parametry zadávány v jiných jednotkách (Kb/s) než na přepínačích (buňky/s).

Adaptér ForeRunner HE se v půběhu testů osvědčil jako nejlepší z testovaných typů. Programový balík ForeThought obsahuje ovladače, nástroje a API pro operační systémy Solaris, IRIX a WindowsNT na platformách Intel Pentium, Sun SPARC, SGI Origin a DEC Alfa.

Konfigurace testovacích zařízení

V průběhu testů byly použity ATM přepínače Cisco LS1010 a následující stanice resp. servery:

• Sun ULTRA 2, Solaris 2.7, Fore SBA-200E
• Sun ULTRA 1, Solaris 2.5.1, Fore SBA-200E
• Sun ULTRA 10, Solaris 2.5.1, Fore HE
• Sun Enterprise 450, Solaris 2.7, Fore HE a SunATM v3
• Sun SPARC 1000, Solaris 2.5.1, SunATM v2.1
• PC PII/330, Linux RedHat 6.0, ATM for Linux 0.59, Fore PCA-200E
• PC PII/330, Linux RedHat 6.0, ATM for Linux 0.59, Efficient ENI 155
• SGI O2, IRIX, Fore PCA-200E

Propustnost jsme měřili programem Netperf, pro ověřování signalizace a měření celkové zátěže linky jsme použili analyzátor RADCOM RC-200-C.

Závěr testů ATM

Všechny nyní i dříve testované adaptéry jsou vhodné pro standardní případ použití v prostředí LANE či CLIP. Rovněž bez problémů umožňují používat PVC. Zjistili jsme, že implementace QoS u starších typů adaptérů je nedokonalá. Tato nízká úroveň podpory je částečně a nedůsledně řešena v ovladači příslušného adaptéru. Naopak karta nové generace ForeRunner HE v testech plně vyhověla. Tento adaptér má jako jedniný funkční podporu služeb třídy ABR, i když pouze pro PVC.

Protože vytyčené cíle projektu v oblasti ATM byly dosaženy a jelikož se v oblasti QoS pozornost obecně přesouvá z využití technologie ATM na prostředky pro zajištění QoS na úrovni protokolu IP, rozhodli jsme se tuto část v září 2000 ukončit. Další práce jsme zaměřili na možnosi poskytování QoS na úrovni protokolu IP, a to zejména s využitím přístupu rozlišovaných služeb (diffserv).

6.3.3   QoS v prostředí IP

QoS na úrovni IP protokolu není dosud plně stabilizováno a neustále se vyvíjí. Zatímco dříve byla snaha vybudovat analogii ke QoS v ATM, které je na rozdíl od IP spojově orientované, nyní se zdá jako perspektivnější se zaměřit na princip relativních priorit.

Při implementaci QoS na úrovni protokolu IP existují dva hlavní přístupy řešení: integrované služby (integrated services, ve zkratce intserv) a rozlišované služby (differentiated services, ve zkratce diffserv).

Intserv

U přístupu intserv aplikace přímo požadují od počítačové sítě zajištění určitých kvantitativních parametrů spojení, například jistou minimální propustnost. K zajištění těchto parametrů se používají rezervační protokoly, například RSVP [RFC2205]. Tento přístup se ukazuje jako příliš restriktivní vzhledem k využití kapacity počítačové sítě a přináší značnou režii - směrovače musí udržovat stavovou informaci o každém procházejícím spojení.

Intserv rozšiřuje základní model služby v IP, tj. best-effort, o další typy služeb podle vzoru QoS v ATM: zaručené služby (Guaranteed Services) a služby s řízeným zatížením (Controlled-Load Services). Záměrem je rozšířit IP o možnosti provozu v reálném čase. Základní nevýhodou je, že intserv vyžaduje přizpůsobení všech aplikací signalizaci RSVP a dále spolupráci síťových prvků, které musí každý datový tok zpracovat izolovaně. To klade značné nároky na výkon síťových prvků. Pro široké použití je intserv nepraktický.

Controlled-Load Services zajišťuje pro datový tok stejnou kvalitu služeb, jako nezatížená síť best-effort. Nezaručují se explicitně žádné vlastnosti týkající se zpoždění. Controlled-Load Sevices zajišťuje, ze dohodnuté datové toky nezahltí síťové prvky. Pakety nesplňující dohodnuté podmínky jsou zpracovány neprivilegovaně na úrovni služby best-effort.

Guaranteed Services zaručují hodnotu maximálního zpoždění při dané přenosové rychlosti a to, že paket nebude zahozen z důvodu přeplnění některé fronty. Cílem naopak není minimalizovat rozdíly zpoždění (jitter). Služba je popsána tzv. fluid modelem, jehož analogií je dedikovaný kanál stejné přenosové rychlosti. Vychází se při tom z faktu, že lze vypočítat maximální zpoždění datového toku v uzlu při znalosti rychlosti výstupní linky a paramtrů datového toku.

Diffserv

V poslední době se pozornost obrací spíše k přístupu diffserv (Differentiated Services) jako k nové metodě řešení problematiky QoS v IP. Na rozdíl od intservu vycházejí poskytované služby z principu relativních priorit v prostředí nespojované sítě. Datové toky jsou agregovány do tříd podle stejného typu služby, takže síťové prvky (s výjimkou hraničních) se nemusí starat o každý datový tok zvlášť.

Každý IP paket vstupující do počítačové 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. Místo v hlavičče IP paketu určené pro tuto značku se nazývá DSCP (differentiated services codepoint). Toto označení probíhá jen na vstupu do počítačové sítě na tzv. ingress směrovači. Během přenosu paketů počítačovou sítí další směrovače pouze přečtou značku každého paketu a řídí se podle ní při zpracování paketu.

Počet různých značek je relativně malý, v současném návrhu diffserv je jich 64. Směrovače přidělí určité prostředky každé třídě přenosu a zajišťují určitý vztah mezi jednotlivými třídami. Například může být stanoveno, že pakety s určitou značkou mohou být poslány dále jen pokud nejsou ve frontě čekající pakety s jinou značkou. Takto fungující síť se nazývá diffserv doména. Rozlehlá počítačová síť může být rozdělena na několik propojených diffserv domén. V každé z nich probíhá zpracování paketů samostatně. Struktura diffserv domény je znázorněna na obrázku.

Zpracování paketů směrovačem na základě značky paketu se nazývá per-hop-behaviour (PHB). V současné době jsou standardizována dvě PHB - expedited forwarding (EF) a assured forwarding (AF). Diffserv domény mohou implementovat i jiná lokálně definovaná PHB.

Expedited forwarding (EF)

Definice EF PHB byla v nedávné době výrazně upravena. Dle původní definice [RFC2598], dosud převážně užívané, zajišťuje EF PHB, že každý směrovač v diffserv doméně odesílá pakety zařazené do EF PHB průměrnou rychlostí alespoň rovnou stanovené rychlosti. Tato průměrná rychlost se měří v jakémkoliv časovém intervalu delším nebo rovném době potřebné pro odeslání paketu maximální délky stanovenou rychlostí.

Dle revidované definice [Arm00] představuje EF PHB striktní limit pro změnu zpoždění, který musí splnit všechny pakety přicházející ve stanovené maximální rychlosti. Nová definice nepřímo též implikuje potřebu zajištění určité šířky pásma pro odcházející pakety, je však přesnější ve specifikaci zpoždění jednotlivých paketů, což je pro řadu aplikací potřebné.

EF PHB je vhodné pro implementaci virtuálního pronajatého okruhu.

Assured forwarding (AF)

AF PHB [RFC2597] umožňuje zařadit pakety do jedné ze čtyř tříd. Každé třídě je ve směrovačích přidělen určitý objem prostředků, například velikost vyrovnávací paměti nebo kapacita výstupní linky. V rámci každé třídy pak může být každému paketu přiřazena jedna ze tří priorit zahození paketu (drop precedence), ke kterému může dojít v případě zahlcení. Směrovač musí odeslat paket mající nižší hodnotu priority se stejnou nebo vyšší pravděpodobností než paket mající vyšší hodnotu priority. AF PHB se používá pro implementaci služeb, u kterých je potřeba volitelná úroveň kvality přenosu.

Mapování současného stavu

V první fázi jsme analyzovali současný stavu problematiky včetně existujících standardů, návrhů a projektů věnujících se přístupu diffserv ve světě. Popis koncepce přístupu diffserv jsme shrnuli v dokumentu QoS a diffserv, který byl publikován v časopise Sdělovací technika a je rovněž dostupný jako technická zpráva sítě TEN-155 CZ [Ubi00]. Téma diffservu bylo dále předmětem prezentace na konferenci EurOpen [Smo00].

V další fázi jsme se věnovali zjištění možností konfigurace jednotlivých mechanismů pro správu front na směrovačích Cisco použitých v síti TEN-155 CZ. Soustředili jsme se zejména na konfiguraci PQ (priority queueing) a WFQ (weighted fair queueing). Tyto mechanismy jsou spolu s určitými metodami pro prevenci zahlcení, například WRED (weighted random early detection) potřebné pro implementaci EF (expedited forwarding) PHB a AF (assured forwarding) PHB a jsou v současné době používány jako základní stavební kameny pro implementaci QoS charakteristik ve směrovačích.

Vývoj konfiguračních prostředků pro QoS v systému IOS

Konfigurační možnosti mechanismů pro správu front a dalších prostředků vhodných pro implementaci diffserv se výrazně liší u jednotlivých verzí systému IOS. Každá verze nabízí určitou kombinaci příkazů a volitelných parametrů. Mnoho důležitých příkazů je k dispozici pouze ve vývojových verzích systému (řady T, XE, atd.). V průběhu vývoje došlo k vytvoření několika specifických alternativ příkazů pro konfiguraci PQ a WFQ, některé z nich jsou popsány v dokumentech [Cisco-Dwfq] a [Cisco-QoS].

Často se objevuje metoda QoS-group-based WFQ, kde rozdělení paketů do jednotlivých tříd WFQ je evidováno pouze interní hodnotou (stavovou informací) ve směrovači v průběhu zpracování paketu a není žádným způsobem vloženo do hlavičky IP paketu. Klasifikace tak musí probíhat na všech směrovačích, nikoliv pouze na hraničních směrovačích. Kuriozitou je metoda ToS-based WFQ, která pracuje s označením třídy v hlavičce IP paketu, používá však pouze 2 bity z pole ToS. Většina mechanismů je podporována až od určité hardwarové třídy směrovače výše.

Naštěstí se zdá být pravděpodobné, že výše zmíněné varianty jsou již jen pozůstatkem historického vývoje. Novější verze vývojových řad systému IOS nabízí tzv. Modular Quality of Service Command Line Interface (Modular QoS CLI), který umožňuje konfiguraci různých mechanismů pro správu front přehledným a jednotným způsobem.

Příkazem class-map se provede klasifikace paketů do tříd podle různých kritérií. Následně se příkazem policy-map definuje, jak má být s pakety jednotlivých tříd zacházeno. Tato definice se pak příkazem service-policy přiřadí k rozhraní směrovače.

Měření toku dat, klasifikace a značkování

Pro měření konformance toku dat k dohodnutým parametrům na vstupu do diffserv domény lze na směrovačích Cisco použít sérii příkazů rate-limit. Dříve byl tento příkaz součástí mechanismu, který Cisco nazývá CAR (Commited Access Rate). Nyní je součástí Modular QoS CLI.

Příkaz je v podstatě kombinací dvou token bucket, jde tedy o obdobu standardního klasifikačního mechanismu trTCM (Two Rate Three Color Marker) [RFC2698]. Rozdíl je v tom, že výstupem je klasifikace pouze do dvou barev a algoritmus porovnávání paketu s obsahem token bucketů je jiný. Pro klasifikaci do více barev, jak je tomu například v AF PHB, je potřeba použít více příkazů rate-limit.

Jeden z problémů, který bylo potřeba vyřešit, je značkování paketů. Například pro implementaci AF je potřeba rozlišovat 4 třídy a v každé z nich 3 priority zahození, tedy celkem 12 různých hodnot. Podle specifikace přístupu diffserv má být možné označovat IP pakety v hlavičce v poli DSCP značkami z množiny 64 různých hodnot (což vyžaduje 6 bitů).

Tuto množinu značek zatím umí nastavovat a využívat jen malý počet verzí systému IOS. Některé verze umožňují využít již nastavené klasifikace v celém poli DSCP, neumí však celé pole nastavit. Všechny verze umožňují nastavování i využívání pole IP precedence, které je předchůdcem DSCP a rozlišuje 8 různých hodnot. To je však pro účely AF málo. Některé verze umožňují pracovat s polem ToS (rovněž předchůdce DSCP), které má šířku 4 bity a rozlišuje tedy 16 různých hodnot. Nejnovější verze systému IOS umí uložit značku též do 3 bitů experimentálního pole MPLS paketů, což je ovšem rovněž málo. V dosavadní práci jsme používali pouze verze systému IOS, které umožňují pracovat s celým polem DSCP. Práce s experimentálním polem MPLS paketů bude předmětem dalších testů.

Test EF PHB

Pro implementaci EF PHB je třeba zajistit pro pakety označené příslušnou značkou v poli DSCP (46 dekadicky) definovanou šířku pásma bez ohledu na přicházející pakety označené jinými značkami. Testování funkce EF PHB jsme prováděli na směrovači Cisco 7500 zapůjčeném od provozně-technického útvaru.

Jako zdroj dat jsme použili dva počítače s operačním systémem Linux - jeden jako zdroj testovacích dat, druhý jako zdroj dat pro vytvoření prostředí zahlcené výstupní linky, kdy se projeví chování mechanismů pro správu front. Třetí počítač s operačním systémem Linux jsme použili jako přijímací, pro vyhodnocování testovacích dat. Konfigurace je znázorněna na obrázku.

Pro generování a příjem testovacích dat jsme použili dvojici programů RUDE/CRUDE (Real-time UDP data emitter and collector). K vysílání dat pro zahlcení linky jsme použili rovněž programy RUDE/CRUDE a alternativně program Netperf.

Verze systému IOS 12.1(2)T, která se (vzhledem k podporovaným konfiguračním možnostem) jevila jako zajímavá, se bohužel ukázala být nepoužitelnou. Směrovač se samovolně restartoval při příchodu prvního paketu zařazeného explicitně do určité třídy příkazem class-map při určitých klasifikačních kritériích. Nejnovější verze z vývojové řady 12.1(3a)E, která také poskytuje potřebné konfigurační možnosti, se zdá být v pořádku.

Důležitý poznatek je ten, že správa front konfigurovaná novým modulárním rozhraním pracuje pouze na rozhraních (portech směrovače) modulů karet s procesorem VIP (Versatile Interface Processor). Ty jsou k dispozici jen pro směrovače řady 7500 nebo 7200. Bohužel jsme měli zatím k dispozici pouze sériové rozhraní tohoto typu, testy proto probíhaly na nízkých rychlostech.

Mechanismy pro správu front jsou až do řady 7500 ve všech směrovačích implementovány čistě softwarově a jejich použití klade značné nároky na procesor. To je zřejmě důvodem, proč jsou podporovány jen na nejvýkonnějších typech směrovačů.

Použitá konfigurace je uvedena dále. Alternativně jsme místo příkazu bandwidth použili příkaz priority.

ip cef distributed
!
access-list 100 permit ip host 195.113.147.10 any
!
class-map match-all ef
  match access-group 100
!
policy-map ds
  class ef
    set ip dscp 46
    bandwidth percent 70
!
interface Serial1/0/0
  service-policy output ds

Chování směrovače s touto konfigurací je znázorněno na následujících obrázcích. Testovací data jsou zobrazena vždy zelenou barvou, data pro zahlcení linky červenou barvou a nastavená šířka pásma pro testovací data modrou barvou. Požadovaná šířka pásma byla nastavena na 70 % kapacity linky (44,8 Kb/s).

Testování probíhalo vždy 40 sekund. Tato doba byla rozdělena na čtyři úseky po 10 sekundách. V jednotlivých úsecích byl objem generovaných testovacích dat po řadě roven 20 Kb/s, 20 Kb/s, 44 Kb/s a 60 Kb/s. V čase 10 sekund byl spuštěn paralelní zdroj dat 60 Kb/s pro zahlcení linky.

Nejprve jsme pro srovnání aplikovali samostatně každý ze zdrojů dat (druhý zdroj dat byl vypnutý). V tomto případě byl průběh dat každého ze zdrojů téměř přesně kopírován na výstupní lince - viz obrázek (oba toky dat jsou znázorněny ve společném obrázku, probíhaly však samostatně).

Potom jsme spustili oba zdroje dat současně. Bez explicitního nastavení obsluhy front byla oběma zdrojům dat přidělována kapacita výstupní linky rovnoměrně, jak je vidět na obrázku.

Průběh procházejících dat po zapnutí obsluhy font podle dříve uvedené konfigurace je znázorněn na obrázku. Alternativu s příkazem priority obsahuje obrázek.

Je vidět, že zajištění požadované šířky pásma i absolutní priority na úrovni IP pracovalo dobře. Zátěž procesoru směrovače byla minimální, šlo však o nízké rychlosti. Protože dle předchozích zkušeností některé mechanismy značně zatěžují procesor, bude zajímavé ověřit zátěž této konfigurace na rozhraní typu Fast Ethernet nebo rychlejším.

Při testování směrovačů řady GSR 12016 v rámci výběrového řízení na dodání gigabitových směrovačů jsme měli možnost vyzkoušet též konfiguraci nastavení požadované šířky pásma na tomto směrovači. Je-li směrovač vybaven procesorem Engine 2 (což byl náš případ), měl by implementovat mechanismus MDRR (Modified Deficit Round Robin), který je obdobou CBQ (class-based queueing) přímo na hardwarové úrovni. V limitovaném časovém prostoru se bohužel nepodařilo tento mechanismus zprovoznit ani pracovníkům firmy Cisco Systems.

6.3.4   Další činnost

Řešitelé plánují pokračovat v roce 2001 v projektu QoS v IP. Pro úspěšné provedení testů bude nezbytné mít možnost dlouhodobě a neomezeně používat směrovač třídy Cisco 7500 ve vhodné konfiguraci. Jakmile bude tento směrovač k dispozici, plánujeme provedení testů mechanismů WFQ a PQ na rychlejších rozhraních (Fast Ethernet a Gigabit Ethernet) a testů WRED v kombinaci s WFQ pro implementaci AF PHB.

Cílem řešitelů dále je zapojit se do mezinárodních projektů v rámci pracovní skupiny TF-NGN při organizaci TERENA. Širším cílem je sledovat vývoj a případně se aktivně účastnit prací v v jiných probíhajících nebo nově zahajovaných projektech (např. projekt Tequila), zaměřených na diffserv a metody traffic engineering.

Budou-li testované mechanismy pracovat bez problémů a nebude-li přidaná zátěž procesoru způsobená konfigurací těchto mechanismů přiliš vysoká, předpokládáme (po dohodě s technicko-provozním útvarem) možnost jejich nasazení v síti TEN-155 CZ pro poskytování spojení s definovanou kvalitou.

předchozí

obsah

následující