Frame Relay alapok

A Frame Realy egy WAN technológia, melynek népszerűsége a VPN és az MPLS elterjedésével ugyan csökkent, de érdemes azért megismerni a működését.

Az írás a Frame Relay cikksorozat első része.

Miért van szükségünk a Frame Relay-ra?

Vegyünk egy egyszerű példát. Adott egy cég egy központtal (R1). A cég két új telephellyel bővül. (R2 és R3) A két új telephelyet bérelt vonalakkal kötjük a központhoz valahogy a következő ábra szerint:

Az összeköttetés kialakításához 2 új soros vonali interfészre volt szükség a R1-en, és 1-1-re a telephelyi forgalomirányítókon. De mi van akkor, ha a cég 20 új telephellyel bővül? Akkor mindegyik pont-pont kapcsolathoz 20 soros vonali interfészre (és ha nincsen integrálva, ugyanennyi CSU/DSU-ra) van szükség. Ehhez persze több forgalomirányítóra, rack-szekrényre, és így tovább. Más megoldást kell keresni.

Gondoljunk csak arra, hogy egy Ethernet helyi hálózat esetén milyen egyszerű dolgunk lenne. Ott egyetlen Ethernet interfészen keresztül egy kapcsolóhoz kapcsolódna a R1, majd ezekkel a kapcsolókkal újabb kapcsolókhoz, míg azok végül a telephelyi forgalomirányítókhoz. Itt viszont nem egy LAN-t, hanem egy WAN-t kell kialakítanunk. A LAN kapcsolókhoz hasonlóan nem lehetne valamilyen WAN kapcsolókat használni? De igen, erre ad megoldást a Frame Relay. A forgalomirányítók között Frame Relay kapcsolókkal teremtjük meg a kapcsolatot, a Frame Relay kapcsolókhoz pedig soros vonalakkal kapcsolódnak a forgalomirányítók. Mégpedig mindegyik kapcsolóhoz csak egyetlen soros interfészen keresztül. Nekünk csupán azokkal a Frame Relay kapcsolókkal kell foglalkoznunk, melyekhez közvetlenül kapcsolódunk. A Frame Relay kapcsolók konfigurálását általában a távközlési szolgáltatók végzik, így azzal nincsen dolgunk, csupán a szolgáltatók által megadott tulajdonságaikat (pl. használt protokollokat) kell figyelembe vennünk. (Ethernet kapcsolók esetén könnyű dolgunk volt. Csupán csatlakozni kellett hozzájuk, és minden működött azonnal a 2. rétegben. Itt egy kicsit több konfigurációra lesz szükség.)

Virtuális áramkörök

A hálózatban Frame Relay kapcsolók alakítják ki  a forrás és a cél eszközök közötti logikai adatutat. Egy ilyen útnak a neve virtuális áramkör (virtual circuit, VC).  A virtuális jelző azt takarja, hogy a két eszköz (forgalomirányító) a hálózaton keresztül nem közvetlenül kapcsolódik össze egymással. A fenti topológiában például az R1 és az R2 úgy kommunikálhatnak egymással, mintha közvetlenül kapcsolódnának egymáshoz, pedig lényegében a kapcsolatot a Frame Relay hálózatban a Frame Relay kapcsolók valósítják meg.

A virtuális áramköröknek két típusát különböztetjük meg:

SVC (Switched Virtual Circuit): Csupán a kommunikáció idejére, átmenetileg jön létre a virtuális áramkör dinamikusan.

PVC (Permanent Virtual Circuit): Előre, állandó jelleggel kiépítjük a virtuális áramkört. Ez a típus felel meg leginkább a bérelt vonali koncepciónak.

Ezeket a virtuális áramköröket a szolgáltatók alakítják ki.

DTE és DCE

Vezessünk be két új fogalmat, a DTE és a DCE fogalmát:

A DTE (Data Terminal Equipment) azok az eszközök, melyek a virtuális áramkörök végén találhatók, lényegében a forgalomirányítók maguk.

A DCE (Data Communication Equipment) eszközök azok a Frame Relay kapcsolók, melyekhez a forgalomirányítók kapcsolódnak.

A DTE és a DCE eszközök közötti összeköttetést nevezzük hozzáférési összeköttetésnek (access link).

A Frame Relay beágyazás

A Frame Relay tehát egy olyan nagyteljesítményű WAN protokoll, amely az OSI modell fizikai és adatkapcsolati rétegében működik. Alapvetően a Frame Relay keretszerkezetét az ITU (International Telecommunication Union) Q.922 számú LAPF (Link Access Procedure for Frame Relay) specifikációja határozza meg. A szabványból azonban hiányzik az, hogy a keret által hordozott adatot (3. rétegbeli csomagot) melyik 3. rétegbeli protokoll dolgozza fel. (Tehát hiányzik a protokolltípus mező.) Két módszer született ennek pótlására:

1. A Cisco (és másik 3 gyártó) továbbfejlesztette az LAPF fejlécet, és az adatrész elé beszúrt egy 2 byte-os protokolltípus mezőt. (Mely pontosan megfelel a Cisco HDLC protokolljában szereplő protokolltípus mzőnek.)
2. Az RFC1490-ben egy gyártófüggetlen megoldás jelent meg Multiprotocol Interconnect over Frame-Relay néven. Ez újabb fejlécet definiált az LAPF fejléc és az adatrész közé, mely a protokolltípuson kívül tovább mezőket is tartalmaz.

A következő ábra ezeknek a kereteknek a szerkezetét mutatja. Az ábrán szereplő ismeretlen fogalmakkal a későbbiekben még találkozunk.

Ezeket az új mezőket a Frame Relay kapcsolók nem dolgozzák fel, kizárólag a DTE eszközöknek szolgáltatnak információt.

A Cisco forgalomirányítók alapértelmezetten az első módszert alkalmazzák, de konfigurálható a második is. Fontos megjegyezni, hogy egy virtuális áramkör két végén található DTE-ken (tehát a forgalomirányítókon) ugyanazt a módszerrel kell beágyazni a csomagokat, különben nem tudják majd feldolgozni egymás kereteit. Különböző virtuális áramkörök (még akkor is, ha azonos forgalomirányítóról indulnak ki, már használhatnak különböző Frame-Relay protokollokat.)

Címzés a Frame Relay hálózatokban

Egy Frame Relay hálózatban a forgalomirányítók soros kapcsolattal kapcsolódnak a hálózathoz, de nem csupán pont-pont kapcsolatot alakítanak ki egymással, hanem egy forgalomirányító több másikat is elérhet. Ehhez azonban a fizikai rétegben is címre van szükségük, ez lesz a DLCI (Data Link Connection Identifier).

Ilyen azonosítónk az Ethernet hálózatban is volt, csak azt MAC címnek hívtuk. MAC címe a forrás és a cél eszköznek volt, vagyis a MAC címek magukat az eszközöket azonosították! A Frame Relay hálózatban a DLCI nem az eszközt, hanem a virtuális útvonalat azonosítja, ráadásul külön a forrás és külön a cél forgalomirányító szemszögéből. A DLCI-k értelmezése sokszor okoz gondot, ezért vizsgáljuk meg egy kicsit részletesebben. A következő ábrán a forgalomirányítókat összekötő virtuális útvonalakra (áramkörökre) már felírtuk az azokat azonosító DLCI címeket:

A logikai topológiát a következőképpen értelmezzük:

• R1 forgalomirányító a 23-as című virtuális áramkörön keresztül éri el R2-t.
• R2 forgalomirányító a 23-as című virtuális áramkörön keresztül éri el R1-et.
• R1 forgalomirányító a 36-as című virtuális áramkörön keresztül éri el R3-at.
• R3 forgalomirányító a 36-as című virtuális áramkörön keresztül éri el R1-et.

A helyzetet az bonyolítja, hogy egy virtuális áramkör két végén más és más cím is szerepelhet. Tegyük fel, hogy Amerikában a híres 66-os utat, amely összeköti Santa Monica-t és Chicago-t másképpen hívnák az egyik végén, mint a másikon. Egy santa monica-i lakos azt mondja: Ahhoz, hogy eljussak Chicago-ba, el kell indulnom a 66-os úton. Ezzel szemben egy chicago-i lakos így gondolkodik: Ahhoz, hogy eljussak Santa Monica-ba, el kell indulnom a 74-os úton. Mindketten eljutnak a céljukig, noha nem ugyanazt az útvonalszámot, de ugyanazt az utat használták. Erre mutat példát a következő ábra:

És hogy egy kicsit tovább bonyolítsuk a példát, semmi nem akadályozza meg, hogy az egyik forgalomirányító ugyanazt a címet használja egy útvonalra, mint egy másik. A következő ábrán R3 ugyanazzal a címmel éri el R1-et, mint R1 R2-t:

Arra természetesen nincsen lehetőség, hogy például R1-ből két azonos című útvonal induljon el. Ezért mondjuk, hogy a DLCI-k lokálisan egyediek, de globálisan nem. Vagyis egyetlen forgalomirányítóból kiinduló VC-ket különböző DLCI-k azonosítják, és az egyik forgalomirányítónál felhasznált DLCI egy másik forgalomirányítónál is felhasználható. (És persze semmi nem mond ellent annak, hogy egy VC-t mindkét oldalon ugyanazzal a DLCI-vel azonosítsuk.)

Ahogyan már korábban néztük, a Frame Relay hálózaton adatokat küldünk, az adatok (LAPF) Frame Relay keretekbe ágyazva haladnak. Emlékezzünk vissza, Ethernet hálózat esetén többek között az Ethernet keretbe lett elhelyezve a cél eszköz, valamint a forrás eszköz MAC címe. A Frame Relay hálózaton nem az eszközöket címezzük, hanem a közöttük haladó útvonalat (VC-t), vagyis csak egyetlen címre van szükségünk, ahogyan a következő ábrán a Frame Relay keretszerkezetében láthatjuk. (Itt kell megjegyezni, hogy maga a DLCI ugyan 10 bites, de itt egy 16 bites-os rész van fenntartva számára, mivel mellé egyéb információkat is betettek, de erről majd később.)

A gond csak az, hogy az útvonalat a forráseszköz és a céleszköz más és más DLCI-vel azonosítja. Melyik kerüljön be a keretbe? A folyamat a következőképpen zajlik: Tegyük fel, hogy R1 küld egy keretet R2-nek. R1 elhelyezi az R2-höz vezető VC címét a keretben, majd elküldi a hozzá kapcsolódó Frame Relay kapcsolónak. A keret végighalad a hálózaton (a szolgáltató dolga, hogy a megfelelő útvonalon vigye végig), mígnem elérkezik az utolsó Frame Relay kapcsolóhoz, mely közvetlenül kapcsolódik R2-höz. Ez a kapcsoló kicseréli a virtuális áramkör címét arra, amelyikkel R2 címezi meg, így R2 is megtudja, melyik VC-ről érkezett a keret. A következő ábra mutatja ezt a folyamatot:

Talán bonyolultnak tűnik ez az egész, de csak azért, mert betekintettünk a színfalak mögé. A normál működés során ebből mi sokkal kevesebbet látunk.

És mi van az IP címzéssel?

Ahhoz, hogy a Frame Relay hálózaton keresztül kommunikálni tudjunk, a forgalomirányítók interfészeihez IP címet is kell rendelnünk. Felmerülhet rögtön a kérdés, hogy amennyiben egy interfészből több virtuális áramkör indul ki, akkor ezekhez rendelhetők-e különböző IP címek? Előre eláruljuk, hogy igen, de ezzel a problémával majd egy másik cikkben foglalkozunk. A mostani példánkban elégedjünk meg egyetlen IP címmel.

Azért, hogy átláthatóbb legyen a topológia, a DLCI-k mellett tüntessük fel az IP címeket is, és címezzük meg valamennyi forgalomirányítót.

Tegyük fel, hogy R1-nek a mögötte lévő LAN hálózatából egy IP csomagot kell továbbítani. R1 meghozta a forgalomirányítási döntését, és ezek szerint R2 felé kell a csomagot továbbítania. R1-ből viszont 2 virtuális áramkör is kiindul, az egyik R2 (10.0.0.2) felé, a másik R3 (10.0.0.3) felé. Honnan tudja R1, hogy melyik virtuális áramkörön keresztül küldje ki a Frame Relay keretbe ágyazott csomagot? Ne feledjük, az irányítótábla alapján R1 csak azt tudja meghatározni, hogy melyik interfészén küldje ki a csomagot, de azt nem, hogy az interfészhez tartozó melyik virtuális áramkörön.

A forgalomirányítóknak kellene rendelkezniük egy olyan összerendeléssel, amely meghatározza, melyik IP címet, milyen című virtuális áramkörön keresztül éri el. Valahogy így:

• Az R1-ből kiinduló 23-as című virtuális áramkör a 10.0.0.2 IP címhez vezet.
• Az R1-ből kiinduló 36-os című virtuális áramkör a 10.0.0.3 IP címhez vezet.
• Az R2-ből kiinduló 47-es című virtuális áramkör a 10.0.0.1 IP címhez vezet.
• Az R3-ból kiinduló 23-as című virtuális áramkör a 10.0.0.1 IP címhez vezet.

Sőt, meglepő módon forgalomirányítóknak még arra az összerendelésre is szükségük van, hogy a saját IP címüket hogyan érhetik el:

• Az R1-ből kiinduló 23-as című virtuális áramkör a 10.0.0.1 IP címhez vezet.
• Az R1-ből kiinduló 36-os című virtuális áramkör a 10.0.0.1 IP címhez vezet.
• Az R2-ből kiinduló 47-es című virtuális áramkör a 10.0.0.2 IP címhez vezet.
• Az R3-ból kiinduló 23-as című virtuális áramkör a 10.0.0.3 IP címhez vezet.

Ezt az összerendelést a hálózat vagy automatikusan előállítja, vagy megtehetjük mi magunk is statikusan.

Az inverz ARP protokoll

Ahogyan azt említettük, a DLCI-IP cím összerendelésnek van egy automatikus formája is, amely alapértelmezetten be van kapcsolva. Ennek a módszernek a neve az inverz ARP. Emlékezzünk vissza, amikor az Ethernet hálózatban egy adott IP című eszközt el akartunk érni, meg kellett határozni az eszköz MAC címét. Vagyis az IP címhez (3. rétegbeli címhez) kerestük a MAC címet (2. rétegbeli címet). Jelen esetben viszont fordítva kell eljárnunk: Megvan a virtuális áramkör DLCI címe (2. rétegbeli cím), és meg kell keresni hozzá az IP címet (3. rétegbeli cím). Vagyis az előző ARP folyamat fordítottját, inverzét kell végrehajtani.

A protokoll nagyon egyszerűen működik. R1 kiküld egy-egy üzenetet mindegyik virtuális áramkörén, melyben szerepelteti a saját IP címét. Ezt az üzenetet megkapják a virtuális áramkörök másik végén lévő forgalomirányítók, és megválaszolják a saját IP címükkel. Közben persze megjegyzik R1 IP címét is. A folyamatot így lehetne leírni R1 és R2 között:

• R1: Kiküldök a 23-as című VC-n egy üzenetet, benne az IP címem, 10.0.0.1
• R2: Kaptam egy üzenetet a 47-es című VC-men keresztül a 10.0.0.1 címmel, tehát megjegyzem, hogy a 47-es DLCI-hez a 10.0.0.1 IP cím tartozik.
• R2: Küldök válaszként a 47-es című VC-men keresztül egy üzenetet, benne a 10.0.0.2 IP címemmel.
• R1: Kaptam egy üzenetet a 23-as című VC-men keresztül a 10.0.0.2 IP címmel, tehát megjegyzem, hogy a 23-as DLCI-hez a 10.0.0.2 cím tartozik.

És persze ugyanígy R1 és R3 között. Saját magára viszont nem küld inverz ARP üzenetet a forgalomirányító, így a saját IP címéhez tartozó DLCI-t manuálisan kell meghatározni. Alapértelmezetten a forgalomirányítók minden Frame Relay interfészükön 60 másodpercenként kiküldenek egy inverz ARP üzenetet.

Nagyon fontos látni, hogy a DLCI-IP cím összerendelés nem a kalsszikus értelembe vett útvonalválasztás! Az embernek olyan érzése van, hogy ha R2 eléri R1-et, akkor eléri biztos R3-at is, hiszen azonos hálózatban vannak. De ez nem így van! Mivel R2 nem rendelkezik olyan információval, hogyan is kellene R3 IP címét (10.0.0.3) elérni, ezért nem is fogja elérni azt. Ha manuálisan felvesszük, hogy a 10.0.0.3 IP cím is a 47-es című virtuális áramkörön érhető el, akkor viszont már elérheti, hiszen a ping IP csomagját R3 először elküldi R1-nek, amely utána továbbítja R3-nak. (Lévén ismeri a 10.0.0.3 felé vezető VC címét.) Nagyon sokszor a következő ugrás forgalomirányítójának IP címéhez adjuk meg a DLCI-t, így biztosítva Frame Relay hálózatokon keresztül a forgalomirányítás működését.

A Frame Relay kapcsoló és a forgalomirányító kapcsolata

Noha látszólag már egy működő hálózat van előttünk, de szót kell ejtenünk még a Frame Relay kapcsoló és a forgalomirányító kapcsolatáról. Egy Frame Relay hálózatban a kapcsoló nem olyan “átlátszó” a forgalomirányító számára, mint egy Ethernet hálózatban. A Frame Relay kapcsolók biztosítják azt a virtuális áramkört, amit a forgalomirányító használni fog, és erről a virtuális áramkörről tájékoztatást is adnak. (Emlékezzünk vissza, például a DLCI-t automatikusan megküldték a forgalomirányítónak.) Két eszköz kommunikációját pedig minden esetben valamilyen protokoll írja elő. És ha már egyféle protokoll van valamire, akkor lesznek annak is változatai.

A forgalomirányító és a Frame Relay kapcsoló kapcsolatát vezérlő protokollt Local Management Interface-nek (LMI) nevezzük. Ez a protokoll jelzi többek között a forgalomirányító számára egy adott PVC állapotát, illetve ébrentartási (keepalive) üzeneteket küld.

Fontos, hogy az LMI-nek semmi köze a Frame Relay beágyazáshoz. Az LMI üzenetek kizárólag a forgalomirányító és a hozzá kapcsolódó Frame Relay kapcsoló között haladnak, és nem hordoznak semmiféle felhasználói adatot. Természetesen az LMI-nek is többfajta megvalósítása létezik, melyek nem kompatibilisek egymással, vagyis ha a DCE-n beállítottuk az egyiket, akkor ugyanezt kell beállítani a DTE-n is. A virtuális áramkör két végén viszont nyugodtan lehet különböző típusú LMI-ket használni. Fajtái a következők:

• Cisco
• ANSI
• ITU

Az LMI üzenetek a router (DTE) és a Frame Relay kapcsoló (DCE) között mindkét irányban haladnak a következő célból:

• A DCE-k tájékoztatják a DTE-ket a virtuális áramkörök DLCI-iről és azok állapotáról.
• Ébrenléti üzeneteket szállít, melyek használatával a DCE-k és a DTE-k hamar felismerik, ha a hozzáférési összeköttetés nem működik.

Egy PVC négyféle állapotot vehet fel a forgalomirányító szemszögéből. Ebből kettőt (aktív és inaktív) az LMI-ből állapítja meg, a másik kettőt (törölt és statikus) a forgalomirányító határozza meg saját maga. Aktív és inaktív állapot esetén a PVC biztosan definiálva van a Frame Relay hálózatban (csak inaktív esetben nem használható, mert a másik oldal forgalomirányítója nem kezeli), míg törölt állapot esetén biztos, hogy nem. (Vagyis a DLCI a forgalomirányítón hozzá lett rendelve az interfészhez, de a Frame Relay hálózat semmit nem tud róla.) Statikus állapot akkor fordul elő, ha az LMI-t nem engedélyeztük a kapcsoló és a forgalomirányító között, így a forgalomirányító semmiféle információt nem kap a DLCI-k állapotáról. Ilyenkor valamennyi virtuális áramkörét statikusnak jelöli meg.  A forgalomirányító aktív és statikus esetben kiküldi a kereteket, míg inaktív és törölt állapot esetén nem.

A Frame Relay és az üzenetszórás

A Frame Relay nem támogatja a 2. rétegbeli üzenetszórást. A Frame Relay ezen tulajdonsága miatt, és amiatt, hogy eközben viszont több eszköz is elérheti a hálózatot, NBMA hálózatnak is nevezzük: NBMA = Non Broadcast – Multi Access hálózat. Nincsen mód arra, hogy a klasszikus módszerrel egy olyan “üzenetszórási DLCI-t” helyezzünk el a Frame-Relay keretben, melynek felhasználásával a kapcsolók valamennyi virtuális áramkörön kiküldenék a keretet. Így a szórási tartomány fogalmát sem lehet értelmezni.

Üzenetszórás viszont nem csak a 2. rétegben, hanem a 3. rétegben is van, és ennek megvalósítására már van lehetőség, igaz azzal a trükkel, hogy az üzenetszórás egy-egy példányát minden VC-n kiküldi a forgalomirányító. (Ez olyan, minthogy nincsen olyan telefonszám, amelyet felhívva, mindenkinek a telefonja csörögne, viszont mindenkit külön-külön felhívva, eljutatthatjuk mindenkihez a hírt.) A 3. rétegbeli üzenetszórást nem lehet elhagyni, hiszen gondoljunk csak arra, hogy például a különböző útvonalválasztó protokollok 3. rétegbeli üzenetszórási vagy csoportcímekre küldik az információikat.

Amennyiben nagyszámú (több száz) virtuális áramkör is van a hálózatban, akkor ez a módszer is nehezen használható az üzenetek nagy száma miatt, hiszen egy-egy üzenetszóráskor a felhasználói üzenetek jelentős késleltetést szenvednének. Ilyenkor az üzenetszórás üzeneteit beteszik a különböző kimenetek üzenetsoraiba, és így azok között lesznek továbbítva. Az IOS konfigurálható, hogy mekkora sávszélességet foglaljon le az üzenetszórások továbbítására.

A sebesség és a hulladékvezérlés a Frame Relay hálózatban

Frame Relay hálózatokban az ügyfél részére kiépített kapcsolat, vagyis a hozzáférési összeköttetés sebessége (AR, Access Rate) egy maximális felső korlátot határoz meg. A szolgáltató viszont, tisztában léve a hálózatának kapacitásával, ennél kisebb sebességet is vállalhat, ez a vállalt adatsebesség (CR, Comitted Information Rate).

A Frame Relay keretben három bit van fenntartva arra, hogy befolyásolhassuk, mi is történjék a hálózatban a keretekkel. Ezeket a biteket akkor tudjuk leginkább használni, ha egy vagy több hálózat hozzáférési összeköttetése jóval nagyobb órajelet használ, mint amennyi a virtuális áramkör vállalt adatsebessége (CIR).

FECN és BECN bitek

Amennyiben egy forgalomirányító képes lenne több adatot küldeni, mint amennyit a CIR-ben meghatározott (mert például a többi ügyfél éppen nem forgalmaz annyit), az IOS az úgynevezett forgalomformálás (Traffic Shaping) technikáját alkalmazza. Ilyenkor egy időre több adatot küld, majd vár, utána megint küld, utána megint vár, és így tovább. A forgalomformálás lehetővé teszi, hogy a router átlagosan a hozzáférési összeköttetés sebességénél kisebb sebességgel, a virtuális áramkör CIR-jének megfelelően küldje az adatokat. Vegyünk egy példát: A hozzáférési összeköttetés T1 sebességű, de a CIR csak 128kbps. A szolgáltató képes úgy konfigurálni a forgalom formálást, hogy átlagosan csak 256kbps adatforgalmat engedélyezzen. Ilyenkor megakadályozza, hogy a forgalom a T1 sebesség közelébe nőjön, ami jelen esetben 12-szerese lenne a CIR-nek. De ha a forgalom eléri átlagosan a 256kbps-t, akkor már nem csökkenti a forgalmat, tehát megengedi a CIR 2-szeresét.

A forgalom formálást lehet egyetlen sebességre is konfigurálni, és lehet arra, hogy két érték között tartsa a sebességet. Ha erre az utóbbira van konfigurálva, akkor, ha a hálózat nem túlterhelt, akkor a felső határon tartja a sebességet, ellenkező esetben az alsó határon. Ahhoz, hogy ez a forgalom formázás működjön, a routereknek szükségük van arra, hogy képesek legyenek jelezni a torlódást. Erre szolgálnak a FECN és a BECN bitek. Ezek jelentése az előremutató explicit torlódásjelzés (Forward Explicit Congestion Notification, FECN) és a visszirányú explicit torlódásjelzés (Backward Explicit Congestion Notification, BECN).

A FECN és a BECN bitek a Frame Relay fejlécben találhatók. A router és a Frame Relay hálózatban található más eszközök is be tudják állítani egy keretben, ha torlódást tapasztalnak. A fenti ábrán ezt láthatjuk. Az első lépésben R1 küld egy keretet R2-nek, melyben a FECN és a BECN bitek értéke 0. A Frame Relay kapcsoló érzékeli a torlódást, ezért úgy küldi tovább a keretet, hogy a FECN bit értékét 1-re állítja, jelezve ezzel R2 felé a torlódást. A cél viszont az lenne, hogy R1 fogja vissza a forgalmát. Ezért a Frame Relay a következő R1 felé menő keretben a BECN bitet 1-re állíthatja, jelezve ezzel R1-nek az ellenkező irányban (tehát R1-től R2 felé) a torlódást. R1 attól függően, hogy hogyan van konfigurálva a forgalom formázás, csökkentheti vagy nem a forgalmát.

A Discard Eligibility (DE) bit

Amennyiben a hálózatban torlódás alakul ki, akkor ésszerű azokat a kereteket eldobni, melyek a torlódást okozzák. A szolgáltató a hálózatát úgy konfigurálja, hogy az összes VC-nek biztosított CIR-nek megfelelő sebességeket képes legyen biztosítani. Ha néhány hálózatnak megengedik, hogy a CIR-jüknél nagyobb sebességgel forgalmazhassanak, akkor ezeknek a többlet forgalmából lehet torlódás esetén kereteket eldobni. Az eldobható keretek jelzésére szolgál a figyelmen kívül hagyható (Discard Eligibility, DE) bit.

A Frame Realy protokoll definiálja azokat az eszközöket, melyekkel képes csökkenteni a forgalmat abban az esetben, ha a VC felett a CIR-nél nagyobb sebességű forgalom alakul ki, a megfelelő keretek eldobásával. Az ügyfelek azokban a keretekben, melyek a túlzott forgalom esetén a szolgáltató által eldobhatók, a DE bitet beállítják, a fontos forgalmukhoz tartozó keretekben viszont nem, így biztosítva, hogy a szolgáltató azokat még torlódás esetén is továbbítja. Ezzel elérjük, hogy ha a hálózat nem túlterhelt, akkor nagy mennyiségű extra adatot is képes az ügyfél elküldeni.

Ha érdekelt a cikk, a következő részét itt találod: Frame Relay konfigurálása