UNIVERZITET U SARAJEVU ELEKTROTEHNIKI FAKULTET ODSJEK ZA TELEKOMUNIKACIJE

XCP I IZBJEGAVANJE ZAGUENJA

Seminarski rad iz predmeta Kvaliteta usluge u TK mreama
Elbisa olak, Meliha Duli & Erma Perenda

Sarajevo, 2012.

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

SAETAK
U ovom radu objanjena je osnovna ideja XCP protokola. XCP je de-facto standard od svog nastanka u 2002. godini. Ovaj protokol je privukao veliku panju u istraivanjima kao idealno rjeenje za budue mree s visokim proizvodom bandwidth-delay za koje trenutno koriteni mehanizmi kontrole zaguenja postaju nestabilni i oscilatorni. Ipak, XCP je jo uvijek u fazi eksperimentiranja, jer je neophodno da se prevaziu neke ozbiljne prepreke koje koe razvoj ovog protokola. U prvom dijelu rada detaljnije je objanjena sama potreba za novim mehanizmom kontrole zaguenja. Dati su osnovni nedostaci TCP-ove end-to-end kontole zaguenja. U drugom dijelu rada objanjen je princip rada XCP protokola, kao jedna od idelanih kontrola zaguenja koja je zasnovana na explicit-feedback mehanizmu. Sigurnost XCP protokola je jako slaba i u radu su dati neki od moguih napada na nivou ovog protokola.

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

SADRAJ
1. 2. UVOD..........................................................................................................................................4 XCP- eXplicit congestion Control Protocol ..................................................................................7 2.1 2.2 XCP osnovna ideja.............................................................................................................7 XCP zaglavlje........................................................................................................................8 Posljedice uvoenja XCP zaglavlja ................................................................................9

2.2.1 2.3

XCP poiljaoci .................................................................................................................... 10 Raunanje delta_throughput ................................................................................ 11

2.3.1 2.3.2 2.4

Reakcija poiljaoca na XCP reverse_feedback........................................................... 12

XCP ruteri .......................................................................................................................... 12 Dolazak paketa na ruter ............................................................................................. 12 Control Interval Timeout ............................................................................................ 13 Odlazak paketa .......................................................................................................... 17 Queue estimation timeout ......................................................................................... 17

2.4.1 2.4.2 2.4.3 2.4.4 2.5 2.6 3.

XCP primaoc ...................................................................................................................... 18 Sigurnost XCP protokola .................................................................................................... 18

ZAKLJUAK ...............................................................................................................................19

AKRONIMI ........................................................................................................................................20 LITERATURA .....................................................................................................................................21

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

1. UVOD
U posljednjih nekoliko godina Internet se znatno proirio. Nove aplikacije, razvoj sigurnosnih mehanizama, otvaranje perspektiva mrenog poslovanja, rad na potpuno novim konceptima Internet arhitekture i stalno unapreivanje protokola su garancije da e Internet nastaviti da raste i privlai nove korisnike. Globalni promet internetom uetverostruit e se do 2015. zbog porasta broja prikljuaka na svjetsku mreu, po predvianjima koje je u junu 2011. objavila amerika kompanija Cisco, specijalizirana za opremu telekomunikacijskih mrea i interneta. Prema ovom predvianju vie od 40% svjetskog stanovnitva ili gotovo est milijardi osoba trebalo bi "surfati" mreom do 2015. godine, a na internet e biti spojeno 15 milijardi ureaja. Udio raunara u tom prometu trebao bi pasti s 97% na 85% u sljedee etiri godine zbog mobitela, tableta i televizora koji nude mogunost prikljuka na net. Rast prometa predvodit e video materijali koji e 2015. ostvariti promet 14 puta vei nego prole godine. Mobilni internet poveat e se 26 puta u istom razdoblju. Ovakvo okruenje se sa pravom moe nazvati najizazovnijim poljem za razvoj i istraivanje irokog spektra problema. Rad u ovoj oblasti je specifian, jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva. Stoga se kae da je Internet pokretna meta. Osnova dananjeg Interneta je paketski prenos zasnovan na TCP/IP skupu protokola. Iz perspektive sloja mree, saobraaj se prenosi IP protokolom koji prua servis najboljeg pokuaja (engl. best effort) bez uspostave konekcije (engl. connectionless, CL). Takav prenos informacija omoguava izuzetnu efikasnost. Postoje dva protokola transportnog sloja TCP i UDP. Za razliku od UDP, TCP protokol sloja transporta referentnog OSI modela je sainjen kao pouzdan, konekcijski orijentiran protokol ope namjene. Procjenjuje se da TCP rukovodi najveim dijelom (oko 90%) dananjeg Internet saobraaja. Praktina upotreba je pokazala da je protokol sposoban da podri irok spektar aplikacija (HTTP, FTP, SMTP, ...) kao i izuzetnu heterogenost mrenih mehanizama i arhitektura. S porastom Interneta glavni akcenat se stavlja na mehanizme kontrole zaguenja koji moraju ostati efikasni bez obzira na porast mree. Izvorna TCP specifikacija nije dala mnogo miljenja po pitanju kontrole zaguenja, jer u vrijeme razvoja ovaj problem nije bio zastupljen. Mnogobrojne modifikacije TCP-a rijeile su neke od uoenih problema tokom posljednje dvije decenije. Da bi se izbjegle oscilacije vie TCP tokova u uslovima velikog mrenog optereenja i da bi TCP radio bolje u uvjetima visokih brzina, razvijeni su razni algoritmi poput: Random Early Discard (RED), Random Early Marking (REM), Fast Recovery, Slow Start, Fast Retransmit, Forward Acknowledgment (FACK), Selective Acknowledgment (SACK) i Highspeed TCP. Tehnoloki trendovi pokazuju da e Internet u budunosti imati veliki broj linkova s visokim kapacitetom. Manje prisutni, ali jo uvijek uobiajni bit e i satelitski i wireless linkovi s visokim kanjenjem. Ovi trendovi su problematini, jer TCP reagira negativno s poveanjem propusnog opsega ili kanjenja. Matematika analiza trenutnih mehanizama za kontrolu zaguenja pokazuje da bez obzira na koritene mehanizme upravljanja redovima ekanja, ukoliko vrijednost proizvoda bandwidth x delay raste, TCP postaje nestabilan i sklon oscilacijama. Takoer, vrlo je malo vjerojatno da e neki od AQM mehanizama moi odrati stablinost TCPa preko linkova s visokom vrijednou proizvoda bandwidth x delay. Drugi problem TCP protokola jeste nain na koji dodjeljuje propusni opseg u mreama s visokom vrijednou proizvoda bandwidth x delay. TCP koristi AIMD (Additive Increase, Multiplicative Decrease) algoritam, koji sprjeava poveanje raspoloivog propusnog opsega vie od jednog paketa po RTT (Round Trip Time). Ako se paket izgubi to za TCP predstavlja indikaciju zaguenja, TCP koristi multiplikativno smanjenje (prepolovi se u sluaju TCP Reno) svoje propusnosti. Od te smanjenje (prepolovljene - TCP Reno, slika 1.1) vrijednosti TCP e aditivno poveavati propusnost za jedan paket po RTT.

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

Slika 1.1 AIMD algoritam za TCP Reno

Mree s visokim RTT e trebati vie vremena da poveaju svoju brzinu na poetnu vrijednost. Razliite varijante TCP protokola koriste razliite algoritme za detekciju gubitka paketa i reagiraju neto drugaije u sluaju gubitka paketa. Meutim, sve one koriste aditivno poveanje (izuzev HighSpeed TCP) za poveanje brzine poslije detekcije zaguenja. TCP protokol koristi detekciju gubitka paketa kao indikaciju zaguenja u mrei. Na ovaj nain poiljaoc saznaje malo informacija o stanju u mrei i ne zna najbolji nain kako da reagira. Npr. na satelitskim i beinim linkovima razlog gubitka paketa moe biti i neki drugi, a ne zaguenje u mrei. S TCP take gledita mrea je 'crna kutija' i TCP ne pretpostavlja nita o samim mogunostima mree. Zbog same neefikasnosti ovog pogleda, razvojem raunarskih mrea i tehnologija ovaj pristup se promijenio. Prvi drugaiji pristup dala je Dina Kitabi, programer XCP (eXplicit Control Protocol) protokola, koja je zagovarala da se razmisli o kontroli zaguenja od nule. XCP je nastao kao odgovor na pitanje: S obzirom na nae trenutno znanje o kontroli zaguenja, kako bi izgledala idealna kontrola zaguenja ?

Slika 1.2 Osobine i ponaanje idealnog mehanizma za kontrolu zaguenja [3]

Dina je na ovo pitanje odgovorila da mrea treba da daje jasne poruke nazad hostovima o trenutnom nivou zaguenja u mrei. Aktivnim ukljuivanjem rutera, poiljaoc bi mogao dobiti tane povratne informacije o tome kako dinamiki prilagoditi optereenje u mrei. Na osnovu ove ideje XCP je

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

specificiran kao eksperimentalni1 RFC 17.10.2004. razvijen od strane Dina Katabi iz MIT, Handley i Rohrs-a. To je novi Internet protokol za kontrolu zaguenja i privukao je veliku panju u istraivanjima zbog svog obeanja prema potencijalnoj dobiti visoke iskoritenosti u mreama s visokom vrijednou proizvoda bandwidth x delay, a da pri tome ne zadrava dugo pakete u redovima ekanja na ruteru i bez potrebe da se stanja pojedinih tokova uvaju na ruterima. U sljedeem poglavlju dat je detaljniji opis ovog protokola. Na osnovu gore navedenog moemo izvriti konanu podjelu mehanizama za kontrolu zaguenja koja je data na slici 1.3.

Slika 1.3 Mehanizmi za kontrolu zaguenja [3]

Mehanizmi za kontrolu zaguenja dijele se na dvije osnovne grupe: End-to-End (E2E) mehanizmi za kontrolu zaguenja se ne oslanjaju na rutere i koriste implictne povratne informacije za detekciju zaguenja. Od tradicionalnih mehanizama najraireniji u Internet upotrebi je TCP Reno. Nedostatak ovih mehanizama je loa skalabilnost s poveanjem kanjenja ili propusnog opsega. U posljednje vrijeme je predloeno nekoliko High-Speed mehanizama od kojih se najvie koristi FAST. Svi ovi mehanizmi koriste end-to-end semantiku, samo su zastupljene male modifikacije na strani poiljaoca. Active Queue Management (AQM) je nain ukljuivanja rutera za pomaganje u kontroli zaguenja. Kod AQM upravljaki algoritam se odvija na ruterima koji pruaju tanije i bre povratne informacije krajnim hostovima. Tradicionalni AQM mehanizmi postaju nestablini s porastom kanjenja i propusnosti. Dok, s druge strane Explicit-Feedback AQM mehanizmi rjeavaju ovaj problem.

Razlozi zato je XCP jo uvijek u fazi eksperimentisanja dat e se u nastavku

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

2. XCP- eXplicit congestion Control Protocol

Poput pouzdanih transportnih protokola TCP i SCTP, XCP je window-based protokol, koji je zasnovan na Explicit Congestion Notification (ECN) i uvodi novi koncept razdvajanja kontrole iskoritenosti linkova od kontrole pravinosti tokova. XCP ima nekoliko irokih ciljeva poput: stabilnosti, pravine dodjele raspoloivog opsega, visoke iskoritenosti linkova, male duina reda ekanja i priblino nultih gubitaka paketa. Vie specifini ciljevi su: minimizacija oscilacija, efikasnost za high bandwidth-delay konekcije, minimizacija trasmisionog kanjenja za male tokove i pravednost izmeu tokova sa razliitim RTT. XCP je eksperimentalni protokol i dosta je sloeniji za realizaciju od drugih predloenih rjeenja za kontrolu zaguenja na Internet-u, s obzirom da zahtijeva odreene modifikacije na ruterima, ali i na krajnjim sistemima.

2.1

XCP osnovna ideja

XCP ima bitno drugaiji pristup kontroli zaguenja nego TCP. Polazi se od pretpostavke da se mrea sastoji od rutera sposobnih za izraunavanje trenutnog mrenog optereenja i sposobnih da o tome obavijeste poiljaoca, tj. da mu daju do znanja koliko imaju na raspolaganju propusnog opsega za slanje svojih podataka. U skladu s time poiljaoc podeava svoju brzinu slanja paketa i na taj nain se sprjeava zaguenje i gubitak paketa. XCP je zamiljen bez nekih znaajnih kompatibilnosti, ali kao zaseban protokol sloja izmeu IP i TCP sloja (slika 2.1). Ovo je konzistentno sa injenicom da XCP nije hop-by-hop komunikacija kao to je IP, niti je end-to-end komunikacija kao to su TCP i UDP, to je zapravo end-system-to-network komunikacija. Trebao bi da omogui ruteru lake lociranje zaglavlja zaguenja na paketu bez IP opcija.Drugi izbori su razmatrani za lokaciju XCP zaglavlja. Na primjer,jedna od opcija je bila TCP sa zaglavljem zaguenja. Ovo bi imalo smisla da je informacija o zaguenju svojstvo samo transportnog protokola. Ipak, ovo zahtijeva da ruteri paze na format zaglavlja za svaki drugi transportni protokol koji koristi XCP. Ovo bi izgledalo kao neopravdano optereenje za apliciranje na rutere i koilo bi razvoj novih transportnih protokola i/ili XCP-a.

Slika 2.1 TCP/XCP/IP stog [1]

Kako bi dobili manje oscilatorni protokol, bio je nepohodan precizniji povratni mehanizam. Ukoliko se povea kanjenje povratne veze (feedback) s tokovima s visokim RTT, protokol treba uzeti u obzir ovo kanjenje tako da poiljaoc smanji brzinu slanja paketa. Vano pitanje je kako protokol treba prilagoditi promjenu kanjenja povratne veze tako da postigne stabilnost ak i kada je kanjenje veoma veliko. XCP e automatski usporiti slanje paketa kada RTT poraste. Ova adaptacija poveanja mrenog kanjenja sprjeava da protokol postane nestabilan i oscilirajui, to je u suprotnosti s TCPom.XCP koristi MIMD (Multiplicative Increase, Multiplicative Decrease) algoritam za kontrolu iskortenosti linkova. To dovodi do mnogo bre dodjele raspoloivog opsega izmeu tokova. XCP e dodijeliti opseg proporcionalno s raspoloivom irinom opsega ( 'Multiplicative Increase') i jednako smanjiti propusnost ako je previe opsega upotrebljeno ('Multiplicative Decrease '). XCP, takoer, mora odrediti na koji nain podijeliti alocirani opseg izmeu aktivnih tokova. Za razliku od TCP, XCP razdvaja alokaciju propusnog opsega od raspodjele po tokovima. XCP protokol koristi AIMD algoritam za odreivanje pravednosti izmeu tokova. TCP koristi AIMD algoritam nakon detekcije gubitka

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

paketa, dok XCP koristi ovaj algoritam za svaki srednji RTT interval. Ovo omoguava XCP-u da bre konvergira ka pravednoj dodjeli opsega izmeu aktivnih tokova.

2.2

XCP zaglavlje

XCP protokol se temelji na stvaranju novog protokolnog sloja i zaglavlja u protokol stogu izmeu IP i TCP zaglavlja. Ovo zaglavlje je fiksne veliine od 20 bajta i nalazi se prije TCP zaglavlja, a poslije IP zaglavlja.

Slika 2.2 XCP zaglavlje

Zaglavlje se sastoji od sljedeih polja: Version: 4 bita. Ovo polje oznaava trenutnu verzija XCP protokola, vrijednost=0x01. Format: 4 bita Ovo polje oznaava format zaglavlja zaguenja. Razlikuju se standardni format (0x01) i minimalni format (0x02). Standardni format oznaava da su polja Throughput, Delta_Throughput i RTT u upotrebi. Ovaj format se koristi u paketima koji se alju od poiljaoca do primaoca. Minimalni format se koristi kada se ACK paket alje od primaoca do poiljaoca. Throughput, Delta_Throughput i RTT polja su postavljena na 0. Svaki XCP ruter moe vidjeti minimalni format i ne smije uiniti nikakve promjene nad XCP zaglavljem. Protocol: 8 bita Ovo polje ukazuje na protokol sljedeeg nivoa, tipino TCP, koji se koristi u prenosu paketa. Vrijednosti za razliite protokole specificira IANA (Internet Assigned Numbers Authority). Length: 8 bita Duina zaglavlja zaguenja u bajtima. Za trenutnu verziju XCP-a, ova duina ima konstantnu vrijednost 20 bajta. Unused: 8 bita Ovo polje se ne koristi i mora biti postavljen na vrijednost 0. RTT: 32 bita RTT koji mjeri poiljaoc, u milisekundama. Ovo polje je tipa unsigned integer. Minimalna vrijednost je 1ms (napomena: na poetku emitovanja podataka ova vrijednost je jednaka nuli, to znai da poiljaoc jo uvijek ne zna RTT). Maksimalna vrijednost ovog polja je 4.3e9 ili priblino 49 dana.

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

Throughput: 32 bita Trenutna propusnost za tok izmjerena na strani poiljaoca, izraena u bajtima u milisekundi. Maksimalna vrijednost u ovom polju je 4.3e9 bajta u milisekundi ili 34.360 Gbps, u koracima od 1 bajt po milisekundi ili 8000 bps. Delta_Throughput: 32 bita Predstavlja eljene ili alocirane promjene brzine slanja podataka (propusnosti). Ovu vrijednost postavlja poiljaoc i moe biti reducirana na ruterima du putanje. Mjeri se bajtima po sekundi te moe biti pozitivna i negativna vrijednost. Minimalna promjena propusnosti je 17 Gbps (maksimalni negativni feedback). Maksimalna vrijednost je 17 Gbps (maksimalni pozitivni feedback), u koracima od 8 bps. Reverse_feedback: 32 bita Vrijednost Delta_Throughput polja primljenog na prijemniku. Prijemnik kopira polje Delta_Throughput u Reverse_feedback polje sljedeeg odlaznog paketa u istom toku.

Slika 2.3 Promjena XCP zaglavlja tokom putanje poiljaoc primalac

XCP protokol radi tako to poiljaoc, primalac i svi XCP ruteri na putu itaju i edituju XCP poruke. Da bi XCP ispravno radio svaki od ovih mrenih entiteta mora da izvri neke proraune. Slika 2.3 pokazuje kako poruka koja sadri XCP zaglavlje putuje izmeu poiljaoca i primalaca i nazad, preko XCP rutera. U svakoj fazi se vrijednosti polja XCP zaglavlja proraunavaju i auriraju. U nastavku su objanjeni detaljnije ovi prorauni. Za ispravan rad XCP protokola neophodno je da na putu od poiljaoca do primalaca postoji barem jedan XCP ruter, tj. ruter koji prepoznaje XCP zaglavlje i sposoban je da izvri neke modifikacije nad njim. Meutim, ukoliko svi ruteri nisu XCP ruteri, protokol nee raditi optimalno, ak e u nekim sluajevima biti gori od TCP protokola. U ovom sluaju poiljaoc bi trebao to bre slati podatke jer e ne-XCP ruter smanjiti zahtjeve poiljaoca za propusnim opsegom. 2.2.1 Posljedice uvoenja XCP zaglavlja

Uvoenjem XCP zaglavlja neophodno je uvesti modifikacije nekih od koritenih mrenih protokola. IPSec posljedice

IPSec [RFC4301] potrebno je izmjeniti da bi se omoguila upotreba XCP-a. Specifikacije IP Autentikacijskog zaglavlja (Authentication Header-AH)[RFC4302] i IP Encapsulating Security Payload (ESP)[RFC4303] zahtijevaju da IPsec zaglavlje treba slijediti IP zaglavlje. Ovo predstavlja problem za XCP zato to:

Kvaliteta usluge u TK mreama a) bilo bi tee nai XCP zaglavlje od strane rutera;

XCP i izbjegavanje zaguenja

b) ESP enkripcija bi uinila nemoguim da ruteri na putu od poiljaoca do primaoca itaju i piu informacije u zaglavlje zaguenja; c) AH autentikacija ne bi prola ako bi ijedan od rutera na putu promijenio zaglavlje zaguenja. Zbog ovoga, XCP zaglavlje zaguenja bi trebalo da slijedi IP zaglavlje i prethodi bilo kakvom AH. NAT, middlebox posljedice

Middlebox koji pokuava da obavlja akcije neprimjetno od strane toka mora sauvati zaglavlje zaguenja. Midleboxovi koji terminiraju TCP konekcije trebalo bi da mogu terminirati i XCP konekciju. Middleboxovi koji ubacuju redove u put za prosljeivanje trebali bi uestvovati u XCPu. MPLS (Multi Protocol Label Switching)/Tuneliranje posljedice

Kada tok ulazi u IP tunel [RFC2003], IPsec ESP tunel [RFC4303]ili MPLS[RFC3031], zaglavlje zaguenja trebalo bi se iskopirati na poetak vanjskog IP zaglavlja (outer header). Na primjer, pri ulasku paketa u IP tunel, sljedea transformacija bi se trebala obaviti:

XCP zaglavlje dodato na poetak vanjskog zaglavlja se kopira iz unutranjeg zaglavlja(inner header) sa odgovarajuom promjenom polja protokola da bi se naglasilo da je sljedei protokol IP. Kada paket naputa tunel, zaglavlje zaguenja, koje je moglo biti promijenjeno od strane rutera na tuneliranom putu, se kopira iz vanjskog zaglavlja u unutranje zaglavlje

2.3

XCP poiljaoci

Poiljaoci su krajnji hostovi koji aktivno prenose podatke u mreu. Oni su odgovorni za odravanje XCP protokola i ne smiju slati vie podataka nego to im je doputeno od XCP rutera u mrei. Veim dijelom sloenost XCP protokola je locirana na strani poiljaoca i oni moraju postavljati razliite mrene parametre kako bi protokol radio ispravno. Poiljaoci su duni odravati sljedea etiri parametra: eljena propusnost [Byte/second]; procjenjena trenutna propunost [Byte/second]; maksimalna propusnost dozvoljena od XCP [Byte/second]; trenutna procjena RTT [miliseconds].

10

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

Poiljaoc moe izabrati bilo koju razumnu vrijednost, tj. bilo koju ostvarivu vrijednost za eljenu propusnost. Ova vrijednost moe biti navedena od strane aplikacije preko API, ili to moe biti brzina lokalnog interfejsa. To je brzina koju poiljaoc eli postii ako u mrei nema zaguenja. Ako aplikacija ne alje podatke dovoljno brzo da potpuno iskoristi dozvoljenu brzinu, XCP bi trebao reducirati dozvoljenu propusnost kako vrijeme prolazi, da bi izbjegao iznenadne burst-ove podataka u mreu, ukoliko aplikacija pone slati podatke kasnije. Svaki RTT u kojem poiljaoc alje podatke brzinom manjom od dozvoljene, dozvoljena brzina mora se reducirati prema sljedeoj formuli:

Allowed _ throughput Allowed _ throughput 1 p Actual _ throughput p

(2.1)

gdje je p parametar koji kontrolie brzinu zastarijevanja, uzima vrijednosti izmeu 0 i 1 (preporuena vrijednost je 0.5). 2.3.1 Raunanje delta_throughput

Da bi izraunao delta_Throughput u XCP zaglavlju, poiljaoc treba znati trenutnu propusnost T. Vrijednost Throughput polja se postavlja na vrijednost trenutne procijenjene propusnosti, u bajtima u milisekundi, ili na vrijednost 0 ako propusnost jo uvijek nije estimirana. Ovo znai da e prvi paketi u toku koristiti kapacitet koji nee biti praen u kontrolnim algoritmima rutera. Kako XCP zahtijeva samo jedan RTT interval za tok da bi se izvrila estimacija RTT-a, ovo e imati beznaajan utjecaj. Poiljaoc postavlja RTT polje na vrijednost procijenjenog RTT-a, ili na nulu, ako RTT jo nije estimirano. Upotrebom vrijednosti eljene propusnosti i procijenjene propusnosti moe se iskoristiti slijedea formula za nalaenje koja se postavlja u XCP zaglavlje.

(2.2)
gdje je: - delta_Throughput po paketu [B/s]; C - kapacitet ili maksimalna eljena brzina poiljaoca [B/s]; T - trenutna procijenjena propusnost [B/ms]; RTT - Round Trip Time mjereno od strane poiljaoca [ms]; MSS - Maximum Segment Size [B]. Relacija (2.2) pokazuje da je obino razlika izmeu trenutne procijenjene propusnosti i eljene propusnosti. Ako poiljaoc nema dovoljno podataka za slanje da iskoristi dostupnu propusnost, ova promjena propusnosti bi trebala biti postavljena na nulu. Poiljaoc potom dijeli eljenu promjenu propusnosti brojem paketa u jednom RTT intervalu i stavlja dobivenu vrijednost u polje delta_Throughput u zaglavlju zaguenja. Ova raspodjela promjene propusnosti po paketu je potrebna jer XCP ruter ne uva stanja zaguenja po toku, mora tretirati svaki paket nezavisno od drugih u tom toku. Broj paketa po RTT-u se moe odrediti kao proizvod trenutne propusnosti i RTT-a, podijeljen sa MSS-om (maksimalna veliina segmenta). Ako je Delta_throughput manje od 1Bps, upisae se 0, jer se koristi integer notacija. Bilo bi mogue slati dijelove paketa u RTT-u sa vrijednostima Delta_throughput razliitim od nule.

11

Kvaliteta usluge u TK mreama 2.3.2 Reakcija poiljaoca na XCP reverse_feedback

XCP i izbjegavanje zaguenja

Na putu do primalaca vrijednost polja u XCP zaglavlju se moe modifikovati od strane XCP rutera. Ovako dobijen , primalac kopira u polje Reverse_feedback zaglavlja zaguenja i pomou ACK poruke alje natrag poiljaocu. Poiljaoc prilagoava svoju veliinu TCP prozora zaguenja (cwnd) kako bi se prilagodio novim raspoloivim propusnim opsegom. Kako je TCP struktuiran tako da prijemnik ne mora vratiti ACK za svaki primljeni paket, ve moe jednim ACK-om potvrditi uspjean prijem vie paketa, iz tog razloga primalac mora akumulirati za svaki primljeni paket i vratiti poiljaocu akumliranu vrijednost upisanu u polje Reverse_feedback zaglavlja zaguenja u sljedeoj ACK poruci. Za prilagoenje veliine prozora zaguenja koristi se sljedea relacija:

gdje je: cwnd - trenutna veliina TCP prozora zaguenja [B]; r - Reverse_feedback polja za primljeni paket [B/s]; RTT Round Trip Time mjereno od strane poiljaoca [ms]; MSS Maximum Segment Size [B]. Prema relaciji (2.3) minimalna vrijednost za cwnd je MSS u cilju izbjegavanja fenomena pod nazivom 'silly window syndrome' . Ovaj fenomen se javlja kada vrijednost cwnd postane toliko mala da TCP poiljaoc moe da poalje sve pakete odjednom. Da bi sprijeilo da cwnd postane 0 uvijek se postavlja na najmanje MSS bajta.

2.4

XCP ruteri

Za ispravan rad XCP protokola neophodno je da postoji barem jedan XCP ruter na putu od poiljaoca do primalaca. Ovaj XCP ruter mora proraunati na koji nain rasporediti propusni opseg izmeu tokova. Da bi to postigli, ruter prati etiri razliita dogaaja. Ovi dogaaji se deavaju kada paket stigne na ruter, kada istekne Control Interval Timer, na odlasku paketa i po isteku Queueassessment Timer-a. Ova etiri dogaaja zahtijevaju odreene proraune od strane rutera i deavaju se ili kada istekne neki specifini tajmer ili pak kad paket dolazi/odlazi s rutera. 2.4.1 Dolazak paketa na ruter

Glavni prorauni na XCP ruteru se deavaju tokom Control Interval Timeout-a. Da bi izvrio ove proraune ruter mora prikupiti potrebne podatke od pristiglog paketa. Podaci su smjeteni u IP i XCP zaglavlju u svakom pojedinanom paketu. Informacije koje se uvaju na ruteru tokom Control Interval-a su: ukupni iznos primljenih bajti (zbroj svih veliina IP paketa); ukupni iznos weighted propusnosti (IP Packet_Size/XCP Throughput ); ukupni iznos weighted RTT (RTT *IP Packet_Size/XCP Throughput).

12

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

Prorauni su jednostavni i vre se za svaki pristigli paket. Sumirane vrijednosti se resetuju poslije svakog Control Interval-a. 2.4.2 Control Interval Timeout

Istek kontolnog intervala javlja se u regularnim razmacima, zasnovanim na prosjenoj vrijednosti RTT-a koji se rauna na osnovu informacija u zaglavlju zaguenja. Glavna svrha raunanja koja se obavljaju tokom kontrolnog intervala je raunanje ukupnog feedback-a i kako distribuirati ovu vrijednost feedback-a po paketu. Za raunanje feedback-a, XCP ruter koristi kontroler efikasnosti - Efficiency Controller i kontroler pravednosti - Fairness Controller (slika 2.4). Oba ova raunanja se procjenjuju na intervalu prosjenog RTT-a za sve aktivne tokove. Procjena parametara na intervalu duem od srednjeg RTT intervala je spora, dok procjena izvrena na intervalu kraem od srednjeg RTT intervala daje pogrene rezultate. XCP protokol koristi rezultate ovih prorauna da promjeni vrijednost delta_Throughput tokom sljedeeg kontrolnog intervala. Tokom proteklog kontrolnog intervala, statistika se prikuplja za sve pristigle pakete i nova vrijednost feedback-a se rauna na osnovu tih vrijednosti. S obzirom da XCP protokol razdvaja kontrolu iskoritenosti linkova od kontrole pravednosti, ove dvije kalkulacije se vre odvojeno (i razliite formule mogu biti osmiljene kako bi se postigle najbolje performanse ili kako bi se omoguila laka prilagodba na pojedinane sisteme). XCP kontroleri prave jednu kontrolnu odluku za svaki prosjeni RTT (kontrolni interval). Ovo je motivirano potrebom da se potuju rezultati prolih kontrolnih odluka prije nego se donese nova odluka. Nakon isteka kontrolnog intervala, ruter aurira svoje procjene i kontrolne odluke.

Slika 2.4 Kontoleri XCP rutera i njihove funkcije [5]

2.4.2.1

Kontroler efikasnosti (Efficiency Controller)

Kontroler efikasnosti ima zadatak da maksimizira ukupnu propusnost kroz interfejse rutera uz minimalne gubitke paketa i perzistentni red. Ne bavi se time kako se promjena u ukupnoj propusnosti manifestuje na neki saobraajni tok. Ovo je posao kontrolera pravednosti. Kako je XCP windowbased, EC izraunava eljeno poveanje ili pak smanjenje trenutne propusnosti da maksimizira iskoritenje linkova tokom sljedeeg kontrolnog intervala. Ukupni feedback se rauna prema slijedeoj relaciji: gdje je: F ukupni feedback tokom kontrolnog intervala [B/s]; - konstanta (prema autorima XCP [KHRO2] predloena vrijednost je 0.4 za koju je sistem

13

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

stabilan i ne ovisi o broju aktivnih tokova, kanjenja i kapaciteta linkova); d srednji RTT svih tokova tokom zadnjeg kontrolnog intervala [s]; S rezervirana propusnost. Razlika izmeu kapaciteta linka i iskoritenosti linka. Moe biti i negativna ako je link preoptereen. [B/s]; - konstanta (prema autorima XCP [KHRO2] predloena vrijednost je 0.226 za koju je sistem stabilan i ne ovisi o broju aktivnih tokova, kanjenja i kapaciteta linkova); Q - veliina perzistentnog reda (minimalni red ekanja tokom kontrolnog intervala) [B]. EC koristi Multiplicative-Increase Multiplicative-Decrease (MIMD) algoritam, koji poveava feedback proporcionalno raspoloivom propusnom opsegu u sistemu, a smanjuje feedback proporcionalno veliini perzistentnog reda. Relacija (2.4) pokazuje da je feedback proporcionalan slobodnoj propusnosti, jer ako je link ima slobodnog propusnog opsega i alje se pozitivan feedback, no ako je S < 0 link je zaguen i alje se negativan feedback. Meutim, ovo samo nije dovoljno u sluaju kada ulazni promet odgovara kapacitetu linka, jer se dobija da je feedback jednak 0 i ne uzima se u obzir poveanje veliine perzistentnog reda. Iz tog razloga, u relaciji je dodana i proporcionalna ovisnost feedback-a o veliini perzistentnog reda. MIMD algoritam omoguava da se brzo postigne pozitivan feedback, ak i na linkovima velikog kapaciteta.

2.4.2.2

Kontroler pravednosti (Fairness Controller)

Zadatak kontrolera pravednosti je da osigura da svaki saobraajni tok kroz interfejse rutera dobije pravedan udio od ukupnog feedback-a. FC koristi isti algoritam za konvergenciju pravednosti kao i TCP, nazvan Additive-Increase Multiplicative-Decrease (AIMD). Za raunanje feedback-a po paketu FC koristi sljedei politiku: Ako je F > 0 ruter je neoptereen i FC e poveati propusnost za sve tokove sa istim iznosom, bez obzira na predhodnu upotrebu propusnog opsega. Ovo dovodi do relativno visokog porasta propusnosti za aktivne tokove s niskom propusnou u odnosu na tokove s visokom propusnou. Primjer 1 pokazuje kako ta raspodjela utjee na ruter s vie tokova koji prolaze kroz njega. Npr. Ruter ima jedan tok propusnosti od 1 000 000 B/s i 10 tokova od 10 000 B/s. EC je izraunao feedback na ruteru od 440 000 B/s. FC e dati svakom toku dodatnih 40 000 B/s. Dakle, sad veliki tok ima propusnost od 1 040 000 B/s dok mali tokovi imaju propusnost od Primjer 1 XCP's additive increase alghoritm 50 000 B/s.
Primjer 1 XCP's additive increase alghoritm

14

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

Ako je F < 0 ruter je preoptereen i FC e smanjiti propusnost za svaki tok proporcionalno trenutnoj propusnosti. Kako se u ovom sluaju vri multiplikativno smanjenje, tokovi s visokom propusnou e najvie izgubiti (primjer 2). Npr. Ruter ima jedan tok propusnosti od 1 000 000 B/s i 10 tokova od 10 000 B/s. EC je izraunao feedback na ruteru od -120 000 B/s (10%). FC e smanjiti propusnost svakog toka za 10%. Dakle, sad veliki tok ima propusnost od 900 000 B/s dok mali tokovi imaju propusnost od 9 000 B/s.
Primjer 2 XCP's multiplicative decrease alghoritm

Na ovaj nain se osigurava kontinuirano pribliavanje pravednosti kada ukupni feedback nije jednak 0. Da bi se sprijeila spora konvergencija kada je efikasnost optimalna, tj. kada je uvodi se pojam bandwidth shuffling (mijeanje opsega). Ovaj pojam oznaava istovremeno i alokaciju i dealokaciju propusnog opsega tako da se ukupna propusnost ne mijenja ( kao ni efikasnost), dok se propusnost pojedinanih tokova mijenja postepeno da se postigne pravedan udio svih tokova u propusnom opsegu (ak i kod sistema s neujednaenim ekvilibrijumom). Shuffled promet se rauna prema slijedeoj relaciji:

gdje je y ulazni promet, a je konstanta jednaka 0.1. Ova relacija osigurava da se tokom svakog srednjeg RTT intervala 10% prometa distribuira prema AIMD algoritmu. Izbor od 10% je rezlutat kompromisa izmeu optimalne efikasnosti i brzog uspostavljanja pravednosti. Nakon prorauna feedback-a po tokovima neophodno je izvriti proraun i feedback-a po pojedinanom paketu da bi FC mogao sprovesti svoju politiku. Zbog AIMD algoritma prikladno je raunati feedback paketa 'i' kao kombinaciju pozitivnog i negativnog feedback-a.

Za pozitivan ukupni feedback, F > 0, glavna ideja je da se ukupna promjena u totalnoj propusnosti nekog toka i distribuira na oekivan broj paketa tog toka tokom kontrolnog intervala, tj. ukupni feedback nekog toka se podijeli s oekivanim brojem paketa tog toka (slika 2.5). Broj oekivanih paketa za neki tok je proporcionalan koliniku veliine prozora zaguenja toka 'i' i veliini paketa , i inverzno proporcionalno RTT intervalu za taj tok . Na osnovu toga dobija se izraz za pozitivni feedback po paketu:

gdje je: - konstanta data izrazom:

15

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

a suma ide za sve pakete koji stignu u kontrolnom intervalu ( srednji RTT za sve tokove).

Slika 2.5 Raspodjela pozitivnog feedback-a po paketu [5]

Na slian nain raunamo i negativni feedback po paketu kada je ukupni feedback F < 0. U ovom sluaju dolazi do proporcionalnog smanjenja propusnosti nekog toka proporcionalno njegovoj trenutnoj propusnosti. Negativni feedback po paketu se dobije kada se ukupni feedback za neki tok podijeli sa oekivanim brojem paketa tog toka u kontrolnom intervalu (slika 2.6). Vrijednost negativnog feedback po paketu je proporcionalna veliini paketa i za taj tok.

gdje je: - konstanta data izrazom:

a suma ide za sve pakete koji stignu u kontrolnom intervalu ( srednji RTT za sve tokove).

Slika 2.6 Raspodjela negativnog feedback-a po paketu [5]

16

Kvaliteta usluge u TK mreama 2.4.3 Odlazak paketa

XCP i izbjegavanje zaguenja

Tokom Control Interval Timeout izraunat je feedback po paketu, koji je ili pozitivan ili negativan. Bazirano na ovim vrijednostima svaki paket treba da prilagodi vrijednost polja delta_Throughput prema doputenoj promjeni propusnosti za taj paket. Ako je delta_Throughput vea nego to ruter dozvoljava tj. vea od feedback po paketu, modifikovat e se ova vrijednost u skladu s doputenom. U sluaju da je delta_Throughput manja od vrijednosti koju ruter nudi, vrijednost delta_Throughput e ostati nepromijenjena. 2.4.4 Queue estimation timeout

Veliina reda igra vanu ulogu kod XCP algoritama. Ona govori koliko je zaguenje na ruteru i indirektno govori algoritmima kako da raspodjele pravedno propusni opseg izmeu aktivnih tokova. Veliina perzistentnog reda se procjenjuje na kraju intervala koji je neto krai od srednjeg RTT intervala, kako bi se izbjegla feed-forward petlja. Trenutna veliina reda ekanja se provjerava svaki put kada paket odlazi i rauna se minimalna veliina reda ekanja.

Kada istekne vrijeme odreeno za proraun reda veliina reda se postavlja na veliinu minimalni_red, a vrijednost minimalni_red na trenutnu veliinu reda. Procjena Queue estimation timeout uzima u obzir veliinu reda, smanjujui Queue estimation timeout kada veliina reda raste (relacija 2.12).

gdje je: T slijedei Queue estimation timeout [ms]; Q doputena veliina reda [ms]; a procijenjeni srednji RTT tokom prolog kontrolnog intervala [ms]; i trenutna veliina reda [B]; C kapacitet izlaznog linka [B/s]. Izraz predstavlja estimaciju propagacijskog kanjenja. Dijeljenje faktorom 2 je potrebno radi izbjegavanja preestimiranja propagacijskog kanjenja. Ako se srednji RTT koristi kao duina kontrolnog intervala, onda se ne smije koristiti ko interval za procjenu veliine perzistentnog reda jer ako se poveava veliina reda srednji RTT raste. Ovo e uiniti da sistem reagira sporije na poveanje veliine reda i red ak postaje dui, to dovodi do nestablinosti. Na ovaj nain se postavlja tajmer za raunanje reda ekanja.

17

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

2.5

XCP primaoc

Kada prijemni sistem dobije XCP poruke, on treba samo kopirati vrijednost delta_Throughout polja u polje Reverse_feedback. Postavljajui format XCP zaglavlja na vrijednost 0x02 primalac sprjeava da XCP ruteri procesiraju XCP zaglavlje na nain kao kad putuje od poiljaoca ka primaocu. Primaoc treba poslati XCP poruku sa slijedeim TCP ACK-om. Meutim, nekada TCP primalac moe jednim ACK-om potvrditi vie primljenih poruka tj. ne alje ACK za svaki primljeni paket. U ovom sluaju XCP primaoc sabira sve vrijednosti delta_Throughout polja pristiglih paketa i sa ACK porukom alje ovu akumuliranu vrijednost poiljaocu. Poiljaoc e u ovom sluaju primiti manje XCP poruka, ali e svaka sadravati ukupnu feedback vrijednost vie XCP poslanih poruka. Mogue je ak i da prazni ACK paketi uzrokuju ili naiu na zaguenje u povratnom smjeru. Iako TCP implementacije generalno nisu pripremljene za bilo koju vrstu kretanja praznih ACK segmenata baziranu na zaguenju, neki transportni protokoli (npr. DCCP) mogu biti. Takvi transportni protokoli vre XCP kontrolu zaguenja na povratnom ACK-u isto kao i na podacima. U normalnom sluaju neusmjerenih tokova podataka sa primjenom XCP-a samo na taj tok podataka, povratna informacija moe biti poslana u minimalnom formatu zaglavlja zaguenja.

2.6

Sigurnost XCP protokola

Prisustvo zaglavlja koje mogu itati i pisati entiteti koji ne uestvuju u end-to-end komunikaciji predstavlja potencijalni sigurnosni propust. Postoji nekoliko vrsta sigurnosnih propusta: Man-in-the-middle napadi zlonamjerni korisnik moe prisiliti poiljaoca da prestane sa slanjem podataka ubacivanjem negativnog feedback-a u tok. Ovo se malo razlikuje od situacije u kojoj zlonamjerni korisnik izaziva odbacivanje paketa koji pripadaju toku, koristei Van Jacobsovu kontrolu zaguenja ili postavljanjem ECN bita; Skriveni podatkovni kanali IPsec mora biti modificiran, kako bi se omoguilo da ruteri itaju zaglavlje zaguenja i upisuju vrijednost u delta_Throughput polje; Zlonamjerni izvori XCP algoritmi se oslanjanju na poiljaoca da e oglasiti informaciju o svom trenutnom RTT-u i Throughput-u i tano odgovoriti na feedback dostavljen sa mree. Postoji mogunost da poiljalac nee tano izvriti ove funkcije. Izvor koji alje lane informacije o svojoj propusnosti ne moe uticati na iskoritenost linka i, u najgorem sluaju, moe bespotrebno koristiti kapacitet. Izvor koji alje lane informacije o svom RTT-u moe naruiti algoritme kontrole na ruteru, posebno kada to radi veliki broj izvora, s obzirom da kontrolni interval rutera zavisi od prosjenog RTT-a. Ovaj napad se ubraja u slabe DoS napade (denial-of-service). Tok moe ignorisati negativni feedback od rutera. Takav tok moe nepravedno dobiti traenu propusnost u zaguenom ruteru. Meutim, XCP omoguava eksplicitnu verifikaciju da su tokovi odgovorili na feedback.

18

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

3. ZAKLJUAK
XCP protokol predstavlja potpuno novi nain rjeavanja mrenih problema poput kontrole zaguenja i pravednosti izmeu tokova. Uvoenjem zaglavlja novog protokola, XCP je u stanju brzo reagovati na povratne informacije od mree. XCP je potencijalno primjenjiv sa bilo kojim transportnim protokolom, poetna testiranja su vrena sa TCP protokolom. Skalabilnost XCP-a zasniva se na principu prenosa informacija o zaguenju unutar svakog paketa u toku. XCP protokol obeava optimalnu pravinost izmeu aktivnih saobraajnih tokova, gotovo bez gubitaka paketa i maksimalne iskoritenosti linkova. XCP ruteri osiguravaju da svaki aktivan tok dobije pravedan udio propusnog opsega, dok u isto vrijeme sprjeavaju da poiljaoc optereti mreu. Kritiari XCP protokola tvrde da uvoenje novog protokolnog sloja izmeu IP/TCP protokol stogu je povreda historijski stabilizirane TCP/IP hijerarhije. Katabi osporava ovakav pogled i ona doputa da ruteri itaju i mijenjaju vrijednosti polja iznad IP mrenog sloja. Meutim, malo je vjerojatno da e XCP ikad postati standardizovani RFC dokument kao rijeenje koje u potpunosti uklanja end-to-end kontrolu zaguenja primjenjivanu kod TCP-a. Ovo objanjava zato XCP tei da postane eksperimentalni RFC dokument, a ne standardizovani RFC dokument. Kao eksperimentalna ideja, XCP osporava gledite da se mrea treba posmatrati kao 'crna kutija'. Postoje odreene prepreke koje XCP protokol mora proi prije nego to se implementira u realan svijet. Istraivanja su pokazala da XCP ima slijedee probleme: iskoritenost uskog grla je smanjena tokom bursty XCP saobraaja i u okruenju gdje nisu zastupljeni svi XCP elementi mree XCP postaje oscilatoran, nestabilan, ak gori od samog TCP-a. Scenariji poput half-duplex veza, bursty aplikacija i netanih ruterovih postavki ine da XCP ruteri vrate pogrenu feedback vrijednost krajnjem hostu. Netana povratna inforamcija moe dovesti do poveanja veliine reda ekanja, oscilacija i gubitka paketa. Skalabilnost XCP protokola je takoer jedan od potencijalnih problema. Svaki XCP paket zahtjeva nekoliko ekstra prorauna na ruterima i sprijeena je upotreba brze putanje. XCP je zamiljen da rijei probleme mrea s visokom vrijednou produkta bandwidth-delay za budue mree. Za budue mree vrlo je vjerojatno da e bre poveati propusnost komponenta nego kanjenje komponente. No, kako se brzina mree poveava, broj paketa koji usmjerivai moraju obraditi raste. Iz tog razloga vrlo je vjerojatno da e XCP ruter vrlo brzo postati usko grlo mree. Jo jedna mana XCP protokola je slaba sigurnost i lahka je meta zlonamjernih hostova. U cilju suzbijanja ovih problema predloene su neke modifikacije XCP protokola poput XCP-i protokola koji predstavlja rjeenje za heterogene mree. Osnovni zadatak kod dizajna XCP-i je da se ouvaju principi kontrole XCP-a, a da se dodaju nove funkcionalnosti za detekciju non-XCP oblaka. XCP-i moe uspjeno obezbijediti nivo performansi kao i XCP, u razliitim scenarijima. Iako XCP-i performanse zavise od tanosti estimacije raspoloive irine opsega, XCP-i ipak nadmauje performanse TCP-a na linkovima velikih brzina, jer se brzo oporavlja od gubitaka paketa.

19

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

AKRONIMI
ACK AH AMID API AQM CBR CWND DCCP EC ECN FC FTP FQ HTTP IP IPSec ISP MIMD MIT MSS QoS RED REM RTO RTT SACK SCTP SMTP TCP UDP XCP Acknowledgement Authentication Header Additive Increase and Multiplicative Decrease Application Programming Interface Active Queue Management Constant Bit Rate Congestion Window Datagram Congestion Control Protocol Efficiency Controller Explicit Congestion Notification Fairness Controller File Transfer Protocol Fair Queuing HyperText Transfer Protocol Internet Protocol Internet Protocol Security Internet Service Provider Multiplicative Increase and Multiplicative Decrease Massachusetts Institute of Technology Maximum Segment Size Quality of Service Random Early Detection Random Exponential Marking Retransmission TimeOut Round-Trip Time Selective Acknowledgement Stream Control Transmission Protocol Simple Mail Transfer Protocol Transmission Control Protocol User Datagram Protocol eXplicit congestion Control Protocol

20

Kvaliteta usluge u TK mreama

XCP i izbjegavanje zaguenja

LITERATURA
[1] [2] http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-00.html http://59.67.33.37/faculties/ytshu/NET_I_09/Net_I_09_PPT/Ch6%20congest%20ctl/KHR02_x cp.pdf http://repository.tamu.edu/bitstream/handle/1969.1/ETD-TAMU-1291/JAINTHESIS.pdf?sequence=1 http://web.univ-pau.fr/~cpham/Paper/Globecom06.pdf http://www.ietf.org/proceedings/61/slides/tsvwg-5.pdf

[3]

[4] [5]

21