10. Liikenteen- ja ruuhkanhallinta ATM:ssä Osa 2

Transkriptio

1 S Liikenneteorian perusteet K-99 Osa 2 lect10.ppt 1 Sisältö Johdanto Liikenteen- ja ruuhkanhallinnan toimenpiteet ATM:ssä Pääsynvalvonta (CAC) Yhteysparametrien valvonta (UPC) ABR-palveluluokan liikenteenhallinta 2 1

2 Liikenteellinen ongelma Liikenne vaihtelee ennustamattomasti Ajoittain verkossa syntyy ruuhkaa Miten verkko saavuttaa halutut laatu- ja suorituskykytavoitteet? Miten verkko suojaa itsensä ja muut käyttäjät huonosti käyttäytyviä lähteitä vastaan LIIKENTEEN- JA RUUHKANHALLINNAN TAVOITE: verkon suojaaminen ruuhkatilanteilta siten, että palvelun laatutavoitteet voidaan täyttää verkon resurssien tehokas käyttö 3 Kaksi lähestymistapaa EHKÄISEVÄT TOIMENPITEET = LIIKENTEEN HALLINTA pyritään estämään jo ennalta ruuhkatilanteiden syntyminen REAGOIVAT TOIMENPITEET = RUUHKAN HALLINTA puretaan ruuhkaa minimoidaan vahingon intensiteetti, laajuus ja kesto Vastakkaisia tavoitteita menetelmien yksinkertaisuus menetelmien tehokkuus viiveherkät / virheherkät palvelut Yhteydellisen verkon tapauksessa (kuten ATM) liikennettä voidaan hallita varaamalla yhteyden käyttöön (koko yhteyden keston ajaksi) tarvittava määrä verkon resursseja (kaistaa ja puskuritilaa) 4 2

3 Esimerkkejä liikenteen- ja ruuhkanhallinnasta Puhelinverkko (piirikytkentäinen verkko): liikenteen- ja ruuhkanhallinta perustuu ennaltaehkäiseviin toimenpiteisiin kullekin yhteydelle varattu paitsi tietty määrä verkon resursseja (so. kaistaa 64 kbit/s kustakin reitin varrelta olevasta linkistä) jopa täsmälleen tietyt fyysiset resurssit (so. tietty aikaviipale kustakin reitin varrella olevasta linkistä) tilastollisen kanavoinnin vuoksi tämä ei ole mahdollista ATM:ssä X.25 (yhteydellinen pakettiverkko): liikenteen- ja ruuhkanhallinta perustuu ennaltaehkäiseviin toimenpiteisiin kullekin yhteydelle varataan tietty määrä verkon resursseja (tässä tapauksessa puskuripaikkoja pakettikytkimistä) koko yhteyden ajaksi kunkin yhteyden liikennettä hallitaan/valvotaan linkkikohtaisella ikkunointimenetelmällä, joka takaa, että yhteydelle varatut puskurit eivät koskaan vuoda yli (virheettömässä ideaalitilanteessa) IP (yhteydetön pakettiverkko): liikenteen- ja ruuhkanhallinta perustuu reagoiviin toimenpiteisiin tarkemmin sanottuna hallittuun reitittimien puskureiden ylivuotoihin kun paketti katoaa matkalla, ylemmän tason protokolla (TCP) päättelee, että verkossa on ruuhkaa ja pienentää sen seuraksena radikaalisti lähetysikkunaansa (jota sitten vähitellen kasvatetaan, kunnes taas jokin paketti katoaa) 5 Reaktiivisten menetelmien ongelmat ATM:n kannalta kaistanleveyden ja kiertoaikaviiveen tulo määrää paljonko informaatiota ehditään lähettää verkkoon ennenkuin lähetysnopeutta ehditään muuttaa verkosta/vastaanottajalta saadun palautteen perusteella laajakaistaisissa WAN-verkoissa tämä tulo kasvaa hyvin suureksi 6 3

4 Kiertoaikaviive-kaistanleveys -tulo 100 Mbit/s nopeus 80 Mbit/s 60 Mbit/s 40 Mbit/s 20 Mbit/s 100 kbytes 0 Mbit/s 20 ms 2000km 40 ms 4000km 60 ms 6000km 80 ms 8000km kiertoaika/ etäisyys 100 ms 10000km 7 Käsitteitä Liikenteenhallinta (traffic management) yleiskäsite Liikenteenhallinta (traffic control, congestion avoidance) ennaltaehkäisevät toimenpiteet ruuhkan välttämiseksi ennakoiva menetelmä Ruuhkan hallinta (congestion control) ruuhkan purkamiseen tähtäävät toimenpiteet reaktiivinen menetelmä Vuonohjaus (flow control) tarkoittaa yleensä sellaisia päästä-päähän menetelmiä, joilla vastaanottaja rajoittaa lähteen nopeutta, jottei ylivuotoa syntyisi vastaanottajan päässä 8 4

5 Sisältö Johdanto Liikenteen- ja ruuhkanhallinnan toimenpiteet ATM:ssä Pääsynvalvonta (CAC) Yhteysparametrien valvonta (UPC) ABR-palveluluokan liikenteenhallinta 9 Aikaskaalahierarkia AIKASKAALAHIERARKIA VERKON SUUNNITTELU JA RAKENTAMINEN vuosia VERKON DYNAAMINEN KONFIGUROINTI tunteja KUTSUTASO minuutteja PURSKETASO ms... s SOLUTASO us / 10 5

6 Liikenneprosessi eri aikaskaaloissa YHTEYSTASO muutokset aiheutuvat yhteyksien muodostamisista ja purkamisista (kesto useita minuutteja) NOPEUDEN MUUTOSTASO yhteyden tarvitsema lähetysnopeus muuttuu (kesto 20ms - minuutteja) PURSKETASO purskeiden saapuminen verkkoon esim. lähiverkosta (kesto 0,1ms - 100ms) SOLUTASO muutokset aiheutuvat eri yhteyksien vaiheiden satunnaisuudesta (kesto 1µs -1ms) 11 Liikenteen- ja ruuhkanhallinnan toimenpiteet eri aikaskaaloissa Ennaltaehkäisevät Reaktiiviset Aikataso Verkon suunnitelu, mitoitus CAC, Resurssien jakaminen, Reititys Nopea resurssien hallinta UPC/NPC, Liikenteen muokkaus, Priorisointi Verkon hallinta Adaptiivinen CAC, Dynaaminen reititys Ruuhkan ilmaisu, Vuonohjaus Solujen hylkääminen Kalenteritaso Kutsutaso Päästä päähän viiveen taso Solutaso 12 6

7 Liikenteen- ja ruuhkanhallinnan toimenpiteet (1) Verkon resurssien hallinta perustuu virtuaalipolkujen käyttöön VCC-yhteyksien ryhmittely eri virtuaalipoluille esim. liikennetyypin mukaan tilastollista kanavointia voidaan yleensä hyödyntää virtuaalipolun sisällä muttei niiden välillä VPC:n toimintakyky tulee asettaa vaativimman VCC:n mukaan ennaltaehkäisevää (staattinen kaistan allokointi) tai reagoivaa (dynaaminen kaistan allokointi) Yhteyksien hyväksyntä eli pääsynvalvonta (CAC, connection admission control) tärkein liikenteenhallinnan toimenpide Yhteysparametrien valvonta (UPC, usage parameter control) yhdessä yhteyksien hyväksyntämenettelyn kanssa muodostaa liikenteenhallinnan rungon 13 Liikenteen- ja ruuhkanhallinnan toimenpiteet (2) Priorisointi ja solujen valikoiva hylkääminen lähde itse voi merkitä vähemmän tärkeät solut CLP=1 -soluiksi verkko (UPC) voi merkitä sopimuksenvastaiset solut CLP=1 soluiksi (cell tagging) ruuhkatilanteessa verkko hylkää ensin CLP=1 soluja Yhteyden purku verkko voi purkaa sopimuksenvastaisen yhteyden Kehysten hylkääminen mikäli soluja joudutaan hylkäämään, on edullisempaa hylätä kokonaisia kehyksiä (so. ylemmän tason paketteja) Liikenteen muokkaus käytetään etupäässä varmistamaan liikenteen yhteensopivuus liikennesopimuksen kanssa valvontarajapinnassa älykkäät päätelaitteet suorittavat itse liikenteen muokkauksen myös kytkinlaitteet saattavat joutua suorittamaan liikenteen muokkausta verkkojen välisissä rajapinnoissa 14 7

8 Liikenteen- ja ruuhkanhallinnan toimenpiteet (3) Eksplisiittinen myötäsuuntainen ruuhkanilmaisu (EFCI, explicit forward congestion indication) ruuhkatilassa oleva kytkentälaite voi asettaa ATM-soluotsikossa olevan EFCI-bitin ykköseksi (käyttäjäsolujen PT-kentän keskimmäinen bitti) -- ei saa koskaan asettaa EFCI-bittiä nollaksi EFCI-bitin käyttö on järkevää vain osana laajempaa hallintamenettelyä, jossa päätelaitteiden käyttäytyminen on määritelty hyödynnetään (optionaalisesti) ABR-palveluluokan vuonohjauksessa Nopea resurssien hallinta (FRM, fast resource management) ATM-yhteyden edestakaisen kiertoajan aikaskaalassa tapahtuvat resurssinhallintatoimenpiteet perustuvat resurssinhallintasolujen (RM, resource management cell) käyttöön parannetuissa ruuhkanhallintamenetelmissä ei pelkästään ilmaista yhdellä bitillä, onko ruuhkaa vai ei, vaan kytkimet voivat RM-solun avulla ilmaista, millä nopeudella lähde voi lähettää soluja (ER, explicit rate) on käytössä ABR-palveluluokassa 15 Sisältö Johdanto Liikenteen- ja ruuhkanhallinnan toimenpiteet ATM:ssä Pääsynvalvonta (CAC) Yhteysparametrien valvonta (UPC) ABR-palveluluokan liikenteenhallinta 16 8

9 Pääsynvalvonta (CAC) CAC:n tulee pystyä määrittämään jokaisen yhteyspyynnön liikennesopimuksesta parametrien arvot liikennelähteen kuvaajasta pyydetyt ja hyväksyttävät arvot jokaiselle QoS-parametrille ja pyydetylle QoS-luokalle pyydetty yhteensopivuusmääritelmä. CAC päättää hyväksytäänkö yhteys vai ei valvottavat liikenneparametrit UPC:ta/NPC:ta varten reitityksestä ja resurssien varaamisesta Resurssitarpeen arviointi on verkko-operaattorin itse suoritettava menettelyä ei standardoida liikenteelliseltä kannalta vaativa toimenpide Yhteyden hylkäämisen tarkoituksena on taata hyväksytyille yhteyksille sovittu laatu ongelma siirretään aikahierarkiassa ylemmälle tasolle käyttäjät näkevät sen lisääntyneenä kutsuestona jos kutsutason palvelu ei ole riittävää on hankittava lisää VP-kapasiteettia verkonhallinnan toimenpitein tai viime kädessä lisättävä verkon fyysistä kapasiteettia 17 Resurssitarpeen arviointi Resurssitarpeen arviointi on palveluluokkakohtainen CBR yhteydelle on varattava kaistaa huippusolunopeuden (PCR) mukaan VBR yhteydelle varataan kaistaa ns. efektiivisen solunopeuden mukaan (ECR, effective cell rate), joka operaattorin on arvioitava SCR < ECR < PCR ECR riippuu toisaalta lähteen luonteesta (sekä liikenteestä että laatuvaatimuksista) ja toisaalta verkon laitteista (esim. linkin nopeudesta) ABR yhteydelle varataan kaistaa minimisolunopeuden (MCR) mukaan todellista nopeutta säädetään yhteyden aikana UBR yhteydelle ei varata kaistaa ollenkaan ei ole mitään takeita, kuinka paljon yhteys saa kaistaa (yhteyden aikana) Resurssintarpeen arvioinnin tulee olla sopusoinnussa CAC:n hyväksymismenettelyn kanssa 18 9

10 Yksinkertainen hyväksymismenettely Tarkastellaan tilannetta, missä eri palveluokat on eroteltu linkin sisällä eri virtuaalipolkuihin Merk. C:llä ko. virtuaalipolun huippusolunopeutta (so. PCR:ää) Indeksoidaan olemassaolevat yhteydet: i = 1, n Uusi yhteyspyyntö: n + 1 Yksinkertainen, pelkästään käytettävissä olevaan kaistaan perustuva hyväksymismenettely voisi olla palveluluokittain seuraava: CBR: uusi yhteys hyväksytään, jos PCR PCR n+1 < C VBR: uusi yhteys hyväksytään, jos ECR ECR n+1 < C ABR: uusi yhteys hyväksytään, jos MCR MCR n+1 < C UBR: kaikki uudet yhteydet hyväksytään 19 Efektiivinen solunopeus Käyttökelpoinen ennen kaikkea VBR-palveluluokan yhteydessä Usein kutsutaan myös efektiiviseksi kaistaksi (EB, effective bandwidth) tällöin yksikkönä pikemminkin bittejä sekunnissa (kuin soluja sekunnissa) Hyödynnetään tilastollista kanavointia kaistan tarvetta voidaan kompensoida puskuroinnilla (mitä enemmän puskuria, sitä pienempi ECR) Oletetaan lähteiden välinen riippumattomuus tämä takaa, että eri lähteiden nopeushuiput sattuvat päällekkäin vain hyvin pienellä todennäköisyydellä Huom. pahimmassa tapauksessa VBR-lähteet toimivat täysin synkronoidusti, jolloin on tyypillisesti tyydyttävä huippunopeusallokaatioon (jota tosin puskuroinnilla voidaan hieman lieventää) 20 10

11 Riippumattomien lähteiden tilastollinen kanavointi 21 Tilastollinen kanavointi puskurittomassa systeemissä Reaaliaikaisuusvaatimus => VBR-rt palveluluokan puskurit pieniä datapurskeiden kannalta verkko puskuriton häviöt määräytyvät hetkellisen nopeuden perusteella CLR = E[(Σ i R i - C) + ] / E[Σ i R i ] R i = lähteen i lähetysnopeus (hetkellinen) C = linkin nopeus Järjestelmän toiminta riippuu lähteiden nopeusjakaumista CLR:n sijasta usein helpompi laskea ylitystodennäköisyys P{Σ i R i > C} karkeasti ottaen samaa luokkaa CLR:n kanssa input rate link rate 22 11

12 Esimerkki efektiivisen kaistan laskennasta (1) Tarkastellaan n:n identtisen ja riippumattoman lähteen summaa (eli ns. superpositiota) kussakin lähteessä hetkellisen lähetysnopeuden R keskiarvo m ja varianssi σ 2 M ja Σ 2 lähteiden summan vastaavat parametrit Riippumattomuuden nojalla M = n m, Σ 2 = n σ 2 Jakauma on likimäärin normaalinen (keskeisen raja-arvolauseen perusteella) normaalijakautuman p-fraktiilia vastaa piste M + z p Σ Linkin kapasiteetti C ylittyy vakiotodennäköisyydellä ε (eli P{Σ i R i > C} = ε), kun C = M + z 1-ε Σ = n m + z 1-ε n 1/2 σ 23 Esimerkki efektiivisen kaistan laskennasta (2) Yhtä lähdettä varten tarvittava kaista EB = C / n = m + z 1-ε σ / n 1/2 Yksinkertainen malli kuvaa efektiivisen kaistan olennaisimmat piirteet: Efektiivinen kaista pienenee lähteiden lukumäärän (linkin kapasiteetin) kasvaessa Lähestyy asymptoottisesti keskinopeutta Efektiivisen kaistan laskemiseen kehitetty tehokkaita menetelmiä suurten poikkeamien teoria Tilastollinen kanavointi on tehokasta pieninopeuksisille lähteille on/off-lähteet, joiden huippunopeus on pieni suhteessa linkin nopeuteen huippunopeus < linkin nopeus /

13 Sisältö Johdanto Liikenteen- ja ruuhkanhallinnan toimenpiteet ATM:ssä Pääsynvalvonta (CAC) Yhteysparametrien valvonta (UPC) ABR-palveluluokan liikenteenhallinta 25 Yhteysparametrien valvonta (UPC/NPC) Tavoitteena on suojata verkkoa väärinkäyttäytyviltä lähteiltä turvata muiden yhteyksien QoS UPC/NPC:n ominaisuuksia: on VPC- tai VCC-kohtainen perustuu yhteydenmuodostuksessa sovittuihin liikenneparametreihin (liikennesopimus) tapahtuu verkon rajapinnoissa UPC (usage parameter control) suoritetaan UNI-rajapinnassa NPC (network parameter control) suoritetaan NNI-rajapinnassa Valvontaan käytetään GCRA-algoritmia UPC/NPC:n mahdolliset toimenpiteet (sopimuksenvastaisten solujen kohtelu) solujen päästäminen läpi solujen merkitseminen (CLP=0 => CLP=1) solujen hylkääminen 26 13

14 Valvonta-algoritmi GCRA(I,L) Algoritmissa GCRA(I,L) on kaksi parametria I valvottavaa nopeutta vastaava väliaika (ts. valvottavan solunopeuden käänteisluku) L sallittu (etuaikainen) poikkeama normaalista saapumisajasta Tästä on kaksi ekvivalenttia toteutusta virtuaalinen skedulointi (virtual scheduling) jatkuvatilainen vuotava sanko (continuous state leaky bucket) 27 Virtuaalinen skedulointi Muuttujat I = lisäys (increment) L = raja (limit) TAT = teoreettinen saapumisaika t a (k) = k:nnen solun saapumisaika Initialisointi yhteyden ensimmäisen solun saapuessa: TAT = t a (1) Toiminta yhteyden k:nnen solun saapuessa, k = 1,2,...: kuva oikealla solun k saapuminen hetkellä t a (k) ON sopimuksen vastainen solu t a (k) > TAT? EI t a (k) < TAT - L? EI ON TAT = t a (k) TAT = TAT + I sopimuksen mukainen solu 28 14

15 Jatkuvatilainen vuotava sanko Kuvitteellinen puskuri (sanko), jonka läpi soluvirran ajatellaan menevän Sanko vuotaa nopeudella 1 (yksi tilavuusyksikkö / aikayksikkö) Jokainen saapuva solu, joka on sopimuksen mukainen, tuo sankoon lisää nestettä määrän I Sangon koko on L+I Solu, joka saisi sangon vuotamaan yli on sopimuksenvastainen 29 Jatkuvatilainen vuotava sanko Jatkuvatilaisuus = sangossa nestettä Muuttujat I = lisäys (increment) L = raja (limit) X = sangossa olevan nesteen määrä Y = apumuuttuja LCT = edellinen sopimuksen mukainen saapumisaika t a (k) = k:nnen solun saapumisaika Initialisointi yhteyden ensimmäisen solun saapuessa: X = 0 LCT = t a (1) Toiminta yhteyden k:nnen solun saapuessa, k = 1,2,...: kuva oikealla solun k saapuminen hetkellä t a (k) sopimuksen vastainen solu Y = X - (t a (k) - LCT) ON EI EI Y < 0? Y > L? X = Y + I LCT = t a (k) sopimuksen mukainen solu ON Y =

16 GCRA:n soveltaminen (1) Voidaan soveltaa useita kertoja peräkkäin CBR-luokassa riittää huippunopeuden valvonta VBR-luokassa valvotaan sekä huippunopeutta että ylläpidettävissä olevaa nopeutta Huippusolunopeuden (PCR) valvonta Sovelletaan algoritmia GCRA(T, τ), missä T = 1 / PCR τ = CDVT Vaikka lähde lähettäisi täsmälleen T:n välein soluja, lähteen ja valvontamekanismin välissä olevat laitteet aiheuttavat (käyttäjästä riippumatonta) väliaikojen vaihtelua => valvontamekanismiksi ei kelpaa pelkkä soluväliaikoihin perustuva erottelu 31 GCRA:n soveltaminen (2) Ylläpidettävissä olevan solunopeuden (SCR) valvonta Sovelletaan algoritmia GCRA(T s, τ s + τ), missä T s = 1 / SCR τ s = pursketoleranssi BT (joka lasketaan purskeen maksimikoosta MBS) τ = CDVT Liikennesopimuksessa määritellään purskeen maksimikoko (MBS, maximum burst size), kun taas GCRA-algoritmi tarvitsee parametrikseen pursketoleranssin (BT, burst tolerance), joka ilmaistaan aikayksiköissä BT voidaan laskea MBS:stä seuraavasti: BT = (MBS - 1)(1/SCR - 1/PCR) 32 16

17 Pahimman tapauksen jaksolllinen VBR-liikenne Pahimmassa tapauksessa (joka vielä menee läpi valvonta-algoritmista) lähde lähettää MBS solua huippunopeudella PCR tähän kuluu aikaa MBS/PCR sekuntia pitää tämän jälkeen taukoa ajan MBS/SCR kuluttua ensimmäisen solun lähetyksen alkamisesta lähde lähettää uuden MBS:n solun ryppään nopeudella PCR jne. Pahimman tapauksen jaksollinen lähde on siis on-off-tyyppinen lähde on päällä (on) ajan MBS/PCR lähettäen tällöin huippunopeudella PCR lähde on pois päältä (off) ajan MBS/SCR - MBS/PCR (nopeus on tällöin 0) keskimääräiseksi lähetysnopeudeksi tulee SCR 33 Sisältö Johdanto Liikenteen- ja ruuhkanhallinnan toimenpiteet ATM:ssä Pääsynvalvonta (CAC) Yhteysparametrien valvonta (UPC) ABR-palveluluokan liikenteenhallinta 34 17

18 Best Effort -palvelut Palvelun laadun takaaminen johtaa verkon alhaiseen käyttöasteeseen => käyttämätön kapasiteetti tarjotaan "best effort" -palveluina (ABR, UBR ja GFR) kaista C ABR VBR CBR aika 35 ABR-palveluluokan liikenteenhallinta Yhteyden hyväksymisen yhteydessä sovitaan vain huippusolunopeudesta (PCR) sekä minimisolunopeudesta (MCR) PCR kertoo, millä nopeudella lähde korkeintaan voi soluja lähettää MCR kertoo, millä nopeudella lähde aina voi soluja lähettää (ainakin tämän verran on ko. yhteydelle siis varattava kaistaa) Puskurien ylivuodon (miksei myös alivuodon) välttämiseksi lähteen nopeutta säädetään suljetulla säätösilmukalla (säädetty nopeus voi olla mitä tahansa MCR:n ja PCR:n väliltä) ABR: ATM-verkkotason mekanismi UBR: siirtää vastuun nopeuden säädöstä kuljetuskerroksen protokollalle (esim. TCP) Ko. menetelmä on selvästikin reaktiivinen. Se reagoi esim. puskurin täyttöasteeseen (lähteiden nopeuksia lasketaan, kun täyttöaste ylittää jonkin kynnyksen, ja nostetaan, kun se putoaa jonkin alemman kynnyksen alapuolelle) tai täyttöasteen muutokseen (esim. lähteiden nopeuksia lasketaan aina, kun täyttöaste on kasvamassa, ja vastaavasti nostetaan, kun täyttöaste on vähenemässä) Kiertoaikaviiveen (RTT, round-trip time) ja kaistanleveyden (BW, bandwidth) tulo määrää reaktiivisten menetelmien hitauden Reiluus (fairness) on tärkeä kysymys 36 18

19 Nopeuspohjainen ABR-mekanismi Lähde lähettää RM-soluja N rm informaatiosolun välein Kytkin lukee solusta lähetysnopeuden ja laskee reilun kaistaosuuden Määränpää kääntää RM-solut paluusuuntaan Kytkin merkitsee palaavien RM-solujen ER-kenttään sallitun nopeuden lähde RM-solu määränpää Lisää ATM-lyhenteitä EB=Effective Bandwidth EFC=Effective Cell Rate EFCI= Explicit Forward Congestion Indication ER = Explicit Rate FRM = Fast Resource Management GCRA=Generic Cell Rate Algorithm NPC = Network Parameter Control RM = Resource Management RTT=Round Trip Time 38 19