Internet se zaručenou kvalitou služby

Ladislav Lhotka

Jihočeská univerzita v Českých Budějovicích

Úvod

Datové komunikace v Internetu se stále a téměř bez výjimky realizují v režimu best effort (BE). Je pozoruhodné, že tento indiferentní přístup k požadavkům jednotlivých klientů přestál všechny dramatické změny, k nimž došlo v letech nedávno minulých: nebývalý nárůst počtu účastníků, komercionalizace a především změna struktury datových přenosů, způsobená rozvojem nových služeb typu WWW. Jestliže před deseti lety zůstávala výrazná většina datových toků uvnitř lokálních - tedy relativně homogenních a dobře propustných - sítí, je dnes situace přesně obrácená a většina zátěže leží na páteřní infrastruktuře všech úrovní. Tradiční datové aplikace podporované mechanismy TCP jsou ještě vcelku dobře schopny vyrovnat se s přetíženými mezinárodními okruhy, horší je to však s aplikacemi multimediálními a speciálně pak interaktivními, které jsou velmi citlivé na zpoždění při přenosu digitalizovaného obrazu a zvuku.

Vzato čistě technicky by možná k vyřešení těchto problémů stačilo povýšit infrastrukturu Internetu na úroveň odpovídající současným možnostem. To však lze v rozumném časovém horizontu prakticky realizovat jen v omezeném měřítku, rozhodně ne v celém Internetu.

Best effort je však také problematický z hlediska marketingu, neboť není jako služba dobře definován. Poskytovatelé připojení tak vlastně nabízejí produkt, jehož parametry závisejí na řadě víceméně náhodných okolností, které nemohou ovlivnit. Mnozí jejich zákazníci jsou přitom ochotni za expresní služby také řádně zaplatit.

Jaké alternativy Internetu s BE jsou tedy k dispozici? Málokdo dnes věří v úspěch revolučních řešení spočívajících v úplném nahrazení rodiny protokolů TCP/IP něčím jiným. Takové ambice měla například ještě nedávno technologie ATM, jež vychází z dědictví klasické telefonie - přepojování okruhů spojené s rezervací zdrojů sítě po celé trase od volajícího k volanému a po celou dobu trvání hovoru. Dnes je však evidentní, že se ATM v takto univerzální poloze neprosadí. Prostředky pro realizaci služeb se zaručenou kvalitou, které jsou v ATM k dispozici, však mohou dobře posloužit jako náročné měřítko pro jiné implementace kvality služby.

Zbývá tedy uvážit, jakým způsobem lze rozšířit stávající protokoly TCP/IP o nové prvky, které umožní rozlišovat mezi datovými toky, specifikovat zvolené parametry přenosu a podle možností zaručit jejich dodržení.

Komponenty pro řízení kvality služby nad IP

Organizace ITU-T definuje ve svém doporučení E.800 kvalitu služby (QoS) jako souhrnný efekt výkonnosti služby, který určuje stupeň uspokojení uživatele této služby. Pro praktickou implementaci v aktivních prvcích sítě je však zapotřebí objektivní definice, založená na kvantitativních parametrech.

Na rozdíl od klasického modelu směrování IP datagramů musíme vycházet z datových toků, které jsou určeny zdrojovými a cílovou adresou (cílová adresa může být multicastová) a cílovým portem. S datovým tokem můžeme spojit tyto parametry QoS:

Propustnost sítě je dána jak kvalitou linek (kapacitou a chybovostí), tak i parametry aktivních prvků podél celé trasy, zejména jejich výpočetním výkonem a velikostí vyrovnávacích pamětí.

U zpoždění dat jsou důležité oba hlavní statistické parametry - střední hodnota a rozptyl. Pro jednosměrné proudy dat (např. neinteraktivní video) není příliš důležitá samotná hodnota zpoždění, avšak velký rozptyl může způsobit pozorovatelné zhoršení kvality příjmu.

Pro interaktivní aplikace, tedy videokonference, telefonii, ale též některé grafické aplikace, jsou velmi podstatné oba parametry.

Je zřejmé, že efektivní implementace QoS musí zahrnovat následující funkce:

  1. Realizace administrativní strategie
  2. Klasifikace paketů
  3. Řízené odesílání paketů

V bodu 1 je jednak třeba kontrolovat, zda případné rezervace zdrojů nepřekračují dostupnou kapacitu, zda skutečné datové toky odpovídají smluveným parametrům a musí se též ověřovat, zda vznášené požadavky pocházejí od subjektů, které k tomu mají příslušné oprávnění. Součástí strategie je i způsob, jakým se nakládá s požadavky či datovými toky, které neodpovídají uvedeným předpokladům, tedy například, zda nezpůsobilé pakety zahazovat anebo je pouze převést na best effort, zda lze dodatečně omezit existující datový tok v případě, že se objeví požadavek s vyšší prioritou apod.

Bod 2 - klasifikace paketů - slouží k určení způsobu, jakým se má naložit s došlým paketem, tedy k jakému toku anebo do jaké kategorie patří.

Výsledkem funkcí 1 a 2 jsou pak instrukce předané modulu 3, který řídí vlastní odesílání paketů. Tato oblast je sama o sobě předmětem intenzivního výzkumu, viz např. [Zha95].

Pod hlavičkou IETF byly zřízeny dvě pracovní skupiny, které studovaly dva možné přístupy k realizaci QoS nad IP. Výsledky práce obou skupin, které již byly publikovány formou RFC, probereme v následujících oddílech.

Integrované služby a RSVP

Model QoS zvaný integrované služby (IntServ) předpokládá záruky pro QoS po celé trase mezi zdrojovou a cílovou stanicí. Pro tento účel musí všechny uzly na trase získat informace o parametrech požadovaných pro daný datový tok a vyhradit pro něj odpovídající zdroje. Pokud je nemá uzel k dispozici anebo rezervace neodpovídá admistrativní strategii, spojení bude odmítnuto. V rámci IntServ jsou definovány dvě třídy QoS:

Ačkoliv je specifikace integrovaných služeb nezávislá na protokolu, jímž se aktivním prvkům v síti signalizují rezervační požadavky aplikací, v praxi se pro tento účel používá výhradně protokol RSVP [Bra97], který je přenášen pomocí IP . RSVP definuje několik typů zpráv, které se rozlišují pomocí osmibitového pole v hlavičce protokolu. Kromě vlastní hlavičky může RSVP přenášet další údaje ve formě tzv. objektů. Některé obecné objekty jsou definovány přímo ve specifikaci RSVP [Bra97], řadu dalších však najdeme až v RFC 2210-2212, v nichž jsou popsány integrované služby.

Protokol RSVP s rozšířeními IntServ funguje následovně:

  1. Zdroj datového toku vysílá v pravidelných intervalech zprávy typu PATH, které jsou dále šířeny po trase směrem k příjemci od jednoho routeru k následujícímu. V případě multicastových toků se zprávy PATH samozřejmě šíří od zdroje ve více větvích. Následující "hop" na trase je vždy určen na základě informací standardních unicastových nebo multicastových směrovacích protokolů. Zprávy PATH obsahují zejména tyto objekty:
    • RSVP_HOP: Každý router na trase od zdroje k příjemci sem zapíše sebe jakožto původce zprávy.
    • SENDER_TSPEC: Do tohoto objektu zapíše zdroj parametry toku, který generuje - jde v podstatě o specifikaci průměrné a špičkové přenosové rychlosti a maximálního rozsahu špiček. Dalšími routery na trase je tento objekt ve zprávách PATH předáván beze změny. Příjemce z něho proto získá originální informace o parametrech datového toku.
    • ADSPEC: Tento objekt umožňuje příjemci poté, co k němu doputuje, zjistit vlastnosti trasy od zdroje (dostupnost funkcí potřebných pro specifikaci QoS, šířku pásma, MTU atd.). Na rozdíl od SENDER_TSPEC je objekt ADSPEC po cestě od zdroje k příjemci postupně modifikován tak, aby odrážel vlastnosti celé trasy.
  2. Na základě údajů získaných z objektů SENDER_TSPEC a ADSPEC specifikuje příjemce toku své požadavky na QoS ve formě dvou objektů:
    • FLOWSPEC: popisuje kvantitativní parametry QoS
    • FILTERSPEC: definuje filtr umožňující rozpoznat pakety toku, jehož se má případná rezervace týkat.

    Příjemce posílá periodicky tyto objekty zabalené ve zprávě typu RESV (rezervační požadavek) proti směru datového toku - jednotlivé uzly na této cestě lze totiž určit z předcházejících zpráv typu PATH.

  3. Každý router podél zpětné cesty vyhodnotí na základě určené administrativní strategie oprávněnost požadavků obsažených v objektu FLOWSPEC a zajistí příslušné rezervace, pokud má k dispozici dostatečné zdroje. V případě, že požadavek nemůže být uspokojen, pošle se směrem k žadateli (tedy příjemci toku) chybová zpráva., která zruší všechny již provedené rezervace v uzlech po proudu. Může-li router požadavek uspokojit, předá zprávu RESV následujícímu routeru proti proudu. Speciálním případem jsou multicastové toky: pokud z routeru vychází více větví, po nichž se tok šíří, musí být rezervační požadavky agregovány - směrem ke zdroji se šíří jediný rezervační požadavek, který je v jistém smyslu maximem všech požadavků obdržených od routerů po proudu.

Vlastnosti protokolu RSVP můžeme tedy shrnout takto:

V rámci projektu TEN-34 byl protokol RSVP testován pracovní skupinou TF-TEN [Lei98] na routerech firmy Cisco Systems. Bylo zjištěno, že implementace RSVP v IOS verze 11 je již poměrně vyzrálá a plně funkční. Jako hlavní problém byla identifikována absence prostředků pro implementaci administrativní strategie, bez níž je ovšem nasazení RSVP ve větším měřítku nemyslitelné.

Diferencované služby

Motivací pro hledání alternativ k integrovaným službám byly oprávněné obavy ze špatné škálovatelnosti protokolu RSVP, zejména pokud by se měly rezervace realizovat napříč celým Internetem. Pro velmi zatížené routery přenášející statisíce toků by totiž nároky na paměť (uchování stavových dat) a výpočetní kapacitu (klasifikace paketů) byly skutečně extrémní.

Pracovní skupina IETF pro diferencované služby (DiffServ) proto vytvořila podstatně jednodušší model QoS, který je založen na agregaci datových toků do malého počtu tříd (Class of Service - CoS) a jim odpovídajících kvalitativních typů služeb. K vyznačení příslušnosti paketu k dané třídě se využívá oktet TOS v hlavičce IPv4 anebo oktet Traffic Class v hlavičce IPv6 (prozatím se využívá pouze šest bitů z těchto oktetů).

Model DiffServ se v současné době ještě vyvíjí, hlavní principy však již lze vyčíst z publikovaných dokumentů RFC ([Bla98] a další). Vychází se z pojmu DS-domény, což je administrativní jednotka analogická autonomnímu systému. Uvnitř DS-domény je zavedena vůči diferencovaným službám jednotná administrativní strategie - vyhodnocování oprávněnosti požadavků, přiřazení toků do tříd, označení paketů a odpovídající diferencované chování aktivních prvků. V DS-doméně se rozlišují tři typy uzlů-routerů:

Předmětem živých diskusí jsou momentálně definice mechanismů diferencovaného zacházení s pakety různých tříd, označované zkratkou PHB (Per-Hop Behavior). Do stadia RFC zatím dospěly dva typy PHB:

Diskutuje se rovněž několik schémat pro počáteční přidělení značky. Jedna z možností již byla naznačena výše - okrajový uzel provádí sám klasifikaci neznačkovaných paketů a přiděluje jim značky. Popřípadě je také možné, aby pakety značkovala už zdrojová stanice a vyznačila tím své preference či požadavky. Okrajový uzel pak tuto indikaci vezme v úvahu spolu s ostatními kritérii a předepsaným způsobem s paketem naloží. Byla rovněž navržena jiná zajímavá varianta [NJZ99] předpokládající využití protokolu RSVP k signalizaci požadavků na QoS, které se v okrajovém uzlu opět transformují do jazyka DiffServ.

Hlavním cílem diferencovaných služeb je tedy vytlačení klasifikační a administrativní inteligence na okraj DS-domén. Vnitřní uzly se pak mohou plně věnovat co nejrychlejšímu směrování paketů, pokud možno přímo v hardwaru.

Přesunutím odpovědnosti jsou ale velmi zvýšeny nároky na okrajové uzly. Navíc na rozdíl od IntServ/RSVP musí rozhodnutí okrajových uzlů vycházet z posouzení situace v celé DS-doméně. Z tohoto důvodu se další směr výzkumu zabývá návrhem speciálních agentů zvaných bandwidth broker, tedy zprostředkovatelů pásma - viz např. [BCI98].

Většina výrobců routerů (IBM, Cisco Systems, Telebit) zatím diferencované služby podporuje jen v beta verzích softwaru, v produkčních verzích se očekávají koncem roku 1999. Velmi zajímavou platformou pro experimenty s DiffServ je také operační systém Linux, který ve verzi 2.2 obsahuje několik variant dispečinku paketů (například CBQ, viz [FJ95]) a jako samostatné rozšíření je k dispozici i implementace DiffServ pro Linux (viz http://icawww1.epfl.ch/linux-diffserv).

Závěr

Tento příspěvek podává stručný přehled možností pro realizaci kvality služby v rámci protokolu IP. Zdaleka ovšem nevyčerpává všechna aktuální témata v této oblasti - namátkou jmenujme tyto okruhy problémů:

Univerzální a robustní řešení QoS v Internetu zatím není známo, zřejmě jím ale bude vhodná kombinace integrovaných a diferencovaných služeb - IntServ/RSVP se bude využívat v lokálních a kampusových sítích, zejména pro multicasting, a DiffServ pak v jádru infrastruktury Internetu. Hlavní překážkou v nasazení obou typů služeb s QoS je zatím nedostatečný pokrok ve vývoji agentů implementujících administrativní strategii a schopných spolupráce s routery v reálném čase. Slibných výsledků již bylo dosaženo naproti tomu při studiu algoritmů pro klasifikaci paketů. Publikované analýzy (např. [BSO99]) ukazují, že pro tuto úlohu v řadě případů postačí výkon současných špičkových procesorů Intel.

Budoucnost také ukáže, zda se třeba konečným řešením QoS v Internetu nestane prostá instalace infrastruktury s mnohonásobně vyšší propustností. Aktuální vývoj v oblastech optických a bezdrátových přenosových technologií dává těmto nadějím reálný základ a liberalizace telekomunikačních trhů by zase mohla způsobit, že se tyto extrémní přenosové kapacity stanou i cenově dostupnými.

Literatura

[Bla98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. & Weiss, W., 1998. An Architecture for Differentiated Services. RFC 2475.

[BCI98] British Columbia Institute of Technology, 1998. Bandwidth Broker System Specification. http://www.merit.edu/working.groups/i2-qbone-bb/doc/BB_Systém_Spec_R11.pdf

[BSO99] Borg, N., Svandberg, E. & Schelen, O., 1999. Efficient multi-field packet classification for QoS purposes. In: Proceedings of the IFIP 7th International Workshop on Quality of Service, London.

[Bra97] Braden, R. (Editor), Zhang, L., Berson, S., Herzog, S. & Jamin, S., 1997. Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification. RFC 2205.

[FJ95] Floyd, S. & Jacobson, V., 1995. Link-sharing and resource management models for packet networks. In: IEEE/ACM Transactions on Networking 3(4):365-386.

[Hei99] Heinanen, J., Baker, F., Weiss, W. & Wroclawski, J., 1999. Assured Forwarding PHB Group. RFC 2597.

[JNP99] Jacobson, V., Nichols, K. & Poduri, K. An Expedited Forwarding PHB. RFC 2598.

[Lei98] Leinen, S., 1998. IP resource reservation. In: Behringer, M. (Editor): TEN-34: Results of Phase 2 Test Programme. DANTE, Cambridge.

[NJZ99] Nichols, K., Jacobson, V. & Zhang, L., 1999. A Two-bit Differentiated Services Architecture for the Internet. RFC 2638.

[SPG97] Shenker, S., Partridge, C. & Guerin, R., 1997. Specification of Guaranteed Quality of Service. RFC 2212.

[Wro97] Wroclawski, J., 1997. Specification of the Controlled-Load Network Element Service. RFC 2211.

[Zha95] Zhang, H., 1995. Service disciplines for guaranteed performance service in packet-switching networks. Proceedings of the IEEE 83(10): 1374-1395.

další příspěvky
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz