kvalitet servisa u voip - rsvp
TRANSCRIPT
KVALITET SERVISA U VoIP MREŽAMA
II deo ( RSVP)
Petrović Julija 338-07
REŠENJA ZA OSTVARIVANJE KVALITETA SERVISA
Postoje različita rešenja za poboljšanje kvaliteta servisa u VoIP mrežama koja rešavanju problema pristupaju iz različitih uglova.
• Jedan pristup je da se pre uspostave poziva rezervišu resursi u mreži koji će garantovati određeni kvalitet. Ovaj pristup podrazumeva da se rezerviše određeni propusni opseg i sličan je pristupu koji se koristi u PSTN mrežama.
• Drugi pristup vrši kategorizaciju saobraćaja i deli ga na klase servisa kojima dodeljuje određene prioritete ( na primer, govorni paketi imaju pravo prvenstva nad paketima koji prenose elktronsku poštu). Ovaj pristup je možda jednostavniji ali nije bez mana. Na primer, jedan servis, kao što je telefonija, može da uguši ostale servise i zbog toga treba obratiti pažnju na pravilnu raspodelu resursa mreže koja se istovremeno koristi za prenos govora i podataka.
PREDIMENZIONISANJE PROPUSNOG OPSEGA
Postoji i pristup koji je možda i najprisutniji u praksi, a to je predimenzionisanje mreže. Ovaj pristup podrazumeva da se u mreži obezbede propusni opsezi koji nadmašuju stvarne potrebe, jer se pokazalo da je upravo propusni opseg najčešći razlog kašnjenja i gubitka paketa.
PREDIMENZIONISANJE PROPUSNOG OPSEGA
Predimenzionisanje propusnog opsega predstavlja možda najjednostavniji pristup ostvarivanja kvaliteta servisa, ali je i najskuplji.
Mreža se projektuje tako da podrži sav saobraćaj u trenucima najvećeg opterećenja ( par sati u doba radnog vremena). Većinom vremena tokom dana mreža ostaje neiskorišćena. Postavlja se pitanje koliko je ovaj pristup isplatljiv provajderu usluga.
PREDIMENZIONISANJE PROPUSNOG OPSEGA
Na sreću provajdera, a i korisnika usluga, tehnološki razvoj u oblasti telekomunikacija je doprineo da cena jedinice propusnog opsega iz dana u dan postaje sva manja.
Iako je dodatni propusni opseg od ključnog značaja za multiservisne mreže, on ne može sam po sebi biti rešenje problema kvaliteta servisa.
Potrebno je implementirati i mehanizme koji će upravljati propusnim opsegom kako bi se on što efikasnije koristio.
U nastavku treba objasniti protokole koji mogu da obezbede određeni kvalitet servisa u VoIP mrežama ( RSVP, DiffServ, MPLS).
RSVP
Protokol za rezervaciju resursa, RSVP ( resource ReSerVation Protocol) je tehnika koja se koristi za rezervaciju resursa IP mreže u cilju obezbeđivanja unapred definisanih parametara integrisanih servisa.
RSVP se koristi za rezervaciju resursa mreže za datu sesiju pre razmene podataka ( govora) između učesnika. RSVP nije protokol za rutiranje, ali se zajedno sa postojećim protokolima za rutiranje koristi za definisanje putanja tokova podataka.
Od ponuđenih rešenja, RSVP najverovatnije predstavlja najkompleksnije rešenje za obezbeđivanje servisa, ali je i rešenje koje je najsličnije emulaciji kola u IP mrežama.
RSVP
U RSVP-u tok podataka predstavlja niz datagrama koji imaju isti izvor, odredište i zahteve za kvalitet servisa.
Zahtevi za kvalitet servisa se definišu u specifikacijama toka ( flow spacification) u kojima se daje opis nivoa servisa koji se zahteva za dati tok podataka.
Ovi opisi su u formi jednog od dva tipa saobraćaja koji odgovaraju RSVP klasama servisa:
RSVP
• SERVIS SA GARANCIJOM – servis koji je veoma sličan emulaciji kola u okviru kojeg postoje dva servisa:
• servis sa garancijom brzine prenosa ( rate – sensitive)
• servis sa garancijom kašnjenja ( delay – sensitive )
• SERVIS KONTROLISANOG OPTEREĆENJA – predstavlja ekvivalent best-effort servisu koji se koristi za pouzdan prenos podataka u IP mrežama a nije osetljiv na izvesno kašnjenje i koji se ostvaruje u mrežama u uslovima kada nisu opterećene.
funkcionisanje RSVP protokola
Pošiljalac ka primaocu, preko nekoliko rutera, prvo šalje PATH poruku. PATH poruka sadrži specifikacije saobraćaja, TSpec ( traffic specification) u kojima se definišu zahtevi pošiljaoca kao što su propusni opseg i veličina paketa.
Svaki ruter na putanji u PATH poruku upisuje adresu uređaja od koga je primio poruku ( stanje putanje). Stanje putanje omogućuje da se povratna poruka šalje istim putem u suprotnom smeru.
Primalac PATH poruke odgovara sa RESV porukom ( reservation request ) u kojoj definiše specifikacije toka ( flow specification ).
Specifikacije toka uključuju informacije o tipu servisa koji se zahteva, tj. da li je servis sa garancijom ili servis kontrolisanog opterećenja.
RESV poruka putuje nazad ka pošiljaocu preko istih rutera kao i PATH poruka. U svakom ruteru se zahtevani resursi rezervišu. Na kraju, RESV poruka stiže do pošiljaoca sa potvrdom da su resursi rezervisani.
Interesantno je da u RSVP-u resurse rezerviše primalac informacija, a ne pošiljalac. Ovaj pristup odgovara multikast prenosu, gde može da postoji više primalaca a samo jedan pošiljalac.
RSVP ne prenosi korisničke podatke već predstavlja kontrolni protokol. Korisnički podaci se prenose kasnije drugim protokolima i to nakon procedure rezervacije.
Rezervacija resursa se mora nakon nekog vremena obnoviti od strane primaoca.
primena RSVP protokola
HOST RUTER
APLIKACIJARSVP
procesKontrola politike pristupa
Klasifikator
paketa
Raspoređivanje
paketa
Kontrola pristupa
Proces
rutiranja
RSVP
proces
Klasifikator
paketa
Raspoređivanje
paketa
Kontrola politike pristupa
Kontrola pristupa
Podaci
aplikacije
Podaci
aplikacije
Da bi se RSVP primenio u mreži, ruteri i korisnički uređaji moraju implementirati određene funkcije.
Kontrola pristupa
Pre prenosa korisničkih podataka, prilikom rezervacije resursa, funkcija kontrole pristupa određuje da li mrežni uređaj ima dovoljno dostupnih resursa da zadovolji zahtevani kvalitet servisa.
Kontrola politike pristupa
Funkcija kontrola politike pristupa određuje da li je korisnik autorizovan da šalje zahtev za rezervacijom resursa.
Klasifikator
paketa
Za vreme prenosa korisničkih podataka, klasifikator paketa određuje klasu servisa koja treba da se primeni za svaki paket,
a na izlaznom interfejsu funkcija za raspoređivanje paketa određuje kada će se dati paket proslediti.
Raspoređivanje
paketa
uspostavljanje RSVP rezervacije resursa
SLUČAJ MULTIKASTA
Slika prikazuje scenario kada postoji jedan pošiljalac a više primalaca informacija.
Putanja se od pošiljaoca grana na više putanja, dok se u suprotnom smeru više putanja stapa u jednu.
Pretpostavka je da primaoci 3 i 4 imaju različite zahteve za kvalitet servisa.
U tom slučaju resursi koji se rezervišu između rutera 2 i 3 predstavljaju maksimum zahteva primaoca 3 i 4.
Slično, resursi koji se zahtevaju između rutera 1 i 2 predstavljaju maksimum zahteva sva četiri primaoca.
Ulazni tok paketa bafer
Brojač tokena
Izlazni tok paketa
B – kapacitet kofe
R – brzina pristizanja tokena
PATH poruke – prenos specifikacije saobraćaja
Kofa ima kapacitet od B bajtova i puni se tokenima brzinom od R bajtova u sekundi.
Kada stigne paket, on će biti prosleđen jedino ako minimalni broj tokena u kofi odgovara veličini paketa.
U suprotnom, paket može biti odbačen ili zadržan dok se kofa ne napuni sa dovoljno tokena.
R – brzina pristizanja tokena
B – kapacitet kofe
Ukoliko je brzina pristizanja paketa manja nego brzina tokena, tada se generisanje tokena u kofi suspenduje dok ne dođe paket koji će potrošiti određen broj tokena.
Sve dok je prosečna brzina toka podataka manja ili jednaka brzini tokena, neće dolaziti do zastoja.
Maksimalna brzina kojom pošiljalac šalje pakete može da bude veća od brzine tokena, međutim pošiljalac ne sme da duži vremenski period tom brzinom šalje pakete jer može da dođe do nestanka tokena i kašnjenja, odnosno odbacivanja paketa.
Maksimalna veličina IP paketa koju će pošiljalac poslati mora odgovarati minimalnoj kontrolnoj jedinici, određenoj u specifikaciji.
Prvi razlog za ovo je to što je čvorovima u mreži omogućeno da procene količinu resursa koji će biti potrebni za procesiranje paketa.
Drugi razlog je ograničavanje propusnog opsega potrebnog za prenos zaglavlja nivoa voda podataka.
RESV poruke – specifikacije toka
Specifikacije toka ( flow specification ) se šalju u RESV poruci od primaoca ka pošiljaocu.
Specifikacija sadrži indikaciju o tipu servisa koji se zahteva ( servis sa garancijom ili servis kontrolisanog opterećenja).
Servis sa garancijom pored specifikacije saobraćaja poseduje i parametre R ( rate) i S ( slack).
R označava propusni opseg koji se zahteva i mora biti veći ili jednak sa brzinom pristizanja tokena. Ako je brzina veća tada se zahteva i veći propusni opseg i kašnjenje je manje.
Parametar S predstavlja broj milisekundi i označava razliku između željenog kašnjenja i kašnjenja koje će se postići ukoliko se koristi brzina R.
Mrežni uređaj koristi parametar S da smanji količinu resursa za određeni tok podataka ukoliko je potrebno.
specifikacije filtra
RSVP sesija se identifikuje samo odredišnom adresom i identifikatorom protokola. Identifikacija RSVP sesije ne sadrži informacije o pošiljaocu.
Zbog ovih činjenica može nastati problem u određivanju za koji tok podataka se data rezervacija zahteva. Na primer, neki primalac može da prima dva toka podataka od dva različita pošiljaoca ( slučaj VoIP poziva sa tri učesnika u vezi).
Da bi se odredilo koji zahtevi za rezervacijom se odnose na koji tok podataka koriste se specifikacije filtra ( filter specification).
Specifikacija filtra predstavlja ulaz klasifikatora paketa i koristi se za definisanje skupa paketa na koji se određeni kvalitet servisa primenjuje.
Format specifikacije filtra zavisi od toga da li se koristi IPv4 ili IPv6.
Minimalno, specifikacija filtra sadrži:
• IP adresu pošiljaoca – identifikuje pošiljaoca podataka za koga se zahtevao određeni kvalitet servisa
• broj porta pošiljaoca – koristi se, recimo, u slučaju videokonferencije kada se posebnim tokovima prenosi audio i video signal koji imaju različite zahteve za kvalitet servisa.
Specifikacija filtra je uključena u PATH i RESV poruci. Kada se šalje u okviru PATH poruke, naziva se templejt pošiljaoca ( sender template).
specifikacija reklame
Primalac u okviru RESV poruke može da zahteva rezervaciju resursa koji nisu dostupni u mreži.
Za tu svrhu RSVP ima mogućnost da u okviru PATH poruke omogući pošiljaocu i ruteru na putanji da prezentuju svoje mogućnosti u pogledu obezbeđivanja kvaliteta servisa. Ovo se ostvaruje korišćenjem specifikacije “reklame” ADSpec ( advertising specification).
Pošiljalac kreira početnu ADSpec u okviru PATH poruke u kojoj definiše šta može da podrži.
U svakom ruteru duž putanje ADSpec se ažurira i prosleđuje dalje do primaoca koji dobija informaciju o mogućnostima mreže.
ADSpec može da sadrži i informaciju o tome da jedan ili više rutera na putanji ne podržava RSVP.
U okviru formata ADSpec postoje opšte informacije koje su praćene informacijama o jednom ili oba servisa koja su definisana u RSVP-u.
Opšte informacije specificiraju da li na putanji postoje mrežni elementi koji ne podržavaju integrisane servise, odnosno ne podržavaju RSVP.
Ukoliko se ovi elementi detektuju, tada informacije u preostalom delu ADSpec-a nisu relevantne, jer postoji mogućnost da se zahtevani kvalitet ne ostvari.
RSVP poruke
RSVP poruka se sastoji od zaglavlja koje je zajedničko za sve RSVP poruke, nakon koje sledi telo poruke koje se sastoji od različitog broja tipova objekata različitih dužina. Za svaku RSVP poruku postoji skup pravila koji se odnose na tipove objekata koji su dozvoljeni.
U okviru zaglavlja postoje sledeća polja:
• V (version) – 4bitno polje koje označava broj verzije protokola. Trenutno se koristi verzija 1.
• Flagovi (flags) – 4bitno polje koje je rezervisano i koje se trenutno ne koristi.
• Tip poruke (message type) – 8bitno polje koje definiše tip poruke. Postoji 7 tipova poruka koje su definisane brojevima: 1-Path, 2-Resv, 3-PathErr, 4-ResvErr, 5-PathTear, 6-ResvTear, 7-ResvConf.
• RESV polje za proveru greške (checksum) – 16bitno polje za proveru pojave greške prilikom prenosa RSVP poruke.
• Send_TTL – 8bitno IP TTL polje koje se može koristiti za proveru da li je putanja ostvarena preko rutera koji nemaju RSVP mogućnosti.
• RSVP dužina (length) – 16bitno polje koje označava ukupnu dužinu RSVP poruke ( zaglavlje i objekti).
Nakon zaglavlja slede objekti poruke kao što su TSpec, ADSpec i slično. Svaki objekat ima zaglavlje i sadržaj objekta.
U okviru zaglavlja objekta postoje tri polja:
• prvo 16bitno polje označava dužinu objekta u bajtima.
• polje dužine 8 bita Class-num identifikuje objekat.
• polje C-type obezbeđuje postojanje različitih verzija datog objekta.
Na primer, format specifikacije filtra se razlikuje od toga da li se koristi IPv4 ili IPv6 i Class-num označava da se radi o specifikaciji filtra, dok C-type označava IPv4 ili IPv6 varijantu. Zajedno, Class-sum i C-type polje se mogu koristiti kao 16bitni broj koji će definisati jedinstveni tip svakog objekta.
Uklananje rezervacije i korišćenje soft stanja
Rezervacija resursa može biti ukinuta na dva načina:
• eksplicitno od strane pošiljaoca
• ili kao posledica isteka vremena trajanja rezervacije
Za eksplicitno ukidanje rezervacije resursa koriste se poruke PathTear i ResvTear, koje šalju pošiljalac i primalac, respektivno, da bi izbrisali stanja putanje i rezervaciju resursa u svakom čvoru putanje.
Međutim, jedan primalac nema prava da ukine rezervaciju za druge primaoce, već svaki to mora da učini sam za sebe.
RSVP koristi pristup soft stanja ( soft state) u cilju upravljanja rezervacijama. Drugim rečima, rezervacije se moraju osvežavati u pravilnim vremenskim periodima da ne bi bile ukinute.
Da bi zadržao rezervaciju, primalac za svaki period osvežavanja mora poslati novu RESV poruku.
U okviru svakog čvora postoji tajmer. Ukoliko čvor ne dobije poruku sa zahtevom za osveženje, rezervacija se ukida.
Da rezervacija nije vremenski ograničena, tada bi ona mogla biti aktuelna i kada za to više ne postoji potreba i zauzimala bi resurse koji su potrebni za prenos nekog drugog toka podataka.