Problémy s využitím ATM

Technologie ATM nežije ve vakuu - ve světě počítačových sítí a komunikací rozhodně není sama. Je proto na místě zamyslet se i nad tím, jak může být navázána na již existující přenosové technologie, protokoly i nejrůznější aplikace.

Na potřebu přizpůsobit vlastnosti technologie ATM představám a nárokům existujících aplikací jsme narazili již dříve - zejména u diskusí nad smyslem adaptační vrstvy ATM. Ta skutečně zakrývá některé odlišnosti ATM od ostatních přenosových technologií, zejména malou velikost jejích buněk, ale jiné rozdíly se zakrývat ani nesnaží - zřejmě nejmarkantnější a nejvýznamnější je to u možnosti tzv. všesměrového vysílání.

Problém všesměrového vysílání v ATM

Většina přenosových technologií, používaných v lokálních sítích (jako například Ethernet), umožňuje tzv. všesměrové vysílání - tedy takové vysílání, které pochází od jednoho uzlu, ale jeho faktickými příjemci mohou být úplně všechny uzly které o to mají zájem. Jinými slovy: co někdo vysílá, to slyší všichni ostatní. Mnohé síťové protokoly a aplikace pak s touto možností bytostně počítají a využívají ji ke svému fungování - například klient si pomocí všesměrového vysílání může vyžádat pomoc nejbližšího serveru (vyšle "do éteru" žádost o pomoc, na kterou zareaguje server schopný pomoc poskytnout).

V ATM však všesměrové vysílání neexistuje. Jak jsme si již dříve uvedli, ATM funguje výlučně spojovaně, a příjemcem každého vysílání je vždy právě a pouze "ten, kdo je na druhém konci". Přeci jen zde ale existuje možnost současného vysílání k více příjemcům - v ATM je možné vytvořit takové spojení, které vede z jednoho zdroje k více příjemcům současně (tedy tzv. multicast), a dokonce jej lze dovést až ke speciálnímu případu, kdy příjemci jsou všechny ostatní uzly (a pak jde o všesměrové vysílání, neboli tzv. broadcast). Dokonce je takovýto druh vícenásobného vysílání (tzv. multicast-u) v ATM podporován již na úrovni ATM vrstvy, protože k "rozvětvování" ATM buněk a k jejich rozesílání různým příjemcům dochází přímo v ATM ústřednách, což činí celý proces dosti efektivním. Navíc je tento druh multicast-u podporován i na úrovni adaptační vrstvy ATM, konkrétně protokolem AAL5 (který se ze všech protokolů AAL používá zdaleka nejvíce, viz minulý díl). Velmi důležité je ale to, že multicast v ATM je pouze jednosměrný - příjemců vysílání sice může být více, ale zdroj je vždy jen jeden. Naproti tomu u všesměrového vysílání (broadcast-u), jaké je obvyklé například v Ethernetu, a jaké předpokládá a využívá většina aplikací i síťových protokolů, může být více i samotných zdrojů (byť nemohou vysílat současně).

Důvod, proč je ATM multicast pouze jednosměrný, je velmi prozaický - ATM buňka, ani její obsah (zejména řídící informace protokolů vrstvy AAL, tj. např. AAL5) neobsahují žádný údaj o tom, kdo je odesilatelem buňky. Tato informace jednoznačně vyplývá ze samotné existence spojení, neboť odesilatelem je vždy "ten, kdo je na začátku spojení". To nebrání tomu, aby příjemců bylo více, ale brání to tomu, aby bylo více i potenciálních odesilatelů - bez identifikace odesilatele by příjemci nedokázali rozlišit, od koho ta která buňka pochází.

VP multicasting

Jednou z možností, jak do světa ATM alespoň dodatečně zavést možnost všesměrového vysílání, či alespoň obousměrného multicast-u, je využít dvousložkového charakteru adresování, resp. dvouúrovňové hierarchie virtuální cesta - virtuální kanál (viz 3. díl tohoto modulu). Nemůže-li mít ATM spojení více zdrojů, pak nechť je toto spojení (odpovídající virtuálnímu kanálu) nahrazeno virtuální cestou, obsahující tolik spojení (kanálů), kolik je potenciálních zdrojů (odesilatelů), přičemž každé spojení v rámci dané cesty povede ke všem potenciálním příjemcům, které je třeba oslovit. Skutečný zdroj (odesilatel) každé jednotlivé ATM buňky pak bude jednoznačně určen identifikátorem kanálu (VCI) v rámci dané virtuální cesty (s jediným identifikátorem VPI).

Právě naznačený princip VP (Virtual Path) multicastingu se ale v ATM prakticky nepoužívá - důvodem je lokální charakter identifikátorů VPI a VCI (viz 3. díl), a z něj vyplývající neschopnost ATM přiřadit všem potenciálním odesilatelům identifikátory platné v celé ATM síti.

Překrývání spojení, aneb přístup hrubou silou

Podobným řešením, které sice připadá v úvahu, ale v praxi se také příliš nepoužívá, je řešení na principu spojení každého se všemi ostatními - každý uzel si zde vytvoří vícenásobné (multicast) spojení se všemi ostatními uzly, byť pouze jednosměrné. Pak sice vzniká funkční ekvivalent možnosti všesměrového vysílání, neboť kterýkoli uzel může oslovit všechny ostatní uzly, a každý příjemce pozná od koho vysílání pochází, ale režie je v tomto případě značná, škálovatelnost špatná, a obtížné jsou i aspekty organizační - když se například připojí nějaký nový uzel, musí nějakým dostupným způsobem oslovit všechny ostatní uzly, a přinutit je rozšířit svá jednosměrná (multicastová) spojení o jeho maličkost.

Řešení s rozesílacími servery

Představa řešení s rozesílacími servery

Mnohem praktičtějším, i když také zdaleka ne nejefektivním řešení, je použití serverů specializovaných na rozesílání - nejlépe je si představit, že v ATM síti se zřídí server (multicast server), který má za úkol vědět o všech uzlech sítě, a na požádání jim rozesílat svěřená data. K tomu mu již postačuje jednosměrné multicastové spojení, které je technologií ATM podporováno - zatímco jednotlivým uzlů, které chtějí služeb tohoto serveru využívat, stačí mít s tímto rozesílacím serverem obousměrné spojení typu bod-bod.

Jak uvidíme v dalších dílech, právě tato varianta napodobování všesměrového vysílání se používá v nejčastějších variantách navázání ATM na ostatní síťové protokoly a aplikace - v rámci tzv. LAN emulace (LANE), i tzv. klasického IP po ATM.

Peer model vs. overlay model ATM

Představa peer modelu (a/) vs. overlay modelu (b/)

Vedle neexistence všesměrového vysílání i obousměrného multicastu je další specifikou ATM konkrétní adresování, používání adresovacích a směrovacích informací a jejich šíření - to je šité na míru světu ATM, a není slučitelné například s tím, jak se obdobné věci řeší třeba v rámci protokolu IP či v prostředí Ethernetu, Token Ringu apod.

Specifické adresovací a směrovací mechanismy, používané v ATM, souvisí s faktem, že autoři ATM dali přednost tzv. překryvnému (overlay) modelu před rovnocenným (peer) modelem pro svou technologii. V čem je jejich rozdíl?

Tzv. peer model předpokládá, že ATM je postaveno na roveň ostatním přenosovým technologiím, ať už na úrovni síťové či linkové vrstvy, tedy například Ethernetu, protokolu IP apod. Na rozhraní mezi ATM a jinou technologií by pak muselo docházet k vhodné formě překladu a "prostupu" příslušných informací skrz ATM síť (například směrovacích informací o dostupnosti konkrétních sítí, k překladu Ethernetových adres na ATM apod.).

Naproti tomu v případě tzv. překryvného modelu (overlay modelu), pro který se autoři ATM nakonec rozhodli, jsou "cizí" technologie položeny nad ATM vrstvy (překrývají je) - což v praxi znamená, že například Ethernetové rámce či IP pakety, směrovací informace apod. prochází skrz ATM sítě prostřednictvím vhodných tunelů, aniž si tento fakt uvědomují, a aniž se mu musí přizpůsobovat. To je také důvod, proč vrstvový model ATM dosti vybočuje z konvencí referenčního modelu ISO/OSI, a ostatně i modelu TCP/IP - ty totiž nepočítají s představou takovéhoto překrývání jedné vrstvy druhou, plnící stejné funkce.

---