Referenční model ISO/OSI - jeho vznik

V sedmdesátých letech se začínají objevovat první významnější rozlehlé počítačové sítě. Vedle experimentálních sítí (jako např. ARPANET a CYCLADES), to byly především sítě, budované podle vlastních koncepcí předních výrobců počítačů (např. sítě SNA firmy IBM, DNA firmy DEC). Zatímco experimentální sítě byly od začátku heterogenní a přímo tedy počítaly se zapojováním počítačů různých typů od různých výrobců, možnost zapojení do ostatních sítí byla vázána na vlastnictví produktů příslušného výrobce, který si v rámci vlastní síťové architektury vytvářel své specifické konvence a protokoly.

Není proto divu, že záhy vyvstala naléhavá potřeba jednotného standardu pro vzájemné propojování počítačových systémů různých typů a koncepcí, pocházejících od různých výrobců. Potřebu vytvoření takovéhoto standardu si brzy uvědomila i mezinárodní organizace ISO, která se v roce 1977 rozhodla převzít tento úkol na svá bedra.

Vytvořila si k tomu novou podkomisi (SC16) v rámci své technické komise pro zpracování dat (TC97, viz 21. Kapitola), a tu pověřila přípravou nového standardu. Ten také již dostal první pracovní název: Open Systems Architecture (tj. architektura otevřených systémů). Přívlastek "otevřený" (open) zde měl zdůraznit, že systém, vyhovující zamýšlenému standardu, bude připraven pro vzájemné propojení se všemi ostatními systémy na celém světě, které budou vyhovovat témuž standardu.

První pracovní schůzka podskupiny SC16 se konala v březnu 1978. Všichni zúčastnění se rychle shodli na vrstvové koncepci, která nejen dokáže vyhovět všem stávajícím nárokům na vzájemné propojování otevřených systémů, ale je schopná i pozdějšího rozšiřování tak, aby mohla vyhovět i budoucím požadavkům. Podskupina SC 16 se proto začala okamžitě zabývat otázkou, kolik vrstev bude nejvhodnější uvažovat, a jaké úkoly těmto vrstvám svěřit. Pro potřeby svého rozhodování si podskupina SC16 zformulovala celkem 13 principů, které se pak snažila aplikovat.

 

Lze je shrnout do následujících myšlenek:

 

Výsledkem aplikace těchto principů bylo vymezení sedmi vrstev a specifikace úkolů, které by tyto vrstvy měly zajišťovat. (Podrobněji se jim budeme zabývat v dalších pokračováních)

Ještě v průběhu práce na připravovaném standardu změnila podskupina SC16 i jeho pracovní název, z Open Systems Architecture na Open Systems Interconnection Architecture, doslova tedy: architektura vzájemného propojování otevřených systémů. Důvodem byla zřejmě skutečnost, že se celá práce skupiny zaměřila pouze na otázky propojování a "vnějšího chování" vzájemně propojených systémů, a nijak neřešila to, jak mají tyto systémy fungovat "uvnitř".

Vlastní návrh standardu byl dokončen za necelých 18 měsíců. V červenci roku 1979 byl předán jako koncept návrhu (draft proposal) nadřízené technické komisi TC97, která jej koncem roku 1979 přijala za základ pro další vývoj navazujících standardů pro vzájemné propojování otevřených systémů v rámci organizace ISO.

Na poslední chvíli však byl ještě jednou změněn slovní název standardu - z blíže neznámých důvodů bylo vypuštěno slovo Architecture, a naopak byla přidána dvě nová slova: Reference Model neboli referenční model. Ta mají zdůraznit, že celý standard není jedním konkrétním návrhem způsobu, jak řešit vzájemné propojování, ale spíše společným rámcem či vzorem (referenčním modelem), podle kterého by mělo být vzájemné propojování systémů řešeno.

Správný název celého standardu je tedy: Reference Model of Open Systems Interconnection (Referenční model propojování otevřených systémů), a jako norma ISO má číslo 7498. V praxi se obvykle označuje zkratkou RM OSI nebo jen ISO/OSI, což současně zdůrazňuje jeho vztah k organizaci ISO (byl však současně převzat i organizací CCITT jako její standard X.200).

Zdůrazněme si znovu, že součástí referenčního modelu ISO/OSI je skutečně pouze vymezení jednotlivých vrstev a spefifikace úkolů, které by tyto vrstvy měly řešit. Referenční model nespecifikuje žádné konkrétní protokoly, pomocí kterých by funkce jednotlivých vrstev měly být realizovány. Nedefinuje dokonce ani přesné rozhraní mezi jednotlivými vrstvami - tedy konkrétní služby, které vrstvy bezprostředně nižší poskytují bezprostředně vyšším vrstvám.

Protokoly a služby pro jednotlivé vrstvy vznikaly až dodatečně, a to jako samostatné standardy (resp. normy) ISO, nebo jako převzaté standardy jiných organizací (např. CCITT či IEEE). Jelikož organizace ISO striktně rozlišuje mezi protokolem a službou (na rozdíl od ostatních standardizačních organizací, jako např. CCITT, které takovéto rozlišování nepoužívají), vznikaly původní standardy ISO vždy ve dvojicích - jeden standard pro protokol, a druhý pro služby, poskytované prostřednictvím tohoto protokolu. Postupně tak vznikaly resp. stále vznikají či jsou přejímány protokoly, definující možné způsoby fungování jednotlivých vrstev ISO/OSI modelu.

 

Referenční model ISO/OSI - sedm vrstev

Jak jsme si uvedli v předcházejícím dílu našeho seriálu, dospěli tvůrci referenčního modelu ISO/OSI při svých úvahách k závěru, že optimální počet vrstev síťového softwaru bude sedm. Jaké vrstvy to jsou a jaké úkoly mají řešit? Vezměme to postupně zdola nahoru, od nejnižší vrstvy k nejvyšší:

1. Fyzická vrstva (Physical Layer)

Úkol této vrstvy je zdánlivě velmi jednoduchý - zajistit přenos jednotlivých bitů mezi příjemcem a odesilatelem prostřednictvím fyzické přenosové cesty, kterou tato vrstva bezprostředně ovládá. K tomu je ovšem třeba vyřešit mnoho otázek převážně technického charakteru - např. jakou úrovní napětí bude reprezentována logická jednička a jakou logická nula, jak dlouho "trvá" jeden bit, kolik kontaktů a jaký tvar mají mít konektory kabelů, jaké signály jsou těmito kabely přenášeny, jaký je jejich význam, časový průběh apod. Problematika fyzické vrstvy proto spadá spíše do působnosti elektroinženýrů a techniků.

2. Linková vrstva (Data Link Layer)

Fyzická vrstva poskytuje jako své služby prostředky pro přenos jednotlivých bitů. Bezprostředně vyšší linková vrstva (někdy nazývaná též: spojová vrstva či vrstva datového spoje) pak má za úkol zajistit pomocí těchto služeb bezchybný přenos celých bloků dat (velikosti řádově stovek bytů), označovaných jako rámce (frames). Jelikož fyzická vrstva nijak neinterpretuje jednotlivé přenášené bity, je na linkové vrstvě, aby správně rozpoznala začátek a konec rámce, i jeho jednotlivé části.

Na přenosové cestě může docházet k nejrůznějším poruchám a rušení, v jejichž důsledku jsou přijaty jiné hodnoty bitů, než jaké byly původně vyslány. Jelikož fyzická vrstva se nezabývá významem jednotlivých bitů, rozpozná tento druh chyb až linková vrstva. Ta kontroluje celé rámce, zda byly přeneseny správně (podle různých kontrolních součtů, viz 3. díl našeho seriálu). Odesilateli potvrzuje přijetí bezchybně přenesených rámců, zatímco v případě poškozených rámců si vyžádá jejich opětovné vyslání.

3. Síťová vrstva (Network Layer)

Linková vrstva zajišťuje přenos celých rámců, ovšem pouze mezi dvěma uzly, mezi kterými vede přímé spojení. Co ale dělat, když spojení mezi příjemcem a odesilatelem není přímé, ale vede přes jeden či více mezilehlých uzlů? Pak musí nastoupit síťová vrstva, která zajistí potřebné směrování (routing) přenášených rámců, označovaných nyní již jako pakety (packets). Síťová vrstva tedy zajišťuje volbu vhodné trasy resp. cesty (route) přes mezilehlé uzly, a také postupné předávání jednotlivých paketů po této trase od původního odesilatele až ke konečnému příjemci.

Síťová vrstva si tedy musí "uvědomovat" konkrétní topologii sítě (tj. způsob vzájemného přímého propojení jednotlivých uzlů).

4. Transportní vrstva (Transport Layer)

Síťová vrstva poskytuje bezprostředně vyšší vrstvě služby, zajišťující přenos paketů mezi libovolnými dvěma uzly sítě. Transportní vrstvu proto zcela odstiňuje od skutečné topologie sítě a vytváří jí tak iluzi, že každý uzel sítě má přímé spojení s kterýmkoli jiným uzlem sítě.

Transportní vrstvě díky tomu stačí zabývat se již jen komunikací koncových účastníků (tzv. end-to-end komunikací) - tedy komunikací mezi původním odesilatelem a konečným příjemcem.

Při odesílání dat zajišťuje transportní vrstva sestavování jednotlivých paketů, do kterých rozděluje přenášená data, a při příjmu je zase z paketů vyjímá a skládá do původního tvaru. Dokáže tak zajistit přenos libovolně velkých zpráv, přestože jednotlivé pakety mají omezenou velikost.

5. Relační vrstva (Session Layer)

Úkolem této vrstvy je navazování, udržování a rušení relací (sessions) mezi koncovými účastníky. V rámci navazování relace si tato vrstva vyžádá na transportní vrstvě vytvoření spojení, prostřednictvím kterého pak probíhá komunikace mezi oběma účastníky relace. Pokud je třeba tuto komunikaci nějak řídit (např. určovat, kdo má kdy vysílat, nemohou-li to dělat oba účastníci současně), zajišťuje to právě tato vrstva, která má také na starosti vše, co je potřeba k ukončení relace a zrušení existujícího spojení.

6. Prezentační vrstva (Presentation Layer)

Data, která se prostřednictvím sítě přenáší, mohou mít mj. povahu textů, čísel či obecnějších datových struktur. Jednotlivé uzlové počítače však mohou používat odlišnou vnitřní reprezentaci těchto dat - např. střediskové počítače firmy IBM používají znakový kód EBCDIC, zatímco většina ostatních pracuje s kódem ASCII. Podobně jeden počítač může zobrazovat celá čísla v doplňkovém kódu, zatímco jiný počítač v přímém kódu apod. - potřebné konverze přenášených dat má na starosti právě tato prezentační vrstva.

V rámci této vrstvy bývá také realizována případná komprese přenášených dat, eventuálně i jejich šifrování.

7. Aplikační vrstva (Application Layer)

Koncoví uživatelé využívají počítačové sítě prostřednictvím nejrůznějších síťových aplikací - systémů elektronické pošty, přenosu souborů, vzdáleného přihlašování (remote login) apod. Začleňovat všechny tyto různorodé aplikace přímo do aplikační vrstvy by pro jejich velkou různorodost nebylo rozumné. Proto se do aplikační vrstvy zahrnují jen části těchto aplikací, které realizují společné resp. obecně použitelné mechanismy. Uvažujme jako příklad právě elektronickou poštu - ta její část, která zajišťuje vlastní předávání zpráv v síti, je součástí aplikační vrstvy. Na všech uzlových počítačích, které používají tentýž systém elektronické pošty, je tato část stejná. Uživatelské rozhraní systému elektronické pošty, tedy ta jeho část, se kterou uživatel bezprostředně pracuje a jejímž prostřednictvím čte došlé zprávy, odpovídá na ně, připravuje nové zprávy a zadává je k odeslání, již není považována za součást aplikační vrstvy, neboť se může v každém konkrétním uzlu dosti výrazně lišit - např. ve způsobu svého ovládání (řádkovými příkazy či pomocí různých menu, s okénky či bez nich apod.). Jiným názorným příkladem může být emulace terminálů, potřebná např. pro vzdálené přihlašování (remote login). Ve světě dnes existuje nepřeberné množství různých terminálů, a realizovat potřebné přizpůsobení mezi libovolnými dvěma typy terminálů je v podstatě nemožné. Proto se zavádí jediný "referenční" terminál - tzv. virtuální terminál - a pro každý konkrétní typ terminálu se pak vytvoří jen jediné přizpůsobení mezi tímto virtuálním terminálem a terminálem skutečným. Prostředky pro práci s virtuálním terminálem přitom jsou součástí aplikační vrstvy (neboť jsou všude stejné), zatímco prostředky pro jeho přizpůsobení konkrétnímu terminálu již součástí aplikační vrstvy nejsou.

 

Referenční model ISO/OSI - přenos dat

Ve 22. kapitole jsme si naznačili základní myšlenku, na které je založena funkce všech vrstvových modelů: že každá vrstva využívá služeb vrstvy bezprostředně nižší, a sama nabízí své služby vrstvě bezprostředně vyšší. Upřesněme si nyní tuto obecnou představu právě na příkladu referenčního modelu ISO/OSI a jeho terminologie a ukažme si, jak se projevuje při přenosu dat.

Ten, kdo v určité vrstvě ISO/OSI modelu něco aktivního vykonává, je označován jako entita (entity). Bývá to nejčastěji objekt programové povahy (např. určitý proces), v nejnižších vrstvách to však může být i hardwarový celek (např. V/V řadič apod.). Na úrovni aplikační vrstvy jde o aplikační entity (application entities), na úrovni prezentační vrstvy o prezentační entity (presentation entities) atd. Entity na stejné úrovni, resp. ve stejnolehlých vrstvách se v angličtině označují přívlastkem peer (tj. jako peer entities).

Entity ve vrstvě N implementují služby, které jsou využívány vrstvou N+1, resp. entitami této vrstvy. Vrstva N zde tedy vystupuje jako poskytovatel služby (service provider), zatímco vrstva N+1 je v roli uživatele služby (service user). Vrstva N je však současně i v roli uživatele služeb vůči vrstvě N-1, neboť využívá její služby.

Bezprostředními poskytovateli a uživateli služeb však nejsou vrstvy jako takové, ale jejich entity. Každá entita, která chce nějaké služby využívat, však musí vědět, kam se má pro ně obrátit. Musí tedy existovat jednoznačně identifikovatelná místa v rámci rozhraní mezi jednotlivými vrstvami, jejichž prostřednictvím jsou služby poskytovány, resp. využívány. V terminologii ISO/OSI modelu se tato místa nazývají body poskytování služby (Service Access Points, zkratkou SAP) a jsou opatřena jednoznačnými adresami. Pro snazší představu je dobré využít analogii s telefonní sítí: bod poskytování služby neboli SAP je analogií zásuvky běžné telefonní přípojky, do které lze zapojit telefonní přístroj (odpovídající entitě vrstvy N+1). Chceme-li se pak dovolat na tento telefonní přístroj (poskytnout službu entitě vrstvy N+1), musíme znát příslušné telefonní číslo (adresu bodu SAP).

Každý bod SAP slouží vždy vzájemné komunikaci právě dvou entit ze sousedních vrstev. Nemůže být tedy sdílen více entitami. Každá entita však může poskytovat své služby více entitám prostřednictvím více bodů SAP a stejně tak každá entita může využívat služby více různých entit přes více bodů SAP.

Každá entita, která chce využívat službu jiné entity bezprostředně nižší vrstvy, musí znát nejen potřebný bod SAP, přes který je jí tato služba nabízena, ale musí také znát přesný způsob volání příslušné služby. Ten je samozřejmě pro různé služby různý, vždy však vyžaduje, aby volající předal volanému určitý objem řídicích informací, které jeho požadavek specifikují. V terminologii ISO/OSI modelu je tato řídicí informace označována jako Interface Control Information (ICI). Součástí požadavku pak bývají ještě různá "užitečná" data, označovaná jako Service Data Unit (SDU). Volající entita tedy v obecném případě předává volané entitě přes příslušný bod SAP na rozhraní mezi nimi dvě skupiny informací (tj. ICI a SDU), které dohromady tvoří tzv. datovou jednotku rozhraní (Interface Data Unit, zkratkou IDU).

Entita, která je poskytovatelem služby a která je příjemcem jednotky IDU, si převezme řídicí informace obsažené v IDU (tj. část ICI). Z ní se dozví, co je od ní požadováno, a podle toho dále naloží s datovou částí (části SDU).

Jedním z nejčastějších požadavků entity ve vrstvě N+1 je žádost o přenos dat stejnolehlé entitě (tj. entitě vrstvy N+1) na jiném uzlovém počítači. Entita vrstvy N, která je o tuto službu požádána, nalezne příslušná data v části SDU přijaté jednotky IDU a snaží se je předat své partnerské entitě na příslušném uzlovém počítači. S touto stejnolehlou entitou komunikuje podle určitého protokolu.

Tento protokol mimo jiné určuje, jak velké "kusy" dat si mohou obě vrstvy posílat a jakými dodatečnými informacemi řídicí povahy musí být tato užitačná data doplněna. Odesílací entita vrstvy N proto rozdělí data z jednotky SDU na tak velké části, jaké jí protokol umožňuje přenášet a připojí k nim potřebné řídicí informace. Tím vzniká tzv. protokolární datová jednotka (PDU, Protocol Data Unit), tvořená kromě užitečných dat (tj. složky SDU) také složkou PCI (Protocol Control Information), který obsahuje informace řídicí povahy, předepsané použitým přenosovým protokolem.

Partnerské entity stejnolehlých vrstev si tedy vzájemně zasílají jednotky PDU (ve formě zpráv, paketů, resp. rámců). Ve skutečnosti to ale doopravdy dělají jen entity fyzické vrstvy, pro které jsou celými jednotkami PDU jednotlivé bity, a které jsou schopné si je navzájem skutečně předávat. Všechny ostatní (tj. vyšší) vrstvy si jednotky PDU vyměňují prostřednictvím entit bezprostředně nižších vrstev - při odesílání se z celé jednotky PDU stávají "užitečná" data (složka SDU). K nim se přidá potřebná řídicí informace (složka ICI) a tím vzniká datová jednotka rozhraní (jednotka IDU), která je přes bod SAP předána entitě bezprostředně nižší vrstvy ... a vše se opakuje až do úrovně fyzické vrstvy.

Každá vrstva na straně odesilatele v závislosti na použitém protokolu přidává k užitečným datům (jednotkám SDU) své řídicí informace (složky PCI) - obvykle ve formě hlavičky, kterou si pak stejnolehlá partnerská vrstva na straně příjemce zase odebírá.

 

Referenční model ISO/OSI - druhy služeb

Na referenčním modelu ISO/OSI se silně projevila skutečnost, že při jeho koncipování měli hlavní slovo lidé spíše "od spojů", než "od počítačů". Celý model je totiž prodchnut spojařskou mentalitou a pohledem na svět, což se projevilo například ve výhradní podpoře tzv. spojovaných služeb na úkor služeb nespojovaných, a v představě o způsobu realizace těchto služeb.

Služby, které poskytují vrstvy různých úrovní, mohou mít charakter spojovaných či nespojovaných služeb. Spojovaná služba (Connection-oriented Service) pracuje na obdobném principu, jako telefonní systém. Chcete-li s někým hovořit po telefonu, musíte nejprve vytočit jeho číslo, a on musí na vaše volání odpovědět zvednutím telefonu. Tím mezi vámi vzniká spojení, prostřednictvím kterého spolu komunikujete, a které na konci hovoru zaniká (položením sluchátka). Analogicky je tomu i v případě dvou entit na stejných úrovních, které spolu chtějí komunikovat - nejprve musí být mezi nimi navázáno spojení. Jakmile je toto spojení navázáno, chová se v jistém smyslu jako roura - vysílající do ní na jedné straně vkládá to, co si přeje odeslat, a příjemce si to na druhé straně ve stejném pořadí odebírá.

Nespojovanou službu (Connectionless Service) lze naopak přirovnat k běžné listovní poště. Ta nepočítá se zřízením spojení mezi odesilatele a příjemcem, ale místo toho považuje jednotlivé části přenášených dat (zprávy) za samostatné celky, opatřené adresou svého konečného příjemce, a doručuje je nezávisle na ostatních zprávách. Jednotlivé zprávy tedy mohou být v principu přenášeny různými cestami, takže se může i stát, že při příjmu nebude zachováno jejich správné pořadí - což se u spojované služby stát nemůže.

Spojovaný (connection-oriented) charakter mají jak telefonní sítě, tak i např. většina veřejných datových sítí a jiných telekomunikačních systémů, zatímco např. v lokálních sítích mají přenosy obvykle nespojovaný (connectionless) charakter. Původní verze referenčního modelu ISO/OSI však počítala pouze se spojovanými (connection-oriented) službami a protokoly, a zavedení nespojovaných bylo provedeno až dodatečně.

Spojované služby jsou v obecném případě výhodnější pro přenos větších objemů dat. Mají sice větší jednorázovou počáteční režii (na navázání spojení), ale na druhé straně vykazují menší režii na vlastní přenos dat. Naopak nespojované služby nemají prakticky žádnou jednorázovou režii, mají však relativně vyšší režii na vlastní přenos jednotlivých částí přenášených dat. Jsou proto naopak výhodnější pro přenos menších objemů dat (tj. kratších zpráv).

Je dobré si uvědomit, že spojovaný resp. nespojovaný charakter mohou mít služby všech vrstev od aplikační po linkovou (zatímco na úrovni fyzické vrstvy již rozlišování mezi oběma variantami ztrácí smysl). V 16. Kapitole, ve které jsme se zabývali veřejnými datovými sítěmi, jsme si ukazovali příklady takovýchto služeb na úrovni síťové vrstvy - přepojování okruhů a virtuálních okruhů (které mají spojovaný charakter) a datagramové služby (která má nespojovaný charakter). V dalších pokračováních našeho seriálu si ukážeme, že služby spojovaného a nespojovaného charakteru existují mj. i na úrovni transportní vrstvy, a že např. nespojovaná transportní služba může být implementována prostřednictvím služby síťové vrstvy, která má naopak spojovaný charakter.

Kromě rozdělování služeb na spojované a nespojované je možné i jiné rozdělení - na spolehlivé a nespolehlivé.

Spolehlivá služba (Reliable Service) je taková, která nikdy neztrácí žádná data. Obvykle je tato služba realizována prostřednictvím vhodného mechanismu potvrzování (kdy příjemce potvrzuje úspěšné přijetí resp. znovu žádá o vyslání dat, které byly přijaty chybně). S tím je ovšem spojena určitá režie, která nemusí být vždy žádoucí - představme si např. přenos digitalizovaného zvuku. Zde je jistě výhodnější raději občas přijmout chybná data (tj. poněkud zkreslený zvuk), než připustit výpadky, způsobované potvrzováním resp. opakovaným přenosem chybně přijatých dat.

Proto mají své opodstatnění i nespolehlivé služby (Unreliable Services), což je ovšem poněkud zavádějící označení - je vhodné chápat je spíše jako služby, které mají vysokou míru spolehlivosti, neposkytují však stoprocentní záruku úspěšnosti přenosu. Jelikož ale nepoužívají mechanismy potvrzování (spojené s určitou režií), mohou být rychlejší než obdobné "spolehlivé" služby.

Prakticky jediným možným způsobem, jak zajistit spolehlivou službu, je vhodný mechanismus potvrzování. Dělení služeb na potrvzované (confirmed) a nepotvrzované (unconfirmed) proto obvykle splývá s jejich dělením na "spolehlivé" resp. "nespolehlivé".

Jak jsme si již uvedli dříve, samotný referenční model ISO/OSI neobsahuje přesné vymezení služeb, které jednotlivé vrstvy poskytují vrstvám bezprostředně nadřízeným. Zavádí pouze dosti obecnou představu o tom, jakým způsobem by mělo být zprostředkováno využití těchto služeb na rozhraní mezi jednotlivými vrstvami - prostřednictvím čtyř druhů tzv. služebních primitiv (service primitives). Ty je možné si představit jako požadavky na provedení určitých konkrétních akcí, nebo naopak jako signalizaci určitých situací, hodných zřetele.

Uvažujme jako příklad potvrzovanou službu, např. zřízení spojení mezi dvěma partnerskými entitami stejnolehlých vrstev. Poskytovatelem služby je entita bezprostředně nižší vrstvy, které musí žadatel o zřízení spojení předat svou žádost ve formě primitiva typu požadavek (request). Entitě, se kterou má být spojení navázáno, se požadavek projeví jako indikace (indication), která je dalším typem služebního primitiva. Jde-li o službu potvrzovanou, následuje odezva (response), která pak vyvolá potvrzení (confirmation).

Zamysleme se ale ještě jednou nad tím, co vlastně jsou ona poněkud vágní "služební primitiva", a to z pohledu programové realizace jednotlivých služeb. Jsou služební primitiva procedury, které vyšší vrstva volá a bezprostředně nižší vrstva vykonává? V případě "požadavku" a "odezvy" je to asi představa dosti vhodná, co ale v případě "indikace" a "potvrzení", které mají příjemce upozornit na určitou skutečnost, a kterou sám nemusí vůbec očekávat? Zde již představa explicitně volané procedury selhává. Vhodnější by byla spíše představa asynchronního přerušení příjemce, což ale jen velmi málo vyhovuje dnešním vyšším programovacím jazykům a je zcela ve sporu se všemi zásadami strukturovaného programování. Z čistě spojařského pohledu na svět je to ale představa velmi přirozená - např. obyčejný telefon v důsledku "indikace" začne vesele zvonit.

 

Fyzická vrstva

Jak jsme si uvedli již dříve, úkol fyzické vrstvy v rámci referenčního modelu ISO/OSI je zdánlivě velmi jednoduchý - zajistit přenos jednotlivých bitů mezi příjemcem a odesilatelem.

V předchozích dílech našeho seriálu jsme si také naznačili, že možných prostředků pro vlastní přenos dat je celá řada - od nejrůznějších kabelů, telefonních okruhů, přes veřejné datové sítě až např. po satelitní spoje - a že tyto se více či méně liší ve způsobu přenosu, dosažitelných přenosových rychlostech, způsobu ovládání i v dalších aspektech. Je právě úkolem fyzické vrstvy, aby se přizpůsobila konkrétním přenosovým prostředkům, vytvořila potřebné rozhraní pro jejich připojení k uzlovému počítači sítě, a prostřednictvím tohoto rozhraní je také ovládala.

Fyzické vrstvy se proto týkají standardy, které definují elektrické, mechanické, funkční a procedurální vlastnosti rozhraní pro připojení různých přenosových prostředků a zařízení (tj. kabelů, modemů apod.) - tedy elektrické parametry přenášených signálů, jejich význam a časový průběh, vzájemné návaznosti řídících a stavových signálů, zapojení konektorů, a mnoho dalších parametrů technického i procedurálního charakteru. Úkolem entit fyzické vrstvy je pak na základě těchto standardů obsluhovat přenosové prostředky, připojené k příslušným rozhraním, a jejich prostřednictvím zajišťovat přenosy jednotlivých bitů.

Způsob připojování modemů k počítačům a terminálům definuje standard RS-232-C (Recommended Standard no. 232, revision C), pocházející od americké standardizační organizace EIA (viz 22. díl našeho seriálu). Ten vymezuje přesné rozhraní mezi dvěma druhy zařízení, které se v terminologii tohoto standardu označují jako DTE (Data Terminal Equipment, v překladu: KZD neboli Koncové Zařízení přenosu Dat), a DCE (Data Circuit-Terminating Equipment, v překladu: UZD neboli Ukončující Zařízení Datového okruhu - viz 8. díl našeho seriálu). Zařízením DTE je např. počítač nebo terminál, zatímco zařízením DCE je modem. Standard RS-232-C definuje nejen počet a znam jednotlivých signálů rozhraní mezi zařízeními DTE-DCE, zapojení konektorů, ale také elektrické parametry přenášených signálů (mj. napěťové úrovně, které vyjadřují jednotlivé stavy těchto signálů). Prakticky shodný standard resp. doporučení s označení V.24 pochází od organizace CCITT (liší se jen v několika málo zřídka používaných signálech). Doporučení V.24 však na rozdíl od standardu RS-232-C nedefinuje přesné elektrické parametry přenášených signálů (v terminologii doporučení V.24: obvodů) - ty specifikuje až doplňkové doporučení V.28.

Ačkoli byly oba tyto prakticky ekvivalentní standardy vyvinuty právě pro připojování modemů k počítačům a terminálů, používají se dnes i k jiným účelům, např. pro připojování tiskáren či jiných periferií (se sériovým rozhraním) k počítačům, a také ke vzájemnému propojování počítačů (tj. k propojování dvou zařízení DTE). V našem seriálu se budeme oběma těmito standardy ještě zabývat podrobněji.

Nevýhodou standardů RS-232-C a V.24 (+ V.28) je maximální dosah přibližně 15 metrů, a maximální přenosová rychlost do 20 kbit/sekundu. Většího dosahu a vyšších přenosových rychlostí lze obecně dosáhnout jen s elektrickými signály jiných parametrů. Proto byly vytvořeny další standardy (doporučení CCITT) V.10 a V.11, které jsou alternativou k doporučení V.28 (tj. definují právě a pouze elektrické parametry přenášených signálů). Předpokládají použití výkonnějších budičů a přijímačů (po řadě nesymetrických resp. symetrických, tj. takových, které přenášený logický signál vyjadřují napětím mezi jedním signálovým vodičem a zemí, resp. rozdílem napětí mezi dvěma signálovými vodiči), a umožňují dosahovat přenosové rychlosti až 10 Mbit/sekundu. Doporučení V.10 a V.11 mají své ekvivalenty v doporučeních CCITT X.26 resp. X.27, a také v doporučeních EIA (konkrétně RS-423-A resp. RS-422-A).

Standard RS-232-C je již poměrně starého data (byl poprvé publikován v roce 1969). Koncem 70. let se jej organizace EIA rozhodla nahradit novějším standardem RS-449. Ten zavádí některé nové signály (především pro potřeby testování) a předpokládá použití jiných konektorů, na rozdíl od svého předchůdce však již nedefinuje elektrické charakteristiky přenášených signálů - pro ně přejímá standardy RS-423-A a RS-422-A.

Nový standard RS-449 se však přes velkou snahu organizace EIA v praxi neujal (zřejmě pro přílišnou komplikovanost oproti svému předchůdci). Proto EIA počátkem roku 1987 přišla s novou verzí (revizí D) standardu RS-232, nyní tedy s označení RS-232-D, která oproti verzi RS-232-C přidává dva nové signály (pro testování modemů).

Způsob připojování počítačů k digitálním okruhům a k veřejným datovým sítím definuje doporučení X.21 CCITT z roku 1976. To sice zasahuje až do síťové vrstvy (neboť obsahuje popis řízení činnosti v síti s přepojováním okruhů), na úrovni fyzické vrstvy však definuje počet a význam přenášených signálů i zapojení konektorů. Nedefinuje však již elektrické vlastnosti přenášených signálů - k tomuto účelu přejímá doporučení V.10/X.26 a V.11/X.27. Kromě doporučení X.21 existuje i alternativní doporučení X.21(bis), které je podmnožinou standardů RS-232-C/V.24, definuje způsob připojování k analogovým přenosovým sítím, a je zamýšleno jako dočasný standard pro dobu, kdy digitální sítě ještě nejsou všeobecně rozšířené.

Fyzickou vrstvu pokrývají také standardy řady 802, pocházející od sdružení IEEE, které jsou určené pro lokální sítě (a my se jimi samozřejmě budeme zabývat podrobněji). Nejzajímavější je z tohoto pohledu zřejmě standard IEEE 802.3 pro sběrnicové lokální sítě s přístupovou metodou CSMA/CD (označované poněkud nepřesně jako sítě typu Ethernet). Tento standard totiž ve své původní verzi (z roku 1985) předpokládal pouze použití tzv. tlustého koaxiálního kabelu (Thick Ethernet, viz 19. díl našeho seriálu). Poměrně brzy však bylo přijato několik doplňků standardu IEEE 802.3, které umožnily využít i jiná přenosová média - od tzv. tenkého Ethernetu, přes koaxiální kabel s přenosem v přeloženém pásmu, až po běžnou kroucenou dvoulinku a optická vlákna. Jednotlivé doplňkové standardy (včetně původního) pak dostaly i výstižná označení, která shrnuje tabulka 28.2. Obdobný vývoj, jako u IEEE 802.3, lze pozorovat i u ostatním standardů řady 802.

Vlastní specifické řešení na úrovni fyzické vrstvy vyžadují také některé novější přenosové technologie a prostředky. Fyzickou vrstvu proto pokrývají i standardy resp. doporučení, které použití těchto prostředků resp. technologií definují, například:

- pro optické přenosy doporučení ISO 9314, které definujestandard FDDI (Fiber Distributed Data Interface),

- pro sítě ISDN doporučení CCITT I.430, (které se týká výhradně fyzické vrstvy)

 

Linková vrstva - I.

Fyzická vrstva ISO/OSI modelu zajišťuje přenos jednotlivých bitů mezi dvěma uzlovými počítači, mezi kterými existuje přímé spojení (tj. vhodný komunikační kanál resp. okruh). Linková vrstva pak využívá těchto prostředků pro přenos větších bloků dat, označovaných jako rámce (frames), a přenos těchto rámců pak sama nabízí jako svou službu bezprostředně vyšší vrstvě - vrstvě síťové.

Fyzická vrstva však nijak nerozlišuje jednotlivé bity, které přenáší. Je proto na linkové vrstvě, aby sama zajistila jejich správnou interpretaci - aby dokázala rozpoznat, které bity resp. skupiny bitů představují řídící informace (např. signalizují začátek či konec bloku, udávají jeho délku apod.), a které bity představují vlastní "užitečná" data.

V případě asynchronního přenosu - viz 1. kapitola našeho seriálu - jsou přenášená data členěna na znaky (stejně velké skupiny bitů). Tyto jsou pak pro potřeby přenosu "obaleny" tzv. start a stop bity, které příjemci umožňují správně rozpoznat začátek a konec znaku. Potřebujeme-li pak přenášet data, tvořená posloupnostmi běžných (tj. tisknutelných) ASCII znaků, je nejjednodušší metodou vložit celý blok znaků mezi dvojici speciálních (tj. netisknutelných znaků): STX (Start of TeXt, začátek textu) a ETX (End of TeXt, konec textu), které jsou pro svou funkci označovány jako řídící znaky přenosu (transmission control characters). Tím se dosáhne potřebné synchronizace na úrovni rámců (frame synchronization), neboť znaky STX a ETX umožňují příjemci správně rozpoznat začátek a konec rámce (zatímco jednotlivé znaky rámce rozpoznává při asynchronním přenosu díky zmíněným start a stop bitům) .

Právě naznačený způsob ovšem nelze použít v případě, kdy potřebujeme přenést (jako data) i některé řídící znaky, nebo v případě, kdy místo znaků přenášíme obecná binární data. Ta sice můžeme rozdělit na stejně velké skupiny bitů a chápat je jako kódy jednotlivých znaků, stále se nám však může stát, že nám takto vyjde právě některý ze zmíněných řídících znaků. Pak je nutné zajistit tzv. transparenci dat (data transparency), tedy umožnit, aby mezi přenášenými daty mohly být i řídící znaky, a tyto nebyly interpretovány jako řídící, ale jako "užitečná" data. Používá se k tomu technika tzv. vkládání znaků (character stuffing), kdy je před řídící znaky STX a ETX vložen ještě jiný řídící znak - znak DLE (Data Link Escape, změna významu následujícího znaku). Ten se ovšem může vyskytovat i mezi vlastními daty, a proto se zde každý jeho výskyt zdvojuje. Příjemce se pak vždy po přijetí znaku DLE rozhoduje podle následujícího znaku - je-li jím další znak DLE, jednoduše jej vypustí (a přijme předchozí znak DLE jako "užitečná" data). Je-li naopak dalším znakem znak ETX, příjemce si z toho odvodí, že se dostal na konec bloku .

Jednou z nevýhod asynchronního způsobu přenosu je vkládání nezbytných start a stop bitů, čímž se dosti podstatně snižuje efektivní přenosová rychlost. Pro vyšší přenosové rychlosti se proto používá spíše přenos synchronní (viz 1. kapitola).

Synchronní přenos si lze představit jako spojitý proud bitů (bez start a stop bitů), ve kterém příjemce musí správně rozpoznávat hranice mezi jednotlivými znaky (což představuje synchronizaci na úrovni znaků, character synchronization). Té se dosahuje pomocí speciálních znaků SYN (viz opět 1.kapitola), které uvozují každý synchronně přenášený blok znaků.

Synchronizace na úrovni rámců (tj. správné rozpoznání začátku a konce rámce) se při synchronním přenosu může dosahovat stejně, jako při přenosu asynchronním - pomocí řídících znaků přenosu. Pak jde o tzv. znakově orientovaný přenos (character-oriented transmission).

Vkládání celých řídících znaků do přenášených dat a jejich nezbytné zdvojování při přenosu binárních dat ale opět přináší snížení efektivní přenosové rychlosti. Proto se dnes stále více uplatňuje bitově orientovaný přenos (bit-oriented transmission). Je založen na myšlence indikovat začátek a konec rámců nikoli řídícím znakem, ale skupinou bitů. Označení "bitově orientovaný" přitom zdůrazňuje skutečnost, že přenášená data jsou vyhodnocována bit po bitu, dokud není nalezena hledaná skupina bitů, indikující začátek rámce resp. jeho konec. Počet bitů, které tvoří vlastní obsah rámce, pak nemusí nutně být násobkem osmi.

Jednou z možností pro bitově orientovaný přenos je použít stejnou skupinu bitů, tzv. křídlovou značku (flag) pro uvození i zakončení rámce. Tato křídlová značka se pak ovšem nesmí vyskytovat "uvnitř" vlastního rámce. Obvykle je křídlová značka tvořena posloupností "01111110", a potřebná transparence dat se zajišťuje vkládáním bitů (bit stuffing), při kterém je za každých pět po sobě jdoucích jedničkových datových bitů automaticky vložen jeden nulový bit (který příjemce zase automaticky odstraňuje) .

Další možností je uvození celého rámce (po tzv. preambuli neboli synchronizačním poli) tzv. příznakem začátku rámce (start-of-frame delimiter), za kterým následuje hlavička (header) předem stanoveného formátu, a údaj o délce rámce. Tato varianta se používá především u lokálních sítí.

Podle používaného způsobu přenosu lze protokoly, používané na úrovni linkové vrstvy ISO/OSI modelu, rozdělit do dvou velkých skupin: na znakově orientované protokoly (character-oriented protocols) a bitově orientované protokoly (bit-oriented protocols).

Mezi znakově orientované protokoly patří především protokol, vyvinutý firmou IBM pod označením Binary Synchronous Protocol, zkráceně nazývaný Bisync, či jen BSC. V poslední době se však stále více prosazují spíše bitově orientované linkové protokoly. Nejvýznamnějším představitelem této skupiny je opět protokol, vyvinutý firmou IBM pro její síťovou architekturu SNA - protokol SDLC (Synchronous Data Link Control). Od tohoto protokolu jsou pak odvozeny téměř všechny ostatní používané bitově orientované protokoly - HDLC (High-Level Data Link Control), pocházející od organizace ISO, LAP (Link Access Procedure) a jeho různé varianty od CCITT, či ADCCP (Advanced Data Communications Control Procedure), který je standardem ANSI.

 

Linková vrstva - II.

Správné rozpoznání začátku a konce každého rámce i jeho jednotlivých částí není zdaleka jediným úkolem, který řeší linková vrstva referenčního ISO/OSI modelu.

Služby, které linková vrstva poskytuje vrstvě síťové, mohou mít charakter spolehlivých i nespolehlivých služeb (viz 26. kapitola). Pro realizaci spolehlivých služeb pak linková vrstva musí mít k dispozici mechanismy pro zajištění toho, že příjemce skutečně přijme všechny vyslané rámce, a to bez chyb (v případě spojované služby ještě ve správném pořadí). Možné způsoby, jak tento požadavek zajistit, závisí na charakteru spojení mezi vysílajícím a příjemcem. Záleží na tom, zda toto spojení je svou povahou simplexní (simplex), tj. umožňující pouze jednosměrný přenos od vysílajícího k příjemci, nebo tzv. poloduplexní (half-duplex), umožňující sice obousměrný přenos, ale nikoli současně, nebo plně duplexní (full duplex), umožňující současný přenos oběma směry.

Simplexní spoje neumožňují vytvořit zpětnou vazbu mezi vysílajícím a příjemcem. Příjemce pak nemá možnost vyžádat si nové vyslání těch rámců, které přijal jako poškozené, a se všemi případnými chybami se musí vyrovnat sám. Vysílající mu v tom může pomoci tím, že použije vhodný samoopravný kód (viz 2. kapitola), díky kterému pak příjemce dokáže některé chyby v přenesených datech opravit sám. Tyto kódy jsou však spojeny se značnou redundancí, kvůli které výrazně klesá efektivní přenosová rychlost "užitečných" dat. Stejná situace nastává také u takových spojů, které sice nejsou simplexní, ale pracují s tak dlouhými dobami přenosu, že se na úrovni linkové vrstvy nevyplatí čekat na zpětnou vazbu od příjemce dat (příkladem mohou být družicové spoje, viz 17. kapitola).

V případě poloduplexních a plně duplexních spojů je možné vystačit již jen se zabezpečením přenášených dat pomocí detekčních kódů. Z nich jsou nejúčinnější tzv. cyklické kódy, které lze použít k zabezpečení rámce jako celku. Při odesílání se k obsahu rámce přidá krátký zabezpečovací údaj (typicky v rozsahu 16 bitů), a příjemce je pak na základě tohoto zabezpečovacího údaje schopen se značnou pravděpodobností rozpoznat, zda přijal rámec bez chyby, či nikoli. V druhém případě pak může využít zpětné vazby, kterou mu nabízí poloduplexní a duplexní spojení s vysílajícím, a vyžádat si na něm nové vyslání celého chybně přijatého rámce.

Právě naznačený mechanismus je obvykle implementován v podobě tzv. potvrzování (acknowledgement), přesněji: potvrzovací zpětné vazby, která předpokládá, že příjemce zkontroluje bezchybovost každého přijatého rámce, a o výsledku informuje vysílajícího. V angličtině je pak tato technika označována také jako ARQ (Automatic Retransmission reQuest).

Možností realizace mechanismu potvrzování existuje celá řada. V prvním přiblížení je lze rozdělit na dvě velké skupiny, na tzv. jednotlivé potvrzování (idle RQ, stop&wait RQ), a kontinuální potvrzování (continuous RQ). V případě jednotlivého potvrzování vysílající odešle rámec, a pak čeká na reakci příjemce. Další rámec pak vyšle teprve poté, kdy mu příjemce signalizuje úspěšné přijetí původního rámce. V opačném případě (kdy je mu signalizováno neúspěšné přijetí, nebo nedostane-li do určitého časového limitu žádnou odpověď), vyšle původní rámec znovu. Konkrétní implementovaný mechanismus pak může vycházet z toho, že příjemce potvrzuje pouze bezchybně přijaté rámce (zatímco přijetí chybných rámců nesignalizuje vůbec a tyto rámce jednoduše ignoruje), nebo naopak z toho, že příjemce vysílá jen záporná potvrzení (negative acknowledgements), resp. odmítnutí (rejections), která signalizují přijetí rámce s chybami a explicitně žádají o jeho opětovné vyslání. Nejefektivnější je ovšem taková varianta, při které příjemce explicitně signalizuje obě možné situace - pomocí kladného i záporného potvrzení.

Obecnou nevýhodou všech variant jednotlivého potvrzování je nutnost čekat před odesláním dalšího rámce na reakci protistrany. V případě delších dob přenosu tak mohou vznikat neúnosně velké časové ztráty, které minimalizuje až potvrzování kontinuální. To je založené na myšlence, že vysílající bude vysílat nové rámce bez toho, že by si byl jist úspěšným přijetím předchozích rámců. Po odeslání určitého rámce tudíž vysílající nečeká na zprávu o úspěšném či neúspěšném přijetí rámce, ale může ihned pokračovat vysláním dalšího rámce. Kladná resp. záporná potvrzení jednotlivých rámců pak dostává s určitým zpožděním, a reaguje na ně samozřejmě až v okamžiku, kdy je skutečně dostane. Zde je opět několik možných variant: vysílající může znovu vyslat jen ten rámec, o kterém se dozvěděl, že nebyl úspěšně přenesen (pak jde o tzv. selektivní opakování, selective repeat), nebo znovu vyslat chybně přenesený rámec, a po něm znovu i všechny následující rámce, které již mezitím mohly být také odvysílány (pak jde o tzv. opakování s návratem, v angličtině o tzv. Go-back-N techniku).

Opakování s návratem je obecně méně efektivní než selektivní opakování, neboť může způsobit opakované vyslání rámců, které již byly přijaty bezchybně. Selektivní opakování zase vyžaduje ke své implementaci poměrně velkou kapacitu vyrovnávacích pamětí, a to jak na straně příjemce, tak i na straně vysílajícího.

Při našich úvahách o mechanismech potvrzování je dobré se zamyslet také nad tím, jakou konkrétní podobu mají kladná i záporná potvrzení, která příjemce datových rámců vrací jejich odesilateli. Mohou to být samostatné rámce zvláštního typu, které nenesou žádná "užitečná" data, ale mají pouze řídící charakter. Pak jde o tzv. samostatné potvrzování, které ovšem svými řídícími rámci zatěžuje přenosové cesty na úkor datových rámců s "užitečnými" daty. Efektivnější alternativou, použitelnou však jen v případě obousměrného toku "užitečných" dat, je vkládat potvrzující informace přímo do datových rámců - této technice se v angličtině říká piggybacking.

Dalším, velmi významným úkolem linkové vrstvy ISO/OSI modelu je zajistit, aby vysílající svými daty nezahltil příjemce. Linková vrstva se tedy musí zabývat také tzv. řízením toku (flow control), které má zajistit, aby vysílající skutečně vysílal jen tehdy, kdy je přijímající vůbec schopen nějaká data přijímat - a ne např. tehdy, když příjemce nemá k dispozici dostatečně velký objem vyrovnávací paměti pro uložení přijímaných dat, nebo je zaneprázdněn jinou činností (obsluhou naléhavého přerušení, zpracováním dříve přijatých dat apod.).

Určujícími jsou přitom možnosti příjemce - ten musí mít možnost dočasně pozastavit vysílaní dat, a později je zase obnovit. Na úrovni linkové vrstvy je nejjednodušší dočasně pozastavovat vysílání celých rámců. V případě jednotlivého potvrzování (viz výše) k tomu příjemci stačí nepotvrdit posledně přijatý rámec (nebo na něj reagovat záporným potvrzením). V případě kontinuálního potvrzování není situace o nic složitější - vysílající zde totiž vysílá "dopředu" (tj. bez potvrzení) vždy jen určitý maximální počet rámců. Vzniká tak "okénko" již vyslaných ale dosud nepotvrzených rámců, které prostřednictvím svých potvrzení posouvá právě příjemce rámců. Díky tomu má i tomto případě možnost podle svých potřeb dočasně pozastavit vysílání (tj. posun okénka) a později jej zase obnovit.

Kvůli charakteristické představě zmíněného "okénka" se metoda kontinuálního potvrzování často označuje také jako metoda okénka (sliding window method).

 

Linková vrstva - III.

V minulých kapitolách jsme se zabývali postavením a funkcí linkové vrstvy v rámci referenčního modelu ISO/OSI. Naznačili jsme si, že linková vrstva musí zajišťovat potřebnou synchronizaci na úrovni jednotlivých znaků i celých rámců, a starat se o bezchybné doručení všech rámců od odesilatele k jejich příjemci. Pro činnost linkové vrstvy je však velmi důležitý také konkrétní způsob vzájemného propojení jednotlivých uzlů, mezi kterými má přenos rámců zajišťovat. Podívejme se proto nyní, jaké jsou možnosti takovéhoto propojení, a jaké důsledky vyplývají z jednotlivých alternativ.

Dva uzlové počítače mohou být propojeny pomocí dvoubodového spoje (point-to-point connection). Dvoubodový spoj může být realizován např. pomocí kroucené dvoulinky, koaxiálního či optického kabelu, nebo také prostřednictvím veřejné telefonní sítě (jako sítě s přepojováním okruhů). Podstatná je přitom skutečnost, že mezi oběma uzly existuje (alespoň po dobu přenosu) přímý přenosový kanál, a protokol linkové vrstvy pak zajišťuje přímou komunikaci obou koncových účastníků.

Poněkud jiná situace však nastává v případě, kdy jsou dva uzly propojeny prostřednictvím sítě s přepojováním paketů - například pomocí veřejné datové sítě na bázi X.25 (viz 17. díl našeho seriálu). Sítě tohoto typu si totiž samy zajišťují vše, co je potřeba pro "interní" přenos paketů (tj. až do úrovně síťové vrstvy, včetně). Linková vrstva zde pak má na starosti jen přenos rámců mezi koncovým uzlem a místem jeho připojení na datovou síť.

Další možností, typickou spíše pro propojení na kratší vzdálenosti, je použití tzv. mnohobodového spoje (multipoint connection), který vzájemně propojuje více uzlů a umožňuje přenos dat mezi kterýmikoli dvěma uzly. Umožňuje dokonce i přenos dat z jednoho uzlu (v roli vysílajícího) současně do více uzlů (v roli přijímajících) - pro tuto svou schopnost se v angličtině tento druh propojení označuje také jako tzv. broadcast channel (doslova: přenosový kanál, umožňující "rozesílání").

Pro mnohobodový spoj je však podstatná skutečnost, že jde o sdílený prostředek, který neumožňuje vícenásobné přidělení - v roli vysílajícího může být vždy nejvýše jeden uzel. Pokud tedy dojde k situaci, že o získání tohoto sdíleného prostředku (tj. práva vysílat po mnohobodovém spoji) bude usilovat více uzlů současně, musí existovat mechanismus, který mezi všemi žadateli umožní vybrat jednoho, a tomu pak prostředek přidělit (tj. nechat jej vysílat).

Možností realizace je opět více. Jednou z nich je existence centrálního arbitra, který sám rozhoduje o využití sdíleného prostředku - jednotlivým žadatelům přiděluje právo vysílat po mnohobodovém spoji. Může tak činit na základě explicitních žádostí jednotlivých žadatelů, což ovšem znamená, že pro tyto žádosti je nutné vyhradit určitou část přenosové kapacity mnohobodového spoje, nebo vytvořit další vhodné propojení mezi centrálním arbitrem a ostatními uzly pro přenos těchto žádostí. V praxi se však používá spíše tzv. metoda výzvy (polling), při které se centrální arbitr sám postupně obrací na jednotlivé potenciální žadatele a zjišťuje, zda chtějí něco vyslat.

Znakově i bitově orientované protokoly linkové vrstvy, o kterých jsme se zmiňovali ve 29. dílu našeho seriálu obvykle umožňují používat jak dvoubodové, tak i mnohobodové spoje. V případě mnohobodových spojů pak počítají právě s existencí centrálního arbitra - tím je u těchto protokolů jedna ze stanic, která má postavení tzv. řídící stanice (supervisory, master), zatímco ostatní stanice vystupují v roli podřízených (slave) stanic. Řídící stanice přiděluje jednotlivým podřízeným stanicím právo vysílat na základě jejich kladné reakce na zaslanou výzvu (poll). Stanice, která v určitém okamžiku získá právo vysílat, se dostává do postavení tzv. hlavní stanice (primary) a sama si volí, komu chce svá data vyslat - prostřednictvím zvláštní výzvy provede tzv. výběr (selection) jedné nebo několika dalších stanic, které budou její data přijímat, a budou tedy vůči ní vystupovat jako tzv. vedlejší stanice (secondary)

Právě naznačený mechanismus v sobě skýtá jedno potenciální nebezpečí - v případě výpadku centrálního arbitra (řídící stanice) se celá síť na bázi mnohobodového spoje stává nepoužitelnou. Existují však i jiné alternativy, které existenci centrálního arbitra nepředpokládají. Jsou založeny na myšlence, že všichni žadatelé o právo vysílat po mnohobodovém spoji se dokáží mezi sebou dohodnout, a vybrat ze svého středu jednoho, který pak skutečně začne vysílat. Jde vlastně o jakousi soutěž, do které se musí přihlásit každá stanice, která chce získat právo vysílat pro mnohobodovém spoji (tj. stát se stanicí hlavní). Tato soutěž musí samozřejmě mít přesně stanovená pravidla, která všichni soutěžící musí dodržovat - jsou definována ve formě tzv. přístupové metody (access method).

"Decentralizovaný" způsob řízení mnohobodového spoje, založený na různých přístupových metodách, je charakteristický hlavně pro lokální sítě. Nejrozšířenější jsou dnes dvě přístupové metody: metoda CSMA/CD, která se používá v lokálních sítích typu Ethernet, a metoda Token passing (tzv. předávání pověření resp. "peška"), která se používá v sítích Token Ring a Token Bus. O obou metodách si samozřejmě budeme povídat podrobněji, pokusme se je však ještě zařadit do kontextu sedmivrstvého referenčního modelu ISO/OSI.

Přístupová metoda, zajišťující korektní přístup ke sdílenému mnohobodovému spoji, musí být implementována nad fyzickou vrstvou - neboť sama využívá služeb této vrstvy pro přenos jednotlivých bitů. Linková vrstva, která zabezpečuje přenos celých rámců, by ale již měla mít potřebný přístup ke sdílenému mnohobodovému spoji zajištěn. Přístupová metoda by tudíž měla být implementována mezi fyzickou a linkovou vrstvou - což by ovšem znamenalo "vsunutí" zcela nové vrstvy do referenčního modelu, která je navíc zapotřebí jen v případě těch lolních sítí, které používají sdílené mnohobodové spoje bez centrálního arbitra. Celá situace se vyřešila tak, že se u těchto sítí "původní" linková vrstva rozděluje na dvě části resp. podvrstvy - nižší podvrstvu MAC (Media Access Control sublayer, podvrstva řízení přístupu k přenosovému médiu), ve které je implementována příslušná přístupová metoda, a vyšší podvrstvu LLC (Link Layer Control, podvrstvu řízení logického spoje), která zajišťuje všechno to, co jsme dosud přisuzovali linkové vrstvě jako takové.

Přístupové metody pro dnes nejrozšířenější lokální sítě jsou definovány ve standardech IEEE řady 802, o kterých jsme se již zmiňovali v souvislosti s fyzickou vrstvou ISO/OSI modelu ve 28. dílu našeho seriálu.

 

Síťová vrstva - I.

Chtějí-li spolu komunikovat dva uzly počítačové sítě, mezi kterými neexistuje přímé spojení, je nutné pro ně najít alespoň spojení nepřímé - tedy vhodnou cestu, vedoucí přes mezilehlé uzly od jednoho koncového uzly ke druhému. Možných cest může být samozřejmě více, někdo je však musí najít, jednu z nich vybrat, a pak také zajistit správné předávání dat po této cestě. Všechny tyto úkoly má v referenčním modelu ISO/OSI na starosti síťová vrstva.

Uvažujme příklad počítačové sítě a situaci, kdy je potřeba přenést určitá data z uzlu A do uzlu D. Zdrojem těchto dat nechť je uživatelský proces, běžící na počítači A (může to být například program pro práci s elektronickou poštu a jím generovaná data zprávou, určenou pro účastníka na uzlu resp. počítači D). Uživatelský proces na počítači A předá svá data k odeslání aplikační vrstvě, která je zase předá vrstvě prezentační atd.. Když se příslušná data dostanou až na úroveň síťové vrstvy, musí tato rozhodnout, kudy je skutečně odeslat. V našem konkrétním případě je toto rozhodnutí velmi jednoduché, jediná cesta "ven" zde totiž vede přes uzel E. Data, určená k doručení do uzlu D, proto síťová vrstva uzlu A předá své bezprostředně nižší (linkové) vrstvě s požadavkem na jejich odeslání do uzlu E.

Jelikož mezi uzly A a E existuje přímé spojení, dokáže lInková vrstva uzlu A předat blok dat (na úrovni linkové vrstvy označovaný jako rámec) své partnerské linkové vrstvě na uzlu E. Jak již ale víme, ve skutečnosti tak činí prostřednictvím fyzické vrstvy.

Linková vrstva na uzlu E předá přijatý rámec své bezprostředně vyšší vrstvě, tj. vrstvě síťové. Ta musí z obsahu rámce poznat, že jde o data určená k doručení do uzlu D. Na základě znalosti topologie sítě (tj. způsobu propojení jednotlivých uzlů) tato vrstva zjistí, že cesta do uzlu D vede dále buď přes uzel G, nebo přes uzel F. Musí se rozhodnout pro jednu z obou možností - předpokládejme, že se rozhodne pro cestu přes uzel G. Data, která převzala od linkové vrstvy, proto síťová vrstva uzlu E vrátí své bezprostředně nižší vrstvě s požadavkem na odeslání do uzlu G.

V uzlu G se situace opakuje. Linková vrstva předá přijatý rámec síťové vrstvě, která jej vrátí linkové vrstvě zpět s požadavkem na odeslání do uzlu D, kam již z uzlu G vede přímé spojení.

V uzlu D se data dostanou analogickým způsobem až na úroveň síťové vrstvy. Ta rozpozná, že jde o data, určená právě danému uzlu, a proto je již nevrací vrstvě linkové, ale předá je své bezprostředně vyšší (tj. transportní) vrstvě. Odtud jsou pak postupně předávána směrem k vyšším vrstvám, až se dostanou k té entitě resp. procesu, která je jejich konečným příjemce.

 

Úkoly síťové vrstvy

Pokusme se nyní, na základě výše uvedeného příkladu, o zobecnění úkolů, které v referenčním modelu ISO/OSI plní síťová vrstva.

Kdykoli transportní vrstva předává vrstvě síťové nějaká data k odeslání, připojuje k nim pouze informaci o tom, kdo má být jejich konečným příjemcem. Pro každý samostatně přenášený blok dat, který se na úrovni síťové vrstvy označuje jako paket (zatímco na úrovni linkové vrstvy jako rámec) pak musí síťová vrstva rozhodnout, kterým "směrem" jej má skutečně odeslat. Jakmile toto rozhodnutí učiní, předá příslušný paket vrstvě linkové spolu s údajem o zvoleném směru.

Nejdůležitějším úkolem síťové vrstvy je tedy tzv. směrování (routing), které představuje právě ono zmíněné rozhodování o směru odesílání jednotlivých paketů. Není jistě třeba zdůrazňovat, že k tomu síťová vrstva potřebuje alespoň základní informace o topologii celé sítě. Konkrétních způsobů směrování, či spíše postupů resp. algoritmů volby vhodného směru přitom existuje celá řada. Od jednoduchých statických metod, které nejsou schopny reagovat na dynamické změny v síti, až po adaptivní metody, které se dokáží přizpůsobit aktuálnímu stavu sítě, jejímu zatížení, případným výpadkům některých uzlů či spojů apod.

Metodám směrování se budeme podrobněji věnovat v dalších pokračováních našeho seriálu. Vraťme se však ještě k úkolům síťové vrstvy - kromě vlastního směrování (chápeme-li jej jen jako rozhodování o dalším směru) musí síťová vrstva zajišťovat i jeho skutečnou realizaci. Tedy v mezilehlých uzlech zajišťovat potřebné předávání jednotlivých paketů na cestě k jejich koncovému příjemci.

S tím dosti úzce souvisí i další úkol síťové vrstvy - předcházet přetížení či dokonce zahlcení částí sítě, řídit tok dat a dbát o co možná nejrovnoměrnější využití všech přenosových prostředků a kapacit.

Při vzájemném propojení dvou či více sítí pak přibývá síťové vrstvě ještě jeden důležitý úkol - zajišťovat nezbytné předávání paketů mezi jednotlivými sítěmi.

Odlišné pohledy na svět

Udělejme si nyní malé shrnutí toho, jaký pohled na celou síť a vzájemné propojení jednotlivých uzlů má transportní, síťová a linková vrstva ISO/OSI modelu - umožní nám to snáze pochopit postavení a význam síťové vrstvy: transportní vrstva v každém uzlu sítě vychází z představy, že mezi jejím uzlem a koncovým příjemcem dat existuje přímé spojení, a proto adresuje svá data přímo tomuto koncovému příjemci. Síťová vrstva si již uvědomuje skutečnou topologii sítě a ví, že představa transportní vrstvy nemusí být správná (činí však vše pro to, aby transportní vrstvě její iluzi zachovala). Pro linkovou vrstvu pak již není topologie celé sítě relevantní - té stačí znát jen ty uzly, se kterými má "její" uzel přímé spojení. Nezná dokonce ani koncového příjemce dat obsažených v rámcích, které sama přenáší.

Komunikační podsíť a hostitelské počítače

Příklad topologie sítě naznačuje nejobecnější situaci, kdy všechny uzlové počítače sítě mají stejné postavení a mohou vystupovat jak v roli zdrojů a koncových příjemců dat, tak i v roli mezilehlých uzlů.

V praxi však může často docházet k tomu, že meziuzly nejsou plnohodnotnými uzly počítačové sítě, ale pouze jednoúčelovými "přepojovači", které vytváří potřebnou komunikační infrastrukturu pro propojení ostatních "plnohodnotných" uzlů. Právě s takovouto představou počítal také referenční model ISO/OSI ve své původní verzi (kdy uvažoval jen tzv. spojované služby). Podle této představy je oddělena čistě komunikační funkce sítě a je svěřená tzv. komunikační podsíti (communication subnet, subnetwork), zatímco vlastní aplikační funkce zajišťují tzv. koncové systémy (end systems). S podobnou představou pracovala například i jedna z prvních rozlehlých sítí ARPANET, jejíž terminologie se nejvíce prosadila do praxe. Koncové systémy, na kterých jsou provozovány uživatelské aplikace, označuje jako hostitelské počítače (host computers, hosts), zatímco jednotlivé "přepojovací" uzly v rámci komunikační podsítě označuje jako IMP (Interface Message Processor) - viz obrázek 32.1. a/. V literatuře se však často používají také termíny uzel přepojování paketů (Packet Switching Node) či mezilehlý systém (Intermediate Node) nebo datová ústředna (Data Switching Exchange).

 

Síťová vrstva - II

Otázka volby mezi spojovanými a nespojovanými službami (connection-oriented vs. connectionless službami) je snad nejkontroverznější právě na úrovní síťové vrstvy. Když vznikal referenční model ISO/OSI, mezi jeho tvůrci měli značnou převahu zastánci spojovaných služeb. Proto také referenční model původně počítal jen s tímto druhem síťových služeb. Zastánci druhé alternativy však alespoň dodatečně prosadili do referenčního modelu i služby spojované. V čem je ale skutečné jádro sporu mezi oběma tendencemi?

Připomeňme si nejprve, že spojovaná služba funguje obdobně jako veřejná telefonní síť - předpokládá nejprve navázání spojení mezi oběma účastníky, pak vlastní přenos dat prostřednictvím tohoto spojení, které se v jistém smyslu chová jako roura, kterou se vlastní data "protlačují", a nakonec vyžaduje ukončení (rozvázání) spojení. Naopak nespojovaná služba funguje obdobně jako běžná listovní pošta - každý jednotlivý paket (resp. datagram) doručuje samostatně a nezávisle na ostatních, bez toho, že by se navazovalo spojení mezi příjemcem a odesilatelem. Další analogií s listovní poštou je rozdíl mezi spolehlivou a nespolehlivou nespojovanou službou - spolehlivá varianta je obdobou doporučené zásilky, která se nemůže (alespoň teoreticky) ztratit, zatímco nespolehlivá verze je obdobou obyčejné zásilky, u které pošta negarantuje její doručení, a která se může beze stopy ztratit. Zastánci spojovaných služeb, rekrutující se především z kruhů spojových organizací, zastávají názor, že uživatelé resp. vyšší vrstvy potřebují maximálně spolehlivou a jednoduše použitelnou službu pro přenos dat, která by je zbavila všech starostí se zabezpečením vlastního přenosu dat (např. s potřebným řízením toku, opravou chyb, zajištěním správného pořadí jednotlivých doručovaných paketů atd.). Tedy spolehlivou spojovanou síťovou službu pro přenos paketů.

Druhá strana, reprezentovaná především lidmi kolem sítě Internet, argumentuje svou dlouhodobou zkušeností s provozováním velké počítačové sítě v reálných podmínkách. Podle ní je nutné považovat komunikační infrastrukturu (podsíť, viz minulý díl našeho seriálu) za nespolehlivou, bez ohledu na to, jak je navržena (tedy i v případě, že se sama snaží být spolehlivou). Koncové systémy (hostitelské počítače, viz minule) musí počítat s tím, že pakety se mohou v podsíti ztrácet, a vše potřebné k zajištění spolehlivosti si tudíž musí realizovat sami - tedy detekci a opravu chyb, řízení toku atd. To ovšem vede na požadavek používat na úrovni síťové vrstvy jen ty nejrychlejší a nejjednodušší služby (na úrovni operací typu "vyšli paket" a "přijmi paket"), a spolehlivost zajistit až v bezprostředně vyšší, transportní vrstvě. Tato druhá strana tedy požaduje na úrovni síťové vrstvy jen jednoduchou nespolehlivou nespojovanou službu.

Na celý spor mezi oběma tábory je možné se dívat i z poněkud jiného úhlu. Spojové organizace jako zastánci spojovaných služeb chtějí poskytovat uživatelům co nejkomplexnější a nejúplnější služby - je to asi přirozené, neboť právě za ně jsou placeny. Druhá strana naopak tvrdí, že výpočetní kapacita je dnes tak laciná, že není nejmenší problém, aby si co nejvíce funkcí zajišťovaly až jednotlivé hostitelské počítače (obvykle ve vlastnictví uživatelů). Dalším silným argumentem této skupiny je pak to, že charakter některých síťových aplikací (jako např. přenos digitalizovaného zvuku a sběr dat v reálném čase) upřednostňuje rychlý přenos před přenosem spolehlivým.

Rozpor mezi spojovanými a nespojovanými službami na úrovni síťové vrstvy je tedy ve své podstatě sporem o to, kam umístit veškerou složitost - tedy funkce, spojené se zajištěním spolehlivosti, které tak jako tak musí být někde realizovány. Zastánci spojovaných služeb je chtějí umístit do síťové vrstvy, zatímco zastánci nespojovaných služeb požadují jejich umístění až do vrstvy transportní (zatímco od vrstvy síťové požadují jen nejjednodušší nespolehlivou nespojovanou službu).

CONS i CLNS

Celý spor byl nakonec vyřešen tak, že aktualizovaná verze referenčního modelu ISO/OSI již počítá na úrovni síťové vrstvy s možností poskytování obou druhů služeb - spojovaných síťových služeb (CONS - Connection-Oriented Network Services) i nespojovaných síťových služeb (CLNS, ConnectionLess Network Services).

Služby vs. jejich realizace

Druh služeb, které síťová vrstva poskytuje své bezprostředně vyšší (tj. transportní) vrstvě, nesmíme mechanicky ztotožňovat s tím, jak síťová vrstva skutečně funguje "uvnitř". Základní možnosti jsme si naznačili již v 17. dílu našeho seriálu, kdy jsme si povídali o veřejných datových sítích. Pomineme-li možnost tzv. přepojování okruhů, která vytváří přímé fyzické spojení mezi oběma koncovými účastníky, jde o dvě základní varianty: první z nich jsou tzv. virtuální okruhy (též: virtuální spoje, virtual calls, virtual circuits) jako mechanismus spojovaného charakteru, který před vlastním přenosem datových paketů předpokládá "vytyčení" logické cesty (virtuálního okruhu) mezi oběma koncovými účastníky.

Druhou alternativou je pak přenos datagramů, který má nespojovaný charakter, každý jednotlivý paket (nyní nazývaný datagram) doručuje samostatně, nezávisle na ostatních paketech, a nepředpokládá žádné vytyčení cesty od odesilatele k jejich příjemci.

Je jistě zřejmé, že spojované síťové služby (CONS) se obvykle realizují prostřednictvím komunikační podsítě, která používá mechanismus virtuálních okruhů, zatímco nespojované síťové služby (CLNS) se realizují prostřednictvím podsítě, které pracuje na bázi přenosu jednotlivých datagramů. Není to ale jediná možnost. Spojované síťové služby lze bez větších problémů poskytovat i pomocí podsítě, která pracuje s přenosem jednotlivých datagramů (jestliže se každý paket místo virtuálním okruhem ve skutečnosti přenáší samostatně jako datagram). Teoreticky je možná i opačná kombinace - nespojované služby v podsíti, která pracuje s virtuálními okruhy. Příliš efektivní to ale není - pro přenos každého jednotlivého datagramu je nutné nejprve zřídit, a pak zase zrušit potřebný virtuální okruh. Pokud je ale k dispozici jen podsíť s virtuálními okruhy, nic jiného nezbývá.

Naznačme si nyní poněkud podrobněji, jak jsou implementovány a jak fungují mechanismy virtuálních okruhů a přenosu datagramů. Pomůže nám to lépe pochopit podstatu sporu mezi zastánci spojovaných a nespojovaných služeb.

Virtuální okruhy vs. datagramy

Mechanismus virtuálních okruhů předpokládá, že mezi zdrojem dat a jejich koncovým příjemcem je v rámci navazování spojení nejprve "vytyčena" logická cesta (virtuální okruh), po které jsou pak postupně přenášeny jednotlivé pakety.

Vytyčit cestu ve skutečnosti znamená, že se právě jednou (v rámci navazování spojení) najde taková posloupnost mezilehlých uzlů (resp. uzlů IMP, viz minule), která vede od zdroje dat až k jejich koncovému příjemci, a je v daný moment považována za optimální. Údaje o této cestě (virtuálním kanálu) se pak uchovávají v jednotlivých meziuzlech jako položky speciální tabulky.

Jednotlivé datové pakety, které jsou pak skutečně přenášeny, nejsou označeny adresou svého konečného příjemce (která může být relativně dlouhá), ale pouze označením příslušného virtuálního kanálu. Síťová vrstva v každém meziuzlu pak podle tohoto údaje zjistí ve své tabulce, kterým směrem má paket předat dále, a učiní tak.

Naproti tomu při přenosu datagramů se předpokládá, že mezi zdrojem dat a jejich koncovým příjemcem není navazováno přímé spojení, a jednotlivé datové pakety (datagramy) jsou vysílány "naslepo", v dobré víře, že jejich příjemce vůbec existuje a bude schopen je přijmout. Každý datagram je přitom doručován nezávisle na ostatních (tak jako např. běžný dopis v případě listovní pošty) - to znamená, že v každém meziuzlu musí síťová vrstva vždy znovu rozhodnout, kterým směrem má být datagram poslán dále. V jednotlivých meziuzlech si proto síťová vrstva nevytváří obdobu tabulky, popisující virtuální okruhy. Místo toho pracuje s tabulkou, ve které má alespoň základní informace o topologii sítě a podle ní přijímá svá rozhodnutí o nejvhodnějším směru dalšího přenosu každého jednotlivého datagramu.

Hlavní výhodou virtuálních okruhů je skutečnost, že rozhodování o dalším směru přenosu paketů se v každém meziuzlu přijímá jen jednou, a nikoli pokaždé znovu, jako je tomu v případě datagramů. Nevýhodou je naopak statický charakter tohoto rozhodnutí (a tím i zvolené cesty resp. virtuálního okruhu), které není možné dynamicky přizpůsobovat okamžitému stavu sítě - což je naopak možné v případě přenosu datagramů.

Virtuální okruhy vykazují větší jednorázovou počáteční režii (na navázání spojení resp. vytvoření logického okruhu), a menší relativní režii na přenos jednotlivých paketů, zatímco v případě datagramů je tomu přesně naopak.

Obecně lze říci, že mechanismus virtuálních okruhů je výhodnější v případě přenosu menších paketů (jako je tomu např. při interaktivních aplikacích), zatímco varianta s přenosem datagramů je výhodnější pro menší počty relativně větších paketů, a ve verzi nespolehlivé (resp. nepotvrzované) datagramové služby také tam, kde jde především o rychlost.

 

Síťová vrstva - směrování

Neexistuje-li v počítačové síti přímé spojení mezi odesilatelem dat a jejich koncovým příjemcem, je úkolem síťové vrstvy nalézt mezi nimi alespoň takovou cestu, která vede přes některé jiné uzly sítě. Z předchozích dílů našeho seriálu již víme, že v případě tzv. virtuálních okruhů se takováto cesta hledá jen jednou, a to na začátku komunikace obou koncových účastníků (v rámci navazování spojení resp. zřizování virtuálního okruhu), zatímco u tzv. datagramové služby se vhodná cesta hledá pro každý jednotlivý paket (resp. datagram) pokaždé znovu. Víme již také, že problematika hledání cest v síti se obecně označuje jako směrování (routing). Co však ještě nevíme, je jak se taková cesta vlastně hledá.

Pro nalezení vhodné cesty od odesilatele až ke koncovému příjemci existuje celá řada algoritmů směrování (routing algorithms), které jsou založeny na různých myšlenkách a principech, a vyžadují různé stupně znalosti sítě, její topologie a dalších parametrů statického i dynamického charakteru. Všechny algoritmy směrování by ovšem měly být korektní, tedy dávat jen takové výsledky, které jsou správné a použitelné, měly by být co možná nejjednodušší, nejsnáze implementovatelné, a jejich režie by měla být minimální. Současně s tím by ale algoritmy směrování měly být i tzv. robustní, tedy schopné vyrovnat se s nepředvídanými výpadky, poruchami či jinými nestandardními situacemi. Měly by také usilovat o optimální využití celé sítě a její přenosové kapacity, a přitom nikoho nediskriminovat - tedy někomu hledat "lepší" cesty, a někomu "horší".

Výsledným efektem aplikace algoritmů směrování by mělo být to, aby síťová vrstva v každém z uzlů sítě věděla, kudy poslat dále takový paket, který není určen přímo jejímu uzlu. Konkrétní pokyny pro směrování paketů resp. datagramů, které vznikají na základě aplikace algoritmů směrování, se pak v jednotlivých uzlech uchovávají ve formě tzv. směrovacích tabulek (routing tables).

Adaptivní a neadaptivní směrování

V prvním přiblížení si můžeme rozdělit algoritmy směrování na dvě velké skupiny. Do první z nich budou patřit takové, které se snaží průběžně reagovat na skutečný stav sítě, a brát jej do úvahy při svém hledání nejvhodnější cesty. Dokáží se tedy přizpůsobit okamžitému stavu sítě, a proto se obecně označují jako adaptivní algoritmy (adaptive algorithms). Naproti tomu neadaptivní algoritmy (nonadaptive algorithms) nevyužívají žádné informace dynamického charakteru - např. údaje o okamžitém zatížení jednotlivých přenosových cest, výpadcích, délkách čekacích front v jednotlivých uzlech apod. Svá rozhodnutí staví pouze na informacích statického charakteru, které jsou předem známy. Díky tomu lze neadaptivní algoritmy použít k nalezení všech potřebných cest ještě před uvedením sítě do provozu, a potřebné informace pak jednorázově zanést do směrovacích tabulek jednotlivých uzlů sítě. Kvůli statickému charakteru výchozích údajů se použití neadaptivních algoritmů někdy označuje také jako tzv. statické směrování (static routing). Je vhodné tam, kde topologie sítě je skutečně neměnná, kde prakticky nedochází k výpadkům a kde se příliš nemění ani intenzita provozu resp. zátěž sítě.

Centralizované směrování

Adaptivní algoritmus může být koncipován tak, že veškeré informace o aktuálním stavu celé sítě se průběžně shromažďují v jediném centrálním bodě, tzv. směrovacím centru (RCC, Routing Control Center), které pak na jejich základě samo přijímá všechna potřebná rozhodnutí, a ostatním uzlům je oznamuje. Pak jde o tzv. centralizované směrování (centralized routing). Jeho výhodou je možnost optimálního rozhodování na základě znalosti skutečného stavu celé sítě. Problém je ovšem v tom, že má-li být centralizované směrování opravdu adaptivní, tedy má-li průběžně reagovat na aktuální stav sítě, musí být vyhledávání nejvhodnějších cest prováděno dostatečně často. Vlastní hledání cest je samo o sobě operací značně náročnou na výpočetní kapacitu, a má-li se často opakovat, dokáže plně zaměstnat i velmi výkonný počítač. Jsou zde však ještě i další problémy - co například dělat v případě výpadku směrovacího centra? Nezanedbatelná není ani zátěž přenosových cest, kterou představuje neustálý přísun aktuálních informací o stavu sítě do směrovacího centra, stejně tak jako zpětná distribuce výsledků.

Izolované směrování

Alternativou k centralizovanému směrování je tzv. izolované směrování (isolated routing), založené na myšlence, že rozhodovat o nejvhodnější cestě si bude každý uzel sám za sebe, a to na základě takových informací, které dokáže získat sám, bez spolupráce s ostatními uzly. Jednou z možností realizace je algoritmus, nazvaný příznačně algoritmem horké brambory (hot potato algorithm). Jak jeho název dává tušit, snaží se uzel zbavit každého paketu resp. datagramu co možná nejrychleji. Sleduje proto počet paketů, které čekají ve frontě na odeslání jednotlivými směry, a nový paket zařadí do té fronty, která je momentálně nejkratší. Uzel se tedy nerozhoduje podle adresy, ani nehledá nejkratší cestu pro přenos paketu, pouze se jej snaží co nejrychleji zbavit ve víře, že po jisté době přeci jen dojde ke svému cíli. V praxi se ovšem algoritmus horké brambory spíše kombinuje s jinými algoritmy resp. metodami - nejčastěji je používán jako jejich doplněk, který se uplatní až v okamžiku, kdy počet paketů v některé frontě překročí určitou únosnou mez.

Zpětné učení

Jiným příkladem izolovaného směrování je tzv. metoda zpětného učení (backward learning). Předpokládá, že každý uzel si do svých směrovacích tabulek průběžně poznamenává, ze kterého směru dostává pakety, pocházející od jiných uzlů. Tím se postupně "učí", ve kterém směru se tyto uzly nalézají. Když pak sám potřebuje odeslat nějaký paket jinému uzlu, vyšle jej tím směrem, ze kterého dříve přijal paket, pocházející od téhož uzlu.

Problémem je ovšem vrozený optimismus metody zpětného učení. Dojde-li k výpadku určité přenosové cesty, kterou se jednotlivé uzly již "naučily", vůbec ji nezaznamenají. Prakticky jediným možným řešením je pak pravidelné "zapomínání".

Záplavové směrování

Extrémní formou izolovaného směrování je tzv. záplavové směrování (flooding). Předpokládá, že přijatý paket je znovu odeslán všemi směry kromě toho, odkud sám přišel.

Zřejmou výhodou je maximální robustnost, díky které se záplavové směrování dokáže vyrovnat prakticky s jakýmkoli výpadkem. Zaručuje také, že každý paket je vždy doručen tou nejkratší možnou cestou. Nevýhodou je ale vznik velkého množství duplicitních paketů, které výrazně zvyšují zátěž existujících přenosových cest, a které je třeba následně rušit.

V praxi se proto používá spíše tzv. selektivní záplavové směrování (selective flooding), při kterém není každý paket znovu vysílán všemi směry, ale pouze těmi, které jsou alespoň přibližně orientovány ke konečnému příjemci paketu.

Distribuované směrování

Metody izolovaného směrování staví na předpokladu, že jednotlivé uzly nebudou zatěžovat přenosové cesty vzájemnou výměnou informací o stavu sítě. To je ale někdy zbytečně přísným omezením.

Pokud jej odstraníme, dostaneme tzv. distribuované směrování (distributed routing). To předpokládá, že jednotlivé uzly si pravidelně vyměňují informace o stavu sítě, a podle nich si pak samy volí příslušné cesty.

Jakmile umožníme výměnu stavových informací mezi jednotlivými uzly sítě, můžeme vcelku efektivně implementovat distribuovanou verzi algoritmu hledání nejkratších cest v síti, který bychom zřejmě používali v případě centralizovaného směrování a jediného směrovacího centra. Naznačme si nyní myšlenku tohoto distribuovaného algoritmu.

Nejprve si však musíme ujasnit, co vlastně bude pro nás měřítkem "délky" nějaké cesty. Může to být například počet meziuzlů, kterými cesta prochází. Tím však dáváme každému existujícímu spoji mezi dvěma uzly stejnou jednotkovou váhu resp. délku. Realističtější je přiřadit vhodné ohodnocení (délku) každému přímému spoji mezi dvěma uzly, a délku výsledné cesty pak chápat jako součet délek jejích jednotlivých částí. Délka spoje přitom může odrážet jeho přenosovou rychlost, cenu za jednotku přenesených dat, zpoždění při přenosu, délku výstupních front apod.

Představme si nyní síť včetně "délek" jednotlivých přímých spojů. Každý uzel předem zná svou "vzdálenost" od všech svých sousedů, a tak si ji ve své směrovací tabulce vyznačí. Svou vzdálenost (délku nejkratší cesty) od ostatních uzlů však ještě nezná, a tak ji zatím považuje za nekonečnou (na obrázku naznačeno vyšrafováním).

Vlastní algoritmus distribuovaného výpočtu pak probíhá v opakujících se krocích. V každém z nich se každý uzel dotáže svých bezprostředních sousedů, jaké jsou jejich vzdálenosti od ostatních uzlů, a podle toho si pak odvozuje i své vlastní vzdálenosti od těchto uzlů.

Uvažme příklad uzlu E. Ten se v prvním kroku od svého souseda C dozví, že jeho vzdálenost od uzlu B je 2. K ní si uzel E připočte svou vzdálenost od uzlu C, tj. 1, a do své směrovací tabulky si poznačí, že cesta do uzlu B vede přes uzel C a má délku 3. Zatím však nezná všechny možné cesty do uzlu B, a tak neví, zda je to cesta nejkratší. Proto se bude v dalších krocích znovu ptát všech svých sousedů, zde přes ně nevede cesta ještě kratší.

Obecně si každý uzel vždy volí minimum z toho, co "již umí" on sám (tj. z cesty, kterou již má poznačenu ve své směrovací tabulce), a co "umí" jeho sousedé (samozřejmě s uvážením své vzdáleností od těchto sousedů). Příkladem může být opět uzel E, který si již na počátku do své směrovací tabulky zanese, že jeho vzdálenost od uzlu D je 5 (což je délka jejich přímého spojení). Již v prvním kroku však od svého souseda C zjistí, že jeho vzdálenost od uzlu D je jen 2. Když si k tomu připočítá svou vzdálenost od uzlu C (tj. 1), vyjde mu, že cesta do uzlu D, vedená přes uzel C, je kratší. Tuto skutečnost si pak poznačí do své směrovací tabulky .

Zde by algoritmus mohl končit, v praxi se však budou jeho kroky neustále opakovat, aby obsah směrovacích tabulek mohl reagovat na průběžné změny v síti.

Právě naznačený algoritmus distribuovaného směrování byl používán v síti ARPA (základu dnešní sítě Internet), a jednotlivé kroky algoritmu zde probíhaly s intervalem 640 milisekund. Ukázalo se však, že režie je přeci jen příliš vysoká - že vzájemné předávání informací mezi sousedními uzly (které vlastně představuje předávání celých směrovacích tabulek) neúnosně zatěžovalo dostupné přenosové cesty na úkor "užitečných" dat. Proto byl uvedený algoritmus distribuovaného směrování v síti ARPA nahrazen jiným - o něm si ale budeme povídat později.

 

Transportní vrstva

Hlavním úkolem transportní vrstvy referenčního modelu ISO/OSI je poskytovat efektivní přenosové služby své bezprostředně vyšší (tj. relační) vrstvě. Tyto služby přitom mohou mít spojovaný (connection-oriented) i nespojovaný (connectionless) charakter. Stejný charakter a stejnou podstatu však mají i služby síťové vrstvy, které transportní vrstva sama využívá. Do značné míry analogické jsou v obou vrstvách i mechanismy adresování a řízení toku dat. Zákonitě se pak nabízí otázka, proč je vlastně nutná samostatná transportní vrstva, když alespoň na první pohled nenabízí nic principiálně jiného, než vrstva síťová?

Komunikace dvou koncových účastníků se transportní vrstva zúčastňuje jen na obou koncových počítačích, zatímco v jednotlivých meziuzlech se na přenosu podílí jen tři nejnižší vrstvy - fyzická, linková a síťová. V případě rozlehlých sítí jsou tyto mezilehlé uzly (též: uzly IMP) často jen přepojovacími uzly v rámci komunikační podsítě, a vyšší vrstvy u nich nemusí být vůbec realizovány. Tak je tomu například u většiny veřejných datových sítí, které jsou provozovány nejrůznějšími spojovými organizacemi. A zde je právě kámen úrazu - je-li komunikační podsíť majetkem spojové organizace, musí uživatelé a jejich koncové (hostitelské) počítače vystačit s tím, co jim komunikační podsíť prostřednictvím své síťové vrstvy nabízí. Chtějí-li něco jiného - například spolehlivou přenosovou službu místo nespolehlivé, spolehlivější místo méně spolehlivé, spojovanou místo nespojované apod. - musí si vše potřebné zajistit sami. A to právě v transportní vrstvě.

K čemu slouží transportní vrstva?

Transportní vrstva je tedy v referenčním modelu ISO/OSI především proto, aby vyšším vrstvám poskytovala kvalitnější přenosové služby, než jaké ve skutečnosti dokáže poskytovat vrstva síťová. Současně s tím pak může uživatele resp. vyšší vrstvy odstiňovat od konkrétních specifik používané komunikační podsítě, od její přenosové technologie, a především pak od všech nedokonalostí podsítě. Transportní vrstva je tedy vlastně rozhraním mezi poskytovateli přenosových služeb (komunikační podsítí) a jejich uživateli (nejvyššími třemi vrstvami). Je také "poslední instancí", která může změnit nespojovaný charakter poskytované přenosové služby na spojovaný a naopak. To je možné udělat také na úrovni síťové vrstvy , nikoli však již na úrovni vyšších vrstev, které jsou uživateli těchto služeb.

Síťové vs. transportní spojení

K lepšímu pochopení úlohy transportní vrstvy nám pomůže bližší přiblížení rozdílu mezi transportním a síťovým spojením. Transportní spojení (transport connection) je spojení, které vzniká mezi dvěma entitami transportní vrstvy (v případě spojovaných služeb). Ve skutečnosti je však realizováno prostřednictvím nižších vrstev, tedy prostřednictvím síťových spojení (network connections) jako spojení mezi dvěma entitami na úrovni síťové vrstvy. Standardně se každé jednotlivé transportní spojení realizuje prostřednictvím jednoho síťového spojení. Pokud ale transportní spojení požaduje vyšší přenosovou kapacitu, než jakou dokáže zajistit jedno síťové spojení, může být jedno transportní spojení zajišťováno pomocí více spojení síťových. Transportní vrstva se pak stará o rozdělení přenášených dat mezi jednotlivá síťová spojení tak, aby to pro vyšší vrstvy bylo transparentní (tj. neviditelné).

Může však nastat i opačný případ. Pokud je zapotřebí vytvořit více transportních spojení s relativně malými nároky na přenosovou kapacitu, může být vždy několik z nich realizováno prostřednictvím jediného síťového spojení. Takováto potřeba nastává např. při použití více terminálů, z nichž každý vyžaduje samostatné transportní spojení se vzdálených počítačem. Jsou-li ale tyto terminály používány spíše příležitostně a jsou-li fyzicky blízko sebe, může být dosti neekonomické zřizovat pro každý z nich samostatné síťové spojení. Potřebné přepínání (multiplexování) jednoho sdíleného síťového spojení mezi více transportních spojení pak zajišťuje opět transportní vrstva.

Kvalita služeb síťové vrstvy

Pro transportní vrstvu je velmi podstatné, jakou kvalitu může předpokládat u služeb, které jí poskytuje síťová vrstva. Této kvalitě pak musí být přizpůsobeny přenosové protokoly transportní vrstvy, mají-li vyšší vrstvy odstiňovat od všech specifik a nedokonalostí komunikační podsítě resp. síťové vrstvy.

Služby síťové vrstvy se v této souvislosti rozdělují na tři kategorie - viz tabulka 35.3. Do kategorie A patří síťové služby, které ztrácí či přenáší s chybou jen zcela zanedbatelné procento paketů, a u kterých prakticky nedochází k výpadkům již jednou navázaných spojení. Takovéto síťové služby lze považovat za (téměř) dokonalé, a transportní vrstva pak má při jejich použití nejméně práce. Kvality kategorie A dosahují síťové služby některých lokálních sítí, zatímco v případě rozlehlých sítí je kategorie A vzácnější než šafrán.

Do kategorie C pak patří všechny ostatní síťové služby. Transportní vrstva je musí považovat za nespolehlivé, a potřebnou spolehlivost zajistit sama. Protokoly transportní vrstvy, které musí využívat služby této kategorie, jsou pak samozřejmě nesložitější a nejkomplikovanější.

Třídy transportních protokolů

Referenční model ISO/OSI se vyrovnává s odlišnou kvalitou služeb na úrovni síťové vrstvy zavedení pěti různých tříd přenosových protokolů na úrovni transportní vrstvy (transportních protokolů).

Do třídy 0 (TP0, Transport Protocol class 0) patří transportní protokoly, které využívají síťové služby kategorie A. Jsou jednoduchou "obálkou" nad příslušnými síťovými protokoly, a navíc zajišťují prakticky jen nezbytné navazování a rušení transportních spojení.

 

Třída 1 (TP1) předpokládá použití síťových služeb kategorie B, a musí se tedy umět vyrovnat s případnými výpadky spojení na úrovni síťové vrstvy.

 

Třída 2 (TP2) předpokládá opět použití síťových služeb kategorie A, tedy takových, které může považovat za dostatečně spolehlivé - stejně jako v případě třídy 0. Transportní protokoly třídy 2 jsou však navíc schopné zajistit potřebné multiplexování jednoho síťového spojení mezi více spojení transportních (viz výše).

Třída 3 (TP3) je kombinací tříd 1 a 2. Předpokládá síťové služby kategorie B, a dokáže je multiplexovat mezi více spojení transportních.

 

Třída 4 (TP4) je určena pro použití nad síťovými službami kategorie C. Transportní protokoly této třídy musí "počítat s nejhorším", a jsou tedy ze všech transportních protokolů nejsložitější a nejkomplikovanější.

 

 Relační vrstva

Jak jsme si již naznačili dříve, čtyři nejnižší vrstvy referenčního modelu ISO/OSI jsou zaměřeny především na vlastní přenos dat mezi jednotlivými uzlovými počítači. Každá z nich přitom poskytuje "o něco více" než vrstva bezprostředně nižší - čtvrtá (tj. transportní) vrstva pak nabízí prostředky pro takovou komunikaci dvou koncových počítačů resp. účastníků, která je nezávislá na konkrétní komunikační podsíti, na její topologii i na dalších specifikách. Vyšší vrstvy referenčního modelu ISO/OSI jsou pak již orientovány spíše na potřeby síťových aplikací. Samy využívají přenosové služby transportní vrstvy, a přidávají k nim takové funkce a schopnosti, které by měly být užitečné pro většinu aplikací. Takový je tedy smysl existence páté (relační), šesté (prezentační), a vlastně i sedmé (aplikační) vrstvy ISO/OSI modelu.

Referenční model ISO/OSI tedy vychází z představy, že jednotlivé aplikace by měly mít k dispozici a měly by využívat ještě dokonalejší a obecnější služby, než jaké nabízí transportní vrstva. Jejich realizaci pak referenční model svěřuje relační (session) a prezentační (presentation) vrstvě. Mlčky tím ovšem předpokládá, že je budou využívat všechny aplikace, nebo alespoň většina z nich - jen pak totiž má rozumný smysl realizovat je pro všechny aplikace společně. Existuje ale velké množství aplikací, které tento předpoklad nesplňují, a které plně vystačí s takovými službami, jaké nabízí již transportní vrstva. V tomto ohledu není jistě bez zajímavosti, že "konkurenční" soustava protokolů TCP/IP vychází z přesně opačné úvahy než referenční model ISO/OSI - svým aplikacím nabízí pouze přenosové služby na úrovni transportní vrstvy. Potřebuje-li některá aplikace resp. služba aplikační vrstvy služby obecnějšího charakteru, musí si je realizovat sama vlastními silami. To je také důvod, proč soustava protokolů TCP/IP, na které je vybudována např. síť ARPANET resp. dnešní Internet, s existencí relační a prezentační vrstvy vůbec nepočítá.

Relační vrstvu s takovými funkcemi, jaké jí přisuzuje referenční model ISO/OSI, neměla v době jeho zavedení žádná síť - snad s výjimkou sítě SNA firmy IBM, která má obdobné funkce realizovány ve více různých vrstvách.

Při vytváření samotného referenčního modelu ISO/OSI byla kolem relační vrstvy a jejích úkolů velká diskuse. Některé alternativní návrhy, které se v té době objevily, s relační vrstvou dokonce vůbec nepočítaly. Nakonec se však relační vrstva do referenčního modelu přeci jen prosadila. Spolu se svou bezprostředně nadřazenou (tj. prezentační vrstvou) však byla a nadále je relativně nejméně propracovanou vrstvou.

Co je vlastně relace?

Pro správné pochopení smyslu relační vrstvy je dobré si nejprve ozřejmit onen poněkud vágní termín relace (session). Nejnázornější bude zřejmě analogie s telefonním hovorem - ten je třeba nejprve vytočit (čímž vzniká analogie transportního spojení), a pak je možné jeho prostřednictvím vést rozhovor (relaci) dvou účastníků.

Relaci tedy můžeme považovat za spojení mezi dvěma koncovými účastníky na úrovni bezprostředně vyšší, než je vrstva transportní. Obvykle je každé takovéto spojení (relace) zajišťováno prostřednictvím jednoho transportního spojení (tj. spojení na úrovni transportní vrstvy), které je zřizováno a rušeno při zřizování resp. rušení relace. Je ovšem možný i takový případ, kdy jedno transportní spojení zajišťuje dvě nebo více po sobě jdoucích relací. Použijeme-li opět analogii s telefonním hovorem, odpovídá tato situace tomu, že dva účastníci telefonního hovoru svůj rozhovor dokončí, ale místo zavěšení předají telefon jiné dvojici, která se může začít bavit o něčem zcela jiném - tedy zahájit nový rozhovor (relaci).

Podobně, jako se transportní vrstva snaží zakrýt případné výpadky spojení na úrovni síťové vrstvy, měla by se i relační vrstva dokázat vyrovnat s případným výpadkem transportního spojení, a zajistit pokračování relace prostřednictvím nově zřízeného transportního spojení. V naší "telefonní" analogii to odpovídá situaci, kdy v průběhu rozhovoru dvou účastníků je jejich hovor přerušen, a oni si musí zavolat znovu, aby svůj rozhovor dokončili.

Zajímavou odlišností relace od transportního spojení je i způsob jejího ukončení. V případě transportního spojení nabízí referenční model ISO/OSI jen prostředky pro jednostranné direktivní ukončení spojení, kterému druhá strana nemá možnost zabránit. Na úrovni relační vrstvy se však předpokládá spíše ukončení na základě vzájemné dohody obou zúčastněných stran. Přesněji na návrh jedné strany, který ale druhá strana má možnost odmítnou a zajistit si tak pokračování relace.

Řízení dialogu

Jedním z hlavních úkolů relační vrstvy je řízení dialogu mezi oběma koncovými účastníky. Tak jako při telefonním rozhovoru není možné (či alespoň slušné), aby oba účastníci mluvili současně, existují i v počítačových sítích takové aplikace, které vyžadují koordinované střídání obou zúčastněných při vysílání (například různé aplikace transakčního charakteru apod.).

Relační vrstva tento požadavek zajišťuje obvykle pomocí mechanismu předávání pověření k přenosu dat (data token) - vysílat data smí vždy jen ten, kdo vlastní tento pomyslný štafetový kolík (pověření resp. token). Relační vrstva přitom nabízí prostředky, pomocí kterých lze pověření předat, nebo si jej naopak vyžádat.

Obecně se na úrovni relační vrstvy rozlišují tři způsoby vedení dialogu :

 

Mechanismus předávání pověření se přitom týká samozřejmě jen poloduplexního dialogu. Zdůrazněme si však, že způsob vedení dialogu nemá nic společného s duplexním, poloduplexním či ev. simplexním charakterem přenosového kanálu. Všechna spojení v referenčním modelu ISO/OSI jsou obecně plně duplexní, a umožňují tedy současný přenos dat oběma směry. Různé aplikace však z různých důvodů nemusí této možnosti využívat, a po plně duplexním spoji mohou vést jen poloduplexní dialog.

Synchronizace

Dalším důležitým úkolem relační vrstvy je tzv. synchronizace (synchronization, též: checkpointing). K jejímu pochopení si nejprve představme následující situaci: příjemcem dat v rámci určité relace nechť je počítač, který si přijímaná data průběžně zapisuje na disk, případně je ihned tiskne na tiskárně. Dojde-li náhle k poruše disku či tiskárny (nebo jí např. dojde papír, toner apod.), může příjemce přijít o určitý objem dat, které jinak v pořádku přijal (tj. které byly transportní vrstvou bezchybně doručeny).

Co je pak zapotřebí, je možnost "vrátit se o kousek zpět", a ztracená data přenést znovu. Tedy znovu dosáhnout potřebné synchronizace (vzájemného souladu). Relační vrstva řeší tento problém možností vkládat do přenášených dat kontrolní body (synchronization points, checkpoints). Příjemci pak umožňuje, aby si na vysílajícím vyžádal návrat k zadanému kontrolnímu bodu, a nové vyslání těch dat, která leží za tímto bodem. Není ovšem úkolem relační vrstvy pamatovat si přenášená data tak, aby byl možný návrat k existujím kontrolním bodům. Tato data si musí "pamatovat" sám jejich odesilatel, který služeb relační vrstvy využívá. Aby si ale nemusel uchovávat zbytečně velké objemy dat, rozlišuje relační vrstva dva druhy kontrolních bodů - hlavní (major) a vedlejší (minor). Rozdíl mezi nimi je ten, že přes vedlejší kontrolní bod se vracet lze, zatímco přes hlavní kontrolní bod již nikoli. Pro vysílajícího z toho pak vyplývá, že si musí "pamatovat" přenášená data jen od posledního hlavního kontrolního bodu.

 

Prezentační vrstva

Pět nejnižších vrstev referenčního modelu ISO/OSI dělá vše pro to, aby přenášená data vždy dorazila ke svému koncovému příjemci přesně v takové podobě, v jaké byla vyslána. Stejná "podoba" však ještě nezaručuje, že pro příjemce nebudou jedna a tatáž data představovat něco jiného, než pro jejich odesilatele.

Obavy z různé interpretace přenášených dat nejsou zdaleka bezdůvodné. Stačí si uvědomit, že např. střediskové počítače firmy IBM používají pro kódování znaků kód EBCDIC, zatímco drtivá většina ostatních používá ke stejnému účelu kód ASCII. Ke znázornění celých čísel se znaménkem používá většina počítačů tzv. dvojkový doplňkový kód, ale např. počítače CDC Cyber pracují s tzv. jedničkovým doplňkovým kódem. Mikroprocesory 80x86 firmy Intel číslují jednotlivé byty (ve slovech, dvojslovech atd.) jedním směrem, zatímco například mikroprocesory řady M68000 firmy Motorola číslují jednotlivé byty přesně opačně. Velmi časté jsou pak také odlišnosti například ve formátu čísel v pohyblivé řádové čárce, odlišné rozsahy zobrazitelných celých čísel (dané počtem k tomu vyhrazených bitů) apod.

Různé počítače tedy v obecném případě používají různé způsoby vnitřní reprezentace dat. Mají-li si takové počítače svá data korektním způsobem vzájemně předávat, musí být vhodným způsobem zajištěny jejich nezbytné konverze. A ty má v referenčním modelu ISO/OSI na starosti právě prezentační vrstva (presentation layer).

Prezentační vrstva se tedy stará o to, aby například celé číslo bez znaménka s hodnotou 234 bylo přijato opět jako celé číslo bez znaménka s hodnotou 234, a ne např. jako celé číslo se znaménkem s hodnotou -22. Není však již úkolem prezentační vrstvy zabývat se tím, co toto číslo znamená. Zda jde např. o počet osob, o číslo stránky v knize, o procentuální výši inflace či něco docela jiného. To přísluší až vlastním aplikacím, které jsou zdrojem resp. příjemcem těchto dat.

Pro zajištění nezbytných konverzí na úrovni prezentační vrstvy se nabízí dvě základní možnosti. První z nich představuje vzájemné přímé přizpůsobení stylu "každý s každým", při kterém jsou přenášená data konvertována jen jednou - jsou-li ovšem k dispozici nezbytné konverzní rutiny pro libovolnou dvojici komunikujících uzlů. Ve druhém případě jsou přenášená data konvertována dvakrát: ze tvaru, se kterým pracuje odesilatel, jsou nejprve převedena do společného "mezitvaru", a z něj pak do takového tvaru, s jakým pracuje jejich příjemce. Nevýhoda dvojí konverze je zde kompenzována tím, že pro každou konkrétní reprezentaci dat, se kterou pracuje nějaký počítač, stačí jediná konverzní utilita pro jejich převod z/do společného "mezitvaru". Referenční model ISO/OSI předpokládá právě tuto druhou variantu se společným mezitvarem. Podívejme se proto na její podstatu poněkud podrobněji.

Chtějí-li vzájemně spolupracovat dvě různé síťové aplikace, musí se nejprve domluvit na společných datových strukturách, které budou používat - tedy například na tom, že datum budou reprezentovat jako záznam (record) tvořený třemi položkami (DEN, MESIC a ROK), které jsou samy o sobě celými čísly bez znaménka. Tyto datové struktury je ovšem nutné vyjádřit tak, aby jejich popis byl pro obě strany srozumitelný, a obě strany si jej také stejně vykládaly. Kdyby byly všechny síťové aplikace psány v jediném vyšším programovacím jazyku, stačilo by použít právě tento jazyk. Předpoklad použití jediného programovacího jazyka však nebyl, není a zřejmě nikdy nebude v praxi splněn, a tak bylo nutné vytvořit pro potřeby formálního popisu dat a datových struktur zvláštní jazyk, který byl nazván ASN.1 (Abstract Syntax Notation). Umožňuje definovat jednotlivé datové položky, stanovit jejich typ (tj. určit, zda jde např. o celé číslo se znaménkem, znakový řetězec či logickou hodnotu apod.), přidělit jim jméno (identifikátor), a také sestavit z jednoduchých datových položek obecnější datové struktury typu záznam, pole, seznam, množina apod.

Jazyk ASN.1, který vzdáleně připomíná jazyk Pascal, je tedy jazykem pro formální popis dat - což se v terminologii ISO/OSI modelu označuje jako abstraktní syntaxe (abstract syntax). Abstraktní proto, že ještě neurčuje žádný konkrétní způsob reprezentace těchto dat. Pro potřeby vlastního přenosu je ale samozřejmě nutné veškerá data vhodným způsobem zakódovat. Způsob kódování datových struktur jazyka ASN.1 pro potřeby jejich přenosu pak určuje samostatná norma organizace ISO (IS 8825). Formát skutečně přenášených dat se přitom v terminologii ISO/OSI modelu označuje jako přenosová syntaxe (transfer syntax). Její konkrétní tvar je založen na myšlence, že každá jednotlivá položka dat by měla být samoidentifikující, tedy měla by sebou nést i informaci o vlastním typu. Každá datová položka proto má při přenosu tři části, které po řadě určují její typ, délku a vlastní obsah .

Kdykoli chce nějaká entita aplikační vrstvy zaslat určitá data své partnerské entitě na jiném uzlovém počítači, předá "své" prezentační vrstvě jednak vlastní data, která si přeje odeslat, a jednak jejich popis v jazyce ASN.1 (který definuje jejich abstraktní syntaxi). Prezentační vrstva na základě tohoto popisu dokáže správně interpretovat jednotlivé položky dat (určit mj. jejich typ a velikost), a na základě toho je pak zakódovat do takového tvaru, který je vhodný pro přenos, a který si sebou nese potřebné informace o typu a formátu přenášených dat (tj. převést je do přenosové syntaxe). Prezentační vrstva na straně příjemce pak díky tomu dokáže správně určit typ a formát přijatých dat, a v případě potřeby provést nezbytné konverze. Jestliže například přenosová syntaxe počítá s vyjádřením celých čísel se znaménkem ve dvojkovém doplňku, ale příjemce používá ke stejnému účelu jednotkový doplněk, může prezentační vrstva příjemce provést nezbytné konverze ještě dříve, než přijatá data předá své bezprostředně vyšší (tj. aplikační vrstvě).

Prezentační vrstvy příjemce a odesilatele se však nejprve musí shodnout na tom, jaké datové struktury si vlastně budou předávat, a jakou budou pro ně používat přenosovou syntaxi. Proto se musí obě strany na začátku vzájemného spojení (přesněji: při zahajování relace) nejprve dohodnout na jednom nebo několika tzv. kontextech, jak se v terminologii ISO/OSI modelu nazývá přiřazení přenosové syntaxe k syntaxi abstraktní. V průběhu relace se pak mohou mezi těmi kontexty, na kterých se oba dohodli, dokonce přepínat.

V současné době je praktické používání jazyka ASN.1 značně usnadněno existencí překladačů z tohoto jazyka do obvyklých vyšších programovacích jazyků, např. do Pascalu či jazyka C. je vstupem tohoto překladače popis datových struktur v jazyku ASN.1, a výstupem jednak ekvivalentní popis v příslušném cílovém jazyku (tedy např. v C či v Pascalu), který pak lze přilinkovat ke zdrojovému tvaru vlastní aplikace, a dále také kódovací a dekódovací rutiny (určené pro potřeby prezentační vrstvy), které převádí datové struktury z příslušného cílového jazyka přímo do jejich přenosové syntaxe resp. obráceně.

Hlavním úkolem prezentační vrstvy je tedy zajištění nezbytných konverzí přenášených dat. Není to ovšem úkol jediný - na úrovni prezentační vrstvy může být například řešeno také zabezpečení přenášených dat pomocí šifrování (encryption), které ovšem lze realizovat i na úrovni fyzické nebo transportní vrstvy. Pro minimalizaci objemu přenášených dat pak může být na úrovni prezentační vrstvy zajišťována i jejich komprimace (compression).

 

Aplikační vrstva

Bylo by jistě nošením dříví do lesa tvrdit, že počítače jsou zde proto, aby dělaly něco užitečného, a vyjmenovávat, co všechno to může být. Přesto neuškodí přesněji vymezit pojem aplikace (aplikačního programu, aplikačního procesu, aplikační úlohy) jako té části programového vybavení, která zajišťuje ony "užitečné funkce", kvůli kterým se počítače vůbec používají. Protipólem je pak zbývající část programového vybavení, která zajišťuje fungování počítače jako takového, a jednotlivým aplikacím vytváří takové prostředí, ve kterém mohou úspěšně pracovat.

Jde-li o samostatný počítač, jsou aplikacemi jednotlivé uživatelské programy, a "zbývající" částí programového vybavení je operační systém, který uživatelským programům zprostředkovává využití nejrůznějších zdrojů a prostředků daného počítače - disků, operační paměti, klávesnice, displeje, dalších V/V zařízení apod. V případě uzlů počítačové sítě je pak odlišnost pouze v tom, že síťový operační systém, který v sobě implementuje jednotlivé vrstvy vrstvového síťového modelu, zprostředkovává aplikacím navíc ještě všechno to, co vlastní síť nabízí - tedy především možnost komunikace s aplikacemi, běžícími na jiných uzlových počítačích, případně i přístup k technickým prostředkům jiných uzlových počítačů atd.

Nyní již si můžeme přesněji vymezit funkci aplikační vrstvy (application layer) v rámci referenčního modelu ISO/OSI. V prvním přiblížení lze říci, že je určena k tomu, aby aplikacím poskytovala přístup do prostředí sítě na bázi ISO/OSI modelu, tedy aby fungovala jako jakési okno (či brána) mezi aplikacemi na různých uzlových počítačích, které si chtějí vzájemně vyměňovat nějaké informace.

Představy o podstatě a mechanismu fungování aplikační vrstvy se však v průběhu existence referenčního modelu ISO/OSI vyvíjely a značně zpřesňovaly. Původní představu, která se objevila v první verzi referenčního modelu. Zde se předpokládalo, že jednotlivé uživatelské aplikace budou zasahovat až do vlastní aplikační vrstvy - přesněji: ty části aplikací, které se bezprostředně týkají sítě a jejího využití, budou přímou součástí aplikační vrstvy (v terminologii ISO/OSI modelu se tyto části aplikací označovaly jako aplikační entity, resp. application entities). Zbývající části aplikací již nebyly považovány za součást "síťového prostředí ISO/OSI modelu".

Tato představa znamenala, že jednotlivé aplikace (resp. ty jejich části, které tvořily aplikační entity) si musely samy zajišťovat všechny služby, potřebné na úrovni aplikační vrstvy (a to pomocí služeb, poskytovaných resp. zprostředkovaných prezentační vrstvou). Referenční model ISO/OSI tyto služby na úrovni aplikační vrstvy nijak podrobněji nespecifikoval, pouze je vymezil jako "takové, které jsou potřeba pro vzájemnou komunikaci mezi otevřenými systémy, a nejsou zajišťovány na nižších úrovních". Nespecifikoval samozřejmě ani žádné protokoly, prostřednictvím kterých by služby aplikační vrstvy měly být realizovány. Jednotlivé protokoly pro aplikační vrstvu vznikaly až dodatečně, v průběhu práce na implementaci síťových aplikací různého typu. Přitom se ale ukázalo, že většina těchto aplikací má mnoho společného, a tudíž se nevyplatí, aby si každá z nich vždy znovu implementovala to, co na úrovni aplikační vrstvy potřebuje. Proto se původní představa referenčního modelu změnila: zajištění služeb na úrovni aplikační vrstvy bylo svěřeno aplikačním entitám, které ale již nejsou součástí jednotlivých aplikací, ale jsou naopak součástí síťového programového vybavení.

Diferenciace na úrovni aplikační vrstvy pak pokračovala ještě dále. Zjistilo se totiž, že takto koncipované aplikační entity je nejvýhodnější sestavovat z ještě menších stavebních bloků, které zajišťují jednotlivé dílčí funkce resp. služby. Tyto stavební bloky se v současné terminologii referenčního modelu ISO/OSI označují jako prvky ASE (Application Service Elements). Jsou v zásadě dvojího druhu: takové, které zajišťují služby, potřebné pro podporu aplikací různých typů (pak jde o tzv. prvky CASE, Common Application Service Element), a konečně takové, které realizují specifické služby, potřebné jen pro jeden konkrétní typ aplikací (označované jako prvky SASE, Specific Application Service Element).

Vezměme si jako příklad otázku vzájemné komunikace dvou aplikací. Ta může být realizována buď jako spojovaná, prostřednictvím (logického) spojení mezi dvěma aplikačními entitami, nebo jako nespojovaná, zajišťovaná jednoduchou výměnnou zpráv. Logické spojení na úrovni aplikační vrstvy, v terminologii ISO/OSI modelu označované jako asociace (association), však musí někdo navázat, udržovat jej, a posléze zase zrušit. To má na starosti jeden z možných prvků ASE, konkrétně ACSE (Association Control Service Element), který patří mezi "podpůrné" prvky ASE, tj. mezi prvky CASE.

Nespojovaná komunikace na úrovni aplikační vrstvy, realizovaná jako výměna krátkých zpráv, má vesměs charakter vzdáleného volání procedur (remote procedure call, v terminologii ISO: vzdálených operací, remote operation), při kterém přenášené zprávy žádají o provedení určité akce (provedení resp. volání procedury), resp. vrací její výsledky. Pro zajištění takovéhoto způsobu komunikace je pak určen jiný druh podpůrného prvku (prvku CASE), a to ROSE (Remote Operations Service Element).

Dalším příkladem podpůrného prvku je prvek CCR (Commitment, Concurrency and Recovery), který je určen především pro koordinaci vzájemné součinnosti více uzlů a pro implementaci transakčního zpracování v sítích. Umožňuje dosáhnout toho, aby posloupnost operací, vyžádaná jedním uzlem a prováděná na jiném uzlu, se vždy provedla buďto celá, nebo se neprovedla vůbec, bez ohledu na případné výpadky, poruchy apod.

Mezi specifické aplikační služby, které mají na starosti prvky CASE, patří například přenos souborů, elektronická pošta, vzdálené terminálové relace apod. Referenční model ISO/OSI přitom předpokládá, že tyto služby budou implementovány tak, aby se vůči vlastním aplikačním procesům "tvářily" vždy stejně, jako jediné virtuální zařízení (virtual device). Nejmarkantnější je tento přístup na způsobu, jakým se model ISO/OSI vyrovnává se značnou různorodostí používaných terminálů, lišících se svými parametry, způsobem ovládání apod. Mechanismus, umožňující terminálu jednoho uzlového počítače vystupovat v roli (lokálního) terminálu jiného počítače, počítá s existencí tzv. virtuálního terminálu. Jde vlastně o abstrakci, o hypotetický terminál, který nemusí ve skutečnosti vůbec existovat, ale který se vždy chová stejně. Uzlový počítač pak může předpokládat, že pracuje vždy jen s tímto jediným typem (virtuálního) terminálu, zatímco ve skutečnosti pracuje s terminálem jiným. Potřebné přizpůsobení mezi virtuálním terminálem a skutečně používaným terminálem pak zajišťuje až konkrétní aplikační proces, který "svůj" terminál dobře zná a dokáže ovládat. Podobně je tomu i v případě přenosu souborů mezi odlišnými a vzájemně neslučitelnými souborovými systémy (které se mohou lišit například ve vnitřní organizaci souborů a adresářů, v konvencích pro jejich jména apod.). Zda se opět zavádí společný "mezitvar" v podobě virtuálního systému souborů, se kterým aplikační entity dokáží pracovat.

Pokud síťová aplikace potřebuje jiné služby, než jaké jsou jí nabízeny v souvislosti s představou virtuálního zařízení, musí si je sama podle svých konkrétních potřeb upravit. V rámci většiny aplikací lze proto ještě vymezit vrstvu, která zajišťuje potřebné přizpůsobení resp. zamapování virtuálního zařízení z/do skutečného - tedy např. "mapování" virtuálního terminálu do konkrétního reálného terminálu, "mapování" reálného systému souborů do virtuálního apod. V terminologii ISO/OSI modelu se tato vrstva označuje jako (uživatelský) prvek UE (User Element) .

Pro specifické služby na úrovni aplikační vrstvy (poskytované prvky SASE, viz výše), byly a jsou postupně vytvářeny potřebné protokoly. Většina z nich dnes již má formu mezinárodních standardů resp. norem (IS, International Standards), jiné jsou zatím ještě ve stádiu návrhů norem (DIS, Draft International Standard). Jejich stručný přehled obsahuje tabulka 38.4., která uvádí také obdobně zaměřené aplikační protokoly v "konkurenční" soustavě protokolů TCP/IP.