CASOPIS REPUBLICKE AGENCIJE ZA TELEKOMUNIKACIJE

Nova generacija multiservisnih telekomunikacionih mreža sa tehnologijom Internet protokola (IP) podrazumeva umrežavanje različitih administrativnih domena sa heterogenim mehanizmima obezbeđivanja kvaliteta servisa (QoS, Quality of Service), što može imati za posledicu ograničenja u skalabilnosti i efikasnosti mreže. Poseban problem predstavlja razvoj sistema za integrisano upravljanje mrežom. Među smernicama IETF iz 2004. godine je istaknuto da „upravljanje mrežom, a ne pojedinačnim uređajima, zahteva sposobnost sistema da posmatra mrežu kao veliki distribuirani sistem“ [1]. U cilju rešavanja ovog problema, razvijen je pristup PBM (Policy Based Management), koji omogućava automatizovano, centralizovano i dinamičko upravljanje mrežom zasnovano na skupovima pravila – politikama.

Politika upravljanja predstavlja plan provajdera, organizacije ili korporacije za realizaciju određenih ciljeva. Taj plan obuhvata specifikaciju ciljeva i pridruženog skupa akcija koje treba preduzeti za njihovu realizaciju, a može da odražava i uslove sporazuma o nivou servisa (SLA, Service Level Agreement) između provajdera i korisnika. Politika upravljanja se definiše skupovima pravila, pomoću kojih se upravlja odlukama o ponašanju mreže ili grupe elemenata mreže, resursima mreže, servisima i grupama korisnika.

Glavni koncept PBM-a jeste opisivanje ciljeva („šta“), a ne procedura („kako“), što je slučaj sa tradicionalnim tehnikama upravljanja. Upravljanje višedomenskom mrežom predstavlja kompleksan i težak zadatak. Veliki je problem i pronalaženje ljudi sa odgovarajućim znanjem, koji bi mogli da upravljaju sve komplikovanijim mrežnim tehnologijama. PBM pojednostavljuje i automatizuje administrativne poslove u mreži, s obzirom na to da se politike koje unosi administrator u mrežu predstavljaju poslovnim jezikom.

Cilj ovog rada je da se ukaže na mogućnosti implementacije koncepta PBM u višedomenskoj IP mreži sa diferenciranjem servisa po klasama kvaliteta.

IETF arhitektura diferenciranih servisa (DiffServ, Differentiated Services [2]) zasniva se na pravilu da paketi koji imaju slične zahteve za QoS mogu da budu grupisani u jednu klasu, iako pripadaju različitim tokovima saobraćaja. Svaki IP paket markira se uz pomoć određenih bita u zaglavlju (DSCP, Differentiated Services Code Point) čime se definiše klasa kojoj pripada, odnosno tzv. Per-Hop Behavior (PHB) u svakom čvoru. PHB određuje prioritet, najveće kašnjenje usled obrade u čvoru, dodeljeni propusni opseg i verovatnoću odbacivanja paketa. Složene operacije kao što su klasifikacija i kondicioniranje saobraćaja izvršavaju se u graničnim čvorovima u kojima je broj tokova IP saobraćaja relativno mali. Ruteri jezgra opslužuju pakete samo na osnovu klase saobraćaja, tj. vrednosti polja DSCP. Definisana su tri tipa PHB:

1)Servis sa ubrzanim prosleđivanjem (EF PHB, Expedited Forwarding, RFC standard 3246) namenjen za aplikacije koje su osetljive na kašnjenje i džiter. Ovaj servis se u literaturi naziva i premium.

2)Servis sa sigurnim prosleđivanjem (AF PHB, Assured Forwarding, RFC standard 2597) pruža relativne garancije QoS, zasnovane na statističkim preduslovima. Moguće je definisati više klasa, unutar kojih se određuju prioriteti odbacivanja paketa u uslovima opasnosti od zagušenja mreže. Klasifikacija saobraćaja preporučena standardom obuhvata četiri klase i tri prioriteta odbacivanja saobraćaja unutar svake klase. Postoje i druge mogućnosti klasifikacije saobraćaja, kao što je, na primer, projektovanje tzv. „Olimpijskog servisa“ sa zlatnom, srebrnom i bronzanom klasom.

3)Servis najboljeg pokušaja (best effort) koji predstavlja predefinisani (default) PHB i odgovara servisu raspoloživom u današnjem Internetu, bez garancija QoS.

Najvišem TMN sloju (sloju posla) odgovaraju informacioni model SLA i funkcionalne komponente koje se odnose na strategiju kompanije, ugovaranje kvaliteta servisa, tarifiranje i obračune, kao i interakcije sa sistemima upravljanja drugih operatora ili kompanija.

Sloj upravljanja servisom je odgovoran za ugovorene aspekte kvaliteta raznorodnih servisa koji se pružaju korisnicima. Informacioni model pridružen ovom sloju definiše politiku upravljanja kvalitetom servisa. Politika upravljanja može obuhvatati: pravila klasifikacije servisa, pravila kondicioniranja ulaznog saobraćaja i konfigurisanja mehanizama za opsluživanje paketa i upravljanje redovima za različite klase QoS, pravila konfigurisanja parametara i tabela rutiranja i dr. Funkcionalne komponente obuhvataju odlučivanje o politici upravljanja i upravljanje sporazumima o nivou servisa i specifikacijama nivoa servisa.

Sloj upravljanja mrežom je odgovoran za upravljanje svim elementima mreže – pojedinačno i u celini. Informacioni model pridružen ovom sloju opisuje tehničke aspekte SLA, odnosno specifikaciju nivoa servisa (SLS, Service Level Specification). Funkcionalne komponente na ovom sloju obuhvataju arhitekturu QoS, upravljanje resursima mreže, QoS rutiranje i dr.

DMTF (Distributed Management Task Force) grupa je predložila opšti okvirni rad za automatizaciju nadzora i upravljanja IP mrežom na osnovu politike operatora ili korporacije, sa ciljem da se kroz standardizovana rešenja obezbedi dinamičko upravljanje i tako doprinese skalabilnosti mreže.

PBM omogućava alokaciju resursa u mreži, propusnog opsega, QoS i bezbednosti u odnosu na definisanu poslovnu politiku. Sa povećanjem zahteva za QoS (zbog VoIP i drugih aplikacija u realnom vremenu), povećavaju se i zahtevi za alokaciju propusnog opsega, koji su zasnovani na povećanju broja politika. Politike su skupovi pravila kojima se definišu: (1) pravo pristupa određenim resursima u mreži; (2) klase saobraćaja i pridruženi prioriteti; (3) garancije kvaliteta servisa (apsolutne ili relativne); (4) način alokacije propusnog opsega u cilju garancije QoS; (5) način odbacivanja saobraćaja (klasa, prioritet odbacivanja) u uslovima preopterećenja i zagušenja mreže.

PBM sistemi najbolji su za velike mreže gde je lakše upravljati velikim brojem uređaja sa jedne, centralne lokacije.

Posredstvom odgovarajućeg aplikacionog programskog interfejsa, administrator koristi alat za upravljanje politikom za definisanje politika koje će biti primenjivane u mreži. Uređaj koji implementira i izvršava različite politike upravljanja naziva se tačkom sprovođenja politike – PEP. PEP može biti ruter, server ili gejtvej. Repozitorijum politika – PR je baza podataka u koju su smeštene politike generisane pomoću alata za upravljanje politikom. On se može realizovati kao SQL (Structured Query Language) server direktorijuma kome se pristupa posredstvom standardizovanog protokola – LDAP. Tačka odlučivanja o politici – PDP je odgovorna za komunikaciju sa repozitorijumom politika, interpretaciju politika i njihovo prosleđivanje tačkama sprovođenja politike, posredstvom upravljačkih protokola kao što su SNMP ili COPS. PDP može da bude server kojim upravlja mrežni administrator koji unosi različite vrste politika. Lokalna tačka odlučivanja o politici (LPDP, Local PDP) predstavlja PDP koja se nalazi unutar čvora mreže, a koristi se u slučajevima kada centralni PDP nije dostupan. Osnovne odluke o politici mogu se programirati kao deo ove komponente.

Struktura alata za upravljanje politikom nije standardizovana budući da standard nije potreban za interoperabilnost između različitih računara. PMT pojednostavljuje upravljanje i konfigurisanje svih elemenata u mreži kroz centralizaciju i apstrakciju na sloju upravljanja poslom [7].

Centralizacija obezbeđuje konfigurisanje mrežnih elementa na jednom mestu (alat za upravljanje) umesto konfigurisanja svakog elementa ponaosob. U sistemu sa velikim brojem računara, centralizovano konfigurisanje olakšava posao administratoru koji unosi politike potrebne za rad mreže u alat za upravljanje politikom, i to pomoću programskog interfejsa putem kojeg se zatim popunjava repozitorijum politika. Informacije u repozitorijumu predstavljene su jezikom tehnologije primenjene u mreži. Na primer, ako je u pitanju arhitektura diferenciranih servisa, politike će biti opisane terminima i koncepcijama koji su karakteristični za ovu arhitekturu. Entitet PDP pretražuje repozitorijum, preuzima odgovarajuću politiku i prosleđuje je entitetu PEP koji je sprovodi. Centralizacijom se takođe skraćuje vreme potrebno za konfigurisanje svih elemenata u mreži.

Apstrakcija na nivou posla pojednostavljuje posao administratoru tako što mu omogućava da politike definiše terminima koji su bliski poslovnim potrebama organizacije, umesto terminima određene tehnologije primenjene u mreži. Administrator ne mora da bude detaljno upoznat sa tehnologijom koja podržava željeni poslovni zahtev.

Na primer, posmatrajmo slučaj mrežnog operatora koji treba korisnicima da obezbedi dva nivoa kvaliteta servisa (premium i najbolji pokušaj) u DiffServ mreži. Ako administrator želi da definiše politike, mora da bude upoznat sa tehničkim detaljima. Na primer, mora da zna da se diferencijacija postiže dodeljivanjem saobraćaja različitim PHB-ovima i da je premium klasa dodeljena određenom PHB-u (EF PHB), a zatim mora da definiše i određene parametre vezane za ovaj PHB. Pored poznavanja poslovnih potreba organizacije, tehnologija zahteva kadrovske resurse sa specifičnim tehničkim znanjem. Apstrakcija na poslovnom nivou zavisi od poslovnih potreba i tehnologije primenjene u mreži.

U zavisnosti od primenjene mrežne arhitekture, razlikujemo i nekoliko načina predstavljanja politika. Najjednostavniji među njima jeste da se politike predstave kao skupovi pravila tipa „if-then-else“. Pravila se izvršavaju u određenim trenucima kada je ispunjen postavljeni uslov. Alternativni način definisanja politika jeste da se predstave tabelarno. Tabele se sastoje od parametara koji definišu uslove i od parametara koji definišu akcije.

U specifikaciji IETF-a, politike su predstavljene kao skup pravila. Pošto politike treba da se smeste u repozitorijum politika (bazu podataka, LDAP direktorijum), moraju da se predstave i tabelarno.

Ova procedura vrši validaciju informacija sadržanih u politikama visokog nivoa i transformiše ih u jezik razumljiv elementima mreže. Proces validacije mora da objedini kako sintaksičke, tako i semantičke provere. Semantička provera politika visokog nivoa sastoji se od različitih tipova provera [7]. Provera granica: proverava da li se vrednosti određenih parametara u specifikaciji politike nalaze unutar granica definisanih od strane administratora. Provera relacionih odnosa: proverava da li vrednosti određenih parametara u specifikaciji politike zadovoljavaju odnose (relacije) determinisane određenom tehnologijom. Provera doslednosti: proverava da politike nisu u međusobnom konfliktu. Doslednost podrazumeva da ako dva pravila mogu da se primene pod istim uslovima, akcije moraju biti definisane jedinstveno i izvodljive istovremeno. Provera dominacije: traži „nemoguće“ politike - politike definisane od strane administratora koje nikada neće biti aktivne u mreži, jer ih poništavaju definicije ostalih politika. Provera izvodljivosti: osigurava da politike određene od strane administratora mogu da se izvode u operativnom mrežnom okruženju.

(Common Open Policy Service) je standardizovan protokol [8], koji se zasniva na paradigmi klijent/server i omogućava tački odlučivanja o politici (PDP) da dostavi odluku o politici tački sprovođenja politike (PEP). U cilju fleksibilnosti ovaj protokol razvijen je da podrži različite tipove klijenata, od kojih je svaki opisan zasebnim dokumentom. COPS protokol koristi TCP protokol za pouzdanu razmenu poruka između PDP-a i PEP-ova. COPS obezbeđuje sigurnu razmenu poruka za utvrđivanje verodostojnosti (autentifikaciju), zaštitu od replikacije i integritet poruka.

SNMP(Simple Network Management Protocol) je standardizovan skup specifikacija za upravljanje IP mrežom [9]. Sastoji se od tri osnovna elementa: (1) upravljačka stanica; (2) upravljivi agent i (3) protokol koji kontroliše razmenu informacija između upravljačke stanice i agenta. Upravljačka stanica implementira skup upravljačkih aplikacija i korisnički interfejs za mrežnog administratora. Ona prikuplja podatke od agenata i sprovodi zahtevane funkcije nadzora i upravljanja mrežom. Agent je program transparentan za korisnika, a implementira se u mrežnim uređajima kao što su ruteri, gejtveji i hostovi. Agent prikuplja relevantne podatke za upravljanjeuređajem i omogućava upravljačkoj stanici pristup tim informacijama. Upravljačka stanica i agent razmenjuju mrežne upravljačke informacije koristeći nekonektivni transportni protokol UDP (User Datagram Protocol). SNMP definiše protokol aplikacionog sloja koji omogućava komunikaciju između upravljačke stanice i agenata u elementima mreže, kao i baze upravljačkih informacija (MIB, Management Information Base), koje se implementiraju u elementima mreže.

LDAP (Lightweight Directory Access Protocol) je standardizovan protokol [10], koji omogućava pristup informacijama smeštenim u direktorijume. LDAP je baziran na standardu ITU-T X.500 za servis direktorijuma i razvijen za okruženje TCP/IP. LDAP obezbeđuje mehanizme za prikupljanje i modifikovanje informacija. LDAP takođe omogućava lociranje organizacije, pojedinca i drugih resursa kao što su fajlovi i uređaji na mreži. LDAP direktorijum je skladište velikog broja različitih informacija, pogodno za skladištenje informacija koje se ne menjaju često, kao što su e-mail adrese, informacije o rutiranju, adresari i dr. LDAP server (DSA, Directory System Agent) prihvata zahtev korisnika i generiše odgovor, pri čemu, po potrebi, prosleđuje zahtev drugom serveru radi dobijanja tražene informacije.

Arhitekturu CORBA (Common Object Request Broker Architecture) [11] je razvila OMG (Object Management Group), sa osnovnim zadatkom da projektuje standardnu i portabilnu arhitekturu namenjenu za razvoj objektno-orijentisanih aplikacija, implementiranih na različitim hardverskim i softverskim platformama.

CORBA je objektno-orijentisana arhitektura i infrastruktura koju koriste računarske aplikacije za međusobnu saradnju u mreži, a nezavisna je od proizvođača. Korišćenjem standardnog IIOP (Internet Inter-ORB Protocol), CORBA programi bilo kod proizvođača, na bilo kom računaru, operativnom sistemu, programskom jeziku ili mreži mogu da komuniciraju sa CORBA programima istog ili drugog proizvođača.

CORBA je arhitektura koja koristi brokera zahteva objekata (ORB, Object Request Broker) za slanje zahteva od objekata jednog sistema do objekata drugog sistema. ORB omogućava interakcije objekata u heterogenom, distribuiranom okruženju, nezavisno od platforme računara na kojoj se nalaze različiti objekti i nezavisno od programskog jezika. Na primer, C++ objekat na jednom računaru može da komunicira sa Common Lisp objektom drugog računara.

CORBA aplikacije mogu da budu i klijent i server istovremeno. Klijent aktivira operacije nad objektima kojima upravlja server, a server prima pozive objekata kojima upravlja i odgovara na te zahteve. Na primer, Common Lisp objekat može da koristi CORBA servise dostupne u mreži (kao klijent) ili može da obezbedi servise drugim komponentama aplikacije (kao server) pomoću IIOP (Internet Inter-ORB Protocol), koji koristi protokol TCP.

Objekti distribuirane aplikacije CORBA, bez obzira na programski jezik, mogu da komuniciraju sa ORB brokerom preko interfejsa napisanog jezikom CORBA IDL (Interface Definition Language). Ovaj jezik definiše se u specifikaciji CORBA 2.0 koja je razvijena u cilju opisa interfejsa objekta, uključujući operacije koje mogu da se izvršavaju nad objektima i parametre tih operacija. Ponašanje objekta je zato obuhvaćeno interfejsom nezavisno od implementacije objekta. Klijent treba jedino da zna interfejs objekta da bi poslao zahtev.

Server odgovara na zahtev koji potiče od tih interfejsa, a klijent ne mora da zna detaljeimplementacije servera.

U slučaju obezbeđivanja QoS u višedomenskoj mreži, neophodno je obezbediti uslove za interoperabilnost domena, tj. uslove za međusobno preslikavanje klasa servisa i pridruženih parametara kvaliteta servisa. Jedan od bitnih preduslova, za takve potrebe, jeste standardizacija tehničkog dela sporazuma o nivou servisa – SLS. Predlozi formata SLS i pridruženih protokola ostali su na nivou nacrta Internet standarda, uglavnom zbog shvatanja da je potrebno prethodno standardizovati mere performansi za IP klase servisa i signalizacione protokole za dinamičko ugovaranje QoS. Iz tih razloga se realizacija QoS u višedomenskoj mreži još uvek prvenstveno zasniva na tzv. kooperativnom modelu – dogovoru grupe operatora o bazičnim parametrima neophodnim za implementaciju QoS (formati SLA, mere performansi, nadzor performansi) [12].

U [13], [14] i [15] prikazani su primeri formata SLA i pridruženih specifikacija nivoa servisa, kao i primer implementacije objektno orijentisane aplikacije za interaktivno ugovaranje SLA.

Bez obzira o kakvoj mrežnoj tehnologiji je reč prvo moraju da se definišu: (1) politike na visokom nivou (poslovni jezik); (2) politike na niskom nivou (tehnički jezik, prilagođen mrežnoj tehnologiji/arhitekturi); (3) pravila preslikavanja politika sa visokog na niski nivo i (4) prirode testova izvodljivosti.

U primeru koji sledi, posmatraćemo predstavljanje SLA u višedomenskoj namenskoj DiffServ IP mreži i pretpostavićemo politike visokog i niskog nivoa predstavljene pomoću jezika UML (Unified Modeling Language [17]). Na Slici 3. prikazan je objektni model sporazuma o nivou servisa predstavljen poslovnim jezikom u namenskoj mreži.

Politike niskog nivoa za preslikavanje sadrže sheme politika definisane za DiffServ tehnologiju. Primer takve specifikacije prikazan je na Slici 4. Više uređaja sa istim skupom politika predstavljaju pravilo uređaja. Za pravilo uređaja je definisano nekoliko mrežnih nivoa, od kojih svaki odgovara jednom od PHB. DiffServ politike preslikavaju pet parametara IP toka saobraćaja (adrese izvora i odredišta, brojevi portova, transportni protokol) u jedan parametar na nivou mreže (klasa servisa – PHB, definisan poljem DSCP u zaglavlju paketa).

Na Slici 5. je prikazan deo hijerarhije klasa informacionog modela. Klasama su predstavljene različite politike upravljanja, odnosno uslovi i akcije, pa su tako definisane klase kojima se određuje vreme potrebno da PDP izvrši konfiguraciju, akcije dodeljivanja određenog propusnog opsega svakoj klasi saobraćaja (PHB) i svakom linku u mreži, akcije u slučaju slobodnog propusnog opsega i u slučaju prekoračenja propusnog opsega, način izračunavanja zahteva za kašnjenje i gubitak paketa itd.

Politike upravljanja takođe treba da poseduju osobinu prilagođavanja novonastalim zahtevima. Tako PBM sistemi treba da omoguće dinamičko dodavanje, promenu i brisanje načina upravljanja. U cilju postizanja takve funkcionalnosti, politike se prevode u skript (koji se obrađuje pogodnim „interpreterom“), na osnovu kojeg se sprovode upravljačke operacije. Korisnik politike može biti lokalno povezan sa odgovarajućom komponentom politike u upravljivom objektu (MO, Managed Object) ili daljinski inicira sprovođenje u MO (npr. posredstvom CORBA).

Kao što je prikazano na Slici 6, korisnik politike (PC) se sastoji iz tri dela. Prvi deo, klijent repozitorijuma (repository client) zadužen je za pristup repozitorijumu politika i odgovoran je za uzimanje odgovarajuće politike koju korisnik politike treba da sprovede za konfigurisanje komponente kojoj je korisnik politike pridružen. Kada se dodaje nova politika, klijent repozitorijuma biva obavešten od strane PMT-a da je nova politika smeštena u repozitorijum politika.

Drugi deo korisnika politike je generator skriptova, koji je odgovoran za kreiranje skripta na osnovu unete politike. Proces generisanja skriptova iz politika visokog nivoa izvodi se automatski kada je politika smeštena u repozitorijum.

Interpretator politika predstavlja vezu između korisnika politike i komponente politike. Definisana su dva tipa funkcija: funkcije koje omogućavaju pristup lokalnim MO objektima i funkcije koje omogućavaju pristup MO objektima udaljenih komponenata. S obzirom na to da je pravilo politike skup akcija koje se sprovode kada su ispunjeni određeni uslovi, pristup MO objektima ima dvostruko značenje. Prvo, provera uslova pravila može se izvesti periodičnim ispitivanjem atributa MO objekata ili može biti vođena događajima, kad MO objekat šalje obaveštenje koje inicira sprovođenje politike. Ovi MO objekti mogu biti lokalni ili udaljeni, u zavisnosti od toga da li se uslov iz politike odnosi na stanje komponente kojoj je pridružen PC ili se odnosi na informacije koje su dostupne na udaljenim komponentama. Drugo, akcije iz politike sprovode se izvršavanjem skriptova, što rezultuje podešavanjem atributa ili pokretanjem operacija u lokalnom MO.

U radu je opisan koncept upravljanja multiservisnom IP mrežom, zasnovan na automatizaciji politika upravljanja – PBM. Glavne osobine PBM sistema su centralizacija i predstavljanje politika terminima koji su bliski poslovnim potrebama organizacije. PBM sistem upravlja ponašanjem mreže na osnovu politika koje su apstrahovane na visokom nivou, koje se dinamički unose u mrežu, procenjuju i proveravaju u smislu doslednosti, a na osnovu kojih se sprovode različite akcije u cilju konfigurisanja odgovarajućih mrežnih elemenata. Politike predstavljene na visokom nivou moraju da se prevedu na jezik razumljiv elementima mreže, pa je u radu opisana i logika prevođenja politike, koja je sastavni deo upravljačkog alata.

Funkcionalnost PBM sistema obezbeđuju savremene ICT tehnologije – telekomunikacioni protokoli kao što su COPS, SNMP i LDAP, kao i objektno orijentisani programski alati, kao što je arhitektura CORBA.

[1] R. Atkinson, S. Floyd: ''IAB Concerns and Recommendations Regarding Internet Research and Evolution'', RFC 3869, IETF, 2004.
[2] S. Blake et al.: ''An Architecture for Differentiated Services'', RFC 2475, IETF, 1998.
[3] Principles for a Telecommunication Management Network, ITU-T Recommendation M.3010, 2000.
[4] TMN Management Services and Telecommunications Managed Areas: Overview, ITU-T Recommendation M.3200, 1997.
[5] TMN Management Functions, ITU-T Recommendation M.340, 2000.
[6] M. Stojanović, V. Aćimović-Raspopović: Inženjering telekomunikacionog saobraćaja u multiservisnim IP mrežama, naučna monografija, Saobraćajni fakultet, Beograd, 2006.
[7] D. C. Verma: ''Simplifying Network Administration Using Policy-Based Management'', IEEE Network, vol. 16, no. 2, March/April 2002, pp. 20-26.
[8] D. Durham et al.: ''The COPS (Common Open Policy Service) Protocol'', RFC 2748, IETF, January 2000.
[9] D. Harrington, R. Presuhn, B. Wijnen: ''An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks'', RFC 3411, IETF, December 2002.
[10] K. Zeilenga: ''Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map'', RFC 4510, IETF, June 2006.
[11] ''CORBA – Common Object Request Broker Architecture'', http://www.omg.org/corba
[12] P. Jacobs, B. Davie: "Technical Challenges in the Delivery of Interprovider QoS", IEEE Communications Magazine, vol. 43, no.6, June 2005, pp. 112-118.
[13] S. Boštjančič, M. Stojanović, N. Gospić: ''Aplikacija za interaktivno ugovaranje kvaliteta servisa u DiffServ IP mrežama'', Zbornik radova TELFOR 2006 (CD).
[14] S. Boštjančič: ''Ugovaranje kvaliteta servisa u IP mrežama sa diferenciranim servisima'', magistarska teza, Saobraćajni fakultet, novembar 2007.
[15] S. Boštjančič, V. Timčenko, M. Stojanović: ''A Common Framework for Inter-Provider IP Quality of Service Specification'', XLIII International Scientific Conference on Information, Communication and Energy Systems and Technologies - ICEST, Niš, Serbia, June 2008.
[16] C. Bouras, A. Sevasti: "Service Level Agreements for DiffServ-based Services Provisioning", Journal of Network and Computer Applications, vol. 28, 2005, pp. 285-302.
[17] D. Braun et al.: ''Unified Modeling Language Tutorial'', Kennesaw State University -CSIS 4650, Spring 2001, http://www.pigseye.kennesaw.edu
[18] P. Flegkas et al.: ''A Policy-Based Quality of Service Management System for IP DiffServ Networks'', IEEE Network Magazine, vol. 16, no. 2, March/April 2002, pp. 50-56.