Egy forrásból egy adott címzett csomópont felé tartó csomagok áramát folyamnak (flow) nevezzük. Összeköttetés-alapú hálózatban az ugyanazon folyamhoz tartozó csomagok ugyanazt az útvonalat járják be; összeköttetés nélküli hálózatokban haladhatnak különböző utakon is. Az egyes folyamok igényeit alapvetően négy paraméterrel írhatjuk le: megbízhatóság, késleltetés, dzsitter és sávszélesség. Ezek együttesen határozzák meg a folyam által igényelt szolgáltatásminőséget (Quality of Service, QoS).

Az 5.27. ábra néhány általános alkalmazást és azok hálózati követelményeit mutatja be. Vegyük figyelembe, hogy a hálózati követelmények kevésbé szigorúak, mint az alkalmazási követelmények azokban az esetekben, amikor az alkalmazás javítani tud a hálózat által biztosított szolgáltatáson. A hálózatnak nem kell veszteségmentesnek lennie a megbízható fájlátvitelhez, és nem kell azonos késleltetéssel kézbesíteni a csomagokat hang és videó lejátszása esetén. Bizonyos mennyiségű csomagvesztés újraküldéssel kijavítható, és valamilyen mértékű dzsitter kiegyenlíthető a csomagok fogadónál történő pufferelésével. Az alkalmazások azonban semmit sem tudnak tenni olyan helyzetekben, ahol túl kicsi a hálózati sávszélesség vagy túl nagy a késleltetés.

5.27. ábra - Alkalmazások szolgáltatásminőségi követelményeinek szigorúsága

Az alkalmazások sávszélesség-igénye eltérő. Az e-mail, a hangátvitel minden formája, valamint a távoli bejelentkezés (remote login) nem igényel nagy sávszélességet, viszont a fájlmegosztás és a videofolyam minden formájához nagy sávszélesség szükséges.

A késleltetési követelmények még érdekesebbek. A fájlátviteli alkalmazások – beleértve az e-mailt és videót is – a késleltetésre nem érzékenyek. Ha az összes csomag késleltetése egyformán néhány másodperc, az nem okoz problémát. Az interaktív alkalmazások, például a weben való szörfözés vagy a távoli bejelentkezés azonban már sokkal érzékenyebbek a késleltetésre. A valós idejű alkalmazások pedig, például a telefon- és a videokonferencia, már kimondottan szigorú követelményeket támasztanak a késleltetéssel szemben. Ha egy telefonhívás során minden szót túl hosszú ideig késleltetünk, a felhasználók elfogadhatatlannak fogják tartani a kapcsolatot. Ezzel szemben a hang- vagy videoállományok egy kiszolgálóról történő lejátszása nem igényel alacsony késleltetést.

A késleltetésnek vagy a csomagok érkezési idejének a változását (azaz a szórást) dzsitternek (jitter) hívják. Az 5.27. ábrán lévő első három alkalmazás nem érzékeny arra, ha a csomagok szabálytalan időközönként érkeznek be. A távoli bejelentkezés egy kicsit már kényesebb, mivel a karakterek apró löketekben fognak megjelenni a képernyőn, ha a kapcsolat nagyobb dzsitterrel terhelt. A videó, de különösen a hang, rendkívül érzékeny a dzsitterre. Az nem okoz gondot, ha egy felhasználó egy filmet néz a hálózaton keresztül, és a keretek pontosan 2 másodperc késleltetést szenvednek. De ha az átvitel ideje véletlenszerűen ingadozik 1 és 2 másodperc között, máris tragikus eredményt kapunk. A hangátvitelnél még a néhány milliszekundumos dzsitter is tisztán hallható.

Az első négy alkalmazás magasabb követelményeket támaszt a csomagvesztéssel szemben, mint a hang- és videoátvitel, mivel az összes bitet helyesen át kell vinni. Ez a cél rendszerint úgy érhető el, hogy a szállítási réteg újraküldi az elveszett csomagokat a hálózaton. Ez azonban pazarlás. Jobb lenne, ha a hálózat visszautasítaná azokat a csomagokat, amelyek először nagy valószínűséggel elvesznek. A hang- és videoalkalmazások el tudják viselni néhány csomag elvesztését újraküldés nélkül, mivel a felhasználók nem észlelik a rövid szüneteket vagy az alkalmanként kihagyott kereteket.

A hálózatok különböző QoS-kategóriákat támogathatnak a különböző alkalmazások igényeinek kielégítése érdekében. Az egyik sokszor emlegetett példa az ATM-hálózatból származik, amelyek egykor a hálózatról alkotott nagy látomás részét képezték, de azóta elavult technikává vált. Ezek a hálózatok a következő QoS-kategóriákat támogatják:

Ezek a kategóriák más hálózatokban, más célokra is hasznosak lehetnek. Az állandó adatsebességgel egy olyan vezetéket szimulálhatunk, amely változatlan sávszélességet és változatlan késleltetést biztosít. Változó adatsebesség például akkor fordulhat elő, ha egy mozgóképet tömörítünk, és némely keret jobban tömöríthető, mint a többi. Így egy nagyon részletgazdag keret elküldése sok bitet igényelhet, egy fehér fal képe viszont rendkívül jól tömöríthető. A hálózaton történő filmnézés valójában nem valós idejű, mivel néhány másodperces videó egyszerűen tömöríthető a fogadónál a lejátszás indítása előtt, így a hálózat dzsitterének hatására csupán a tárolt-de-nem-lejátszott videó mennyisége változik. A rendelkezésre álló adatsebesség az olyan alkalmazások számára megfelelő, amelyek nem érzékenyek a késleltetésre vagy a dzsitterre, mint például az e-mail.

Ahhoz, hogy a hálózat QoS-garanciákat biztosíthasson, tudnia kell, hogy milyen forgalomhoz szükséges a garancia. Telefonhálózat esetén ez a jellemzés egyszerű. Például egy hanghívás (tömörítetlen formátumban) 64 kb/s-os sebességet igényel, és egy 8 bites mintát tartalmaz 125 mikroszekundumonként. Az adathálózatokban azonban a forgalom löketekben érkezik. Jellemzően változó sebességgel érkezik, ahogy a forgalom sebessége változik (például tömörített videokonferencia), ahogy a felhasználók használják az alkalmazásokat (például új weboldal böngészése), illetve ahogy a számítógép kapcsolgat a feladatok között. Az ingadozó forgalom kezelése bonyolultabb, mint az állandó sebességű fogalomé, mivel a pufferek telítődhetnek és csomagok veszhetnek el.

A forgalomformálás (traffic shaping) a hálózatra belépő adatfolyam átlagos sebességének és ingadozásának (löketességének) szabályozására szolgáló technika. A cél az, hogy az alkalmazások az igényeiknek megfelelő, különböző típusú – löketeket is tartalmazó – forgalmat vihessenek át, továbbá, hogy rendelkezzenek egy egyszerű és használható eszközzel a hálózat lehetséges forgalmi mintáinak leírására. Amikor egy folyam felépül, a felhasználó és a hálózat (azaz az ügyfél és a szolgáltató) megegyeznek egy adott forgalmi mintázatban az adott folyamhoz. A valóságban az ügyfél a következőt mondja a szolgáltatónak: „Ilyen az átviteli mintám. Képes vagy ezt kezelni?”

Ezt szolgáltatásszintű megállapodásnak (Service Level Agreement, SLA) is hívják, különösen akkor, ha összesített folyamra és hosszú időtartamra vonatkozik, mint például egy ügyfél teljes forgalma. Mindaddig, amíg az ügyfél betartja az alku rá vonatkozó részét, és csak az elfogadott szerződésnek megfelelő módon küld csomagokat, a szolgáltató vállalja, hogy időben le is szállítja azokat.

A forgalomformálás csökkenti a torlódást, ezáltal segíti a hálózatot abban, hogy teljesítse az ígéretét. Ahhoz azonban, hogy ez működjön, felmerül az a kérdés is, hogy vajon a szolgáltató hogyan tudja megállapítani, hogy az ügyfél tartja-e magát a megállapodáshoz, és mit lehet tenni, ha kiderül, hogy nem? Az egyeztetett mintát meghaladó csomagokat a hálózat eldobhatja vagy alacsony prioritásúként jelölheti meg. A forgalom folyamának figyelését forgalmi rendfenntartásnak (traffic policing) nevezzük.

A forgalomformálás és a rendfenntartás nem túl fontos a P2P-hálózatoknál és más olyan adatok átvitele esetén, amelyek a teljes rendelkezésre álló sávszélességet vagy annak egy részét felhasználják. Nagy a jelentősége azonban az olyan valós idejű adatok – mint például a hang- és videoadatok – átvitele esetén, ahol szigorúak a szolgáltatásminőségi követelmények.

5.4.2.1. Lyukas vödör és vezérjeles vödör

Korábban már láthattunk egy módszert az alkalmazás által küldött adatok mennyiségének korlátozására: ez az ún. csúszóablak, amely egy paramétert használ az adott idő alatt átvitt adatok mennyiségének korlátozására, és amely indirekt módon korlátozza a sebességet. Most általánosabb módszert ismertetünk a forgalom jellemzésére: a lyukas vödör (leaky bucket) és a vezérjeles vödör (token bucket) algoritmust. A két módszer kissé különbözik, de azonos eredményre vezetnek.

Képzeljünk el egy vödröt, az alján egy kis lyukkal, ahogy az 5.28.(b) ábrán látható. Mindegy, hogy a víz milyen sebességgel érkezik a vödörbe, a kimenő folyam konstans R sebességű, amikor van víz a vödörben, és nulla, amikor a vödör üres. Ha a vödör a B kapacitásig megtelt, az ezután érkező víz kicsordul a vödörből és elvész.

5.28. ábra - (a) Forgalomformáló csomagok (b) Lyukas vödör. (c) Vezérjeles vödör

Ugyanez az ötlet alkalmazható a hálózatra belépő csomagokra is, amely szerint minden hoszt egy lyukas vödröt tartalmazó interfészen keresztül csatlakozik a hálózatra (ahogy azt az 5.28.(a) ábra mutatja). Egy csomag hálózatra küldéséhez lehetővé kell tenni több víz betöltését a vödörbe. Ha egy csomag akkor érkezik, amikor a vödör tele van, a csomagot vagy sorba kell állítani, amíg nem folyik ki elég víz, vagy el kell dobni. Az előbbi olyan hoszton lehetséges, amely a hálózati forgalmat az operációs rendszer részeként formálja. Az utóbbi a szolgáltató hálózati interfészének hardverén lehetséges, amely a hálózatra belépő forgalom rendfenntartását intézi. Ezt először Turner [1986] javasolta, és lyukas vödör (leaky bucket) algoritmusnak nevezte.

Alapjában véve a lyukas vödörrel azonos elképzelés, bár attól eltérő megoldás, ha a hálózati interfészt olyan vödörként képzeljük el, amely meg van töltve az 5.28.(c) ábrán látható módon. A csap R sebességgel engedi a vizet, a vödör kapacitása pedig B, mint ahogy korábban. Egy csomag küldéséhez vizet vagy vezérjeleket – ahogy a vödör tartalmát rendszerint hívják – kell tudnunk kivenni a vödörből (ahelyett, hogy vizet tennénk a vödörbe). Egy rögzített számú (B) vezérjelnél több nem halmozható fel a vödörben, és ha a vödör üres, akkor másik csomag küldése előtt várni kell további vezérjel érkezésére. Ezt az algoritmust vezérjeles vödör (token bucket) algoritmusnak hívják.

A lyukas vödör és vezérjeles vödör korlátozza a folyam hosszú távú sebességét, de engedélyezi, hogy a rövid távú löketek a maximális szabályozott hosszig változatlanul menjenek át, bármilyen mesterséges késleltetés nélkül. A nagy löketeket a lyukas vödör, mint forgalomformáló, elsimítja, hogy csökkentse a hálózati torlódást. Képzeljünk el például egy számítógépet, amely maximum 1000 Mb/s-os sebességgel tud adatokat előállítani (125 millió bájt/sec) és a hálózat első vonala szintén ezzel a sebességgel működik. A hoszt által generált forgalom mintája az 5.29.(a) ábrán látható. Ez a minta löketeket tartalmaz. Az átlagos sebesség több mint egy másodpercig 200 Mb/s, még akkor is, ha a hoszt 16000 KB-os löketet küld a maximális 1000 Mb/s-os sebességgel (a másodperc 1/8 részéig).

5.29. ábra - (a) Hoszt forgalma. Vezérjeles vödör által formált kimenet 200 Mb/s-os sebességgel és (b) 9600 KB és (c) 0 KB kapacitással. Vezérjeles vödör szintje a formáláshoz 200 Mb/s sebességgel és (d) 16 000 KB (e) 9600 KB és (f) 0 KB kapacitással

Tételezzük fel, hogy az útválasztók a maximális sebességű adatokat csak rövid ideig tudják fogadni, amíg a pufferek meg nem telnek. A pufferméret 9600 KB. Ez kisebb, mint a forgalomlöket. Hosszú távon az útválasztók akkor működnek a legjobban, ha a sebesség nem haladja meg a 200 Mb/s-os sebességet (mivel ez az ügyfél számára biztosított sávszélesség). Az ilyen minta szerint érkező forgalom következménye, hogy a csomagok egy része eldobásra kerül a hálózaton, mivel az összes csomag nem fér be az útválasztókon lévő pufferekbe.

A csomagvesztés elkerülése érdekében a forgalmat a hoszton vezérjeles vödörrel alakíthatjuk. Ha az R sebesség 200 Mb/s, a B kapacitás pedig 9600 KB, akkor a forgalom a hálózat által kezelhető tartományba esik. A vezérjeles vödör kimenetét az 5.29.(b) ábra mutatja. A hoszt rövid ideig adhat 1000 Mb/s-os sebességgel, amíg a vödör meg nem telik. Utána vissza kell fognia a sebességet 200 Mb/s-ra, amíg a löket elküldésre nem kerül. A löket hatása időben elhúzódik, mivel túl nagy ahhoz, hogy a hálózat egyszerre lekezelje. A vezérjeles vödör szintje az 5.29.(e) ábrán látható. A vödör induláskor tele van, és a kezdeti löket üríti ki. Amikor üres, akkor új csomagok csak olyan sebességgel küldhetők, amilyen sebességgel a puffer töltődik. Nem lehet több löket, amíg a vödör ismét tele nem lesz. A vödör töltődik, ha nincs forgalom, és töltöttsége egyenletes marad, ha a forgalom sebessége megegyezik a töltési sebességgel.

Simább forgalmat is előállíthatunk. Az 5.29.(c) ábra a vezérjeles vödör kimenetét mutatja R = 200 Mb/s sebesség és 0 kapacitás mellett. Ez egy szélsőséges eset, amelyben a forgalom teljesen kiegyenlített. A löketek nem megengedettek, és a forgalom egyenletes sebességgel lép be a hálózatra. A megfelelő vödörszint (lásd 5.29.(f) ábra) mindig üres. A forgalom sorba állításra kerül a hoszton a hálózatra kerülés érdekében, és mindig van küldésre váró csomag, ha az engedélyezett.

Végül az 5.29.(d) egy vezérjeles vödör szintjét mutatja R = 200 Mb/s sebesség és B = 16 000 KB kapacitás mellett. Ez a legkisebb vezérjeles vödör, amelyen keresztül a forgalom változatlanul halad. Ez használható a hálózaton lévő útválasztón a hoszt által küldött forgalom rendjének fenntartásához. Ha a hoszt által küldött forgalom megfelel a hálózattal egyeztetett vezérjeles vödörnek, akkor a forgalom a hálózat szélén lévő útválasztón futó vezérjeles vödörnek is megfelel. Ha a hoszt olyan sebességgel küldi a forgalmat, amely megfelel annak a vezérjeles vödörnek, amelyről a hálózattal megegyezett, akkor a forgalom meg fog felelni a hálózat szélén lévő útválasztón futó vezérjeles vödörnek is. Ha a hoszt gyorsabban vagy több lökettel forgalmaz, akkor a vezérjeles vödörből kifogy a víz. Amennyiben ez megtörténik, akkor a forgalom rendfenntartója tudja, hogy a forgalom nem a leírt módon halad. Ekkor a rendfenntartó a hálózat kialakításától függően vagy eldobja a többletcsomagokat, vagy csökkenti e csomagok prioritási szintjét. Példánkban a vödör a kezdeti löket végén csak egy pillanatra ürül ki, majd visszaáll a következő lökethez elegendő kapacitása.

A lyukas és a vezérjeles vödröt egyszerű megvalósítani. Most a vezérjeles vödör működését írjuk le. Annak ellenére, hogy a vödörbe befolyó és a vödörből kifolyó vízfolyamot folyamatosnak mondtuk, a gyakorlatban diszkrét mennyiségekkel kell működniük. A vezérjeles vödröt egy számlálóval valósítják meg, ami a vödör telítettségi szintjét mutatja. A számláló értéke másodpercenként egységgel növekszik. Ez az egység a fenti példában 200 kbit 1 milliszekundumonként. A számláló értéke eggyel csökken minden alkalommal, amikor adatok kerülnek elküldésre a hálózat irányába. Addig lehet adatokat küldeni, amíg a számláló el nem éri a nullát.

Ha a csomagok azonos méretűek, akkor a vödörszint mérhető csomagokban (például a 200 kbit 20 darab 1250 bájtos csomag). A csomagok azonban gyakran eltérő méretűek. Ebben az esetben a vödörszintet bájtban mérik. Ha a meglévő bájtszám túl kicsi nagy csomag küldéséhez, akkor a csomagnak várnia kell a következő órajelre (vagy még tovább, ha a töltési sebesség kicsi).

A maximális sebességű löket hosszának kiszámítása kissé trükkös. Nem egyszerűen 9600 KB osztva 125 MB/s-mal, mert miközben kiadjuk a löketet, további vezérjelek érkeznek. Ha a lökethossz S másodperc, a maximális kimeneti sebesség M bájt/s, akkor láthatjuk, hogy a kimeneti löket maximum  bájtot tartalmaz. Azt is tudjuk, hogy a bájtok száma egy S másodperc hosszú, maximális sebességű löketben MS. Így kapjuk a következőt:

Ezt az egyenletet megoldva kapjuk a következőt: . A megadott paraméterekkel, ahol B = 9600 KB, M = 125 MB/s, és R = 25 MB/s, 94 ms körüli löketidőt kapunk.

Egy lehetséges probléma a vezérjeles vödör algoritmusával, hogy a nagy löketeket lelassítja a hosszú távú R sebességre. Gyakran kívánatos a csúcssebesség csökkentése, de a lyukas vödör hosszú távú sebességéhez való visszatérés nélkül (és a hosszú távú sebesség növelése nélkül, amely több forgalmat engedélyezne a hálózaton). A simább forgalom előállításának egy módja, hogy egy újabb vezérjeles vödröt teszünk az első után. Alapvetően az első vödör jellemzi a forgalmat: rögzíti az átlagsebességet, de engedélyez némi löketet. A második vödör csökkenti a löketek hálózatba küldésének csúcssebességét. Ha például a második vezérjeles vödör sebessége 500 Mb/s, a kapacitás pedig 0, a kezdeti löket 500 Mb/s-os csúcssebességgel lép be a hálózatba, amely alacsonyabb a korábbi 1000 Mb/s-os sebességnél.

Ezeknek a vödröknek az alkalmazása egy kissé trükkös lehet. Ha vezérjeles vödröt használunk a forgalomformáláshoz a hosztokon, akkor a csomagok sorban állnak és késleltetést szenvednek, amíg a vödör nem engedélyezi a küldésüket. Ha vezérjeles vödröt használunk a forgalom rendjének fenntartásához a hálózat útválasztóin, akkor az algoritmus szimulálásra kerül annak ellenőrzése érdekében, hogy a megengedettnél több csomag nem kerül elküldésre. Ezek az eszközök kezelhetőbbé teszik a hálózati forgalmat, elősegítik a szolgáltatásminőségi követelmények kielégítését.

A szolgáltatásminőség szempontjából jó kezdet, ha szabályozni tudjuk a felkínált forgalom alakját. A teljesítőképesség garantálásához azonban elegendő erőforrást kell lefoglalni a csomagok hálózaton követett útvonala mentén. Ehhez feltételezzük, hogy a csomagok folyama mindig ugyanazt az útvonalat követi. Nehéz lenne bármit is garantálni úgy, hogy a csomagokat véletlenszerűen szórjuk szét a hálózaton. Következésképpen, a forrás és cél között valamilyen, a virtuális áramkörhöz hasonló kapcsolatot kell létrehozni, és a folyamhoz tartozó összes csomagnak ezt az útvonalat kell követnie.

Az algoritmust, amely útválasztó erőforrásokat oszt ki egy folyam csomagjai között és a versengő folyamok között, csomagütemezési algoritmusnak (packet scheduling algorithm) hívják. Háromféle erőforrást lehet lefoglalni a különféle folyamok számára:

Az első, a sávszélesség a legkézenfekvőbb. Ha egy folyamnak 1 Mb/s sávszélességre van szüksége, és a kimeneti vonal kapacitása 2 Mb/s, akkor azon a vonalon nyilván nem fogunk tudni három ilyen folyamot átvezetni. A sávszélesség lefoglalása tehát annyit jelent, hogy nem foglaljuk túl a kimeneti vonalat.

A második erőforrás, amiből gyakran hiányt szenvedünk, a pufferterület. Amikor egy csomag megérkezik, az útválasztón pufferelésre kerül, amíg át nem küldhető a választott kimeneti vonalon. A puffer célja a forgalom kis löketeinek elnyelése, amíg a folyamok versengenek egymással. Ha nincs szabad puffer, a csomagot el kell dobni, mivel egyszerűen nincs hová tenni. A jobb szolgáltatásminőség érdekében néhány puffer fenntartható meghatározott folyam számára, hogy az adott folyamnak ne kelljen a pufferért versengenie a többiekkel. Ily módon egy bizonyos határig mindig lesz szabad puffer, amikor a folyamnak szüksége van rá.

Végül a processzoridő is szűkös erőforrásnak számít. Az útválasztónak minden csomag feldolgozásához bizonyos processzoridőre van szüksége, így egy másodperc alatt csak korlátozott számú csomag feldolgozására van lehetőség. A modern útválasztók a legtöbb csomagot gyorsan fel tudják dolgozni, bizonyos csomagok azonban gyorsabb processzorfeldolgozást igényelnek, mint például az ICMP-csomagok, amelyekről az 5.6. szakaszban lesz szó. Ahhoz, hogy minden csomagot megfelelő időben feldolgozhassunk, biztosítani kell, hogy a processzor ne legyen túlterhelve.

A csomagütemezési algoritmusok a sávszélességet és más útválasztó erőforrásokat úgy foglalják le, hogy meghatározzák, melyik, a pufferben elküldésre váró csomagokat kell következőnek a kimeneti sorba helyezni. Az útválasztók működésének bemutatásánál már ismertettük a legegyszerűbb ütemezőt. Az útválasztók egy várakozási sorba rakják (pufferelik) a csomagokat minden kimeneti vonalhoz, amíg azok el nem küldhetők. A csomagok ugyanabban a sorrendben kerülnek elküldésre, mint ahogy érkeztek. Ezt az algoritmust FIFO-nak (First-In First-Out – elsőnek be, elsőnek ki) vagy FCFS-nek hívják (First-Come First-Serve – elsőként bekerül, elsőként kiszolgálva).

A FIFO-útválasztók általában akkor dobják el az újonnan érkezett csomagokat, ha a sor tele van. Mivel az újonnan érkezett csomag a sor végére kerül, ezt a viselkedést a farokrész eldobásának (tail drop) nevezik. Ez elgondolkodtathat bennünket, hogy milyen alternatívák léteznek. Az 5.3.5. részben leírt RED-algoritmus az újonnan érkezett csomagok közül véletlenszerűen dob el, amikor az átlagos sorhossz túl nagyra nő. A másik leírt ütemezési algoritmus egyéni lehetőségeket is ad annak eldöntéséhez, hogy mely csomagot kell eldobni, ha a pufferek tele vannak.

A FIFO-ütemezést egyszerű megvalósítani, de nem megfelelő a jó szolgáltatásminőség biztosításához, mivel ha több folyam van, akkor egy folyam könnyen befolyásolhatja más folyamok teljesítőképességét. Ha az első folyam agresszív, és nagy csomaglöketeket küld, akkor a csomagok egy várakozási sorba kerülnek. A csomagok beérkezési sorrendben történő feldolgozása azt jelenti, hogy az agresszív küldő lekötheti az útválasztó kapacitásának nagy részét, amelyen a csomagjai áthaladnak, kiéheztetve a többi folyamot, csökkentve ezáltal a szolgáltatásminőséget. És ami még rosszabb, más folyamok csomagjai, amelyek keresztülmennek ezen az útválasztón, valószínűleg késleltetést szenvednek, mivel sorban állnak az agresszív küldő csomagjai mögött.

Számos csomagütemezési algoritmus létezik, amelyek jobban elszigetelik a folyamokat, és megakadályozzák a zavarási kísérleteket [Bhatti és Crowcroft, 2000]. Az első ilyen elgondolások között volt az egyenlő esélyű sorba állítás (fair queuing) algoritmusa, amelyet Nagle [1987] írt le. Az algoritmus lényege az, hogy az útválasztók külön várakozási sorokat tartanak fenn minden kimeneti vonalon, minden folyam számára egyet. Ha egy vonal tétlen lesz, az útválasztó körforgásos (round-robin) alapon végignézi a sorokat, ahogy azt az 5.30. ábra szemlélteti, majd kivesz egy csomagot a következő sorból. Ily módon, ha n hoszt verseng egy adott kimeneti vonalért, akkor mindegyik egy csomagot küldhet el minden n csomagból. Ez abból a szempontból egyenlő esélyt biztosít, hogy az összes folyam azonos aránnyal küldhet csomagot. Több csomag küldése nem javítja ezt az arányt.

Bár kiindulásnak jó, az algoritmusnak van egy hiányossága: nagyobb sávszélességet ad a nagy csomagokat használó hosztoknak, mint a kis csomagokat használó hosztoknak. Demers és mások [1990] ennek kiküszöbölésére azt javasolták, hogy a körforgást bájtonkénti körforgásként szimulálják a csomagonkénti körforgás helyett. A trükk a körforgások számát megadó virtuális idő kiszámítása, amely alatt az egyes csomagok elküldése befejeződik. Minden kör egy bájtot vesz ki minden sorból, amelyben küldendő adatok vannak. A csomagok ezután befejezési idejük sorrendjében rendeződnek, és ebben a sorrendben kerülnek elküldésre.

5.30. ábra - Körforgó egyenlő esélyű sorba állítás

Ez az algoritmus és egy példa látható az 5.31. ábrán, amely három folyamban érkező csomagok befejezési idejét illusztrálja. Ha egy csomag hossza L, akkor a befejezéshez szükséges körök száma egyszerűen L lesz a kezdő időpont után. A kezdő időpont az előző csomag befejezési időpontja, vagy a csomag beérkezési ideje, ha a sor üres, amikor a csomag megérkezik.

5.31. ábra - (a) Súlyozott egyenlő esélyű sorba állítás. (b) Csomagok befejezési ideje

Ha az 5.31.(b) ábrán lévő táblázatban csak a felső két sorban lévő első két csomagot nézzük, akkor a csomagok a következő sorrendben érkeznek: A, B, D és F. Az A csomag a 0. körben érkezik és 8 bájt hosszú, így ennek befejezési ideje 8 kör. Ehhez hasonlóan a B csomag befejezési ideje 11. A D csomag megérkezik, miközben a B elküldése folyamatban van. Ennek befejezési ideje 9 óraütés a B befejezése után, azaz összesen 20. Ehhez hasonlóan az F befejezési ideje 16. Új érkezők hiányában a relatív küldési sorrend A, B, F, D annak ellenére, hogy F a D után érkezett. Elképzelhető, hogy másik kis csomag érkezik a felső folyamon és a befejezési ideje D előtti. Csak akkor kerül D elé, ha a D csomag átvitele nem kezdődött el. Az egyenlő esélyű sorba állítás nem előzi meg azokat a csomagokat, amelyek átvitele folyamatban van. Mivel a csomagok egészben kerülnek elküldésre, az egyenlő esélyű sorba állítás az ideális bájtonkénti átviteli sémának csak egy megközelítése. De ez egy nagyon jó megközelítés, amely mindenkor az ideális séma egyetlen csomagátvitelén belül marad, vagyis az ideális sémától legfeljebb egy csomagnyira távolodik el.

Ennek az algoritmusnak az egyik hibája a gyakorlatban az, hogy minden hosztnak azonos prioritást biztosít. Sok esetben kívánatos például a videokiszolgálóknak nagyobb sávszélességet adni, mint például a hagyományos fájlkiszolgálóknak. Ez egyszerűen kivitelezhető, ha két vagy több bájtot adunk nekik óraütésenként. Ezt a módosított algoritmust súlyozott egyenlő esélyű sorba állításnak (weighted fair queueing, WFQ) hívják. Ha az óraütésenkénti bájtok száma a folyam súlya, W, akkor a befejezési idő kiszámításának a képlete a következő lesz:

ahol az érkezési idő, a befejezési idő, pedig az i csomag hossza. Az 5.31.(a) ábra alsó sorának súlya 2, így a csomagok gyorsabban kerülnek elküldésre, ahogy azt az 5.31.(b) ábrán látható befejezési idő is mutatja.

A másik gyakorlatban felmerülő probléma a bonyolult megvalósítás. WFQ esetén a csomagokat a befejezési idejük alapján kell a rendezett sorba rakni. N folyam esetén ez a legjobb esetben is művelet csomagonként, amit a nagy sebességű útválasztókban lévő sok folyam esetén nehéz megvalósítani. Shreedhar és Varghese [1995] ennek megoldására a különbséggel súlyozott körbejárást (deficit round robin vagy deficit weighted round robin) javasolja, amely hatékonyan megvalósítható, csomagonként csak művelettel. A WFQ-t széles körben használják ezzel a megközelítéssel.

Más típusú ütemezési algoritmusok is léteznek. Egyszerű példa a prioritásütemezés, amelyben minden csomaghoz tartozik prioritás. A magas prioritású csomagok mindig az alacsony prioritású csomagok előtt kerülnek elküldésre, amelyek pufferbe kerülnek. Az azonos prioritású csomagok FIFO-sorrendben kerülnek elküldésre. A prioritásütemezés hátránya azonban, hogy a magas prioritású csomagok lökete kiéheztetheti az alacsony prioritású csomagokat, amelyeknek így esetlegesen határozatlan ideig kell várniuk. A WFQ gyakran jobb alternatívát kínál. Ha a magas prioritású sor nagy súlyt kap, például 3-at, akkor a magas prioritású csomagok gyakran rövid vonalon mennek át (mivel viszonylag kevés csomag lehet magas prioritású), azonban az alacsony prioritású csomagok egy része továbbra is elküldésre kerül még magas prioritású forgalom esetén is. A magas és alacsony prioritású rendszer lényegében egy kétsoros WFQ-rendszer, amelyben a magas prioritásnak a súlya végtelen.

Az ütemező utolsó példájaként a csomagok tartalmazhatnak időbélyeget, és elküldhetők az időbélyeg sorrendjében. Clark és mások [1992] olyan kialakítást ismertetnek, amelyben az időbélyeg azt jelzi, hogy a csomag hol tart az ütemezéséhez képest (előtte vagy mögötte van) az útvonalon lévő útválasztókon történő átküldés során. Azok a csomagok, amelyek más csomagok mögött kerültek sorba állításra egy útválasztón, lemaradnak az ütemezéshez képest, az elsőként kiszolgált csomagok pedig gyorsabbak lesznek, mint az ütemezés. A csomagok időbélyeg szerinti küldésének előnye, hogy a lassú csomagokat felgyorsítja, a gyorsakat pedig lelassítja. Ennek eredménye, hogy a hálózat az összes csomagot következetesebb késleltetéssel kézbesíti.

Már láttuk a QoS valamennyi szükséges elemét, így eljött az ideje, hogy ezeket összerakjuk a szolgáltatásminőség tényleges biztosításához. A QoS-garanciák a belépés-ellenőrzési folyamattal valósulnak meg. A belépés-ellenőrzést először a torlódáskezeléshez alkalmaztuk, amely teljesítőképességi garancia ugyan, de elég gyenge. A most tárgyalt garanciák erősebbek, de a modell ugyanaz. A felhasználó szolgáltatásminőségi követelménnyel együtt küldi a folyamot a hálózat felé. A hálózat ezután a kapacitás és a más folyamokkal szemben vállalt kötelezettség alapján eldönti, hogy elfogadja vagy visszautasítja a folyamot. Ha elfogadja, akkor kapacitást foglal le előre az útválasztókon a QoS garantálásához, amikor a forgalom elküldésre kerül az új folyamon.

A foglalást a csomagok által bejárt útvonal összes útválasztóján meg kell tenni. A lefoglalás nélküli útválasztókon torlódás léphet fel, és egyetlen torlódott útválasztó meg tudja hiúsítani a QoS-garanciát. A legtöbb útválasztó algoritmus minden forrás és cél között igyekszik megtalálni a legjobb utat, és minden forgalmat a legjobb úton küld. Ez néhány folyam visszautasítását okozhatja, ha nincs elegendő felesleges kapacitás a legjobb útvonal mentén. Új folyamok a QoS garanciáinak kielégítéséhez még alakítható a rendszer azáltal, hogy másik útvonalat választ a kapacitást meghaladó folyamhoz. Ezt QoS-útválasztásnak (QoS routing) nevezik. Chen és Nahrstedt [1998] áttekintést adnak ezekről a technikákról. A forgalom minden célnál több útvonalra elosztható a felesleges kapacitás egyszerűbb megtalálása érdekében. Útválasztók esetén egyszerű megoldás az, ha egyenlő költségű útvonalakat választunk és a forgalmat egyenletesen osztjuk fel, vagy megoszthatjuk a forgalmat a kimeneti vonalak kapacitásának arányában. Léteznek azonban kifinomultabb algoritmusok is [Nelakuditi és Zhang, 2002].

Adott útvonal esetén a folyam elfogadásról vagy elutasításról szóló döntés nem pusztán a folyam által kért erőforrások (sávszélesség, pufferek, processzoridő) és az útválasztó ezen három dimenzió mértékében mért felesleges kapacitásának összehasonlításából áll. Ennél azért bonyolultabb kérdésről van szó. Kezdjük azzal, hogy néhány alkalmazás tisztában van ugyan a saját sávszélesség-igényével, a pufferekről vagy a processzoridőről azonban már kevesen tudnak. Így a legkevesebb az, hogy más módot kell találnunk a folyamok leírására és a leírásnak az útválasztó-erőforrásokra való lefordítására. Hamarosan ezzel is foglalkozunk.

Továbbá, egyes alkalmazások sokkal jobban tolerálnak egy esetlegesen lekésett határidőt, mint mások. Az alkalmazásoknak választani kell a hálózat által biztosított garanciatípusok közül, amelyek lehetnek szigorú garanciák, vagy olyan viselkedés, amely az idő nagy részében biztosítható. Ha mindezek azonosak lennének, akkor mindenki szigorú garanciákat szeretne, de a gond az, hogy ez költséges, mivel ezek korlátozzák a legrosszabb esetbeli viselkedést. A csomagok nagy részének nyújtott garancia gyakran elegendő az alkalmazások számára, és több folyam ezzel a garanciával hozzájuttatható egy rögzített kapacitáshoz.

Végül, egyes alkalmazások hajlandók lehetnek a folyamparaméterekről alkudozni, mások ellenben nem. Például egy általában 30 keret/s sebességgel működő filmlejátszó hajlandó lehet 25 keret/s sebességre visszaállni, ha nincs elég sávszélesség az előbbi sebességhez. Hasonlóképpen változtatható a keretenkénti képpontok száma, a hang sávszélessége és egyéb jellemzők.

Mivel az egyeztetésben sok fél vesz részt (a feladó, a címzett és a kettejük közötti úton lévő összes útválasztó), a tárgyalás alapját képező paramétereket tekintve pontosan le kell tudnunk írni a folyamokat. Az ilyen paraméterek halmazát folyammeghatározásnak (flow specification) hívjuk. Általában a feladó (például egy videokiszolgáló) állítja elő a folyammeghatározást, amikor is ajánlatot tesz az általa használni kívánt paraméterekre. Ahogy a meghatározás végighalad a leendő útvonalon, minden útválasztó megvizsgálja azt, és igénye szerint módosítja az egyes paramétereket. A módosítások nem növelhetik a folyamot, csak csökkenthetik (például kisebb adatsebességet megadhatnak, nagyobbat nem). Az útvonal végére érve a paraméterek elnyerik végleges értéküket.

A folyammeghatározás lehetséges tartalmára mutat példát az 5.32. ábra. Ez az RFC 2210-et és az RFC 2211-et veszi alapul, amelyek az integrált szolgáltatásra és a QoS tervezésére vonatkoznak. Ezeket a témákat a következő szakaszban fogjuk megvizsgálni. Itt öt paraméterről van szó. Az első két paramétert, a vezérjeles vödör sebességét, és a vezérjeles vödör méretét arra használják, hogy egy vezérjeles vödör megadja azt a fenntartott legnagyobb sebességet, amellyel a küldő adhat, hosszú idő átlagában, valamint hogy megadja azt a legnagyobb löketet, amit az adó egy rövid időtartam alatt elküldhet.

5.32. ábra - Példa a folyammeghatározásra

A harmadik paraméter, az adatsebesség csúcsértéke a maximális megengedett átviteli sebesség. Az adó sosem lépheti túl ezt az értéket, még rövid löketek esetén sem.

Az utolsó két paraméter a minimális és maximális csomagméretet határozza meg, beleértve a szállítási és a hálózati réteg fejrészeit is (például TCP és IP). A minimális méret azért fontos, mert a feldolgozás minden csomagnál fix időt vesz igénybe, függetlenül attól, hogy milyen rövid a csomag. Lehet, hogy egy útválasztó képes másodpercenként 10 000 darab 1 KB-os csomagot kezelni, de korántsem biztos, hogy megbirkózik másodpercenként 100 000 darab 50 bájtos csomaggal, hiába felel ez meg kisebb adatsebességnek. A maximális csomagméret a hálózat belső korlátjai miatt fontos, ezeket ugyanis nem lehet túllépni. Ha például az útvonal egy része egy Etherneten keresztül vezet, akkor a maximális csomagméret nem lehet több mint 1500 bájt, függetlenül attól, hogy a hálózat fennmaradó része mennyit képes kezelni.

Érdekes kérdés az, hogy az útválasztó hogyan alakíthatja át a folyammeghatározásokat konkrét erőforrás-foglalások halmazává. Első ránézésre úgy tűnhet, hogy ha egy útválasztó egyik adatkapcsolata például 1 Gb/s-os sebességű és egy átlagos csomag 1000 bites, akkor 1 millió csomagot dolgoz fel másodpercenként. Ez a megfigyelés azonban nem felel meg a valóságnak, mert a terhelés statisztikai ingadozása miatt mindig lesznek tétlen periódusok az adatkapcsolaton. Ha az adatkapcsolatoknak a kapacitás összes bitjére szüksége van a munka elvégzéséhez, akkor néhány bites kiesés miatt olyan hátrányba kerül, amit már soha nem fog tudni behozni.

Sőt még a kevéssel az elméleti kapacitás alatt maradó terhelés esetén is sorok alakulhatnak ki, és késleltetés léphet fel. Tekintsünk egy olyan helyzetet, ahol a csomagok véletlenszerű időközönként, átlagosan csomag/s sebességgel érkeznek be. A csomagok hossza véletlenszerű, és az adatkapcsolaton az átlagos kiszolgálási sebesség csomag/s. Ha feltesszük, hogy mind a beérkezés, mind a kiszolgálás Poisson-eloszlású (amelyet M/M/1 sorbanállási rendszernek hívunk, ahol „M” Markovot jelent, azaz Poisson), akkor a sorbanállási elmélet eszközeivel bizonyítható, hogy egy csomag által elszenvedett T késleltetés átlagos értéke

ahol a processzor kihasználtsága. Az első tényező, azt mutatja meg, hogy mennyi lenne a kiszolgálási idő versengés nélkül. A második tényező a többi folyammal való versengés okozta lassulást jelképezi. Ha például csomag/s és csomag/s, akkor és az egyes csomagok által elszenvedett átlagos késleltetés 20 s lesz 1 s helyett. Ebben benn van a sorbaállás és a kiszolgálás ideje is, amint az alacsony terhelés esetén látszik . Ha a folyam útvonalán mondjuk 30 útválasztó van, akkor egyedül a sorbaállásból fakadó késleltetés is már 600 s lesz.

Parekh és Gallagher [1993, 1994] egy módszert ad, amely a folyammeghatározások, illetve a sávszélességre és késleltetésre vonatkozó teljesítménygaranciáknak megfelelő útválasztó-erőforrások viszonyát mutatja ki. Ez az (R, B) vezérjeles vödör által formált forgalomforrásokra és az útválasztókbeli WFQ-ra épül. Minden folyam elég nagy W WFQ-súlyt kap az R vezérjeles vödör kapacitás elvezetéséhez, ahogy az az 5.33. ábrán látható. Ha például a folyam 1 Mb/s-os sebességű és az útválasztó és a kimeneti adatkapcsolat kapacitása 1 Gb/s, akkor a folyam súlyának a kimeneti vonalhoz tartozó útválasztón nagyobbnak kell lennie, mint az összes folyam összsúlyának 1/1000-e. Ez a folyam számára garantál egy minimális sávszélességet. Ha nem adható elég nagy sebesség, akkor a folyam nem engedhető meg.

5.33. ábra - Sávszélesség és késleltetési garanciák vezérjeles vödrökkel és WFQ-val

A folyam által tapasztalt legnagyobb sorbanállási késleltetés a vezérjeles vödör löketméretének függvénye. Tekintsünk meg két szélsőséges esetet. Ha a forgalom egyenletes, nincs semmilyen löket, akkor a csomagok az útválasztótól a megérkezésük sebességével mennek tovább. Nincs sorbanállási késleltetés (figyelmen kívül marad a csomagba rendezési hatás). Másrészről, ha a forgalom löketekben érkezik, akkor maximálisan B méretű löket érkezhet egyszerre az útválasztóra. Ebben az esetben a D maximális sorbanállási késleltetés lesz a löket elvezetésének ideje a garantált sávszélességen, vagy B/R (újra figyelmen kívül hagyva a csomagba rendezési hatást). Ha ez a késleltetés túl nagy, akkor a folyamnak további sávszélességet kell kérni a hálózattól.

Ezek a garanciák szigorúak. A vezérjeles vödrök összefogták a forrás löketszerű adását, az egyenlő esélyű sorba állítás pedig elkülöníti a különböző folyamok számára biztosított sávszélességet. Ez azt jelenti, hogy a folyam megfelel a sávszélességi és késleltetési garanciáknak attól függetlenül, hogy más versengő folyamok hogyan viselkednek az útválasztón. Ezek a folyamok még úgy sem képesek meghiúsítani a garanciát, hogy összegyűjtik és egyszerre küldik a forgalmat.

Továbbá, az eredmény érvényes egy olyan útvonalra, amely tetszőleges hálózati topológiában elhelyezkedő több útválasztón keresztül halad. Minden folyam minimális sávszélességet kap, mivel a sávszélesség minden útválasztón garantált. Annak oka, hogy az egyes folyamok késleltetése miért maximális, már bonyolultabb kérdés. A legrosszabb esetben, amikor a forgalom lökete eléri az első útválasztót, és más folyamok forgalmával versenyez, akkor ennek a késleltetése akár a legnagyobb D késleltetés is lehet. Ez a késleltetés azonban kisimítja a löketet. Viszont ez azt jelenti, hogy a löket nem okoz újabb sorbanállási késleltetést a további útválasztókon. A teljes sorbanállási késleltetés maximum D lesz.

1995 és 1997 között az IETF sok energiát fektetett a multimédia folyamszerű átvitelét lehetővé tevő (streaming multimédia) architektúra kidolgozásába. A munka eredménye több mint két tucat RFC lett, az RFC 2205-2212-vel kezdve. E művek az integrált szolgáltatások (integrated services, IS) nevet viselik. Az elgondolások egyaránt irányulnak az egyesküldéses és a többesküldéses alkalmazásokra. Az előbbire példa egy szóló felhasználó, aki egy videoklipet folyamszerűen tölt le egy híroldalról; az utóbbira pedig a digitális televízióállomások egy csoportja, amelyek egy IP-csomagokból álló folyammal közvetítik műsorukat a különböző helyeken tartózkodó nézőknek. Az alábbiakban a többesküldésre fogunk koncentrálni, mivel az egyesküldés is ennek egy speciális esete.

A csoportok tagjai számos többesküldéses alkalmazásban dinamikusan megváltoztathatják a tagságukat, például bekapcsolódhatnak egy videokonferenciába, majd ha megunták, átkapcsolhatnak egy szappanoperára vagy a sportcsatornára. Ilyen feltételek mellett nem működik jól az a megoldás, hogy a feladók előre lefoglalják a sávszélességet, mert ehhez a közönségük minden be- és kilépését nyomon kéne követniük. Egy olyan rendszerben pedig, amelyet arra terveztek, hogy több millió nézőnek szolgáltasson televíziós közvetítést, ez egyáltalán nem is működne.

5.4.5.1. RSVP – erőforrás-foglalási protokoll

Az integrált szolgáltatások architektúrájának fő protokollja, amely a hálózat felhasználói számára látható, az RSVP (Resource reSerVation Protocol – erőforrás-foglalási protokoll). Leírását az RFC 2205-2210 tartalmazza. Ezt a protokollt a foglalásokhoz használják; az adatok elküldését más protokollok végzik. Az RSVP lehetővé teszi, hogy több adó adjon vevők több csoportjának, továbbá hogy az egyes vevők szabadon választhassanak a csatornák között. A protokoll ezenkívül optimalizálja a sávszélesség-felhasználást, miközben kiküszöböli a torlódásokat is.

A legegyszerűbb formájában a protokoll a feszítőfát használó többesküldéses útválasztást használja, ahogy azt korábban leírtuk. Minden csoporthoz hozzárendelünk egy csoportcímet. Hogy egy csoportnak küldjön, az adó a csoport címét teszi annak csomagjaiba. A szokásos többesküldéses útválasztás ezután felépít egy feszítőfát, amely a csoport minden tagját lefedi. Az útválasztó algoritmus nem az RSVP része. A normál többesküldéstől való egyetlen eltérés az, hogy a csoportnak egy kevés kiegészítő információt kell periodikusan elküldeni, hogy a fa menti útválasztókat utasítsuk bizonyos, a memóriájukban levő adatstruktúrák karbantartására.

Példaként tekintsük az 5.34.(a). ábra hálózatát. Az 1. és 2. hoszt többesküldéses adó, a 3., 4. és 5. hoszt többesküldéses vevő. Ebben a példában az adók és a vevők szétválnak, általában azonban a két halmaz átlapolódhat. A többesküldéses fa az 1. hosztra az 5.34.(b) ábrán, a 2. hosztra az 5.34.(c) ábrán látható.

5.34. ábra - (a) Egy hálózat. (b) A többesküldéses feszítőfa az 1. hoszt számára. (c) A többesküldéses feszítőfa a 2. hoszt számára

Hogy jobb vételt érjen el és kiküszöbölje a torlódást, az egy csoportban levő vevők közül bármelyik küldhet egy foglalási üzenetet a fán felfelé az adóig. Az üzenetet a korábban tárgyalt visszairányú továbbítás algoritmus segítségével terjesztik. Az útválasztó minden lépésnél észreveszi a foglalást, és lefoglalja a szükséges sávszélességet. Ha nem áll rendelkezésre elegendő sávszélesség, sikertelenséget jelez vissza. Amikorra az üzenet visszajut a forrásig, már le lesz foglalva a sávszélesség a feszítőfa mentén, az adótól a foglalást kérő vevőig.

Ilyen foglalásra látható példa az 5.35.(a) ábrán. Itt a 3. hoszt egy csatornát igényelt az 1. hoszthoz. Ha ez már felépült, a csomagok torlódás nélkül folyhatnak az 1.-től a 3.-ba. Most vegyük szemügyre, mi történik, ha a 3. hoszt legközelebb a másik adóhoz, a 2. hoszthoz foglal csatornát, hogy a felhasználó egyszerre két tv-műsort tudjon nézni. Egy másik út is fenn lesz tartva, ahogy az 5.35.(b) ábra mutatja. Vegyük észre, hogy két külön csatornára van szükség a 3. hoszttól az E útválasztóig, mert két független adatfolyam kerül továbbításra.

Végül az 5.35.(c) ábrán az 5. hoszt elhatározza, hogy az 1. hoszt által adott programot akarja nézni, és szintén foglalást végez. Először, saját célra sávszélességet foglal le a H útválasztóig. Viszont ez az útválasztó látja, hogy már kapja a táplálást az 1. hoszttól, így ha a szükséges sávszélesség már le van foglalva, nem kell többet lefoglalnia. Vegyük észre, hogy a 3. és 5. hosztok különböző méretű sávszélességet kérhettek (például a 3. hosztnak kis képernyője van, és csak kis felbontású információt kíván), így a lefoglalt kapacitásnak olyan nagynak kell lennie, hogy kielégítse a legmohóbb vevőt is.

5.35. ábra - (a) A 3. hoszt egy csatornát igényel az 1. hoszthoz. (b) Ezután a 3. hoszt egy második csatornát igényel a 2. hoszthoz. (c) Az 5. hoszt egy csatornát igényel az 1. hoszthoz

Amikor egy vevő foglalást végez, (opcionálisan) megnevezhet egy vagy több forrást, amelyekből venni akar. Azt is megmondhatja, hogy ezek a választások rögzítettek a foglalás időtartama alatt, vagy pedig a vevő meg akarja tartani a forrásváltoztatás lehetőségét későbbre. Az útválasztók ezt az információt a sávszélesség-tervezés optimalizálásához használják fel, nevezetesen, két vevőt csak akkor állítanak be közös út használatára, ha mindkettő beleegyezett, hogy később nem változtat forrást.

Ennek a stratégiának az oka a teljesen dinamikus esetben az, hogy a lefoglalt sávszélesség el van különítve a forrás választásától. Ha egy vevő már lefoglalt sávszélességet, átkapcsolhat egy másik forrásra, és megtarthatja a létező út azon részét, amely érvényes az új forrásra is. Ha mondjuk a 2. hoszt több videofolyamot is továbbít valós időben, például egy több csatornával rendelkező tv-adó, a 3. hoszt tetszése szerint kapcsolgathat köztük a foglalás változtatása nélkül: az útválasztók nem törődnek vele, milyen programot néz a vevő.

A folyamalapú algoritmusoknak megvan az a képességük, hogy jó szolgáltatásminőséget tudnak biztosítani egy vagy több folyam számára, mivel bármilyen igényelt erőforrást le tudnak foglalni az út mentén. Megvannak azonban ennek a maguk hátrányai is. Minden egyes folyam kialakítása előkészületeket igényel, ez pedig nehezen kézben tartható, ha több ezer vagy millió folyamról van szó. Ráadásul az egyes folyamok állapotát az útválasztókban kezelik, ami sebezhetővé teszi azokat az útválasztók összeomlása esetén. Végül jelentős változtatásokat követelnek meg az útválasztók szoftverében is, a folyamok felépítése pedig bonyolult üzenetváltásokkal jár együtt az útválasztók között. Ebből fakadóan, mialatt az integrált szolgáltatásokkal kapcsolatos munkák előrehaladnak, nagyon kevés integrált szolgáltatásokkal kapcsolatos megvalósítás vagy bármi ehhez hasonló létezik.

Ezen okok miatt az IETF is egyszerűbb megoldást gondolt ki a szolgáltatásminőség megvalósítására, olyat, amely minden útválasztóban javarészt helyileg implementálható, az előkészületek és az egész útvonal bevonása nélkül. Ezt a megoldást osztályalapú (class-based) szolgáltatásminőségnek nevezik (szemben az eddig látott folyamalapúval). Az IETF egy architektúrát is szabványosított a számára, differenciált szolgáltatások (differentiated services, DS) néven, melyet az RFC 2474, RFC 2475 és számos más RFC ír le. A következőkben itt is bemutatásra kerül.

Differenciált szolgáltatásokat az egy adminisztratív körzetbe (például egy internetszolgáltató vagy telefontársaság) tartozó útválasztók egy halmaza kínálhat. Az adminisztráció definiálja a szolgáltatási osztályok egy halmazát a nekik megfelelő továbbítási szabályokkal együtt. Ha egy ügyfél előfizet egy differenciált szolgáltatásra, akkor a körzetbe belépő csomagjait megjelölik azzal az osztállyal, amelyikhez tartoznak. Ezt az információt az IPv4- és IPv6-csomagok Differenciált szolgáltatások (Differentiated services) mezője hordozza (erről az 5.6. szakaszban lesz szó). Az osztályokat ugrásonkénti viselkedésekként (per hop behavior) adják meg, mivel ezek megfelelnek annak a kezelésnek, ahogy a csomagot az egyes útválasztók venni fogják, ez nem hálózati garancia. Jobb szolgáltatások biztosíthatók az ugrásonkénti viselkedésű csomagok számára (például prémiumszolgáltatás), mint mások számára (például normál szolgáltatás). Egy adott osztályhoz tartozó forgalomtól megkövetelhető, hogy megfeleljen egy meghatározott mintának – ez lehet például egy adott sebességgel csöpögő lyukas vödör. Jó üzleti érzékkel megáldott szolgáltató külön díjat számolhat fel minden leszállított prémiumcsomag után, vagy engedélyezhet legfeljebb havi N darab prémiumcsomagot rögzített havi különdíj ellenében. Vegyük észre, hogy ez a séma – szemben az integrált szolgáltatásokkal – nem igényel előzetes beállítást, sem erőforrás-lefoglalást, sem időigényes végpontok közti tárgyalásokat külön-külön minden egyes folyamhoz. Ezért tehát a differenciált szolgáltatások viszonylag egyszerűen megvalósíthatók.

Osztályalapú szolgáltatásokkal más területeken is találkozhatunk. A csomagküldő szolgáltatások gyakran kínálnak éjszakai, kétnapos vagy háromnapos kézbesítést. A légitársaságok első osztályú, üzleti osztályú és turista osztályú szolgáltatásokat nyújtanak. Gyakran a távolsági vonatokon is többféle szolgáltatási osztály van, sőt még a párizsi metrónak is két osztálya van. A csomagok esetében az osztályok többek közt a késleltetés, a dzsitter és a torlódás esetén történő eldobás valószínűsége szerint különbözhetnek (ez a hosszabb Ethernet-keretekre valószínűleg nem érvényes).

Hogy jobban meg tudjuk különböztetni a folyamalapú és az osztályalapú szolgáltatásminőséget, vegyük szemügyre az internettelefon példáját! Folyamalapú sémát használva mindegyik hívás megkapja a maga erőforrásait és garanciáit. Osztályalapú sémával az összes hívás együtt kapja meg az adott osztály számára lefoglalt erőforrásokat. Ezeket az erőforrásokat nem vehetik el a webböngésző osztályhoz vagy más osztályokhoz tartozó csomagok, de egyetlen telefonhívásnak sem lesznek fenntartva saját használatra erőforrások.

5.4.6.1. Gyorsított továbbítás

A szolgáltatási osztályok megválasztása a hálózatüzemeltetők dolga, de mivel a csomagokat gyakran különböző szolgáltatókhoz tartozó hálózatok között továbbítják, az IETF néhány hálózatfüggetlen szolgáltatási osztályt határozott meg. A legegyszerűbb ilyen osztály a gyorsított továbbítás (expedited forwarding), kezdjük most ezzel. Az osztályt az RFC 3246 írja le.

A gyorsított továbbítás mögött megbúvó ötlet nagyon egyszerű. Kétfajta szolgáltatási osztály áll rendelkezésre: szabályos és gyorsított. A forgalom túlnyomó része várhatóan szabályos lesz, de a csomagok egy kis hányadát gyorsítjuk. Az ilyen gyorsított csomagoknak elvileg úgy kell keresztülhaladniuk a hálózaton, mintha más csomag nem is lenne ott jelen. Így a csomagok veszteség nélkül haladnak át, kis késleltetéssel, kis dzsitterrel – éppen úgy, ahogy a VoIP kívánja. Ezt a „kétcsöves” rendszert ábrázolja az 5.36. ábra. Vegyük észre, hogy továbbra is csak egy fizikai vonalunk van. Az ábrán látható két logikai csővezeték azt a módot ábrázolja, ahogy sávszélesség lefoglalható a különböző szolgáltatási osztályok számára, és nem egy másik fizikai vonalat.

5.36. ábra - A gyorsított csomagok forgalommentesnek látják a hálózatot

Egy lehetséges megvalósítási stratégia a következő. A csomagokat gyorsítottként vagy szabályosként osztályozzák, és ennek megfelelően megjelölik. Ez a lépés a küldő hoszton vagy a bemeneti (első) útválasztón hajtható végre. A küldő hoszton való osztályozás előnye az, hogy több információ áll rendelkezésre arról, hogy melyik csomag melyik folyamhoz tartozik. Ezt a feladatot a hálózatkezelési szoftver vagy az operációs rendszer hajthatja végre, hogy a meglévő alkalmazásokat ne kelljen módosítani. Például VoIP-csomagok esetén általános, hogy a hosztok jelölik meg a csomagokat gyorsított szolgáltatásra. Ha a csomagok vállalati hálózaton vagy a gyorsított szolgáltatást támogató internetszolgáltató hálózatán mennek keresztül, akkor előnyben részesülnek. Akkor sincs baj, ha a hálózat nem támogatja a gyorsított szolgáltatást.

Természetesen, ha a jelölést a hoszt végzi, akkor a bemeneti útválasztó feltehetőleg elvégzi a forgalom rendfenntartását annak biztosítása érdekében, hogy az ügyfelek ne küldjenek több gyorsított forgalmat, mint amiért fizettek. A hálózatban az útválasztók két kimeneti sort tarthatnak fenn minden kimenő vonalhoz: egyet a szabályos, egyet a gyorsított csomagokhoz. Amikor egy csomag megérkezik, bekerül a megfelelő sorba. A gyorsított sor prioritást élvez a szabályossal szemben, például prioritásütemező segítségével. Ily módon a gyorsított csomagok terhelés nélküli hálózatot látnak még abban az esetben is, ha valójában a szabályos forgalom nagy terhelést ró a hálózatra.

5.4.6.2. Biztosított továbbítás

A szolgáltatási osztály az előzőnél némileg kidolgozottabb kezelését nyújtja a biztosított továbbítás (assured forwarding) sémája, melyet az RFC 2597 ír le. A séma négy prioritási osztályt határoz meg; itt minden osztályhoz saját erőforrások tartoznak. Ezenkívül a torlódásba került csomagok eldobására is definiálnak három különböző valószínűséget (kis, közepes és nagy). Mindent összevetve, a két tényező együtt 12 szolgáltatási osztályt határoz meg.

Az 5.37. ábra a csomagok biztosított továbbításának egy lehetséges módját mutatja. Első lépésben minden csomagot a négy prioritási osztály közül az egyikbe sorolnak. Ezt megteheti a feladó hoszt (ahogy az ábra is mutatja) vagy az első (ún. beléptető) útválasztó, és a magasabb prioritású csomagok sebességét az operátor a szolgáltatási ajánlat részeként korlátozhatja.

5.37. ábra - Az adatáramlás egy lehetséges megvalósítása a biztosított továbbításnál

A következő lépés az egyes csomagok eldobási osztályának meghatározása. Ez úgy történik, hogy minden egyes prioritási osztály csomagjait egy forgalmi rendfenntartón küldik keresztül, mint amilyen például a vezérjeles vödör. A rendfenntartó az összes forgalmat átengedi, de a kis löketekbe beleillő csomagokat alacsony eldobási osztályúnak, a kis löketeket meghaladó csomagokat közepes eldobási osztályúnak, a nagy löketeket meghaladókat pedig magas eldobási osztályúként azonosítja. A prioritás és az eldobási osztály kombinációja ezután kódolásra kerül minden csomagban.

Végül a csomagokat a hálózaton lévő útválasztók feldolgozzák egy csomagütemezővel, amely megkülönbözteti a különböző osztályokat. Általános választás az, hogy a súlyozott egyenlő esélyű sorba állítást használják a négy prioritási osztályhoz úgy, hogy a magasabb osztályok nagyobb súlyt kapnak. Ily módon a magasabb osztályok megkapják a sávszélesség nagy részét, de az alacsonyabb osztályok sem lesznek teljesen kiéheztetve, számukra is jut némi sávszélesség. Ha például a súlyok osztályonként megduplázódnak úgy, hogy egy magasabb szintű osztály kétszer akkora súly kap, mint az alatta lévő osztály, akkor a magasabb osztály kétszer akkora sávszélességet kap. Egy prioritási osztályon belül a magasabb eldobási osztállyal minősített csomagok preferenciabeállítások alapján dobhatók el egy olyan algoritmus futtatásával, mint amilyen például az 5.3.5. szakaszban látható RED (Random Early Detection – véletlen korai detektálás). A RED elkezdi eldobni a csomagokat, ahogy a torlódás kialakul, de mielőtt az útválasztó kifogyna a pufferterületből. Ebben a fázisban van még pufferterület, amelyre az alacsony eldobási osztályú csomagokat elhelyezi, miközben a magas eldobási osztályú csomagokat eldobja.