Palvelun laatutekijät SISÄLLYSLUETTELO

Transkriptio

1 SISÄLLYSLUETTELO 1. Palvelun laatutekijät Laadun parametrit Kaistanleveys Pakettien kokema viive Pakettien katoaminen ja niiden järjestys Jonotustekniikoita Luokkapohjaiset jonotustekniikat Oikeudenmukaiset jonotustekniikat Ruuhkanhallintamekanismit TCP ruuhkanhallinta UDP ruuhkanhallinta RSVP Integrated services Differentiated services TOS ja DS Classes of service Eri palvelumallien vertailu Lähdeluettelo 11 1

2 Tiina Suvanto 1. PALVELUN LAATUTEKIJÄT Internet protokollaan (IP) perustuvaa verkkoa ei ole tarkoitettu puheen tai muun reaaliaikaisen datan siirtämiseen. Sen vuoksi on kehitetty protokollia ja tekniikoita palvelun laatuun varmistamiseksi. Tarkoituksena on minimoida sekä hukkuneiden pakettien määrä että pakettien kokema viive ja tarjota sovelluksille tarvittava kaistanleveys. Palvelun laadun varmistamiseksi on kehitetty Best Effort palvelumallin lisäksi kaksi muuta palvelumallia: Integrated Service ja Differentiated Services. Niiden välinen ero on yhteyden laadussa ja palvelun laadun toteuttamisen mekanismeissa. Tässä esitelmässä tarkastellaan sekä itse palvelumalleja että niiden toteuttamiseen tarvittavia mekanismeja. 1.1 Laadun parametrit Ainoat laatutekijät, jotka huomioitiin pakettikytkentäisen IP-verkon suunnittelussa olivat pakettien luotettava siirto ja aineiston eheys eli se, että aineisto säilyy muuttumattomana perille asti. VoIP kuitenkin asettaa verkolle muitakin laatuvaatimuksia, koska siinä lähetetään reaaliaikaista ääntä ja/tai kuvaa. [3] Käsite Quality of Service (QoS) on vakiintunut tarkoittamaan tiettyjen laatutekijöiden, kuten virheiden ja viiveiden mittaamista, parantamista ja tietyssä määrin jopa tiettyjen laatuvaatimusten takaamista etukäteen. Pakettiverkoissa paketit kulkevat niin sanotun best effort periaatteen mukaisesti. Sen mukaan mikään ei ole taattua eikä minkäänlaista valvontaa ole. Myöhemmin verkkoon on liitetty vuonhallintaa ja liikenteen yksinkertaista priorisointia. [9] Best effort -verkko ei kuitenkaan sovellu puheen lähettämiseen ja siksi IP-verkkoon on liitetty uusia sovelluksia ja protokollia huolehtimaan reaaliaikaisen aineiston lähettämisen erityispiirteistä. Kuvassa 1 on kuvattu niitä ongelmia, jotka vaikuttavat pakettiverkossa siirretyn puheen laatuun. Pakettien katoamista tapahtuu yleensä, kun pakettien tielle tulee ruuhkaa ja reitittimet tiputtavat paketteja. Jitterillä tarkoitetaan pakettien viiveen vaihtelua, kuten kuvasta ilmenee. 2

3 Pakettien katoaminen Siirtoviive päästä päähän: kaikuilmiö Hei! Mitä kuuluu? Hei! Mitä kuuluu? T Hei!... Hei! Mitä kuuluu? Jitter Hei! Mitä kuuluu Hei! Mi- tä kuuluu Kuva 1. Äänen laatua heikentävät ongelmat.[3] VoIP käyttäjiä ovat ne kaikki henkilöt, jotka käyttävät puhelinta. Puhelun palvelun laatu on subjektiivinen asia, mutta Keepence esittää laadulle seuraavanlaisia kvalitatiivisia ja kvantitatiivisia mittoja [4]: Palvelun saatavuus (99,999%) Puhelun kytkemiseen kuluva aika (<2 sekuntia paikallispuhelulle) Viive (<150ms yhteen suuntaan) Äänen laatu (min kaiku ja häiriöt yhteydessä) Tärkeimmät laatuparametrit, jotka vaikuttavat puheen laatuun, ovat [3] Pakettien kokema viive Kaistanleveys Pakettien katoaminen ja niiden järjestyksen muuttuminen Kaistanleveys Kaistanleveys on yksi palvelun laatuun vaikuttavasta parametristä. Siihen liittyy muutakin kuin ainoastaan tarvittavan kaistanleveyden tarjoaminen sovelluksille. Haastavampaa etenkin TCP:n tapauksessa on tarjota kaikille oikeudenmukainen osuus kaistasta. Jonotustekniikoita tarkastellaan tarkemmin omassa kappaleessaan. [3] IP-puhelimen täytyy toimia sellaisessa ympäristössä, jossa kaistanleveys, viiveet, pakettien katoaminen ja kustannukset ovat rajoittavana tekijänä. 3

4 Tiina Suvanto ITU on tältä pohjalta muodostanut standardeja koskien koodekkeja. Tällä hetkellä kolme ITU:n koodekkia sopii VoIP ympäristöön, vaikka niitä ei sinne ole alun perin suunniteltukaan. Nämä koodekit ovat G723.1, G.729 ja G.729A. [5] Tarpeeksi suuri kaistanleveys on edellytys sille, että puhetta voidaan siirtää IP:n päällä. Standardeissa G.729 ja G.729A kehysten koot ovat pieniä, jolloin pienilläkin kaistanleveyksillä voidaan siirtää puhetta ilman suurta viivettä. Kotikäyttäjille parempi on kuitenkin G.723.1, koska sen avulla pieni kaistanleveys saadaan paremmin käyttöön. [5] Pakettien kokema viive Pakettien kokema viive on ongelmallisin palvelun laadun parametreistä. On jopa sanottu, että pakettien kokeman viiveen vuoksi, IP ei ollenkaan soveltuisi puheliikenteelle. Tämän ongelman ratkaisemiseksi on kehitetty jonotusalgoritmeja kuten Weighted fair queuing. Näillä algoritmeilla voidaan teoriassa taata tietty maksimiarvo viiveelle. Niitä on kuitenkin hankala käytännössä implementoida. RSVP on varausprotokolla, joka mahdollistaa tämän kaltaisen lähestymistavan maksimiviiveen asettamiseen. [3] Pakettien kokema viive voidaan jakaa useaan osatekijään: koodauksesta ja dekoodauksesta aiheutuva viive, joka on vakio, ja verkon kuormituksesta johtuvaan viiveeseen, joka on luonteeltaan satunnaista. Viiveet vaihtelevat voimakkaasti riippuen verkon kuormituksesta ja ominaisuuksista kuten vuonhallinnasta. Vuonhallinnalla pyritään estämään lähdettä ylittämästä vastaanottajan resursseja. [5] Pakettien katoaminen ja niiden järjestys IP-verkko ei takaa pakettien saapumista perille se ei ole niin sanottu päästä-päähän protokolla. Pakettien hukkuminen on väistämätöntä, mutta sitä voidaan korjata koodekkien avulla. Yksittäisten pakettien hukkuminen ei ole kriittistä IP-puheelle, mutta Internetille ominaiset purskeet ovat. Purskeilla tarkoitetaan useiden pakettien peräkkäistä katoamista. [5] 1.2 Jonotustekniikoita On kehitetty useita menetelmiä verkon viiveiden minimoimiseen ja verkon resurssien allokoimiseen oikeudenmukaisella tavalla. Jonoja esiintyy sekä laitteiden ja reitittimien sisäänmenossa että ulostulossa. Jonotustekniikat ovat oleellisia niin sanottujen Differentiated Services -palvelujen tarjoamisessa. Näitä palveluita käsitellään tarkemmin luvussa 1.5. [1] Yksinkertaisin jonotustekniikka on FIFO (first in first out), jossa yksinkertaisesti käsitellään tulevat paketit samassa järjestyksessä kun ne ovat tulleet. Tämä tekniikka on erittäin yleinen IP-verkossa ja se toimii hyvin niin kauan kuin verkon liikenne ei aiheuta paljon purskeita. Verkossa tietynlaiselle liikenteelle voidaan antaa myös korkeampi prioriteetti kuin muulle liikenteelle ja näin vähentää esimerkiksi juuri reaaliaikaisen datan viivettä. Tämä voi kuitenkin aiheuttaa nopeille linkeille 4

5 ylimääräistä kuormaa pakettien ylimääräisen prosessoinnin takia. Toinen ongelma on korkean prioriteetin pakettien suuri määrä. Alhaisen prioriteetin paketit eivät välttämättä pääse ollenkaan prosessoitavaksi, koska jonot vuotavat yli. [1] Luokkapohjaiset jonotustekniikat Luokkapohjaiset jonotustekniikat perustuvat siihen, että liikenne ohjataan useaan eri jonoon, joille annetaan prioriteetit ja joille jokaiselle tarjotaan tietty kaistanleveys. Eri luokkia voi olla niin sisäänmenojonoissa kuin ulostulojonoissakin. Jokainen luokka toimii FIFO periaatteella. Luokkapohjaisessa tekniikassa priorisoidaan yleensä UDP- ja Telnetliikennettä. Ongelmana on kuitenkin se, että priorisointi aiheuttaa ylimääräistä prosessointia linkeissä ja pakettien järjestyksen muuttumista. Siten se ei käy muille kuin hitaille linkeille. [1,3] Luokkiinlajittelualgoritmi käyttää hyväkseen IP-paketin otsikossa olevaa TOS kenttää, jota tarkastellaan tarkemmin luvussa 1.5. Algoritmi voi myös lajitella paketit perustuen osoitteisiin ja porttiin tai sitä voidaan hallita RSVP:n avulla. RSVP:tä tarkastellaan tarkemmin luvussa 1.3. [3] Luokkapohjaiset jonotustekniikat ovat perusta Differentiated Services palveluille, sillä ne perustuvat eri luokille tarjottavaan palvelun laadun ajatukseen Oikeudenmukaiset jonotustekniikat Oikeudenmukaisuuden käsite ei ole yksikäsitteinen. Näiden tekniikoiden perusideana on tarjota kaikille voille sama palvelu suhteutettuna niiden prioriteettiin. Yksinkertaisin oikeudenmukainen jonotustekniikka on TDM (Time Division Multiplexing) linkkeihin perustuva tekniikka, jossa jokaiselle vuolle määrätään prioriteetin mukaisesti aikavälejä linkistä. Tämän menetelmän ongelma on puuttuva datavirtojen eristäminen toisistaan. Toisin sanoen, jos yksi vuo ei ole lähettänyt dataa pitkään aikaan ja sitten lähettää suuren purskeen, tämä purske palvellaan ja muut vuot eivät saa palveltavaksi yhtään pakettia. [3] Weighted Fair Queuing (WFQ) on oikeudenmukaista periaatetta noudattava algoritmi, joka pyrkii tarjoamaan ennustettavissa olevia vasteaikoja. WFQ toteuttaa tämän lajittelemalla eri paketit eri voihin ja suhteuttamalla jonotusajat liikenteen määrään eri voissa. Oikeudenmukaisuus toteutuu siinä, että pienillekin voille taataan tietty määrä kaistanleveyttä. [1] WFQ:lla on joitakin samoja ominaisuuksia kuin prioriteettiin pohjautuvilla ja luokkapohjaisilla jonotustekniikoilla. Ylimääräisen priorisoinnista tai luokasta kertovan datan prosessointi ja yleensä jonon hallintaan liittyvät ongelmat ovat kuitenkin este näiden kaikkien tekniikoiden kehittymiselle ja laajalle käytölle tällä hetkellä. Lisäksi WFQ:n oikeudenmukaisuuden ohjaamiseen olisi panostettava, jotta tämän tekniikan käyttö olisi helpommin hallittavissa. [1] 5

6 Tiina Suvanto 1.3 Ruuhkanhallintamekanismit Ruuhkanhallinnalla tarkoitetaan tilannetta, jossa yhteydelle määritellään rajoja ruuhkautumisen tapahduttua. Tämä on tyypillistä pakettiverkoissa, joissa ei ole ollenkaan resurssienhallintaa eli rajojen määrittelemistä yhteydelle ennalta käsin. Esimerkiksi perinteisissä puhelinverkoissa ei ole ruuhkanhallintaa, koska resurssit on jaettu ennalta käsin. Ruuhkanhallinnassa algoritmi ratkaisee resurssien jaon ruuhkatilanteessa, koska lähteet kilpailevat samasta kaistasta. [8] Ruuhkanhallintamekanismeja on vaste- ja varauspohjaisia. Varauspohjaisissa järjestelmissä kuten RSVP (Resource Reservation Protocol) lähde pyytää verkolta tiettyä määrää resursseja yhteyden ajaksi. Pyyntö välitetään polun joka solmuun ja jokainen reititin joko täyttää tämän pyynnön tai hylkää yhteyden. Vastepohjaisissa menetelmissä lähteet aloittavat lähettämisen heti ja säätävät nopeuttaan saamansa vasteen perusteella. [8] TCP ruuhkanhallinta TCP ruuhkanhallinnan tehtävänä on selvittää, kuinka paljon verkossa on kapasiteettia vapaana. Ruuhkanhallinta toimii itseohjautuvasti käyttäen kellotus vastesanomia (ACK). Kellona toimii kiertoaikaviive (RTT), joka kertoo ajan paketin lähettämisestä sen vastaanottamiseen. Lähde suorittaa itseohjautuvaa verkon hallintaa perustuen vastesanomiin ja kadonneisiin paketteihin. [8] TCP:n ruuhkanhallinta perustuu ruuhkaikkunan koon muuttamiseen ja sen sopivan koon havaitsemiseen. Perusversioissa ruuhkaikkunan kokoa kasvatetaan lineaarisesti ja paketin kadotessa ikkunan koko putoaa nopeasti. Tästä syntyy TCP:lle tyypillinen sahalaitakuvio. Tämän mekanismin ongelmana on kuitenkin lähteen nopeuden liian hidas kasvattaminen alussa. Tarvitaankin tehokkaampi mekanismi ikkunan kasvattamiseen alussa. [8,10] Niin kutsutussa hitaan kasvamisen mekanismissa ikkunan kokoa kasvatetaan yhdestä paketista tuplaamalla jokaisen paketin kohdalla ikkunan arvo. Tämä mekanismi on nopeampi kuin perusmekanismi, mutta silti paljon hitaampi kuin koko ikkunallisen lähettäminen kerralla. Tämä mekanismi aikaansaa nopean ikkunan koon kasvamisen alussa ja aina paketin katoamisen jälkeen, mutta vastesanomien odottaminen aiheuttaa pitkät kuolleet hetket pakettien katoamisen jälkeen ennen kuin ajastin laukeaa. Pitkiä kuolleita hetkiä poistamaan on kehitetty nopean toipumisen mekanismi, jossa yksittäisen paketin hukkuminen ei aiheuta pitkää kuollutta hetkeä vaan lähde toipuu yksittäisen paketin hukkumisesta nopeammin. [8,10] RED (Random Early Detection) on algoritmi, jossa hyödynnetään reitittimen puskurin sen hetkistä tilaa pakettien tiputtamistodennäköisyyksien laskemiseen. RED:n tärkein tavoite on estää ruuhkautuminen hallitsemalla jonon keskimääräistä kokoa. RED ei myöskään aiheuta globaalia synkronisaatiota eli kaikkien verkon lähteiden yhtäaikaista joutumista hitaaseen vaiheeseen ruuhkaikkunan koon kasvattamisessa. Koska pakettien tiputtamiseen vaikuttaa vain jonon 6

7 keskiarvo, ei purskeinen liikenne aiheuta lineaarista kasvua pakettien tiputtamisen keskiarvoon. Siten mekanismi takaa, että puskurissa on tilaa myös purskeiselle liikenteelle. [2,8] UDP ruuhkanhallinta UDP:llä ei ole mitään standardinomaista ruuhkanhallintamekanismia. Siten kaikki kunnolliset UDP:n päällä toimivat sovellukset huolehtivat ruuhkanhallinnasta. Jotkut sovellukset kuitenkin lisäävät bittinopeuttaan, kun verkossa havaitaan ruuhkaa, koska silloin FIFO periaatteella toimivat linkit palvelevat suuremman määrän tämän sovelluksen redundantteja paketteja. Tämä perustuu siihen, että mitä enemmän lähde lähettää paketteja linkille, sitä enemmän se saa niitä myös läpi. [3] RSVP RSVP (Resource Reservation Protocol) on palvelun laatua takaamaan käytetty signalointiprotokolla, jonka avulla muodostetaan virtuaalinen yhteys kahden pisteen välille verkossa. Sen avulla voidaan IP-verkossa varata kaistanleveyttä multicast lähetyksiin ja muihin suurta kaistanleveyttä vaativiin sovelluksiin. RSVP:tä käytetään takaamaan laatu kaikissa paketin tielle tulevissa reitittimissä, jotta tietylle paketille voidaan taata pyydetty laatu. RSVP kuuluu Integrated Services malliin, jota tarkastellaan lähemmin kappaleessa 1.4. RSVP vaatii suurta laskentatehoa ja siksi sen ei soveltuvuus runkoverkon reitittimiin ei tällä hetkellä ole kovin hyvä, mutta tilanne saattaa muuttua prosessorien tehon parantuessa. [1,3] RSVP perustuu resurssien jakamiseen jokaisessa reitittimessä soveltaen vuolle pehmeää tilaa. Kovassa tilassa reititin pitää yllä tarkkaa tietoa yhteyden kytkennästä, resurssitarpeesta ja olemassaolosta. Pehmeän tilan varaus ja polku säilytetään jaksottaisilla virkistysviesteillä polun läpi. Tyypillisesti näitä viestejä lähetetään 30 sekunnin välien ja, jos viestiä ei tule, yhteys katkaistaan. Tällainen pehmeän tilan yhteyskäytäntö on välttämätön RSVP:lle, koska RSVP on varausprotokolla, jossa varauksella ei tarkoiteta staattista yhteyttä. [1] Tällaisella pehmeällä tilalla voidaan IP-puheellekin antaa tietty laatuvaatimus eli vaadittu kaistanleveys ja viiveen maksimimäärä ja sen vaihtelulle viiveestä riippuvat rajat. [3] Käytännössä RSVP varaus tietylle polulle verkossa tulee tehdä etukäteen ja varaus siirtyy koko polun läpi kaikille polun kaikille linkeille. RSVP paketit voivat olla eri kokoisia ja sisältää erilaista tietoa. Mikäli polulle osuva linkki ei tue RSVP:tä, paketti tunneloidaan tavallisena pakettina. RSVP:lle multicast on korkean prioriteetin tietoa. [10] RSVP on hyvin joustava protokolla yhteyden varaamiseen, koska virkistyssanoma täytyy kuitenkin lähettää jokaiseen polun solmuun tietyn väliajoin. Samalla on helppo muuttaa varauksen kaistanleveyttä tai purkaa yhteys. RSVP sisältää kahdenlaisia viestejä: PATH ja RESV. PATH on viesti, jonka lähettäjä lähettää vastaanottajalle polkua pitkin, jotta jokainen linkki osaa varata tarvittavat resurssit yhteyttä varten. Vastaanottaja taas lähettää RESV viestin takaisin samaa polkua pitkin, jotta lähettäjä tietää, 7

8 Tiina Suvanto että yhteys on varattu. Mallissa ei hylätä tai tiputeta yksittäisiä paketteja vaan koko vuo, jos yhteyttä ei voida muodostaa. Näiden viestien käyttöä on kuvattu kuvassa 2. [3,10] S Lähettäjä RESV PATH S S RESV Vastaanottaja S RESV Vastaanottaja Kuva 2. RSVP:n viestit ja niiden käyttö. [3,10] 1.4 Integrated services Liikenne IP-verkossa voidaan jakaa reaaliaikaiseen ja elastiseen eli eireaaliaikaiseen liikenteeseen. Reaaliaikainen liikenne jaetaan edelleen viiveen vaihtelua sietävään ja sietämättömään liikenteeseen. Perusidea Integrated Services (IntServ) palvelumallin takana on se, että ne sovellukset, jotka tarvitsevat tiettyä palvelun laatua verkolta, voivat sitä pyytää. Tässä mallissa joitakin paketteja kohdellaan toisin kuin toisia paketteja. [10] Tämä palvelumalli antaa siis käyttäjälle mahdollisuuden valita erilaisia palveluluokkia ja yhteyden laatutasoja. IntServ on yhteydellinen palvelu, joka on tyypiltään päästä-päähän palvelu. Sen keskeinen mekanismi on kappaleessa 1.3. kuvattu RSVP. [7] IntServ palvelumalli perustuu siis signalointiprotokolliin ja se tarjoaa vuokohtaisen luokittelun ja palvelun laadun. [6] Palvelumalli määrittelee neljä mekanismia, jotka muodostavat liikenteenhallinnan toiminnot OSI mallin kerroksella kolme ja sen alapuolella [1]: Pakettien järjestämismekanismi: Jonotusalgoritmi voi olla FIFO:a monimutkaisempi ja sen tehtävänä on myös määrätä, mikä vuo pääsee verkkoon lähettämään dataa. Pakettien luokittelu: Tämä mekanismi hoitaa pakettien luokittelun, jotta niitä voidaan kohdella erilaisesti riippuen käyttäjän vaatimuksista. Pyydetyn palvelun myöntämisen hallinnointi: Tehtävänä on päättää, saako tietty vuo pyytämäänsä palvelun laatua, jotta muut jo yhteyden muodostaneet vuot eivät häiriinny. 8

9 Resurssien varaus: Yhteydelliselle palvelumallille välttämätön resurssien varaus taataan RSVP:llä ja siten saadaan aikaan päästäpäähän yhteys. Tätä palvelumallia on vertailtu muihin palvelumalleihin kappaleessa 1.6 olevassa yhteenvedossa. 1.5 Differentiated services Differentiated Services (DiffServ) palvelumalli on yhteydetön palvelumalli, jossa paketit jaetaan luokiksi ja palvelun laatu perustuu näihin luokkiin. DiffServ palvelumalli käsittelee siis yksittäisiä paketteja eikä suorita vuokohtaista lajittelua. Tämä palvelumalli toteuttaa luokkakohtaisen jonotuksen ja verkko valvoo käyttäjän liikennettä. [7] DiffServ palvelumallin tavoitteena on luokkiin jaon avulla antaa etuoikeus tietynlaiselle liikenteelle esimerkiksi juuri reaaliaikaiselle liikenteelle. Palvelumalli ei kuitenkaan takaa tiettyä kaistanleveyttä tai viivettä kuten IntServ palvelumalli, vaan palvelu on luonteeltaan Best Effort -palvelua; tietyille luokille vaan annetaan parempi prioriteetti. [7] Jako luokkiin voi perustua eri tekijöihin, mutta seuraavassa on lueteltu yleisempiä jakoperusteita [1]: Protokolla: verkko- ja kuljetusprotokollat kuten IP, TCP, UDP. Lähteen protokollan portti: sovellusprotokollat, kuten Telnet riippuen niiden lähteen osoitteesta. Vastaanottajan protokollan portti: sovellusprotokollat, kuten Telnet riippuen niiden vastaanottajan osoitteesta. Protokollaspesifinen osoite, joka kertoo liikenteen alkuperän. Protokollaspesifinen osoite, joka kertoo liikenteen päämäärän. Lähteen laiterajapinta: rajapinta, johon tietyn laitteen liikenne saapui. Vuo TOS ja DS TOS (Type of Service) oktetti IP-paketin otsikossa kertoo paketin aseman muihin paketteihin nähden sekä varsinaisen halutun TOS kentän. Lisäksi oktetissa on yksi ylimääräinen bitti kokeellista käyttöä varten. Kuva 3 selventää tilannetta TOS Kuva 3. TOS oktetin rakenne IPv4:ssä. [3] 9

10 Tiina Suvanto Varsinainen TOS kenttä, jonka koko on 4 bittiä kertoo halutun kompromissin hinnan, viiveen, luotettavuuden ja prosessoitavan liikenteen määrän välillä. Eri vaihtoehdot on kuvattu RFC dokumentissa RFC Esimerkiksi arvo 1000 tarkoittaa viiveen minimoimista. Usein linkit eivät kuitenkaan huomioi TOS arvoa. [3] Internet standardointityön tuloksena TOS oktetti vaihdettiin DS (Differentiated Services) nimiseksi. Näin luokittelubitit saadaan tehokkaammin käyttöön ja paketteja voidaan luokitella jonoihin reitittimissä paremmin. TOS/DS oktetti mahdollistaa DiffServ palvelumallin käytön IP verkossa. [3] Classes of service Käsite Classes of Service (CoS) eroaa käsitteestä Quality of Service (QoS) siinä, että edellinen tarkoittaa selkeämmin pakettien jakoa luokkiin ja niiden palvelun laadun määrittelemistä siltä pohjalta. Tietylle liikenteelle voidaan tarjota best effort palvelua, kun taas jollekin toiselle luokalle tarjotaan tiettyä laatua. Tämä laatu ei kuitenkaan ole niin sanottua taattua laatua eli ei voida antaa viiveelle tiettyä maksimiarvoa vaan ainoastaan taata, että tietyn luokan paketit käsitellään korkean prioriteetin paketteina. [1] 1.6 Eri palvelumallien vertailu Taulukossa 1 on vertailtu kolmea eri palvelumallia ja samalla tiivistetty tärkeimmät asiat koskien palvelumalleja ja niiden eroja. Taulukko 1: Eri palvelumallien vertailu [1,3,7,10] Best Effort DiffServ IntServ Yhteydetön Yhteydetön Yhteydellinen EI päästä-päähän yhteyttä Päästä-päähän yhteys Yhteyskohtainen signalointi (RSVP) Luokkakohtainen laadun hallinta perustuu yksittäisiin paketteihin Luokittainen WFQ (Weighted Fair Queuing) Pyydetyn palvelun myöntämisen hallinnointi Vuokohtainen laadun hallinta Luokittainen tai vuokohtainen WFQ 10

11 1.7 Lähdeluettelo [1] Ferguson, P & Huston, G, Quality of Service: Delivering QoS on the Internet and in Corporate Networks, John Wiley & Sons, New York, 1998, 266 s. [2] Floyd, S. & Jacobson, V., Random Early Detection gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, 1993, Vol. 1 Nro. 4. [3] Hersent, O., Gurle, D. & Petit, J., IP Telephony: Packet-Based Multimedia Communications Systems, Addison-Wesley Pub Co, 1999, 304 s. [4] Keepence, B., Quality of service for voice over IP, IEE Colloquium on Services Over the Internet What Does Quality Cost? (Ref. No. 1999/099), 1999, 4/1-4/4 s. [5] Kostas, T., Borella, M., Sidhu, I., Schuster, G., Grabiec, J. & Mahler, J., Real-time voice over packet-switched networks, IEEE Network, 1998, Vol. 12, Nro. 1. [6] Kroth, N., Mark, L. & Tiemann, J., A framework for testing IP QoS over ATM networks: implementation and practical experiences, 2 nd Internaitonal Conference on ATM, ICATM, 1999, s. [7] Luoma, M., Arkkitehtuurit, 1999 [viitattu ] < [8] Luoma, M., Liikenteenhallinta Internetissä, 1999 [viitattu ] < [9] Melia, A., Quality of Sercive in enterprise networks, IEE Colloquium on Services Over the Internet What Does Quality Cost? (Ref. No. 1999/099), 1999, 2/1-2/4 s. [10] Peterson, L. & Davie, B., Computer Networks: A Systems Approach, Morgan Kaufmann Publishers, San Francisco, 1996, 552 s. 11