Ji°φ Peterka

╚ßst 4. - Pilφ°e vzßjemnΘ spoluprßce

DneÜnφ poΦφtaΦovΘ sφt∞ pou₧φvajφ velmi Üirok² repertoßr p°enosov²ch technologiφ - od dru₧icov²ch a mikrovlnn²ch spoj∙, p°es spoje optickΘ a₧ po r∙znΘ druhy drßtov²ch spoj∙. VÜechny tyto p°enosovΘ technologie majφ svß specifika, vypl²vajφcφ jak z fyzikßlnφch a obvodov²ch vlastnostφ pou₧itΘ p°enosovΘ cesty (nap°. koaxißlnφho kabelu, kroucenΘ dvoulinky, telefonnφ linky Φi optickΘho vlßkna), tak i z konkrΘtnφho zp∙sobu jejφho vyu₧itφ - nap°φklad po stejnΘm druhu optickΘho vlßkna m∙₧eme alternativn∞ p°enßÜet data rychlostφ 10 Mbit/sekundu (u tzv. optickΘho Ethernetu), Φi rychlostφ 100 Mbit/sekundu (v p°φpad∞ FDDI) apod. Stejn∞ tak mohou b²t tytΘ₧ p°enosovΘ protokoly provozovßny nad r∙zn²mi p°enosov²mi cestami - nap°φklad sφt∞ typu Ethernet mohou k fyzickΘmu p°enosu dat pou₧φvat bu∩ koaxißlnφ kabely nebo kroucenou dvoulinku a nov∞ji i optickß vlßkna, zatφmco p°enosovΘ protokoly FDDI mohou b²t p°enßÜeny nejen po optick²ch vlßknech, ale takΘ po kroucenΘ dvoulince atd.

Jednou z v²hod vrstvovΘ koncepce, ze kterΘ vÜechny dneÜnφ sφt∞ vychßzφ, je pak nezßvislost vyÜÜφch vrstev na pou₧φvanΘ p°enosovΘ technologii - tΘ se musφ p°izp∙sobit jen urΦit² poΦet ni₧Üφch vrstev, zatφmco vÜechny vyÜÜφ mohou b²t °eÜeny nezßvisle na konkrΘtnφ p°enosovΘ technologii.

V p°φpad∞ sedmivrstvΘho referenΦnφho modelu ISO/OSI, o kterΘm jsme se zmi≥ovali minule, jsou na konkrΘtnφ p°enosovΘ technologii zßvislΘ nejni₧Üφ dv∞ vrstvy, tj. vrstva fyzickß a vrstva linkovß. V p°φpad∞ rodiny protokol∙ TCP/IP jde o jedinou nejni₧Üφ vrstvu (vrstvu sφ¥ovΘho rozhranφ), kterß odpovφdß ob∞ma nejni₧Üφm vrstvßm referenΦnφho modelu ISO/OSI, ale kterou sφ¥ov² model TCP/IP nijak blφ₧e nespecifikuje - oΦekßvß toti₧, ₧e pro praktickou implementaci tΘto vrstvy budou pou₧ita ji₧ existujφcφ Φi nov∞ vznikajφcφ °eÜenφ, vytvß°enß nezßvisle na protokolech TCP/IP. Tv∙rci referenΦnφho modelu ISO/OSI naopak p°edpoklßdali, ₧e pot°ebnΘ standardy pro vÜechny pou₧itelnΘ p°enosovΘ technologie vytvo°φ sami. Teprve pozd∞ji uznali, ₧e velmi ₧ivotaschopnΘ p°enosovΘ technologie mohou vznikat i mimo rßmec ISO/OSI, a tak p°φsluÜnΘ standardy do referenΦnφho modelu alespo≥ formßln∞ p°ejφmajφ.

Linkovß vrstva se rozpadla

Naproti tomu u ni₧Üφch vrstev referenΦnφho modelu ISO/OSI doÜlo k jinΘ zajφmavΘ situaci: linkovß vrstva se rozpadla na dv∞ Φßsti, oznaΦovanΘ jako podvrstvy (sublayers).

Pro sprßvnΘ pochopenφ d∙vod∙, kter² k tomu vedly, je vhodnΘ si nejprve ujasnit p°φsluÜn² Φasov² horizont: referenΦnφ model ISO/OSI vznikl zhruba ve stejnΘ dob∞ jako protokoly TCP/IP, a to na p°elomu sedmdesßt²ch a osmdesßt²ch let. V tΘ dob∞ ovÜem existovaly prakticky jen sφt∞ rozlehlΘ (sφt∞ WAN, Wide Area Networks), zatφmco lokßlnφ sφt∞ se prosadily p°eci jen o n∞co pozd∞ji (viz tΘ₧ box: Nenφ Ethernet jako Ethernet).

RozlehlΘ sφt∞ ovÜem byly (a stßle jeÜt∞ jsou) budovßny tΘm∞° v²luΦn∞ na dvoubodov²ch spojφch, zatφmco lokßlnφ sφt∞ pou₧φvajφ jak dvoubodovΘ, tak i mnohobodovΘ spoje - tedy takovΘ, ke kter²m je fyzicky p°ipojeno vφce uzl∙, ne₧ jen dva (jako je tomu u dvoubodovΘho spoje). Zßsadnφ rozdφl je pak v tom, ₧e u dvoubodovΘho spoje nemohou vznikat ₧ßdnΘ vß₧n∞jÜφ konflikty mezi uzly, kterΘ cht∞jφ zaΦφt vysφlat (u tzv. pln∞ duplexnφho spoje tak mohou Φinit oba souΦasn∞, a u tzv. poloduplexnφho spojenφ se musφ vhodn∞ st°φdat). Naproti tomu u vφcebodovΘho spoje se m∙₧e stßt, ₧e ·mysl zaΦφt vysφlat projevφ vφce uzl∙ souΦasn∞ - zatφmco vyhov∞t lze jen jednomu z nich. Proto zde musφ nastoupit vhodn² mechanismus, kter² mezi vÜemi zßjemci vybere jednoho, a tomu skuteΦn∞ umo₧nφ vysφlat. Typick²m p°φkladem m∙₧e b²t koaxißlnφ kabel, na kter² m∙₧e b²t p°φmo p°ipojeno vφce uzl∙, ale na kter² m∙₧e v danΘm okam₧iku vysφlat nejv²Üe jeden uzel.

Mechanismy, zajiÜ¥ujφcφ korektnφ p°φstup jednotliv²ch zßjemc∙ o vysφlßnφ ke spoleΦn∞ sdφlenΘmu p°enosovΘmu mΘdiu, mohou b²t zalo₧eny na velmi odliÜn²ch principech a myÜlenkßch, a pou₧φvat velmi odliÜnΘ mechanismy. SpoleΦn∞ jsou pak oznaΦovßny jako p°φstupovΘ metody (access methods).

ReferenΦnφ model ISO/OSI (stejn∞ tak jako TCP/IP) vÜak s existencφ p°φstupov²ch metod nepoΦφtal, a tyto do n∞j musely b²t teprve dodateΦn∞ zaΦlen∞ny. OvÜem kam, resp. do kterΘ vrstvy? P°φstupovΘ metody rozhodn∞ pat°φ nad fyzickou vrstvu, proto₧e samy vyu₧φvajφ slu₧eb typu "p°enes bit/p°ijmi bit". SouΦasn∞ ale pat°φ pod vrstvu sφ¥ovou, kterß se ji₧ starß o sprßvnΘ sm∞rovßnφ (tj. volbu trasy, po kterΘ majφ b²t celΘ bloky dat p°enßÜeny), a nikoli ji₧ o jejich skuteΦn² p°enos mezi dv∞ma sousednφmi poΦφtaΦi, kter² mß na starosti vrstva linkovß.

P°φstupovΘ metody je tedy nutnΘ implementovat na ·rovni linkovΘ vrstvy. Jednou z mo₧nostφ by jist∞ bylo vzφt vÜechny konkrΘtnφ protokoly linkovΘ vrstvy, a do ka₧dΘho z nich "zabudovat" p°φsluÜnou p°φstupovou metodu. Zde je ovÜem t°eba si uv∞domit, ₧e r∙znΘ druhy p°enosov²ch cest vy₧adujφ pou₧itφ specifick²ch p°φstupov²ch metod. To by ale znamenalo, ₧e od ka₧dΘho jednotlivΘho p°enosovΘho protokolu linkovΘ vrstvy by bylo t°eba "vyrobit" tolik variant se zabudovan²mi p°φstupov²mi metodami, kolik takov²chto p°φstupov²ch metod existuje, Φi bude teprve vytvo°eno. A to jist∞ nenφ rozumnΘ °eÜenφ.

Mnohem vhodn∞jÜφ je implementovat p°φstupovou metodu nezßvisle na p°enosov²ch protokolech linkovΘ vrstvy. To ovÜem znamenß vlo₧it mezi fyzickou vrstvu a vrstvu linkovou novou samostatnou vrstvu, a p°φstupovou metodu pak implementovat v tΘto novΘ vrstv∞. Z koncepΦnφch d∙vod∙ ovÜem nebylo vhodnΘ tuto novou vrstvu °eÜit skuteΦn∞ jako samostatnou a postavit ji na rove≥ ostatnφm vrstvßm. Mφsto toho se zvolil kompromis - nov∞ vlo₧enß vrstva je koncipovßna jako podvrstva (sublayer) linkovΘ vrstvy, kterß se v d∙sledku toho rozd∞lila na dv∞ podvrstvy: vyÜÜφ podvrstva, oznaΦovanß jako podvrstva LLC (Logical Link Control sublayer, Φesky nejspφÜe: podvrstva °φzenφ logickΘho spoje) si ponechala ·koly, kterΘ jsme a₧ dosud p°isuzovali celΘ linkovΘ vrstv∞ - v zßsad∞ tedy p°enos cel²ch blok∙ dat (rßmc∙). Ni₧Üφ podvrstva, oznaΦovanß jako podvrstva MAC (Media Access Sublayer, Φesky: podvrstva °φzenφ p°φstupu k p°enosovΘmu mΘdiu), naopak dostala za ·kol zajiÜ¥ovat korektnφ p°φstup ke sdφlenΘmu p°enosovΘmu mΘdiu (tedy implementaci p°φsluÜnΘ p°φstupovΘ metody).

U sφ¥ovΘho modelu TCP/IP, dφky jeho zßsad∞ "co je pod sφ¥ovou vrstvou, to jde mimo mne", nemuselo dojφt k ₧ßdnΘ zm∞n∞.

Standardy lokßlnφch sφtφ

V∞tÜina dnes pou₧φvan²ch standard∙ pro lokßlnφ sφt∞ pochßzφ od americkΘho sdru₧enφ elektrotechnick²ch a elektronick²ch in₧en²r∙ IEEE (Institute of Electrical and Electronic Engineers), p°esn∞ji od jejφ pracovnφ skupiny pro lokßlnφ sφt∞, oznaΦovanΘ podle data jejφho zalo₧enφ (v ·noru roku 1980) Φφslem 802. Tato pracovnφ skupina se dßle d∞lφ na specificky zam∞°enΘ podskupiny (viz tabulka 1), od kter²ch pochßzφ jednotlivΘ konkrΘtnφ standardy. Tyto jsou oznaΦovßny jako IEEE 802.x, kde x je Φφslo podskupiny, vyjad°ujφcφ souΦasn∞ i zam∞°enφ standardu. Pokud n∞kterß podskupina vypracovßvß vφce standard∙, tyto jsou oznaΦovßny jeÜt∞ jin²m zp∙sobem - viz tabulka 2. Do referenΦnφho modelu ISO/OSI byly standardy IEEE 802 p°evzaty pod oznaΦenφm ISO 8802.x

Tabulka 2: Alternativnφ standardy podskupiny IEEE 802.3

oznaΦenφ standardu	standard schvßlen v roce	co standard definuje
10 Base 5	1985	sφt∞ CSMA/CD (Ethernet) s p°enosovou rychlostφ 10 Mbit/sekundu po tzv. tlustΘm koaxißlnφm kabelu, s max. dΘlkou souvislΘho kabelovΘho segmentu 500 metr∙
10 Base 2 (tΘ₧: 802.3a, "Cheapernet", "Thinnet")	1988	sφt∞ CSMA/CD (Ethernet) s p°enosovou rychlostφ 10 Mbit/sekundu po tzv. tenkΘm koaxißlnφm kabelu, s max. dΘlkou souvislΘho kabelovΘho segmentu cca 200 metr∙ (p°esn∞ 185 m.)
1 Base 5 (tΘ₧: 802.3e)	1988	sφt∞ CSMA/CD (Ethernet) s p°enosovou rychlostφ 1 Mbit/sekundu po tzv. kroucenΘ dvoulince, s max. dΘlkou kabelu 500 m (podle sφt∞ AT&T Starlan)
10 Broad 36 (tΘ₧: 802.3b)	1988	sφt∞ CSMA/CD (Ethernet) s p°enosovou rychlostφ 10 Mbit/sekundu po koaxißlnφm kabelu v tzv. p°elo₧enΘm pßsmu (broadband), s max. dΘlkou souvislΘho kabelovΘho segmentu 3,6 km
10 Base T	1990	sφt∞ CSMA/CD (Ethernet) s p°enosovou rychlostφ 10 Mbit/sekundu po tzv. kroucenΘ dvoulince, s max. dΘlkou kabelu 100 m.

KonkrΘtnφ zp∙sob zaΦlen∞nφ standard∙ IEEE 802 do sedmivrstvΘho referenΦnφho modelu ISO/OSI ukazuje obrßzek 1. Z n∞j je takΘ patrnΘ, kterΘ vrstvy a podvrstvy jednotlivΘ standardy pokr²vajφ.

Obr. 1.: Standardy IEEE 802.x vs. referenΦnφ model ISO/OSI

Existujφ ovÜem i jinΘ vÜeobecn∞ p°ijφmanΘ a v praxi hojn∞ pou₧φvanΘ standardy pro lokßlnφ sφt∞, kterΘ nepochßzφ od sdru₧enφ IEEE. Z nich je nejv²znamn∞jÜφ standard FDDI (Fiber Distributed Data Interface) pro sφt∞ na bßzi optick²ch vlßken s p°enosovou rychlostφ 100 Mbit/sekundu, kter² vypracovala americkß normotvornß organizace ANSI (American National Standards Institute), konkrΘtn∞ jejφ pracovnφ skupina ASC X3T9.5.

Obr.2: Standard FDDI vs. referenΦnφ model ISO/OSI

KoncepΦn∞ se standard FDDI liÜφ od standard∙ IEEE 802.x v tom, ₧e krom∞ linkovΘ vrstvy d∞lφ na dv∞ podvrstvy i vrstvu fyzickou - viz obrßzek 2. Tφm vznikajφ celkem Φty°i podvrstvy, a FDDI definuje samostatnΘ dφlΦφ standardy pro t°i nejni₧Üφ (zatφmco pro nejvyÜÜφ podvrstvu LLC p°ejφmß p°φsluÜn² standard IEEE 802.2). Krom∞ toho definuje v samostatnΘm dφlΦφm standardu i prost°edky pro °φzenφ a sprßvu sφt∞ (Station Management), kterΘ zasahujφ a₧ do podvrstvy °φzenφ p°φstupu ke sdφlenΘmu mΘdiu (podvrstvy MAC).

Do referenΦnφho modelu ISO/OSI pak byly vÜechny Φty°i dφlΦφ standardy FDDI op∞t p°evzaty, a to pod oznaΦenφm ISO 9314.

D∙sledky rozd∞lenφ linkovΘ vrstvy

Kdy₧ jsme si v minulΘm dφlu popisovali, jak²m zp∙sobem prochßzφ p°enßÜenß data postupn∞ jednotliv²mi vrstvami vrstvovΘho modelu, ukßzali jsme si, ₧e v ka₧dΘ z nich jsou data "vlo₧ena do novΘ obßlky" - neboli jsou k nim p°ipojeny °φdφcφ ·daje, urΦenΘ pro partnerskou entitu stejnolehlΘ vrstvy vzdßlenΘho poΦφtaΦe. Nynφ toto platφ i pro ob∞ podvrstvy linkovΘ vrstvy - ka₧dß z nich vklßdß p°enßÜenß data do vlastnφ "obßlky", oznaΦovanΘ v tomto p°φpad∞ jako rßmec (frame). Situaci nßzorn∞ ilustruje obrßzek 3.

Obr.3: Vklßdßnφ paket∙ do rßmc∙ podvrstvy LLC a MAC

Pro podvrstvu LLC byl standardem IEEE 802.2 p∙vodn∞ navr₧en jednotn² rßmec (viz obr. 4), kter² mj. specifikuje p°echodovΘ body (body SAP, viz minul² dφl) na stran∞ p°φjemce i odesilatele, skrz kterΘ jsou data p°edßvßna mezi linkovou a sφ¥ovou vrstvou. Tφm tyto dva ·daje nep°φmo urΦujφ, kdo je odesilatelem a kdo p°φjemcem p°enßÜen²ch dat na ·rovni sφ¥ovΘ vrstvy, a tφm souΦasn∞ i p°esn² v²znam datovΘ Φßsti rßmce - tedy to, podle kterΘho protokolu sφ¥ovΘ vrstvy byla datovß Φßst rßmce sestavena. Pozd∞ji se vÜak ukßzalo, ₧e jeden jedin² byte, vyhrazen² k identifikaci p°echodovΘho bodu (a tφm i sφ¥ovΘho protokolu), by nemusel v₧dy staΦit, a tak se zavedl jeÜt∞ dalÜφ druh rßmce podvrstvy LLC, oznaΦovan² jako IEEE 802.2 SNAP (od: Sub-Network Access Protocol). Ten pak pro identifikaci sφ¥ovΘho protokolu pou₧φvß p∞t samostatn²ch byt∙ (viz op∞t obr. 4), a od p∙vodnφho rßmce IEEE 802.2 jej lze rozpoznat dφky tomu, ₧e oba p∙vodnφ byty pro identifikaci p°echodov²ch bod∙ mß pevn∞ nastaveny na hodnotu AA (hexadecimßln∞).

Obr.4: Rßmce IEEE 802.2 a 802.2 SNAP podvrstvy LLC

Rßmce pro podvrstvu MAC jsou pak ji₧ specifickΘ pro konkrΘtnφ p°φstupovou metodu, resp. pou₧itou p°enosovou cestu - jinΘ jsou tedy pro sφt∞ typu Ethernet, Token Ring Φi Token Bus (a takΘ pro FDDI). V naÜem dalÜφm v²kladu se vÜak omezφme jen na sφt∞ typu Ethernet, kterΘ jsou u nßs zdaleka nejrozÜφ°en∞jÜφ.

V p°φpad∞ sφtφ typu Ethernet je nep°φjemn² problΘm v tom, ₧e pro n∞ existujφ dva ne zcela shodnΘ standardy - tzv. Ethernet II a IEEE.802.3. (viz box: Nenφ Ethernet jako Ethernet). Oba definujφ vlastnφ rßmce na ·rovni podvrstvy MAC (viz obr. 5): tyto shodn∞ obsahujφ Ethernetovou adresu p°φjemce a odesilatele (ka₧dou v rozsahu 48 bit∙, tj. Üesti byt∙), a takΘ zßv∞reΦn² kontrolnφ souΦet (v rozsahu Φty° byt∙). LiÜφ se ale v obsahu dvou dalÜφch byt∙ (konkrΘtn∞ 13. a 14., viz obrßzek 5): v p°φpad∞ Ethernetu II tyto dva byty specifikujφ, kterΘmu protokolu sφ¥ovΘ vrstvy "pat°φ" datov² obsah rßmce, zatφmco v p°φpad∞ rßmce IEEE 802.3 tytΘ₧ dva byty vyjad°ujφ dΘlku datovΘ Φßsti rßmce.

Obr.5: Rßmce IEEE 802.3 a Ethernet II podvrstvy MAC

Pokud bychom cht∞li za tφmto rozdφlem hledat n∞jakΘ racionßlnφ jßdro, pak je z°ejm∞ nßsledujφcφ: standard Ethernet byl vyvinut jako samostatn² standard, zasahujφcφ jen do ·rovn∞ podvrstvy MAC. Nep°edpoklßdß tedy nic o tom, jakΘ protokoly budou pou₧ity na vyÜÜφch vrstvßch (a hlavn∞ na ·rovni podvrstvy LLC), a proto musφ sßm nabφzet mo₧nost, jak identifikovat datov² obsah svΘho rßmce. Naproti tomu standard IEEE 802.3 byl vytvo°en jako souΦßst ÜirÜφ skupiny standard∙. Formßt rßmce IEEE 802.3 (tj. rßmec podvrstvy MAC) proto poΦφtß s tφm, ₧e uvnit° jeho datovΘ Φßsti bude v₧dy umφst∞n rßmec IEEE 802.2 (tj. rßmec podvrstvy LLC), a ten ji₧ obsahuje vÜe pot°ebnΘ k identifikaci protokolu, podle kterΘho jsou sestavena skuteΦn∞ p°enßÜenß data - tak₧e tuto informaci nenφ nutnΘ znovu replikovat i v rßmci IEEE 802.3 (tj. v rßmci podvrstvy MAC).

Podφvejme se nynφ, jak je tomu v praxi.

Sφ¥ov² model TCP/IP nijak blφ₧e nespecifikuje svou nejni₧Üφ vrstvu (vrstvu sφ¥ovΘho rozhranφ), a tudφ₧ ani nijak nep°edepisuje, do jak²ch Ethernetov²ch rßmc∙ majφ b²t vklßdßny datovΘ pakety sφ¥ovΘ vrstvy (tj. tzv. IP datagramy). Existujφ vÜak doporuΦenφ, popisujφcφ jak²m zp∙sobem vklßdat IP datagramy do rßmc∙ Ethernet II, i do rßmc∙ IEEE 802.3 (vΦetn∞ rßmc∙ 802.2 SNAP podvrstvy LLC). Tato doporuΦenφ majφ formu dokument∙ RFC, vydßvan²ch provozovateli sφt∞ Internet. Na Unixovsk²ch poΦφtaΦφch se pak lze v∞tÜinou setkat se vÜemi mo₧n²mi variantami, a obvykle i s mo₧nostφ v²b∞ru.

Pon∞kud jinß je situace u tolik oblφben²ch lokßlnφch sφtφ NetWare firmy Novell. Tato firma dala jednoznaΦn∞ p°ednost rßmc∙m dle standardu IEEE 802.3. ZaΦala je vÜak systematicky pou₧φvat ji₧ v dob∞, kdy jeÜt∞ nebyl dokonΦen standard IEEE 802.2 pro podvrstvu LLC. Z tohoto d∙vodu se v sφtφch NetWare zaΦaly vklßdat sφ¥ovΘ pakety (tj. pakety sφ¥ovΘho protokolu IPX) p°φmo do rßmc∙ podvrstvy MAC (tj. do rßmc∙ IEEE 802.3), a tedy bez rßmc∙ podvrstvy LLC (rßmc∙ IEEE 802.2) - viz obrßzek 5. Tento formßt pak firma Novell sama oznaΦuje jako "raw" 802.3 (doslova: "hol²" rßmec 802.3), a podle vlastnφch slov je jedinß, kdo jej pou₧φvß. Aby vÜak vyÜla vst°φc pot°ebßm vzßjemnΘho propojovßnφ sφtφ a budovßnφ heterogennφch sφtφ (tj. takov²ch sφtφ, ve kter²ch jednotlivΘ uzly pou₧φvajφ r∙znΘ r∙znΘ p°enosovΘ protokoly, ale sdφlφ spoleΦnΘ p°enosovΘ mΘdium), umo₧nila firma Novell u₧ivatel∙m sv²ch sφtφ NetWare zvolit si jin² zp∙sob vklßdßnφ sφ¥ov²ch paket∙ (IPX paket∙) do rßmc∙ linkovΘ vrstvy. Mo₧nosti, kterΘ p°ipadajφ v ·vahu, jsou nßsledujφcφ (viz tΘ₧ obr. 6):

Obr.6: Mo₧nosti rozliÜenφ rßmc∙ a jejich kombinacφ

• "raw" IEEE 802.3 (tj. bez rßmc∙ 802.2),
• Ethernet II,
• IEEE 802.3 s rßmci 802.2
• IEEE 802.3 s rßmci 802.2 SNAP

Pokud u₧ivatel (resp. sprßvce sφt∞) nestanovφ jinak, jsou implicitn∞ pou₧φvßny "raw" rßmce IEEE 802.3. V nedßvnΘ dob∞ (konkrΘtn∞ od 15. dubna 1993) vÜak firma Novell, vedenß snahou maximßln∞ dodr₧ovat vÜeobecn∞ uznßvanΘ standardy, zm∞nila toto implicitnφ nastavenφ na rßmce IEEE 802.3 s rßmci 802.2. U₧ivatelΘ vÜak majφ nadßle mo₧nost explicitn∞ si vybrat jinou mo₧nost.

Zajφmavou otßzkou, kterß se v tuto chvφli nabφzφ, je to, zda je mo₧nΘ vÜechny Φty°i v²Üe uvedenΘ mo₧nosti jednoznaΦn∞ identifikovat. Odpov∞∩ je naÜt∞stφ kladnß.

Rßmce Ethernet II a IEEE 802.3 je mo₧nΘ rozliÜit dφky jejich maximßlnφ mo₧nΘ dΘlce a dφky konvenci o p°id∞lovßnφ Φφsel, kterΘ v rßmcφch Ethernet II identifikujφ jednotlivΘ protokoly sφ¥ovΘ vrstvy - tato Φφsla jsou v₧dy v∞tÜφ ne₧ 1500, zatφmco maximßlnφ velikost datovΘ Φßsti rßmce IEEE 802.3 (uvßd∞nß na stejnΘm mφst∞ jako Φφslo protokolu v rßmcφch Ethernet II) je prßv∞ 1500.

Podle hodnoty t°inßctΘho a ΦtrnßctΘho bytu ka₧dΘho p°ijatΘho rßmce je tedy mo₧nΘ rozpoznat, zda jde o rßmec Ethernet II Φi o rßmec IEEE 802.3. Pokud jde o tuto druhou mo₧nost, tedy o rßmec IEEE 802.3, jak postupovat dßle a zjistit, zda obsahuje jeÜt∞ rßmec IEEE 802.2 (resp. 802.2 SNAP), Φi zda jde o "raw" rßmec, kter² ji₧ obsahuje p°φmo paket sφ¥ovΘho protokolu IPX? Zde je mo₧nΘ vyu₧φt konvence, kterou si sama zavedla firma Novell: prvnφ dva byty ka₧dΘho paketu IPX, vklßdanΘ do "raw" rßmce 802.3, jsou v₧dy nastaveny na hodnotu FFFF (hexadecimßln∞). Tato hodnota nenφ v souΦasnΘ dob∞ pou₧φvßna v polφch DSAP a SSAP rßmc∙ IEEE 802.2, kterΘ identifikujφ p°echodovΘ body mezi linkovou a sφ¥ovou vrstvou. Po testu t°inßctΘho a ΦtrnßctΘho bytu tedy lze otestovat hodnotu dalÜφch dvou byt∙. Jsou-li rovny FFFF (hexadecimßln∞), jde o "raw" rßmec IEEE 802.3. Jsou-li rovny AAAA (hexadecimßln∞), jde o rßmec IEEE 802.3 s vlo₧en²m rßmcem IEEE 802.2 SNAP. Jinak jde o rßmec IEEE 802.3 s vlo₧en²m rßmcem 802.2.

Je ale takovΘto slo₧itΘ rozliÜovßnφ v∙bec n∞kdy zapot°ebφ? Odpov∞∩ je op∞t kladnß - jinak by toti₧ nemohly existovat multiprotokolovΘ pßte°nφ sφt∞, kterΘ pomocφ jednΘ p°enosovΘ technologie (na ·rovni linkovΘ vrstvy, v naÜem konkrΘtnφm p°φpad∞ Ethernetu) p°enßÜφ vφce r∙zn²ch sφ¥ov²ch protokol∙ souΦasn∞. Jak by m∞l postupovat nap°φklad multiprotokolov² sm∞rovaΦ (router), kter² pot°ebuje znßt p°esn² typ ka₧dΘho p°ijatΘho datovΘ rßmce, aby mohl aplikovat jemu p°φsluÜnß pravidla sm∞rovßnφ a dokßzal zvolit sprßvn² sm∞r, kter²m mß paket poslat dßle?

Pot°eba demultiplexu sφ¥ov²ch paket∙

Ukßzkov²m p°φkladem m∙₧e b²t bezdiskovß stanice v sφti NetWare, na kterΘ u₧ivatel provozuje slu₧bu FTP (z rodiny protokol∙ TCP/IP), a jejφm prost°ednictvφm p°enßÜφ soubor ze vzdßlenΘho UnixovskΘho poΦφtaΦe na sv∙j sφ¥ov² disk na file serveru sφt∞ Novell. Ka₧d² "kus" takto p°enßÜenΘho souboru je nejprve p°enesen z UnixovskΘho poΦφtaΦ na pracovnφ stanici u₧ivatele, a z nφ je pak p°enesen na file server sφt∞ NetWare.

Jedno·lohovost operaΦnφho systΘmu v tomto p°φpad∞ nenφ p°ekß₧kou (proto₧e p°ipojenφ sφ¥ov²ch disk∙ z file serveru je zajiÜ¥ovßno rezidentnφmi programy, zatφmco slu₧ba FTP je provozovßna na pop°edφ). Velmi podstatnΘ je ovÜem to, ₧e v danΘm p°φpad∞ na jednom poΦφtaΦi vedle sebe existujφ dv∞ sestavy protokol∙ (protocol stacks), kterΘ se musφ dokßzat pod∞lit o jeden technick² prost°edek, zajiÜ¥ujφcφ fyzick² p°enos dat po sφti - v naÜem p°φpad∞ o sφ¥ovou kartu. V obecnΘm p°φpad∞ m∙₧e b²t takov²chto sestav protokol∙ vedle sebe vφce, a potencißlnφch p°φjemc∙ dat m∙₧e b²t dokonce jeÜt∞ vφce - n∞kterΘ aplikace toti₧ mohou p°φsluÜnΘ sestavy protokol∙ Φi jejich Φßsti sdφlet.

P°i odesφlßnφ dat principißlnφ problΘmy nenastßvajφ. P°i p°φjmu je ale situace pon∞kud slo₧it∞jÜφ. VÜechna p°ijφmanß data vstupujφ do uzlovΘho poΦφtaΦe jednφm vstupnφm bodem (jsou p°ijφmßna jednou sφ¥ovou kartou), ale potencißlnφch koneΦn²ch p°φjemc∙ m∙₧e b²t vφce. Podle Φeho a jak mß b²t sprßvn² p°φjemce vyhledßn? Na kterΘ ·rovni a jak mß b²t jeho v²b∞r proveden? Jak prakticky zajistit to, aby se p°φsluÜnß data dostala a₧ k takto vybranΘmu p°φjemci?

Odpov∞∩ na tyto otßzky nenφ jednoduchß. Rozd∞lovßnφ p°ijat²ch dat mezi r∙znΘ p°φjemce nem∙₧e b²t realizovßno ji₧ na ·rovni fyzickΘ vrstvy, nebo¥ ta pouze p°ijφmß jednotlivΘ bity, ale nijak je neinterpretuje. Proto ani nem∙₧e rozpoznßvat, komu jsou urΦeny, a musφ je vÜechny p°edßvat jedinΘmu p°φjemci - jednΘ konkrΘtnφ entit∞ na ·rovni linkovΘ vrstvy.

Tato entita je prvnφ instancφ, na kterΘ je mo₧nΘ p°ichßzejφcφ data rozd∞lovat - vφce entitßm na ·rovni sφ¥ovΘ vrstvy. K tomu vÜak entita linkovΘ vrstvy pot°ebuje sprßvn∞ rozpoznat datov² obsah ka₧dΘho p°ijatΘho rßmce, a z n∞j si pak odvodit, kterΘ entit∞ na ·rovni sφ¥ovΘ vrstvy jej mß p°edat.

Uka₧me si to na konkrΘtnφm p°φkladu sφtφ typu Ethernet, kter²m jsme se a₧ dosud zab²vali. Zjistφ-li p°ijφmajφcφ entita na ·rovni linkovΘ vrstvy, ₧e jde o tzv. "raw" rßmec IEEE 802.3, pak si z toho m∙₧e odvodit, ₧e jeho datov² obsah mß p°edat do sφ¥ovΘ vrstvy tΘ entit∞, kterß implementuje p°enosov² protokol IPX sφtφ NetWare. Jde-li o rßmec Ethernet II, dozvφ se z n∞j, kterΘmu p°enosovΘmu protokolu sφ¥ovΘ vrstvy datov² obsah rßmce "pat°φ". Pak si musφ zjistit, p°es kter² p°echodov² bod (bod SAP, Service Access Point) se dostane na entitu, implementujφcφ p°φsluÜn² protokol v sφ¥ovΘ vrstv∞, a p°es takto zjiÜt∞n² p°echodov² bod pak data skuteΦn∞ p°edß. Jde-li o rßmec IEEE 802.3 s vlo₧en²m rßmcem 802.2, mß entita linkovΘ vrstvy k dispozici jeÜt∞ podrobn∞jÜφ informaci - dozvφ se toti₧ explicitn∞, p°es kter² p°echodov² bod mß data p°edat do sφ¥ovΘ vrstvy. Dφky tomu je pak mo₧nΘ ji₧ na ·rovni linkovΘ vrstvy rozliÜit vφce instancφ tΘho₧ sφ¥ovΘho protokolu, co₧ v p°edchozφm p°φpad∞ nebylo mo₧nΘ. Obdobn∞ pak pro rßmec 802.3 s vlo₧en²m rßmcem 802.2 SNAP.

DalÜφ "rozv∞tvovßnφ" pak samoz°ejm∞ m∙₧e probφhat i na ·rovni sφ¥ovΘ vrstvy i vrstev vyÜÜφch, ovÜem ji₧ podle specifick²ch pravidel konkrΘtnφch protokol∙ t∞chto vrstev.

Nenφ Ethernet jako Ethernet

DalÜφ podstatn² rozdφl mezi standardem IEEE 802.3 a skuteΦn²m Ethernetem (DIX Ethernetem, Ethernetem II) je pak i v jejich dalÜφm v²voji. Zatφmco skuteΦn² Ethernet se ji₧ dßle p°φliÜ nevyvφjφ, pracovnφ skupiny a podskupiny v rßmci IEEE pracujφ stßle, a upravujφ svΘ standardy pro nov∞ se objevujφcφ p°enosovΘ technologie. Jestli₧e tedy skuteΦn² Ethernet poΦφtß pouze s pou₧itφm koaxißlnφho kabelu o pr∙m∞ru p∙l palce a impedanci 50 Ohm∙ (znßmΘho tΘ₧ jako tzv. tlust² kabel), standard IEEE 802.3 postupn∞ zφskal n∞kolik dalÜφch alternativ, kterΘ dovolujφ pou₧φvat mj. i tenΦφ koaxißlnφ kabel (o pr∙m∞ru 0,2 palce, tzv. tenk² kabel) Φi nestφn∞nou kroucenou dvoulinku.