Sarajevo, maj 2015

Univerzitet u Sarajevu

Elektrotehniki fakultet u Sarajevu

Odsjek za telekomunikacije

Opis SLA koji se koristi u

praksi

Projektni zadatak (drugi dio)

Kvaliteta usluge u telekomunikacijskim mreama

Studenti:

Adnan Mehremi

Adis Bajri

Meris Bihorac

2

Sadraj

Uvod ...................................................................................................................................... 3

1. Bilateralni SLA-ovi ........................................................................................................... 5

1.1. Administrativno/pravni dio SLA ........................................................................... 6

1.2. SLS dio .................................................................................................................. 7

2. SLA za uspostavu sa kraja na kraj ............................................................................... 10

2.1. SLA verifikacija .................................................................................................. 14

3. Procedura dodjele servisa ............................................................................................ 16

Zakljuak ............................................................................................................................. 20

Literatura ............................................................................................................................. 21

3

Uvod

SLA (engl. Service-level agrement) predstavlja oekivanja i obaveze koje postoje izmeu

dva entiteta, definisanih kao provajder i kupac. Uz pomo SLA se osiguravaju sredstva za

definisanje usluga. Ovim se odreuje ta kupac eli, te ta provajder ima da ponudi. Da bi

se osigurala usklaenost sa SLA definiu se procedure i obavjetenja kako bi se osiguralo

praenje kvalitete pruene usluge, te se postavljaju ciljevi izvedbe koju dobavlja treba

ispuniti. Takoer je bitno naglasiti da sa najnovijim napretkom u rezervisanju

diferencijalnih usluga, SLA igra znaajnu ulogu.

Evolucija veoma zahtjevnih aplikacija te dostupnost velikih brzina na prenosnom mediju i

mrenoj opremi ima fokusiran interes dostavljanja QoS-a na best-effort modelu Interneta.

Zbog svoje skalabilnosti DiffServ arhitektura je u sluaju IP backbone mrea prevladala,

uprkos velikom broju alternativa. Zbog osiguravanja IP usluge prema DiffServ okviru

uvedena je kompleksnost u datom poslovnom okviru, te su podignuti uvjeti za kontrolisanu

raspodjelu resursa upravljanja, definiranja, praenja i provjere pruene kvalitete. Trenutno

SLA izmeu kupca i provajdera predvia pruanje zahtjevane i kontrolisane okoline. U

ovom okviru SLA djeluje kao posrednik za uzajamno pruanje usluga izmeu

odgovarajuih domena.

DiffServ okvir se istie po tome to nastoji pruiti usluge diferencijacije prometa na

skalabilan nain, sugeriui kumuliranju zahtjeva pojedinanih tokova sa slinim

potrebama kvalitete. Definiu se razliite klase servisa prema kojima se agregati

postavljaju i implementiraju mehanizme za diferencijalnu obradu od strane mrenih

elemenata (engl. Per-Hop-Behavior, PDB ) te paketa koji pripadaju pojedinim klasama

servisa. PHB opisuje obradu agregiranog prometa na nain da osigurava garanciju

kvalitete koju prua odgovarajua klasa servisa.

DiffServ mehanizmi su se pokazali teki za implementaciju i praenje u velikoj razmjeri

unutar mrenih ureaja, uprkos tome to su na poetku smatrani vrlo pogodnim zbog svoje

skalabilnosti. Problem takoer lei u tome to danas u stvarnosti DiffServ servis jo nije

uspjeno implementiran na mrenim ureajima. Problemi koji se javljaju pri

implementaciji su nedostatak poslovnog modela, nedoraslost usluge, provjera

infrastrukture, nedovoljna standardizacija i arhitekturske praznine.

4

Iako se vjeruje da DiffServ bazirane usluge imaju znaajan potencijal u unapreenju best-

effort modela Interneta, ovaj model je potrebno temeljito specificirati i standardizirati, jer

za sada je on probabilistiki mehanizam.

Danas je uspostava SLA mehanizama izmeu kupaca i provajdera prilino statino i radno

intenzivan zadatak. Ovim zadatkom su ukljueni procesi koji su u vlasnitvu provajdera.

Standardizacija tehnikih dijelova osnovnog procesa moe omoguiti visok stepen

automatizacije i dinamian pregovor o SLS (engl. Service Level Specification) izmeu

peering usluga ili kupca i provajdera. Automatizacija moe biti korisna prilikom opskrbe

korisnika i provajdera sa tahnikim ureajima za pruanje dinamikog stabilnog QoS

transportnog servisa. SLA i SLS su neophodni za isporuku dobivenog QoS-a preko vie

domena od jednog do drugog korisnika.

U mreama proizvodnje, servis provajderi koriste vlastite SLA ugovore koje su prilagodili

u svrhu kvalitetne IP usluge rezervisanja. Model direktnog rezervisanja se obino odnosi

na backbone mreni servis provajder i njegove direktno vezane kupce. Rijetko se deavaju

sluajevi kada je potrebno preslikati parametre kvalitete u susjedne domene.

Ovim radom, u poetnom dijelu prestavljamo naela za uspostavu ugovora o pruanju SLA

usluge u DiffServ baziranim uslugama u bilateralnom obliku (izmeu peering domena). U

ovu svrhu se koriste servisi bazirani na temelju ubrzanog prosljeivanja, za posluivanje

visoko-prioritetnog saobraaja sa zahtjevima visoke kvalitete.

Predlae se metodologija za uspostavu end-to-end SLA na temelju bilateralnih SLA-ova ,

koristei GEANT jezgrenu pan-Evropsku istraivaku mreu kao referentnu arhitekturu,

koja povezuje istraivaki centar i obrazovne mree, a kroz njih i korisnike irom Evrope.

Osim ovog naina uspostave, predlae se model rezervisanja za uspostavu i koordinaciju

SLA baziranih usluga implementacije i operacija.

5

1. Bilateralni SLA-ovi

Bilateralni SLA je zasnovan na garanciji, dostupnosti i detaljnom opisu izmeu peering

domena koji podravaju jednu ili vie kompatibilnih usluga. Sa ovim opisujemo kako

svaka od dvije domene ima omoguenu odreenu uslugu do saobraaja dobijenog od

svojih susjeda i obratno. Dok se predloena bilateralna SLA specifikacija sastoji od dva

dijela:

Administrativno-pravni dio

SLS dio, koji definie skup parametara i njihovih vrijednosti za pruanje DiffServ

baziranih usluga agregatu po DiffServ domeni

U sljedeim koracima bit e definisani koraci mehanizama za SLA pregovaranja te

uspostavljanje end-to-end usluga baziranih na pojedinanom SLA-u. Svaki primjer SLA

obuhvaa SLO (engl. Service Level Object) te sadri parametre i njihove vrijednosti koje

opisuju DiffServ baziranu uslugu i specifini tok koji je primljen za vrijeme trajanja

transportnog domena.

Kombinacijom dva SLO-a je mogua dvosmjerna usluga, prilikom koje se vri ugovaranje

usluge za dva toka, po jedan u svakom smjeru. Ove SLO obuhvataju transportnu uslugu,

koja je sastavni dio SLA ugovora definisanog izmeu dva podruja, meu kojima je i

dvosmjerna usluga uspostavljena. U nastavku e biti prikazan SLA obrazac i dvije

instance, koje e prikazati pojedinane SLA komponente zajedno. Na slici (Slika 1) je na

lijevoj strani prikazan primjer dvosmjernog SLA koji sadri dva jednosmjerna SLO-a.

Definisani SLO-ovi grubo definiu pruanje EF-bazirane usluge preko GEANT backbone

mree. Takoer na slici je prikazan SLA primjer koji definie osiguravanje EF-bazirane

usluge preko GRNET backbone-a. Sljedeim poglavljem je omoguena detaljna

specifikacija predloenog SLA i SLS template-a.

6

Slika 1 SLA template, SLA instanca, SLS i SLO-ovi

1.1. Administrativno/pravni dio SLA

Ovim dijelom SLA je predloen kompromis od nekoliko polja koje definiu procedure i

okvir za pruanje usluga na kojima je SLA osnovan. Predloena polja su:

Administrativne i tehnike strane koje su ukljuene u sklopu ovog dijela je

potreban jedan administativni i jedan tehnilki kontakt svake dvije strane koje

sudjeluju u SLA

Vremenski period ovaj dio sadri vremenski period za koji je SLA validan.

Mogue je razlikovanje ovog perioda i onog koji je definisan unutar polja service

schedule koji se nalazi u SLS dijelu SLA. Service Scheduler je skup vremenskih

7

perioda za koje je usluga aktivna, dok je trajanje SLA vremenski period za koji je

SLA validna za pruanje usluge.

Garancija dostupnosti u sklopu ovo dijela definie se proraun podataka oko

dostupnosti usluge, te kako e podaci biti dostavljeni. Ovim dijelom se takoer

treba osigurati omjer dostupnosti usluge u odnosu na vrmensko trajanje SLA-a,

vremensko ogranienje nedostupnosti te formule za izraunavanje naknade za

nedostupnost.

Nadgledanje (Monitoring) u sklupo ovog dijela se odreuje kada i kako se SLA

nadzire. Pored ovoga odreuju se take na kojima se vri nadgledanje te gdje je

mjerna oprema instalirana. Takoer se navode i SLS podaci koji su vidjlivi klijentu

te nalin na koji klijent moe pristupati praenju podataka.

Vrijeme odziva ovim dijelom definiemo ukupno vrijeme odziva garantovanog

od provajdera u sluajevima kada klijent zahtjeva podeavanje SLA-a ili SLS-a te

vrijeme potrebno za konfigurisanje relevantnih ureaja.

Fault Handling Trouble Ticket ovim dijelom se specificiraju radnje poduzete

od strane provajdera kada se desi greka koja se tie isporuivanja usluge

definisane u SLS-u i u odgovarajuem vremenu reakcije

Odreivanje cijene ugovorenih servisa ovo je najznaajniji dio SLA ugovora

izmeu korisnika i mrenog provajdera. DiffServ je ema koja efikasno odrava

vrijednost usluge i maksimizira nekoliko kriterija, mora biti vrlo temeljita i zavisna

uz SLA infrastrukturu nadgledanja i brojanja koja se koristi.

Opis servisa ovim dijelom se vri generalni opus mrene usluge, opisuje se

kvalitet usluge i radnje koja treba biti pruena.

1.2. SLS dio

Templejt koji emo opisati se primjenjuje za sluaj kad nam transportna domena

uspostavlja ugovor o pruanju usluge sa korisnikom na jednosmjeran nain. Na osnovu ove

pretpostavke imamo SLS koji je dio SLA ugovora i kao takav sadri polja:

8

1. Podruje definie topologoji regiona koja e biti omoguena zajedno sa

odreenim servisom, kojeg definiemo SLS-om. Podruje mora odreivati gdje

paketi u skladu sa SLS-om, ulaze ili izlaze iz DiffServ domene.

2. Opis protoka inicira se na koje IP pakete e garancija kvalitete biti primljenje, te

koji paketi e primiti PHB tretman koji rezultira garancijom kvalitete usluga kod

SLS-a. Dodatne informacije su ve prisutne u paketu ili se mogu saznati iz mrene

topologije.

3. Garancije performanse ovim poljem se prikazuju granice koje mrea nudi

korisniku za protok paketa koji je opisan prethodnim poljem preko opsega

tokologije preko polja podruje. Niz parametara performansi za standardni

saobraaj za EE bazirane usluge ali i na druge DiffServ bazirane usluge:

a. One-way delay (OWD) - kanjenje u jednom smjeru. Predloeno je da bude

garantovano maksimalno kanjenje prenosa paketa mjereno izmeu

definiranih taaka.

b. Instantaneous Packet Delay Variation (IPDV) varijacija kanjena

trenutnih paketa. Predloeno je da bude garantovano kao maksimalna

promjena kanjenja prenosa paketa mjerena izmeu definiranih taaka

c. One-way packet loss (OWPL) gubici paketa u jednom smjeru. Predloeno

je da bude garantovano kao kolinik izgubljenih paketa izmeu krajnjih

taaka i ukupnog broja ubaenih paketa na ulaznoj strani definisanoj poljem

podruje.

d. Kapacitet. Definie se kao brzina mjerena na nizu izlaznih taaka svih

paketa identificiranim poljem Flow descriptor.

e. Maximum Transmission Unit (MTU) maksimalna jedinica prenosa. Ovo

je najvea fizika veliina paketa u bajtima za koju je SLS garantovao

prenos bez fragmentacije. Predloena vrijednost za WAN je 4470 bajta.

4. Traffic envelope and traffic conformance Traffic envelope je niz traffic

conformance parametara koji opusuju kako QOS usluga pod nazivom ukupni

saobraaj upstream domene treba izgledati kako bi se dobile garancije indicirane

parametrima performanse SLS-a. Traffic conformance je algoritam koji je sastavni

9

dio SLS-a te opisuje kako se saobraaj ispituje u odnosu na ciljano/ugovoreno

ponaanje.

5. Obrada vika saobraaja ovim atributom se opisuje kako je viak saobraaja

tretiran.

6. Raspored usluga ovim poljem se indicira poetak i kraj vremena za koji je

usluga omoguena. Preporuuje se da obraun bude na mjesenom nivou, ili za

nekoliko mjeseci uzastopno.

7. Pouzdanost ovim poljem se opisuje dozvoljeno srednje vrijeme prekida rada po

godini (MTD) i maksimalno dozvoljeno vrijeme oporavnka (TTR) u sluaju kvara

za pruanje usluga opisanih SLS-om. Vrijednosti navedenih parametara trebaju da

budu u skladu sa garancijama koje se predviaju putem administrativnog dijela

SLA ugovora.

10

2. SLA za uspostavu sa kraja na kraj

SLA izmeu dva peer-a predstavlja strukturnu jedinicu za uspostavu usluge sa kraja na

kraj. Ako su odgovarajui SLA ugovori od izvora do odredita pravilno definirani, onda

odgovarajui mehanizmi mogu procijeniti veze izmeu uzastopnih peers-a i odrediti

dostupne resurse za zahtjeve specificirane usluge.

Slika 2

Ovdje emo definisati neophodne off-line procedure za SLA uspostavu sa kraja na kraj. Za

uspostavljanje e2e SLA, kako je prikazano na slici 2., mora postojati lanac bilateralnih

SLA. Na njoj je prikazan scenarij dodjele usluge podrane DiffServ mehanizmom preko

uzastopnih transportnih domena od korisnika A koji je u mrei kampusa, do korisnika B u

udruenom domenu. Za izvedbu ove komunikacije, saobraaj prolazi kroz vie regionalnih

i nacionalnih backbone mrea. Svaki bilateralni SLA treba da je definisan tako da nijedan

dio veze s kraja na kraj nije nepokriven. Cilj svakog bilateralnog SLA izmeu dvije

domene je definisanje procedura i garanciju kvaliteta usluge. Uspostava SLA veze sa kraja

na kraj se odvija u nekoliko koraka. U prvom koraku potrebno je provjeriti ispravnost

bilateralnih SLA redom od jednog do drugog korisnika. U sluaju da jedna od ukljuenih

SLA ne moe osigurati garancije kvaliteta odgovarajuih klasa usluga, onda se SLA veza s

kraja na kraj ne moe uspostaviti. Tada je potrebno pronai drugu domenu sa

odgovarajuim bilateralnim SLA. Drugi korak obuhvata popunjavanje administrativnog

dijela SLA veze sa kraja na kraj. On se popunjava sljedeim redoslijedom:

11

Administrativni i tehniki dijelovi: sadri usluge administrativnih i tehnikih

kontakata za pristupne domene krajnjih korisnika uz odgovarajui bilateralni SLA

Period trajanja za koje je SLA sa kraja na kraj validan. Ovaj period mora pripadati

zajednikom vremenskom razdoblju svih podruja rasporeda usluga ukljuenog

bilateralnog SLA i ako postoji takvo vremensko razdoblje, period definiu

korisnici.

Garancije dostupnosti je dio koji sadrava dostupnost usluge s kraja na kraj u

vremenskoj jedinici. Za tipine backbone mree i bilateralni SLA potpisan sa

susjednim domenama, nedostupnost ili degradiranje garancije performansi moe

biti pola ili cijeli dan. SLA s kraja na kraj mora predvidjeti najgori scenarij, gdje se

bilateralni SLA ne smiju preklapati. Tada se garancija nedostupnosti SLA rauna

kao: 2 100 %e e SLAii

unavailability unavailability

Nadgledanje je dio u kome se specificira kako i kada e se nadgledati SLA s kraja

na kraj. Ovaj posao rade take u mrenoj topologiji gdje je oprema za nadgledanje

postavljena. Ovdje se postavljaju podaci koji nisu dio mree, a koji su vezani za

ocjenjivanje percipirane kvalitete usluge krajnjih korisnika.

Vrijeme odziva se odnosi na ukupno vrijeme odziva koje je garantovano u sluaju

zahtjeva krajnjih korisnika za SLA vezu s kraja na kraj.

Fault handling trouble ticket procedura odreuje radnje koje administrator ili

tehnika podra SLA veze s kraja na kraj treba poduzeti kada doe do greke u

isporuci usluge.

Kvalitet i performanse podrke i helpdesk-a odreuje podrku infrastrukture

ugovorene usluge.

Naplata ugovorene usluge je zahtjevna funkcionalnost koja uzima u obzir cijenu

duine veze s kraja na kraj, te naknade u sluaju krenja SLA.

Opis usluge sadri generalni kvalitativni opis ugovorene usluge, npr.kanjenje,

gubitak paketa, itd.

12

U treem koraku se daje opis protoka i podruja SLA veze s kraja na kraj. Prema ve

predstavljenim principima bilateralnog SLA, podruje i opis protoka polja SLA veze s

kraja na kraj trebaju biti definirani kako slijedi:

Polje podruja odreuje regiju u kojoj je definirana SLA usluga omoguena. Za

SLA vezu s kraja na kraj, ovo polje treba navesti izlazni interfejs pristupne domene

(SLA c na slici 2) kroz koji je izvor saobraaja krajnjeg korisnika ubaen u

topologiju i ulazni interfejs destinacijske domene (SLA e na slici 2), kroz koji

saobraaj dolazi do krajnjeg korisnika.

Opis protoka polje treba jedinstveno identificirati pakete oznaene za odreenu

uslugu, poslane od krajnjeg korisnika A do korisnika B kroz nekoliko domena.

U etvrtom koraku se na temelju bilateralnih SLA garancija odreuju garancije

performanse SLA veze s kraja na kraj. Bilateralni SLA-ovi, kao to su izmeu backbone i

nacionalne domene, obino sadravaju veinu klasa usluga koje se posluuju kroz nekoliko

domena. Da bi SLA s kraja na kraj bio izvediv potrebno je:

Minimalna MTU vrijednost du lanca bilateralnih SLA mora biti vea ili jednaka

od MTU zahtjevanog SLA s kraja na kraj.

Propusnost podranog saobraaja u lancu bilateralnih SLA mora biti u jednom

dijelu lanca s kraja na kraj (i) vei od sume ve podranih SLA s kraja na kraj i

(ii) vei ili jednak sumi vei postojeih SLA sa protokom koji je SLA s kraja na

kraj zatraio.

U sluaju EF baziranih servisa potrebne metrike za SLA uspostavu s kraja na kraj su:

OWD iz podruja korisnika A do podruja krajnjeg korisnika B. OWD je dodatna

metrika i garancije koje daje SLA s kraja na kraj moraju biti usklaene:

2e e i

i

d d

gdje id pripada svakoj od bilateralnih SLA-ova i, kombionovanih kako bi izgradili e2e

SLA.

Kapacitet. Garantovani kapacitet za e2e SLA mora biti manji ili jednak

minimalnom garantovanom kapacitetu koji je pruen toku (tokovima),

identifikovanog pomenutim 'flow description field' poljem nad svim ukljuenim

bilateralnim SLA-ovima.

2 mine e ii

c c

13

U ovom trenutku ovo je ono od ega uspostava e2e SLA ovisi bez obzira da li ukupni

dostupni (nedodjeljeni drugim e2e SLA-ovima) kapacitet du lanca bilateralnog SLA-a je

dovoljan da zadovolji potranju kapaciteta trenutnog e2e SLA-a.

IPDV. Garantirani IPDV za e2e SLA mora vei ili jedank od zbira garantovanih

jittera od strane svih ukljuenih bilateralnih SLA-ova

2e e i

i

j j

gdje ij pripada svakoj od bilateralnih SLA-ova i, kombinovanih kako bi izgradili e2e

SLA.

OWPL. Garantirani gubitak paketa za e2e SLA mora predvidjeti najgori sluaj

scenarija, u kojem, kako paketi izvornog end-korisnika prelaze uzastopne domene,

maksimalni broj gubitaka se javlja na udaljenosti izmeu svake bilateralne SLA.

Stoga vrijedi:

2e e i

i

l l

Gdje je il maksimalni broj izgubljenih paketa garantovan od strane svakog od bilateralnih

SLA-ova i, kombinovanih kako bi izgradili e2e SLA.

MTU. Koritena MTU vrijednost za e2e SLA odgovara minimalnoj MTU

vrijednosti svih koritenih bilateralnih SLA-va:

2 mine e ii

MTU MTU

Ponovno, uspostavljanje e2e SLA ovisi o tome da li je minimalna MTU vrijednost u lancu

bilateralnih SLA dovoljna kako ne bi naruila trenutnu e2e MTU vrijednost SLA-ova.

U petom koraku se definie usklaenost saobraaja i SLA s kraja na kraj anvelopa

saobraaja. Za usklaivanje saobraaja najee se koristi algoritam token bucket sa

parametrima r (bit/s) kao brzina i b (u paketima) dubina, koji identificira pakete ili kao

'inprofile' ili "out-of-profile ' na osnovu prosjene brzine i usnopljenosti protoka. U

zavisnosti od usluga za koje je SLA osnovana token bucket parametri mogu koristiti

razliite vrijednosti.

1...3 ,b paketa 21.2 e er c

2e ec je vrijednost ugovorena od strane e2e SLA kapaciteta za specificine klase servisa

izmeu krajnjih korisnika.

14

Konano, u estom koraku definiraju se e2e SLA operativna polja. Kod e2e SLA, vitak

saobraaja se ili odbacuje ili oznaava kao best-effort na ulaznom interfejsu pristupne

domene krajnjeg korisnika A. Vrijeme poetka i zavretka perioda za koji se e2e usluga

prua prema SLA se odreuje poljem rasporeda servisa. Pouzdanost treba definisati

maksimalno dozvoljeno vrijeme za popravak u sluaju kvara za pruanje e2e servisa i

dozvoljeno prosjeno sredstvo zastoja po jedinici vremena za pruenu uslugu

2.1. SLA verifikacija

Za verifikaciju SLA na osnovu lanca bilateralnih SLA, potrebno je definisati

infrastrukturni monitoring, koji se sastoji od:

Monitoring opreme pozicionirane na sredini putanje s kraja na kraj, pod nazivom

oprema za monitoring nadalje (SPME).

Monitoring oprema kod krajnjih korisnika (EME)

Slika 3

Postojanje SPME je bitno za uspostavljanje i praenje bilateralnih SLA-ova. SPME treba

da je pozicioniran u kritinim pozicijama domena ukljuenih u bilateralnim SLA-ovima, u

cilju nadgledanja pruene usluge i otkrivao uzroke i porijeklo kvarova servisa. Za

bilateralni SLA, SPME treba da postoji na svim interfejsima ukljuenim u oblast

djelokruga SLA. Za infrastrukturni monitoring za bilateralni SLA prikazan na slici 3

SPME treba da postoji na svim interfejsima A-E. Svaka domena moe izabrati da rasporedi

monitoring infrastrukturu u okvirima svoje administrativne granice. Mada nije direktno

ukljuena u postupak monitoringa, ona moe pomoi u izoliranju nedostataka u pruanju

usluga unutar domena. Ovo je korisno kada monitoring rubnih interfejsa rezultira krenje

datih garancija u bilateralnom SLA. Nakon uspostavljanja SLA s kraja na kraj, mora se i

krajnjim korisnicima pruiti alat EME za potrebe provjere kvalitete i koliine protoka

15

usluge. Obzirom da EME ne moe biti zasnovana na hardveru i sloenim procedurama,

krajnjim korisnicima se dodjeljuje skup softverski baziranih, aktivnih alata za praenje,

omguavajui im da posmatraju performanse pruene usluge u odreenim intervalima.

SMT ne zahtijeva vrijeme sinhronizacije izmeu krajnjih korisnika, zbog ega je strogo

predloen. SMT-ovi koji se dodjeljuju krajnjim korisnicima moraju biti u pratnji skupa

skripti za obradu log-ova stvorenih tokom rada i smjernice za skup parametara koji je

potrebno konfigurisati za rad svakog SMT-a . Svaka naznaka krenja garantovane kvalitete

i protoka koja nastaje na EME-u, morae biti dostavljena uesnicima e2e SLA-a. Nakon

toga se obavlja istraga pojedinh bilateralnih SLA monitoring podataka du e2e putanje na

rekurzivan nain, u nastojanju da se problem pronae i rijei. Navedena hijerarhija SPME-

a (kako u granicama uzastopnih domena i unutranjost svakog domena) treba biti

iskoritena u tom pravcu, na osnovu procedure za rukovanje greke navedene u svakoj

bilateralnoj SLA.

16

3. Procedura dodjele servisa

Prilikom pruanje DiffServ-baziranih usluga povezanosti izmeu dva krajnja korisnika

potrebno je uspostaviti kroz nekoliko faza, kao to je prikazano na slici 4. Na samom

poetku, faza pregovaranja bi trebala definisati ukljuene subjekte, svrhu koritenja

pojedinih servisnih konektivnosti, izvodljivost pruanja usluga, itd. U toku set-up faze

servisa, prikupljaju se detalji o pruanju usluga, te potrebni SLA/SLS-ovi moraju biti

potpisani i detaljne konfiguracije koritene opreme se moraju izvriti.

Slika 4. Faze dostavljanja servisa

U toku faze operacije usluge, ukoliko se ne pojavi indikacija kvara servisa, nema potrebe

da se neke specifine aktivnosti moraju obavljati. U tom sluaju, poduzimaju se potrebne

mjere kako bi se usluga operacije obnovila. Paralelno sa fazom operacije servisa, trebala bi

se odvijati i faza praenje, koja vri konstantna mjerenja aktivnosti s ciljem utvrivanja

potrebne kvalitete servisa. U fazi monitoringa moe se dogoditi da performanse servisa

odstupaju od eljenih performansi. Kao rezultat toga pokree se faza podeavanja servisa,

ukljuujui podeavanje konfiguracije du puta uspostave servisa. Faza prilagoavanja

servisa uvijek rezultira novom servisnom operacijom i fazom monitoringa, koje se odvijaju

17

paralelno, sve dok vrijeme pruanja usluge frame-ova istekne i faza terminiranja servisa

pone.

U ovom poglavlju emo se uglavnom baviti pregovorima i fazama uspostavljanja servisa, a

takoer pokuava dodijeliti odgovornosti ostalim fazama. Zbog vie ukljuenih domena u

pruanje usluge na bazi DiffServ e2e, neophodno je da veliki broj entiteta bude imenovano

i ukljueno u razliite faze pruanja uslugu. Metodologija ovog pristupa se bazira na

osnovu GEANT - NREN arhitekture koja se koristi kao referentni model. Za koordinaciju

faza pregovora, postavljanja i fazu operacije se preporuuje da krajnji korisnici imenuju

zajednikog predstavnika (SPC-Service Provision Coordinator) koji e biti posrednik

izmeu ukljuenih mrea i strane krajnjih korisnika, koordinirajui postupkom uspostave

pruanje usluga kao i bilo kojeg od zadataka potrebnog u fazi operacije.

Takoer se preporuuje da se imenuje tehnika osoba kao odgovorna za pruanje usluge i

implementaciju za svaku od strana krajnjih korisnika. U konzistenciji sa scenarijom

pruanja na slici 2. , Sl . 5 prikazuje kako tehniki kontakt (tehniki kontakt A ili TC A)

treba da bude odgovoran za uspostavu usluge i odravanja od domene krajnjeg korisnika A

do izlaznog interfejsa nacionalnih domena A (EA), i na analogan nain jo jedno tehniko

lice (tehniki kontakt B ili TC B) bi trebalo biti odgovorno za servise iz nacionalne

domene B ulaznog interfejsa (IB) do domene krajnjih korisnika B.

Slika 5. Delegacija autoriteta za proceduru pruanja servisa

18

Ovi tehniki kontakti trebaju pripadati NOC-u svake nacionalne domena. Slino tome,

backbone mrea treba da imenuje tehniku osobu za pruanje i odravanje usluga

podravanih od ponuenih SLA-ova. Kao to je prikazano na slici 5. , backbone tehniki

kontakt (BTC) e biti odgovoran za odreene usluge rezervisanja od I do E, dok u isto

vrijeme prua povratne informacije potrebne za TCS. Sa slike 5. je oigledno da e TC-

ovi A i B, koji su odgovorni za usluge uspostave i rezervisanja na strani svakog krajnjeg

korisnika, imati pod njihovim nadzorom upostavu i operaciju servisa za vie od jedne

domene (najmanje dvije na osnovu meunarodnog povezivanje: nacionalnu domene i

domenu krajnjeg korisnika).

To ini njihov posao prilino zahtjevnim, u smislu da bi oni morali imati koordinirati

servis rezervisanja izvan granica domene koju mogu izravno kontrolisati. Dakle, njihove

dunosti, osim komunikacije sa BTC-om e ukljuivati pruanje tehnike pomoi svim

domenskim administratorima koji su ukljueni pod njihov autoritet (vidjeti 'plavi' oblak na

slici 5). To znai da e TC A i TC B morati prevesti pravila pruanja servisa (kao to je

prioritet zakazivanja za sluaj EF baziranih usluga ) na specifinu opremu koja je

dostupna u okviru njihovog autoriteta kad god se trai da to uine. Osim toga, oni e biti

odgovorni (uz pomo SPC-a) za prikupljanje i odravanje svih potrebnih kontakt

informacijama za tehnike kontakte u okviru svojih ovlatenih regija.

Na ovaj nain, usluga rezerviranja sa tehnikog aspekta e se vriti na hijerarhijski nain,

sa BTC-om i svakimTC-om krajnjeg korisnika na vrhu hijerarhije zajedno sa bilo kojim

drugim tehnikim subjektima ukljuenim na svakoj strani krajnjeg korisnika, koji je

koordiniran odgovarajuom TC stranom krajnjeg korisnika (slika 6.).

Slika 6.Hijerarhijska komunikacija tehnikih kontakata ukljuenih u pruanje servisa

19

Osim tehnikih odgovornosti, potrebno je da svaka strana krajnjeg korisnika imenuje

osobu odgovornu za procjenu uinka servisa iz gledita ukljuenih aplikacija. Ovi kontakti

performansi evoluacije (PEC A i PEC B) su, drugim rijeima, odgovorni za provjeru da li

realizira usluga isporuuje do krajnjeg korisnika kvalitetu koja im je potrebna, a ako ne

isporuuje tada savjetuje prilagodbe SLA/SLS-u. Njihove preporuke za korekcije onda

treba dostaviti TCS-u svake strane preko SPC-a kako bi se prevelo na akciju re-

konfiguracije u koritenoj opremi. Slika 7. prikazuje mogui nain za komunikaciju

predloenih entiteta, gdje SPC djeluje na sredini izmeu TC-va, PEC-va i korisnikih

strana. Alternativno, kako bi se smanjio overhead komunikacije, krajnji korisnici mogu

izbjei direktni kontakt sa SPC-om i komunicirati bilo kakve informacije putem PEC-a

svakestrane krajnjeg korisnika.

Slika 7.Ukljueni entiteti u pruanju SLA baziranog servisa

20

Zakljuak

Koritenjem SLA specifikacija za DiffServ mree imamo za cilj osigurati kompatibilnost

pruenih usluga preko uzastopnih domena, teimo pruiti zadovoljavajue kvalitete usluga

i elimo postaviti granice za usluge koje se pruaju. U odnosu na ve postojea rijeenja

ovi SLA-ovi variraju, te ne moraju specificirati samo dostupnost, sigurnost, koliinu

dodijeljenih sredstava, ve se moraju navesti i vrijednosti odreenih parametara kvalitete.

Best-effort saobraaj nema garanciju kvalitete u IP mreama, stoga se uvode kvalitativne

usluge koje zahtjevaju temeljit i precizan inenjering QoS metrika u SLA specifikaciji.

Ovim radom je definisan okvir za uspostavljanje bilateralnog SLA-a prema principima

DiffServ bazirane usluge rezervisanja. Takoer su administrativni i SLS dijelovi SLA

detaljno predstavljeni, sa ciljem obuhvatanja svih tehnikih parametara koji se zahtjevaju

pri rezervisanju usluga sa kvalitativnim garancijama. Predloena je metodologija za

uspostavu e2e SLA uz opis koordinacije subjekata ukljuenih u uspostavu SLA e2e. Jo je

dosta rada potrebno kako bi se DiffServ bazirani SLA-ovi postali potpuno efikasni i

funkcionalni, kako bi na taj nain inili korisne alate za administratore mrea i operatore.

Poseban dio je zadatak za osmiljanje mehanizama i procedura za identifikaciju i kontrolu

prekraja unaprijed definisanih SLA-ova, kako bi se omoguilo ponovno pregovaranje i

pircing SLA-ova te mehanizama za kompenzacije u sluaju kvarova. U buduem radu na

SLA-ovima za IP mree koje imaju omoguen QoS je mogue ostvariti dio definisanog

zadatka.

21

Literatura

[1] Blake S, et al. An architecture for differentiated Services IETF RFC 2475, December

1998.

[2] Bouras C, Campanella M, Sevasti A. SLA definition for the provision of an EF-based

service 16th International Workshop on Communications Quality and Reliability (CQR

2002), Okinawa, Japan, May1416 2002 p. 1721.

[3] Davie B, et al. An expedited forwarding PHB (Per-Hop behavior) IETF RFC 3246,

March 2002.

[4] Fankhauser G, Plattner B. DiffServ bandwidth brokers as mini-markets Workshop on

Internet Service Quality Economics, MIT, US, December 23 1999.

[5] Goderis D, et al. D1.1: Functional architecture definition and top level design,

TEQUILA project: traffic engineering for quality of service in the internet, at large scale

IST-1999-11253, September 2000.

[6]Internet2 QoS group, QBone bandwidth broker architecture, Work in progress,

accessible at: http://qbone.internet2.edu/ bb/bboutline2.html.

[7]Neilson R, Wheeler J, Reichmeyer F, Hares S, editors. A discussion of bandwidth

broker requirements for Internet2 Qbone deployment. Internet2 Qbone BB Advisory

Council, Version 0.7, August.

[8] Nichols K, Jacobson V, Zhang L. A two-bit differentiated services architecture for the

Internet IETF RFC 2638, July 1999.

[9] Paxson V, Almes G, Mahdavi J, Mathis M. Framework for IP performance metrics

IETF RFC 2330, May 1998.

[10] Rajan R, Celenti E, Dutta S. Service level specification for inter-domain QoS

negotiation, draft somefolks-sls-00.txt Internet Draft, November 2000.

[11] Roth R, et al. IP QoS across multiple management domains: practical experiences

from pan European experiments. IEEE Commun Magaz 2003;41(1).

[12] Salsano S, et al. Definition and usage of SLSs in the AQUILA consortium, draft-

salsano-aquila-sls 00.txt Internet Draft, November 2000.