Az adatkapcsolati és fizikai rétegek

Átírás

1 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áljuk 1, 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 t. okt Szarka T.

2 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án 2 néhány alfejezetét láthatjuk: Például a napjaink domináns Ethernet technológiáival a szabványok foglalkoznak 3. 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ártya 4 a fenti listából több szabványt is realizálhat, pl.: t. okt Szarka T.

3 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 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<=2 N -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őt 5, 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) szegmensre 6 való felosztásával történhet. Az ábrán 7 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 ütközés fölött a várakozási idő maximuma 1023 egységen állandósul. 6 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 t. okt Szarka T.

4 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án 8 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án 9 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ést 10 is tartalmaz, pl p, e, 802.1j, 802.6k, stb t. okt Szarka T.

5 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 ábra 11 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ása 12 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. 100Base- TX é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 t. okt Szarka T.

6 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át 14 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át 15. 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ódot 16. Ezt konkrétan a 802.3u auto-negotiation protokoll szerint kell egyeztetnie a szomszéddal. A vizsgálati sorrend: Base-TX Full Duplex Base-T Base-TX 4. 10Base-T Full Duplex 5. 10Base-T pdf t. okt Szarka T.

7 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ően 17. Egyéb források 18. 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 és t. okt Szarka T.

8 CSMA/CA. A (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: t. okt Szarka T.

9 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ábellel 19 és lezáró dugó 20 a kábel végén: t. okt Szarka T.

10 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 (U/UTP) 23 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/FTP 24. (Pl. egy Industrial Ethernet rendszerben: és 24 Fólia vagy fémszövet az árnyékolás. Forrás: helukabel_bus_cables/ind_ethernet_600ind.html t. okt Szarka T.

11 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án 25 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éssel 26 ) 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 Egyéb elnevezései: Auto uplink and trade, Universal Cable Recognition and Auto Sensing t. okt Szarka T.

12 Az előbbiek figyelembe vételével a használandó kábelek fajtája 27 : 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él 28 : 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ábele 29 mind a 4 érpárat használja: Rollover (konzol) kábel: bizonyos menedzselhető eszközök (router, switch) konfigurálásához használják 30. (Normál hálózati adatforgalomra nem használható.) crossover.color-codes.gif t. okt Szarka T.

13 Kábel kategóriák EIA/TIA Category ISO/IEC11801 [class] Jellemző vezetéktípusa Maximum frekvencia (ISO 11801) MHz Max csillapítás db/km, 100MHz Felhasználási területek (főleg Ethernet technológiákhoz kapcsolódóan) Cat1(*) A UTP Cat2(*) B UTP 1 - Cat3 C UTP Hagyományos telefon rendszerhez hangátvitelre Régi ARCNet és Token Ring hálózatokban használták 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 Token Ring hálózatokban Cat5(*) - UTP STP Cat5e D UTP Cat6 E UTP Cat6A EA UTP Cat7 F S/FTP 600 Cat7A FA S/FTP 1000 (*) Az EIA/TIA által nem elismert kategóriák. 10Base-T, 100Base-TX 1000Base-T (nem ajánlott) 10Base-T, 100Base-TX 1000Base-T 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 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 Szarka T.

14 A kábelek néhány villamos jellemzőjére az alábbi ábrán 31 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 ára 32 : 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 Class C, D, and E ISO/IEC Class F (DTX-1800 only) EN Class C, D, E EN Class F (DTX-1800 only) ANSI TP-PMD IEEE BASE-T, 100BASE-TX, 1000BASE-T IEEE (STP cabling, IBM Type 1, 150Ω ) Token Ring, 4 Mbps and 16 Mbps t. okt Szarka T.

15 A 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), Remote NEXT, Remote Attenuation-to-crosstalk Ratio (ACR), Remote ELFEXT, Remote Power Sum ELFEXT, Remote Power Sum NEXT, Remote Power Sum ACR, Remote A kábelezések főbb villamos jellemzői 34 A mérési eredményeket megjeleníti 33 és azokat az adott szabvány követelményeivel összevetve minősíti a kábelezést. 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 á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, NEXT 35 ) é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) és users.iit.uni-miskolc.hu/~szkovacs/gamfnetd/netde3.pdf 35 t. okt Szarka T.

16 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érik 37. Alien Crosstalk a szomszédos kábelek, a patch panelek és az aljzatok egymáshoz közeli portjai között keletkező áthallás 38. 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 t. okt Szarka T.

17 Az egyes kategóriákba (osztályokba) tartozó kábelezések villamos jellemzői 40 : 1. Specified as ELFEXT for category 5e/class D and category 6/class E. 2. Specified as PSELFEXT for category 5e/class D and category 6/class E. 3. 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án 42 az alap összeköttetés (mint link) és az A, D és E jelű patch kábeles szakaszok láthatóak és ge10ge.pdf és t. okt Szarka T.

18 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ő é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 nd 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 CENELEC 43 EN nd szabványnak is. A következő két ábrán 44 a strukturált kábelezés lényegét láthatjuk: Általános esetben az épület helyiségeiben (a munkaterületen) kb. 5m 2 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 European Committee for Electrotechnical Standardization 44 t. okt Szarka T.

19 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ő fa 45. Vonali kódolás A vonali kódolás az alapsávi 46 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] jelzési sebesség: az időegység alatt továbbított vonali szimbólumok száma [Baud] 47 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 bitsorozatot 48, 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 Modulációt nem használ, ezáltal a jel spektruma nem tolódik el a frekvenciatengelyen és t. okt Szarka T.

20 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án 50 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 2 5 -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álata 52 : 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) gbenthien.net/encoding.pdf 52 splash.eik.bme.hu/papers/ge10ge.pdf t. okt Szarka T.

21 kódolást használnak, amely minden jelzéssel log 2 5=2.32 bitnyi információt visz át egy érpáron, így a négy érpáron ez kb 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ő pontosabban 5 4 =625 különböző vonali szimbólumból számunkra csak 2 8, 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án 53 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ák 54 összefoglalója: Egyéb források: időzités: PoEthernet: minden: users.iit.uni-miskolc.hu/~szkovacs/gamfnetd/netde3.pdf people.inf.elte.hu/lukovszki/courses/08nwi/nwi07s4.pdf The Ethernet new handout.pdf pcs.pdf 53 ftp.dell.com/app/4q01-pat.pdf 54 t. okt Szarka T.

22 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. NIC generálja Preamble 8 IEEE típusú Ethernet keret, LLC betéttel LLC generálja LLC PDU (Az LLC kliensétől v. kliensének) MAC fej LLC fej LLC adat Cél MAC címe Adó MAC címe Hossz DSAP SSAP CONTR ADAT LLC gen. PAD x NIC gen. CRC 4 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: , majd az utolsó 8 bit , í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álja 56, 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 Ezt a 8 bitet külön elnevezték: keretkezdet határoló. 56 Mindaddig, amíg szoftveresen át nem állítjuk a kártyánk fizikai címét. t. okt Szarka T.

23 00:00:02 BBN 00:00:0C Cisco 00:00:0E Fujitsu 00:00:0F NeXT 00:00:10 Sytek/Hughes LAN Systems 00:00:11 Tektronics 00:00:15 Datapoint 00:00:18 Webster 00:00:1A AMD? 00:00:1B Novell/Eagle Tech. 00:00:1D Cabletron 00:00:20 Data Industrier AB 00:00:21 SC&C 00:00:22 Visual Technology 00:00:23 ABB 00:00:29 IMC 00:00:2A TRW 00:00:3C Auspex 00:00:3D ATT 00:00:44 Castelle 00:00:46 Bunker Ramo 00:00:49 Apricot 00:00:4B APT 00:00:4F Logicraft 00:00:51 Hob Electronic 00:00:52 ODS 00:00:55 AT&T 00:00:5A SK/Xerox 00:00:5D RCE 00:00:5E IANA 00:00:61 Gateway 00:00:62 Honeywell 08:00:0A IBM 00:AA:00 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 sorrendben 57 és bitenként részletezve: G/I bit U/L bit 22 bit a gyártót jelöli 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 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. 58 Lehet, hogy a cím legbaloldalibb bájtja helyesebb lenne. t. okt Szarka T.

24 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: C CC CC CC Bridge Spanning Tree: C 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 ( ) 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 ( E E-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 csoportcímet használó alkalmazások a következő MAC címet rögzítik a NIC-ben: E-C 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 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 közötti lehet 59 : 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 Szarka T.

25 Mező: Méret (bájt): MAC cél 6 MAC küldő 6 Hossz 2 LCC fej 3 CRC 4 Összesen 21 A táblázat a keretben elhelyezett (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 (LLC)) szerint TYPE 1 60 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 LLC fejléc LLC adat DSAP SSAP CONTROL Adatok (pl. IP fejléc +adatok(tcp fejléc + adatok) 1 bájt 1 bájt 1 bájt 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 hoszton 61 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 Null LSAP (Management az LLC rétegek egymás közötti kommunikációjához.) 02 Individual LLC Sublayer Management Function 03 Group LLC Sublayer Management Function (csoportcím) 04 IBM SNA Path Control (individual) 05 IBM SNA Path Control (csoportcím) 06 ARPANET Internet Protocol (IP) 08 SNA 0C 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 Szarka T.

26 0E PROWAY (IEC955) Network Management & Initialization 42 IEEE Bridge Spannning Tree Protocol 4E EIA RS-511 Manufacturing Message Service 7E ISO 8208 (X.25 over IEEE 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 S S S S S S S 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 Szarka T.

27 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 SSAP CONTROL DDDDDDDI/G SSSSSSS 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 SSAP CONTROL DDDDDDDI/G SSSSSSS FORMAT CLASS WINDOW XXXXXXXX 000YYYYY ZZZZZZZ0 XXXXXXXX= 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= 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 SSAP CONTROL Adatbájtok DDDDDDDI/G SSSSSSSC/R 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 (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 pufferelésre 62. 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 változik 63. Ezt nevezik TYPE 2 formátumú 64 LLC PDU-nak. Adatszállító fej: DSAP SSAP CONTROL 1 CONTROL 2 DDDDDDDI/G SSSSSSSC/R N(S) 0 N(R) P/F Supervisory fej: DSAP SSAP CONTROL 1 CONTROL 2 DDDDDDDI/G SSSSSSSC/R 0000 SS 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. 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. 63 A vezérlő bájt helyett szó lesz. 64 A típusok (type) az LLC PDU fejére vonatkoznak. t. okt Szarka T.

28 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 MTU [byte] MAC protokoll MTU [byte] Token Ring ARPANET 1006 FDDI 4352 X Ethernet II 1500 ARCNET 508 Ethernet Szabványos minimum 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ál 65 é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 keretben 66. 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 bites AUTODIN II. polinom segítségével készíti. Csak az egyszerűsítés miatt neveztük CRC mezőnek. 66 Fizikailag beolvassa, de logikailag nemlétezőnek tekinti. t. okt Szarka T.

29 ETHERNET II keret Ez a változat 3 évvel idősebb mint az IEEE 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 6 Protokoll azonosító 2 Adat 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 keretben az IEEE 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 XNS 0601 XNS Address Translation 0800 DOD IP 0801 X.75 internet 0802 NBS internet 0803 ECMA internet 0804 Chaosnet 0805 X.25 Level ARP 0807 XNS Compatibility 081C Symbolics private 0888 Xyplex 0900 Ungermann-Bass net debug 0A00 Xerox PUP 0A01 Xerox PUP Address Translation 0BAD Banyan Systems 0BAF Banyan Echo 1000 Berkeley trailer negotiation 1001 Berkeley trailer encapsulation 1234 DCA - Multicast 1600 VALID system protocol 1989 Artificial Horizons (dogfight sim.) 3C00 3Com NBP 4242 PCS Basic Block Protocol 4321 THD - Diddle 5208 BBN Simnet Private 6000 DNA experimental 6001 DNA Dump/Load -MOP DNA Remote Console -MOP DNA IV Routing Layer 6004 DEC: Local Area Transport 6005 DEC: Diagnostics 6006 DEC: Customer Use 6007 DEC: LAVC Com 7000 Ungermann-Bass download 7001 Ungermann-Bass NIUs 7002 Ungermann-Bass diagnostic/loopback 7003 Ungermann-Bass 7005 Ungermann-Bass Bridge 7007 OS/9 Microware 7009 OS/9 Net? 7020 Sintrom (was LRT) 7030 Racal-Interlan 7031 Prime NTS 7034 Cabletron 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe 8006 Nestar 8008 AT&T/Standford 8010 Excelan 8013 Silicon Graphics diagnostic 8014 Silicon Graphics network games 8015 Silicon Graphics 8016 Silicon Graphics XNS Nameserver 8019 Apollo DOMAIN 802E Tymshare 802F Tigan 8035 Reverse ARP 8036 Aeonic Systems 8037 IPX (Netware) 8038 DEC: bridge 8039 DEC: DSM/DDP 803A DEC: (Argonaut console) 803B DEC: (VAXELN) 803C DEC: NMSV DNA Naming 803D DEC: encryption 803E DEC: distributed time service 803F DEC: LAN Traffic Monitor 8040 DEC: NetBIOS Datagrams 8041 DEC: Local Area System Transport 8042 DEC Unassigned 8044 Planning Research Corp AT&T 8048 DEC: DECamds 8049 ExperData 805B VMTP/RFC C Stanford V Kernel 805D Evans & Sutherland 8060 Little Machine 8062 Counterpoint Computers 8065 UMass. at Amherst 8067 Veeco Integrated Automation 8068 General Dynamics 8069 AT&T 806A Autophon 806C ComDesign 806D Compugraphic Corp. 806E Landmark Graphics Corp. 807A Matra 807B Dansk Data Elektronic 807C Merit Internodal 807D Vitalink Communications 8080 Vitalink TransLAN III Mgmt 8081 Counterpoint Computers 8088 Xyplex 809B AppleTalk (EtherTalk) 809C Datability 809F Spider Systems PAD x CRC 4 t. okt Szarka T.

30 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 Analyzer 67 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 Szarka T.

31 ETHERNET SNAP (SUBNETWORK ACCESS PROTOCOL) típusú keret NIC generálja Preamble 8 LLC generálja LLC PDU (Az LLC kliensétől v. kliensének) MAC fej LLC fej SNAP Cél Adó Hossz DSAP SSAP CONTROL OUI TYPE DSAP=AAH SSAP=AAH CONTROL=03H OUI (Organizationally Unique Identifier) mint protokoll gyártója, gazdája=0 68 TYPE= az ETHERNET II. tipusnál megismert protokoll azonosítók. ADAT LLC gen. PAD x NIC gen. CRC 4 Az IEEE keretben egy kicsit módosult a (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 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 IEEE 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 az IP protokoll azonosítója! Pl. AA AA 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 (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 betétje (nyers RAW), ezért nem alkalmas multiprotokollos működésre és megakadályozza azt is, hogy az IEEE 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 Ethernet-SNAP Novell (RAW) IEEE LLC 0-5 Cél cím Cél cím Cél cím Cél cím 6-11 Forrás cím Forrás cím Forrás cím Forrás cím Prot. azon. (Type) Hossz Hossz Hossz 14 DSAP (fix AAH) DSAP (lényegében a Type) 15 SSAP (fix AAH) SSAP 16 Control (fix 03H) Control-1 17 Organizációs kód (Control-2) 18 (3 byte) Típus (Type) Horváth György, Lanvizs.zip (MEK) 68 Pl C=CISCO t. okt Szarka T.

32 A hálózati operációs rendszerek (NOS) által támogatott Ethernet keretek Keret típus: Novell elnevezése: Cisco elnevezés: Windows elnevezés IEEE LLC Ethernet_ LLC Ethernet Ethernet II. Ethernet_II. ARPA Ethernet II SNAP Ethernet_SNAP 70 SNAP SNAP Novell (RAW) Ethernet_802.3 Novell Ethernet 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 LLC] [Ethernet II.] [Ethernet 802.3] [Ethernet LLC SNAP] IPX/SPX TCP/IP A kliens természetesen mindegyiket támogatja, lásd a NET.CFG load és bind parancsait. IPX/SPX IPX/SPX és TCP/IP IPX/SPX és TCP/IP és AppleTalk 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ó 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 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 (LLC TYPE1) keret az alapértelmezett, de a protokoll tulajdonságai menüből bármelyik beállítható. NetBEUI protokoll esetén Ethernet (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 IEEE MAC Fizikai réteg CSMA/CD Token Bus Token Ring 69 DSAP=SSAP=0E0H 70 DSAP=SSAP=0AAH t. okt Szarka T.

33 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 Szarka T.

34 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 Szarka T.

35 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 MAC cél mindig egy speciális multicast cím: C 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 PAD 42 Eredeti adatok max 1500 CRC 4 Ú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 3 bit Canonical 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 : érvényes VLAN ID 4095: foglalt azonosító t. okt Szarka T.

36 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 Szarka T.

37 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 CSOMAG Adatkapcsolati réteg LLC protokoll LLC CSOMAG MAC protokoll MAC LLC CSOMAG MAC Fizikai réteg Média pl. elektromos jelek Amikor például az Ethernet hálózatok jellemzőit és működését vázoljuk, akkor tulajdonképpen az IEEE (CSMA/CD) szerinti MAC protokoll és az IEEE 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 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 Szarka T.

38 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 Szarka T.

39 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álja 71 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 Szarka T.

40 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 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= B) küldjük 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 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án 72 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 t. okt Szarka T.

41 á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 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 Szarka T.

42 Az interfész funkciókat, egy DTE (amely SW és HW komplexum) így értelmezi: Név: Adója D 9 D 25 Funkció: RxD DCE 2 3 TxD DTE 3 2 RTS DTE 7 4 CTS DCE 8 5 DTR DTE 4 20 DSR DCE 6 6 DCD vagy RLSD DCE 1 8 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. 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. 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. 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.) 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. 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. 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 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 Szarka T.

43 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 Szarka T.

44 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 puffere 73 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 bps vonali adatátviteli sebesség mellett a soros interfészen esetleg bps-os adatátviteli sebességre is szükség lehet a folyamatos adáshoz. t. okt Szarka T.

45 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 protokoll 74 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: ): 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 ( 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 Multilink 75 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 HYPERLINK " 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 Szarka T.

46 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: 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 Szarka T.