Embed Size (px)
Citation preview
TALLINNA TEHNIKAÜLIKOOL
Raadio- ja sidetehnika instituut
Telekommunikatsiooni õppetool
Kood: IRT70LT
TEENUSEKVALITEETI TAGAV PAKETTSIDEVÕRK
Rainer Aus
Töö on tehtud telekommunikatsiooni õppetooli juures
Juhendaja Avo Ots
Konsultant võrguarhitekt Marko Veelma
Kaitsmine toimub raadio- ja sidetehnika instituudi kaitsmiskomisjonis
Autor taotleb tehnikateaduse magistri kraadi
Esitatud: 21.05.2010
Kaitsmine: 27.05.2010
Tallinn 2010
2
ReferaatMagistritöö teemal “Teenusekvaliteeti tagav pakettsidevõrk” käsitleb kvaliteedigarantiide
pakkumisega seonduvat problemaatikat pakettkommuteeritud võrgus, vastandades
„parimal võimalikul viisil“ edastuse võimalusi tänaste tarbijate ning teenusepakkujate
poolsete vajadustega.
Töö eesmärgiks on leida paindlik lahendus diferentseeritud teenusekvaliteedi tagamiseks
pakettkommuteeritud võrgutopoloogial. Selleks analüüsitakse IP protokolli tehnoloogilisi
võimalusi kombineerituna klassikalisi IP teenuseid pärssivate piirangute ning MPLS-i
poolt pakutavate eelistega. Töö käigus viiakse läbi praktilised laborikatsed, illustreerimaks
töö kestel esitatud seisukohti ja kontrollimaks nende paikapidavust. MPLS tehnoloogia
võimaluste rakendamine osutub sobivaks lahenduseks.
Töö on kirjutatud eesti keeles 85 leheküljel ning sisaldab 17 joonist ja 13 tabelit.
Märksõnad: QoS, CoS , IP, DSCP, MPLS, RSVP, DiffServ
3
AbstractThe master thesis “QoS guarantees in packet network” concentrates on the prerequisites
for providing guaranteed quality services in packet-switched networks, contrasting the
features of legacy „best-effort“ approach to the requirements of today's subscribers and
service providers.
Goal of the research is to verify a scalable technological solution, fit for providing
differentiated quality services on a packet-switched network topology. Proposal is based
on an analysis combining technical capabilities of legacy technology, limitations of native
IP services and advantages offered by MPLS. Practical lab tests were conducted in order to
verify and illustrate the statements and principles brought up throughout the thesis. As a
result, implementation of MPLS as the next generation technology is considered suitable.
Thesis is written in Estonian and consists of 85 pages, including 17 figures and 13 tables.
Keywords: QoS, CoS , IP, DSCP, MPLS, RSVP, DiffServ
4
EessõnaInternetikasutajate ootused neile võimaldatava ribalaiuse ja andmesidele pakutavate
garantiide osas on kirjeldatavad ajas kasvava funktsiooni abil. Teenusepakkujatele
tähendab see vastupidiselt kasutatava infrastruktuuri täitumist ning pakutava teenuse
kvaliteedinäitajate suurema tõenäosusega halvenemist. Tõstatub küsimus: kuidas seda
olukorda teenusepakkuja jaoks kõige tõhusamalt lahendada? Valikuid on ju mitmeid:
„loopida probleemi ribalaiusega“, rakendada ammu tuntud liikluse diferentseerimise
võtteid, leida lahendus uute tehnoloogiate juurutamisest. Meetodi tõhususe hindamise
peamiseks aluseks on täiendav ressursikulu probleemi lahendamisele ning tulemuses
kajastuv kasutegur. Seniste lähenemiste ebapiisavusest annab mõista nende
piirsituatsioonides ilmnev eelis.
Käesolevas töös uuritakse alternatiivseid lähenemisi teenusekvaliteedi tagatavuse
parandamiseks. Hüpoteesiks on, et IP, iganenud tehnoloogiana, ei suuda täita
multiteenusvõrgu alustehnoloogiale esitatavaid nõudmisi. Töö käigus otsitakse vastuseid
küsimustele, kuidas avaldub teenuste kvalitatiivse diferentseerimise puhul teenusepakkuja
jaoks lisaväärtus ning mil viisil on omavahel seotud teenuse kvaliteet ning infrastruktuuri
kuluefektiivsus. Vastuste leidmiseks analüüsitakse pakettside toimivust pärssivaid tegureid
ning võimalusi nende mõju minimeerimiseks, väljundeid klassikaliste IP-teenuste näitel
teenusekvaliteedi tagamiseks ning jõutakse tulemusena uue põlvkonna pakettsidevõrgule
esitatavate nõuete sätestamiseni. Hüpoteesi tõestamise käigus rajanetakse nii erinevate
autorite seisukohtadele kui ka töö käigus läbi viidud katsete tulemustele.
Teema valik lähtus autori soovist omandada parem tunnetus küllalt aktuaalsete pakettside
valdkondade problemaatikas. Sügavam huvi teenusekvaliteedi tagamise ja MPLS-iga
seonduva vastu on suures osas tingitud autori töistest kokkupuudetest IP-võrgundusega.
Toe, nõuannete ja tagasiside eest töö koostamise käigus tahan sügavalt tänada juhendajat
Avo Otsa ning konsultanti ja kolleegi Marko Veelma't. Lisaks avaldan tänu kõigile, kes
selle töö valmimisele nii oma nõu, jõu kui ka kannatlikkusega kaasa aitasid.
Rainer Aus Tallinn, 21.05.2010
5
Sisukord0 Sissejuhatus.......................................................................................................................13
0.1 Töö struktuur..............................................................................................................140.2 Allikakriitika.............................................................................................................15
1 Teenusekvaliteedi põhimõisted.........................................................................................162 Klassikalise pakettside põhiprobleemid............................................................................18
2.1 Viide...........................................................................................................................192.2 Ummistused...............................................................................................................202.3 Liikluse ebaühtlane jaotus..........................................................................................22
3 Teenusekvaliteedi tagamise äriline taust...........................................................................244 Teenused...........................................................................................................................28
4.1 Internetiühendus........................................................................................................294.2 IP transiit ..................................................................................................................294.3 IP-VPN......................................................................................................................304.4 IP multimeediateenused............................................................................................314.5 IP teenused ja QoS – analüüs....................................................................................33
5 Nõuded infrastruktuurile....................................................................................................365.1 Planeerimine ja nõuded.............................................................................................365.2 Teenuste poolt esitatavad nõuded..............................................................................375.3 Teenusepakkuja poolsed funktsionaalsed nõuded.....................................................37
6 Võrgutopoloogia valik......................................................................................................396.2 Skaleeruvus...............................................................................................................396.3 Mahuhaldus...............................................................................................................406.4 Käideldavus...............................................................................................................426.5 Teenusegruppide virtualiseerimine...........................................................................446.7 Võrgusõlmede vaheline signaalimine QoS tagamiseks............................................466.5 Seadmed....................................................................................................................49
7 Praktiline katse: asümmeetrilise varukanaliga võrgusegment..........................................537.1 IP marsruutimine ja DiffServ......................................................................................587.2 Eraldi LSP-d BE ja EF edastusklasside transpordiks (L-LSP)................................637.3 Katsetulemuste analüüs..............................................................................................67
8 Kokkuvõte.........................................................................................................................72Kasutatud kirjandus..............................................................................................................74LISA A – IEEE soovitused CoS väärtuste defineerimiseks [Ernie].....................................77LISA B – ülevaade IP paketi päise ToS väljast [Ernie, RFC 791]........................................78LISA C – DiffServ'i seos RFC 791-ga [Cisco BTS H-12]..................................................79LISA D – laborikatsetes kasutatud võrgutopoloogia............................................................80LISA E – IP marsuutimise katses kasutatud CoS seadistus.................................................81LISA F – MPLS katses kasutatud MPLS ja CoS seadistus................................................82LISA G – laborikatses kasutatud utiliitide osaline väljund..................................................84LISA H – tcpdump utiliidi väljund MPLS liiklustest..........................................................85
6
Tekstijooniste loeteluJoonis 1. Magistritöö struktuur.............................................................................................14
Joonis 2. Terviklik vaade QoS-le sidevõrkudes [Park lk. 5].................................................16
Joonis 3. Kanali ribalaiuse mõju kanali efektiivsele koormatavusele [Faucheur lk.54].......20
Joonis 4. Ummistuse mõju võrgu läbilaskevõimele [Chao, Guo lk. 8]................................20
Joonis 5. Teenusekvaliteedi kompleksse tagamise eeldused [Lionel, Xiao lk. 17]..............23
Joonis 6. QoS ja ARPU seos ärikliente huvitavate rakenduste lõikes [Odinma lk. 11].......25
Joonis 7. Infrastruktuuri arenduskulud ajas..........................................................................26
Joonis 8. Teenuste seostamine PHB-dega tuumikvõrku sisenemisel [Faucheur lk. 341]....34
Joonis 9. Võrdlev näide LSP-de hierarhilise ülesehituse eelistest [Minei, Lucek lk. 33].....39
Joonis 10. QoS parameetrid protokollipäistes [Ernie].........................................................47
Joonis 11. QoS signaalimine protokollide kombineeritud vahendeid kasutades.................47
Joonis 12. Laborikatses kasutatav võrgutopoloogia.............................................................54
Joonis 13. IP protokollil rajaneva katse põhimõtteskeem.....................................................59
Joonis 14. L-LSP katse põhimõtteskeem..............................................................................64
Joonis 15. DiffServ'i mõju viitele rakenduskihil...................................................................67
Joonis 16. Hilistuse erinevus IP ja MPLS kasutusjuhtudes..................................................68
Joonis 17. Erinevate tegurite mõju paketikaole avariist taastumisel....................................69
7
Tabelite loeteluTabel 1. Võimalused võrguliidese ribalaiuse käitlusklassiti jaotamiseks............................47
Tabel 2. Näitlik jaotus teenuste virtualiseerimiseks..............................................................52
Tabel 3. Näitlik QoS märgistamisskeem...............................................................................55
Tabel 4. Kombineeritud DiffServ'i ja IP marsruutimise kasutusjuhtude ülevaade..............67
Tabel 5. Viide (RTT) mikrosekundites koormamata IP infrastruktuuril...............................68
Tabel 6. Paketikadu 1Gb/s kanali avarii korral 30 Mb/s koormusel.....................................69
Tabel 7. DiffServ'i tulemuslikkus kombineerituna IP marsruutimisega................................70
Tabel 8. DiffServ'i mõju rakenduskihile ping utiliidiga tehtud katse põhjal........................70
Tabel 9. Ülevaade LSP-de võimalikest paigutustest katsetopoloogial ................................72
Tabel 10. Viide (RTT) mikrosekundites koormamata MPLS võrgus...................................73
Tabel 11. MPLS-i poolt pakutavate taastemeetodite tõhusus...............................................74
Tabel 12. DiffServ'i tulemuslikkus kombineerituna MPLS edastusega...............................74
Tabel 13. Hinnang katse tulemustele püstitatud kriteeriumide põhjal..................................76
8
Tähistuste loeteluAE aggregated ethernet
Juniper Networks'i nimetus 802.3ad standardile vastavale ethernet liitliidesele
AF assured forwarding
RFC 2597 raames defineeritud DiffServ PHB missioonikriitilise liikluse jaoks
ARPU average revenue per user
keskmine tulu teenuse kasutaja kohta
AS aggregated SDH
Juniper Networks'i firmaomane tehnoloogia SDH liideste liitmiseks
ASIC application specific integrated circuit
rakendusspetsiifiline integraalskeem
ATM asynchronous transfer mode
asünkroonne sidetehnoloogia
BE best effort
parimal võimalikul viisil edastus
BFD bidirectional forwarding detection
protokoll kanalikihi toimivuse jälgimiseks
BGP border gateway protocol
RFC 4721 raames defineeritud süsteemidevaheline marsruutimisprotokoll
CAC call admission control
ligipääsukontroll
CE customer edge
kliendi võrgusõlme tähistus MPLS võrgus
CLP cell loss priority
kaadri edastusprioriteeti tähistav bitt ATM-i kaadri päises
CoS class of service
IEEE 802.1p standardis defineeritud 3-bitine väli ethernet protokolli päises
CSPF constrained shortest path first
marsruutimisel kasutatav algoritm, leidmaks piirangutele vastav lühim tee
CWDM coarse wavelength division multiplexing
hõreda kanalisammuga optiline sagedustihendus
DA destination address
sihtaadress
DARPA Defense Advanced Research Projects Agency
9
DF default forwarding
RFC 2474 raames loodud DiffServ PHB parimal võimalikul viisil edastuseks
DiffServ differentiated services
RFC 2474 raames defineeritud arhitektuur QoS tagamiseks pakettsidevõrgus
DSCP differentiated services code point
RFC 2474 raames ümber defineeritud ToS väli IP protokolli päises
DWDM dense wavelength division multiplexing
tiheda kanalisammuga optiline sagedustihendus
ECMP equal cost multipath
samaaegselt mitut teed kasutada võimaldav marsruutimisstrateegia
ECN explicit congestion notification
RFC 791 poolt defineeritud ühese otstarbeta bitt IPv4 päise ToS baidis
EF express forwarding PHB
RFC 3246 raames defineeritud DiffServ PHB aegkriitilise liikluse edastuseks
E-LSP EXP-inferred label switched path
ühe LSP-ga on võimalik siduda 8 erineva edastusklassi liiklus
EXP experimental field in MPLS header
3-bitine väärtus MPLS kaadri päises, mis on kasutusel DiffServ signaalimiseks
FCS frame check sequence
datagrammide tervikluse hindamiseks kasutatav veakontroll
FEC forwarding equivalence class
samadel tingimustel (sihtpunkt) edastatav paketivoog
FQ fair queuing
võrdset ressursijaotust võimaldav teenindusalgoritm
FRR fast reroute
MPLS-i poolt võimaldatav ennetav taastemehhanism
FTP file transfer protocol
failiedastusprotokoll
Gb/s gigabitti sekundis
ICMP internet control message protocol
interneti kontrollsõnumiprotokoll
IEEE Institute of Electrical and Electronics Engineers
Elektri- ja Elektroonikainseneride Instituut; maailma suurim erialaühing
IntServ integrated services
RFC 1633 raames defineeritud (tänaseks kehtetu) arhitektuur QoS tagamiseks
10
IP internet protocol
internetiprotokoll
IPT IP transiiditeenus
IPTV IP televisioon
IPv4 internet protocol version 4
IPv6 internet protocol version 6
IP-VPN IP virtual private network
IP virtuaalne privaatvõrk
IS-IS intermediate system to intermediate system
ISO/IEC 10589:2002 standardis defineeritud marsruutimisprotokoll
ITU-T International Telecommunications Union Telecommunications Sector
sidealase standardimisega tegelev institutsioon
kb/s kilobitti sekundis
L3-VPN layer 3 VPN
MPLS-i poolt võimaldatav skaleeruv privaatvõrguteenuste arhitektuur
LDP label distribution protocol
sildijaotusprotokolli tähistav üldmõiste; ka RFC5036 raames sätestatud protokoll
LSP label switched path
virtuaalne tee andmeedastuseks MPLS võrgus
L-LSP label-inferred LSP
lähenemine, mille puhul edastuprioriteet on üks-ühele seoses LSP-ga
Mb/s megabitti sekundis
MPLS multiprotocol label switching
kanalkommutatsiooni eeliseid eviv, madala päisekuluga pakettsidetehnoloogia
ms millisekund
MTU maximum transfer unit
maksimum-ülekandeühik; protokolli poolt suurim koos saadetav andmehulk
OSI open systems interconnect
avatud süsteemide sidumise arhitektuur
OSPF open shortest path first
RFC 2328 raames defineeritud marsruutimisprotokoll
P-router provider router
MPLS tuumikvõrgu sõlm
p2p peer to peer
võrdõigusvõrk, detsentraliseeritud teenusvõrgu kontseptsioon
11
PE-router provider edge router
MPLS tuumikvõrgu piirill asuv sõlm, sidumispunkt muude võrkudega
PHB per hop behaviour
paketile QoS parameetrit alusel kohandatav käitluskontekst
PHP penultimate hop popping
meetod, mis eemaldab MPLS kaadrilt päise enne PE võrgusõlme jõudmist
PPP point to point protocol
protokoll andmeedastuse juhtimiseks kanalikihil
PVC permanent virtual circuit
ATM ja kaadrirelee kooseisus kasutatav püsiva iseloomuga virtuaalne kanal
QoE quality of experience
tajutav kvaliteet
QoS quality of service
teenusekvaliteet; üldisemalt sidevõrgu tõrgeteta töö tagamine
RED random early detection
ummistuskontrolliga teenindusalgoritm
RFC request for comments
kommentaarikutse; internetiga seotud standardite koostamise protsess
RSVP resource reservation protocol
ressursside reserveerimise protokoll IntServ arhitektuuris
RSVP-TE RSVP with traffic engineering extensions
RSVP- põhinev, MPLS võrgus kasutatav ressursside reserveerimisprotokoll
RTCP RTP control protocol
reaalaja-juhtprotokoll, rakenduskihi protokoll RTP edastuse juhtimiseks
RTP realtime transport protocol
reaalaja-transpordiprotokoll multimeediateenuste edastuseks
RTT round-trip time
andmete või signaali sihtpunkti ja tagasi levimise aeg
SA source address
lähteaadress
SDH synchronous digital hierarchy
Euroopas levinud optiline aegtihendusega sidetehnoloogia (vt. SONET)
SLA service level agreement
teenusetasemeleping
12
SMTP simple mail tranfer protocol
lihtne meiliedastusprotokoll
SONET synchronous optical networking
USA -s levinud optiline aegtihendusega sidetehnoloogia (vt. SDH)
SPF shortest path first
lühimat teed eelistav marsruutimisalgoritm
STM synchronous transport module
SDH poolt kasutatav edastusvorming
TCP transport control protocol
ühendusele orienteeritud andmeedastuse protokoll
TDM time-division multiplexing
aegtihendusega sidetehnoloogia üldisem tähistus
ToS type of service
teenustüübi väli IPv4 protokollipäises
TTL time to live
IP paketi eluiga tähistav parameeter protokollipäises
UDP user datagram protocol
ühenduseta andmeedastuse protokoll
VLAN virtual local area network
virtuaalne kohtvõrk
VoD video on demand
nõudevideo
VoIP voice over IP
IP kõneside
VPN virtual private network
virtuaalne privaatvõrk
WDM wavelength division multiplexing
optiline sagedustihendus
WFQ weighted fair queuing
prioritiseerimist võimaldav teenindusalgoritm
WRED weighted random early detection
ummistuskontrolliga prioritiseerimist võimaldav teenindusalgoritm
WWW world wide web
interneti graafiline kasutajakeskkond
13
0 SissejuhatusÜhelt poolt teaduslik-tehnoloogilise progressi ning ning teisalt üha suureneva
tarbijaskonna kasvava infovajaduse läbi on aset leidmas omapärane võidujooks
sideteenuse pakkujate ning tarbijate vahel, suunaga Interneti võimaluste ammendamise
poole. Kurjakuulutaval arenguspiraalil kasvavad tsükliliselt nõudlus täiendava ribalaiuse
ja uute teenuste järele, operaatorid on konkurentsis püsimise nimel järjepidevalt sunnitud
turule tooma uut tüüpi teenuseid ning kaasajastama kasutatavaid infrastruktuure. Kahjuks
käsitletakse seda probleemi tihti liialt ühekülgselt ribalaiusele keskendudes, märkamata
hoopis olulisemat konflikti - Internet on ajalooliselt garantiideta (best-effort)
edastusmeedium, samas põhinevad tänased ja homsed teenused ribalaiusele lisaks
garantiide pakkumisel. Parima võimaliku edastuse olemus muutus piiranguks hetkest, mil
Internetti kolisid interaktiivsust nõudvad teenused nagu videokonverentsid ja kõneside.
Uue lähenemisena operaatorite poolt on lisandunud ka multiteenusvõrgu visioon –
eesmärk koondada seni eraldi püsinud sidetehnoloogiaid ühtsele pakettside
infrastruktuurile kui kuluefektiivsele meediumile. Interneti kontekstis on nende ideede
rakendamise tulemuslikkus siiski pigem soovida jätnud, andes alust arvata, et oleme liialt
takerdunud kehtiva IP-paradigma raamidesse ja peaksime otsima uudsemaid lahendusi.
Tänasel päeval on üheks arvestatavaks kandidaadiks tõusnud tehnoloogia nimega MPLS
(multiprotocol label switching).
Peamine probleem senises QoS praktikas - pärandtehnoloogiate vaates - ongi
mehhanismide reaktiivne mõju. Kasuteguri ilmnemine vaid piirsituatsioonides tähendab, et
tõhusus sõltub ühelt poolt rikete ilmnemise tõenäosusest ning teiselt poolt teenusekvaliteedi
garanteerituse tagamiseks vajaliku haldusressursi hulgast. Seega – mida vähem esineb
probleeme, seda kahjulikum on operaatori jaoks lisakulutuste suunamine infrastruktuuri
haldusesse, samaks jääva tulubaasi toel. Järeldusena on uute tehnoloogiate rakendatavuse
hindamisel väga oluline nende poolt pakutav lisaväärtus.
Käesoleva töö eesmärgiks on kontrollida MPLS-i perspektiivi teenuste kvalitatiivseks
diferentseerimiseks pakettsidevõrgus, kõrvutatuna klassikalise pakettsidetehnoloogia
rakendamisel ilmnevate puudustega.
Töö mõistmine eeldab algteadmisi MPLS, IP ja ethernet protokollidel põhinevate võrkude
üldisematest tööpõhimõtetest ja DiffServ arhitektuurist.
14
0.1 Töö struktuur
Ülevaade töö struktuurist annab joonis 1. Esimeses peatükis seletatakse lahti segadust
tekitavalt sarnased lühendid ning teenusekvaliteediga seonduv terminoloogia. Teine
peatükk keskendub pakettside põhiprobleemidele, tuues välja võimalusi nende mõju
leevendamiseks IP-võrgu näitel. Kolmas jaotis selgitab teenuste kvalitatiivse
diferentseerimisega seonduvaid ärilisi tahke ning pakutavaid eeliseid, andes sealhulgas
ülevaate multiteenusvõrguga seonduvast. Neljas peatükk kirjeldab klassikalisi IP teenuseid
ning analüüsib neid kvalitatiivse diferentseerimise vajaduse taustal. Viiendas peatükis
viiakse kokku teenuste omadustest tulenevad ning operaatori poolt esitatavad lisanõuded
sidevõrgule ning ühendatakse need lahendusi pakkuvate tehnoloogiliste võimalusega.
Kuues peatükk käsitleb võtmeaspekte võrgutopoloogia valikul – vastates küsimustele,
kuidas tagada nõutud skaleeruvus, käideldavus, teenustegruppide eraldatus ning lahendada
signaalimine. Lisaks antakse näpunäiteid, mida silmas pidada võrguseadmete valikul.
Seitsmendas peatükis tegeletakse praktilise võrgulahenduse koostamise, laborikatsete
läbiviimise ja tulemuste analüüsiga. Katsetel on mitu eesmärki - praktiliselt näitlikustada
töö käigus esitatud põhimõtteid ning katsetulemuste põhjal leida selgeid eeliseid IP ja
MPLS tehnoloogiate vahendusel diferentseeritud teenusekvaliteedi pakkumises.
Joonis 1. Magistritöö struktuur
15
0.2 Allikakriitika
Autori eesmärgiks oli vältida töös esitatu sisulist kallutatust konkreetse seadmetootja
seisukohtade ja lahenduste poole. Seetõttu on materjalide valikul püütud erinevaid
osapooli kajastada võimalikult võrdseltel alustel - allikatena on kasutatud nii Cisco
Systems'it [Faucheur et al.] kui ka Juniper Networks'i [Minei, Lucek] esindavate autorite
publikatsioone. Materjalide asjakohasuse kinnituseks on ka fakt, et samade autorite
nimed figureerivad paljude temaatikat käsitletavate RFC-de koostajate hulgas - näiteks
RFC 3720 toimetajaks oli F. Le Faucheur. Interneti otsimootorite poolt väljastatud
tulemused märksõnadega seotud otsingutele olid selgelt Cisco Systems'it soosivad.
IEEE artiklite hulgas leidus palju küllalt vanu allikaid (2002 ja varem periood), mis
pakkusid väga spetsiifilisi infokillukesi. Artiklite peamine väärtus oli pilguheit QoS
temaatika omaaegsesse evolutsiooni.
RFC-de ja standardite poole pöördus autor juhtudel kui neid refereerivate autorite poolt
esitatud informatsioon jäi ebaselgeks või ei kattunud.
Väärtuslikuks ressursiks osutus Google'i e-raamatute initsiatiiv, pakkudes peamise
eelisena mugavat võimalust tutvuda laia valiku temaatilise materjaliga (tõsi küll, piiratud
ulatuses) selle sobivuse hindamiseks.
Keeleliselt osutus peamiseks probleemiks tehniliste terminite tõlge. Siin üritas autor
võimaluste piires lähtuda pigem olemasolevast terminoloogiast kui oma keelevaistust.
Mitmel juhul osutus parimaks viisiks vastava võõrkeelse lühendi kasutamine – näiteks
MPLS. Võrguliideste kombineerimist loogiliseks liideseks tähistav termin aggregation
tõlgiti kui liitmine. LSP-de prioritiseerimisega seonduvad setup ning hold priority tõlgiti
vastavalt rajamis- ja hoideprioriteedina. MPLS-i poolt võimaldatav aegtihendatud kanalite
emuleerimine üle pakettsidevõrgu nimetusega pseudowire, tõlge, pseudotraat on üle võetud
Eesti sidevaldkonna praktilisest diskursusest (allikas: Rivo Nurges). Terminile metric oli
E. Laaneoksa poolt soovitatud tõlge meetrika, autor soovitab selle asendada terminiga
meetrik. Põhjendus: -a sõnalõpp on segadust tekitav, viidates tavaliselt kesksoost nimisõna
mitmusele ladina keeles. Termini proprietary vasteks sai firmaomane [Laaneoks].
Ühekülgse käsitluse vältimine oli kindel eesmärk ka laborikatses, kus hoolimata
võimalusest kasutada sama tootja lahendusi, leidsid võrdselt rakendust nii Cisco Systems'i
kui Juniper Networks'i võrguseadmed.
Käesoleva töö koostamisel (v.a. laboriseadmed) on kasutatud eranditult avatud
lähtekoodiga tarkvara.
16
1 Teenusekvaliteedi põhimõistedTeenusekvaliteedi mõiste on väga lai, isegi sidevõrkude kontekstis eksisteerib mitmeid
definitsioone:
1. „Kogum teenusespetsiifilisi nõudeid, mida ühendust või voogu transportiv võrk
peab järgima; teenuse toimivuse mõju, mis peegeldub teenuse kasutaja rahulolu
määras.“ [Fineberg lk. 4]
2. „Võimekus juhtida võrguliiklust suunavaid mehhanisme viisil, mis tagab võrgus
opereerivate rakenduste ja kasutajate poolt seatud nõuete täitmise“. [Fineberg lk. 4.]
3. ITU-T standard X.902 pakub järgneva määratuse: Ühe või enama objekti
koostoimele kehtivate kvaliteedinõuete hulk. (A set of quality requirements on the
collective behavior of one or more objects) [X.902 lk. 10]
Lühidalt – võrguteenuse kvaliteeti saab vaadelda mitmest aspektist: teenuse kasutaja tajule
või teenust pakkuva võrgu talitlusparameetritele tuginedes. Ilmeka tervikvaate kasutaja ja
tehnilise tasandi seostamiseks pakub välja Park (vt. joonis 2).
Sidemaailm on kurikuulus käibel olevate tehniliste lühendite arvukuse osas, mida
kontekstivälise homonüümsuse tõttu valitseb pidev oht omavahel segi ajada.
Teenusekvaliteedi temaatika pole selles osas mingi erand ja järgnevalt tuuaksegi välja
Joonis 2. Terviklik vaade QoS-le sidevõrkudes [Park lk. 5]
17
põhiliste lühendite tutvustus antud töö kontekstis:
• QoS (Quality of Service) – üldine teenusekvaliteedi tagatavust iseloomustav
termin. Käesolevas töös tähistatakse terminiga QoS üldisemalt sidevõrgu tõrgeteta
töö tagamist, seda võimaldavatele võrgu kontrollmehhanismidele viidatakse kui
teenusekvaliteedi tagamise mehhanismidele.
• QoE (Quality of Experience) – teenuse kasutaja poolselt tajutav kvaliteet;
• CoS (Class of Service) – IEEE 802.1p standardis defineeritud 3-bitine väli
ethernet protokolli päises, mille väärtus tähistab kaadri edastusprioriteeti
kanalikihil. Standard sisaldab lisaks soovitust liikluse tüüpide ja edastusprioriteetide
sidumiseks. Soovitus liigendati hiljem IEEE 802.1Q standardi raames ümber,
tagamaks ühilduvus DiffServ'i ja DSCP parameetritega IP protokollis. (vt. lisa A).
Side praktilises diskursuses on just see lühend (osalt ka seadmetootjate poolse
kasutuse, kuid peamiselt ikkagi oma mugavama foneetilise kuju tõttu) kujunenud
termini QoS tehniliseks sünonüümiks;
• ToS (Type of Service) – teenustetüüp. RFC 791 poolt defineeritud 8-bitine (6
tähenduslikku ja 2 hilisemaks kasutuseks reserveeritud bitti) väli IP protokolli
päises, mis võimaldab paketiga siduda tema edastusele kehtivad nõuded kahes
osas: 3 bitiga märgitakse paketi suhteline olulisus (precedence) ning 3 bitiga
täiendavad juhtparameetrid (vt. lisa B). Alates 1998 aastast asustab ToS välja
mõnevõrra paindlikum DSCP (Differentiated Services Code Point) konstruktsioon;
• DSCP – diferentseeritud teenuste koodipunkt. Ühtlustamaks RFC 791 poolt välja
pakutud lähenemist, reformiti ToS baiti RFC 2474 raames, kaasates ühe kolmest
selle ajani üksikparameetrina kasutatud bitist samuti paketi edastusklassi
määratlusse.
Ülevaade ToS ja DSCP väärtustest ning nende seostest on esitatud lisas C.
Lihtsustatult võiks QoS-i käesolevas käsitluses sõnastada järgnevalt: võrgu toimivuse
parendamine täiendava ribalaiuse lisamiseta [Laaneoks lk. 144].
18
2 Klassikalise pakettside põhiprobleemidKlassikalise pakettside all peetakse siin ja edaspidi silmas IP-protokollil toimivat
sidevõrku. Pakettkommutatsiooni väljatöötamise ja rakendamise olulisemateks
insenertehnoloogilisteks eesmärkideks olid ületada elektroonika vähesest jõudlusest
tingitud piiranguid ja (peamiselt sõjatööstuse jaoks atraktiivne siht) parandada sidevõrkude
topoloogilist töökindlust. Kui aga tehnoloogia leidis lõpuks väärilise niši hoopis
ootamatus vormis ning plahvatusliku arengu tulemusena lisandus üha uusi ja uusi
väljundeid, hakkasid need moderniseeruvate vajaduste foonil esile tooma arenduse
algeesmärkides ettenägematuid kitsaskohti ja vaibuma esialgne võidurõõm. Leiti, et kuna
tegu on ikkagi „parima võimaliku edastusega“, on tõenäosus, et informatsioon üldse
allikast tarbijani jõuab, seda väiksem, mida enam on süsteemis lülisid – võrgusõlmi,
kanaleid, samaaegseid teenuse kasutajaid. Viimaste arvukuse suurenedes tõusevad nii
rikete kui ka nõudluse poolt põhjustatud ülekoormuse esinemise tõenäosused. Seega on
Interneti ressurssidele tugineva interaktiivse rakenduse (videokonverents, IP-kõneside)
kasutaja jaoks olukord halvemgi kui empiirilisele kogemuse põhjal eeldada võiks.
Klassikalise pakettkommutatsiooni probleemide hulka kuuluvad:
• pakettide viiteaegade erinevus sama tee läbimisel,
• pakettide muutunud järjestus sihtkohta jõudmisel,
• ummistuste oht võrgusõlmedes liiklusmahtude järskude muutuste korral,
• topoloogiamuutuste (rikked) mõju ennustamatus võrgu stabiilsusele,
• a priori määratamatus paketi tee valikul läbi võrgusõlmede.
Ülalmainitud probleemidele võib välja pakkuda lahendusi lihtsamast keerukaimani:
• viiteaja kõikumist lõpp-punktide vahel on võimalik kompenseerida rakenduskihil
informatsiooni puhverdamisega vastuvõtjas [Laaneoks lk. 145],
• pakettide järjestuse ja info komplekteerimise eest sihtkohta jõudmisel hoolitseb
kõrgema kihi protokoll (TCP, RTCP).
Kuidas aga toime tulla summaarse hilistuse, ummistuste ja topoloogiamuutustega
kaasnevate infokadudega?
19
2.1 Viide
Vaadeldes viite võimalikke põhjuseid pakettsidevõrgus, näeme, et summaarse viite annavad
kokku kolm tegurit:
1. levihilistus (propagation delay) füüsilises lainejuhis,
2. saateviide (serialization delay) – aeg, mis kulub võrguliidesel informatsiooni
tükeldamiseks pakettidesse, eelnevalt kanalisse edastamisele,
3. puhverdamisest tingitud viide marsruuterites ning kommutaatorites.
Esimeses ja teises punktis põrkume füüsikalistele piirangutele, mis on konkreetse kanali
puhul konstantsed. Levihilistus sõltub peamiselt kasutatava meediumi omadustest,
saateviide oleneb võrguliidese bitikiirusest (1500-baidise paketi saateviide 64 kb/s
edastuskiirusel on 187 millisekundit ja 10 Gb/s kanalis 1,7 mikrosekundit) [Faucheur lk.
50] . See jätab ainsaks muutujaks puhverdamisviite. Puhverdamine muutub vajalikuks
juhul kui liidesele suunatud andmevoo(gude) ribalaius läheneb liidese edastuskiirusele.
Paketi või kaadri puhverdamine võrguseadmes saab toimuda vaid eelnevalt selle
väljasaatmisele – seega, et oleks pakette, mida puhverdada, peab võrguseade need paketid
eelnevalt kas vastu võtma või tekitama. Kui paketid saabuvad liidese saatepuhvisse
jätkuvalt kiiremini kui puhvris olevat infot välja saadetakse, tekib lõpuks ületäitumine ja
andmed, mis puhvrisse ei mahu, liigutatakse vastavalt käitlusloogikale edasi madalama
klassi puhvrisse või kuuluvad eiramisele (discard). Käsitledes võrguliidese läbilaskevõimet
väljundisse lisanduva liikluse ja kanali ribalaiuse keskmistatud suhtena (puhvrisse
sisenevate ja sealt väljuvate andmevoogude ribalaiused), jõuame järgnevate
seaduspäradeni (vt. joonis 3, lk. 20)
• suhe on suurem kui 1 – puhvrit täitev andmevoog on kiirem tühjendavast. Ilmneb
paratamatu ületäitumine ja andmekadu – tajutav teenusekvaliteet ei ole rahuldav,
• suhe on väiksem kui 1 - puhvri täituvus on madal ja teenusekvaliteet hea,
• suhe läheneb 1-le - puhvri täituvus kasvab ja teenusekvaliteet langeb.
[Faucheur lk. 54]
Eelneva põhjal eksisteerib viite vähendamiseks kolm võimalust:
• kasutada geograafiliselt lühimat teed/meediumi,
• kasutada võimalikult kõrge bitikiirusega võrguliideseid ja edastuskanaleid,
• metoodiliselt minimeerida väljundpuhvri täituvust.
20
2.2 Ummistused
Ummistus tekib võrgus edastatava liiklusmahu kasvul piirini, kus võrk ei suuda
garanteerida lisanduva liikluse transporti. Süsteemi läbilaskevõime kahaneb ja kasvab
liikluse edastusviide (vt. joonis 4). Ummistuse poolt põhjustatud häired ei mõjuta ainuüksi
lõppkasutajaid vaid võivad läbi taassünkroniseerumise mehhanismi sekkuda ka operaatori
Joonis 3. Kanali ribalaiuse mõju kanali efektiivsele koormatavusele [Faucheur lk.54]
Joonis 4. Ummistuse mõju võrgu läbilaskevõimele [Chao, Guo lk. 8]
21
tuumikvõrgu töösse. TCP reaktsioon kandub üle kõrgematesse OSI kihtidesse, mõjutades
marsruutimisprotokollide tööd. Kanali täituvuse tõustes kriitilise piirini ilmneb paketikadu
- kui samas kanalis liiguvad ka haldusprotokollide paketid, tekib olukord, kus ummistusest
tuleneva paketikao tingimustes juhtprotokolli seanss katkeb ning tänu haldusinfo
puudumisele liikluse maht kanalis väheneb. Languse mõjul kanal stabiliseerub, juhtseanss
taastub ja situatsioon kordub. TCP protokolli resünkroniseerumine toimub sellises
olukorras sekundaarefektina. Kirjeldatud liikluse järellainetus mõjub võrgu stabiilsusele
nõrgestavalt ning tuleb isoleerida kas liikluse ümbersuunamise teel või välistada
võimalusena juba võrguhalduse loogika planeerimisel. Praktikas on sellisele võnkumise
olukorrale tihti eelistatud ebastabiilse kanali täielik seiskamine. Ummistust võrgus ei saa
vaadelda abstraktselt ühe võrgusõlme või kanali põhjal, vaid tuleb analüüsida kogu
topoloogia taustal. Lihtsustatult on ummistus tingitud võrguressursi ebapiisavusest, mis
omakorda võib olla sümptomiks erinevatele probleemidele [Gibson lk. 3] :
• liiklusmahu erakorraline ebaühtlane jaotumine võrgus;
◦ statistiliselt ennustamatu nõudluse kasv mingi teenuse järgi ;
◦ rikke tagajärg;
◦ võrguründe tagajärg;
• üldine võrguressursi (kanalite või võrgusõlmede läbilaskevõime) nappus.
Viimasel juhul on ainsaks väljapääsuks kas puuduliku ressursi täiendamine või liikluse
mahu vähendamine.
Ebaühtlaselt jaotunud liiklusmahtudega toimetulekuks tuleb leida meede vastavalt
olukorrale. On selge, et võrgu ideaalne disain liiasusega, kus iga kanali ja võrgusõlme
läbilase oleks igal ajahetkel sobitatud kogu võrku läbiva liikluse ribalaiusega, pole meie
lõplike ressurssidega maailmas lihtsalt võimalik. Samuti ei saa eeldada, et liiklusmahud
võrgusõlmede vahel on ühtlase jaotusega, võimaldades sel viisil üksikute võrgusõlmede
ning kanalite näitajate põhjal lineaarselt ennustades kajastada kogu võrgutopoloogia
laiendamise vajadust.
Ummistuse mõju kompenseerimiseks on mitmeid võimalusi:
• piirata võrku lisanduvat liiklust (admission control),
• intelligentne puhverdamine (erinevad RED (random early detection) algoritmid) IP
võrgu sõlmedes, mõjutamaks TCP seansside libiseva akna suurust pakettide
juhusliku eiramisega,
22
• võrguliiklusele prioriteetide seadmine ja missioonikriitilise liikluse
(haldusprotokollide ja reaalajarakenduste poolt tekitatav liiklus) käitlemine
eelisjärjekorras.
On selge, et nende meetmete rakendamisel tuleb leida tasakaal tulemuslikkuse ja reaalsete
võimaluste vahel – reguleerida on mõistlik ikkagi suurima mahuga (mõjuga täituvusele)
liiklusklassi kuuluvat võrguliiklust, samuti peaks võrku lisanduva liikluse piiramine
toimuma edastusklassi põhiselt.
2.3 Liikluse ebaühtlane jaotus
IP-võrgu puhul on kahe lõpp-punkti vahelise liikluse paralleelset jaotumist (eriti
asümmeetrilisi teid mööda) küllalt keeruline saavutada. Arvestades, et võrgusõlme läbiva
liikluse sihiks pole ainult konkreetne võrgusõlm, vaid ka teised selle kaudu ühendatud
sõlmed - käideldav liiklusmaht moodustub termineeritava ja transiitliikluse mahtude
summast. Mahud ja nende jagunemise dikteerib peamiselt tarbijate nõudlus; operaator saab
omalt poolt olukorda mõjutada topoloogia arendamisel nimetatud nõudlust tagasisidena
arvestades. Mõningat leevendust jooksval liiklusvoo optimeerimisel pakub marsruutimis-
protokollide IS-IS ja OSPF koosseisus leiduv ECMP (equal cost multipath) parameeter,
mis võimaldab liiklust jagada lühimate teede vahel. Samas on ECMP tulemusliku
rakendamise eelduseks mitme sellise tee leidumine võrgus. [Lionel, Xiao lk. 15]
Liikluse jaotuse ühtlustamise keerukuse tingib peamiselt sobiva ehituskivi puudumine -
valikuteks on üksik pakett või üksik marsruut, mis tõstavad tänu oma atomaarsusele
halduskeerukust ning omavad vähest mõju ribalaiuse kasutusele võrgus; või siis kogu
liiklus, mis aga enama kui kahe võimaliku tee puhul võrgusõlmede vahel tähendab
ebaefektiivsust võrguressursi rakendamisel.
Mitut teed pidi ühendatud võrgusõlmede puhul lasub otsustus tee valiku üle
võrguhaldusloogikal, mistõttu võib etteheited osalt suunata IP-võrgu traditsioonilisele
juhtprotokollistiku võimekuse aadressil. Arvestades küll teede olemasoluga, ei võimalda
nad oma põhimõttelise ülesehituse tõttu siiski paralleelsete teede poolt pakutava ribalaiuse
paindlikku paralleelkasutust ja valivad parameetrite alusel eelistatud lühima marsruudi
(edaspidi SPF) (shortest path first) - olemus, mis peegeldub selgelt ka terminoloogias
sisalduvas ülivõrdes. Kuna lühimaid teid saab korraga olla ainult üks, lubab see
omakorda järeldada, et topoloogilise graafi ülejäänud servad võrgusõlmede vahel on oma
ribalaiuselt suure tõenäosusega ebaotstarbekalt koormatud.
Väljapääsu pakub siinkohal piirangutel põhinev marsruutimine (constraint-based routing),
23
mis võimaldab marsruuti arvutada mitme parameetri põhjal:
• läbitavate võrgusõlmede arvu (hop count),
• kanalite ribalaiust ning maksumust,
• töökindlust (reliability),
• viidet ja selle varieeruvust (jitter).
Arvutusprotsess on lihtsustatult järgnev – esimese sammuna praagitakse topoloogiast välja
sobimatute parameetritega kanalid, seejärel teostatakse lühima tee leidmise arvutus
Djikstra või Bellmann-Ford'i algoritmi abil juba piiranguid arvestava topoloogilise vaate
põhjal [Lionel, Xiao lk. 16]. MPLS, DiffServ ja piirangutel põhinev marsruutimine
moodustavad komplektse metoodika (vt. joonis 5) teenusekvaliteedi tagamiseks:
• piirangutepõhine marsruutimine välistab paketivoogude jaoks ebasobivad teed,
tagamaks nende vastavus esitatavatele kvaliteedinõuetele,
• MPLS võimaldab sobiva granulaarsusega paketivoogude piirangutele vastavat
edastust,
• MPLS LSP-de loendurid varustavad piirangutepõhist marsruutimist täpse
tagasisidega erinevates punktides võrku siseneva ja sealt väljuva liikluse kohta,
• DiffServ maandab ummistuste ohust tuleneva riski kõrgema edastusprioriteediga
liiklusele.
Joonis 5. Teenusekvaliteedi kompleksse tagamise eeldused [Lionel, Xiao lk. 17]
24
3 Teenusekvaliteedi tagamise äriline taustKäsitledes teenuste kvalitatiivset diferentseerimist, on selle rakendamise esmaseks
eelduseks eristamist vajavate teenuste pakkumise soov. Eksisteerib mitmeid stsenaariume
– peamisena võib välja tuua tõhusama toimimise eesmärgil multiteenuste keskkonna
loomise poole pürgiva operaatori visiooni samale infrastruktuurile koondatud
teenusegruppidest (lõppkasutaja pakettandmeside, VPN, kõneside ja televisioon).
Pakutavad eelised uuele operaatorile oleksid madalam sisenemisbarjäär turule,
infrastruktuuri juba omavale operaatorile aga võimalus kulude optimeerimiseks
eraldiseisvate käitiste (osade) haldusvajaduse minimeerimise näol. Hüpoteesi tõesusele
saame kinnitust, heites pilgu traditsiooniliste, oma toimimises selgelt eristunud
telekommunikatsioonivõrkude sidususes toimunud arengutele. Telefonivõrk on (tänu talle
eripärasele interaktiivsusele) pidanud arenema eraldiseisva tehnoloogilise lahendusena
muust andmesidest - näiteks televisioonist. IP-võrkude areng on toimunud tehnoloogilisel
„laineharjal“, tekkivate võimaluste kiire ärakasutamine selgitab nende klassikalist „kihilist“
aluspõhja – tihendustehnoloogiate, OSI mudeli teise kihi topoloogiate (ATM,
SONET/SDH, ethernet), ning kõneside (PSTN) najal. Kogu seda arengut on järjepidevalt
iseloomustanud üks trend – koondumine igas mõõtmes. Selline tehnoloogiate vaheliste
piiride hägustumine, kihtide liitumine ja tulemusena lõpptarbijateenuste „ümberasumine“
üha lihtsamatel alustel toimivale infrastruktuurile loob selle operaatorile kaheldamatu
majandusliku eelise mastaabisäästu näol:
1. operaatoril kaob vajadus üleval pidada erinevaid kindlale teenusele kinnistatud (ja
seega majanduslikust vaatenurgast piiratud) infrastruktuure,
2. vastukaaluks tekib võimalus universaalsele platvormile suhteliselt lihtsamalt välja
töötada ja lisada uusi teenuseid [Fineberg lk. 4].
Lõpptarbijale suunatud teenuste puhul tuleb tähelepanu pöörata väga olulisele
kvaliteedijuhtimisega seonduvale asjaolule – et teenust oleks üldse võimalik suuremal või
vähemal määral kvaliteetseks pidada, peab selgelt paigas olema taustsüsteem, kus iga
madalama kvaliteediastmega teenus on kõrgema kvaliteediklassi teenuse suhtes kliendi
poolt selgelt tajutavate ja aktsepteeritud piirangutega. Teisisõnu – madalamate
kvaliteedigarantiidega teenus peab ka praktikas olema tuntavalt kehvem, vastasel juhul
puudub kliendil motivatsioon maksta kõrgemat hinda. Selles valdkonnas üheks näiteks
Lucent Technologies'e poolt läbi viidud uuring, mis jõudis tulemuseni, et kvalitatiivne
diferentseerimine on võtmeteguriks teenuselt saadava keskmise tulu tõusul kliendi kohta
25
(ARPU - average revenue per user). Lisaks pingereastati need andmed ärikliente enim
huvitavanud teenusegruppide lõikes vajaliku QoS-i määra ning tulususe alusel [Odinma lk.
11].
Tulemustest (vt. joonis 6) selgub muuhulgas, et kuigi enamus teenusegruppe on nii
käibenäitaja kui QoS nõuete kasvu osas korreleeritud, osutub „mustaks lambaks“ IP-
kõneside, mis esitab kõige kõrgemaid nõudmisi transpordivõrgule, pakkumata samas
ligilähedastki keskmist tulu võrrelduna nõudevideoga. Osalt võinuks uurimus olla veidi
paremini struktureeritud, kuna esitatud tulemuste kategoriseeritusest lähtuvalt on omavahel
ära segatud sisu- ja sideteenused, lisaks kattuvad mõned kategooriad olemuslikult. Näiteks
internetikonverents ühendab endas reeglina nii nõudevideo (1-2-1 video) kui VoIP-i, VoIP
omakorda mitu audiovoogu. Sellest hoolimata annab diagramm küllalt tervikliku ülevaate
erinevate teenustega seonduvatest tuludest, mis omakorda pakub alusandmeid hinnangulise
kulubaasi piiritlemisel.
Kulutuste osas eksisteerib kaks alternatiivi: panustada teenusetaseme garanteerimise
mehhanismide rakendamisele või lihtsalt laiendada alusinfrastruktuuri. Kumbagi
lähenemist ei saa pidada valeks, kuid neil on üks põhimõtteline erinevus, mis seisneb
meetme tulemuslikkuses. Ribalaiuse tõstmine ei paku algseisuga võrreldes mitte mingeid
lisagarantiisid, võimaldades vaid kasvatada pakutavate teenuste kogumahtu. QoS
rakendamisel tekib võrgus garanteeritud edastusparameetritega andmeside näol aga püsiv
Joonis 6. QoS ja ARPU seos ärikliente huvitavate rakenduste lõikes [Odinma lk. 11]
26
eelis, mis lubab klientidele pakkuda oluliselt rangematele kvaliteedinõuetele vastavaid
teenuseid, tagades seega kõrgema tasuvuse [Fineberg lk. 21]. Valiku tegemisel tuleb
loomulikult lähtuda hetke turutrendidest – kas tulusam on pakkuda kvaliteeti või ribalaiust.
Laiendusvõimaluse hindamisel tuleb kriitiliselt arvestada ka mitmete piirangutega, mis ei
pruugi esmasel vaatlusel ilmneda:
• infrastruktuuri geospetsiifika,
• võrgu aluskihtide tehnoloogilised piirangud,
• liiasuse üldine tase võrgus,
• majanduskliima.
Ajaline maksumus on aeg, mis on kasutada laiendamise otsuse hetkest vaba võrguressursi
100% ammendamiseni teenuste lisandumisel ootuspärases tempos. Teisalt on see aeg,
mille võrra on kulutusi edasi lükates võimalik akumuleerida teenuste pakkumisest laekuvat
kapitali. Rahalise maksumuse moodustavad täiendava võrguressursi väljaehitamise
maksumus või alternatiivkulu, mis on põhjustatud viivituse korral müümata jäävatest või
tulevikku nihkuvatest uutest teenustest oodatavast tulust.
Majandusliku aspekti mittelineaarsus saab selgemaks kui valemisse kaasata ülal esitatud
piirangud. Kui laiendamine on nimetatud tingimustel teostatav, on probleem järgmise
tsüklini lahendatud. Mõnel juhul võib otstarbekaks osutuda kulutuste hajusam ajastamine
(vt. joonis 7). Joonisel on punasega tähistatud olukord, kus arendusinvesteeringu eeldusena
võib vajalikuks osutuda täiendav finantsanalüüs.
Järgnevalt mõned näited piirsituatsioonidest. Ulatuslikul territooriumil paikneva
sideinfrastruktuuri laiendamise kulubaas võib järsult kasvada, kuna rajatise:
• aluseks oleva kiudoptilise magistraali füüsiline ressurss on ammendatud - kõik
kiud on kasutusele võetud,
• aluseks olevad seadmed on saavutanud maksimaalse laiendatavuse ja järgmine
Joonis 7. Infrastruktuuri arenduskulud ajas
27
samm oleks topoloogia täies ulatuses dubleerimine,
• aluseks olev tehnoloogia on moraalselt vananenud ja tuleb täies ulatuses välja
vahetada,
• ribalaius on planeerimisvea tõttu jõudnud maksimaalne laiendatavuse piirini, kuid
arendustöö liidestatava tihenduskihi saavutamiseks alles käib,
• seadmete tarkvara ei toeta piisava hulga sidekanalite liitmist (aggregation) (autori
kogemuses pole tänasel päeval midagi ebatavalist kui IP-magistraalvõrgus on
kokku liidetud kuni 256 liiniliidest STM-16),
• võrgu ülesehitus on ajaloolistel põhjustel kihiline ja uuendus ribalaiuseapla
pakettside kihi laiendamiseks eeldab kõigi aluskihtide laiendamist.
Seega - mida ulatuslikum ja kihilisemal alusel on piiranguteni jõudnud võrgutopoloogia,
seda keerulisemaks ja kulukamaks kujunevad esmapilgul lihtsana tunduvad laiendamised
ning äriliselt põhjendatumaks võib osutuda venitamistaktika.
Kokkuvõtlikult – QoS juurutamine pakub sideettevõttele ainest efektiivsemaks
opereerimiseks nii tegevuskulude kokkuhoiu, uute teenuste põhjal tulubaasi kasvatamise
kui ka investeeringute parema ajastamise osas.
28
4 TeenusedTCP/IP varases arengustaadiumis olid võrgurakendused väga täpselt sobitatud võrgu
spetsiifikaga – nad polnud oma liiklussignatuurilt reaalajas interaktiivsed, vaid üksikutel
sõnumitel põhinevad. Näiteks e-post ja veebilehed, mille puhul on kasutaja jaoks teenuse
toimivuse hindamine piisavalt keerukas ülesanne – sest nagu kehtib ka nende paberkandjal
eelkäijate kirjade ja ajalehtedega - pole oluline, millal nad postkasti jõuavad– peaasi, et nad
seal olemas on. Vastupidine on lugu aga televisiooni või telefonikõnega - väikseimgi
katkestus köidab tähelepanu ja tekitab frustratsiooni, kuna infoedastus on häiritud ning
tarbija ei saa oma ootusele mitte vastavat teenust pidada kvaliteetseks.
Majanduslikult on võrgu kasutuse efektiivsus võrdelises seoses teenuste rohkuse, klientide
arvu ja mahutatava võrguliiklusega. Kõige konkreetsem piirang võrrandile on liiklusmahu
osas - 100%-ga infrastruktuuri poolt pakutavast ribalaiusest. Pakettkommutatsiooni
olemusest tulenevalt tekib siin huvitav erand – maht on sõltuvuses liikluse täpsemast
koostisest ning mingites piirides osutub võimalikuks tõsta infrastruktuuri kasutuse määra.
Kui kanalkommuteeritud võrku mahub kindel arv kanaleid, mille hõivatusel loetakse võrk
küllastunuks üksikute kanalite täituvusest olenemata, on pakettside puhul võimalik liikluse
edastusalgoritme ja -parameetreid diferentseerides võrgu tajutavalt tõrgeteta töörežiimi
viia 100%-le koormusele lähemale ilma tavapäraselt ilmneva languseta võrgu
läbilaskevõimes – samale ribalaiusele mahutada rohkem pakette. Teisalt võib sellise
nähtuse võimalikkust pidada hoopis kinnituseks klassikalisele pakettsidevõrgule omasest
ebaefektiivsusest, mis oli seni peitunud traditsiooniliste võrgurakenduste (www, ftp, e-
post) poolt esitatavate madalate nõuete [ITU-T G.1010 lk.4] varju. Nende rakenduste poolt
genereeritava võrguliikluse ajutine iseloom ja ajalise kattuvuse tõenäosus (võimalus, et
kasutajate päringud üksteist blokeeriksid) on madal. Kasutusmustri tihenedes blokeeringu
tõenäosus kasvab, nõudes operaatorilt täiendavaid meetmeid käideldavuse tagamisel.
Kasutajatega liidestumine teenusega on lühidalt järgnev – klient kasutab oma vajaduste
rahuldamiseks rakendusi, mis eeldavad andmeside võimaluse olemasolu. Rakendus
esitab andmesidele eripäraseid nõudmisi. Operaator pakub erinevaid andmesideteenuseid,
mis sisaldavad erinevaid võimalusi ning mille hulgast klient peab valima oma rakenduse
nõuetele vastava. Mida rohkem esitatavad nõuded tavapäraselt pakutavaist erinevad ja
mida missioonikriitilisem on rakendus kliendi jaoks, seda keerukam (suuremate kuludega)
on teenuse pakkumine ning kõrgem teenuse maksumus. Klient ei ole sideteenuse eest
valmis maksma kõrgemat hinda kui rakenduse kasutamine talle tulu toob.
29
Järgnevates alajaotistes antakse lühiülevaade peamistest klassikalise IP võrgu põhjal
pakutavatest teenustest.
4.1 Internetiühendus
Internetiühendus tähendab tarbija ühendamist teenusepakkuja võrku ja kaasnevat
lepingulises mahus ligipääsu Internetis asuvale informatsioonile. Tegu on klassikalise
„parima võimaliku edastuse“ teenusega, kus teenusepakkuja saab reaalselt vastutada vaid
ligipääsu tagamise eest enda poolt kontrollitavale võrguressursile. Väljaspool
teenusepakkuja võrku sõltub kontrolli määr võrkude sidumise viisist. Juriidiliselt
võrdõigusliku sidumise (peering) puhul saab probleemide korral teist osapoolt vaid
informeerida ja loota tähtajatule positiivsele lahendusele. Juhul kui probleem puudutab
populaarset sisuteenust välisvõrgus, on teenusepakkujad tihtipeale sunnitud just kasutajate
survel astuma samme ühenduvuse parandamiseks. Ka hiljem, IP transiidi alajaotises,
näeme, et olulise turuosaga sisuteenuse pakkujad on väga head IP-transiidi müügi-
argumendid.
Kvaliteedi tagamise osas ei ole kasutaja heaks peale andmeside toimivuse ja nõutava
ribalaiuse kasutatavuse tagamise palju rohkem võimalik teha. Internetiühendus on hea
näide üks-mitmele (point to multipoint) teenusest, kus kliendile pakutakse parimal
võimalikul viisil ühenduvust kõigi Internetis asuvate ressurssidega. Eksisteerib küll
võimalus diferentseerida edastustingimusi kõrgematel OSI mudeli kihtidel toimivate
protokollide lõikes, tagamaks neile viimaste omapärast (pakett ja voogedastus - ntx. www/
SMTP vs. VoIP liiklus) lähtuvad edastusnõuded, eesmärgiga parandada kasutaja poolset
taju teenuse kvaliteedist. Näiteks - multimeediavoo paketid saavad kõrgema
edastusprioriteedi osalisteks kui e-post või päringud/vastused veebilehtede kuvamiseks.
Siinkohal on raskendavateks asjaoludeks mõned puhtpraktilised tehnilised küsimused -
kuidas eristada videoklippide vaatamist nõudevideost või videokõnest ning kuidas toimida
p2p-failivahetustarkvara poolt tekitatud liiklusega. Ärilisest vaatenurgast ei ole
internetiühenduse puhul individuaalne teenusekvaliteedi tagamine teostatav (vähemalt
Eesti mastaape arvestades), osutudes suurusjärke kulukamaks kui teenuselt saadav tulu.
4.2 IP transiit
IP transiidi näol on tegu teenusepakkujate tasemel IP võrkude sidumise ja globaalsele
marsruutingutabelile ligipääsu pakkumisega. IP transiidi ostja ise on tavaliselt interneti-
või sisuteenuse pakkuja ja vahetatavat liiklust võib lihtsustatult vaadelda interneti-
30
ühenduste summeeritud liiklusmahuna. Teenus on tehniliselt keerukama ülesehitusega kui
internetiühendus ning eeldab marsruutimisprotokollina BGP (border gateway protocol)
kasutamist. IP transiidi puhul on tavapäraseim situatsioon nn. multikodu (multihoming)
struktuur, kus teenuse tarbija ostab hulgimüügi korras transiitliiklust mitme kõrgema kihi
(tier) üleslülipakkuja käest, saades nii mitu marsruuti (loogiline liiasus) samade
ressurssideni globaalses Internetis. Üleslülide paljusus on oluline mitmel põhjusel: esiteks
tagab see vajaliku füüsilise liiasuse võrgutopoloogias esineda võivate rikete mõju
minimeerimisel, teiseks on igal kõrgema taseme operaatoril omad geograafilised eelised,
mis taanduvad parematele marsruutidele.
IP-transiidi üheks alaliigiks on võrdõiguslikud ja mahutasuta otsesidumised (peering), mis
aga omavad teatavat sisenemisläve – selleks, et bartertehingus osaleda, peaks
pooltevaheline liiklus olema ekvivalentne. Tavaliselt vahetatakse võrdõiguslikul sidumisel
vaid oma võrguga seotud klientide marsruute.
Müügiargumentideks hulgimüügil on eksootilised marsruudid ja populaarsed sisuteenused,
millele kvaliteetsemat (madalama viite või parema töökindlusega) ligipääsu ihkavad
internetiühenduse tarbijad suudavad reeglina oma sideoperaatori samas suunas tegutsema
panna.
Transiidist lähtuvad tavaliselt suured liiklusmahud, mille poolt tekitatud käive mahuühiku
kohta ei ole märkimisväärne (ja järjest langev) ning mis pigem kipuvad globaalsete rikete
korral teenusepakkujate võrke ummistama. Võrrelduna VPN teenustega on transiidiliiklus
keskmiselt madalamate tajutava kvaliteedi nõuete ja tuumikvõrgus tavapäraselt suurima
osakaaluga. Kvalitatiivsest aspektist omab tähtsust just selle osakaalu (peamiselt järsu
tõusu) mõju, mida avariiolukorras viisakalt vähendada tuleb, tagamaks teiste samal
infrastruktuuril käideldavate teenuste lepingujärgne toimivus.
4.3 IP-VPN
IP-VPN on internetiühendustele baseeruvate krüptotunnelitena realiseeritav virtuaalne
privaatvõrk kliendi kohtvõrkude vahel, võimaldamaks turvalist andmesidet üle Interneti.
Harilikult luuakse selliseid konstruktsioone kuluefektiivsuse saavutamiseks ja
administratiivselt peaksid (aga ei pruugi) need paiknema ühe teenusepakkuja võrgu piires,
vältimaks operaatorite vahel vastutuse hajumise võimalust.
VPN-idele on omased kaks peamist topoloogilist ülesehitust – üks-ühele kanalid kõigi
kliendi võrgusõlmede vahel (full mesh). Selline lahendus ei skaleeru eriti hästi kahel
31
põhjusel:
• võrgusõlmede arvu lineaarsel suurenemisel kasvab tunnelite arv eksponentsiaalselt;
• konfidentsiaalsuse tagamiseks krüpteeritud liikluse mahule seab esmajärjekorras
piirid kliendiseadmete arvutusjõudlus, mida topoloogia laiendamisel tuleb liikluse
ühtlase jaotuse eeldusel tõsta kõigis võrgusõlmedes võrdselt.
Teiseks variandiks on tunnelite ühe otspunktina keskse kontsentraatori kasutamine, kuhu
koondatakse kõigist võrgusõlmedest lähtuv liiklus ja kus leiab lisaks aset võrgusõlmede
vaheline marsruutimine. Selline konstruktsioon lihtsustab üldist disaini ja pehmendab
kliendiseadmetele esitatavaid nõudeid, tekitades aga samas vajaduse kõrgendatud
töökindlusega keskseadme järele, võimaldamaks maandada rikke võimalusest tulenevat
operatsiooniriski.
VPN-i puhul tuleb tähelepanu pöörata liikluse jaotuslikule eripärale – fakt, et peamiselt
edastatakse üks-ühele liiklust (ärirakendused, korporatiivsed multimeedia
suhtluskeskkonnad), tähendab, et VPN puhul osutub vajalikuks tagada ühenduvus piiratud
hulga võrgusõlmede vahel. Seda erinevalt best-effort liiklusest, kus on ülekaalus
klassikalisele internetiühendusele omane liikluskonsistents, mille täpsemat jaotust
võimalike sihtpunktide vahel on tänu viimaste rohkusele keerulisem ennustada.
IP-VPN-i peamine puudus ongi tema kvalitatiivne määramatus - kuna teenus toimib lõpp-
punktide vahelise seansina internetis, vahepealsete võrgusõlmede tuge vajamata, puudub
tegelik kontroll teenuse toimivuse üle - ka teenusepakkuja vastutus piirdub sellises
olukorras internetiühendusega seonduvaga. Isegi juhul kui teenuse on komplekteerinud
sideoperaator, puudub tegelikult piisav ülevaade teenuse toimivusest mikrotasandil,
võimaldamaks operaatoril poolselt hinnata mõjusid teenusekvaliteedile igapäevaste
võrguhaldusoperatsioonide teostamisel, marsruutimispoliitika muudatustes või sidumistes
partnerite võrkudega. Nagu näha, peitub IP-VPN teenuses eriti ränk ootuste konflikt –
teenus, millelt eeldatakse garantiisid ja millel on ettevõtete jaoks tihtipeale eluline tähtsus,
osutub paradoksaalsel kombel parimal võimalikul viisil realiseerituks üle parimal
võimalikul viisil toimiva meediumi, mille sidumispunktid pole tihtipeale kaetud
operaatorite vaheliste kvaliteedilepetega.
4.4 IP multimeediateenused
1990-ndate teise pooleni oli multimeedia kolimist Internetti pärssinud peamiselt vähene
pakutav ribalaius - seda nii terminalide kui ka sidevõrkude üldise võimekuse osas.
Multimeedia oli oma interaktiivsusest tulenevate rangete nõuetega ribalaiusele ning
32
stabiilsele viitele pigem rendikanalite pärusmaa – nagu ka klassikaline telefoniside.
Tänasel päeval on multimeedia internetiseerumise etapp edukalt läbitud ning näha, et
esialgne umbusk „parima võimaliku tulemuse“ lähenemise mõjusse missioonikriitiliste
rakenduste tööle oli mõnevõrra ülepaisutatud. Sellest annab täna tunnistust ka
akronüümide VoIP (Voice over IP) ja IPTV (IP television) erakordselt lai kõlapind.
Progressi ilmingud tingivad omakorda vajadusi uuteks arenguteks - lisaks interaktiivsetele
teenustele on Internetis ootamatult jõudsalt kanda kinnitanud ka laiatarbemultimeedia,
muutes oluliselt käideldavate andmemahtude kasvades nõudeid sidevõrkude poolt
pakutavatele võimalustele – peamiselt pakutava ribalaiuse kontekstis. Ehkki uuenevad
tehnoloogilised võimalused aitavad vähendada üksikute meediavoogude ribalaiust,
suurenevad liigutatavad andmemahud järjest ning tekitatav võrguliiklus oma
kasvuproportsiooniga (kasutaja kohta) ähvardab teenusepakkujaid erakordselt suure
summaarse liiklusmahu näol. Kirjeldatud olukord loob mõistetavatel põhjustel ka
soodumuse blokeeringute ilmnemise tõenäosuse kasvuks Internetis.
Operaatori vaatenurgast võiks olukorda kirjeldada järgnevalt:
• laiatarbe-multimeedia lähtub sisuteenuste pakkujatelt,
• interaktiivne multimeedia seondub suhtluskeskkondadega,
• äriliselt on multimeedia valdkonnaga seonduvad huvipakkuvamad rakendused IP-
kõneside (VoIP – voice over IP) ja nõudevideo (VoD -video on demand).
IP-kõneside osas tuleb olukorda vaadelda laiemalt - korrigeerimaks levinud väärarusaama,
et VoIP tähendab olukorda, kus Interneti vahendusel on lahendatud üksikabonendi
kõneside. Teenuste koondumisest tõusva sünergia peamiseks eeliseks ongi võimalikuks
osutuv paindlikkus. IP protokolli kasutamine võib aset leida nii kliendi ja keskjaama või
siis hoopis PSTN telefonivõrgu keskjaamade sidumisel. Küsimus seisneb vaid vajalikus
ribalaiuse kättesaadavuses ja maksumuses. Milline meedium seda ribalaiust pakub, on
sekundaarne. Pakettside kasutamine pakub klassikaliste kanalkommuteeritud süsteemidega
võrrelduna märkimisväärset paindlikkust – suurema hulga võimalike kanalite, liideste
struktuurist tulenevate piirangute puudumise (E-carrier hierarhia vs. ethernet) ja suhteliselt
madalamate kulude (liidese maksumus, rendikanalite maksumus, klassikaliste ärimudelite
hierarhia vältimine) osas.
VoIP ja IPTV on oma nõuetelt infrastruktuurile väga erinevad teenused. Kui telefoniside
puhul on tegu dupleksse, interaktiivse, vähese ribalaiuse vajaduse ning keskmiselt madala
33
seansikestusega sidelahendusega kahe või enama abonendi vahel, on televisioon pidev,
ühesuunaline ja ribalaiuseahne simpleks- või asümmeetriline duplekssüsteem. See eripära
kajastub kõige paremini võrguliikluses – videovoo peamiselt ühesuunaline liiklus tekitab
olukorra, kus sümmeetrilisele koormusele arvestatud infrastruktuuri tabav ebaefektiivsus
ilmneb suuniti liikluse tasakaalu vähenemises. Et tarbijalt lähtuv võrguliiklus on igal
juhul asümmeetrilise iseloomuga, allalüli kasuks, kasvab sellise teenuse pakkumisel allalüli
koormatus veelgi. Operaatori seisukohalt tuleb seda eripära võrgu disainis kindlasti
arvestada, minimeerimaks mõju tuumikvõrgu ressursi ebaefektiivsele kasutamisele.
Võrguliikluse juhtimisel ja kvalitatiivsel diferentseerimisel on äriliselt määravaks teguriks
kahtlemata asjaolu, kas ja kuidas üks või teine protokoll teenusepakkuja huve esindab või
neile vastandub – näiteks sisuteenuste (VoIP või VoD) pakkujad ei pruugi olla sõbralikult
meelestatud sellise teenuse asenduskauba (näiteks Skype) vaba leviku suhtes.
4.5 IP teenused ja QoS – analüüs
Eelnevates jaotistes kirjeldatud probleemid iseloomustavad ilmekalt olukorda „parima
võimaliku edastuse“ tänasest ebapiisavusest. Kui keerukamate kasutusjuhtude alusena
võis vaadelda lihtsat ühenduvust Internetiga, mille puhul kvalitatiivne diferentseerimine ei
osutuks majanduslikult mõistlikuks, kanduvad need puudused võimendudes edasi ka
kõigisse internetiühendusele rajatud pealiskihtidesse – näiteks IP VPN. Seda ilmingut võib
lugeda üheks kinnituseks senise IP paradigma ebapiisavusest.
Teenuste vaatlusel jõudsime järgnevate põhiliste järeldusteni:
• „parimal võimalikul viisil“ edastus osutub enamikul kasutusjuhtudest piisavaks,
• IP teenuste ärimudelis puudub soodumus edastusgarantiide pakkumiseks,
• edastusgarantiide puudumine või vähesus väljendub teenuse (äri)kliendi jaoks
ärilises riskis,
• multimeediateenuste puhul on oluline tagada interaktiivsuse nõude täitmine.
Neid aspekte silmas pidades saab sõnastada operaatori poolse tegevusplaani – leides
võimaluse piiratud määral edastusgarantiide pakkumiseks, saavad lahendatud nii äriliste
riskide maandamise kui ka nii vajaliku interaktiivsuse küsimus. Oluline on eristada
missiooni- ning aegkriitilisi teenuseid – haldusinfo puhul on oluline vaid see, et teave
jõuaks kindlasti sihtpunkti. Aegkriitilisus multimeedia näitel lisab täiendava ajalise
piirangu.
34
Teenuste paketeerimise üheks võimaluseks on liigitada teenused juurdepääsu- (IPT ja
internetiühendus) ja privaatvõrguteenusteks (VPN, multimeedia) sõltuvalt
kvaliteedikriteeriumidest:
• kõrgklassi teenus – garanteeritud (minimaalne ja muutumatu) viide ning edastus;
• tagatud teenus – garanteeritud edastus, viide võib väikestes piirides varieeruda;
• „parim võimalik“ teenus – tavapärane internetiühendus.
Siinkohal ei tohi aga segi ajada teenuseid ja DiffServ'i PHB-sid (vt. joonis 8). Võrgu
ühtlase koormuse kavandamiseks peab iga selline diferentseeritud kvaliteediga teenuse
kompleks sisaldama erinevates vahekordades erinevate kvaliteediklasside liiklust – kas
protsendina kliendile pakutavast ribalaiusest, fikseeritud andmemahuna või nõudepõhiselt
arveldusperioodi lõikes. Selline lähenemine on operaatori seisukohalt kindlasti kaalukam
tehniline väljakutse just lepinguvälise liikluse paindliku käsitluse osas, nõudes täiendavat
arveldusloogikat dünaamilise teenusetaseme pakkumiseks. Tavapäraselt realiseeritakse
selliselt liigendatud teenusepaketid nn. olümpiateenuste loogikat kasutades – defineerides
eri parameetritega (kuld, hõbe, pronks) teenused, mis sisaldavad erinevates osakaaludes
diferentseeritud edastusklasside kasutamise võimalust. Pakkudes privaatvõrguteenustele
teistest rangemaid kvaliteedigarantiisid, tuleb tagada ka nimetatud teenuste kõrgema
prioriteediga käitlus tehnoloogilisel tasandil. Reastades eelnevalt kirjeldatud teenused
Joonis 8. Teenuste seostamine PHB-dega tuumikvõrku sisenemisel [Faucheur lk. 341]
35
nende tehnilisest eripäradest tuleneva prioriteetsuse alusel:
1. Multimeediateenused, mille puhul on fikseeritud viide ning kiire edastus lõpptarbija
rahulolu tagamisel võtmetähtsusega - (Expedited forwarding – edaspidi EF);
2. VPN – sellele teenusegrupile on võimalik kõige loovamalt läheneda, pakkudes
kliendile välja just teda huvitavate parameetritega lahenduse (veakindluse, viite ja
eri edastusklassidest liikluse mahtude osas) - (Expedited forwarding ja/või
Assured forwarding);
3. Internetiühendus ja IP transiit – tegu on tüüpilise „parima võimaliku edastuse“
teenustega. (Default forwarding - edaspidi DF).
Kolmanda punkti (tavapäraselt suurima osakaaluga liiklus) kontekstis on võimalik
vaadelda võrku täitva liikluse jaotust ja liikluse käitlust korraldada vastavalt
teenusepakkuja kulukriteeriumitele:
• käsitletava liikluse tüübi osakaal kogu liiklusmahust,
• teenusepakkujale ilmnev konkurentsieelis,
• välisühenduse (reeglina kulukam kui transport oma võrgu piires) kasutuse määr.
Selles problemaatika keskmes on viimase aastakümne jooksul jõudsat arengut näidanud
failivahetusvõrgustikud, mis tarbivad kaalukalt enim Interneti ressurssidest. [Hallerman].
Kuna väikeste teenusepakkujate jaoks on sellisel puhul suurema tõenäosusega tegu võrku
siseneva liiklusega, on seda operaatori seisukohalt mõistlik piirata, leidmaks ribalaiusele
majanduslikult otstarbekam rakendadus muude teenuste näol. Autor lähtub siinkohal
Eestile omastest turutingimustest, kus lairiba internetiühendusele ei kehti tavapäraselt
mahutasud vaid fikseeritud kuutasud. Klientidele mahupõhist maksustamisskeemi
kohaldava teenusepakkuja seisukohalt on selline liiklus seevastu vägagi kasulik.
Kokkuvõtteks - operaatori poolne võrguliikluse prioritiseerimise poliitika kujuneb välja
mitme kirjeldatud vaate põhjal:
• teenusegrupist või kliendisegmendist lähtuv reaalne (või potentsiaalne) tulu,
• diferentseeritud kvaliteedigarantiidega teenuste pakkumise tehniline keerukus,
• VPN-teenuste paindlikkus vastavalt kliendi vajadustele,
• kuluefektiivsuse tagamine.
36
5 Nõuded infrastruktuurile
5.1 Planeerimine ja nõuded
Olulisim eeldus garanteeritud teenusekvaliteeti pakkuva infrastruktuuri edukaks
loomiseks on pakkuda plaanitavate teenuste poolt esitatavate nõuetega piisavalt varajane
arvestamine. Tähtis on lähtuda põhimõttest, et võrk peab olema disainitud teenuste jaoks -
vastasel juhul saaks teenusekvaliteedi tagamist käsitleda infrastruktuuri piirangute
minimeerimise kontekstis, mis vähendab teenusepakkuja jaoks oluliselt sellisest tehnilisest
lahendusest tulenevat konkurentsieelist. Kuigi standardid sätestavad DSCP vormingu ja
DiffServ PHB-d, peab need tehnilised võimalused pakutavateks teenusteks vermima
ikkagi operaator, alustades sellega juba teenusteportfelli kujundamise käigus.
Teenuse tehnoloogiliste lülide prototüüpimine peab toimuma projekteerimistsükli
võimalikult varajases faasis, kinnitamaks tagasiside korras tehnilise teostatavuse
realistlikkust. Vastasel juhul varitseb alati oht, et püstitatud eesmärgid võivad osutuda
saavutamatuiks ning kaasneb täiendav ajakulu nõuete ümberhindamisele.
Teenusekvaliteedi tagamisele - nagu ka selleks eelduste loomisele - tuleb
võrguplaneerimise protsessis läheneda kompleksselt:
• millised on infrastruktuuri komponentide tehnilised karakteristikud, tagamaks
pakutavate teenuste funktsionaalsed parameetrid (viide ja selle stabiilsus; tõrgeteta
tööaja piiratusest tulenevad riskid);
• mahuplaneering teenuste lõikes (millisel määral võrguressurssi on plaanitud mingi
teenuse liikluse edastuseks mingi perioodi jooksul) absoluut- (eeldatavad
andmemahud) ja suhtelisel (osakaal teiste teenuste suhtes) skaalal;
• mahtude halduse poliitika (millise on kanalite ja võrgusõlmede normaalne
koormatus töö- ja veaolukordades; millise kasutusläve saavutamisel alustatakse
laiendusprotsessi);
• võrgu töökindlus (milline võib olla rikke ulatus, mille puhul võrgu toimivus säilib
nõutud piirides) ja magistraalvõrgu liikluse taasteks vajalike mehhanismide valik
vastavalt nende parameetrilisele sobitusele teenuste eripäradega [Faucheur lk. 95];
• seadmete valik, tagamaks piisav ressurss (sh. laiendatavus) tõrgeteta tööks
planeeritud mahus teenuste pakkumisel.
37
5.2 Teenuste poolt esitatavad nõuded
Klassikaliste IP-teenuste puuduste analüüsist tõstatub hulk nõuded, mille täitmiseks IP
paradigma raames puuduvad sobivad vahendid. Käesolevas jaotise eesmärk on välja tuua
kokkupuutepunktid MPLS tehnoloogiaga, võimaldamaks üle saada leitud kitsaskohtadest.
1. Kontroll andmeside parema juhitavuse üle:
1. ribalaiuse diferentseeritud jaotamine ning edastusgarantiid võrgusõlmede vahel
(MPLS vaste: RSVP-TE) [Fineberg lk. 5];
2. võimalus juhtida liiklust mööda hetkel parimat marsruuti, eraldades selleks
eelnevalt piisaval hulgal ribalaiust (MPLS vaste: RSVP-TE ja CSPF) [Garret
lk. 484];
3. mehhanismid võrgu veakindluse tõstmiseks, tagamaks piisav käideldavuse tase
rikke olukorras (MPLS vaste: FRR);
4. liiklusele kohandatava garanteeritud edastuse dünaamiline sidumine liikluse
edastusklassiga (MPLS vaste: Diffserv-aware-TE) [Fineberg lk. 5];
2. Järgmise põlvkonna teenuste tugi
1. Teenusegruppide virtualiseerimine infrastruktuuril (MPLS vaste: eraldamine
LSP-desse);
2. Vajadus paindliku VPN teenuse järgi (MPLS vaste: L3VPN mudel);
3. Ribalaiuse dünaamiline pakkumine (Bandwidth on demand) (MPLS vaste:
RSVP-TE) [Fineberg lk. 10; Lionel, Xiao lk. 11];
5.3 Teenusepakkuja poolsed funktsionaalsed nõuded
Lisaks rakenduste poolt esitatavatele, on veel suur hulk nõudeid, mis ei mõjuta otseselt
rakenduste tööd, kuid lisavad väärtust operaatori vaatenurgast lähtuvalt.
1. topoloogia lihtsustumine multiteenuste keskkonna operatiivsemaks halduseks
(MPLS: LSP-d);
2. võrguliikluse mugavam (võrdluses IP tehnoloogiaga) granulaarsus (MPLS vaste:
FEC);
3. skaleeruv tehnoloogiline lahendus (MPLS vaste: LSP-de hierarhia);
4. võrguressurssi efektiivsema paralleelkasutuse võimalus (MPLS vaste: TE-LSP);
38
5. dünaamiline rikke mõju minimeerimise metoodika (MPLS vaste: RSVP-TE,
DiffServ-TE);
6. erinevate edastusnõuetega teenusegruppide koostoimimise tagamine ja sellest
tulenev võrguressursi efektiivsem kasutus (MPLS vaste: DiffServ-TE);
7. vajadus paindlikku haldust võimaldava VPN-teenuste raamistiku järele (MPLS
vaste: L3VPN);
1. korduvate aadressivahemike ja marsruutimisprotokollide parameetrite tugi;
2. ressursisäästlik hallatavus;
8. infrastruktuuri haldusega seonduva teabe eraldamine teenustega seonduvast
võrguliiklusest (control plane, data plane);
9. efektiivne kontroll võrguressursile ligipääsu üle (MPLS vaste: DiffServ-TE ja
RSVP-TE);
10. piisava granulaarsusega kontroll liiklusmahtude juhtimisel.
39
6 Võrgutopoloogia valik
6.2 Skaleeruvus
Tuumikvõrku kujundades tuleb silmas pidada, et see osa võrgust peab
juurdepääsusegmendist kombineeruvate liiklusmahtudega muudatusteta toime tulema
pikema perioodi vältel. MPLS-i rakendamine pakub selleks võimaluse vajalike LSP-de
arvu minimeerimiseks alumistest võrgukihtidest sõltumatult - LSP-de hierarhilise
ümberkorraldamise teel [Minei, Lucek lk. 55]. Võrreldes sama füüsilise topoloogia (vt.
joonis 9) erinevaid lahendusi, näeme, et hierarhiliste LSP-de loomine võimaldab kesksetes
võrgusõlmedes talletamist vajavate olekute hulka oluliselt vähendada. Vasakpoolsel
kasutusjuhul (vt. joonis 9) peab iga seade hoidma ja signaalima kõigi teda läbivate LSP-de
olekuid. Parempoolse näite põhjal teavad R1 ja R2 vahelise LSP olemasolust vaid R1 ja
R2 ning nende vahetud naabrid, muud teel asuvad marsruuterid edastavad ainult „välist“
LSP-d. See näide illustreerib lisaks ilmekalt IntServ mudeli puudusi. Algupärane RSVP
vajanuks mitmeid suurusjärke enam olekuid, olles mõeldud signaalima ja haldama seansse
lõppkasutajate rakenduste vahel, RSVP-TE mõjuala piirneb aga teenusepakkuja MPLS
infrastruktuuri sõlmedega. Joonise põhjal ilmneb ka, (vt. parempoolne topoloogia joonisel
9) et hierarhilise struktuuri efekt saabub alles piisavalt suure võrgusõlmede arvu
saavutamisel.
LSP-de arvukuse piiramine omab lisaks füüsilise võrguressursi kasutuse määra tõstmisele
võtmetähtsust ka haldussuutlikkuse parandamisel. LSP-de arvu kasvades muutuvad
keerukamaks uute teenuste lisamine, teenuste monitooring, võrgu laiendamine ning rikete
diagnostika. Skaleeruvuse oluliseks eelduseks on ühe tegurina ka ühtlustatud
Joonis 9. Võrdlev näide LSP-de hierarhilise ülesehituse eelistest [Minei, Lucek lk. 33]
40
infrastruktuur – võrk või võrgusegment, mis koosneb tervenisti või tsooniti
(juurdepääsuvõrk, magistraalvõrk, geograafiline piirkond) sarnastest seadmetest. Samu
põhimõtteid järgivad seadmed tagavad väiksema vajaduse oskusteabe ja tugisüsteemide
(sealhulgas tugistruktuuri opereeriva inimressursi) järele teenusepakkuja organisatsioonis,
efektiivsema avariilao korralduse, võimaldades lihtsamaid mehhanisme korralisteks
haldustoiminguteks, tarkvara versioonipoliitikaks ja riketest taasteks.
6.3 Mahuhaldus
Mahuhalduse kui protsessi eesmärgiks on käideldavate liiklusmahtude absoluut- ja
suhtarvulise osakaalu (liikluse jaotus erinevate edastusprioriteetide vahel) statistiline
ennustamine ja ning vastavalt sellele vajalikul määral vaba ribalaiuse kättesaadavaks
tegemine. Kuna ribalaius on piiratud ressurss, tuleb seda planeerides taotleda järgnevate
tingimuste täitmist:
• rikete puhul säilib piisavalt vaba ribalaiust,
• üksiku kliendi või teenuse ribalaiuse kasutus ei tohi kasvades tekitada probleeme
muude teenuste toimivusele,
• tagatud peab olema majanduslikult põhjendatud ressursikasutus.
Olulisemateks piirideks on siin seadmete ja kanalite ressursi rakendatuse määr töö- ning
avarii olukordades, ning sellest lähtuvalt küsimus - kui suur osa kanali ribalaiusest,
seadmete protsessoriajast või mälukasutusest tuleks hoida reservis. Rikke puhul tuleb
arvestada mingi osa kanalite või võrgusõlmede väljalangemisega, mille tulemusena
ülejäänud võrgusegmentides ummistust tekkida ei tohi. Mida karmimad on nõuded
veakindlusele, seda kõrgem saab olema nendele nõuetele vastava infrastruktuuri
maksumus.
Tavapäraselt esitatakse ressursi lubatud täituvuse aste protsendina tema ribalaiusest – nn.
ohutusvaruna (safety margin). Tööolukorras on see signaaliks alustada uuendusprotsessi –
kanali puhul on selleks tavapäraselt 40-50% keskmine täituvus, mille saavutamine
tähendab sisuliselt, et selle kanali rikke korral ei piisa enam reservis olevast ribalaiusest,
tagamaks „üle jääva“ liiklusmahu transporti.
Makromõõtmes on äärmiselt oluline ka topoloogia ribalaiuste tasakaalustatuse tagamine.
Puudub mõte maksimeerida üksikute kanalite võimalikku kasutuse määra kui võrgus
tervikuna puudub valmidus (ribalaiuse reserv) toime tulla ühe sellise kanali rikke puhul üle
41
jääva liiklusmahuga. [Minei, Lucek lk. 62]. Eelkõige tuleb tähelepanu suunata
miinimumide (pudelikaelte) leidmisele ja kõrvaldamisele. MPLS-i rakendamise peamine
eelis seisneb siinkohal traditsiooniliselt keerukate liikluse halduse mehhanismide lihtsa
realiseerimise võimaluses mahtude ümber jaotamise korraldamisel. [Minei, Lucek lk. 39]
Siiski tuleb mõista, et MPLS ei tekita juurde täiendavat ribalaiust ning ei saa olematuks
muuta madalama läbilaskevõimega komponentidest tingitud pudelikaelu võrgus.
Mahuhalduse puhul tuleb kvalitatiivse diferentseerimise tingimustes fikseerida ka eri
edastusklassidesse kuuluva liikluse osakaal kasutadaolevast ribalaiusest. Selles nõudes
peitub mitu jäika piirangut:
• liidese edastuspuhvri lubatav maht sõltub otseselt liiklusklassile eraldatud
ribalaiusest, lubatavast viitest ja rakenduse poolt tekitatava liikluse granulaarsusest
(paketi või kaadri suurus),
• puhvri maht seab piiri vastava liiklusklassile eraldatud ribalaiusele liidesel.
Lisaks tuleb langetada otsus, kas edastusklassidel põhinevad ribalaiuse reserveeringud
fikseerida jäigalt (turvalisem) või on mõistlikum võimaldada vaba ribalaiuse ristkasutust
(majanduslikult efektiivsem) erinevate liiklusklasside vahel. EF puhul on jäiga ülempiiri
tagamine oluline peamiselt põhjusel, et UDP protokoll ei allu erinevalt TCP-st
puhvrihaldusmehhanismi poolsele ribalaiuse piiramisele RED (random early detection)
algoritmide abil. Seetõttu tuleb täiendavate meetoditega välistada EF liikluse poolt
põhjustatud ummistusest tõusev risk AF (selles klassis edastatakse tavapäraselt ka
võrguhaldusteavet) liiklusele. Tabelis 1 on selgitatud mõlema lähenemise olemust.
KäitlusklassRibalaiuse jäik jaotamine Ribalaiuse ristkasutus
Reserveering Ülempiir Reserveering Ülempiir
EF 30% 30% 30% 30%
AF 60% 60% 60% 100%
BE 10% 10% 10% 100%
100% 100% 100% 230%
Tabel 1. Võimalused võrguliidese ribalaiuse käitlusklassiti jaotamiseks
Tabelis 1 toodud informatsiooni tuleb tõlgendada lähtuvalt piirangute jäikusest tulenevat
ebaefektiivsusest olukorras, kus liikluse jaotus erineb eeldatust. Näiteks tekiks jäiga
reserveeringu puhul olukord, kus isegi muu liikluse puudumisel piirataks IP teenuste või
VPN teenuste liiklust vastavat 10% ja 60%-ini kanali ribalaiusest. 230% ei tähista mingil
42
juhul juurde tekkivat ribalaiust, vaid iseloomustab paindlikuma alternatiivi – ribalaiuse
ristkasutuse poolt pakutavat eelist vaba ressursi leidumisel.
Kvalitatiivse diferentseerimise rakendamisel koos ribalaiuse reserveerimisega kerkib
täiendavalt liiklusmahtude koondamise vajadus edastusklasside kaupa. Mitmest tsoonist
koosneva topoloogia puhul tuleb seega jooksvalt tagada ka reserveeritud mahtude sobitus
juurdepääsu- ja tuumikvõrgu vahel, et esimesest lähtuva EF liiklusmahu tarbeks leiduks
magistraalvõrgus piisavalt vaba ribalaiust ekvivalentses edastusklassis. Mahuhalduse ühe
osana tuleb käsitleda ka laiendamise strateegiat – eri tsoonide võrgusõlmedele kehtivad
siin reeglina erinevad lähenemised. Juurdepääsuvõrgu arenduses puudub vajadus üle
dimensioneerida (overprovisioning) – eesmärgiks tuleb seada korralise laiendatavuse
lihtne tagatavus, kuna ribalaius kanali kohta on suhteliselt madal ja täituvus kasvab
peamiselt täiendavate füüsiliste kanalite (klientide liinid) lisandumisest. Samal põhjusel ei
anna lähenemine juurdepääsuvõrgus eelist ka viite minimeerimisel - madalamate
ribalaiuste puhul on paratamatu kõrgem saateviide, muutes seega puhverdusviite mõju
summaarses hilistuses vähem oluliseks. [Faucheur lk.6; Fineberg lk. 4]
Magistraalvõrgus on - vastupidiselt – taotluseks kahe külgneva võrgusõlme vahel
eraldiseisvate füüsiliste kanalite tekkimise vältimine ning ribalaiuse kontsentreerituse
tagamine. Seetõttu on soovitatav nii piisava varuga arvestamine uute rajatiste välja
ehitamisel kui ka loogiliste liitliideste (tehnoloogiad: Aggregated Ethernet, Aggregated
Sonet (Juniper Networks); EtherChannel (Cisco Systems)) kasutamine. Viimaste eeliseks
on kanalite ribalaiuste dünaamilise suurendamise võimalus, teenuse toimivust
mõjutamata.
Mahuhalduse alla võib paigutada ka võrguressursile ligipääsu kontrollimise (call
admission control) nõude. Piirtäituvuse lähedases olukorras ei lubata võrku juurde
täiendavat liiklust - sellise liikluse pääs võrku (kuna liikluse jõudmine sihtpunkti on
vähetõenäoline) oleks käsitletav võrguressursi raiskamisena. Parima efekti saavutamiseks
tuleb ligipääsukontrolli teostada segmendi äärealadel.
6.4 Käideldavus
Taastemehhanismide valikule eelnevalt tuleb defineerida võrgu käideldavust puudutavad
üldisemad eesmärgid, mille eeldused peituvad võrgurakenduste olemuses. On selge, et
näiteks pseudotraat (pseudowire) lahendused ja internetipõhine kõneside karmistavad
hilistusele seatavaid piiranguid tunduvalt enam võrrelduna veebiliiklusest koosneva
43
andmesidega. Eesmärgistatus seondub peamiselt lõppkasutajale pakkuda soovitavate
teenuste taotletava tajutava kvaliteedi tagamise määra või rikke aktsepteeritava
mastaabiga. Esimesel juhul defineeritakse, millised teenusekvaliteedi langused on
lubatavad. Telefoniside puhul võib võrgusõlme rikke tingimustes eesmärgiks seada kõne
jätkumise (kriitiline aeg 2 sekundit) või kuuldavate häirete puudumise (kriitiline aeg 20 ms)
kõnekanalis [Faucheur lk 68]. Nende võimaluste vaheline ajaline erinevus (vajalik
taastekiirus) on ligikaudu 100-kordne, mis võimaldab nõuete põhjal selgelt valida erinevate
tehnoloogiliste lahenduste hulgast. Mastaabi osas piiritletakse infrastruktuuri koososa(d),
mille rikke korral peab teenuste toimivus säilitama vastavuse kehtivatele kvaliteedinõuetele
– näiteks sidekanal(id), võrgusõlm(ed), seadmemajutuskeskus(ed).
Käideldavuse tagamise aluseks on teineteist funktsionaalselt dubleerivate mehhanismide
paralleeltöö. Need mehhanismid jaotuvad kahte peamisesse rühma:
1. ennetavate mehhanismide (protection) puhul on varutee signaalitud rikkele
eelnevalt,
2. taastemehhanismid (recovery) signaalivad varutee alles vahetult peale riket.
Mehhanismi valikul mängivad peamist rolli:
• tasakaal maksumuse ja oodatava tulemuslikkuse vahel,
• varutee poolt pakutav QoS-i ekvivalentsus,
• võrguseadmete täiendav ressursikulu lisaolekute salvestamisele varuteede
signaalimisel,
• taastemehhanismi varjukülgedest (võnkumiste oht) tulenev risk võrgu stabiilsusele.
Lihtsaim ja odavaim viis IP võrgu puhul on marsruutimisloogika poolt tagatav töökindlus.
Aegkriitilise liikluse kontekstis jätab sellise lähenemise topoloogia muutustele
reageerimise ajaline mõõde (sekundites) aga soovida. SDH (synchronous digital hierarchy)
kasutamine transmissioonis võimaldab alla 50 ms taasteaegu, olles aga komponentide
maksumuselt (ja peamiselt varukanalite ribalaiuse ebaefektiivse kasutuse tõttu)
suurusjärke kulukam. Mõningatel juhtudel pakub mehhanismide kombineerimine
lisaväärtust – näiteks SDH võrguliideste kasutamine marsruuterites parandab rikkele
reageerimise aega tänu kanali oleku kõrgema operatiivsusega signaalimisele. Võrgu
stabiilsuse huvides on siiski soovitav taastemehhanisme mitte segada ning jääda lihtsuse
huvides kindlaks loetud valikutele.
44
MPLS pakutav eelis siinkohal on kahe kirjeldatud äärmuse kompromiss fast reroute
(edaspidi FRR) mehhanismina, mis võimaldab SDH-le lähedasi taasteaegu ning kiiret
reaktsiooni topoloogiamuudatustele peamiselt tarkvaralise loogika toel, nõudmata
lisakulutusi täiendavatele seadmetele. Lisaks võimaldab tarkvarale taandatud
taastemehhanism oluliselt laiendada ühilduvate tehnoloogiliste platvormide valikut.
Tarkvaralise lähenemise ühe ohuna võib välja tuua jõudluse sõltuvuse võrku juhtiva
arvutusressursi koormusest.
6.5 Teenusegruppide virtualiseerimine
Virtualiseerimine tagab ühelt poolt efektiivsema võrguressursi kasutuse ja teisalt ühtsel
infrastruktuuril toimivate teenuste selgema eristamise. MPLS-i rakendamisel avaldub see
tehnilise võimalusena jagada erinevate teenusegruppide poolt tekitatava liiklus
erinevatesse LSP-desse. Ressursside osas vastavate reserveeringute tekitamise ning
liikluse taaste mehhanismide rakendamise muudab võimalikuks RSVP-TE (edaspidi
RSVP) protokoll, mille eeliseid alternatiivide ees tutvustab lähemalt Garret [Garret lk
484].
RSVP võimaldab hallata füüsilisele kanalile loodud LSP-sid ja pidada arvet, millises
ulatuses võrguressurssi on reserveeritud. Vastavalt ülemüügi (overbooking) koefitsendi
väärtusele ei luba RSVP maksimaalse eraldatava ribalaiuse (vaikimisi kanali ribalaius)
saavutamisel uute LSP-de loomist. Siinkohal tuleb rõhutada, et RSVP ei piira kuidagi LSP
kaudu edastatava liikluse mahtu– ligipääsukontroll (policing/shaping) peab toimima
eraldiseisva mehhanismina. Vastavalt LSP prioriteeti märkivatele parameetritele
määratakse LSP-de omavaheline ülemuslikkus – kõrgem (setup) rajamisprioriteet
võimaldab loodaval LSP-l kanalilt elimineerida (preempt) madalama (hold)
hoideprioriteediga LSP. Silmas tuleb pidada kahte praktilist kaalutlust [Minei, Lucek lk.
58]:
• vältida olukordi, kus LSP hoideprioriteet on madalam kui rajamisprioriteet - tekib
võnkumise oht,
• võimaldada suuremahulistel LSP-del ümber suunata (preempt) väikesemahulisi
LSP-sid – põhjenduseks asjaolu, et väiksema ribalaiuse puhul on vaba
võrguressurssi leidmine uue tee tarbeks lihtsam.
Viimase väite osas esitab autor oma kogemuste põhjal vastuväite - praktilistes
olukordades on võrguliikluse maht ja edastusprioriteet tavaliselt just pöördvõrdelises
45
seoses. Lähtudes eeldusest, et kõrgemate edastusnõuetega liiklusklasside (EF) puhvrid on
piiratud suurusega just tänu hilistuse minimeerimise vajadusele, ei saa selline liiklus mingil
juhul omada ülekaalu kasutatava ribalaiuse osas. [Minei, Lucek lk. 117].
RSVP-d rakendades saame olukorra lahendada järgnevalt: olgu iga teenuseklassi jaoks
magistraalvõrgus omaette LSP. BE-liikluse jaoks rakendatav LSP on ribalaiuse poolest
mahukaim, ent samas ka kõige madalama RSVP taasteprioriteediga. Kui magistraalvõrgus
ilmneb kanali rike, lõpetavad kõik sellel kanalil aktiivsed LSP-d tegevuse ja neile leitakse
uus tee, DF LSP saab aga taastuda vaid juhul kui tema jaoks leidub taas piisavalt vaba
ribalaiust. Kui EF ning AF liiklust kandvad LSP-d vajavad rikke tõttu koondunud
liiklusmahtudele enam ruumi ning DF LSP-le ei jätku piisavalt vaba ribalaiust, too ei taastu
ning võrk rikke ajal rohkem DF liiklust ei edasta.
Ehkki IP liikluse edastusprioriteediks sellises kihilises disainis oleks DF - madalam kui
kahel kõrgemal edastusklassil, ei oleks kirjeldatud „must-valge“ RSVP rakendusskeem IP-
teenuste pakkuja seisukohalt täiel määral vastuvõetav ning isegi pakutava parima
võimaliku teenusekvaliteedi tagamiseks tuleks rakendada IP protokolli liikluse halduse
võtteid. Täiendavat sõltumatust pakkuv võimalus oleks IP liiklus võimalik paigutada
eraldi L3VPN marsruutinguinstantsi (VRF), kuid selle teostus vajab täiendavat
infrastruktuuri jõudluse analüüsi – L3VPN marsruutingukirjed omavad rohkem atribuute
ning nõuavad rohkem mälu kui tavalised IPv4 marsruutingukirjed. [Faucheur, lk. 247]
Haldusinfo tarbeks tuleb luua eraldi tasand – milleks on kaks peamist võimalust:
• eraldiseisev AF edastusklassiga LSP,
• IPv4 marsruutingutabeli kasutamine (eeldusel, et Interneti jaoks eksisteerib eraldi
VRF).
On selge, et signaalimine kui võrgu toimivuse alus peab asuma DF-st kõrgemas
edastusklassis. Tavaliselt eelistatakse selleks otstarbeks AF-klassi, kuna tegu on
missioonikriitilise (kuid mitte aegkriitilise) liiklusega. Peamise keerukuse tingib asjaolu, et
LSP-de loomiseks eeldatakse IP võrgu funktsionaalsust juhttasandil, kuna
sildijaotusprotokollid baseeruvad IP protokollil. Haldusinfo käitlemiseks IP liikluse
edastuskihil tuleb täiendavalt lahendada IP liikluse prioritiseerimisskeem magistraalvõrgus
paralleelselt LSP-de liiklusega.
EF klassi asustamisele pretendeerivad nõuete poolest järgnevad teenused:
• pseudotraat (pseudowire) teenused,
• IP kõneside teenused,
46
• videovoo edastus,
• olümpiateenusena realiseeritud VPN-teenuse liiklus.
EF edastusklassi peamine piirang on seotud pakutava edastuse aegkriitilisuse
kriteeriumiga, mis muudab keeruliseks tõhusa ressursikasutuse. Kuna EF puhvrid on viite
minimeerimise otstarbest lähtudes väikesemahulised, on EF-le eraldatud ribalaiuse
ületamisel risk kvaliteedi languse ilmnemiseks suur. Tabel 2 esitab ühe võimaluse teenuste
liikluse kihiti eristamiseks MPLS võrgus vastavalt teenuste eripärale.
Otstarve Edastusklass Kapseldus/protokoll
Marsruutingutabel Osakaal liiklusest
IP teenused DF IP/LSP IPv4/VRF 45%
Video/VoIP/VPN+ teenused
EF LSP VRF 25%
VPN teenused AF LSP VRF 25%
Haldusinfo AF IP/LSP IPv4 <5%
Tabel 2. Näitlik jaotus teenuste virtualiseerimiseks
6.7 Võrgusõlmede vaheline signaalimine QoS tagamiseks
Diferentseeritud teenuste arhitektuuri (edaspidi DiffServ) puhul erimärgistatakse (marking)
IP paketid IPv4 protokollipäise DSCP välja (6 bitti) kasutades, luues nii
prioriteediklassid (26=64), millele tuginedes saab võrguseadmete poolt rakendada
diferentseeritud teenindusvõtteid. Kõigis diferentseeritud teenuseid toetavates
võrgusõlmedes peab eksisteerima ühtne käitluskontekst (PHB – per-hop-behaviour), mille
alusel pakettide mägistust tõlgendades edastusotsuseid langetatakse. Kolm sellist
käitluskonteksti on standarditud (reastatuna edastusnõuete karmistumise järjestuses):
• Default forwarding („best effort“ edastuse ekvivalent) [RFC 2474];
• Assured forwarding (edaspidi AF) [RFC 2597];
• Expedited forwarding (edaspidi EF) [RFC 3246].
Liiklus, mille puhul konteksti täpsustada ei õnnestu, kuulub edastamisele DF
edastusklassis.
DiffServ toimib MPLS-võrgus ja IP võrgus põhimõtteliselt identselt. MPLS-i eelist
kannavad edasi just viimase kombineeritud lisavõimalused– näiteks prioritiseeritava
liikluse kiirem edastus käitluskonteksti sidususe arvelt vastava LSP-ga (label switched
47
path). IP-võrgu puhul ilmneb võrdluses mõningane töötluskiiruse langus, tulenevalt
vajadusest viia iga käideldava paketi päisega kõigis võrgusõlmedes lisaks
marsruutimisotsusele läbi täiendav prioritiseerimisoperatsioon. [Odinma, Oborkhale lk. 15]
Juurdepääsuvõrgus toimub signaalimine traditsioonilisi IP ja ethernet protokollide päistes
sisalduvaid välju kasutades (vt. joonis 10)
MPLS tuumikvõrgus liigub QoS info MPLS kaadri EXP välja kasutades (vt. joonis 11).
IP paketile lisatakse MPLS päis ja infokaadri edasine käitlus toimubki EXP väljal paikneva
teabe alusel. Tuumikvõrgu piires edastamisel EXP väljal (nagu ka kapseldatud IP-paketi
DSCP väljal) asuvat teavet tavaliselt ei muudeta. MPLS-võrgust väljumisel eemaldatakse
Joonis 11. QoS signaalimine protokollide kombineeritud vahendeid kasutades
Joonis 10. QoS parameetrid protokollipäistes [Ernie]
48
paketilt MPLS päis ja edasine DiffServ käitlus juurdepääsuvõrgus toimub taas IP DSCP
alusel. PHP (penultimate hop popping) põhimõtet järgides lõpetatakse MPLS-edastus
(sidumispunktide koormuse leevendamiseks [Faucheur lk. 13]) sidumispunktile eelnevas
võrgusõlmes ning viimasel sammul (hop) lähtutakse edastuse prioritiseerimisel paketi
DSCP väärtusest.
Järgnevalt on tabelis 3 kirjeldatud näitlikku mitmetasandilist märgistamisskeemi võrgu
puhul, kus juurdepääsusegment kasutab liikluse prioriteedi signaalimiseks IP DSCP välja
ning tuumikvõrgus toimub eristamine EXP väärtuse alusel. Lisaks erimärgistusele on välja
toodud ka kasutatav liidesepuhver võrguseadmes. Rõhutamist väärib, et võrguhalduse
puhul on DSCP märgistusel lähtutud enamuse tootjate poolt vaikimisi lisatavatest
väärtustest võrguseadmete poolt tekitavale haldusprotokollide (telnet, SNMP,
marsruutimisprotokollid) liikluse pakettidele.
Teenus DSCP väärtus juurdepääsuvõrgus
Liidesepuhver juurdepääsuvõrgus
EXP tuumikvõrgus
Liidesepuhver tuumikvõrgus
Pseudotraat 46 EF2 EF
VoIP 46 EF
VPN 16 AF 4AF
Võrguhaldus 48 AF 5
IP teenused 0 BE0 BELepinguväline
liiklus0 BE
Tabel 3. Näitlik QoS märgistamisskeem
Kvaliteediklasside seostamiseks LSP-ga eksisteerib kaks meetodit - E-LSP (EXP-inferred)
pakub 8 ja L-LSP (label-inferred) 64 võimalikku edastusklassi tähistust. Lisaks suuremale
kombinatsioonide arvule on viimase eripäraks ainusobivus ATM transporti kasutavates
lahendustes, kus puudub võimalus EXP välja kasutamiseks. [Cisco Systems 1.]
Lihtsustavalt võib selgitada, et E-LSP puhul, kus käitlusklassi adresseeritakse 3-bitise
EXP parameetri abil, on samasse LSP-sse võimalik koondada kuni 8 erineva
kvaliteediklassi liiklust. L-LSP-ga, kus ainus edastusklassi identifitseeriv parameeter on
LSP sildi väärtus (label), on võimalik siduda ühe kvaliteediklassi liiklus.
Teenusetaseme andmete sidumiseks liiklusega on OSI mudeli põhjal mitmeid võimalusi:
1. Rakenduse, kasutaja või serveri põhjal IP paketi DSCP välja täitmine – äärmiselt
paindlik, tekitades samas teenusepakkuja seisukohalt kontrollimatu olukorra – kui
49
kliendi poolel puuduvad rangelt järgitavad sisemised protseduurid ning kontroll
prioriteetide kasutamise üle, võib sellisetel tingimusetel toimuda kõrge
prioriteetsusega edastusklassi väärkasutus;
2. Kanalikihi protokolli tasemel, juhul kui kliendi sisevõrgus asuvat võrguseadet
haldab teenusepakkuja. Liikluse prioriteeti on võimalik määrata seadme liidese või
VLAN-i tunnuse alusel ja ethernet protokolli kaardi päises edasi kanda hilisemaks
DSCP väärtuseks transleerimiseks või selle kontrolliks;
3. Kliendi poolt teenusepakkujale esitletud kanalikihi (lähte MAC-aadress),
võrgukihi (lähte- või sihtkoha IP aadress) või transpordikihi (TCP/UDP lähte-
ja/või sihtpordi number) parameetrite alusel;
4. Võrguseadme füüsilise liidese tasemel – näiteks kõrgemat edastusprioriteeti vajav
kõneliiklus siseneb TDM liidese ja madalama prioriteediga andmeside ethernet
liidese kaudu.
Kokkuvõtvalt - pakettsidevõrgu QoS valmidus DiffServ arhitektuuri juurutamisel eeldab
terviklikku käsitlust – kõik võrgusõlmed peavad (nii üles- kui allalüli suunal) teostama
pakettide erimärgistamist/märgistuse eemaldamist ühtse käitluskonteksti alusel. Lisaks
tuleb rõhutada, et ehkki enamiku MPLS ja IP võrguseadmete vaikimisi seadistuseks on
kas igasuguse QoS märgistuse eiramine (midagi ei loeta ega märgistata) või eemaldamine
(asendamine vaikeväärtustega), ei saa see olla aluseks eeldada korrektset lähenemist
operaatoriga seotud klientide ja partnerite võrkudelt. Välised riskid peavad QoS disainis
olema süsteemselt maandatud enne igasuguse DiffServ-teadlikkuse rakendamist
teenusepakkuja võrgus.
6.5 Seadmed
Seadmed peavad vastama planeeritavate teenuste poolt esitatavatele nõuetele, pakkuma
piisavat laiendamisvõimalust ning rahuldama operaatori poolseid kriteeriume
funktsionaalsuse, haldusvõimaluste ja turvalisuse osas. Peamiselt tuleb arvestada
planeeritavale rakendusviisile spetsiifilisi piiranguid – antud juhul:
• maksimaalne toetatud LSP-de arv (kas lähevad arvesse ainult termineeritud või ka
transiit LSP-d),
• maksimaalne toetatud L3VPN marsruutingukirjete arv,
50
• maksimaalne IP marsruutingukirjete arv marsruutingutabelis,
• virtuaalsete marsruutinguinstantside (virtual routing forwarding instance) arv,
• võtmeoperatsioonide raudvaraline (ASIC) tugi (IP marsruutimine, liideste
edastuspuhvrid),
• vajalike protokollide tugi ja juurutuse ulatus.
Seadmete juhttasandi (control plane) eraldatus andmeside tasandist (data plane) peab
tagama, et rikke korral jääb side toimima vastavalt rikkele eelnenud QoS määrangutele.
Seda kõike nii raudvara (ASIC) - (nii hetkel pakutavate kui arenduskavas olevate
juhtmoodulite (routing engine; forwarding engine) ning võrguliideste) kui tarkvara osas.
Eraldi tähelepanu tuleb pöörata vajaliku funktsionaalsuse litsenseeritusele. Praktika
näitab, et kahjuks on seadmetootjate poolt pakutav teave just selles osas tihti keerukalt
struktureeritud ja ebaselge.
Väga suurt kaalu talitlusparameetrite piisavuse hindamisel omab multiplatvormsuse
nõude püstitus - kas seade hakkab MPLS-iga paralleelselt edastama ka IP protokolli või
mitte. Täielikult MPLS magistraalvõrgust IP protokolli tuge eemaldada ei sa, sest MPLS
marsruutinguinfot vahetavad protokollid (näiteks LDP, RSVP) rajanevad oma toimimises
TCP/IP protokollistikul, küll aga on võimalik topoloogia kesksetest sõlmedest kärpida
IP-marsruuterile omased funktsioonid, võites sel viisil mälukasutuse paranemises IP
marsruutingutabeli puudumise ning protsessoriressursi säästmisel
marsruutinguprotokollide käitamise vajaduse arvelt. Täieliku IP-marsruutingutabeli
säilitavad sõltuvalt disainist, kas topoloogia servades paiknevad sõlmed, mille
ressurssikasutus paraneb omakorda LSP-de hulga ja marsruutingudomeeni keerukuse
vähenemisest või multiplatvormsusest hoidumisel eraldiseisvad IP marsruuterid. Selline
lähenemine võimaldab muuhulgas tõhustada haldusskeemi turvalistust, vähendades liikluse
lekkimise võimalusi MPLS ja IP võrgukihtide vahel.
DiffServ'iga seonduvalt tõusevad esiplaanile ka seadmete võrguliideste puhvrite
parameetrid. Tänasel päeval on tavaliste L2 ja L3 seadmete võrguliideste puhvrite arvuks
8 (vanematel tavaliselt 4). Seadme spetsifikatsiooni puhul on väga oluline selgitada, kas
puhvrite arv on piiratud füüsilise liidese, virtuaalse liidese (VLAN) või dupleksi osas -
eksisteerib ka eriotstarbelisi liideseid , mille puhvrite arv küündib mitmetesse kümnetesse
tuhandetesse. Liidesepuhvrite suurem arv ei tähista üheselt mooduli paremust (pigem on
oluline sobitatus plaanitud otstarbega), küll aga märkimisväärset erinevust hinnas.
51
3-bitilise EXP parameetri põhjal võib nentida, et pakutavad 8 väärtust rahuldavad täielikult
magistraalvõrgu vajaduse ning täiendavad puhvrid võivad vajalikuks osutuda
juurdepääsuvõrgus:
• L2: ethernet kaadri päis- 3 CoS bitti (23=8 kombinatsiooni);
• L2,5 MPLS kaadri päis: 3 EXP bitti (23=8 kombinatsiooni);
• L3: IP paketi päis - 6 DSCP bitti (26=64 kombinatsiooni).
Väikeste liiklusmahtude korral on soovitatav puhvrite ühiskasutus mitmest sarnaste
nõuetega edastusklassist pärineva liikluse puhverdamisel. Klassifitseerimis- ja sellega
paralleelselt puhverdamisskeemi saab järjest täpsustada vastavalt muutustele liikluse mahus
ja jaotuslikes eripärades. [Hattingh, Szigeti lk. 56 ]
Edastusnõuete põhjal eristatakse aeg-kriitilist (EF edastusklass), missioonikriitilist (AF
edastusklass) või best-effort (DF edastusklass) liiklust, millele erivormina lisandub
võrguhaldusteave (AF edastusklassi sobiv). Selline lihtsustatud käsitlus võimaldab
DiffServ'i kasutuselevõttu vaid nelja liidesepuhvrit rakendades – mis on ka paljude
seadmetootjate poolt kasutatav vaikimisi seadistus. Enamate edastusklasside vältimatu
defineerimise vajaduse korral tuleb erinevate edastusklasside liiklust puhverdamisel
grupeerida vastavalt edastusnõuetele. Sama kaalutlus kehtib ka DiffServ'i väärtuste osas –
ei ole otstarbekas luua keerukamat süsteemi kui tegelik praktiline vajadus ette näeb,
mõistlikum on reserveerida kasutamata jäävad ressursid (puhvrid, EXP ja DSCP väärtused)
hilisemaks rakendamiseks.
Klassifitseerimist teaostavad mehhanismid jaotuvad seadmetes üldisemalt kaheks: ühe
parameetri alusel klassifitseerijad (code point classifier) (parameetriks võib olla DSCP,
ToS, EXP või IEEE 802.1p väärtus) ja multiparameetrilised (multifield) klassifitseerijad,
mis teevad otsuseid mitme parameetri alusel (analoogia paketi käitlusega tulemüüri poolt).
[Heinlein lk. 5] Klassifikaatorite hulk on pöördvõrdelises seoses otsuse langetamiseks
vajaliku ressursikuluga (arvutusressurss ja aeg) - mistõttu leiavad multiparameetrilised
klassifitseerijad enamasti kasutust võrgu juurdepääsusegmendis ning ühe parameetri alusel
klassifitseerijad tuumikvõrgu sõlmedes. Sidumispunktides teostab klassifitseerija vastavalt
käitluskontekstile sisendparameetrite teisendust väljuvate MPLS kaadrite EXP väärtusteks,
mille põhjal langetatakse esmased otsused kaadri ligipääsukontrolli ja puhverdamise osas.
DiffServ'i seadistamise osas tuleb operaatoril arvestada järgnevate praktiliste kaalutlustega:
52
1. hübriidse (MPLS+IP) infrastruktuuri puhul tuleks võrgu juurdepääsusegmendis ja
tuumikus kujundada erinevad liikluse prioritiseerimise tasandid, tagamaks süsteemi
paindlikkus (vt. joonis 11 lk. 47);
2. operaatori sisestandardite kujundamisel tuleb alati arvesse võtta erinevate tootjate
võrguseadmete poolt vaikimisi seadistusel liikluse märgistamisel kasutatavaid
väärtusi, täpsemalt nende ühisosa (näiteks MPLS kaadrile vaikimisi seatavad EXP
väärtused, haldusinfo pakettide vaikimisi DSCP väärtused jne.) vältimaks esialgset
„jalgratta leiutamist“ ja hoidmaks kontrolli all edaspidiseid halduskulusid;
3. võrkude sidumiseks valmistumisel on oluline teada olemasolevate ja potentsiaalsete
partnerite poolt kasutatavaid märgistamiskeeme, tagamaks vajadusel lihtne
koostoimivus;
4. juba olemasoleva infrastruktuuri puhul tuleb teha kompromisse (vähimad
ühistegurid) vastavalt seadmete (või nende koosluse) poolt esitatavatele
piirangutele;
5. käitlusklasside määratlemisel tuleks võimalusel lähtuda vaikesätetest ning otsesest
vajadusest – kasutamata (EXP, CoS ja DSCP) väärtused reserveerida hilisemaks
juurutamiseks.
53
7 Praktiline katse: asümmeetrilise varukanaliga võrgusegment
Katsete läbiviimise eesmärgiks on praktiliselt kontrollida (ning illustreerida) töös esitatud
seisukohti, toomaks esile erinevate võtete mõju multimeediateenuste käideldavuse
tagamiseks ummistuse olukorras. Katseks valitud lähenemised on:
1. DiffServ ja IP marsruutimine,
2. DiffServ ja eraldiseisvad MPLS LSP-d erinevatest edastusklasside liikluse
transpordiks (L-LSP).
Valik põhineb kompromissil käesoleva töö piiratud mahu ja maksimaalse näitlikkuse
vahel. Katsete tulemusena saab hinnata erinevate meetodite tõhusust, võttes aluseks
järgnevad kriteeriumid:
• rikke mõju EF edastusklassi liiklusele,
• rikke mõju DF (käesolevas osas kasutatakse termineid DF ja BE sünonüümselt)
edastusklassi liiklusele,
• lahendusele omased rakenduslikud eelised ja puudused.
Labor sisaldab järgnevat riistvara:
• 2 Juniper M10i tüüpi marsruuterit (edaspidi marsruuter);
◦ 1 optiline(ainumood) Gigabit Ethernet võrguliides;
◦ 1 optiline(multimood) Gigabit Ethernet võrguliides;
◦ 1 optiline (ainumood) STM-1 võrguliides;
• 2 Cisco 4506 modulaarset kommutaatorit (edaspidi kommutaator);
◦ 2 kuue optilise (ainumood või multimood mooduliga) pordiga Gigabit
Ethernet liideskaarti;
◦ 1 48 RJ-45 pordiga (10/100/1000) Gigabit Ethernet liideskaart;
• 2 JDSU „SmartClass Ethernet“ ethernet ja IP protokollide testrit (edaspidi tester),
◦ 1 RJ-45 pordiga elektriline (10/100/1000) Gigabit Ethernet võrguliides;
◦ 1 optiline (ainumood) Gigabit Ethernet võrguliides;
• 2 Lenovo T60 sülearvutit Linux operatsioonisüsteemi ja Iperf 2.0.2. tarkvaraga
(edaspidi liikluse generaator);
◦ 1 RJ-45 pordiga (10/100/1000) Gigabit Ethernet võrguliides.
Riistvara valiku üheks aluseks oli katse läbiviimiseks piisavate parameetritega seadmete
54
kättesaadavus, teiseks autori poolse eelneva kasutajakogemuse olemasolu.
Juniper M10i näol on tegu Juniper Networks poolt juurdepääsuvõrgu tarbeks loodud
modulaarse marsruuteriga, mis võimaldab kasutada kahele moodulile jagatud kaheksat
võrguliidest, dupleksse läbilaskevõimega 4 Gb/s mooduli kohta. Cisco Catalyst 4506 on
andmemajutuskeskustele suunatud L3 (layer 3) toega kommutaator, mis võimaldadab
käesolevas seadistuses kasutada 5 liideskaarti (2x10Gb/s; 6x1Gb/s; 48x1Gb/s;
48x100Mb/s), dupleksse läbilaskevõimega 6 Gb/s kaardi kohta. JDS Uniphase poolt
toodetud „SmartClass Ethernet“ portatiivne tester on loodud kuni 1Gb/s kanalite
testimiseks viite, viiteväreluse, läbilaskevõime ning kadude määramisel. Testrid töötavad
paarikaupa, üks seade liikluse generaatori ning teine tarkvaralise silmusseadmena
(loopback). Täpsema ülevaate seadmest annab [SmartClass ethernet tester datasheet].
Lenovo T60 sülearvutiplatvorm osutus valituks tänu Gigabit Ethernet liidese olemasolule.
Sülearvutitele paigaldati autori valikul vaikimisi seadistuses OpenSuSE 11.2 linux'i
distributsioon ja GNU Iperf tarkvara.
Seadmete kokku ühendamisel loodud topoloogiast annab ülevaate joonis 12. Detailne kaart
on toodud lisas D.
Katse sisuks on 1Gb/s tuumikvõrgu kanali rikke korral liikluse taastamine ribalaiuselt
oluliselt kitsama varukanali (155 Mb/s STM-1) abil. Põhikanali ribalaiuse valik on tingitud
1Gb/s etherneti laiast levikust magistraalvõrgulahendustes, seda tänu nii CWDM ja
Joonis 12. Laborikatses kasutatav võrgutopoloogia
55
tänapäevasemate DWDM lahenduste poolsele toele. STM-1 liidese kasutamine
varukanalina, võib selle madalama ribalaiuse tõttu tunduda mõneti ebaotstarbekas, kuid
selleks on mitu põhjust:
• varukanal peab olema põhikanalist võimalikult sõltumatu – reeglina SDH võrk
seda on;
• SDH liides võimaldab katsetada tehnoloogiale omase, eelnevalt mainitud
signaalimisloogika eeliseid ethernet'i ees;
• DiffServ'i võimaluste demonstreerimiseks on vajalik piirsituatsiooni näide;
• madal ribalaius lubab suurendada topoloogia kuluefektiivsust, kuna harilikult sõltub
rendikanali hind kanali ribalaiusest.
Modelleeritava topoloogia (vt. joonis 12, lk. 54; lisa D) näol on tegu tuumikvõrgu
segmendiga, mis koosneb kahest IP/MPLS marsruuterist ning nendega ühendatud,
juurdepääsusegmenti kujutavatest kommutaatoritest, mille külge on ühendatud võrgutestrid
ning liikluse genereerimise tarkvaraga (GNU Iperf) varustatud sülearvutid. Liiklus
topoloogias on jaotatav kahte klassi:
• aegkriitiliste multimeediateenuste transport (EF edastusklass),
• IP teenuste (internetiühendused ja IP-transiit) transport (BE edastusklass).
EF liikluse paketisuurus on valitud lähtudes G.711 koodrist, mis väljastab 10
millisekundilise töötsükli tulemusena 80-baidiseid (64 kb/s = 64 b/ms = 8 B/ms= 80 B/10
ms) andmeblokke . Väljundile lisanduvad RTP (12 baiti), UDP (8 baiti) ning IP (20 baiti)
protokollipäised. Tulemuseks 80+12+8+20=120 baiti. Kanalikihil lisandub ethernet'i puhul
38 ja STM-1 (PPP) puhul 6 baiti päist. Testides kasutatud 128-baidine pakett oli soovitule
lähim testri poolt võimaldatav suurus. BE liikluse paketisuuruse valik 1500 baiti juhindub
eeldusest, et tegu on ethernet (MTU 1500 baiti) tüüpi võrgust (levinuim kohtvõrgu tüüp)
lähtuva liiklusega.
Ribalaius magistraalvõrgu segmendis jaotub kanalite vahel asümmeetriliselt (1000 Mb/s vs.
155 Mb/s) – põhikanali rikete kompenseerimiseks on olemas ~6 korda madalama
ribalaiusega varukanal.
Probleemiks kujuneb kanalite ribalaiuste erinevusest tingitud ebaefektiivsus – igal juhul
tuleb arvestada olukorraga, kus summaarne taastatav liikluse maht ei saa ribalaiuselt olla
üle 155 Mb/s. DiffServ on kirjeldatud juhul vajalik ribalaiuse puudujäägist tulenevate
ummistustega toime tulekuks - tagamaks EF klassi liikluse nõuetekohane käideldavus.
Lisaks ribalaiusele tuleb silmas pidada ka puhvrite sõltuvust ribalaiusest, mis antud juhul
56
samuti erineb. Kirjeldatud kanalite osas kujuneb erineva suurusega pakettide saatmiseks
vajalik aeg järgnevalt:
• 1Gb/s ethernet: (lisandub 38-baidine ethernet protokolli päis)
◦ 158-baidine pakett: 158 baiti*8 bitti /(1000 Mb/s*106)=1,26 mikrosekundit;
◦ 1538-baidine pakett: 1538 baiti*8 bitti /(1000 Mb/s*106)=12,3 mikrosekundit;
• STM-1: (lisandub 6-baidine PPP protokolli päis)
◦ 126-baidine pakett: 126 baiti*8 bitti /(155,52 Mb/s*106)=6,48 mikrosekundit;
◦ 1506-baidine pakett: 1506 baiti*8 bitti/(155,52Mb/s*106)=77,47 mikrosekundit;
Arvutustest on näha, et et saateviidete suhe on võrdne kanali ribalaiuste suhtega. Võrku
läbiva liikluse puhul tuleb igal juhul arvesse võtta puhverdamise mõju summaarsele
viitele. See tähendab, et süsteemi hilistuse arvutamisel tuleb piirangutena arvestada kahe
halvema stsenaariumi parameetriga: varukanali poolt võimaliku edastusviitega
tööolukorras ning varukanali puhul tekkida võiva puhverdusviitega avariiolukorras.
Puhverdamise seisukohalt tekib ribalaiuste halva sobituse tõttu lisaks oht, et kõikumised
kõrgemate bitikiirustega liidestelt lähtuvas liiklusmahus võivad põhjustada kadusid
saateviite erinevuse tõttu. STM-1 kanali puhul tuleb puhvri suuruse arvutamisel lähtuda
just sellest aspektist, hinnates liikluse voo ühtlust ning kõikumise riski. Ajaga, mis kulub
STM-1 kanalil ühe 126-baidise paketi saatmiseks, on 1 Gb/s ethernet neid suuteline
edastama 6 – seega peab STM-1 liides suutma saatmisega paralleelselt viit paketti
puhverdada.
Testrid töötavad paarikaupa- „tester1“ liikluse generaatorina, mille ülesandeks on tekitada
kasutaja poolt seatud DSCP märgistusega topoloogiat läbiv UDP datagrammide voog ning
fikseerida liikluses esinevad anomaaliad - viited ja kaod. „Tester2“ töötab silmusena,
analüüsides liiklust (paketiloendur ning kaadrivigade loendur) ning suunab paketivoo läbi
võrgu tagasi esimesele seadmele. Käesolevas katses on testrid seadistatud saatma 128-
baidiseid UDP pakette (testri seadistuses lähim võimalus), DSCP-ga „101110“.
Marsruuterite raudvara võimaldab puhvrite osas järgnevat seadistust:
• SDH STM-1 Egress queues: 4 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 0 0 0
57
• ethernet Egress queues: 4 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 0 0 0
Katse lihtsustamise huvides kasutati topoloogia koostamisel puhvrite vaikimisi sätteid.
Seadmete komplekteerimisel ja kokkuühendamisel lähtuti skaleeruva süsteemi loomise
eeldustest (lk. 39) ning ühenduste loomisel kasutati võrguliideste loogilist liitmist nii
magistraalvõrgus kui selle sidumisel juurdepääsusegmendiga. Sel viisil on tagatud edasine
katkestustevaba ribalaiuse lisamine.
Võrgusegmente ühendab modulaarne kommutaator (vt. lk. 54), seega võib täidetuks lugeda
ka plaanilise laiendatavuse kriteeriumi.
marsruuter1#show interfaces descriptionsInterface Admin Link Descriptionge-0/0/0 up up -> marsruuter2 ge-0/0/0so-0/2/1 up up -> marsruuter2 so-0/2/1ge-1/0/0 up up -> kommutaator1 Gi1/1;ae0 up up -> marsruuter2 ae0ae1 up up -> kommutaator1 Po1ae1.68 up up -> Iperf klientae1.69 up up -> tester1as0 up up -> marsruuter2 as0as0.0 up up -> marsruuter2 as0.0
marsruuter2#show interfaces descriptionsInterface Admin Link Descriptionge-0/0/0 up up -> marsruuter1 ge-0/0/0so-0/2/1 up up -> marsruuter1 so-0/2/1ge-1/0/0 up up -> kommutaator2 Gi1/1;ae0 up up -> marsruuter1 ae0ae1 up up -> kommutaator2 Po1ae1.68 up up -> Iperf serverae1.69 up up -> tester2as0 up up -> marsruuter1 as0as0.0 up up -> marsruuter1 as0.0
kommutaator1>show interface descriptionGi2/1 up up marsruuter1 ge-1/0/0Gi6/1 up up tester1Gi6/2 up up Iperf klientPo1 up up marsruuter1 ae1kommutaator2>show interface descriptionGi2/1 up up marsruuter2 ge-1/0/0Gi6/1 up up tester2Gi6/2 up up Iperf serverPo1 up up marsruuter2 ae1
LDP valikul lähtutakse järgnevaist kriteeriumeist:
• vajadus reserveerida ribalaiust;
58
• vajadus rakendada liikluse taastemehhanisme.
Seetõttu langeb valik RSVP-TE (edaspidi RSVP) kasuks. RSVP hõlbustab oluliselt ka
staatiliste LSP-de loomist - võimaldades seda vaid ühe seadistuse reaga LSP alguseks
oleva võrgusõlme kohta. Lisanõudena tõstatub marsruutimisprotokolli kasutamine võrgus -
tingituna vajadusest 32-bitise maskiga alamvõrkude marsruutide (marsruuterite
tagasisidestusaadressid) levitamise järele. Käesoleval juhul osutus sobivaks IS-IS protokoll
- seda tänu marsruuterite tarkvara vaikimisi seadistusel toimiva sidususega RSVP-ga.
7.1 IP marsruutimine ja DiffServ
Dünaamilise marsruutimise algtingimuseks on võrgus töötav marsruutimisprotokoll –
käesoleval juhul täidab seda rolli IS-IS. Kuna katses kasutatavate seademete vaheliste
ühenduste näol on mõlemal juhul (ethernet ja STM-1) tegu ühesammulise (hop)
topoloogiaga, tuleb kanaleid marsruuterite jaoks täiendavalt eristada meetrikute
(vaikeväärtus 10) arvutuskäiku ekvivalentse ribabalaiuse kaasamisega (IS-IS protokolli
seadistuse parameeter reference-bandwidth). Meetriku arvutamiseks kasutatav valem on
järgnev: meetrik=vaikimisi meetrik+(ekvivalentne ribalaius / liidese ribalaius) [Garrett,
lk. 357]
Ribalaiusi arvestava algoritmi põhjal saab 1Gb/s kanali meetrikuks 11 ning varukanalil
vastavalt 16. Alati on eelistatum madalama meetrikuga kanal, seega suundub liiklus
vaikimisi 1Gb/s kanalisse:
marsruuter2> show isis route 192.168.4.1/32 IS-IS routing table Current version: L1: 2393 L2: 441IPv4/IPv6 Routes----------------Prefix L Version Metric Type Interface Via192.168.4.1/32 1 2393 11 int ae0.0 marsruuter1
Viimase rikke korral kaob seda kanalit läbiv marsruut vastavalt marsruutingutabelist ning
liiklus suundub ümber meetrikult järgmisesse - antud näites STM-1 kanalisse:
marsruuter2> show isis route 192.168.4.1/32 IS-IS routing table Current version: L1: 2390 L2: 441IPv4/IPv6 Routes----------------Prefix L Version Metric Type Interface Via192.168.4.1/32 1 2390 16 int as0.0 marsruuter1
Katkestuse korral kulub enamus ajast rikkest kuni marsruutimisprotokolli poolse
reageerimiseni just veaolukorra tuvastamisele ja signaalimisele. Kirjeldatud olukord võib
tunduda petlikult lihtne - OSI esimesel kihil ühendatud liideste puhul on see aeg
59
võrdlemisi lühike - sõltudes seadme võimest tuvastada liideskaardilt signaali kadumine.
Keerukus ilmneb aga juhul kui marsruuterite vahelises topoloogias on kasutusel ka
ethernet protokolli kommutaatoreid. Kuna ethernet'il veel puudub ühene lähenemine
vigade signaalimise osas, võib andmeside katkeda nii, et signaal marsruuterite
võrguliides(t)elt ei kao ning seadmed jätkavad veel mõnda aega liikluse saatmist
mittetöötavasse kanalisse. Sellisel puhul on ajaliselt järgmiseks reageerimisvõimaluseks
alles marsruutimisprotokolli taimeri aegumine (holddown timer), mis võib aga vaikimisi
seadistuses kesta mitmeid sekundeid, tähendades olulist andmekadu. Konvergentsiaja
(convergence) edasine minimeerimine eeldab juba täiendavate protokollide (näiteks BFD)
kasutuselevõttu, kompenseerimaks raudvara puudusi OSI kõrgematel kihtidel. See
võimaldab katkestuste mõju viia alla 1 sekundi läve. [Garrett, lk 375]. Katses kasutatava
loogilise topoloogia põhimõtteline skeem on esitatud joonisel 13.
Ligipääsuvõrgust lähtuv pakett prioritiseeritakse vastavalt selle päises sisalduvale DSCP
väärtusele, mille alusel toimub kogu edasine käitlus kuni sihtpunktini. Esimene liiklust
puhverdav liides on magistraalvõrguga ühendatud liides – tööolukorras 1 Gb/s kanal ning
avariiolukorras STM-1 kanal. Vajalik käitluskonteksti ja puhvrite seadistus marsruuteris on
kirjeldatud lisa E raames.
Joonis 13. IP protokollil rajaneva katse põhimõtteskeem
60
Stsenaarium A Stsenaarium B
STM-1 Täies mahus kasutamata Kasutusel ainult EF liikluse jaoks
Gigabit Ethernet
Täies mahus kasutusel Kasutusel ainult BE edastusklassi liikluse jaoks
Piirang Multimeedia ja võrguhaldus-teabe summaarset ribalaiust põhikanalis tuleb töö-olukorras piirata 155 Mb/s
BE edastusklassi liiklusmahtu põhikanalis tuleb piirata, hoidmaks reservis 155 Mb/s vaba ribalaiust
Tabel 4. Kombineeritud DiffServ'i ja IP marsruutimise kasutusjuhtude ülevaade
Topoloogia rakendamise alternatiive tutvustab tabel 4. Kuna kommutaatorite vahelise
signaalimisega seonduv puudus kehtib ethernet tehnoloogia puhul, on see oluline
argument stsenaariumi B eelistamiseks, samas muudab stsenaariumi rakendamise
keerukaks liikluse eristamise vajadus marsruutimisprotokolli jaoks, millest tulenevalt kaob
IS-IS-e pakutav eelis.
Lähteandmete saamiseks tuleb esmalt fikseerida ülesande püstituses kirjeldatud liikluse
käitumine koormamata infrastruktuuri puhul. Selleks saadetakse testi käigus kumbagi
kanalisse (joonisel 12, lk 54) kaks erinevate parameetritega paketivoogu ja mõõdetakse
testri abil pakettide viidet ja viite värelust (jitter). Lisaks korratakse katset madalama
ribalaiusega erimärgstusega pakettide vooga, hindamaks puhverdamise mõju viitele. Testi
tulemused on esitatud tabelis 5 (lk. 60)
DSCP „000000“Paketi suurus
1500 baiti 128 baiti
Kanal TestvoogViide Värelus Viide Värelus
Min Avg Max Max Min Avg Max Max
155 Mb/s 30 Mb/s 384 387 396 10 67 70 83 14
1Gb/s 30 Mb/s 321 323 323 10 65 65 77 12
155 Mb/s 100 Mb/s 384 387 396 10 69 70 83 14
1Gb/s 100 Mb/s 321 323 323 10 63 65 79 13
DSCP „101110“
155 Mb/s 30 Mb/s 384 387 396 10 69 70 83 14
1Gb/s 30 Mb/s 321 323 333 10 63 65 79 12
Tabel 5. Viide (RTT) mikrosekundites koormamata IP infrastruktuuril
61
Katse tulemustest (vt. tabel 5, lk. 60) järeldub, et paketivoo ribalaius ja puhverdamine
tavaolukorras viitele mõju ei avalda. Seda kinnitavad tulemuste samasused 155 Mb/s ja
1Gb/s kanalite ning erinevate ribalaiustega paketivoogude kombinatsioonides – seda
DSCP väärtustega „101110“ ja „000000“ märgistatud liikluse puhul. Küll aga sõltub
edastusviide paketi suurusest ning kanali ribalaiusest. Viite värelus kasvab pöördvõrdeliselt
paketi suuruse ning kanali ribalaiusega. 1500-baidise paketivoo viite väreluse mõõtmisel
näib väärtuste samasuse olevat tingitud testri poolsest piirangust.
Uurimaks põhikanali rikke korral liikluse terviklust mõjutavaid tegureid, viiakse testritega
30 Mb/s multimeediateenuste liiklust (128-baidised UDP paketid) genereerides läbi katse,
kus simuleeritakse 1Gb/s kanali avariid (optilise kaabli katkestus) ummistusteta olukorras.
Katse käigus kombineeritakse märgistatud ja märgistamata liiklust IS-IS protokolli
vaikimisi ja optimeeritud parameetritega, mõõtes erinevatel juhtudel ilmnevat paketikadu.
Optimeeritud parameetrid tähistavad BFD (bidirectional forwarding detection) protokolli
kasutuselevõttu vähima võimaliku sõnumiintervalliga, milleks on 100 ms. BFD ülesandeks
on lühikese intervalliga sõnumeid saates jälgida kanalikihi dupleksset toimivust ning rikke
korral teavitada sellest IS-IS- protokolli. Lisaväärtusena võimaldab BFD kasutamine tõsta
IS-IS protokolli töö aluseks olevate taimerite intervalle, vähendades sel viisil marsruuterite
arvutuskoormust. IS-IS-e töö optimeerimiseks on marsruuterite IS-IS protokolli
seadistusse lisatud rida: bfd-liveness-detection { minimum-interval 100; }.
Seadistuse mõju hindamiseks mõõdetakse testriga paketikadu (tulemused keskmistatud
nelja katse põhjal) põhikanali rikkele järgnevalt marsruutingu muutmisele kulunud
ajavahemikus. Tulemustest annab ülevaate tabel 6.
Märgistuseta + vaikimisi IS-IS
Märgistatud +vaikimisi IS-IS
Optimeeritud IS-IS parameetrid
rike taastumine rike taastumine rike taastumine rike
Katse 1 5593 0 15326 0 10073 0 5325
Katse 2 22591 0 21286 0 5605 0 6042
Katse 3 23099 0 13859 0 5849 0 7188
Katse 4 13236 0 20054 0 9965 0 10964
Katsete keskmine
16130 0 17631 0 7873 0 7380
Tabel 6. Paketikadu 1Gb/s kanali avarii korral 30 Mb/s koormusel
Katse tulemustest (vt. tabel 6) võib järeldada, et madalal koormusel töötava kanali rikke
korral DiffServ'i olemasolu taasteprotsessi tulemuslikkust ei mõjuta. IS-IS-e optimeeritud
62
parameetritega läbi viidud katsete keskmistatud tulemuse põhjal osutub olulisemaks
mõjuriks hoopiski marsruutimisprotokolli seadistus, millest sõltub rikke registreerimise
kiirus. Mida lühem on reaktsiooniaeg, seda väiksem on kaotatud pakettide arv. Vajaduseta
rikkele reageerida – antud näites põhikanali töö taastumisele järgnevalt liikluse tagasi
asumine põhikanalile – toimub marsruutingu muutmine andmekadudeta.
Teise katse eesmärgiks on vaadelda võrgutopoloogia käitumist ummistuse tingimustes.
Selleks on paralleelselt kasutusel Iperf tarkvara ning võrgutestrid. Iperf'i abil tekitatakse
topoloogias 800 Mb/s best-effort (edaspidi BE) liikluse voog. Genereerides testriga
samaaegselt multimeediateenustele omast liiklust, juhitakse topoloogiasse vaheldumisi 30
Mb/s ribalaiusega 128-baidiste UDP pakettide vooge nii EF kui BE edastusklassi
kasutatades –vastavalt „101110“ ja „000000“ DSCP väärtustega. Testri abil fikseeritakse
meetmete mõju (viide, viite värelus, paketikadu) multimeediateenuste liiklusele.
Tulemused, millest annab ülevaate tabel 7 leheküljel 62, iseloomustavad olukorda
ootuspäraselt. Kaod ja viited väljaspool rikkest tingitud ummistusi ei sõltu DiffServ'ist.
Võrreldes käesoleva katse tulemusi tühikäigul mõõdetud väärtustega (vt. tabel
5,leheküljel 60), on näha, et antud katses on viide ligikaudu 4 korda suurem, samas
võrrelduna DiffServ'i puudumisega, aga suurusjärke madalam. Ummistusest tulenevad
andmekadu õnnestus EF edastust kasutades täielikult vältida.
Kanal CoSViide (mikrosekundites)
Viite värelus (mikrosekundites) Paketikadu
keskmine maksimaalne keskmine tippväärtus
155Mb/s - 10341 23795 164 295 612
155Mb/s BE 8990 22621 426 952 283
1Gb/s BE 1715 5143 33 146 6
155Mb/s EF 228 340 33 258 0
1Gb/s EF 121 220 33 143 0
Tabel 7. DiffServ'i tulemuslikkus kombineerituna IP marsruutimisega
Täiendava korrelatiivsuse huvides ning demonstreerimaks võrgukihil ilmneva viite mõju
OSI mudeli kõrgematele kihtidele viidi lisaks eelnenud katsetele läbi ICMP hilistuse test
(Linux tööjaamade vahel) ping utiliidi abil järgnevates QoS seadistustes (vt. lisa G):
1. marsruuterite CoS tugi puudub,
2. CoS-i toega BE edastusklassis,
3. CoS-i toega EF edastusklassis.
63
QoS
EdastusklassViide (millisekundites)
minimaalne keskmine maksimaalne standardhälve
- - 2,6 9,93 22,83 3,48
+ BE 1,78 9,35 20,47 3,45
+ EF 0,23 0,53 1,46 0,2
Tabel 8. DiffServ'i mõju rakenduskihile ping utiliidiga tehtud katse põhjal
Ping utiliidi abil saadud tulemused kinnitavad eelnevate katsete tulemusi, tõestades
keskmise viite ja standardhälbe põhjal BE edastuse ja DiffServ'i puudumise samaväärsust.
Käesoleva katse tulemus iseloomustab peamiselt viite mõju rakendustarkvarale. Nagu ka
edastusklasside lõikes keskmistatud väärtuste põhjal näha, parandab DiffServ'i kasutamine
ummistuse olukorras tarkvara poolt kogetavat keskmist viidet paketi saatmisel ligikaudu 20
korda, vähendades seejuures viite varieeruvusi enam kui 20 korda.
7.2 Eraldi LSP-d BE ja EF edastusklasside transpordiks (L-LSP)
L-LSP lähenemist kasutades luuakse magistraalvõrgus iga edastusklassi jaoks eraldi LSP.
Katsetopoloogia põhimõtteline skeem on esitatud joonisel 14. On näha, et
juurdepääsuvõrgust lähtuvad IP paketid kapseldatakse segmentide sidumispunktis MPLS
kaadrisse ning kantakse läbi tuumikvõrgu ühe sammuga (hop). LSP valik (EF, BE) sõltub
IP paketi DSCP märgistusest, MPLS võrgust väljudes jätkub pakettide käitlus algse DSCP
väärtuse alusel. Labori piiratud riistvararessursid välistavad katses PHP (pen-ultimate hop
popping) kasutamise võimaluse, kuna testtopoloogia koosneb ainult kahest marsruuterist,
tähendaks MPLS päise eemaldamine eelviimases võrgusõlmes liikluse edastamist IP
marsruutimise teel. Vaikimisi kasutatava PHP meetodi keelamiseks lisati marsruuterite
MPLS protokolli seadistusse rida: explicit-null;. Nii LSP-de loomiseks vajalik
seadistus kui DiffServ parameetrite määrangud on kirjeldatud lisa F raames. On näha, et
antud juhul osutub seadistus oluliselt keerukamaks kui IP marsruutimise näites (vt. lisa E).
Tuleb otsustada, kas kanaleid eristada rangelt põhi- ning varukanaliks või rakendada neid
paindlikkuse huvides paralleelselt. Esitatud piirangute kontekstis osutub valituks teine
stsenaarium. BE LSP ribalaius tuleb piirata 830 Mb/s, mahutamaks STM-1 rikke korral
seda mööda edastatavat kõrgema prioriteediga liiklust ja jätmaks ressurssi ka
võrguhaldusliiklusele. Kasutusjuhu olulisimaks miinuseks on mahukate teenuste liikluse
kaotamine rikke vältel, mis viitab vajakajäämisele võrgu disainis. See puudus on ühtlasi
kinnituseks eelnevalt esitatud väitele (lk. 40), et kanalite kasutuse tõhustamiseks peavad
64
ribalaiused võrgusegmendis olema sobitatud.
LSP-de jagamiseks kanalite vahel on mitmeid võimalusi, millest annab ülevaate tabel 9.
Stsenaarium A Stsenaarium B
STM-1 Täies mahus kasutamata Kasutusel EF LSP jaoks
Gigabit Ethernet
Täies mahus kasutusel BE ja EF LSP-de jaoks
Kasutusel BE LSP tarbeks, 155 Mb/s vaba ribalaiust avariitaasteks
Piirang EF ja AF LSP-de liikluse kogumaht peab olema vähem kui 155 Mb/s
EF liikluse jaoks tuleb 1Gb/s kanalil reservis hoida 155 Mb/s ribalaiust. 1Gb/s kanali rikke korral
Tabel 9. Ülevaade LSP-de võimalikest paigutustest katsetopoloogial
Lähteandmete kontrollimiseks ning eelmise katsega võrdlusmaterjali saamiseks
fikseeritakse esmalt liikluse käitumine koormamata infrastruktuuril. Selleks saadetakse
testi käigus kumbagi kanalisse kaks erinevate parameetritega (128- ja 1500-baidised
paketid) paketivoogu, mõõtes testri abil pakettide poolt kogetavat viidet ning selle värelust
(jitter). Lisaks korratakse katset madalama ribalaiusega (EF edastuseks märgistatud)
testliiklusega, hindamaks puhverdamise mõju viitele tööolukorras – tulemused on esitatud
tabelis 10. Kinnituseks, et magistraalvõrgus liigub MPLS liiklus annab segmendist kogutud
nuhkutiliidi tcpdump väljund lisas H.
Joonis 14. L-LSP katse põhimõtteskeem
65
EXP „0“Paketi suurus
1500 baiti 120 baiti
Kanal TestvoogViide Värelus Viide Värelus
Min Avg Max Max Min Avg Max Max
155 Mb/s 30 Mb/s 384 387 396 10 69 71 173 102
1Gb/s 30 Mb/s 321 323 331 8 65 66 85 21
155 Mb/s 100 Mb/s 384 387 398 12 69 71 85 18
1Gb/s 100 Mb/s 321 323 333 10 65 66 79 14
EXP 2 „010“
155 Mb/s 30 Mb/s 384 387 396 10 69 71 83 12
1Gb/s 30 Mb/s 321 323 333 10 65 61 85 18
Tabel 10. Viide (RTT) mikrosekundites koormamata MPLS võrgus
Tulemused näitavad, et viide, võrrelduna IP protokolli kasutamisega (vt. tabel 5 lk. 60),
kohati kasvab, mis on seletatav 4-baidise MPLS-i päise lisandumisega. Arvutuslikult
mõjutab MPLS päise lisandumine kasutatavate liideste puhul edastusviidet järgnevalt:
• 1Gb/s ethernet:
◦ 124-baidine pakett: 124 baiti*8 bitti /(1000 Mb/s*106)=0,99 mikrosekundit;
◦ 1504-baidine pakett: 1504 baiti*8 bitti /(1000 Mb/s*106)=12,03 mikrosekundit;
• STM-1:
◦ 130-baidine pakett: 130 baiti*8 bitti /(155,52 Mb/s*106)=6,69 mikrosekundit;
◦ 1510-baidine pakett: 1510 baiti*8 bitti /(155,52 Mb/s*106)=77,62
mikrosekundit;
Uurimaks põhikanali rikke korral liikluse terviklust mõjutavaid tegureid, viiakse testritega
30 Mb/s multimeediateenuste liiklust (128-baidised UDP paketid) genereerides läbi katse,
kus simuleeritakse 1Gb/s kanali avariid (optilise kaabli katkestus) madala ressursihõive
olukorras. Katse käigus kombineeritakse EF edastusklassi kandva LSP liiklust MPLS
poolt võimaldatavate vaikimisi ja optimeeritud taastemehhanismidega. Tabelis 11 on
esitatud nii 1Gb/s kanali kui STM-1 kanali katkestuse tulemusena LSP rajavahetusel
tekkivad paketikaod. Kuna käesolevas näites kasutatavad LSP-d ei olnud seadistatud
algsele kanalile tagasi pöörduma, jäid nad ka taastumise järgselt uuele marsruudile.
Seetõttu tuli nende asukoha ennistamiseks tekitada katkestus ka varuteele. Viimase mõju
liiklusele tähistabki tabelis tulp taastumine . Katkestuste vaheline intervall katses oli
ligikaudu 5 minutit.
66
EF LSP EF LSP ja fast reroute
rike taastumine rike taastumine
Katse 1 7003 3313 5178 6702
Katse 2 5837 4843 1021 4512
Katse 3 5181 4631 1201 5213
Katse 4 5156 5361 1381 5181
Katsete keskmine 5794 4537 2195 5402
Tabel 11. MPLS-i poolt pakutavate taastemeetodite tõhusus
Tulemuste põhjal võib järeldada, et fast reroute parameeter omab minimeerivat mõju
keskmisele EF liikluse paketikaole kanali rikke korral.
Kolmandas katses vaadeldakse MPLS-il põhineva topoloogia käitumist ummistuse
tingimustes. Iperf'i abil tekitatakse 800 Mb/s best-effort (edaspidi BE) liikluse voog.
Testritega genereeritakse võrku 30 Mb/s ribalaiusega 128-baidiste UDP pakettide vooge
EF ja BE DSCP märgistusega ja fikseeritakse ummistuse mõju kumbagi edastusklassi
liiklusele. Katse tulemuste (vt. tabel 12 lk. 66) tõlgendamisel ei tohi unustada, et vea
korral ei taastu BE LSP enne kui tema jaoks on olemas piisavalt vaba ribalaiust. Antud
näites seda 1Gb/s kanali rikke ajal pole, mis selgitab ka 100% BE liikluse kadu.
Kanal CoSViide (mikrosekundites)
Viite värelus (mikrosekundites) Paketi-
kadu keskmine maksimaalne keskmine tippväärtus
155Mb/s - 70,33 89,14 20,48 0 0
155Mb/s BE - - - - 100%
1Gb/s BE 229,91 599,09 32,77 184,32 0
155Mb/s EF 70,31 278,08 0 217,09 0
1Gb/s EF 115,78 250,93 32,77 186,37 0
Tabel 12. DiffServ'i tulemuslikkus kombineerituna MPLS edastusega
Välistades ummistuse võimaluse, muudab lähenemine ülearuseks DiffServ'i kasutamise
ning selgitab viite muutumatust STM-1 kanalis - sõltumata puhverdamisest. 155 Mb/s
kanalisse jääb vaid EF liiklus ja ummistuse oht puudub. Olulisimaks puuduseks on BE
liikluse täielik kadu. Sõltuvalt EF liikluse mahust STM-1 kanalis, saab sealset vaba
ribalaiust lugeda ebaefektiivseks ressursside kasutuseks. Diffserv'i peamine väljund antud
katses on ummistuse mõju elimineerimine EF liiklusele STM-1 kanali rikke korral, kui
kogu liiklus asub täitunud 1 Gb/s kanalis. Mõõtmiste põhjal vähendab DiffServ kasutamine
67
EF liikluse paketi viidet keskmiselt kaks korda võrrelduna samadel tingimustel BE
edastusklassi liiklusega sooritatud testidega.
7.3 Katsetulemuste analüüs
Ülesande püstituses kirjeldatud kriteeriumidele vastav hinnang on toodud tabelis 13.
IP marsruutimine ja DiffServ MPLS LSP-d ja DiffServ
rikke mõju EF
liiklusele
liiklus taastatakse võrreldava QoS-ga;taaste kiirusel on määrav veale reageerimise kiirus (IS-IS);DiffServ kasutamine on vajalik;rikke eemaldamisel liiklus ennistub; ennistumine põhikanalile kadudeta;
liiklus taastatakse ekvivalentse QoS-iga;taaste kiirusel on määrav veale reageerimise kiirus (fast reroute);DiffServ kasutamine ei ole vajalik;liiklus ei ennistu automaatselt;LSP rajavahetusel toimub katkestus;
rikke mõju BE liiklusele
liiklus taastub võimaluste piires;esmatähtis on EF liikluse käideldavus;DiffServ kasutamine on vajalik;
BE liiklust ei taastata, lihtsustades selle arvelt EF liikluse taastet;DiffServ kasutamine on vajalik;
lahenduse rakenduslikud eelised/puudused
– ajaliselt ennustamatu tulemus;– keerukam tööpõhimõte;+ lihtne seadistada;+ BE liiklus säilib rikke ajal osaliselt;+ efektiivsem ressursikasutus;
+ deterministlik tulemus (signaalimine);+ lihtsalt mõistetav tööpõhimõte;– keerukam seadistada;– BE liiklus kaotatakse rikke ajaks;– ebaefektiivne ressursikasutus;
Tabel 13. Hinnang katse tulemustele püstitatud kriteeriumide põhjal
Katsete tulemuste põhjal on tabelis 13 välja toodud mõlema lähenemise eelised ja
puudused. IP protokolli kasutamisel ilmnenud eelised näivad (erinevalt MPLS
kasutusjuhust) üles kaaluvat oma puudused.
Nagu katsetulemuste võrdlusest (vt. joonis 15 (lk. 67) näha, on DiffServ'i suhteline mõju
Joonis 15. DiffServ'i mõju viitele rakenduskihil
QoS puudub BE EF
0
5000
10000
15000
20000
25000
min viidekeskmine viidemaksimaalne viide
68
ummistuse olukorras rakenduskihi tööle märkimisväärne. EF edatusklassi liikluse viite
varieeruvus väheneb suurusjärke, olles keskväärtuselt 10 korda madalam kui parima
võimaliku edastuse olukorras. QoS puudumisel ning BE edastusklassi kasutamisel nii suurt
erinevust keskmiste vahel pole - vaid viite miinimum ja maksimum on esimesel juhul 10%
kõrgemad.
Vaadeldes põhilisi erinevusi IP ja MPLS kasutamisel, on joonise 16 põhjal näha, et teisel
kasutusjuhul on hilistuse keskväärtus oluliselt madalam. Seda hoolimata asjaolust, et
koormamata topoloogia puhul oli MPLS puhul (vt. tabel 10 lk. 47) viide, võrrelduna IP
protokolli põhise edastusega (vt. tabel 5 lk. 23), mõnevõrra kasvanud. See erinevus on
tingitud BE liikluse puudumisest võrgus 1Gb/s kanali rikke puhul.
Siinkohal peab tulemuste tõlgendamisel meeles pidama skaleeruvuse aspekti ja vaatama,
kuidas saavutatud tulemused muutuksid võrgutopoloogia (keerukuse) kasvades.
Käesoleval juhul oli nii juurdepääsu- kui magistraalvõrgu segmentide seadistus labori
mõõtmete tõttu koondatud samadesse seadmetesse ning tundus tänu sellele oluliselt
mahukam. Edastusloogika puhul oli olukord vastupidine – labori ei ole piisavalt ulatuslik
modelleerimaks marsruutingutabelite mahu kasvu ja selle mõju võrguseadmete jõudlusele
(pikem otsiaeg). Suurem arv võrgusõlmi (suurem hulk keerukamaid sisend-väljund
operatsioone) võimaldaks adekvaatsemalt hinnata MPLS-i võimalusi traditsioonilise IP-
marsruutimise taustal. Peamiselt eeldus rajaneb signaalimise poolt tagatavale
ennustatavusele - fast reroute tulemuslikkus sõltub MPLS LSP otspunktidest, erinevalt
marsruutimisprotokollist, mille puhul viide kujuneb kompleksselt kõigi topoloogias
osalevate marsruuterite kombineeritud jõudlusest topoloogiamuudatuse arvutamisel ning
sidestamisel. Tulemused annavad alust oletada, et katsetes kasutatud kahest seadmest
Joonis 16. Hilistuse erinevus IP ja MPLS kasutusjuhtudes
1 2 3
0
200
400
600
800
1000
1200
1400
1600
1800
2000
IP keskmine viideMPLS keskmine viide
69
koosnev topoloogia polnud nende mõju ilmnemiseks piisavalt ulatuslik.
Paketikadudest erinevate seadistuste puhul annab ülevaate joonis 17. Erinevalt DiffServ'i
tõhususest ummistuse olukorras nägime tabeli 6 (vt. lk. 61) põhjal, et DiffServ'i mõju
katkestuse tagajärgede minimeerimiseks vaba ribalaiuse olemasolul puudub. Kõigi
kasutatud meetodite lõikes paketikadusid hinnates näeme, et jällegi on võitjaks MPLS-i
vahendid. Nagu joonisel 17 näha, läheneb LSP ümberlülitusaeg ilma fast reroute'i
kasutamata samasle suurusjärgule, mis optimeeritud parameetritega IS-IS protokolli puhul.
Fast reroute suudab sellest hoolimata tagada täiendava eelise ning LSP ümberlülituse aega
2,6 korda lühendada.
Selgus, et RSVP eeliseid on DiffServ arhitektuuriga küllalt keeruline kombineerida. RSVP
eelised ilmnevad olukorras, kus osutub vajalikuks voopõhine otsustamine võrguressursile
ligipääsu üle. Lähenemise eelised ilmnevad ummistuse eelses olukorras, kus võrku ei
lubata luua uusi LSP-sid; teisalt on sellise liiklussignatuuriga klassiklalise pakettsidevõrgu
näitel küllalt vähe. Pigem on lähenemine suunatud (tänu ilmsele analoogiale ATM võrgule
omaste teenustega) just pseudotraat-teenuste pakkumisele, mille puhul eksisteerib palju
paralleelseid, ribalaiuselt võrreldavaid vooge. Sellesse konteksti on klassikaliste IP
teenuste liiklust väga keeruline paigutada– peamiselt selle keskmistatult pideva iseloomu
ja suhteliselt (üli)suure haaratava ribalaiuse tõttu.
Lisaks ei paku LSP-de loomine (ja termineerimine) kõrvutiasuvate võrgusõlmede
vahele olulist eelist, pigem kaasneb negatiivse kõrvalmõjuna topoloogia halduskeerukuse
kasv:
• täiendavate MPLS edastuskihtide arvelt,
• DiffServ'i töötlus peab LSP-de mõlemas lõpp-punktis toimuma nii tuumik- kui
juurdepääsuvõrgu tasemel.
Joonis 17. Erinevate tegurite mõju paketikaole avariist taastumisel
Katse 1 Katse 2 Katse 3 Katse 4
0
5000
10000
15000
20000
25000
Märgistuseta + v aikimisi IS-ISMärgistatud + v aikimisi IS-ISMärgistuseta + optimeeritud IS-ISMärgistusega + optimeeritud IS-ISEF LSPEF LSP ja f ast reroute
70
Ressursside efektiivse kasutuse määr sõltub peamiselt kanalite ribalaiustest ning EF liikluse
mahust. Kui EF liiklust ei kasutata just kogu kanali kogu ulatuses, tuleks leida
täitematerjali ülejäänud kanali jaoks. Suurte erinevuste puhul kanalite ribalaiuses on see
küllalt keerukas, kuna tavaolukorras moodustaks AF klass 1Gb/s ribalaiusest oluliselt
suurema osa kui 155 Mb/s kanalisse mahuks. Samuti peaks sama edastusklassi raames
käideldav liiklus (erandiks on BE liiklus) leidma terviklikku käsitlust. Kui vajadus AF
klassi teenuste järele, (va. võrguhaldus) puudub, saab ribalaiuse napi ülejäägi ära kasutada
BE klassi jaoks. 6:1 suhtes kanalite kasutamisel tekib BE klassi liiklust kasutavatel
lõpptarbijatel paketikadu sõltuvalt BE liikluse mahust kanalis. Sellele annab lõpliku
vastuse erinevate teenuste liikluse osakaal operaatori pakettsidevõrgus.
Teiseks rõhutasid MPLS-i abil saavutatud kesised tulemused skaleeruvuse olulisust,
tõestades, et tarvitatavad meetmed peavad olema sobitatud süsteemi keerukusega. Antud
näites kasutatud labor polnud MPLS-i eeliste ilmnemiseks piisavalt mastaapne.
Kolmandaks leidis kinnitust asjaolu, et QoS-i mõiste laiemalt levinud käsitlus - kitsalt
võrguliikluse diferentseeritud käitluse kontekstis – on selgelt üle tähtsustatud. Võrgu
korrektse toimimise tagamisel on hoopis olulisemaks eelduseks infrastruktuuri ja sellega
seotud mehhanismide eesmärgipärane ja terviklik disain.
Kogemus katsetest näitab, et pakettside QoS-i tagamine tuleb juurutada ka L2 võrgu
töösse:
• esiteks ilmnes töö käigus pudelikael marsruuteri ja kommutaatori vahel. Kuna
kanalisse (vt. lisa D) kommutaatori ja marsruuteri vahel tuleb ära mahutada nii
testri kui ka liiklusegeneraatori liiklus, tingib see olukorra, kus seadmetest lähtuv
summaarne liikluse maht ei saa ribalaiuselt ületada 1 Gb/s. Et juurdepääsuvõrgu ja
tuumikvõrgu ribalaiused olid sobitatud, raskendas see ummistusega seotud
veastsenaariumide esitamist 1 Gb/s kanali puhul;
• täiendava asjaoluna selgus vajadus muuta kommutaatori poolselt CoS käsitlust.
Nimelt kirjutab seade vaikesätetega üle edastatavates kaadrites sisalduvate IP
pakettide DSCP märgistuse, viies selle kujule „000000“ ja „võrdsustab“ sel viisil
seadet läbiva liikluse. Keelamiseks tuli kommutaatori seadistusse lisada rida:
„no qos rewrite ip dscp“.
Teine järeldus oli, et täiesti mugandatud DiffServ klasside kasutamine osutub
ebamugavaks nii ülevaatlikkuse kui seadistuse standardsuse (ühilduvus) poolelt.
Eelistatum on olukord, kus kasutatakse ära seadmete poolt vaikimisi pakutavate
71
edastusklasside võimalused.
Kokkuvõtteks - katsed tõid küllaltki hästi esile pudelikaelade mõju tegelikku ulatuse võrgu
tööle – ka võrguhalduse ja mahtude planeerimise osas. Teadagi seostub madalama
ribalaiusega varukanalite kasutamine peamiselt kuluefektiivsuse kriteeriumiga, samas ei
tohi unustada universaalset reeglit – erandid muudavad süsteemi keerukamaks. Ehkki
sellist varukanalit on põhimõtteliselt võimalik kasutada 1/6 põhikanali liikluse
varundamiseks, tuleb napi ribalaiuse kasulikul viisil töösse rakendamiseks palju
ressurssi suunata haldustoimingutesse. Siit ka järeldus, et varukanal ribalaiuse suhtega
6:1 ei ole pakettsidevõrgus soovitav nähtus.
72
8 Kokkuvõte
Multiteenuste infrastruktuuri realiseerimise keerukuse tingib vajadus tagada pakutavatele
teenuse liikidele ühtsetel alustel tingimused, mis on omased rakendusspetsiifilistele
monofunktsionaalsetele võrkudele. Eesmärgi äriline tahk on selge – võimaldada
sideoperaatorile infrastruktuuride kombineerimise tulemusena võitu tegevuskuludes ja
osalt asendava tulubaasi tekkes klassikalise IP teenuste ärimudeli kõrvale. Viimane osutub
üldjuhul piisavaks, kuid ei suuda peamise puudusena pakkuda piisavalt edastusgarantiisid
äriklientide riskide maandamiseks.
Universaalne infrastruktuur lihtsustab ka uute teenuste turule toomist. Et aga
universaalsus ei langeks iseenese ohvriks, peavad pakutavad võimalused olema piisavad.
Peamine tehnoloogiline väljakutse seisneb siin viitetundlike reaalajarakenduste jaoks
piisava, paketipõhise edastuse tagamisele - seda nii jooksva andmeedastuse, teenuste
koostoimivuse kui avariitaaste seisukohalt. Ribalaiuse tõstmise abil seda olukorda ei
lahenda – pakettside probleemiks jääb endiselt pakutava edastuse parameetrite
garanteerimatus. Võimalus olukorda parandada ribalaiust lisamata eeldab pakettsidevõrgus
järgnevate nõuete täitmist:
• paketi keskmist ooteaega väljuval võrguliidesel tuleb vähendada erinevate
edastusnõuetega paketivoogude multiplekseerimise teel;
• fikseeritud viitega liikluse edastamisel tuleb arvestada viite sõltuvust edastuspuhvri
mahust;
• taastemehhanism peab olema teenusega sobitatud – rakenduma enne kui ilmneb
tajutava kvaliteedi langus teenuse najal toimiva rakenduse töös;
• teenuste jaoks peab eksisteerima võimalus ribalaiuse reserveerimiseks.
Teise majandusliku küljena käsitletav tegevuskulude ajastamine infrastruktuuri
mastaapsema laiendamise ettevalmistusel sõltub projekti finantsanalüüsist – võtmesõnaks
teenuste diferentseeritud käitluse juurutamisel laiendamise edasilükkamiseks saab
majanduslik teostatavus.
Töö põhjal selgus, et IP võrgu funktsionaalsusest jääb kirjeldatud eesmärkide saavutamise
alusena väheks ning evolutsioonis tuleb teed anda MPLS paradigmale. Klassikaline IP võrk
taandub sarnaselt telefoni- ja televisioonivõrgule üheks paljudest MPLS infrastruktuuri
poolt võimaldatavatest teenustest. Olulise lisaväärtusena pakub MPLS paindlikke lahendusi
seni IP-teenuste pealisehitisena realiseeritud „parimatele võimalikele“ privaatvõrgu-
73
teenustele L3-VPN-, ning traditsiooniliselt jäiga liigendusega sünkroonsetele
sidemeetoditele pseudotraat-teenuste näol.
Töö praktilise osa tulemusena leidis kinnitust fakt, et teenusekvaliteedi tagamiseks ei piisa
ainult ummistuste riski maandamisest - ehkki see tundub olevat siht, mis on hetkel QoS-i
mõistesse pakettside kontekstis kõige tugevamalt kinnistunud. Samuti ilmnes, et DiffServ
arhitektuuri juurutamisega kaasneb märkimisväärne lisanduv haldusressursi kulu.
Ainuüksi mahtude osas tuleks sellisel juhul planeerimistöös lähtuda summaarse ribalaiuse
asemel ressursihõivest kõigi kasutatavate edastusklasside lõikes – seda nii juurdepääsu-
kui tuumikvõrgus. Kuna DiffServ'i eelised ilmnevad alles avariiolukorras, ei tundu selline
orienteeritus tagajärgede kõrvaldamisele mõistliku lahendusena. Hoopis olulisemaks tuleb
pidada terviklikku lähenemist võrgu disainile ning selle vastavust planeeritavate teenuste
poolt osutatavatele nõuetele.
Võrgu eesmärgipärase toimivuse seisukohalt on esmatähtis orienteeritus tehnoloogilise
lahenduse skaleeruvusele, mis seostub planeeritava süsteemi kasvuga kaasnevate
muutustega. Ka laborikatsete tulemuste põhjal selgus, et lihtsa süsteemi näitel osutub
tõhusamaks olukorra lahendamine pärandtehnoloogia vahendeid kasutades. Siit ka järeldus,
et planeeritavate süsteemide mudelite toimivust tuleb alati kontrollida võimalikult
reaalsetes tingimustes, leidmaks (kas või arvutuslikult), millal ning millistest teguritest
tingituna ilmnevad esimesed piirangud.
Kriitilist meelt tuleb ilmutada kuluefektiivsuse jälgimisel – ärilise edu aluseks on küll
tulusus, kuid ülereageerimisest tingitud pudelikaelad võivad näilist võitu pakkudes
halduskulusid, läbi süsteemi keerukuse ja haldusressursi vajaduse kasvu ning eranditest
tuleneva veakindluse vähenemise, hoopiski suurendada.
74
Kasutatud kirjandusIEEE standard 802.1D: Media Access Control (MAC) Bridges
(http://standards.ieee.org/getieee802/download/802.1D-2004.pdf) 12.2009
IEEE standard 802.1Q: Virtual Bridged Local Area Networks
(http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf) 12.2009
ITU-T G.1010: End-user multimedia QoS categories
(http://www.itu.int/rec/T-REC-G.1010-200111-I ) 11.2009
ITU-T X.902: Information technology – open distributed processing – reference model: foundations (http://www.itu.int/rec/T-REC-X.902-199511-S) 11.2009
RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers(http://www.apps.ietf.org/rfc/rfc2474.html ) 09.2009
RFC 2597: Assured Forwarding PHB Group. ( http://www.apps.ietf.org/rfc/rfc2597.html )
09.2009
RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection
(http://tools.ietf.org/html/rfc2991) 05.2010
RFC 3168: ECN bits specification. (http://www.rfc-editor.org/rfc/rfc3168.txt ) 24.10.2009
RFC 3246: An Expedited Forwarding PHB (Per-Hop Behavior)
(http://www.apps.ietf.org/rfc/rfc3246.html) 09.2009
RFC 3270: Multi-protocol label switching (MPLS) support of differentiated services
(http://www.apps.ietf.org/rfc/rfc3270.html) 09.2009
Garret, A. JUNOS cookbook. O'Reilly 2006, 657 lk.
Guichard, J. Faucheur, F. Vasseur, J.P. Definitive MPLS network designs. Cisco Press
2005, 516 lk.
Laaneoks, E. Sissejuhatus võrgutehnoloogiasse. TÜ kirjastus 2008, 200 lk.
Minei, I. Lucek, J. MPLS-enabled applications. John Wiley and Sons 2006, 406 lk.
Lionel, M. Xiao, X. Internet QoS: a big picture. 25 lk. (www.cs.columbia.edu/~zwb/my/oral/qos/netmag/qos.pdf) 18.09.2009
Bhaniramka, Jain, R. P. Sun, W. QoS using traffic engineering over MPLS: an analysis. 4 lk. (http://www.cs.wustl.edu/~jain/papers/ftp/mpls-te-anal.pdf) 14.09.2009
75
Gibson, M. The management of MPLS LSPs for scalable QoS Service Provision 2000 (http://www.softarmor.com/wgdb/docs/draft-gibson-manage-mpls-qos-01.txt) 21.09.2009
Barakovic J. Bajric H., Husic, A. QoS desing issues and traffic engineering in next generation IP/MPLS network. ConTEL 2007. IEEE publication. IEEE Xplore. 09.2009
Fineberg, V. QoS Support in MPLS Networks. MPLS/Frame Relay Alliance White Paper
2003, 26 lk (http://www.ipmplsforum.org/tech/MPLSQOSWPMay2003.pdf) 05.2009
Hallerman, D. Video, Bandwidth and Online Advertising. eMarketer Magazine, 14.10.2008 (http://www.emarketer.com/Article.aspx?R=1006610) 10.2009
Heinlein, S. Delivering predictable IP communications: QoS for VoIP. Juniper Networks, 05.2005 (http://www.juniper.net/solutions/literature/white_papers/200126.pdf) 11.2009
Odinma, A.C., Oborkhale, L. Quality of Service Mechanism and Challenges for IP Networks. Pacific Journal of Science and Technology. 7(1):10-16. 2006.(http://www.akamaiuniversity.us/PJST7_1_10.pdf) 11.2009
MPLS VPN QoS design. Cisco Systems.
( http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/VP NQoS.html ) 11.2009
Quality of Service for Multi-Protocol Label Switching Networks. Cisco Systems.
(http://www.cisco.com/en/US/tech/tk828/technologies_q_and_a_item09186a00800a43f5.shtml ) 20.01.2010
Implementing Quality of Service Policies with DSCP. Cisco Systems
(http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml#dscpandassuredforwardingclasses) 12.2009
Cisco BTS 10200 Softswitch Command Line Interface Reference. Appendix H. Cisco Systems. 12 lk.
(http://www.cisco.com/en/US/docs/voice_ip_comm/bts/4.1/command/reference/93PktCbl.p
df) 04.2010
Park, K. I. QoS in packet networks. 2005 Springer Inc. 251 lk.(http://books.google.ee/booksid=dXxGdDn2vnYC&pg=PA216&lpg=PA216&dq=qos+in+mpls+capable+networks&source=bl&ots=SUQmwkADSW&sig=sJ5d8QHItjxnfhuF7jl4onT9Dy8&hl=et&ei=Md8VSpWjE8mX_Aae0b3zDA&sa=X&oi=book_result&ct=result&resnum=6#PPP1,M1) 11.2009
Hattingh, C.,Szigeti, T. End to end QoS network design: Quality of Service in LANs, WANs, and VPNs. Cisco Press 2005, 715 lk.(http://books.google.ee/booksd=WOPoD6cGXEsC&pg=PA82&lpg=PA82&dq=cos+ethernet+frame&source=bl&ots=yWdYY4c46c&sig=pAoGoWvg41RIdhhihEjNZgT3HdU&hl=et&ei=VQKoStf1CJPcbjzazACA&sa=X&oi=book_result&ct=result&resnum=3#v=onepage&q=cos%20ethernet%20frame&f=false) 10.2009
76
Chao, J.,Guo, X. Quality of service control in high-speed networks. John Wiley and Sons 2002, 371 lk.(http://books.google.ee/booksid=UIGR5RiurQC&pg=PA6&lpg=PA6&dq=qos+in+mpls+capable+netw orks&source=bl&ots=TPrPyAUhDi&sig=bpkRI5VjEz7iupSIoWLt1eTNWk&h l=et&ei=0dwVSqbFMMiB_AaQ_MX0DA&sa=X&oi=book_result&ct=result&resnum=8#PPP1,M1) 11.2009
SmartClass ethernet tester datasheet. JDSU, 2006, 8 lk. ( http://www.jdsu.com/product-literature/smclassethgige_ds_acc_tm_ae.pdf ) 06.05.2010
SmartClass ethernet tester user's guide. JDSU 2006, 76 lk. 06. 05.2010
eTeatmik: IT ja sidetehnika seletav sõnaraamat. (http://vallaste.ee) 17.05.2010
Ernie's Quality of Service Guide. (http://www.pbxphreak.com/QoS/) 11.12.2009
77
LISA A – IEEE soovitused CoS väärtuste defineerimiseks [Ernie]
User priority 802.1D 802.1Q
Traffic Type Traffic Type
0 Best Effort Best Effort
1 Background Background
2 Spare Excellent Effort
3 Excellent Effort Critical applications
4 Controlled Load Video
5 Video Voice
6 Voice Internetwork control
7 Network Control Network Control
78
LISA B – ülevaade IP paketi päise ToS väljast [Ernie, RFC 791]
Precedence value Type of Service
0 Routine
1 Priority
2 Immediate
3 Flash
4 Flash override
5 CRITIC/ECP
6 Internetwork Control
7 Network Control
79
LISA C – DiffServ 'i seos RFC 791-ga [Cisco BTS H-12]
80
LISA D – laborikatsetes kasutatud võrgutopoloogia
81
LISA E – IP marsuutimise katses kasutatud CoS seadistus
marsruuter2>show configuration class-of-serviceclassifiers { dscp dscp_classifier { forwarding-class expedited-forwarding { loss-priority low code-points 101110; } } } drop-profiles { BE-drop { interpolate { fill-level [ 60 85 ]; drop-probability [ 1 100 ]; } } } interfaces { * { scheduler-map queue_exit; unit * { classifiers { dscp dscp_classifier; } } } } scheduler-maps { queue_exit { forwarding-class expedited-forwarding scheduler EF-scheduler; forwarding-class best-effort scheduler BE-scheduler; }}schedulers { EF-scheduler { transmit-rate 100m rate-limit; buffer-size percent 30; priority strict-high; } BE-scheduler { transmit-rate remainder; buffer-size percent 25; priority low; drop-profile-map loss-priority high protocol any drop-profile BE-drop; }}
82
LISA F – MPLS katses kasutatud MPLS ja CoS seadistus
marsruuter2>show configuration class-of-service classifiers { dscp dscp_classifier { forwarding-class expedited-forwarding { loss-priority low code-points 101110; } } exp exp_classifier { forwarding-class expedited-forwarding { loss-priority low code-points 010; } }}drop-profiles { BE-drop { interpolate { fill-level [ 60 85 ]; drop-probability [ 1 100 ]; } }}interfaces { ae0 { scheduler-map queue_exit; unit * { classifiers { exp exp_classifier; } } } ae1{ scheduler-map queue_exit; unit * { classifiers { dscp dscp_classifier; } } } as* { scheduler-map queue_exit; unit * { classifiers { exp exp_classifier; } } }}scheduler-maps { queue_exit { forwarding-class expedited-forwarding scheduler ef-scheduler; forwarding-class best-effort scheduler df-scheduler;
83
forwarding-class network-control scheduler af-scheduler; }}schedulers { ef-scheduler { transmit-rate 100m; buffer-size percent 25; priority strict-high; } df-scheduler { transmit-rate remainder; buffer-size percent 25; priority low; drop-profile-map loss-priority high protocol any drop-profile BE-drop; }}
marsruuter2> show configuration protocols mplsstatistics { file mpls-statistics.txt files 2 world-readable; interval 30;}explicit-null;label-switched-path EF-to-marsruuter1 { to 192.168.4.1; install 192.168.167.0/30; bandwidth 100m; class-of-service 2; fast-reroute;}label-switched-path BE-to-marsruuter1 { to 192.168.4.1; metric 5; install 192.168.166.0/30; bandwidth 850m; class-of-service 0;}interface as0.0;interface ae0.0;
84
LISA G – laborikatses kasutatud utiliitide osaline väljund
1.
iperf klient:~> ping 192.168.168.2 -Q 0x0
363 packets transmitted, 363 received, 0% packet loss, time 363458ms
rtt min/avg/max/mdev = 2.671/9.933/22.833/3.480 ms
iperf server > tcpdump -i eth0 -vvvv | grep -i icmp
02:21:41.18014 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.166.2 > 192.168.168.2: ICMP echo
request, id 7124, seq 686, length 64
02:21:41.18662 IP (tos 0x0, ttl 64, id 17319, offset 0, flags [none], proto ICMP (1), length 84) 192.168.168.2 > 192.168.166.2: ICMP
echo reply, id 7124, seq 686, length 64
2.
iperf klient:~>ping 192.168.168.2 -Q 0xB8
1043 packets transmitted, 1043 received, 0% packet loss, time 1042389ms
rtt min/avg/max/mdev = 0.225/0.527/1.464/0.202 ms
iperf server:~> tcpdump -i eth0 -vvvv | grep -i icmp
03:15:41.918651 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.166.2 > 192.168.168.2: ICMP echo
request, id 18964, seq 1038, length 64
03:15:41.918662 IP (tos 0x0, ttl 64, id 47304, offset 0, flags [none], proto ICMP (1), length 84) 192.168.168.2 > 192.168.166.2: ICMP
echo reply, id 18964, seq 1038, length 64
3.
iperf klient:~>ping 192.168.168.2
--- 192.168.168.2 ping statistics ---
706 packets transmitted, 705 received, 0% packet loss, time 707826ms
rtt min/avg/max/mdev = 1.781/9.347/20.470/3.451 ms
iperf server:~> tcpdump -i eth0 -vvvv | grep -i icmp
03:30:13.855257 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.166.2 > 192.168.168.2: ICMP echo
request, id 15381, seq 702, length 64
03:30:13.855267 IP (tos 0x0, ttl 64, id 48011, offset 0, flags [none], proto ICMP (1), length 84) 192.168.168.2 > 192.168.166.2: ICMP
echo reply, id 15381, seq 702, length 64
iperf server:~>iperf -s
iperf klient:~> iperf -c 192.168.168.2 -t 10000 -i 2 -l 1500B
[ 3] 1994.0-1996.0 sec 34.3 MBytes 144 Mbits/sec
[ 3] 1996.0-1998.0 sec 34.4 MBytes 144 Mbits/sec
[ 3] 1998.0-2000.0 sec 34.3 MBytes 144 Mbits/sec
[ 3] 0.0-2000.1 sec 33.4 GBytes 143 Mbits/sec
85
LISA H – tcpdump utiliidi väljund MPLS liiklustest
1. MPLS liiklus EXP väärtusega 0 (BE)
17:07:44.249160 MPLS (label 0, exp 0, [S], ttl 64), IP, length: 104[|MPLS]
17:07:44.249165 MPLS (label 0, exp 0, [S], ttl 64), IP, length: 104[|MPLS]
17:07:44.269970 MPLS (label 0, exp 0, [S], ttl 64), IP, length: 104[|MPLS]
17:07:44.269979 MPLS (label 0, exp 0, [S], ttl 64), IP, length: 104[|MPLS]
17:07:44.331263 MPLS (label 0, exp 0, [S], ttl 64), IP, length: 104[|MPLS]
17:07:44.331270 MPLS (label 0, exp 0, [S], ttl 64), IP, length: 104[|MPLS]
17:07:44.353984 MPLS (label 0, exp 0, [S], ttl 64), IP, length: 104[|MPLS]
17:07:44.353991 MPLS (label 0, exp 0, [S], ttl 64), IP, length: 104[|MPLS]
40697 packets captured
34267 packets received by filter
193157 packets dropped by kernel
2. MPLS liiklus EXP väärtusega 2 (EF)
17:06:23.755501 MPLS (label 0, exp 2, [S], ttl 255), IP, length: 132[|MPLS]
17:06:23.755565 MPLS (label 0, exp 2, [S], ttl 255), IP, length: 132[|MPLS]
17:06:23.755567 MPLS (label 0, exp 2, [S], ttl 255), IP, length: 132[|MPLS]
17:06:23.755569 MPLS (label 0, exp 2, [S], ttl 255), IP, length: 132[|MPLS]
17:06:23.755571 MPLS (label 0, exp 2, [S], ttl 255), IP, length: 132[|MPLS]
17:06:23.755572 MPLS (label 0, exp 2, [S], ttl 255), IP, length: 132[|MPLS]
17:06:23.755574 MPLS (label 0, exp 2, [S], ttl 255), IP, length: 132[|MPLS]
17:06:23.755578 MPLS (label 0, exp 2, [S], ttl 255), IP, length: 132[|MPLS]
1293 packets captured
26432 packets received by filter
209394 packets dropped by kernel
![Implementation, testers and testing of satellite phoneavots/BWA_1A/Maarja_Laos_mag.pdf · 2010. 6. 3. · 2+ (Geostationary Mobile Radio Release 2+, enhanced variant of GMR-2) [7]](https://img.dokumen.tips/doc/110x75/5fcf05e9561322272f3ea2d0/implementation-testers-and-testing-of-satellite-phone-avotsbwa1amaarjalaosmagpdf.jpg)
