ATM - Asynchronous Transfer Mode II.

AAL - ATM Adaptation Layer (Adaptační vrstva ATM)

Základní přenosové funkce, tedy transport jednotlivých ATM buněk, zajišťuje hlavní vrstva ATM, neboli tzv. ATM vrstva. S tím, že by bezprostředně nad touto vrstvou byly provozovány jednotlivé aplikace, však autoři ATM příliš nepočítali - zejména proto, že požadavky různých aplikací na druh a kvalitu poskytovaných přenosových služeb mohou být skutečně diametrálně odlišné. Proto nad základní "přenosovou" ATM vrstvou sídlí ještě tzv. adaptační vrstva (ATM Adaptation Layer), jejímž úkolem je zajišťovat potřebné přizpůsobení mezi možnosti ATM vrstvy a požadavky vyšších vrstev.

 

AAL1

pro adaptační vrstvu bylo připraveno několik protokolů, lišících se v tom, jaké kategorii aplikací vychází vstříc, přičemž jednotlivé verze jsou číslovány. Jako AAL1 je označován protokol, který vychází vstříc nekomprimovaným přenosům v reálném čase, a vytváří tzv. bitovou rouru - z jedné strany se do ní vkládají jednotlivé bity, které z druhé strany zase vystupují (přičemž veškerou segmentaci bitového proudu do ATM buněk transparentně zajišťuje právě protokol AAL1). Jde v zásadě o nadstavbu nad režimem CBR (Constant Bit Rate) ATM vrstvy, který se ale týká přenosu celých ATM buněk.

 

AAL2

protokol AAL2 je určen pro komprimované přenosy zvuku a obrazu, které také potřebují "dorazit včas", ale díky komprimaci nemají stejnoměrné nároky na přenosovou kapacitu.

 

AAL3/4

vedle protokolů AAL1 a AAL2, určených pro přenosy citlivé na čas doručování jednotlivých částí dat, byly připravovány i protokoly AAL3 a AAL4, pro přenosy které nejsou tolik citlivé na rovnoměrnost doručování. Oba protokoly se přitom měly lišit v tom, zda fungují ve spojovaném či nespojovaném režimu (přičemž samotná ATM vrstva funguje zásadně spojovaně, takže nespojovaný charakter musí být poměrně složitě emulován). Časem ale autoři dospěli k závěru, že dva samostatné protokoly AAL3 a AAL4 nejsou zapotřebí, a místo nich byl vyvinut protokol společný, označovaný jako AAL3/4. Ten přitom může fungovat v režimu "roury", kdy vytváří iluzi spojitého datového proudu a sám si rozhoduje o tom, kdy přenášená data "rozřeže" na vhodně velké bloky a ty pak skutečně přenese. Další možností je tzv. blokový režim, kdy už samotný protokol AAL3/4 dostává data "nařezaná" do bloků a ty pak přenáší.

 

AAL5

protokoly AAL1 až AAL3/4 vznikly ve světě spojů, způsobem který byl ve světě počítačů silně kritizován. Například standard AAL2 byl přijat v časové tísni, když se zjistilo že obsahuje závažné chyby, a tak byly ze standardu vypuštěny některé důležité parametry, aby se sice dodržel termín odevzdání standardu, ale výsledek byl záměrně zcela nepoužitelný. Protokol AAL3/4 byl sice standardizován jako funkční, ale je zase nesmírně složitý a neefektivní. O protokolu AAL1 se zjistilo, že vlastně není vůbec zapotřebí. Když si tuto situaci uvědomili ve světě počítačů, rozhodli se vyvinout vlastní protokol pro adaptační vrstvu AAL. Tento protokol dostal označení AAL5 a je dnes zdaleka nejpoužívanějším ve světě ATM. Poskytuje v zásadě stejné služby jako AAL3/4, tedy spojovaný i nespojovaný přenos v režimu blokového přenosu i "roury", ale je výrazně jednodušší a efektivnější než AAL3/4.

 

Native ATM application

Existence adaptační vrstvy AAL sice vycházela vstříc potřebám různých aplikací, ale zase ne zcela dokonale. Například u datových aplikací, typických pro provoz v počítačových sítích (tedy nejvíce pro přenosové protokoly na úrovni síťové vrstvy), se ukázalo že i přes existenci adaptační vrstvy panuje stále ještě velká odlišnost mezi tím, co nabízí ATM a co tyto aplikace očekávají. Snad nejkřiklavějším příkladem je neexistence všesměrového vysílání, neboli vysílání z jednoho zdroje všem existujícím příjemcům současně. To ATM skutečně nedokáže poskytnout, a ani adaptační vrstva tento handicap neodstraňuje. Případné aplikace, které by mohly být provozovány přímo nad adaptační vrstvou, by tak musely být doslova ušity na míru možnostem a vlastnostem ATM, resp. vlastnostem a schopnostem adaptační vrstvy. Takovéto aplikace, označované jako "nativní" (doslova: rozené pro ATM) by však zase nemohly jednoduše fungovat v prostředí mimo ATM. Při nasazení ATM například do role páteřní sítě by to znamenalo, že by tyto aplikace nemohly "dosáhnout" mimo páteřní části sítě, tedy například až k jednotlivým pracovním stanicím atd.

 

Classical IP over ATM

nativní aplikace pro ATM nevznikly prakticky žádné. Místo toho bylo velké úsilí věnováno tomu, jak nad ATM provozovat obvyklé aplikace ze světa počítačů a počítačových komunikací, tedy například síťové protokoly IP či IPX, nebo NetBIOS apod. Snad nejvíce to ale platilo pro protokol IP, jehož provozování nad ATM vrstvou by umožnilo budovat výkonné páteřní sítě na bázi ATM a ty pak propojovat s jinými sítěmi, používajícími jiné přenosové technologie než ATM. Nejjednodušší způsob jak provozovat protokol IP nad ATM (přesněji nad adaptační vrstvou AAL, konkrétně obsazenou protokolem AAL5), je protokol IP poněkud upravit - v tom smyslu, že se mu "dá vědět", že funguje nad ATM a že tudíž nesmí používat některé mechanismy, které jindy běžně používá. Jde zejména o možnost všesměrového vysílání, kterou ATM nenabízí, ale kterou protokol IP používá k převodu síťových IP adres na fyzické adresy a naopak. Pokud se protokolu IP zakáže používat všesměrové vysílání, pak vzniká varianta koexistence ATM a IP označovaná jako Classical IP over ATM. Je použitelná v páteřních částech sítě, kde je možné napevno zabudovat fyzické adresy do implementace protokolu IP, tak aby on sám již neměl potřebu příslušné překlady provádět.

 

LANE, LAN Emulation

Řešení "Classical IP over ATM", použitelné v minimálně se měnících páteřních sítích, je přeci jen poněkud nestandardní, protože určitým způsobem mění vlastnosti protokolu IP a "dává mu vědět", že pod ním je ATM. Proto bylo časem vyvinuto i jiné řešení, které také umožňuje provozovat protokol IP nad ATM, ale nemění žádné jeho vlastnosti - ve skutečnosti jde o řešení, které se snaží dokonale skrýt veškerá specifika ATM a vytvořit protokolu IP iluzi, že pracuje nad běžným Ethernetem (nebo nad sítí Token Ring). Jelikož jde vlastně o emulaci chování Ethernetu, resp. Token Ringu, čili dvou nejpoužívanějších přenosových technologií sítí LAN, dostalo toto řešení označení "LAN Emulace" (zkratkou LANE). Jeho nevýhodou je poměrně velká složitost, spojená s emulací, a z ní pak vyplývá i dosti značná neefektivnost. Jen pro ilustraci: emulována musí být i schopnost všesměrového vysílání, která ATM chybí - toho se dosahuje tak, že součástí implementace LANE je i specializovaný server, tzv. BUS server (Broadcast and Unknown Server), jehož povinností je znát všechny existující uzly v daném segmentu sítě. Když pak vyšší vrstvy vysloví požadavek na všesměrové vyslání určitých dat, dostane je ve skutečnosti BUS server a individuálně je rozesílá jednotlivým příjemcům.

 

MPOA, Multiprotocol over ATM

Velkou předností řešení LANE je jeho "neviditelnost" - to, co funguje nad vrstvou LANE, si skutečně může myslet, že pracuje nad Ethernetem, resp. Token Ringem - a tak není nutné příslušné protokoly vyšších vrstev jakkoli měnit, a lze je okamžitě "posadit" nad ATM s LANE. Na druhou stranu ale LANE toto umožňuje pouze protokolu IP, který je sice nejpoužívanější, ale zdaleka ne jediný existující síťový protokol, který je zájem provozovat v ATM sítích. Proto bylo časem vyvinuto i řešení označované jako "Multiprotocol over ATM" (MPOA). Jak už jeho název napovídá, jde o řešení které umožňuje provozovat nad ATM i další síťové protokoly, včetně např. IPX, a to opět bez toho, že by si musely vůbec uvědomovat existenci ATM a přizpůsobovat se mu. Kromě toho však MPOA přináší i některé další výhody. Umožňuje například lokalizovat veškeré směrovací informace i s potřebnou logikou pro jejich průběžnou aktualizaci do jednoho centra (tzv. route serveru), s tím že tyto směrovací informace pak mohou být fakticky využívány větším počtem ATM přepínačů, které se nemusí zabývat jejich generováním ani aktualizací, a mohou tudíž fungovat velmi rychle.