Protokol RSVP

Úvod

Resource ReSerVation Protocol (RSVP)[1] je standard navržený IETF a je součástí architektury Integrated Services (IntServ). Architektura IntServ je množina IETF standardů určujících jakým způsobem aplikace definuje své požadavky na kvalitu služby (QoS) v lokálních sítích a v Internetu. V rámci IntServ by měl každý síťový prvek zveřejnit své možnosti ovlivnění QoS a své požadavky na QoS. Dle této architektury by také směrovače měly klasifikovat pakety a udržovat stavové informace o každém aktuálním datovém toku. Koncové stanice pak pomocí protokolu RSVP dynamicky žádají zajištění dané QoS a všechny směrovače na cestě od zdroje k požadovanému cíli by tomuto požadavku měly vyhovět. Definice protokolu RSVP je podrobně popsána v RFC2205.

Princip RSVP

Protokol RSVP je určen pro signalizaci požadavků na přenosové pásmo a to především ve velkých lokálních sítích. V Internetu mohou nastat problémy z důvodu, že RSVP musí podporovat všechny směrovače na cestě od odesílatele požadavku k požadovanému zdroji. Zdroj datového toku pomocí protokolu RSVP periodicky informuje uzly přihlášené v dané multicastové skupině o vlastnostech svého datového toku. Kterýkoli člen multicastové skupiny si pak na základě těchto informací může požádat o zarezervování přenosového pásma a všechny směrovače na cestě by mu měly vyhovět. Jak je tedy patrné, RSVP je využíván hlavně v multicastovém vysílání jako jsou videokonference a multimediální přenosy v reálném čase.
Jelikož se jedná o signalizační protokol, lze princip RSVP rozdělit na dvě části:

Signalizace odesílatel ==> síť

Odesílatel, například server vysílající určitý video stream, stanoví hranice parametrů kvality služby požadované na jeho datový tok, speciálně šířku pásma, zpoždění a změnu zpoždění. Tyto parametry vloží do zprávy (PATH message) a periodicky jej začne zasílat na multicastovou adresu v jejíž skupině je registrován. PATH message je tedy rozeslána směrem ke všem účastníkům multicastové skupiny a veškeré uzly na cestě jsou tak informovány o specifikaci datového toku odesílatele.

Signalizace příjemce ==> síť

Příjemce, zaregistrovaný v dané multicastové skupině, přijme některou ze zpráv PATH a na základě jejích parametrů vytvoří rezervační požadavek. Tato RESV zpráva obsahuje požadavky na kvalitu a rychlost datového toku (obvykle stejné jako v PATH zprávě), port, na kterém příjemce naslouchá, a použitý přenosový protokol (TCP/UDP). Dále mohou být v RESV požadavku připojeny autentizační informace (založeny na zašifrovaném kontrolním součtu zprávy, klíč k dešifrování sdílí všechny RSVP uzly). Požadavek RESV je poté odeslán na adresu zdroje uvedenou v PATH zprávě. Jakmile některý ze směrovačů přijme zprávu RESV, proběhne případná autentizace a na základě požadavků uvedených v RESV zprávě rozhodne o rezervaci prostředků. Pokud se směrovač z jistých důvodů rozhodne odmítnout žádost o rezervaci odešle žadateli upozornění o zamítnutí. Jestliže i poslední směrovač potvrdí požadavek, jsou příjemce i odesílatel uvědoměni a prostředky jsou rezervovány.

Instalace RSVP na systému Linux

Pro použití RSVP v Linuxu je nutné do systému nainstalovat RSVP daemona, který bude tuto službu zajišťovat. Daemon pak slouží jako rozhraní mezi aplikací využívající RSVP a síťovou vrstvou systému. Bohužel, pro systém Linux jsme nenašli žádné oficiální vydání tohoto daemona. Institut ISI [4], který se několik let podrobně zabýval implementací RSVP, vydal několik verzí svého daemona, poslední ve verzi 4.2a4. Tento daemon je však určen pro operační systém SunOS. Ostatní daemony pro systémy na bázi UNIXu jsou převážně založeny na této verzi ISI. Abychom mohli tuto verzi použít také na Linuxu, našli jsme patch, který vytvořil Alexey Kuznetsov [5]. Tento patch ale upravuje pouze zdrojové kódy pro samotný RSVP daemon a rozhraní API k tomuto daemonu. Ostatní podpůrné aplikace, které ISI dodává ke své verzi, například utilitu pro zjištění stavu rezervace, tento patch neopravuje. Jiný patch jsme bohužel nenašli.

Instalace RSVP daemona:

Z FTP serveru ISI (ftp://ftp.isi.edu/rsvp/release/) jsme stáhli tyto soubory:
- rsvpd.rel4.2a4.tar.Z - oficiální a zatím poslední verze RSVP daemona (rok vydání 1998).
- rsvpd.rel4.2a4-1.tar.gz - patch na tuto verzi (rok vydání 1999)

Patch Alexeye Kuznetsova lze nalézt zde (http://www.cs.helsinki.fi/u/jmanner/software/rsvp/)
Všechny zde použité soubory jsou také uloženy v tomto archivu.

Po rozbalení souboru s RSVP daemonem vznikne adresář rel4.2a4. Oficiální patch se aplikuje pouze jeho rozbalením do stejného adresáře, přepíše se několik souborů. Do adresáře rel4.2a4 jsme zkopírovali soubor s patchem Alexeye Kuznetsova. Příkazem patch -p1 < rsvp-rel4.2a4-kuznetsov.patch dojde k opravení asi 20ti souborů. Ke kompilaci je dále třeba skript mkdep, který je obsažen ve výše uvedeném archivu a je nutné ho nakopírovat do /bin adresáře v systému. Před kompilací je vhodné vymazat předkompilované objektové soubory a knihovny příkazem make clear. Samotná kompilace se provádí příkazem make depend a následně make.

Spuštění a práce s RSVP daemonem

Samotný daemon je umítěn v adresáří rsvpd. Daemon lze pustit ve dvou režimech:
./rsvpd spustí daemon na pozadí systému
./rsvpd -D spustí daemon zároveň s RTAP rozhraním, pomocí kterého lze daemonu zadávat příkazy. Definice a popis použití těchto příkazů jsou uvedeny v dokumentaci k RTAP, v adresáři doc.
RTAP rozhraní lze k již běžícímu daemonu spustit dodatečně. Je umístěno v adresáři apitools.

Testování RSVP daemona:

Použili jsme pouze dva počítače, přímo propojené kříženým UTP kabelem. Na obou počítačích jsme nainstalovali a spustili RSVP daemon.


RSPV daemon jednom počítači jsme nastavili jako vysílač (sender), zde je výpis s API konzole:

> dest udp 1.0.0.1/5000   // Vytvoření nové session, připojení na adresu 1.0.0.1 udp port 5000
> sender 1.0.0.2/5000 [t 6000 256 6000 64 256]    //  přihlášení  odesílatele z adresy rozhraní 1.0.0.2 portu 5000

[t <b> <r> <p> <m> <M>] je TSpec (Traffic Specification) parametr definujicí požadavky na QoS [6]:
    b - velikost token bucketu
    r - rychlost doplňování tokenů
    p - součet velikosti token bucketu a špičkové rychlosti přicházejících paketů
    m - minimální datová jednotka pro správu linky
    M - maximální velikost datagramu
   
Po zádání těchto příkazů  začal odesílatel v pravidelných intervalech zasílat PATH message, což jsme ověřili na obou PC pomocí aplikace Ethereal.
Zkrácený obsah PATH paketu zachycený programem Ethereal je uveden na konci v příloze.

Druhý počítač jsme nastavili jako příjemce:

> dest udp 1.0.0.2/5000    // Vytvoření nové session s cílem na IP 1.0.0.2 port udp 5000
> receive    // připojení do multicastové skupiny, v našem případě neměl tento příkaz žádný vliv
> reserve wf [cl 3280 256 64 3280 128]     //  Odeslání požadavku na zarezervovaní prostředků

Parametr wf (Wildcard-Filter) znamená, že bude zarezervován jeden datový tok sdílený pro všechny odesílatele (zdroje dat. toku)
    ff (Fixed-Filter) - pásmo se rezervuje zvlášť pro jednotlivé odesílatele, není sdíleno.
    se (Shared-Explicit) - bude zarezervován jeden datový tok (podobně jako wf), ale sdíleny pouze s vybranými odesílateli.
Parametr cl (Controlled Load) definuje požadovanou charakteristiku QoS a má tvar podobně jako TSpec:
    [cl <b> <r> <p> <m> <M>]
Místo cl může být použit parametr g (Guaranteed) tvaru:
    [g <R> <S> <b> <r> <p> <m> <M>], kde
    R - šířka pásma vyhrazená pro spojení
    S - čas, o který se může datagram zpozdit v síťovém uzlu

Další testování již nemělo žádný význam, jelikož i když na straně příjemce bylo pomocí Etherealu možné zachytit PATH zprávy, sám příjemce po provedení příkazu reserve vypsal chybu "No path message found...". Po vypnutí kontroly intergrity přijímaných zpráv již příjemce na zprávy reagoval, ale pouze vypsáním chyby "Parse error in RAW PKT". Zpráva RESV proto díky této chybě nemohla být vůbec odeslána. Tuto chybu jsme již bohužel nedokázali v rámci vymezeného času opravit. Náš problém je nejspíše způsoben ještě stále se vyskytujícími chybami ve zdrojových kódech daemona, špatným zkompilováním, nebo absencí ještě jiného patche.

Seznam zkratek

API - Application Programming Interface
ICMP - Internet Control Message Protocol
IETF - Internet Engineering Task Force
ISI - Information Science Institute
QoS - Quality of Service
RSVP - Resource Reservation Protocol