Az Ethernet keretek
Az Ethernet hálózaton az adatok ún. keretekben "utaznak". A keretek valójában nem mások, mint mezõkre osztott bitsorozatok, amelyek egyetlen elemi egységet képeznek. A szóban forgó mezõk a cél- ill. küldõ állomás címét, magát a továbbítandó adatot alkotó bitsorozatot ill. egy ellenõrzõ számot tartalmaznak (ez utóbbi az adatok "sértetlen" megérkezésének ellenõrzésére használható).
Minden Ethernet csomagot egy 56-bites, 1-esek és 0-k váltakozó sorozatából álló ún. preamble (elõtag) vezet be. Az elõtag funkciója, hogy a kábelre felfûzött állomások számára lehetõvé tegye az adás megkezdésének detektálást még a tényleges, "értékes" adatok megérkezése elõtt.
A keretben az elõtagot a 8-bites ún. start frame delimiter követi, ami egy fix 10101011 bitsorozat, és amelynek funkciója a keret tényleges kezdetének jelölése. (Ez teszi lehetõvé az adatok fogadásához a szinkronizációt, hiszen a fogadó állomások maga a preamble alapján nem lennének képesek erre, hiszen az csupa azonos bitcsoportok sorozatából áll.)
(Megjegyzendõ, hogy egyes források 62 bites, 10 bitkombináció sorozatából álló szekveciának jelölik a preamble-t és 11 bitsorozatnak a start frame delimitert. Az eredmény nyilvánvalóan ugyanaz, a dolognak nincs különösebb jelentõsége. Én magam azért szimpatizálok inkább a fentebb olvasható felosztással, mert az bájthatárokra helyezi a mezõhatárokat és így egyszerûbbé teszi a formátumok jelölését.)
Ezek után a cél- és a küldõ-állomás 48-bites címei következnek (ebben a sorrendben). Az Ethernet hálózaton minden állomást egy egyedi, 48-bites (6 bájtos) ún. MAC (Media Access Control) cím azonosít. Ezen címek kiosztását az IEEE kontrollálja a kiosztott címtartományok adminisztrálásán keresztül. Az IEEE minden Ethernet-egységet (kártyát, eszközt) gyártó szervezet részére egy egyedi, 24-bites azonosítót oszt ki, az ún. OUI-t (Organizationally Unique Identifier, azaz Szervezeten belüli Egyedi Azonosító) ami a szóban forgó gyártó által készített Ethernet-eszközök címeinek elsõ 24 bitjét fogja adni. A cím fennmaradó 24-bitjét már maga a gyártó osztja ki, de garantálnia kell, hogy kibocsátott eszközei között sosem lesz két azonos címû. Ennek a rendkívül egyszerû, ugyanakkor nagyon effektív módszernek köszönhetõ, hogy elméletileg (!) a világ bármely két Ethernet hálózata minden további nélkül összeköthetõ, hiszen az egyesített hálózaton nem léphetnek fel címütközések a gyárilag meghatározott címek garantált egyediségébõl adódóan. (Meg kell jegyeznünk, hogy maguk az Ethernet kártyák azonban általában lehetõséget nyújtanak a gyárilag kiosztott egyedi címek szoftveres módon történõ felülbírálására, ami így cím-konfliktusok potenciális forrása lehet.)
Az adatok átvitele során minden, a közös átviteli médiára csatlakoztatott Ethernet-eszköz elkezdi olvasni az éppen küldés alatt álló keret tartalmát, azonban a célállomás címe után már csak az az eszköz folytatja a keret fogadását, amelynek címe egyezik a megjelölttel. Ez alól kivételt képez a tisztán 1-esekbõl álló ún. broadcast cím aminek észlelése estén a csomagot az állomásnak feltétel nélkül fogadnia kell. (A broadcast cím használható a minden a hálózatra csatlakoztatott eszköz egyidejû "megszólítására".) Itt is meg kell jegyeznünk, hogy a legtöbb ma használatos kártya ismer egy speciális, ún. promiscuous átviteli módot, amikor is nem csak a részére szánt, hanem az összes többi állomás felé küldött csomagot is fogadja és továbbítja a felsõbb rétegek felé. Ez a lehetõség komoly biztonsági rést teremthet a hálózaton, hiszen kihasználásával bármelyik a közös médiumra csatolt eszköz azonnal képessé válik bármely két másik eszköz közti kommunikáció lehallgatására.
A keret eddig felsorolt mezõi minden Ethernet hálón azonosak, azonban az ezt követõek felépítése és jelentése eltérõ lehet, az alkalmazott konkrét szabványtól függõen. Ezek pedig a következõk lehetnek:
Ethernet II, másnéven Ethernet DIX
IEEE 802.3 és 802.2
Ethernet SNAP
Az Ethernet II, azaz DIX keretformátum
A nemzetközi Ethernet-szabványok IEEE részérõl történõ kidolgozása elõtt az alkalmazott formátumokat egyedül a Xerox határozta meg és alakította ki. A Xerox a keretben a címeket követõ 16-bitet egy ún. protokoll-azonosító kialakítására használta fel, ami lehetõvé tette a különbözõ gyártók protokolljainak együttmûködését egyetlen Ethernet-hálózaton belül. Ezeket az egyedi kódokat a Xerox osztotta ki és tartotta nyilván. A legismertebbek közülük a következõk:
Protokoll-azonosító kód Jelentés
0x0600
XNS (Xerox NS)
0x0800
IP (Internet Protocol)
0x6003
DecNET
0x8137
Novell Netware IPX
0x86DD
IPv6
Ugyanakkor a Xerox nem tartott fent külön mezõt a csomagok hosszának jelzésére, ezért errõl minden egyes protokollnak saját magának kellett gondoskodnia az adatmezõn belül. (Erre azért van feltétlen szükség, mert az Ethernet csomagok minimális mérete 64 bájt, ezért az ennél rövidebb csomagokat az átvitel során 0-kkal ki kell egészíteni. Ha az alkalmazott protokoll ennél rövidebb csomagok átvitelét is lehetõvé teszi, akkor gondoskodnia kell arról, hogy képes legyen a kapott Ethernet-csomagon belül a "hasznos" és a kitöltõ bitek szétválasztására, azaz az eredeti csomaghossz visszaállítására.)
Az Ethernet 802.3 és 802.2
Az IEEE 802-es bizottságának feladata olyan Ethernet-szabvány kidolgozása volt, ami jól illeszkedett az OSI modellbe és csereszabatos volt más, már létezõ átviteli protokollokkal (azaz nem függött magasabb szintû protokolloktól). Az Ethernet csomagok elõbb említett minimális csomagmérete azonban teljesen egyedi volt (igazából csak a megbízható ütközés-vizsgálat miatt volt rá szükség) és hasonló megkötéssel semmilyen más addigi hálózat nem rendelkezett. Ez azt - az elõbb már szintén említett - a problémát vetette fel, hogy a magasabb szintû protokollok amennyiben maguk nem tartalmaztak a csomag méretére vonatkozó információkat, képtelenek lettek volna változtatás nélkül (!) Ethernet-hálózatokon is mûködni (hiszen a 64 bájtnál rövidebb csomagok galibát okoztak volna).
Ezen okból kifolyólag az eredeti Ethernet szabvány protokoll-azonosító mezõjét csomaghossz-mezõvé "alakították át". Mivel a Xerox semmilyen fontos protokoll számára nem osztott ki azonosítót 1500 alatt, és mivel az Ethernet csomagok maximális mérete 1500 bájt, ezért ez a módosítás nem okozott konfliktust a mezõk kiosztásában, és a korrektül megírt hálózati szoftverek a vegyes – mind DIX, mind IEEE 802.3 szabvány szerint mûködõ elemeket is tartalmazó – hálózatokon is mûködõképesek maradtak.
Ugyanakkor nyilvánvalóan továbbra is gondoskodni kellett a csomagok magasabb szintû protokollok felé történõ szétosztásáról, azaz a protokoll-azonosító kereten belüli helyének és formátumának szabványosításáról. Ezt úgy oldották meg, hogy a 802.3-as keretbe, az adatmezõbe beágyaztak egy másik, szabványosított formátumú keretet, ami a 802.2-es típusjelet viseli. A 802.2-es keretben az elsõ három, speciális jelentéssel bíró bájtot (DSAP, SSAP és Control) követik a tényleges adatbitek.
Sajnos azonban ezzel a szabvánnyal történt egy kis malõr. Mégpedig az, hogy a Novell a saját, úgymond a 802.3-at implementáló protokollját a szabvány egy elõzetes, még kisebb hiányosságokkal / tisztázatlan pontokkal rendelkezõ kiadása alapján kezdte meg, és ennek folyamán valószínûleg valamilyen félreértés történt. A lényeg, hogy a Novell Netware az úgymond 802.3-as csomagokat a 802.2-es "betét" nélkül állítja össze, tehát esetében a keretben a csomag-hosszot közvetlenül követi a csomag adattartalma, ami nyilván inkompatibilitáshoz vezet és meggátolja, hogy a két eltérõ szabvány szerint készült rendszerek ugyanazon a hálózaton párhuzamosan mûködjenek. Ráadásul mivel a Novell-féle implementáció nem gondoskodik semmiféle protokoll-azonosító átvitelérõl, így az ilyen keretformátumot alkalmazása mellett mindössze egyetlen hálózati protokoll mûködtethetõ az egész hálózaton. Öröm az ürömben, hogy mivel az IPX a csomag elsõ két bájtját az ellenõrzõ-összeg részére tartja fent, és mivel általában ezt nem szokták kihasználni (lévén ellenõrzõ-összegrõl maga az Ethernet is gondoskodik) – amikor is annak értékét 0xFFFF-re kell állítani –, így az igazi 802.3/802.2-es és a Novell-féle 802.3-as csomagok nagy biztonsággal megkülönböztethetõk egymástól. (Ez persze nem változtat azon, hogy a Novell 802.3-as csomagokkal dolgozó hálózat így is csakis egyféle protokollt használhat.)
Az Ethernet SNAP
Az így felmerült problémák és a 802.3-as hiányosságainak pótlására az IEEE kidolgozta az Ethernet SNAP szabványt, ami a megelõzõ keretformátumokkal kompatíbilis módon oldja meg a problémákat. Az Ethernet SNAP szabvány lényege, hogy a 802.3-as alapkeretbe egy, a 802-vel kompatíbilis, de elsõ három bájtjában fix, a 802.2 fejlécnek megfelelõ tartalmú keretet ágyaz be, majd ezt követi a SNAP csomag 40-bites protokoll-azonosítója és az adatbitek. A SNAP csomagban a 802.2-es DSAP, SSAP és Control mezõinek helyén rendre a 0xAA, 0xAA, 0x03 értékek állnak, amik lehetõvé teszik a 802.3/802.2-es és a SNAP csomagok egyértelmû szétválogatását. Az 5-bájtos protokoll-azonosító pedig (szemben a 802.3 mindössze 7 bites hasonló jellegû mezõjével) nyilvánvalóan elegendõen nagy tartományt biztosít a belátható jövõben esetlegesen kidolgozásra kerülõ összes magasabb szintû protokoll egyértelmû megkülönböztetésére.
A SNAP protokoll azonosítója egyébként az Ethernet címekhez hasonlóan szintén két részre oszlik: az elsõ három bájtot a központilag adminisztrált és kiosztott OUI-k adják, míg a fennmaradó 2 bájttal a gyártók belül szabadon rendelkezhetnek. A gyakorlatban egyébként az elsõ három bájt tipikusan 0, míg a fennmaradó két bájtra az eredeti, Ethernet_II csomagokban is alkalmazott protokoll-azonosítók kerülnek, így gyakorlatilag az Ethernet_II hálózaton mûködõ protokollok minimális módosítással átvihetõk Ethernet SNAP alá is.
Ha szükséges, a kereteket a már említett kitöltõ bitek egészítik ki minimum 128-bitessé és végül az ún. FCS (Frame Check Sequence – Keret-Ellenõrzõ Sorozat) zárja. Ez nem más, mint egy 4-bájtos CRC ellenõrzõszám, ami a vételi oldalon a keret megelõzõ bitjei alapján újragenerálásra kerül, és ha a számolt és kapott összegek nem egyeznek, akkor a fogadó átviteli hibát feltételezve a csomagot eldobja.
Az Ethernet hálózaton az adatok ún. keretekben "utaznak". A keretek valójában nem mások, mint mezõkre osztott bitsorozatok, amelyek egyetlen elemi egységet képeznek. A szóban forgó mezõk a cél- ill. küldõ állomás címét, magát a továbbítandó adatot alkotó bitsorozatot ill. egy ellenõrzõ számot tartalmaznak (ez utóbbi az adatok "sértetlen" megérkezésének ellenõrzésére használható).
Minden Ethernet csomagot egy 56-bites, 1-esek és 0-k váltakozó sorozatából álló ún. preamble (elõtag) vezet be. Az elõtag funkciója, hogy a kábelre felfûzött állomások számára lehetõvé tegye az adás megkezdésének detektálást még a tényleges, "értékes" adatok megérkezése elõtt.
A keretben az elõtagot a 8-bites ún. start frame delimiter követi, ami egy fix 10101011 bitsorozat, és amelynek funkciója a keret tényleges kezdetének jelölése. (Ez teszi lehetõvé az adatok fogadásához a szinkronizációt, hiszen a fogadó állomások maga a preamble alapján nem lennének képesek erre, hiszen az csupa azonos bitcsoportok sorozatából áll.)
(Megjegyzendõ, hogy egyes források 62 bites, 10 bitkombináció sorozatából álló szekveciának jelölik a preamble-t és 11 bitsorozatnak a start frame delimitert. Az eredmény nyilvánvalóan ugyanaz, a dolognak nincs különösebb jelentõsége. Én magam azért szimpatizálok inkább a fentebb olvasható felosztással, mert az bájthatárokra helyezi a mezõhatárokat és így egyszerûbbé teszi a formátumok jelölését.)
Ezek után a cél- és a küldõ-állomás 48-bites címei következnek (ebben a sorrendben). Az Ethernet hálózaton minden állomást egy egyedi, 48-bites (6 bájtos) ún. MAC (Media Access Control) cím azonosít. Ezen címek kiosztását az IEEE kontrollálja a kiosztott címtartományok adminisztrálásán keresztül. Az IEEE minden Ethernet-egységet (kártyát, eszközt) gyártó szervezet részére egy egyedi, 24-bites azonosítót oszt ki, az ún. OUI-t (Organizationally Unique Identifier, azaz Szervezeten belüli Egyedi Azonosító) ami a szóban forgó gyártó által készített Ethernet-eszközök címeinek elsõ 24 bitjét fogja adni. A cím fennmaradó 24-bitjét már maga a gyártó osztja ki, de garantálnia kell, hogy kibocsátott eszközei között sosem lesz két azonos címû. Ennek a rendkívül egyszerû, ugyanakkor nagyon effektív módszernek köszönhetõ, hogy elméletileg (!) a világ bármely két Ethernet hálózata minden további nélkül összeköthetõ, hiszen az egyesített hálózaton nem léphetnek fel címütközések a gyárilag meghatározott címek garantált egyediségébõl adódóan. (Meg kell jegyeznünk, hogy maguk az Ethernet kártyák azonban általában lehetõséget nyújtanak a gyárilag kiosztott egyedi címek szoftveres módon történõ felülbírálására, ami így cím-konfliktusok potenciális forrása lehet.)
Az adatok átvitele során minden, a közös átviteli médiára csatlakoztatott Ethernet-eszköz elkezdi olvasni az éppen küldés alatt álló keret tartalmát, azonban a célállomás címe után már csak az az eszköz folytatja a keret fogadását, amelynek címe egyezik a megjelölttel. Ez alól kivételt képez a tisztán 1-esekbõl álló ún. broadcast cím aminek észlelése estén a csomagot az állomásnak feltétel nélkül fogadnia kell. (A broadcast cím használható a minden a hálózatra csatlakoztatott eszköz egyidejû "megszólítására".) Itt is meg kell jegyeznünk, hogy a legtöbb ma használatos kártya ismer egy speciális, ún. promiscuous átviteli módot, amikor is nem csak a részére szánt, hanem az összes többi állomás felé küldött csomagot is fogadja és továbbítja a felsõbb rétegek felé. Ez a lehetõség komoly biztonsági rést teremthet a hálózaton, hiszen kihasználásával bármelyik a közös médiumra csatolt eszköz azonnal képessé válik bármely két másik eszköz közti kommunikáció lehallgatására.
A keret eddig felsorolt mezõi minden Ethernet hálón azonosak, azonban az ezt követõek felépítése és jelentése eltérõ lehet, az alkalmazott konkrét szabványtól függõen. Ezek pedig a következõk lehetnek:
Ethernet II, másnéven Ethernet DIX
IEEE 802.3 és 802.2
Ethernet SNAP
Az Ethernet II, azaz DIX keretformátum
A nemzetközi Ethernet-szabványok IEEE részérõl történõ kidolgozása elõtt az alkalmazott formátumokat egyedül a Xerox határozta meg és alakította ki. A Xerox a keretben a címeket követõ 16-bitet egy ún. protokoll-azonosító kialakítására használta fel, ami lehetõvé tette a különbözõ gyártók protokolljainak együttmûködését egyetlen Ethernet-hálózaton belül. Ezeket az egyedi kódokat a Xerox osztotta ki és tartotta nyilván. A legismertebbek közülük a következõk:
Protokoll-azonosító kód Jelentés
0x0600
XNS (Xerox NS)
0x0800
IP (Internet Protocol)
0x6003
DecNET
0x8137
Novell Netware IPX
0x86DD
IPv6
Ugyanakkor a Xerox nem tartott fent külön mezõt a csomagok hosszának jelzésére, ezért errõl minden egyes protokollnak saját magának kellett gondoskodnia az adatmezõn belül. (Erre azért van feltétlen szükség, mert az Ethernet csomagok minimális mérete 64 bájt, ezért az ennél rövidebb csomagokat az átvitel során 0-kkal ki kell egészíteni. Ha az alkalmazott protokoll ennél rövidebb csomagok átvitelét is lehetõvé teszi, akkor gondoskodnia kell arról, hogy képes legyen a kapott Ethernet-csomagon belül a "hasznos" és a kitöltõ bitek szétválasztására, azaz az eredeti csomaghossz visszaállítására.)
Az Ethernet 802.3 és 802.2
Az IEEE 802-es bizottságának feladata olyan Ethernet-szabvány kidolgozása volt, ami jól illeszkedett az OSI modellbe és csereszabatos volt más, már létezõ átviteli protokollokkal (azaz nem függött magasabb szintû protokolloktól). Az Ethernet csomagok elõbb említett minimális csomagmérete azonban teljesen egyedi volt (igazából csak a megbízható ütközés-vizsgálat miatt volt rá szükség) és hasonló megkötéssel semmilyen más addigi hálózat nem rendelkezett. Ez azt - az elõbb már szintén említett - a problémát vetette fel, hogy a magasabb szintû protokollok amennyiben maguk nem tartalmaztak a csomag méretére vonatkozó információkat, képtelenek lettek volna változtatás nélkül (!) Ethernet-hálózatokon is mûködni (hiszen a 64 bájtnál rövidebb csomagok galibát okoztak volna).
Ezen okból kifolyólag az eredeti Ethernet szabvány protokoll-azonosító mezõjét csomaghossz-mezõvé "alakították át". Mivel a Xerox semmilyen fontos protokoll számára nem osztott ki azonosítót 1500 alatt, és mivel az Ethernet csomagok maximális mérete 1500 bájt, ezért ez a módosítás nem okozott konfliktust a mezõk kiosztásában, és a korrektül megírt hálózati szoftverek a vegyes – mind DIX, mind IEEE 802.3 szabvány szerint mûködõ elemeket is tartalmazó – hálózatokon is mûködõképesek maradtak.
Ugyanakkor nyilvánvalóan továbbra is gondoskodni kellett a csomagok magasabb szintû protokollok felé történõ szétosztásáról, azaz a protokoll-azonosító kereten belüli helyének és formátumának szabványosításáról. Ezt úgy oldották meg, hogy a 802.3-as keretbe, az adatmezõbe beágyaztak egy másik, szabványosított formátumú keretet, ami a 802.2-es típusjelet viseli. A 802.2-es keretben az elsõ három, speciális jelentéssel bíró bájtot (DSAP, SSAP és Control) követik a tényleges adatbitek.
Sajnos azonban ezzel a szabvánnyal történt egy kis malõr. Mégpedig az, hogy a Novell a saját, úgymond a 802.3-at implementáló protokollját a szabvány egy elõzetes, még kisebb hiányosságokkal / tisztázatlan pontokkal rendelkezõ kiadása alapján kezdte meg, és ennek folyamán valószínûleg valamilyen félreértés történt. A lényeg, hogy a Novell Netware az úgymond 802.3-as csomagokat a 802.2-es "betét" nélkül állítja össze, tehát esetében a keretben a csomag-hosszot közvetlenül követi a csomag adattartalma, ami nyilván inkompatibilitáshoz vezet és meggátolja, hogy a két eltérõ szabvány szerint készült rendszerek ugyanazon a hálózaton párhuzamosan mûködjenek. Ráadásul mivel a Novell-féle implementáció nem gondoskodik semmiféle protokoll-azonosító átvitelérõl, így az ilyen keretformátumot alkalmazása mellett mindössze egyetlen hálózati protokoll mûködtethetõ az egész hálózaton. Öröm az ürömben, hogy mivel az IPX a csomag elsõ két bájtját az ellenõrzõ-összeg részére tartja fent, és mivel általában ezt nem szokták kihasználni (lévén ellenõrzõ-összegrõl maga az Ethernet is gondoskodik) – amikor is annak értékét 0xFFFF-re kell állítani –, így az igazi 802.3/802.2-es és a Novell-féle 802.3-as csomagok nagy biztonsággal megkülönböztethetõk egymástól. (Ez persze nem változtat azon, hogy a Novell 802.3-as csomagokkal dolgozó hálózat így is csakis egyféle protokollt használhat.)
Az Ethernet SNAP
Az így felmerült problémák és a 802.3-as hiányosságainak pótlására az IEEE kidolgozta az Ethernet SNAP szabványt, ami a megelõzõ keretformátumokkal kompatíbilis módon oldja meg a problémákat. Az Ethernet SNAP szabvány lényege, hogy a 802.3-as alapkeretbe egy, a 802-vel kompatíbilis, de elsõ három bájtjában fix, a 802.2 fejlécnek megfelelõ tartalmú keretet ágyaz be, majd ezt követi a SNAP csomag 40-bites protokoll-azonosítója és az adatbitek. A SNAP csomagban a 802.2-es DSAP, SSAP és Control mezõinek helyén rendre a 0xAA, 0xAA, 0x03 értékek állnak, amik lehetõvé teszik a 802.3/802.2-es és a SNAP csomagok egyértelmû szétválogatását. Az 5-bájtos protokoll-azonosító pedig (szemben a 802.3 mindössze 7 bites hasonló jellegû mezõjével) nyilvánvalóan elegendõen nagy tartományt biztosít a belátható jövõben esetlegesen kidolgozásra kerülõ összes magasabb szintû protokoll egyértelmû megkülönböztetésére.
A SNAP protokoll azonosítója egyébként az Ethernet címekhez hasonlóan szintén két részre oszlik: az elsõ három bájtot a központilag adminisztrált és kiosztott OUI-k adják, míg a fennmaradó 2 bájttal a gyártók belül szabadon rendelkezhetnek. A gyakorlatban egyébként az elsõ három bájt tipikusan 0, míg a fennmaradó két bájtra az eredeti, Ethernet_II csomagokban is alkalmazott protokoll-azonosítók kerülnek, így gyakorlatilag az Ethernet_II hálózaton mûködõ protokollok minimális módosítással átvihetõk Ethernet SNAP alá is.
Ha szükséges, a kereteket a már említett kitöltõ bitek egészítik ki minimum 128-bitessé és végül az ún. FCS (Frame Check Sequence – Keret-Ellenõrzõ Sorozat) zárja. Ez nem más, mint egy 4-bájtos CRC ellenõrzõszám, ami a vételi oldalon a keret megelõzõ bitjei alapján újragenerálásra kerül, és ha a számolt és kapott összegek nem egyeznek, akkor a fogadó átviteli hibát feltételezve a csomagot eldobja.
Nincsenek megjegyzések:
Megjegyzés küldése