Az adatkapcsolati és fizikai rétegek

HÁLÓZATOK

ADATKAPCSOLATI RÉTEG

Az adatkapcsolati és fizikai rétegek Az adatkapcsolati rétegbe tartozó hálózati technológiák és szolgáltatások célja: 1. ugyanazon médiához kapcsolódó számítógépek között adatátvitel 2. médiákat összekapcsolva komplexebb hálózatok kialakítására ad lehetőséget Az adatkapcsolati réteg a fizikai réteg alap építő elemére a médiára támaszkodik, amely jel átviteli szolgáltatást nyújt a számára. Láttuk, hogy a hálózatok felépítésének és működésének tárgyalásához előnyös, ha valamelyik réteges szerkezetű hálózatleíró modellt hívjuk segítségül. Ebben a jegyzet sorozatban általában az ISO OSI modelljét használjuk1, amelynek 2. rétege az adatkapcsolati réteg (Data Link Layer). Előtte még ismételjük át a (főleg mechanikai és villamos specifikációkat tartalmazó és megvalósító) fizikai réteg szerepét. Az L1, azaz a fizikai réteg meghatározza: • az információ átvitelre használt közeg (média) fajtáját, amely általában réz-, ill. optikai kábel vagy rádióhullám. • a médiához való csatlakozás funkcióit és ezek feladatát a kapcsolatban, pl. Rx (vétel), Tx (adás), handshake (átvitel vezérlő), stb. vezetékek. • a csatlakozó fizikai kivitelét, pl. RJ 45. • az információt hordozó fizikai mennyiséget (jel), pl. feszültség, fény, stb. • jel miként reprezentálja az átvinni kívánt bitsorozatot, azaz milyen a kódolás és/vagy moduláció, pl. logikai 0=0V, logikai 1=5V. • a kialakítható topológia típusát, pl. pont-pont, busz, fa, gyűrű, stb. és a hálózat mérete is ebbe a rétegbe tartozik. Az L2, azaz adatkapcsolati réteg (Data Link Layer). Az azonos médiára (pl. egy adott kábelre) kapcsolódó készülékek közötti adatátvitelt végzi. Főbb (részben opcionális) feladatai, melyeket a normál kereteket alkotó mezőkben, vagy speciális „szervíz” keretekben hordozott adatokra támaszkodva (lásd L2 szintű virtuális kommunikáció) old meg: • Keretképzése, -küldése és -fogadása: a hálózati réteg adataiból képzi, ill. a fizikai bitfolyamból felismeri. A következőfeladatait. • Hibavédelem: küldendő adatok (gyakran hiba detektálást, esetleg -javítást támogató) kódolása. A beérkező keret épségének ellenőrzése. Nyugták generálása, fogadása. • Adatfolyam vezérlés (flow control, forgalom szabályozás, hand-shake): az adás időpontját és/vagy sebességét a vevőhöz igazítja. • Kapcsolat menedzselése: az összeköttetés (kapcsolat) létrehozása és meglétének ellenőrzése, a kapcsolat jellemzőinek egyeztetése és a kapcsolat lebontása. • Demultiplexer funkció: a vett keretek adatmezőjének tartalmát a keret fejrészében meghatározott folyamatnak adja át. • Fizikai (másnéven MAC) cím segítségével kijelöli (azonosítja), hogy egy adott keret esetében mely fizikai hálózati interfészek (NIC) között történjen (történik) az adatátvitel. • Valamilyen közeghozzáférést vezérlő eljárással képes meghatározni, hogy egy adott pillanatban melyik NIC lehet adó szerepben a médián (busz arbitráció.) Ennek például akkor van szerepe, ha az alkalmazott technológia megengedi, hogy több NIC kapcsolódjon a médiához, de a technológia egyszerre csak egy adás fogadására alkalmas.

1

http://hu.wikipedia.org/w/index.php?title=F%C3%A1jl:OSI_mod_2.png&filetimestamp=20060217082530

t. okt. 2011

1

Szarka T.

HÁLÓZATOK


Az adatkapcsolati rétegben használatos technológiák Több száz különböző technológia használatos LAN ill. WAN hálózatokban, de csak néhány olyan elterjedt megoldást említünk meg itt, amellyel a környezetünkben is találkozhatunk. A LAN-ok szabványos fizikai és adatkapcsolati technológiáival az IEEE 802 szabványok foglakoznak. A következő ábrán2 néhány alfejezetét láthatjuk:

Például a napjaink domináns Ethernet technológiáival a 802.3 szabványok foglalkoznak3. Ezek a specifikációk a fizikai rétegre és az adatkapcsolati réteg MAC alrétegére egyaránt kiterjedhetnek:

A számítógépünkben lévő Ethernet kártya4 a fenti listából több szabványt is realizálhat, pl.:

2

http://www.perihel.at/2/basics/07-Ethernet_Intro.pdf http://en.wikipedia.org/wiki/IEEE_802.3 4 http://www.argep.hu/trend/SMCS/Smc-SMC1255TX-1.html 3

t. okt. 2011

2

Szarka T.

HÁLÓZATOK


A MAC alrétegben az Ethernet a Carrier Sense Multiple Access with Collision Detection (CSMA/CD) közegelérési módszert használja. Az IEEE 802.3 foglalta szabványba ezt az eljárást, melynek lényege a következő. A többiekhez hasonlóan az adatküldésre készülő állomás is „hallja” a közegen zajló forgalomat (Multiple Access). Amennyiben azt érzékeli, hogy már valaki adás állapotban van, azaz vivőt érzékel (Carrier Sense), akkor várakozik az adás megszűnésére. Amikor a közegen később „csend” lesz, akkor megkezdi az adást, amelyet azok az állomások vesznek, amelyek az üzenetben szereplő (MAC) cím alapján megszólítva érzik magukat. Előfordulhat olyan helyzet, hogy (megközelítően) egyszerre többen kezdenek adásba, ekkor az adók egymást zavarják, ezért a közegre került információ sérül. A hálózat ilyen állapotát (ütközést) detektálni kell (Collision Detection). Ezt az állapotot az adók az adott jel visszaolvasásakor érzékelt hibákról ismerik fel („nem hallja tisztán a saját hangját”). Ekkor minden, az ütközést érzékelő adó beszünteti az adást, majd véletlenszerű késleltetési idő után újból próbálkozik az adással. (Az ütközést érzékelő eszközök egy ún. JAM jelsorozatot helyeznek a hálózatra, amely alaphelyzetbe vezérli a hálózatra kapcsolódó állomásokat.) A véletlen időzítést követően valószínű, hogy az egyik adó kellően korán lefoglalja a közeget és a többiek az adásuk megkezdése előtt érzékelik azt. A véletlen várakozási idő (t) az N (egymást követő) ütközés után 0<=t<=2N-1 egységnyi, a bináris exponenciális visszatartás (binary exponential backoff) algoritmusa szerint. Az N maximális értéke 15. Tekintettel arra, hogy az ütköző állomások az első ütközés után a [0..1] tartományból, majd az esetleges második ütközés után a [0..3] tartományból, sőt ha kell még tovább bővített [0..7], stb. tartományból választanak várakozási időt5, belátható, hogy az ütközés valószínűsége egyre inkább csökken.. Bár az ütközés a hálózat természetes állapota, amennyiben mértéke eléri az 50%-ot, akkor csökken a rendszer adatátviteli teljesítménye és javasolt a Collision Domain (ütközési tartomány) méretének (tehát az ütközési tartományt alkotó gépek számának) csökkentése, amely az adott hálózat két vagy több ütközési tartományra, másnéven hálózat(i) szegmensre6 való felosztásával történhet. Az ábrán7 egy elavult, a IEEE802.3 vagy 802.3a (másnéven 10Base5 ill. 10Base2) szabványt használó hálózat látható, amelyben a gépek egy közös busz (sin) jellegű koaxiális kábelről (médiáról) ágaznak le. A szabvány által alkalmazott fél-duplex adatátviteli mód miatt egy adott pillanatban csak egy adó lehet és ezt a megszorítást a busz topológia az egész hálózatra (a megosztott közegre) kiterjeszti. A busz topológia másik következménye, hogy az adót minden egyéb gép „hallja”, függetlenül attól, hogy ki az adás címzettje, azaz ki fogja azt feldolgozni. Az előbbi körülmények miatt a hálózat minden gépe egy közös ütközési tartományt alkot, ezért a példában szereplő hálózat 4 felhasználója a technológia által elméletileg biztosított 10Mbit/s-os sávszélességből csak 1/4-1/4 részt fog érzékelni. A megoldás használhatóságát az is negatívan befolyásolta, hogy egy kábel meghibásodás (szakadás, rövidzár) során fellépő jel reflexió a kábel hibátlan szakaszain belüli hálózati forgalmat is megakadályozza. 5

10 ütközés fölött a várakozási idő maximuma 1023 egységen állandósul. A szegmentálás egy túlterhelt fogalom: egyik változata a fizikai rétegben történő szegmentálás, pl. repeater vagy hub segítségével. Ennek előnye, hogy egy adott szegmensben bekövetkező fizikai szintű hiba nem hat a többi szegmens fizikai szintű működésére. Másik megközelítés szerint a szegmens a hálózat azon része, amelyik a hálózat többi részétől független adatforgalomra is képes, azaz önálló Collission Domain-t alkot. Ekkor a MAC alréteg (tehát az adatkapcsolati réteg) szintjére is ki kell terjeszteni a szegmentációt. 7 http://www.ybet.be/en-hardware-2-04/ethernet-network.htm 6

t. okt. 2011

3

Szarka T.

HÁLÓZATOK


Egy IEEE802.3 vagy 802.3a hálózat ütközési tartományokra osztásához bridge (híd) vagy router funkciójú hálózati eszköz(ök)re van szükség (a routerek működését később részletezzük). A következő ábrán8 olyan (bridge használata miatt két szegmensből és ütközési tartományból álló) hálózat látható, amelyekben 3 ill. 2 eszközt tartalmaznak az ütközési tartományok. A megoldás előnye, hogy a felhasználók nagyobb sávszélességet érzékelnek és az egyik szegmensben bekövetkező kábel meghibásodás hatása csak az adott szegmenst bénítja meg. Tovább növelhető a hálózatok hibatűrése, ha egy kábel meghibásodásának hatását megpróbálják két eszköz közötti kommunikációra korlátozni. Ez az elv jelent meg a 802.3i (10Base-T) szabványban és a napjainkban elterjedt 802.3u (100Base-TX) rendszerekben is érvényesül, azaz minden géphez egyedi kábelt vezetnek a hálózat „közepén” (a „csillagpontban”) elhelyezett hub vagy switch (kapcsoló) nevű eszköz interfészeitől (portjaitól). A megoldások másik sajátossága, hogy koaxiális kábel helyett már sodrott érpárokat tartalmazó kábelt használnak. A hub, mint a fizikai rétegben dolgozó hálózati eszköz jellemzői: • A hálózat csillagpontja. Hozzá kapcsolódnak az egyes számítógépek külön- külön kábelekkel. • Az esetleg sérült szegmens leválasztása a hálózat többi részéről. • Általában repeater, azaz jel erősítő (jel ismétlő) feladatot is ellát. Az erősítő ugyan hálózatot fizikailag szegmentálja, de továbbra is egy ütközési tartományt alkotnak a számítógépek. Az ábrán9 látható, hogy az F géptől a C gépnek küldött Ethernet keretet minden portján kiküldi a hub. A csillagpontban elhelyezhető másik készülék a kapcsoló, amely a hub képességeit kiegészítve az ütközési tartományok méretét is csökkenti. A korábban említett (de még nem ismertetett) bridge működési elvét követi, annak „sokportos” megfelelője. Napjaink hálózataiban bridge helyett inkább switch-et (kapcsolót) használnak az ütközési tartományok méretének csökkentésére. A switch több porttal rendelkezik mint a bridge, azért, hogy lehetőleg minden egyes számítógép (legfeljebb) a switch egy portjával alkosson ütközési tartományt (mikro szegmentálás). A szegmenseken belül önálló adatforgalom lehetséges, más szegmensek leterhelése nélkül. A switch vagy bridge a keretek MAC szintű címének vizsgálatával biztosítja, hogy egy adott gépnek szóló Ethernet keret nem jelenik meg egy „harmadik” szegmensben. A kapcsoló működése egy dinamikusan karbantartott táblázatra épül, amelyben a kapcsoló minden portjához feljegyzi az adott porton beérkező keretek küldőjének MAC címét. Ezzel a kapcsoló megismeri a hozzá kapcsolódó gépek helyzetét, tehát azt, hogy az egyes gépek a kapcsoló melyik interfészéhez kapcsolódnak. Egy beérkezett keret továbbításához csak meg kell vizsgálnia a táblázatot, hogy a keretben szereplő cél MAC cím melyik interfészén keresztül érhető el. Egy interfészhez több gép MAC címe is feljegyezhető, ezért nincs akadálya hub-switch vagy switch-switch kapcsolatnak sem. A switch bekapcsolásakor kezdődő tanulási folyamat során fokozatosan alakul ki a kapcsoló táblázata. Ezért normál jelenségnek tekinthető, ha egy olyan keretet kell továbbítania, amelynek a címzettje még a switch számára ismeretlen irányban van. Ekkor az ún. elárasztást alkalmazza, azaz a beérkezett keretet a fogadó port kivételével az összes többi portján kiküldi. Szintén elárasztással továbbítja a MAC szintű broadcast- vagy multicast célcímet tartalmazó kereteket. A kapcsolók (hidak) működési elvet a 802.1D írja le, amely az alapelven kívül több kiegészítést10 is tartalmaz, pl. 802.1p, 802.12e, 802.1j, 802.6k, stb. 8

http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/bridge.html http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/bridge.html 10 http://en.wikipedia.org/wiki/IEEE_802.1D 9

t. okt. 2011

4

Szarka T.

HÁLÓZATOK

ADATKAPCSOLATI RÉTEG Azzal, hogy a továbbítandó keretek tartalmától függ a működése, a kapcsoló (bridge) az adatkapcsolati réteget (L2) is használja a működése során. Az ábra11 modellje két kapcsolót (vagy hidat) szemléltet, amelyek az L1 és L2 rétegekben helyezkednek el, biztosítva a két hálózati végpont közötti forgalmat.

A következő két ábrán a kapcsolók normál, illetve elárasztásos keret továbbítása12 látható, míg a harmadik ábrán az általános működés is megfigyelhető13: • A switch a beérkező kereteket a beérkezés portjáról a cél NIC felé kapcsolja. Egy időpontban akár több keret kapcsolására is képes. • „Illetéktelenek” nem „hallják” a keretet.

A kapcsolási folyamat rendelkezésére állnak be és kimeneti pufferek, hogy az egyes linkek esetlegesen eltérő sebessége ne okozzon problémát. A sebesség eltérést forgalmi vagy technológiai ok idézheti elő. Ez utóbbi akkor fordul elő, ha a kapcsolóhoz eltérő, pl. 100BaseTX és 1000Base-T linkek csatlakoznak. Ha a huzamosan eltérő sebesség valamelyik puffer telítődését okozná, akkor az adatfolyamot szabályozó (802.3x) funkcióval a megfelelő adó „csillapítható”. A pufferek használata a kapcsoló üzemmódjától is függ, mert a beérkező kereteket a továbbítás előtt részben vagy egészben tárolják. Full-Cut Through módban csak a keret első 16 byte-ját olvassa be (feltétlenül) a pufferbe, ebből már tudja, hogy ki a címzett, míg a keret többi részét csak továbbítja, így számítási kapacitást takarítva meg. A kapcsolási mód másik véglete a Store and Forward mód, amelyben a teljes keretet beolvassa ellenőrzés céljából és csak hibátlan keretet küld tovább. Egy kapcsolt hálózatban annyi ütközési tartomány van, ahány portja van a kapcsolónak (mikroszegmentálás). Egy számítógép ekkor legfeljebb a kapcsolóval versenyezhet a média használatáért, de ez sem életszerű, mert minden gép-switch link üzemelhet duplex (802.3x) módon. Ilyenkor lehetetlen ütközés kialakulása, ezért (ekkor) feleslegessé válik a CSMA/CD eljárás használata. Ha a portok között arányosan oszlik meg a forgalom, akkor minden felhasználó az elméleti 100Mbit/s-os sávszélességet érzékeli. A bridge ill. switch a hálózat többi eszköze számára „észrevehetetlen” (transzparens) módon dolgozik, pl. a keretek továbbítása során azok tartalmát nem módosítják. A legegyszerűbb (tehát csak az alapfunkciót megvalósító) kapcsolókra jellemző, hogy nem forrásai Ethernet keretnek, azaz saját „elhatározásukból” nem bocsátanak ki Ethernet keretet, ezért még MAC címmel sem kell rendelkezniük az interfészeiknek. 11

www.igi-global.com/downloads/excerpts/1930708173BookEx.pdf http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/bridge.html 13 http://www.ybet.be/en-hardware-2-05/hub-switch.htm 12

t. okt. 2011

5

Szarka T.

HÁLÓZATOK


A korszerű (kapcsolt) Ethernet hálózatokban alapvető hálózati eszközök a kapcsolók. Nagyméretű kapcsolt hálózatok sikeres megvalósításához célszerű, pl. a hálózattervezés háromrétegű modelljét bemutató ábrát14 figyelembe venni, ahol az egyes rétegekben dolgozó kapcsolók különböző (későbbi fejezetekben bemutatott) feladatok végrehajtására vannak optimalizálva. Az előnyös tulajdonságok mellett a kapcsolók működéséből adódóan a nagyméretű hálózatokban problémák megjelenésével is számolni kell, pl. ún. broadcast vihar jöhet létre. Ha egy hálózati tartományban (domain) másodpercenként kb. 100-nál több broadcast címzésű keret jelenik meg, akkor ezek (a gépek többsége számára valójában felesleges) feldolgozása jelentősen terheli tartományban található a gépeket és ezért célszerű csökkenteni az ilyen keretek számát15. A jelenség hátterében az áll, hogy a kapcsolók elárasztással továbbítják a broadcast, multicast vagy az ismeretlen címre küldött kereteket. A broadcast címzésű keretek által okozott terhelés mértékének csökkentésére most egy módszert említünk: a broadcast tartomány méretének csökkentését. Ha egy adott tartományba tartozó gépek száma csökken, akkor kevesebb broadcast csomagot bocsátanak ki. Mivel a (később ismertetendő) routerek nem továbbítják a broadcast (IP vagy MAC) címzésű csomagokat, a routerrel történő szegmentáláskor a broadcast tartományok számát is növeljük. Ekkor több darab, de kisebb méretű broadcast domain (és egyben ütközési tartomány) alkotja a hálózatot. Visszatérve általában az Ethernet eszközökre, gépünk interfészének jellemzőit is megvizsgálhatjuk, beállíthatjuk. Például azt, hogy periódikusan ellenőrizze a link működőképességét és „felmérje” a szomszédos hálózati eszköz képességét, azaz a használható legjobb adatátviteli sebességet és módot16. Ezt konkrétan a 802.3u auto-negotiation protokoll szerint kell egyeztetnie a szomszéddal. A vizsgálati sorrend: 1. 100Base-TX Full Duplex 2. 100Base-T4 3. 100Base-TX 4. 10Base-T Full Duplex 5. 10Base-T

14

http://www.ausnog.net/files/ausnog-03/presentations/ausnog03-dale-ethernet_evolution.pdf http://en.wikipedia.org/wiki/Broadcast_radiation 16 ….20095.pdf 15

t. okt. 2011

6

Szarka T.

HÁLÓZATOK


Egyéb MAC protokollok Token Ring (IEEE 802.5) Főleg ipari környezetben lehet fontos az, hogy egy hálózatra kapcsolódó eszköz meghatározott, véges időtartamon belül adási lehetőséghez jusson, illetve az állomásokhoz szükség esetén eltérő adási prioritás legyen rendelhető. A CSMA/CD protokoll ezt nem teszi lehetővé, ezért más elven kellett megszervezni az adáshoz való jog kiosztását. A fizikailag gyűrűt alkotó állomások logikailag is gyűrűt alkotnak a protokollban. A gyűrű beindulásakor a legmagasabb logikai sorszámú állomás rendelkezik (a rendszerben meghatározott ideig) adási joggal. Ezen idő alatt több üzenetet is a hálózatba küldhet. A gyűrűben az üzenet (keret) gépről-gépre vándorol, de csak a címzett „hasznosítja”. Az, hogy az elküldött keret sikeresen megérkezett-e, a visszaérkező keret státuszából derül ki (tehát kell-e ismét elküldenie a keretet vagy mehet a következő keret). Az adó az adási idejének letelte után egy speciális üzenetet (tokent) küld a logikai szomszédjának. Ezután a tokent „birtokló” állomás az, melyik a rendszerben rendelkezik az adási lehetőséggel. Egy meghatározott idő múlva egy tokent küld a szomszédjának… . Felismerhető ezek után az, hogy a körbeadott token segítségével minden állomás szóhoz juthat egy, a rendszerre jellemző maximális időtartamon belül. Minden állomáson belül létezik egy prioritási rendszer a továbbítandó üzenetek számra. Egy állomás adási idejében először a legmagasabb prioritású üzenetei kerülnek továbbításra és ha még van adási ideje, akkor az eggyel alacsonyabb prioritású üzenetei és így tovább. Az ilyen elven működő hálózatokban ütközés nem jöhet létre és a legmagasabb prioritási szintű üzenetek számára egy garantált átviteli sebességet lehet biztosítani. Hátránya, hogy a gyűrű logikai karbantartásához külön gépre lehet szükség. A rendszert alkotó gépek a MAU nevű központi “hub” segítségével a megbízhatóság érdekében gyűrűt alkotnak (Token Ring). A gyűrű minden gépéhez két kábel csatlakozik. A MAU egyik feladata az esetleg megsérülő szegmens leválasztása és áthidalása. A MAU helyett kapcsolót alkalmazva a tokenen alapuló MAC protokoll is leváltható ún. DTR-re (Dedikált Token Ring), amelyben token “csomag” (TP) helyett kapcsolt hálózatot használnak. A média adatátviteli sebessége 4Mbps...1Gbps a Token Ring változatától függően17. Egyéb források18.

Token Bus (IEEE 802.4) Fizikailag csillag vagy sin topológiájú hálózaton az Ethernethez hasonlóan, üzenetszórást használnak. Hivatalból ütközésmentes a protokoll, mert itt is csak a tokent birtokló állomás adhat a rendszerben meghatározott ideig. Az adási jog kijelölése egy logikai sorrend alapján történik, majd ciklikusan ismétlődik, ebből adódik, hogy csak logikailag tekinthető gyűrűnek a rendszer. Az adón belül nincs belső prioritás. A tokenes megoldások lassan az iparból is kiszorulnak, mert az Ethernet a folyamatirányítás területére is betör. Az érzékelő és beavatkozó elemek közötti kommunikációhoz a Transparent Factory Ethernet előírásait kielégítő eszközöket használatát javasolják a gyártók.

17 18

http://www.cse.wustl.edu/~jain/cse473-05/ftp/i_9lan.pdf http://hu.wikipedia.org/wiki/Token-Ring és http://www.eeherald.com/section/design-guide/ieee802_p2.html

t. okt. 2011

7

Szarka T.

HÁLÓZATOK


CSMA/CA. A 802.11 (népszerűen: WiFi) szabványok MAC protokollja, amelyben az állomások elkerülik az ütközést (Collision Avoidance). Adás után minden állomás a rá jellemző egyedi várakozási idő letelte után adhat, ha más nem ad. Látható hogy, a PHY rétegben különböző modulációs módot, adatátviteli sebességet, stb. előíró szabványok léteznek.

forrás: http://hu.wikipedia.org/wiki/Wi-Fi www.inf.u-szeged.hu/~bilickiv/ip_1_2005_2/4.ppt

t. okt. 2011

8

Szarka T.

HÁLÓZATOK


Pillantás a fizikai rétegre. Jelek, média típusok, kódolás, topológia A hálózatokat alkotó készülékek között az információ áramlást jelek segítségével biztosítják. A jel valamilyen fizikai mennyiség (pl. feszültség, fény, stb.), amelynek célja, hogy hordozza, reprezentálja az információt miközben az a készülékek között „halad”. Egy adott szabványnak a fizikai rétegre vonatkozó leírása definiálja, hogy milyen funkciójú jelekre van szükség, ezekhez milyen csatlakozóval kell a készülékeket ellátni, milyen médiát (információ továbbító közeget) (pl. ’x’ típusú koaxiális kábelt) kell a készülékek között használni, stb. Vékony koaxiális kábelt használ a 802.3a (10Base2) szabvány. Napjainkban esetleg még találkozhatunk ezekkel az ún. vékony Ethernet (cheapernet, Thin Ethernet, Thinnet) hálózatokkal. 10 Mbit/s átviteli sebességű és egy szegmens hossza maximum 185m lehet (jelismétlő nélkül). A felhasznált kábel általában az RG 58-as családba tartozó, 50 Ω-os hullámimpedanciájú koaxiális kábel, amely jó védelmet jelent a villamos zavarforrásokkal szemben. A számítógépek egy-egy „T” elágazó egység segítségével csatlakoznak a hálózatra. A csatlakozók között legalább 0,5 m távolságnak kell lennie. Egy szegmensre maximum 30 egység csatlakoztatható. A szegmensek lezárására villamos szempontból 50 Ω-os lezáró dugó szükséges. Az egységek kábelre kapcsolásához ún. Bayone-Neil-Cuncelman (BNC) csatlakozókat használnak. Ha kevés a 185 m áthidalható távolság, akkor ún. repeater (jelismétlő, erősítő) eszközzel kapcsolhatók össze a kábelek. A repeater egy olyan fizikai rétegben elhelyezkedő eszköz, amelyik mindkét oldalról képes a jeleket venni, majd továbbadni a másik oldalra. A hálózat szempontjából az így összekötött kábelek egy szegmensnek tekinthetők. Az ismétlők késleltetése miatt korlátozásra van szükség az ütközések érzékelhetőségének biztosítása érdekében: a hálózat két állomása között maximum 4 repeater lehet, így két gép közötti maximális távolság 5*185 m=925 m. Nagyobb távolságokhoz már híddal kell összekapcsolni a szegmenseket. Bármilyen topológiát (sin, csillag, fa) kialakíthatunk a kábelezés során, de arra vigyáznunk kell, hogy minden állomás csak egy útvonalon legyen elérhető. A Thin Ethernet hiányosságai: • Egy kábel meghibásodása (ami gyakran bekövetkezhet) egy egész szegmenst, sőt az egész hálózat működését megbéníthatja. • Legtávolabbi gépek között megengedett kis maximális távolság és átviteli sebesség. BNC csatlakozó, “T” elágazás koaxiális kábellel19 és lezáró dugó20 a kábel végén:

19 20

http://en.wikipedia.org/wiki/10BASE2 http://www.eeherald.com/section/design-guide/ieee802_3.html

t. okt. 2011

9

Szarka T.

HÁLÓZATOK


Sodrott érpár (Twisted Pair). „Külső zavarok ellen védtelen adatátviteli közeg. Leggyakrabban alkalmazott kábeltípus az Ethernet hálózatokon. Az UTP kábel számos hálózatokban használt, 4 érpárból álló réz alapú átviteli közeg. Az UTP kábeleknek mind a 8 rézvezetéke szigetelőanyaggal van körbevéve. Emellett a vezetékek párosával össze vannak sodorva, így csökkentve az elektromágneses és rádiófrekvenciás interferencia jeltorzító hatását. Az árnyékolatlan érpárok közötti áthallást úgy csökkentik, hogy az egyes párokat eltérő mértékben sodorják. Maximális átviteli távolsága 100 m.”21 Néhány megjegyzés: • • • •

elterjedésének okai: könnyű szerelhetőség, olcsóság a koaxiális kábeltől eltérő módon nem (feltétlenül) árnyékolt, de a rendszer zavarvédelmét (egy bizonyos szintig) nem csak a kábel árnyékolása, hanem az érpárok összesodrása, valamint a szimmetrikus meghajtó és vevő áramkörök is tudják biztosítani. Kapcsolt hálózatban egyes szegmenseinek hossza ugyan max. 100m, de a gépek akárhány szegmens távolságra lehetnek egymástól. A kábelek elnevezése az egyes érpárak árnyékolt, ill. árnyékolatlanságából kiindulva (Shielded TP, ill. Unshielded TP). Ezt egészíti ki az érpárok együttes árnyékoltságát leíró jelzés.22 Régi és új jelölési mód néhány magyarázattal: UTP→U/UTP Árnyékolatlan érpárok, a kábel árnyékolatlan FTP→F/UTP Árnyékolatlan érpárok, a kábel fóliával árnyékolt S-FTP→SF/UTP Árnyékolatlan érpárok, a kábel harisnyával és fóliával árnyékolt F-FTP→U/FTP Fóliával árnyékolt érpárok, a kábel árnyékolatlan S-STP→S/FTP Fóliával árnyékolt érpárok, a kábel harisnyával (fonattal) árnyékolt

A következő ábrákon az Ethernet által általában használt árnyékolatlan csavart érpár 23 (U/UTP) látható:

Nagy átviteli frekvenciánál, ill. ipari környezetben szükség lehet árnyékolásra. Ennek oka az, hogy a nagyfrekvenciás jelet a kábel nagy csillapítással továbbítja a vevőbe, ahová ezért kis amplitúdóval érkezik meg. Ez a kis amplitúdójú jel már összemérhető a különböző forrásokból származó zavaró jelekkel. A kábel árnyékolásával a vevőbe érkező zavaró jel amplitúdója csökkenthető. Különböző árnyékolási megoldásokkal találkozhatunk: • az egyes érpárok árnyékoltak (U/STP) • a kábel is árnyékolt, pl. S/FTP24. (Pl. egy Industrial Ethernet rendszerben:

21

http://hu.wikipedia.org/wiki/UTP http://www.telesisnet.hu/halozat/index.php?option=com_content&view=article&id=11&Itemid=14 23 http://en.wikipedia.org/wiki/Twisted_pair és http://www.ob121.com/bus_cable_connectors.html#utp 24 Fólia vagy fémszövet az árnyékolás. Forrás: http://www.hitechcontrols.com/cables/data_network_bus/ helukabel_bus_cables/ind_ethernet_600ind.html 22

t. okt. 2011

10

Szarka T.

HÁLÓZATOK


A kábel csatlakozó bekötése Az Ethernet terminológia szerint egy RJ45 elnevezésű (egyébként 8P8C típusú) csatlakozó dugó (plug, apa csatlakozó) bekötése két séma szerint lehetséges. Egyenes kábel esetén a kábel mindkét végén azonos, TIA/EIA-568A vagy TIA/EIA-568B típusú sémát kell használni. Keresztkötésű (cross-over) kábel esetében az egyik csatlakozót az egyik, a másik csatlakozót a másik séma szerint kell bekötni.

Az Ethernet eszközök RJ45 típusú aljzattal (jack, anya csatlakozó) fogadják a kábel apa csatlakozóját. Az aljzatnak kétféle típusa van: • Számítógép (általánosan: végberendezés)- és router Ethernet interfészében: MDI • Hub, switch Ethernet interfészében: MDI-X Az eltérő kivitel célja, hogy ún. egyenes kábellel lehessen összekapcsolni azokat a készülékeket, amelyek a hálózatokban leggyakrabban kerülnek egymással kapcsolatba (pl. ilyennek tekinthető a PC-switch (hub) vagy a router-switch (hub) kapcsolat). A következő ábrán25 látható, hogy az UTP kábelt használó (az ábrán pl. PC és HUB) készülékek a 10Base-T és 100Base-TX szabványok fizikai rétegre vonatkozó előírásai által definiált RX (vétel) és TX (adás) funkciójú jelekkel dolgoznak. Általános szabály, hogy az egyik készülék TX pontját a másik készülék RX pontjával kell összekötni. Az MDI és MDI-X aljzatok eltérő csatlakozó kiosztása egyenes kábel használata esetén kielégíti az előbbi követelményt. Megjegyzések: • Hálózatokban gyakori a hub-switch, hub-hub vagy switch-switch kapcsolat igénye is. Ezért ezeken az eszközökön előfordul ún. uplink port, amely MDI jellegű azért, hogy lehetővé tegye egyenes kábel használatát az előbbi kapcsolatokban. • Korszerű készülékekben megjelentek olyan Ethernet interfészek (auto MDI/MDI-X jelzéssel26) amelyek a távolvégen lévő készülék és az alkalmazott kábel típusától függetlenül, automatikusan helyes láb konfigurációt választanak ki. • Látható, hogy a 4 érpárból 2-t használ fel a 802.3i és 803.3u (10Base-T és 100Base-TX) szabvány. A két érpár akár egyidejűleg is használható, tehát adás alatt vétel is történhet, azaz duplex a kapcsolat is lehetséges (pontosabban ez az alapértelmezett mód) a linken. 25 26

http://searchnetworking.techtarget.com/generic/0,295582,sid7_gci1050255,00.html Egyéb elnevezései: Auto uplink and trade, Universal Cable Recognition and Auto Sensing

t. okt. 2011

11

Szarka T.

HÁLÓZATOK


Az előbbiek figyelembe vételével a használandó kábelek fajtája27: • Keresztkötésű: PC-PC, PC-router, router-router és switch (nem uplink port) -switch. • Egyenes: PC-switch, switch-router, switch (uplink port)-switch. Megjegyzés: előfordul, hogy egy link több kábel szakaszból áll, pl. a kábelcsatornában lévő szakasz, fali csatlakozó-PC közötti szakasz, stb. Ilyenkor elég az egyik szakaszon keresztkötésű kábelt használni, hogy az eredő is keresztkötésű legyen. Egy második crossover szakasz már egyenes kötést eredményez! Egyenes kötésű kábelnél a dugók 1-1, 2-2, 3-3, 4-4, 5-5, 6-6, 7-7, 8-8 érintkezői között van kapcsolat és a két szín séma valamelyikét valósítjuk meg a kábel mindkét végpontján. Keresztkötésű kábelnél28: a kölcsönös 1-3 és 2-6 kapcsolat kialakítása jelenti az eltérést:

1000Base-T keresztkötésű kábele29 mind a 4 érpárat használja:

Rollover (konzol) kábel: bizonyos menedzselhető eszközök (router, switch) konfigurálásához használják30. (Normál hálózati adatforgalomra nem használható.) 27

http://en.wikipedia.org/wiki/Medium_dependent_interface

28

http://techpubs.sgi.com/library/dynaweb_docs/linux/SGI_EndUser/books/SGIconsole_HW_CG/sgi_html/figures/pinout.RJ 45-crossover.color-codes.gif 29 30

http://en.wikipedia.org/wiki/Ethernet_crossover_cable http://techgurulive.com/2008/09/29/rj-45-pinouts-r-straight-through-cross-over-and-roll-over-cables/

t. okt. 2011

12

Szarka T.

HÁLÓZATOK


ISO/IEC11801 [class]

Jellemző vezetéktípusa

Cat1(*)

A

UTP

0.1

-

Hagyományos hangátvitelre

Cat2(*)

B

UTP

1

-

Régi ARCNet és Token hálózatokban használták

Maximum frekvencia (ISO 11801) MHz Max csillapítás dB/Km, 100MHz

EIA/TIA Category

Kábel kategóriák

Felhasználási területek (főleg Ethernet technológiákhoz kapcsolódóan)

telefon

rendszerhez Ring

Cat3

C

UTP

16

98

Egy korai 100 Mbps-os Ethernet rendszer, a 100Base-T4 használta. Sajátossága, hogy a kábel mind a 4 érpárjára szüksége volt az átvitelhez.

Cat4(*)

-

UTP

20

72

Token Ring hálózatokban

Cat5(*)

-

UTP STP

100

65

10Base-T, 100Base-TX 1000Base-T (nem ajánlott)

Cat5e

D

UTP

100

24

10Base-T, 100Base-TX 1000Base-T

Cat6

E

UTP

250

21.3

Cat6A

EA

UTP

500

20.9

Cat7

F

S/FTP

600

Cat7A

FA

S/FTP

1000

10Base-T, 100Base-TX 1000Base-T, 1000Base-TX UTP: 10GBase-T<37m! STP: 10GBase-T 10Base-T, 100Base-TX 1000Base-T, 1000Base-TX 10GBase-T 10Base-T, 100Base-TX 1000Base-T, 1000Base-TX 10GBase-T 10Base-T, 100Base-TX 1000Base-T, 1000Base-TX 10GBase-T

(*) Az EIA/TIA által nem elismert kategóriák.

A kategória ill. az osztály a különböző szabványok szóhasználatában a kábelezési rendszer komponenseinek (az infrastrukturájának) a villamos jellemzőit és az ebből származó átviteli képességet minősíti. A „fali” kivitelű UTP kábelek tömör (solid) réz ereket tartalmaznak, míg a lengő (patch, stranded) kivitelű kábelek erei a nagyobb hajlékonyság érdekében több elemi szálból állnak. Ez utóbbi kábel gyengébb villamos jellemzőkkel rendelkezik, ezért max. 10 méternyi ilyen kábel lehet egy max. 100m-es linken belül. Az RJ45-ös dugók kiválasztásakor ellenőrizni kell, hogy egy adott dugó melyik kábellel (kábelekkel) használható.

t. okt. 2011

13

Szarka T.

HÁLÓZATOK


A kábelek néhány villamos jellemzőjére az alábbi ábrán31 láthatunk példát:

Az üzemeltetési tapasztalatok alapján vált szükségessé a Cat 5 követelményeinek kiegészítése Cat 5e-re, hogy a Fast Ethernet helyett (természetesen az aktív hálózati elemek lecserélése mellett) később még a Gigabit Ethernet stabil működéséhez is megfelelő legyen a kábelezési infrastruktura. A Cat 6 és Cat 7 módosított változatainak megjelenését a 10GBase-T tapasztalatai kényszerítették ki. A kábelezés eredő jellemzőit a kábelek mellett az egyéb szerelési komponensek (pl. aljzatok, rendezők) is befolyásolják, ezért a hálózat minőségét ezen szerelvényeket is magába foglaló mérésekkel kell ellenőrizni. A hálózat kábelezésének minősítése. Az ellenőrzést azaz, pl. az EIA/TIA Cat 5e vagy a vele összehasonlítható ISO11801 D osztály követelményeinek teljesítését hálózat analizátorral elvégzett mérésekkel ellenőrzik. Egy tipikus LAN analizátor, képességei és ára32: Test Standards: TIA Category 3 and 5e per TIA/EIA-568B TIA Category 5 (1000BASE-T) per TIA TSB-95 TIA Category 6 per TIA/EIA-568B.2-1 (Addendum #1 to TIA/EIA-568B.2) ISO/IEC 11801 Class C, D, and E ISO/IEC 11801 Class F (DTX-1800 only) EN 50173 Class C, D, E EN 50173 Class F (DTX-1800 only) ANSI TP-PMD IEEE 802.3 10BASE-T, 100BASE-TX, 1000BASE-T IEEE 802.5 (STP cabling, IBM Type 1, 150Ω ) Token Ring, 4 Mbps and 16 Mbps

31 32

http://discountcablesusa.com/ethernet-cables100.html http://www.datacomtools.com/catalog/Fluke_dtx.htm

t. okt. 2011

14

Szarka T.

HÁLÓZATOK


A http://www.datacomtools.com/catalog/Fluke_dtx.htm szerint az analizátor a következőket vizsgálja: • • • • • • • • • • • • •

Wire Map Length Propagation Delay Delay Skew DC Loop Resistance Insertion Loss (Attenuation) Return Loss (RL), RL @ Remote NEXT, NEXT @ Remote Attenuation-to-crosstalk Ratio (ACR), ACR @ Remote ELFEXT, ELFEXT @ Remote Power Sum ELFEXT, PSELFEXT @ Remote Power Sum NEXT, PSNEXT @ Remote Power Sum ACR, PSACR @ Remote

A mérési eredményeket megjeleníti33 és azokat az adott szabvány követelményeivel összevetve minősíti a kábelezést. A kábelezések főbb villamos jellemzői34 Attenuation: beiktatási csillapítás. Az adó által kiküldött jel milyen mértékben csökken a vevőhöz érkezve. Érpárankét kell ellenőrizni. Pl. az ISO 11801 által a class D-ben engedélyezett maximum 23.2dB/100m 100MHz-es frekvencián. Reflexiós veszteség (Return Loss, RL). Jel visszaverődés lép fel közeg inhomogenitás esetén, pl. kábel és NIC találkozásánál az eltérő hullámimpedanciák miatt. A visszaverődő jel interferenciát okoz. Közelvégi áthallás (Near-end crosstalk, NEXT35) és Powersum (összegzett) NEXT (PS-NEXT). Az adott hasznos jelre szuperponálódik (mint zavar) az azonos kábelvégen lévő más adó(k) jele. Azt mutatja, hogy a zavar forrás(ok) jele milyen csillapítással szivárog be a vizsgált érpárba. Távolvégi áthallás (Far-end crosstalk, FEXT).

33

http://kvk.bmf.hu/oktato/temesvarizs/Strukturalt%20halozatok%20merese.pdf

34

http://en.wikipedia.org/wiki/Copper_cable_certification és users.iit.uni-miskolc.hu/~szkovacs/GAMFNetD/NetDE3.pdf

35

https://www.tilb.sze.hu/tilb/targyak/ta37/meresek.ppt

t. okt. 2011

15

Szarka T.

HÁLÓZATOK


ACR (Attenuation to Crosstalk Ratio) az áthallás és a jel gyengülése közötti különbség decibelben kifejezve. Minél nagyobb az ACR értéke, annál megbízhatóbb az adatátvitel.36

Equal-Level Far-End Crosstalk (ELFEXT): A FEXT mérésekor a kábel csillapítását kivonják a mért FEXT értékéből, hogy a NEXT értékével összehasonlítható jellemzőt kapjanak. Tehát ELFEXT= FEXT-csillapítás. Az ELFEXT másik elnevezése Attenuation to Crosstalk Ratio, Far-end (ACRF) Power Sum Equal Level Far End Cross Talk (PSELFEXT) esetében mindhárom másik érpárt megtáplálják a „zavaró” jellel miközben az áthallást mérik37. Alien Crosstalk a szomszédos kábelek, a patch panelek és az aljzatok egymáshoz közeli portjai között keletkező áthallás38. A 10GBase-T üzemeltetési tapasztalatok azt mutatták, hogy a kábelek határfrekvenciája mellett ez a jellemző is fontos, ezért a jelentek meg a Cat 6 és Cat 7 módosított változatai. Delay Skew: az érpárok közötti futásidő különbségek Kábelhibák: Helyes és helytelen kábel bekötések.39

Egyéb hibák: kábel erek szakadása és az erek közötti rövidzár. 36

http://www.datacottage.com/nch/testing.htm http://www.datacottage.com/nch/testing.htm 38 http://www.keline.eu/hu/teoria1hu.html 39 www.skor.hu/dolgok/strukturalt_kabelezes.pdf 37

t. okt. 2011

16

Szarka T.

HÁLÓZATOK


Az egyes kategóriákba (osztályokba) tartozó kábelezések villamos jellemzői40:

1. 2. 3.

Specified as ELFEXT for category 5e/class D and category 6/class E. Specified as PSELFEXT for category 5e/class D and category 6/class E. ELTCTL is specified at 30 MHz.

A kábelezési szabványokban a chanel fogalma a horizontális kábelezés teljes (NIC-kapcsoló közötti) hosszát jelenti, míg a link alatt a patch kábelek nélküli szakasz értendő41. A következő ábrán42 az alap összeköttetés (mint link) és az A, D és E jelű patch kábeles szakaszok láthatóak.

40

http://www.siemon.com/us/white_papers/07-03-01-demystifying.asp és ge10ge.pdf http://www.docstoc.com/docs/28004290/A-White-Paper/ 42 www.tilb.sze.hu/tilb/targyak/ta37/Legrand-ea-2006.pdf és http://www.krugel.hu/informaciok12003.html 41

t. okt. 2011

17

Szarka T.

HÁLÓZATOK


Strukturált kábelezés egyik célja, hogy épületekben olyan kábelezést hozzanak létre, amely több feladat ellátására is alkalmas (felhasználás semleges), pl. analóg és digitális telefonok, videó rendszerek, számítógépes hálózat, különböző érzékelők jeleinek épületen belüli továbbítására. A hálózati technológiák fejlődésével a strukturált kábelezésre vonatkozó szabványosítás is lépést tart, illetve próbál „előre gondolkodni”. A szabványok másik célja, hogy a kábelezés és kiegészítő elemei ne csak a pillanatnyi igényeknek, hanem a jövőben (következő 10-15 évben) elterjedő technológiáknak is feleljenek meg. (A hálózat aktív eszközeivel, pl. router, kapcsoló nem foglalkozik ez a szakterület.) ISO/IEC 11801 2nd Edition a strukturált kábelezések egész világon érvényes alapszabványaként a "telephelyi hálózatok"-on (LAN) történő nagysebességű, számítógépes adat, telefon, kép és más, alacsony feszültségű szabványos jelek (Token Ring, Ethernet, ISDN, TPDDI, Fast Ethernet, 100Base-TX, ATM, Gigabit-Ethernet, 1000Base-T, CATV, stb.) átvitelével foglalkozik. Definiálja az alkatrészek felépítését, topológiáját, műszaki követelményeiket és az adatátviteli utat, valamint meghatározza a mérési paramétereket és módszereket a beépített alkatrészek teszteléséhez. Ez a nemzetközi szabvány tartalmilag nagyon megközelíti a TIA/EIA 568-B amerikai szabványt és kiindulási alapja az európai CENELEC43 EN 50173 2nd szabványnak is. A következő két ábrán44 a strukturált kábelezés lényegét láthatjuk:

• Általános esetben az épület helyiségeiben (a munkaterületen) kb. 5m2–re jut egy iker (LAN és telefon célú) távközlési aljzat (TO). • Ezeket az ún. vizszintes kábelezés köti össze az emeletenként kialakított szint elosztó (FD) szekrényben (esetleg emeleti távközlési helyiségben) található patch panelekkel, amelyekben a kábelek végződnek. • A patch panelek csatlakozóiból patch kábelekkel lehet igény szerint a szekrényben elhelyezett switch-hez vagy, pl. a telefonközpont portjához menő vezetékhez csatlakozni. • Az egyes szintek FD-it az ún. felszálló (függőleges, gerinc) vezetékezés köti össze az épület távközlési helyiségében kialakított központi elosztóval (BD). (A gerinc vezetékek fajtái már eltérőek lehetnek telefon, ill. számítógépes hálózat esetén.) Itt elkülönítve találjuk a számítógépes hálózat és az egyéb, pl. telefon központi (épület) elosztó szekrényeitEbbe a helyiségbe futnak be a WAN és telefon szolgáltatók vonalai és kapcsolódnak a megfelelő eszközökhöz: pl. privát telefonközponthoz (PBX), modemhez, routerhez. Több épületet magában foglaló hálózat esetén az épületek közötti elosztást biztosító CD szekrény is itt található. 43 44

European Committee for Electrotechnical Standardization http://digitus.itk.ppke.hu/~takacsgy/tkhtea11_09.ppt

t. okt. 2011

18

Szarka T.

HÁLÓZATOK


Hálózati topológia A strukturált hálózat tervezésekor is figyelembe kell venni, hogy az Ethernet technológia akkor működik helyesen, ha minden számítógép egy útvonalon közelíthető meg, tehát egy fa jellegű topológia jellemzi a hálózatot. A gyakorlatban előfordul az, hogy kapcsolók közötti alternatív (redundanciát biztosító) útvonalakkal is kiegészítik a hálózatot, hogy egy-egy link kiesése ne okozza a hálózat nagy részének leszakadását. Ilyenkor a kapcsolók feladata az, hogy az alternatív útvonalak letiltásával újra fa topológiát hozzanak létre. A kapcsolók az alternatív útvonalat akkor veszik igénybe (építik be a fába), ha egy addig működő link meghibásodik. A kapcsolók közötti alternatív útvonalak csak akkor hozhatók létre a hálózatban, ha a kapcsolók támogatják a Spanning Tree Protocol (STP)-t. Routerek esetében az alternatív útvonalak kezelése az alapértelmezett szolgáltatások közé tartozik. A következő két ábrán az áttekinthetőség miatt csak a kapcsolókat tüntettük fel (az itt most nem ábrázolt számítógépek ezekhez csatlakoznak). A kapcsolók közötti fizikai kapcsolatok és a kapcsolók által kialakított feszítő fa45.

Vonali kódolás “A vonali kódolás az alapsávi46 digitális jelátvitelben az a művelet, mely során a továbbítandó információhoz (a forrás szimbólumsorozathoz) olyan jelsorozatot (vonali szimbólumsorozatot) rendelünk, mely az átviteli úton a legkisebb torzítással halad át. ...

Sebesség definíciók a digitális jelátvitelben: • bitsebesség: az időegység alatt továbbított információ mennyisége [bit/s] 47 • jelzési sebesség: az időegység alatt továbbított vonali szimbólumok száma [Baud]” 10Base-2 technológia Félduplex. 10Mbps bitsebesség, Base azaz alapsávi átvitel. Max. 185m-es azaz, kb. 200m-es szegmens. Az átküldendő adatokból Manchester kódoló algoritmus (enkóder) segítségével generálják a vonali bitsorozatot48, amelyet +2.5V és -2.5V-os-os feszültség szintek reprezentálnak a kábelen. Kódolás során szükséges egy órajel, amely a bitsorozat ütemezését végzi. Az órajelből és az átküldendő adatbitekből az alábbi (a Manchester kódolás egyik változatát leíró) igazságtáblázat alapján jön létre a vonali bitsorozat:

A vevő a jelváltozásból ismeri fel a a bitidő közepét, azaz egyértelmű számára, hogy mikor kell mintát vennie a bemenő jelből (önszinkronizáló). Hátránya a megoldásnak, hogy az igényelt sávszélesség kétszerese az átvinni kívánt kódolatlan jelsorozathoz képest. 45

http://wapedia.mobi/en/File:NetworkTopology-Tree.png Modulációt nem használ, ezáltal a jel spektruma nem tolódik el a frekvenciatengelyen. 47 http://alpha.tmit.bme.hu/meresek/4-17.htm 48 http://en.wikipedia.org/wiki/Manchester_code és http://www.interfacebus.com/manchester-encoding.html 46

t. okt. 2011

19

Szarka T.

HÁLÓZATOK


100Base-TX technológia A duplex átvitelhez 1 érpárat adásra és egy másikat vételre használ. 100Mbps MLT-3 és 4B/5B kódolást használ. Az MLT-3 (Multi Level Transmit) kódolási eljárása: “a kódoló egy négy állapotú ciklikus működésű automata. Az automata állapotaihoz rendre a vonali jel következő értékeit rendeljük: -1,0,1,0. Az automata 1-es továbbításakor a következő állapotba lép, 0 továbbításakor állapota nem változik. A kódolás sávszűkítő, az "alapfrekvencia" a bitidő negyede lesz.”49 Az algoritmus a következő ábrán50 figyelhető meg. A vonali kód 3 jelszintet használ: -1V, 0V, 1V. Megfigyelhető, hogy azonos bitráta mellett kisebb (1/4) a sávszélesség igénye, de a kód nem rendelkezik önszinkronizáló képességgel. Ezen segít küldendő adatok 4B/5B kódolással történő “előkezelése”. Ez biztosítja, hogy a jelfolyamban megfelelő számú szintváltás legyen (10 bites kódszavanként legalább 3), ezáltal lehetővé teszi a helyes órajel szinkron előállítását A küldendő adatbájtokat 2-2 bájtos csoportokra bontják és 4 bit helyett 5 bites kódot állítanak elő51. Ezáltal a vonalon 25-en, azaz 32 különböző (adat vagy speciális célú, a keretek elejének és végének megjelölésére, és a keretek közti szünetek kitöltésére) szimbólumot lehet átküldeni. Részlet a 4B/5B kódtáblából: A 4 helyett 5 bit továbbítása a 100Mbps-es adatfolyam helyett 125Mbps-es adatfolyamot eredményez. Ezen az MLT-3 kódolást végrehajtva jelentkezik az MLT-3 frekvencia negyedelő hatása, amelynek következtében csak egy elfogadható 31,25MHz-es adatfolyamot kell továbbítani a CAT5e típusú kábelen. Más megfogalmazásban a vonalon a jelzési sebesség (simbol rate) csak 31,25Mbaud (Msymbols/sec), de minden jel egynél több bitnyi információt hordoz azáltal, hogy több jelszintet értelmez a rendszer. 1000Base-T technológia Pont-pont jellegű kapcsolat (tehát gép-hub kivételével gép-gép, gép-sw kapcsolat) esetén mind a 4 érpáron egyszerre mindkét irányban lehet adás és vétel egy adott pillanatban. (Láttuk, hogy a 100Base-TX esetén egy adott érpáron csak egy irányú (szimplex) a kommunikáció, de maga a rendszer már duplex a két érpár használata miatt.) Az ún. hibrid áramkör biztosítja, hogy az érpár azonos végéhez kapcsolódó adó és vevő lehetőleg ne érzékelje egymást. (Pl. a hagyományos telefonban sem zavarja egymást a mikrofon és a hallgató pedig egy érpárra kapcsolódnak.) Egy érpár duplex használata52: 125Mbaud jelzési sebességet használnak minden érpáron. Ha minden jelzéssel 2 bitnyi (hasznos) információt visznek át, akkor tehát egy érpáron 250Mb/s adatátviteli sebesség érhető el irányonként. A vonalon 5 szintes (PAM5) 49

http://alpha.tmit.bme.hu/meresek/4-17.htm http://en.wikipedia.org/wiki/MLT-3_encoding 51 gbenthien.net/encoding.pdf 52 splash.eik.bme.hu/papers/ge10ge.pdf 50

t. okt. 2011

20

Szarka T.

HÁLÓZATOK


kódolást használnak, amely minden jelzéssel log25=2.32 bitnyi információt visz át egy érpáron, így a négy érpáron ez kb. 9.28 bitnyi információt jelent. Ez más szavakkal azt jelenti, hogy redundáns információt is továbbítunk a vonalon, mert az elvileg egy jelzéssel átvihető 29.28 pontosabban 54 =625 különböző vonali szimbólumból számunkra csak 28, azaz 256 a hasznos adat szimbóluma. A maradék szimbólumok különböző jelzésekre (pl. a keret kezdetéhez, a carrier extension-nél a keretek megtoldására, valamint frame bursting esetén az összetartozó keretek jelzésére), illetve hibajavítási célokra is használhatóak. A következő ábrán53 három jelzést látunk, amelyek a 625 lehetséges kódszóból 3 félét visznek át. Összefoglalva: 4érpár*125Mbaud* 2bit/baud=1Gbps 1000Base-TX technológia Egyszerűbb elektronika, de CAT6 kábelezés követelmény. Gigabites technológiák54 összefoglalója:

Egyéb források: időzités: www.inf.u-szeged.hu/~bilickiv/ip_1_2005_2/4.ppt PoEthernet: http://www.poweroverethernet.com/articles.php?article_id=52 minden: http://ob121.com/bus_ethernet.html users.iit.uni-miskolc.hu/~szkovacs/GAMFNetD/NetDE3.pdf http://alpha.tmit.bme.hu/meresek/interf.htm http://www.johanyak.hu/files/u1/segedlet/halozatepites/er_Balazs_Passziv_halozati_elemek_telepitese.pdf www.inf.u-szeged.hu/~bilickiv/ip_1_2005_2/4.ppt people.inf.elte.hu/lukovszki/Courses/08NWI/nwI07s4.pdf http://www.rhyshaden.com/encoding.htm http://ckp.made-it.com/ieee8023.html http://www.ronmar.netfirms.com/ppc/network/chapter3.html http://alpha.tmit.bme.hu/meresek/lanfiz.htm#eframe The Ethernet new handout.pdf pcs.pdf

53 54

ftp.dell.com/app/4q01-Pat.pdf http://en.wikipedia.org/wiki/Gigabit_Ethernet

t. okt. 2011

21

Szarka T.

HÁLÓZATOK


Ethernet keretek Térjünk vissza az (L2) adatkapcsolati réteghez! A továbbiakban először az ETHERNET hálózatokban használatos keretekkel ismerkedünk meg. Korábban láttuk, hogy a fizikai rétegben található médián bitek áramlanak a fizikai kommunikáció során. Ezek a bitek az L2 szintjén kereteket alkotnak, amelyek az L2-ben használatos protokollok adattovábbítási egységei. A keretek küldésének oka az L3-ban implementált protokollokban keresendő: ezek szeretnének egymással kommunikálni. Ezt a (virtuális) kommunikációt az L2+L1-ben implementált (pl. valamilyen Ethernet) protokoll segítségével, használatával tudják elvégezni. Kiindulásként úgy tekintsünk a keretre, hogy • A fejrészt alkotó mezők és záró hibakezelő mező az L2-L2 protokollok közötti virtuális kommunikációt teszik lehetővé, azaz pl. az Ethernet kártyák ezek segítségével beszélgetnek egymással. • az adatmezőt az L2 protokollja nem értelmezi. Az adási végponton csak kapja a tartalmát, és a vételi oldalon csak továbbadja az L3-ban implementált a megrendelő protokollnak, ezzel létrehozva az igényelt L3-L3 közötti “beszélgetést”, azaz a virtuális kommunikációt. Megjegyzés: a következőkben gyakran felmerül az LLC fogalma. Később részletesebb magyarázatot kapunk feladatáról, most tekintsük pl. az Ethernet kártya meghajtó programjának, amelyik illesztést végez a keret átvitelét megrendelő L3 protokoll és a hálókártya hardvere között.

IEEE 802.3 típusú Ethernet keret, 802.2 „LLC betéttel” NIC generálja

LLC generálja

MAC fej Preamble Cél MAC címe Adó MAC címe 8 6 6

LLC PDU LLC NIC (Az LLC kliensétől v. kliensének) gen. gen. LLC fej LLC adat ADAT PAD CRC Hossz DSAP SSAP CONTR 1 0…1497 x 4 2 1 1

Preamble mező: (8 bájt) A NIC-en elhelyezkedő MAC protokollt megvalósító chip az adás kezdetén „magától” generálja. Az adó azért bocsátja ki, hogy a vevő(k) szinkronba kerüljenek az adóval. Az első 56 bit tartalma: 10101010, majd az utolsó 8 bit55 10101011, így jelzi a chip MAC fej kezdetét. Ezt a mezőt, semmilyen későbbi hossz számításban nem vesszük figyelembe. A cél NIC fizikai (MAC) címe (6 bájt): első megközelítésben minden Ethernet kártyának 6 bájtos egyedi címe van. A címkiosztás (kezdetben a XEROX által központosított) módszere elvileg garantálja56, hogy a világon ne legyen két azonos fizikai című kártya. A cím 48 bitjéből 22 bitet a XEROX fenntartott a NIC gyártók, ill. egyéb gyártók „fölötti” szervezetek azonosítására. Egy-egy gyártó 24 bittel rendelkezik, hogy egymástól megkülönböztesse a saját legyártott kártyáit. A maradék 2 bitet a fizikai címek jellegének leírására használják. A gyártók 24 bites címkomponenseit napjainkban az IEEE osztja ki (részletet):

55 56

Ezt a 8 bitet külön elnevezték: keretkezdet határoló. Mindaddig, amíg szoftveresen át nem állítjuk a kártyánk fizikai címét.

t. okt. 2011

22

Szarka T.

HÁLÓZATOK

00:00:02 00:00:0E 00:00:10 00:00:15 00:00:1A 00:00:1D 00:00:21 00:00:23 00:00:2A 00:00:3D 00:00:46 00:00:4B 00:00:51 00:00:55 00:00:5D 00:00:61 08:00:0A


BBN Fujitsu Sytek/Hughes LAN Systems Datapoint AMD ? Cabletron SC&C ABB TRW ATT Bunker Ramo APT Hob Electronic AT&T RCE Gateway IBM

00:00:0C 00:00:0F 00:00:11 00:00:18 00:00:1B 00:00:20 00:00:22 00:00:29 00:00:3C 00:00:44 00:00:49 00:00:4F 00:00:52 00:00:5A 00:00:5E 00:00:62 00:AA:00

Cisco NeXT Tektronics Webster Novell/Eagle Tech. Data Industrier AB Visual Technology IMC Auspex Castelle Apricot Logicraft ODS SK/Xerox IANA Honeywell INTEL

Például két gyártó által előállított kártyák MAC címe, ahol XX tetszőleges értékű bájt: IBM 08:00:0A:XX:XX:XX INTEL 00:AA:00:XX:XX:XX Egy MAC címet 6 darab hexadecimális számmal írunk le, például: 08:00:0A:33:24:00 A fizikai (MAC) cím a médián való megjelenési sorrendben57 és bitenként részletezve: 0.

G/I bit

1.

U/L bit

2.

23.

22 bit a gyártót jelöli

24.

47.

24 bit a gyáron belül

A MAC címekben két bitnek kitüntetett szerepe van: • G/I bit különbözteti meg az egyedi (Individual) címet (0) és a csoportcímeket (Group) (1). • U/L bit különbözteti meg a gyárilag kiosztott (Universally administered) címet (0) a nem hivatalos, helyi rendszergazda által kiadott (Locally administered) címtől (1). Az Ethernet keret mezői kapcsán meg kell említenünk, hogy a több bájtos adatok ábrázolása az ún. nagy endián rendszert követi, amely azt jelenti, hogy az adatszerkezet legnagyobb helyiértékű bájtja kerül az adatszerkezet által elfoglalt memóriaterület legkisebb címére. Az általunk használt INTEL processzorokra viszont a kis endian típusú adattárolás jellemző, ezért az erre a processzora „készített” adatszerkezetek esetében szükséges lehet egy bájtsorrend konverzió. Tegyük fel, hogy a programunkban az ethernet keret kétbájtos hossz mezőjét egy WORD típusú változó segítségével kezeljük. Ha a mező értékét a változóba áttöltjük és a változó értéke, pl. 1234H lesz, akkor a hossz mező valójában 3412H-t tartalmazott! Az viszont más kérdés, hogy ilyen értékű hossz mező nem lehet. (A MOTOROLA gyártmányú processzorok szintén nagy endian módon tárolják a szavakat, ezért ha korábbi APPLE-re fejlesztünk, akkor nincs (ilyen) problémánk, mert a hálózati bájtsorrend (network order) megegyezik a hoszt oldali bájtsorrenddel (host order). Elegánsan is megoldható ez a probléma: pl. egy CD-ROM esetén, mindkét alakban rögzítik a vezérlő információkat és lám ezt a médiát mindegyik rendszerben probléma nélkül lehet használni!)

Visszatérve a fizikai címekhez, ügyeljünk tehát arra (legalábbis IBM PC-s környezetben), hogy a cím legnagyobb helyiértékű58 bájtja van (vagy legyen) a cím által elfoglalt memóriaterület kezdőcímén és ezt követik az egyre kisebb helyiértékű bájtok. Az egyedi, más szóval unicast cím azt jelenti, hogy csak egy NIC-nek lett címezve a keret, illetve az adó címeként mindig ilyen címet használunk. A csoport (multicast, többesküldés) cím jelentősége az, hogy több (az adott csoportba tartozó) NIC számára nem kell külön 57 58

Az RS232 interfészre is az volt a jellemző, hogy az adás alatt lévő bájt 0. bitje került először a vonalra. Lehet, hogy a cím „legbaloldalibb bájtja” helyesebb lenne.

t. okt. 2011

23

Szarka T.

HÁLÓZATOK


kereteket küldeni, mert egy darab multicast címzésű kerettel az összes csoporttagnak küldhető üzenet. Csak cél címeként használható csoportcím. Üzenetszóró (broadcast) címzést akkor használnak, ha a hálózat minden gépének (pontosabban NIC-nek)szól az üzenet. Csak cél címeként használható broadcast cím. (Később bemutatjuk, hogy a NIC promiscuous üzemmódban minden keretet vesz a célcímtől függetlenül!) Összefoglaljuk a fogalmak kiemelt fontossága miatt: • Unicast címet akkor használunk, ha a keretnek a hálózaton egy címzettje van. • Multicast címet kell használni, ha a keretnek a hálózaton több címzettje van. • Broadcast címmel érhető el, hogy a keretet a hálózaton mindenki vegye. Az átviteli közeg terhelését csökkenti a multicast és broadcast címzési mód, mert nem kell minden érintettnek külön-kölön elküldeni a keretet. Broadcast (üzenetszóró, adatszóró) címben minden bit egyes értékű: FF:FF:FF:FF:FF:FF Csoportcím a G bit beállításával képezhető az egyéni NIC címből. Az egyik előbbi MAC címből: IBM 09:00:0A:..:..:.. (Fentebb olvashattuk, hogy miért nem 88:00:0A:..:..: lett.) Az adatkapcsolati réteg protokoljai, amelyek multicast címet használnak (részlet): CISCO Discovery Protocol: 01 00 0C CC CC CC Bridge Spanning Tree: 01 80 C2 00 00 00 A csoportos címzés igényével gyakran valamelyik felsőbb réteg alkalmazása jelentkezik: • A Media Services (W2K szerver) egy csoport számára „sugároz” valamilyen anyagot, pl.: filmet, Power Point prezentációt, stb. • Az Exchange 2000 Conferencing Server segítségével többrésztvevős konferenciát lehet létrehozni. • A Windows indulásakor a routerek számára fenntartott csoportcímre címre küldött Router Solicitation üzenettel képes megkeresni a Default Gateway-t. A fenti alkalmazások a hálózati réteg által biztosított csoportcím használati lehetőségre épülnek, azaz a hálózati rétegben az IP címtér csoportcím alteréből (224.0.0.1.239.255.255.254) származó hálózati címeket használnak. A hálózati rétegben megjelenő csoportcím használatot a MAC alrétegnek is támogatnia kell fizikai szintű csoportcímekkel. Ezért a fenti alkalmazások dinamikusan konfigurálják a hálózati kártyát úgy, hogy a NIC által vizsgált csoportos MAC címek közé fölveszik az adott alkalmazás által használt (csoportos IP) címből a csoportcímzésre fenntartott MAC címtartományban (01-00-5E-00-00-00...01-005E-FF-FF-FF) kialakított MAC címet. Ehhez az alkalmazás az általa használt csoportos IP cím utolsó 3 oktettjét használják fel a konkrét MAC cím kialakítására. Például a 239.192.1.2 csoportcímet használó alkalmazások a következő MAC címet rögzítik a NIC-ben: 01-00-5E-C0-01-02. Mivel a csoportcímet csak célként használják nem okoz gondot a MAC címek egyezősége. Maradt azonban egy apró probléma, amely abból származik, hogy az IP cím 4 „hasznos” bitje nem vesz részt a MAC cím kialakításában. Ezért előfordulhat, hogy különböző (csoportos) IP címekhez azonos MAC cím tartozik.

Adó NIC fizikai (MAC) címe mező: (6 bájt) Bár nem kötelező, de leggyakrabban megegyezik az adó NIC MAC címével. Hossz mező: Az LLC PDU méretét tartalmazza. Egy ETHERNET keret (preamble nélkül) max. 1518 bájt, ill. min. 64 bájt hosszú lehet. Ha figyelembe vesszük a MAC keret és az LLC fej számára fenntartott bájtokat, akkor az LLC adatbájtok száma 43..1497 közötti lehet59:

59

A később bemutatandó más típusú Ethernet keretek esetében az LLC adatmező mérete ettől eltérő is lehet.

t. okt. 2011

24

Szarka T.

HÁLÓZATOK

Mező: MAC cél MAC küldő Hossz LCC fej CRC Összesen


Méret (bájt): 6 6 2 3 4 21

A táblázat a 802.3 keretben elhelyezett 802.2 (LLC) betét esetére készült!

A hossz mező szó hosszúságú, ezért vigyázzunk a bájt sorrendre! Az Ethernet kereten belül most elérkeztünk az LLC PDU-t alkotó mezőkhöz, azokat mintegy „kinagyítva” megvizsgáljuk a szabvány (IEEE 802.2 (LLC)) szerint TYPE 160 PDU nevű adatszerkezetet, amely segítségével az LLC alréteg és a kliense közötti kapcsolat zajlik. Ezt a TYPE 1 adatszerkezet típust akkor használják, ha összeköttetés mentes kapcsolatot kell kialakítani az LLC rétegek, ill. az általuk kiszolgált kliensek között. Ezt jelzi az Unnumbered Information frames minősítése, amely arra utal, hogy az LLC fejlécben nincs a keretek sorszámozására utaló mező, tehát összeköttetés mentes szolgáltatásról van szó. LLC PDU DSAP 1 bájt

LLC fejléc SSAP CONTROL 1 bájt 1 bájt

LLC adat Adatok (pl. IP fejléc +adatok(TCP fejléc + adatok)

n bájt

SSAP (Source Service Access Point). Az adott LLC PDU-t küldő alkalmazást (az LLC egy kliensét) azonosítja, tehát a SAP mezők az LLC kliensek megkülönböztetésére, "címzésére" szolgálnak. Az SSAP mindig egyedi cím. (A küldő lehet egy protokoll, egy alkalmazás vagy általánosítva egy kliens, ahogy tetszik, mert az LLC nem tesz különbséget a kliensei között az alapján, hogy azok melyik rétegben vannak implementálva.) DSAP mező (Destination SAP). A cél alkalmazást (klienst) jelöli, tehát meghatározza, hogy az adott PDU-t melyik kliensnek adja át az LLC alréteg. Unicast, multicast vagy broadcast cím lehet. Egyedi címnél (az adott számítógépen belül) csak egy kliens (protokoll) kapja, multicast címnél több és broadcast cím esetén az összes kliens megkapja az LLC PDU-t. (Legalábbis a MAC alréteg által megcímzett hoszton61 biztosan, mert a megcímzett hosztot (hosztokat) itt nem látjuk, csak a MAC célcímből derül(nek) ki.) Az alkalmazások egységes megkülönböztetése érdekében a gyakori kliensekhez központilag rendeltek SAP értéket. Néhány konkrétum (a „félkövér” protokollokkal később találkozunk a jegyzetben): 00 02 03 04 05 06 08 0C

Null LSAP (Management az LLC rétegek egymás közötti kommunikációjához.) Individual LLC Sublayer Management Function Group LLC Sublayer Management Function (csoportcím) IBM SNA Path Control (individual) IBM SNA Path Control (csoportcím) ARPANET Internet Protocol (IP) SNA SNA

60

Az LLC TYPE 1 protokoll csak a nevében protokoll, valójában egy transzparens réteg a hálózati és MAC réteg között, amelyben nincs implementálva protokoll. A TYPE 1 csak arra kellett, hogy egy piaci súllyal rendelkező termékhez (ETHERNET-hez) alakítsák a szabványt. 61 HOST: Régebben a központi számítógép. Napjainkban minden olyan hálózati eszközt így nevezhetünk, amelynek saját hálózati címe van és képes a kapcsolattartásra hálózaton keresztül. (PC, printer, gateway.)

t. okt. 2011

25

Szarka T.

HÁLÓZATOK


0E PROWAY (IEC955) Network Management & Initialization 42 IEEE 802.1 Bridge Spannning Tree Protocol 4E EIA RS-511 Manufacturing Message Service 7E ISO 8208 (X.25 over IEEE 802.2 Type 2 LLC) 80 Xerox Network Systems (XNS) 8E PROWAY (IEC 955) Active Station List Maintenance 98 ARPANET Address Resolution Protocol (ARP) BC Banyan VINES AA SubNetwork Access Protocol (SNAP) E0 Novell NetWare F0 IBM NetBIOS F4 IBM LAN Management (individual) F5 IBM LAN Management (csoportcím) F8 IBM Remote Program Load (RPL) FE ISO Network Layer Protocol FF Global LSAP (broadcast)

Összefoglalva: a SAP-ok lényegében 7 bites kliens azonosítók (protokoll címek), nyolcadik bitjük speciális szerepű, amint az később az LLC fej bitenkénti leírásából kiderül. (A kliensek megkülönböztetése eléggé korlátozott 8 biten, ezért fejlesztették ki az ebből a szempontból rugalmasabb ETHERNET-SNAP keretet.) CONTROLL mező meghatározza, hogy az LLC protokollok kapcsolatában milyen parancsot ad, vagy milyen parancsra válaszol a küldő. A teljes LLC fej részletesen: DSAP SSAP CONTROL D D D D D D D I/G S S S S S S S C/R MMM P/F MM 1 1 I ndividual (0): egyéni (egy kliensnek szóló) cím. G roup (1): csoportos cím (több kliens megkapja az LLC PDU-t). D estination: A vevő kliens címe C ommand (0): parancs (a klienstől jön) R esponse (1): válasz a kliensnek S ource: a küldő protokollt azonosítja, mindig egyéni cím. M : Az LLC szolgáltatásait kiválasztó bitek P oll/Final (0/1): A Poll értéke arra utal, hogy még nem ért véget egy adott kerettel a logikailag összetartozó keretek sorozata. Ethernetnél ennek nincs jelentősége.

Tehát a CONTROL bájt határozza meg, hogy a SSSSSSS című kliens milyen szolgáltatást kér az LLC-től, illetve az LLC ezzel jelzi, hogy milyen parancsra ad választ a DDDDDDD című kliensnek. A lehetséges szolgáltatások: CONTROLL=03H Unnumbered Information (UI) paranccsal úgy tudunk adatokat küldeni a vevő LLC-nek (ill. a kliensének), hogy nem rendelünk az adott kerethez sorszámot és nem várjuk a küldött keret megérkezésének visszaigazolását sem. Tehát összeköttetés mentes és nyugtázatlan szolgáltatásra használható, ahol az LLC az adatokat egyszerűen tovább adja a DSAP-ban megadott kliensnek. Az SSAP mezőben C=0 a parancs kiadásakor: DSAP SSAP CONTROL Adatbájtok D D D D D D D I/G SSSSSSS0 000 0 00 1 1 x Az egy másik történet, ha pl. a szállítási rétegben majd biztosítják nyugtázott összeköttetéses szolgálatot az ezt igénylő (pl. banki) alkalmazások számára. Pl. a TCP/IP esetén látunk erre példát. Érdeklődőknek ismertetjük az LLC TYPE 1 (IP, ARP által nem használt) egyéb parancsait:

t. okt. 2011

26

Szarka T.

HÁLÓZATOK


XID: Exchange Identification paranccsal LLC kérdez le LLC-t, hogy az milyen típusú szolgáltatással rendelkezik és mennyi adatot tud fogadni (milyen az ablak mérete). A parancs kódja: 0AFH vagy 0BFH a P/F bit értékétől függően és a C/R bit 0:

DSAP DDDDDDDI/G

SSAP SSSSSSS0

101

CONTROL 0 11 1

1

A válaszban DDDDDDD tartalma helyet cserél SSSSSSS-el. A C/R=1 és a CONTROL mező után az LLC által generált (!) adat érkezik: 81H, 01H, 00H az Ethernet esetén. A válasz mezői:

DSAP DDDDDDDI/G

SSAP SSSSSSS1

FORMAT XXXXXXXX

CLASS 000YYYYY

101

CONTROL 0 11 1

1

+

WINDOW ZZZZZZZ0

XXXXXXXX=10000001 Basic XID formátumú a válasz. Ekkor a következő a mezők jelentése: YYYYY=00001 TYPE I. szolgáltatással rendelkezik az LLC YYYYY=00011 TYPE II. szolgáltatással rendelkezik az LLC ZZZZZZZ=0000000 Az ablak mérete (Kbyte). (Az LLC ennyi adatot képes fogadni anélkül, hogy a kliense ürítené a vételi bufferét.) TEST: Test Frame paranccsal LLC tud LLC-nek próbaképpen adatokat küldeni. A parancs kódja: 0E3H vagy 0F3H a P/F bit értékétől függően és C/R bit 0:

DSAP DDDDDDDI/G

SSAP SSSSSSSC/R

CONTROL 111 0 00 1 1

Adatbájtok

A TEST válaszban DDDDDDD tartalma helyet cserél SSSSSSS-el és C/R=1. A válaszban a CONTROL mező után az elküldött adatok is visszajönnek. IEEE 802.2 (LLC) szerint TYPE 2 PDU Az eddig tárgyalt TYPE 1 mellett létezik egy másik LLC PDU formátum is, amely összeköttetéses szolgáltatást támogat. Lehetőséget ad sorszám-ellenőrzésre és nyugtázásra, valamint csúszóablakos 62 pufferelésre . Ethernet hálózatban a TYPE 2 PDU nem TCP/IP esetén, hanem pl. NetBEUI protokollnál fordul elő. A kapcsolat orientált (tehát összeköttetést biztosító) szolgáltatásoknál az LLC PDU átküldése előtt kapcsolatot kell létrehozni az adó és vevő között, majd a kapcsolatot fenn kell tartani az adatok és vezérlőinformációk átküldése alatt, végül a kapcsolatot le kell bontani. Az LLC CONTROL 16 bitesre 63 64 változik . Ezt nevezik TYPE 2 formátumú LLC PDU-nak. Adatszállító fej: CONTROL1 CONTROL2 DSAP SSAP

DDDDDDDI/G SSSSSSSC/R

N(S)

0

N(R)

P/F

Supervisory fej:

DSAP SSAP DDDDDDDI/G SSSSSSSC/R

CONTROL1

0000

SS

CONTROL2

0

1

N(R)

P/F

Megjegyzés: nem tüntettük fel a fej után következő adatmezőt. A CONTROL mező leírását a szakirodalomban megtalálhatjuk (pl. http://protocols.com), most csak annyit ennek a sajátosságairól, hogy minden PDU-t egy sorszámmal, pl. Nr(SEND) látnak el, az összeköttetéses kapcsolatot megvalósító LLC protokoll működtetése érdekében. Újra felmerült a kapcsolat nélkül és kapcsolatot megvalósító szolgáltatás kérdése. A kapcsolat orientált szolgáltatások biztonságosabbak az adatvesztés elkerülésében. Ezt a biztonságot sok szerviz információ küldözgetésével érik el, ezért (ugyanolyan minőségű hálózatok esetében) relatíve kisebb a felhasználó által látott adatviteli sebesség, mint a kapcsolat mentes szolgáltatásoknál. A felhasználási terület határozza meg, hogy melyiket célszerű használni. Például folyamatirányítási célú hálózatban jó, ha biztonságos az adatátvitel, viszont egy videokonferencián nem zavaró egy apró képhiba, itt inkább az átviteli sebességen van a hangsúly. 62

Ezeket a módszereket később a TCP kapcsán részletesen tárgyaljuk. A vezérlő bájt helyett szó lesz. 64 A típusok (type) az LLC PDU „fejére” vonatkoznak. 63

t. okt. 2011

27

Szarka T.

HÁLÓZATOK


Térjünk vissza az LLC PDU adatmezőjéhez! Adatmező: Általában hálózati réteg protokollja (általánosabban az LLC kliense) tölti fel adatokkal, illetve vétel esetén az értelmezi. (Az LLC PDU-t bemutató ábrán például az IP által kezelt adatmezőre utalunk.) Megismételjük, hogy az ETHERNET kártyát nem érdekli, hogy mit ad vagy vesz, egyszerűen „szó szerint” elküldi azt, amit rábízott az LLC. Az LLC kliensének figyelembe kell vennie, hogy az adott MAC+LLC protokollban mennyi az egy kerettel átvihető adatbájtok száma. Ethernet hálózat esetén ez az ún. Maximum Transmission Units (MTU) az aktuális kerettípustól függően 1500 bájt körül van. A most tárgyalt kerettípus esetén az MTU 1497 bájt. Néhány MAC protokoll és az MTU értéke: MAC protokoll Token Ring FDDI Ethernet II Ethernet 802.3

MTU [byte] 17914 4352 1500 1497

MAC protokoll ARPANET X.25 ARCNET Szabványos minimum

MTU [byte] 1006 576 508 68

PAD mező: Opcionális mező, az Ethernet keretet a minimális 64 bájtos hosszra egészíti ki. (Tehát a MAC címek, hossz, LLC PDU, PAD, CRC legalább 64 bájtot „tegyenek ki”.) A most tárgyalt kerettípus esetén is elképzelhető, hogy 43 bájtnál kevesebb adatot, pl. 10 bájtot kell küldeni. Ilyenkor az LLC érzékeli, hogy 10 bájtos a PDU adatmezeje és ennek megfelelően állítja be a hossz jelzést 13-ra (3 LLC fej+ 10 LLC adat). Viszont gondoskodnia kell a PAD mező feltöltéséről, hogy a legrövidebb kerettel kapcsolatos követelményeket kielégítse. Ebben az esetben tehát 33 bájtos PAD mezőt illeszt a PDU adatbájtok után (14 MAC fej+13 LLC PDU+33 PAD+4 CRC). Természetesen a vételi oldalon a hossz mező alapján leválasztják a tölteléket (a PAD-ot) az LCC PDU adatmezőjéről, így nem kerül át a hálózati rétegbe. Elképzelhetőnek tartom azt is, hogy a PAD (Packet Assembler-Disassembler) mezőt az Ethernet kártya automatikusan generálja. A kérdést nem tudtam eldönteni, mert az Ethernet kártya később megismerendő eszközmeghajtó szoftvere „eltakarja” ezt a problémát a programozó elől.

CRC mező a keret épségét ellenőrző bájtsorozat. Adáskor az LLC alréteg a memória x címétől kezdve elhelyezi a küldendő MAC keret teljes tartalmát a NIC által automatikusan generált preamable és CRC mezők kivételével. Ezután parancsot ad az Ethernet adapternek, hogy az előbbi x memória címtől kezdődően n bájtot küldjön a médiára. Amikor a NIC megkezdi az adást, a keret tartalmából a cél címtől kezdve hibaellenőrző kódot generál65 és az utolsó adatbájt után elküldi mint 4 bájtos értéket. Adás érzékelése esetén a NIC a cél MAC címét vizsgálva eldönti, hogy vennie kell-e a médián érzékelt keretet. Vételkor a NIC az LLC által vételi pufferként megadott y memóriacímtől kezdve a preamble és CRC mező kivételével a teljes keretet elhelyezi. A keret végét a MAC szinten kialakuló adásszünet jelenti, ekkor a vevő ellenőrzi a CRC-t. A vett keretet „eldobja”, ha hibás a CRC a beérkezett keretben66. Azt már említettük, hogy Ethernet hálózatban sem a vevő MAC, sem a vevő LLC rétege nem küld az adónak visszajelzést a vétel sikerességéről vagy sikertelenségéről.

65 66

32 bites AUTODIN II. polinom segítségével készíti. Csak az egyszerűsítés miatt neveztük CRC mezőnek. Fizikailag beolvassa, de logikailag nemlétezőnek tekinti.

t. okt. 2011

28

Szarka T.

HÁLÓZATOK


ETHERNET II keret Ez a változat 3 évvel idősebb mint az IEEE 802.3 ajánlás, de jelentősége miatt kvázi szabványnak is tekinthető. Egyéb megnevezései: DIX ETHERNET, ill. az eredeti 1982-es ETHERNET II. leírás borítója alapján Blue Book ETHERNET. Preamble 8

MAC cél 6

MAC forrás Protokoll azonosító 6 2

Adat 46-1500

PAD x

CRC 4

Látszik, hogy a szabványos LLC fej hiányzik, csak egy protokoll azonosítót tartalmaz a keret. Megalkotói úgy gondolták, hogy hossz információt tartalmazó mezőt, majd a protokollok biztosítanak maguknak az adatmezőben, a protokollra jellemző kereten belül. Protokoll azonosító mező : tartalma mindenképpen nagyobb, mint 1500, ezért ebből a jobb szoftverek felismerik, hogy ETHERNET II típusú kerettel dolgoznak, mert a hossz/típus mező értéke alapján a két keretformátum megkülönböztethető. (Felismerhető, hogy az ETHERNET II-ből kifejlesztett IEEE 802.3 keretben az IEEE 802.2 betét DSAP mezője vitte tovább a protokoll azonosító funkcióját a szabványosítás után.)

A mező konkrét értékei közül néhány, a XEROX nyilvántartása szerint: 0600 0800 0802 0804 0806 081C 0900 0A01 0BAF 1001 1600 3C00 4321 6000 6002 6004 6006 6010 7001 7003 7007 7020 7031 8003 8005 8008 8013 8015 8019 802F 8036 8038 803A 803C 803E 8040 8042 8046 8049 805C 8060 8065 8068 806A 806D 807A 807C 8080 8088 809C

XNS DOD IP NBS internet Chaosnet ARP Symbolics private Ungermann-Bass net debug Xerox PUP Address Translation Banyan Echo Berkeley trailer encapsulation VALID system protocol 3Com NBP THD - Diddle DNA experimental DNA Remote Console -MOPDEC: Local Area Transport DEC: Customer Use 3Com Ungermann-Bass NIUs Ungermann-Bass OS/9 Microware Sintrom (was LRT) Prime NTS Cronus VLN HP Probe AT&T/Standford Silicon Graphics diagnostic Silicon Graphics Apollo DOMAIN Tigan Aeonic Systems DEC: bridge DEC: (Argonaut console) DEC: NMSV DNA Naming DEC: distributed time service DEC: NetBIOS Datagrams DEC Unassigned AT&T ExperData Stanford V Kernel Little Machine UMass. at Amherst General Dynamics Autophon Compugraphic Corp. Matra Merit Internodal Vitalink TransLAN III Mgmt Xyplex Datability

t. okt. 2011

0601 0801 0803 0805 0807 0888 0A00 0BAD 1000 1234 1989 4242 5208 6001 6003 6005 6007 7000 7002 7005 7009 7030 7034 8004 8006 8010 8014 8016 802E 8035 8037 8039 803B 803D 803F 8041 8044 8048 805B 805D 8062 8067 8069 806C 806E 807B 807D 8081 809B 809F

29

XNS Address Translation X.75 internet ECMA internet X.25 Level 3 XNS Compatibility Xyplex Xerox PUP Banyan Systems Berkeley trailer negotiation DCA - Multicast Artificial Horizons (dogfight sim.) PCS Basic Block Protocol BBN Simnet Private DNA Dump/Load -MOPDNA IV Routing Layer DEC: Diagnostics DEC: LAVC Ungermann-Bass download Ungermann-Bass diagnostic/loopback Ungermann-Bass Bridge OS/9 Net ? Racal-Interlan Cabletron Cronus Direct Nestar Excelan Silicon Graphics network games Silicon Graphics XNS Nameserver Tymshare Reverse ARP IPX (Netware) DEC: DSM/DDP DEC: (VAXELN) DEC: encryption DEC: LAN Traffic Monitor DEC: Local Area System Transport Planning Research Corp. DEC: DECamds VMTP/RFC-1045 Evans & Sutherland Counterpoint Computers Veeco Integrated Automation AT&T ComDesign Landmark Graphics Corp. Dansk Data Elektronic Vitalink Communications Counterpoint Computers AppleTalk (EtherTalk) Spider Systems

Szarka T.

HÁLÓZATOK


Ha a protokoll azonosítót WORD-ben tároljuk, akkor gondoskodnunk kell az alsó és felső bájtok cseréjéről, pl. a 8137H helyett 3781H-t kell egy WORD-ben tárolni! Ez a csere az általunk használt INTEL processzorok esetében szükséges, mert ezekre az ún. kis endian típusú adattárolás jellemző. A kis endian sajátossága, hogy egy több bájtos adatszerkezetnek a legkisebb helyiértékű bájtja kerül az adatszerkezet által elfoglalt memóriaterület legkisebb című bájtjába. A hálózati bájtsorrend nagy endian módon kezeli a szavakat, azaz az alacsonyabb memória címen van a szó nagyobb helyiértékű bájtja. (A MOTOROLA gyártmányú processzorok szintén nagy endian módon tárolják a szavakat, ezért ha APPLE-re fejlesztünk, akkor nincs (ilyen) problémánk, mert a hálózati bájtsorrend megegyezik a hoszt oldali bájtsorrenddel. Elegánsan is megoldható ez a probléma: pl. egy CD-ROM esetén, mindkét alakban rögzítik a vezérlő információkat és lám ezt a médiát mindegyik rendszerben probléma nélkül lehet használni!)

Sokat beszéltünk az Ethernet keretekről, hát pl. az Analyzer67 nevű (free) protokoll analizátor segítségével elkaptuk (capture) egy induló Windows által generált kereteket.

A 3.-ként elfogott keretet vizsgálgatjuk egy kicsit, amelyet az ARP küldött a médiára. (Az ARP-t egy későbbi fejezetben részletesen megvizsgáljuk, most csak annyit érdemes tudni róla, hogy a hálózati réteg kiegészítő protokollja.) Szóval azt láthatjuk, hogy az ARP-ARP virtuális kommunikációt szolgáló keret broadcast célcímet használ, a küldő címével sincs probléma mert unicast. A protokollt azonosító word-őt (0806H) a memóriában az ún. hálózati bájtsorrendben találjuk meg, nem pedig az Intel-es világban megszokott kis endian „system” szerint. (Ehhez a word-ön host order to network order konverziót kellett az ARP-nek végeznie. Ezt mi az előzőekben a word-öt alkotó bájtok felcseréléseként adtuk elő.) Az analizátor egyébként Ethertype-Length lehetőségekből indult ki a harmadik mezőnél, de azt tapasztalta, hogy a mező értéke olyan nagy, hogy nem lehet hossz benne, ezért rájön, hogy típust (protokoll azonosítót) tartalmaz a mező. 67

Használatához a WinPcap packet driver telepítése is kell.

t. okt. 2011

30

Szarka T.

HÁLÓZATOK


ETHERNET SNAP (SUBNETWORK ACCESS PROTOCOL) típusú keret NIC generálja

LLC generálja

LLC PDU (Az LLC kliensétől v. kliensének) MAC fej LLC fej OUI Preamble Cél Adó Hossz DSAP SSAP CONTROL 6 6 2 1 1 1 3 8

LLC gen. SNAP TYPE 2

ADAT 0…1492

NIC gen.

PAD CRC x 4

DSAP=AAH SSAP=AAH CONTROL=03H OUI (Organizationally Unique Identifier) mint protokoll „gyártója”, gazdája=068 TYPE= az ETHERNET II. tipusnál megismert protokoll azonosítók. Az IEEE 802.3 keretben egy kicsit módosult a 802.2 (LLC) betét kialakítása. Az eredetileg DSAP, SSAP, CONTROL bájtok eredeti szerepe megszünt, tartalmuk fixen a következő: AAH, AAH, 03, amely a SNAP típusú keretet jelzi. A SNAP keret újdonsága az, hogy a fenti 3 bájtot követi egy 5 bájtos protokoll azonosító, az IEEE 802.2-ben szereplő, effektíve 7 bites azonosító helyett. (Az viszont nem látszik itt, hogy SNAP útválasztási információt is hordozhat, ami az igazi újdonság.) A SNAP keret a fenti 3 bájt tartalma alapján könnyen megkülönböztethető az IEEE 802.3+IEEE 802.2 típustól. A protokoll azonosító felső 3 bájtján (OUI) általában 0 van, míg az alsó két bájton az ETHERNET II.-ben megismert protokoll azonosítók találhatók. Pl. AA AA 03 00 00 00 08 00 az IP protokoll azonosítója! Pl. AA AA 03 00 00 00 08 93 az Appletalk phase II. protokoll azonosítója! Ha a protokoll azonosítót WORD-ben tároljuk, akkor gondoskodnunk kell az alsó és felső bájtok cseréjéről! Aláhúzva láthatjuk a memóriában (és a médián) kialakítandó bájtsorrendet. (Tehát pl. a 0893H helyett 9308H-t kell a WORD-ben tárolni!).

NOVELL 802.3 (RAW) típusú keret A Novell Netware 3.11 verziója előtt a Novell saját IPX/SPX protokollja használta ezt a kerettípust. Van hossz mezője, viszont nincs 802.2 betétje (nyers≈RAW), ezért nem alkalmas multiprotokollos működésre és megakadályozza azt is, hogy az IEEE 802.3 féle keretekkel együtt használják a hálózatot, ugyanis a két keretformátum nehezen különböztethető meg egyértelműen. Kihasználható az, hogy az IPX fejléc első két bájtja feleslegesen van ellenőrző összeg részére fenntartva, mert a MAC alréteg végez hibadetektálást. Ezért az IPX fejléc első két bájtja FFH-FFH tartalmat is adhat a DSAP és SSAP mezőknek, így lehetőség adódik a keretformátum megkülönböztetésére. (A protokoll azonosító hiánya miatt azonban továbbra is csak egy protokoll használatát teszi lehetővé a keret.) Ethernet keretek összefoglalása: Byte Ethernet II 0-5 Cél cím 6-11 Forrás cím 12-13 Prot. azon. (Type) 14 15 16 17 18 19 20-21 Horváth György, Lanvizs.zip

68

Ethernet-SNAP Cél cím Forrás cím Hossz DSAP (fix AAH) SSAP (fix AAH) Control (fix 03H) Organizációs kód (3 byte)

Novell 802.3 (RAW) Cél cím Forrás cím Hossz

IEEE 802.3 + LLC Cél cím Forrás cím Hossz DSAP (lényegében a Type) SSAP Control-1 (Control-2)

Típus (Type) (MEK)

Pl. 00 00 0C=CISCO

t. okt. 2011

31

Szarka T.

HÁLÓZATOK


A hálózati operációs rendszerek (NOS) által támogatott Ethernet keretek Keret típus: IEEE 802.3+802.2 LLC Ethernet II. 802.3 SNAP Novell 802.3 (RAW)

Novell elnevezése: Ethernet_802.269 Ethernet_II. 70 Ethernet_SNAP Ethernet_802.3

Cisco elnevezés: LLC ARPA SNAP Novell

Novell Netware által támogatott keretek és protokollok: Netware 3.11 előtt: [Ethernet 802.3] (RAW) [Ethernet II.] Netware 3.12 től: [Ethernet 802.3] [Ethernet 802.2 LLC] [Ethernet II.] [Ethernet 802.3] [Ethernet 802.2 LLC SNAP]

Windows elnevezés Ethernet 802.2 Ethernet II SNAP Ethernet 802.3

IPX/SPX TCP/IP IPX/SPX IPX/SPX és TCP/IP IPX/SPX és TCP/IP és AppleTalk

A kliens természetesen mindegyiket támogatja, lásd a NET.CFG load és bind parancsait.

Windows alapú hálózatok: TCP/IP protokoll esetén Ethernet II (DIX Ethernet) típusú keret az alapértelmezett. A registry-ben beállítható 802.3 SNAP keretek adása is, pl. W2000 esetén: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\Parameters alatt létre kell hozni, vagy módosítani kell az ArpUseEtherSNAP bejegyzést, amelynek jellemzői: Value Type: REG_DWORD—Boolean Valid Range: 0, 1 (false, true) Default: 0 (false) A paraméter 1-es értéke esetén a TCP/IP adáshoz 802.3 SNAP típusú Ethernet keretet használ, de vételre továbbra is mindkét keretformátumban képes. NW Link (IPX/SPX kompatibilis Microsoft protokoll) esetén az Ethernet 802.2 (LLC TYPE1) keret az alapértelmezett, de a „protokoll tulajdonságai” menüből bármelyik beállítható. NetBEUI protokoll esetén Ethernet 802.2 (LLC TYPE2) keret használatos. Összefoglalva az eddigieket megállapíthatjuk, hogy az LLC réteg feladata az, hogy a kliens réteg felé egy MAC-tól és annak keretformátumától független, hibamentes adatátviteli szolgáltatást nyújtson a kliens(ek) számára. Az LLC szolgáltatások a MAC alréteg szolgáltatásaira (különböző protokolljaira) épülnek. Az ETHERNET a MAC egyik (CSMA/CD) jellegű realizációja. Az ehhez a MAC protokollhoz használt NIC drájverek általában (pl. IP „alatt”) TYPE I. LLC szolgáltatásokat nyújtanak klienseiknek, azaz nyugtázatlan össszeköttetés mentes szolgálatokat. Láttuk viszont, hogy NetBEUI esetén össszeköttetéses szolgálatokat biztosítanak. Megismertük az ETHERNET hálózatokon használatos négyféle MAC keretet, valamint az ezekben használt MAC és SAP jellegű címeket hordozó mezők tartalmát és ezek szerepét. 2. Adatkapcsolati réteg

LLC MAC

1. Fizikai réteg

69 70

IEEE 802.2 802.3

802.4

802.5

CSMA/CD

Token Bus

Token Ring

DSAP=SSAP=0E0H DSAP=SSAP=0AAH

t. okt. 2011

32

Szarka T.

HÁLÓZATOK


Az ETHERNET kártya ellenőrzése Mielőtt az Ethernet interfészt felhasználnánk célszerű ellenőriznünk a NIC(ek) és a kábelezés működőképességét. Ellenőrzéshez hozzunk létre egy minimális hálózatot, pl. két NIC és egy crossover kábel felhasználásával. Tesztelő szoftver műszerként használjuk a NIC telepítőlemezén található setup jellegű programot, pl. RSET8029.EXE, SET2111.EXE. Valószínűleg más néven, de minden hálókártyához kaptunk ilyen programot... . Az általam vizsgált „Setup And Diagnostics” programok a NIC típusára utaló feliratokat leszámítva a következő módon jelentkeznek be:

Ha lekérjük az aktuális beállításokat, a következőket láthatjuk az ábrán: • A kártya MAC címe • 10 BASE T média csatlakozik a NIC-hez, amely egyébként automatikusan figyeli azt, hogy a csavart érpáras (TP) vagy a koax-os (CX) csatlakozóját veszik-e igénybe. • A kártya képes adásra és vételre egy időben. (Full-duplex üzemmód engedélyezett.) • A kártya báziscíme az I/O címtartományban 6000H • Hardver megszakításhoz az IRQ 10 vonalat használja • 16 KB-os boot EPROM engedélyezve a kártyán. (Ez tévedésből maradt bekapcsolva egy BIOS bővítő EPROM-mal folytatott kísérlet után.)

t. okt. 2011

33

Szarka T.

HÁLÓZATOK


Bizonyos beállítások módosítására lehetőség van:

Tesztelhetjük a kapcsolatban érintett hardvereket. Az egyik kártyát állítsuk be válaszadásra a Run Diagnostics/Run Diagnostics On Network/Set Up As Responder menüvel:

A többi kártyát állítsuk Initiátor üzemmódba és ellenőrizzük az adást (Tx) és a vételt (Rx):

t. okt. 2011

34

Szarka T.

HÁLÓZATOK


Speciális Ethernet keretek Pause Frame (802.3x) Full duplex Ethernet technológiák (FastEthernet, GigabitEthernet) használják adatfolyam szabályozásra (flow control). Pl. számítógép és switch kapcsolatban fordul elő, hogy valamelyik eszköz a vevő pufferének telítettsége miatt pause frame-t küld a linkre, hogy a távolvéget az adásának a szüneteltetésére „rávegye”: Preamble 8

MAC cél 6

MAC forrás 6

Protokoll azon./hossz 2

OpCode 2

Pause Time 2

PAD 42

CRC 4

MAC cél mindig egy speciális multicast cím: 01-80-C2-00-00-01 MAC forrás: a küldő interfész címe Protokoll azonosító: 8808 OpCode: 0001 azaz „pause” Pause Time: ezen paraméter * 512 bit ideje adja a kért várakozási idő nagyságát. Új pause kerettel a várakozás alatt aktualizálható. Pad: 0 értékű kitöltő oktettek VLAN és kiegészítése a Class of Service (802.1q és 802.1p) A korszerű kapcsolók támogatják VLAN-ok kialakítását. Ennek segítségével már az adatkapcsolati rétegben olyan (virtuális) hálózatok hozhatók létre, amelyek között a forgalom csak routeren keresztül jöhet létre. A kapcsoló hozzáférési pontján beérkező keretet a VLAN információkat hordozó Tag-gel egészíti ki, ezért a keret mérete az eredeti Ethernet szabványban engedélyezettnél hosszabb lesz. Ezek kezeléséhez olyan speciális interfészekre van szükség amelyek támogatják a 802.1q keretformátumot (beágyazást). Számítógépek általában nem találkoznak ilyen keretekkel, mert a kapcsoló a eltávolítja a plusz mezőt a címzetthez érkező keretekből. Ha a számítógépet VLAN-ok közötti forgalom irányítóként üzemeltetik, akkor olyan Ethernet adaptert és operációs rendszert kell használni amely támogatja a VLAN kezelést. Preamble 8

MAC cél 6

MAC forrás 6

Tag 4

Eredeti protokoll azon./hossz 2

Eredeti adatok max 1500

Új CRC 4

A keretbe illesztett Tag tartalmazza a kiegészítő információkat. 4 bájtos méretével nő az eredeti keret hossza, így a keret tartalmának változása miatt az ellenőrző összeg újraszámolása is megtörténik. A Tag részletei: Tagged Frame Type 16 bit

802.1p Priority Canonical 3 bit 1 bit

802.1q VLAN ID 12 bit

Tagged Frame Type (Tag Protocol Identifier): 0x8100, 0x9100, 0x9200 értékek valamelyike jelzi, hogy 802.1q és 802.1p jellegű információkat is szállít a keret. A következő 3 mezőből álló csoport a TCI (Tag Control Information): Priority: adatkapcsolati szintű QoS támogatást biztosít: 7: Hálózat vezérlő információk: pl. a RIP, OSPF útválasztási információk 6,5: Késleltetésre érzékeny adatok: pl. video, hang. 4..1: Adatvesztésre kevéssé érzékeny alkalmazások adatai: pl. FTP 0: A hagyományos best effort szolgáltatás Canonical: Ethernet típusú hálózatokban mindig 0 VLAN ID: 0 csak prioritás szintet rendel a kerethez 1..4094: érvényes VLAN ID 4095: foglalt azonosító

t. okt. 2011

35

Szarka T.

HÁLÓZATOK


Az adatkapcsolati réteg összefoglalása az Ethernet technológia alapján Az OSI modell szerinti második réteg az adatkapcsolati réteg (Data Link Layer). A réteg általános feladata, hogy egy adott médiára (pl. kábelre) kapcsolódó készülékek közötti adatátvitelt segítse. Valamelyik gép L3 rétegében implementált protokoll szeretne beszélgetni egy másik gép L3 szintű protokolljával. Ez lehet pl. ARP-ARP, IP-IP, stb. közötti virtuális kommunikáció, de tudjuk, hogy ez csak azonos tipusú protokollok között lehetséges, mert ők értik egymás nyelvét. Az L3 protokollokat megvalósító programok (folyamatok) beregisztrálják magukat az Ethernet kártya (NIC) driverénél. A regisztráció során létrejönnek szolgáltatás elérési pontok (SAP-ok), amelyeket lényegében a protokoll azonosítók különböztetnek meg egymástól. Minden regisztráló folyamat az általa megvalósított protokoll azonosítóját fogja használni. Az már csak részletkérdés, hogy az azonosító 1 vagy 2 bájtos, amint a különböző keret típusoknál megfigyelhettük. Amikor az ARP üzenetet szeretne küldeni a másik gépen lévő társának, akkor meghívja a NIC driverének “keret_küldés” függvényét (szolgáltatását) és paraméterként átadja számára a megfelelő paramétereket: a cél és küldő gép MAC címét, valamint a küldendő adatokat. A NIC driver ezen adatok alapján összeállítja a küldendő keret bájtjainak tartalmát és utasítja a hardvert, hogy küldje el a keretet. A kártyába beépített CSMA/CD MAC algoritmus megvizsgálja, hogy a média adásra használható-e és a megfelelő pillanatban megkezdi az adást. Az adás alatt a keretet alkotó bitek valamilyen vonali kódolással jutnak a médiára. (A NIC a vevők működését segítendő, kezdő és végjellel is ellátja a bitfolyamot.) A médián megjelenő biteket a hálózat jellegétől függően minden gép hallja (busz topológia vagy hub használata esetén), vagy csak a címzett hallja, ha kapcsolt a hálózat. (Kapcsolt hálózatban az elárasztásos továbbítás is árnyalja, hogy kik hallják az adást.) Az adást halló NIC hardverek kezdik a hallott bitekből felépíteni a keretet a saját memóriájukban. Megvizsgálják, hogy a vett célcím egyedi-e, ha igen akkor csak abban az esetben folytatják a keret felépítését, ha ez a cím a saját MAC címük (vagy a NIC hardver promiscuous módban van). Ha a vett célcím broadcast jellegű akkor feltétel nélkül folytatják a vételt, illetve multicast cím esetén akkor folytatják, ha a NIC-nek van olyan MAC címe amely az adott csoportba tartozik. A keret beérkezett a vevőhöz akkor ellenőrzi, hogy hibátlan-e a vett keret. Ehhez a keret utosó mezőjét a CRC-t használja. Hiba esetén a keretet eldobja és a további lépések attól függnek, hogy az LLC milyen változatát használjuk. A mi hálózatainkban általában nem LLC tipusú (pl. Ethernet II) vagy legfeljebb LLC TYPE1 keretekkel dolgozunk, ezeknél semmi sem történik a keret eldobásán kívül. Tehát nincs hibajelzés vagy törekvés a hiba javítására az L2 szintjén, más megfogalmazásban az L2-L2 virtuális kommunikációja összeköttetés mentes átviteli szolgáltatást biztosít L3 számára. Ekkor legfeljebb feltételezhetjük, hogy L3-L7-ben valahol észreveszik a keretben lévő adatmező tartalmának elvesztését és ha indokoltnak tartják akkor valamit tesznek a hiba következményeinek elhárítására. A mi TCP/IP alapú hálózatainkban az L4-ben implementált protokolltól függ, hogy zavarja-e a hiba és ezért törekszik az

t. okt. 2011

36

Szarka T.

HÁLÓZATOK


elveszett adat pótlására (TCP), vagy nem zavarja az elveszett adat, ezért semmi sem történik (UDP). Az L4-ben használt protokoll tehát attól függ, hogy milyen átviteli szolgáltatást (összeköttetéses, azaz TCP-vel megvalósítottat) vagy összeköttetés mentest (UDP-vel megvalósítottat) kér L4-től egy L5-L5 kommunikációra készülő protokoll. Ha az alkalmazás nem kér összeköttetéses szolgáltatást, de az átviteli hibák zavarják, akkor az alkalmazásnak magának kell gondoskodni ezek kezeléséről. A programozók számára nyilván általában egyszerűbb, ha a mások által megírt OS protokoll vermétől kérik összeköttetéses átviteli szolgáltatást, mint hogy ők mégegyszer készítsenek valami hasonlót… . Ha a hálózat tervezője az (Internet működésétől eltérően) fontosnak tartja, hogy már L3-L3 kommunikációja számára összeköttetéses kapcsolat álljon rendelkezésre, akkor olyan protokollt választ L2-be(n), amelyik ezt biztosítja. Ekkor az L2-L2 kommunikációjában plusz információkra is szükség van pl. elküldött keretek azonosítására, visszajelzésre, stb. ezért van az LLC TYPE 2 keretformátum.

Demultiplexer funkció. Akármilyen szolgáltatást nyújtson is L2, rendelkeznie kell azzal az (LLC) képességgel, hogy a vett keretek adatmezőjének tartalmát a keret fejrészében (type vagy dsap mezőben) meghatározott protokollnak (folyamatnak) adja át. Az adatkapcsolat rétegben dolgozó protokollok a fenti feladatokat különböző módon és mértékben valósíthatják meg. Például a LAN technológiákkal foglalkozó IEEE 802 számú szabvány az adatkapcsolati réteget a következő két alrétegre bontotta: • logikai-kapcsolat vezérlő (Logical Link Control, LLC) alréteg • közegelérést-vezérlő (Media Access Control, MAC) alréteg (opcionális szerepű) A MAC alréteg az üzenetszórást használó média (csatorna) pl. Ethernet hálózat esetén jut szerephez azzal, hogy szükség esetén pont-pont jellegű kapcsolatot hoz létre, míg egy eleve pont-pont kapcsolatot biztosító csatorna (pl. modem) esetén elég csak az LLC megvalósítása. Két gép hálózati protokollja közötti adatcsomag egy keretben (frame) jut át a hálózaton: Hálózati réteg

Hálózati protokoll

Adatkapcsolati réteg

LLC protokoll

Fizikai réteg

CSOMAG LLC

CSOMAG

MAC protokoll

MAC LLC

CSOMAG

Média

pl. elektromos jelek

MAC

Amikor például az Ethernet hálózatok jellemzőit és működését vázoljuk, akkor tulajdonképpen az IEEE 802.3 (CSMA/CD) szerinti MAC protokoll és az IEEE 802.2 szerinti TYPE I. LLC protokoll egy realizációját ismertetjük. Maga a hálózati kártya (NIC) az IEEE 802.3, a kártya driver pedig az IEEE 802.2 ajánlás megvalósítása. Megjegyzés: ha Ethernet helyett más pl. V.24, V.35, stb interfészeket használunk, akkor a pont-pont jellegű technológia miatt nincs szükség a MAC alréteg szolgáltatásaira: a közeget nem kell „megszerezni” és a közegen megjelenő jelsorozat mindig az egyetlen vevőnek szól. Visszatérve az előző példájára az adó LLC szintű protokolljának az a feladata, hogy (támaszkodva a MAC alréteg és a fizikai réteg szolgáltatásaira) a vevő LLC protokolljával együtt kiszolgálja a kliensek, pl. a hálózati protokollt megvalósító folyamatok közötti adatátviteli igényt. Ennek során az LLC-LLC közötti virtuális kommunikációt ún. keretek (frame-k) reprezentálják, amelyek továbbítása az alsóbb rétegek által biztosított fizikai kommunikáció során valósul meg.

t. okt. 2011

37

Szarka T.

HÁLÓZATOK


Az egyes rétegek (most konkrétan az LLC alréteg) által nyújtott szolgáltatás jellege lehet: •

Összeköttetés mentes (nyugtázatlan) szolgáltatás: az egymást követő kereteket egymástól függetlenül küldik. A küldő LLC számára nem derül ki, hogy a küldött keret hibamentesen megérkezett-e. Az esetleges hibák kezelése a felsőbb rétegek feladata.

•

Összeköttetés mentes (nyugtázott) szolgáltatás: hibamantes átvitelt valósít meg a megérkezett keretekről küldött nyugta segítségével.

•

Összeköttetéses szolgáltatás: a keretek küldését az adó és vevő közötti egyeztetési folyamat előzi meg. Ennek során megbízható kapcsolat (összeköttetés) jön létre az adó és vevő között. Nyugtázás, sorszámozás és újraküldés segítségével garantálja a szolgáltatás, hogy a küldési sorrenddel megegyező sorrendben érkeznek meg a keretek.

Üzenetszórásos technológiák általában összeköttetés mentes szolgáltatást nyújtanak TCP/IP protokoll verem esetén: • Token Ring hálózaton nyugtázott összeköttetés mentes kapcsolat van a NIC-ek között. • ETHERNET kártyák általában nyugtázatlan összeköttetés mentes kapcsolatban állnak egymással. Összefoglalás összefoglalása, L2 főbb feladatai: Keretképzés: az L3adataiból képzi, ill. a fizikai bitfolyamból felismeri. Kiválasztja, hogy ki adhat a médián. (Ethernet MAC: CSMA/CD) Kiküldi és veszi a keretet reprezentáló bitsorozatot. (Valamilyen vonali kódolással.) MAC cél alapján az adást halló gépek közül eldönti, hogy ki a vevő. Demultiplexer funkció: a vevő gépen vett keret adatmezőjének tartalmát a keret fejrészében meghatározott folyamatnak adja át. • Hibavédelem: küldendő adatok kódolása, hogy az esetleges hiba detektálható legyen. Nyugták generálása, fogadása. (Ez utóbbiak Ethernetnél általában nem jellemzőek.) • Adatfolyam vezérlés (flow control, forgalom szabályozás, hand-shake): az adás sebességét a vevő feldolgozási sebességéhez igazítja. (Pause frame) • Kapcsolat menedzselése: az összeköttetés létrehozása, a kapcsolat jellemzőinek egyeztetése, kapcsolat lebontása. (Ethernetnél általában nem jellemzőek.) • • • • •

t. okt. 2011

38

Szarka T.

HÁLÓZATOK


AZ RS 232 INTERFÉSZ A számítógépek és a hozzájuk kapcsolandó perifériák közötti kapcsolattartás egyik lehetséges eszköze a soros interfész (interface). Az interfészek különböző specifikációkkal írhatók le. A mechanikai specifikáció pl. az, hogy DB 25 típusú csatlakozót kell használni, a DTE készüléken apa, a DCE készüléken pedig anya kialakításban. A villamos specifikáció szerint a –3V..-25V közötti feszültség logikai 1-et, míg a 3V..+25V közötti feszültség logikai 0-t reprezentál. A DTE és DCE között max. 20 Kbs adatátviteli sebesség megengedett, egy legfeljebb 15m-es kábelen. A funkcionális leírás a 25 vezeték szerepét, elnevezését rögzíti. Az eljárás specifikáció az előbbi eszközökkel megvalósított kapcsolat logikai szervezését (a protokollt) adja meg. (Az interfész elnevezést gyakran csak a fizikai kapcsolódási felületre, -a dugóra és az aljzatra- értik). A PC soros interfésze nagyjából megfelel az RS 232 amerikai, illetve a V.24 európai szabványnak, ill. mai elnevezéssel EIA/TIA-232 szabványnak. A szabványos és elterjedt interfészeknek, pl. olyan előnye van, hogy az egyféle hardver kialakítással legyártott perifériát bármilyen, az adott interfésszel rendelkező számítógéphez lehet csatlakoztatni. Például ha olyan egeret gyártunk, amelyiket egy elterjedt interfésszel szereltünk fel, akkor sok számítógéphez használhatják termékünket. Más megközelítést használnak a gyártók amikor saját interfészt alkalmaznak, hogy csak a saját gyártású kiegészítők legyenek kapcsolhatók pl. egy mobil telefonhoz.

Az interfész tehát egy célszerű, hardver és protokoll szintű kapcsolódási felület számítógépek és a perifériák között az adatcsere érdekében. ASZINKRON SOROS ADATÁTVITEL Az adatforgalom az RS 232 típusú interfészen keresztül sorosan történik, tehát egy adatbájt bitjei időben elkülönítve, (egymás után) jelennek meg a vezetéken. Az időbeni elkülönítés az adatbájt átviteléhez szükséges időt ugyan megnöveli, viszont minden adatbit ugyanazon a vezetéken „halad”, így a kapcsolat fizikai kialakítása (a kábel) olcsóbb, mint egy párhuzamos kapcsolatban. Az aszinkron jelző arra utal, hogy az adatbájtok között tetszőleges időtartam lehet, viszont egy szinkron rendszerben nemcsak a karaktereket felépítő bitek időtartama rögzített, hanem a karakterek adási időpontja is. A rendszer képes időben egyszerre adni és venni (ún. duplex üzemmód), természetesen ehhez két különböző vezetéket használ. Szükséges még egy közös vezeték (a GND vagy magyarul „föld”) is a kommunikációhoz, amelyhez képest értelmezik a feszültségszinteket. A logikai 1 (HIGH vagy MARK) bitértékhez –3V…-25V feszültségtartomány tartozik, míg a +3V…+25V a logikai 0 (LOW vagy SPACE) bitértéket reprezentálja71 fizikai szinten (a vezetékeken) az RS 232 C kódolás szerint:

A előbbi ábrán egy adatbájt továbbításának időbeli folyamatát látjuk az adatvezetéken. (Természetesen a bájt fizikailag nem megy sehová, mert az adó csak meghatározza a vezeték állapotát, a vevő pedig leolvassa ezt az állapotot). Az adatvezeték (TxD) alaphelyzetben logikailag magas szinten van. Az adás kezdetén az adó egy startbittel értesíti a vevőt az adás megkezdéséről (szinkronizálás). A vevő ennek hatására felkészül a startbit után érkező adatbitek fogadására. Először a D0 adatbit kerül adásra, így a vevőbe ez „érkezik meg” elsőnek, majd a többi adatbit kerül sorra. Az adatbiteket egy hibadetektási célú ún. paritásbit követheti, majd egy stopbit zárja az adatbájt átvitelét. Látszik, hogy a vevőnek pontosan ismernie kell azt, hogy az adó éppen melyik bitet küldi, ezért a kapcsolat kialakítása előtt az 71

A logikai 1 elnevezése az RS 232 szerint mark, a logikai 0 pedig space.

t. okt. 2011

39

Szarka T.

HÁLÓZATOK


adóval meg kell állapodnia az átvitel jellemzőiről. Ezt a megállapodást a kommunikációs programok készítői is „megköthetik”, amint az a példákból majd később kiderül. A megállapodás a következő adatátviteli jellemzőket érinti: 1. Adatátviteli sebesség (bit-rate, Baud-rate). Egy bit átvitelének idejével van kapcsolatban. Alapvetően ez határozza meg az adó és a vevő szinkronizmusát, tehát ha az adó úgy tudja, hogy pl. a D1 adatbitet adja, akkor a vevő ezt szintén D1 adatbitként értelmezze. A tipikus adatátviteli sebesség 150 bit/sec-tól 38400 bit/sec-ig terjed. Figyeljük meg, hogy a különböző célú bitek adási ideje megegyezik, pl. 150 bit/sec esetén 6,666 ms. 2. Adatbitek száma. A gyakorlatban 5, 6, 7 vagy 8 bitet használnak. 3. Paritásbit, használatával egy egyszerű hibadetektálási lehetőséget kapunk. Hátránya, hogy csak speciális esetekben képes bitsérülést jelezni. Ha egyáltalán használják, akkor páros paritást vagy páratlan paritást lehet beállítani. A páros paritás azt jelenti, hogy az adatbájtban elküldött logikai 1-es bitek számát a paritásbit párosra egészíti ki és a vevő ezt ellenőrzi. (A paritásbit elhagyásakor D7 után a STOP bit következik.) 4. Stopbitek száma. A gyakorlatban 1, 1.5, 2 bitet használnak. A vevőnek minimum ennyi ideje van a következő bájt vételére felkészülni, azaz a következő startbit minimum ennyi idő múlva érkezik. Amennyiben az adó később küldi a startbitet azzal nem okoz problémát. Példa: az ’E’ karakter ASCII kódját (45H=0100.0101B) küldjük 19200 bit/sec (bps) adatátviteli sebességel. Feltételezzük azt, hogy ebben a kapcsolatban a kibővített ASCII karakterkészletet használjuk, amelyben a kódok 0-255 közöttiek, ezért 8 adatbit szükséges. A példa kedvéért páros paritást választottunk és egy stopbitet. Az alábbi diagram a bitek logikai értékét mutatja az idő függvényében, nem pedig a vezetéken lévő feszültséget.

A diagramon nem látszik, de egy bit ideje egységesen 0,0521 msec. Az adatátviteli sebesség karakter/secundum-ban (cps) is megadható. Jelen példában minimum 11 bitnyi idő kell egy karakter átviteléhez, tehát 19200/11=1745 cps az adatátviteli sebesség. Ez növelhető, pl. a paritásbit elhagyásával 1920 cps-ra. Szintén növelhető a cps értéke, ha csak normál ASCII kódú (0-127) karaktereket továbbítunk, mert ilyenkor 7 adatbit is elég. A következő ábrán72 egy 4BH értékű bájtot reprezentáló feszültség alakja látható. Ha ASCII kódtáblát használunk, akkor ez a ’K’ betűt jelenti. A következőkben egy eléggé általános esetet vizsgálunk, ahol az RS 232-es soros interfész egy számítógépet és egy modemet kapcsol össze. Mindkét egységnek van egy-egy RS 232-es interfésze. A modem arra szolgál, hogy néhányszor tíz méternél távolabbi számítógépek között is tudjunk kapcsolatot kialakítani. Az adatcsere a számítógépek számára érthető logikai feszültségszintek helyett hangfrekvenciás jelekkel zajlik az (analóg) modemek között, ezért alkalmas egy normál telefonvonal vagy rádiócsatorna az információ kétirányú 72

http://en.wikipedia.org/wiki/File:Rs232_oscilloscope_trace.svg

t. okt. 2011

40

Szarka T.

HÁLÓZATOK


átvitelére. A modem alapfeladata a logikai feszültségszintek hangfrekvenciás jelekké alakítása (modulátor funkció) és a fordított irányú átalakítás (demodulátor funkció). Tehát a modemünk hangfrekvenciás jelekké alakítja az adatbájt bitjeinek logikai értékét, így pl. nem logikai nullát (pl. +10V-ot) küld egy műholdra, hanem egy rádió csatornán a logikai nullát reprezentáló, pl. 1000 Hz-es hangfrekvenciás jelet. (Mindkét modem adhat egyszerre a vonalon, ha adásukban az azonos logikai szinteket különböző frekvencia reprezentálja.) Ma már ritka eset az, hogy a modemünk telefonvonalon hangfrekvenciás kapcsolatba lép, pl. az Internet szolgáltatónkkal. A szolgáltatónknál egy másik modem a hangfrekvenciás jeleket logikai szintekké alakítva, azokat egy interfészen keresztül átküldi a szervernek. Napjaink ISDN vagy GSM vonalain való adattovábbításhoz nincs szükség modulációra, ezért terminál adapternek (TA) nevezik az „ISDN modemet”. A fő témánkat ez most nem érinti, mert egy ISDN terminál adapternek is lehet RS 232 interfésze vagy hasonló a helyzet a mobiltelefonok esetében, amelyekkel külön fejezetben foglalkozunk. Az alábbi ábrán négy darab interfész látható. Az interfészek között feltüntettük a főbb interfész funkciók rövidített elnevezését: (Az elnevezések nem az összekötő vezetékekhez tartoznak, hanem az interfészek csatlakozó pontjaihoz.)

Természetesen a szabvány konkrét készülékek helyett általánosabban fogalmaz, mert csak a napi gyakorlatra gondolva sem mindig modemet csatlakoztatunk számítógéphez az RS 232 interfész segítségével. A szabványos elnevezése a fenti készülékeknek: DTE – Data Terminal Equipment (adatvég-berendezés, pl. a PC). DCE – Data Circuit Terminating Equipment (adatáramköri-végberendezés, pl. a modem).

t. okt. 2011

41

Szarka T.

HÁLÓZATOK


Az interfész funkciókat, egy DTE (amely SW és HW komplexum) így értelmezi: Név: Adója D 9

RxD

TxD

DCE

DTE

2

3

D 25

Funkció:

3

Received Data. Vételkor a soros adat erre a pontra „érkezik”. Programozási szempontból a beérkezett karakter a DTE vevőadatregiszterében érhető el. Érkezéséről a port vonali státus regisztere informál.

2

Transmitted Data. Adáskor a soros adat ezen a ponton „lép ki”a DTE adó-léptetőregiszteréből. Programozási szempontból az adó átmeneti regiszterébe írjuk a kiküldendő karaktert, amelyből automatikusan átkerül a léptetőregiszterbe, ha az kiürült az előző karakter elküldését követően. Az átmeneti regiszterbe akkor írhatunk, ha a port vonali státus regiszterében a megfelelő státuszbit engedélyezi.

RTS

DTE

7

4

Request to Send. A hardveres handshake egyik „ága” amelyen a DTE jelzi, hogy szeretne adatot küldeni DCE-nek. Ez és az alábbi funkciók programozási szemontból a port modem státusz regiszterében érhetők el.

CTS

DCE

8

5

Clear to send. A hardveres handshake másik „ága”, amelyen a DCE jelzi, hogy kész a DTE által küldendő adatokat fogadni. (Az RTS-CTS pár félduplex kapcsolat esetén az irány kijelölésére is használatos.)

DTR

DTE

4

20

Data Terminal Ready. DTE jelzi a DCE-nek, hogy bekapcsolták. Nyilván azért kapcsolták be, mert rövidesen szükség lesz a DCE szolgáltatásaira.

6

Data Set Ready. Válasz a DTR jelre. Ezzel a DCE jelzi DTE-nek, hogy be van kapcsolva. Modem esetén ekkor már küldhetjük számára a modemvezérlő karakter-sorozatokat. Pl. lépjen a vonalra (vegye fel a kagylót), tárcsázzon, adjon válaszjelet és várjon a hívott állomás vivőjére, stb. Data Carrier Detect vagy Received Line Signal Detector. DCE jelzi, hogy a másik DCE-vel kialakította a kapcsolatot. A modemek közötti kapcsolat kialakítása több szervíz jellegű üzenetváltással jár. Ezek az üzenetváltások a közeli és a távoli modem belső számítógépének operációs rendszere által vezéreltek, így nem érintik közvetlenül az RS 232 interfészt. A modem bizonyos beállítása esetén a hangszórója közvetíti ezt az üzenetváltást, amelyet népiesen összefütyülésnek nevezünk. A modemek közötti sikeres kapcsolat kialakítása esetén a modemek a DCD-vel jeleznek a DTE-nek. A jelzésnek egy olyan értelme is van, hogy a modem az eddigi parancs üzemmódból adat üzemmódba kapcsolt át. Ilyenkor a DTE által a modemnek küldött adatokat már nem parancsként értelmezi a modem, hanem továbbítja a távoli modemnek. Ún. ESCAPE szekvenciával a modemet visszakapcsolhatjuk parancs üzemmódba, de a DCE-DCE kapcsolatot ettől még nem bontja le (van DCD jel), csak ha egy speciális karakter sorozatot (sztringet) küldünk neki.

DSR

DCE

6

DCD vagy RLSD

DCE

1

8

RI

DCE

9

22

Ring Indicator. A közeli modem ezzel jelzi a közeli DTE-nek, hogy a távoli modem hívja a közeli modemet. A továbbiakban a driver program dönt arról, hogy a közeli modemet a vonalra lépteti-e.

GND

-

5

7

Ground. Közös pont. Az eddigi funkciók feszültség szintje ehhez a ponthoz viszonyítva értelmezendő.

(D9 vagy D25 típusú csatlakozót használnak.)

t. okt. 2011

42

Szarka T.

HÁLÓZATOK


Handshake Az interfészek segítségével végzett kommunikáció általában az RxD-n vett, illetve a TxD-n adott adatfolyamon túl, az azt szabályozó vezérlőjeleket is igényli. A DTE és DCE közötti optimális adatáramlás általában egy bonyolultabb egyeztetési folyamattal tartható fenn. Az egyeztetés egy „kézfogásos” (handshake) protokoll alapján, a vezérlő vezetékek felhasználásával történik. A handshake protokoll mögött olyan igények vannak, amelyek szeretnék az adatok áramlását szabályozni (flow control). Néhány példa ezekre: • Egy ún. fél-duplex összeköttetés esetén (az ilyen kapcsolatban egy adott időpontban csak az egyik modem adhat a vonalon) az adó és a vevő modem kijelölésére használhatjuk. • A modem működése közben fontos esemény lehet, pl. a modem adó pufferének kiürülése, amit a modem a CTS „megemelésével” jelez a számítógépnek. A számítógép ezt interrupt (megszakítás) kérésként érzékeli és a modem drivernek az adásért felelős (egyébként interrupt típusú) eljárása által kiküldendőnek tartott karaktereket átküldi a modemnek. A modemen belül az adó részhez rendelt pufferben raktározódnak ezek a karakterek. Amikor a puffer nem képes több karaktert fogadni (megtelt), akkor a modem az CTS-t alacsonyra állítja, ezzel értesíti a számítógépet arról, hogy ne küldjön több adatot a pufferbe. A modem driver adásért felelős eljárása egy időre elvégezte a feladatát és az OS-hez visszakerül a vezérlés. Itt most rövid kitérőben azt tekintjük át, hogy a programozó miként láttatja programjával a handshake jeleket: az előbbi megszakításos adatforgalom szervezési módszer mellett gyakori még az ún. lekérdezéses (polling). Ekkor, a driver program az adás alatt rendszeresen vizsgálja a CTS állapotát, ezért a számítógép más feladatot körülményesebben tud végezni. Amennyiben ezzel a „más feladattal” is megbízzuk nem biztos, hogy fenn tudjuk tartani az adás folyamatosságát a puffer átmenetileg észrevétlen kiürülése miatt. A harmadik adatforgalom szervezési módszer DMA jellegű átvitelt használ. Nagy adatmennyiségek rendkívül gyors átvitelére alkalmazzák. A PC-k RS 232-es interfészénél nincs erre szükség, de a gyorsabb párhuzamos (nyomtató) portoknál megtalálható.

A következő ábrán egy gyors RTS-CTS (tehát hardver) handshake-et használó általános változatot láthatunk a soros interfész kézfogási protokolljából DTE-DCE kapcsolat esetén. A példában a DTE felépíti, majd lebontja ezt a kapcsolatot, de közben egy ’E’ karaktert átküld a DCE-nek. (Általános példa, mert ez a DCE bármi lehet.) A DTE és DCE kapcsolatban az azonos nevű pontokat kell összekötni a kábellel. Műszakilag fontos, hogy amíg pl. a DTE készülék DTR pontja kimenet, addig a DCE egység DTR pontja bemenet! Az általános után egy magyarázat modemes „felhangokkal”, amelyben a helyi számítógép (h_szg) fog adni a távoli számítógép felé. A h_szg szeretné a soros vonalat használni, ezért bekapcsolja a DTE egységét. Ezt a bekapcsolást a DTR lábon jelzi a h_modemnek. A h_modem a DSR jelű vezetékével szól vissza, ha be van kapcsolva. Ekkor speciális modem parancsokkal a h_szg a h_modemet „ráveszi”, hogy lépjen a vonalra és „tárcsázzon”. (Állandó kapcsolatnál (bérelt vonalnál) a tárcsázás elmarad, mert a vonal másik végén mindig a hívandó t_modem van). A t_modem érzékeli a csengetést és ezt RI jelzi a t_szg-nek (DTE-nek). RI hatására a t_szg-n futó driver a t_modemet „ráveszi”, hogy lépjen a vonalra. Ha a t_modem „felvette a kagylót”, akkor a modemek hangfrekvenciás jelekkel „megkeresik” (összefütyülik) egymást. Az egyezkedésük után a modemek DCD-vel jelzik a számítógépeknek, hogy van kapcsolat a modemek között. A DCD-k megjelenése után már beérkező karakterekre számíthatunk számítógépek RxD pontján. (A példában csak a t_szg RxD pontján várható karakterek megjelenése, amelyek a h_szg és h_modem adásából származnak.) A h_szg a DCD-t érzékelve az RTS t. okt. 2011

43

Szarka T.

HÁLÓZATOK


megemelésével jelzi az adási szándékát. Amikor erre válaszul a h_modem a CTS-t megemeli, akkor a h_szg a TxD pontján megkezdi a karakterek küldését h_modemnek. A h_modem által a vonalon továbbított jeleket t_modem demodulálja és az RxD pontján át t_szg RxD pontjára küldi. A kapcsolat bontásához a modemeket egy ún. ESCAPE karaktersorozattal érzékennyé kell tenni a modemparancsokra, amelyekkel a kapcsolat bontása kezdeményezhető. Lehetőség van arra is (megfelelő meghajtóprogramok és modemek esetén), hogy egyszerre adjon mindkét modem. A mai otthoni modemeink erre az ún. duplex adatátvitelre is képesek, tehát egy telefonvonalon egyidőben tudnak adni és venni. Az RTS-CTS vezetékpárt karakterekkel is helyettesíthetjük (szoftveres handshake), ha a modem és a számítógép meghajtóprogramja egyaránt alkalmas arra, hogy speciális vezérlőkarakterekkel oldja meg a kézfogási folyamatot. Ilyenkor, ha a modem képes az adatokat fogadni (tehát CTS=1 lenne), akkor a DTE RxD vezetékén XON karaktert küld a driver programnak. Amikor a modem adási puffere73 megtelik, akkor egy XOFF karakterrel kéri a számítógép meghajtóprogramját a „töltés” megszüntetésére. A hadshake másik ágát, a számítógépből érkező RTS jelet pedig a TxD vezetéken a modemnek küldött XON (ASCII 17) és XOFF (ASCII 19) karakterek helyettesítik, azaz a számítógép is képes jelezni a modemnek, hogy tud-e adatot fogadni A megoldás hátránya, hogy a relatíve kicsi adatátviteli sebességet még tovább csökkentik a vezérlő karakterek, ráadásul csak szöveges állományok átvitelekor használható a módszer, mert abban nem fordulnak elő ilyen speciális vezérlő karakterek. Bináris állományok átvitelekor hardveres flow control-t kell használni vagy valamilyen fájl átviteli protokollt, pl. Xmodem, Zmodem, FTP, stb.

Null modem A közeli (max. néhány 10 méterre lévő) számítógépek összekapcsolásához nincs szükség modemre, mert az RS 232-es interfészekkel ezek a rövidebb távolságok közvetlenül is áthidalhatók. Az ilyen „null modemes”, azaz DTE-DTE öszeköttetéseknek különböző kialakítási lehetőségei vannak. Az interfészek különböző összekötési módjai és a különböző protokollok közötti választás során ezek együttműködési képességére is figyelemmel kell lenni. Gyakoribb null modem huzalozási változatok:

Figyeljük meg, hogy a közeli DTE TxD pontja egy vezetékkel a távoli DTE RxD pontjával van összekötve, mert műszakilag egy kimenetet (általában) csak egy bemenettel lehet összekötni. A háromvezetékes rendszerben legfeljebb szoftveres handshake-et lehet használni az adatáramlás vezérlésére. A belső hurkos kialakításnál a DTE azonos felső indexű pontjai nem kapcsolódnak a másik DTE-hez, mert csak helyben vannak összekötve egymással. Az ilyen huzalozást használó interfész valójában becsapja a kézfogásos folyamatot „kézbentartó” meghajtó programot. Látható, hogy a huzalozás és a meghajtó program protokollja között szoros kapcsolat van. 73

Az adó puffer pl. azért kell, mert a modem nem képes a vonalra olyan sebességgel kiküldeni a karaktereket, ahogyan az interfészen át érkeznek. A processzor a puffer feltöltése után más feladatokkal foglalkozhat, ezzel „magára hagyja” a modemet, amely majd a saját tempójában vonalra küldi a puffer tartalmát. A mai modemeknél ez érdekes terület, mert a modem számítógépe adattömörítést végez(het), így pl. 33600 bps vonali adatátviteli sebesség mellett a soros interfészen esetleg 90000-115200 bps-os adatátviteli sebességre is szükség lehet a folyamatos adáshoz.

t. okt. 2011

44

Szarka T.

HÁLÓZATOK

ADATKAPCSOLATI RÉTEG Pont-pont kapcsolatok keretformátumai

Az előző részben megismertük az üzenszórásos csatornán, pl. az Ethernet hálózatokban használatos kereteket. Pont-pont jellegű kapcsolatban más keretformátumok terjedtek el. HDLC (High-Level Data Link Control) Ez az egyik jelentős protokoll74 mely összeköttetéses kapcsolatot nyújt. A HDLC a hibajavítást és adatfolyam vezérlést nyugtázással oldja meg. A nyugtázás hatékonysága és az adatfolyam vezérlés érdekében csúszóablakos eljárást használ. A HDLC keretek formátuma (FORRÁS: WWW.LINUXVILAG.HU/CONTENT/FILES/CIKK/44/CIKK_44_65_68.PDF ): Az eredeti HDLC keret nem tartalmaz protokoll azonosító mezőt, ezért csak egyféle protokoll adatait képes szállítani. Különböző továbbfejlesztések jelentek meg, pl. a CISCO által kifejlesztett (és a routerekben alkalmazott) változat már képes többféle hálózati rétegbeli protokoll szállítására. A HDLC-hez hasonló, de más technológiákhoz optimalizált protokollok (http://bmf.hu/users/beinschrothj/Infokomm_halozatok/):

• • • • • • •

HDLC: High-level Data Link Control (ISO) SDLC: Synchronous Data Link Control (IBM) LAPx: Link Access Procedure (CCITT–ITU T) LAPB: Link Access Procedure Balanced LAPD: Link Access Procedure on D channel (ISDN) LAPF: Link Access Procedure FR (Frame Relay) LAPM (Link Access Procedure for Modems)

PPP (Point to Point Protocol) Szintén a HDLC továbbfejlesztésével keletkezett. Szolgáltatásai miatt az Interneten elterjedten alkalmazzák. Két alprotokollból áll: LCP: feladata a pont-pont összekötés létrehozása az adatkapcsolati réteg szintjén. A kapcsolatot konfigurálja és teszteli. Egyéb szolgáltatásokat is megvalósíthat: • • • •

Hitelesítés (pl. PAP, CHAP) Tömörítés Hibafelismerés Multilink75 PPP

• PPP visszahívás • Kapcsolat megszakítása NCP: feladata a különböző hálózati protokoll (pl. IP) beágyazása és konfigurálása, hogy a PPP kapcsolaton átvihető legyen az adatcsomag. Minden L3 protokollhoz külön hálózati vezérlő protokoll tartozik, pl. az IP-hez IPCP, amelynek feladata pl. az IP cím beállítása a végponton vagy a DNS szerver címének megadása, stb.

74

www.linuxvilag.hu/content/files/cikk/44/cikk_44_65_68.pdf HYPERLINK "http://www.linuxvilag.hu/content/files/cikk/44/cikk_44_65_68.pdf" vehok.uni-pannon.hu/~brios/jegyzet/Szamitogep%20halozatok%20jegyzet/X25.doc 75 Pl. az ISDN BRI két B csatornájának nyalábolása (akár dinamikusan is) terhelésmegosztás céljából.

t. okt. 2011

45

Szarka T.

HÁLÓZATOK


Egy lehetséges forgatókönyv a PPP működésére A PPP először a tárcsázó jellegű démont indítja, amely létrehozza a fizikai szintű kapcsolatot a két végpont között. Amikor a modemek konnektálnak akkor indul az LCP szintű egyeztetés. Ehhez mindként végpont LCP kereteket küld terhelési és egyeztetési céllal. Kezdetben a PPP Link-Dead állapotú. A modemek konnektálása után Link-Establishment állapotba kerül. Ezután konfigurációs kereteket küldözgetnek. Ha ez sikeres volt, akkor LCP-Open állapotba kerül a PPP. Ezt követi az opcionális azonosítási (általában PAP vagy CHAP) folyamat. Végül az NCP egyeztetési folyamat után használható lesz a kapcsolat. A kapcsolat bármikor megszakítható LCP vagy NCP segítségével, ill. megszakad a vivő elvesztésekor, azonosítási hibánál, a link minőségének romlásakor vagy huzamosabb ideig inaktív link esetén. A PPP kapcsolat kiépítésének fázisai:

forrás:

http://www.tcpipguide.com/free/t_PPPLink SetupandPhases.htm A továbbiakban mi az authentication (hitelesítés) opcióval foglalkozunk. A hitelesítés célja, hogy a linken összeköttetést létrehozni szándékozó készülékek egyike (vagy mindegyike) tudjon arról, hogy kivel épít ki (és tart fenn) kapcsolatot. Pl. egy Internet Szolgáltató ezzel azonosítja a felhasználót, mielőtt szolgáltatna számára. PAP (Password Authentication Protocol) A PPP Link-Establishment állapotát érzékelve kapcsolatot kezdeményező (initiator) végpont a felhasználói nevet és jelszót egyszerű nyilt szövegként küldi át a létrejött LCP linken a védett végpontnak (authentcator), ezzel egy alacsony fokú védelmet nyújtva a jelszó lehallgatása, ellopása vagy visszajátszása ellen. A küldést addig ismétli, amíg a hitelesítést jelző nyugta meg nem érkezik vagy a link meg nem szakad, pl. a sikertelen hitelesítés miatt. A hitelesítés csak egyszer, a PPP kapcsolat kiépítési fázisában történik meg. A PAP konfigurálása CISCO routeren Első lépés: a védendő pl. R1 router helyi hitelesítési adatbázisába felvesszünk (legalább) egy felhasználónevet és a hozzátartozó jelszót, de közben ügyeljünk arra, hogy a kis- és nagybetűket a rendszer megkülönbözteti. Több felhasználó és jelszava is elhelyezhető az adatbázisban, de egy felhasználói névhez csak egy jelszó rendelhető. A későbbiekben majd az ebben az adatbázisban megtalálható valamelyik „párost” használó protokoll vagy felhasználó férhet hozzá a router bizonyos védett szolgáltatásaihoz. Ezt az adatbázist a router a különböző hitelesítési feladatok (pl. soros-, ill. konzol porton, stb. végzett hitelesítések) alkalmával fogja használni. Tehát egy felhasználó és jelszava: R1(config)#username fh1_név password fh1_jelszó Második lépés: a pont-pont kapcsolathoz tartozó routerek soros interfészein PPP beágyazást írunk elő. Az interfészek egyéb beállításait (pl. IP cím, netmaszk, stb) sem hanyagoljuk el, de itt azokat nem részletezzük: R1(config-if)#encapsulation ppp R2(config-if)#encapsulation ppp

t. okt. 2011

46

Szarka T.

HÁLÓZATOK


Harmadik lépés: a védendő router interfészen előírjuk az alkalmazandó hitelesítési eljárást. A következő paranccsal megadhatjuk a használandó hitelesítési eljárást vagy eljárások esetén azok sorrendjét: R1(config-if)#ppp authentication {chap|pap|chap pap|pap chap} Most konkrétan: R1(config-if)#ppp authentication pap Negyedik lépés: az itt következő parancsra csak azért van szükség, mert eltérünk az alapértelmezés szerinti bizonságos CHAP hitelesítő eljárástól. A hitelesítendő routeren (tehát azon amelyik igazolja magát) beállítjuk, hogy CHAP helyett PAP eljárást használjon és egyben az eljárás során használandó felhasználói nevet és jelszót is megadjuk. Fontos, hogy ezek azonosak legyenek az R1 hitelesítési adatbázisában már korábban tárolt értékekkel: R2(config-if)#ppp pap sent-username fh1_név password fh1_jelszó CHAP (Challenge Handshake Authentication Protocol) A PPP Link-Establishment állapotának elérését érzékelve a védett (hitelesítő) router egy kihívást (challenge) küld a kezdeményezőnek. (Az eljárás megköveteli, hogy mindkét résztvevő ugyanazt a jelszót használja az azonosításra.) A kihívásban szerepel egy számsorozat és a hitelesítő router neve. A kezdeményező megkeresi a hitelesítő nevéhez tartozó jelszót, majd ebből és a számsorozatból képez egy hash értéket76 (kivonatot), amit visszaküld a hitelesítőnek. A hitelesítő a számsorozat és a kezdeményezőhöz tartozó jelszó alapján maga is számított egy kivonatot. A hitelesítő a két kivonatot összehasonlítja és ha megegyezik, akkor hitelesítettnek tekinti a kezdeményezőt. Későbbiekben a hitelesítő a PPP kapcsolat alatt bizonyos időközönként majd megismétli a kihívási folyamatot, de mindig másik számsorozattal. Ez az eljárás biztosítja, hogy a link lehallgatásával, majd a válasz visszajátszásával sem lehet megtéveszteni a hitelesítőt. Figyeljük meg, hogy a jelszó még titkosított formában sem jelenik meg a linken. A CHAP konfigurálása CISCO routeren, amely az R1 router védelmét mutatja be Első lépésként mindkét routeren létrehozzuk a hitelesítési adatbázist. Most fontos, hogy felhasználói névként a szomszédos router nevét adjuk meg, mert az eljárásban (alap beállítások mellett) minden router a saját hoszt nevét küldi el felhasználói névként. A bevezetőben szereplő okokból azonos jelszót kell a routerekhez rendelni: R1(config)#username R2 password közös_jelszó R2(config)#username R1 password közös_jelszó Második lépés: a pont-pont kapcsolathoz tartozó routerek soros interfészein PPP beágyazást írunk elő. Az interfészek egyéb beállításait (pl. IP cím, netmaszk, stb) sem hanyagoljuk el, de azokat most sem részletezzük: R1(config-if)#encapsulation ppp R2(config-if)#encapsulation ppp

76

Egy olyan speciális függvénnyel dolgozik, amelynek értékeit megfigyelve nagyon költséges lenne meghatározni, hogy milyen függvény argumentum hatására jött létre a függvény értéke. Ez még akkor is igaz, ha a link lehallgatásával hozzájutunk az argumentum egyik részéhez, a kihívásban szereplő számsorozathoz!

t. okt. 2011

47

Szarka T.

HÁLÓZATOK


Végül harmadik lépésként a védendő routeren beállítjuk az alkalmazandó hitelesítő eljárást: R1(config-if)#ppp authentication chap Megjegyzés: az előző példákban csak a link egyik végpontján található routert védte egy adott hitelesítő eljárás. Természetesen az előbbi parancsok felhasználásával mindkét végpont védelme megoldható. A PPP beágyazás és a hitelesítés vizsgálata Megvizsgáljuk, hogy a soros interfészhez tartozó linken milyen állapotban van az LCP és az aktuális NCP (részlet a válaszból): R1#show interfaces serial 2/0 Serial2/0 is up, line protocol is up (connected) Hardware is HD64570 Internet address is 192.168.1.1/24 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive set (10 sec) LCP Open Open: IPCP, CDPCP

Mit szállítanak a PPP csomagok (részlet): R1#debug ppp packet Serial2/0 PPP: I pkt type 0xc021, datagramsize 104 Serial2/0 PPP: O pkt type 0xc021, datagramsize 104 Serial2/0 PPP: I pkt type 0xc223, datagramsize 104 Serial2/0 PPP: O pkt type 0xc223, datagramsize 104 Serial2/0 PPP: I pkt type 0x0207, datagramsize 104 Serial2/0 PPP: O pkt type 0x0207, datagramsize 104

0xc021: LCP 0xc223: CHAP 0x0207:CDP

t. okt. 2011

48

Szarka T.

Az adatkapcsolati és fizikai rétegek

Recommend Documents