QoS signalizacija u vieuslunim mreama sljedee generacije

Jasmina Barakovi
BH Telecom d.d. Sarajevo jasmina.barakovic@bhtelecom.ba

Saetak - Session Initiation Protocol (SIP) predstavlja protokol namijenjen za upravljanje sesijom u vieuslunim mreama sljedee generacije. Kljuni izazov u ovim mreama predstavlja osiguranje kvalitete usluge (Quality of Service, QoS) za krajnje korisnike aplikacije uz efektivno iskoritenje mrenih resursa. Real-time Transport Control Protocol (RTCP) osigurava razmjenu QoS informacija, ali ne garantira QoS za vremenski osjetljive usluge, niti omoguava rezervaciju resursa. S obzirom da SIP i RTCP ne osiguravaju QoS, moraju se naslanjati na postojee QoS arhitekture radi postizanja eljenog cilja. Arhitektura diferenciranih usluga (Differentiated Service, DiffServ) se pojavljuje kao skalabilno rjeenje koje osigurava viestruke klase usluga unutar mree. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), s druge strane, omoguava rezervaciju resursa, toleranciju na pogreke i optimizaciju prijenosnih resursa. Izbor signalizacijskog protokola za razmjenu DiffServ, MPLS i TE informacija predstavlja kljuni izazov MPLS DiffServ-aware TE arhitekture koja kombinira prednosti ovih rjeenja. Resource Reservation Protocol (RSVP) sa nekoliko proirenja predstavlja postojee rjeenje problema QoS signalizacije. Na definiranju buduih zahtjeva, okvira i protokola QoS signalizacije intenzivno radi Internet Engineering Task Force (IETF) Next Step in Signaling (NSIS) radna grupa. U radu je dat prikaz izazova u vezi sa problemom ostvarivanja QoS-a uporabom SIP i RTCP protokola, te analiziran rad na postojeim i buduim QoS signalizacijskim protokolima. Razmotrena je potreba uvo enja klase usluge za signalizacijski i kontrolni prometa, te rjeenje problema prioritetnog tretmana klase usluge za signalizacijski i kontrolni promet. Kljune rijei - SIP, RTCP, RSVP, NSIS, DiffServ, MPLS, TE, QoS

I. UVOD S obzirom da broj aplikacija koji zahtijevaju uspostavu sesije kontinuirano raste, Internet Engineering Task Force (IETF) je razvio Session Initation Protocol (SIP) [1] s ciljem uspostave i odravanje sesije izme u dva ili vie partnera u komunikaciji. U veini sluajeva, usluge koje zahtijevaju uspostavu sesije zahtijevaju i odre eni stupanj kvalitete (Quality of Service, QoS). SIP samostalno ne moe odgovoriti na QoS zahtjeve takvih usluga, to i nije njegova svrha, niti moe osigurati odgovarajuu razmjenu QoS signalizacijskih informacija u cilju ostvarivanja QoS podrke. S tim u vezi, definiran je Real-time Transport Control Protocol (RTCP) [2] s primarnim ciljem da osigura povratnu informaciju o kvaliteti dostavljanja vremenski osjetljivih usluga. Iako se temelji na periodikoj razmjeni kontrolnih paketa izme u svih sudionika sesije koristei

iste mehanizme distribucije koji se koriste i za prijenos podataka, RTCP ne garantira QoS za vremenski osjetljive usluge. Za ovu funkciju moraju se koristiti protokoli koji se nalaze ispod RTCP-a u protokol stogu. Iz ovog razloga, definiran je veliki broj proirenja SIP i RTCP protokola radi upravljanja mrenim zaguenjem i suoavanja sa problemima koji se mogu dogoditi koritenjem nepouzdanog User Datagram Protocol (UDP) na prijenosnom sloju. Poto i SIP i RTCP mogu raditi preko UDP protokola koji ne garantira kontrolu toka, uestala je pojava mrenog zaguenja i posljedina QoS degradacija. Proirenje SIP i RTCP protokola u tom kontekstu je od velikog znaaja, s obzirom da nema smisla raditi na pruanju QoS podrke ako protokol radi pod rizikom nastanka mrenog zaguenja. SIP i RTCP ne osiguravaju QoS, stoga se moraju naslanjati na postojee QoS arhitekture radi ostvarivanja ovog cilja to moe prouzroiti problem interoperabilnosti izme u QoS arhitekture i protokola. Iz tog razloga, posebna panja se posveuje radu na poboljanju interoperabilnosti, ali i izboru QoS arhitekture. Differentiated Service (DiffServ) arhitektura [3] predstavlja efikasno i skalabilno rjeenje koje osigurava QoS u Internet Protocol (IP) mreama. U cilju optimiziranja prijenosnih resursa, ovoj arhitekturi se moraju dodati efikasni Traffic Engineering (TE) mehanizmi. MultiProtocol Label Switching (MPLS) [4] tehnologija predstavlja prikladan metoda za osiguranje TE funkcionalnosti kao to su rezervacija resursa, tolerancija na pogreke i optimizacija iskoritenosti resursa [5]. Kombinirana uporaba DiffServ i MPLS arhitekture [6] predstavlja atraktivno rjeenje problema osiguranja QoS za multimedijski promet uz efikasno iskoritenje mrenih resursa. Rezultat ove integracije je DiffServ-aware Traffic Engineering (DS-TE). Ovaj model omoguava da MPLS-TE spozna klase usluge (Class of Servce, CoS) i osigura rezervaciju resursa sa CoS granularnou, te MPLS toleranciju na pogreke na CoS razini. U cilju omoguavanja DS-TE funkcionalnosti, potrebna je razmjena DiffServ, MPLS i TE informacija izme u usmjeritelja u kontrolnoj ravni posredstvom dinamikog signalizacijskog protokola. Resource Reservation Protocol Traffic Engineering (RSVP-TE) [7] je odabran kao MPLS signalizacijski protokol, dok je obustavljen rad na daljnjem razvoju Constraint based Routing Label Distribution Protocol (CR-LDP) [8]. RSVP-TE predstavlja proirenje RSVP [9] protokola koji je razvijen u okviru Integrated Services (IntServ) arhitekture. S obzirom na nedostatke RSVP kao QoS signalizacijskog protokola, potrebno je izvriti njegovu optimizaciju.

IETF Next Step in Signaling (NSIS) [10] radna grupa formirana je s ciljem rjeavanja problema QoS signalizacije. Njen rad se fokusira na definiranju zahtjeva, okvira i protokola neophodnih za postizanje tog cilja uz analizu postojeih QoS signalizacijskih protokola. Zadatak NSIS radne grupe nije definiranje novog QoS signalizacijskog protokola, ve optimizacija postojeih protokola unutar definiranog okvira. Namjera je ponovno uporabiti odgovarajue RSVP mehanizme uz svojevrsno pojednostavljenje i definiranje generikog signalizacijskog modela. II. SIP SIGNALIZACIJSKI PROTOKOL SIP je signalizacijski protokol aplikacijske razine razvijen u svrhu kreiranja, promjene i prekida viemedijskih sesija ili poziva izme u dva ili vie sudionika, lociranja korisnika i preusmjeravanja poziva, omoguavanja mobilnosti preusmjeravanjem poziva i upotrebom proxy posluitelja. Iako ga je razvio i standardizirao IETF, prihvatila su ga i ostala znaajna me unarodna standardizacijska tijela kao glavni protokol u viemedijskim domenama 3G mobilnih sustava, IP Multimedia Subsystem (IMS), te kao okosnicu mrea sljedee generacije (Next Generation Network, NGN) [11]. S migracijom tradicionalnih telekomunikacijskih mrea prema IP vieuslunim i viemedijskim mreama, SIP protokol dobiva nezaobilaznu vanost. Sve interesne grupe u telekomunikacijskoj industriji su se usuglasile da je protokol SIP glavno sredstvo realizacije viemedijskih komunikacijskih usluga sljedee generacije. A. Osnovna naela SIP protokola SIP je temeljen na HTTP (Hypertext Transport Protocol) transakcijskom modelu zahtjeva i odgovora. SIP se ne koristi za opis obiljeja sesije, nego tijelo SIP poruke nosi karakteristike sesije za iji se opis koristi SDP (Session Description Protocol) [12] protokol ili neki drugi protokol razvijen u tu svrhu. Razdvajanje funkcije upravljanja uspostavom sesije od ugovaranja karakteristika sesije vana je karakteristika koja SIP predstavlja kao uinkovit protokol, budui da se moe koristiti za uspostavljanje bilo kojeg tipa sesije. SIP je zajedno sa drugim IETF protokolima (Real-time Transport Protocol RTP, Real-Time Streaming Protocol RTSP, i sl.) sastavni dio arhitekture koja u potpunosti omoguava multimediju (slika 1). Iako se SIP, zajedno sa navedenim protokolima, koristi u svrhu omoguavanja potpune usluge korisnicima, njegova osnovna funkcionalnost ne ovisi niti o jednom od navedenih protokola.

SIP je strukturiran kao slojeviti protokol, pri emu svaki sloj definira odre eni skup pravila. Najnii sloj SIP protokola predstavlja njegova sintaksa i kodiranje. Drugi sloj je prijenosni sloj koji definira kako klijent alje zahtjeve i prima odgovore putem mree. Sve komponente SIP protokola moraju implementirati UDP i Transport Control Protocol (TCP), ali mogu koristiti i Stream Control Transmission Protocol (SCTP). Trei je sloj transakcijski sloj koji upravlja retransmisijama aplikacijskog sloja, povezivanjem odgovora i zahtjeva, kao i istekom vremena aplikacijskog sloja. Iznad transakcijskog sloja se nalazi sloj korisnika transakcije. B. SIP entiteti Osnovne znaajke SIP protokola su odre ivanje lokacije, mogunosti i dostupnosti korisnika te uspostava i upravljanje viemedijskim sesijama [13]. To je omogueno sljedeim logikim komponentama koje ine temelj bilo koje arhitekture koja koristi SIP: korisniki agenti, registri, proxy posluitelji i redirekcioni posluitelji (slika 2). Razlika izme u SIP posluitelja je logika, a ne fizika, to znai da se SIP posluitelj istovremeno moe ponaati kao registar i proxy. Korisniki agenti mogu biti u svojstvu klijenta ili posluitelja, pri emu je razlika opet logika. Korisniki agent u svojstvu klijenta predstavlja entitet koji inicira sesiju slanjem zahtjeva, dok korisniki agent u svojstvu posluitelja vri obradu zahtjeva i alje odgovarajui odgovor. Registri su entiteti u kojima se vri registracija SIP korisnika u cilju lokalizacije SIP korisnika. Proxy posluitelji su posredniki entiteti koji prihvaaju i proslje uju SIP poruke. Redirekcioni posluitelji izvode sline zadatke i vre preusmjeravanje korisnika na alternativni skup SIP adresa. C. Uspostava SIP sesije SIP osigurava uspostavu sesije kroz dvosmjernu razmjenu opisa sesije, odnosno offer/answer model [14]. Korisniki agent generira opis sesije (offer) koja sadri informacije neophodne za uspostavu sesije i alje ga ka udaljenom korisnikom agentu. Udaljeni korisniki agent generira vlastiti opis sesije, odnosno answer po prijemu offer-a. Nakon zavretka offer/answer razmjene zapoinje razmjena tokova medija izme u korisnikih agenata, to je znak da je sesija uspostavljena. Putanja SIP poruka moe se razlikovati u odnosu na putanju koja se koristi za razmjenu tokova medija unutar uspostavljene sesije. Po tome se SIP razlikuje od tradicionalnih telefonskih signalizacijskih protokola. D. Problem prijenosa SIP poruke SIP moe koristiti pouzdani ili nepouzdani nain prijenosa, kao to su SCTP, TCP ili UDP protokol. Preporuuje se uporaba UDP protokola, s obzirom da se na taj nain izbjegava faza uspostave i raskida TCP veze. TCP je sigurniji nain prijenosa SIP poruka jer postoji kontrola postojee TCP veze otvorene za uspostavu sesije. Najvei problem TCP prijenosa je mogue kanjenje prilikom uspostave veze. UDP protokol karakteriziraju dva nedostatka. Prvi problem predstavlja nedostatak mehanizama za kontrolu mrenog zaguenja to je neophodno za prevenciju mrenog kolapsa. Drugi problem predstavlja fragmentacija SIP poruka, s obzirom da je UDP nepouzdan protokol i ne osigurava sredstva za oporavak od izgubljenih fragmenata i promjene njihovog redoslijeda.

Slika 1. IETF protokol stog za multimediju

Slika 2. SIP logike komponente i uspostava sesije SIP ne osigurava mehanizam za upravljanje zaguenjem. Jedini pokuaj SIP-a da rijei problem zaguenja je koritenjem eksponencijalnih retransmisijskih back-off timer-a i ograniavanje veliine poruka koje se prenose preko UDP-a. Referenca [15] definira znaenje sigurnog rada SIP protokola u odnosu na pojavu zaguenja i proirenje osnovnog protokola na temelju kojeg SIP entitet moe raditi na spomenuti nain. Definirana su pravila koja se moraju potivati kada se SIP poruke prenose preko UDP-a [15]. Jedno od pravila je da se uvijek koristi TCP ukoliko sljedei skok predstavlja proxy, a UDP jedino ukoliko je sljedei skok korisniki agent. Nedostatak ovog pristupa lei u tome to SIP vor ne zna da li je naredni vor korisniki agent ili proxy, niti spreava pojavu zaguenja prilikom posljednjeg skoka. Definirana su dva zahtjeva kada se za prijenos SIP poruka koristi UDP. Prvo, slanje SIP zahtijeva koritenjem UDP-a ne smije uzrokovati zaguenje u mrei. Jednostavan pristup u postizanju ovakvog ponaanja je slanje zahtjeva jedino u sluaju prijema odziva na prethodni zahtjev. Nedostatak ovog pristupa je smanjenje propusnosti, jer se prijenos odvija na simplex nain, to uzrokuje minimalno 2xRTT kanjenje izme u transmisija. Drugo, prilikom slanja SIP poruka uporabom UDP-a treba se izbjegavati slanje poruka ija je veliina vea u odnosu na Maximum Transmission Unit (MTU) za taj link. Poto SIP protokol ne osigurava nain da ukae na dozvoljenu veliinu, referenca [15] definira dva nova polja zaglavlja koja nose ovu informaciju (ProxyMax-Size i Proxy-Seen-Size). Rad sa SIP odgovorima je jednostavniji, jer prate istu putanju kao i zahtjevi od kojih potiu. Stoga, ako SIP entitet primi zahtjev na siguran nain u odnosu na zaguenje, moe se pretpostaviti da e i odgovor biti generiran na isti nain. Vrijedi i suprotno. Ukoliko je veliina generiranog odgovora manja u odnosu na pridrueni zahtjev, odgovor se nee fragmentirati i moe se smatrati sigurnim u odnosu na zaguenje. Entitet koji generira odgovor, a ne poznaje MTU putanje na koju e ga proslijediti, mora odbiti zahtjev radi izbjegavanja rizika fragmentacije odgovora. E. QoS podrka u SIP sesiji Aplikacije koje koriste SIP zahtijevaju QoS podrku, stoga je potrebno omoguiti kooperaciju izme u SIP i QoS mehanizama, posebno s aspekta rezervacije resursa i upravljanja pristupom.

1) Integracija SIP protokola i rezervacije resursa Jedan od prijedloga je da se vri povezivanje SIP-a sa mehanizmima za rezervaciju resursa koritenjem tzv. koncepta preduvjeta [16]. Preduvjeti predstavljaju skup zahtjeva koje SIP korisniki agenti moraju ispuniti u cilju zapoinjanja ili nastavka SIP sesije. Potreba za preduvjetima dolazi od miljenja da uspostava nekih sesija moe imati negativan ishod ukoliko se ne izvri rezervacija resursa. S druge strane, mehanizmi za rezervaciju resursa esto zahtijevaju koritenje parametara koji se koriste u kontekstu SIP signalizacijske razmjene. Predloeno rjeenje stvara pretpostavku da zaetnik sesije alje offer sa preduvjetima koji moraju biti zadovoljeni prema udaljenoj strani koja alje answer s informacijom da li su preduvjeti zadovoljeni ili ne. Nedostatak ovog prijedloga je to uvodi dodatno kanjenje prilikom uspostave SIP sesije s obzirom da mreni resursi moraju biti rezervirani prije toga. 2) QoS proirenja SIP protokola Drugi prijedlog ostvarivanja QoS podrke za SIP se temelji na DiffServ arhitekturi kao prijenosnom mehanizmu i Common Open Policy Service (COPS) [17] kao protokolu za QoS zahtjeve i pristupnu kontrolu. Prethodno opisani prijedlog na bazi preduvjeta direktno utie na modifikaciju implementacije korisnikih agenata. Reference [18,19] predlau rjeenje u kojem se izbjegava ukljuenje korisnikih agenata u operacije QoS signalizacije, odnosno rjeenje u kojem su QoS funkcije implementirane u lokalnom SIP posluitelju. III. RTCP KONTROLNI PROTOKOL U viemedijskim mreama sljedee generacije prijenos vremenski osjetljivih tokova i signalizacijskih poruka se vri odvojeno. TCP protokol je najrasprostranjeniji protokol na prijenosnom sloju IP protokolnog stoga. TCP osigurava pouzdan prijenos u smislu sigurnog prijema i pravilnog redoslijeda svih paketa u toku, ali posjeduje i karakteristike koje ga ine neprihvatljivim za prijenos vremenski osjetljivih i signalizacijskih poruka. Za prijenos vremenski osjetljivih tokova definiran je Real-time Transport Protocol (RTP) [2]. RTP osigurava prijem paketa u ispravnom redoslijedu, nadzor QoS parametara, te identifikaciju i specifikaciju razliitih tipova korisnih podataka. Iako je proiriv u smislu definiranja profila za formate i tipove korisnih podataka, RTP posjeduje brojna ogranienja. Bez polja za identifikaciju porta, RTP se mora naslanjati na UDP protokol. Za razliku od TCP protokola, RTP ne nastoji osigurati pouzdan prijenos vremenski osjetljivih paketa preko nepouzdane mree. RTP ne omoguava rezervaciju resursa, niti garantira QoS za vremenski osjetljive usluge. RTP standard osigurava informaciju drugim mehanizmima izvan standarda radi osiguranja prihvatljive dostave vremenski osjetljivih tokova. Ovi mehanizmi mogu biti jednostavni poput prilago avanja prijenosne bitske brzine krajnjih ure aja ili pak sloeni kao centralni sustav za upravljanje propusnim opsegom. S tim u vezi, definiran je Real-time Transport Control Protocol (RTCP) kao integralni dio RTP standarda za osiguranje povratne informacije o kvaliteti prijema vremenski osjetljivih usluga [2].

A. Osnovna naela RTCP protokola RTCP protokol je definiran s namjerom da podri veliki broj funkcionalnosti ukljuujui kontrolu RTP sesija, nadzor kvalitete i sinkronizaciju vie RTP tokova medija. RTCP se temelji na periodikom prijenosu kontrolnih paketa izme u svih sudionika sesije. Primarna funkcija RTCP protokola je osiguranje povratne informacije o kvaliteti prijema vremenski osjetljivih podataka uporabom izvjetaja poiljatelja (Sender Report, SR) i izvjetaja primatelja (Receiver Report, RR). Koritenjem ovih upravljakih poruka RTCP protokol vri prikupljanje i razmjenu statistikih podataka kao to su ukupan broj prenesenih RTP paketa i okteta, ukupan broj izgubljenih RTP paketa, kanjenje paketa i sl. Na temelju prikupljenih informacija poiljatelj se moe prilagoditi dinamikim promjenama mree (npr. koritenjem tehnika adaptivnog kodiranja, poveanjem redundantnosti i formata za niskopropusno kodiranje), a primatelj utvrditi razmjeru eventualno nastalog zaguenja u mrei. Prijenos detaljnijih informacija i inkorporiranje dodatnih statistikih podataka u RTCP pakete mogue je ostvariti koritenjem proirenog izvjetaja (eXtended Report, XR) [20]. RTCP XR osigurava mrenim operatorima dodatne informacije iz kojih se moe zakljuiti o mrenim performansama i zadovoljavanju Service Level Agreement (SLA) danog korisnika. Naela rada RTCP protokola Brzina slanja RTCP paketa nije fiksna. Ona varira u skladu s veliinom sesije i formatom toka medija. Cilj je ograniiti ukupni iznos RTCP prometa na fiksni iznos koji iznosi 5% propusnog opsega. To se postie reduciranjem brzine kojom svaki sudionik alje RTCP pakete kako se poveava veliina sesije. Prosjeno vrijeme koje svaki sudionik eka izme u slanja RTCP paketa je poznato kao interval izvjetavanja. On se rauna na temelju nekoliko faktora: propusnog opsega dodijeljenog RTCP-u, prosjene veliine primljenih i poslanih RTCP paketa i ukupnog broja sudionika sesije i broja poiljatelja. Prvi RTCP paket se raspore uje za prijenos na temelju inicijalne ocjene vremena izvjetavanja. Stvarno vrijeme izme u paketa je sluajno, u rasponu izme u jedne polovine i tri polovine intervala izvjetavanja. Ako se radi o prvom RTCP paketu, interval se prepolovi da bi omoguio bru povratnu informaciju novim sudionicima sesije. Ako je broj poiljatelja vei od nule, ali manji od etvrtine ukupnog broja sudionika sesije, interval izvjetavanja ovisi o tome da li se alje. Ako se alje, interval izvjetavanja predstavlja umnoak broja poiljatelja i prosjene veliine RTCP paketa koji se dijeli sa 25% eljenog propusnog opsega. Ako se ne alje, interval izvjetavanja predstavlja umnoak broja primatelja i prosjene veliine RTCP paketa podijeljen sa 75% RTCP propusnog opsega. Ako nema poiljatelja, ili ako su vie od etvrtine sudionika poiljatelji, interval izvjetavanja se rauna kao umnoak prosjene veliine RTCP paketa i ukupnog broja sudionika podijeljen sa RTCP propusnim opsegom [21]. Broj sudionika unutar sesije se mijenja od vremena slanja posljednjeg RTCP paketa do vremena predvi enog za slanje sljedeeg RTCP pakta. Poseban rizik od promjene broja sudionika se deava tijekom faze uspostave ili prekida sesije kada se veliki broj sudionika ukljuuje ili naputa sesiju. Poseban izazov predstavlja B.

sluaj kada se u sesiju istovremeno ukljui veliki broj sudionika. U tom sluaju se primjenjuje algoritam koji vri provjeru veliine grupe u trenutku raspore enom za slanje sljedeeg RTCP paketa i rekalkuliranje intervala. U sluaju kada veliki broj sudionika naputa sesiju, primjenjuje se algoritam koji vri prilago avanje trenutka za slanje sljedeeg RTCP paketa u skladu sa promjenom broja sudionika u ovisnosti o trenutnom i pretpostavljenom broju sudionika u trenutku raspore enom za slanje sljedeeg RTCP paketa. C. Problem prijenosa RTCP poruka RTCP protokol se temelji na naelima razmjene povratnih informacija o kvaliteti prijema vremenski osjetljivih podataka. Pomou analize povratnih informacija, poiljatelji mogu vriti prilagodbu brzine podataka sukladno uvjetima u mrei. Usporedbom statistikih podataka iz izvjetaja poiljatelja i primatelja moe se ocijeniti kvaliteta distribucije vremenski osjetljivih podataka, implementirati nadzor kvalitete neovisno o kodiranju i profilu podataka, proraunati brzina gubitka paketa i odrediti razina zaguenja mree na temelju me udolaznog jitter-a prije nego to do e do gubitka paketa. Ove informacije se mogu koristiti za kontrolu adaptivnog kodiranja, ali su vrlo korisne i za detekciju problema pri distribuciji vremenski osjetljivih podataka. Poto RTCP protokol osigurava povratnu informaciju svim sudionicima sesije koristei iste mehanizme distribucije koji se koriste za prijenos vremenski osjetljivih podataka, neophodno je omoguiti pravovremen i pouzdan prijenos ovih poruka. Da bi se poiljatelj prilagodio dinamikim promjenama mree, mora se osigurati prijenos RTCP poruka bez kanjenja i gubitaka. Prihvaanjem UDP protokola za prijenos RTP/RTCP paketa javlja se problem upravljanja zaguenjem koje dovodi do potencijalne nestabilnosti mree. S obzirom na primarnu funkciju RTCP protokola moe se zakljuiti da je upravljanje zaguenjem odgovornost protokola koji se nalaze ispod RTP/RTCP sloja u IP protokol stogu [22, 23]. IV. QOS SIGNALIZACIJSKI PROTOKOLI Na temelju prethodnih razmatranja izvodi se zakljuak da ni SIP, niti RTCP protokol ne mogu osigurati kvalitetu usluge bez odgovarajue QoS podrke (slika 3).

Slika 3. QoS podrka

DiffServ arhitektura predstavlja efikasno i skalabilno rjeenje za osiguranje QoS u IP mreama. U cilju optimiziranja prijenosnih resursa, ova arhitektura se kombinira sa MPLS tehnologijom koja omoguuje TE funkcionalnosti kao to su rezervacija resursa, tolerancija na pogreke i optimizacija iskoritenosti resursa. Integracija DiffServ i MPLS arhitekture predstavlja atraktivno rjeenje problema osiguranja QoS za viemedijski promet uz efikasno iskoritenje mrenih resursa [25]. Jedan od najveih izazova ove arhitekture je odabir signalizacijskog protokola, s obzirom da ne postoji generiki signalizacijski protokol. Standardizirana su tri signalizacijska protokola koja se mogu koristiti u MPLS mreama: Label Distribution Protocol (LDP) [26], CRLDP [27] i RSVP-TE [7]. Kako LDP prua jedino osnovne funkcionalnosti i ne podrava TE mehanizme, ne moe se koristiti u DS-TE mreama. Preostala dva rjeenja omoguavaju TE funkcionalnosti kao to su uspostava Label Switched Path (LSP), rezervacija propusnog opsega za LSP, te Fast Rerouting (FRR) mehanizmi, to predstavlja klju za ispunjavanje QoS zahtjeva. Za razliku od CR-LDP, RSVP-TE je najee koriteni signalizacijski protokol. U praksi se preferira proirivanje postojeih protokola kada god je to mogue, prvenstveno zbog napora koji je potrebno uloiti u dizajn, standardizaciju, razvoj i otklanjanje pogreki novih protokola. Iz tog razloga je RSVP-TE odabran kao MPLS signalizacijski protokol, dok se odustalo od daljnjeg razvoja CR-LDP protokola. IETF je u okviru radnih grupa pokrenuo istraivake aktivnosti u svrhu razvoja proirenja RSVP protokola kako bi podrao funkcionalnosti DiffServ-aware MPLS mrea [28]. RSVP-TE je signalizacijski protokol za MPLS TE, koji poiva na RSVP protokolu uz dodatak proirenja za MPLS TE [7] i MPSL DiffServ [31]. RSVP-TE koristi RSVP poruke za uspostavu, odravanje (osvjeavanje) i prekid TE LSP-a, te signalizaciju pogreaka. RSVP-TE se koristi u MPLS okruenju koje se razlikuje u odnosu na okruenje za koje je dizajniran originalni RSVP. U MPLS mreama ne dolazi do este i brze promjene LSP-a. Kao rezultat, RSVP-TE ne mora manipulirati velikim brojem novih ili modificiranih poruka. Veina razmjenjivani poruka predstavljaju poruke osvjeavanja koje se upravljaju mehanizama definiranim u RFC 2961. Definiranje ovog dodatka ini RSVP-TE idealnim za TE LSP unutar MPLS mree. Iako se uz TE dodatak moe razmatrati izvan QoS konteksta, RSVP protokol predstavlja primarni QoS signalizacijski protokol u IP mreama. A. Osnovna naela RSVP protokola RSVP predstavlja IP protokol za rezervaciju resursa iji je razvoj potaknut definiranjem IntServ arhitekture. Modularnost RSVP protokola ini ga neovisnim u odnosu na arhitekturu, te omoguava njegovu primjenu i u drugim signalizacijskim aplikacijama. Mree mogu koristiti RSVP prilikom uspostave LSP-a ili za IntServ rezervacije. RSVP podrava rezervaciju resursa u sluaju unicast i multicast aplikacija. RSVP modul komunicira sa dva lokalna modula za donoenje odluka, admission control i policy control. Admission control odre uje da li vor ima dovoljno raspoloivih resursa da osigura zahtijevanu QoS. Policy control osigurava autorizaciju QoS zahtjeva [9].

RSVP koristi koncept sesije koja obuhvata izvjestan broj poiljatelja i primatelja. RSVP sesija obuhvata tok podataka sa naznaenim odreditem i protokolom prijenosnog sloja. Sesija moe obuhvaati vie rezervacija u sluaju multicast destinacije. Rezervacije su jednosmjerne. Definicija RSVP sesije se mijenja kada se RSVP koristi za signalizaciju LSP-a. U tom sluaju, sesija predstavlja proizvoljni prometni tok koji poiljatelj alje prema jednom ili vie primatelja [29]. B. Naela rada RSVP protokola Rad RSVP protokola se temelji na periodinoj transmisiji i obradi Path i Resv poruka za uspostavu i odravanje rezervacije. Poiljatelji generiraju Path poruke koje nose informaciju o specifikaciji toka poiljatelja. Primatelji prenose Resv poruke nazad prema poiljateljima i izvode rezervaciju resursa. Mreni vorovi proslje uju Resv poruke na hop-by-hop principu koritenjem rezervirane putanje. ResvConf poruke slue primatelju kao potvrda uspjene rezervacije. Mreni vorovi pohranjuju i odravaju Path i Resv stanje na temelju Path i Resv poruka koje primaju. RSVP protokol posjeduje mehanizam za eksplicitni prekid rezervacije to ubrzava odziv protokola u odnosu na istek soft state vremenskog intervala. RSVP koristi PathTear i ResvTear poruke za prekid soft state-a. RSVP definira i ResvErr i PathErr poruke za notifikaciju pogreaka. Dva nova tipa poruka, Bundle i Srefresh, reduciraju koliinu informacija koje razmjenjuju susjedni RSVP vorovi radi osvjeavanja soft state-a [30]. Upotrebom Hello poruka moe se brzo uoiti ispad susjednih RSVP vorova [7]. C. Problem prijenosa RSVP poruka RSVP ne posjeduje dobar mehanizam isporuke poruka. Ako do e do gubitka poruke, retransmisija e se izvriti tek nakon isteka soft state vremenskog intervala osvjeavanja koji iznosi 30 sekundi. Uvo enje mehanizma za postepeno osvjeavanje timer-a doprinosi rjeenju ovog problema na nain da se vri retransmisija RSVP poruke sve dok prijemni vor ne potvrdi njen prijem [30]. Svaka RSVP poruka sadri informaciju o samo jednoj sesiji. U mrei koja sadri veliki broj RSVP sesija moe doi do preoptereenja usmjeritelja i potencijalnog zaguenja u mrei. U cilju rjeavanja ovog problema definiran je mehanizam koji reducira broj poruka koje se razmjenjuju izme u susjednih vorova [30]. RSVP ne daje ni podrku fragmentaciji poruka na razini protokola. Ako je veliina RSVP poruke vea od MTU, poruka e se fragmentirati. Usmjeritelji ne mogu detektirati ni vriti obradu fragmenata RSVP poruka. Rjeenje MTU problema ne postoji. Pojava signalizacijskih protokola nove generacije s prethodno opisanim MTU problemom e sprijeiti koritenje postojeih RSVP prijenosnih mehanizama. Ukoliko bude potreban novi prijenosni mehanizam, on e morati rijeiti problem pouzdanosti slanja poruka, problem pakiranja poruka, MTU problem i problem prekomjernog generiranja poruka. D. Problem performansi RSVP protokola Sloenost elemenata RSVP protokola predstavlja jedan od kljunih izazova. Prvo, RSVP se temelji na toku, stoga je broj stanja proporcionalan broju RSVP sesija. Path i

Resv stanja se moraju odravati u svakom usmjeritelju za svaku sesiju. Drugo, RSVP optimizira razliite operacije spajanja poruka prilikom multicast rezervacija to izaziva obradu velikog broja Resv poruka. Dodavanje mehanizama za rjeavanje spomenutog multicast problema predstavlja dodatni izvor pogreaka. Tree, RSVP signalizacijske poruke se ne koriste samo za odravanje stanja, nego i za rjeavanje problema gubitka istih i otkrie promjene putanje. Stoga, iako su elementi protokola koji specificiraju podatke odvojeni od signalizacijskih elemenata, dodatna obrada svih RSVP poruka nije zanemariva. Jo jedan izazov predstavlja iznos propusnog opsega koritenog tijekom trajanja sesije. RSVP poruke se alju radi iniciranja nove rezervacije ili osvjeavanja postojee rezervacije. Standardni RSVP koristi iste Path/Resv poruke i za iniciranje novih i za osvjeavanje postojeih rezervacija to rezultira poveanjem veliine poruka osvjeavanja. Hop-by-hop osvjeavanje reducira prekomjerno koritenje propusnog opsega za RSVP, ali moe rezultirati poveanjem broja izvora pogreaka. RFC 2961 uvodi novi tip RSVP poruke i reducira redundantnost osvjeavanja. E. Prednosti RSVP protokola Osim prethodno navedenih nedostataka, RSVP posjeduje i izvjesne prednosti. Najvea prednost RSVP-a je mogunost aplikacije da tono definira rezervacijske zahtjeve za tok i da za prihvaeni tok dobije vrstu garanciju kvalitete usluge. Pouzdanost, prilagodljivost i dinamika promjena soft state rezervacije predstavljaju dodatne prednosti RSVP protokola. Prilago enost primatelju je bitna prednost RSVP protokola koja ga ini pogodnim za vieodredine i heterogene skupine. Pojedini primatelj bira razinu kvalitete usluge i stvara rezervaciju odravajui je na toj razini koliko god dugo eli. Poiljatelji raspore uju promet u nekoliko razliitih RSVP tokova s razliitim razinama kvalitete usluge. Primatelj moe birati jedan ili vie RSVP tokova. Ovakav pristup omoguava heterogenim primateljima da zatrae razliite kvalitete usluga prilago ene njihovim specifinim mogunostima i potrebama. QoS upravljaki ure aji odre uju kako podesiti parametre veze da bi se postigla traena kvaliteta usluge, a RSVP samo prua mogunost distribucije tih parametara. RSVP je dizajniran da QoS parametre tretira kao nevidljive podatke koji se moraju isporuiti kontrolnim modulima u usmjeriteljima gdje se interpretiraju po potrebi. Ovo logiko odvajanje QoS kontrolnih ure aja i sredstava za distribuciju pojednostavljuje RSVP i ini ga prilagodljivim novim mrenim tehnologijama i primjenama. V. SLJEDEI KORACI U SIGNALIZACIJI Analizom prednosti i nedostataka RSVP protokola, javlja se tenja ka definiranju zahtjeva, okvira i protokola neophodnih za rjeenje problema QoS signalizacije. NSIS radna grupa je osnovana upravo s tim ciljem. Zadatak NSIS radne grupe nije definiranje novog QoS signalizacijskog protokola, ve optimizacija postojeih protokola unutar ve definiranog okvira. Namjera je ponovno uporabiti odgovarajue RSVP mehanizme uz svojevrsno pojednostavljenje i definiranje generikog signalizacijskog modela.

A. Zahtjevi za signalizacijske protokole Osnovni korak u definiranju optimalnog signalizacijskog rjeenja je zadovoljavanje postavljenih zahtijeva. NSIS je definirao skup zahtjeva koji se postavljaju pred signalizaciju u razliitim mrenim okruenjima i opisao neke scenarije njihove primjene [32]. Definirana je generika mrena arhitektura s glavnim logikim elementima [33]: NSIS zaetnik, entitet koji zapoinje proces QoS signalizacije kao rezultat korisnikog aplikacijskog zahtjeva. NSIS prosljeditelj, posredniki entitet u resoru upravljanja operacijama signalizacije du putanje prema primatelju. NSIS odgovaratelj, entitet koji zavrava proces QoS signalizacije, postavljen na kraju signalizacijske putanje. Umjesto pruanja uvida u detaljnu listu zahtjeva, u radu se daje osvrt na spomenute zahtjeve s aspekta podruja njihove primjene. Jednu skupinu ine fleksibilni i me uovisni zahtjevi koji su prikladni za signalizacijsko rjeenje. Druga skupina zahtjeva se bavi pozicijom u odnosu na putanju gdje se smjetaju tri glavna NSIS entiteta [32]. Definirana je i skupina zahtjeva koja upuuje na problem vrste poruka koje bi protokol trebao prenositi, odnosno na definiciju i rangiranje funkcionalnosti signalizacijskog protokola. Neki uvjeti su postavljeni na temelju upravljakih informacija, a drugi u odnosu na performansne zahtjeve. Prva klasa performansnih zahtjeva je u vezi sa rjeenjem problema skalabilnosti, odnosno broja razmjenjenih poruka i broja ukljuenih entiteta. Druga klasa se vie odnosi na mjerenje performansi. Performansni zahtjevi moraju biti generalizirani s obzirom da su performanse ovisne o samom scenariju. S tim u vezi, jezgro mree treba protokol koji minimizira kanjenje razmjene signalizacijskih poruka, dok se u pristupnim mreama preferira nisko iskoritenje propusnog opsega, a ne reduciranje kanjenja, posebno u sluaju beinih linkova. Sigurnost i pokretljivost, tako er, predstavljaju izazove signalizacijskog rjeenja [32]. Cilj NSIS radne grupe je analiza postojeih signalizacijskih protokola i pronalazak optimalnog protokola i njegovih proirenja u svrhu ispunjavanja postavljenih zahtjeva. Analiza postojeih QoS protokola je ve izvrena [34]. Glavni fokus je na RSVP protokolu. Njegove funkcionalnosti su detaljno razmatrane, kao i predloena rjeenja u cilju mimoilaenja njegovih nedostataka. RSVP ne moe biti izabran kao NSIS signalizacijski protokol prvenstveno zbog nedostatka podrke za pokretljivost. Odluka o izboru optimalnog generikog signalizacijskog protokola je vremenski neodre ena. B. Signalizacijski okvir Osnovna ideja signalizacijskog okvira je posjedovanje slojevitog modela, u kojem se nii sloj implementira u NSIS entitetu i predstavlja signalizacijski prijenosni sloj, dok vii sloj predstavlja signalizacijski aplikacijski sloj i specifian je za svaku aplikaciju posebno. Zbog specifinosti signalizacijskog aplikacijskog sloja, postoji nekoliko komponenti koje se realiziraju preko jedinstvenog signalizacijskog prijenosnog sloja.

Slika 4. Logike komponente unutar NSIS entiteta Signalizacijski prijenosni protokol radi na hop-by-hop osnovi. Nakon prijema signalizacijske poruke, vri se njeno proslje ivanje ka sljedeem NSIS mrenom entitetu prijenosnog sloja. Ako je signalizacijski aplikacijski sloj implementiran u tom entitetu, poruka se alje viem sloju radi daljnje obrade. Ovo je svakako glavni zadatak prijenosnog sloja, proslje ivanje signalizacijskih poruka neovisno o niim mrenim slojevima. Da bi se postigao ovaj cilj, pripadni entiteti moraju biti u mogunosti korektno izvriti lociranje partnera kome je namijenjena signalizacijska poruka. Optimalni protokol za ovaj sloj jo uvijek nije odabran u NSIS radnoj grupi. Jedan od glavnih izazova svakako predstavlja pitanje da li ukljuiti pouzdanost ili ne, ili pak prepustiti protokolima na viim slojevima eksploataciju tih funkcionalnosti. NSIS se sastoji od dva protokolna sloja koja su prikazana na slici 4. Funkcionalnosti NSIS prijenosnog signalizacijskog sloja (NTLP, NSIS Transport Layer Protocol) [35] se moraju osigurati. NTLP e leati povrh IP protokola, koji omoguava koritenje funkcionalnosti IP usmjeravanja kada je to potrebno. NLTP obuhvaa General Internet Signaling Transport (GIST) protokol koji vri prijenos signalizacijskih poruka aplikacijskog sloja. GIST se implementira iznad standardnih prijenosnih i sigurnosnih protokola (TCP, UDP, SCTP, DCCP i sl.). Signalizacijski protokol aplikacijskog sloja (NSLP, NSIS Signaling Layer Protocol) [35] koristi usluge koje nudi NTLP. Glavna razmatranja se odnose na QoS u vezi sa NSLP. Glavni izazov predstavlja garantiranje skalabilnosti. Stoga se preporuuje minimiziranje informacija neophodnih za izraavanje stanja unutar NSIS entiteta. Protokol mora biti u mogunosti podrati QoS zahtjeve na bilo kojoj razini granularnosti kako bi zadovoljio zahtjeve pojedinanih ili grupnih tokova. VI. DIFFSERV MODEL I MEHANIZMI DiffServ model [3] omoguava diferenciranje usluga u mrei tako da se razliitim aplikacijama dodijeli odgovarajua razina usluge uz zadravanje visokog stupnja skalabilnosti. Osnovna pretpostavka DiffServ mrea je da usmjeritelji unutar jezgra mree upravljaju paketima razliitih prometnih tokova vrei njihovo proslje ivanje uporabom razliitih Per-Hop Behavior (PHB). PHB se odre uje na temelju Differentiated Services Codepoint (DSCP) oznake unutar IP polja zaglavlja. Rubni usmjeritelji pridruuju DSCP oznaku

paketima na ulazu u DiffServ mreu. Prednost ove sheme lei u injenici da se vie prometnih tokova moe grupirati u jedan tok i proslijedi koritenjem istog PHB-a. Kljuni elementi DiffServ arhitekture su prikazani na slici 5. Funkcionalni blok za klasificiranje i kondicioniranje prometa se obino smjeta na ulazu/izlazu mree (slika 6). Klasificiranje prometa moe se vriti na temelju bilo kojeg polja zaglavlja. Za klasificiranje se moe koristiti prijenosni protokol, izvorina ili odredina IP adresa i sl. Nakon klasificiranja pristupa se kondicioniranju prometa. Kondicioniranje prometa se vri uporabom sljedeih elementa: mjera (meter), oznaiva (marker), oblikovatelj (shaper) i odbaciva (dropper). Mjera se koristi za uspore ivanje klasificiranih tokova sa ugovorenim prometnim profilom da bi se odredila pripadnost danom profilu. Prometni profil se uobiajeno temelji na token bucket algoritmu. Oznaiva postavlja DS polje zaglavlja paketa sukladno radu mjeraa. Oblikovatelj izaziva zakanjenje, a odbaciva odbacivanje nekih paketa klasificiranog toka kako bi se taj tok usuglasio sa specificiranim prometnim profilom prije ulaska u DiffServ jezgro [24]. PHB karakterizira vanjski opazivo proslje ivanje paketa odgovarajueg prometnog toka. PHB se moe specificirati u smislu dijeljenja resursa (npr. propusnog opsega linka, me uspremnika i prioriteta pristupa me uspremnicima) ili u smislu relativnih QoS karakteristika (npr. razina kanjenja/varijacija kanjenja i razina gubitaka paketa). IETF je specificirao odre eni broj PHB-a me u kojima se izdvajaju Default PHB, Class Selector (CS) PHB, Expedited Forwarding (EF) PHB i Assured Forwarding (AF) PHB grupe [36]. Default PHB odgovara uobiajenom best-effort nainu proslje ivanja paketa koji je dostupan u svim usmjeriteljima za standardnu vrstu prometa ija je odgovornost jednostavno proslje ivanje to je mogue vie paketa. Default PHB je namijenjen za promet koji nema posebne QoS zahtjeve. Prije pojave DiffServ arhitekture, IP mree su koristile Precedence polje unutar Type of Service (ToS) okteta IP zaglavlja za oznaavanje prioriteta. IETF je izvrio redefiniranje ToS okteta u DS polje za DiffServ mree (slika 7). U cilju odravanja kompatibilnosti sa mrenim ure ajima koji jo uvijek koriste Precedence polje, unutar DiffServ arhitekture je definiran CS PHB [37].

Slika 5. DiffServ arhitektura

Slika 6. DiffServ klasifikator i kondicioner prometa EF PHB [38] prua uslugu proslje ivanja paketa sa malim iznosom kanjenja, varijacije kanjenja i gubitka paketa. EF PHB garantira da se promet posluuje brzinom koja je najmanje jednaka konfiguriranoj minimalnoj brzini posluivanja. AF PHB [39] grupe su namijenjene aplikacijama koje zahtijevaju malu razinu gubitka paketa sve dok grupirani promet ostaje unutar korisnikog/pretplatnikog profila. Proslje ivanje paketa se vri u jednu od 4 AF klase. Unutar svake AF klase paketu se pridruuje jedan od 3 prioriteta odbacivanja. Svaki PHB se oznaava sa AFij pri emu i oznaava AF klasu, a j prioritet odbacivanja. Svakoj AF klasi su dodijeljeni resursi ukljuujui i propusni opseg. Proslje ivanje je neovisno izme u AF klasa. Unutar AF klase, paketi sa vrijednou prioriteta p mogu imati manji iznos gubitaka u odnosu na pakete sa vrijednou prioriteta q, ako je p<q. Paketi su zatieni od gubitka redoslijeda unutar zadate AF klase bez obzira na nivo prioriteta. PHB definicije ne specificiraju niti jedan implementacijski mehanizam. U cilju implementacije PHB-a, potrebno je aktivirati i podesiti odgovarajuu kombinaciju mehanizama za proslje ivanje paketa i AQM mehanizama koji su podrani od strane DiffServ usmjeritelja. Mehanizmi za upravljanje redovima ekanja definiraju politiku odbacivanja paketa u sluaju zaguenja. Najjednostavniji i najee koritena politika odbacivanja paketa je tail-drop. Tail-drop jednostavno odbacuje dolazne pakete kada do e do prenapunjenosti me uspremnika. Prilikom pojave zaguenja, tail drop mehanizam moe dovesti do poveanja kanjenja, odbacivanja skupine paketa, nepravilne razdiobe propusnog opsega i globalne oscilacije prometnih izvora. U cilju rjeavanja ovih problema objavljen je odre en broj algoritama za aktivno upravljanje redovima ekanja (Active Queue Management, AQM). Random Early Detection (RED), Weighted Random Early Detection (WRED), DSCP-Based WRED i Explicit Congestion Notification (ECN) su primjeri najee implementiranih AQM mehanizama unutar DiffServ usmjeritelja. AQM mehanizmi se koriste za informiranje poiljatelja o pojavi zaguenja prije nego to do e do prenapunjenost me uspremnika [40].

Raspore ivanje predstavlja proces donoenja odluke o redoslijedu proslje ivanja paketa. Raspore ivanje se doga a kada se na suelju pojavi zaguenje, ali tako er i na sueljima na kojima nema zaguenja. Ako na suelju nema zaguenja, paketi se proslje uju redoslijedom kojim dolaze. Ako se na suelju dogodi zaguenje, koriste se algoritmi raspore ivanja i proslje ivanja paketa u redove ekanja. Raspore iva mora donijeti odluku o redoslijedu posluivanja redova ekanja. Ova odluka se donosi koritenjem razliitih tipova algoritama za raspore ivanje i proslje ivanje paketa iz redova ekanja. First In First Out (FIFO), Priority Queuing (PQ), Custom Queuing (CQ) i Weighted Fair Queueing (WFQ) predstavljaju osnovne mehanizme za raspore ivanje i proslje ivanje paketa iz redova ekanja. Noviji mehanizmi, kao to su PQ-WFQ, Class-Based Weighted Fair Queuing (CBWFQ) i Low-Latency Queuing (LLQ), nastoje kombinirati najbolje karakteristike osnovnih algoritama i minimizirati njihove nedostatke [40]. VII. DEFINIRANJE KLASE USLUGE ZA QOS
SIGNALIZACIJU

DiffServ arhitektura prua efikasno i skalabilno rjeenje koje osigurava QoS na temelju klasificiranja prometa u definirani skup klasa usluge. Definicije klasa usluga se temelje na karakteristikama razliitih vrsta prometa i zahtijevanim performansama aplikacija/usluga. Specifini zahtjevi prometnih tokova se realiziraju primjenom DSCP klasificiranja prometa, kondicioniranja prometa, PHB i AQM mehanizama. Definirano je 12 razliitih klasa usluga, 2 za mreno funkcioniranje i 10 za korisnike aplikacije/usluge [41]. S obzirom na tematiku rada posebnu panju zahtijeva klasa usluge za signalizacijski i kontrolni promet i klasa usluge za mreno upravljanje. A. Klasa usluge za signalizacijski i kontrolni promet Klasa usluge za signalizacijski i kontrolni promet se koristi za upravljanje sesijama i aplikacijama. Signalizacijski promet karakterizira varijabilna veliina paketa, isprekidan prometni tok, povremena navala prometa i upravljake poruke osjetljive na kanjenje. Stoga, aplikacije koje koriste ovu klasu usluge zahtijevaju relativno brz odgovor, malu vjerojatnost odbacivanja paketa i kanjenja unutar redova ekanja prilikom vrnog optereenja mree. Klasa usluge za signalizacijski i kontrolni promet trebala bi koristiti CS PHB. Osim SIP i RTCP protokola, postoji odre eni broj signalizacijskih protokola (H.323, H.248/MEGACO Media Gateway Control Protocol MGCP, Internet Group Management Protocol IGMP i sl.) kojima se preporuuje oznaavanje sa CS5 DSCP kako bi se osigurao minimalan propusni opseg potreban za njihovo proslje ivanje. Za kondicioniranje prometa unutar CS PHB-a koristi se token bucket algoritam za postizanje kontrole brzine i koliine navale prometa. Klasa usluge za signalizacijski i kontrolni promet bi se trebala realizirati koritenjem sustava za raspore ivanje paketa u redove ekanja i njihovo proslje ivanje pri odre enoj brzini. WFQ ili Weighted Round Robin (WRR) su primjeri ovog tipa sustava u kojima kanjenje paketa ovisi o parametrima i stupnju zauzetosti osobnog reda ekanja i konkurentnih redova ekanja. Signalizacijskom i kontrolnom prometu je neophodno osigurati poboljanu best-effort uslugu sa kontroliranom

Slika 7. Veza izme u ToS i DSCP/ECN polja

brzinom i kanjenjem. Za promet unutar ove klase usluge mora se omoguiti dovoljno propusnog opsega u mrei i malo kanjenje. CS5 oznaeni tokovi ne odgovaraju dinamiki na gubitak paketa. Stoga se prilikom realizacije izbjegava uporaba AQM mehanizama. B. Klasa usluge za mreno upravljanje Klasa usluge za mreno upravljanje se koristi za prijenos paketa izme u mrenih ure aja koji zahtijevaju razmjenu kontrolnih informacija (usmjeravanje) izme u vorova unutar administrativne domene, kao i partnerskih toaka izme u razliitih administrativnih domena. Promet koji se prenosi ovom klasom je veoma vaan jer odrava radno stanje mree i stoga se paketi moraju proslje ivati na vrijeme i bez gubitaka. Karakterizira ga varijabilna veliina paketa, slanje pojedinanih paketa uz povremenu pojavu navale prometa. Klasa usluge za mreno upravljanje bi se trebala konfigurirati koritenjem CS PHB na nain da se osigura dovoljno propusnog opsega, minimalna vjerojatnost odbacivanja i pravovremeno opsluivanje paketa. Osim signalizacijskim protokolima (CR-LDP i RSVP-TE), i protokolima za usmjeravanje (Open Shortest Path First OSPF, Border Gateway Protocol BGP, Intermediate System Intermediate System ISIS, Routing Information Protocol RIP) se preporuuje oznaavanje sa CS6 DSCP, dok je CS7 DSCP vrijednost rezervirana za buduu uporabu. Za kondicioniranje prometa unutar CS PHB-a koristi se token bucket algoritam za postizanje kontrole brzine i koliine navale prometa. Klasa usluge za mreni promet bi se trebala realizirati uporabom sustava za raspore ivanje paketa u redove ekanja i njihovo proslje ivanje pri odre enoj brzini. Klasi usluge za mreno upravljanje neophodno je osigurati poboljanu best-effort uslugu sa visokim stupnjem osiguranja propusnog opsega. S obzirom da se ova klasa usluge koristi za proslje ivanje elastinih i neelastinih tokova, usluga bi se trebala realizirati uporabom AQM mehanizama. VIII. ZAKLJUAK Prihvaanjem Internet tehnologija za prijenos medija, SIP protokol postaje predvodnik promjena koje e uvesti nove vidove komuniciranja me u ljudima i mogunosti realiziranja i koritenja brojnih novih usluga [42]. Vrlo iva standardizacijska aktivnost usmjerena na dogradnju SIP protokola i njegovu primjenu, svjedoi o tome da SIP postaje nezaobilazan protokol u novim, IP temeljenim telekomunikacijskim mreama. Kljuni izazov u ovim mreama predstavlja unapre enje kvalitete usluge. RTCP protokol prua informacije o kvaliteti distribucije RTP tokova zaduenih za prijenos vremenski osjetljivih podataka koje koriste QoS mehanizmi. Ni RTCP, niti SIP protokol ne mogu samostalno odgovoriti na QoS zahtjeve, stoga se moraju naslanjati na postojee QoS modele i mehanizme radi postizanja ovog cilja. Pravilnim izborom zadovoljavajue kombinacije QoS mehanizama i realizacijom klase usluge za signalizacijski i kontrolni promet potencijalno se mogu rijeiti dva fundamentalna problema. Prvi problem se odnosi na pitanje kako prilagoditi signalizacijske i kontrolne pakete na konstantno promjenljivu propusnost i uvjete zaguenja. Drugi problem zahtjeva rjeenja za savladavanje problema kanjenja i gubitka signalizacijskih paketa.

Navedeni problemi nisu neovisni te se kao takvi ne mogu odvojeno razmatrati i prouavati. Povezuje ih utjecaj na unapre enje kvalitete usluge koja se nudi krajnjem korisniku. Rezultat uvo enja strategije prioritetnog tretmana signalizacijskih i kontrolnih poruka moe imati veliki znaaj na podruja koja nisu direktno vidljiva za krajnjeg korisnika, ali zato jesu za davatelja usluga. Iako je u tekstu analizirano stanje razvoja postojeih i buduih QoS signalizacijskih protokola, u fokusu budueg istraivanja bit e SIP i RTCP protokol kao svojevrsni predstavnici klase usluge za signalizacijski i kontrolni promet, kao i pristupi u formiranju odgovarajueg skupa mehanizma za osiguranje kvalitete usluge. REFERENCE
[1] [2] J. Rosenberg, et.al., SIP: Session Initiation Protocol, Technical Report RFC 3261, IETF, June 2002. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, Technical Report RFC 3550, IETF, July 2003. S. Blake, et al., An Architecture for Differentiated Service, Technical Report RFC 2475, IETF, December 1998. E. C. Rosen, et al., Multiprotocol Label Switching Architecture, Technical Report RFC 3031, IETF, January 2001. D. Awduche, et al., Requirements for Traffic Engineering over MPLS, Technical Report RFC 2702, IETF, September 1999. F. Le Faucheur, et al., Requirements for Support of Differetiated Services-aware MPLS Traffic Engineering, Technical Report RFC 3564, IETF, July 2003. D. Awduche, et al., RSVP-TE: Extensions to RSVP for LSP Tunnels, Technical Report RFC 3209, IETF, December 2001. L. Andersson et al., The Multiprotcol Label Switching (MPLS) Working Group decision on MPLS signaling protocols, Technical Report RFC 3468, IETF, February 2003. B. Braden, et al., Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification, Technical Report RFC 2205, IETF, September 1997. Next Step in Signaling (NSIS) IETF Working Group. http://www.ietf.org/html.charters/nsis-charter.html M. Schmidt et al., IMS Interoperability and Conformance Aspects, IEEE Communication Magazine, Vol. 45, No. 3, pp. 138-142, March 2007. M. Handley, V. Jacobson, C. Perkins, SDP: Session Description Protocol, Technical Report RFC 4566, IETF, July 2006. G. Camarilo, SIP Demystified, McGraw-Hill Companies, Inc., 2002. J. Rosenberg, H. Schulzrinne, An Offer/Answer Model with Session Description Protocol (SDP), Technical Report RFC 3264, IETF, June 2002. D. Willis, B. Campbell, Session Initation Protocol Extension to Assure Congestion Safety, Internet Draft (work in progress), February 2003. draft-ietf-sip-congestsafe-01.txt G. Camarillo, W. Marshall, J. Rosenberg, Integration of Resource Management and Session Initation Protocol (SIP), Technical Report RFC 3312, IETF, October 2002. D. Durham et al., The COPS (Common Open Policy Service) Protocol, Technical Report RFC 2748, IETF, January 2000. S. Salsano, L. Veltri, QoS Control by Means of COPS to Support SIP Based Applications, IEEE Networks, Vol. 16, No.2, pp 27-33, March/April 2002. L. Veltri, S. Salsano, D. Papalilo, SIP Extensions for QoS Support, Internet Draft (work in progress), October 2002. draftveltri-sip-qsip-01.txt T. Friedman, R. Caceres, A. Clark, RTP Control Protocol Extended Reports (RTCP XR), Technical Report RFC 3611, IETF, November 2003. C.Perkins, RTP: Audio and Video for Internet, Addison Wesley, June 2003. M. Handley, S. Floyd, J. Padhye, J. Widmer, TCP Friendly Rate Control (TFRC): Protocol Specification, Technical Report RFC 3448, IETF, January 2003.

[3] [4] [5] [6]

[7] [8]

[9]

[10] [11]

[12] [13] [14]

[15]

[16]

[17] [18]

[19]

[20]

[21] [22]

[23] E. Kohler, M. Handley, S. Floyd, Datagram Congestion Control Protocol (DCCP), Technical Report RFC4340, IETF, March 2006. [24] T. Szigeti, C. Hattingh, End-to-End QoS Network Design, Cisco Press, November 2004. [25] J. Barakovic, H. Bajric, A. Husic, QoS Design Issues and Traffic Engineering in Next Generation IP/MPLS Network, ConTEL 2007, June 2007. [26] L. Andersson et al., LDP Specification, Technical Report RFC 3036, IETF, January 2001. [27] B. Jamoussi et al., Constraint-Based LSP Setup using LDP, Technical Report RFC 3212, IETF, January 2002. [28] F. Le Faucher, Protocol Extensions for Support of DiffServaware MPLS Traffic Engineering, Technical Report RFC 4124, IETF, June 2005. [29] S. Alvarez, QoS for IP/MPLS Networks, Cisco Press, June 2006. [30] L. Berger, RSVP Refresh Overhead Reduction Extension, Technical Report RFC 2961, IETF, April 2001. [31] F. Le Faucher et al., Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, Technical Report RFC 3270, IETF, May 2002. [32] M. Brunner, Requirements for Signaling Protocols, Technical Report RFC 3726, IETF, April 2004. [33] R. Hancock et al., Next Steps in Signaling (NSIS) Framework, Technical Report RFC 4080, IETF, June 2005.

[34] J. Manner, X. Fu, Analysis of Existing Quality-of-Service Signaling Protocols, Technical Report RFC 4094, IETF, May 2005. [35] X. Fu, et al., NSIS: A New Extensible IP Sinaling Protocol Suite, IEEE Communication Magazine, pp 133-141, October 2005. [36] V. Risnen, Implementing Service Quality in IP Networks, John Wiley & Sons Ltd, 2003. [37] K. Nichols et al. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, Technical Report RFC 2474, IETF, December 1998. [38] B. Davie, et al., An Expedited Forwarding PHB (Per-Hop Behavior), Technical Report RFC 3246, IETF, March 2002. [39] J. Heinanen, et al. Assured Forwarding PHB Group, Technical Report RFC 2597, IETF, June 1999. [40] K. I. Park, QoS in Packet Networks, Springer Science + Business Media, Inc., 2005. [41] J. Babiarz, K. Chan, F. Baker, Configuration Guidelines for DiffServ Service Classes, Technical Report RFC 4594, IETF, August 2006. [42] H. Sinnreich, A. B. Johnson, Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol, Second Edition, Wiley Publishing, Inc., 2006.