| Název: | QoS v IP sítích |
| Autor: | Petr Panáček |
| Publikováno: | LANCom 11/2002 |
Protokol IP (Internet Protocol) verze 4 je nejrozšířenějším komunikačním protokolem v současných počítačových sítích. Protokol IP se používá jak v podnikových sítích, tak v sítích ISP (Internet Service Provider). Je na něm založena i největší celosvětová síť - Internet. V těchto sítích se provozují aplikace s různými nároky na parametry komunikace neboli kvalitu služby QoS (Quality of Service). Těmito parametry mohou být zpoždění IP paketů, rozptyl zpoždění, požadované přenosové pásmo, ztrátovost paketů apod. Jakými prostředky lze v IP sítích zajistit, aby požadovaná kvalita služby byly splněna a zmíněné aplikace mohly uspokojivě fungovat ?
Organizace IETF (Internet Engineering Task Force) definovala dva modely pro zajištění kvality služeb v IP sítích - Integrated Services (IntServ) definovaný v RFC 2210, 2211, 2212, 2215 a Differentiated Services (DiffServ) definovaný v RFC 2474, 2475, 2597, 2598.
V modelu IntServ koncová komunikující zařízení signalizují síti své požadavky na QoS. Pro signalizaci se využívá protokol RSVP (Resource Reservation Protocol). Pro každý individuální datový tok v síti je protokolem RSVP signalizována požadovaná kvalita služby a síťová zařízení si na základě signalizace rezervují dostatečné prostředky, aby mohly službu v požadované kvalitě poskytnout. Tímto způsobem je tedy možné pro každý datový tok v síti zajistit (alespoň teoreticky) požadovanou kvalitu služby. Tento přístup má však řadu nevýhod. Všechna zařízení přes která procházejí IP pakety datových toků a pro které je potřeba zajistit určitou kvalitu služby, včetně koncových zařízení (PC, servery), musí podporovat protokol RSVP. Každý směrovač v síti musí udržovat stavovou informaci pro každou rezervaci (každý datový tok s požadavkem na zajištění kvality služeb), je rozšiřitelnost IntServ modelu omezená. Ve větších sítích, kde množství datových toků roste do statisíců, bychom narazili na vysoké paměťové a výkonnostní nároky na směrovače. Proto bychom model IntServ stěží hledali v sítích service providerů. V podnikových sítích však nalézá model IntServ uplatnění např. při zajišťování QoS pro přenos hlasu v IP síti, kdy před ustavením komunikace probíhá kontrola přijetí spojení (CAC - Connection Admission Control) právě protokolem RSVP.
Model DiffServ se snaží problematiku zajištění kvality služby zjednodušit a snižit tak nároky na systémové zdroje uzlů sítě. Datové komunikace jsou klasifikovány (agregovány) do několika málo tříd (CoS - Class of Service) a pro tyto třídy jsou následně zajištěny požadované parametry QoS. IP pakety lze klasifikovat do různých tříd s využitím pole ToS (Type of Service) v paketu IPv4 resp. TC (Traffic Class) v paketu IPv6. Pro tento účel se využívá 6 bitová hodnota DSCP (Differentiated Services Code Point) v poli ToS resp. TC. Pakety jsou klasifikovány do tříd na okraji sítě a následně jsou v každém síťovém uzlu zpracovány tak, aby byly dodrženy parametry QoS pro danou třídu paketu. Uvedené zpracování dle příslušnosti k dané třídě se formálně označuje jako PHB (Per-Hop Behavior). V modelu DiffServ nedochází k signalizaci požadavků na QoS. Počet stavových informací, které je potřeba v síťových uzlech udržovat je oproti modelu IntServ značně zredukován.
Dříve než se objevily zmíněné modely IntServ a DiffServ pro zajištění QoS na 3. vrstvě modelu OSI (síťová vrstva) existovala podpora pro QoS na 2. vrstvě modelu OSI (linková vrstva). Technologie jako ATM nebo FrameRelay disponují bohatou podporou pro zajištění QoS. Podmínkami pro dosažení opravdové end-to-end podpory QoS jsou nezávislost implementace na médiu resp. na technologii 2. vrstvy OSI a vzájemná interoperabilita (mapování) mezi QoS na 2. a 3. vrstvě modelu OSI. Modely IntServ a DiffServ lze implementovat nad technologiemi ATM a FrameRelay a s výhodou přitom využít QoS podporu, která je v těchto technologiích k dispozici. V případě modelu DiffServ lze např. IP pakety na základě hodnoty v poli ToS vyslat přes různé ATM PVC nebo SVC. FrameRelay mechanismy jako FRTS (FrameRelay Traffic Shaping) a FRF.12 (fragmentace a interleaving paketů na pomalých FrameRelay linkách) lze použít jako doplněk ke službám IP QoS.
Jakými nástroji lze zajistit odpovídající kvalitu služby? Uvádíme jejich stručný přehled a vysvětlení s ohledem na implementaci v operačním systému směrovačů firmy Cisco (Cisco IOS):
- klasifikace (Clasification)
- řazení do front a plánování (Queueing and Scheduling),
- prevence před zahlcením (Congestion Avoidance),
- omezení a úprava rychlosti (Policing and Shaping),
- signalizace (Signaling),
- optimalizace linkové vrstvy (Link Efficiency Mechanisms).
Klasifikace
Pakety vstupující do sítě mohou být klasifikovány a "obarveny" ve smyslu vyžadované třídy služeb. Směrovače zacházejí s pakety podle "barvy" paketu.
Cisco IOS dovoluje provádět klasifikaci podle několika různých kritérií. "Barva" přidělená paketu procesem klasifikace slouží jako primární parametr pro další zacházení v síti. Pole "barvy" může být využito například na vyhrazení určitého přenosového pásma linky, zajištění zpoždění a jeho variance v přípustných mezích nebo jako vstupní parametr procesu prevence před zahlcením.
Nástroje Cisco IOS podporují kódování "barvy" do bitů IP precedence (tři nejvýznamnější bity pole ToS - Type of Service), nebo do bitů DSCP (Differentiated Services Code Point) pole DS (Differentiated Services) v rámci modelu DiffServ (uvedeno v dalším textu).
Klasifikaci lze provádět například pomocí následujících nástrojů Cisco IOS:
Commited Access Rate (CAR)
CAR klasifikuje pakety podle obsahu pole precedence záhlaví IP paketu, adres nebo portů, hlídá charakteristiky datového toku a dovoluje definovat akci při překročení mezních hodnot.
Class Based Packet Marking
Nástroj poskytuje obdobné možnosti jako CAR. Podporuje práci s polem DSCP i IP precedence v záhlaví IP paketu.
Řazení do front a plánování
Všem soudobým technologiím přenosu hlasu pomocí protokolu IP slouží pro transport hlasové informace protokol RTP (Realtime Transport Protocol). Pro zajištění kvalitního přenosu hlasu musí síť minimalizovat možné zpoždění, varianci zpoždění a ztrátovost RTP paketu. Sítě WAN, vybudované na pomalých a intenzivně využívaných komunikačních spojnicích o rychlostech menších než 2 MB/s, vyžadují užití takových algoritmů, které zajistí striktní (absolutní) prioritu paketům protokolu RTP a zároveň poskytnou zbytek přenosového pásma k rovnoměrnému sdílení datových aplikací. Uvedené funkcionality lze dosáhnout pomocí následujících nástrojů řazení paketů do front a plánování:
Weighted Fair Queueing (WFQ)
Algoritmus WFQ automaticky detekuje individuální toky a přiřazuje jim váhu podle hodnoty pole precedence záhlaví IP paketu. K detekci WFQ využívá například zdrojové a cílové adresy, protokol a port paketu. Přidělená váha a délka paketu ovlivňuje množství přenosového pásma, které bude toku přiřazeno vzhledem k ostatním tokům. Algoritmus upřednostňuje kratší rámce oproti delším. Takto mohou být interaktivní sezení obsloužena přednostně.
Class Based WFQ (CBWFQ)
Algoritmus CBWFQ rozšiřuje vlastnosti WFQ o uživatelem definovatelné třídy s přidělenou šířkou přenosového pásma. Poskytuje větší flexibilitu oproti WFQ. Vlastnost může být kombinována s LLQ, nebo IP RTP Prioritou. Rozdělení paketů do tříd lze zajistit pomocí access listu. Podporuje práci jak s polem precedence, tak s DSCP v záhlaví IP paketu. CBWFQ dovoluje s přihlédnutím k šířce přenosového pásma definovat až 64 tříd.
IP RTP Priority
Nástroj dovoluje definovat frontu využívající algoritmus striktní priority pro rámce protokolu RTP, jež obsahují hlasovou informaci. Umožňuje definovat paketům se striktní prioritou maximální šířku přenosového pásma v kb/s a současně omezit počet paketů vkládaných do fronty podle rozsahu UDP portů. Vlastnost je obzvláště užitečná v prostředí s pomalými linkami. Může být kombinována jak s algoritmy WFQ, tak s CBWFQ.
Low Latency Queueing (LLQ)
LLQ poskytuje podobné možnosti jako IP RTP priorita. Vlastnost umožňuje definovat frontu pro pakety se striktní prioritou v rámci CBWFQ. Navíc rozšiřuje možnosti IP RTP priority na virtuální kanály ATM.
Prevence před zahlcením
Techniky prevence před zahlcením monitorují zátěž sítě ve snaze předvídat a předejít zahlcení ještě než k němu skutečně dojde. Algoritmy jsou navrženy za účelem zajištění maximální průchodnosti a využití kapacity sítě při snaze o minimalizaci ztrátovosti a zpoždění paketů. Pro pochopení problému si představme větší množství TCP toků sdílejících společnou linku. Nevyužijeme-li žádného ochranného algoritmu, potom v případě zahlcení linky začne směrovač náhodně zahazovat pakety náležící libovolnému z komunikačních toků, čímž většina koncových uzlů po uplynutí určité doby aktivuje mechanismus opětovného vyslání ztraceného paketu. Uvedený postup vede na problém globální synchronizace v síti, který způsobuje degradaci přenosových rychlostí všech toků, nehledě na jejich prioritu. Algoritmy prevence před zahlcením sledují stav vyrovnávacích pamětí a provádí zahazování paketů pouze u vybraných toků s nejnižší prioritou, proto mohou ostatní toky i nadále procházet bez znatelné degradace rychlosti.
Cisco IOS využívá jako prostředek prevence před zahlcením algoritmus WRED (Weighted Random Early Detection). Jedná se o firemní implementaci algoritmu RED (Random Early Detection) tak, aby využíval hodnotu pole IP Precedence záhlaví IP paketu. Algoritmus RED byl původně navržen pro protokol TCP jako mechanismus adaptivního přizpůsobování rychlosti odesílatele na základě zjištění ztracených rámců. Jestliže dojde k překročení nastavené prahové hodnoty zaplnění fronty směrovače, začnou se náhodně zahazovat pakety TCP datových toků a jejich rychlost se následně sníží.
Omezení a úprava rychlosti
Cisco IOS poskytuje následující nástroje pro omezení a úpravu přenosové rychlosti:
Commited Access Rate (CAR)
CAR kromě klasifikace může rovněž hlídat rychlostní charakteristiky datového toku. Při překročení rychlostních charakteristik může například začít zahazovat pakety nebo změnit hodnotu precedence záhlaví IP paketu sledovaného toku.
Nástroj byl primárně implementován tak, aby docházelo k zahazování rámců při překročení mezních rychlostních limitů, ne za účelem úpravy nebo řazení rámců do front.
Generic Traffic Shapping (GTS)
Nástroj není určen (na rozdíl od CAR) k zahazování rámců při překročení mezních rychlostních limitů. Zařízení musí používat GTS tam, kde je známo, že následující uzel implementuje omezení rychlosti (např. pomocí CAR). Algoritmus má za úkol snížit rychlost vysílání paketů.
Signalizace
Cisco IOS podporuje signalizaci QoS v síti pomocí protokolu RSVP.
Optimalizace linkové vrstvy
V případě, že komunikační síť, která má poskytovat hlasové služby, využívá pomalé komunikační spojnice s kapacitou menší jak 1 Mb/s, je třeba zohlednit i aditivní zpoždění přenosu hlasové informace. Toto aditivní zpoždění přenosu hlasové informace může být způsobeno blokováním výstupní linky dlouhým paketem, například během přenosu souboru pomocí protokolu FTP. Toto zpoždění může narůst až na hodnoty pro přenos hlasu neakceptovatelné, obzvlášť když hlasový paket prochází přes několik pomalých komunikačních spojnic.
Tuto problematiku lze řešit prostřednictvím určité optimalizace komunikačního protokolu používaného na pomalé komunikační spojnici. Cisco IOS poskytuje dva efektivní prostředky optimalizace linkové vrstvy - Link Fragmentation and Interleaving (LFI) a Compressed Realtime Transport Protocol (CRTP).
Link Fragmentation and Interleaving (LFI)
Optimalizace spočívá de facto v úpravě (zmenšení) maximální velikosti rámce přenášeného danou spojnicí. Tato úprava zajistí, že krátké hlasové pakety nejsou zpožďovány vysíláním dlouhých datových paketů. Jejich maximální délka totiž podléhá omezení plynoucímu z nastavení maximální velikosti rámce dané spojnice.
Na pronajatých linkách můžeme s výhodou použít LFI mechanismus založený na protokolu MPPP (Multilink Point-to-Point Protocol).
Principem LFI mechanismu využívajícího protokol MPPP je to, že na jedné straně MPPP spojnice směrovač fragmentuje velké pakety datových komunikací na velikost, která zaručuje akceptovatelné zpoždění vysílání krátkých paketů typických pro hlasové komunikace a současně tyto pakety prokládá s pakety hlasových komunikací (tzv. interleaving). Směrovač na protější straně dvoubodové MPPP spojnice pak fragmentované pakety opět skládá do původní velikosti. Na rozdíl od úpravy MTU není v tomto případě nutné natrvalo zmenšovat velikost datových paketů, což má příznivý efekt na celkovou propustnost čistě datových komunikací využívajících obvykle dlouhé pakety. Tento mechanismus rovněž samozřejmě hladce spolupracuje s ostatními mechanismy pro implementaci QoS sítí (řazení paketů do front apod.).
Na Frame Relay linkách lze k obdobnému účelu využít již zmíněnou technologii FRF.12.
Compressed Real-Time Protocol (CRTP)
Za předpokladu, že pro kompresi hlasového signálu použijeme algoritmus G.729 generující datový tok 8 Kb/s a pro transport hlasového signálu použijeme protokol RTP, vyjde nám požadavek na přenosovou kapacitu jednoho hlasového kanálu 24 Kb/s. Pro efektivnější využití dostupné přenosové kapacity je vhodné použít kompresi záhlaví hlasových paketů protokolem CRTP, který redukuje požadavek na přenosovou kapacitu jednoho hlasového toku s využitím kodeku G.729 na hodnotu cca 12 Kb/s.
Výše zmíněné nástroje se dnes s úspěchem využívají pro zajištění kvality služeb v řadě sítí založených na protokolové sadě TCP/IP.
