Elektrotehniki Fakultet

Sarajevo

Opis SLA koji se koristi u praksi

Kvaliteta usluga u TK mreama

Studenti: Herenda Adna

Zaimovi Faruk
Hadiahmetovi Adnan
Sarajevo, Maj 2014. godine

Sadraj

Uvod....................................................................................................................... 3
1. Bilateralni SLA-ovi.............................................................................................. 5
1.1.......................................................................................................................... 5
2.2 SLS dio......................................................................................................... 7
3. SLA za uspostavu sa kraja na kraj......................................................................8
3.1. e2e SLA verifikacija.................................................................................... 12
4 . Procedure dodjele servisa............................................................................... 14
5. Zakljuak.......................................................................................................... 17
6. Liter atura......................................................................................................... 18

Uvod
SLA je eksplicitna izjava o oekivanjima i obavezama koje postoje u poslovnom
odnosu izmeu dva entiteta: provajdera (davatelja usluga) i kupca (Rajan et al.,
2000). SLA osigurava sredstva definiranja usluga. To odreuje ono to kupac eli i
onoga to isporuitelj (supplier) ima da ponudi. To definira standarde za kvalitete
pruene usluge, postavljanje ciljeva izvedbe koje dobavlja (supplier) mora
postii, takoe definira procedure i izvjea koja se moraju osigurati radi praenja
kako bi se osigurala usklaenost s SLA. U polju telekomunikacionih mrea, SLA
igra znaajnu ulogu, s najnovijim napretkom u rezervisanju diferenciranih usluga.
Dostupnost velike brzine po prenosnom mediju i mrenoj opremi, kao i evolucija
kvalitetom vrlo zahtjevnih aplikacija ima fokusirani interes dostavljanja QoS-a na
best-effort modelu Interneta. Broj alternativa za usluge diferencijacije i pruanja
QoS su predloene i standardizovane, ali u sluaju IP backbone mrea
Differentiated Services(DiffServ) arhitektura je prevladala, zbog svoje
skalabilnosti.
Osiguravanje IP usluge prema DiffServ frameworku je uvelo
kompleksnost u datom poslovnom modelu i podiglo uvjete za kontroliranu
raspodjelu resursa upravljanja, definiranje, praenje i provjeru pruene kvalitete.
U ovom trenutku, SLA izmeu kupca i provajdera je predvien za pruanje
zahtjevane kontrolirane okoline. U ovom frameworku, SLA e djelovati kao
posrednik za uzajamno pruanje usluga izmeu peering domena.
DiffServ framework se istie nastojei pruiti uslugu diferencijacije prometa na
skalabilan nain, sugerirajui kumuliranja pojedinanom zahtjevu tokova sa
slinim potrebama kvalitete. DiffServ uvodi definiciju razliitih klasa servisa
prema kojim se takvi agregati postavljaju i implementiraju mehanizme za
diferecijalnu obradu od strane mrenih elemenata (Per-Hop-Behavior,PHB) paketa
koji pripadaju pojedinim klasama servisa. PHB opisuje obradu agregiranog
prometa na nain koji osigurava garanciju kvaliteta koju prua odgovarajua
klasa servisa.
Iako je DiffServ u poetku bio smatran izuzetno pogodnim, zbog svoje
skalabilnosti, DiffServ fremework (okvir) mehanizmi su se pokazali teki za
implemetaciju i praenje u velikoj razmjeri, unutar mrenih ureaja. Na osnovu
DiffServ frameworka, broj modela usluga izgraenih kombinacijom DiffServ
mehanizama je predloen i ekspreminetalno se ocjenjuje do danas. Meutim, u
realnosti DiffServ servis jo nije uspjeno implementiran na mrenim ureajima.
Tu nedostaju: DiffServ funkcionalnost s IP rutera, odnosno QoS, znaajna
operativna i ekonomska paradigma pomaka se trai od operatora, nedostatak
poslovnog modela, nedoraslost usluge, provjera infrastukture, nedovoljna
standardizacija i arhitekturske praznine su neke od glavnih problema u
implemetaciji.
Vjerujemo da DiffServ framework i DiffServ bazirane usluge imaju znaajan
potencijal u unapreenju best-effort modela Interneta. Meutim, s obzirom na
3

njegov probabilistiki, a ne deterministiki diferencijacijski mehanizam, model

rezerviranja DiffServ treba biti temeljito specificiran i standardiziran to je prije
mogue. Meu pomenutim problemima implemetacije, fleksibilan poslovni model
za unutar-domenski razvoj i peering ugovore u skladu sa postojeim
sporazumima se smatra kljunim za uspjenu implemetaciju DiffServ baziranih
usluga u mrenim ureajima.
Danas, instalacija SLA izmeu kupaca i provajdera je prilino statino i radnointezivan zadatak. Postupci koji su ukljueni u taj proces su vlasnitvo provajdera.
Po svojoj prirodi, takav proces ne doputa open-service arhitekturu, kao to je bio
sluaj DiffServ baziranih usluga, koja bi bila izgraena na meusobno povezanim
IP mreama. Podrazumjeva se da standardizacija tehnikih djelova osnovnog
procesa moe omoguiti vrlo razvijen stupanj automatizacije i dinamian
pregovor o Service Level Specification (SLS-specifikaciji nivoa usluge) izmeu
peering usluga ili kupaca i provajdera. Ova automatizacija moe biti korisna
prilikom opskrbe korisnika (kao i provajdera) sa tehnikim ureajima za pruanje
dinamikog QoS stabilnog transportnog servisa. SLA i SLS su neophodni za
isporuku dobivenog QoS-a od jednog do drugog krajnjeg korisnika preko vie
domena.
Do sada je bilo nekoliko nastojanja standardizacije definicija SLA i njihove
instalacije u QoS baziranim mreama (Bouras et al., 2002; Fankhauser and
Plattner, 1999; Neilson et al., 1999; Nichols et al., 1999). U mreama proizvodnje,
servis provajderi koriste vlastite prilagoene SLA ugovore za kvalitativne IP
usluge rezerviranja. Osim toga, model rezerviranja obino se odnosi na backbone
mreni servis provajder i njegove direktno vezane kupce. Sluaj uspostave QoS-a
unutar vie domena u kojoj se parametri kvalitete mree moraju preslikati u
susjedne dokmene i trebaju biti konzistentne du puta, se rijetko rjeava. Nadalje,
procesi za uspostavu end-to-end SLA-ova u takvim sluajevima nisu jo dovoljno
razvijeni.
U ovom radu, mi u poetku predstavljamo temeljna naela za uspostavu ugovora
o pruanju usluge (SLA) u DiffServ-baziranim uslugama, u bilateralnom obliku
(izmeu peering domena). U tu svrhu, koristi se, servis bazirana na temelju
ubrzanog proslijeivanju (EF), DiffServ PHB (Salsano, 2000), za posluivanje
visoko-prioritetnog saobraaja i saobraaja koji zahtjeva visoku kvalitetu.
Osim toga, mi smo predloili i metodologiju za uspostavu end-to-end SLA na
temelju bilateralnih SLA-va, koristei GEANT jezgrenu pan-Europsku istraivaku
mrea kao referentnu arhitekture, koja meusobno povezuje Europski nacionalnih
istraivaki centar i obrazovne mree (NREN), a kroz njih kampus i institucije,
korisnike grupe i na kraju korisnike diljem Europe. Osim SLA end-to-end
uspostave, predlaemo model rezerviranja za uspostavu i koordinaciju SLAbaziranih usluga implementacije i operacija.

1. Bilateralni SLA-ovi
Bilateralni SLA se zasniva na detaljnom opisu pruanja usluga, dostupnosti i
garancije izmeu dva peering domena koji podravaju jednu ili vie kompatibilnih
servisa (usluga). SLA opisuje kako svaka od dvije domene omoguuje odreenu
uslugu do usluno-prihvatljivog saobraaja dobijenog od svojih susjeda i obrnuto.
Predloena bilteralna SLA specifikacija se sastoji od dva dijela:

Administrativno/pravni dio
SLS dio, definira skup parametara i njihovih vrijednosti, za pruanje
DiffServ-baziranih usluga prometnom agregatu po DiffServ domeni.

Nakon definiranja bilateralne SLA, sljedei koraci su definirati mehanizme za SLA

pregovaranja i, naravno, uspostavljanje
end-to-end usluga baziranih na
pojedinanom SLA-u.
Svaki primjer SLA obuhvaa SLO (Service Level Object) i sadri parametre i
njihove vrijednosti koji opisuju DiffServ-baziranu uslugu i specifini tok (flow) koji
je primio tokom transportnog domena.
Dvosmjerne usluge su takoer mogue kombinacijom dva SLO-a prilikom
ugovaranja usluge koje se odnose na dva toka, jedan u svakom smjeru. Ove SLO
e obuhvaati transportnu uslugu, koja je dio SLA ugovora definiranog izmeu
dva podruja, meu kojima je dvosmjerna usluga uspostavljena. Slika 1 prikazuje
SLA obrazac i dvije njegove instance, prikazujui spomenute pojedinane SLA
komponente zajedno.
SLA prikazan na lijevoj strani je primjer dvosmjernog SLA koji sadri dva
jednosmjerna SLO-a. Ovi SLO-ovi grubo definiraju pruanje EF-bazirane usluge
preko GEANT backbone mree na grki NREN (GRNET) za EF konektivnost sa
njemakim NREN (DFN).
Na donjoj slici (Slika 1) prikazan je SLA primjer koji definira osiguravanje EFbazirane usluge preko GRNET backboon-a. U sljedeim poglavljima omoguena
je detaljnija specifikacija predloenog SLA i SLS template-a.
5

1.1. Administativno/pravni dio SLA

Administrativno/pravni dio SLA je predloio kompromis od nekoliko polja koje

definiraju procedure i framework za pruanje usluge na kojima je SLA osnovana.
Predloena polja su:

Administrativne i tehnike strane koje su ukljuene. Ovaj dio treba

da sadri barem jedan administrativni i jedan tehniki kontakt iz svake od
dvije strane koje sudjeluju u SLA.
Vremenski period. Ovaj dio treba da sadri period za koje je SLA validan.
Ovaj period moe se razlikovati od perioda definiranog u
service
schedule polju SLS dijela od SLA, ali vrijednosti service schedule polja
se trebaju nalaziti unutar perioda unutar perioda definisanog u ovoj sekciji
SLA-a. Service Schedule je skup vremenskih perioda za koje je usluga
aktivna, dok trajanje SLA je vremenski period za koje je SLA validna za
pruanje usluge.
Garancija dostupnosti. Ovaj dio bi trebao definirati proraun podataka
oko dostupnosti usluge, te kako e biti dostavljeni. Ovaj dio treba osigurati
omjer dostupnosti usluga u odnosu na vremensko trajanje SLA-a,
vremensko ogranienje nedostupnosti (Unavailable Time Limit - UTL) i
formule za izraunavanje naknade za nedostupnost.

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

Nadgledanje (Monitoring). Ovaj dio treba odrediti kako i kada (stalno ili
povremeno) se SLA nadzire. Takoer bi trebalo odrediti take mrene
topologije gdje je monitoring oprema instalirana i gdje se mjerenja
oitavaju. Treba navesti i SLS podatke koji su vidljivi klijentu i kako klijent
moe imati pristup praenju podataka.
Vrijeme odziva. Ovaj dio se odnosi na ukupno vrijeme odziva
garantovanog od provajdera u sluajevima zahtjeva klijenta za
podeavanjem SLA(i/ili SLS) i za potrebno konfigurisanje relevantnih
ureaja.
Fault Handling Trouble Ticket. Ovaj dio treba specificirati radnje
poduzete od strane
provajdera kada se desi greka koja se tie
isporuivanja usluge definirane u SLS-u i korespondirajueg vremena
reakcije.
Kvalitet i performanse podrke i helpdesk-a. Ovaj dio treba temeljito
odrediti infrastrukturu izvjetaja ugovorenih servisa.

Odreivanje cijene ugovorenih servisa. Odreivanje cijene pruene

usluge je najznaajniji dio SLA ugovora izmeu korisnika i mrenog
provajdera. DiffServ ema, koja efikasno odraava vrijednost usluge i
maksimizira nekoliko kriterija, mora biti vrlo temeljita i zavisna sa SLA
infrastrukturom nadgledanja i brojanja koja se koristi..

Opis servisa. Generalni opis mrene usluge, opisujui kvalitet usluge i

radnje koja treba biti pruena.

2.2 SLS dio

Predloeni SLA templejt se primjenjuje direktno na sluaj gdje transportna

domena uspostavlja ugovor o pruanju usluge sa korisnikom na jednosmjeran
nain. Bazirano na ovoj pretpostavci, SLS dio SLA ugovora sadri slijedea polja:
1. Podruje. Ovo polje definie topologiju regiona koji e sa odreenim
servisom, definisanim SLS-om, biti omoguen. Ono mora odreivati gdje
paketi, u skladu sa SLS-om, ulaze i izlaze iz DiffServ domene.
2. Opis protoka. Ovo polje e indicirati na koje IP pakete e garancija kvalitete
specifinog SLS-a biti primjenjena, drugim rijeima, koji paketi e primiti
PHB tretman koji rezultira garancijom kvalitete usluga kod SLS-a. Ovo polje
je predloeno da bude prvenstveno DSCP ili IP vrijednost koja moe
jedinstveno identificirati primljene pakete SLA specifine usluge. Kako god,
dodatne informacije, su ve pristutne u paketu (izvorna ili destinacijska IP
asresa, tip protokola, itd) ili se mogu saznati iz mrene topologije.
3. Garancije performanse. Ovo polje prikazuje garancije koje mrea nudi
korisniku za protok paketa opisan prethodnim poljem preko opsega
topologije sa vrijednou podruje polja. Niz parametara performansi za
standardni saobraaj koji se primjenjuje za sluaj EF bazirane usluge ali
takoer i na druge DiffServ bazirane usluge:

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

da bude garantovano maksimalno kanjenje prenosa paketa
mjereno izmeu definiranih taaka.

Instantaneous Packet Delay Variation (IPDV) varijacija kanjena

trenutnih paketa. Predloeno je da bude garantovano kao
8

maksimalna promjena kanjenja prenosa paketa mjerena izmeu

definiranih taaka.
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.
Kapacitet. Definie se kao brzina mjerena na nizu izlaznih taaka
svih paketa identificiranim poljem Flow descriptor.
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 (TC) parametara koji opisuju kako QOS usluga pod nazivom
ukupni saobraaj upstream domene treba izgledati kako bi dobili garancije
indicirane parametrima performanse SLS-a. Traffic conformance algoritam
je dio SLS-a, koji opisuje kako se saobraaj ispituje u odnosu na
ciljano/ugovoreno ponaanje. Mogue je imati i druge binarno bazirane ili
TC algoritme sa vie nivoa.
5. Obrada vika saobraaja. Ovaj atribut opisuje kako je viak saobraaja
tretiran (npr. odbacivanje paketa).
6. Raspored usluga. Ovo polje indicira poetak i kraj vremena za koji je usluga
omoguena. Predloeno je da bude mjeseni obraun, svaki mjesec ili za
nekoliko mjeseci uzastopno.
7. Pouzdanost. Ovo polje treba opisati dozvoljeno srednje vrijeme prekida
rada po godini (MDT) i maksimalno dozvoljeno vrijeme oporavka (TTR) u
sluaju kvara za pruanje usluga opisanih SLS-om. Vrijednosti ovih
parametara trebaju biti u skladu sa garancijama predvienim putem
administrativnog dijela SLA ugovora.

3. SLA za uspostavu sa kraja na kraj

Definicija SLA izmeu dva peer-a je strukturna jedinica za uspostavu usluge sa

kraja na kraj. Pod uvjetom da su bilateralni SLA ugovori pravilno definirani od
eljenog izvora do eljenog odredita, odgovarajui mehanizmi mogu procijeniti
sve veze izmeu uzastopnih peers-a i utvrditi resurse koji su dostupni za zahtjeve
specifine usluge.

Slika 2. Topologija SLA uspostave sa kraja na kraja

Konfiguracija s kraja na kraj i osiguravanje kvalitete servisa ima niz osobitosti
koje treba rjeavati. U ovoj konfiguraciji je najvanija koordinacija pruanja usluga
na vie samostalnih upravljanih domena na nain da krajnji korisnici doive
stabilnu i predvidljivu uslugu s unaprijed definiranih garancijama kvalitete usluge,
bez obzira na domene i bilateralni SLA koji je ukljuen. Umjesto davanja
automatizovanog mehanizma za SLA uspostavu sa kraja na kraj, ovo poglavlje e
pokuati definisati neophodne off-line procedure.

Kao to je prikazano na slici 2., ukoliko se eli uspostaviti e2e SLA (end-2-end sa
kraja na kraj), prvo mora postojati lanac bilateralnih SLA-ova. Slika prikazuje
indikativni scenarij za dodjeljivanje usluge podrane DiffServ mehanizmom preko
uzastopnih transportnih domena od korisnika A koji se nalazi u mrei kampusa,
do krajnjeg korisnika B koji se nalazi u udruenom domenu. Da bi ova
komunikacija bila izvediva, saobraaj prolazi kroz nekoliko regionalnih i
nacionalnih backbone mrea, preko meunarodne backbone mree.

Pojedinani bilateralni SLA mora biti definisan na nain da nijedan dio veze s
kraja na kraj nije ostao nepokriven. Cilj svakog bilateralnog SLA izmeu domene
D1 i D2 je definirati procedure i garanciju kvaliteta usluge.

Da bi se uspostavila SLA veza s kraja na kraj, nekoliko koraka mora biti poduzeto:

10

Korak 1: Kolekcija lanaca SLA-ova s kraja na kraj. Ovaj korak uspostave SLA
veze s kraja na kraj treba na poetku provjeriti valjanost bilateralnih SLA redom
od jednog korisnika do drugog. Ovaj postupak bi trebao osigurati da bilateralni
SLA postoji na putu od izvora do odredita i da su usklaeni sa osnovnim
principima te usluge.
U sluajevima da jedna od ukljuenih SLA ne uspije osigurati osnovne garancije
kvaliteta odgovarajuih klasa usluga, onda se SLA veza s kraja na kraj ne moe
uspostaviti. U takvim sluajevima, potrebno je potraiti alternativnu domenu s
odgovarajuim bilateralnim SLA.

Korak 2: Popunjavanje administrativnog/legalnog dijela SLA veze s kraja

na kraj. U ovom koraku, administrativni dio SLA veze s kraja na kraj mora biti
popunjen kako slijedi:

Administrativni i tehniki dijelovi koji su ukljueni: Ovo polje e

najvjerovatnije sadravati usluge administrativnih i tehnikih kontakata za
pristupne domene krajnjih korisnika uz odgovarajui bilateralni SLA.

Period trajanja. Ovaj dio e najvjerovatnije sadravati period za koje je

SLA s kraja na kraj validan. Taj period mora pripadati zajednikom
vremenskom razdoblju svih podruja 'rasporeda usluga' ukljuenog
bilateralnog SLA i ako postoji takvo vremensko razdoblje, taj period
definiu sami krajnji korisnici.

11

Garancije dostupnosti. Ovaj dio treba sadravati dostupnost usluge s

kraja na kraj u vremenskoj jedinici. Ovo polje moe takoe eksplicitno
proizilaziti iz odgovarajuih polja ukljuenih bilateralnih SLA-va. Za tipine
backbone mree i bilateralni SLA potpisan sa susjednim domenama,
nedostupnost ili degradiranje garancije performansi moe biti pola dana ili
jedan dan. SLA s kraja na kraj mora predvidjeti najgori scenarij, u kome se
bilateralni SLA ne smiju preklapati. U tom sluaju, garancije nedostupnosti
SLA s kraja na kraj se mogu raunati kao:

unavailabilitye 2 e 100

unavailability
i

SLAi

gdje je nedostupnost SLA izraena u postotcima.

Nadgledanje. Ovaj dio bi trebao specificirati kako i kada (stalno ili

povremeno) e se nadgledati SLA s kraja na kraj. To bi trebale odrediti
pojedine take mrene topologije gdje je postavljena oprema za
nadgledanje ili gdje se mjerenja oitavaju. Ovaj dio takoer treba
specificirati podatke koji nisu dio mree, a koji su vezani za ocjenjivanje
percepirane kvalitete usluge krajnjih korisnika, koji su najvjerovatnije
ovisni o programu koritene usluge.

Vrijeme odziva. Ovaj dio se odnosi na ukupno vrijeme odziva koje je

garantovano u sluaju zahtjeva krajnjih korisnika za SLA vezu s kraja na
kraj. Ovo polje treba predvidjeti najvee odgovarajue polje izmeu svih
ukljuenih bilateralnih SLA-ova.

Procedura fault handling trouble ticket. Ovaj dio treba odrediti radnje
koje treba poduzeti administrator ili tehnika podrka SLA veze s kraja na
kraj kada se dogodi greka u isporuci usluge SLA e2e. To bi trebalo
definirati postupke za ukljuivanje kontakt osobe bilateralnog SLA koje je
potrebno kontaktirati u sluaju greke.

Kvalitet i performanse podrke i helpdesk-a. Ovaj dio treba odrediti

podrku infrastrukture ugovorene usluge.

12

Naplaivanje ugovorene usluge. Odreivanje cijene usluge s kraja na kraj

je iznimno zahtjevna fukcionalnost koja treba uzeti u obzir cijenu duine
veze s kraja na kraj, kao i naknade u sluaju krenja SLA.

Opis usluge. Ovaj dio treba sadravati generalni opis ugovorene usluge,
opisujui kvalitativno njegove karakteristike (npr kanjenje, gubitak
paketa, itd).

Korak 3: Opis podruja i opis protoka SLA veze s kraja na kraj. U skladu sa
osnovnim principima ve predstavljenog bilateralnog SLA, podruje i opis protoka
polja SLA veze s kraja na kraj trebaju biti definirani kako slijedi:

Polje podruja treba odreivati topoloku regiju u kojoj je definirana SLA

usluga omoguena. Za SLA vezu s kraja na kraj, ovo polje treba navesti
izlazni interfejs pristupne domene (prikazano sa SLA c na slici 2) kroz koji
je izvor saobraaja krajnjeg korisnika ubaen u topologiju i ulazni interfejs
destinacijske domene (prikazano sa SLA e na slici 2), kroz koji saobraaj
dolazi do krajnjeg korisnika.

Polje opisa protoka u SLA vezi s kraja na kraj treba jedinstveno

identificirati pakete oznaene za odreenu uslugu, poslane od krajnjeg
korisnika A do krajnjeg korisnika B kroz nekoliko povezanih domena.

Korak 4: Odreivanje garancija performanse SLA veze s kraja na kraj, na

temelju bilateralnih SLA garancija. U ovoj koraku treba biti naglaeno da
bilateralni SLA-ovi, kao to su izmeu backbone domene i nacionalne domene na
slici 2, obino sadravaju veinu klasa usluga koje se posluuju kroz nekoliko
domena. Kako god, SLA s kraja na kraj je povezan sa kvalitetom i kvantitetom
isporuke na nekoliko ogranienih protoka izmeu dva krajnja korisnika.
Predloeno je da SLA s kraja na kraj usvoji kvantitativne garancije isporuene od
strane bilateralnih SLA ukljuenih u zakonsku odredbu usluge na putu izmeu dva
korisnika. U isto vrijeme, predloeno je da SLA s kraja na kraj definie
kvantitativne metrike prema potrebama samog krajnjeg korisnika. Vaan korak
SLA s kraja na kraj procedure je utvrditi da je postojei bilateralni SLA takav da
moe podrati zahtjev SLA veze s kraja na kraj. Drugim rijeima, da bi SLA s kraja
na kraj bio izvediv, potrebno je:

13

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.

Minimalna MTU vrijednost du lanca bilateralnih SLA mora biti vea ili
jednaka od MTU zahtjevanog SLA s kraja na kraj.

Metrike koje su potrebne za SLA uspostavu s kraja na kraj u sluaju EF baziranih

servisa su:

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

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

d e2e di
i

di
gdje
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.???

ce 2 e min ci
i

14

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

je 2 e ji
i

ji
gdje
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:

le 2 e li
i

li
Gdje je
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:
15

MTU e 2 e min MTU i

i

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.

Korak 5: e2e SLA anvelopa saobraaja i definicija usklaenosti

saobraaja. esto koriteni algoritam usklaivanja saobraaja (TCA-Traffic
Conformance Algorithm) je token bucket sa parametrima r (bit/s) kao brzina i b (u
paketima) kao parametar dubine, koji identificira pakete ili kao 'in profile' ili "outof-profile ' na osnovu prosjene brzine i usnopljenosti protoka. Za e2e SLA, token
bucket TCA bi se trebao primijeniti na sve naznaeno u skladu sa SLA ubaenim
standardnim saobraajem od krajnjeg korisnika korisnika do ulaznog interfejsa
njegove pristupne domene.

Za token bucket parametre, u zavisnosti od usluga za koje je SLA osnovana,

mogu se koristiti razliite vrijednosti. Za sluaj EF-bazirane usluge visoke
kvalitete preporuuju se sljedee vrijednosti:

b 1...3 paketa,

r 1.2 ce 2 e

ce 2 e
gdje je vrijednost
ugovorena od strane e2e SLA kapaciteta za specifine klase
servisa izmeu dva krajnja korisnici.

16

Korak 6 : e2e SLA operativna polja. U sluaju e2e SLA , viak saobraaja (ili
out-of profile saobraaj , prema profilu opisanom anvelopom saobraaja i poljem
usklaenosti saobraaja) se ili odbacuje ili oznaava kao best-effort na ulaznom
interfejsu pristupne domene krajnjeg korisnika A.

Polje rasporeda servisa odreuje vrijeme poetka i zavretka perioda za koji se

e2e usluga prua prema SLA. Potrebno je da zadovolji ogranienja
administrativnog dijela e2e SLA i treba bi biti manji ili jednak e2e SLA periodu
trajanja.

Pouzdanost treba definisati dozvoljeno prosjeno sredstvo zastoja po jedinici

vremena za pruenu uslugu i maksimalno dozvoljenog vremena za popravak (TTR
) u sluaju kvara za pruanje e2e servisa opisanog preko e2e SLA.

3.1. e2e SLA verifikacija

Da bi se izvrio proces verifikacije e2e SLA na osnovu lanca bilateralnih SLA-va,

neophodno je prvo definisati infrastrukturni monitoring. Ovaj infrastrukturni
monitoring bi se treba sastojati od :

Opreme za monitoring smjetene u sredinji poloaj du e2e putanje od

krajnjeg korisnika A do krajnjeg korisnika B (sl. 2 ), pod nazivom oprema za
monitoring (SPME) nadalje.

Opreme za monitoring smjetene u prostorijama svakog krajnjeg korisnika,

pod nazivom monitoring oprema krajnjih korisnika (EME) nadalje .

Kao to je ve objanjeno , bilateralni SLA potpisan izmeu pruaoca usluga imaju

tendenciju da bude dugotrajna pojava prije nego e2e SLA izmeu krajnjih
korisnika. Dakle, postojanje SPME je prije svega bitno za uspostavljanje i praenje
bilateralnih SLA-ova. SPME mora biti smjeten u kritinim pozicijama domena
17

ukljuenih u bilateralnim SLA-ovima, kako bi konstantno nadgledao pruenu

uslugu i ukazivao na mogue uzroke i porijeklo kvarova servisa. Za sluaj
bilateralnog SLA, SPME mora obavezno da postoji na svim interfejsima ukljuenim
u oblasti djelokruga SLA. Na primjer , u sluaju bilateralnog SLA za EF bazirane

Slika 3. Infrastrukturni monitoring za bilateralni SLA

usluge povezivanja izmeu domena 1 i 2 (Slika 3) , SPME treba da postoji na svim

interfejsi A - E , kako bi SLA mogao na pravi nain monitorisati. Za svoje potrebe
ili za potrebe praenja bilateralnih SLA-ova sa upstream domenama, domena 1
na slici 1 moe takoer odabrati da postavi SPME na interfejse A0 i B0. Osim toga
, svaka domena moe izabrati da rasporedi monitoring infrastrukturu u okviru
svoje administrativne granice. Ova infrastruktura , iako nije direktno ukljuena u
postupak monitoringa u bilateralnom SLA-u, moe pomoi u izoliranju
nedostataka u pruanju usluga unutar domena. Ovo e biti posebno korisno kada
monitoring izmeu rubnih interfejsa (npr. A i C ) rezultira krenju garancija unutar
bilateralnog SLA. Pod uslovom da se monitoriu bilateralni SLA du e2e putanje
izmeu dva krajnja korisnika kao to je ve navedeno, tada se garancije kvalitete
svakog pojedinanog bilateralnog SLA stalno prati. Oni se mogu, dakle, koristiti u
e2e SLA procesu uspostave koji je opisan u prethodnim dijelovima, kako bi se
mogle dostii e2e garancije. Meutim , nakon osnivanja e2e SLA, mora se i
krajnjim korisnici pruiti alat (EME) za provjeru kvalitete i koliine protoka usluge.
Zbog prirode e2e SLA , koji su manje trajni od bilateralnih SLA-ova izmeu
domena , EME ne moe biti zasnovana na hardveru i sloenim procedurama.
Stoga , predlae se da krajnji korisnici dobiju skup softverski baziranih, aktivnih
alata za praenje, nazvanih alati za upravljanje softvera (SMT-Software
Management Tools) nadalje, omoguavajui im da posmatraju performanse
pruene usluge u odreenim intervalima. SMT je takoer strogo predloen jer on
ne zahtijeva vrijeme sinhronizacije izmeu opreme krajnjih korisnika i prema
tome je, lagan za upotrebu. SMT-ovi koji se dodjeljuju krajnjim korisnicima moraju

18

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, e

morati 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.

4 . Procedure dodjele servisa

Pruanje DiffServ-baziranih usluga povezanosti izmeu dva krajnja korisnika mora

biti uspostavljeno kroz nekoliko faza, kao to je prikazano na slici 4 . Na poetku,
faza pregovaranja bi trebala razjasniti ukljuene subjekte, svrhu koritenja
pojedinih sevisnih konektivnosti, izvodljivost pruanja usluga , itd. U toku set -up
faze servisa , svi detalji o pruanju usluga moraju da budu prikupljeni , potrebni
SLA / SLS-ovi moraju biti potpisani i detaljne konfiguracije koritene opreme se
moraju izvriti .

19

Slika 4. Faze dostavljanja servisa

U toku faze operacije usluge, nema potrebe da se neke specifine aktivnosti

moraju obavljati ukoliko se ne pojavi indikacija kvara servisa. U tom sluaju,
mjere moraju biti poduzete kako bi se usluga operacije obnovila. Paralelno sa
fazom operacije servisa, trebala bi se odvijati i faza praenje, koja se sastoji od
konstantnog mjerenja aktivnosti s ciljem utvrivanja potrebne kvalitete servisa. U
fazi monitoringa moe se dogoditi da performanse servisa odstupaju od eljenih
performansi. U tom trenutku se pokree faza podeavanja servisa, ukljuujui
podeavanje konfiguracije du puta uspostave servisa. Faza prilagoavanja
servisa uvijek rezultira novom servisnom operacijom i fazom monitoringa, koje se
odvijaju paralelno, sve dok vrijeme pruanja usluge frame-ova istekne i faza
terminiranja servisa pone.

Ovo poglavlje e 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. Sljedei
paragrafi pokuati dati metodologiju ovog pristupa, 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
20

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 scenariom pruanja na slici . 2 , Sl . 5 prikazuje kako
tehniki kontakt

Slika 5. Delegacija autoriteta za proceduru pruanja servisa

(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. Ovi tehniki kontakti trebaju
pripadadi 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 Sl . 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
21

administratorima koji su ukljueni pod njihov autoritet (pogledajte ' 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 svakim TC-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 (vidi sliku. 6).

Slika 6. Hijerarhijska komunikacija tehnikih kontakata ukljuenih u pruanje

servisa

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
22

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
izbjegi direktni kontakt sa SPC-om i komunicirati bilo kakve informacije putem
PEC-a svake strane krajnjeg korisnika.

Slika 7. Ukljueni entiteti u pruanju SLA baziranog servisa

23

5. Zakljuak
SLA specifikacija za DiffServ mree ima za cilj osigurati kompatibilnost pruenih
usluga preko uzastopnih domena, pruanje zadovoljavajuih kvaliteta usluge i
postavljanje granica pruenim uslugama. Takvi SLA-ovi se kreu korak naprijed u
odnosu na ve koritena rijeenja, u smislu da oni ne moraju da specificiraju
samo dostupnost, sigurnost, koliinu dodijeljenih sredstava i niz drugih
kvantitativnih vrijednosti, ve moraju i navesti vrijednosti odgovarajuih
parametara kvalitete. U IP mreama, gdje best-effort saobraaj nema garanciju
kvaliteta, uvoenje kvalitetnih usluga zahtjeva temeljit i precizan inenjering QoS
metrika u SLA specifikaciji. U ovom radu je definisan framework za uspostavljanje
bilateralnog SLA-a prema principima DiffServ bazirane usluge rezervisanja.
Predloeni administrativni i SLS dijelovi SLA su detaljno predstavljeni, u
nastojanju da obuhvate sve tehnike parametre zahtjevane u rezervisanju usluga
s kvalitativnim garancijama. Na temelju bilateralne SLA specifikacije, predloena
je metodologija za uspostavu e2e SLA te je opisana koordinacija subjekata
ukljuenih u uspostavu SLA e2e. Iako ovaj rad ini korak prema definiciji
strukturiranih i detaljnih SLA-ova za rezervisanja garancija QoS-a u IP mreama,
jo rada je potrebno kako bi DiffServ bazirani SLA-ovi postali potpuno funkcionalni
i efikasni, i na taj nain inili korisne alate za administratore mrea i operatere.
Jo jedan izazovan dio je da se osmisle mehanizmi i procedure za identifikaciju i
kontrolu prekraja unaprijed definiranih SLA-ova, za ponovno pregovaranje i
pricing SLA-ova, ukljuujui i mehanizme kompenzacije u sluaju kvarova. Takva
pitanja nisu obraena u ovom radu ali e biti dio budueg rada na SLA-ovima za
QoS omoguene IP mree .

24

6. Liter atura

[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 EFbased 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.

25

[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.
[13] Teitelbaum B, Shalunov S. Why premium IP service has not deployed (and
probably never will) Internet2 QoS Working Group Informational Document, May 3
2002
found
at:
http://mail.internet2.edu:8080/guest/archives/qbone-archdt/log200205/msg00000.html.
[14] Verma D. Supporting service level agreements on IP networks. USA: McMillan
Technical Publishing; 1999.

26