QoS

QoS signalizacija u višeuslužnim mrežama sljedeće generacije Jasmina Baraković BH Telecom d.d. Sarajevo [email protected]

Sažetak - Session Initiation Protocol (SIP) predstavlja protokol namijenjen za upravljanje sesijom u višeuslužnim mrežama sljedeće generacije. Ključni izazov u ovim mrežama predstavlja osiguranje kvalitete usluge (Quality of Service, QoS) za krajnje korisničke aplikacije uz efektivno iskorištenje mrežnih resursa. Real-time Transport Control Protocol (RTCP) osigurava razmjenu QoS informacija, ali ne garantira QoS za vremenski osjetljive usluge, niti omogućava rezervaciju resursa. S obzirom da SIP i RTCP ne osiguravaju QoS, moraju se naslanjati na postojeće QoS arhitekture radi postizanja željenog cilja. Arhitektura diferenciranih usluga (Differentiated Service, DiffServ) se pojavljuje kao skalabilno rješenje koje osigurava višestruke klase usluga unutar mreže. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), s druge strane, omogućava rezervaciju resursa, toleranciju na pogreške i optimizaciju prijenosnih resursa. Izbor signalizacijskog protokola za razmjenu DiffServ, MPLS i TE informacija predstavlja ključni izazov MPLS DiffServ-aware TE arhitekture koja kombinira prednosti ovih rješenja. Resource Reservation Protocol (RSVP) sa nekoliko proširenja predstavlja postojeće rješenje problema QoS signalizacije. Na definiranju budućih 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 postojećim i budućim QoS signalizacijskim protokolima. Razmotrena je potreba uvođenja klase usluge za signalizacijski i kontrolni prometa, te rješenje problema prioritetnog tretmana klase usluge za signalizacijski i kontrolni promet. Ključne riječi - 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 održavanje sesije između dva ili više partnera u komunikaciji. U većini slučajeva, usluge koje zahtijevaju uspostavu sesije zahtijevaju i određeni stupanj kvalitete (Quality of Service, QoS). SIP samostalno ne može odgovoriti na QoS zahtjeve takvih usluga, što i nije njegova svrha, niti može osigurati odgovarajuću razmjenu QoS signalizacijskih informacija u cilju ostvarivanja QoS podrške. 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 periodičkoj razmjeni kontrolnih paketa između svih sudionika sesije koristeći

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 proširenja SIP i RTCP protokola radi upravljanja mrežnim zagušenjem i suočavanja sa problemima koji se mogu dogoditi korištenjem nepouzdanog User Datagram Protocol (UDP) na prijenosnom sloju. Pošto i SIP i RTCP mogu raditi preko UDP protokola koji ne garantira kontrolu toka, učestala je pojava mrežnog zagušenja i posljedična QoS degradacija. Proširenje SIP i RTCP protokola u tom kontekstu je od velikog značaja, s obzirom da nema smisla raditi na pružanju QoS podrške ako protokol radi pod rizikom nastanka mrežnog zagušenja. SIP i RTCP ne osiguravaju QoS, stoga se moraju naslanjati na postojeće QoS arhitekture radi ostvarivanja ovog cilja što može prouzročiti problem interoperabilnosti između QoS arhitekture i protokola. Iz tog razloga, posebna pažnja se posvećuje radu na poboljšanju interoperabilnosti, ali i izboru QoS arhitekture. Differentiated Service (DiffServ) arhitektura [3] predstavlja efikasno i skalabilno rješenje koje osigurava QoS u Internet Protocol (IP) mrežama. 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 pogreške i optimizacija iskorištenosti resursa [5]. Kombinirana uporaba DiffServ i MPLS arhitekture [6] predstavlja atraktivno rješenje problema osiguranja QoS za multimedijski promet uz efikasno iskorištenje mrežnih resursa. Rezultat ove integracije je DiffServ-aware Traffic Engineering (DS-TE). Ovaj model omogućava da MPLS-TE spozna klase usluge (Class of Servce, CoS) i osigura rezervaciju resursa sa CoS granularnošću, te MPLS toleranciju na pogreške na CoS razini. U cilju omogućavanja DS-TE funkcionalnosti, potrebna je razmjena DiffServ, MPLS i TE informacija između usmjeritelja u kontrolnoj ravni posredstvom dinamičkog 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 proširenje RSVP [9] protokola koji je razvijen u okviru Integrated Services (IntServ) arhitekture. S obzirom na nedostatke RSVP kao QoS signalizacijskog protokola, potrebno je izvršiti njegovu optimizaciju.

IETF Next Step in Signaling (NSIS) [10] radna grupa formirana je s ciljem rješavanja problema QoS signalizacije. Njen rad se fokusira na definiranju zahtjeva, okvira i protokola neophodnih za postizanje tog cilja uz analizu postojećih QoS signalizacijskih protokola. Zadatak NSIS radne grupe nije definiranje novog QoS signalizacijskog protokola, već optimizacija postojećih protokola unutar definiranog okvira. Namjera je ponovno uporabiti odgovarajuće RSVP mehanizme uz svojevrsno pojednostavljenje i definiranje generičkog signalizacijskog modela. II. SIP SIGNALIZACIJSKI PROTOKOL SIP je signalizacijski protokol aplikacijske razine razvijen u svrhu kreiranja, promjene i prekida višemedijskih sesija ili poziva između dva ili više sudionika, lociranja korisnika i preusmjeravanja poziva, omogućavanja mobilnosti preusmjeravanjem poziva i upotrebom proxy poslužitelja. Iako ga je razvio i standardizirao IETF, prihvatila su ga i ostala značajna međunarodna standardizacijska tijela kao glavni protokol u višemedijskim domenama 3G mobilnih sustava, IP Multimedia Subsystem (IMS), te kao okosnicu mreža sljedeće generacije (Next Generation Network, NGN) [11]. S migracijom tradicionalnih telekomunikacijskih mreža prema IP višeuslužnim i višemedijskim mrežama, SIP protokol dobiva nezaobilaznu važnost. Sve interesne grupe u telekomunikacijskoj industriji su se usuglasile da je protokol SIP glavno sredstvo realizacije višemedijskih komunikacijskih usluga sljedeće generacije. A. Osnovna načela SIP protokola SIP je temeljen na HTTP (Hypertext Transport Protocol) transakcijskom modelu zahtjeva i odgovora. SIP se ne koristi za opis obilježja 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 važna je karakteristika koja SIP predstavlja kao učinkovit protokol, budući da se može 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 omogućava multimediju (slika 1). Iako se SIP, zajedno sa navedenim protokolima, koristi u svrhu omogućavanja potpune usluge korisnicima, njegova osnovna funkcionalnost ne ovisi niti o jednom od navedenih protokola.

Slika 1. IETF protokol stog za multimediju

SIP je strukturiran kao slojeviti protokol, pri čemu svaki sloj definira određeni skup pravila. Najniži sloj SIP protokola predstavlja njegova sintaksa i kodiranje. Drugi sloj je prijenosni sloj koji definira kako klijent šalje zahtjeve i prima odgovore putem mreže. Sve komponente SIP protokola moraju implementirati UDP i Transport Control Protocol (TCP), ali mogu koristiti i Stream Control Transmission Protocol (SCTP). Treći 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 značajke SIP protokola su određivanje lokacije, mogućnosti i dostupnosti korisnika te uspostava i upravljanje višemedijskim sesijama [13]. To je omogućeno sljedećim logičkim komponentama koje čine temelj bilo koje arhitekture koja koristi SIP: korisnički agenti, registri, proxy poslužitelji i redirekcioni poslužitelji (slika 2). Razlika između SIP poslužitelja je logička, a ne fizička, što znači da se SIP poslužitelj istovremeno može ponašati kao registar i proxy. Korisnički agenti mogu biti u svojstvu klijenta ili poslužitelja, pri čemu je razlika opet logička. Korisnički agent u svojstvu klijenta predstavlja entitet koji inicira sesiju slanjem zahtjeva, dok korisnički agent u svojstvu poslužitelja vrši obradu zahtjeva i šalje odgovarajući odgovor. Registri su entiteti u kojima se vrši registracija SIP korisnika u cilju lokalizacije SIP korisnika. Proxy poslužitelji su posrednički entiteti koji prihvaćaju i prosljeđuju SIP poruke. Redirekcioni poslužitelji izvode slične zadatke i vrše 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]. Korisnički agent generira opis sesije (offer) koja sadrži informacije neophodne za uspostavu sesije i šalje ga ka udaljenom korisničkom agentu. Udaljeni korisnički agent generira vlastiti opis sesije, odnosno answer po prijemu offer-a. Nakon završetka offer/answer razmjene započinje razmjena tokova medija između korisničkih agenata, što je znak da je sesija uspostavljena. Putanja SIP poruka može 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 može koristiti pouzdani ili nepouzdani način prijenosa, kao što su SCTP, TCP ili UDP protokol. Preporučuje se uporaba UDP protokola, s obzirom da se na taj način izbjegava faza uspostave i raskida TCP veze. TCP je sigurniji način prijenosa SIP poruka jer postoji kontrola postojeće TCP veze otvorene za uspostavu sesije. Najveći problem TCP prijenosa je moguće kašnjenje prilikom uspostave veze. UDP protokol karakteriziraju dva nedostatka. Prvi problem predstavlja nedostatak mehanizama za kontrolu mrežnog zagušenja što je neophodno za prevenciju mrežnog 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 2. SIP logičke komponente i uspostava sesije SIP ne osigurava mehanizam za upravljanje zagušenjem. Jedini pokušaj SIP-a da riješi problem zagušenja je korištenjem eksponencijalnih retransmisijskih back-off timer-a i ograničavanje veličine poruka koje se prenose preko UDP-a. Referenca [15] definira značenje sigurnog rada SIP protokola u odnosu na pojavu zagušenja i proširenje osnovnog protokola na temelju kojeg SIP entitet može raditi na spomenuti način. Definirana su pravila koja se moraju poštivati kada se SIP poruke prenose preko UDP-a [15]. Jedno od pravila je da se uvijek koristi TCP ukoliko sljedeći skok predstavlja proxy, a UDP jedino ukoliko je sljedeći skok korisnički agent. Nedostatak ovog pristupa leži u tome što SIP čvor ne zna da li je naredni čvor korisnički agent ili proxy, niti sprečava pojavu zagušenja prilikom posljednjeg skoka. Definirana su dva zahtjeva kada se za prijenos SIP poruka koristi UDP. Prvo, slanje SIP zahtijeva korištenjem UDP-a ne smije uzrokovati zagušenje u mreži. Jednostavan pristup u postizanju ovakvog ponašanja je slanje zahtjeva jedino u slučaju prijema odziva na prethodni zahtjev. Nedostatak ovog pristupa je smanjenje propusnosti, jer se prijenos odvija na simplex način, što uzrokuje minimalno 2xRTT kašnjenje između transmisija. Drugo, prilikom slanja SIP poruka uporabom UDP-a treba se izbjegavati slanje poruka čija je veličina veća u odnosu na Maximum Transmission Unit (MTU) za taj link. Pošto SIP protokol ne osigurava način da ukaže na dozvoljenu veličinu, 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 potiču. Stoga, ako SIP entitet primi zahtjev na siguran način u odnosu na zagušenje, može se pretpostaviti da će i odgovor biti generiran na isti način. Vrijedi i suprotno. Ukoliko je veličina generiranog odgovora manja u odnosu na pridruženi zahtjev, odgovor se neće fragmentirati i može se smatrati sigurnim u odnosu na zagušenje. Entitet koji generira odgovor, a ne poznaje MTU putanje na koju će ga proslijediti, mora odbiti zahtjev radi izbjegavanja rizika fragmentacije odgovora. E. QoS podrška u SIP sesiji Aplikacije koje koriste SIP zahtijevaju QoS podršku, stoga je potrebno omogućiti 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 vrši povezivanje SIP-a sa mehanizmima za rezervaciju resursa korištenjem tzv. koncepta preduvjeta [16]. Preduvjeti predstavljaju skup zahtjeva koje SIP korisnički agenti moraju ispuniti u cilju započinjanja ili nastavka SIP sesije. Potreba za preduvjetima dolazi od mišljenja da uspostava nekih sesija može imati negativan ishod ukoliko se ne izvrši rezervacija resursa. S druge strane, mehanizmi za rezervaciju resursa često zahtijevaju korištenje parametara koji se koriste u kontekstu SIP signalizacijske razmjene. Predloženo rješenje stvara pretpostavku da začetnik 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 kašnjenje prilikom uspostave SIP sesije s obzirom da mrežni resursi moraju biti rezervirani prije toga. 2) QoS proširenja SIP protokola Drugi prijedlog ostvarivanja QoS podrške 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 utiče na modifikaciju implementacije korisničkih agenata. Reference [18,19] predlažu rješenje u kojem se izbjegava uključenje korisničkih agenata u operacije QoS signalizacije, odnosno rješenje u kojem su QoS funkcije implementirane u lokalnom SIP poslužitelju. III. RTCP KONTROLNI PROTOKOL U višemedijskim mrežama sljedeće generacije prijenos vremenski osjetljivih tokova i signalizacijskih poruka se vrši 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 različitih tipova korisnih podataka. Iako je proširiv u smislu definiranja profila za formate i tipove korisnih podataka, RTP posjeduje brojna ograničenja. 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 mreže. RTP ne omogućava 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 složeni 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 načela RTCP protokola RTCP protokol je definiran s namjerom da podrži veliki broj funkcionalnosti uključujući kontrolu RTP sesija, nadzor kvalitete i sinkronizaciju više RTP tokova medija. RTCP se temelji na periodičkom prijenosu kontrolnih paketa između svih sudionika sesije. Primarna funkcija RTCP protokola je osiguranje povratne informacije o kvaliteti prijema vremenski osjetljivih podataka uporabom izvještaja pošiljatelja (Sender Report, SR) i izvještaja primatelja (Receiver Report, RR). Korištenjem ovih upravljačkih poruka RTCP protokol vrši prikupljanje i razmjenu statističkih podataka kao što su ukupan broj prenesenih RTP paketa i okteta, ukupan broj izgubljenih RTP paketa, kašnjenje paketa i sl. Na temelju prikupljenih informacija pošiljatelj se može prilagoditi dinamičkim promjenama mreže (npr. korištenjem tehnika adaptivnog kodiranja, povećanjem redundantnosti i formata za niskopropusno kodiranje), a primatelj utvrditi razmjeru eventualno nastalog zagušenja u mreži. Prijenos detaljnijih informacija i inkorporiranje dodatnih statističkih podataka u RTCP pakete moguće je ostvariti korištenjem proširenog izvještaja (eXtended Report, XR) [20]. RTCP XR osigurava mrežnim operatorima dodatne informacije iz kojih se može zaključiti o mrežnim performansama i zadovoljavanju Service Level Agreement (SLA) danog korisnika. B.

Načela rada RTCP protokola Brzina slanja RTCP paketa nije fiksna. Ona varira u skladu s veličinom sesije i formatom toka medija. Cilj je ograničiti ukupni iznos RTCP prometa na fiksni iznos koji iznosi 5% propusnog opsega. To se postiže reduciranjem brzine kojom svaki sudionik šalje RTCP pakete kako se povećava veličina sesije. Prosječno vrijeme koje svaki sudionik čeka između slanja RTCP paketa je poznato kao interval izvještavanja. On se računa na temelju nekoliko faktora: propusnog opsega dodijeljenog RTCP-u, prosječne veličine primljenih i poslanih RTCP paketa i ukupnog broja sudionika sesije i broja pošiljatelja. Prvi RTCP paket se raspoređuje za prijenos na temelju inicijalne ocjene vremena izvještavanja. Stvarno vrijeme između paketa je slučajno, u rasponu između jedne polovine i tri polovine intervala izvještavanja. Ako se radi o prvom RTCP paketu, interval se prepolovi da bi omogućio bržu povratnu informaciju novim sudionicima sesije. Ako je broj pošiljatelja veći od nule, ali manji od četvrtine ukupnog broja sudionika sesije, interval izvještavanja ovisi o tome da li se šalje. Ako se šalje, interval izvještavanja predstavlja umnožak broja pošiljatelja i prosječne veličine RTCP paketa koji se dijeli sa 25% željenog propusnog opsega. Ako se ne šalje, interval izvještavanja predstavlja umnožak broja primatelja i prosječne veličine RTCP paketa podijeljen sa 75% RTCP propusnog opsega. Ako nema pošiljatelja, ili ako su više od četvrtine sudionika pošiljatelji, interval izvještavanja se računa kao umnožak prosječne veličine 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 sljedećeg RTCP pakta. Poseban rizik od promjene broja sudionika se dešava tijekom faze uspostave ili prekida sesije kada se veliki broj sudionika uključuje ili napušta sesiju. Poseban izazov predstavlja

slučaj kada se u sesiju istovremeno uključi veliki broj sudionika. U tom slučaju se primjenjuje algoritam koji vrši provjeru veličine grupe u trenutku raspoređenom za slanje sljedećeg RTCP paketa i rekalkuliranje intervala. U slučaju kada veliki broj sudionika napušta sesiju, primjenjuje se algoritam koji vrši prilagođavanje trenutka za slanje sljedećeg RTCP paketa u skladu sa promjenom broja sudionika u ovisnosti o trenutnom i pretpostavljenom broju sudionika u trenutku raspoređenom za slanje sljedećeg RTCP paketa. C. Problem prijenosa RTCP poruka RTCP protokol se temelji na načelima razmjene povratnih informacija o kvaliteti prijema vremenski osjetljivih podataka. Pomoću analize povratnih informacija, pošiljatelji mogu vršiti prilagodbu brzine podataka sukladno uvjetima u mreži. Usporedbom statističkih podataka iz izvještaja pošiljatelja i primatelja može se ocijeniti kvaliteta distribucije vremenski osjetljivih podataka, implementirati nadzor kvalitete neovisno o kodiranju i profilu podataka, proračunati brzina gubitka paketa i odrediti razina zagušenja mreže 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. Pošto RTCP protokol osigurava povratnu informaciju svim sudionicima sesije koristeći iste mehanizme distribucije koji se koriste za prijenos vremenski osjetljivih podataka, neophodno je omogućiti pravovremen i pouzdan prijenos ovih poruka. Da bi se pošiljatelj prilagodio dinamičkim promjenama mreže, mora se osigurati prijenos RTCP poruka bez kašnjenja i gubitaka. Prihvaćanjem UDP protokola za prijenos RTP/RTCP paketa javlja se problem upravljanja zagušenjem koje dovodi do potencijalne nestabilnosti mreže. S obzirom na primarnu funkciju RTCP protokola može se zaključiti da je upravljanje zagušenjem 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 zaključak da ni SIP, niti RTCP protokol ne mogu osigurati kvalitetu usluge bez odgovarajuće QoS podrške (slika 3).

Slika 3. QoS podrška

DiffServ arhitektura predstavlja efikasno i skalabilno rješenje za osiguranje QoS u IP mrežama. U cilju optimiziranja prijenosnih resursa, ova arhitektura se kombinira sa MPLS tehnologijom koja omogućuje TE funkcionalnosti kao što su rezervacija resursa, tolerancija na pogreške i optimizacija iskorištenosti resursa. Integracija DiffServ i MPLS arhitekture predstavlja atraktivno rješenje problema osiguranja QoS za višemedijski promet uz efikasno iskorištenje mrežnih resursa [25]. Jedan od najvećih izazova ove arhitekture je odabir signalizacijskog protokola, s obzirom da ne postoji generički signalizacijski protokol. Standardizirana su tri signalizacijska protokola koja se mogu koristiti u MPLS mrežama: Label Distribution Protocol (LDP) [26], CRLDP [27] i RSVP-TE [7]. Kako LDP pruža jedino osnovne funkcionalnosti i ne podržava TE mehanizme, ne može se koristiti u DS-TE mrežama. Preostala dva rješenja omogućavaju 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 najčešće korišteni signalizacijski protokol. U praksi se preferira proširivanje postojećih protokola kada god je to moguće, prvenstveno zbog napora koji je potrebno uložiti u dizajn, standardizaciju, razvoj i otklanjanje pogreški 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 istraživačke aktivnosti u svrhu razvoja proširenja RSVP protokola kako bi podržao funkcionalnosti DiffServ-aware MPLS mreža [28]. RSVP-TE je signalizacijski protokol za MPLS TE, koji počiva na RSVP protokolu uz dodatak proširenja za MPLS TE [7] i MPSL DiffServ [31]. RSVP-TE koristi RSVP poruke za uspostavu, održavanje (osvježavanje) i prekid TE LSP-a, te signalizaciju pogrešaka. RSVP-TE se koristi u MPLS okruženju koje se razlikuje u odnosu na okruženje za koje je dizajniran originalni RSVP. U MPLS mrežama ne dolazi do česte i brze promjene LSP-a. Kao rezultat, RSVP-TE ne mora manipulirati velikim brojem novih ili modificiranih poruka. Većina razmjenjivani poruka predstavljaju poruke osvježavanja koje se upravljaju mehanizama definiranim u RFC 2961. Definiranje ovog dodatka čini RSVP-TE idealnim za TE LSP unutar MPLS mreže. Iako se uz TE dodatak može razmatrati izvan QoS konteksta, RSVP protokol predstavlja primarni QoS signalizacijski protokol u IP mrežama. A. Osnovna načela 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 omogućava njegovu primjenu i u drugim signalizacijskim aplikacijama. Mreže mogu koristiti RSVP prilikom uspostave LSP-a ili za IntServ rezervacije. RSVP podržava rezervaciju resursa u slučaju unicast i multicast aplikacija. RSVP modul komunicira sa dva lokalna modula za donošenje odluka, admission control i policy control. Admission control određuje da li čvor ima dovoljno raspoloživih resursa da osigura zahtijevanu QoS. Policy control osigurava autorizaciju QoS zahtjeva [9].

RSVP koristi koncept sesije koja obuhvata izvjestan broj pošiljatelja i primatelja. RSVP sesija obuhvata tok podataka sa naznačenim odredištem i protokolom prijenosnog sloja. Sesija može obuhvaćati više rezervacija u slučaju multicast destinacije. Rezervacije su jednosmjerne. Definicija RSVP sesije se mijenja kada se RSVP koristi za signalizaciju LSP-a. U tom slučaju, sesija predstavlja proizvoljni prometni tok koji pošiljatelj šalje prema jednom ili više primatelja [29]. B. Načela rada RSVP protokola Rad RSVP protokola se temelji na periodičnoj transmisiji i obradi Path i Resv poruka za uspostavu i održavanje rezervacije. Pošiljatelji generiraju Path poruke koje nose informaciju o specifikaciji toka pošiljatelja. Primatelji prenose Resv poruke nazad prema pošiljateljima i izvode rezervaciju resursa. Mrežni čvorovi prosljeđuju Resv poruke na hop-by-hop principu korištenjem rezervirane putanje. ResvConf poruke služe primatelju kao potvrda uspješne rezervacije. Mrežni čvorovi pohranjuju i održavaju 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 pogrešaka. Dva nova tipa poruka, Bundle i Srefresh, reduciraju količinu informacija koje razmjenjuju susjedni RSVP čvorovi radi osvježavanja soft state-a [30]. Upotrebom Hello poruka može se brzo uočiti 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 izvršiti tek nakon isteka soft state vremenskog intervala osvježavanja koji iznosi 30 sekundi. Uvođenje mehanizma za postepeno osvježavanje timer-a doprinosi rješenju ovog problema na način da se vrši retransmisija RSVP poruke sve dok prijemni čvor ne potvrdi njen prijem [30]. Svaka RSVP poruka sadrži informaciju o samo jednoj sesiji. U mreži koja sadrži veliki broj RSVP sesija može doći do preopterećenja usmjeritelja i potencijalnog zagušenja u mreži. U cilju rješavanja ovog problema definiran je mehanizam koji reducira broj poruka koje se razmjenjuju između susjednih čvorova [30]. RSVP ne daje ni podršku fragmentaciji poruka na razini protokola. Ako je veličina RSVP poruke veća od MTU, poruka će se fragmentirati. Usmjeritelji ne mogu detektirati ni vršiti obradu fragmenata RSVP poruka. Rješenje MTU problema ne postoji. Pojava signalizacijskih protokola nove generacije s prethodno opisanim MTU problemom će spriječiti korištenje postojećih RSVP prijenosnih mehanizama. Ukoliko bude potreban novi prijenosni mehanizam, on će morati riješiti problem pouzdanosti slanja poruka, problem pakiranja poruka, MTU problem i problem prekomjernog generiranja poruka. D. Problem performansi RSVP protokola Složenost elemenata RSVP protokola predstavlja jedan od ključnih izazova. Prvo, RSVP se temelji na toku, stoga je broj stanja proporcionalan broju RSVP sesija. Path i

Resv stanja se moraju održavati u svakom usmjeritelju za svaku sesiju. Drugo, RSVP optimizira različite operacije spajanja poruka prilikom multicast rezervacija što izaziva obradu velikog broja Resv poruka. Dodavanje mehanizama za rješavanje spomenutog multicast problema predstavlja dodatni izvor pogrešaka. Treće, RSVP signalizacijske poruke se ne koriste samo za održavanje stanja, nego i za rješavanje problema gubitka istih i otkriće 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 korištenog tijekom trajanja sesije. RSVP poruke se šalju radi iniciranja nove rezervacije ili osvježavanja postojeće rezervacije. Standardni RSVP koristi iste Path/Resv poruke i za iniciranje novih i za osvježavanje postojećih rezervacija što rezultira povećanjem veličine poruka osvježavanja. Hop-by-hop osvježavanje reducira prekomjerno korištenje propusnog opsega za RSVP, ali može rezultirati povećanjem broja izvora pogrešaka. RFC 2961 uvodi novi tip RSVP poruke i reducira redundantnost osvježavanja. E. Prednosti RSVP protokola Osim prethodno navedenih nedostataka, RSVP posjeduje i izvjesne prednosti. Najveća prednost RSVP-a je mogućnost aplikacije da točno definira rezervacijske zahtjeve za tok i da za prihvaćeni tok dobije čvrstu garanciju kvalitete usluge. Pouzdanost, prilagodljivost i dinamička promjena soft state rezervacije predstavljaju dodatne prednosti RSVP protokola. Prilagođenost primatelju je bitna prednost RSVP protokola koja ga čini pogodnim za višeodredišne i heterogene skupine. Pojedini primatelj bira razinu kvalitete usluge i stvara rezervaciju održavajući je na toj razini koliko god dugo želi. Pošiljatelji raspoređuju promet u nekoliko različitih RSVP tokova s različitim razinama kvalitete usluge. Primatelj može birati jedan ili više RSVP tokova. Ovakav pristup omogućava heterogenim primateljima da zatraže različite kvalitete usluga prilagođene njihovim specifičnim mogućnostima i potrebama. QoS upravljački uređaji određuju kako podesiti parametre veze da bi se postigla tražena kvaliteta usluge, a RSVP samo pruža mogućnost distribucije tih parametara. RSVP je dizajniran da QoS parametre tretira kao nevidljive podatke koji se moraju isporučiti kontrolnim modulima u usmjeriteljima gdje se interpretiraju po potrebi. Ovo logičko odvajanje QoS kontrolnih uređaja i sredstava za distribuciju pojednostavljuje RSVP i čini ga prilagodljivim novim mrežnim tehnologijama i primjenama. V. SLJEDEĆI KORACI U SIGNALIZACIJI Analizom prednosti i nedostataka RSVP protokola, javlja se težnja ka definiranju zahtjeva, okvira i protokola neophodnih za rješenje problema QoS signalizacije. NSIS radna grupa je osnovana upravo s tim ciljem. Zadatak NSIS radne grupe nije definiranje novog QoS signalizacijskog protokola, već optimizacija postojećih protokola unutar već definiranog okvira. Namjera je ponovno uporabiti odgovarajuće RSVP mehanizme uz svojevrsno pojednostavljenje i definiranje generičkog signalizacijskog modela.

A. Zahtjevi za signalizacijske protokole Osnovni korak u definiranju optimalnog signalizacijskog rješenja je zadovoljavanje postavljenih zahtijeva. NSIS je definirao skup zahtjeva koji se postavljaju pred signalizaciju u različitim mrežnim okruženjima i opisao neke scenarije njihove primjene [32]. Definirana je generička mrežna arhitektura s glavnim logičkim elementima [33]: • NSIS začetnik, entitet koji započinje proces QoS signalizacije kao rezultat korisničkog aplikacijskog zahtjeva. • NSIS prosljeditelj, posrednički entitet u resoru upravljanja operacijama signalizacije duž putanje prema primatelju. • NSIS odgovaratelj, entitet koji završava proces QoS signalizacije, postavljen na kraju signalizacijske putanje. Umjesto pružanja uvida u detaljnu listu zahtjeva, u radu se daje osvrt na spomenute zahtjeve s aspekta područja njihove primjene. Jednu skupinu čine fleksibilni i međuovisni zahtjevi koji su prikladni za signalizacijsko rješenje. Druga skupina zahtjeva se bavi pozicijom u odnosu na putanju gdje se smještaju tri glavna NSIS entiteta [32]. Definirana je i skupina zahtjeva koja upućuje na problem vrste poruka koje bi protokol trebao prenositi, odnosno na definiciju i rangiranje funkcionalnosti signalizacijskog protokola. Neki uvjeti su postavljeni na temelju upravljačkih informacija, a drugi u odnosu na performansne zahtjeve. Prva klasa performansnih zahtjeva je u vezi sa rješenjem problema skalabilnosti, odnosno broja razmjenjenih poruka i broja uključenih entiteta. Druga klasa se više odnosi na mjerenje performansi. Performansni zahtjevi moraju biti generalizirani s obzirom da su performanse ovisne o samom scenariju. S tim u vezi, jezgro mreže treba protokol koji minimizira kašnjenje razmjene signalizacijskih poruka, dok se u pristupnim mrežama preferira nisko iskorištenje propusnog opsega, a ne reduciranje kašnjenja, posebno u slučaju bežičnih linkova. Sigurnost i pokretljivost, također, predstavljaju izazove signalizacijskog rješenja [32]. Cilj NSIS radne grupe je analiza postojećih signalizacijskih protokola i pronalazak optimalnog protokola i njegovih proširenja u svrhu ispunjavanja postavljenih zahtjeva. Analiza postojećih QoS protokola je već izvršena [34]. Glavni fokus je na RSVP protokolu. Njegove funkcionalnosti su detaljno razmatrane, kao i predložena rješenja u cilju mimoilaženja njegovih nedostataka. RSVP ne može biti izabran kao NSIS signalizacijski protokol prvenstveno zbog nedostatka podrške za pokretljivost. Odluka o izboru optimalnog generičkog signalizacijskog protokola je vremenski neodređena. B. Signalizacijski okvir Osnovna ideja signalizacijskog okvira je posjedovanje slojevitog modela, u kojem se niži sloj implementira u NSIS entitetu i predstavlja signalizacijski prijenosni sloj, dok viši sloj predstavlja signalizacijski aplikacijski sloj i specifičan je za svaku aplikaciju posebno. Zbog specifičnosti signalizacijskog aplikacijskog sloja, postoji nekoliko komponenti koje se realiziraju preko jedinstvenog signalizacijskog prijenosnog sloja.

Slika 4. Logičke komponente unutar NSIS entiteta Signalizacijski prijenosni protokol radi na hop-by-hop osnovi. Nakon prijema signalizacijske poruke, vrši se njeno prosljeđivanje ka sljedećem NSIS mrežnom entitetu prijenosnog sloja. Ako je signalizacijski aplikacijski sloj implementiran u tom entitetu, poruka se šalje višem sloju radi daljnje obrade. Ovo je svakako glavni zadatak prijenosnog sloja, prosljeđivanje signalizacijskih poruka neovisno o nižim mrežnim slojevima. Da bi se postigao ovaj cilj, pripadni entiteti moraju biti u mogućnosti korektno izvršiti 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 uključiti pouzdanost ili ne, ili pak prepustiti protokolima na višim 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 ležati povrh IP protokola, koji omogućava korištenje funkcionalnosti IP usmjeravanja kada je to potrebno. NLTP obuhvaća General Internet Signaling Transport (GIST) protokol koji vrši 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 preporučuje minimiziranje informacija neophodnih za izražavanje stanja unutar NSIS entiteta. Protokol mora biti u mogućnosti podržati QoS zahtjeve na bilo kojoj razini granularnosti kako bi zadovoljio zahtjeve pojedinačnih ili grupnih tokova. VI. DIFFSERV MODEL I MEHANIZMI DiffServ model [3] omogućava diferenciranje usluga u mreži tako da se različitim aplikacijama dodijeli odgovarajuća razina usluge uz zadržavanje visokog stupnja skalabilnosti. Osnovna pretpostavka DiffServ mreža je da usmjeritelji unutar jezgra mreže upravljaju paketima različitih prometnih tokova vršeći njihovo prosljeđivanje uporabom različitih Per-Hop Behavior (PHB). PHB se određuje na temelju Differentiated Services Codepoint (DSCP) oznake unutar IP polja zaglavlja. Rubni usmjeritelji pridružuju DSCP oznaku

paketima na ulazu u DiffServ mrežu. Prednost ove sheme leži u činjenici da se više prometnih tokova može grupirati u jedan tok i proslijedi korištenjem istog PHB-a. Ključni elementi DiffServ arhitekture su prikazani na slici 5. Funkcionalni blok za klasificiranje i kondicioniranje prometa se obično smješta na ulazu/izlazu mreže (slika 6). Klasificiranje prometa može se vršiti na temelju bilo kojeg polja zaglavlja. Za klasificiranje se može koristiti prijenosni protokol, izvorišna ili odredišna IP adresa i sl. Nakon klasificiranja pristupa se kondicioniranju prometa. Kondicioniranje prometa se vrši uporabom sljedećih elementa: mjerač (meter), označivač (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 uobičajeno temelji na token bucket algoritmu. Označivač postavlja DS polje zaglavlja paketa sukladno radu mjerača. Oblikovatelj izaziva zakašnjenje, 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 odgovarajućeg prometnog toka. PHB se može specificirati u smislu dijeljenja resursa (npr. propusnog opsega linka, međuspremnika i prioriteta pristupa međuspremnicima) ili u smislu relativnih QoS karakteristika (npr. razina kašnjenja/varijacija kašnjenja 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 uobičajenom best-effort načinu prosljeđivanja paketa koji je dostupan u svim usmjeriteljima za standardnu vrstu prometa čija je odgovornost jednostavno prosljeđivanje što je moguće više paketa. Default PHB je namijenjen za promet koji nema posebne QoS zahtjeve. Prije pojave DiffServ arhitekture, IP mreže su koristile Precedence polje unutar Type of Service (ToS) okteta IP zaglavlja za označavanje prioriteta. IETF je izvršio redefiniranje ToS okteta u DS polje za DiffServ mreže (slika 7). U cilju održavanja kompatibilnosti sa mrežnim 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] pruža uslugu prosljeđivanja paketa sa malim iznosom kašnjenja, varijacije kašnjenja i gubitka paketa. EF PHB garantira da se promet poslužuje brzinom koja je najmanje jednaka konfiguriranoj minimalnoj brzini posluživanja. AF PHB [39] grupe su namijenjene aplikacijama koje zahtijevaju malu razinu gubitka paketa sve dok grupirani promet ostaje unutar korisničkog/pretplatničkog profila. Prosljeđivanje paketa se vrši u jednu od 4 AF klase. Unutar svake AF klase paketu se pridružuje jedan od 3 prioriteta odbacivanja. Svaki PHB se označava sa AFij pri čemu i označava AF klasu, a j prioritet odbacivanja. Svakoj AF klasi su dodijeljeni resursi uključujući i propusni opseg. Prosljeđivanje je neovisno između AF klasa. Unutar AF klase, paketi sa vrijednošću prioriteta p mogu imati manji iznos gubitaka u odnosu na pakete sa vrijednošću prioriteta q, ako je p