Ebben a részben az ATM hálózatok egy másik perspektivikus alkalmazását vizsgáljuk meg, nevezetesen egy hálózati protokollnak az ATM fölött való mûködtetését. A választott hálózati protokoll természetesen az IP. A bevezetôben említett okok mellett azért, mert eddig csupán az IP ATM fölötti mûködésérôl látott napvilágot számottevô elképzelés. Ez javarészt annak köszönhetô, hogy az IP nyilvános protokoll, míg az IPX, DECNet, AppleTalk, XNS, VINES, mindegyike egy-egy gyártóhoz kapcsolódik, aki eddig nem fordítottak túl sok figyelmet a kérdésre vagy megoldásaik publikálására.
Az IP és az ATM között meglehetôsen nagy összeférhetetenség van. [17] A két fôbb pont:
Biztos, hogy a továbbiakban is szükség lesz IP route-olásra, hiszen sohasem várható, hogy az IP kizárólag ATM fölött fusson, a különbözô technológiák között pedig csak egy router adhatja át a csomagokat. Az is célszerûnek látszik, hogy az ATM hálózatokon belül is mûködjenek router-ek, hiszen különbözô szervezetek belsô IP hálózatait célszerû elkülöníteni egymástól, még akkor is, ha közöttük közvetlen ATM kapcsolat létesíthetô. Az egész ATM hálózatot tehát fel kell osztani több subnet-re, melyek között router biztosítja az átjárást, dacára annak, hogy közvetlen ATM kapcsolat is létrehozható.
Az IP-over-ATM javaslatok kulcspontjai a következôk:
A becsomagolásra alapvetôen négy megoldás létezik, ezeket a következô részben tárgyaljuk.
A kapcsolatorientáltság kihasználása érdekes kérdés. Van ugyanis egy kapcsolatorientált AAL5-ünk, mely fölött egy datagram jellegû IP-t szeretnénk futtatni, mely fölött azonban gyakran használt a kapcsolatorientált TCP. Vagy megpróbáljuk kiküszöbölni a kapcsolatorientáltságot és a router-ek közötti PVC-ken bonyolítjuk a forgalmat, vagy pedig éppen ellenkezôleg, minden TCP kapcsolathoz külön VC-t hozunk létre.
Természetesen a helyes megoldás valahol e két szélsôség között lehet, de hogy hol és hogyan az egyenlôre még nem látszik. Maga az IP is egyre inkább veszít datagram jellegébôl, s az, hogy mindez hova torkollik majd magában az IP-ben, most még megjósolhatatlan. Így nehéz arra is választ adni, használjuk ki az ATM kapcsolatorientált voltát. Mindenesetre abban mindenki megegyezik, hogy az IP alapszolgáltatását, a megbízhatatlan datagram-továbbítást továbbra is támogatni kell, így az IP-over-ATM megoldásoknak is fel kell készülniük egy-egy datagram célbajuttatásának megoldására, nem elég a TCP- implementálni.
A harmadik kérdés jobb megértéséhez elôbb egy másik kérdést vessünk fel: Mekkora subnet-ekre osztjuk fel az ATM hálózatot? Túl nagy subnet-ek esetén a subnet-eken belüli ARP lehet túl bonyolult, túl kis subnet-ek esetén pedig túl sok router-en vezet át az út, ami fölösleges és lassú lehet. A kérdés ilyen átfogalmazása azonban nem tükrözi a probléma egészét, hiszen ha az ATM hálózatot felosztjuk is subnet-ekre, attól még lehetséges lesz két subnet között közvetlen ATM kapcsolatot kiépíteni. Megengedjük-e ezt, vagy sem? Ha igen, milyen keretek között? És hogyan mûködjön a subnet-en kívüli ARP?
Csak olyan megoldás támogatható, mely képes együttmûködni nem ATM IP hálózatokkal és nem hoz topológiai megkötéseket (például csak egy csatlakozási pont lehet az ATM és nem ATM hálózat vagy az egyes subnet-ek között). A következô öt megoldási javaslat született:
Az ATM Forum és az IETF munkamegállapodása RFC1754 alatt, az IP-over-ATM hívásfelépítési aspektusai pedig RFC1755 alatt kerültek publikálásra. Ezen felül számos internet-draft foglalkozik a kérdéssel.
A kérdéssel elôször az RFC1483 foglalkozott, ahol alapvetôen két módszert ismertettek.
Az egyik az LLC Encapsulation, amikor a csomag elé helyezik el, hogy az adott csomag milyen protokollé. A módszer ugyanazokat a kódokat használja, mint egy IP csomag MAC keretbe (például Ethernet) való becsomagolásakor, tehát ez az LLC által alkalmazott becsomagolási módszer. Elôször egy LLC fejléc (3 byte) jön, ami egy számozatlan keretet jelöl és azt, hogy egy OSI NSAP fejléc következik. Majd egy OUI (Organizationally Uniquoe Identifier), ami a protokollok kódkiosztását végzô szervezetet jelöli (3 byte), a csupa 0 érték azt jelöli, hogy egy az Ethernet típusmezôben használatos érték következik (EtherType). 0x800 jelöli az IP-t, 0x806 az ARP-t, és 0x86DD az IPv6-t. Az overhead tehát 8 byte.
A másik megoldás a VC-alapú encapsulation, amikor minden protokoll számára külön VC-t létesítünk. Ekkor a SETUP üzenet hordozza a protokoll típusát a felsôbb rétegekrôl szóló információs elemben. A protokoll a VC élettartama alatt nem változik, minden AAL5 keret a protokoll egy csomagját hordozza.
Az elsô esetben egy VC fölött több protokoll is mûködhet, ami a hálózat számára erôforrás-takarékos, a protokollok demultiplexálása viszont az AAL fölött történik az AAL-tôl kapott csomag elejének alapján. A második esetben a demultiplexelést az ATM réteg végzi, a VC-k elkülönítésével és minden protokollhoz külön AAL5 processz mûködik.
Két másik becsomagolási módszer is felmerült. [17]
Az elsô a TCP and UDP over Lightweight IP (TULIP), amelyik kapcsolatfelvétel után már az IP csomag fejlécét se viszi át. Minden a fejlécben tárolt információt kapcsolatfelvételkor küld át a másik félnek, a csomag hossza pedig az AAL5-bôl kiderül. A TULIP nem érinti az IP modellt, címek és csomagok szerepelnek továbbra is, csupán a csomag átküldésekor megspórolunk egy csomó adatot.
A második a TCP and UDP over Nonexistent IP Connection (TUNIC), amelyik teljesen kiküszöböli az IP-t, már IP cím sincs, közvetlenül a TCP és az UDP fut az AAL5 fölött. Természetesen a TCP vagy UDP kapcsolat kiépítéséhez szükséges az IP cím, ám miután kiépült a TCP kapcsolat, a kommunikáció már nem IP, hanem AAL5 csomagokban zajlik. Ez a módszer nem foglalkozik egyedi IP csomagok célbajuttatásával, csak TCP vagy UDP csomagokéval.
Az alábbi táblázat összefoglalja és összehasonlítja a leírt módszereket. [17]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Az encapsulation problémakörébe tartozik a maximális csomagméret (MTU) meghatározása is. Erre az ATM Forum alaphelyzetnek 9180 byte-ot javasolt, mint az SMDS-nél, ám a lehetôséget meghagyta, hogy ez egyezkedéssel akár 64k-ig felmehessen, hisz a nagy csomagméret növelheti a teljesítményt.
A módszerrel elôször az RFC1577 foglalkozott, de javított verziója [18] alatt található, fô különbség az, hogy ez utóbbi megenged több ATMARP servert és definiálja a köztük szükséges szinkronizációs mechanizmusokat.
A klasszikus megoldás lényege, hogy az ATM hálózatot LIS-ekre (Logical IP Subnet) osztjuk fel, melyeken belül közvetlen VC létrehozásával kommunikálnak a berendezések, míg a LIS-en kívülre szóló csomagokat a LIS egy router-ének küldik el és az továbbítja. A megoldás egyetlen igazán kérdéses része tehát az ARP.
A LIS tagjainak IP címe olyan, hogy azok mind egy subnet-be tartoznak (közös prefixük van) és más, a LIS-be nem tartozó állomás nem rendelkezik ilyen IP címmel. Minden LIS-ben egy ATMARP server gondoskodik az ARP bonyolításáról.
Mikor egy állomás bekapcsolódik, felhívja az ATMARP servert egy elôre konfigurált címen. Az ATMARP server ekkor küld neki egy inverz ARP kérelmet, lekérdezve tôle az IP címét, azután az IP cím, ATM cím összerendelést elraktározza táblázatában. Ha egy állomásnak szüksége van egy IP címhez tartozó ATM címre, akkor postáz a servernek egy ATMARP kérelmet, amire az vagy a keresett ATM címmel, vagy elutasító csomaggal válaszol, jelezve, hogy a bejegyzés nincs táblázatában.
Az ATMARP server bejegyzései idôvel kiöregszenek. Vagy a kiöregedô állomás által feladott közönséges ATMARP kérelem hatására frissül fel a bejegyzés (ha egy állomás felad egy ATMARP kérelmet, akkor bizonyosan mûködik), vagy a végleges kiöregedés elôtt a server maga kérdezi le inverz ARP csomaggal az állomás IP címét.
Az ATMARP server meghibásodása, az egész hálózat mûködését megakadályozza, éppen ezért az IETF dolgozik a továbbfejlesztett javaslaton, ahol több ATMARP server létezik, melyek egymás között szinkronizálják ARP adatbázisukat. [18]
Ebben a klasszikus megoldásban minden a LIS-en kívülre szóló csomagnak végig kell haladnia a közbeesô LIS-ek router-ein (mint a hagyományos IP hálózatokban), ami nem teszi lehetôvé a QOS támogatást és nem túl hatékony. Ezekre a problémákra ad megoldást az NHRP.
Az NHRP megtartja az RFC1577 LIS modelljét. Magát a protokollt nem specifikusan az ATM, hanem bármilyen többszörös elérésû, ám nem broadcast jellegû (Non-Broadcast Multiple Access, NBMA) hálózatra tervezték, mint az X.25 vagy az ATM. Mi ATM használatát tételezzük fel.
Az ATMARP server helyett itt NHRP server (NHS) szerepel. Minden LIS-hez egy NHS tartozik. Az NHS-ek táblázatokban tartják nyilván az összes hozzájuk tartozó IP állomás címét és azokat a prefixeket, melyek hozzájuk tartozó állomásokon (router-eken) keresztül a nem ATM Internetben elérhetôk. Az állomások bekapcsolásukkor regisztrálják magukat az NHS-nél, aki ezekbôl az információkból építi fel táblázatát.
Ha egy állomás csomagot kíván küldeni és nem ismeri a cél ATM címét, akkor kérést intéz saját NHS-éhez, aki ha ismeri a választ, megadja a kívánt ATM címet, ha pedig nem ismeri, akkor továbbadja a kérést annak az NHS-nek, akihez a kérdéses célállomás tartozik.
Az NHS-ek két üzemmódban képesek dolgozni. Az elsô esetben minden NHS-ben manuálisan beállítjuk az összes többi NHS-hez tartozó állomások IP címeit. Így ha a hozzá intézett kérdést maga az NHS nem is tudja megválaszolni, akkor is tudja, hogy melyik NHS az illetékes és tôle kérdezi meg. Ez a megoldás elsôsorban kisméretû ATM hálózatokban célszerû.
A másik üzemmódban az NHS-ek egy routing protokollt is futtatnak és ennek segítségével határozzák meg, hogy a keresett célállomás merre található és abba az irányba adják tovább a kérdést. Alapvetôen abból indulnak ki, hogy a célpont felé útba esik a célpontot kiszolgáló NHS is, aki majd képes lesz megmondani az ATM címet. A routing protokoll segítségével tehát a kérelem elhatol a célpontot kiszolgáló NHS-ig, a válasz pedig visszafelé ugyanazon az úton érkezik, így az NHS-ek is eltárolhatják a választ, hogy legközelebb maguk is válaszolhassanak a kérdésre. A visszaérkezett választ a kezdeti NHS aztán eljuttatja a kérdezôhöz. A kérdezô pedig kiépítheti a közvetlen VC-t a célponthoz még akkor is, ha nem ugyanabban a LIS-ben vannak (nem ugyanaz az NHS szolgálja ki ôket).
Az NHS-ek mûködési módja észrevehetetlen az állomások számára, akik csupán kérdeznek és válaszokat kapnak. Az NHRP támogatja „autentikus" kérdések föltevését is, amikre csak annak az NHS-nek válasza elfogadható, akihez a cél tartozik, cache-ben tárolt, másodkézbeli információ nem.
Az ATM hálózat szélén levô NHS-ek kénytelenek az összes az ATM hálózaton kívüli, rajtuk elérhetô állomás prefixét képviselni, így a külsô célpontok felôl érdeklôdô kérdések hozzájuk jutnak el. Ôk saját ATM címükkel válaszolva magukra irányítják ezeket a csomagokat és kifele route-olják ôket. Ugyanez történik akkor is, ha az ATM hálózatot több egymástól elkülönített területre osztjuk fel, melyek között nem megengedettek a közvetlen kapcsolatok. A két terület határán lévô NHS-ek saját címüket adják meg, a csomagokat pedig route-olják. Így lehetôség nyílik a csomagok IP szintû ellenôrzésére, például vállalati tûzfalak (firewall) létrehozására, amiken keresztül csak a jogosultsággal rendelkezô IP forgalom haladhat be és ki. Ez a mechanizmus azonban csak azt biztosítja, hogy az NHRP-n keresztül nem ismerhetô meg a tûzfal túloldalán lévô állomás ATM címe. Ha ezt a címet én valahonnan máshonnan megtudom, nyugodtan létrehozhatok közvetlen VC-t a tûzfal megkerülésével. Éppen emiatt az IP szintû tûzfal mellett szükséges ATM szintû védelem is, hogy a tûzfal mögé csak hitelesített ATM címekrôl lehessen VC-t kiépíteni.
Az NHRP számos opcionális képességgel bír, mint például az útvonal rögzítése, hurkok kivédése, cím-aggregáció, amikor a lekérdezett IP címhez megkapjuk a subnet maszkot is, így az összes abba a LIS-be tartozó állomáshoz üzenhetünk. Számos idôzítô mechanizmus gondoskodik a régi és elavult információk törlésérôl. A specifikáció azt is javasolja, hogy amíg a meglehetôsen lassú kérdés-válasz procedúra lezajlik, az állomás kezdjen el csomagokat adni saját LIS-e egyik router-ének, hogy addig se álljon a forgalom. Ez csak addig van így, amíg ki nem épül a közvetlen VC, onnantól természetesen azon mennek a csomagok. Elôfordulhat, hogy az router-nek utoljára leadott csomag késôbb érkezik meg, mint a közvetlen összeköttetésen az elsô, ami megnehezítheti a vevô dolgát, mert több a sorbarendezési feladat.
Ezt az érdekes javaslatot [20] veti fel. Abból indul ki, hogy a route-olás mindig szükséges funkciója marad az Internetnek, hiszen néhány csomag átviteléhez nem érdemes VC-t kiépíteni, de még a VC kiépülése elôtt elküldött csomagok esetén is hasznos a route-olás. A javaslat által elképzelt berendezés a cellakapcsoló router (CSR) már 1 IP csomag esetén is képes ATM sebességgel kapcsolni.
Ezt úgy érjük el, hogy a CSR, amely egy teljes értékû ATM kapcsoló, két portja között VPI/VCI összerendeléseket nem csupán az AM kontroll sík, hanem az IP szint utasítására is létrehoz. Ehhez az ATM kapcsoló funkciói mellett több, IP-specifikus funkciót is el kell látnia. A kialakított összerendelések valóban ATM sebességûek és lehetôség van QOS támogatásra is. Az ilyen összerendelésekbôl létrehozott útvonalat továbbító csônek (bypass pipe) hívja; ATM szinten ez nem egy virtuális kapcsolat, hanem több, különálló VC összekapcsolásaként adódik. A csövek kiépítésénél egy IP routing protokollt használnánk, melyet maguk a CSR-ek futtatnának, ez határozná meg, mely CSR-ek vegyenek részt a csô kiépítésében. Az ATM route-olás csak a CSR-ek között mûködne, így hatékonyabb hívásfelépítés érhetô el, mint az NHRP által, hisz ott a hívás egyszer IP szinten végigfut az NHS-eken (kérdés formájában), majd vissza, végül az ATM routing építi ki az útvonalat. Mindez a javaslat esetében egy lépésben történne.
Ha egy CSR-hez olyan VPI/VCI kapcsolaton jön IP csomag, melyhez nincs kimenô VC rendelve, akkor összevárja a csomagot és a routing protokollja által szolgáltatott információk alapján egyszerû router-ként továbbítja. A megoldás együttmûködne bármely eddigi IP megoldással és hálózattal, hiszen a route-olás megmarad és könnyen támogathatná az IP erôforrás-lefoglaló protokolljait (RSVP, ST2+, melyekrôl a következô fejezetben lesz szó).
A csövek kiépítését a Bypass Pipe Control Protocol végezné. Alapvetôen két okból dönthet a rendszer csô kiépítése mellett:
A csövek kiépítésére három elképzelés született:
A módszer hátránya, hogy egy ATM kapcsoló ma sem túl egyszerû, vagy olcsó, ha funkcióit egy (multiprotocol) router funkcióival egészítjük ki, talán a világ legösszetettebb hálózati berendezését kapjuk. Másik probléma, hogy az ATM és az IP egybeforrasztásával nehézkéssé válna a két technológia független fejlôdése, mint a peer modellnél. Ez semmiképpen nem kívánatos. Mindenesetre sok munka szükségeltetik még, mire az ötlet teljes értékû, implementációra érett specifikációvá válik.
Az eddig vázolt IP-over-ATM megoldásokból hiányzott a multicast képesség, pedig ez egyre fontosabb lesz az Internetben. A LANE-ben szükséges volt a multicast és broadcast mechanizmusok kidolgozása, hiszen ez a LAN-ok alapvetô tulajdonságaihoz tartozik, az IP esetén azonban nem.
Bár az IP multicast megoldható lenne például a klasszikus IP-over-ATM esetén ugyanúgy, mint az eddigi link-ek fölött, multicast router-ekkel, világos, hogy az ATM felett ez finoman szólva nem hatékony, hisz maga az ATM is nyújt pont-multipont kapcsolatot.
A LANE-hez hasonló megoldást javasol a [21] és [22]. Az ATM hálózatban definiáljuk a Multicast Address Resolution Server-t (MARS). A MARS feladata, hogy a D osztályú címeket ATM címekké fordítsa át. Egy MARS egy területet (cluster) szolgál ki, célszerû egy területet egy LIS-nek választani. A területeket multicast router-ek kötik össze, ez már ATM független. (A következô fejezetben még szó lesz az Internet multicast-ról.) A megoldás tehát csak a cluster-en (LIS-en) belüli multicast-ot érinti, körülbelül azt nyújtva, amit egy Ethernet link nyújt a MAC szintû broadcast lehetôséggel.
Magát a multicast kommunikációt pedig két módon bonyolíthatjuk le.
Az elsô esetben a hálózatban a MARS mellett még létezik egy komponens, a multicast server, amely bizonyos multicast csoportok összes, a területen lévô tagjához kiépített pont-multipont kapcsolattal rendelkezik. Ebben az esetben a MARS a hozzá intézett kérdésre a megadott D osztályú címhez tartozó csoportot kiszolgáló server címét adja meg. Az adni kívánó állomás a server-nek postázza a feladni kívánt csomagot, az pedig a LANE BUS-hoz hasonlóan összevárja és szétteríti a csoportban. Elôfordulhat, hogy a csoport oly kiterjedt, hogy több server szolgálja ki (erre biztonsági okokból is szükség lehet), ekkor a MARS minden server címét megadja, a feladó pedig egy pont-multipont kapcsolaton mindnek postázza a csomagot.
A másik megoldás esetén a MARS közvetlenül a csoport tagjainak ATM címlistáját adja meg, a feladó közvetlenül a tagokhoz épít ki pont-multipont kapcsolatot és zajlik az adatátvitel. Természetesen, ha egy állomás sokszor forgalmaz ugyanarra a D osztályú címre, akkor csak egyszer kell kiépíteni a kapcsolatot.
A második megoldás gyorsabb és nincs szükség a multicast server-re, viszont ha sok állomás ad ugyanarra a csoportra, igen sok pont-multipont kapcsolat épülhet ki ugyanazokhoz a célpontokhoz, ami sok VC és AAL SAR erôforrást köthet le.
A csoportokra való jelentkezés természetesen vagy a MARS-nál, vagy a multicast server-nél történik. A területen lévô multicast router-ek az egész D osztályra jelentkeznek, így az összes multicast csomagot megkapják és továbbíthatják, ha a területen kívül is vannak tagjai a csoportnak. Ha nincsenek multicast server-ek, hanem pont-multipont kapcsolatok hálózatán zajlik a forgalom, akkor N multicast csoport esetén, csoportonként átlagosan M feladóval minden multicast router N*M beérkezô kapcsolatot kell fogadjon, ennyi AAL processz és SAR kapacitás szükséges. Ez minden bizonnyal nagyon sok és fölösleges is. Ha a multicast forgalom nagy része csak a területen belül érdekes, akkor a D címosztályt két részre osztva csökkenthetô a terhelés. Az egyik részen ugyanis azok a csoportok kapnának számot, melyeknek csak lokális forgalma van, a másikon pedig azok, amelyeknek külsô forgalma is. A multicast router-ek ez esetben csak ez utóbbi részre iratkoznának fel, így csak azokat a csomagokat kapnák meg, melyeket tényleg továbbítani kell kifelé.
Természetesen például a klasszikus IP-over-ATM esetén a MARS, a multicast server és az ATMARP server funkciója egy berendezésben egyesíthetô, így különösen kis LIS-ek esetén takarékosan járhatunk el.