Uvod:
RSVP (Resource ReSerVation
Protocol) se koristi kad se želi zatražiti određena kvaliteta usluge od mreže
za nekakav data stream. RSVP se također koristi od strane routera
da dostavi zahtjev za kvalitetom usluge (u daljnjem tekstu QoS –
quality-of-service) svim čvorovima kroz koje prolazi data stream. Važno
je reći da pomoću RSVP-a ne prenosimo podatke već se koristi kao kontrolni
protokol. Također ne služi kao routing protokol nego se oslanja na današnje
i buduće unicast i multicast routing protokole. RSVP konzultira
lokalnu routing bazu podataka za dobijanje rute.
Tokom rezervacijskog postupka
RSVP QoS zahtjev se prosljeđuje na dva lokalna modula. Admission control
i Policy cntrol. Admission control provjerava da li postoje
odgovarajući resursi, a policy control provjerava da li korisnik ima
odgovarajuće ovlasti za uspostavu rezervacije. Ako ijedna provjera vrati grešku,
rezervacija se ne ostvaruje te se šalje poruka o grešci korisniku (aplikaciji)
koji je zatražio QoS.
S obzirom da se broj članova
multicast grupe može mijenjati, a samim tim i topologija multicast
stabla, RSVP šalje periodički poruke za osvježavanje tj. održavanje
rezerviranog path-a (putanje) kojim prolazi data stream. U slučaju
izostanka te poruke rezervirani path se briše.
RSVP poruke:
Postoje dvije glavne RSVP
poruke: Resv i Path.
Slika 1. Prikaz routera koji koristi RSVP
Svaki receiver šalje
rezervacijsku poruku (Resv) prema sender-u. Ova poruka mora ići
točno suprotnom putanjom kojom će podaci putovati. Rezervacijska poruka stvara
i održava rezervacijsko stanje. Na kraju poruka dolazi do sender-a koji
postavlja parametre kontrole prometa podataka. Rezervacijska poruka prenosi flowspec
i filter spec koji zajedno čine flow descriptor. Pomoću flow
descriptora se definiraju zahtjevi za QoS.
Svaki sender šalje Path
poruku koja prati putanju podataka. U Path poruku se upisuje IP adresa
prijašnjeg čvora koja se koristi za proslijeđivanje Resv poruke čvor
po čvor u suprotnom smjeru. Path poruka također sadrži slijedeće
informacije:
·
Sender Template
– opisuje format podatkovnih paketa koje će sender generirati. Ovaj
opis se može koristiti za razlučivanje paketa od različitih sender-a
unutar iste sesije na istom linku.
·
Sender Tspec
– definira karakteristiku prometa podataka koje će sender generirati.
Koristi se kod sprijećavanja prekomjernih rezervacija i nepotrebnih admisson
control prekida.
Spajanje
zahtjeva:
Resv
poruka se proslijeđuje na prethodni čvor (ovdje se struktura čvorova striktno
definira od sender-a prema receiver-u te se samim tim kod slanja Resv
poruke od receiver-a prema sender-u govori o prethodnim čvorovima)
s tim da se se od svih zahtjeva (tj. flowspec-a) uzima onaj najveći.
Ovdje naravno treba uzeti u obzir nedorečenost izraza najveći jer ako jedan receiver
traži širu vezu, a drugi manju propagaciju signala ne možemo govoriti o najvećem
zahtjevu. Umjesto uzimanja "najvećeg" potrebne su procedure koje će
stvoriti treći flowspec s zahtjevima oba receivera. U tom slučaju
se govori o spajanju zahtjeva.
Održavanje rezervacijskog
stanja:
Svako rezervacijsko stanje se
periodički osvježava Path i Resv porukama. Rezervacijsko stanje
se automatski briše ako ne dođe do osvježavajućih poruka unutar cleanup
timeout vremenskog intervala. Rezervacija se također može eksplicitno
obrisati teardown porukom.
Ako se u nekom slučaju
topologija putanje promjeni slijedeća Path poruka će inicijalizirati
novu putanju, a buduća Resv poruka će uspostaviti novo rezervacijsko
stanje.
Periodično slanje osvježavajućih
poruka od strane servera dozvoljava povremen gubitak RSVP poruka. Ako je
efektivni cleanup timeout postavljen na K puta interval slanja poruka
tada RSVP može tolerirati gubitak K-1 paketa. Mrežna kontrola prometa bi
trebala biti konfigurirana tako da ostavi minimalni bandwith za RSVP
pakete da ne dolazi do pogrešnih brisanja rezervacijskih stanja.
Održavanje rezervacijsko
stanja je dinamičko. Ako bilo tko od korisnika želi promjeniti QoS jednostavno
se počmu slati revidirane Path i Resv poruke. Automatski se
prilagođavaju sva RSVP stanja u čvorovima duž putanje (naravno uz dopuštenje
admisson i policy control-a). Nekorištena stanja, ako se
ekslicitno ne obrišu, će se automatski izbrisati nakon timout-a.
RSVP teardown poruka
briše path ili rezervacijsko stanje. Iako nije potrebno eksplicitno
brisati path i rezervacijsko stanje zbog timeout-a savjetuje se da
aplikacija čim završi šalje zahtjev za brisanjem. Postoje dvije vrste teardown
poruka: PathTear i ResvTear. PathTear poruka putuje prema
svim receiver-ima od točke njene inicijalizacije prema dolje. ResvTear
briše rezervacijsko stanje i putuje prema gore svim sender-ima.
Potvrda rezervacije:
Potvrda rezervacije se dobije
uključenjem confirmation-request objekta koji sadrži IP adresu receiver-a.
Na svakoj točki spajanja flowspeca samo se najveći zahtjev šalje dalje
s pratećim zahtjevom za potvrdom. Ako je rezervacijski zahtjev jednak ili manji
od rezervacije koja je već na mjestu u čvoru zahtjev se ne šalje dalje, a ResvConf
poruka se šalje nazad onom koje posla zahtjev za potvrdom.
Prolazak kroz router koji
ne podržava RSVP:
S obzirom da nije moguće
implementirati RSVP na cijeloj mreži, protokol mora podržavati normalan rad i
kad paketi prolaze kroz router koji ne podržava RSVP. Naravno taj router
ne može rezervirati određene resurse, ali ako ima dovoljne kapacitete može
pružiti dovoljnu kvalitetu usluge. Kako nemogućnost rezervacije unosi
nesigurnost u kvalitetu usluge RSVP protokol postavlja NonRSVP zastavicu.
Zaključak:
Trenutna situacija je takva
da se protokol ne koristi u mjeri u kojoj bi trebao. Probleme stvaraju jako
kompleksna implementacija. University of Southern California Information
Sciences Institute ima vodeću ulogu u implementaciji protokola. Napisana je
implementacija od 30000 linija koda u C-u i još uvijek ne podržava sve mogućnosti
koje teoretski protokol ima. RSVP je protokol koji sigurno ima budućnost, samo što to vrijeme još nije
stiglo.