Internet QoS: lehetőség vagy délibáb?

Telbisz Ferenc <telbisz@sunserv.kfki.hu>

KFKI RMKI SzHK és MATÁV PKI-FI

Bevezetés

Az internet szolgáltatás mai napig "best effort" szolgáltatásként működik, de egyre több szó esik a minőségi adatátviteli szolgáltatásról (QoS: Quality of Service). Igényként jelentkezik a felhasználók részéről, akik megbízható, jó minőségű hálózatot szeretnének az alkalmazásaikhoz ill. az újonnan megjelenő alkalmazások (video konferencia, VoIP, tudományos eredmények megjelenítése, orvosi diagnosztika, stb.) különleges minőségi követelményeket támasztanak az adatátvitellel szemben.

A szóba jövő legfontosabb minőségi mutatók a teljes vég-vég késleltetés, valamint ennek ingadozása (jitter) ill. ennek felső határa, továbbá az alkalmazás számára rendelkezésére álló sávszélesség és a csomagvesztés (adatvesztés).

Az IP QoS fogalma

A hagyományos adat- vagy beszédátviteli szolgáltatásnál az adatforgalom megindulása előtt egy (virtuális) áramköri kapcsolat jön létre a kommunikáló partnerek között, amelynek során az adatátvitelhez szükséges erőforrások lefoglalása megtörténik, olyan módon, hogy a "sávszélesség", késleltetés, frekvencia torzítás, stb. a megfelelő korlátok között legyen tartható. Digitális beszédátvitelnél pl. az egyes kapcsolatokhoz a két forgalmi iránynak megfelelően 2 x 64 Kbps kapacitású "adatátviteli csatorna foglalódik le és ez garantálja a megfelelő minőségű átvitelt Adatátvitelnél az egyes adatcsomagok mind egy-egy ilyen kapcsolathoz vannak rendelve, és a csomagok ezen kapcsolat azonosítóját hordozzák. Az adatátvitelnél megfelelő protokoll (pl. X.25) gondoskodik a hiba detektálásról, hibajavításról, sorrendtartásról, stb.

Az IP kapcsolat nélküli datagram szolgáltatás (connectionless datagram service). Ez azt jelenti, hogy minden egyes adatcsomag a teljes címet tartalmazza, és az egyes adatcsomagok egymástól függetlenül továbbítódnak, esetleg különböző útvonalakon is. A hálózatnak nincs semmilyen információja arról, hogy mely adatcsomagok tartoznak ugyanazokhoz a kommunikáló entitásokhoz. Ezen felül az IP protokoll csak az adatátviteli hibát detektálja, és a hibás adatcsomagokat egyszerűen eldobja, a magasabb protokoll szintekre hárítva a sorrendcsere, adatvesztés, adatkettőzés felderítését és javítását. Ezért az IP definíciója szerint csak "best effort" lehet. Felvethető azonban, hogy ez a "best effort" mennyire jó ("good"), és ennek a befolyásolására az IP keretein belül is igyekeznek - nem is sikertelenül - eszközöket kialakítani.

A mai átviteli hálózatok minősége olyan, hogy az adatátviteli hiba gyakorlatilag elhanyagolható. A minőséget befolyásoló tényezők az IP hálózatban szükségképpen fellépő torlódások és az ezek elhárítására alkalmazott adateldobási stratégia következtében fellépő adatvesztés, késleltetés és annak fluktuációja. Az IP QoS a mondottak értelmében mindig globális (nem lehet beszélni egy adott kapcsolat minőségéről) és statisztikus, azaz csak átlagosan teljesülnek a minőségi mutatók. Ezen felül, mint az a továbbiakban részletesen látható lesz, kiemelt minőséget csak a kommunikáció bizonyos részének a különleges, általában prioritásos kezelésével lehet nyújtani.

Az IETF QoS-re irányuló tevékenysége

Az IETF is felismerte, hogy az újabb alkalmazásokhoz nem megfelelőek az Internetnél eddig megszokott minőségi mutatók. Ezért két lehetséges megoldással is foglalkoztak.

• Adatfolyam alapú: az erőforrások lefoglalása adatfolyamok szerint történik, ezért az adatfolyamok számára ad minőségi garanciát, viszont az adatfolyamok állapotát nyilván kell tartani a hálózatban. Igy működik pl. az ATM is.

• Nem adatfolyam alapú: az egyes adatcsomagokat megjelölik, és a csomagok feldolgozása, továbbítása a jelölési osztályok szerint történik.

Az adatfolyam alapú QoS: az Intserv

A korábbi megoldás az intserv-nek (Integrated Services) nevezett megoldás volt [1], ahol megpróbálták megoldani az erőforrások lefoglalását az egyes kapcsolatokhoz. Ennél a megoldásnál az alkalmazás jelzi az elvárásait a hálózatnak és a hálózat válaszol erre. Az alkalmazás csak akkor indítja az adatátvitelt, ha a hálózat jelezte, hogy ki tudja elégíteni a kért sávszélességet a kért minőségi szinten és elfogadja az erőforrás lefoglalást. A lefoglalás mindaddig érvényes, amíg az alkalmazás explicite nem jelzi a lefoglalás végét, vagy a hálózat nem jelzi, hogy a továbbiakban képtelen a lefoglalás teljesítésére. Ennek a megoldásnak a lényege a "minden vagy semmi" működés. A hálózat vagy képes az erőforrásokat biztosítani és akkor az alkalmazásnak nem kell figyelnie a szolgáltatás minőségére, vagy a hálózat jelzi, ha nem képes a teljesítésre.

Az Intserv célja az volt, hogy a real-time alkalmazásokat támogassák az Internetben, garantált szolgáltatást nyújtva. Ez garantált vég-vég késleltetést és sávszélességet jelent, annak fejében, hogy az alkalmazás által adott terhelés ellenőrzött és előre megadottan korlátozott. A felhasználó az adatfolyamban torlódásmentes hálózati viselkedést érez. Jól illeszthető ill. illeszkedik a QoS-t nyújtani képes adatátviteli (2. réteg) technológiákhoz mint az ATM vagy a Frame-Relay.

Az igények jelzésére kidolgozták az RSVP-t (Resource Reservation Protocol) [2]. Az RSVP IP szintű külön protokoll, amely IP datagrammot ill. UDP-t használ. Szimplex protokoll, mindkét irányban külön kell az erőforrás foglalást elvégezni. Az erőforrás lefoglalást ugyan általában a küldő kezdeményezi, de a fogadótól visszafelé haladva történik a tényleges lefoglalás. A működése olyan, hogy a lefoglalást időnként meg kell erősíteni, ill. újítani. Ha a beállított időzítésen belül ilyen nem érkezik, a lefoglalás törlődik. Így ki lehet védeni az erőforrások felszaba­dításának elmulasztását.

Mivel ennél a módszernél a hálózatnak alkalmazásonként kell az állapotot nyilvántartani, ez jelentős terhet jelent a hálózatnak. Így meglehetősen rosszul skálázható, ezért a gerinc szolgáltatóknál gyakorlatilag nem alkalmazható. Valójában az intserv nem is igen illik bele az IP koncepciójába, hiszen a kapcsolat nélküli hálózati rétegtől idegen a kapcsolatonkénti állapotok nyilvántartása.

Nem adatfolyam alapú QoS: a Diffserv

A továbbiakban felmerült másik megoldás a diffserv-nek (Differentiated Services) nevezett megoldás [3]. Ez szakít avval a gondolattal, hogy kapcsolatonként, kommunikáló alkalmazás páronként tartsuk nyilván a hálózat állapotát. A diffserv e helyett a csomag header-ben "jelzést" helyez el, és a csomagok kezelése ezen jelzés szerint történik. Mivel a differenciált szolgáltatásnak az Internet méretében (több millió hálózat) kell működnie és igen nagy sebességeknél is, az összes állapot nyilvántartását a hálózat "peremére" kell helyezni ugyanúgy, mint minden kapcsolatonkénti tevékenységet (pl. nyilvántartás, forgalom szabályozás) is. Mivel az állapotok nyilvántartása a hálózat peremén történik, a különleges vagy normális továbbítás jelzését is itt kell elhelyezni a csomagokban. Az adminisztratív szabá­lyozások sokfélesége és a nagy hálózati sebességek miatt a jelzésnek igen egyszerűnek kell lennie. Mivel a gerincben nem lehetséges állapotok nyilvántartása, a csomagtovábbítás csak csoportok szerint szabályozható.

A diffserv alapgondolata az, hogy a hálózat csupán kisszámú, speciális kiszolgálási osztályt kezel, és a hasonló kiszolgálási igényű alkalmazásokat azonos kiszolgálási osztályba sorolja, amelyekhez erőforrásokat is allokál ill. erőforrások allokálhatók. Az osztályokba sorolás a hálózatba belépéskor történik (FEC: forwarding equivalence class) és azok a továbbiakban különböző továbbítási sorokba kerülnek. Az osztályokat a továbbítás kezelése szerint u.n. PHB csoportokba ("Per-hop Behaviour Aggregate") sorolják, egy PHB csoportba több FEC is kerülhet. A diffserv valójában nem szolgáltatásokat, hanem "viselkedési módokat" definiál.

Az osztályok számára mind az Ipv4-ben, mind az Ipv6-ban 6 bitet jelöltek ki [4]. Ez kiterjesztése az Ipv4 header-ben levő TOS byte-nak, ahol erre a célra három precedencia bit (7 prioritás) állt rendelkezésre Bár így 64 különböző PHB lehetséges, eddig lényegében kétfélét definiáltak: az "express továbbítást" (EF: Expedited Forwarding) [5] és a "garantált továbbítás" (AF: Assured Forwarding) [6] négy osztályát. Mindegyik osztályhoz garantált sávszélesség rendelendő hozzá.

Expedited forwarding (EF)

Az "express továbbítás" (expedited forwarding) esetében előírás, hogy a garantált minimális sávszélességet megkapják az ebbe az osztályba sorolt adatcsomagok, függetlenül attól, hogy milyen egyéb forgalom van a hálózatban. Mivel a csomagvesztés, a késleltetés és annak ingadozása a hálózatban fellépő torlódások következménye, ezért ha az osztályba sorolt csomagok nem éreznek sorbaállást az áthaladás során, a forgalom bérelt vonali szolgáltatáshoz hasonló szolgáltatást nyújt. Ez csak akkor működik így, ha bármely közbenső csomóponton az ezen osztályhoz tartozó beérkező forgalom kisebb, mint az ugyanezen csomópontban ugyanezen osztályhoz rendelt kimenő sávszélesség. A végpontok számára ez a szolgáltatás pont-pont kapcsolatnak, azaz "virtuális bérelt vonalnak" látszik.

Assured forwarding (AF)

A "garantált továbbítási" osztályokban minden osztályon belül 3 prioritási szint van, ami eldobási prioritást jelent. Ha az osztály számára garantált sávszélességet túllépi a forgalom, akkor először a legmagasabb eldobási prioritású csomagokat dobja el a hálózat, majd ha a terhelés nő és a sorok növekednek, akkor a következő prioritási szint csomagjai kerülnek sorra. Ezeknél az osztályoknál a garancia arra vonatkozik, hogy lehetnek olyan csomagok, amelyek viszonylag jó átjutást érzékelnek, mert "garantáltan" az alacsonyabb prioritású csomagok kerülnek eldobásra. Viszont az AF osztályoknál mód van arra, hogy a lefoglalt sávszélességnél nagyobb forgalmat lehessen egy osztályban a hálózatba bocsátani, mert a magasabb prioritású csomagok átjutása még jó valószínűséggel garantálható és ha nincs torlódás a hálózatban, a magas eldobási prioritású csomagoknak is van esélye az átjutásra. A különböző osztályok között a csomagok átcsoportosítása tilos!

A QoS implementálása.

Az eddig elmondottak lényegében "elméleti" konstrukciót jelentenek, a gyakorlat attól függ, hogy ebből mit és hogyan valósítanak meg az implementációk. Az alábbiakban csak nagy vonalakban ismertetjük a különböző stratégiákat, részletesebb ismertetés található az egyes cégek (pl. CISCO) eszköz­leírásaiban

Egyszerű prioritásos sorkezelés

A csomagokat a legegyszerűbb esetben az IP csomag header-ben levő TOS (Type of Service) byte-ban levő IP precedencia bit-ek szerint lehet osztályozni. A csomagok kezelése lehet abszolút prioritás szerint rendezett sorokkal, és ilyenkor az alacsonyabb prioritású sorok kiszolgálása csak akkor történik meg, ha a magasabb prioritású sorok üresek: PQ (Priority Queueing). Általában ilyenkor csak négy sort használnak: magas, közepes, normál és alacsony prioritás (CoS: Class of Service). A PQ használható az EF PHB diffserv szolgáltatás megvalósítására.

Weighted Fair Queueing

A prioritás kezelhető ennél árnyaltabban is. A WFQ (Weighted Fair Queueing) esetében a csomagokat lényegében adatfolyamok szerint osztályozzuk, ahol az osztályozási alap lehet a TOS precedencia, küldő vagy fogadó IP cím ill. portszám és/vagy a protokoll típus. A WFQ a továbbításkor a nagyobb prioritású sorokból több csomagot továbbít, ill. nagyobb prioritással továbbítja ezeket, olyan módon, hogy az adott prioritású adatfolyam lényegében a csatorna idejének a prioritással arányos hányadát kapja meg. Ilyen módon a rendelkezésre álló sávszélesség "arányosan" osztódik fel az egyes sorok között. Azonos prioritásra több különböző adatfolyam is tehető, ekkor az adott prioritás többszörösen részesül a csatorna kapacitásból. Ha a sávszélességet egy magasabb prioritási osztály nem használja fel, az az alacsonyabb prioritású sorok számára rendelkezésre áll.

A torlódások elhárítása

A csomagvesztés, késleltetés és a késleltetés ingadozása a hálózatban fellépő torlódások következménye, azok függvénye. A forgalom szabályozására, a torlódások elkerülésére különböző eszközök állnak rendelkezésre. Mivel a torlódások esetén a sorok külön beavatkozás nélkül egyre növekednének, ennek elhárítására különböző módszereket lehet/kell használni, amelyek implementálva is vannak. Ilyen módszer a WRED (Weighted Random Early Discard). A csomagok eldobását az alacsonyabb prioritású soroknál kezdi a hálózat, ilyen módon jobb szolgáltatást nyújtva a kiemelt forgalomnak. (Ez az módszer az AF megvalósítását teszi lehetővé.)

Az erőforrások használatának a szabályozása

A hálózat erőforrásai korlátosak, ezért a QoS nyújtásához a hálózatba bejutó forgalmat szabályozni, korlátozni kell. Ehhez a hálózat szélein a következő funkcionális elemekre van szükség:

• Csomag osztályozó (packet classifier), ami a csomagokat osztályokba rendezi a szolgáltató és a felhasználó közötti megállapodások szerint

• Csomag megjelölő (marker), ami a csomag header-ben a megfelelő állapotjelzőket (DSCP) beállítja

• Forgalom szabályozó (traffic shaper), ami arról gondoskodik, hogy a terhelés ne lépje túl a megengedettet, a többletforgalmat kissé visszatartva kiegyenlíti, ill. eldobja (traffic dropper).

QoS (premium) forgalom és "best effort" forgalom viszonya

Mivel az IP forgalomban lökésszerű terhelések jelentkeznek, a különleges kezelést, a jobb továbbítási feltételekkel kezelendő forgalmi minőséget csak akkor lehet garantálni, ha a szükséges sávszélességet túlfoglaljuk, hogy a forgalmi csúcsok is beleférjenek. Ez csak akkor nem jelent számottevő kihasználatlan, kihasználhatatlan kapacitást, ha jelentős mennyiségű "best effort" forgalom is van, amit vissze lehet fogni a kialakult forgalmi csúcsok lekezelésének idejére, de a csúcsokon kívüli időben fel tudja használni a "premium" forgalom kihasználatlan kapacitását.

Diffserv mérések (Quantum/TERENA)

A diffserv QoS vizsgálatára a Dante ill. TERENA nagyszabású kísérletsorozatot indított, az első eredmények már rendelkezésre állnak. [7] Ezek során első lépésként egy rövid blokkokból álló, a VoIP-t utánzó, nagyprioritású EF forgalmat vizsgáltak szokványos IP, általában hosszú blokkokból álló háttér "best effort" forgalom mellett.

Ezekből látható, hogy laboratóriumi körülmények között nyújtott EF szolgáltatást nem zavarja a "best effort" szolgáltatás. Ugyanilyen kísérletet egy kisebb méretű WAN hálózaton elvégezve az eredmény kevésbé megnyugtató. Egy négy csomópontból álló gerinc hálózaton azt az eredményt kapták, hogy az EF szolgáltatás késleltetése ugyan jól kézben tartható, de már a késleltetés ingadozása (jitter) nem, ha a "best effort" háttér forgalom szokásos hosszú adatblokkokat tartalmazó IP forgalom volt. De jitter problémák merültek fel akkor is, ha a gerinc hálózat bármely csomópontján több, burst-ös jellegű EF forgalmat emittálnak a gerinchálózatba. Az eredmények bővebb ismertetése az idézett irodalomban megtalálható.

A kísérletek arra látszanak utalni, hogy bár a rendelkezésre álló eszközökkel lehetséges differenciált QoS szolgáltatást nyújtani, még alighanem hosszú kísérletezés áll előttünk, és elsősorban a hálózattervezésében, méretezésben is nagyon sok probléma vár megoldásra.

MPLS használata QoS szolgáltatáshoz

Az MPLS (Multiprotocol Label Switching) technológia elsősorban a gerinc hálózatok teljesítőképességét növeli, amennyiben a mag (core) router-ek a processzor igényes IP routing helyett kapcsolás (switching) alkalmazásával végzik az adattovábbítást. Mivel a kapcsolástechnika az MPLS hálózatokban lényegében úgy működik, mint egy virtuális áramkör, (v.ö. ATM) ezeknél a szolgáltatás minősége is jobban kézben tartható. Az MPLS ezért jól alkalmazható diffserv szolgáltatás nyújtására. [8]

További teendők, problémák

A QoS szolgáltatások széleskörű bevezetéséhez még számos, elsősorban nem technikai, hanem szervezési (policy) kérdést kell tisztázni. Ezekkel egy nem régen megjelent RFC is foglalkozik [9]. Az alábbiakban ezek közül szerepel néhány.

Nagyszámú különböző (64 féle DSP lehetséges) QoS szolgáltatás, amit egy ISP fel tud ajánlani, nem igazán hasznos. Célszerű lenne kisszámú alapszolgáltatás profilt általánosan bevezetni, mint "jól ismert" szolgáltatást és az összes többit a "magánhasználat" körébe utalni.

A QoS nyújtásaához hálózati töblet erőforrásokat kell használni, ami többlet költséget is jelent, amit az azt igénybe vevőkre át kell hárítani, különben mindenki a prémium szolgáltatást venné igénybe. Mindezideig azonban nem volt az Internetben ilyen számlázási modell, a számlázás a hozzáférési sávszélesség szerint történt, egyenlőre az ehhez szükséges adatok gyűjtése sem tisztázott.

Mivel az internet nagyon sok szolgáltatónak az inhomogén összessége, ugyanakkor egyetemes átjárhatósággal, rendkívül valószínütlen, hogy ezek egy egységes szolgáltatási környezetben olvadjanak össze. A különböző minőségű szolgáltatási osztályokból felépülő hálózati utak rendszere újabb skálázhatósági problémákat vet fel.

Összefoglalás

Mivel az IP kapcsolat nélküli datagram protokoll, ezért az IP QoS mindig globális (nem lehet beszélni egy adott kapcsolat minőségéről) és statisztikus, azaz csak átlagosan teljesülnek a minőségi mutatók.

Az integrált szolgáltatások aligha jutnak jelentős szerephez a rossz skálázhatóság miatt, annak ellenére, hogy felmerült az integrált szolgáltatás nyújtásának ötlete diffserv gerincen [10]. A differenciált szolgáltatás szerepe viszont nem a vég-vég QoS nyújtása lehet, hanem elsősorban az IP gerincek jó menedzselhetőségére alkalmas.

Valójában a problémát egy időre alighanem a DWDM formájában rendelkezésre álló bőséges sávszélesség fogja megoldani, ami egyenlőre valószínűleg legalább egy nagyság­renddel meghaladja a közeljövőben várható igényeket. [11]

Ha a címben feltett kérdést meg akarjuk válaszolni, azt kell mondanunk, hogy ha a QoS-en vég-vég viszonylatban garantált szolgáltatást értünk, akkor alighanem délibábot kergetünk, de a diffserv mint forgalom szabályozó (traffic engineering) eszköz, megfelelő sávszélességek esetén igen jól használható.

Irodalom

[1] R. Brade, D. Clark, S. Shenker: Integrated Services in the Internet Architecture: an Overview, RFC 1633, June 1994

[2] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin: Resource ReSerVation Protocol (RSVP), RFC 2205, September 1997

[3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss: An Architecture for Differentiated Services, RFC 2475, December 1998

[4] K. Nichols, S. Blake, F. Baker, D. Black: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998

[5] V. Jacobson, K. Nichols, K. Poduri: An Expedited Forwarding PHB, RFC 2598, June 1999.

[6] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski: Assured Forwarding PHB Group, RFC 2597, June 1999.

[7] T. Ferrari, S. Leinen, J. Novak, S. Nybre, H. Prigent, V. Reijs, R. Sabatino, R. Stoy: Deliverable D6.2, Report on Results of the Quantum test programme, QUA-00-015, 23. June 2000. http://www.dante.net/quantum/qtp/final.report.pdf,

[8] Francois Le Faucheur, Liwen Wu, Bruce Davie, Shahram Davari, Pasi Vaananen, Ram Krishnan, Pierrick Cheval, Juha Heinanen: MPLS Support of Differentiated Services, draft-ietf-mpls-diff-ext-07.txt (work in progress)

[9] G. Huston: Next Steps for the IP QoS Architecture. RFC 2990. November 2000.

[10] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M., Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine.: A Framework for Integrated Services Operation over Diffserv Networks, RFC 2998, November, 2000.

[11] F. Baker: "The Global Internet: Developments and Challenges", Lecture on "1st International workshop on Quality of future Internet Services" Berlin, 25-27. September 2000. http://www.fokus.gmd.de/events/qofis2000/html/programme.html