VzßjemnΘ propojovßnφ sφtφ - I.
P°i naÜem povφdßnφ o referenΦnφm modelu ISO/OSI jsme a₧ doposud uva₧ovali pouze v dimenzφch jedinΘ poΦφtaΦovΘ sφt∞, a neuva₧ovali jejφ mo₧nΘ vazby na sφt∞ jinΘ. U₧ivatelΘ vÜak dnes stßle nalΘhav∞ji volajφ po vzßjemnΘm propojovßnφ existujφcφch sφtφ, kterΘ by bylo co mo₧nß nejuniverzßln∞jÜφ, ale souΦasn∞ i co nejmΘn∞ "viditelnΘ", tak aby o n∞m museli v∞d∞t co nejmΘn∞. V ideßlnφm p°φpad∞ by m∞la zcela zaniknout jakßkoli specifika jednotliv²ch sφtφ, aby se u₧ivatel mohl domnφvat, ₧e pracuje v jednΘ jedinΘ, vÜezahrnujφcφ sφti. Podφvejme se proto nynφ, jakΘ jsou principißlnφ mo₧nosti vzßjemnΘho propojovßnφ sφtφ. V dalÜφch dφlech si pak ukß₧eme, jak k tΘto problematice p°istupuje referenΦnφ model ISO/OSI i n∞kterΘ dalÜφ sφ¥ovΘ architektury..
Vzßjemn²m propojenφm dvou Φi vφce sφtφ stejnΘho Φi r∙znΘho typu vznikß v∞tÜφ celek, pro kter² mß angliΦtina velmi v²sti₧nΘ oznaΦenφ: internetwork, nebo jen internet (zatφmco Internet - s velk²m I - je jmΘno celosv∞tovΘ poΦφtaΦovΘ sφt∞ resp. konglomerßtu sφtφ, kter² vznikl v USA ze zßrodeΦnΘ sφt∞ ARPANET, viz nap°. CW 7/92, str. 12). ╚eÜtina vÜak vhodn² termφn pro oznaΦovßnφ vzßjemn∞ propojen²ch sφtφ teprve hledß).
Problematika vzßjemnΘho propojovßnφ sφtφ a jejich souΦinnosti (v angliΦtin∞: internetworking) je sama o sob∞ znaΦn∞ rozsßhlß, rychle se vyvφjφ, a je dnes velmi populßrnφ. V souΦasnΘ dob∞ existuje °ada r∙zn²ch koncepcφ toho, jak poΦφtaΦovΘ sφt∞ navzßjem propojovat. Pro jejich pochopenφ je ale klφΦov²m momentem poznßnφ toho, ₧e vzßjemnΘ propojenφ je mo₧nΘ realizovat na r∙zn²ch ·rovnφch vrstvovΘho sφ¥ovΘho modelu - od fyzickΘ a₧ po aplikaΦnφ vrstvu.
Zßkladnφ myÜlenka vzßjemnΘho propojenφ je naprosto trivißlnφ - dv∞ nebo vφce sφtφ se propojφ prost°ednictvφm k tomu urΦen²ch za°φzenφ, obecn∞ oznaΦovan²ch jako relay, v terminologii ISO tΘ₧: Intermediary System resp. IS, p°φpadn∞: Internetworking Unit resp. IWU.
OpakovaΦe
Zmφn∞nΘ propojujφcφ za°φzenφ p°itom m∙₧e b²t pouh²m zesilovaΦem elektrick²ch signßl∙, kterΘ jsou v sφti p°enßÜeny. Tak je tomu nap°φklad v lokßlnφch sφtφch typu Ethernet, kterΘ umo₧≥ujφ dosßhnout celkovΘ dΘlky kabelß₧e a₧ 2,5 kilometru, ale jednotlivΘ p°ipojovacφ obvody (tzv. transceivery) jsou schopnΘ generovat elektrickΘ signßly s dosahem jen asi 500 metr∙. Pak je nutnΘ sestavovat celΘ kabelovΘ vedenφ ze segment∙ (souvisl²ch ·sek∙ kabel∙) dΘlky maximßln∞ 500 metr∙ (v p°φpad∞ tzv. tlustΘho Ethernetu, resp. 200 metr∙ v p°φpad∞ tzv. tenkΘho Ethernetu). JednotlivΘ segmenty se pak musφ spojovat pomocφ za°φzenφ, kterß se v tomto p°φpad∞ naz²vajφ opakovaΦe (repeaters), a fungujφ prßv∞ a pouze jako zesilovaΦe elektrick²ch signßl∙. OpakovaΦe tedy pracujφ na ·rovni fyzickΘ vrstvy, nebo¥ vzhledem k zesilovßnφ elektrick²ch signßl∙ "vnφmajφ" jen jednotlivΘ p°enßÜenΘ bity, ale nikoli ji₧ celΘ bloky (rßmce) dat.
Mosty
Nev²hodou opakovaΦ∙ je skuteΦnost, ₧e "propouÜtφ" veÜker² provoz z jednoho segmentu do druhΘho, i kdy₧ by to v∙bec nebylo nutnΘ. V²hodn∞jÜφ by jist∞ byl p°φpad, kdyby propojovacφ za°φzenφ dokßzalo sprßvn∞ rozpoznat, kterß data mohou z∙stat "uvnit°" p°φsluÜnΘ Φßsti sφt∞ (segmentu), a nezat∞₧ovat jimi provoz v ostatnφch segmentech. K tomu je ale nutnΘ, aby propojovacφ za°φzenφ "vnφmalo" celΘ p°enßÜenΘ rßmce a znalo jejich formßt natolik, aby dokßzalo zjistit fyzickou adresu jejich odesilatele a p°φjemce (a podle toho je pak propustit do sousednφho segmentu Φi nikoli). To ovÜem znamenß, ₧e takovΘto propojovacφ za°φzenφ, kterΘ se pak naz²vß most (bridge), musφ pracovat na ·rovni linkovΘ vrstvy (resp. na ·rovni podvrstvy °φzenφ p°φstupu k mΘdiu (vrstvy MAC) v p°φpad∞ lokßlnφch sφtφ dle standard∙ IEEE 802), kde ji₧ lze fyzickΘ adresy p°φjemce a odesilatele rozpoznat.
Rozdφl mezi opakovaΦem a mostem spoΦφvß dßle i v mechanismu jejich fungovßnφ. Zatφmco opakovaΦ nemß pam∞¥ a p°enßÜenß data resp. signßly zpracovßvß pr∙b∞₧n∞ (je pro n∞ vlastn∞ "pr∙chozφ"), most ji₧ pracuje na principu "store and forward" (p°ijmi a p°edej dßl). Most tedy z ka₧dΘ strany pr∙b∞₧n∞ p°ijφmß jednotlivΘ datovΘ rßmce, a podle adres v nich se rozhoduje, zda je p°edß na opaΦnou stranu Φi nikoli. Existuje p°itom vφce konkrΘtnφch postup∙ a algoritm∙, kterΘ mohou mosty v tΘto souvislosti pou₧φvat.
Jednou z nejjednoduÜÜφch variant je ta, p°i kterΘ most pr∙b∞₧n∞ vyhodnocuje odesilatele jednotliv²ch rßmc∙, a podle toho, ze kterΘho sm∞ru p°φsluÜn² rßmec p°ijal, si pak sßm odvozuje umφst∞nφ jednotliv²ch uzl∙. Zßhy se tak sßm dokß₧e "nauΦit" topologii sφt∞. V dob∞, kdy ji jeÜt∞ neznß, jednoduÜe p°edßvß vÜechny rßmce do vÜech ostatnφch segment∙.
Tato metoda je velmi atraktivnφ proto, ₧e nevy₧aduje ₧ßdnΘ konfigurovßnφ mostu (kter² se vÜechno pot°ebnΘ nauΦφ sßm). JednotlivΘ uzly v sφti p°itom nemusφ o jeho existenci v∙bec v∞d∞t - proto se takΘ takov²to typ mostu oznaΦuje jako tzv. transparentnφ most (transparent bridge). Lze jej ovÜem pou₧φt jen v takov²ch sφtφch, kterΘ majφ p°φsn∞ stromovitou strukturu, kdy mezi ka₧d²mi dv∞ma uzly existuje v₧dy jen jedna jedinß cesta. Pro obecn∞jÜφ topologie jsou pak nutnΘ jinΘ, slo₧it∞jÜφ algoritmy prßce most∙.
Pokud jde o technickΘ provedenφ, mohou b²t opakovaΦe i mosty konstruovßny tak, aby vzßjemn∞ propojovaly jen dva segmenty, nebo takΘ vφce segment∙ najednou. Pak jde o tzv. vφcevstupovΘ opakovaΦe (multiport repeater) resp. vφcevstupovΘ mosty (multiport bridge).
Mosty se vyrßbφ i ve variant∞ tzv. vzdßlen²ch most∙ (remote bridge). Od standardnφ varianty most∙ (oznaΦovan²ch pro odliÜenφ takΘ jako mφstnφ mosty resp. local bridges) se vzdßlenΘ mosty liÜφ v tom, ₧e jde vlastn∞ o dv∞ relativn∞ samostatnΘ "poloviny" mostu, p°φznaΦn∞ naz²vanΘ p∙lmosty (halfbridge), kterΘ jsou mezi sebou vhodn∞ propojeny - nap°. pevn²m telefonnφm okruhem, optick²m kabelem apod. Umo₧≥ujφ propojit dva segmenty sφt∞, kterΘ nejsou fyzicky blφzko sebe. Takto lze nap°φklad propojit dva segmenty lokßlnφ sφt∞ ve dvou objektech na opaΦn²ch stranßch m∞sta, p°iΦem₧ v²sledn² efekt je takov², ₧e oba segmenty tvo°φ jedinou "logickou" sφ¥ (z pohledu sφ¥ovΘ vrstvy a vÜech vyÜÜφch vrstev je toti₧ existence mφstnφch i vzdßlen²ch most∙ transparentnφ).
N∞kterΘ mosty pak mohou mφt i schopnost selektivnφho filtrovßnφ n∞kter²ch rßmc∙ v zßvislosti na jejich odesilateli Φi p°φjemci, dennφ dob∞, intenzit∞ provozu apod. Pak jde o tzv. routing bridges, kterΘ sprßvc∙m sφtφ umo₧≥ujφ regulovat p°enosy mezi jednotliv²mi segmenty - umo₧≥ujφ nap°φklad zakßzat v dob∞ "ÜpiΦky" p°φstup z jednoho segmentu do jinΘho, a p°i poklesu intenzity provozu jej pak zase nßsledn∞ povolit.
Mosty i opakovaΦe se tedy pou₧φvajφ pro spojovßnφ jednotliv²ch segment∙ lokßlnφch sφtφ. OpakovaΦe jako jednoduÜÜφ a lacin∞jÜφ (a souΦasn∞ i rychlejÜφ) se pak volφ spφÜe tam, kde intenzita provozu nenφ velkß. Pou₧itφ most∙ (obecn∞ slo₧it∞jÜφch, dra₧Üφch a takΘ pomalejÜφch ne₧ opakovaΦe) je naopak vhodnΘ tam, kde je pot°eba vzßjemn∞ propojit segmenty s v∞tÜφ intenzitou provozu tak, aby se navzßjem nezat∞₧ovaly vφce, ne₧ je skuteΦn∞ nezbytn∞ nutnΘ.
Velmi Φastou a oblφbenou topologiφ lokßlnφch sφtφ sb∞rnicovΘho typu Ethernet je zapojenφ s tzv. pßte°φ (backbone), co₧ je segment, urΦen² p°edevÜφm pro vzßjemnΘ propojenφ ostatnφch segment∙. V²hodou tΘto topologie je skuteΦnost, ₧e spojenφ mezi kter²mikoli dv∞ma body sφt∞ prochßzφ v₧dy nejv²Üe p°es dva mosty. Nap°φklad v budov∞ o vφce patrech je mo₧nΘ vΘst jednotlivΘ segmenty horizontßln∞ po patrech, a pomocφ most∙ je p°ipojit na vertikßln∞ vedenou pßte°, kterß prochßzφ vÜemi patry.
VzßjemnΘ propojovßnφ sφtφ - II.
V minulΘm dφlu naÜeho serißlu jsme si naznaΦili, ₧e poΦφtaΦovΘ sφt∞ je mo₧nΘ vzßjemn∞ propojovat na r∙zn²ch ·rovnφch vrstvovΘho sφ¥ovΘho modelu. Podrobn∞ji jsme se pak zab²vali opakovaΦi (repeaters) a mosty (bridges), kterΘ realizujφ propojenφ na ·rovni fyzickΘ resp. linkovΘ vrstvy. Dnes budeme pokraΦovat mo₧nostmi propojovßnφ na vyÜÜφch ·rovnφch.
Vra¥me se vÜak jeÜt∞ na chvilku k most∙m. Jak jsme si ji₧ uvedli, pou₧φvajφ se tyto v lokßlnφch sφtφch pro spojovßnφ jednotliv²ch segment∙, pracujφ na ·rovni linkovΘ vrstvy (p°esn∞ji: na ·rovni podvrstvy MAC), a p°i svΘ Φinnosti vychßzφ pouze z fyzick²ch adres skuteΦnΘho odesilatele a p°φjemce jednotliv²ch rßmc∙. Vlastnφ datov² obsah jednotliv²ch rßmc∙ p°itom nijak neinterpretujφ ani nem∞nφ. Tφm jsou pro n∞ neviditelnΘ veÜkerΘ informace, kterΘ do obsahu vlastnφho rßmce zak≤dovaly protokoly vyÜÜφch vrstev, od sφ¥ovΘ poΦφnaje. Je jim ovÜem takΘ jedno, kterΘ konkrΘtnφ protokoly to byly. Jin²mi slovy: mosty jsou zcela transparentnφ pro protokoly vyÜÜφch vrstev. Dokß₧φ tedy spolupracovat s jak²mikoli sφ¥ov²mi (a vyÜÜφmi) protokoly, a p°enßÜet jejich pakety bez toho, ₧e by je jakkoli transformovaly Φi m∞nily. JednotlivΘ segmenty, kterΘ jsou vzßjemn∞ propojeny prost°ednictvφm most∙, tvo°φ z pohledu sφ¥ovΘ vrstvy (i vÜech vyÜÜφch) jedin² logick² celek, kter² mß takΘ jedinou spoleΦnou (sφ¥ovou) adresu.
Sm∞rovaΦ a jeho funkce
Jakmile vÜak budeme po₧adovat, aby si jednotlivΘ segmenty lokßlnφch zachovaly relativnφ samostatnost (nap°φklad vlastnφ sφ¥ovou adresu, mo₧nost samostatnΘ sprßvy apod.), nebo kdy₧ pot°ebujeme vzßjemn∞ propojit lokßlnφ sφt∞ r∙zn²ch typ∙, spojujeme-li dv∞ lokßlnφ sφt∞ p°es sφ¥ rozlehlou nebo vytvß°φme-li vzßjemnΘ propojenφ sφtφ se slo₧it∞jÜφ topologiφ, musφme k tomu pou₧φt obecn∞jÜφ °eÜenφ, ne₧ jakΘ nabφzφ mosty. Pot°ebujeme propojovacφ za°φzenφ, kterΘ ji₧ pracuje na ·rovni sφ¥ovΘ vrstvy, a naz²vß se sm∞rovaΦ (router). Teprve takovΘto za°φzenφ toti₧ "vnφmß" vlastnφ obsah jednotliv²ch rßmc∙ (na ·rovni linkovΘ vrstvy), dokß₧e sprßvn∞ rozpoznat formßt jednotliv²ch paket∙, kterΘ jsou v rßmcφch p°enßÜeny, a vyu₧φt informace, kterΘ jsou v nich obsa₧eny.
Hlavnφ ·kol sm∞rovaΦ∙ je vlastn∞ shodn² s ·kolem sφ¥ovΘ vrstvy - tedy postarat se o doruΦenφ paket∙ od jejich p∙vodnφho odesilatele a₧ ke koneΦnΘmu p°φjemci. Sm∞rovaΦe tedy musφ p°ijφmat rozhodnutφ o tom, kudy majφ dßle odeslat ka₧d² jednotliv² paket tak, aby se dostal ke svΘmu cφli - tedy zajiÜ¥ovat to, Φemu se b∞₧n∞ °φkß sm∞rovßnφ (routing). Musφ nutn∞ pou₧φvat n∞jak² algoritmus sm∞rovßnφ, na zßklad∞ kterΘho svß rozhodnutφ p°ijφmajφ. Jak jsme si ji₧ takΘ uvedli ve 34. dφlu, m∙₧e mφt tento algoritmus a z n∞ho vychßzejφcφ sm∞rovßnφ statickou povahu (tj. b²t nezßvislΘ na okam₧itΘm stavu sφt∞), nebo m∙₧e mφt naopak dynamickou povahu (a reagovat na pr∙b∞₧nou situaci). V tomto druhΘm p°φpad∞, kter² je dnes nejΦast∞jÜφ, pak jeÜt∞ pot°ebuje vhodnou metodu resp. protokol, prost°ednictvφm kterΘho zφskßvß pot°ebnΘ informace o stavu sφt∞.
DalÜφ charakteristickou odliÜnostφ sm∞rovaΦ∙ od most∙ je to, ₧e jsou pro ostatnφ entity na ·rovni sφ¥ovΘ a linkovΘ vrstvy viditelnΘ. Majφ svΘ adresy, a pakety, kterΘ jimi majφ projφt, jim jsou explicitn∞ adresovßny (zatφmco mosty zachycujφ veÜker² provoz v ka₧dΘm z p°ipojen²ch segment∙). Proto takΘ sm∞rovaΦe zpracovßvajφ mΘn∞ rßmc∙ ne₧ mosty, ovÜem jejich zpracovßnφ je zase o to nßroΦn∞jÜφ.
Je dobrΘ si uv∞domit, ₧e pro funkci sm∞rovaΦe je nutnΘ, aby vzßjemn∞ propojovanΘ sφt∞ pou₧φvaly stejn² protokol na ·rovni sφ¥ovΘ vrstvy - podle n∞j toti₧ sm∞rovaΦ rozpoznßvß odesilatele i adresßta jednotliv²ch paket∙, a rozhoduje o tom, kudy je dßle odeslat. Nenφ ovÜem nutnΘ, aby totΘ₧ platilo i na ·rovni linkovΘ a fyzickΘ vrstvy. Zde se ji₧ konkrΘtnφ protokoly a p°enosovΘ technologie mohou liÜit. Sm∞rovaΦe jsou dnes obvykle konstruovßny tak, aby m∞ly vφce r∙zn²ch rozhranφ (tzv. port∙), a bylo je mo₧nΘ vzßjemn∞ propojit nap°φklad pomocφ pevn²ch okruh∙, ve°ejn²ch datov²ch sφtφ, optick²ch p°enosov²ch cest, a p°ipojit k nim r∙znΘ lokßlnφ sφt∞ dle standard∙ IEEE 802 apod. V rßmci budov jsou jednotlivΘ segmenty p°ipojeny na pßte°nφ sφ¥ pomocφ most∙, zatφmco pßte°e jsou vzßjemn∞ spojeny prost°ednictvφm sm∞rovaΦ∙ (propojen²ch optick²m kabelem resp. pevn²m okruhem)
MultiprotokolovΘ sm∞rovaΦe
Po₧adavek stejnΘho (a tudφ₧ jedinΘho) protokolu v sφ¥ovΘ vrstv∞ je ovÜem velmi omezujφcφ, zvlßÜt∞ v dneÜnφ dob∞, kdy vedle sebe koexistuje celß °ada soustav protokol∙ (krom∞ ISO/OSI tΘ₧ TCP/IP, SNA, DECnet, SPX/IPX a dalÜφ), a u₧ivatelΘ volajφ po jejich co nejt∞sn∞jÜφ integraci v rßmci tzv. heterogennφch sφtφ (tj. sφtφ, jejich₧ uzly pou₧φvajφ r∙znΘ soustavy protokol∙).
ProblΘm heterogennφch sφtφ lze °eÜit v principu dv∞ma zp∙soby - konverzφ protokol∙, a sm∞rovßnφm vφce protokol∙ souΦasn∞. ╪eÜenφ prost°ednictvφm konverzφ se ukßzalo b²t znaΦn∞ nßroΦnΘ a nespolehlivΘ, a proto se prosadila p°edevÜφm druhß mo₧nost. P°ednφ v²robci dnes nabφzφ tzv. multiprotokolovΘ sm∞rovaΦe (multiprotocol routers), schopnΘ pracovat souΦasn∞ s vφce r∙zn²mi protokoly. Multiprotokolov² sm∞rovaΦ musφ b²t schopen rozpoznat typ paketu, kter² dostane od linkovΘ vrstvy, a podle toho pak aplikovat ten sm∞rovacφ algoritmus, kter² k p°φsluÜnΘmu sφ¥ovΘmu protokolu p°φsluÜφ.
Rrouter
V dneÜnφ dob∞, kdy dochßzφ ke stßle t∞sn∞jÜφmu propojovßnφ rozlehl²ch i lokßlnφch sφtφ, je pou₧itφ most∙ i sm∞rovaΦ∙ velmi rozÜφ°enΘ. Rozhodnutφ mezi tφm, zda v urΦitΘ situaci pou₧φt most Φi sm∞rovaΦ, nemusφ b²t v₧dy okam₧it∞ z°ejmΘ, zvlßÜt∞ pak u lokßlnφch sφtφ se slo₧it∞jÜφ topologiφ a v∞tÜφm poΦtem pou₧φvan²ch protokol∙. V dneÜnφ dob∞ vÜak ji₧ existujφ takΘ za°φzenφ, kterß v sob∞ kombinujφ funkce obou t∞chto za°φzenφ. V angliΦtin∞ se pro jejich oznaΦenφ pou₧φvß nejΦast∞ji termφn bridge/router, n∞kdy tΘ₧: brouter. Jde o za°φzenφ, kterΘ se sna₧φ fungovat jako sm∞rovaΦ, a teprve v okam₧iku, kdy pro n∞jak² paket neumφ aplikovat sm∞rovacφ algoritmus, p°edß p∙vodnφ rßmec dßl tak, jako by to ud∞lal most. V²hodou takovΘhoto za°φzenφ je pak i to, ₧e se dokß₧e vyrovnat s takov²mi protokoly, kterΘ v∙bec nelze sm∞rovat (nebo¥ nepoΦφtajφ se sφ¥ovou vrstvou - jako nap°φklad protokoly DECLAT (DEC Local Area Transport), LU 6.2 firmy IBM a protokoly NetBIOS).
Brßna
Pokud je pot°eba vzßjemn∞ propojit sφt∞ zcela odliÜn²ch koncepcφ, pou₧φvajφcφ zcela jinΘ soustavy protokol∙, je nutnΘ pou₧φt propojovacφ za°φzenφ, schopnΘ provßd∞t nezbytnou konverzi protokol∙. TakovΘto za°φzenφ, oznaΦovanΘ nejΦast∞ji jako brßna (gateway, n∞kdy tΘ₧: protocol converter) pak pracuje na takovΘ ·rovni, na kterΘ je mo₧nΘ p°φsluÜnou konverzi zajistit - tedy nap°φklad a₧ na ·rovni aplikaΦnφ vrstvy.
Poznamenejme vÜak jeÜt∞, ₧e pojem "brßna" resp. "gateway" se Φasto pou₧φvß i pro propojovacφ za°φzenφ na ni₧Üφch ·rovnφch. Nap°φklad v souvislosti s protokoly TCP/IP je termφn "gateway" pou₧φvßn k oznaΦenφ sm∞rovaΦe (routeru).
VzßjemnΘ propojovßnφ sφtφ a RM ISO/OSI
V minul²ch kapitolßch jsme se zab²vali mo₧nostφ vzßjemnΘho propojovßnφ poΦφtaΦov²ch sφtφ na r∙zn²ch ·rovnφch vrstvovΘho sφ¥ovΘho modelu. Uka₧me si nynφ, jak se k tΘto problematice stavφ referenΦnφ model ISO/OSI.
ReferenΦnφ model ISO/OSI samoz°ejm∞ poΦφtß s mo₧nostφ vzßjemnΘho propojovßnφ jednotliv²ch sφtφ - ve°ejn²ch i privßtnφch, rozlehl²ch i lokßlnφch - a v d∙sledku toho i s tφm, ₧e spojenφ mezi dv∞ma koncov²mi ·Φastnφky m∙₧e ve skuteΦnosti prochßzet p°es jednu Φi vφce mezilehl²ch sφtφ (kterΘ se v terminologii ISO oznaΦujφ jako podsφt∞, subnetworks). Pro transportnφ vrstvu, kterß zajiÜ¥uje p°φmou komunikaci koncov²ch ·Φastnφk∙, by ale tento fakt nem∞l b²t v∙bec viditeln² - proto referenΦnφ model ISO/OSI sv∞°uje veÜkerou agendu, spojenou se vzßjemn²m propojenφm podsφtφ, vrstv∞ sφ¥ovΘ.
Sφ¥ovß vrstva referenΦnφho modelu ISO/OSI se pak Φlenφ na t°i podvrstvy:
Podvrstva p°φstupu k podsφti, kterß je z t∞chto t°φ podvrstev nejni₧Üφ, mß na starosti to, co jsme a₧ doposud p°isuzovali celΘ sφ¥ovΘ vrstv∞ jako takovΘ - tedy p°edevÜφm sm∞rovßnφ jednotliv²ch paket∙ Φi datagram∙ - ovÜem pouze v rßmci jednΘ konkrΘtnφ podsφt∞, kde platφ stejnß pravidla pro sm∞rovßnφ, kde se pou₧φvajφ stejnΘ adresy, kde jsou k dispozici stejnΘ p°enosovΘ slu₧by atd.
Sφt∞ odliÜnΘho typu samoz°ejm∞ vy₧adujφ r∙znΘ podvrstvy p°φstupu, kterΘ ovÜem poskytujφ nestejnΘ slu₧by, vypl²vajφcφ z odliÜnΘho charakteru mechanism∙ a princip∙, na kter²ch jsou tyto sφt∞ zalo₧eny. JednotlivΘ podvrstvy p°φstupu k podsφti proto jeÜt∞ nenφ mo₧nΘ mezi sebou vzßjemn∞ propojit. Mφsto toho je nutnΘ nejprve p°izp∙sobit jimi poskytovanΘ slu₧by jednotnΘmu standardu, co₧ mß za ·kol prost°ednφ ze t°φ zmφn∞n²ch podvrstev, podvrstva p°izp∙sobenφ podsφt∞.
Pro nejvyÜÜφ podvrstvu se pak vÜechny podsφt∞ "tvß°φ" stejn∞. Podvrstva °φzenφ vzßjemn∞ propojen²ch sφtφ pak ji₧ m∙₧e zajiÜ¥ovat vÜe, co je pot°eba k doruΦovßnφ jednotliv²ch paket∙ a₧ k jejich koneΦnΘmu p°φjemci - vΦetn∞ jejich pr∙chodu skrz jednu Φi n∞kolik mezilehl²ch sφtφ prost°ednictvφm existujφcφch propojovacφch za°φzenφ (IS, Intermediary System).
Pro sprßvnΘ pochopenφ smyslu prost°ednφ podvrstvy, tedy podvrstvy p°izp∙sobenφ podsφt∞, je vhodnΘ si pon∞kud up°esnit, v Φem mohou spoΦφvat odliÜnosti jednotliv²ch sφtφ resp. podsφtφ, a jak se projevujφ.
P°edstavme si jako p°φklad dv∞ lokßlnφ sφt∞, propojenΘ prost°ednictvφm ve°ejnΘ datovΘ sφt∞ na bßzi doporuΦenφ X.25. Jednφm z nejmarkantn∞jÜφch rozdφl∙ zde bude ji₧ samotnß povaha p°enosov²ch slu₧eb na ·rovni sφ¥ovΘ vrstvy. Zatφmco lokßlnφ sφt∞ budou nejspφÜe pou₧φvat nespojovanΘ (connectionless) slu₧by, sφ¥ na bßzi X.25 pou₧φvß spojovan² (connection-oriented) mechanismus virtußlnφ okruh∙. P°i p°enosu jednotliv²ch datagram∙ z jednΘ lokßlnφ sφt∞ do druhΘ je pak nutnΘ pro ka₧d² z nich v₧dy znovu z°φdit nov² virtußlnφ okruh, a po p°enesenφ datagramu jej zase ihned zruÜit (p°φpadn∞ jeÜt∞ chvφli poΦkat, zda nebude zßhy po₧adovßn p°enos dalÜφho datagramu, pro kter² by se ji₧ vytvo°en² virtußlnφ okruh dal jeÜt∞ vyu₧φt). Jde tedy vlastn∞ o emulaci mechanismu datagramovΘ slu₧by prost°ednictvφm mechanismu virtußlnφho okruhu, kterou zajiÜ¥uje prßv∞ podvrstva p°izp∙sobenφ podsφt∞.
DalÜφ mo₧nou odliÜnostφ je maximßlnφ velikost datov²ch paket∙ resp. rßmc∙ v jednotliv²ch podsφtφch. Nap°φklad sφt∞ na bßzi X.25 umo₧≥ujφ, aby datov² rßmec m∞l a₧ 32768 bit∙, zatφmco sφt∞ typu Ethernet (resp. IEEE 802.3) p°ipouÜtφ rßmce jen do velikosti 12144 bit∙, ale nap°φklad sφt∞ typu Token Bus (resp. IEEE 802.4) mohou p°enßÜet rßmce velikosti a₧ 65528 bit∙.
ProblΘm nastßvß v okam₧iku, kdy pot°ebujeme p°enΘst pakety resp. rßmce urΦitΘ velikosti podsφtφ, kterß je schopna pracovat jen s menÜφmi pakety resp. rßmci - nap°φklad p°i p°enosu z jednΘ sφt∞ Token Bus do jinΘ sφt∞ Token Bus p°es ve°ejnou datovou sφ¥ na bßzi X.25. Z°ejm²m a v podstat∞ jedin²m mo₧n²m °eÜenφm je rozd∞lit p∙vodnφ velk² paket na n∞kolik menÜφch paket∙, tzv. fragment∙, a ty p°enΘst jako samostatnΘ celky. Otßzkou ovÜem je, kdo a kdy mß provΘst zp∞tnΘ sestavenφ jednotliv²ch fragment∙ do p∙vodnφho celku. Zde jsou mo₧nΘ dva zßkladnφ p°φstupy. Prvnφ z nich, oznaΦovan² jako transparentnφ fragmentace (transparent fragmentation, n∞kdy tΘ₧: intranet fragmentation), p°edpoklßdß, ₧e vÜechny fragmenty (dφlΦφ pakety) jsou zp∞tn∞ sestaveny do p∙vodnφho tvaru na v²stupu z tΘ podsφt∞, kterß fragmentaci vyvolala. OpaΦn² p°φstup, oznaΦovan² jako netransparentnφ fragmentace (nontransparent fragmentation, n∞kdy tΘ₧: internet fragmentation), poΦφtß naopak s tφm, ₧e jednotlivΘ fragmenty si do p∙vodnφho tvaru posklßdß a₧ jejich koncov² p°φjemce.
DalÜφ odliÜnosti mezi jednotliv²mi podsφt∞mi se t²kajφ nap°φklad odliÜnΘho zp∙sobu adresovßnφ a formßtu adres, pou₧φvan²ch v jednotliv²ch podsφtφch, mechanismu °φzenφ toku dat a p°edchßzenφ stavu zahlcenφ, zajiÜ¥ovßnφ sprßvy, hlßÜenφ nestandardnφch situacφ atd.
Podvrstva °φzenφ vzßjemn∞ propojen²ch sφtφ, nejvyÜÜφ ze t°φ podvrstev sφ¥ovΘ vrstvy, m∙₧e b²t koncipovßna tak, aby svΘ bezprost°edn∞ vyÜÜφ (tj. transportnφ) vrstv∞ poskytovala slu₧by bu∩ spojovanΘho, nebo naopak nespojovanΘho charakteru. V souΦasnΘ dob∞ se vÜak i v rßmci referenΦnφho modelu ISO/OSI, p∙vodn∞ orientovanΘho v²hradn∞ na slu₧by spojovanΘho charakteru, prosazuje spφÜe nespojovanß varianta. Organizace ISO p°ijala dokonce normu ISO 8473, definujφcφ protokol podvrstvy °φzenφ vzßjemn∞ propojen²ch podsφtφ (protokol SNICP, viz v²Üe). Tento protokol, znßm² tΘ₧ jako ISO Internet Protocol Φi jen ISO-IP, toti₧ p°edpoklßdß prßv∞ nespojovan² charakter poskytovan²ch p°enosov²ch slu₧eb. Je nezßvisl² na konkrΘtnφm charakteru podsφt∞, a je schopen zajistit jak transparentnφ, tak i netransparentnφ fragmentaci, sm∞rovßnφ, °φzenφ toku atd. Je do znaΦnΘ mφry inspirovßn obdobn²m protokolem IP (Internet Protocol) ze soustavy protokol∙ TCP/IP.