Služby v reálném čase už nejsou jen fikcí

Na téma kvality služeb (QoS) v IP sítích probíhá bouřlivá diskuze. Stojí zde proti sobě dvě možná řešení: "Dif...


Na téma kvality služeb (QoS) v IP sítích probíhá bouřlivá diskuze. Stojí zde
proti sobě dvě možná řešení: "Diferencované služby" a "Integrované služby",
která by však měla být postupně sloučena do jednoho. Ve své knize "Kvalita
služeb", kterou napsal společně s Geoffem Hustonem, označil Paul Ferguson QoS
jako "nepolapitelného slona". Chce tím říci, že podle úhlu pohledu si pod
pojmem QoS může každý představovat různé věci. Každý by sice chtěl mít kvalitní
služby, ale pro část odborné veřejnosti představuje zmínka o kvalitě služeb v
souvislosti s internetovým protokolem protimluv sama o sobě, pro jiné lze
určité úrovně kvality služeb v sítích IP dosáhnout teprve v budoucnosti nebo v
nejlepším případě až s nástupem IPv6. Třetí skupina zase zastává názor, že
kvalitní služby v sítích IP jsou již realitou.
Standardy
ve světě IP
Normy týkající se IP jsou vyvíjeny v IETF (Internet Engineering Task Force).
IETF je otevřeným grémiem, ve kterém neexistuje žádné formální členství. Dělí
se na pracovní skupiny, zabývající se určitým odborným tématem. Každý se může
na tvorbě standardů podílet pomocí veřejných adresářů nebo svou účastí na
setkáních, která se konají třikrát do roka.
O budoucím standardu se nejdříve diskutuje uvnitř pracovní skupiny. Pokud
účastníci dospějí k jakési shodě, je koncept vytvořený ve skupině předán IESG
(Internet Engineering Steering Group. Ta návrhy přezkoumá a pomocí tzv.
poslední výzvy zjišťuje, zda v rámci IETF nejsou nějaké námitky proti nové mu
dokumentu. Po případné dodatečné revizi v pracovní skupině je dokument předán
editorovi RFC k uveřejnění jako navrhovaný standard. Pokud existuje více
nezávisle na sobě vyvinutých implementací, je třeba překonat další krok
standardizačního postupu koncepci standardu. Po plošném nasazení v Internetu se
může daný protokol stát internetovým standardem, což se stává velmi zřídka.
Pojem RFC však nesmíme zaměňovat s jediným standardem. Kromě standardních RFC
existují i další RFC, od neformálních až po žerty.
Jak zajistit dostatečnou kvalitu
Mnozí uživatelé se nejprve soustředí na to, aby v dálkovém provozu zavedli
kvalitní služby tak, že odstraňují místa, kde dochází ke snížení šířky
přenosového pásma. Proto posilují příslušné systémy anebo nasazují vedení s
větší šířkou pásma. Dodatečně se pak přizpůsobí i příslušná lokální síť.
IETF zatím navrhla dvě metody, s jejichž pomocí je možné kvalitu služeb v
sítích IP zaručit:
"Integrované služby" (Int-Serv): U této metody jsou v síti rezervovány
prostředky pro každé připojení. Ve většině případů používá koncový systém
protokol RSVP ("Resource Reservation Protocol" protokol rezervace zdrojů), aby
sdělil své požadavky na parametry provozu. Snaha nastavit a udržet v celé síti
určitý stav pro dané připojení ovšem omezuje možnost odstupňování. Tento
protokol je tedy vhodný především pro aplikace s kontrolovaným počtem
připojení. Do této kategorie patří multimediální aplikace nebo jakékoli
aplikace využívající multicast. Použití v celém Internetu nepřipadá v úvahu.
"Diferencované služby" (Diff-Serv): U těchto služeb jsou připojení rozdělena do
tříd. Zdroje v síti nejsou rezervovány pro jedno připojení, ale pro určitou
třídu. Proto není možné kvalitu služeb rozlišovat tak jemně jako u Int-Serv
nebo v sítích s ATM. Na druhé straně tato poněkud "hrubá metoda" umožňuje
výrazně lepší odstupňování.
Integrované služby: základ RSVP
Int-Serv představuje model služeb "od vstupu po výstup". Kromě provozu typu
"Best Effort" podporuje i přenos multimediálních dat v reálném čase a současně
i řízené rozdělování zátěže na jedno připojení. Požadavek na služby přitom
vychází z koncového systému. ATM zde pro signalizaci používá UNI ("User Network
Interface" uživatelský síťový interface). V oblasti IP sítí představuje
srovnatelný protokol RSVP. Slouží k signalizaci provozních parametrů pro
Int-Serv, ale zatím si udržel přístup i do jiných oblastí. Rezervace,
uskutečněná pomocí RSVP, je stále jednosměrná a lze ji použít pro provoz typu
unicast nebo multicast. Řečové spojení prostřednictvím IP tedy vyžaduje dvě
rezervace, pro každý směr komunikace jednu.
Odesílatel signalizuje své požadavky na spojení ve zprávě "PATH". Tento paket
je označen příznakem Router-Alert (aktivace směrovače), takže každý směrovač,
který podporuje RSVP a leží na cestě mezi odesílatelem a příjemcem, tento paket
analyzuje. Přezkoumá požadavky na zdroje, případně i s pomocí externího
přístupového serveru, zaprotokoluje IP adresu přístupového interface do
RSVP--paketu, který pak pošle dál směrem k určenému příjemci.
Adresát sdělí požadavky na provoz, které jsou pro něj přijatelné, ve zprávě
"RESV", která je předávána podle zaprotokolovaných IP adres od jednoho
směrovače k druhému (od hopu k hopu) směrem k odesílateli. Tímto způsobem je
zajištěno, že jednosměrná rezervace proběhne správně, zvláště u asymetrických
tras. Protože se trasa v síti IP může měnit, musejí se zprávy PATH/RESV
pravidelně opakovat. Pokud se neobjeví, může směrovač rezervaci smazat.
Ověření rezervace pomocí protokolu Cops
Směrovač rozpoznává tok dat na základě IP adresy a IP protokolu a také podle
TCP/UDP čísel portů, u IPv6 pak též podle tzv. flow-labels (návěští). RSVP ale
nepřezkoumává, zda je daná rezervace přípustná. Provedení tohoto úkolu
obstarává speciální přístupový protokol COPS ("Common Open Policy Server").
Je-li aktivní Int-Serv, měla by síť rozlišit, zda se jedná o oprávněnou žádost
o rezervaci, například pro důležitou obchodní aplikaci, anebo zda se nějaký
uživatel v polední pauze baví společenskou hrou s dalšími uživateli. Takováto
rozhodnutí o přístupu vyžadují i jiné metody než Int-Serv; proto vyvinula
skupina RAP ("Resource Administration Policy") v rámci IETF nový model
přístupu: "Common Open Policy Server" COPS.
Síťový přístroj zde přebírá funkci jakéhosi PEP ("Policy Reinforcement Point"
bod posílení přístupu). Pomocí TCP propojení se v PDP ("Policy Decision Point"
bod rozhodování o přístupu) zkoumá, zda je požadovaná akce vůbec proveditelná.
Pomocí COPS si mohou PDP a PEP vyměňovat libovolné informace o přístupu a
konfiguraci. PDP získává své informace např. z protokolu LDAP.
Ačkoliv je struktura Int-Serv dokumentována od roku 1994 a také RSVP existuje
již od roku 1997, bude Int-Serv sotva použit. Příčinou je především dlouhodobě
mizivá podpora v koncových systémech. Protokol RSVP tak podporují pouze
aktuální verze Windows 98 a 2000; podobné to je v oblasti Unixu. Navíc se
provozovatelé sítě obávají nedostatečné možnosti odstupňování. Kromě toho zde
dlouho chyběl přístupový server. Naproti tomu směrovače jsou schopny podporovat
několik tisíc toků dat RSVP.
Diferencované služby: zdroje podle tříd
Model Diff-Serv obeplul úskalí odstupňování, se kterými se potýká Int-Serv,
tím, že rezervuje zdroje na základě jejich provozní třídy. Paket IP je při
vstupu do sítě zařazen do určité třídy a pak je dále předáván podle předem
daných pravidel na základě požadavků jeho třídy služeb.
Ke klasifikaci byla v RFC 791 určena již od roku 1981 část oktetu TOS ("Type Of
Service") v záhlaví IP: 3 bity nazvané "IP Precedence". V rámci standardizace
Diff-Serv však vyšlo najevo, že takto vzniklých možných osm tříd nebude stačit.
Proto bylo zcela změněno určení ostatních, zatím téměř nepoužívaných částí pole
TOS. Osmibitové pole TOS bylo přejmenováno na "Diffserv Field" a nabízí nyní v
tzv. "Diffserv Code Point" shodně s "IP Precedence" 6 bitů ke klasifikaci.
Zbývající 2 bity jsou rezervovány, v současnosti nejsou používány.
Jako základ 64 tříd služeb, které poskytují IPv4 a IPv6, byla standardizována
některá provozní pravidla, platící pro hopy (PHB "Per Hop Behaviour" typ
chování v hopu). Je na výrobcích, jak tuto normu zabudují do svých produktů.
Každá implementace podporuje přinejmenším PHB typu Best Effort.
Metoda "Expedited Forwarding" (spěšné doručování) byla vyvinuta pro provoz v
reálném čase, tedy např. pro přenos řeči přes IP. V řadě čekajících dat
upřednostňuje řečový paket před ostatními daty. Háček je v tom, že hlasový
přenos v IP používá k přenosu dat protokol UDP ("User Datagram Protocol").
Aplikace TCP je proto nutno chránit před "vyhladověním" ve frontě tím, že šířka
pásma, která je k dispozici datům UDP, je co nejvíce omezena.
Další metodou přenosu v rámci Diff-Serv je "Assured Forwarding" (doručování se
zárukou). Ta optimalizuje techniku Best Effort pro aplikace TCP. Tímto způsobem
lze zřídit "olympijské služby" (zlaté, stříbrné, bronzové). Tento standard
rozeznává celkem čtyři třídy provozu, každou ještě rozdělenou na tři podtřídy.
Pro vybudování a správu diferencovaných služeb je zapotřebí speciálních
nástrojů, jak pro klasifikaci, měření či zřízení přístupu. K tomu přistupují
nástroje, kterými lze ovládat fronty a přetížení v jádru sítě. Stupňovatelné
realizace Diff-Serv jsou od konce roku 1997 proveditelné na základě "IP
Precedence", případně od roku 1999 na základě DCP (Diff-Serv Code Points). Tato
metoda bude zaváděna do sítí poskytovatelů služeb i do podnikových sítí.
Zkušenosti a výhledy
Dosavadní zkušenosti z praxe dokládají, že předpoklady realizované v Diff-Serv
skutečně fungují: důležité obchodní aplikace lze odlišit od ostatních; současně
lze do sítě integrovat i služby v reálném čase, jako je řeč, aniž by bylo nutné
slevit na kvalitě. Jako nákladné se ukázalo řízení tříd služeb, případně jejich
zdrojů po trase spojení. Dokud nebudou dostupná adekvátní řešení řízení a
plánování, nedoporučuje se pracovat s velkým počtem tříd. Jako smysluplné se
ukázalo použití dvou tříd pro datové přenosy a jedné třídy pro řeč.
V mnoha podnicích k tomu ještě přistupuje ten problém, že se zcela přesně neví,
jaké jsou požadavky různých aplikací na síť a nebo nelze díky dynamické volbě
portů aplikace přímo klasifikovat. V takovém případě se doporučuje vypracovat
SLA ("Service Level Agreement" dohodu o úrovni služeb) anebo nasadit postupy,
které rozeznají a zpracují data Layer-7, jako je "Network Based Application
Recognition" od firmy Cisco.
Smíření nepřátel
Členové IETF pracují v současné době na tom, aby sloučili Int-Serv a Diff-Serv.
Mohlo by to vypadat takto: aplikace signalizuje prostřednictvím RSVP své
požadavky síti; první směrovač se dotáže přístupového serveru COPS, který zpět
nahlásí potřebná provozní pravidla PHB pro Diff-Serv. Žádost RSVP je pak
směrována k cíli prostřednictvím páteře Diff-Serv. Firmy Microsoft, SAP a Cisco
předvedly tuto metodu loni na veletrhu Networld + Interop v Atlantě.
Na závěr je nutno konstatovat, že kvalita služeb IP již dnes není žádnou fikcí,
i když ještě chybí několik kostek do stavebnice: standardy existují a uživatel
může odpovídající řešení integrovat do své sítě. Největší požadavek pro
budoucnost spočívá v zabudování QoS do správy sítě.
0 0936 / pen

IETF hledá řešení pro QoS
V rámci "Internet Engineering Task Force" (IETF) diskutují odborníci již od
počátku 90. let o tom, jak by bylo možno rozšířit tenkrát již dvacet let starý
postup "Best Effort" (maximální snahy) i pro šíření IP paketů pro aplikace s
mimořádnými nároky na služby. Tato otázka se poprvé objevila v souvislosti s
multimediálními službami, konkrétně s přenosem mítinků IETF pomocí techniky
IP-multicast. Pokus vyřešit to pomocí trvale postačující šířky pásma (tedy
nekonečné), ztroskotal. Exponenciální nárůst objemu přenášených IP dat zatím
dovedl všechny podobné snahy ad absurdum.
IETF vyvinula dvě metody, s jejichž pomocí je možné kvalitu služeb v sítích IP
zaručit: integrované služby (Int-Serv), kde jsou v síti rezervovány prostředky
pro každé připojení, a diferencované služby (Diff-Serv), kde jsou připojení
rozdělena do tříd. Každý z těchto přístupů má svá pro i proti, navíc zde
existuje snaha po jejich sloučení. Budoucnost je tedy otevřená.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.