Integrované služby

Integrované služby ( anglicky  Integrated services, IntServ ) - v počítačových sítích architektura správy zdrojů, která poskytuje danou kvalitu služeb ( QoS ). Metoda používaná integrovanými službami vyžaduje architekturu protokolu, kterou je obtížné škálovat. Problém škálovatelnosti souvisí s principem fungování integrovaných služeb, při kterých se provádí end-to-end rezervace zdrojů ve všech prvcích, které tvoří síťovou vrstvu aplikace.

Historie

Pozoruhodný růst internetu vedl k výraznému nárůstu provozu. Vznik nových typů aplikací, jako jsou webové aplikace, video v reálném čase, IP telefonie a mnoho dalších, donutil specialisty hledat nové způsoby řízení síťového provozu. Jedním z nedávných rozhodnutí bylo využití integrovaných služeb, které kombinují všechna navrhovaná řešení.

Úvod

Standardní protokoly TCP/IP stacku poskytují služby v maximální možné míře a dávají stejnou prioritu všem požadavkům. Při transportu streamovaného mediálního provozu (VoIP, audio a video konference a další) nebo datového provozu s různými požadavky na šířku pásma po stejné síti je nutné umět zpracovávat a klasifikovat různé typy síťového provozu, ať už v závislosti na požadavcích, popř. obsah . Nezaručené doručení neznamenalo žádné odlišení provozu a neposkytovalo spolehlivé doručení, garantovanou kapacitu kanálu nebo nízkou ztrátovost paketů.

Pro vyřešení všech výše uvedených problémů negarantovaných dodávek byly vytvořeny následující dva modely kvality služeb [1] :

Funkce

Před odhalením tohoto tématu stojí za to definovat pojem proudění . Pod pojmem "flow" budeme rozumět nepřetržitý provoz generovaný uživatelem nebo aplikací a vyžadující stejnou kvalitu služeb. Ve verzi IPv4 je tok určen na transportní vrstvě používaného protokolu (buď TCP nebo UDP ) přes porty a IP adresy zdroje a cíle. Verze IPv6 má také pole speciálně vytvořené pro tuto funkci, které spolu se zdrojovou a cílovou adresou charakterizuje tok. Toto pole se nazývá jmenovka proudu.

V rámci modelu integrovaných služeb lze rozlišit následující důležité subsystémy [1] :

  1. Řízení přístupu
  2. Klasifikátor paketů
  3. Plánovač balíčků
  4. Aktivní správa front

Řízení přístupu

Jak již bylo zmíněno dříve, před odesláním informací prostřednictvím sítě jsou zdroje rezervovány v souladu s požadovanou kvalitou služby. Při obsluze nového toku se provádí prohlášení o požadavcích na kvalitu služby (podle specifikace požadavku na službu - RSPEC ) a získávají se charakteristiky provozu, který by měl být odeslán sítí (podle specifikace provozu - TSPEC ). Pokud router nemá dostatek volných zdrojů pro obsluhu nového toku, bude takový tok odmítnut. Pokud mohou být požadavky nového toku splněny, pak směrovač dá pokyn plánovači a klasifikátoru paketů, aby si vyhradili část svých zdrojů pro zajištění kvality služby požadované pro tento tok.

V RSPEC lze rozlišit následující kategorie tokových služeb:

RSPEC a TSPEC jsou poskytovány protokolem rezervace síťových prostředků RSVP .

Klasifikátor balíků

Klasifikátor paketů identifikuje tokové pakety na směrovačích. Každý příchozí paket patří do určité třídy. Balíčky, které jsou rozděleny do tříd, obdrží stejné zpracování pro svou třídu z plánovače balíčků. Výběr konkrétní třídy závisí na prioritách odesílatele a příjemce, IP adrese a čísle portu v hlavičce paketu. Vlákna stejného typu zpravidla patří do stejné třídy.

Plánovač balíků

Plánovač paketů pomocí systému řízení fronty reguluje odesílání paketů směrovačům v souladu s výše uvedenou klasifikací a parametry kvality služeb specifikovanými pro každý tok. Plánovač paketů musí fungovat v bodě, kde jsou pakety zařazeny do fronty. Tímto bodem jsou obvykle protokoly spojové vrstvy v operačním systému routeru.

Aktivní správa front

Aby se předešlo přerušením v síti, je zajištěno řízení přetížení. Existují tři způsoby implementace řízení zahlcení vyloučením paketů:

RSVP

RSVP nebo Resource Reservation Protocol, je značkovací protokol, který umožňuje uživatelům sdělovat své požadavky na spolehlivost a efektivitu do sítě. Navzdory skutečnosti, že RSVP je simplexní protokol, tj. redundance se vyskytuje pouze v jednom směru, byl koncipován pro duplexní připojení. Pro duplexní připojení, jako jsou audio nebo video konference, kde je každá strana zároveň odesílatelem i příjemcem, je požadavek na rezervaci zdroje na RSVP odeslán oběma koncovými body.

V rámci protokolu RSVP se používá pojem " cesta " ( anglicky  PATH ). Cesta je cesta, kterou pakety procházejí různými směrovači od odesílatele k cíli. Na této trase se provádějí rezervace zdrojů. Všechny pakety stejného streamu budou sledovat stejnou cestu. Cesta je určena, když odesílatel odešle zprávu RSVP, takzvanou zprávu o cestě. Obsahuje informace o kvalitě provozu služby pro daný tok. Protože RSVP není směrovací protokol, používá informace ze směrovacích tabulek každého směrovače k ​​co nejrychlejšímu doručení zprávy o cestě [1] .

Formát zprávy PATH je následující (údaje v hranatých závorkách jsou nepovinné):

Common Header, [Integrity], Session, RSVP_Hop, Time Values, [Policy_Data], Sender Template, Sender_Tspec, [ADSPEC]

Po obdržení zprávy o cestě jsou směrovače připraveny rezervovat zdroje pro tok. Pro rezervaci určitých parametrů QoS odešle přijímač zprávu RESV . Každé zařízení, které podporuje protokol RSVP, již zná adresu předchozího zařízení na trase, takže zpráva RESV putuje zpět k odesílateli a sděluje tranzitním směrovačům požadované parametry pro rezervaci zdrojů.

Formát zprávy RESV je následující:

Common Header, [Integrity], Session, RSVP_Hop, Time Values, [Reso_Confirm], [Scope], Style, Flow Descriptor List

Některá upřesnění:

Je třeba poznamenat, že tento způsob rezervace zdrojů je možný pouze v případě, že všechny margrutizery na trase podporují protokol RSVP. Při absenci podpory RSVP může nebo nemusí zprostředkující směrovač splňovat požadavky QoS v závislosti na jeho zatížení. Kompletní specifikace protokolu RSVP je definována v RFC-2205.

Hlavní problém

Přestože myšlenka IntServ a RSVP byla v polovině 90. let velmi slibná, zájem o tuto architekturu časem vyprchal. Hlavním důvodem byl problém se škálovatelností způsobený potřebou ukládat a udržovat informace o stavu přenosu v každém routeru. Tento problém, přenesený do sítí WAN, jako je internet, odvádí RSVP od reality. V poslední době se však znovu začalo mluvit o použití RSVP v MPLS nebo v dopravním inženýrství, protože v těchto případech je hodnota provozu malá, což ji činí lépe ovladatelnou a snižuje náklady na zařízení.

Poznámky

  1. 1 2 3 Tanenbaum E., Weatherall D. Počítačové sítě . 5. vyd. - Petrohrad: Petr, 2012 - Ch. 5.4

Literatura

Odkazy