QoS a diffserv - Úvod do problematiky

Technická zpráva TEN-155 CZ číslo 6/2000

QoS a diffserv - Úvod do problematiky Sven Ubik 29. 9. 2000 Poznámka: tento text byl připraven pro publikaci v časopise Sdělovací technika.

1

Úvod

Pojem kvalita služby (Quality of Service, QoS) vyjadřuje jeden z trendů vývoje technologií a služeb počítačových sítí - poskytovat uživatelům služby s definovanou kvalitou. Technický vývoj dává uživatelům k dispozici stále rychlejší a spolehlivější přenos dat počítačovou sítí. Přidělování kapacity jednotlivých spojů a dalších komponentů počítačové sítě však zatím není řešeno systematicky s ohledem na potřeby jednotlivých uživatelů a jejich aplikací sdílejících stejnou počítačovou síť. Počítačová síť se snaží vyhovět stejně všem požadavkům aplikací. Pokud to není možné, protože požadavky na přenos dat jsou v určitém okamžiku větší než kapacita počítačové sítě, jsou pakety přenášející data jednotlivých aplikací víceméně náhodně zahazovány nebo pozdržovány. To se projeví zpomalením přenosu, výpadky spojení a dalšími problémy, přičemž chování jednotlivých aplikací je předem obtížné predikovat. Tomuto přístupu se anglicky říká „best effort“. V současné době stále většina komunikace v Internetu probíhá tímto způsobem.

2

QoS aplikací a QoS počítačové sítě

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 služby Internet telefonie, videokonference a další interaktivní služby. Uživatel požaduje, aby mu byla poskytnuta určitá definovaná kvalita služby (QoS). Například videosignál určitého rozlišení o určitém počtu obrázků za sekundu, zvuk určité šířky pásma nebo přenos souboru dat v určitém čase. Tyto požadavky na QoS aplikací lze splnit, když se odpovídající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í.

Ztrátovost paketů - kolik procent paketů nedorazí od odesílatele k adresátovi,

Průchodnost - objem dat v bajtech přenesený za jednotku času, Zpoždění - doba potřebná k přenosu paketu od odesílatele k adresátovi, Změna zpoždění - jak se mění zpoždění jednotlivých paketů během přenosu. U změny zpoždění můžeme sledovat jak okamžitou změnu mezi po sobě následujícími pakety i statistický rozptyl hodnot zpoždění během určitého intervalu. V současnosti existují dva hlavní přístupy k implementaci QoS počítačové sítě: integrované služby (integrated services, ve zkratce intserv) a rozlišované služby (differentiated services, ve zkatce diffserv).

3

Integrované služby - intserv

V případě integrovaných služeb [intserv] aplikace oznámí počítačové síti své požadavky na přenos dat, neboli přímo požaduje určité QoS počítačové sítě, například určitou minimální průchodnost a určité maximální zpoždění. Počítačová síť ověří zda je k dispozici dostatek prostředků pro uspokojení požadavku a rozhodne, zda požadavkům vyhoví (admission control). V případě, že síť nemůže požadavkům vyhovět, spojení není provedeno a aplikace se může rozhodnout, zda požádá o méně náročné QoS počítačové sítě. Pokud je požadavkům vyhověno, počítačová síť musí o požadavcích informovat všechny komponenty, například směrovače v uzlech počítačové sítě, přes které bude probíhat spojení, aby mohly pro dané spojení rezervovat odpovídající objem prostředků. Například určitou šířku pásma spoje mezi dvěma směrovači, určitou velikost fronty paketů uvnitř směrovače, apod. K tomuto účelu slouží rezervační protokoly. Zřejmě nejrozšířenějším rezervačním protokolem je RSVP (Resource Reservation Protocol) [Bra97]. Tento protokol je však poměrně složitý, přináší významnou režii při řízení chodu počítačové sítě. Proto se v poslední době objevují návrhy jednodušších rezervačních protokolů, například YESSIR [Pan99]. Jejich implementace jsou však zatím jen experimentální, nejsou běžně k dispozici ve směrovačích významných výrobců. Ačkoliv možnost přesné specifikace požadované QoS počítačové sítě je lákavá, ukazuje se, že tento přístup je příliš restriktivní a jeho implementace přináší velkou časovou režii. Řada interaktivních aplikací nepotřebuje nutně zajistit určitou konkrétní průchodnost nebo minimální zpoždění. Postačí, když bude zajištěno, že tyto parametry nebudou výrazně zhoršeny vlivem jiné komunikace současně probíhající v téže počítačové síti. Například, aby spuštění přenosu velkého souboru nezpůsobilo podstatné zpomalení interaktivní komunikace, kde je odezva vnímána uživatelem mnohem citlivěji. Navíc, při stále se zvyšujících rychlostech průchodu paketů směrovači je třeba maximálně zjednodušit zpracování jednotlivých procházejících


2

paketů a minimalizovat objem stavové informace (jakou je například rezervace určité QoS), kterou musí směrovače o jednotlivých spojeních udržovat. Proto se v poslední době pozornost obrací více k jinému přístupu k implementaci QoS počítačové sítě - k rozlišovaným službám.

4

Rozlišované služby - diffserv

V případě rozlišovaných služeb [diffserv] aplikace neoznamuje předem počítačové síti své požadavky na QoS. Použití rezervačních protokolů je možné, ale není nutné a obvykle se v tomto případě nepoužívá. Jednotlivé směrovače neudržují žádnou stavovou informaci o jednotlivých spojeních. Implementace QoS je řešena tak, že každý paket vstupující do počítačové síte je označen značkou, která říká, jak má být s paketem zacházeno, neboli určuje třídu přenosu poskytnutou paketu. Toto označení paketů probíhá pouze na vstupu do počítačové sítě. 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 dle této značky se řídí při zpracování paketu. Počet různých značek je relativně malý, obvykle jednotky, maximálně desítky. Zatímco u integrovaných služeb udržuje každý směrovač informaci o prostředcích přidělených každému jednotlivému spojení, u rozlišovaných služeb směrovače pouze přidělí určité prostředky každé třídě 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.

5

Klasifikace paketů

Rozhlehlé počítačové sítě (například národní síťě) bývají obvykle tvořeny propojením sítí menšího rozsahu (například metropolitní sítě). Každá síť může být vybavena jinými směrovači a organizacně řízena jiným subjektem. Z toho vyplývají i různé možnosti zpracování procházejících paketů s ohledem na zajištění požadované QoS. Proto je rozlehlá šíť rozdělena na oblasti se samostatnou správou rozlišovaných služeb, na tzv. diffserv domény. Struktura diffserv domény je znázorněna na obr. 1. Pakety vstupují do diffserv domény přes tzv. ingress směrovače, prochází přes vnitřní směrovače diffserv domény a vystupují přes tzv. egress směrovače. Jsou-li dvě diffserv domény propojeny jedním směrovačem, pracuje egress směrovač jedné diffserv domény zároveň jako ingress směrovač druhé diffserv domény a plní i opačné funkce pro pakety procházející v opačném směru. Klasifikace paketů, t. j. označení značkami probíhá na ingress směrovači a to jak při vstupu paketů do sítě, tak i při přechodu z jedné diffserv domény do


3

vnitřní směrovač ingress směrovač

egress směrovač

vnitřní směrovač diffserv doména

Obrázek 1: Diffserv doména jiné. Výběr značky při vstupu paketu do sítě může být proveden na základě protokolu, IP adresy odesílatele a adresáta, čísel portů a dalších kriterií, včetně výsledků měření dynamických vlastností přicházejících dat. Při přechodu do jiné diffserv domény může být značka zachována, změněna na jinou značku se stejným významem (pokud různé diffserv domény používají různé značky pro stejné zpracování paketů) nebo změněna na jinou značku s jiným významem (pokud následující diffserv doména nemůže zajistit zacházení s pakety použité v předcházející doméně). Pakety mohou být klasifikovány také již aplikací posílající pakety do sítě. První ingress směrovač může tuto klasifikaci zachovat nebo změnit. Způsob označení paketu závisí na technologii nebo protokolu použitém pro přenos paketů. Značka může být buď obsažena uvnitř hlavičky paketu, pokud je tam pro ni vhodné místo, nebo připojena vně paketu. Nejčastější je implementace diffserv na úrovni síťové vrstvy modelu sítě při použití protokolu IP. V tomto případě je značka obsažena v poli označeném DS (differentiated services) [Nic98], které je uloženo buď v místě určeném pro pole TOS (type-of-service) hlavičky protokolu IP verze 4 nebo v místě pro pole Traffic Class hlavičky protokolu IP verze 6. Pole TOS bylo původně určeno pro obdobné účely, související se zpracováním paketu ve směrovačích, nebylo však běžně využíváno. Pole Traffic Class bylo navrženo pro určitý způsob klasifikace paketů bez bližší specifikace. Obě místa jsou tedy vhodná pro uložení značky diffserv. Pole DS má 8 bitů, z toho je 6 bitů určeno pro vlastní značku (differentiated services codepoint, DSCP) a zbývající 2 bity jsou rezervovány pro budoucí použití. Umístění a struktura pole DS jsou znázorněny na obr. 2. Jiným způsobem označení by mohlo být použití čísel virtuálních spojů v technologii ATM - VCI (virtual channel identifier) a VPI (virtual path identifier). Technologie ATM však používá jinou metodu pro zajištění QoS počítačové sítě [Gir99].


4

DS: rozlišované služby (differentiated services) DSCP: značka rozlišované služby (differentiated services code point) CU: nepoužito (currently unused) DSCP

CU

DS Délka Verze hlavičky

TOS Příznaky

Identifikace TTL

Celková délka paketu

Protokol

Offset fragmentu

Kontrolní součet hlavičky

Verze

Označení toku dat

Třída přenosu

Typ následující hlavičky

Délka datové části paketu

Hop limit

Adresa odesílatele

Adresa odesílatele

.. .

Cílová adresa .. . IPv4

IPv6

Obrázek 2: Umístění a struktura pole DS

6

Zpracování paketů

Zpracování paketů ve směrovačích v rámci diffserv domény lze popsat ve třech úrovních abstrakce. Na nejvyšší úrovni je zpracování určeno službou definovanou mezi koncovými body - účastníky komunikace. Služba je definována souborem parametrů popisujících vazbu mezi účastníkem a sítí (Service Level Agreement, SLA). Příkladem služby je tzv. virtuální pronajatý okruh (virtual leased line). Účastník (aplikace) má k dispozici komunikační kanál, který se chová jako skutečný pronajatý okruh, tedy poskytuje stálou předem dohodnutou propustnost s nízkou latencí a malou ztátovostí paketů, ačkoliv je realizován pomocí prostředků (linek a směrovačů) sdílených spolu s dalšími účastníky. Na střední úrovni je zpracování paketů určeno tím, jak je s pakety zacházeno jednotlivými směrovači, bez ohledu na ostatní směrovače (per-hop-behaviour, PHB). Každý směrovač totiž zpracovává pakety zcela nezávisle na ostatních směrovačích. Stará se pouze o to, aby jeho vlastní zpracování paketů odpovídalo značkám paketů. Uvnitř diffserv domény nejsou udržovány žádné virtuální spoje přes několik směrovačů. 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. Specifikace PHB je klíčovou částí diffserv. Předpokládá se, že směrovače budou poskytovat určitá PHB, která budou aplikace využívat k implementaci různých komunikačních služeb (například zmíněný virtuální pronajatý okruh). Hodnota 0 v poli DS je navržena pro označení default PHB, kterým je best-effort přístup. Technická zpráva TEN-155 CZ číslo 6/2000

5

Specifikace PHB popisuje zpracování paketů z pohledu vnějšího pozorovatele. Určité PHB může být v rámci směrovače implementováno různým způsobem. Tato implementace je nejnižší úrovní popisu zpracování paketů. Možné metody implementace budou uvedeny dále v části věnované řízení front.

7

Expedited forwarding (EF)

EF PHB [Jac99] zajišťuje, že každý směrovač v diffserv doméně odesílá pakety zařazené do EF PHB průměrnou rychlostí alespoň rovné stanovené rychlosti. Průměrná rychlost se měří v jakémkoliv časovém intervalu delším nebo rovném době potřebné pro odeslání paketu maximální délky stanovenou rychlostí. EF PHB je vhodné pro implementaci virtuálního pronajatého okruhu.

8

Assured forwarding (AF)

AF PHB [Hei99] 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.

9

Traffic conditioning

Při provozu počítačové sítě se běžně stává, že objem dat přicházejících na určitý směrovač, která mají být dále poslaná na určitý výstupní port směrovače, přesahuje okamžitou kapacitu linky připojené na daný výstupní port. Přicházející pakety jsou v tom případě ukládány do fronty na směrovači. Je však třeba vyřešit situaci, kdy dojde k vyčerpání kapacity fronty (congestion management) nebo předejít vyčerpání kapacity fronty (congestion prevention). Dále je potřeba upravovat objem dat přicházejících do diffserv domény na ingress směrovači v souladu s dohodnutou SLA a implementovat požadovaná PHB na všech směrovačích. Úprava objemu přicházejících dat se obvykle provádí jen na ingress směrovači. K tomu účelu se používají techniky nazvané policing a traffic shaping. Struktura zpracování paketů na ingress směrovači je znázorněna na obr. 3. Značkování paketů se provádí na základě klasifikace a může být ovlivněno


6

i měřením dynamických vlastností přicházejících dat, stejně jako policing a traffic shaping. Zpracování paketů následující po klasifikaci se souhrnně nazývá traffic conditioning a soubor parametrů popisujích toto zpracování se nazývá Traffic Conditioning Agreement (TCA). traffic conditioning

měření přicházející pakety

klasifikace

značkování

policing / traffic shaping

Obrázek 3: Zpracování paketů na ingress směrovači Policing obvykle představuje jednoduché zahazování přicházejících paketů (paket je směrovačem ignorován, není poslán dále a o zahození není poslána žádná zpráva), které se začne provádět při dosažení určité podmínky. Tou může být vyčerpání kapacity fronty nebo překročení určitého objemu přicházejících dat. Inteligentnější metodou je traffic shaping, při které jsou směrovačem jednotlivé pakety pozdržovány tak, že se změní průběh okamžitého objemu odesílaných dat v čase ve srovnání s přijímanými daty, z čehož vyplývá název této techniky. Obvykle se průběh vyrovná tak, že data přicházející na směrovač nepravidelnou rychlostí (s krátkými špičkami - bursts) jsou odesíláná stálou rovnoměrnou rychlostí odpovídající části kapacity výstupní linky. K tomuto vyrovnávání se používá metoda, které se říká „token bucket“ (obr. 4). Metoda logicky patří do komponentu měření (obr. 3) a může být použita i pro ovlivnění značkování nebo rozhodnutí o policing (zahození paketu). Token bucket je nádoba obsahující v každém okamžiku určitý počet tokenů, každý z nich je povolením k odeslání nebo jinému zpracování určitého objemu dat, například 1 bajt. Na počátku je nádoba plná. Při příchodu každého paketu je ověřeno, zda počet tokenů v nádobě alespoň odpovídá velikosti paketu. Pokud ano, paket je zařazen do fronty k odeslání na výstupní port nebo určitým způsobem označen. Zároveň je z nádoby odebrán počet tokenů odpovídající velikosti paketu. Pokud ne, paket je zahozen nebo označen jiným způsobem. Tokeny jsou do nádoby plynule doplňovány stálou rychlostí, dokud není nádoba plná. Token bucket lze tedy popsat dvěma parametry: rychlostí doplňování tokenů <em>r (obvykle dle kapacity výstupní linky) a velikostí nádoby <em>b. Je zřejmé, že dlouhodobý průměr rychlosti přicházejících dat nesmí být vyšší než je rychlost doplňování tokenů a krátkodobé špičky nesmí překročit velikost nádoby (může jít o jednu velkou špičku nebo více menších krátce po sobě následujících špiček), jinak dojde k zahození paketů nebo jiné odpovídající akci. Je také možné použít více nádob s různými parametry para-


7

lelně a tak třídit pakety do více kategorií. To může být použito například pro nastavení drop precedence u AF PHB. r - rychlost doplňování tokenů Token bucket b - velikost nádoby pakety, jejichž odchod byl povolen tokeny přicházející pakety zahozené pakety (nebyl dostatek tokenů)

Obrázek 4: Token bucket

10

Řízení front

Při správné funkci traffic conditioning na ingress směrovači by na vnitřních směrovačích již nemělo dojít k vyčerpání kapacity front a proto tyto směrovače již pouze implementují požadovaná PHB. Implementace PHB však musí být provedena i na ingress směrovači, kde následuje po traffic conditioning. Jednotlivá PHB jsou typicky realizována použitím více front s určitým algoritmem pro zařazování přicházejících paketů do jednotlivých front a pro obsluhu front, tedy výběr paketů z front pro odeslání. Nejrozšířenější metody pro správu více front jsou priority queueing (PQ), classbased queueing (CBQ) a weighted fair queueing (WFQ). Ve všech třech případech je každý přicházející paket vložen do jedné z několika front podle své značky. Metody se liší v tom, jak jsou jednotlivé fronty obsluhovány.

11

Priority queueing (PQ)

U PQ [Ron97] (obr. 5) má každá fronta přiřazenu určitou prioritu, která je u každé fronty jiná. Platí, že z fronty s určitou prioritou může být vybrán paket k odeslání jen pokud jsou všechny fronty s vyšší prioritou prázdné. Fronty s vyšší prioritou mají tedy absolutní přednost před frontami s nižší prioritou.


8

Této vlastnosti lze využít například pro implementaci expedited forwarding PHB (EF PHB). V tomto případě stačí dvě fronty - jedna pro EF PHB, druhá pro „besteffort“ provoz. Nevýhodou PQ je možnost uváznutí (starvation) dat ve frontě s nižší prioritou. Je-li zpoždění paketů příliš veliké, jsou navíc v protokolu vyšší vrstvy obvykle považovány již za ztracené a mohou být poslány znovu, čímž dále zatíží počítačovou síť.

klasifikace

fronta priority 1 obsluha front fronta priority 2 fronta priority 3

Obrázek 5: Priority queueing (PQ)

12

Class-based queueing

U CBQ (obr. 6) jsou jednotlivé fronty obsluhovány cyklicky - jedna po druhé (round-robin). Jakmile určitá fronta přijde na řadu, jsou z ní odesílány pakety dokud není odeslán alespoň stanovený minimální počet bajtů nebo dokud není fronta vyprázdněna. Počet bajtů odeslaných při jedné obsluze fronty lze stanovit individálně pro každou frontu. CBQ může být použito například pro implementaci assured forwarding PHB (AF PHB). V tomto případě jsou potřeba čtyři fronty - jedna pro každou třídu AF PHB. CBQ však musí být ještě doplněno dalším mechanizmem pro implementaci drop precedence jednotlivých tříd AF PHB, například WRED. obsluha front 100 bajtů klasifikace

fronta třídy 1 150 bajtů fronta třídy 2 200 bajtů fronta třídy 3

Obrázek 6: Class-based queueing (CBQ)

13

Weighted fair queueing (WFQ)

U WFQ [Zha] (obr. 7) jsou průběžně obsluhovány vždy všechny fronty. Žádná fronta nemá vyšší prioritu než jiná fronta. Jednotlivým frontám je přitom při-


9

dělována alikvotní část kapacity výstupní linky podle váhy přiřazené ke každé frontě. Není-li však kapacita přidělená určité frontě právě využívána, může být využita pro obsluhu jiné fronty. Přesný postup při určení, ze které fronty má být vybrán další paket k odeslání, je následující. Pro každý přicházející paket je vždy vypočten čas, kdy nejpozději musí být daný paket odeslán vzhledem k tomu, že pro obsluhu fronty, do které je paket zařazen, je garantována určitá kapacita linky. Například, je-li paket vkládán do fronty obsluhované rychlostí 1 paket za 2 jednotky času (pro jednoduchost uvažujeme pakety stejné délky), přičemž ve frontě již jsou uloženy 2 pakety, potom tento nový paket musí být obsloužen nejpozději za 6 jednotek času od jeho příchodu. Po ukončení obsluhy každého paketu se vždy určí, který paket ze všech paketů na vrcholu neprázdných front má být obsloužen nejdříve. Tento paket je pak vybrán pro odeslání. WFQ může být spolu s WRED, obdobně jako CBQ, použito pro implementaci AF PHB.

klasifikace

fronta 1

obsluha front

fronta 2 fronta 3

Obrázek 7: Weighted fair queueing (WFQ)

14

(Weighted-) Random Early Detection (RED / WRED)

RED [Flo93] nebo WRED jsou metody prevence zahlcení (congestion prevention). Pokud necháme fronty zcela naplnit pakety a teprve potom začneme zahazovat další příchozí pakety, může dojít k synchronizaci zahlcení mezi více směrovači a vytvoření vln střídajícího se zahlcení s okamžiky, kdy je snížen objem dat posílaných do sítě tak, že není využita kapacita linek. Příčinou tohoto jevu je chování protokolu TCP, kterým se dnes přenáší významná část všech dat v síti Internet. Pokud totiž protokol TCP na straně odesílatele detekuje ztrátu paketu, odešle ztracený paket znovu a zároveň sníží rychlost odesílání paketů k příjemci neboť předpokládá přetížení přenosové cesty a snížením rychlosti chce předejít dalším ztrátám paketů. Protože směrovačem obvykle prochází řada různých TCP spojení současně od různých odesílatelů, dojde při zahlcení směrovače ke snížení rychlosti na řadě odesílatelů a tím i k následnému nevyužití kapacity výstupní linky směrovače. Jednotliví odesílatelé postupně obnoví původní rychlost přenos a dojde znovu k zahlcení směrovače. Tomuto jevu se snaží předejít metoda RED. Přesáhne-li naplnění fronty určitou mez, začne směrovač zahazovat pakety z náhodně vybraných TCP spojení.


10

Pravděpodobnost zahození paketu se zvyšuje se zvyšujícím se naplněním fronty (obr. 8a). Tím dojde ke snížení objemu dat od některých odesílatelů a plynulému vyrovnání celkového objemu přicházejích dat s kapacitou odchozí linky. U modifikované metody WRED závisí pravděpodobnost zahození paketu též na značce paketu přidělené klasifikací. Limit naplnění fronty při jehož překročení může být paket zahozen je různý pro pakety s různými značkami (obr. 8b). pravděpodobnost zahození 1

a) RED

0

naplnění fronty 0%

pravděpodobnost zahození 1

100%

b) WRED vyšší drop precedence

nižší drop precedence

0

naplnění fronty 0%

100%

Obrázek 8: a) Random early detection (RED), b) Weighted random early detection (WRED)

15

Závěr

Diffserv je perspektivní metoda řešení implementace služeb počítačové sítě s definovanou kvalitou (QoS). Hledání optimálních metod řízení front paketů ve směrovačích pro implementaci požadovaných služeb při sdílení počítačové sítě mnoha účastníky je stále předmětem výzkumu. Testování chování některých metod s použitím směrovačů firmy Cisco bylo prováděno v rámci projektu Diffserv pracovní skupiny TF-TANT [Fer00]. Tato práce bude pokračovat v nové pracovní skupině vytvořené pod hlavičkou organizace TERENA pro rozvoj telekomunikační infrastruktury školských a vědeckých pracovišť v Evropě. Sdružení CESNET, které je členem organizace TERENA, se podílí na testování některých aspektů diffserv v síti národního výzkumu TEN–155 CZ.


11

Reference [intserv]

Integrated Services (intserv) IETF Working Group1 .

[Bra97]

Braden R., Zhang L., Berson S., Herzog S., Jamin S.: Resource Reservation Protocol (RSVP), RFC22052, 1997.

[Pan99]

Pan P., Schulzrinne H.: YESSIR: A Simple Reservation Mechanism for the Internet, ACM Computer Communication Review, Vol. 29, No. 2, 1999, str. 89-101.

[diffserv] Differentiated Services (diffserv) IETF Working Group3 . [Nic98]

Nichols K., Blake S., Baker F., Black D.: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC24744, 1998.

[Gir99]

Giroux G., Ganti S.: Quality of Service in ATM Networks, Prentice Hall, 1999.

[Hei99]

Heinanen J., Baker F., Weiss W., Wroclawski J.: Assured Forwarding PHB RFC25975, 1999.

[Jac99]

Jacobson V., Nichols K., Poduri K.: An Expedited Forwarding PHB, RFC25986, 1999.

[Ron97]

Ronngren R., Ayani R.: A Comparative Study of Parallel and Sequential Priority Queue Algorithms, ACM Transactions on Modelling and Computer Simulation, Vol. 7, No. 2, 1997, str. 157-209.

[Zha]

Zhang H.: Service Disciplines for Guaranteed Performance Service in Packet-Switching Networks.

[Flo93]

Floyd S., Jacobson V.: Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, Vol. 1, No. 4, 1993.

[Fer00]

Ferrari T.: Differentiated Services: Experiment Report, Phase 27, TFTANT Task Force, 2000.

1

http://www.ietf.org/html.charters/intserv-charter.html http://www.ietf.org/rfc/rfc2205.txt 3 http://www.ietf.org/html.charters/diffserv-charter.html 4 http://www.ietf.org/rfc/rfc2474.txt 5 http://www.ietf.org/rfc/rfc2597.txt 6 http://www.ietf.org/rfc/rfc2598.txt 7 http://www.cnaf.infn.it/ ferrari/tfng/ds/rep2-del.ps 2


12

QoS a diffserv - Úvod do problematiky

Recommend Documents