|  | ||||||||
|  | ||||||||
| | ||||||||
| | ||||||||
 |
kategória |  |
||||||||
|
|
||||||||||
 |
 |
|
|
|
|
|
||
|
|
|
|||||||||||||
Hangcsomag átvitele esetén az ideális végpont-végpont közötti késleltetés 150 és 200 milliszekundum között van. Láthattuk, hogy a CODEC-ek és csomagképzés két útvonalválasztás közötti átvitelbe 50 és 60 milliszekundum közötti késleltetést iktat be. A következökben bemutatjuk, hogyan kell úgy egy hálózatot beállítani, hogy megfelelö késleltetés és késleltetés-ingadozás értékekkel rendelkezzen, csak 100-140 milliszekundumot igényeljen a végpontok közötti csomagátvitel.
A Quality of Service (QoS), Class of Service (CoS), és a Type of Service (ToS) olyan széleskörüen használt kifejezések, amelyeket gyakran helytelenül és túlzóan használnak. Az alapvetö cél a szükséges sávszélesség biztosítása és megfelelö értékü késleltetés elérése valamely speciális alkalmazás számára. Az ilyen paraméterekkel rendelkezö szolgáltatásnál az eredmény sokkal fontosabb, mint a felhasznált eszközök, technológiák. Más szavakkal a QoS problémák megoldásánál nem csak egy QoS eszközökre kell fókuszálni, hanem a hálózatot, mint egészet kell kezelni, és azt kell vizsgálni, hogy az egyes QoS eszközökkel milyen részfeladatokat lehet megoldani. Az sem szabad elfelejteni, hogy minél finomabb a sorba állítás és a vezérlés annál alacsonyabb a csomagok továbbítási sebessége.
Egy jól megtervezett hálózatban elkülönülnek a perem és a gerinc funkciók. A legjobb QoS elérése érdekében is fontos ez. A Cisco cég számos eszközt biztosít a QoS megvalósításához. Néhány esetben a hálózat QoS-e QoS eszközök használata nélkül is megvalósítható. Minden egyes hálózatnak más-más problémái vannak és ezeket egy vagy több, a következökben ismertetendö QoS eszközzel lehet megoldani.
Az RTP egy szabványos Internet protokoll valós-idejü adat átvitelére, beleértve a hang és a videó jelek csomagban történö átvitelét is. Az RTP szabványban definiált tömörítési eljárás alapvetöen a TCP/IP fejléc tömörítés során használt eljáráson alapul (RFC 1144). Az RTP-t interaktív szolgáltatásoknál (pl. Internet telefon) és médián elérés (Real-Time Audio) használják. Az RTP-nek adat és vezérlési része van, az utóbbit RTCP-nek nevezik.
Az RTP adat része egy egyszerü protokoll, amely a valós idejü alkalmazások számára (pl. folyamatos hang és/vagy videó átvitel) biztosít támo 919j95j gatást beleértve az idözítés helyreállítását, a csomagvesztés érzékelést és tartalomazonosítást.
Az RTCP Internet alapú, tetszöleges résztvevöszámú, valós-idejü csoportkonferenciát tesz lehetövé. Biztosítja a forrásazonosítást, támogatja az átjárók használatát (pl. hang és videó hidak, multicast-unicast transzláció). Az RTCP QoS információ visszacsatolást biztosít a vevöktöl a multicast csoport felé és támogatja a különbözö média folyamok szinkronizálását is.
A Compressed Real-Time Transport Protocol, röviden csak CRTP a kapcsolati szinten használatos az IP/UDP/RTP fejlécek 40 bájtról átlag 2-4 bájtra tömörítésére. Csomag alapú hangátvitel a 20 milliszekundumonkénti beszéd mintavétel és keretezés 20 bájtos csomagokat állít elö. A teljes IP csomagméret egyrészt ebböl a 20 bájtból, az RTP fejlécböl (12 byte), az UDP fejlécböl (8 byte) és az IP fejlécböl (20 byte) áll össze. Látható, hogy a fejlécek méreteinek az összege kétszerese a hasznos tartalom méretének. 20 milliszekundum-ként elöállított csomagoknál egy lassú adatátviteli vonal sávszélességének nagy részét elfoglalják a fejlécek.
A rendelkezésre álló sávszélesség szükségtelen elfoglalása ellen a CRTP-t használják az adatkapcsolati szinten (2. szint). Ez a tömörítés 2 bájtra szorítja le az IP/UDP/RTP fejlécek méretét abban az esetben, ha nincs UDP checksum elküldés és 4 bájtra, ha az UDP checksum használatos.
A TCP fejléctömörítésnél a 2: 1 arányú összenyomás abból a tényböl következik, hogy az IP és a TCP fejlécekben lévö byte-ok fele állandó a TCP kapcsolat során.
Az RTP fejléctömörítésnél az elözöhöz hasonlatos technika alkalmazható. Azonban a nagy lehetöséget az rejti, hogy ugyan jó néhány mezö változik minden egyes csomagnál, de a változás (az elsö rendü különbség, az 1. derivált) csomag és csomag között gyakran állandó és a változás változása (másodrendü különbség, a 2. derivált) pedig nulla. Amennyiben mind a tömörítö és a kibontó ismeri a tömörítetlen fejlécet és annak elsö rendü különbségét a kapcsolat során, akkor csak azt az információt kell átvinni, hogy a másodrendü különbség nulla-e. Amennyiben nulla, akkor a kibontó képes visszaállítani az eredeti fejlécet információvesztés nélkül, az elsö rendü különbségnek az elmentett, tömörítetlen fejléchez történö hozzáadásával minden egyes csomagnál beérkezésénél.
Hasonlóan a TCP fejléctömörítéshez, ahol több párhuzamos TCP kapcsolat állapotát figyelik, az IP/UDP/RTP tömörítésnél is több kapcsolat helyzet állapotát vizsgálják. A kapcsolat helyzetet az IP forrás- és célcím, az UDP forrás és cél kapuszám és az RTP szinkronizációs forrás mezö (SSRC) definiálja. A tömörítö megvalósításánál ezekkel a mezökkel kódolást végezhetnek a tárolt kapcsolati helyzetek táblájának sorszámozására, megcímzésére. A tömörített csomag egy kis egész leíróval van megjelölve amelyet kapcsolati helyzet azonosítónak (CID) neveznek; ez jelzi, hogy a csomag mely kapcsolat helyzethez tartozik az adott csomag. A kibontó a CID felhasználásával címzi meg a helyzeti kapcsolatok tábláját.
A CRTP legtöbbször 40 bájtról 2-4 bájtra szorítja le a fejléc méretét. Néha azonban az IP/UDP/RTP fejlécet nem lehet tömöríteni, mert változás történt egy olyan mezöben, amelynek az értéke állandó szokott lenni. Például ha a tartalom típus mezö megváltozik, akkor a tömörítetlen fejlécet kell elküldeni.
A CRTP-t csak WAN interfészeken kell alkalmazni, ahol a sávszélesség kritikus lehet és a forgalom nagy része RTP-t használ.
A használt kapuszámok Cisco eszközöknél 16384 + 4 * a rendelkezésre álló csatornák száma az adott eszközön.
(Például egy Cisco útvonalválasztás 12 hangcsatornával a 16384-16432 kapuszámokat használja.)
A CRTP-t nem kell nagy sebességü interfészeken használni, mert csak hátrányokat jelenthet. A nagy sebesség definíciója persze meglehetösen relatív, a gyakorlatban E1 sebesség felett nincs szükség a CRTP használatára, habár néhány hálózatban már 512 kbps nagy sebességnek számít.
Az RSVP az elsö jelentösebb szabványként elfogadott protokoll, amellyel dinamikusan lehet végponttól végpontig terjedö QoS-t megvalósítani heterogén hálózat esetén. Az RSVP mind az IPv4-gyel (a jelenlegi IP szabvány) mind az IPv6-tal együttmüködik. Az RSVP transzparens müködést biztosít azon hálózati csomópontokon (útvonalválasztókon) keresztül is, amelyek nem támogatják magát az RSVP-t. Leegyszerüsítve az RSVP a hálózati végpont azon képessége, amely lehetövé teszi számára, hogy bizonyos szintü QoS-t kérjen a hálózattól. Az RSVP megfelelö útvonalon csomópontról csomópontra végigviszi a hálózaton a kérést, minden egyes csomópontnál megkísérli a szükséges eröforrásokat lefoglalni az adatátviteli folyam számára.
Az RSVP-t úgy tervezték meg, hogy kihasználja a jelenlegi IP útvonalválasztó algoritmusok erösségeit. Ez a protokoll nem végez saját útvonalválasztást; ehelyett az útvonalválasztó protokollokra hagyatkozva határozza meg, hogy hol eröforrás lefoglalást végrehajtania. Ahogy az átviteli útvonalak változása követi a topológia változásokat, úgy az RSVP is módosítja a lefoglalásokat. Ez a felépítés nem zárja ki azt, hogy RSVP más útvonalválasztó szolgáltatást is igénybe vegyen. A jelenlegi fejlesztések az RSVP-nél arra irányulnak, hogy az RSVP képes legyen olyan útvonalválasztó szolgáltatások használatára, amelyek alternatív és fix útvonalakat nyújtanak.
Az RSVP együttmüködik a jelenlegi sorba állítási mechanizmusokkal, és nem helyettük dolgozik. Ugyan az RSVP kéri az adott QoS-t, de az interfész sorba állítási mechanizmusnak (Weighted Fair Queuing [WFQ], Weighted Random Early Detection [WRED]) kell azt megvalósítania.
Az eröforrás lefoglalás úgy történik a hálózati csomóponton (útvonalválasztón), hogy az RSVP daemon két helyi döntést végzö modullal kommunikál, a kibocsátás vezérléssel és a szabályrendszer vezérléssel. A kibocsátás vezérlés meghatározza, hogy a csomópontnak van-e rendelkezésre álló eröforrása a kért QoS kielégítésére; a szabályrendszer vezérlés pedig abban dönt, hogy a felhasználónak van-e adminisztratív jogosultsága a lefoglaláshoz. Ha bármelyik ellenörzés elutasító választ ad, akkor az RSVP hibajelzést küld vissza a kérést kibocsátó alkalmazásnak. Ha mindkét ellenörzés sikeres eredménnyel tér vissza, akkor az RSVP daemon beállítja a paramétereket a csomagosztályozónál és csomagidözítönél a kért QoS eléréséhez. A csomag osztályozó minden egyes csomagnál meghatározza a QoS osztályt, és az idözítö rendezi a csomagok kibocsátását
a visszaigazolt QoS kéréseknek megfelelöen.
Két típusú dinamikus lefoglalást lehet végezni az RSVP-vel: ellenörzött terhelést és garantált szolgáltatást. Az RSVP RFC-je az ellenörzött terhelést a következö módon definiálja:
A hálózati elemek által egy alkalmazásnak nyújtott végponttól-végpontig terjedö viselkedés, amely ellenörzött terhelés szolgáltatást nyújt, szorosan közelíti azt a viselkedést, amelyet az alkalmazás számára látható és legjobb eröfeszítés szolgáltatást nyújt terheletlen feltételek vagy kevéssé terhelt/torlódott feltételeknél. Ez nem jelenti az összes többi, ugyanazoktól a hálózati elemektöl származó forgalom hiányát. Ha a hálózat megfelelöen müködik, akkor ezek az alkalmazások feltételezhetik azt, hogy:
a küldött csomagok nagyon magas százalékát sikeresen juttatja el a hálózat a célpontokhoz (a sikertelen csomagok aránya szorosan közelíti az átviteli média hibaarányát)
az átvitt csomagok igen magas százalékánál az észlelt átviteli késleltetés nem nagyon éri el a más csomagoknál észlelt minimális átviteli késleltetést (ez a minimális átviteli késleltetés magában foglalja a fényterjedési sebesség és az útvonalválasztó, illetve más kommunikációs eszközök által okozott késleltetést az átvitel út során).
Annak érdekében, hogy ezeknek a feltételeknek a meglétéröl megbizonyosodjanak, az ellenörzött terhelés szolgáltatást igényelö kliensek a közbülsö hálózati elemeknek információt adnak arról, hogy mennyi tervezett forgalmat fognak generálni - ez TSpec. Válaszként a szolgáltatás megbizonyosodik arról, hogy a hálózati elemek elegendö eröforrással rendelkeznek a kliensek által megfogalmazott szolgáltatás megvalósításához. Ha a kliensek által generált forgalom tulajdonságai mégis kívül esnének a Tspec paraméterek által meghatározott területen, akkor a kliens részére nyújtott QoS egy túlterhelt átvitel képét mutathatja nagyszámú késve érkezett vagy elveszett csomagokkal. A szolgáltatás definiálása nem igényli azt, hogy a túlterhelt viselkedés precíz karakterisztikája megegyezzen azzal, amit egy legjobb eröfeszítéssel átvitt adatfolyamnál kapnánk ugyanazon az útvonalon, túlterhelt feltételekkel.
A garantált szolgáltatás definíciója a következö:
A hálózati elemek által egy alkalmazásnak nyújtott végponttól-végpontig terjedö viselkedés, amely összhangban van ezzel a dokumentummal egy biztosított sávszélesség, amelyet ha egy szabályozott átvitel használ, akkor kötött késleltetésü szolgáltatást nyújt sorba állítási veszteség nélkül a megfelelö adatcsomagok részére (hálózati részek hibamentességét és az átvitel ideje alatt útvonal váltás kizárását feltételezve).
A végponttól végpontig terjedö viselkedés összhangban van a folyadék modellel úgy, hogy a behozott sorbaállási késleltetés nem éri el a folyadék késleltetést többször, mint a specifikált hibakorlát.
A garantált szolgáltatás nem ellenörzi a minimális vagy az átlagos késleltetését az adatcsomagoknak, inkább a maximális sorba állítási késleltetést. Továbbá az adatcsomag által észlelt maximális késés kiszámításához az útvonal késleltetését kell meghatározni és hozzáadni a garantált sorba állítási késleltetéséhez. (Azonban a késleltetés körülbelüli mértéke kiszámítható egy csomag átvitele során észlelt késleltetés megfigyelésével).
Ez a kibocsátás vezérlés feladatai közé tartozik.
Másként megfogalmazva bizonyos bit arány lefoglalását végzi a szolgáltatás. A korlátozott késleltetést WFQ vagy WRED kedvezményezett súlyozással történö használata biztosítja. A késleltetési korlát nem specifikált, azonban az ellenörzött terhelés szolgáltatás csupán "jó kiszolgálást" ígér; és a garantált szolgáltatás ad olyan információt, amelyböl kiszámíthatóak az aktuális késleltetési korlátok.
Ennek az oka nyilvánvaló. A késleltetési korlát nem olyan egyszerü, mint "19 kbps 500 milliszekundumos késleltetéssel".
Ha ez a 19 kbps egy E1 része, akkor az 500 milliszekundum nevetségesen hosszú, a késleltetési határ nem lesz több, mint kb. 20 milliszekundum. Amennyiben a 19 kbps egy 64 kbps vonalhoz tartozik, akkor valószínüleg két átmeneti tároló kimeneti várakozási sorával és adott sorba állítással dolgozunk; a késleltetési korlát kb. 400 milliszekundum. Egy 19.2 kbps sebességü vonalon 19 kbps-os átvitel esetén 1 másodperc körül van a késleltetési korlát.
Habár az RSVP egy fontos eszköz a QoS eszköztárában, ez a protokoll nem oldja meg az összes QoS-sel összefüggö problémát. Az RSVP-nek számtalan hátrányos tulajdonsága is van: nem eléggé skálázható, a kibocsátási vezérlés nem teljesen megfelelö és a végponttól-végpontig terjedö lefoglalás felépítéshez szükséges idö túl nagy.
Az RSVP-t már kipróbálták nagy kiterjedésü hálózatban is. Az RSVP számára a legrosszabb helyzetet az jelentené, ha egy gerinchálózati útvonalválasztó használnánk, ahol több ezer lefoglalást kellene kezelni és minden egyes átvitelt sorba kellene állítani a beállított lefoglalásoknak megfelelöen.
Az RSVP skálázhatóságát körülvevö információhiány miatt ez a protokoll leginkább csak a hálózat szélén alkalmazott, emiatt a gerinchálózaton általában más QoS eszközöket célszerü használni.
Egy másik fontos szempont a felhasználók authentikálása és authorizálása, azaz annak az eldöntése, hogy a lefoglalást kérö felhasználónak joga van-e az adott lefoglalás kérésére. Jelenleg az RSVP nem rendelkezik ezzel a képességgel.
Az RSVP az IP csomagok teljes hosszával számol, nem veszi számításba a lehetséges tömörítési sémákat, a CRC-ket vagy a vonali csomagolásokat (Frame Relay, Point-to Point Protocol [PPP], High-Level Data Link Control [HDLC]). Például amikor RSVP-t és G.729-es kódolást alkalmazunk VoIP esetén, akkor a Cisco IOS 24 kbps-t foglal, összehasonlítva az RTP használata esetén elérhetö 11 kbps körüli értékkel. Másként megfogalmazva egy 56k-s kapcsolaton csak 2 db 24 kbps-es lefoglalás enged meg annak ellenére, hogy akár több 11 kbps-os VoIP átvitel is elférne.
Egy jól megtervezett és ellenörzött
hálózatban azért lehet erre a problémára megoldást adni. Lehetöség van
arra, hogy a vonal sávszélességét az RSVP lefoglalások engedélyezése miatt
"túllépjük" - azaz több sávszélességet foglalunk le mint amennyi normálisan
rendelkezésre állna. Ezt az interfészeknél beállított sávszélesség érték
manipulálásával lehet megtenni. Például egy 56 kbps sebességü vonalon 100
kbps-es sávszélesség értéket használunk. Ezek után az RSVP a rendelkezésre álló
"virtuális" sávszélesség 75%-át, azaz 75 kbps-et lesz képes lefoglalni a
különbözö kérések számára. Így
A token (zseton) vödör a hivatalos definíciója az átviteli sebességnek, amelynek 3 komponense van: a burst méret, az átlagos sebesség és az idö intervallum. Habár az átlagos bit sebességet általában bit per másodpercben fejezik ki, a következö képlet segítségével bármely kettö ismeretében a harmadik kiszámítható:
Átlagos bit sebesség = burst méret / idö intervallum
Definíció szerint az intervallum bármely egész számú többszörös esetén sem éri el a bit sebesség az átlagos bit sebességet. Az intervallumon belül a bit sebesség tetszöleges értékü lehet.
A forgalmat gyakran alakítani kell. Ez nem csak azért történhet, hogy ne legyen a helyi interfészen torlódás, hanem azért is, hogy megfelelö legyen a távoli interfészeknek, illetve a szabályrendszernek. Ez a változtatás általában a megfelelö token vödör szürö megtalálását jelenti (átlag sebesség plusz az elfogadható forgalmi burst sebesség ellenörzés nélkül egy idöperiódus alatt). A token vödör értéket a felhasználó állíthatja be, vagy az interfész típusából lehet meghatározni.
A legegyszerübb eset az, amikor a szabályrendszer kényszeríti azt, hogy egy adott interfész sebessége átlagban ne érjen el egy bizonyos sebességet, még akkor sem, ha idölegesen túl is lépi azt. Az ilyen korlátozásnak általában az az oka, hogy a kérdéses átviteli szolgáltatást egy bizonyos sebességgel biztosít a szolgáltató.
Egy sokkal bonyolultabb kérdés egy olyan adatátviteli hálózat, amely torlódás esetén jelzést ad, különbözö hozzáférési sebességeket nyújt különbözö DTE eszközök számára, és képes lehet egy idöben több átviteli kapacitást nyújtani az egyik DTE-nek mint a másiknak. Ebben az esetben szükséges a token vödör vezérlése.
Bármelyik esetet is alapul véve nagyon kritikus fontosságú az, hogy a valós idejü forgalom (hang) érzékeny a késleltetésre és ezért a forgalom teljes mennyisége és csomagvesztés a hálózati kapcsolatokon erösen behatárolt, fontos a forgalom útvonalválasztók által történö alakítása. Az útvonalválasztó képes a forgalmat az általa meghatározott garanciáknak megfelelöen priorizálni.
Az interfész szintü forgalom alakítás egy olyan szolgáltatás, amely a token vödröt és a fair queue-t használja a szoftver interfész leíró blokknál (IDB) (amely vagy interfészhez vagy szubinterfészhez kapcsolódik). A parancs beállítja az átlagos sebességét a szoftver IDB-ben lévö token vödörbe tett forgalom számára, hogy összhangban legyen a kívánalmakkal és elindítja a megfelelö processzt.
A Custom queuing lehetö teszi a felhasználók számára, hogy meghatározzák egy bizonyos protokoll/forgalmi típus számára a rendelkezésre álló sávszélesség hány százalékát használhatják. 16 kimenö várakozási sort lehet definiálni, de létezik egy addicionális sor is a rendszer üzenetek (keepalive, stb.) számára. Minden egyes sor ciklikus sorrendben kap kiszolgálást és a forgalom meghatározott százalékát továbbítja.
A útvonalválasztókon meghatározzuk azt, hogy az egyes várakozási sorokból hány bájtot kell továbbítani egy ciklus alatt, ez a számítás az interfész sebességén és szükséges sávszélesség hányadon alapul.
A priority queuing lehetö teszi a hálózat adminisztrátora számára, hogy 4 forgalmi prioritást használjon (magas, normál, közepes és alacsony). A bejövö forgalom szürölistás osztályozás révén a 4 kimenö várakozási sor valamelyikébe kerül. A magas prioritású sor mindaddig kiszolgálásra kerül, amíg üres nem lesz; ezután kerülnek csak a következö szintü várakozási sorból továbbításra a csomagok.
Ez a sorba állítási elrendezés lehetövé teszi azt, hogy a kritikus fontosságú forgalom mindig megkapja azt a sávszélességet, amit igényel, és jócskán visszafogja a többi alkalmazás forgalmát.
Ennél a sorba állítási mechanizmusnál különösen fontos tudni a forgalmi viszonyokat annak érdekében, hogy az alkalmazások ne szenvedjenek sávszélesség hiányban.
A WFQ lehetö teszi azt, hogy a várakozási sorok ne szenvedjenek sávszélesség hiányban, és a forgalom megjósolható kiszolgálást kapjon. Az alacsony forgalmi igényü adatátvitelek kiemelt szolgáltatást kapnak, az összes átvinni kívánt forgalom idöben továbbítódik. A magas forgalmat okozó adatátvitelek a fennmaradó sávszélességen egyenlö mértékben vagy arányosan osztoznak.
A fair queuing dinamikusan azonosítja az egyes adatátviteli folyamokat és dinamikusan priorizálja azokat az elözöleg elfogyasztott sávszélesség alapján. Ez a felállás lehetö teszi azt, hogy a sávszélesség tisztességes módon kerüljön megosztásra szürölisták használata vagy más idörabló adminisztratív feladatok nélkül. A fair queuing az egyes adatátviteleket forrás- és célcím, protokoll típus, kapuszám és QoS/ToS értékek alapján különbözteti meg.
A fair queuing az alacsony sávszélesség igényü alkalmazások számára - amelyek a forgalom nagyobbik részét teszik ki - lehetö teszi, hogy annyi sávszélességet igényeljenek, amennyire csak szükségük van; háttérbe szorítva a maradékon osztozó nagy sávszélesség igényü forgalmakat. A fair queuing csökkenti a késleltetés ingadozását, tisztességes módon megosztja a rendelkezésre álló sávszélességet az alkalmazások között.
A súly érték a súlyozott fair queuing-nál több tényezöböl áll össze:
IP elsöbbség
RSVP
Frame Relay DE, FECN és BECN bitek
az adatfolyam által összesen forgalmazott adatmennyiség.
Az IP elsöbbség mezö értéke 0 (ez az alapértelmezett) és 7 között változhat. Ahogy nö ennek a mezönek az érték úgy ad több sávszélességet az adatfolyam számára az algoritmus.
Frame Relay hálózatoknál a torlódást az FECN és a BECN bitek jelzik. Amikor torlódásjelzés érkezik, akkor az algoritmus által használt súlyok úgy változnak, hogy a torlódással szembetalálkozó alkalmazás kevesebbszer továbbíthasson.
Az adatfolyam súlya fordítottan arányos az elfogyasztott sávszélesség összegével.
A többszörös kapcsolat széttördelés és közbeszövés vagy a Multichassis Multilink PPP (MMP) az az eljárás, amelyre több alacsony sávszélességü vonal esetén van szükség. A nagyobb méretü csomagok széttördelésre kerülnek, a sorba állítási rendszer a kisebb méretü csomagokat a nagyobb méretü csomagok darabjai közé helyezi be.
Az alapvetö megoldandó probléma az, hogy a legnagyobb (1500 byte) - a maximálisan elküldhetö egység (MTU) méretével megegyezö méretü - csomagoknak 215 milliszekundumra van szüksége egy 56 kbps sebességü vonalon való áthaladáshoz. A valós idejü forgalmat vivö csomagoknak (föként hangátvitel esetén) a teljes végponttól végpontig terjedö késleltetése a 150-200 milliszekundumos tartományba kell hogy essen, de ezt ugye a 215 milliszekundumos vonali késleltetés esetén túllépjük.
Az MMP az MP csomag széttördelö képességére épít. Az MMP 4 vagy 16 félbeszakítási/felfüggesztési szintet ("sorba állítást") nyújt, amíg az MP csak egyet. Az MMP esetén nincs szükség arra, hogy a vonal minkét vége támogassa az MMP-t.
Az MMP-t csak Point-to-Point Protocol-t használó (PPP) interfészeken lehet alkalmazni, kizárva a többi WAN átviteli módszert (Frame Relay, stb.).
Az MMP csak a széttördelési eljárást és a félbeszakítási szinteket specifikálja, és nem specifikálja az egyes csomagdarabok priorizálásához szükséges sorba állítási technikát.
A szabályrendszer-alapú útvonalválasztás esetén a rendszer adminisztrátorának lehetösége van az általa beállított szabályrendszerrel irányítani a forgalmat, és nem csak az útvonalválasztó protokollok által meghatározott útvonalválasztást használni. A szabályrendszer-alapú útvonalválasztás lehetövé teszi az IP elsöbbség mezö megváltoztatását, és ezzel lehetöséget teremt a különbözö szolgáltatási osztályok engedélyezésére a hálózaton.
A szabályrendszer alapulhat az IP címeken, kapu számokon, protokollokon vagy a csomagok méretén. Egyszerü esetben csak az egyik ilyen szempontot vehetjük figyelembe a szabályrendszer kialakításakor, de akár mindegyiket is használhatjuk egy bonyolultabb esetben.
Minden csomag, amely egy szabályrendszer-alapú útvonalválasztásra engedélyezett interfészen érkezik be egy route map-nak nevezett kifinomult szürön halad át. A route map dönti el, hogy a csomag hová kerüljön továbbításra.
A route map bejegyzéseket engedélyezö vagy tiltó jelzéssel látjuk el. Ha a bejegyzés tiltó, akkor az összehasonlítás feltétellel egyezö csomagok a normális továbbító csatornán keresztül kerülnek továbbításra (más szavakkal a célcím alapú útvonalválasztás hajtódik végre). Ha a bejegyzés megengedö, de a csomag nem egyezik meg az összehasonlítási feltétellel, akkor a csomagok szintén a normál útvonal-választási csatornán át továbbítódnak. Csak akkor kerülnek a szabályrendszer-alapú útvonalválasztás által specifikált beállítások végrehajtásra, ha a bejegyzés megengedö és a csomag összehasonlítása a feltétellel egyezö eredményt ad.
Megjegyzés: a szabályrendszer-alapú útvonal-választást a csomagot fogadó és a nem a csomagot elküldö interfészen kell megadni.
Standard vagy kiterjesztett IP elérési vezérlö listát lehet használni az összehasonlítási feltételek megfogalmazására. Standard IP elérési listával forráscím feltételeket lehet specifikálni; kiterjesztettel pedig forrás- és célcím, alkalmazás, protokoll típus, ToS és elsöbbség mezö érték alapján lehet dönteni.
Az egyezési vizsgálatot továbbfejlesztették, hogy a csomagokat méret specifikált minimum és maximum méret alapján is lehessen vizsgálni. A hálózati adminisztrátor ezek után a csomagméretet, mint feltételt használhatja az interaktív és tömeges forgalom megkülönböztetésére (a tömeges forgalom általában nagyobb csomagméretet használ).
A szabályrendszeres útvonal-választási processz addig vizsgálja a route map-et, amíg egyezést nem talál. Ha nem talál egyezést, vagy tiltó bejegyzést talál, akkor a normál célcím alapú útvonal-választás következik.
Megjegyzés: mint mindig, most is ott van egy implicit tiltás az egyezést kifejezések listájának a végén.
Alacsony terhelésü kapcsolatokon jobb lehet a sorba állítási technikákat nem használni. Nagy sebességü vagy nagymértékben terhelt kapcsolt esetén ajánlott elöször tesztelést végezni, hogy melyik QoS eszköz nyújtja a legkövetkezetesebb megoldást.
Az IP elsöbbség egy perem funkció, amely lehetövé teszi a gerinchálózati QoS eszközöknek (Random Early Detection [RED], WRED), hogy a forgalmat a szolgáltatási osztálynak megfelelöen továbbítsák. A rendszergazda 6 szolgáltatási osztályt definiálhat. Ezek után kiterjesztett elérési vezérlö listák és szabályrendszer térképek használatával torlódáskezelésre és forgalmi osztályok számára történö sávszélesség foglalásra használhatja ezeket. Az IP elsöbbség szolgáltatás az egyes csomagokhoz történö CoS hozzárendelésére az IP fejléc ToS mezejében lévö három elsöbbség bitet használja fel. Az IP elsöbbség szolgáltatás jelentös flexibilitást nyújt az elsöbbség hozzárendeléséhez; lehetöség van alkalmazás, IP cím, MAC cím vagy fizikai por alapján történö hozzárendelésre.
A rendelkezésre álló IP elsöbbség beállítások a következök lehetnek a ToS mezöben:
routine Set routine elsöbbség (0)
priority Set priority elsöbbség (1)
Immediate Set immediate elsöbbség (2)
Flash Set Flash elsöbbség (3)
flash-override Set Flash override elsöbbség (4)
critical Set critical elsöbbség (5)
internet Set internetwork control elsöbbség (6)
network Set network control elsöbbség (7)
A 6-os és a 7-es értéket a hálózati vezérlö és ellenörzö információk részére (útvonal-választási információfrissítés, stb.) van fenntartva. Alapesetben minden csomag a 0-s osztályba tartozik.
Az IP elsöbbség szolgáltatás lehetövé teszi, hogy a hálózat vagy passzív módon (a felhasználó által beállított elsöbbséget hagyva) vagy aktív módon (a megadott szabályrendszert használva beállítsa vagy felülírja az elsöbbségi hozzárendelést) viselkedjen. Az IP elsöbbséget le lehet képezni más hasonló technológiáknál alkalmazott QoS eljárásokra (például Tag Switching, Frame Relay, vagy ATM), lehetö téve végponttól végpontig terjedö QoS szabályrendszer nyújtását heterogén hálózati környezetben. Ezért az IP elsöbbség szolgáltatási osztályokat tesz lehetövé a meglévö alkalmazások módosítása és bonyolult hálózati jelzésrendszer nélkül.
Az IP elsöbbség nem egy sorba állítási módszer, de lehetö teszi más sorba állítási eljárások számára (WFQ, WRED), hogy az IP elsöbbség alapján priorizálják a csomagokat.
A Cisco IOS szoftvernél a passzív mód az alapértelmezett. Ebben a módban nincs bebocsátás ellenörzés, és bármely IP elsöbbség opcióval rendelkezö alkalmazás magasabb QoS-t kaphat. Az IP elsöbbség bitek értékét az útvonalválasztás során lehet felülírni route map-ek és szürölisták segítségével.
A véletlenszerü korai detektálás - Random Early Detection (RED) - egy torlódás megelözési algoritmus, amely azon az elven alapul, hogy bizonyos forgalom típusok érzékenyek a csomagvesztésre, és lelassítják a forgalmat, amikor csomagvesztést érzékelnek. A 1980-as évek elején kifejlesztett RED a csomageldobás módszerét használja a csomagokat küldö host-ok forgalom-kibocsátásának csökkentésére.
A RED jól müködik olyan környezetekben, ahol a forgalom magas százaléka a csomagvesztést jól türi (TCP). Ha a forgalom jelentös százaléka nem ilyen (például Novell NetWare vagy AppleTalk), akkor az algoritmus által a forgalom csökkentése érdekében eldobott csomagok nagy valószínüséggel súlyos mellékhatásokat okoznak. Hasonlóan, a csak egyszer elküldhetö (valós idejü) forgalom, mint például a hangátvitel nehezen türi a csomagvesztést. Az RED által okozott adminisztratív többletterhelés meglehetösen alacsony, ezért egészen az OC-3 sebességü interfészekig alkalmazható.
A RED müködésének megértéséhez a legáltalánosabb használt megbízható protokoll, a TCP müködését kell megértenünk csomagvesztési szituációban.
Amikor a TCP vevö egy adat szegmenset vesz, akkor ez vagy az a szegmens, amit várt (az oktet szekvencia szám az, amire számított), vagy nem az. Ha ez a következö várt szekvencia szám, akkor az összes elküldhetö adatot továbbítja az alkalmazás felé, frissíti a várt szekvencia számot, és vagy azonnal, vagy kis késleltetéssel elküldi a nyugtázást (ACK) jelezve, hogy mindent megkapott kivéve azt az egy (hiányzó) szekvencia számot. Vagyis minden más elküldött szegmensre nyugtázást próbál küldeni. Az ok egyszerü: a legtöbb alkalmazásban van valamilyen visszaküldött válasz, amelyre a nyugtázást rá lehet ültetni, és ez a kis késleltetés lehetövé teszi a "hordár" elkapását. De ha valamit nem sorrendben kap, akkor általában azonnal nyugtáz mindent, amit csak tud. A cél az, hogy ha valami elveszik, akkor az elsö ismételt küldés befoltozza a hiányzó részt.
Amikor a TCP küldö megkapja a nyugtázást, akkor elöször is ellenörzi, hogy van-e valami kinnlevö, nyugtázandó adat. Ha nincs, akkor ez egy keepalive üzenet. Ha van, akkor ez vagy a küldött adat egy részét, vagy semelyik részét sem nyugtázza. Ha egy részét nyugtázza, akkor a küldö ellenörzi, hogy megnövekedett-e a hitelkeret, amely a küldö számára több adat küldését teszi lehetövé. Ha semelyik részét sem nyugtázza és van kinnlevö adat, akkor csak egy lehetséges magyarázat van - ez egy megismételt nyugtázás. Nos, miért is ismétel meg egy küldö egy nyugtázást? Legvalószínübben azért, mert néhány adatot nem megfelelö sorrendben kapott meg (ez okozza az elsö nyugtázást), majd megkapta a második szegmenset szintén nem megfelelö sorrendben (a második nyugtázást okozva). Nos, miért kaphatott meg két szegmenset nem megfelelö sorrendben? Bizonyára azért, mert egy szegmens eldobódott.
Amikor egy TCP küldö kiesett szegmenset érzékel, vagy az imént leírt módon vagy idötúllépés miatt, akkor a nyugtázási várólistáján lévö elsö szegmenset ismét elküldi (az adatátvitel újraindítása érdekében) és a lassú indítás állapotba lép be. Ez teszteli a hálózatot, hogy mekkora az a sebesség, amellyel adatvesztés nélkül adhat.
Egy RED-et nem használó hálózatban a megtelö átmeneti tárolók és eldobódó csomagok több TCP kapcsolatnál lassú (újra) indítást okoznak. Ez a helyzet végsö fokon azt eredményezheti, hogy a hálózati forgalom a TCP ablakok méreteinek növekedésével szinte hullámokban jön.
A router a RED használatával képes menedzselni a TCP lassú indítás mechanizmust, elöször csak egy TCP átvitelt visszafogva, megmérve az okozott hatást, majd ha szükséges, a többi TCP átviteleknél is csomagokat eldobva.
A RED a várakozási sort két részre osztja, egy normális müködésre szánt részre, ahonnan szándékosan sohasem kerül adat eldobásra, és egy másikra, amely az additív terhelést okozó, túlburjánzó TCP kapcsolatok által okozott túlcsordulások kezelésére hivatott. Ezek a túlcsordulások közvetlenül összefüggnek az adási és a várokozási sorok mélységével. A RED méri is az átlagos sor mélységét - amikor az átlagos sor mélység az alacsony tartományban van, akkor a felsö tartomány átmeneti tárolóként szolgál, de amikor az átlagos sor mélység a felsö tartományba esik, akkor el kell kezdeni az adatok eldobását. Nem minden kerül eldobásra, csak bizonyos arányú eldobás kezdödik el.
Az eldobási mértéknek a legutóbbi eldobás óta eltelt idö (minél több idö telt el azóta, annál nagyobb a valószínüsége, hogy ez az üzenet eldobásra kerül) és az átlagos sor mélység sztohasztikus függvényének kell lennie. Ha a forgalom szintje hullámzik, akkor elöször egy csomag eldobásra kerül, és valamennyi idö eltelhet abban az esetben, ha a hullám csak idöleges volt. Ha a forgalom szintje növekszik, akkor további csomagok kerülnek eldobásra a növekvö forgalmi terhelés arányában.
Továbbá, az eldobások közötti intervallumnak elég hosszúnak kell lennie, hogy a TCP küldönek lehetösége legyen a csomagvesztés érzékelésére és a lassú indítás állapotba lépésre. Természetesen, ha a forgalom véletlenül kerül kiválasztásra és az elsö TCP küldönek relatíve alacsony a forgalma, akkor néhány más kapcsolat fajlagoson többször kerül "eltalálásra".
A RED nagy sebességü TCP/IP hálózatoknál hasznos, a vezérelt csomageldobással megelözi a torlódás kialakulását.
A Cisco ajánlása szerint az exponenciális súlyozási tényezöt alapértéken célszerü hagyni; azonban a müködési környezettöl függöen szükséges lehet az érték megváltoztatására. Például a 10-es érték (az alapértelmezett), amely 10-4 elvesztési arányt valósít meg nagy sebességü kapcsolatok esetén javasolt (DS3 és OC-3); míg a 7-es érték, amely 10-3 elvesztési arányt valósít meg, T1 sebességü kapcsolatoknál ajánlott.
A RED egy típusa a FIFO sorba állításnak, és ezért nem lehet olyan interfészen bekonfigurálni, amely custom, priority vagy fair sorba állításra van már konfigurálva.
Ez a rész néhány alapvetö eljárást mutat be a hang forgalom priorizálására és a szükséges minöség biztosítására Frame Relay csatornán, valamint megjegyzéseket füz minden egyes megoldáshoz. A megoldások skáláján megtalálható az MTU változtatása, az RTP fejléctömörítés, külön DLCI a hang és az adatforgalom részére, a rendelkezésre álló sávszélességnek a CIR-hez állítása és az általános forgalom alakítás használata. Az adott hálózaton legsikeresebben használható eszköz megtalálásának érdekében ki kell tesztelni az adott Frame Relay hálózat karakterisztikáját.
Alacsony sávszélességü Frame Relay kapcsolatoknál szükséges a nagyobb méretü csomagok széttördelése a nagy csomagméret miatt jelentkezö késleltetés elkerülése érdekében. Az MMP-hez hasonló adatkapcsolati szintü széttördelést végzö eszköz nélkül az interfész MTU értékét szükséges megváltoztatni a késleltetési türés és a sávszélesség függvényében. Ez a beállítás megoldja a nagy csomagok kérdését, mert az interfészen minden, az "új" MTU méreténél nagyobb csomag széttördelésre kerül.
Az MTU átméretezés különbözö problémákat okozhat. Egy csomag 300 bájtokra tördelése a csomag processz kapcsolását okozza. A széttördelt csomagok egész hálózaton történö utazásuk során "új" MTU méretüek lesznek. Természetesen a kisebb csomag méretek az egész hálózat teljesítményét is befolyásolják. És ha valamelyik csomagnál a ne-tördelj-szét bit be van állítva, akkor az eldobásra kerül.
Az általános szabály MTU változtatásra az,
hogy 64 kbps-os interfészen 100, 128 kbps-on 200, 256 kbps-on 400 és 512
kbps-on
Mint a PPP-t alkalmazó bérelt vonalnál, a CRTP-t csak alacsony sávszélességü kapcsolatnál kell használni.
A tesztelések azt mutatják, hogy a legjobb hangminöség Frame Relay esetén 2 DLCI használatával érhetö el. Ebben az esetben az elsö DLCI az adat DLCI, a második a hang DLCI; minden hang forgalomnak a hang DLCI-t kell használnia, a többi forgalom az adat DLCI-t használhatja.
Ennél a példánál két szubinterfészt használunk, minden adatforgalom a serial 0.1 interfészen át továbbítódik (adat DLCI). Az adat DLCI nincs a CIR értékre korlátozva, szükség esetén bármikor használhatja a Frame Relay burst sebességét. MTU méretezést kell használni az adat DLCI-n, mert csak egy fizikai kapcsolat van a Frame Relay hálózathoz. Csak egy fizikai interfész esetén a nagy csomagok a hang DLCI-n átmenö forgalom akaratlan késleltetését okozhatják.
A serial 0.2 szubinterfész limitált sávszélességre van beállítva a rendelkezésre álló CIR alapján. Mivel nagy csomagok nem kerülnek a hang DLCI-hez küldésre, ezért az MTU méretezés nem szükséges.
Az általános forgalom alakítás használata mind a hang, mind az adat DLCI-n lehetövé teszi a forgalom lelassítását a Frame Relay hálózaton érkezö torlódásjelzés (BECN) esetén. Emellett szintén megengedi a hálózati rendszergazdának az idöperiódus és az alatt elküldhetö teljes adatmennyiség mértékének beállítását.
Megjegyzés: a Frame Relay forgalomalakítás és az RSVP jelenleg nem kompatibilisek.
Mint minden más hálózati elrendezésnél, ennél is vannak hátrányos tulajdonságok. A legbonyolultabb a Frame Relay hálózatban szükséges DLCI duplázás megvalósításához szükséges adminisztratív munka. További adminisztratív munkát jelent az IP útvonalak megkétszerezése és a komplex beállítások használata. Nem elhanyagolható a két DLCI használat okozta többletköltség sem.
Megjegyzés: a felhasználónak szabályrendszer-alapú vagy állandó útvonalválasztást kell ahhoz beállítania, hogy az x forgalom az x interfészen át továbbítódjon.
Az elözöek áttekintést és rövid magyarázatot adtak a Cisco IOS legtöbb QoS eszközéröl. Ezek után itt az idö megérteni, hogy ezek az eszközök hol és milyen típusú hálózatoknál használhatóak. Általánosságban elmondható, hogy a perem szekcióban leírt eszközöket az alacsony sávszélességü kapcsolatoknál kellene használni, ahol a sorba állítás és a tömörítés a legnagyobb hatást fejti ki. A gerinchálózati részben ismertetett eszközöket pedig megközelítöleg a hálózat központjában kell bevetni. A gerinchálózaton a fö cél nem a csomagok osztályozása vagy biztonsági listák elöírása, hanem a csomagoknak a cél felé történö lehetö leggyorsabb kapcsolása, továbbítása. Azonban néhány gerinchálózatnál szükséges a torlódás menedzsment eszközök használata, például a WRED alkalmazása a forgalom ellenörzésére és a terhelési túllövések levágására.
Amikor VoIP hálózatot tervezünk, akkor a késleltetést és az átviteli idöt szigorúan ellenörzés alatt kell tartani. Elfogadható hangminöséges eléréséhez a végponttól-végpontig terjedö késleltetést 200 milliszekundum alatt kell tartani. Ez a késleltetési határ nem az átlagos késleltetésen, hanem az egyes csomagoknál megengedett késleltetésen alapul.
Két VoIP-t végzö Cisco útvonalválasztó és torlódásmentes kapcsolat esetén a késleltetés az 50-60 milliszekundumos tartományba esik. Az elérendö 150-200 milliszekundumos késleltetést célul kitüzve és a két VoIP útvonalválasz okozta késleltetést adottnak véve, 90-150 milliszekundumig tarthat a csomagforrástól végpontig való átvitele.
Amikor tervezésre vállalkozunk, akkor az egyik legelsö és fontos dolog a használandó CODEC kiválasztása. Azok, akik VoIP hálózat telepítését választják, legnagyobb valószínüséggel kihasználják a csöndelnyomás (VAD) és a tömörítés (G.729) adta elönyöket. Más cégek emelt minöségü szolgáltatást akarnak nyújtani, ekkor a G.711 a vonzóbb.
A CODEC választásnál figyelembe veendö szempontok között szerepelhet a MOS érték, a tandem kódolás, a rendelkezésre álló sávszélesség, a megtakarítható költség és a felhasználók száma. Ezeket a szempontokat gondosan mérlegelni kell a CODEC kiválasztás elött.
Nagyon fontos megérteni, hol tart ma a felhasználó hálózata és milyennek akarja a felhasználó az adat-hang integráció után. A következö kérdésekre kell választ kapni mielött a javasolt megoldásról szó eshetne:
Mennyi a hang hálózat éves költsége és mekkora a szükséges tökebefektetés?
Mi a VoIP alkalmazásának elsödleges célja?
Hány távoli kirendeltség van?
Hány fö van a távoli kirendeltségeken?
Hány perc az átlagos telefonhasználati idö / fö / távoli helyszín?
A hívások hány százaléka irányul a cégen belülre?
Mekkora az átlagos költség percenként és helyszínenként?
Milyen a felhasználók által elvárt hangminöség (rádiótelefon, fizetö minöség)?
Hány perc a helyszínek között lebonyolított távolsági hívások idejének összege?
A forgalom hány százaléka lesz hang és hány százaléka fax?
Támogatja-e a meglévö IP infrastruktúra a hangátvitelhez szükséges QoS-t?
Frame Relay hálózatok késleltetését alapvetöen az állandó sorbaállítási és a változó bufferelési késleltetés határozza meg. Az elöbb említett két tényezö mellett a terjedési idö is jelentös szerepet tölthet be (például VSAT-os FR szolgáltatás esetén), de normál körülmények között ezt elhanyagolhatjuk. A sorbaállási késleltetés a frame relay keret méretétöl és vonal sebességétöl függ. A keret méret növelése hatékonyabb sávszélesség kihasználást, ugyanakkor nagyobb késleltetést is eredményez. Pl. 64 kbi/s és 1500 bájt hosszúságú csomagméret esetén a sorbaállítási késleltetés egyetlen linken 187 ms (1500*8/64 000). Természetesen amennyiben a FR keret több FR linken, kapcsolón megy keresztül, minden egyes kapcsoló újabb sorbaállítási késleltetést eredményez. A nagy méretü adat csomagok okozta késleltetés megelözése érdekében a Frame Relay Forum FRF 12 szerinti FR keret darabolás/összeállítási eljárást is alkalmazhatjuk.
A bufferelési késleltetést a forgalmi, torlódási viszonyok és a berendezés belsö felépítése (buffer méret) határozza meg. A hang csomagok megfelelö prioritással történö kezelése "Átviteli minöségi követelmények" fejezetben ismertetett mechanizmusok (RSVP, IP precedence , FRF 12 ...) segítségével történik.
Általában a FR hálózat okozta késleltetés nem jelent megoldhatatlan problémát az IP alapú hangtovábbítás számára. A FR tervezési irányelvekkel részletesen foglalkozik még a "Frame Relay Qos" fejezet.
A hangcsatornák számának meghatározása után rendelkezésünkre áll a minimálisan szükséges sávszélesség. A FR virtuális áramkör garantált átviteli sebességének (CIR- Committed Information Rate) egyenlönek vagy nagyobbnak kell lenni, mint a hangcsatornák és jelzésrendszerek átviteléhez szükséges sávszélesség. Természetesen a CIR igénylésekor más adat alkalmazás sávszélesség igényét is figyelembe kell venni.
A hang és adat forgalom megfelelö prioritással történö kezelése a routerekben, access koncentrátorokban az "Átviteli minöségi követelmények" fejezetben ismertetett mechanizmusok (RSVP, IP precedence ,..) segítségével történik. A felhasználók a hang és adat forgalmat FR szinten is elkülöníthetik, ha két PVC-t bérelnek a szolgáltatótól, de erre a legtöbb esetben nincs szükség.
Az ATM különbözö szolgáltatási osztállyal igényelhetö, amely közül az IP alapú hangátvitelre leginkább a CBR és a VBR szolgáltatási osztály a legalkalmasabb. Az UBR a szabvány szerint nem garantál késleltetés sem átvitt adat mennységet. Az ABR alkalmas hangtovábbításra elterjedése azonban még meglehetösen limitált.
Mivel az ATM szolgáltatást úgy tervezték, hogy alkalmas legyen valós idejü információ továbbítására, a késleltetés és a jitter nem okoz problémát. CBR esetén a késleltetés és a késleltetés ingadozása (CDVT) kicsi, VBR (nrt, rt) szolgáltatás esetén nagyobb, de még így is nagyságrendekkel alacsonyabb, mint amit a FR kapcsán láttunk.
Sávszélesség.
CBR szolgáltatás esetén a PCR-nek (Peak Cell Rate -Maximális Cella Sebesség) nagyobbnak vagy egyenlönek kell lenni, mint a hangátvitelhez meghatározott sávszélesség.
VBR szolgáltatás esetén a SCR-nek (Sustained Cell Rate - Átlagos Cella Sebesség) kell nagyobbnak vagy egyenlönek lenni, mint a hangátvitelhez kiszámított sávszélesség. A VBR szolgáltatási osztály jobban alkalmas idöben változó forgalom
Találat: 2104
