Mielôtt rátérnénk az ATM hívásfelépítésre, néhány témát még alaposabban körüljárunk. Ezek egyike az AAL-ek mûködése, valamint az ATM referencia modell részletesebb áttekintése, a másik pedig a hálózat által nyújtott minôségi garanciák és szolgáltatások területe.
Tekintsük át mégegyszer az ATM referencia modellt, ezúttal csak egy síkot tekintve (a felhasználói vagy kontroll síkot), de egy kicsivel részletesebben. Elôször sorra vesszük a felhasználói és kontroll síkokban közös részeket, majd röviden szót ejtünk a két sík eltérô részeirôl is.
Az AAL réteg 3 részbôl áll. Az felsô kettô együttesen alkotja a Convergence Sublayert (CS), melynek feladata, hogy a magasabb szintektôl kapott csomagokat illessze az ATM hálózathoz. A harmadik rész, a SAR Sublayer, amelynek feladata elsôsorban az adó oldalon a csomagok cellákra tördelése, a vevô oldalon pedig a cellákból való összeállítása. A CS két részbôl áll, az alsó az adott AAL-re jellemzô, míg a felsô szolgáltatásonként különbözô. Például az AAL5-höz mind a Frame Relay SSCS, mind pedig az SMDS SSCS definiálásra került, de mindkettô ugyanazt az AAL5 CPCS-t használja. Éppen ezért a CPCS és SAR részeket együttesen AAL CP-nek (közös résznek) szokták nevezni.
Dolgozatunk szempontjából az AAL1, amely fix bitsebességû és az AAL2, amely változó bitsebességû szolgáltatást nyújt, nem igazán lényeges, részletesen csupán az AAL3/4-et és az AAL5-t tárgyaljuk.
Az AAL3 és az AAL4 egyforma közös résszel rendelkezik, ezért az AAL3/4 elnevezés. Az AAL3/4 CPCS a felülrôl kapott csomagot a következô keretbe helyezi.
A CPI (Common Part Indicator) mezô jelzi, hogy a BASize bitben vagy byte-ban mérendô, a BASize jelzi, hogy mekkora pufferre van szüksége a keret összeállításához a vételi oldalon a SAR processznek. A PAD szolgál a teljes keret hosszának 44 byte egész számú többszörösére való kiegészítésére, az AL a keret végén levô információt egészíti ki 32 bitre a könnyebb feldolgozás érdekében. Az Etag és a Btag értéke tetszôleges, de azonosnak kell lennie, ez a vett csomag integritásának leellenôrzésében játszik szerepet, a hossz azonosító pedig az adat hosszát jelöli, hogy a PAD mezôt el lehessen különíteni az értékes adattól.
Az AAL3/4 SAR processz a következôképp osztja cellákba a kapott keretet.
Az ST (Segment Type) azonosítja, hogy a cella egy keret elsô, közbülsô vagy utolsó cellája, illetve, hogy egy cellába beférô keret-e. Az SN (Sequence Number) mezôt az adó sorban növeli az egymást követô cellákban, a vevô pedig vételkor ellenôrzi. A MID (Multiplex Identification) szolgál az egy VC-n párhuzamosan átküldött több keret azonosítására. Minden keret kap egy sorszámot, amit a SAR processz minden hozzá tartozó cellában beír a MID mezôbe. Ez alapján a vevô SAR processz csoportosítani tudja az egy kerethez tartozó cellákat. A LI (Length Indicator) mezô mutatja, hogy a keret utolsó cellája esetén hány értékes byte van a 44 adatbyte-ban, a CRC pedig a teljes cellát védi.
Az alábbi ábrán két csomag feladása látható, a keretekhez tartozó cellák összekeveredhetnek.
Az AAL5 közös része teljesen ugyanazt a funkciót látja el, mint az AAL3/4 közös része nevezetesen csomagok feladása és vétele, csupán sokkal egyszerûbben, de kevésbé megbízhatóan.
Az AAL5 CPCS szintén keretbe helyezi a kapott csomagot. Az UU (Uset-to-User Indication) mezô a felhasználó rendelkezésére áll, az AAL nem módosítja. A CPI egyetlen jelenleg is definiált funkciója, hogy a keret végén levô információt a 32-bit határra igazítsa. A Hossz az Adat hosszát adja meg, hogy a PAD eltávolítható legyen. A CRC az egész keretet védi, mert az egyes cellákba már nem kerül hibaellenôrzô kód.
Az AAL5 SAR cellastruktúrája roppant egyszerû, a 48 byte-nyi adatot teljes egészében a keret darabjai töltik ki. A keret utolsó celláját a cella fejlécében lévô PT (Packet Type) mezô egyik, az AAL részére fönntartott bitje jelzi.
Az AAL5 tehát nem azonosítja az egyes csomagokat, így egy VC-n egyszerre csak egy csomag haladhat, amíg a csomag összes cellája át nem ért, nem kezdhetünk új csomag adásába, hisz semmi sem mutatja, melyik cella melyik csomaghoz tartozik. Az alábbi ábrán az AAL3/4-nél már látott két csomag feladása látható, a második csomag addig vár, míg az elsôt teljes egészében fel nem adtuk.
Mind az AAL3/4, mind az AAL5 közös részének felhasználásával üzemeltethetô a fölöttük levô, a szolgáltatásra jellemzô SSCS rész. A felhasználói síkon eddig igazán két SSCS került definiálásra, az egyik a Frame Relay-hez, a másik az SMDS-hez.
A Frame Relay SSCS feladata a Frame Relay és az ATM QoS paramétereinek egymásnak való megfeleltetése, a DCLI-VC fordítás, a DE bit CLP bitbe való átírása és a Frame Relay forgalomszabályzó bitjeinek a csomagba való elhelyezése.
Az SMDS SSCS eltávolítja az SMDS harmadik rétege által a csomagba helyezett fejlécet és végtagot, amit a saját fejlécével és végtagjával helyettesít. Szintén fontos, hogy az SMDS által használt forgalomellenôrzést az ATM megfelelô algoritmusával (GCRA) szimuláljuk, ezen algoritmusok paramétereinek egymásbafordítását is meg kell oldani. [6]
Ezenkívül létezi még a null SSCS is, amikor közvetlenül a közös rész funkcióit használjuk, nevezetesen nagyméretû csomagok küldését és fogadását. Erre épül például az IP-over-ATM.
A kontroll sík AAL rétege az AAL5 közös részeit használja. Azért az AAL5-re esett a választás, mert a hívásfelépítés üzeneteinél igazából nincsen szükség az egyes csomagok átlapolhatóságára és a bonyolult hibaellenôrzési funkciókra. Ha ugyanis az üzenet hibás aminek kiderítésére elegendô az AAL5 CRC-je, akkor úgyis újra kell küldeni.
A fenti ábrán az UNI kontroll síkjának felépítését láthatjuk. Az alsó két egység az AAL5 közös része. Fölöttük található az SSCOP (Q.2110) rész, ami nagyjából az adatkapcsolati szint LLC alrétegének feladatát látja el, azaz az AAL5 által nyújtott megbízhatatlan kereteket továbbító szolgáltatásra épülve megbízható, sorrendhelyes átvitelt nyújt. Ha egy keret hibásan érkezik át, akkor annak újraküldését kezdeményezi. Meglehetôsen nagy ablakméretet enged meg, tehát igen sok keret mehet el nyugtázatlanul, az újraküldési mechanizmus éppen ezért a szokásostól eltérôen nem küldi újra a hibás keret óta feladott összes keretet (Go-Back újraküldés), hanem csupán a hibásat (szelektív újraküldés). Ezen kívül az SSCOP periodikus üzenetek küldésével jelzi, hogy a szomszédos entitás még életben van és a fent vázolt, a TCP-hez hasonló, megbízható adatküldés mellett az UDP-hez hasonló megbízhatatlan adatküldési szolgáltatást is nyújt. Az SSCOP állapotgép sokféle funkciója miatt meglehetôsen összetett, a nyújtott szolgáltatások is meglehetôsen bonyolultak.
Az SSCF alréteg(Q.2130 az UNI-ban és Q.2140 az NNI-ben) feladata elsôsorban az alatta elterülô rétegektôl függetlenül megbízható és megbízhatatlan adatátviteli szolgáltatások nyújtása. Ez az SSCOP összetett szolgáltatásaival könnyen megvalósítható, az SSCF mindössze egy egyszerûbb interface-t nyújt, mint az SSCOP. [6]
A felsô réteg az UNI esetében a DSS2 jelzésrendszer, melyet nemsokára részletesebben is szemügyre veszünk.
Az NNI kontroll sík felépítése hasonló, az SSCF kissé módosított verziójával és teljesen más felsô rétegekkel. A magán NNI (PNNI) interface mûködésérôl szintén nemsokára bôvebben írunk.
Ezeknek a felsô rétegeknek a feladata a hívások felépítése, karbantartása és lebontása. A hívásfelépítés az ATM-ben meglehetôsen bonyolult feladat a hálózat igen sokféle szolgáltatása miatt. Errôl szólnak a következô részek.
Az ATM hálózat a kapcsolat kiépítésekor számos paraméterben állapodik meg a hívó féllel. A hívó közli igényeit a hálózattal, amely annak függvényében, hogy vállalja-e az adott minôségi paraméterekkel rendelkezô kapcsolat kiépítését, elfogadja vagy elutasítja a hívást. Például, ha a megadott állomás felé már nem áll rendelkezésre a szükséges sávszélesség, a hálózat informálja a hívót, hogy ilyen nagy átviteli kapacitású kapcsolatot nem garantál. Ha a hálózat viszont vállalja az adott forgalom továbbítását, a kapcsolat kiépül. Ez a híváskor megkötött szerzôdés (trafic contract), melyben a hívó lerögzíti, hogy milyen forgalmat generál, a hálózat pedig azt, hogy ezt milyen minôséggel viszi át. A hívást egyébként a hívott fél is elutasíthatja.
A hálózat a szerzôdésben rögzített paraméterek által leírt forgalmat be is tarttatja, tehát ha például az elôírt sebességnél gyorsabban jönnek a cellák, akkor a megállapodáson felüli cellákat nonkonformnak jelöli meg (a CLP bit 1-re állításával) vagy esetleg nem is továbbítja. Ha egy kapcsolat hosszútávon nem tartja be szerzôdésben leírt, a forgalomra vonatkozó vállalásait, a hálózat kezdeményezheti a kapcsolat bontását. [12]
A forgalom karakterizálására és a konformitás ellenôrzésére az UNI specifikációban a Generic Cell Rate Algorithm (GCRA) algoritmust definiálták, mely a „lukas vödör" analógiájával példázható.
Adott egy vödör, melyen pontosan akkora luk található, hogy belôle egy csészényi víz egy idôegység alatt folyik ki. A vödör mérete M csészényi. Minden beérkezô cella hatására T csészényi vizet öntünk a vödörbe, ha van még annyi hely benne. Ez azt jelenti, hogy egy cella hatása a vödörbôl T idô alatt tûnik el. Ha a vödör már annyira tele van, hogy a cella hatására beletöltött víz már kicsordulna, akkor a cellát nonkonformnak jelöljük és a vizet nem öntjük a vödörbe. Azt mondhatjuk tehát, hogy a celláknak nagy általánosságban T idôközönként kell jönniük, hiszen ilyen tempóban folyik ki a vödörbôl a víz. A vödör mérete azonban megenged eltéréseket ettôl a követési távolságtól, nevezetesen ha egy cella túl hamar érkezik, attól még beleférhet a vödörbe, de ha túl sok cella érkezik igen gyorsan egymás után, akkor a vödör megtelik és számos cellát nonkonformnak fogunk jelölni.
Ha a vödör mérete pontosan T csésze, akkor a cellák szigorúan T idôközönként (vagy ritkábban) jöhetnek, mert ha nem telt még el az elôzô cella óra T idô, a vödör nem üres és nem fér bele még T csésze víz. A cellák összes késleltetésingadozása tehát akkora lehet, amennyivel nagyobb a vödör mérete T-nél, legyen ez .
Egy állandó bitsebességû (Constant Bit Rate, CBR) kapcsolat jól illeszthetô a fenti példára. A cellák jólfésülten, egyenletesen, T idôközönként érkeznek és továbbítódnak. A hálózat nem tökéletes volta miatt azonban némi ingadozás bekövetkezhet, de ezt egy meglehetôsen kisméretû pufferrel el lehet simítani, a CBR forgalom tehát kis vödörmérettel írható le. A PCR (Peak Cell Rate) paraméter írja le a cellafolyam adatsebességét cella/s-ban (végeredményben ez a T reciproka), míg a CDVT (Cell Delay Variation Tolerance) pedig a , a plusz vödörméret, a tartalék.
Nem minden forgalom ilyen jól kezelhetô. A számítógépes adatok (például egy file server-rel való kommunikáció) többnyire nagy sebességet igénylô löketekben jelentkezik, a löketek között pedig hosszú a csend. Minthogy a PCR mint nevébôl is adódik a legnagyobb adatsebességet, másképp fogalmazva a cellák közötti legkisebb idôtartamot határozza meg, ilyen VBR forgalom esetén ezt az értéket a löketek sebességére kellene állítani, ami roppant gazdaságtalan volna, hiszen elmennénk a mellett a tény mellett, hogy az idô nagy részében ennél kisebb, sôt akár semmi forgalom nincs.
Emiatt a VBR forgalom jobb jellemzésére használhatjuk még az SCR (Sustainable Cell Rate) és a BT (Burst Tolerance) paramétereket. Az SCR a kapcsolat átlagos adatsebességét írja le, a BT pedig a hozzá tartozó vödörméretet. Ilyenkor tehát a GCRA nem a PCR és CDVT paraméterekkel ellenôrzi a forgalmat, hanem az SCR és a BT paraméterekkel, melyek az átlagos sebességre vonatkoznak, a PCR pedig a löketek maximális sebességét hivatott specifikálni. Tehát a PCR mindig nagyobb, mint az SCR, ha ugyanis egyenlôek, akkor a forgalmat nem sikerült jobban jellemezni, mintha csak a PCR, CDVT párost adtuk volna meg.
A PCR, SCR és BT paraméterekbôl kiszámolható a PCR sebességen leadható maximális löket mérete (Maximum Burst Size, MBS).
Ahol s a BT, Ts pedig az SCR reciproka, amint T a PCR reciproka. A zárójel alsó egészrészt jelöl.
Ha ugyanis üres vödörrel indulunk a löket elején, akkor a vödörbe önthetô víz mennyisége:
Hiszen a löket alatt MBS darab cella érkezik, ezek mindegyike Ts csészényi vizet önt a vödörbe. A löket lezajlása alatt azonban a vödörbôl a víz ki is folyik, méghozzá annyi csészényi, amennyi ideig a löket tartott (Tb). Ennyivel tehát kisebb vödörméret is elég, ez a különbség látható a bal oldalon, a jobb oldalon pedig a vödör mérete. Ebbôl az MBS-re vonatkozó fenti összefüggés adódik.
Természetesen ezek a löketek nem követhetik akármilyen sûrûn egymást, meg kell várni, míg a vödör újra kiürül. Egy újabb maximális méretû löket érkezése elôtt
idônek kell eltelnie.
A hálózat tehát a fent említett 4 paraméterrel írja le a forgalmat.
További paraméterek specifikálják a megadott folyamnak nyújtott minôséget. Ezek a QoS paraméterek a következôk:
Az ATM által nyújtott eredetileg 4 szolgáltatási
osztály mára hatra bôvült.
|
|
|
|
|
|||
|
|
|
|
|
|
||
| Típus |
|
|
||||
| Idôzítés |
|
|
|
|||
| Cellaveszteség |
|
|
|
|||
| PCR & CDVT |
|
|
||||
| SCR & BT |
|
|
|
|||
| CTD & CDV |
|
|
|
|||
| Forgalomszabályozás |
|
|
|
|||
| AAL |
|
|
|
|
|
|
A fenti táblázat felsô sorában láthatók a szolgáltatási osztályok. Ezek a következôk:
Az UNI 3.1 használata esetén három osztály áll rendelkezésünkre. Az A (CBR, idôzítésérzékeny forgalom), a C (VBR, nem idôzítésérzékeny) és az X, ahol a paramétereket a felhasználó állíthatja össze. [12]
Az ITU-T már nagyon régen letette voksát az E.164 címrendszernek a nyilvános B-ISDN hálózatokban való használata mellett. Az E.164 címek nagyjából a mai telefonszámoknak felelnek meg, ahhoz hasonló hierarchiával (ország, körzet, központ, elôfizetô). Minthogy az E.164 címtér egy nyilvános (emiatt drága) erôforrás, magán ATM hálózatokban nem célszerû használatuk. Az ATM Forum éppen ezért az UNI 3.0/3.1 specifikációjában az OSI NSAP formátumú címstruktúráját használta fel a magán hálózatokban való címzésre. Bár az így NSAP címekkel megcímzett pontok nem a hálózati réteg szolgálatelérési pontjai (Network Service Access Point), amire az OSI NSAP címeket szabványosították, így az NSAP cím elnevezés pongyola, mégis széles körben használatos.
Az NSAP címek 20 byte hosszúak, az ATM Forum háromféle változatukat definiálta [6] [12] [11].
Az AFI (Authority and Format Identifier) határozza meg az IDI (Initial Domain Identifier) mezô formátumát és típusát; az IDI, mely a címkiosztást és az adminisztrációs hatóságot azonosítja; a DSP (Domain Specific Part), amely az aktuális címinformációt tartalmazza és a SEL (Selector), amely a végponton belül azonosít egyes entitásokat. A három címformátum az IDP (Initial Domain Part) formátumában tér el egymástól:
A DSP részt az OSI 3 részre osztotta fel, a routing domain (RD), a terület (vö OSI routing) és az ESI (End System Identifier) részekre. Az ESI tulajdonképpen egy 48 bites MAC cím, amint az az IEEE LAN-okban megszokott és a végberendezést azonosítja. Az RD és a terület lenne hivatott a route-olást segíteni, ám ezeket a mezôket az ATM Forum egyetlen HO-DSP (High Order DSP) mezôben egyesítette. A HO-DSP-n belül nincs megkötve, hogy hány hierarchia szintet használunk és azoknak hol van a határa. A HO-DSP tehát a hálózatnak a CIDR-hez hasonló fix hierarchiától mentes felosztását teszi lehetôvé.
Az UNI-ban a felek megjelölésére egy cím és egy opcionális alcím használatos. Ennek segítségével két, a nyilvános ATM hálózaton át összekötött magán ATM hálózat végberendezései azonosítani tudják egymást. A cím tartalmazza a másik magán hálózat nyilvános E.164 címét, míg az alcím a magán hálózaton belüli NSAP címet. Az összekötô VC így észrevétlenül keresztülhaladhat a nyilvános hálózaton.
Az UNI 3.1 Specifikáció [12] néhány kisebb hiba kijavításán kívül abban különbözik, a korábbi, UNI 3.0-tól, hogy míg az adatkapcsolati réteg feladatait (a jelzésrendszer üzeneteinek hibamentes továbbítását) a Q.2100 (másnéven Q.SAAL) protokoll segítségével bonyolította le, addig az UNI 3.1 már az ITU-T új, Q.2110 (másnéven SSCOP) protokollját használja, hogy a két szabvány minél több ponton egyezzen. Ugyan a 3.0 és a 3.1 között funkcionális eltérés szinte nincs, az adatkapcsolati réteg különbözôsége miatt mégsem kompaibilisek.
A jelzésrendszer üzenetei a végberendezés és a hálózat között a VPI=0, VCI=5 csatornán folynak. A hívásfelépítés a telekommunikációban (telefónia) megszokott egymenetes modellt követi, tehát a hívó közli a hálózattal, hogy kivel és milyen minôségi paraméterekkel kíván egy VC-t létrehozni. Ez az üzenet a hálózat kapcsolóinak során halad át, a hálózat mindenütt elbírálja, hogy ekkora szabad kapacitás van-e még (admission control), és ha igen, tovább adja a kérést. Mire a kérés elér a hívott félhez a kapcsolathoz tartozó erôforrások a hálózatban már le vannak foglalva. A hívott fél vagy elfogadja vagy elutasítja a hívást, a megfelelô üzenet visszafele végighalad a hálózaton. Elutasítás esetén az erôforrások felszabadulnak, elfogadás esetén pedig az üzenetnek a hívóhoz való megérkezése után megindulhat az adatforgalom.
Az egymenetesség miatt korlátozott lehetôség van a kapcsolat (minôségi) paramétereinek a hívó és a hívott közötti egyeztetésre. Ez ugyanis változtathat a szükséges erôforrások mennyiségén, ami a kapcsolat útvonalát is módosíthatja, erre pedig nincs lehetôség.
A jelzésrendszer a Q.2931 számos részét elhagyta és bôvítéseket is tartalmaz, új minôségi paramétereket, az NSAP címeket és a pont-multipont kapcsolatok kiépítését. Ez utóbbi úgy zajlik, hogy a hívó kiépít egy pont-pont kapcsolatot, majd a többi hívottat sorban hozzáadja a kapcsolathoz. Az ilyen kapcsolatok egyirányúak, azaz a vissza-irányú sebesség 0 kell legyen. A hívottak saját hatáskörben elhagyhatják a kapcsolatot, de nem csatlakozhatnak hozzá, csak a hívó adhatja ôket újra a kapcsolathoz.
A jelzésrendszer alapjai az üzenetek. Az UNI 3.1 15 üzenetet definiál, az elsô 10 a Q.2931-ben is szerepel, az ottani 31 üzenet részeként [9]. Minden egyes üzenet számos információs elemet tartalmazhat, melyek némelyike kötelezô, némelyike opcionális. Ezek az információs elemek (IE) tartalmazzák az adott üzenet részleteit.
Az UNI 3.1 ezenfelül definiál egy sor management funkciót is, például a címek automatikus kiosztását, mikor a cím nem a végberendezés, hanem sokkal inkább az ATM kapcsoló portjának tulajdonsága. A végberendezés csatlakoztatásakor a kapcsoló közli a végberendezéssel annak címét. Hasonlóképp egy végberendezés több címmel is rendelkezhet, például átszámozások esetén hasznos tulajdonság ez. A címmanagement minden a CIDR fejezetben fölmerült kérdése itt is aktuális.
Az UNI 3.1 1994 szeptemberében jelent meg. Az azóta eltelt mintegy másfél évben számos bôvítési irány körvonalazódott. Ezeket az UNI 4.0 specifikációban készíti el az ATM Forum, melynek megjelenése várható. Néhány tervezett funkció [11]:
A PNNI két részbôl áll. Az egyik az UNI funkciójához hasonlóan egy jelzésrendszeri rész, melyen a különbözô üzeneteket adják-veszik a kapcsolók. Ez a jelzésrendszer az UNI jelzésrendszerére épül és szintén az SSCOP-ot használja megbízható adatátvitelre. Természetesen számos új információs elemmel bôvül az UNI verzióhoz képest, a szükséges többletinformáció átvitele érdekében. A PNNI másik része maga a routing, azaz útvonalkeresés. Bár az ATM kapcsolatorientált, paradox módon mégis szükség van egy a datagram jellegû hálózatokban megszokott route-oláshoz hasonló mûveletre a kapcsolat felépítésekor, hiszen ilyenkor még nincs semmiféle kiépült útvonal, amit a jelzés követhetne. Az ATM routing ilyen módon számos hasonlóságot mutat az eddig tárgyalt routing protokollokkal, azonban a PNNI minden eddiginél összetettebb. Egyrészt a skálázhatóság követelménye, másrészt pedig a QOS támogatás miatt.
Minden kapcsoló, melyen a hívás áthalad leellenôrzi, hogy képes-e egy ilyen minôségû kapcsolatot kiszolgálni (van-e elég sávszélesség vagy szabad pufferterület, stb.). Ezt hívjuk admission control-nak. Minden kapcsolóban implementálásra kerül egy Connection Admission Control (CAC) függvény, amely a kapott QOS paraméterek alapján dönt. A PNNI feladata, hogy olyan irányba küldje a hívást, amerre várhatóan nagy eséllyel minden kapcsoló képes elfogadni a hívást. Ha ez mégsem sikerülne és egy kapcsoló visszautasítaná a hívást, akkor az egy ideig visszafele halad, útja mentén felszabadítva az erôforrásokat és egy ponton más irányban újra megpróbál eljutni a hívott félhez. Ez tulajdonképpen egy hagyományos visszalépéses (backtrack) algoritmus, a PNNI specifikáció Cranckback néven említi.
A PNNI leginkább a link-state protokollokhoz hasonlít; minden kapcsoló információkat tárol a hálózat topológiájáról. Ez azonban nemcsak a link-ek, hanem a kapcsolók adatait is tartalmazza, minthogy ez is befolyásolhatja a rendelkezésre álló erôforrásokat. Az adatok pedig olyan minôségi paramétereket is tartalmaznak, mint maximális késleltetés, késleltetésingadozás, cellaveszteség, sávszélesség, stb. Ezeket az információkat PTSP (PNNI Topology State Packet) csomagok formájában terjesztik a kapcsolók egymás között. Így minden kapcsoló áttekintô képpel rendelkezik a hálózat képességeirôl és éppen aktuális terheltségérôl.
A PNNI egy source routing protokoll, azaz a hívást a végberendezéstôl fogadó router határozza meg a teljes útvonalat. Ez azért van így, mert nagyon nehéz lenne a QOS paraméterek figyelembevétele, ha nem egy központi helyen, hanem elosztott módon történne az útvonal meghatározása, viszont az útvonal leírása nem minden adatcsomagot terhel meg, csupán a hívásfelépítést.
Minthogy a PNNI-nek a PTSP-kben terjesztett információkból meg kell becsülnie, hogy mely kapcsolók vállalnák el a hívást, szükség van egy általános CAC függvényre, amivel a kezdô kapcsoló modellezheti egy távoli kapcsoló viselkedését. A CAC ugyanis erôteljesen függ a kapcsoló belsô felépítésétôl és gyártóspecifikus. A PNNI-ben specifikált Generic CAC (GCAC) jó közelítését adja az értelmes CAC függvényeknek.
Ezután maga a hívásfelépítés a következôképpen zajlik.
A hívó kapcsoló a topológiai adatbázisból ideiglenesen törli azokat a kapcsolókat és link-eket, melyekrôl a GCAC azt állítja, hogy nem bírnák el a kapcsolatot. A megmaradt gráfon elvégezzük a legrövidebb utak kiszámítását. A kapott utak közül további lehetôségeket zárunk ki, melyek egyéb paramétereikben (késleltetés, vagy más) nem felelnek meg nekünk. A megmaradt utak közül pedig egyet kiválasztunk, több egyforma út esetén esetleg megoszthatjuk a forgalmat. Az így kapott út alapján elkészítjük a DTL-t (Designated Transit List), amely az útvonal tételes leírása, elhelyezzük a SETUP üzenetben és útjára bocsájtjuk.
Természetesen minden kapcsoló helyi szinten a saját CAC függvényével leellenôrzi, hogy a hívást valóban képes-e vállalni. A hálózat állapota ugyanis idôközben megváltozhatott, a PTSP-ben terjesztett adatoknál sokkal pontosabb helyi adatok állhatnak rendelkezésre és a GCAC sem tökéletesen mintázza az adott kapcsoló CAC-át. A végsô szót mindig maga a kapcsoló mondja ki.
A kezdô kapcsoló tehát mindössze egy jó utat próbál tippelni, nem pedig pontos és precíz útmeghatározást végez, erre kísérletet sem tesz. A legrövidebb út kifejezés nem pontosan definiált egy ilyen sokrétû minôségi paramétereket terjesztô hálózat esetén, mint az ATM. Ezen felül az információk aggregálása miatt a pontosság tovább csökken. (Hamarosan megvizsgáljuk, hogyan aggregál a PNNI.)
Mint láttuk az OSPF-nél, egy link-state protokoll nem szolgálhat ki korlátlan méretû hálózatokat, a topológiai adatbázis nem lehet akármekkora. A PNNI viszont a QOS támogatás mellett a skálázhatóság követelményét is maga elé tûzte, így nagy ATM hálózatokban is mûködnie kell. Ezt hierarchia szintek bevezetésével oldották meg. Az ATM címek HO-DSP mezôje meglehetôsen nagy és számos hierarchia szintet (maximum 105) tesz lehetôvé. Természetesen valószínûtlen, hogy egy tucatnál többre lenne szükség. A hierarchia szintek száma és az egyes szintekre kiosztott címbitek száma teljesen rugalmasan változhat, mint a CIDR esetén.
Egy PNNI hierarchia szint logikai állomásokból áll logikai link-ekkel összekapcsolva. A legalsó szinten ezek a logikai kapcsolók és link-ek maguk a fizikai kapcsolók és fizikai link-ek, minden kapcsoló saját NSAP címmel rendelkezik. Minden hierarchia szinten a logikai kapcsolók csoportokat alkotnak (peer groups). Az egy csoportban levô kapcsolók topológiai adatbázisa megegyezik és a csoport teljes topológiáját tartalmazza, mint egy OSPF terület. Minden csoport a hierarchia egyel magasabb szintjén egy logikai kapcsoló. A második szinten tehát az elsô szint csoportjai a logikai kapcsolók.
Fontos megértenünk, hogy a magasabb szinteken levô kapcsolók nem fizikai berendezések, hanem az egyel lejjebb lévô szintek csoportjai. Tehát ha a 2. szinten lévô B csoport 2 logikai kapcsolója üzenetet vált, akkor valójában az elsô szinten lévô 2 csoport egésze vált üzenetet. Minthogy ennek megvalósítása meglehetôsen sajátos lenne, így minden csoport választ magának egy vezetetôt, PGL-t (Peer Group Leader), az OSPF megbízott router-éhez hasonlóan. A csoportvezetôk az ábrán vastag vonallal jelöltek. A csoportvezetôk képviselik majd csoportjukat az egyel magasabb szinten, ezt a képviselési relációt jelzik a vastag vonalak a szintek között. Minthogy a 2. szinten a B csoport vezetôje az 1. szintû 3. csoport, így a 3. csoport vezetôje nem csupán az 1. csoportot képviseli a 2. szinten, hanem a B csoportot is a 3. szinten.
A csoportvezetôk feladata, hogy a csoportjuk topológiai adatbázisát összefoglalják és elkészítsék az egyel magasabb szinten az egész csoportot jelképezô PTSP-ket. Tehát a 2.a. kapcsoló összefoglalja az egész 2. csoportot jellemzô információkat, mondhatni a csoport áteresztô képességét. Ezeket terjeszti 2. szintbeli társainak, az 1.c és a 3.b kapcsolóknak. A 2. szint logikai kapcsolói között teljesen azonos topológiai adatbázis alakul ki a 2. szint B csoportjáról, tehát mind az 1.a, 2.a és 3.b kapcsolók ismerik mind a 3 csoport összegzett tulajdonságait és saját csoportjuk részletes információit. A csoportok összegzett információit a 2. szint választott csoportja nevében a 3. logikai kapcsoló (3.b) összegzi a 3. szint felé.
Az információk összegzése a link-ekre is vonatkozik, tehát az 1. és 2. csoport közötti 2 link a 2. szinten már egy aggregált link-ként jelenik meg, és az is látszik, hogy az 1. és 3. csoport között nincs közvetlen összeköttetés.
A két logikai kapcsoló közötti link-et virtuális link-nek nevezzük. Tehát a 2. szinten az 1. és 2. logikai kapcsoló a PTSP-ket egy virtuális link-en keresztül cseréli ki. Ez leggyakrabban egy VP (Virtual Path) a két csoportot képviselô csoportvezetô (esetünkben 1.a és 2.a között).
Az NNI jelzésrendszer üzenetei a VCI=5 csatornán mennek, hasonlóan az UNI-hoz, a VPI érték 0, ha a két kapcsolót fizikai link köti össze és más, ha virtuális. A PTSP-k és a Hello csomagok adása-vétele a VCI=18 csatornán folyik, a VPI érték hasonló.
A PNNI a szomszédok és a link-ek földerítését a többi routing protokollhoz hasonló módon egy Hello protokoll segítségével végzi. A Hello és PTSP csomagokat periodikus rendszerességgel adják egymásnak a kapcsolók. A PTSP-k ezenkívül valami lényeges változás esetén is elküldésre kerülnek (lényegi változás a terheltségben, link hiba, stb.). A PTSP-k terjesztése teljesen az OSPF-ben leírtakhoz hasonlóan történik beleértve az idôbélyegeket, sorszámokat, újraküldést és a CRC ellenôrzést (tehát nem az SSCOP biztosítja a hibamentes átvitelt).
A hierarchia minden egyes szintjén a címek is aggregálásra kerülnek egyre rövidebb prefixekké. A legalsó szinten a kapcsoló a hozzá csatlakoztatott állomások címébôl csak az ESI részt vágja le (az egy kapcsolóhoz csatlakoztatott állomások HO-DSP címmezôje azonos). A magasabb szinteken a prefix egyre rövidebb lesz. Természetesen ez feltételezi, hogy a csoportok és a címek kiosztása összhangban van.
Ha két szomszédos kapcsoló elôször kommunikál egymással, megnézik, hogy egy csoportban vannak-e (a prefixek alapján) és ha igen, nekilátnak a topológiai adatbázisuk szinkronizálásának. A szinkronizációba beleértendô a csoportvezetô megválasztása is, ha még nem lenne. A csoportvezetôk szintén kiépítik egymás között a virtuális link-eket és felveszik egymással a kapcsolatot, szinkronizálják topológiai adatbázisukat és csoportvezetôt választanak, aki elkezdi a szomszédos csoportok keresését, stb. egészen a legfelsô hierarchia szintig.
A csoportvezetôk saját csoportjukban terjesztik a fölsôbb szintekrôl megismert topológiai információkat, így a hierarchia felépítésével minden kapcsoló a hálózat teljes topológiájának birtokába kerül, legfeljebb a hálózat egyes részei meglehetôsen elnagyolt formában ismeretesek elôtte. Az 1.a kapcsoló ismerni fogja az 1., a B. és a legfelsô csoport topológiáját (tekintsük most a hálózatot 3 szintesnek).
Amikor egy állomás hívás felépítését kezdeményezi, az UNI-n keresztül átadja a szükséges információkat kapcsolójának. Legyen ez példánkban az 1.a. Az adott kapcsoló ekkor megvizsgálja, hogy a célpont melyik csoportban van. Legyen a célpont most a 3.c kapcsoló valamelyik állomása. Az 1.a úgy tapasztalja, hogy a cím HO-DSP mezôje nem egyezik saját prefixével, így a célpont nem az ô állomásai közül valaki. Mitöbb a cím még csoportjának prefixére sem illeszkedik, így a cél-kapcsoló nem az ô csoportjában van. A prefix a B. csoport prefixére már passzol, így a célpont valahol a B. csoportban van. Az 1.a kapcsoló ekkor elkészíti a DTL-t. Elôször a legfelsô érintett hierarchia szinten készíti el az útvonalat, ez esetünkben a 2. szint. Az útvonal:
1., 2., 3.
Minthogy az 1.a ismeri az 1. csoport belsejének topológiáját, választ egy útvonalat az 1. csoporton belül, ezt bele is helyezi az útvonalba az általánosabb „1." megjelölés helyett.
1.a, 1.b, 2., 3.
Ezután elküldi a csomagot, az 1.b kapcsolónak. Az 1.b kapcsoló észleli, hogy az adott hierarchia szinten ô az utolsó eleme a csoportnak, kiveszi az 1.a és 1.b bejegyzéseket a DTL-bôl és átadja a hívást a 2.b kapcsolónak. A 2.b kapcsoló ismeri a 2. csoport belsejét és lecseréli a 2. bejegyzést egy precízebb útvonallal.
2.b., 2.c, 3.
A hívás így a 2.c kapcsolóhoz kerül, aki szintén csoportjának utolsó kapcsolója lévén leveszi a 2.b., 2.c, bejegyzéseket és átadja a csomagot a 3.b-nek. Az részletes útvonalat generál a 3.c -ig:
3.b, 3.d, 3.a, 3.c.
Így a hívás eljut cél-kapcsolójához, ahol UNI hívási üzenetté alakul és eljut a végberendezéshez.
Ha a célpont az A csoportban lett volna és az A csoport felé kizárólag a 3.c kapcsolón keresztül vezetne út, a folyamat hasonló lenne, csupán minden útvonal végén ott lenne az „A." csoport megjelölése. A 3.c kapcsoló átadná a hívást az A csoportbeli szomszédjának, aki kifejtette volna a második szintû útvonalat az A csoportban, úgy, ahogy az 1.a tette itt, a B csoportban.
Ha az úton valamelyik kapcsoló visszautasítja a hívást, az addig a kapcsolóig gördül vissza, amelyik legutoljára módosította a DTL-t, vagyis a csoport elsô kapcsolójáig. Ez a kapcsoló végzi el majd a Crankback-et, új útvonalat keresve saját csoportján belül. Ha új útvonal nem létezne, akkor megállapítja, hogy ez a csoport nem képes átvinni a hívást és visszaadja az egyel magasabb hierarchia csoport elsô eleméig. Ha elôbbi példánkban a 2. csoportban megakad a hívás a 2.c kapcsolónál, elôször a 2.b-hez kerül vissza, aki detektálja, hogy csak a 2.c-n vezet út, így a 2. csoport nem képes a hívás továbbítására. Így a hívás az 1.a-hoz jut vissza, aki ráébred, hogy a 2. szinten elôállított 1., 2., 3. útvonal nem járható és más utat kell keresni a 2. szinten. Minthogy ilyen út nincs, a hívás nem sikerült.
Lévén a csoportok információinak egy logikai kapcsolóban való ábrázolása igen sok információt elrejt, elveszít, az útvonalválasztás korántsem optimális. Az 1.a kapcsolónak például semmiféle lehetôsége nincs, hogy megítélje, hogy melyik link jobb a 2. csoport felé. Ehhez ugyanis a 2. csoport belsejérôl több információt kellene tudni. Éppen ezért a PNNI lehetôvé teszi, hogy csoportokat ne egy logikai kapcsolóvá aggregáljunk, hanem egy csillag alakú úgynevezett komplex kapcsolóvá, amit egy sereg körben elhelyezkedô és egy középen levô pszeudo kapcsoló alkot. A szélsô kapcsolók és a pszeudo kapcsoló között virtuális link-ek futnak. A komplex kapcsoló leírásában minden kapcsoló és minden virtuális link adata szerepel. Így módon könnyebb megítélni, hogy a komplex kapcsoló melyik részéhez érdemes eljuttatni a hívást. Bár más modellekkel talán jobban leírható lenne egy csoport (teljes gráf, feszítôfa), ez a megoldás jól aggregálható és számolható. A PTSP csomagformátuma lehetôvé teszi a késôbbiekben további modellek bevezetését.
A PTSP-k az aggregált címeken, kapcsoló- és linkparamétereken kívül számos más információt is hordoznak, mint például külsô (nem PNNI) utak, aggregálhatatlan címek, csoport- és anycast címek és ezek taglistái. A csoport és anycast címek terjesztési köre behatárolt, a PNNI hierarchia valamilyen szintjéig (például épület, telephely, stb.), így nem a teljes ATM hálózatban teritôdnek szét ezek az alapjában véve aggregálhatatlan adatok.
A PNNI ezenfelül támogatja a puha PVC-kiépítést, azaz, amikor a PNNI mechanizmust PVC kiépítésére használjuk (például a hívott végberendezés nem képes hívásfelépítésre). Ez sokkal egyszerûbb, mint a manuális konfiguráció és a QOS támogatás is jobb.
A PNNI támogatja az UNI 3.1-ben szereplô pont-multipont kapcsolatokat is, minthogy az ADD PARTY mûvelet roppant hasonló egy egyszerû hívásfelépítéshez. A különbség csupán a celladuplázásban és ennek helyeinek meghatározása körül van. Az UNI 4.0 anycast címzése megoldható a PNNI jelenlegi 1. fázisában (Phase 1), melyrôl eddig írtunk, csupán az anycast csoport tagságát kell a PTSP-kben terjeszteni. A csoportcímekre való egylépéses multicast hívásfelépítés azonban egy komplett fa generálását vonná maga után, amit az ATM Forum a PNNI 2. fázisának hatáskörébe utalt.