Součinnost architektury diferencovaných a integrovaných služeb Ing. Jan Kacálek Doc. Ing. Vladislav Škorpil, CSc. Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, Ústav telekomunikací, Purkyňova 118, 612 00 Brno, Česká republika email: xkacal00@stud.feec.vutbr.cz Pro zajištění kvality služeb byly organizací IETF, která se zabývá standardizací na Internetu, navrženy dva hlavní modely. Jedná se o model Integrovaných služeb a model Diferencovaných služeb. Pro nasazení těchto modelů do Internetu je proto velmi důležitá také jejich efektivní spolupráce. Možnou spoluprací těchto dvou modelů se zabývá tento článek. 1. Možnosti součinnosti Integrovaných a Diferencovaných sluzěb Architektury Diferencovaných (DiffServ) a Integrovaných (IntServ) služeb samozřejmě nebudou existovat samostatně v nějakých izolovaných sítí, ale byly primárně navrženy pro zajištění kvality služeb (QoS) v sítích s protokolem IP, tj. především současný Internet. Protože Internet je rozlehlá celosvětová síť, zákonitě se v něm budou vyskytovat oblasti (tzv. domény) s podporou Intserv a oblasti s podporou Diffserv. Intserv se nasazuje především v okrajových sítí, kde se s výhodou využije možnost rezervovat zdroje pro jednotlivé datové proudy. Naopak Diffserv nalezneme především v páteřních sítích, kde se využije jeho agregační charakter. Proto nutně vystává problém s přenosem IntServ dat přes domény s podporou Diffserv. Specifické realizace RSVP/IntServ-DiffServ spolupráce závisí na přidělování zdrojů a na podpoře RSVP protokolu v DiffServ doméně. Řízení přidělování zdrojů v DiffServ doméně může být buď statické (ovládané lidmi - administrátory), nebo dynamické (přes protokoly). DiffServ doména má podporu protokolu RSVP, jestliže se uvnitř této domény nacházejí standardní RSVP směrovače. Možné scénáře RSVP/IntServ-DiffServ spolupráce jsou ukázány na obrázku 1. Ze všech zobrazených scénářů jsou pouze scénáře 1 a 3 vhodné pro praktické používání, protože ostatní mají stejné problémy s rozšířitelností jako samostatná IntServ architektura. Obrázek 1 - Možné scénáře spolupráce IntServ a Diffserv architektur 52-1
2 Intserv / Diffserv architektura Hlavní cíl Intserv/Diffserv architektury je samozřejmě koncová QoS rozmístěná v současném Internetu. Návrh Intserv/Diffserv architektury je motivován následujícími cíli: Co nejméně nových změn v existujících architekturách - S IntServ/DiffServ architekturou budou samozřejmě uvedeny nové mechanizmy ve stávajících síťových architekturách, ale tyto mechanismy by neměly změnit současné řešení Intserv nebo Diffserv architektury. Hlavní operace Intserv/Diffserv spolupráce by měly být vykonávány na hranicích mezi Intserv a Diffserv doménami - Hlavní operace IntServ/DiffServ součinnosti budou vykonávány v okrajových zařízeních buď v Intserv, nebo Diffserv regionu. Tyto zařízení budou mít režii s manipulací RSVP/Intserv zpráv a Diffserv paketů. Snadno rozšířitelná pro využívání v bezdrátovém síťovém prostředí - Intserv/Diffserv architektura je určena pro tradiční "drátované" sítě, ale s cílem rozmístit ji v bezdrátovém prostředí. V těchto sítích by bylo její využívání ještě cennější z důvodu nedostatku zdrojů v těchto sítích. Podle výše uvedených cílů existují pro správnou funkčnost IntServ / DiffServ architektury určité požadavky na síťové prvky: RSVP/IntServ okrajová síť - Okrajová síť musí být založena na RSVP/IntServ architektuře, která generuje RSVP signalizaci s IntServ parametry a která vykonává v síťových prvcích IntServ kontrolu přístupu na příchozích datech. Podrobný popis RSVP signalizace naleznate v [2]. DiffServ vnitřní síť - Vnitřní síť musí být založena na DiffServ architektuře s podporou řízení agregovaných datových proudů. Dále musí nabízet přinejmenším dvě úrovně služeb, například "Best Effort" a AF PBH. Tato síť se může skládat z jediné administrativní domény nebo několika administrativních domén. IntServ/DiffServ zákaznicko-poskytovatelský vztah - V IntServ/DiffServ architektuře mají RSVP/IntServ okrajové sítě a DiffServ vnitřní síť zákaznickoposkytovatelský vztah. To znamená, že RSVP/IntServ okrajová síť je jen další zákazník DiffServ vnitřní sítě. DiffServ síť je transparentní pro RSVP/IntServ zprávy - DiffServ domény mohou obsahovat prvky s podporou RSVP protokolu. Z tohoto důvodu mohou vykonávat RSVP signalizaci a kontrolu přístupu. Aby byly přichozí RSVP zprávy z RSVP/IntServ domény pro DiffServ doménu "neviditelné", jsou tyto zprávy tunelovány přes DiffServ domény. Tunelování RSVP zprávy přes DiffServ domény bude vykonáváno nezávisle na specifických realizacích DiffServ domény. DiffServ okrajové zařízení (hraniční směrovač) bude RSVP/IntServ-DiffServ (RID) směrovač - Zařízení nebo směrovač, který bude mít hlavní roli v IntServ/DiffServ součinnosti, je okrajový směrovač nacházející se v DiffServ doméně. Tento požadavek byl motivován těmito důvody: o IntServ doména je považovaná za zákazníka DiffServ směrovače. Proto je přirozené, že majitel DiffServ regionu se pokusí uspokojit požadavky svého o zákazníka. Takto bude snadno rozšířitelný o dynamické přidělování zdrojů v DiffServ doméně. DiffServ okrajové zařízení (hraniční směrovač) bude vykonávat funkce souvisejíci s RSVP tunelem - DiffServ okrajové směrovače budou také koncové body tunelu RSVP. 52-2
2.1 Referenční síť IntServ/DiffServ Architektury Výše uvedené cíle návrhu a požadavky na design IntServ/DiffServ architektury mají za následek specifickou realizaci se zřetelně definovanými funkcemi jednotlivých prvků. IntServ/DiffServ referenční síť je ukázaná na obrázku 2. IntServ/DiffServ architektura je založena na statickém zásobení DiffServ regionu zdroji. IntServ region, který je zákazníkem DiffServ regionu, vyjedná smlouvu zajišťující úroveň služeb (SLS) s majitelem DiffServ regionu. Bude se jednat statický kontrakt (statický SLS), který definuje službu a její parametry. Tyto služby jsou poskytnuty DiffServ vnitřní sítí RSVP/IntServ okrajová sítím. Pro každého zákazníka existuje aspoň jedna vyjednaná a nakonfigurovaná SLS v okrajových zařízeních. Obrázek 2 - Referenční síť IntServ/DiffServ architektury 2.2 Směrovače IntServ / DiffServ architektury IntServ/DiffServ architektura obsahuje několik druhů směrovačů (viz. obrázek 2): IntServ směrovače (IntServ Router - IR) - jedná se o standardní RSVP/IntServ směrovače, který vykonávají RSVP signalizaci, kontrolu přístupu a plánování paketů. Tyto směrovače jsou podrobně popsány v [1]. Okrajové směrovače (Edge Router - ER) - jenž se nacházejí na hranici RSVP/IntServ domény. Jedná se o standardní RSVP/IntServ směrovače stejně jako jiné IntServ směrovače (IR) v RSVP/IntServ okrajových sítích. Tyto směrovače také vykonají RSVP signalizaci, kontrolu přístupu, úpravu a plánování paketů pro jednotlivé datové proudy. Okrajové směrovače mohou také vykonávat určité funkce související s IntServ/DiffServ součinností v případě, že IntServ/DiffServ architektura je rozšířena o podporu dynamických SLS. DiffServ okrajové směrovače (DiffServ Border Routers - BR) - propojují DiffServ síť buď s jinými DiffServ doménami, nebo s RSVP/IntServ doménami. Tyto 52-3
směrovače musí vykonávat funkce úpravy provozu, tak jak jsou definované v SLS mezi svou DiffServ doménou a doménou, se kterou jsou spojeny. V případě že jsou připojeny k RSVP/IntServ doméně, vykonávají funkce související se součinností RSVP/IntServ-DiffServ. To znamená, že zpracovávají oba druhy paketů (RSVP/IntServ a DiffServ). Musí také vykonávat kontrolu přístupu na RSVP zprávách podle aktualního množství zdrojů v DiffServ doméně a provádějí mapování IntServ služeb na vhodné DiffServ služby. Zároveň vykonávají funkce související s tunelováním RSVP zpráv přes DiffServ doménu. Dále je tento směrovač uváděn jako RSVP/IntServ - DiffServ (RID) okrajový směrovač [5]. V [4] tyto RID směrovače působí jako DiffServ vstupní uzly a jako DiffServ výstupní uzly pro různé směry datových proudů. Data vstupují do DiffServ sítě ve vstupním RID směrovači. Ten je zodpovědný za zajištění, že tyto data budou přizpůsobena SLS vyjednané mezi DiffServ sítí a okrajovou sítí, ke které je vstupní uzel připojen, tj. RSVP/IntServ okrajová síť nebo další DiffServ doména. Data opouští DiffServ síť ve výstupním RID směrovači. DiffServ vnitřní směrovače (DiffServ Core router - DR) - jedná se o standardní DiffServ směrovače, které aplikují příslušné úrovně služeb (PHB) na pakety podle hodnoty jejich DS codepointu. Mohou také vykonávat některé omezené funkce úpravy provozu jako například přeznačení DS codepointů paketů. Protože RSVP signalizační zprávy budou zapouzdřené, DiffServ vnitřní směrovač je nezpracuje dokonce i v případě, že by obsahoval podporu protokolu RSVP. Tyto směrovače jsou podrobně popsány v [3]. RSVP/IntServ-DiffServ (RID) okrajový směrovač V IntServ/DiffServ architektuře budou plnit hlavní funkce součinnosti mezi DiffServ a IntServ okrajové síťové prvky, které se nachází v DiffServ doméně. Okrajový směrovač je DiffServ směrovač s podporou protokolu RSVP, který bude pracovat jako překladač mezi DiffServ a RSVP/IntServ daty. Tento směrovač bude také vykonávat funkce související s tunelováním RSVP zpráv přes DiffServ domény. 2.3 Model RID okrajového směrovače Protože RID okrajový směrovač je také DiffServ směrovač, jeho model [5] bude podobný modelu DiffServ směrovače. Model okrajového směrovače by měl také zahrnovat součásti pro RSVP/IntServ-DiffServ překlad. Obecně se směrovač skládá ze směrujícího jádra a několika rozhraní připojených k tomuto směrujícímu jádru. Rozhraní budou v závislosti na směru dat fungovat jako vstupní nebo výstupní. Každý z nich bude obsahovat funkční prvky pro manipulaci s datovým provozem. Z tohoto důvodu bude každé rozhraní obsahovat klasifikátory a prvky pro úpravu datového provozu. Tyto součásti budou realizovat nakonfigurované úrovně služeb (PHB). Navíc v případě RID směrovače budou muset vstupní a výstupní rozhraní obsahovat také přídavné prvky. Tyto prvky budou manipulovat s daty, které obsahují signalizační zprávy RSVP protokolu, a budou také vykonávat příslušný překlad RSVP/IntServ služby na DiffServ službu. Funkční prvky pro manipulaci s daty budou v tomto případě rozděleny na ovladač DiffServ paketů a ovladač RSVP zpráv. Ovladač DiffServ paketů se skládá ze standardních DiffServ prvků pro úpravu provozu a prvků pro řazení paketů do front [3]. Ovladač RSVP zpráv bude vykonávat omezený soubor funkcí standardního RSVP/IntServ směrovače. Rozhodnutí o tom, zda-li vstupující provoz má být ošetřen v RSVP ovladači zpráv nebo DiffServ ovladači paketů, je vykonané vstupním rozhraním, které je konfigurované pro klasifikaci RSVP zpráv a datových paketů. RSVP zprávy a DiffServ pakety budou 52-4
zpracovány odděleně ovladačem RSVP zpráv a ovladačem DiffServ paketů. Daný model RID hraničního směrovač je zobrazený na obrázku 3. Hlavní funkční prvky jsou vstupní klasifikátor, ovladač RSVP zpráv, standardní ovladač DiffServ paketů a výstupní rozhraní realizující PHB. Architektura RID okrajového směrovače Architektura RID hraničního směrovače a jeho funkční prvky, které jsou založené na modelu popsaném výše, jsou ukázány na obrázku 3. Obrázek 3 - Architektura RID okrajového směrovače DiffServ prvky úpravy provozu a prvky pro řazení paketů do front jsou zcela shodné s prvky standardních DiffServ směrovačů [3]. Tyto prvky raelizují nakonfigurované úrovně služeb. Klasifikátor dat RID hraničního směrovače má stejnou funkčnost jako klasifikátor ve standardních DiffServ směrovačích. V případě RID hraničního směrovače by měl být klasifikátor nakonfigurován tak, aby klasifikoval signalizační RSVP zprávy a DiffServ pakety. Filtry pro třídění RSVP signalizačních zpráv a DiffServ paketů a jejich výsledný výstupní toky jsou ukázané v tabulce 1. Tabulka 1 - Realizace klasifikátoru paketů v RID směrovači Prvky pro ovládání RSVP zpráv obsahují RSVP manažera, kontrolu přístupu, kontrolu rychlosti a modul mapování služeb. RSVP manažer bude vykonávat podobné funkce jako RSVP proces. Bude podporovat PATH a RESV stavy přichozích RSVP zpráv, ale také bude zpracovávat odpovídající chybové zprávy. Při přijetí RSVP zprávy spustí kontrolu rychlosti a kontrolu přístupu. RSVP manažer bude také ve spolupráci se směrováním rozhodovat, na 52-5
které rozhraní mají být RSVP zprávy poslány a tunelovány. Kontrola rychglosti a kontrola přístupu má stejnou funkčnost jako v standardních RSVP/IntServ směrovačích [1]. Navíc budou nakonfigurovány pro vykonávání kontroly přístupu na RSVP zprávách podle množství zdrojů v celé DiffServ doméně. Jakmile je rezervační žádost přijatá, je spouštěno mapování RSVP/IntServ služby na DiffServ službu. Prvek mapování služeb Existují různé způsoby jak namapovat IntServ služby k DiffServ službám. Prvek mapující služby bude vykonávat mapování IntServ služby k DiffServ službě na RSVP paketech, které prošly kontrolou rychlosti a kontrolou přístupu. Podle výsledků těchto kontrol přiřadí vhodnou úrověň služeb (PHB) [3]. Výsledek mapování služeb je poslán do klasifikátoru paketů. Datové pakety přicházející do RID okrajového směrovače jsou identifikované klasifikátorem a označeny vhodným DS codepintem podle informací přijatých od prvku mapování služeb. Dále budou datové pakety zpracované standardními DiffServ způsobem. Možnosti mapování IntServ služby na DiffServ služby jsou zobrazeny v tabulce 2. Tabulka 2 - Standardní mapování IntServ služeb na DiffServ PBH Jak je vidět z tabulky 2. Služba s řízenou zátěží (CL) muže být namapován na různé režimy zasílání (PHB), tzn. na různé DiffServ úrovně služeb. Zaručená služba (GS) smí být namapována pouze na nejvyšší úroveň DiffServ služby, tj. EF PHB. Podrobně jsou tyto DiffServ služby popsány v [6], [7]. 3 IntServ/DiffServ Architektura - příklad provozu Obrázek 4 - Souslednost událostí při přenosu dat v IntServ/DiffServ architektuře Pro lepší pochopení IntServ/DiffServ architekury uvedu příklad přenosu dat [4] (viz. obrázek 4): 1. Host1 generuje RSVP PATH zprávu. 2. PATH stav je nainstalován v ER1 a PATH zpráva je poslána do DiffServ regionu. 3. RID-BR1 zpracuje PATH zprávu, zapouzdří ji a tuneluje ji přes DiffServ region. 4. RID-BR2 přijímá PATH zprávu, zpracuje ji, odpouzdří a pošle do ER2. 5. PATH zpráva je zpracována v ER2 v standardním RSVP/IntServ způsobem. 6. PATH zpráva dosáhne Hosta2, který vygeneruje RESV zprávu. 7. RESV zpráva je poslána zpět k Hostu1. 8. ER2 zpracuje RESV zprávu standardním způsobem, a jestliže není odmítnuta je poslaná do RID-BR2. 52-6
9. RID-BR2 zpracuje RESV zprávu, zapouzdří ji a tuneluje ji přes DiffServ region. 10. DiffServ vnitřní směrovače přenesou zapouzdřené RSVP zprávy transparentně bez jejich zpracování. 11. Jakmile je RID-BR1 v RESV zprávě odpouzdřena, spustí kontrolu přístupu podle vyjednané statické SLS. Jestliže jsou požadované zdroje dostupné, je poté klasifikátor nastaven pro třídění dat patřících do příslušné úrovné služeb (PHB) podle nakonfigurovaného mapování. Poté RSVP zpráva je poslaná do ER1. 12. ER1 zpracuje RESV RSVP zprávu stardandním IntServ způsobem, a jakmile je rezervace přijata, pošle RESV zprávu k cíli. 13. Host1 přijíme RESV RSVP zprávu a začne poslání datových paketů, které jsou zpracované v IntServ domémě jako standardní Intserv pakety. 14. Datové pakety, které přijdou do RID-BR1 budou klasifikovány a přeznačeny na vhodný DSCP podle nakonfigurovaného mapování služeb. 15. V DiffServ vnitřních směrovačích budou zpracovaný jako standardní DiffServ pakety. 16. Jakmile přijdou do IntServ regionu, budou zpracovány standardním IntServ způsobem. 4 Závěr Z charakteru jednotlivých modelů vyplívá, že Intserv bude nasazen především v okrajových sítích Internetu a Diffserv ve vnitřních, proto je důležitá jejich efektivní spolupráce. Aby byla daná spolupráce možná, byl v navržen síťový prvek tzv. RID směrovač, který tuto spolupráci umožní. Tento směrovač tvoří nejdůlěžitější část RSVP/IntServ-DiffServ architektury. Jedná se o překladač mezi IntServ a DiffServ službami. RID směrovač bude mít proto režii se vzájemným překladem těchto služeb. Dále v měm musí být realizován mechanizmu umožňující tunelování RSVP zpráv přes DiffServ domény. Pomocí těchto mechaniznů implementovaných v tomto směrovači je umožněna koncová QoS mezi jednotlivýmí zařízeními v IP sítích, tzn. především v dnešním Internetu. Slovník pojmů Klasifikátor - prvek, který vybere pakety na základě určitých informací obsažených v hlavičce paketů a podle definovaných pravidel. DS codepoint - TOS oktet v IPv4 hlavičce nebo oktet třídy provozu v IPv6. Dohoda úrovně služeb (Service Level Specifications - SLS) - smlouva mezi zákazníkem a poskytovatelem služeb, která specifikuje poskytovanou službu. Zákazník může být uživatelská organizace (zdrojová doména) či jiná DS doména. SLA může obsahovat dohody o úpravě provozu (TCA). Úprava provozu - prvek, který vykonává funkce úpravy provozu a který může obsahovat měřiče, značkovače, zahazovače, a tvarovače. PATH zpráva - zpráva, která je v IntServ posílána k příjemci služby. RESV zpráva - zpráva, kterou posílá příjemce služby zpět vysílači služby. Kontrola rychlosti - jedná se o kontrolu, která probíhá v IR směrovačích. Hlídá, zda-li datová rychlost pro daný datový proud nepřekročí rezervovanou úroveň. Zkratky AF PHB - Assured Forwarding PHB BR - DiffServ Border Router CL - Conrol Load Service DiffServ - Diffentiated Services DR - DiffServ Router DS - DiffServ 52-7
EF PHB - An Expedited Forwarding PHB ER - Edge Router GS - guaranteed service IntServ - Integrated Services IR - IntServ Router PHB - Per Hop Behavior QoS - Quality of Services RID - RSVP/IntServ-DiffServ RSVP - Resource Reservation Protocol SLS - Service Level Specifications Literatura [1] Kolektiv autorů. Integrated Services in the Internet Architecture: an Overview. IETF. Červen 1994. Dostupné na WWW: <http://www.ietf.org/rfc/rfc1633.txt?number=1633> [2] Kolektiv autorů. Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification. IETF. Září 1997. Dostupné na WWW: <ftp://ftp.rfc-editor.org/innotes/rfc2205.txt> [3] Kolektiv autoru. An Architecture for Differentiated Services. IETF, Prosinec 1998. Dostupné na WWW: <http://www.ietf.org/rfc/rfc2475.txt?number=2475> [4] Kolektiv autoru. A Framework for Integrated Services Operation over Diffserv Networks. IETF. Listopad 2000. Dostupné na WWW: <ftp://ftp.rfc-editor.org/innotes/rfc2998.txt> [5] Rexhepi, V.. Heijenk, G. J.. Interoperability of Integrated Services and Differentiated Services Architectures. University of Twente. 30.10. 2000. [6] Kolektiv autoru. Assured Forwarding PHB Group. IETF. Červen 1998. Dostupné na WWW: <ftp://ftp.rfc-editor.org/in-notes/rfc2597.txt> [7] Kolektiv autoru. An Expedited Forwarding PHB. IETF. Červen 1998. Dostupné na WWW: <ftp://ftp.rfc-editor.org/in-notes/rfc2598.txt> 52-8