Navazování spojení a formát ATM buňky

V dnešním dílu se budeme znovu zabývat problematikou spojení v ATM, a seznámíme se také s formátem ATM buňky.

Jak jsme si již uvedli minule, ATM je výhradně spojovanou technologií, a tudíž předpokládá existenci spojení mezi příjemcem a odesilatelem. Takováto spojení mohou být dvojího druhu - permanentní, existující trvale (a zřizovaná jednorázově provozovatelem ATM sítě po dohodě s uživatelem), a dále komutovaná, zřizovaná v momentě jejich skutečné potřeby, a posléze zase rušená. Jakým způsobem se ale takováto komutovaná spojení navazují?

Navazování spojení v ATM

Pro navazování komutovaného spojení v prostředí ATM existuje několik možností. Nejčastěji používaný způsob vychází z toho, že je právě pro tyto potřeby dopředu vyhrazeno jedno konkrétní (permanentní) spojení, kterým se žadatel o navázání komutovaného spojení může "dovolat" takového subjektu, kterému pak může předat svou žádost. Zmíněným permanentním spojením je virtuální kanál číslo 5, v rámci virtuální cesty číslo 0 (jak jsme si uváděli minule, adresy v ATM jsou dvousložkové, a identifikuje je číslo kanálu a číslo cesty).

Postup navazování komutovaného spojení

Žadatel o zřízení komutovaného spojení tedy může předem vědět, kam svou žádost poslat. Ve skutečnosti je ale celý postup poněkud komplikovanější - na zmíněném kanálu č. 5 a cestě č. 0 se pouze pošle žádost o zřízení speciálního řídícího spojení, a teprve tímto spojením pak žadatel odešle svou faktickou žádost o zřízení "datového" spojení. Důvody jsou ryze praktické - aby pro trvale existující spojení (na kanálu č. 5 a cestě 0) stačila jen zanedbatelná přenosová kapacita, a dostatečná kapacita byla vyhrazena až pro faktické navazování spojení.

Vlastní navazování (i rušení) komutovaného spojení probíhá pomocí šesti druhů zpráv (např. SETUP, CALL PROCEEDING, CONNECT, CONNECT ACK, RELEASE a RELEASE COMPLETE) a prostřednictvím dialogu, který naznačuje dnešní obrázek (navazování spojení). Součástí žádosti o navázání komutovaného spojení samozřejmě musí být i přesná identifikace "druhé strany" - adresy, které se pro tento účel používají, mohou být 20-bytové ISO-adresy, nebo i starší 15-místné adresy, určené pro ISDN telefony.

Vícebodová spojení

Připomeňme si také, že spojení v ATM jsou v zásadě pouze jednosměrná (a podle terminologie obvyklé ve světě spojů tedy jde o tzv. kanály), přičemž ale mohou být zřizována ve dvojicích, a tudíž vytvářet logický ekvivalent obousměrných spojení - s tím, že pro každý z obou směrů může být vyhrazena jiná přenosová kapacita.

Představa rozhraní UNI a NNI

Důležité je také uvědomit si, že spojení (kanály) mohou být nejen dvoubodové (tj. vedoucí od jednoho zdroje k jedinému příjemci), ale mohou být zřizovány také jako vícebodové, vedoucí od jednoho zdroje k více příjemcům současně. Mají přitom charakter tzv. multicastingu, a potřebné "rozesílání" dat je zajišťováno ATM ústřednami, přes které vícebodové spojení prochází a ve kterých se rozvětvuje. Představa navazování takovéhoto vícebodového spojení je přitom následující: nejprve je spojení zřízeno jako dvoubodové, vedoucí k jedinému příjemci. Posléze mohou být k tomuto spojení přidáváni další příjemci, řídícími příkazy s příznačným názvem "ADD PARTY".

Stále je ale nutné mít na paměti, že i takovéto vícebodové spojení je pouze jednosměrné, a nikoli obousměrné. V prostředí ATM nelze vytvořit analogii všesměrového vysílání (což by odpovídalo obousměrnému vícebodovému spojení), a jak později uvidíme, právě tento fakt způsobuje mnoho komplikací při snaze použít ATM místo jiných přenosových technologií typu Ethernetu.

Formát ATM buňky

Dříve, než si popíšeme konkrétní formát ATM buňky, je vhodné se nejprve zmínit o dvou rozhraních, které ATM předpokládá. Jde o rozhraní UNI (User-to-Network Interface) a NNI (Network-to-Network Interface), jejichž smysl naznačuje druhý dnešní obrázek - rozhraní UNI je rozhraním mezi koncovým uzlem a ATM sítí (resp. mezi tímto uzlem a nejbližší ATM ústřednou), zatímco rozhraní NNI je rozhraním mezi dvěma ATM ústřednami. S formátem ATM buňky existence těchto dvou rozhraní souvisí proto, že existují dva různé formáty ATM buňky - jeden pro buňku cestující skrz rozhraní UNI, a druhý pro buňku cestující skrz rozhraní NNI.

Formát ATM buňky

Jak je vidět z dnešního třetího obrázku, jedinou odlišností obou formátů je velikost položky VPI (identifikátoru virtuální cesty) a existence resp. neexistence položky GFC. Tato položka (GFC, alias General Flow Control) byla údajně zamýšlena pro potřeby řízení toku, ale standardy ATM její význam ani způsob využití nedefinují, a konkrétní implementace ji ignorují. Podle jednoho velmi seriózního zdroje (A. Tannenbaum: Computer Networks, vyd. Prentice Hall, 1996) je nejlépe dívat se na tuto položku jako na chybu ve standardu, kterou dosud nikdo neodstranil.

Význam dalších položek hlavičky ATM buňky je vcelku zřejmý: VPI je identifikátor virtuální cesty (viz minule), VCI identifikátor virtuálního kanálu. Třibitová položka PTI (od: Payload Type Identifier) udává, jaký je typ (význam) obsahu nákladové části buňky - zda například jde o uživatelská data nebo o řídící data sloužící komunikaci mezi ATM ústřednami apod. Současně s tím je v této položce obsažena i informace o tom, zda se ATM buňka při své cestě setkala někde se zahlcením. S tímto potenciálním problémem pak souvisí i jednobitová položka CLP (Cell Loss Priority), rozlišující zda daná buňka v případě vážných problémů se zahlcením smí být zahozena "v první vlně" (resp. až v "druhé vlně", neboli až po všech buňkách s menší prioritou). Celá otázka reakce na případné zahlcení je v ATM dosti komplikovaná, a ještě se k ní vrátíme podrobněji.

Poslední položkou v hlavičce ATM buňky je položka HEC (Header Error Control), která slouží potřebám zabezpečení hlavičky. Je osmibitová, a není pouhým kontrolním součtem - jde o samoopravný kód, schopný opravit jednobitovou chybu v kterémkoli bitu hlavičky. Zkušenost totiž ukazuje, že při přenosech po optických vláknech většina případných chyb je pouze jednobitových, a tento samoopravný kód je tudíž dokáže odstranit). Samotný datový náklad ATM buňky (tzv. payload) zebezpečen není.

---