ATM -tekniikan hyödyt nähdään eri tahoilla varsin erilaisina. Joillekin se merkitsee uusien sovellusohjelmatyyppien, kuten multimedian ja videosovellusten tuloa, ja toisille vain parempaa suorituskykyä pienemmillä kustannuksilla. ATM:n käyttöönoton kannalta on joka tapauksessa tärkeää, että se saadaan liitettyä nykyisiin jaettua mediaa (shared media) käyttäviin lähiverkkoihin. Nykyisistä lähiverkkosovelluksista ja -protokollista lähes kaikki olettavat, että lähiverkko pystyy kuljettamaan paketit yksilöllisen MAC-osoitteen (Media Access Control) avulla ilman erillistä yhteydenmuodostusvaihetta ja lisäksi kuljettamaan levitysviestityyppiset viestit (broadcast) lähiverkon kaikille asemille tai asemaryhmille erityisen broadcastia tai multicastia tarkoittavan MAC-osoitteen perusteella. ATM-verkko ei tue suoraan näitä vaatimuksia, sillä siirrettävä tieto kulkee virtuaalikanavayhteyttä (VCC, Virtual Channel Connection) pitkin. Virtuaalikanavayhteys on siis muodostettava, ennen kuin datan siirto voidaan aloittaa. Broadcastien ja multicastien käsittely on tästä johtuen huomattavasti monimutkaisempaa. Jotta data saadaan siirtymään kaikille asemille, on niihin jokaiseen ensin luotava yhteys eli oma virtuaalikanava.
ATM Forum, jonka jäsenet ovat laitevalmistajia, operaattoreita ja loppukäyttäjiä, on julkaissut spesifikaationsa koskien rajapintaa, joka liittää yhteen pääteaseman ja LAN/ATM -konversiolaitteet eli reitittimet, keskittimet ja muut verkkolaitteet. Tämä rajapinta tunnetaan nimellä LUNI (LAN Emulation User Network Interface). LUNI -protokollat ovat juuri niitä, jotka mahdollistavat virtuaalikanavien kontrollin ja sitä kautta yhteydettömän lähiverkon emuloinnin. Koko tätä prosessia kutsutaan LAN-emuloinniksi.
Vaikka ATM:n eri kerroksia ei voikaan suoraan verrata ISO OSI-malliin (Open Systems Interconnection), on se silti mahdollista kuvata saman tyylisenä kerrosrakenteena. Voidaan ajatella, että ATM ja LAN-emulointi korvaa OSI-mallin kaksi alinta kerrosta ja osia kolmannesta, koska ATM -kerros pystyy itse huolehtimaan soluvirran reitittämisestä. Itse asiassa on aivan yhdentekevää, mitä kerroksia ATM:n yläpuolella on, sillä ATM ei ota mitään kantaa siirrettävän datan sisältöön. Seuraavassa kuvassa on hahmoteltu LAN emulointia kerrosrakenteen avulla.
LAN-emulointi toimii eräänlaisena konversiokerroksena ATM-sovituskerroksen (AAL5) yläpuolella MAC-tasolla. Sen tehtävänä on peittää ATM:n vaatiman yhteydenmuodostusvaiheen ja kättelyn näkyminen ylempien kerrosten protokollilta ja sovelluksilta. Lisäksi se huolehtii siitä, että ylemmiltä kerroksilta tuleva data siirtyy oikealle virtuaalikanavayhteydelle MAC-osoitteen perusteella. Tämä saa aikaan sen, että ylempien kerrosten protokollat luulevat toimivansa yhteydettömässä verkossa.
Koska ATM-verkon kautta voidaan kuljettaa monen tyyppistä liikennettä, voi sovituskerroksella olla useampia yhtäaikaisesti toimivia sovitusprotokollia. Sovituskerrokseksi on valittu AAL5, jossa bittivirran nopeus voi vaihdella ja synkronointia ei vaadita. AAL5 voi lisäksi toimia joko yhteydellisesti tai yhteydettömästi. Se hyväksyy vaihtelevan kokoiset paketit, jos ne pysyvät välillä 1-65535 oktettia. Lähetettäessä paketti verkkoon, se pilkotaan 48 tavun mittaisiksi lohkoiksi (segmentation), jotka välitetään edelleen ATM-kerrokselle. Mikäli paketti ei ole 48 tavun monikerta, joudutaan siihen lisäämään täytetavuja (padding). Vastaanottopäässä AAL5-sovituskerros kokoaa saapuvat 48 tavun lohkot takaisin MAC -osoitteelliseksi paketiksi (reassembly) ja poistaa mahdollisen täytteen ennen sen luovuttamista ylemmille kerroksille.
ATM-kerros ottaa vastaan sovituskerrokselta kiinteän kokoiset lohkot ja liittää niihin 5 tavun kokoisen otsikon, joka sisältää käytetyn virtuaaliyhteyden tunnistimet (VPI ja VCI). Tämän jälkeen kiinteän kokoinen (53 tavua) solu välitetään fyysiselle kerrokselle, joka huolehtii varsinaisesta siirrosta. Vastaanottopäässä ATM-kerros poistaa otsikon ja siirtää 48 tavun lohkot sovituskerrokselle koottavaksi.
Lopputuloksena voidaan Ethernet- ja Token Ring -kehykset kuljettaa ATM-verkon yli ilman sovelluksiin tehtäviä muutoksia.
LAN-emulointispesifikaatio perustuu client-server -pohjaiseen malliin, jossa ATM-työasemilla ja muilla ATM-verkkolaitteilla on kullekin lähiverkolle määrätyt palvelimet. Emuloitu lähiverkko koostuu LUNI-rajapinnan kautta keskustelevista asiakkaista (LEC, LAN Emulation Client), emulointipalvelimesta (LES, LAN Emulation Server), konfiguraatiopalvelimesta (LECS, LAN Emulation Client Server), levitysviestipalvelimesta (BUS, Broadcast and Unknown Server) sekä esimerkiksi asiakaskeskittimeen (LEC -prosessin sisältävä ATM-keskitin) liitetyistä Ethernet- tai Token Ring -työasemista.
LEC-prosessia ohjaa ohjelmiston ja laitteiston yhdistelmä ja se sijoittuu kiinteästi ATM-verkkolaitteisiin. Sen tehtävänä on ohjata sille saapuva data eteenpäin ja huolehtia osoitteen selvityksestä. Lisäksi sillä on vielä muita kontrollitoimintoja. Jokainen verkon komponentti tukee useampia LANE-asiakasesiintymiä eli sama laite voi olla yhtä aikaa liittyneenä useampiin emuloituihin lähiverkkoihin. Esimerkiksi kaksi emuloitua lähiverkkoa yhdistävä reititin voi sisältää kaksi LEC-prosessia eli yhden molempia lähiverkkoja varten.
LAN-emulointipalvelu sisältää emulointipalvelimen, LESin, konfiguraatiopalvelimen, LECSin ja broadcast -tyyppisten viestien käsittelijän eli BUSin. Palvelun osatekijöiden implementointia ei ole spesifioitu, joten ne voivat sijaita erillisissä laitteissa, ohjelmistona päätelaitteissa tai modulina runkoverkkoon liitetyssä ATM-kytkimessä. Palvelu kuvataan tästä syystä usein pilvenä, joka sisältää palveluun kuuluvat prosessit.
Perinteisissä lähiverkoissa esiintyy erittäin runsaasti multipoint-to-multipoint -tyyppisiä viestejä ja se aiheuttaa ristiriidan niiden ja ATM-tekniikan välille. ATM perustuu vain point-to-point- ja point-to-multipoint -tyyppisiin yhteyksiin. Tämän ongelman ratkaisemiseksi on emulointipalvelimen ja BUSin tehtävä yhteistyötä ja niiden työnjako on seuraava:
* LES käsittelee osoitteen selvityspyynnöt ja pitää rekisteriä MAC-osoitteista ja niitä vastaavista ATM-osoitteista.
* BUS on suunniteltu välittämään levitysviestit. Tyypillisiä levitysviestejä (broadcast) ovat esimerkiksi TCP/IP ARP (Address Resolution Protocol) ja SAP (Novell Service Advertising Protocol). Toimenkuvaan kuuluu myös kaikkien multicast-tyyppisten viestien käsittely ja lisäksi vielä LANE-asiakkailta saapuvien unicast -viestien lähetys sillä aikaa, kun emulointipalvelin luo yhteyttä sen ja asiakkaan välille.
Yhteistoiminnasta johtuen on LES- ja BUS -prosessit sijoitettu yleensä samaan laitteeseen, vaikka LANE 1.0 -spesifikaatio ei sitä erikseen määrääkään. Version 2.0 odotetaan kiinnittävän tämä käytäntö.
Konfiguraatiopalvelimen, LECSin, vastuulla on yhdistää eri asiakkaat oikeisiin emuloituihin lähiverkkoihin. Se antaa asiakkaalle oikean palvelimen osoitteen ja pitää yllä tietokantaa niistä. Yksi konfiguraatiopalvelin voi hallita suurenkin verkkoalueen, sillä sen ei tarvitse osallistua muuten verkon toimintaan.
ATM-verkot koostuvat pääteasemista (end station) ja kytkimistä (switch), jotka on kaikki kytketty yhteen fyysisillä point-to-point -linkeillä. Kytkimissä on useampia portteja yhteyksille pääteasemiin ja toisiin kytkimiin.
Kun asema haluaa kommunikoida toisen aseman kanssa, sen täytyy signaloida sen kytkimen kanssa, johon se on kytketty ja vaatia virtuaalikanavayhteyttä (VCC, Virtual Channel Connection) kohdeasemaan. Tämä tapahtuu signalointiprotokollalla, jonka toiminta on analoginen puhelinyhteyden muodostamisen kanssa. Samoin kuin puhelinverkoissa, ATM kytkimet paikallistavat yhteisvoimin halutun osoitteen mukaisen kohdeaseman ja muodostavat virtuaalikanavayhteyden. Mikäli yhteydenmuodostus onnistuu, saa lähettävä asema ilmoituksen siitä. Samalla se saa tunnistimen, (VCI, Virtual Channel Identifier), joka identifioi sen virtuaalikanavan, johon siirrettävä data lähetetään kohdeasemalle. Seuraavassa kuvassa on kuvattuna ATM-verkon sovelluksille tarjoamat palvelut alkaen yhteydenmuodostuksesta ja päättyen varsinaiseen datasiirtoon.
ATM-solu muodostuu 5 tavun otsikosta (header) ja 48 tavun hyötykuormasta (payload). Solujen otsikon VCI-kenttään asetetaan saatu VCI-tunnus, jonka kytkin ja itse asiassa sen ATM-kerros tulkitsee reitittääkseen sen edelleen kohdeasemalle.
LAN-emulointi voi toimia useamman tyyppisissä laitteissa - esimerkiksi pääteasemissa ja silloissa tai LAN-kytkimissä. Emulointiprosessi eroaa hieman riippuen laitteesta, jossa se toimii. Seuraavassa tarkastellaan LAN-emulointia eri ympäristöissä.
Kun Ethernet- tai Token Ring -päätelaitteen verkkosovellus haluaa lähettää dataa verkkoon, se lähettää vastaavan kehyksen verkkokortille ajuriohjelmiston kautta. Kehys sisältää datan lisäksi MAC-kohdeosoitteen, joka voi olla yksikäsitteinen, broadcast- tai multicast -osoite. Nämä tiedot riittävät Ethernet- ja Token Ring -verkkokortille, ja niiden perusteella se osaa lähettää kehyksen edelleen lähiverkkoon kohti määränpäätä. Emulointirajapinnan alapuolella toimittaessa on ATM-verkkokortin suoritettava seuraavat tehtävät tiedonsiirron suorittamiseksi:
1. On selvitettävä, onko virtuaalikanavayhteys jo olemassa eli onko virtuaalikanava jo tiedossa. Tämä tapahtuu siten, että kortti pitää yllä tietokantaa aiemmin pystytetyistä yhteyksistä eli MAC - VCC -vastaavuudesta (MAC-VCC mapping). Tapaa, jolla tietokantaa pidetään, ei ole spesifioitu.
2. Jos MACia vastaavaa virtuaalikanavayhteyttä ei ole olemassa, on kortin luotava yhteys ennen datan siirtoa. Yhteyden muodostus on kaksivaiheinen prosessi. Ensin kortti käynnistää osoitteen selvitysprosessin (ARP), joka mahdollistaa uutta MACia vastaavan ATM-osoitteen oppimisen. Sen jälkeen se signaloi[1] ATM-verkkoon halukkuudestaan muodostaa yhteys (VCC) haluttuun ATM-osoitteeseen. Kun virtuaalikanavayhteys on saatu onnistuneesti luotua, kortti päivittää MAC - VCC -tietokantansa.
3. Kun on tiedossa, mihin virtuaalikanavaan kehykset lähetetään, emulointiprosessi ottaa sovellukselta sille saapuneen kehyksen kokonaisuudessaan ja lisää siihen kahden tavun mittaisen LANE-otsikon. AAL5-kerros pilkkoo sen sitten 48 tavun palasiksi, joihin jokaiseen ATM kerros lisää 5 tavun mittaisen otsikon. Otsikko sisältää VCI:n jonne solu on menossa. Sen jälkeen solut ovat valmiita siirrettäväksi verkkoon.
4. Kun solut saapuvat kohdeasemalle, ne puretaan takaisin alkuperäiseksi Ethernet- tai Token Ring -kehykseksi ja välitetään odottavalle sovellukselle aivan kuin se olisi vastaanotettu Ethernet- tai Token Ring -verkosta.
Edellä on oletettu, että työasema on suoraan yhteydessä ATM-verkkoon. LAN-emulointi voi kuitenkin toimia myös silloissa ja LAN-kytkimissä.Tämä mahdollistaa fyysisten Ethernet- tai Token Ring -segmenttien yhdistämisen toisiin vastaaviin segmentteihin tai työasemiin ATM-verkon yli. Tässä yhteydessä sillalla tai LAN-kytkimellä tarkoitetaan erityistä ATM-pääteasemaa, jolla on useita MAC-osoitteita. MAC-osoitteet ovat siihen liittyneiden todellisten Ethernet- tai Token Ring -segmenttien asemia. Sillat ja LAN-kytkimet tarjoavat yhteyden kahden samanlaisen segmentin välillä. Edelleenkään ei ole mahdollista yhdistää Ethernet-segmenttiä Token Ring -segmenttiin. Tyypillisesti silta on kaksiporttinen laite, jonka portit on liitetty eri segmentteihin. LAN-kytkin taas on useampiporttinen laite, joka sillan tavoin voi yhdistää samantyyppisiä segmenttejä. Jatkossa käytetään pelkkää termiä silta tarkoitettaessa siltoja ja LAN kytkimiä.
Silta toimii siirtämällä kehyksiä segmentistä toiseen joko kohdeosoitteen tai source-route -informaation mukaan. Jos nyt saadaan ATM-verkko emuloimaan Ethernet- tai Token Ring -segmenttiä, voidaan silta saada siirtämään kehykset fyysisestä Ethernet- tai Token Ring -segmentistä emuloituun segmenttiin ja päinvastoin. Yksinkertaisesti tämä tarkoittaa sitä, että on oltava silta, jossa on LAN-emulointia tukeva ATM-liittymä.
Source-Routing ja Transparent Bridging
On olemassa kaksi eri logiikkaa, joiden perusteella silta päättää, välittääkö se kehyksen toiseen segmenttiin vai ei. Näitä vastaavat termit transparent bridging ja source-routing (SR). Transparent bridging on käytössä yleisesti Ethernet-verkoissa ja source-routing vain Token Ringissä. Molemmissa tapauksissa on loogiset säännöt siitä, välittääkö silta kehyksen edelleen vai ei.
Lyhyesti transparent bridging tarkoittaa sitä, että silta oppii MAC-osoitteiden sijainnin sitä mukaa, kun se välittää niitä. Source-route bridging on puolestaan hieman monimutkaisempi kokonaisuus. Siinä vaaditaan jokaiselta yhteyttä haluavalta asemalta erillinen ohjelmisto, joka mahdollistaa source-routing -toiminnon. Kun transparentti silta päätti MAC-osoitteen mukaan kehyksen välittämisestä, löytyy informaatio tässä tapauksessa jokaisesta paketista erikseen. Source-route -sillat eivät ylläpidä erillistä listaa tuntemistaan asemista, vaan tieto osoitteista on joka asemalla erikseen. Selvittääkseen reititysinformaation, asemat suorittavat route discoveryn. Tämä tarkoittaa sitä, että lähetetään erityinen osoitteenselvityspaketti kaikkialle verkkoon ja kun kohdeasema huomaa paketin, se lähettää sen osoitteellaan varustettuna takaisin.
Kun LAN-emuloinnin sisältävä silta saa kehyksen siihen liitetyltä fyysiseltä lähiverkkosegmentiltä, se päättää normaalien sääntöjen mukaan kehyksen välittämisestä. Jos kehys on välitettävää lajia, silta etsii kehyksen MAC-osoitetta vastaavaa virtuaalikanavayhteyttä vastaavuustaulusta ja tästä eteenpäin toiminta on kuten pääteasemassa.
Yksi esittelemätön elintärkeä prosessi on se, kuinka pääteasema tai silta selvittää lähiverkon MAC-osoitetta vastaavan ATM-osoitteen. Emuloidussa lähiverkossa tämä on ratkaistu siten, että tarjotaan palvelu LES (LAN Emulation Server) ja protokolla, jolla kommunikoidaan emulointipalvelimen kanssa. Käytetty protokolla tunnetaan nimellä LE_ARP (LAN Emulation Address Resolution Protocol). Osoitteen selvityksen kannalta toinen tärkeä prosessi, joka emuloidussa lähiverkossa tarvitaan, on LEC (LAN Emulation Client). Se toimii joko sillassa tai pääteasemassa ja tarjoaa yhteyden emuloituun lähiverkkoon.
Kun LANE-asiakas haluaa tietää toisen LANE-asiakkaan ATM-osoitteen (MAC-osoiteon tiedossa), se lähettää selvityspyynnön LANE-palvelimelle käyttäen LE_ARP-protokollaa. Jos LANE-palvelin tietää MAC-osoitetta vastaavan ATM-osoitteen, se lähettää sen takaisin LANE-asiakkaalle. Jos taas se ei tiedä oikeaa osoitetta, se lähettää selvityspyynnön edelleen kaikille muille tuntemilleen asiakkaille ja jos joku LANE-asiakas tuntee osoitteen, se vastaa pyyntöön. Jotkut LANE-asiakkaista voivat olla siltoja ja ne vastaavat LE_ARP-pyyntöön, jos kyseinen MAC-osoite löytyy niihin liitetyistä lähiverkkosegmenteistä.
Jotta prosessi voisi toimia, on asiakkaalla oltava luotuna sellainen virtuaalikanavayhteys LANE-palvelimeen, johon se voi lähettää LE_ARP pyynnön ja josta se saa vastauksen. Tämä virtuaalikanavayhteys, nimellä Control Direct VCC tunnettu, luodaan, kun asiakas liittyy emuloituun LANiin. Tämä tapahtuu normaalisti osana LAN-emulointia tukevan sillan tai pääteaseman käynnistymistä. Liittymisprosessin aikana asiakas vaihtaa informaatiota palvelimen kanssa, jotta palvelin voi päivittää aktiivisista asiakkaista pitämänsä tietokannan. Seuraavassa kuvassa on esitetty liittymisprosessi vaiheittain.
Yksi LANE-palvelimen tehtävistä on siis osoitteen selvityspyyntöjen välittäminen edelleen muille asiakkaille, mikäli se ei itse löydä oikeaa osoitetta omasta tietokannastaan. Selvityspyynnön välittämiseen voidaan käyttää Control Direct VCC:tä jokaiselle asiakkaalle erikseen. Tehokkaampaa on kuitenkin käsitellä välitys point-to-multipoint tyyppisenä. LANE-palvelin voi siis luoda point-to-multipoint yhteyden asiakkaiden kanssa, kun ne liittyvät verkkoon. Tällainen virtuaalikanavayhteys tunnetaan nimellä Control Distribute VCC. Kuva 5 esittää osoitteen selvityksen ja yhteyden muodostuksen kaaviona.
Kokonaisuutena LE_ARP-prosessi muistuttaa hyvin paljon TCP/IP-verkkojen osoitekyselyä ARPia. Suurin ero onkin siinä, että LAN-emuloinnissa kyselyä ei lähetetä broadcastina, vaan Control Direct VCC:tä pitkin ainoastaan emulointipalvelimelle, jolloin kyselyt eivät näy muille verkon asemille.
Aiemmin on vain mainittu, että LANE-asiakas rekisteröityy LANE-palvelimelle. Ongelmana on kuitenkin se, kuinka se löytää emulointipalvelimen ATM-osoitteen. Osoitteen löydyttyä asiakas pääsee muodostamaan Control Direct VCC:n emulointipalvelimeen ja edelleen suorittamaan rekisteröitymisprosessin loppuun. Käytännössä on mahdollista, että samassa ATM-verkossa on useampia palvelimia, joista jokainen edustaa omaa emuloitua lähiverkkoansa. Tästä syystä tarvitaan mekanismi, jonka mukaan asiakas tietää, mihin palvelimeen sen täytyy liittyä. Tehtävää hoitamaan on valittu konfiguraatiopalvelin (LECS, LAN Emulation Client Server), joka antaa LANE-asiakkaalle oikean palvelimen osoitteen.
LANE-spesifikaatio tarjoaa useampia tapoja konfiguraatiopalvelimen osoitteen saamiseksi:
* Asiakas voi käyttää tunnettua osoitetta (vrt. 9700-LECS tavallisessa puhelinliikenteessä). Teoriassa tällainen menettely tarjoaa helposti implementoitavan tavan LANE-asiakkaiden konfiguroimiseksi. Osoiteformaatti ja tunnettu osoite määriteltiin kuitenkin tulevaisuuden signalointispesifikaatiota varten, joten kovin kauaa tällainen menettely ei käy. Seuraava LANE-spesifikaatio tullee määrittelemään tämän tarkemmin.
* LANE-asiakas voi lähettää ILMI-viestejä (Interim Local Management Interface) ATM-kytkimelleen. Tämä vaihtoehto edellyttää, että verkon ylläpitäjä asettaa konfiguraatiopalvelimen osoitteen jokaiseen kytkimeen erikseen. Kun nyt LANE-asiakkaaseen kytketään virta, se lähettää ensimmäiseksi UNI-rajapinnan (User-to-Network Interface) yli ILMI-viestin, jossa se pyytää konfiguraatiopalvelimen osoitetta. Tällöin siihen fyysisesti liitetty kytkin vastaa. Tällä hetkellä tämä on sopivin tapa konfiguraatiopalvelimen löytämiseksi, sillä se edellyttää vain ATM kytkinten konfiguroimista. Reitittimiin, siltoihin ja muihin asiakaslaitteisiin ei tarvitse koskea lainkaan.
* LANE-asiakas voi käyttää ennalta määrättyä virtuaalikanavayhteyttä. Tämä vaatii sen, että jokaisesta ATM-rajapinnasta ja jokaisesta UNI-portista on täytynyt asettaa ennakolta virtuaalikanavayhteys konfiguraatiopalvelimeen. Tähän kuluu luonnollisesti suuri määrä vapaita tunnistimia (VCI) ja ne ovat kaiken lisäksi suurimman osan ajasta joutilaina.
* LANE-asiakkaaseen voidaan konfiguroida käsin oikean LANE-palvelimen osoite. Tämä on kuitenkin ylläpidollisesti erittäin kankeaa, eikä siinä ole minkäänlaista virheensietoa LANE-palvelimen vikatilanteiden varalta.
Kun LANE-asiakas on paikallistanut konfiguraatiopalvelimen, se luo Configuration Direct VCC:n siihen ja suorittaa konfiguraatiokyselyn. Kyselyn yhteydessä välitetään parametreina mm. asiakkaan ATM-osoite, MAC-osoite, lähiverkon tyyppi ja kehyksen maksimikoko. Näistä tiedoista konfiguraatiopalvelin päättelee asiakkaalle sopivan emulointipalvelimen ja palauttaa kyseessä olevan lähiverkon tyypin, suurimman sallitun kehyskoon ja LANE-palvelimen ATM-osoitteen.
LANE-spesifikaatio ei määrittele logiikkaa, minkä mukaan konfiguraatiopalvelin tarjoaa jotakin LANE-palvelinta asiakkaalle. Tämä antaakin verkon ylläpitäjälle vapaat kädet, kun määritellään emuloitujen lähiverkkojen liittymissääntöjä. Yksinkertaisimmillaan nämä säännöt varmistavat vain sen, että Ethernet-asemaa emuloiva LANE-asiakas liittyy emuloituun Ethernetiin eikä Token Ringiin. Hienostuneempaa on käyttää liityntäsääntöjä siten, että niiden avulla pystytään määrittelemään ja kontrolloimaan liittymistä useampaan virtuaaliseen lähiverkkoon ATM-verkossa.
LANE-spesifikaatio ei myöskään määrittele, miten useampia ATM-osoitteita sisältävät, esimerkiksi LAN-kytkimet, järjestävät osoitteensa. Määrittelemätöntä on myös, kuinka konfiguraatiopalvelimen tulee ylläpitää tietokantaansa.
Kun LANE-asiakas saa kehyksen lähetettäväksi, kertoo MAC-osoitteen ensimmäinen bitti, minkä tyyppinen lähetys on kyseessä:
* Jos ensimmäinen bitti on 1, on kehys broadcast/multicast -tyyppiä.
* 0 indikoi unicast -tyyppisen kehyksen.
Tarkastellaan seuraavaksi broadcastien ja multicastien aiheuttamia toimenpiteitä päätelaitteessa tarkemmin. Itse asiassa prosessi on juuri samanlainen kuin silloin, kun kyseessä on vain yhteen paikkaan menevä kehys ts. etsitään broadcast tai multicast MAC-osoitetta vastaava virtuaalikanavayhteys ja segmentoidaan kehys soluiksi. Ethernet- ja Token Ring -verkoissa kaikki liikenne on tavallaan broadcast -tyyppistä, sillä aseman lähettämän kehyksen "kuulevat" kaikki verkossa olevat asemat. ATM-verkossa tilanne on luonteeltaan sellainen, että kehys kulkee vain yhdelle vastaanottajalle virtuaalikanavaa pitkin. ATM-verkon on siis huolehdittava, että broadcastiksi tai multicastiksi tarkoitettu kehys todella saavuttaa kaikki tarvittavat asemat. Tätä varten tarvitaan ATM-verkkoon vielä yksi lisäprosessi, BUS (Broadcast and Unknown Server).
Kun LANE-asiakas rekisteröityy verkkoon, se kysyy heti LE_ARPia käyttäen sen ATM-osoitteen, joka vastaa broadcastin MAC-osoitetta (FFFFFFFFFFFF). LANE-palvelin palauttaa vastauksena BUSin osoitteen ja seuraavaksi LANE-asiakas muodostaa virtuaalikanavayhteyden levitysviestipalvelimeen BUSiin. Tämä yhteys tunnetaan nimellä Multicast Send VCC. Kun LANE-asiakas on saanut yhteyden BUSiin, luo BUS virtuaalikanavayhteyden takaisin asiakkaaseen. Tähän BUSlla on kaksi vaihtoehtoa:
1. LANE-asiakas voidaan lisätä olemassaolevaan point-to-multipoint -virtuaalikanavayhteyteen tai
2. luoda point-to-point -virtuaalikanavayhteys LANE-asiakkaaseen.
Kun pääteasemassa oleva sovellus vaatii broadcastin tai multicastin siirtämistä, pääteaseman LEC-prosessi käyttää tarkoitusta varten varattua virtuaalikanavayhteyttä lähettääkseen kehyksen BUSille. Kun BUS saa LANE-asiakkaalta broadcast tai multicast kehyksen, se kopioi kehyksen ja välittää sen edelleen kaikille LANE-asiakkaille, jotka ovat rekisteröityneet, käyttäen Multicast Distribute VCC:tä. Kannattaa huomata, että BUS todellakin lähettää broadcastit ja multicastit kaikille LECeille - myös alkuperäiselle lähettäjälle. Lähettäneen LANE-asiakkaan vastuulle jääkin "kaiun" poissuodatus. Yksi tapa tehdä tämä on verrata saapuvaa LANE-otsikkoa omaan LECID:hen.
Jos BUS saa lähetettäväkseen yhtä aikaa kaksi broadcast- tai multicast-kehystä, se puskuroi niistä toisen siksi aikaa, kun se on saanut ensimmäisen lähetettyä. Tämä sen vuoksi, ettei samaan kehykseen kuuluvat solut joudu erilleen. Puskurointi voidaan suorittaa vain yhdelle kehykselle, sillä se on AAL5:n mukanaan tuoma rajoitus.
Emuloidussa lähiverkossa, jossa yksi tai useampi LANE-asiakas on transparentisti toimiva silta, tulee tilanteita, jolloin normaalilla osoitteenhakuprosessilla ei saada MAC-osoitetta vastaavaa ATM-osoitetta. Tällainen tilanne voi syntyä, kun MAC-osoite viittaa jonkun sillan takaiseen asemaan, josta ei ole vielä siirretty yhtään kehystä. Tällöin silta ei tiedä mitään kyseisen aseman olemassaolosta, koska (transparentit) sillat voivat oppia asemien osoitteita vain silloin, kun ne lähettävät kehyksiä.
Kun LANE-asiakkaalle tulee lähetettäväksi kehys, jonka kohdeosoitetta ei löydy omasta tietokannasta, on sillä kaksi mahdollisuutta:
1. LANE-asiakas voi hylätä kehyksen, mutta selvittää silti osoitevastaavuuden tulevia kehyksiä varten.
2. LANE-asiakas voi lähettää kehyksen BUS:lle, joka lähettää sen edelleen kaikille siihen liittyneille LANE-asiakkaille.
Jos LANE-asiakas ei onnistu ratkaisemaan MAC-osoitetta LE_ARP-prosessilla, se voi siis lähettää kehyksen BUS:lle käyttäen Multicast Send VCC:tä. BUS käsittelee tällaisen viestin aivan kuten kyseessä olisi tavallinen broadcast tai multicast ja välittää sen edelleen kaikille rekisteröityneille LANE-asiakkaille. Jos LANE-asiakas sattuu olemaan transparentti silta, sen siltauslogiikka käskee sitä välittämään sellaisen kehyksen kaikille siihen liitetyille työasemille. Kun kohdeasema vastaa, silta oppii sen osoitteen.
Tällaisessa menettelytavassa on olemassa riski, että huonosti käyttäytyvä LANE-asiakas lähettää kaikki kehyksensä BUS:lle, eikä se yritäkään ratkaista MAC-osoitetta eikä luoda Data Direct VCC:tä kohdeasiakkaaseen. Tästä syystä on määritelty yläraja sille, miten useasti LANE-asiakas voi lähettää tuntemattomia kehyksiä BUS:lle.
Source-routing on Token Ring -lähiverkkosegmenttien välinen standardi siltaustekniikka. LAN-emulointi tukee täysin source-routingia emuloidun lähiverkon päällä toimivassa Token Ringissä. Source-routing -ympäristössä liikkuva kehys sisältää paitsi lähettäjän ja vastaanottajan MAC-osoitteet, niin myös Routing Information -kentän (RI). Routing Information -kenttä sisältää listan Route Descriptoreista (RD), joka kuvaa renkaiden ja siltojen numerot siinä järjestyksessä kun ne esiintyvät matkalla määränpäähän. Pääteasemat selvittävät reitin ennen kehyksen lähettämistä route explorer broadcast kehyksillä ja ne käsitellään LAN-emuloinnissa aivan kuten tavallisetkin broadcastit.
Transparentista sillasta tuttu osoitteenhakuprosessi ei aivan sellaisenaan toimi source-routingissa, sillä ennen LE_ARP:ia LANE-asiakkaan täytyy selvittää, joutuuko kehys kulkemaan source-route -sillan läpi vai ei. Sen se voi selvittää tutkimalla routing information -kenttää. Seuraavissa tapauksissa se voi päätellä, että kehys on suunnattu saman renkaan toiselle LANE-asiakkaalle eikä sen siis tarvitse kulkea source-route -sillan läpi:
1. routing information -kenttää ei ole.
2. routing information -kenttä on lyhyempi kuin 6 bittiä.
3. Viimeinen renkaan numero on sama kuin lähetysrenkaan numero.
Tässä tapauksessa lähettävä LANE-asiakas voi käyttää standardia LE_ARP-menettelyä. Jos taas osoittautuu, että kehyksen täytyy kulkea source-route -sillan läpi, täytyy LANE-asiakkaan määritellä LE_ARPiin seuraavan routing information -kentässä määritellyn hopin[2] Route Descriptor (sillan tai renkaan numero). Tämä sen vuoksi, että source-route -sillat eivät, päinvastoin kuin transparentit sillat, tiedä mitään niihin liittyneistä MAC-osoitteista. Ne tuntevat vain siltojen ja renkaiden numerot.
LANE-palvelin voi vastata suoraan LE_ARP Route Descriptor -pyyntöön, jos source-route -sillassa toimiva LANE-asiakas on rekisteröinyt edustamansa Route Descriptorit liittymisvaiheessa. Source-route -ympäristössä toimiva LANE-palvelin voi siis ylläpitää listaa sekä MAC-osoitteista että Route Descriptoreista ja niitä vastaavista ATM-osoitteista, jotta se voi vastata molemman tyyppisiin LE_ARP -pyyntöihin. Jos LANE-palvelin ei pysty vastaamaan suoraan Route Descriptor LE_ARPiin, lähettää se pyynnön edelleen niille LANE-asiakkaille, jotka ovat rekisteröityneet proxyina. Tällöin se source-route -silta, joka tunnistaa Route Descriptorin LE_ARPissa, vastaa. Kun LANE-asiakas saa vastauksen Route Descriptor LE_ARPiin, se luo Data Direct VCC:n asianmukaiseen source-route -siltaan, jotta kaikki myöhemmin tulevat samaa reittiä kulkevat kehykset voidaan lähettää suoraan virtuaalikanavayhteyden toisessa päässä olevalle source-route -sillalle.
Seuraavassa kuvassa esitetään yhteenvetona eri LANE-prosessien väliset virtuaalikanavayhteydet.
BUSin palvelujen käytöstä saattaa seurata ongelmia kehysten järjestyksen säilymisessä. Koska Ethernet ja Token Ring eivät salli kehysten välittämistä epäjärjestyksessä, eikä lähiverkkoa käyttävissä sovelluksissa aina ole toimivaa mekanismia järjestyksen menettäneiden kehysten uudelleenjärjestämiseksi, on LAN-emulointiin implementoitu lisäksi valinnainen protokolla käsittelemään tämän tyyppisiä komplikaatioita. Tätä protokollaa kutsutaan nimellä Flush Message Protocol.
Jos LANE-asiakas epäonnistuu ensimmäisellä kerralla MAC-osoitteen selvittämisessä, se lähettää kehyksen BUSille levittämistä varten. Jos LANE-asiakas toisen kehyksen kohdalla onnistuukin selvittämään osoitteen ja BUS on hieman viivytellyt ensimmäisen kehyksen kanssa, voi käydä niin, että jälkimmäinen paketti, joka kulkee Data Direct VCC:tä pitkin, on ensimmäisenä perillä. Flush Message -protokolla on tarkoitettu eliminoimaan riski pakettien joutumisesta epäjärjestykseen. Jos LANE-asiakkaan täytyy vaihtaa reittiä kesken siirron (tässä tapauksessa BUSista Data Direct VCC:lle), se lähettää ennen muutosta Flush Request Messagen vanhalle reitille eli tässä tapauksessa BUSille. Lähettämisen jälkeen se voi odottaa, kunnes saa vastauksen kohteena olevalta LANE-asiakkaalta. Tällöin lähettäjä voi olla varma siitä, että vanhoja kehyksiä ei enää ole matkalla. Vasta sen jälkeen se alkaa lähettää kehyksiä uutta reittiä pitkin.
LAN-emuloinnin virheherkkyys riippuu olennaisesti LANE-palvelimien, LANE-asiakkaiden ja konfiguraatiopalvelimen palvelujen saatavuudesta. Käytännössä nämä toiminnot onkin yleensä jaettu fyysisesti useampaan eri paikkaan.
On kaksi lähestymistapaa, jotka parantavat verkon virheherkkyyttä edellä mainittujen palvelujen suhteen:
1. Tarjota varallaolevat tai valmiustilassa olevat palvelut, jos ensisijainen palvelun tarjoaja epäonnistuu.
2. Tarjota palveluita jaetulta pohjalta, ts. verkkoon asennetaan useampia LES- ja BUS -palveluita tarjoavia prosessoreita toimimaan rinnan.
Yksinkertaisempi edellämainituista tavoista on tarjota varalla olevaa LANE-palvelun tarjoajaa. Yksi potentiaalinen ongelma on se, että LAN-emulointi ei tarjoa erityistä menetelmää havaita LANE-palvelimen tai BUSin virhettä. LANE-asiakkaan pitäisi kuitenkin pystyä itsekin havaitsemaan virhe LANE-palvelimessa ja BUSissa tarkkailemalla vuoropuhelua LANE-palvelimen ja BUSin kanssa. Esimerkiksi jos LANE-asiakas lähettää broadcast-kehyksen BUSille, sen pitäisi olettaa kuulevansa kehyksen toistamisen Multicast Distribute VCC:ssä, kun BUS on välittämässä kehystä edelleen kaikille tuntemilleen LANE-asiakkaille. Jos broadcastin "kaikua" ei kuulu, voi LANE-asiakas päätellä, että BUSin toiminnassa on jotain vikaa.
Vaikka LAN-emuloinnissa ei määritelläkään tapaa, jolla mahdollinen virhe havaitaan, kuvataan kyllä mitä pitäisi tapahtua virhe havaittaessa. LANE-asiakkaan täytyy purkaa kaikki olemassaolevat yhteydet ja käynnistää liittymisprosessi uudelleen, ts. kysyä konfiguraatiopalvelimelta, minne liittyä jne. Konfiguraatiopalvelimen pitäisi siksi kyetä havaitsemaan LANE palvelimen tai BUS:n virhe, jotta se voi tarjota kaikille uudelleenliittyjille varaosoitteen toiseen LANE palvelimeen tai BUS:iin.
Kokonaan oma lukunsa onkin sitten virhetilanteet konfiguraatiopalvelimessa. Sen toiminnan luonteesta johtuen voi käydä niin, etteivät verkon käyttäjät edes havaitse vikaa. Ainoa huomattava haitta onkin se, että uudet LANE-asiakkaat eivät pysty liittymään verkkoon. Olettaen, että ylläpitäjä saa tiedon konfiguraatiopalvelimen virhetilanteesta, hänellä luultavimmin on aikaa käynnistää uusi LECS-prosessi manuaalisesti ilman, että keskeytystä juurikaan havaitaan. Toinen vaihtoehto on implementoida konfiguraatiopalvelin jaettuna tietokantana, jossa on sisäänrakennettu virheensietomekanismi.
LAN-emuloinnin raamit eivät estä täysin hajautettuja LES-, LECS- ja BUS -palveluja, mutta toisaalta se ei myöskään kerro, kuinka ne voidaan aikaansaada. Hajautettujen palvelujen implementointi vaatinee uusia protokollia hajautettujen elementtien välille, mutta niitä ei ole vielä määritelty.
LANE-asiakas voidaan ajatella sisäänkäyntinä emuloituun lähiverkkoon. LANE-asiakkaisiin on aina liitetty fyysinen ATM-rajapinta. Ne voivat sijaita pääteasemissa, kuten PC:issä tai työasemissa, jotka on yhdistetty suoraan ATM-verkkoon. Lisäksi LEC-prosessit voivat sijaita laitteissa, jotka yhdistävät emuloidun lähiverkon muihin verkkoihin. Tällaisia laitteita ovat mm. sillat, LAN-kytkimet ja reitittimet. Seuraava kuva havainnollistaa lähiverkkoemuloinnin eri prosessien sijoittumista.
Aiemmin on jo tullut esille LEC-prosessien implementointi LAN-kytkimiin ja siltoihin. Nämä laitteet tarjoavat protokollariippumattoman yhteyden fyysisten Ethernet- tai Token Ring -segmenttien välille ja emuloidun Ethernetin tai Token Ringin ATM-verkon sisällä. LANE-asiakkaat voivat sijoittua myös reitittimien ATM-rajapintaan. Tässä tapauksessa reititintä kohdellaan vain toisenlaisena pääteasemana, joka voi liittyä ATM-verkkoon.
LEC-prosessi toimii PC:ssä tai työasemassa ohjelmistona joko isäntäkoneessa tai ATM-kortin prosessorissa. Se toimii standardien ajurirajapintojen kuten ODI:n (Novell Open Datalink Interface) tai NDIS:n (Microsoft Network Datalink Interface Specification) alapuolella. Nämä rajapinnat tukevat Ethernetin ja Token Ringien standardia Client/Server verkko-ohjelmistoa. Käytännössä LANE-asiakas on ATM- kortin ajuriohjelman sisäinen osa. On täysin mahdollista, että samassa kortissa voi olla kaksi eri LEC-prosessia ja erityisesti ne voivat olla erityyppisiä. Käytännössä tällainen tilanne tulee eteen, kun olemassaoleva verkko on sekoitus Ethernetiä ja Token Ringiä ja molemman tyyppisistä verkoista halutaan pääsy yleisiin palvelimiin. Tässä tapauksessa ATM-kortin ajureihin voidaan implementoida sekä Ethernet- että Token Ring -emulointi yhtäaikaisesti. Tällöin samassa laitteessa on kaksi tai useampia emuloituja MAC-osoitteita. ODI ja NDIS sallivat sekä Ethernet- että Token Ring -rajapintojen olemassaolon. Palvelinohjelmisto näkee tilanteen siten, että samassa laitteessa olisi asennettuna kaksi fyysisesti eri korttia.
LANE-palvelimen, konfiguraatiopalvelimen ja BUSin täytyy sijaita laitteessa, johon kaikkien LANE-asiakkaiden on helppo päästä kiinni. Ne voivat olla sijoittuneina kaikki samaan isäntään tai vaikka kaikki eri isäntiin. Käytännössä ne voivat toimia missä tahansa ATM-verkkoon liitetyssä asemassa, joka voi olla dedikoitu PC, työasema tai palvelin. Ne voidaan implementoida esimerkiksi NLM:na (NetWare Loadable Modules) ja tällöin ne toimivat dedikoidussa tai muussa käytössä olevassa NetWare-palvelimessa.
LES-, BUS- ja LECS -prosessit voivat vaihtoehtoisesti toimia myös ATM-kytkimeen integroidussa prosessorissa. ATM-kytkimet voidaan varustaa sellaisella prosessorilla, että ne pystyvät hoitamaan erilaisia tehtäviä, kuten reititystä ja verkonhallintaa. Siksi emuloidun lähiverkon prosessit voivat sijaita hyvin myös kytkimessä.
ATM:n päällä toimiva LAN-emulointi sallii sellaisten emuloitujen Ethernet- ja Token Ring -segmenttien implementoinnin, että ne ylittävät reilusti todellisten lähiverkkosegmenttien rajoitukset, kuten ulottuvuus, kaistanleveys ja asemien lukumäärä. ATM ei aseta mitään rajoituksia fyysiselle etäisyydelle. Käyttäen yleisiä siirtopalveluja, on mahdollista levittää yksi ainoa emuloitu lähiverkkosegmentti vaikka koko maapallon laajuiseksi. ATM ei aseta käytännön rajoituksia myöskään kaistanleveydelle eikä siirtokapasiteetille. Data siirretään päätelaitteiden välillä point-to-point virtuaalikanavayhteyttä pitkin ja ATM-linkki itsessään voi toimia nopeudella 622 Mbit/s ja nopeamminkin, jos tarve vaatii.
Emuloituun lähiverkkoon liittyneiden laitteiden lukumäärällä ei myöskään ole teoreettista ylärajaa, vaikkakin yhteen LANE-palvelimeen liittyneiden LANE-asiakkaiden määrä on maksimissaan 65279. Sitä voidaan käytännössä pitää ylärajana. Tästä seuraa se houkutteleva mahdollisuus, että suurten yritysten verkot voidaan rakentaa suoraan ATM-runkoverkko -pohjalta, jonka kautta saavutetaan fyysiseen Ethernetiin tai Token Ringiin liitetyltä omalta työasemalta kaukanakin sijaitsevat palvelimet siltojen ja LAN-kytkinten välityksellä. Tällöin ei erillistä reititintä tarvita lainkaan. ATM-verkko itsessään koostuu eri reittejä kulkevien point-to-point yhteyksien sekasotkusta, jossa ATM-kytkimet yhteistyössä reitittävät kunkin yhteyden ja huolehtivat samalla kuormituksen tasaisesta jaosta. Emuloidut lähiverkkosegmentit, jotka on liitetty ATM-runkoverkkoon, tarjoavat tällöin luotettavan siirtotien fyysisiin LAN-segmentteihin liitettyjen LAN-kytkinten ja suoraan ATM-runkoverkkoon liitettyjen palvelinten välillä. Lisäksi lähes olematon viive end-to-end yhteyksissä voisi heittää historiaan nykyisiä reititinverkkoja kiusaavat timeout-ongelmat.
ATM-desktop liikenteeseen siirtymisessä on se hyvä sivuvaikutus, että reitittimiä ei enää tarvita (siis puhtaassa ATM verkossa). Toisaalta olemassaolevien Ethernet- ja Token Ring -verkkojen kannalta ATM tarjoaa globaalin lähiverkkoarkkitehtuurin, joka operoi riippumatta verkkokerroksen protokollista.
Monet LAN-protokollat ovat tunnettuja siitä, että ne lähettävät säännöllisesti erilaisen valikoiman broadcasteja ympäri verkkoa. Mitä useampia asemia verkkoon on liitetty, sitä enemmän broadcastit kuormittavat verkkoa. Liiallinen broadcastien lähetys syö kapasiteettia ja lisää verkon kustannuksia. Siksi broadcast-liikenteen kontrolli on olennaista. Reitittimet ovat erityisen tehokkaita broadcastien leviämisen estäjiä ja saattaa käydäkin niin, että useampia emuloituja lähiverkkosegmenttejä joudutaan yhdistämään reitittimillä. Reitittimet kuitenkin lisäävät verkon monimutkaisuutta ja siksi riippuvaisuutta reitityksestä pyritäänkin vähentämään. Verkkoteknologiassa on kaksi kehitysaluetta, jotka kamppailevat tämän parissa:
1. Yritys saada verkkotuotteiden tarjoajat vähentämään lähiverkkoon generoitavan broadcast -liikenteen määrää. Esimerkiksi Novellin NetWare Link State Protocol luo paljon vähemmän broadcast-liikennettä kuin perinteinen NetWare on luonut.
2. Siltoihin ja LAN-kytkimiin ollaan kehittämässä älykkäitä broadcastien suodatusominaisuuksia. Näin sillat ja LAN-kytkimet voivat vähentää huomattavasti niiden broadcastien määrää, jotka niiden pitää päästää läpi. Esimerkiksi huonosti käyttäytyvästä protokollasta käy NetBIOS.
On siis selvää, että reitittimiä tarvitaan vielä jonkin aikaa ainakin ympäristöissä, jotka hyödyntävät reititettäviä protokollia, kuten IP ja IPX. Kuitenkin sitä mukaa kun organisaatiot siirtyvät kohti puhdasta ATM-liikennettä ja broadcastien rajoitusmenetelmät kehittyvät, vähenee reitittimien rooli paljon nykyisestä.
LAN-emulointi tarjoaa tehokkaan ratkaisun siihen, kuinka voidaan käyttää olemassaolevia sovelluksia ATM-verkon yli ja kuinka yhdistää jo asennetut Ethernet- ja Token Ring lähiverkot ATM-verkkoon. Kuitenkin on selvää, että emulointi ei ole paras tulevaisuuden ratkaisu verkkoihin, joissa ATM-yhteydet on käytössä kaikkialla. Tämä siksi, että LAN-emulointi estää tehokkaasti käyttäjiä ottamasta kaikkea hyötyä irti joistakin ATM:n hyödyllisimmistä piirteistä, kuten esimerkiksi palvelun laadusta.
Kun ATM saa markkinoilla maata jalkojensa alle, voidaan odottaa suoraan ATM- verkon rajapinnoille kirjoitettuja verkkokäyttöjärjestelmiä ja verkkosovelluksia. Ne voivat toimia paljon tehokkaammin kuin nykyiset emulointirajapinnan läpi käytettävät sovellukset ja lisäksi ne voivat hyötyä kyvystä erottaa erilaisia liikenneluokkia. Ei tietenkään ole esteitä sille, että nämä uudet sovellukset käyttäisivät samaa ATM-verkkoa LAN-emulointia hyödyntävien tahojen kanssa. Kun end-to-end -ATM-verkot yleistyvät hallitsevaan asemaan saakka, voidaan olettaa, että LAN-emulointi häviää pois käytöstä. Kuitenkin niin kauan kuin verkkojen ylläpitäjien on tuettava sovelluksia, jotka on kirjoitettu Ethernetille tai Token Ringille ja niin kauan kuin tällaiset lähiverkot on saatava yhdistettyä ATM-verkon kanssa, tulee LAN-emulointi olemaan erittäin merkittävässä osassa.
ARP Address Resolution Protocol
ATM Asynchronous Transfer Mode
CLP Cell Loss Priority
ELAN Emulated LAN
GFC Generic Flow Control
IP Internet Protocol
IPX Internet Packet Exchange Protocol (Novell)
ISDN Integrated Services Digital Network
LAN Local Area Network
LANE LAN Emulation
LE_ARP LAN Emulation Address Resolution Protocol
MAC Media Access Control
MIB Management Information Base (SNMP)
PT Payload Type
RD Route Descriptor
RI Routing Information (field)
SNMP Simple Network Management Protocol
TR Token Ring
VC Virtual Channel
VCC Virtual Channel Connection
VCI Virtual Channel Identifier
VP Virtual Path
VPC Virtual Path Connection
WAN Wide Area Network
1. Taylor, M., LAN Emulation Over ATM, A Technology White Paper, Madge, 1994
2. Taylor, M., ATM at the Desktop, A Technology White Paper, Madge, 1995
3. CELLplex&tm; 7000 Operation Guide, 3Com, 1995
4. Asynchronous Transfer Mode, An Olicom White Paper, Olicom, 1995
5. ATM Basics And Background, An Olicom Technology Guide, Olicom, 1995
[1] Hallintatasolla (Control Plane) tapahtuvasta liikennöinnistä käytetty nimitys.
[2] Hop tarkoittaa yhtä sillan tai reitittimen "ylitystä"
