Classical IP over ATM

V minulém dílu tohoto modulu, věnovaného technologii ATM, jsem se začali zabývat možnostmi navázání ATM na stávající přenosové technologie, přenosové protokoly i konkrétní aplikace. Dnes se již dostaneme ke konkrétním příkladům.

K tomu, aby bylo možné provozovat v ATM sítích konkrétní síťové aplikace a protokoly, existují tři principiální přístupy. Prvním z nich je vyvinutí takových aplikací, které budou bezprostředně "šity na míru" technologii ATM, budou využívat její přenosové schopnosti již na úrovni ATM vrstvy, a budou také schopny využít všech vlastností ATM, například tříd služeb (viz 6. díl). Nevýhodou tohoto přístupu je fakt, že takovéto "nativní aplikace", maximálně uzpůsobené technologii ATM, nebudou schopné fungovat jinde než v prostředí ATM, a také jejich spolupráce s ostatními aplikacemi či síťovými protokoly je problematická. Zajímavé je, že sdružení ATM Fórum (organizace, na jejíž půdě probíhá vývoj ATM) se již v roce 1995 rozhodlo nepokračovat v dalším vývoji v tomto směru (konkrétně se jednalo o zastavení vývoje rozhraní API, které by takovéto aplikace používaly).

Druhým principiálním přístupem k provozování aplikací nad ATM je použít již existující aplikace, resp. již existující síťové protokoly, a uzpůsobit je tak, aby dokázaly nad ATM pracovat. "Uzpůsobením" přitom je dopracování takových mechanismů, postupů a technik, které jsou nutné pro využití toho, co ATM nabízí, a případně i zavedení určitých omezení či nastavení parametrů, popisujících chování sítě. Nejznámějším příkladem je zřejmě technika, označovaná jako "Classical IP over ATM", kterou si popíšeme v následujícím odstavci, či techniky MPOA (Multiprotocol over ATM), se kterými se seznámíme později.

Konečně třetím principiálním přístupem k provozování aplikací nad ATM je důkladně skrýt tuto přenosovou technologii a vytvořit aplikacím (resp. síťovým protokolům) věrnou iluzi toho, že pracují v prostředí, které je jim dobře známé - konkrétně například nad Ethernetem či sítí Token Ring. Představitelem tohoto třetího přístupu je technika LAN Emulation (LANE). Pak je z pohledu aplikací a síťových protokolů všechno maximálně jednoduché, protože není potřeba vůbec nic měnit - na druhá straně implementace samotné technologie LANE je značně netriviální záležitostí, a daní za její věrné napodobování Ethernetu či Token Ringu prostřednictvím přenosových schopností ATM je celkově menší efektivnost. Společnou nevýhodou druhého a třetího přístupu je pak skutečnost, že již existující aplikace a síťové protokoly nedokáží využít garance kvality přenosových služeb, které ATM umí nabídnout - protože s existencí něčeho takového vůbec nepočítají.

Jak funguje Classical IP over ATM?

Podívejme se nyní podrobněji na jednu konkrétní variantu realizace druhého možného přístupu - tedy myšlenky vzít již existující síťový protokol a dopracovat k němu to, co je potřebné pro jeho provozování nad ATM. Konkrétním protokolem je zde značně rozšířený protokol IP, používaný na úrovni síťové vrstvy ve všech sítích na bázi protokolů TCP/IP (tedy např. v Internetu), a příslušné řešení pochází od organizace IETF (Internet Engineering Task Force, zabývající se vývojem protokolů TCP/IP), z roku 1994, a je popsáno v dokumentu RFC1577. Výsledné označení "Classical IP over ATM" pak vychází z toho, že se nad technologií ATM může být takto provozován "klasický" protokol IP, byť přeci jen v něčem omezený - má zakázáno všesměrové vysílání, neboli tzv. broadcast (a dokonce i skupinové vysílání, tzv. multicast, protože Classical IP over ATM nepodporuje ani broadcast, ani multicast).

Zapouzdřování pomocí LLC/SNAP

Pro možnost provozování protokolu IP nad ATM bylo nutné vyřešit dva důležité momenty - prvním bylo to, jak poznat co jsou zač ta která data, přenášená pomocí ATM spojení. Classical IP over ATM využívá služeb adaptačního protokolu AAL5 (viz minulý díl), který se dokáže postarat o potřebné rozdělování celých bloků dat na tak malé části, aby je bylo možné vkládat do jednotlivých ATM buněk. Jak jsme si ale již také uvedli, adaptační protokol AAL5 se nijak nesnaží identifikovat přenášená data - proto se potřebná identifikace zajišťuje tím, že bloky dat určené k přenosu se ještě před jejich předání protokolu AAL5 "zapouzdří" (vloží) do standardizovaných linkových rámců LLC/SNAP (viz poslední díl předchozího modulu, který byl věnován Ethernetu).

Překlad adres

Podstatně tvrdším oříškem byl druhý úkol, který bylo nutné vyřešit, a to překlad IP adres na ATM adresy a naopak. Obdobná potřeba například v prostředí Ethernetu (tj. při provozování protokolu IP nad Ethernetem) se řeší pomocí schopnosti všesměrového vysílání, kterou je Ethernet vybaven - zde, v prostředí ATM, však takováto schopnost schází. Proto bylo zvoleno řešení na principu překladových serverů (viz též minulý díl), které si udržují potřebné informace o všech existujících uzlech a jejich IP adresách a odpovídajících ATM adresách, a na požádání zajišťují překlad adres jedním i druhým směrem. Tyto servery jsou označovány jako ATMARP servery, protože nahrazují funkčnost protokolů ARP (Address Resolution Protocol) a RARP (reverse ARP), které jsou v prostředí se všesměrovým vysíláním používány k překladu adres.

Důležité ale je, že pro smysluplnost celého řešení s překladovými servery (ATMARP servery) bylo nutné nějak definovat (vymezit) okruh jejich působnosti - které uzly mají považovat "za své" a pamatovat si o nich vše potřebné, a které již nikoli? Tak vznikl pojem tzv. logické IP podsítě (Logical IP Subnet, zkratkou LIS), který je právě onou "doménou působnosti" každého jednotlivého ATMARP serveru.

Každý uzel přitom musí dopředu znát adresu "svého" ATMARP serveru (standard Classical IP over ATM však neříká explicitně jak, může to být vyřešeno například zanesením této adresy do vhodných konfiguračních tabulek uzlu). Po svém "probuzení" (aktivaci, naběhnutí operačního systému) uzel kontaktuje svůj ATMARP server, oznámí mu svou existenci, a poskytne mu svou ATM a IP adresu. Když pak chce takovýto uzel komunikovat s jiným uzlem, zná jeho IP adresu (což je zajištěno fungováním protokolu IP a dalších protokolů TCP/IP), a s tou se obrátí na ATMARP server (zatímco v prostředí se všesměrovým vysíláním by ke stejnému účelu využil protokol ARP). ATMARP server mu poskytne potřebnou ATM adresu, a uzel si pak může nechat zřídit dočasné (komutované) spojení s příslušným uzlem a provést požadovaný přenos - ten již samozřejmě probíhá přímo, bez účasti ATMARP serveru.

Podotkněme ještě, že celý mechanismus překladu IP adres na ATM adresy a naopak je nutný především pro navazování komutovaných ATM spojení - v případě permanentních spojení, navazovaných zásahem operátora, lze vše řešit dopředu, "ručně".

ATM směrovače a domény LIS

Jak již samotný název napovídá, "doména" LIS (Logical IP Subnet) odpovídá skutečně IP síti - dokonce i v tom smyslu, že cesta z jedné takovéto domény LIS (IP sítě) do jiné LIS (či jiné, "skutečné" IP sítě) může vést jen přes IP směrovač. Tím může být jakýkoli IP směrovač, vybavený alespoň jedním ATM rozhraním s podporou Classical IP over ATM (zatímco další rozhraní mohou vést jak do dalších ATM sítí, tak i do ne-ATM sítí). Přestup do ne-ATM sítí je díky tomu velmi jednoduchý, ale přestup do jiné ATM sítě může být zdrojem značné neefektivnosti - pokud se totiž jedná o dvě domény LIS, které ale "fyzicky splývají", neboli jsou připojeny ke stejné ATM síti (neboli: mezi jejich uzly jsou pouze ATM ústředny, a může tedy mezi nimi vést přímé ATM spojení), pak i v tomto případě musí veškerý provoz z jedné LIS do druhé LIS procházet přes příslušný IP směrovač (zatímco "fyzicky" by nemusel").