ABTEKNILLINEN KORKEAKOULU Tietoverkkolaboratorio

Transkriptio

1 ABTEKNILLINEN KORKEAKOULU Tietoverkkolaboratorio 12. Liikenteen- ja ruuhkanhallinta Internetissä luento12.ppt S Liikenneteorian perusteet - Kevät

2 Sisältö Johdanto IP-verkot Liikenteen- ja ruuhkanhallinta Internetissä QoS arkkitehtuurit 2

3 Liikenteenhallinta Liikenteellisiä ongelmia: Liikenne on luonteeltaan satunnaista (vaihdellen ennustamattomasti) ajoittain verkossa syntyy ruuhkaa (congestion) Liikennelähteet voivat käyttäytyä huonosti (pyrkien saamaan käyttöönsä enemmän kuin reilun osuuden verkon resursseista) Liikenteenhallintaa (traffic management) tarvitaan, jotta verkko saavuttaisi halutut laatu- ja suorituskykytavoitteet verkko pystyisi suojaamaan itsensä ja muut käyttäjät huonosti käyttäytyviä lähteitä vastaan Verkon suojaamiseen ruuhkatilanteilta on kaksi lähestymistapaa: ennakoivat (proactive) menetelmät, joilla pyritään ennalta välttämään ruuhkan syntyminen reagoivat (reactive) menetelmät, joilla pyritään lievittämään ruuhkasta aiheutuvia ongelmia ja poistamaan koko ruuhka 3

4 Miksi ei ATM? (1) ATM valittiin nopean yhteydellisen paketti(=solu)kytkentäisen verkon toteutusmenetelmäksi Pystyy tarjoamaan Liikenteenhallintaa Puheen ja datan integrointi samaan verkkoon Palveluluokkien avulla: CBR, VBR, ABR, UBR Signalointia ja palvelunlaatuun perustuvaa yhteyden muodostusta Mutta jotta todellinen päästäpäähän ratkaisu Tarvittaisiin uusia päätelaitteita (uutta HW ja SW)! ATM signalointi käyttäjän ja verkon välillä (UNI) pidetään monimutkaisena ja tarvittava tekniikkaa (HW + SW) pidetään kalliina Muita heikkouksia ATM:n palvelunlaatu mahdollisuudet hankalia käyttää Liikennesopimusten parametrien valintaan ei standardoituja menetelmiä Lyhyet solukoot sopivat paremmin äänelle kuin datalle Liian suuria muutoksia liian aikaisin 4

5 Miksi ei ATM? (2) Mutta samaan aikaan, kun ATM päätelaitteita ja laitteita kehiteltiin, Internetin käyttö räjähti Webbiselain mahdollisti helpon, yksinkertaisen ja halvan yhteyden Internetiin Käyttäjien ja liikenteen määrä Internetissä kasvoi eksponentiaalisesti Internet siis voitti kilpailun käyttäjän pöydälle! Internet on nyt kaikkialle ulottuva verkko Vielä on parannettava sen mahdollisuutta kuljettaa kaikenlaista liikennettä Nyt lähestymistapa on parantaa Internetiä ja sen palvelunlaatu mekanismeja Eikä rakentaa uutta verkkotekniikkaa (kuten ATM) ATM:ää käytetään kuitenkin runkoverkoissa 5

6 Verkon evoluutioon vaikuttavat trendit Pienevät laitekustannukset (CPU, muisti) Kasvava laskentateho ja tehokkaammat koneet Paljon kapasiteettia käyttävien sovellusten määrä kasvaa Linkkien nopeudet kasvavat dramaattisesti 1993: 100 Mbit/s (FDDI), 2000: 1 Tbit/s (WDM teknologialla) Kumpaa enemmän liikennettä vai kapasiteettia? Jos liikennettä enemmän kuin kuljetuskapasiteettia liikenteenhallintaa tarvitaan Jos kapasiteettiä riittävästi ei tarvita mitään liikenteenhallintaa Kapasiteetti ongelma WANeissa Dataliikenteen määrä ohitti puheliikenteen määrän 1999 Lähde: [4] 6

7 Sisältö Johdanto IP-verkot Liikenteen- ja ruuhkanhallinta Internetissä QoS arkkitehtuurit 7

8 Internet Erittäin laajalle levinnyt Tulee työpöydälle asti tietokoneisiin ja niiden sovellutuksiin on rakennettu tarvittava protokollatuki Webbiselaimen myötä käyttäjä- ja liikennemäärät kasvaneet eksponentiaalista vuosivauhtia Selain myös mahdollisti erilaisten sovellusten integroinnin virtaava liikenne, interaktiiviset chatit, pelit jne. IP-verkko on perustunut best-effort palveluun Palvelun laatu on tässä maailmassa ollut perinteisesti tuntematon käsite Juuret yhteydettömään pakettiverkko- ja reititintekniikkaan perustuvassa tietokoneiden välisessä kommunikaatiossa (ARPANET) verkon solmut eivät tallenna mitään käyttäjä- tai yhteyskohtaista tietoa Alunperin tarkoitettu ei-reaaliaikaisten viestien välittämiseen tiedostojen siirto, tietokoneiden etäkäyttö, sähköposti Uudet palveluarkkitehtuurit (DiffServ, IntServ) kuitenkin pyrkivät eriytettyyn palvelun laatuun 8

9 Vuot Vuo on verkkokerroksessa (siis reitittimissä) havaittu approksimaatio ylempien kerrosten liikenteestä Vuo (flow) = sarja peräkkäisiä ja toisiinsa kuuluvia IP-paketteja, joilla sama lähde ja määränpää Karkeassa luokittelussa huomioidaan vain lähde- ja määränpääosoite Hienommassa luokittelussa Erotellaan esim. ylemmät protokollat (esim. TCP, UDP, HTTP, FTP,...) Peräkkäiset vuot erotetaan toisistaan ajastimella peräkkäiset paketit kuuluvat samaan vuohon vain, jos niiden ajallinen etäisyys on tarpeeksi pieni Huom. Vuon määritelmä on hyvin joustava. Se, miten vuot käytännössä pitäisi luokitella, on oma taiteenlajinsa: karkeuden (granularity) valinta ajastuksen (timeout) valinta 9

10 Palvelun laatu Palvelun laatua voidaan tarkastella sekä vuo- että pakettitasolla Vuotasolla voidaan toisaalta ottaa kokonaisvaltainen näkökulma, jolloin tehokkuuden kannalta tärkeää on verkon kokonaisläpäisy (throughput), mutta toisaalta myös resurssien jaon oikeudenmukaisuus (fairness), tai vuokohtainen näkökulma, jolloin elastiselle liikenteelle tärkein laatutekijä on läpäisy (throughput) tai oikeammin hyödyllinen läpäisy (goodput) Pakettitasolla virtaavalle reaaliaikaiselle liikenteelle tärkein laatutekijä on pakettien päästä-päähän viive ja vaihtelut tässä viiveessä sen sijaan yksittäisten pakettien katoaminen tai korruptoituminen ei ole niin vaarallista elastiselle liikenteelle ja transaktioille (ts. yksittäisille paketeille) oleellisinta on pakettien menetyssuhteen pysyminen vähäisenä 10

11 IP-protokollapino H1 H2 H3 Network 2 (Ethernet) R1 Network 1 (Ethernet) H7 R3 H8 H4 Network 3 (FDDI) R2 Network 4 (point-to-point) H5 H6 H1 H8 TCP R1 R2 R3 TCP IP IP IP IP IP ETH ETH FDDI FDDI PPP PPP ETH ETH Lähde: [2] 11

12 IP IP = Internet Protocol Yhteydetön: ei yhteydenmuodostusta ei resurssien varausta Informaation siirto diskreetteinä paketteina vaihtelevanmittaisia sisältää otsikon, jossa mm. kohteen globaali osoite Best Effort palvelumalli verkon solmut, reitittimet, toimittavat paketteja eteenpäin parhaan kykynsä mukaan paketteja saattaa kadota, ne voivat viivästyä, tai niiden järjestys saattaa muuttua A B B B B B 12

13 IP-paketti IP-paketti = tietosähke (datagram) Version vaihtelevanpituinen Ident Flags Otsikko (väh. 20 tavua) [RFC791]: Version: nykyinen versio 4 SourceAddress IHL: otsikon pituus TOS: pakettien priorisointiin Options (variable) TotalLength: kokonaispituus Ident, Flags, Offset: pirstoutumiseen TTL: jäljelläoleva elinikä hyppyinä Data Protocol: kertoo ylemmän tason protokollan, esim. TCP (6), UDP (17) Checksum: otsikon virheettömyyteen SourceAddress, DestinationAddress: lähteen ja määränpään globaalit Internet-osoitteet IHL TOS TotalLength Offset TTL Protocol Checksum DestinationAddress Padding (variable) IP header Data 13

14 IP-pakettien käsittelymekanismit BE-reitittimissä Pakettien toimitus eteenpäin (forwarding): valitaan paketti sisääntulopuskurista, tutkitaan sen määränpääosoite, katsotaan reititystaulusta ko. osoitetta vastaava ulosmeno, ja viedään ko. paketti ko. ulosmenopuskuriin Pakettien skedulointi (scheduling) valitaan paketti ulosmenopuskurista ja käynnistetään sen lähetys ulosmenolinkillä tavallisin skedulointialgoritmi: FIFO Vrt. reititys (routing): hajautettu prosessi, jolla luodaan reitittimien reititystaulut (routing table) Control Plane Routing Forwarder User Plane Scheduler 14

15 Reititys Internet jakaantuu hallintapiireihin (routing domain) Reititysongelma voidaan jakaa hierarkkisesti yhden piirin sisällä (intradomain) pyritään löytämään optimaaliset reitit etsi edullisin reitti minkä tahansa kahden saman piirin solmun välillä, kun ko. piirin topologia ja linkkien kustannukset tunnetaan tähän ongelmaan on esitetty erilaisia algoritmeja Bellman-Ford-algoritmissa solmut kertovat naapureilleen etäisyydet kaikkiin muihin piirin solmuihin, esim. RIP Dijkstra-algoritmissa solmut kertovat kaikille muille piirin solmuille etäisyytensä naapurisolmuihin, esim. OSPF yleensä linkin kustannukseksi (so. kahden naapurisolmun etäisyydeksi) valitaan 1 jolloin optimireitit minimoivat tarvittavien hyppyjen lkm:n eri piirien välillä (interdomain) tärkeintä on selvittää saavutettavuus etsi jokin reitti minkä tahansa kahden piirin välillä, kun piirien välinen topologia tunnetaan, esim. BGP 15

16 Kuljetuskerroksen päästä-päähän protokollat Verkkokerroksen (IP) päällä on kuljetuskerros joka hoitaa IP-pakettien käsittelyn päätelaitteissa. TCP = Transmission Control Protocol yhteydellinen tarkoitettu elastiselle, ei-reaaliaikaiselle liikenteelle ei absoluuttisia QoS takeita, mutta takaa luotettavan tavupohjaisen tiedonsiirron liikenteen valvontaan kehitetty oma vuonohjaus/ruuhkanhallintamenettely perustuu adaptiivisen liukuvan ikkunan käyttöön UDP = User Datagram Protocol yhteydetön soveltuu erityisesti transaktioille (interaktiiviselle liikenteelle, jossa siirrettävät sanomat tyypillisesti lyhyitä) soveltuu myös (paremman puutteessa) virtaavalle, reaaliaikaiselle liikenteelle, jolloin UDP:n päällä tarvitaan vielä muita protokollia, esim. RTP ei minkäänlaisia QoS takeita 16

17 TCP TCP = Transmission Control Protocol yhteydellinen kuljetuskerroksen päästä-päähän protokolla IP:n päällä luotettava tavuvirran (reliable byte stream) siirto pakettien perillemeno oikeassa järjestyksessä varmistetaan kuittauksin ja uudelleenlähetyksin vuonohjaus (flow control): estää ylikuormittamasta vastaanottajan ruuhkanhallinta (congestion control): estää ylikuormittamasta verkon Application process Application process Write bytes Read bytes TCP Send buffer TCP Receive buffer Lähde: [2] Segment Segment Segment Transmit segments 17

18 TCP-paketti TCP-paketti = lohko (segment) vaihtelevanpituinen kuljetetaan läpi verkon IP-paketissa Otsikko (väh. 20 tavua) [RFC793]: SourcePort, DestinationPort: lähettäjän ja vastaanottajan identifiointiin SequenceNumber: lähetettävän lohkon ensimmäisen tavun indeksi AcknowledgementNumber: seuraavaksi vastaanotettavan tavun indeksi THL: otsikon pituus Flags: lipuilla kerrotaan esim. yhteyden avauksesta ja lopetuksesta Window: seuraavaksi vastaanotettavien tavujen kokonaismäärä Cheksum: pakollinen, sisältäen datan, TCP-otsikon ja IP-osoitteet THL SourcePort Reserved Checksum Options (variable) SequenceNumber AcknowledgementNumber Flags Data DestinationPort Window UrgentPointer Padding (variable) 31 IP header TCP header Data 18

19 UDP UDP = User Datagram Protocol yhteydetön kuljetuskerroksen päästä-päähän protokolla IP:n päällä vain multipleksointipalvelu ei takeita pakettien perillemenosta (siis epäluotettava) ei vuonohjausta (flow control): voi ylikuormittaa vastaanottajan ei ruuhkanhallintaa (congestion control): voi ylikuormittaa verkon UDP-paketti = tietosähke (datagram) vaihtelevanpituinen kuljetetaan läpi verkon IP-paketissa Otsikko (8 tavua) [RFC768]: SourcePort, DestinationPort: lähettäjän ja vastaanottajan identifiointiin Length: kokonaispituus Checksum: optionaalinen, sisältäen datan, UDP-otsikon ja IP-osoitteet SourcePort Length Data DestinationPort Checksum 31 IP header UDP header Data 19

20 Sisältö Johdanto IP-verkot Liikenteen- ja ruuhkanhallinta Internetissä QoS arkkitehtuurit 20

21 Liikenteen- ja ruuhkanhallintamekanismit eri aikaskaaloissa Response time: Long term (hours - days) Connection duration (secs - mins) RTT (ms - secs) Packet handling time (µs - ms) Proactive methods: - Routing algorithm - MPLS Traffic Engineering - TCP Vegas congestion avoidance - Scheduling - Active queue management Reactive methods: - TCP flow control - TCP congestion control - Queue management source based methods router based methods 21

22 Lähteissä toteutetut menetelmät TCP vuonohjaus (flow control) estää lähdettä ylikuormittamasta vastaanottajan menetelmänä adaptiivinen liukuva ikkuna vastaanottaja kertoo, montako tavua hän on valmis vastaanottamaan TCP ruuhkanhallinta (congestion control) estää lähdettä ylikuormittamasta verkon solmuja menetelmänä (sama!) adaptiivinen liukuva ikkuna verkosta ei tule suoraan tietoa, montako tavua lähde voi lähettää sen sijaan lähteen on itse pääteltävä, milloin verkko on ruuhkainen tällaisen signaalin antaa paketin katoaminen paketin kadotessa ikkunaa pienennetään muutoin sitä kasvatetaan (verkon tilan tunnustelemiseksi) ei koskaan suuremmaksi kuin vastaanottajan mainostama ikkunankoko TCP Vegas ruuhkanvälttäminen (congestion avoidance) tavoitteena voiden pakettien lukumäärän rajoittaminen pullonkaulalinkeissä ja sitä kautta ruuhkan ennaltaehkäiseminen ikkunan kokoa hallitaan vertaamalla odotettua ja lyhyintä kiertoaikaa 22

23 Reitittimissä toteutetut menetelmät Pakettien skedulointi (scheduling) seuraavaksi lähetettävän paketin valinta FIFO (First In First Out): paketit lähetykseen saapumisjärjestyksessä vuopohjaiset menetelmät kullekin aktiiviselle vuolle oma jono reilu jonotus (Fair Queueing, FQ): eri voiden paketit lähetykseen tasapuolisesti painotettu reilu jonotus (Weighted Fair Queueing) prioriteettipohjaiset menetelmät Jononhallinta (queue management) poistettavan paketin valinta jonon täyttyessä häntäpudotus (Tail Drop): saapuva paketti hylätään satunnaispudotus (Random Drop) Aktiivinen jononhallinta (active queue management) pakettien satunnainen poistaminen jo ennen jonon täyttymistä ehkäisee ruuhkan syntymistä ja TCP-lähteiden synkronoitumista esim. RED (Random Early Detection) 23

24 Liukuva ikkuna Luotettavan tiedonsiirron takaamiseksi lähetetty data pitää kuitata (acknowledge). Pakettien katoamisen varalta tarvitaan myös aikavalvontaa (timeout) ja uudelleenlähetyksiä (retransmission). Yksinkertainen menetelmä: stop-and-wait uusi paketti lähetetään, kun edellinen on kuitattu ongelma: linkin matala käyttöaste Tehokkaampi: liukuva ikkuna (sliding window) ikkunan koko W kertoo, montako kuittaamatonta pakettia voi korkeintaan olla lähetettynä stop-and-wait: W = 1 ikkunan koko W yhdessä kiertoajan T ja paketin lähetysajan S kanssa määrää lähetysnopeuden R: R = min{1/s, W/T} ikkunalla on siis efektiivinen yläraja: W T/S (eli kiertoajan T ja kaistan 1/S tulo) time time sender T sender S receiver W = 1 receiver W = 3 24

25 Adaptiivisen liukuvan ikkunan käyttö vuonohjaukseen Liukuvaa ikkunaa voidaan käyttää vuonohjaukseen. Jos vastaanottaja tyhjentää puskuriaan vakionopeudella C lähetysikkunalla on yläraja W CT estää lähdettä ylikuormittamasta vastaanottajan Jos vastaanottaja tyhjentää puskuriaan epäsäännöllisemmin vastaanottajan on eksplisiittisesti kerrottava, kuinka monta pakettia se on valmis vastaanottamaan kullakin hetkellä eli kuinka paljon sen puskuriin juuri sillä hetkellä mahtuu paketteja. TCP vuonohjauksessa tieto sallitusta ikkunankoosta kulkee (tosin tavuina) kuittaavan TCP-paketin Window-kentässä 25

26 Adaptiivisen liukuvan ikkunan käyttö ruuhkanhallintaan Liukuvaa ikkunaa voidaan käyttää myös ruuhkanhallintamenetelmänä Tavoitteena on sovittaa ikkunan koko W vastaamaan kyseiselle vuolle (juuri sillä hetkellä) verkossa käytettävissä olevaa kaistaa C ja kiertoaikaa T, ts. W = CT Tehtävää vaikeuttaa tietysti se, että sekä C että T vaihtelevat satunnaisesti, eikä niitä mikään taho ilmoita lähteelle (saati sitten täsmällistä ylärajaa ikkunalle) Lähde voi kuitenkin epäsuorasti saada tietoa ruuhkasta tekemällä havaintoja pakettien katoamisesta esim. uudelleenlähetysajastimen laukeaminen viittaisi tällaiseen tilanteeseen Paketin kadotessa pitää lähetysikkunan kokoa tietysti pienentää pudottaa lähetysnopeutta Toisaalta taas paketin mennessä läpi voidaan ikkunaa kasvattaa kasvattaa lähetysnopeutta timeout sender receiver 26

27 TCP ruuhkanhallinta Alkuperäinen TCP [RFC793] (1981) käytti adaptiivista liukuvan ikkunan menetelmää (adaptive sliding window) vain vuonohjaukseen Tämän seurauksena Internet kaatui aika-ajoin (congestion collapse): uudelleenlähetykset tukkivat verkon Jacobsonin (1988) ehdotti adaptiivisen liukuvan ikkunan menetelmän käyttöä myös ruuhkanhallintaan, nimeltään TCP Tahoe, se sisälsi seuraavat mekanismit hidas aloitus (slow start) ruuhkan välttäminen (congestion avoidance) nopea uudelleenlähetys (fast retransmit) Myöhemmin Jacobson (1990) ehdotti TCP Renoa, jossa oli vielä joitakin lisämuutoksia. nopea toipuminen (fast recovery) TCP-ruuhkanhallintamekanismit on koottu RFC2581:een (1999) 27

28 Sisältö Johdanto IP-verkot Liikenteen- ja ruuhkanhallinta Internetissä QoS arkkitehtuurit 28

29 QoS arkkitehtuurit Integroidut palvelut (Integrated Services, IntServ) määrittely IETF:ssä hienojakoinen (fine grained) vuokohtainen palvelun laatu, vrt. ATM-yhteydet absoluuttiset päästä-päähän laatutakeet mahdollisia pääsynvalvonta & resurssien varaus skaalautuvuusongelmia vuokohtaisen palvelun/kirjanpidon vuoksi Eriytetyt palvelut (Differentiated services, DiffServ) määrittely IETF:ssä yrittää ratkaista IntServin skaalautuvuusongelman niputtamalla voita runkoverkossa karkeajakoinen (coarse grained) staattiset palvelutasosopimukset (Service Level Agreement, SLA) palvelun laatu määritellään aggregoidulle liikenteelle (ei siis yksittäisille voille vaan vuokimpuille) vain suhteelliset hyppykohtaiset laatutakuut Vrt. ATM hienojakoinen: jos palvelunlaatu jokaiselle VC:lle karkeajakoinen: jos palvelunlaatu jokaiselle VP:lle eli aggregoidulle VC:ille 29

30 IntServ Palveluluokat (Service Class) Taattu-palvelu (Guaranteed Service), vrt. CBR reaaliaikaisille lähteille, joilla ehdoton viivevaatimus edellyttää pääsynvalvontaa, resurssien varausta ja pakettien priorisointia Kontrolloitu kuorma -palvelu (Controlled Load Service), vrt. VBR sopeutuville lähteille, jotka toimivat hyvin kunhan kuorma on rajoitettu edellyttää pääsynvalvontaa ja palveluluokkien erottelua reitittimissä Best-effort, vrt. ABR ja UBR IP tasolla perustuu TCP:n vuon- ja ruuhkanhallintaan Vuotason mekanismit Voiden määrittely (Flowspec) liikenteen kuvaus (TSpec) ja palveluvaatimuksen kuvaus (RSpec) Pääsynvalvonta (Admission control) Resurssien varaus signaloimalla (Resource reservation protocol, RSVP) Pakettitason mekanismit Pakettien luokittelu (classification) ja priorisointi Palveluluokkien erottelu skeduloimalla paketit vuokohtaisella WFQ:lla 30

31 Voiden määrittely (FlowSpec) IntServissä Vastaa ATM:n liikennesopimusta (traffic contract) Koostuu kahdesta osasta Rspec (vrt. ATM:n laatuparametrit) Tspec (vrt. ATM:n liikenneparametrit) RSpec (Request Specification): haluttu palvelu vain taatulle-palvelulle: vaadittu tavoite viiveelle (jonotusviiveelle) kontrolloidun kuorman palvelulle on jo etukäteen luvattu pieni kuorma TSpec (Traffic Specification): liikenteen kuvaus lähteen keskimääräinen nopeus lähteen huippunopeus purskeisuus muita vaihtuvakokoiseen pakettikokoon liittyviä parametreja 31

32 Vuoromerkkisanko (Token bucket) Lähteen käyttäytymistä tarkkaillaan ja luonnehditaan vuoromerkkisangon (token bucket) avulla lähteen keskimääräinen nopeus merkkien generointi nopeus (r) purskeisuus sangon tilavuus (b) muita parametreja vuoromerkin ja paketin koon rinnastamiseen Vuoromerkkisangon toiminta: Sanko on alussa täynnä (b kpl) vuoromerkkejä Sangon läpi kulkeva liikenne käyttää kokoaan vastaavan määrän merkkejä Sankoon tulee uusia merkkejä nopeudella r parametri m, pienin käsittelykoko määrää vuoromerkin yksikön Vuoromerkki sanko määrää onko saapuva paketti sopimuksen mukainen (in-profile) Vrt. ATM:n UPC ja siinä käytetty GCRA-algoritmi suurin ero on, että saapuvat paketit ovat vaihtuvamittaisia 32

33 IntServ Vuotason mekanismit reitittimissä Pääsynvalvonta Vuon määrittelyn (RSpec ja Tspec) perusteella Edeltää mahdollinen parametrien valvonta (vuoromerkkisanko) Reititin määrittelee voidaanko saapuva vuo hyväksyä ilman että muiden voiden palvelunlaatu (QoS) huononee tämä riippuu eniten reitittimen käyttämistä skedulointi mekanismeista Resurssien varaus signaloimalla (Resource Reservation) RSVP yhteydettömissä verkoissa (kuten Internet), käyttäjäkohtaista tietoa ei tallenneta reitittimiin RSVP yrittää säilyttää tämän robustin piirteen käyttämällä ns. soft-state tietoa yhteyksien elinaikaa päivitetään 30 s välein RSVP:n ideana on myös mahdollistaa sekä multicast että unicast palvelua Perustuu vastaanottajan toimintaan: Vastaanottaja (toisinkuin yhteydellisissä protokollissa) päättää resurssitarpeen Vastaanottaja voi muuttaa resurssitarpeitaan dynaamisesti refresh-viestiä käyttäen 33

34 RSVP esimerkki Lähde: [5] 34

35 IntServ Pakettitason mekanismit reitittimissä Pakettien luokittelu vuokohtaisesti sama lähde-, määränpääosoite, protokolla, lähde- ja määränpääportti jokaiselle paketille vuota vastaava resurssintarve ja -varaus Pakettien skedulointi Palveluluokat erotellaan sekdulointialgoritmien avulla Vuokohtaiset Prioriteettijono Weighted Fair Queueing (WFQ), kapasiteetti jaetaan vuokohtaisten painojen perusteella Skeduloinnilla pystytään toteuttamaan luvatut palveluluokat Ei yhtä oikeata ratkaisua 35

36 DiffServ IntServin suurin ongelma vuokohtaisuus vuokohtainen resurssien varaus, skedulointi ja vuokohtaisen tilan päivitys (RSVP) DiffServ Ei signalointia vaan palvelusopimukset (SLA) Verkon solmuissa toteutetaan määrätty määrä pakettien käsittelyluokkia (PHB) ei palveluluokkia, jossa parametrien valinnalla saadaan ääretön määrä luokkia käsittelyluokat paketeille ei voille! Palvelunlaatu on eriyttävää ja suhteellista Ei tiukkoja ja absoluuttisia palvelunlaatutakeita Suhteellisia takeita: Mitä korkeampi prioriteetti sitä parempi palvelunlaatu Monimutkaisemmat vuokohtaiset mekanismit reunareitittimissä (edge) Pakettien luokittelu (classification) ja merkkaus (marking) Voiden valvonta: mittaus (metering) ja muotoilu (shaping) Yksinkertaiset vuonippukohtaiset mekanismit runkoreitittimissä (core) Käsittelyluokkien erottelu skeduloimalla paketit luokkakohtaisella WFQ:lla Luokka- ja arvokohtaiset jononhallintamekanismit 36

37 Pakettien käsittelyluokat (PHB) Pakettien käsittelyluokat (Per Hop Behaviour, PHB) DiffServin liikenneluokka PHB:n avulla pyritään tarjoamaan erilaisia palveluja Se miten PHB:t toteutetaan eri mekanismeilla, jätetty avoimeksi Joudutettu toimitus (Expedited Forwarding, EF) tavoitteena lyhyet viiveet ja viiveenvaihtelut sekä alhainen pakettikato pakettien palvelunopeus on sama kuin maksimi lähetysnopeus toteutus antamalla ko. luokan paketeille ylin prioriteetti Varmistettu toimitus (Assured Forwarding, AF) kullekin AF-luokalle (max. 4) allokoidaan oma minimikaista AF-luokan sisällä 3-tasoinen pakettien arvojärjestys (drop precedence) yhteensä 12 eri luokkaa Paketin käsittelyluokka IP otsikossa 6 bittiä, jokainen bittikombinaatio on nimeltään Differentiated Service Code Point (DSCP) Type of Service kenttä IPv4ssa, Traffic Class IPv6ssa 37

38 DiffServ Verkon reunasolmuissa Pakettien luokittelu eli vuon ja käsittelyluokan määräys BA (Behavior Aggregate) tyyppiaggregaatti luokittelija luokittelee paketit DSCP:n perusteella MF (Multi-Field) monikenttä luokittelija luokittelee paketit IP otsikon muidenkin kenttien avulla (DSCP, osoitteet, protokolla,...) mittaukset Mittaus paketit Luokittelu Merkkaus Muotoilu/tiputus jonoon tiputus 38

39 DiffServ Verkon reunasolmuissa Paketin vuokohtaiset mekanismit käsittelyluokalle Mittaus: mitataan liikenne ja verrataan liikenneprofiiliin, esim EF:n bittinopeus Merkkaus: Paketit sopimuksen mukaisia (in-profile) tai ei (out-of-profile) voidaan myös merkata moneen prioriteettiluokkaan alempi prioriteetti, jos ylittää käsittelyluokan liikenneprofiilin ylempi prioriteetti, jos alittaa käsittelyluokan liikenneprofiilin Muotoilu/tiputus alemman prioriteetin paketit voidaan tiputtaa tai viivästyttää mittaukset Mittaus paketit Luokittelu Merkkaus Muotoilu/tiputus jonoon tiputus 39

40 DiffServ Verkon sisäsolmuissa Vain pakettien eteenpäin lähetys Perustuu paketin DSCP kenttään Paketti laitetaan luokkaansa vastaavaan jonoon Luokkakohtaisen skeduloinnin ja jononhallintamekanismien suunnittelu ratkaisevaa ei ollenkaan yksinkertaista! EF jono 1 luokka 1palvellaan aina ennen luokkaa 2 paketit Luokittelija PS 2 1>2 jononhallinta mekanismit jonon sisällä AF jonot Kaista jaetaan AF jonojen välillä painojen antamissa suhteissa 40

41 Internetin liikenteenhallinnan ongelmat DiffServ Päästäpäähän palvelunlaatua vaikeata ellei mahdotonta saavuttaa pelkkien PHB luokkien avulla luokkakohtainen palvelunlaatu ei riittävää pitkäkestoisille ja paljon kaistaa vaativille sovelluksille (esim. video) SLAt ovat staattisia mutta verkon tila ja liikenteen vaatimukset dynaamisia DiffServ verkon mitoitus hankalaa, koska ei tarkkoja laatuvaatimuksia IntServ vuokohtaista palvelunlaatua mahdotonta toteuttaa skaalautuvasti Paketti ja varsinkin IP-verkon joustavuutta ja yhteydellisten verkkojen takeita vaikea yhdistää kaikkia tyydyttävällä tavalla! 41

42 Kirjallisuutta 1 W. Stallings (1998) High-Speed Networks: TCP/IP and ATM design principles Prentice-Hall, New Jersey 2 L.L. Peterson and B.S. Davie (2000) Computer Networks A Systems Approach, 2 nd edition Morgan Kaufmann, San Francisco 3 V. Jacobson (1988) Congestion Avoidance and Control ACM SIGCOMM 88, Stanford, CA, August Professor Raj Jain s homepage e.g. course material from Recent Advances in Networking (1999) 5 Quality of Service Forum Homepage e.g. white papers on QoS and links to related sites 42