Óbudai Egyetem Keleti Károly Gazdasági Kar
Dr. Wührl Tibor
Irodai informatika II.
ÓE KGK 4018 Budapest, 2010.
Lektorálta: Gyányi Sándor
Felelős kiadó: Dr. Medve András az ÓE KGK dékánja Készült: az ÓE Nyomdájában Jegyzetszám: ÓE KGK 4018 Műszaki vezető: Bélteky István Példányszám: 100
Irodai Informatika II.
Dr. Wührl Tibor
Tartalom Bevezető ..................................................................................................................................... 4 1.
Nyilvános kapcsolt hálózatok és hozzáférési technikák fejlődése ..................................... 5 1.1.
Nyilvános kapcsolt telefonhálózat (PSTN) ................................................................ 6
1.2.
Nyilvános kapcsolt telefonhálózat, mint adatátviteli közvetítő hálózat (Dial-Up
hozzáférés) ............................................................................................................................. 9 1.3.
Nyilvános kapcsolt telefonhálózat megkerülésével, de annak infrastruktúrájával
történő hozzáférések............................................................................................................. 14 1.3.1.
ADSL hozzáférés ............................................................................................. 16
1.3.2.
SDSL hozzáférés .............................................................................................. 23
1.3.3.
VDSL hozzáférés ............................................................................................. 27
1.4.
1.4.1.
DOCSIS1.0, 1.1 és 2.0 ..................................................................................... 32
1.4.2.
DOCSIS3.0....................................................................................................... 33
1.5.
2.
3.
2
Kábel TV hálózattal megvalósított hozzáférés......................................................... 30
Optikai hozzáférési hálózatok, FTTx ....................................................................... 45
1.5.1.
BPON – Broadband–PON................................................................................ 49
1.5.2.
EPON – Ethernet PON ..................................................................................... 50
1.5.3.
GPON-Gigabit capable Passive Optical Network............................................ 52
Áramkör kapcsolt beszédcélú magán hálózatok .............................................................. 54 2.1.
Beszédcélú magánhálózatok interfészei................................................................... 55
2.2.
Beszédcélú magánhálózatok fontosabb szolgáltatásai ............................................. 57
2.2.1.
Hívásátadás folyamata...................................................................................... 58
2.2.2.
Konferenciabeszélgetés .................................................................................... 63
2.2.3.
Visszahívás kérése............................................................................................ 65
2.2.4.
PIN kódos felhasználó azonosítás .................................................................... 66
IP alapú útválasztás és csomagok továbbításának alapjai ................................................ 67 3.1.
IPv4 .......................................................................................................................... 68
3.2.
IPv6 .......................................................................................................................... 75
3.3.
IP – Internet Protocol ............................................................................................... 77
3.4.
ICMP – Internet Control Message Protocol ............................................................. 86
3.5.
TCP – Transmission Control Protocol ..................................................................... 87
3.6.
UDP-User Datagram Protocol.................................................................................. 92
4.
Csomagkapcsolt helyi hálózatok, LAN-ok ...................................................................... 94 4.1.
4.1.1.
Fizikai átviteli közeg ........................................................................................ 96
4.1.2.
Adatbitek illesztése a vezetékes fizikai átviteli közegre ................................ 107
4.1.3.
Adatkapcsolati réteg ....................................................................................... 111
4.2.
5.
Vezetékes helyi számítógép hálózatok..................................................................... 95
Vezeték nélküli helyi számítógép hálózatok .......................................................... 121
4.2.1.
Rádiós fizikai átviteli közeg, fizikai réteg...................................................... 124
4.2.2.
WLAN Adatkapcsolati réteg, közeghozzáférési eljárás................................. 133
4.2.3.
IEEE 802.11n – „Next generation” WLAN ................................................... 142
IP alapú hangátvitel ........................................................................................................ 143 5.1.
RTP és RTCP ......................................................................................................... 151
5.1.1.
RTP – Real-time Transport Protocol.............................................................. 151
5.1.2.
RTCP – Real TimeControl Protocol .............................................................. 153
5.2.
H.323 ...................................................................................................................... 156
5.3.
SIP – Session Initiation Protocol............................................................................ 160
6.
Összegzés ....................................................................................................................... 164
7.
Mellékletek..................................................................................................................... 165 7.1.
OSI referenciamodell ............................................................................................. 165
7.2.
Számrendszerek áttekintése.................................................................................... 169
7.3.
Az IP fejléc „Protocol” mező értékei és jelentése.................................................. 171
7.4.
ICMP üzenetek ....................................................................................................... 174
7.5.
TCP és UDP Portszámok táblázata ........................................................................ 175
7.6.
Az EtherType mező értékei és jelentése................................................................. 181
7.7.
Irodalom ................................................................................................................. 183
7.8.
Rövidítések jegyzéke.............................................................................................. 184
3
Bevezető Kedves Olvasó!
Ez a könyv az Irodai Informatika I. jegyzet folytatásának tekinthető. Míg az Irodai Informatika I. könyvben elsősorban az áramkör kapcsolt hálózathoz kapcsolódó irodai berendezésekkel foglalkoztunk, ez a könyv a beszéd-, és adatátviteli célú, helyi hálózatok áttekintését, és azok fontosabb protokoll elemeit tartalmazza. Fontosnak tartottam azt, hogy a nyilvános hálózatok fejlődéstörténetét is összefoglaljam. Az összefoglalás elsősorban a hozzáférési technikák (vagyis az előfizetői hozzáférési hálózat) kialakulását, annak formálódását mutatja be.
Jelen jegyzet írásánál törekedtem arra, hogy a leírtak olvasmányosak és könnyen megérthetőek legyenek. Az egyes hálózatok és informatikai rendszerek, protokollok ismertetésénél nem volt cél a teljes részletességű ismertetés, inkább a globális áttekinthetőségre törekedtem. Ahol a Kedves Olvasó mélyebb ismeretek elsajátítására vágyik, ott a szabványok és műszaki ajánlások tanulmányozását javaslom. A szövegrészben több helyen hivatkoztam IEEE, ETSI, ITU, CableLabs és RFC dokumentumokra, melyek legfrissebb változatai az Interneten elérhetők.
Munkámban sok kollégám volt segítségemre, sok hasznos tanácsot kaptam. Kiemelten szeretnék köszönetet mondani a lektornak, Gyányi Sándornak, valamint az ábrák készítőjének, Fekete Zoltánnak.
A jegyzetet elsősorban a Műszaki Menedzser Hallgatóimnak ajánlom, de hasznos lehet azon Villamosmérnök Kollégák számára is, akik e tématerülettel csak most kezdenek megismerkedni.
Eredményes, kitartó munkát kívánok!
A szerző
4
1. Nyilvános kapcsolt hálózatok és hozzáférési technikák fejlődése Az egymástól távol tartózkodó emberek kommunikáció-igénye a régmúltban gyökerezik. Abban az esetben, ha az információ csere megfelelő időben történik (vagyis az információ megérkezésekor az még nem évült el), akkor a kommunikáló felek jól mérhető előnyöket élveztek, és élveznek napjainkban is. Az információ csere sebessége, valamint az információ mennyisége egyre növekszik és jelenleg senki sem tudja megjósolni, hogy ez a tendencia meddig tart. Napjainkban, az információ gyors megszerzése alapfeltétele egy sikeres karriernek. Nem szabad viszont megfeledkeznünk arról sem, hogy a túlzott információ mennyiségben „elveszhetnek” a lényeges információ tartalmak. A gyakran emlegetett „Információs társadalom” felesleges információ áradata felőrli az egyéneket. A virtuális térben élő embereket számos veszély fenyegeti, például korunk új betegsége, az úgynevezett „Internet-függőség”. Természetesen ezzel senkit sem szeretnék elriasztani az „Informatikától”, sőt inkább az a célom, hogy megismertessem a nyilvános távközlő-, és informatikai hálózatok felépítését és működését. A fejlődéstörténeti áttekintés abban nyújt segítséget, hogy megértsük, megérthessük a jelenleg kialakult rendszereket. Nem szabad elfelejtenünk, hogy a fejlődést sok esetben nem a műszaki, technológiai vívmányok megjelenése dominálja. Jelentős fejlődést befolyásoló tényező a távközlő monopóliumok „akarata”, azok marketing stratégiája. A távközlésre nagy befolyással volt, és van a politika is. Hazánkban a rendszerváltás előtt a politika jelentősen korlátozta a kommunikációs lehetőségeket, lassította az információ-áramlás lehetőségét (például befagyasztott távközlő- és telefonhálózati fejlesztések, kísérletek az „imperialista” műsorszóró állomások
jeleinek
elnyomására stb.). Napjainkban is fontos szerepe van a politikának, ami reményeink szerint sokkal jobb szándékú. A távközlési törvény, valamint a távközléssel kapcsolatos kormányrendeletek kialakíthatják és élénkíthetik a versenyt a távközlés piacán. A szabályozások védhetik a fogyasztókat (előfizetőket), és rendezhetik az esetleges vitás helyzeteket a szolgáltatók és az előfizetők között. Ma Hazánkban a távközlő hálózatokat működtető szolgáltatók legfontosabb felügyeleti szerve az NHH (Nemzeti Hírközlési
5
Hatóság)1, korábban HÍF (Hírközlési Főfelügyelet), azt megelőzően pedig a PTF (Posta és Távközlési Felügyelet) volt. Fontos szerepe van a versenyhelyzet tisztán tartásában a GVHnak (Gazdasági és Verseny Hivatal).
1.1. Nyilvános kapcsolt telefonhálózat (PSTN) A nyilvános kapcsolt telefonhálózat, a PSTN (Public Switched Telephone Network) fejlődése a telefonközpontok kialakításától számítható. A telefonközpont feltalálója Puskás Tivadar. Az első működő telefonközpont 1877-ben valósult meg Bostonban. Puskás Tivadar 1879-ben, Párizsban helyezte üzembe második telefonközpontját. Ezt követően Pesten indult a következő központ, mely felépítésében Puskás Ferenc (Puskás Tivadar öccse) is részt vett. Még két érdekességet érdemes megemlíteni: • A telefonbeszélgetések elején elhangzó „Halló” szó a „Hallom”-ból származik, sok országban a „Halló” helyett bejelentkezéskor „Hallom”-ot mondanak. • Az
első
professzionális,
telekommunikációs
hálózaton
közvetített
broadcast
üzenetszolgáltatás - a „Telefon hírmondó” - is Puskás találmánya, mely szolgáltatás 1893. február 15-én indult.
A telefonhálózat belseje, az úgynevezett „mag hálózat” kapcsolóközpontok hierarchikus struktúrájából áll. A kapcsolóközpontok között az összeköttetést úgynevezett „trunk” áramkörök biztosítják. A kapcsolóközpontok közti, a kapcsoláshoz és a bontáshoz szükséges információk átvitelét az úgynevezett jelzéshálózat valósítja meg. Az előfizetői „fronton” az úgynevezett helyi kapcsolóközpontok, vagy azok kihelyezett fokozatai állnak.
1
A jegyzet kéziratának zárásakor az NHH szervezeti átalakításáról jelentek meg információk a sajtóban!
6
1.1-1. ábra. PSTN és előfizetői hozzáférési hálózata Az előfizetői hozzáférési hálózatot két érből álló réz vezeték biztosítja. Több próbálkozás is volt rádiós hozzáférések (például RLL) kialakítására, de ezek inkább szükségmegoldásként voltak használatosak. A réz alapú hozzáférési hálózat hossza néhány száz métertől általában maximum 4 – 5 km-ig terjed. A maghálózat (Core network) és a hozzáférési hálózat (Access network) kialakításának és karbantartásának aránya általában 30% / 70%-os, de speciális környezetben előfordulhat az is, hogy a költségek közel 90%-át a hozzáférési hálózat kialakítása és fenntartása jelenti. A fentiekből látható, hogy a PSTN igazán „értékes” része a hozzáférési hálózat és annak alépítményei. A PSTN hálózat az előfizetőket úgynevezett „vonalkapcsolással” kapcsolja össze és alakítja ki a beszéd átvitelét biztosító utat. A „vonalkapcsolás”, mint szakkifejezés helyett napjainkban inkább az „áramkörkapcsolás” (Ciruit switch) kifejezést használjuk, mivel a hálózatok digitalizálása miatt már nem tényleges vonalakat, vezetékeket kapcsolják össze, hanem az előfizetői végpontok közötti kapcsolatot lefoglalt áramkörök biztosítják. Az áramkörök foglalása a kapcsolat felépítésétől annak bontásáig tart. A lefoglalt erőforrásokhoz kizárólag a kapcsolatban résztvevők férnek hozzá, akár továbbítanak azon hasznos információt,
akár
nem.
A
nyilvános
kapcsolt
telefonhálózat
digitalizálódásának
eredményeképpen az összeköttetést a maghálózat általában egy „átlátszó” (transzparens) kétirányú (full-duplex) 64 kbit/s adatátviteli csatorna kiépítésével látja el. Az analóg kéthuzalos távtáplált telefonkészülékek a hozzáférési hálózaton keresztül kapcsolódnak a helyi kapcsolóközponthoz. Egy kábelrendező szekrényen keresztül a vezetékek a kapcsolóközpont úgynevezett előfizetői kártyáihoz csatlakoznak. Az előfizetői
7
kártyán valósulnak meg az analóg telefon illesztés funkciói, az úgynevezett „BORSCHT” funkciók. A „BORSCHT” funkciók jelentése a következő: B – Battery feeding; - egyenáramú távtáplálás funkcióját jelenti. O – Overvoltage protection; - túlfeszültség védelem. R – Ringing; - csengetés funkció. S – Signaling (régen Supervision Subscriber Loop-nak is nevezték); - előfizetői jelzések, jelzésváltások C – Coding; - PCM kódolás és dekódolás (A/D és D/A konverziók). H – Hybrid; - adás és vétel szétválasztás, vagyis 2/4 huzalos átalakítás. T – Test; - előfizetői vonalak tesztelés képessége. A BORSCHT funkciókról részletek az Irodai Informatika I. jegyzetben találhatók.
Az analóg hozzáféréssel rendelkező előfizetőknek a PSTN egy 300 – 3400 Hz sávszélességű és körülbelül 50dB dinamikatartományú kapcsolatot biztosít. A beszédjel digitalizálásának következtében ez a csatorna kvantálási hibával (kvantálási zajjal) terhelt, mely jel-zaj viszony érték a teljes dinamikatartományban - az úgynevezett „A” konverziós karakterisztikának köszönhetően - közel állandónak, mintegy 30 – 35 dB-nek adódik.
8
1.2. Nyilvános kapcsolt telefonhálózat, mint adatátviteli közvetítő hálózat (Dial-Up hozzáférés) Mint azt a megelőző részben láttuk, a PSTN hálózat analóg hozzáférési pontok között 300 – 3400 Hz frekvenciasávban biztosít analóg hozzáférést. A számítógépek közti kommunikáció speciális kívánalmainak megfelelően az 1960-as évek elején megjelent egy új kommunikációs elv, a csomagkapcsolás. A hidegháború idején a két nagyhatalom fegyverkezési versenyében az USA Védelmi Minisztérium figyelmét felkeltette egy olyan hálózat gondolata, mely hálózat kevésbé sérülékeny, mint az áramkör kapcsolt hálózatok. Az USA létrehozta a Defense Advanced Research Project Agency-t, vagyis a DARPA-t, melyen keresztül kutatás-fejlesztési finanszírozások valósulhattak meg. Egy ilyen K+F eredménye volt az ARPANET2, mely működése 1969-ben indult el. Ezt a hálózatot először kizárólag katonai bázisok közti kommunikációra, valamint kutatóhelyek kísérleteihez építették ki. A hálózaton fájlok cseréje, valamint levelezés zajlott. Az Internet kifejezés 1974 táján jelent meg, és az „Inter network”-ből származik. Az ARPANET felhasználását szigorúan ellenőrizték, civil hozzáférés ekkor még elképzelhetetlen volt. 1983 egy újabb mérföldkő volt a fejlődésben, ugyanis ekkor a kutatóhelyeket és a katonai célú hálózatrészeket leválasztották (katonai szegmens a MILNET kifejezést kapta). Ez után válhatott szabad felhasználásúvá a civil szféra számára a nem katonai szegmens. A civil szféra Internet hálózatát és annak működésével kapcsolatos tevékenységek főbb feladatait egy nonprofit szervezet látja el, az ISOC (Internet Society). Az ISOC-ot 1992-ben hozták létre, és bárki a tagja lehet a szervezetnek. A civil szféra Internet hozzáférésének kialakítása nehéz és költséges feladat. Ennek a hálózatnak kezdetben nem volt önálló hozzáférési hálózata. A felhasználók az Internet hozzáférését a telefonhálózattal, mint közvetítő hálózattal valósították meg.
2
Advanced Research Projects Agency Network
9
1.2-1. ábra. PSTN mint az Internet hozzáférését biztosító hálózat Az analóg csatornán a digitális átvitel úgynevezett digitális moduláció segítségével történhet. Ebben az esetben az analóg vivőt, ami általában egy harmonikus jel, az átvinni kívánt digitális jel modulálja, vagyis a vivő valamilyen fizikai jellemzőjét változtatja meg. Abban az esetben, ha a megváltoztatott vivő jellemző a vivő amplitúdója, akkor a modulációs eljárást ASK-nak (Amplitude Shift Keying) nevezzük, amit amplitúdó billentyűzésnek szokás fordítani. FSK (Frequency Shift Keying) a modulációs eljárás neve, ha az információt a vivő frekvenciájának elhangolásával visszük át, míg ha a vivő fázishelyzete hordozza az információt, akkor PSKról (Phase Shift Keying) beszélünk. A PSK és az FSK eljárásokat gyűjtőnéven „szögmodulációknak” is szoktuk nevezni. A vivő jel szöghelyzete és az amplitúdója egymástól független paraméter, ezért lehetőség adódik az amplitúdó moduláció, és valamely szögmoduláció egyidejű használatára. Tipikusan az ASK és a PSK eljárások egy vivőn alkalmazásával, digitális kvadratúra amplitúdó modulációs eljárást hozhatunk létre.
1.2-2. ábra. Digitális QAM konstellációs ábra 10
A QAM eljárásban használatos szimbólumokat úgynevezett konstellációs ábrán szokás szemléltetni. A komplex számsíkon megjelölt pontok egyértelműen definiálják az egyes szimbólumokat, vagyis megadják a vivő amplitúdóját (az origóból kiinduló, adott szimbólum pontba mutató vektor hossza), valamint a vivő fázishelyzetét (az origóból kiinduló, adott szimbólum pontba mutató vektor valós tengellyel bezárt szöge). Minden szimbólumhoz digitális bitcsoport rendelt, vagyis a fenti ábrán látható 16 állapotú QAM esetén egy szimbólum négy bit információt képes hordozni. Egy lehetséges kódolást láthatunk a következő ábrán:
1.2-3. ábra. QAM16 egy lehetséges kódolása A többszintű modulációs eljárások esetén – az előző ábrákon is szemléletesen látszik – a szimbólum sebesség és az adatátvitel sebessége különböző. A szimbólum sebességet [szimbólum/másodperc] egységben, vagyis [Baud]-ban szokás kifejezni, míg az adatátviteli sebesség egysége a [bit/s]. A példa szerinti 16 állapotú QAM esetén, ha a szimbólum átvitel sebessége 9600 Bd (Baud), akkor az adatátviteli sebesség ennek a négyszeresének adódik, vagyis 38400 bit/s. Ez természetesen nem azt jelenti, hogy ez a csatorna 100%-ban „hasznos” adatok átvitelére szolgál. Például FEC (Forward Error Correction) kódolás esetén a hasznos digitális csatorna sávszélesség a továbbítandó adat szempontjából 28800 bit/s. A következő ábra azt az egyszerű esetet szemlélteti, amikor az Internet szolgáltató (ISP – Internet Service Provider) analóg vonalon úgynevezett betárcsázós hozzáférést biztosít az előfizetőnek. Természetesen ez a hozzáférési technika már a múlté, hiszen magas költségek ellenére kis hozzáférési sávszélességet biztosított. Az ilyen rendszereket jelenleg leginkább
11
tartalék hozzáférésként használnak arra az esetre, ha a szélessávú hozzáférés valamilyen műszaki hiba miatt leállna. Internet hozzáférést biztosító szolgáltató
Számítógép
Modem
2
PSTN
2
ISP Számítógép
Modem
Felhasználó indítja az internet hozzáférés kapcsolat kiépítést ATD hívószám Hurok zár T-hang Hívószám 1 Hívószám 2
Hívószám n. Csengető jel cs-visszhang
RING ATA Hurkot Zár
1
PSTN Számlázás indul
„Beszédút”
felépítés
MODEMEK sebesség egyeztető eljárása + nyugta CONNECT
CONNECT
Virtuális digitális csatorna felépül
Felhasználó autentikáció ( USR név -PWRD ) 2
Internet számlázás indul
idő
1.2-4. ábra. Betárcsázós (Dial-up) hozzáférés analóg telefonvonalon A fenti folyamat során azzal a feltételezéssel éltünk, hogy a hívott vonal a hívás pillanatában szabad volt. Az ábrán a MODEM-ek és a számítógépek úgynevezett „AT” parancsokkal
12
kommunikálnak (az „AT” parancsokról bővebben az Irodai Informatika I. jegyzetben olvashatunk). A PSTN a beszédátvitelre alkalmas kapcsolatot a hívott MODEM hurok zárását követően építi fel. Ezt az idő tengelyen „1”-el jelöltük, és a PSTN ettől az időponttól jogosan megkezdi a számlázást. A MODEM eszközök szinkronizációja és sebesség egyeztetése is megkezdődhet, mely procedúra időtartama változó, ami elsősorban a kapcsolatban résztvevő MODEM-ek képességeitől és a telefonos beszédút minőségétől is függő paraméter. A sikeres egyeztetést követően kiépül az adat átvitelére alkalmas virtuális digitális csatorna, melyen megkezdődhet a felhasználó azonosítás, vagyis a bejelentkezés a szerver számítógépre. Előzőleg eltárolt felhasználó név és jelszó esetén az autentikáció tipikusan 1-2 másodperc, de ha ezeket a paramétereket most kell begépelnünk, akkor ez az időtartam akár néhányszor 10 másodpercre is növekedhet. Itt kell megjegyezni azt is, hogy az ISP-k a rendszerüket általában úgy állították be, hogy ha a hitelesítési folyamat néhányszor 10 másodpercen belül nem történt meg, vagy többször egymás után sikertelen volt, akkor a hívott MODEM bontást kezdeményezett azért, hogy feleslegesen ne legyen foglalt a behívó vonal. Sikeres bejelentkezést követően (miután az ISP azonosította a felhasználóját) indulhat a számlázás az ISP részéről (az idődiagramon ezt „2”-es ponttal jelöltük). A betárcsázós Internet hozzáférések esetén gyakori volt az időtartam alapú számlázás. Akkoriban tömeges panaszok érkeztek a hírközlést felügyelő hatósághoz (akkor PTF, illetve HÍF, jelenleg NHH) a számlázással kapcsolatosan, mivel a lelkes felhasználók összevetették telefonszámlájukat az ISP által adott számlával, és abban mindig túlszámlázást véltek felfedezni… A betárcsázós hívószámok először „normál” telefonszámok voltak, majd később külön számmező tartományba rendezték azokat. Egy szolgáltató természetesen több behívó vonallal rendelkezett, de egy behívó számmal azokat csoportba fogták össze, így a betárcsázó felhasználó mindig a következő szabad vonalat „kapta”, persze, ha éppen volt szabad vonal. Az Internet előfizetők számának növelését és az Internet, mint hálózat fejlődését különböző szabályozásokkal segítették elő. Ilyen szabályozás volt a közvetítő hálózat (PSTN) percdíj maximum rendelete, mely Internet elérés esetén volt érvényben. Látszólag csökkentette az Internet előfizetési díjakat és a hozzáférések díját az úgynevezett bevétel megosztás rendelete is. Ez a rendelet úgy tekintett az ISP-re, mint a PSTN számára üzletkötő félre, és így az Internet elérésből származó, PSTN oldalon kiszámlázott hozzáférési díj bizonyos százalékát (ennek mértékét többször is módosították) az ISP-nek kellett átadni.
13
1.3. Nyilvános kapcsolt telefonhálózat megkerülésével, de annak infrastruktúrájával történő hozzáférések Az elérhető maximális adatátviteli sebesség legnagyobb korlátját a PSTN maghálózata (core network) jelentette. A réz érpárból kialakított előfizetői hozzáférési hálózat jóval nagyobb tartalékokkal rendelkezett, így kézenfekvő volt az a megoldás, hogy a csomagkapcsolt hálózati hozzáférést továbbra is a réz hálózaton érjük el, de kerüljük ki a PSTN-t. A PSTN csomópont jellegű kialakítása miatt egy helyi kapcsoló központba néhány ezertől, néhány tízezerig terjedő vonalszám fut be. Az előfizetői forgalom első pontjának koncentrálását célszerűen itt kell megtenni. Az úgynevezett xDSL (Digital Subscriber Loop) technikák első változatai ezen gondolatmenet alapján alakultak ki. Az xDSL elnevezésben szereplő „x” helyére több betű is helyettesíthető, például „S”, vagy a talán elterjedtebb „A”. Az SDSL jelentése Symmetrical Digital Subscriber Loop, vagyis szimmetrikus, digitális előfizetői hurok. A „szimmetrikus” szó azt jelenti, hogy a fel- és a letöltési sebesség egymással megegyező mértékű, vagyis nem az elektromos szempontból kialakított földszimmetriára utal. Az ADSL jelentése „aszimmetrikus” digitális előfizetői hurok. Az aszimmetria jelen esetben azt jelenti, hogy a le-, és a feltöltési sebesség egymással nem megegyező, hanem figyelembe veszi a normál felhasználó Internet használati szokásait, és a letöltési sebesség nagyobb, akár négy-, ötszöröse is lehet a feltöltési sebességnek. Fontos kérdésként merült fel, hogy miként lehet versenyhelyzetet teremteni az xDSL szolgáltatások nyújtása terén? A versenyt elsősorban az gátolta, hogy a PSTN szolgáltatók (akik tulajdonában volt a réz alapú előfizetői hálózat), az egyes szolgáltatási terülteteken monopolhelyzetben voltak. Ismert tény, hogy az előfizetői hurok képezi a PSTN hálózat telepítési költségeinek 60-80%-át, de ez speciális helyszíneken akár 90% is lehet! Logikusan lehetett számítani arra, hogy a monopolhelyzetet élvező szolgáltató önként nem fogja átadni (még részlegesen sem) az előfizetői hozzáférési hálózatot a konkurenciát jelentő másik szolgáltatónak, ezért szükséges volt az állami beavatkozás, vagyis a jogi szabályozás. A szabályozó rendeletet, előfizetői hurok megosztásnak nevezzük, és az 2001. január 1-től hatályos. Fontos megemlíteni (de az évszámból persze kiderül), hogy ekkor még nem voltunk az Európai Unió tagja. A rendelet kötelezi a szolgáltatókat arra, hogy abban az esetben, ha egy előfizető és egy másik szolgáltató kíván előfizetői szerződést kötni egymással, akkor az előfizetői hurkot át kell
14
engedni az új szolgáltatónak. Természetesen az átengedést senki sem várhatja el ingyen, ezért az átengedés valójában bérbeadást jelent. A szabályozás pozitív hatásaként az egyes szolgáltatások árai csökkenni kezdtek, hiszen az egyes szolgáltatási területeken realizált extra profit sok versenytársat vonzott volna. Az előfizetői hurok megosztás (előfizetői hurok átengedés) két részre bontható: •
Előfizetői hurok teljes átengedése;
•
Előfizetői hurok részleges átengedése.
Az „előfizetői hurok részleges átengedése” fogalom tette lehetővé azt, hogy egy adott PSTN szolgáltatási területen egy másik szolgáltató biztosítson ugyanazon a hozzáférési ponton ADSL szolgáltatást.
A távközlési szolgáltatók „megbélyegzéseként” jelenik meg egy fontos fogalom, az úgynevezett Jelentős Piaci Erő (JPE). „Jelentős Piaci Erővel” rendelkezik jogi értelemben az a távközlési szolgáltató, amely adott szolgáltatási területen nagyobb, mint 25%-ban birtokolja a hálózatot és nagyobb, mint 25%-ban szolgálja ki az adott szolgáltatást igénybe vevő előfizetőket.
Az előfizetői hurok átengedését sokféleképpen szokták értékelni. Néhányan kudarcként jegyzik fel, hiszen az előfizetői hurok teljes átengedésével működő szolgáltatások általában 1% körüli mértéket mutatnak. ADSL szolgáltatások terén látszólag jobb a helyzet, hiszen több mint 20 ISP nyújt a Magyar Telekom és az Invitel szolgáltatási területein ilyen hozzáférést. Az ADSL versenyt ugyanakkor erősen korlátozza az, hogy az agregációs hálózat (amit az előfizetői hozzáférési hálózatot birtokló szolgáltatók kiépítettek), valamint a hurok megosztás bérleti díja az árakat jelentősen behatárolja. Nagymértékben befolyásolta az igazi verseny kialakulását, hogy a jelentős piaci erővel bíró szolgáltatók 2003-ban a hurokmegosztás bérleti díját nemhogy csökkentették, de még áremelést is tudtak kiharcolni. 2002. november 4-én az akkori MATÁV benyújtotta az előfizetői hurok átengedésére vonatkozó referencia ajánlatát „MARUO” néven. „Az ajánlat négy szolgáltatást foglal magában: előfizetői hurok teljes átengedése, előfizetői hurok részleges átengedése, fizikai betelepülés, külső betelepülés (az előfizetői hurok a sodrott réz érpárt jelenti). A teljes hurokátengedés havi díja 3.177 Ft-ról 3.544 Ft-ra nőtt, a részleges hurokátengedés havi díja pedig 3.118 Ft-ról 3.290 Ft-ra emelkedett.
15
A hurok átengedéséhez szükséges vizsgálat díja 36.705 Ft-ról 39.099 Ft-ra nőtt. Az átengedéshez kapcsolódó, 100 hurok kapacitású blokk biztosításának egyszeri díjai 93.071 és 364.772 Ft között vannak. A teljes, illetőleg részleges hurok átengedéséhez szükséges egyszeri rákötési díj 24.680 Ft-ra, illetőleg 27.484 Ft-ra emelkedett.
A hurokátengedéshez kapcsolódó fizikai és külső betelepülés egyszeri díjai havi díjakká kerültek átalakításra, nagyságuk a Matáv épületeiben, illetve az azokhoz tartozó telkeken szükséges átalakítás mértékétől és a klíma telepítésétől függően 39.156 Ft és 384.799 Ft között alakul.”3
A MARUO-t a Hírközlési Döntőbizottság fogadta el 2003 júniusában. A MARUO „hosszú távú, inkrementális költségek módszerén alapuló” referencia megállapodássá vált. A fenti okokból a piaci viszonyok befagytak, az ADSL hozzáférések díjai idővel mégis csökkenni kezdtek. Ennek oka elsősorban az volt, hogy az Internet hozzáférések más eljárásokkal is hozzáférhetőkké váltak (például mobil internet, valamint kábel TV hálózaton történő elérések).
1.3.1. ADSL hozzáférés Az ADSL hozzáférések olyan digitális csatornát alakítanak ki a réz hozzáférési hálózaton, mely segítségével a telefon szolgáltatás megtartása mellett, annak zavarása nélkül néhány megabit/szekundum sebességű letöltési sávszélesség biztosítható. A feladat persze nem egyszerű, hiszen a telefonos előfizetői vonalak, így azok paraméterei elsősorban a magasabb frekvenciákon meglehetősen sokfélék. A vonalak hosszúsága (helyi telefonközpont és az előfizető távolsága) néhány 100 métertől néhány kilométeres is lehet (Magyarországon maximum 4-5 km). A vezetékek futhatnak a földben, illetve földalatti alépítményekben, de az oszlopokra telepített légkábel sem ritka. A különféle hosszúságú és különféle földrajzi területeken áthaladó vezetékek különböző, helyszín- és napszakfüggő zavarjeleket szednek össze (például ipari zajok, AM rádióadók). Az ADSL összeköttetések frekvencia spektruma először 25 kHz-től indult. Ez a frekvenciahatár lehetővé tette az ADSL és a PSTN L2 POTS interfész megtartását, de az alapsávi ISDN esetén az ADSL együttműködés nem volt kompatibilis. Az alapsávi ISDN visszhangkioltós módszerrel üzemelő „U” interfésze a spektrumot körülbelül 100 kHz frekvenciáig veszi igénybe, ezért később az ADSL spektrum kezdetét feltolták a 100 kHz feletti frekvenciára. A korábban telepített PSTN előfizetői vonalakat (mely esetén nem szabad 3
Forrás: http://www.mfor.hu/cikkek/Elfogadtak_a_Matav_rendszeratengedesi_ajanlatat.html
16
elfeledkeznünk arról, hogy elektromos paraméterek szempontjából kizárólag a 300-3400Hz beszédsáv átvitelére tervezték) az adatátvitelre, ADSL hozzáférés esetén maximum (Annex-A szerint) 1,1 MHz-ig használjuk.
1.3-1. ábra. ADSL hozzáférés rendszertechnikája Az ADSL hozzáférés esetén a réz érpáron a digitális adattovábbítás az előfizető oldali DSL MODEM és a „központ oldali” DSLAM (Digital Subscriber Line Access Multiplexer) berendezés között zajlik. A DSLAM több előfizető forgalmát gyűjti össze, és szélessávú adatcsatornán továbbítja azt a csomagkapcsolt hálózat irányába. Ezt a hálózati szakaszt szokás DSL agregációs hálózatnak nevezni. Az átviteli eljárás ATM alapú volt, de mivel az ATM hálózatok kiépítése és üzemeltetési költsége relatív magas, ezért az Ethernet alapú megoldások kerültek előnybe, és manapság szinte mindenhol ezt alkalmazzák. A DSLAM eszközök (több egységből álló berendezés komplexumok) néhányszor 10 előfizetőtől több ezer előfizető koncentrálását is elvégzi.
A réz előfizetői vonali paraméterek sokrétűsége, és az egyes vonalak közti zavartatás különbség figyelembevételével olyan
eljárást kellett kidolgozni,
mely általánosan
alkalmazható a meglévő előfizetői vonalak túlnyomó részén. A rendelkezésre álló 1 MHZ sávszélességet 4 kHz-es sávokra osztották. Adott tehát egy – előfizetői vonalanként eltérő zajos átviteli csatornánk. A zajok és zavarok spektruma is más és más lehet. Egyes zavaró
17
jelek spektrális elhelyezkedése helyszín és napszakfüggő (például helyi AM rádióadók, ipari zavarok). Az ADLS-nél alkalmazott adatátviteli módszert DMT (Discrete Multi Tone) modulációs eljárásnak nevezzük. Fontos megjegyezni, hogy a DMT-t megelőzően alkalmaztak egy a DMT-vel nem kompatibilis eljárást, melyet CAP-nak (Carrierless Amplitude Phase) neveztek, de ez napjainkban már nem használatos.
1.3-2. ábra. ADSL spektrumok A DMT esetén maximálisan 255 db 4 kHz csatorna definiált (az elfoglalt sávszélesség pontosan 4,3125kHz, amit vivőtávolságnak is szoktak emlegetni), melyben digitális QAM-el történik az adat továbbítás. A feltöltési irányra maximum 31 db csatornát, úgynevezett „upstream bin”-t különítettek el, míg letöltésre 224 db csatorna (downstream bin) állhat rendelkezésre. Az elméletben megadott csatornaszám 255 ⋅ 4,3125kHz = 1099,6875kHz frekvenciaigényt támaszt, mely alapján azt látjuk, hogy közelítőleg 0 Hz frekvencián kellene lennie a sávhatár alsó határának. A 255 csatorna használata tehát csak akkor valósítható meg, ha a vonalon áramkör kapcsolt szolgáltatás (POTS vagy alapsávi ISDN) elérés nincs.
Az áramkör kapcsolt hálózat hozzáférését biztosító frekvenciasávot, az ADSL által felhasznált frekvenciasávtól analóg alul-, és felüláteresztő szűrőből álló komplexummal valósítják meg, melynek neve „splitter”. A splitter feladata az, hogy „kettévágja” a két szolgáltatás által igényelt frekvenciasávot. Abban az esetben, ha ezt a szétválasztást nem tennénk meg, akkor a telefonszolgáltatás hasznos jele az ADSL számára zajként jelentkezne, valamint az ADSL
18
hasznos jele zajt eredményezne a telefon szolgáltatásban. Ez utóbbit az emberi fül azonban nem képes érzékelni, valamint a telefonkészülékek aluláteresztő szűrő jellegű átvitele miatt a szűrési funkció nagy részét ellátja maga a végberendezés. A splitter eszköznek 3 db kétvezetékes csatlakozási pontja van. Az egyik csatlakozási pontra magát a szolgáltató felöl érkező telefon vezetéket kell kapcsolni. Ezt a csatlakozást általában „LINE” felirattal látják el. A másik két csatlakozón a „PHONE” és „MODEM” feliratot szokás feltüntetni, melyhez értelemszerűen a telefonkészüléket, illetve a DSL MODEM eszközt kell csatlakoztatni. „PHONE” felirat helyett elő szokott fordulni a „POTS/ISDN” felirat, és a „MODEM” helyett a „DSL” mozaikszót is szokták alkalmazni. Fontos megjegyezni, hogy a splitter egy passzív analóg szűrőkomplexum, mely általában induktív (L) és kapacitív (C) tagokból épül fel. A splitter frekvenciája nem hangolható, így mindig a megfelelő konfigurációhoz illeszkedő splittert kell alkalmazni. A gyakorlatban sokszor a splitter felépítése sokkal egyszerűbb és gyakran elhagyják a felüláteresztő szűrőt. Ebben az esetben a vonali csatlakozás és az ADSL MODEM csatlakozó közti kapcsolatot egyszerű vezetékek biztosítják. Az alábbi szűrő felépítés egy precíz leválasztást biztosít a POTS szolgáltatások számára, és a telefonkészülék felől érkező zavarok szűrése is hatékonyan valósul meg, de a rendszerből a felüláteresztő tagot egyszerűen elhagyták:
1.3-3. ábra. ADSL – POTS egyszerűsített splitter elvi kapcsolási rajza
A szűrőben túlfeszültség védő tagokat is láthatunk, melyek 250V feletti impulzusokat söntölik. Az F1 és F2 olvadóbiztosítékok szintén a túlfeszülség védelmet szolgálják. A LINE és a telefon csatlakozó között a névleges lezárások alkalmazásával a következő csillapításkarakterisztikát vehetjük fel a frekvencia függvényében:
19
1.3-4. ábra. Splitter beiktatási csillapítás a frekvencia függvényében a „LINE” és a „TEL” kapcsok között
Analóg kéthuzalos távtáplált telefon interfész esetén célszerű lenne a 4 kHz és a 25 kHz közötti sávban váltó szűrő alkalmazása, de a szolgáltatók gyakran az ISDN képes eszközöket választják. A magasabb frekvenciára helyezett váltási-frekvencia működési gondot nem eredményez sem a POTS, sem pedig az alapsávi ISDN esetén. POTS „együttélés” esetén azonban 20 – 26 db BIN-t dobunk el, ami azt jelenti, hogy értékes csatornák maradnak kihasználatlanok. A vonali paraméterektől és a helyszíni adottságoktól függően az egyes 4kHz sávszélességű csatornákban a bit hibaarány különböző lehet. Rossz bit hibaarányt mutató csatornák az átvitelből kizárhatók, ami persze az elméleti maximális le- és feltöltési sebesség értékét csökkenti. A gyakorlati tapasztalat azt mutatja, hogy az ANNEX-A ADSL szabvány szerint működő eszközök letöltési irányban a maximális letöltési sebességet (körülbelül 8 Mbit/s, ha minden ideális és egyetlen BIN-t sem dobunk el) csak akkor képesek biztosítani, ha az előfizetői vonal hossza rövidebb, mint 3 km. 3 és 4 km hosszúságú vonalakon a maximálisan elérhető sebesség 6 Mbit/s, míg 4-5 km esetén ez az érték akár 2 Mbit/s sebességre is korlátozódhat.
20
1.3-5. ábra. Tipikus ADSL csatornák és azok kihasználtsága A BIN-ek, vagyis a körülbelül 4 kHz sávszélességű csatornák mindegyikében több szintű digitális kvadratúra amplitúdó modulációt (QAM) alkalmazunk a bitek továbbításához. A többszintű moduláció miatt egy szimbólum több bitet szállít. A szállított bitek száma függ az adott csatorna minőségétől, elsősorban annak jel-zaj viszonyától. A fenti ábrán látható, hogy az egyes BIN-ek különböző számú hasznos adatbit szállítására képesek, és vannak olyanok is, melyek egyáltalán nem szállítanak információt. A le- és feltöltés sávok elválasztásához gyakran 2, 3 vagy akár ennél nagyobb számú BIN használatát is tilthatják. Ez elsősorban gyártótól függő kialakítás. Azoknak a csatornáknak, melyek erősen zavartak szintén kitiltás a sorsuk. Több csatorna tiltása pedig azért valósul meg, mert az előfizető sávszélességét az előfizetői szerződésben megadott sávszélességre korlátozzák. Ez logikus, hiszen a kisebb sávszélességet vásárló előfizető is ugyan azt az eszközt (MODEM-et) kapja a szolgáltatás eléréséhez, mint a nagyobb sávszélességre szerződő ügyfél. Az előbb említett okból lehetett egyszerűen megoldani a 2004 év végén, 2005 év elején végrehajtott sávszélesség „duplázást”, mely során az ADSL hozzáférést biztosító szolgáltatók a letöltési sebességet az alábbi módon megemelték: Letöltési sebesség a
Letöltési sebesség a
sávszélesség emelést
sávszélesség emelés után:
megelőzően: 384 kbit/s
512 kbit/s
512 kbit/s
1024 kbit/s
768 kbit/s
1,5 Mbit/s
1,5 Mbit/s
3 Mbit/s
21
A sávszélesség emeléshez nem kellett mást tenni, mint a konfigurációs paramétert megváltoztatni. A konfiguráció módosítását elegendő volt a központ oldalon (DSLAM eszközben) elvégezni, így az előfizetőhöz nem kellett kiszállni. További sávszélesség emeléseknek is tanúi lehettünk 2006 év végén és 2007 év elején. Ez a kampány több előfizetőnél is gondot okozott, hiszen a vonal minősége (jel-zaj viszony), valamint a vonal hosszúság (elsősorban csillapítási paraméter) nem tette lehetővé a 3 Mbit/s-ról a 6 Mbit/s-ra átállást. Az előfizetői panaszok egy részét az adott vonal vizsgálatát (mérését) követő javítás elhárította, de egyes helyeken a műszaki megoldás jelen ADSL technikánál nem állt rendelkezésre. Ekkor adminisztratív eszközökkel lehetett feloldani a problémát (például tarifacsökkentés). Azoknak az előfizetőknek, akik az adott helyszínen nagyobb sávszélességre vágytak, nem volt más lehetőségük (persze, ha volt egyáltalán lehetőség rá), minthogy hozzáférési technikát váltott. Gyakori volt az ADSL lecserélése kábel TV hálózati hozzáférésre.
Az ADSL szabványosítás 1997-ben kezdődött (ITU első hivatalos ADSL-lel kapcsolatos ülés évszáma). Az első ajánlás 1998-ban jelent meg, melyet 1999-ben az ITU G.992 sorozat ajánlás gyűjteményé egészített ki. A szabványosítás folyamata nagyon felgyorsult, és még ebben az évben megjelentek a G VDSL-re vonatkozó előírások. További fontos évszámok:
22
-
2001. G SHDSL;
-
2002. ADSL2;
-
2003. ADSL2+;
-
2004. VDSL.
1.3.2. SDSL hozzáférés Az SDSL jelentése Symmetrical Digital Subscriber Line, ami olyan digitális hozzáférést jelent, ahol a le- és a feltöltési irány adatátviteli sebessége szimmetrikus. A szimmetrikus hozzáféréseket az ITU, 2001 februárjában szabványosította G.SHDSL gyűjteményében, a G.991.2 ajánlás sorszám alatt.
1.3-6. ábra. SDSL hozzáférés referencia konfiguráció Az SDSL referencia konfigurációban két eszköz szerepel. Az NTU (Network Termination Unit) az előfizetőnél elhelyezkedő hálózat végződtető pont, míg a központ oldalon az LTU (Line Termination Unit). Az SHDSL „Single-pair High-speed Digital Subscriber Line” egy tágabb fogalom (ez az elnevezésében is szerepel), mivel olyan átviteli eljárásokat rendszerez, melyek egy érpáron, nagy sebességű digitális átvitelt képesek biztosítani. Az ETSI is megtette a szabványosítási lépéseket ezen a területen. Az ajánlást SDSL néven rögzítették és európai viszonylatban a szakmai tartalom megegyező az ITU-T G.SHDSL ide vonatkozó pontjaival. Az ehhez a témához kapcsolódó ETSI dokumentumok az ETSI TS 101 524 kód alatt találhatók4. Az SDSL témát (valószínűleg szolgáltatói elvárások miatt) gondosan elválasztják az ADSL hozzáférésektől, de ha belegondolunk, hogy miben is különbözik (különbözhetne) a két technológia, arra jutunk, hogy igazán nem sokban. Felmerül a kérdés, hogy mi a jelentősége a szétválasztásnak, hiszen ADSL eszközökkel is biztosítható (elvben) szimmetrikus le- és feltöltési irányú sávszélesség, ugyanis nem kell mást tenni, mint ugyanannyi sávszélességet kell biztosítani a feltöltésre, mint a letöltésre, akár a letöltésre szánt BIN-ek számának a rovására. 4
Regisztrációt követően az ETSI ajánlások PDF formátumban a www.etsi.org oldalról letölthetők.
23
Az SDSL hozzáférés felhasználási területe eltér az ADSL felhasználásától, hiszen ez utóbbit az Interneten szörföző felhasználóknak fejlesztették, és tömegtermékké vált. Az SDSL hozzáférésen szerver számítógépet is jól lehet üzemeltetni, hiszen a tartalom szolgáltatás esetén a szerver gép szempontjából a feltöltési iránynak is erősnek kell lennie. A szerverüzemeltetésre és a külön telephelyeken található vállalati helyi hálózatok (LAN-ok) összekapcsolására a szolgáltatók úgynevezett bérelt vonali összeköttetéseket biztosítanak. A bérelt vonali összeköttetések korántsem nevezhetők olyan tömegterméknek, mint az ADSL kapcsolatok, így a bérelt vonali szolgáltatások árai is jóval magasabbak, vagyis marketing szempontból nem érdemes összemosni az ADSL alapon árusított „termékkel”. Az igazsághoz persze az az egyáltalán nem elhanyagolható dolog is hozzátartozik, hogy a magasabb ár megbízhatóbb szolgáltatást, magasabb adatbiztonságot és jobb rendelkezésre állást biztosít. A szerződő felek (a szolgáltató és az előfizető) gyakran külön SLA megállapodást kötnek, melyben szabályozzák a kötbér mértékét szolgáltatás kiesés esetén. Természetesen ADSL előfizetők esetén is van ilyen szerződés, de a szerződés ekkor általánosnak tekinthető és annak feltételeit az úgynevezett ÁSZF (Általános Szerződési Feltételek) dokumentum tartalmazza. A szolgáltatóknak az ÁSZF-hez való hozzáférést biztosítaniuk
kell
(például
honlap
letölthetőség,
illetve
ügyfélszolgálaton
annak
hozzáférhetősége). Az ÁSZF-et életbe léptetése előtt a szolgáltató minden esetben megküldi a Nemzeti Hírközlési Hatóságnak (NHH-nak). Az ETSI TS101 524 ajánlás értelmében az SDSL keretszervezése a következő:
1.3-7. ábra. SDSL keretszervezés (ETSI TS 101 524)
24
Az SDSL keretszervezés a hasznos átvitt adat szempontjából 192 kbit/s adatátviteli sebességtől 2,312 kbit/s sebességig támogatja az átvitelt. Az átvitel történhet szinkronizált módon, vagy plesiochron üzemmódban. Ez utóbbit a PCM rendszerek alkalmazzák, ahol az átvitelt biztosító eszközök órái nem szinkronizáltak, ezért az egyes berendezéseknél a PCM hierarchiában szükségessé válik az eltérő sebességek kiegyenlítése. A kiegyenlítést az úgynevezett „stuffing” bitek beszúrásával, illetve elhagyásával lehet megtenni. Szinkron átvitel esetén a „stuffing” bitek nem értelmezhetők, ekkor a kiegyenlítő bitek helyén fix állapotú, úgynevezett „tartalék” (spare) biteket láthatunk. A keret időtartama 6ms. Minden keret egy 14 bitből álló szinkronizáló szóval (Sync word) kezdődik. A szinkronizáló szó minden esetben az ’11111100001100’ alakot kapja. A szinkronizáló szót kettő SDSL fejléc (SDSL OverHead) bit követi. A további fejléc bitek (további 3 x 10 bit) a keret belsejében találhatók. A fejléc bitek státusz információkat, valamint a hibafelfedéshez szükséges CRC-t tartalmazzák.
A fejléc (OH – OverHead) tehát 2+10+10+10=32 bitből áll, melyek jelentése és funkciója a következő:
losd-bit (loss of signal) [1 bit] – Abban az esetben, ha a felhasználói interfészen nincs detektálható jel, akkor ez a bit ’0’-ba vált. Normál körülmények között ez a bit ’1’ értéken áll.
sega-bit (segment anomaly) [1 bit] – A vett SDSL keretek CRC hibáját tünteti fel. Hibás keret vétele esetén ez a bit ’0’ értéket vesz fel, míg normál működési körülmények között az értéke ’1’.
segd-bit (segment defect) [1 bit] – Ez a bit a szinkronizáció elvesztését jelzi, ha az értéke ’0’. Normál működés, vagyis helyesen szinkronizált vétel esetén a bit ’1’-ben áll.
eoc-bitek (embedded operation channel) [20 bit] – Ezek a bitek egy üzemviteli csatornát alakítanak ki, melyek segítségével a hálózat menedzselése megvalósítható.
CRC-bitek (Cyclic Redundancy Check) [6 bit] – Segítségével ismerhető fel az adott keret hibája. A CRC számítás az x6+x1+x0 generátorpolinommal (’1000011’) történik.
ps-bit (power supply) [1 bit] – A ps bit a helyi (NT oldali) tápellátás hibáját (annak kimaradását) indikálja. Hiba esetén a bit értéke ’0’, míg normál működési körülmények esetén ennek a bitnek az értéke ’1’.
sbid-bit (stuff indicator) [2 bit] – Plesiochron működés esetén a bit beszúrást „stuffing”ot, és a beszúrt bitek számát jelzi. 25
Az SDSL keretben a hasznos információt az úgynevezett Payload Blokk-ok szállítják. Egy keretben összesen 4x12 blokk szerepel. Minden Payload blokk i + n x 8bit –ből áll, ahol i=0…7, illetve n = 3…36. Az „i” az úgynevezett ’Z’ csatorna bitszámát mutatja, melyeken fenntartói üzenetek, illetve jelzésüzenetek átvitele történhet. Az „n” az átvitt „B” csatornák számát jelöli. Az i=1, és az n=36 esetben az SDSL keret teljesen kompatibilis az ETSI TS 101 135 ajánlásban szereplő HDSL kerettel.
Az összeállított keret a fizikai rétegen történő továbbítást megelőzően egy bitkeverésen (scrambling) esik át. A bitkeverés („szépen” magyarul szoktuk „szkremblerezésnek” is hívni) egy megszokott eljárás a digitális adatátviteli eljárásoknál. A bitkeverés célja elsősorban az, hogy az átvitt jel leginkább egy véletlen jelhez hasonlítson. Az ilyen tulajdonságú jelek kellemesebben vihetők át, jobban kinyerhetők belőle a szinkron információk stb. A bitkevert jel első ránézésre titkosítottnak is tűnik, de valójában nem az, mivel a scrambler szekvencia pontosan ismert. Az SHDSL úgynevezett önszinkronizáló bitkeverést alkalmaz, amely a hálózat végponttól (NT-től) a vonal-végig (LT-ig) az x-23+x-18+1 polinomot használja, míg fordított irányban (LT-től az NT-ig) az x-23+x-5+1.
A bitkeverést követően a jelet 2B1Q módszerrel kódolják. A 2B1Q egy általánosan elterjedt vonali kódolás, mely a „two-binary, one-quaternary” kifejezésből ered. Az átvinni kívánt biteket bitpárokba csoportosítjuk, és az egyes bitpárok által képviselt értéknek megfelelően azokhoz egy-egy egyértelműen megkülönböztethető vonali szintet rendelünk:
bitpár
Vonali szint:
00
- 450 mV
01
- 150 mV
10
+ 450 mV
11
+ 150 mV
A 2B1Q vonali kódolás nem garantálja a kereten belüli DC kiegyenlítést, vagyis az átvitt információ tartalmától függően a vonali kódolt jelnek egyenfeszültség tartalma is lehet. A bitkeverő eljárás (scrambling) statisztikailag segít ezen a problémán.
26
1.3.3. VDSL hozzáférés A VDSL elnevezése a nagy sebességű átvitelt emeli ki (Very high bitrate Digital Subscriber Line). A hozzáférési technika sok rokon vonást mutat az ADSL-lel, hiszen a DSLAM-tól az előfizetőig a PSTN hálózat korábbi réz érpárja biztosítja a kapcsolatot. Egy fontos dologban viszont eltérnek egymástól, az pedig a réz szakasz maximális megengedett hossza. A korábban akár 4 – 5 km hosszúságú réz szakasz maximum 1,5 km lehet. A földrajzilag a kapcsolóközponthoz közel található előfizetők (rövid réz előfizetői vonallal kapcsolódó) előnyös helyzetben vannak, mert VDSL technológiával lényegesen nagyobb letöltési sebességek érhetők el, mint az ADSL esetén. A kapcsolóközponttól távol elhelyezkedő előfizetők esetében a „hegynek kell Mohammedhez menni”, vagyis a réz előfizetői szakasz úgy rövidíthető, hogy a DSLAM-ot közelebb telepítik (például szolgáltatással ellátandó utca sarkára) az előfizetői hozzáférési ponthoz. Ez a megoldás rokon jegyeket mutat a később tárgyalt FTTx technológiával! A közelebb telepített DSLAM eszköz mellett plusz költségként jelentkezik az, ha a réz előfizetői vonalszakaszon analóg vagy ISDN telefonos szolgáltatás is van. Ebben az esetben az áramkör kapcsolt hálózat kapcsolóközpontjának az előfizetői szerelvényeit (illetve annak érintett részeit) is a DSLAM mellé kell telepíteni, és PCM vonalon a kapcsolóközponthoz kell továbbítani az információkat (64 kbit/s adat- illetve beszédcsatornákat, valamint jelzésinformációkat).
A VDSL sebesség maximumokat a következő táblázat foglalja össze:
Réz előfizetői hozzáférési
Maximális elérhető adatátviteli
hálózat maximális hossza:
sebesség a letöltési irányban:
0,0 km
100 Mbit/s
0,5 km
60 Mbit/s
1,0 km
40 Mbit/s
1,5 km
25 Mbit/s
A VDSL műszaki jellemzőit az ITU-T G.993:1 ajánlás foglalja össze. A
VDSL
továbbfejlesztése
VDSL2,
illetve
VDSL2+
elnevezéssel
jelent
meg.
Szabványosítása az ITU-T G.993:2 ajánlásban valósult meg. VDSL2 esetén a VDSL-nél magasabb adatátviteli sebességek érhetők el, melyek elméleti határai a következők: 27
Réz előfizetői hozzáférési
Maximális elérhető adatátviteli
hálózat maximális hossza:
sebesség a letöltési irányban:
0,0 km
200 Mbit/s
0,5 km
100 Mbit/s
1,0 km
50 Mbit/s
1,6 km
VDSL szerint működik 25 Mbit/s
Mint azt előzőleg említettük, a VDSL rendszertechnikája nagyon hasonlít az ADSL-hez, de az ajánlásokban az egyes eszközök terminológiája megváltozott. Az alábbi ábrán (forrás ITU-T G.993.2 ajánlás) a baloldalon elhelyezkedő eszközök jelentik a hálózati oldalt, míg a jobb oldalon az előfizetői hálózat végződtető eszközök és végberendezések láthatók.
1.3-8. ábra. VDSL rendszertechnika (ITU-T G.993.2) A lerövidített réz alapú hozzáférési hálózat (copper pair) teremti meg a kapcsolatot az utolsó métereken az előfizetőhöz. Itt meg kell jegyeznünk egy érdekes dolgot az előfizető felé tartó „utolsó méterekről”! Angol elnevezés szerint létezik egy úgynevezett EFM hozzáférés, melynek rövidítés feloldása „Ethernet to The First Mile”, vagyis „első mérföld” (ezen talán érdemes egy picit elgondolkodnunk – minden kedves olvasóra rábízom a következtetések levonását)! Az EFM egy hozzáférési technikákat összefoglaló gyűjtőnévnek tekinthető. Minden olyan hozzáférési technika mely Ethernet kereteket továbbít a hozzáférési hálózati szakaszon, ebbe
28
a
kategóriába
soroljuk.
Valójában
az
Ethernet
keret
beillesztése,
úgynevezett
„enkapszulációja” történik meg az átvitel során. Az Ethernet keretformátumot és annak jellemzőit a helyi hálózatok (LAN-ok) témakörnél tekintjük át. A VDSL rendszertechnika ábrán az adatátviteli célú berendezéseket „User Terminal”-nak, míg a beszéd célú eszközöket „Voice Terminal” eszközöknek nevezik. Az ADSL-nél megismert „splitter” eszközt kettő különálló blokkal szemléltetik (HPF – High Pass Filter, illetve LPF – Low Pass Filter). A HPF és az LPF együttes funkciója itt is a frekvencia sáv kettévágását hivatott szolgálni. A GSTN is új terminológiaként jelent meg, ahol a „P” (PSTN) helyett használt „G” a „General” szóra utal. Ez azzal indokolható, hogy az eddig áramkör kapcsolt nyilvános telefonhálózat alkotta beszédcélú kapcsolat hálózatban is megjelentek az úgynevezett „Soft Switch” eszközök, melyek nem feltétlenül az áramkör kapcsolás szabályai szerint látják el a kapcsolási funkciókat, de a kéthuzalos analóg interfészen (L2) megismert BORSCHT funkciókkal megegyezően biztosítják az előfizetői hozzáférést. A rendszermodellben a DSLAM funkciót az AN (Access Node), míg az előfizetőnél telepített VDSL Modem funkciót a NT (Network Termination) testesíti meg. A VDSL spektrum felhasználás is módosult a korábbi ADSL-hez képest. A VDSL technikák a lerövidített réz szakaszon körülbelül 30 MHz szélességben veszik igénybe a frekvenciaspektrumot. A VDSL ajánlások a spektrum felosztást két lépésben tárgyalják. Az első lépésben a 12MHz alatti frekvenciákat öt részre osztják.
1.3-9. ábra. VDSL spektrum 12 MHz frekvencia alatti sávban (ITUT G.993.2) Az US0, US1 és US2 tartományokat kizárólag a feltöltési irányok veszik igénybe, míg a DS1 és DS2 tartományban a letöltés irány adatai érkeznek. A 12MHz – 30MHz tartomány kihaszálhatóságáról kizárólag a VDSL2 és VDSL2+ ajánlások rendelkeznek. A VDSL technológiák az adatok továbbítására az ADSL-nél jól bevált DMT-t használják. A VDSL2 esetén a kiterjesztett spektrum jóvoltából 4096 alvivő áll (állhat) rendelkezésre.
29
1.4. Kábel TV hálózattal megvalósított hozzáférés Mint azt az előzőekben láttuk, a távközlő és informatikai hálózatoknál a legproblémásabb és a talán a legköltségesebb az előfizetői hozzáférési szakasz. Napjainkban a számítógépes hálózatokhoz egyre nagyobb sávszélességű hozzáférésre van igény. A multimédiás tartalmak ezt az elvárást egyre csak erősítik. A képi információt hordozó multimédiás tartalmak felbontása, így mérete is egyre növekszik. A HD (High Density) minőségű tartalom egyre általánosabb, ami folyamatos lejátszás esetén (720p, 1080i formátum esetén, MPEG-4 kódolással) 6-8 Mbit/s folyamatos letöltési sebességet feltételez. A valódi szélessávú hozzáférések költséghatékony kialakításához jó alapot szolgáltatnak a kábeltelevíziós hálózatok, melyek többsége kétirányú adatátvitelt is lehetővé tesz (úgynevezett „kétirányúsított”).
Napjainkban a kábeltelevíziós hálózatok koaxiális kábellel kialakított szegmenseinek felső határfrekvenciája körülbelül 860 MHz-re tehető, de a mai technológiával (ami természetesen hálózati építőelemek cseréjét jelenti) ez kiterjeszthető 1 GHz, vagy magasabb frekvenciára is. Jelenleg műsorszórásra többnyire a 108 MHz - 862 MHz között rendelkezésre álló sávot használjuk, míg a visszirányú (feltöltési irány – „upstream”) kommunikációra a körülbelül 5 MHz-től az 50 MHz-ig terjedő sáv áll rendelkezésre.5 Az európai SD analóg TV csatornák sávszélessége miatt a rendelkezésre álló frekvenciasávot 7, illetve 8 MHz sávszélességű csatornákra osztották fel. A kétirányú koaxiális szegmensen többszintű digitális modulációs technikákkal kétirányú digitális csatorna alakítható ki.
A DOCSIS (Data Over Cable Service Interface Specifications) ajánlást a CableLab és több közreműködő cég (ARRIS, BigBand Networks, Broadcom, Cisco, Conexant, Intel, Motorola, Netgear, Terayon és a Texas Instruments) dolgozta ki. A DOCSIS ajánlások a kommunikáció módját definiálják a kábel hálózaton. A DOCSIS 1.0 specifikációk 1997 márciusában jelentek meg, míg annak revíziója - DOCSIS 1.1 – 1999. áprilisban.
5
A frekvenciák a helyi adottságok (elsősorban a koaxiális szegmens műszaki paraméterei miatt) függvényében a fentiektől eltérhetnek! A DOCSIS3.0 ajánlások a letöltési irány csatornáinak elhelyezését 47-1002MHz sávon belül bárhol megengedik.
30
További fejlesztés vált szükségessé a valós idejű szolgáltatások megjelenése miatt. A DOCSIS 2.0 ajánlások 2001 decemberében kerültek kibocsátásra, mely ajánlásban szerepelt a megnövelt feltöltési adatátviteli sebesség, valamint a QoS (Quality of Service) képesség. A DOCSIS3.0 ajánlás tervezete 2006 augusztus hónapban jelent meg, de már 2009 év végén a DOCSIS4.0 ajánlásról beszélt a szakma (ez utóbbi ajánlás, illetve annak tervezete a jegyzet írásának időpontjában még nem jelent meg).
Az egyes DOCSIS berendezések ajánlás-megfelelőség ellenőrzését a CableLab végzi és hozza nyilvánosságra. Az ITU (International Telecommunication Union Standardization Sector) ratifikálta a DOCSIS 1.1 és a DOCSIS 2.0 ajánlásokat. Az előbbit ITU-T J.112 (Annex B), míg az utóbbit ITU-T J.122 jelentette meg. Érdekességképpen meg kell említeni, hogy az ITU-T J.112 Annex A írja le a korábbi Európai kábel modem rendszereket (DVB EuroModem), melyek ATM-en alapulnak, valamint az Annex C definiálja a Japán kábel rendszereket.
A frekvencia allokáció az Amerikai Egyesült Államok és az Európai CATV rendszerekben jelentősen eltér, mivel a TV csatornák sávszélessége különböző, ezért a DOCSIS szabványok európai verziója (módosítása) is megszületett EuroDOCSIS néven. Az amerikai és az európai rendszerek közti fő eltérést a TV csatorna sávszélessége jelenti. Európában a PAL rendszerű analóg adás a B = 8 MHz, míg a Amerikában az NTSC rendszer B = 6 MHz sávszélességet specifikál. Az EuroDOCSIS specifikáció tehát figyelembe veszi a nagyobb rendelkezésre álló csatorna sávszélességet és így ugyanannyi csatorna felhasználása esetén nagyobb átviteli sebességet képest biztosítani. A jegyzetben elsősorban az EuroDOCSIS jellemzőit vesszük figyelembe, amikor DOCSIS ajánlásról beszélünk.
31
1.4.1. DOCSIS1.0, 1.1 és 2.0 A DOCSIS ajánlások igazodnak az OSI (Open System Interconnection)6 rétegstruktúrájához, és abból az alsó két réteget definiálják. A layer1 a fizikai (PHY) átvitelt írja le, míg a layer2ben az adatkapcsolati ( mely utóbbi két alrétegből áll: MAC –Media Access Control; és LLC – Logical Link Control) réteg működésének definícióját találjuk. A DOCSIS 2.0 ajánlás előírásai alapján fontos követelmény a kompatibilitás, vagyis a 2.0-ás eszköz képes „lebutulni” 1.0/1.1 szintre. A modulációs mód DOCSIS 1.0/1.1 esetén 64, vagy 256 állapotú QAM a letöltési irányban, míg a felfelé irányra QPSK-t, vagy 16 állapotú QAM-et használnak. A DOCSIS 2.0-ban lehetőség van feltöltési irányban magasabb állapotszámú modulációk használatára (QAM-32, QAM-64, QAM-128), mellyel értelemszerűen magasabb feltöltési sebesség elérése biztosítható. A MAC réteg vonatkozásában a DOCSIS ajánlások több hozzáférési eljárást alkalmaznak: DOCSIS 1.0/1.0 – TDMA7 DOCSIS 2.0 – TDMA és S-CDMA8 A DOCSIS1.0 és 1.1 esetében a maximális letöltési sebesség 42,88 Mbit/s (ebből hasznos sávszélesség körülbelül 38 Mbit/s lehet), míg a feltöltési irány 10,24 Mbit/s, amiből körülbelül 9 Mbit/s sebességet lát a felhasználó. EuroDOCSIS1.1 esetén a nagyobb csatorna sávszélesség miatt az elérhető digitális sávszélesség is magasabb a letöltési irányban 57,2MBit/s (hasznos 51 Mbit/s). A DOCSIS2.0-nak megfelelő eszközök letöltési irányban ugyanazt a sávszélességet biztosítják, mint a DOCSIS1.0/1.1 eszközök, de a feltöltési irány digitális sávszélességét megemelték 30,72Mbit/s értékre, melyből hasznosnak körülbelül 27 Mbit/s tekinthető.
6
Az OSI referenciamodellt az ISO hozta létre abból a célból, hogy az egyes feladatokat egymástól jól elkülönítse. A hét rétegű modell célja volt az, hogy az egyes rétegek és az abban megvalósított eljárások könnyen cserélhetők legyenek… A kedélyeket itt nem borzolnám tovább az OSI modellel (hiszen azt szinte minden informatikai könyv megtanítja), ha a Kedves Olvasó mégis úgy gondolná, hogy hasznos lehet az áttekintése, akkor a könyv végén a mellékletben egy picit bővebb leírást talál. 7 TDMA – Time Division Multiple Access 8 S-CDMA – Synchronous Code Division Multiple Access
32
1.4.2. DOCSIS3.0 Napjainkban az IP címek „elfogyása” miatt, valamint az egyre növekvő sávszélesség igény okán 2006 augusztusában jelent meg a DOCSIS 3.0 tervezet, mely már az IPv6-ot is támogatja, valamint jelentős átviteli sebesség növelés is történt, mind a fel- és letöltés irányban. A DOCSIS 3.0-ban megjelent a csatorna-összefogás (Channel-bonding) lehetősége, mely segítségével még magasabb átviteli sebesség érhető el. A csatorna összefogás függetlenül megvalósítható a fel- és letöltési irányban is. A csatorna-összefogás (Channel-bonding) miatt a letöltési irány sávszélessége magasabb lehet, mint 480 Mbit/s, míg feltöltési irányban több, mint 120 Mbit/s állhat a rendelkezésre. A jegyzet írásakor a DOCSIS3.0 eszközökkel a szolgáltatók által nyújtott letöltési sávszélesség maximuma 80 Mbit/s, míg a feltöltési irányban mindössze 5 Mbit/s-ot biztosítanak9. A DOCSIS 3.0 ajánlásban szintén kiemelkedően fontos a kompatibilitási kérdés. A DOCSIS 3.0 eszközbe be kell építeni a DOCSIS1.0/1.1, 2.0 és 3.0 képességeket. A DOCSIS 3.0 kábel modemnek (CM) képesnek kell lennie az együttműködésre a korábbi (1.0, 1.1, 2.0) kábel modem végződtető rendszerekkel (CMTS), valamint a DOCSIS 3.0 CMTS-nek együtt kell működnie a korábbi verziójú CM-ekkel is. A DOCSIS ajánlás alkotói ezt a szempontot mindvégig szem előtt tartották. Természetesen az ilyen alulról-felülről kompatibilitás maga után vonja azt, hogy az összeköttetés, a szerényebb képességű eszközökhöz igazodik.
A DOCSIS3.0 architektúra két fő komponensből áll: •
Kábelmodemből (CM – Cable Modem);
•
Kábelmodem végződtető rendszerből (CMTS – Cable Modem Termination System).
A CM a felhasználónál helyezkedik el, míg a CMTS a CATV fejállomásnál.
9
Magyar Telekom „Kábelnet Maximum” tarifacsomag, 2010. január
33
IPv4 CPE NMS
CM
CMTS
IPv6 CPE
HFC
CM
Kezdeti konfigurációs rendszer
IPv4 CPE IPv6 CPE
Háttérirodai hálózat
HFC hálózat
Előfizetői hálózat
1.4-1. ábra. A DOCSIS3.0 hálózat
A HFC hálózaton történő adatátvitel minden esetben egy CMTS és egy CM (kábelmodem) között folyik. A CMTS-CM irányt letöltési (downstream), míg a CM-CMTS irányt feltöltési (upstream) iránynak nevezzük. Egy hálózatban legalább egy CMTS és több CM található. A letöltési irány kezelése ütközés szempontból viszonylag egyszerű, mivel egy CMTS az adott szegmensben egyedül kommunikál egy letöltési frekvencián. Feltöltési irányban viszont ugyanazt a frekvenciát akár több száz kábelmodem (CM) is használhatja és a kábelmodemek között nincs szinkronizáció. Ezen okból a CMTS feladata a CM-ek feltöltési csatornájának hozzáférés ütemezése, vagyis az upstream adatfolyam szervezése. A DOCSIS protokoll értelmében minden CM-nek kérnie kell a CMTS-től egy időkeretet, amikor kizárólagos jogot kap adott feltöltési frekvencia használatra. Ennek az időkeretnek a neve „mini-slot”. Egy mini-slot hossza 6,25 µs. Egy mini-slotban minimum 16, maximum 48 byte hasznos információ lehet, de egy limitált határig a CM kérhet több mini-slotot, így lehetőség adódik nagyobb mennyiségű adat feltöltésére is. A mini-slot kéréseket a CMTS által meghatározott időközönként (időosztásban) lehet továbbítani. A mini-slot kiosztás engedélyezés (MAP – Mini-slot Allocation Packet) a letöltési irány sávszélesség terhére megy.
34
Feltöltési irány (Up-stream) jellemzői A feltöltési irányban FDMA/TDMA
(amit
„TDMA”
módnak
neveznek),
vagy
FDMA/TDMA/S-CDMA (melyet „S-CDMA” módnak neveznek) burst típust alkalmaznak, amelyhez hat modulációs mód tartozik. Az adás üzemmód kiválasztása (CM) a CMTS-sel „MAC” (2. réteg) üzenettel programozható. Az FDMA (Frequency Division Multiple Acces) jelen vonatkozásban azt jelenti, hogy több csatorna tartozik a feltöltési irányhoz. A CM egy vagy több rádiófrekvenciás (RF) csatornát használ a feltöltési irányban. A TDMA (Time Division Multiple Access) a DOCSIS 3.0 vonatkozásában azt jelenti, hogy a feltöltési irány adása (CM adás) szakaszosan (burst-ökben) történik, az időrések dinamikus kiosztásával. Az S-CDMA (Synchronous Code Division Multiple Access) jelen vonatkozásban azt jelenti, hogy a CM képes egyidejű adásra ugyanabban az RF csatornában, ugyanabban az időrésben úgynevezett ortogonális kód alkalmazásával. Ebben az esetben az információk az ortogonális kódolás miatt választhatók szét.
TDMA üzemmód A TDMA módban a jelfolyam a következő feldolgozáson esik át: A feldolgozási folyamatba az adatok csomag egységként érkeznek. •
Információs blokkokra bontás;
•
R-S (Reed-Solomon) kódolás;
•
Byte-ba illesztés (byte interleaver) [ez a funkció kikapcsolható];
•
Szkremblerezés;
•
Felvezető kód (preamble) hozzáfűzés;
•
Szimbólumhoz rendelés;
•
Adás kiegyenlítés;
•
Szűrés (adási spektrum formázás);
•
Modulálás.
A feldolgozás kimenete az RF jel.
S-CDMA üzemmód Az S-CDMA üzemmódban az adatküldés kétdimenziós módban történik. A két dimenziót a kódolás és az idő jelenti. A fizikai rétegben ekkor az adatok átvitele maximum 128 mezőből álló kóddal kerülnek továbbításra (lásd lenti ábra).
35
A CMTS-ben keretszámláló (frame-counter) és mini-slot számláló is van. Minden CM-ben ugyanekkor kötelező karbantartani az úgynevezett időbélyeg számlálót, mini-slot számlálót és keretszámlálót. A CM úgynevezett UCD (Upstream Channel Descriptor) üzenetből veszi a CMTS időbélyeget (time stamp), és további paramétereket, melyből képes kiszámolni az S-CDMA keretenként az „időszámláló” számot. A számításhoz a CM modulo aritmetikát használ. A CMTS és a CM 32 bites időbélyeg számlálót, 32 bites mini-slot számlálót és 8 bites keretszámlálót használ.
1.4-2. ábra. Kétdimenziós kódolás, keret időbélyeg
Az UCD-ben 3 paraméter specifikált, ami definiálja a mini-slot elrendezést: •
Szórás intervallum keretenként (spreading intervals);
•
Kódszám mini-slotonként;
•
Aktív kódok száma.
T fr = K ⋅ 128 ⋅ Ts Az összefüggésben a kód hossza minden esetben 128 hosszúságú. A szórás intervallum keretenkénti értéke („spreading intervals per frame”) 1 – 32 közé eső szám lehet.
36
A kódok száma mini-slotonként (Cms) definiálja a mini-slot kapacitást, vagyis megadja az összes lehetséges szimbólum számot, ami a mini-slot-ban előfordulhat. A mini-slot kapacitást (Sms) a következő összefüggés definiálja:
S ms = K ⋅ C ms A mini-slot kapacitás alsó határa 16 szimbólum. A maximális mini-slot kapacitást a szórás intervallum keretenkénti maximális számának és a mini-slot-ban előforduló kódszám maximális számának szorzata adja, ami 32 ⋅ 32 = 1024 szimbólumot jelent. A fentiek értelmében a mini-slot-ban előforduló kódok száma 2 – 32 közé eshet.
Az aktív kódok paraméter száma (Na) 128, vagy annál kisebb szám lehet. Abban az esetben, ha Na értékének 128-nál kisebb számot választunk, akkor azt a következő két módszer szerint lehet meghatározni: •
„Selectable Active Codes Mode1”;
•
„Selectable Active Codes Mode2”.
Az aktív kódok redukálásának több előnye is van, melyek közül talán a legfontosabb előny az, amikor a működtetés zajos csatornában történik. Kevesebb engedélyezett kódszám esetén lehetőség van az aktív kódokhoz tartozó teljesítmény növelésére, így például 128 helyett 64 aktív kód alkalmazásával 3 dB-es jel-zaj viszony javulás érhető el.
CM modulátor A feltöltési irány szimbólum sebessége (modulációs sebesség) 160 – 5120 ksym/s, míg SCDMA alkalmazása esetén a modulációs sebességet „chip-rate”-nek nevezzük, és 1280 – 5120 kHz értéktartományba eshet.
A feltöltési irány esetében a CM modulátort, valamint a CMTS demodulátort vizsgáljuk. A CM modulátor magába foglalja az elektromos-jelszint modulációs funkciót, valamint a digitális jelfeldolgozás (DSP) funkciót. A DSP funkció felelős a FEC (Forward Error Correction), a preamble, prepend és a „symbol-mapping”, valamint az egyéb feldolgozási lépések ellátásáért. A CM-ben a DSP funkció folyamatát a következő ábra szemlélteti:
37
1.4-3. ábra. DSP funkció folyamata A CMTS demodulátor hasonlóan két alapfunkciót ellátó komponensből áll, a demodulálást ellátó és a jelfeldolgozást megvalósító részből. A demodulátor demodulációs funkciója fogadja
a
különböző
szintű
jeleket
(a
beállított
szint
körül),
megvalósítja
a
szimbólumidőzítést, a vivő helyreállítást és követést, a burst-ök begyűjtését és demodulálását. Ez a fokozat becsli továbbá a jel-zaj viszonyt, és adaptív kiegyenlítést végez, mérsékli a visszhang és csoportfutási problémák hatását. A dekóder DSP funkciója a CM-ben található feldolgozási feladatok inverzét látja el. Fogadja a demodulált burst-öket, ezen felül időzítési feladatokat is ellát. Indikálja továbbá a sikeres dekódolást, jelzi a dekódolási hibát, valamint megadja minden kódszóhoz a korrigált Reed-Solomon szimbólum számot.
Modulációs eljárások, szimbólumok elhelyezkedése A feltöltési irányban (CM adási irány, CMTS vételi irány) a kompatibilitás miatt a DOCSIS eszközöknek a következő modulációs eljárásokat kell ismerniük: •
QPSK;
•
QAM-8;
•
QAM-16;
•
QAM-32;
•
QAM-64;
•
QAM-128 (kizárólag TCM-nél).
A CM és a CMTS berendezés modulációs módja MAC (második réteg) üzenettel választható ki (menedzselhető). Differenciális kódolású QPSK és 16 állapotú QAM mód lehetséges TDMA módban. A QPSK szimbólumokat a 1.4-4. ábra, a 16 QAM szimbólumok elhelyezkedését a 1.4-5. ábra mutatja.
38
1.4-4. ábra. QPSK szimbólumok
1.4-5. ábra. QAM szimbólumok QPSK, 8 QAM, 16 QAM, 32 QAM, 64 QAM és 128 QAM a TDMA és S-CDMA csatornák számára használatos, míg a TCM kódolt QPSK, 8 QAM, 16 QAM, 32 QAM, 64 QAM és 128 QAM S-CDMA csatorna esetén használatos. Mindegyik üzemmódban a bitek elrendezése az I (In-phase) és Q (Quadrature-phase) konstellációban az alábbi táblázat szerinti definíciónak kell megfelelnie:
39
QAM mód:
Bemeneti bitek definíciója: (x1 jelenti a legkisebb helyértékű bitet, LSB-t)
QPSK
x2x1
8 QAM
x3x2x1
16 QAM
x4x3x2x1
32 QAM
x5x4x3x2x1
64 QAM
x6x5x4x3x2x1
128 QAM
x7x6x5x4x3x2x1
1.4-1. táblázat. Bitek elrendezése különböző QAM esetén
A soros adatfolyam első kilépő bitje mindig a legértékesebb bit (MSB).
1.4-6. ábra. 8 QAM és 32 QAM szimbólumok
1.4-7. ábra. 64 QAM és 128 QAM szimbólumok
40
Az egyes szimbólumok kódolása Gray, vagy differenciális kódolással történhet.
1.4-8. ábra. Gray (a) és differenciális (b) kódolás 16 QAM esetén Spreader S-CDMA átvitel alapja az úgynevezett direkt szekvenciájú szórt spektrumú moduláción (direct-sequence spread-spectrum) alapszik. Az S-CDMA digitális ortogonális kódszavak családját alkalmazza, így egyidejűleg maximum 128 modulációs szimbólum adására is képes. Minden szórás intervallum egy vektorral írható le (Pk), ahol:
PK = S K ∗ C A fenti összefüggésben az Sk egy vektor, ami a modulációs szimbólumokat tartalmazza, valamint C egy mátrix:
ahol a C mátrix sorai a 128 kódot definiálja. A DOCSIS ajánlások a C mátrixot rövidített formában írják le (a „coden” valójában a mátrix n-edik sorát jelenti, ami 128 elemből áll):
41
code127 ⋅ C= code1 code0
A C mátrixot gyakran szórás mátrixnak (spreading matrix) nevezik.
Kódugratás (Code Hopping) A kódugratás nem jelent mást, mint a C mátrix (szórás mátrix) sorainak szisztematikus felcserélését. A felcserélési sorrendet ál-véletlen generátor vezérelt ciklikus shift végzi. A DOCSIS 3.0 ajánlás kétféle kódugrató eljárást definiál: •
MODE1;
•
MODE2.
A MODE1 a „SAC-Mode1” (Selectable Active Codes Mode1) esetben használatos, míg a MODE2 a „SAC-Mode2” (Selectable Active Codes Mode2) esetben. MODE1 esetben a Ck alakulása:
Ahol:
MODE2 esetben:
42
Ahol:
Szkremblerezés A szkrembler feladata, hogy az adatjelet átvitelre előkészítse és annak tulajdonságait véletlen jel tulajdonságaihoz hasonlóra alakítsa (innen származik a funkcióra szintén használt „randomiser” elnevezés). A szkrembler jelen esetben nem más, mint egy 15 bites shift regiszterből kialakított álvéletlen szekvencia generátor, mely kimenete és a továbbítandó jel bitjei között ütemről-ütemre kizáró-vagy (xor) műveletet végzünk. A szkremblerezett jelet a kizáró-vagy műveletet végző logikai kapu kimenetén kapjuk. A szkrembler elvi felépítése a következő ábrán látható:
1.4-9. ábra. Feltöltési irány szkrembler fokozata A szkremblerezéshez az x15 + x14 + 1 polinomot alkalmazzuk.
Adási elő-kiegyenlítő Az adási elő-kiegyenlítő fokozat struktúráját tekintve az ajánlás a DOCSIS 3.0 esetén ugyanúgy, mint a 2.0 esetén 24-ed fokú FIR struktúrát ír elő (DOCSIS 1.1 esetén ez 8-ad fokú szűrő volt). A FIR szűrőstruktúra előnye a lineáris fázis, valamint a stabil működés, mivel a struktúra nem tartalmaz visszacsatolást. Az adási elő-kiegyenlítő elvi jelfolyam diagramja a következő ábrán látható:
43
1.4-10. ábra. Feltöltési irány adási elő-kiegyenlítő fokozata Az elő-kiegyenlítőben szereplő konstansok (F1 … F24) valójában a szűrő impulzus válaszának (súlyfüggvénynek) mintái. A szűrő frekvenciatartománybeli átviteli függvényét a súlyfüggvény minták Fourier transzformáltja szerint számíthatjuk. A 1.4-10. ábra szerinti struktúra a z síkon történő megvalósítást mutatja, ahol a z-1 az időtartományban nem más, mint egy T ütem (T = a DSP struktúra mintavételi frekvencia reciproka) szerinti késleltető elem. A sorba kapcsolt tároló elemeket tehát T ütem szerint léptetett tároló lánccal valósíthatjuk meg. A FIR szűrő tehát az időtartományban a súlyfüggvény minták (F1 … F24) és a beérkező jelminták konvolúcióját végzi el.
44
1.5. Optikai hozzáférési hálózatok, FTTx Korábban az optikai összeköttetések kizárólag a hálózat belsejében, az úgynevezett maghálózatban (core-network) biztosították az egyes berendezések között a szélessávú digitális kapcsolatot. Ennek oka elsősorban az volt, hogy az optikai átviteli berendezéseknek igen magas volt az ára és az optikai adók, és vevők élettartama is viszonylag alacsony volt, ami néhány év időtartamot jelentett. Az optikai összeköttetések költségét emelte az is, hogy a korábbi adó eszközök (lézer diódák) fényerő korlátja miatt az átviteli utakba, az alkalmazott technológiától függően bizonyos távolságoknál úgynevezett regenerátor berendezéseket kellett építeni.
Az optikai átvitel a fizikai közegben (fényvezető szálban) többféle módon történhet, az átvitel módja elsősorban a fizikai méretektől függ. Régebben vastagabb optikai vezető szálakat alkalmaztak, melyeknek magmérete 200 µm körüli volt. Ezen szálakban a terjedés multimódusú.
1.5-1. ábra. Multimódusú terjedés
Multimódusú terjedés esetén a közegbe adott szórt irányú fényimpulzus nyalábok különböző hosszúságú utat tesznek meg, amíg elérnek a célig. A véges terjedési sebesség miatt a kimeneti impulzus jelentős jelalak torzulást szenved. A mechanikai méretek csökkentésével (szál mag átmérő 10 µm) a terjedés egyutassá tehető. Az ilyen szálakat monomódusú szálaknak, benne a vezetett fény terjedését monomódusú terjedésnek nevezzük.
45
1.5-2. ábra. Monomódusú terjedés A monomódusú átvitellel jóval kedvezőbb a jelalak továbbítás, nagyobb távolságok hidalhatók át optikai jelfrissítő eszköz igénybevétele nélkül. A technológiai fejlesztések egyre kisebb csillapítású, jobb átviteli paraméterekkel rendelkező optikai szálakat hoztak létre, az optikai adó- és vevő eszközök egyre jobb hatásfokkal működnek és várható élettartamuk már néhányszor 10 év. Mindez lehetővé tette olyan, viszonylag olcsón kiépíthető és üzemeltethető hálózatok kialakítását, melyek megjelenhettek az előfizetői szakaszokban. Ezek a hálózatok már nem tartalmaznak regenerátor berendezéseket, ezért ezeket passzív optikai hálózatoknak (PON – Passive Optical Network) nevezzük.
Egyre nagyobb számban létesítettek és építenek ki napjainkban optikai szálon működő úgynevezett hozzáférési hálózatokat. Az elmúlt években az ITU-T, DSL Forum, IEEE által elfogadott ajánlások és ipari szabványok egységesítették a megoldásokat. 1998-ban jelent meg az első hozzáférési hálózatra vonatkozó ITU-T ajánlás az ATM-PON (Passive Optical Network) vagy APON, amelyen az információ cella formában10 továbbítható. 2001-ben jelent meg a BPON átviteli eljárásra vonatkozó ITU-T ajánlás, amely továbbra is az ATM (Asynchronous Transfer Mode) alapú átvitelt alkalmazza. Az ajánlás lehetőséget biztosít a 622,08 Mbit/sec szimmetrikus átviteli sebesség használatára is. 2004-ben az ITU-T által kidolgozott a GPON átviteltechnikai eljárás már a 2,4/2,4 Gbit/sec sebességű médiaátvitelt teszi lehetővé, felülről kompatibilis a korábbi APON/BPON ajánlásokkal. A gyártók általában az 1,2/2,4Gbit/sec sebességű változatot támogatják, ezt az ITU-T tanulmányi bizottsága elfogadta, erről 2006-ban egy úgynevezett „Amendment”-et jelentetett meg. A hozzáférési hálózatban, ezen ajánlás szerint a BPON, azaz az ATM szerinti
10
Az ATM esetében az átvitel nem változó hosszúságú keretekkel történik. A fix hosszúságú adategységeket celláknak nevezzük. Egy ATM cella mérete mindig 53 byte, ebből 5 byte a fejléc, és 48 byte a hasznos adat.
46
médiaátvitel, vagy az újonnan kidolgozott keretmódú úgynevezett GEM (GPON Encapsulation Method) eljárások használhatók. Az ITU-T-vel párhuzamosan folyik az IEEE-ben az Ethernet szabvány kiegészítésének kidolgozása, amelyet 2004–ben jelentettek meg, az IEEE 802.3ah megjelöléssel. Ez az úgynevezett EPON, amely MAC keretek továbbítási eljárását, annak formátumát specifikálja pont-többpont kapcsolatra. Természetesen az adatátvitel itt is a passzív optikai hálózaton történik. Jelenleg is folyik az ITU-T és a DSL Fórum bizottságaiban a szélessávú szolgáltatások igénybevételére alkalmas hálózati megvalósítás rendszertechnikájának (TR 101), a felhasználónál telepítendő hálózatban a residental gateway (J.192) funkcióinak kidolgozása és elfogadási folyamata. E bizottságokban folyó munka magába foglalja a szolgáltatói és előfizetői berendezések funkcióinak meghatározását, az átviteli formátum kidolgozását, hitelesség, jogosultság titkosításra vonatkozó ajánlások megfogalmazását valamint a szolgáltatás minőségi jellemzőinek kidolgozását.
A „PON” (Passive Optical Network) elnevezésben a passzív szó azt jelenti, hogy az optikai hálózati végpontok között telepített berendezés működtetéséhez külső energiaforrás nem szükséges, vagyis mint azt az előzőekben láttuk, aktív jel regenerátor berendezés az átviteli útban nincs. Az információ továbbítása alapján a létesített kapcsolatok lehetnek pont-pont vagy pont – multipont alapúak. Gazdasági okokból valamint a sávszélesség optimális felhasználás szempontjából előnyösebb a pont - multipont kialakítású optikai hálózat, amelynek egyik problémája, médiajel szétosztása (downstream) le irányban az egyes előfizetők között. Ehhez különböző osztásarányú passzív splitterek használhatók. A másik probléma (upstream) fel irányban több használó által küldött jelfolyam ütközésmentes továbbítása. Az ütközések elkerülhetők, ha az igénybejelentést követően a szolgáltatói oldalon lévő berendezésben megvalósított szoftver gondoskodik a sávszélesség dinamikus kiosztásáról, a hozzáférést időosztás elven vezérli. Ezt különböző hálózati technológiák BPON, EPON, GPON egymástól eltérő módon oldják meg. A passzív optikai hálózattal megvalósított hozzáférési hálózatot FTTx hálózatoknak nevezzük. Az FTTx rövidítés jelentése „Fiber To The x”, vagyis optikai szál az „x”-ig. Az „x” az optikai szál előfizető felé eső végének helyét határozza meg. Az „x” hely a gyakorlatban többféle lehet:
47
•
H = Home;
•
B = Building;
•
C = Cabinet (vagy Curb).
Az FTTH esetén az optikai szál előfizető oldali vége az előfizető otthonában található, ekkor az előfizetői hálózat hozzáférési helye optikai interfész, úgynevezett UNI (User Network Interface). Abban az esetben, ha szükséges, akkor a rézre átállás az előfizetői végponton valósul meg. ODN
ONU
OLT Optikai szál
UNI
SNI
Hozzáférési hálózat
1.5-3. ábra. FTTH kialakítása Az előfizetői oldalon az hozzáférési pontot az ONU (Optical Network Unit) biztosítja, míg a hozzáférési hálózat „hálózati” vége (SNI – Service Network Interface), az OLT-ben (Optical Line Termination) végződik. Az FTTB és FTTC hozzáférési hálózatok esetén a hozzáférési hálózat tartalmazza azt az eszközt, melyen megvalósul az optikai – réz átállás. A két technológia ezért közösnek tekinthető, a különbség csak annyi, hogy az optikai – réz hordozó közeg átállást biztosító eszköz hol helyezkedik el. Az FTTB esetben az optikai szál az épületig fut, mely lehet egy intézmény, üzem, társasház stb. Az FTTC kialakítás esetén az ONU egy önálló, szabadtérben lévő berendezés, amelyet rézhálózaton keresztül, a lakásokban és a családi házakban telepített végberendezéshez csatlakoztatnak. Ezen belül is két altípust különböztethetünk meg. Az FTTCabinet, nagyelosztóig kiépített rézhálózatot, míg az FTTCurb, utcasarokig kiépített rézhálózatot jelenti.
ONU
HN UNI
Réz hálózat
OLT ODN
Hozzáférési hálózat
1.5-4. ábra. FTTB és FTTC rendszertechnikája
48
SNI
Az FTTx ajánlások a helyi hálózat (HN - Home Network) rendszertechnikai helyét csak jelölik, de azok nem tartalmazzák annak definícióját, funkcióit. Fontos megemlíteni, hogy az FTTC rendszerű passzív optikai hálózatok jelenthetik az xDSL hálózatok agregációs hálózati részét. A passzív optikai hálózati technológiák – mint azt az ezzel kapcsolatos ajánlások rövid áttekintése kapcsán az előzőekben már láthattuk - meglehetősen sokfélék és fejlődéstörténetük alapján egymástól eltérőek. A következőkben ezeket tekintjük át.
1.5.1. BPON – Broadband–PON A BPON ajánlás szerint a szimmetrikus átvitelhez ajánlott fel- és letöltés irányú átviteli sebesség 155,52 Mbit/sec lehet. Az aszimmetrikus átvitel során a feltöltés irányban 155,52 Mbit/sec az átviteli sebesség, míg a letöltés irányban 622,08 Mbit/sec áll rendelkezésre. Az ajánlás lehetővé teszi egy optikai szálon a WDM (Wave Division Multiplex) használatát, amelynek során feltöltés irányban 1260-1360 nm közötti, valamint letöltés irányban 14801580 nm közötti hullámhosszúságon továbbítható az információ. Az ONT (Optical Network Termination) és OLT (Optical Line Termination) között a kétirányú médiaforgalom csak cella formátumú lehet. Letöltés irányban minden 28. cella úgynevezett PLOAM (Physical Layer Operations Administration and Maintenance), amely vezérlési üzeneteket, parancsokat tartalmaz. A keretszervezés is cella alapú, azonban egy keretben lévő cellaszám a beállított átviteli sebesség függvénye. Így 155,52 Mbit/sec esetén 2 PLOAM-et (2*28 = 56 cellát), 622,08 Mbit/sec esetében 8 PLOAM-ot, azaz 8*28 = 224 cellát tartalmaz egy keret. A BPON keretszervezését a következő ábrán láthatjuk. Letöltés irány PLOAM
01.cella
27.cella
PLOAM PLOAM
01.cella
Feltöltés irány 01.cella
02.cella
53.cella
01.cella
1 keret = 53 cella
1.5-5. ábra. BPON keretszervezés
49
Feltöltés irányban minden cellát egy 3 byte-os úgynevezett overhead mező egészít ki, amelynek tartalmát az OLT határozza meg. Az első byte az úgynevezett Guard time, amelyben nem minden bit kerül átvitelre. Az egyes ONU-k (Optical Network Unit) és az OLT közötti távolság különböző lehet, azok késleltetési ideje a távolság függvénye. Elvileg két egymás után megszólaló ONU által küldött cella átlapolódhat. Ennek megakadályozására az OLT meghatározza a biztonságos működéshez szükséges időtartamot, azt a bitszámot, amelyet nem kell elküldeni. Az első néhány bit időtartama alatt a lézer dióda kikapcsolt állapotban marad és csak a maradék bitektől kezdi el a cella küldését. (Lehet, hogy a 3 byte-os overheadből csak 20 bit kerül átvitelre, az 5. bittől kezdődően.) A második byte az úgynevezett Preamble. Az OLT ennek a byte-nak beérkezése alapján határozza meg a cella fázishelyzetét, illetve az ONU helyi időzítését. A harmadik byte egységes tartalma a cella kezdetét jelzi (Start Of Frame). Feltöltés irányban bármelyik cella tartalmazhat PLOAM üzenetet. Letöltés irányban a PLOAM cellában lévő engedélyező (Grant) byte-ok jelzik az ONU-knak, hogy az 53-as keret melyik celláit használhatják feltöltés irányban az ütközés elkerülése érdekében.
1.5.2. EPON – Ethernet PON A letöltés irányban küldött MAC keretek splitteren keresztül jutnak el az egyes ONU eszközökhöz. Feltöltés irányban az ütközések elkerülése miatt az OLT-nek vezérelnie kell az üzenetküldést a bejelentett sávszélesség igény alapján. A pont-többpont ütközésmentes működés megvalósítása időosztás-elv alapján történik. Az egyes ONU-k a bejelentkezést követően csak a nyugtázási (Grant) üzenetben meghatározott időintervallumban használhatják az optikai hálózatot. A működéshez kidolgoztak több vezérlő üzenetből álló úgynevezett MPCP-t (Multi-Point Control Protocol), amelyet az alábbi fázisokban használnak: •
Felismerési fázisban (Discovery process) az OLT regisztrálja az ONU bejelentkezését.
•
Működési állapotot jelzi, ha a regisztrálási idő lejárta előtt Report-ot küld. Ebben az üzenetküldésre várakozó sor (queue) állapotát is jelzi. Az ONU optikai végződésnél megvalósított sor (queue) tárolja a rézhálózati végződésen több számítógéptől érkező MAC kereteket. Ennek a sornak az állapotát (1,2,..8 üzenet szám) küldi el riportban az
50
ONU. Az engedélyezést, az úgynevezett Grant byte-kat, a Gate válaszüzenetből olvassa ki az ONU. •
Üzenetküldés kizárólag az engedélyezésben meghatározott időpontokban lehetséges. Ezekben az időintervallumokban lehet csak aktív az adó eszköz lézer diódája.
•
Minden ONU-t egyedi LLID-vel (Logical Link ID) azonosítanak az üzembe helyezés során. Az OLT által elküldött MAC keretnek tartalmaznia kell a kijelölt ONU LLID címét. A splitter valamennyi ONU-nak továbbítja a MAC keretet, azonban azt csak a megcímzett ONU küldi tovább a csatlakoztatott rézhálózaton. A két hálózati berendezésnek (ONU és OLT) bridge funkcióval is rendelkeznie kell a MAC keretszűrés miatt. Az OLT nyilvántartja, hogy egy LLID-hez milyen MAC címek tartoznak.
Az EPON szabvány szerint a maximális szimmetrikus adatátviteli sebesség 1 Gbit/sec lehet, Egy optikai szálon a duplex adatátvitel hullámhossz multiplexálással valósul meg. Például feltöltés (upload) irányban 1310 nm, míg a letöltés (download) irányban 1490 nm hullámhossz használható. Az optikai hálózatba 1:16 –os splitter is telepíthető.
51
1.5.3. GPON-Gigabit capable Passive Optical Network
GPON referencia modell A lenti ábrán látható GPON referencia modell. A GPON rendszer közvetett módon ugyan, de már jelzi a videó szolgáltatás bevezetését. Az előző ajánlások még átviteltechnikai szinten sem foglalkoztak e szolgáltatás megvalósításával, pedig a nagy sávszélesség elsősorban a videó átvitelnek kedvez. Valószínűleg azt feltételezték, hogy a tömörített videót MAC keret vagy cellaformában továbbítják, ugyanazon a hullámhosszon. A 2006-ban megjelenő ITU-T Amendment ipari gyakorlatra történő hivatkozással, különálló hullámhosszúságot ajánl a videó átvitelére, amelyhez esetleg külön WDM használata is szükséges. UNI TE
Optikai elosztó hálózat HN
ONU
SNI WDM
TE
OLT
WDM WDM TE
HN
Splitter
ONU PON
TE
PON
xDSL
1.5-6. ábra. GPON referencia modell A GPON csatlakozáson az alábbi szabványos sebességek használhatóak: 155Mbit/sec feltöltési irányban/ 1,2 Gbit/sec letöltés irányban 622Mbit/sec feltöltési irányban/ 1,2 Gbit/sec letöltés irányban 1,2 Gbit/sec feltöltési irányban/ 1,2 Gbit/sec letöltés irányban 155Mbit/sec feltöltési irányban/ 2,4 Gbit/sec letöltés irányban 622Mbit/sec feltöltési irányban/ 2,4 Gbit/sec letöltés irányban 1,2 Gbit/sec feltöltési irányban/ 2,4 Gbit/sec letöltés irányban 2,4 Gbit/sec feltöltési irányban/ 2,4 Gbit/sec letöltés irányban
52
60 km
ONT
OLT ONU
Splitter
20 km
1.5-7. ábra. GPON hálózat és maximálisan áthidalható távolságok A GPON kétféle szolgáltatás megvalósítására alkalmas: Az adat, és hang (VoIP) mellett tartalmazza még a videojel továbbítás támogatását is. Ebben az esetben a médiajelet külön hullámhosszúságon továbbítják, amelyhez esetleg alkalmazni kell egy külön WDM blokkot. Az OLT két hullámhosszat választ szét (fel és le irányút), míg az ONU hármat (fel- és 2db letöltés irányút). A képátvitel (videó) nélküli szolgáltatáshoz elegendő két hullámhossz a fel- és letöltés irányban. A GPON rendszerek műszaki specifikációit az ITU-T G.984 ajánlások11 foglalják össze. A G.984.1 a GPON általános specifikációit, rendszertechnikai felépítését adja meg, a G.984.2-ben a fizikai átviteli közeg definícióit tartalmazza. A G.984.3 az átviteli eljárásokat írja le, míg a hálózatmenedzselés és távfelügyelet kérdéseit a G.984.4 ajánlás tárgyalja.
11
A GPON ajánlások pdf formátumban szabadon letölthetők az ITU honlapról, például a www.itu.int/rec/TREC-G.984.1/en címen a G.984.1 érhető el.
53
2. Áramkör kapcsolt beszédcélú magán hálózatok A hozzáférési hálózat és a hozzáférési technikák tárgyalását követően most az előfizető oldali rendszereket tekintjük át. Ebben a fejezetben – mint azt a cím is mutatja - az áramkör kapcsolás elvén működő rendszereket vizsgáljuk. Irodák, intézmények, de akár csak két-három helyiségből álló kis cégek (mikrovállalkozások), esetén jogos igényként merül fel a munkatársak közti beszédcélú telefonos kommunikáció. A munkatársak egymás között folytatott beszélgetéseire a távközlési szolgáltató cégek szolgáltatásait igénybe véve havi szinten a költségek meglehetősen magasak lehetnek, ezért megfontolandó a saját beszédcélú magánhálózat kiépítése. Családi házak esetén a helyi beszédcélú hálózat kialakítása elsősorban kényelmi szempontként jelentkezhet. Alközpont alkalmazásával például az egy, vagy két fővonal hatékonyan szétosztható 6-8 telefonkészülék között. Jól tervezett rendszer esetén a gyakorlat azt mutatja, hogy a hálózat kiépítésének és rendszeres karbantartásának költsége általában néhány hónap, maximum néhány év alatt megtérül. A beszédcélú kapcsolt vonali magánhálózat lelkét az úgynevezett alközpont (PABX) jelenti. Ez a berendezés végzi a beszédút felépítését, bontását. Az irodai telefonkészülékek az alközpont mellékvonali áramköreihez kapcsolódnak. A mellékvonalak száma a gyakorlatban 4, 6, 8 vonaltól pár ezerig terjedhet. A „külvilággal” a kapcsolat az úgynevezett fővonali áramkörökön, trunk-áramkörökön keresztül valósulhat meg. A „külvilág” alatt most egy nyilvánosan hozzáférhető beszédcélú hálózat segítségével szolgáltatást nyújtó távközlési szolgáltatót értünk.
54
2-1. ábra. Alközpont és a PSTN kapcsolata
2.1. Beszédcélú magánhálózatok interfészei A telefon alközpont a nyilvános hálózathoz a fővonali áramkörökön keresztül kapcsolódik. A fővonali áramkör lehet:
□ analóg kéthuzalos távtáplált interfész; □ digitális, alapsávi ISDN interfész; □ primer PCM, vagy ISDN30 interfész; □ bérelt vonali csatlakozás, társközponti interfész. Az áramkör kapcsolt telefon alközpontok ugyanakkor (elsősorban költséghatékonysági megfontolások alapján) a GSM hálózathoz, és IP hálózathoz is kapcsolódhatnak.
2.1-1. ábra. Alközpont alternatív „kimenő” útirányokkal
55
A GSM és IP alternatív irányok használatának több előnye lehet. Napjainkban az alternatív útirányokat elsősorban költséghatékonysági szempontok miatt alkalmazzák, de az alternatív irányok alkalmazásának nagy jelentősége van a működésbiztonság terén is. A működés folytonosság nagyobb biztonsággal garantálható, ha az alközpont több nyilvános hálózathoz és több hozzáférési technikával csatlakozik. Gyakran alkalmazott módszer az, hogy a modern, nagy sávszélességű módszerek mellett az alközpont analóg kéthuzalos telefonvonallal is kapcsolódik a külvilághoz, így egy esetleges jelzés protokoll hiba miatt leálló ISDN30 összeköttetés redundanciáját jelentheti az analóg fővonal. Kérdésként merül fel, hogy mi hibásodhat meg egy több éve jól működő alközpont – PSTN kapcsolatban? A válasz egyszerű! A nyilvános kapcsolt telefonhálózat digitális, tárolt program vezérlésű központjainak szoftvereit folyamatosan frissítik, illetve arra hibajavító „pach”-eket töltenek. A szoftverfrissítések új szolgáltatás elemeket, így új protokoll elemek használatát is tartalmazhatják. A szolgáltatók gondos teszteket követően szokták a szoftverfrissítést megtenni, de az alközpont szoftveréhez általában nem férnek hozzá. Az alközpontban
megbújó
hibára,
(előzőleg
nem
használt
protokoll
elem
hibás
implementációjára) gyakran az ilyen frissítések világítanak rá. Az ilyen jellegű problémák akár teljes leállást is eredményezhetnek, amelyek különösen kellemetlenek nagy intézmények, irodaházak, bevásárlóközpontok esetén. A több kimenő irány alkalmazásával jelentős költség takarítható meg, ha a kimenő irányt jól választjuk meg. Tarifa költség takarítható meg például, ha a felépített beszédkapcsolat „hálózaton belül” marad, vagyis ha mobil számot hívunk, akkor a hívást mobil hálózatból indítjuk, a vezetékes számok elérését pedig vezetékes hálózati híváskezdeményezéssel valósítjuk meg. Ez természetesen megoldható lenne úgy is, hogy az irodai asztalon lenne egy vezetékes telefon és mobil szolgáltatónként egy-egy darab mobiltelefon. Ekkor mindig azt a készüléket
kellene
használnunk,
mely
használata
olcsóbb.
A
gyakorlatban
ez
kivitelezhetetlen, elég ha csak arra gondolunk, hogy hány mobilkészüléket és előfizetést kellene biztosítani egy olyan irodaházban, ahol 100, vagy annál több ügyintéző, irodai dolgozó végzi a feladatát. A kimenő útirány „okos” kiválasztása az erre alkalmas alközpontokkal automatizálható. Az útirány kiválasztás funkciót ARS-nek (Auto Routing Select) nevezik. Az ARS a hívószám kiértékelésével valósul meg. Az ARS működésének alapfeltétele az, hogy az alközpontnak beadott számokat nem adja azonnal tovább a nyilvános hálózat felé, hanem azt a memóriájába begyűjti, és teljes hívószám begyűjtést követően, adatbázisban tárolt hívásirány táblázat segítségével választ az alközpont kimenő irányt. 56
A mellékvonali interfészek általában:
□ analóg kéthuzalos távtáplált; □ alapsávi ISDN (BRI); □ rendszer specifikus, gyártói szabvány szerint kialakított interfész. Napjainkban elterjedőben van az IP hálózaton alapuló mellékvonal kialakítás, mellyel jelentős mellékoldali kábelezési költséget lehet megtakarítani. Ebben az esetben a hangátvitel VoIP átvitelen alapul.
2.2. Beszédcélú magánhálózatok fontosabb szolgáltatásai A beszédcélú magánhálózatok alközpontjai a többletszolgáltatások széles skáláját vonultatják fel. Az alközpontok gyártói az egyszerűbbektől kezdve, a bonyolult, összetett szolgáltatásokig sokféle funkciót alakítanak ki a berendezéseikben. A szolgáltatások elérése, hozzáférhetősége többnyire rendszer-specifikus. Az alközpontok néhány jellemzője, működésének módja rugalmasan programozható. A programozás
irányulhat
a
nyilvános
hálózattal
és
a
mellékvonalakon
található
végberendezésekkel történő együttműködés érdekében (például tárcsázási módok és paraméterek beállítása, bontási idők beállítása, rövid-hurokmegszakítási idők beállítása stb.), de programozással állítható be az egyes szolgáltatások elérése, esetleg mellékvonalak bizonyos szolgáltatás elérésének korlátozása is. Legegyszerűbb esetben a programozás analóg kéthuzalos telefonkészülékről történhet, vagy esetleg egy rendszer specifikus telefon igénybevételével. A működési paraméterek telefonkészülékről történő beállítása általában csak kisméretű (néhány vonalas) központok esetén szokásos, illetve a nagyméretű központok esetén bizonyos szolgáltatás funkciókat a telefonkészülékről kiválasztva azok kizárólag csak az adott mellékvonalra vonatkoznak. A nagyobb rendszerek esetében a rendszer-működés beállítás (programozás) gyakran elvégezhető személyi számítógép segítségével is, például V.24 interfészen, vagy Ethernet porton. A költséghatékony üzemeltetés érdekében a gyártók távprogramozási lehetőséget (távfelügyeletet) valósítanak meg, mely történhet MODEM segítségével, vagy IP hálózaton történő eléréssel. Az alközpontok gyakran kettő (vagy annál több) konfigurációs tárral rendelkeznek, melyek közül egyszerre csak az egyik az aktív. A két konfigurációs tár elnevezése, általában
57
„Nappali” és „Éjszakai”. A működési üzemmódok közti váltás lehet manuális, vagy az alközpontba beállított időpont alapján automatikus. A következőkben néhány fontosabb szolgáltatást tekintünk át.
2.2.1. Hívásátadás folyamata A hívások átadása talán az alközpontok egyik legfontosabb alapszolgáltatása. Ezt a funkciót, a néhány vonalat kiszolgáló „házi kisközpontok” esetén is megvalósítják. A funkció segítségével akár bejövő, akár kimenő hívásokat kapcsolhatunk át egy tetszőleges mellékállomásra. A hívás átadás folyamata különböző alközpontoknál némileg eltérhet. Magát a folyamatot analóg kéthuzalos távtáplált vonali interfészű mellékállomásokkal rendelkező alközponton mutatjuk be, amely fővonali áramköre szintén analóg kéthuzalos távtáplált. Az első példában azt feltételezzük, hogy egy hívó (ábrán az „A”), a „B” hívott oldal számát már korábban tárcsázta és a „B” vonal már csengetett állapotban van, vagyis egy bejövő hívást és annak átadás folyamatát vizsgáljuk. Az alközpont konfigurációja szerint a bejövő hívás csengető jelének hatására a „Kezelő” („K”) mellékállomás is csengetett állapotba került. A csengetett állapotú „K” vonal beemelése esetén a kezelői mellékállomás off-hook (vagyis hurok zárt) állapotba kerül. A hurok zárás hatására az alközpont beszédutat („x1”) épít fel a „K” mellékállomás és a „Co” fővonali áramkör között, valamint a fővonali áramköri hurok is zárt állapotba kerül. A fővonali áramkör hurokzárását követően a PSTN is kiépíti a beszédkapcsolatot a hívó és a hívott („A” és „B”) között („y” beszédút). A felépült beszédkapcsolaton keresztül az „A” és a „K” kommunikál, például „A” kéri, hogy kapcsolják neki „N”-et (vagyis kölcsönös, és illedelmes bemutatkozást követően az „A” elmondja, hogy „N”-et keresi).
58
2.2-1. ábra. Bejövő hívás-átadás folyamata – „bejelentéses” hívásátadás A hívásátadás folyamatát tehát „A” kérésére „K” kezdeményezi. A folyamat a „FLASH” billentyű megnyomásával indul, mely hatására a készülék a „K” vonali hurokáramot rövid
59
időre megszakítja (rövid hurokmegszakítás). A rövid hurokmegszakítás (mely időtartama 100ms, de alközponti rendszereknél ez akár 300ms, 600ms, 750ms, sőt 900ms időtartam is lehet), a fővonali áramkört „tartásba” helyezi és az ábrán feltüntetett „x1” beszédutat bontja. Az alközpont a tartásba helyezett fővonalra „tartási hangot” kapcsol, ami lehet egy egyszerű, megszaggatott jelzőhang, de lehet zene is. A tartási zene esetén előfordulhat, hogy az alközpontot üzemeltető jogdíj fizetésére kötelezett (!). A „FLASH” hatására a „K” úgynevezett regiszter funkciót kap az alközponttól, melyet az alközpont belső tárcsahanggal jelez. A tárcsahang megérkezését követően a „K” tárcsázza „N” mellékállomás hívószámát, mely, ha ezt megelőzően nyugalmi állapotban volt, akkor azt az alközpont kicsengeti. Ezen a ponton a hívásátadás folyamata több módon folytatódhat! Először az úgynevezett „bejelentéses” hívásátadást tekintjük át. Ez esetben a „K” megvárja, hogy „N” megválaszolja a hívást, vagyis beemelje a készülékének kézibeszélőjét. Amint az „N” megválaszolta a hívást, beszédkapcsolat (x2) épül fel a „K” és az „N” között. A „K” a felépült kapcsolaton keresztül tájékoztatja „N”-et, hogy „A” keresi és szeretne vele beszélni. Abban az esetben, ha „N” nem tagadja le magát ☺, és kívánja fogadni az „A” megkeresését, akkor létrejöhet a hívás átadás, ami egyszerűen a „K” letételével valósul meg, miközben „N” tartja a vonalat. Természetesen előfordulhat olyan eset is, hogy az „N” mellékállomásnál nem a keresett személy válaszolta meg a hívást, és az nem is tartózkodik ott (például házon kívül van). Ebben az esetben a „K”-nak lehetősége nyílik visszavenni a kapcsolatot a „Co” fővonallal, vagyis az „A” hívóval. A visszavétel általában a „FLASH” billentyű ismételt megnyomásával történik. A „K” és az „A” között ismét felépült kapcsolaton a „K” képes tájékoztatni az addig türelmesen várakozó „A”-t, és ha szükséges, akkor újabb hívásátadás indításra is lehetőség adódik. Mint azt már előbb említettük, a hívásátadás történhet bejelentés nélkül is. Ebben az esetben a „kezelő” funkcióval rendelkező állomás a hívást úgy adja át, hogy nem várja meg a cél állomás bejelentkezését. A következő ábrán egy bejövő hívás bejelentés nélküli átadását láthatjuk. Itt is azzal a feltételezéssel élünk, hogy az „A” hívó a hurokzárást (kézibeszélő beemelést) követően tárcsahangot kapott és sikeresen tárcsázta a „B” hívószámát. A folyamatot tehát attól a ponttól szemléljük, amikor a „B” vonal „kicseng” és a hívó csengetés visszhangot hall.
60
2.2-2. ábra. Bejövő hívás-átadás folyamata – „bejelentés nélküli” hívásátadás A következő példában szintén azt feltételezzük, hogy egy hívó (ábrán az „A”), a „B” hívott oldal számát tárcsázta és a „B” vonal már csengetett állapotban van. Az alközpont
61
konfigurációja szerint a bejövő hívás csengető jelének hatására a „Kezelő” („K”) mellékállomás is csengetett állapotba kerül. A csengetett állapotú „K” vonal beemelése esetén a kezelői mellékállomás off-hook (vagyis hurok zárt) állapotba lép. A hurok zárás hatására az alközpont beszédutat („x1”) épít fel a „K” mellékállomás és a „Co” fővonali áramkör között, valamint a fővonali áramkör is hurok zárt állapotba kerül. A fővonali áramkör hurokzárását követően a PSTN is kiépíti a beszédkapcsolatot a hívó és a hívott („A” és „B”) között („y” beszédút). A felépült beszédkapcsolaton keresztül az „A” és a „K” kommunikál, például „A” kéri, hogy kapcsolják neki „N”-et (természetesen most is illedelmesen bemutatkoznak egymásnak ☺). A hívásátadás folyamat most is a „FLASH” billentyű megnyomásával indul, mely hatására a készülék a „K” vonali hurokáramot rövid időre megszakítja (rövid hurokmegszakítás). A rövid hurokmegszakítás hatására a fővonal „tartás” állapotba kerül, míg a „K” állomás belső (alközponti) tárcsahangot kap. A tárcsahang megérkezését követően a „K” tárcsázza „N” mellékállomás hívószámát, mely, ha ezt megelőzően „N” nyugalmi állapotban volt, akkor azt az alközpont kicsengeti. Jelen esetben a „K” nem várja meg, amíg az „N” a hívást megválaszolja, hanem leteszi a kézibeszélőt, vagyis a hívásátadás folyamatát látszólag magára hagyja. Ekkor, ha az „N” beemeli a kicsengő telefonkészülék kézibeszélőjét, akkor az alközpont azonnal a fővonallal kapcsolja össze azt. Természetesen a fővonali tartási hang is lekapcsolódik, így a felépült kapcsolaton zavartalanul kommunikálhat a keresett „N” és a hívó „A”. Fontos megemlíteni azt, hogy az ilyen típusú hívásátadások esetén a folyamat, időzítésekkel védett. Abban az esetben, ha ez nem így lenne, az alközponti rendszerben „zsákutca” állapotok állhatnának elő. Jó példa erre az, ha a bejelentés nélkül átadott hívás esetén az „N” mellékállomásnál senki sem tartózkodik, akkor az „N”-nek átadott hívás az idők végezetéig csengetné az „N”-et. A T1 védőidőzítést a „K” letétel indította. A T1 lejártának időtartama a gyakorlatban néhányszor 10 másodperc. Abban az esetben, ha a T1 lejárta előtt az „N” nem válaszolja meg a hívást, vagyis a T1 lejár, ez újabb esemény sorozatot indít el. Egyszerűbb alközpontok esetén az alközponti oldalon egy bontási és áramkör felszabadítási folyamat indul. Ez a megoldás nem túl illedelmes a hívó („A”) szemszögéből, hiszen úgy érezheti, hogy „kidobták”. Kifinomultabb, és jobb megoldásnak bizonyul az, ha az átadás kezdeményezőnek (jelen esetben „K”-nak) visszakapcsoljuk a hívást. Ez persze nem egyszerű feladat, hiszen a „K” lehet, hogy egy másik kapcsolatban van. Az ilyen esetekben a visszacsengető hívást várakozó sorba kell szervezni (akár több várakozó is előfordulhat!).
62
Egyszerűbb a helyzet, ha a „K” éppen nyugalmi állapotban van, amikor az „N” irányába indított hívásátadás T1 időzítője lejárt. Ekkor a „K” azonnal visszacsengethető. A visszacsengetett „K”, ha beemeli a kézibeszélőjét, ismét kapcsolatba lép az „A” hívóval. Természetesen most is előállhat az a helyzet, hogy közben „K” kiment a szobából (például lejárt a kezelő munkaideje), ezért a visszacsengetés időtartama is időzítéssel védett. Az időzítés lejárta esetén a legegyszerűbb úgy „elvarrni” a hívásfolyamat szálat, hogy lekapcsoljuk a „K”-ról a csengetést és bontjuk a kapcsolatot. Ettől persze eltérő megoldás is alkalmazható, például úgy, hogy a „K” az időzítésen belül „nem válaszolt” esetben a hívás egy másik megjelölt kezelő vonalán jelentkezik. Ez a láncolat nagyon sokáig folytatható, de gyakorlati jelentősége nincs, hiszen a hívásátadás ezen lépésein (visszacsengetés, újabb timer időzítés, továbbcsengetés stb.) ha végighaladunk, akkor az több perc időtartamot is jelenthet, amit a hívó oldalon várakozó személy valószínűleg már nem vár meg, hanem bontja a hívást.
2.2.2. Konferenciabeszélgetés Az irodai munkák során a gyakorlatban sokszor előfordul, hogy egy kérdés tisztázásához, egy gyors
döntés
meghozatalához
több
résztvevős
beszélgetésre
van
szükségünk.
A
telefonhálózaton bonyolított több résztvevős hívásokat konferenciabeszélgetésnek nevezzük. A konferenciahívást általában a nyilvános hálózat digitális kapcsolóközpontjai is támogatják és több alközpont is nyújt ilyen lehetőséget. A konferenciabeszélgetésbe bevont előfizetők számát általában a „használhatóság” limitálja. Sok résztvevő esetén a telefonos konferenciabeszélgetés hamar kezelhetetlen zűrzavarrá válhat, de a három, vagy négy résztvevős esetek még jól kezelhetők. A videó konferencia jobb átláthatóságot biztosít a résztvevők számára, de az ilyen szolgáltatást támogató rendszerek nagy sávszélességű digitális kapcsolatot igényelnek. Az alábbi folyamat egy egyszerű, alközponton belül felépített háromrésztvevős konferencia felépítését szemlélteti.
63
B A C
Alközpont
Beemel T-hang „B” hívószáma Csengetési visszhang
Csengetés
Beemel
Hurok zár
„A”-„B” beszédkapcsolat Flash
Tartási hang
T-hang „C” hívószáma Csengetés Hurok zár
„A”-„C” beszédkapcsolat Flash
Tartási hang
T-hang Konferencia kód
idő
„A”-„B”-„C” beszédkapcsolat
2.2-3. ábra. Háromrésztvevős konferencia felépítése alközponttal
64
Beemel
2.2.3. Visszahívás kérése Gyakran előfordul, hogy akit éppen telefonon keresünk, az foglalt (például beszédállapotban van). Ekkor időrabló és feleslegesen idegesítő, ha újra és újra sikertelenül próbálkozunk. A telefon alközpontok túlnyomó része manapság kellemes támogatást nyújt ennek a bosszantó problémának az elkerülésére. A szolgáltatás, általában mellékállomásonként engedélyezhető, illetve tiltható. Abban az esetben, ha a hívó vonalon a „visszahívás kérés” szolgáltatás bekapcsolt, és a hívott vonal foglalt (például az éppen beszédállapotban van), akkor a foglaltsági hang kiegészítéseképpen (vagy a helyett) egy tájékoztató üzenetet hallunk, miszerint a visszahívás kérést egy kód (szolgáltatást aktiváló kód) segítségével bekapcsolhatjuk. Ha élni kívánunk a szolgáltatással, akkor az aktiváló kód billentyűzését követően nem kell mást tennünk, mint letenni a telefonkészülék kézibeszélőjét. A teendőinket zavartalanul folytathatjuk (akár más telefonhívást is bonyolíthatunk). Amikor a készülékünk nyugalomban van, és a korábban hívott mellékállomás is felszabadul, akkor az alközpont visszacsenget minket (általában egy normál bejövő hívástól jól megkülönböztethetően eltérő csengetéssel). Ekkor, ha felemeljük a kézibeszélőt, akkor az előzőleg sikertelenül hívott mellékállomás kicseng, és mi csengetés visszhangot hallunk, míg a hívott meg nem válaszolja a hívást.
65
2.2.4. PIN12 kódos felhasználó azonosítás Nagyvállalati irodai kialakításoknál előfordulhat az, hogy az irodai munkahelyek egymással megegyezők és bárki, bárhová ülhet. Ezt gyakran alkalmazzák az olyan irodákban, ahol az irodai alkalmazottaknak otthoni munkavégzésre13 is lehetőségük van, ezért a személyes munkahely kialakítás nem gazdaságos. Ekkor általában az informatikai hátteret egy hordozható számítógép (laptop) jelenti, de a vezetékes telefon rendszer mobilizálására nincs lehetőség. A felhasználói profil, vagyis a mellékállomás konfigurálása egy személyes kód megadásával, az úgynevezett PIN kóddal történik.
Egyszerűbb esetekben a PIN kódot csak a hívás irányok jogosultság ellenőrzéséhez, illetve a költséghely (vagyis ki fizeti a hívás díját) meghatározásához használják. Ekkor a hívószámok nem „vándorolnak” a PIN kóddal, hanem fixen az adott végponthoz rendeltek. A PIN kódos belépésnek is több fajtája ismert. Bizonyos esetekben – általában amikor az adott mellékállomáshoz egy időben több kolléga is hozzáférhet - a PIN kód megadás a hívás indításakor történik és az azonosítás csakis az adott hívásra érvényes. Ekkor a rendszertől függően meglehetősen sok számjegy bevitele válik szükségessé, ami fárasztó, és a rontásnak (hibás kód billentyűzésnek) is nagy az esélye. Kényelmesebb, de nagyobb odafigyelést igényel az a megoldás, ha a munka megkezdésekor a személyes kódunkkal belépünk a rendszerbe, majd a munka végeztével kilépünk. A kilépés rövid kóddal, vagy akár egy billentyű lenyomásával is történhet. A felhasználói mulasztások csökkenthetők egy előre beállított időzítéssel, ugyanis előfordulhat olyan helyzet, hogy a dolgozó a munka végeztével gyorsan összepakol és a telefon rendszerből történő kilépés nélkül távozik az irodából. Mondanom sem kell, hogy milyen károk keletkezhetnek ebből! Gondoljunk arra az esetre, ha távozásunkat követően valaki véletlenül leül ugyanarra a munkahelyre és a telefonkészülékről a PIN kóddal belépett felhasználó terhére, hívásokat bonyolít… Abban az esetben, ha az időkorlátot például a belépéstől számított nyolc órára állítjuk, akkor az némi védelmet jelent a feledékeny felhasználóknak.
12 13
PIN – Personal Identification Number Divatosan: „Home-Office”
66
3. IP alapú útválasztás és csomagok továbbításának alapjai A csomagkapcsolt hálózatok esetén a kapcsolás a csomaghoz fűzött irányítási információk szerint megy végbe. Az IP alapú útválasztás az OSI modell szerinti harmadik (úgynevezett „hálózati” - network) rétegben történik, az útválasztás alapjául egy azonosító, az IP cím szolgál. Az IP címek és azok struktúrája is többlépcsős fejlődésen ment keresztül. A napjainkban használatos IP címeket 4 byte-on (IPv4) ábrázoljuk, mely módszerrel elvileg 232, vagyis 4.294.967.296 állapot írható le. Abban az esetben, ha ez ennyi IP címet jelentene, akkor ez a négy byte elegendő lenne még egy darabig, de az IP címek struktúrája és az egyes tartományok kiosztása sajnos a rendelkezésre álló több mint négymilliárd lehetőséget jelentősen lecsökkentette. Az IP címek struktúráját és az egyes címosztályokat az RFC790, míg az IP csomagok fejlécének szerkezetét az RFC791 ajánlása tartalmazza.
A kevés IP cím probléma feloldását már 1995-ben kidolgozták és az RFC2460-ban (1998ban) szabványosították (IPv6), de a teljeskörű elterjedés még várat magára. Az IP címek, illetve IP tartományok kiosztása hierarchikus rendben történik. A legfelső szervezet, aki a „piramis” csúcsán áll az úgynevezett IANA (Internet Assigned Numbers Authority). Az IANA szervezet alatt öt szervezet található, melyek elméletben azonos súlyúak. Az amerikai kontinens címkiosztását két szervezet, az ARIN és a LACNIC végzi, a RIPE (Réseaux IP Européens) az európai címtartományok kiadását felügyeli, míg az APNIC az ázsiai címek felett bábáskodik.
2.2-1. ábra. IANA szervezetei14 14
Kép forrása: www.iana.org
67
Ezen öt szervezet alatt is hierarchikus rendszer található. Az egyes szervezetekhez kapcsolódnak a nemzeti szervezetek, melyek alatt az úgynevezett regionális egységek állnak, és ezek látják el a „fogyasztókat” (consumer) IP címekkel, illetve IP címtartományokkal.
3.1. IPv4 Az IPv4 esetén az IP címek 4 byte-on, vagyis 4 x 8 biten ábrázoltak. A leírásmód decimális formátumban történik byte-onként, és az egyes egységeket a pont ’.’ karakter választja el. Nyolc biten (egy byte-on) összesen 256 állapot adható meg, vagyis a decimális értékeknek 0 – 255 számtartományba kell esniük. xxxxxxxx
0 - 255
xxxxxxxx
.
0 - 255
xxxxxxxx
.
0 - 255
xxxxxxxx
.
0 - 255
3.1-1. ábra. IP címek és ábrázolása IPv4 esetén Az IP filozófiája szerint kisebb hálózatokat kötnek össze más hálózatokkal, és így alakul ki egy nagyobb méretű hálózat. Ennek megfelelően egy IP címmel rendelkező végpont egy alhálózatnak is a tagja, így a cím két részből áll. A cím egyik része szolgál a hálózat, míg a másik része a hálózat tagjaként működő végpont azonosítására. Ez a módszer jelentősen egyszerűsíti a csomagok irányítását, mivel elegendő csak a célhálózatot megkeresni, a célhálózaton belüli irányítás már a helyi eszközök feladata. A kettévágott IP cím felső fele (a magasabb helyértékű bitek) a hálózat („network”) azonosítására, míg az alsó fele (az alacsonyabb helyértékű bitek) az adott eszköz („host”) azonosítására szolgál. A kettévágás helyét több minden meghatározhatja. Korábban fix határok léteztek, és a fix határok elhelyezkedését az adott IP cím hordozta. Az IP címeket osztályokba sorolták (osztályos IP címek) és az adott osztály mondta meg, hogy hány bit jut a hálózati címnek, és mennyi a „host” címnek. Az „A” osztály esetén a felső 8 bit jelentette a „network” címet, míg a maradék 24 biten helyezkedhettek el az eszközök.
68
xxxxxxxx
0xxxxxxx
0 – 127
.
Hálózati cím
I
0 – 255
xxxxxxxx
.
0 – 255
xxxxxxxx
.
0 – 255
Host cím
3.1-2. ábra. „A” osztályú IP címek Az „A” osztályú IP címet onnan lehet felismerni, hogy a cím legértékesebb bitje mindig ’0’ értéket mutat. Ez sajnos azt jelenti, hogy a 8 biten ábrázolható 256 állapot helyett az ábrázolási tartományunk 0-127 közé fog esni, vagyis „A” osztályú címmel rendelkező hálózatból összesen 27=128db létezhet a nyilvános hálózatban. Természetesen egy „A” osztályú hálózatban jó sok, pontosan 224 - 2db, vagyis 16.777.214 db eszköz kaphat helyet. A „host” cím darabszám számításnál figyelembe vettük azt, hogy minden alhálózat esetén két IP cím nem osztható ki tényleges végpont számára. Amikor a „host” cím értéke csupa ’0’ bitből áll, akkor ez a cím magát a hálózatot azonosítja (a forgalomirányító eszközök ez alapján azonosítják a célhálózatot), míg csupa ’1’ esetén (alsó 3 byte-on: 255.255.255) az adott hálózat összes eleme megcímzésre kerül (úgynevezett broadcast üzenet). Az így érkező üzenet a megcímzett hálózatban található összes eszköznek szól.
A „B” osztályú IP címek esetén a „network” és „host” kettévágás éppen középen történik, vagyis két byte jut a hálózati címre és szintén két byte az adott hálózatban található eszköz azonosítására. A „B” osztályú IP címet onnan lehet felismerni, hogy a cím legértékesebb két bitje mindig ’10’ értéken áll. Ennek ismeretében a legfelső byte értékének decimálisan a 128 – 191 tartományba esőnek kell lennie, vagyis 16384 db „B” osztályú hálózat létezhet.
xxxxxxxx
10xxxxxx
128 – 191
.
0 – 255
Hálózati cím
xxxxxxxx
. I
0 – 255
xxxxxxxx
.
0 – 255
Host cím
3.1-3. ábra. „B” osztályú IP címek Egy ilyen, „B” osztályú hálózatban pontosan 216 - 2db, vagyis maximálisan 65534 db eszköz kaphat helyet.
69
A „C” osztályú IP címek esetén a hálózat azonosítását a felső három byte végzi, azonban a legértékesebb 3 bit értéke ebben az esetben ’110’, így a címezhető hálózatok maximális száma 221-2, azaz 2097152 db.
xxxxxxxx
110xxxxx
192 – 223
.
0 – 255
xxxxxxxx
.
0 – 255
Hálózati cím
xxxxxxxx
.
0 – 255
I
Host cím
3.1-4. ábra. „C” osztályú IP címek A felső három bit állapotának figyelembevételével a „C” osztályú IP cím a 192 – 223 közti tartományba esik. Egy „C” osztályú hálózatban maximálisan 28 - 2db, vagyis 254 db eszköz kaphat helyet.
Az úgynevezett „D” osztályba sorolt IP címek speciális osztályt alkotnak, nem oszthatók ki végpontok számára. Ebbe a címtartományba az úgynevezett multicast (többes címzésű) címek találhatók, amellyel multimédiás tartalmak (videó és hanganyagok) továbbíthatók nagy hatékonysággal (egyetlen forrás, több címzett). A „D” osztályú IP címek felső 4 bitje minden esetben ’1110’ értéket kapja, így a felső byte értéke 224 – 239 tartományba eshet. Az alsó 28 bit multicast címeket jelöl15. A 224.0.0.0 – 224.0.0.255 címmezőt viszont nem szabad használni.
xxxxxxxx
1110xxxx
224 – 239
.
0 – 255
xxxxxxxx
.
0 – 255
xxxxxxxx
.
0 – 255
Multicast cím
3.1-5. ábra. „D” osztályú IP címek Az osztályos IP címek között létezik egy „E” osztály is, melyet az IPv4 tervezésekor a további fejlesztésekhez tartottak fenn. Az „E” osztály ismérve az, hogy a felső 4 bit minden esetben ’1111’ értéken áll16.
15
Az IP Multicast címek alsó 23 bitje lefordítható a 01-00-5E-00-00-00 Ethernet Multicast címek alsó 23 bitjére, így Ethernet helyi hálózatokba könnyen továbbítható. 16 RFC1112 szerint. Ugyanakkor meg kell említeni, hogy a 255.255.255.255 egy speciális cím, melyet „limited broadcast destination address”-nek hívnak és nem tartozik az E osztályhoz.
70
IPv4 esetében az olyan IP címek használata nem megengedett, ahol az első byte értéke 240 – 255 közé esik. Ezt a tartományt „további fejlesztéshez” tartották fenn.
Az előzőleg említett címtartományokon kívül további IP címek használata sem megengedett a nyilvános hálózatokban. Az úgynevezett nem publikus IP tartományok használhatók, de kizárólag olyan magánhálózatokban, amelyek közvetlenül nem kapcsolódnak publikus hálózatokhoz. A nem publikus IP címeket az RFC1918 jelöli ki, melyek a következők: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 Abban az esetben, ha a nyilvános hálózatban olyan üzenet jelenne meg, melyben nem nyilvános IP cím található, akkor azt az útválasztó berendezésnek (router) el kell dobnia. A nem publikus IP címek nagy könnyebbséget jelentenek az IP alapú magánhálózatok kialakításánál. Az egymástól elkülönülő magánhálózatok nyugodtan dolgozhatnak ugyanazon címtartományokkal. Gondoljunk a kisméretű WLAN routerekre, melyek alapértelmezésben a 192.168.1.0 – 192.168.1.255 tartományt támogatják. Hátrányként jelentkezik viszont az az előny, miszerint a nem nyilvános ponton elhelyezkedő eszköz IP címe nem jelenhet meg a nyilvános hálózaton, még akkor sem, ha ez a berendezés a nyilvános hálózaton kíván kommunikálni. Ebben az esetben a nem publikus IP címet át kell fordítani egy nyilvánosra és viszont. Az eljárás neve NAT (Network Address Translation) vagy PAT (Port Adrress Translation, szokás még „Overloaded NAT” néven is emlegetni).
Mint azt előzőleg az úgynevezett „osztályos” IP címeknél láttuk, a hálózat azonosítást és az adott hálózatban lévő eszközök azonosítását az IP címek „kettévágásával” oldották meg. Az IP cím felső része azonosítja magát a hálózatot (network cím), míg az alsó része az adott hálózatban található eszközt (host cím). Osztályos esetben ez a kettévágás fix, és byte határon történik. Sok esetben az adott osztály („A”, „B” vagy „C”) jóval több eszköz használatát tenné lehetővé az adott hálózatban, mint amennyire ténylegesen szükségünk van: „A” osztály esetén: 16.777.214 db; „B” osztály esetén: 65.534 db; „C” osztály esetén: 254 db.
71
Ugyanakkor az IP címek száma IPv4 esetén igencsak szűkös, ezért az ilyen mértékű pazarlás nem célszerű. A pazarlás csökkentése lehetséges az úgynevezett „alhálózatok” képzésével. Ebben az esetben az adott hálózatot további hálózatokra (subnet) bontjuk, vagyis a hálózati cím és a host cím határát a byte határról elmozdítva szabadon „tologatjuk”. Az alhálózat kialakítását az úgynevezett alhálózati maszk, „subnet mask” teszi lehetővé. Az alhálózati maszk szintén 4 byte méretű, viszont kitöltése meglehetősen kötött. A felső bitektől a kevésbé értékes bitek felé haladva egybefüggő logikai ’1’ sorozatnak kell lennie mindaddig a bitpozícióig, amíg az IP címet hálózati címnek kívánjuk értelmezni. Ezt követően a maszk bit értékei kötelezően ’0’ értéket kapnak. A subnet kialakításának szabályait az RFC950 írja elő. Mivel itt már nem érvényesek a címosztályok, ezt a módszert „classless IP”-nek is nevezik. A négy byte-os alhálózati maszk leírásmódja megegyező az IPv4 IP címek leírásával, vagyis négy darab, 8 bites értéket reprezentáló decimális szám formájában jelenítjük meg és azokat pont ’.’ karakterrel választjuk el. Nézzük meg, hogy az egyes osztályos IP címekhez milyen subnet maszk tartozik, ami nem módosítja az adott osztály szerinti network – host felosztást:
00000000
11111111
255
.
Hálózati cím
I
0
00000000
.
0
00000000
.
0
Host cím tartomány
tartomány
3.1-6. ábra. „A” osztályú IP címek subnet maszkja
11111111
255
11111111
.
255
Hálózati cím tartomány
00000000
. I
0
00000000
.
0
Host cím tartomány
3.1-7. ábra. „B” osztályú IP címek subnet maszkja 11111111
255
11111111
.
255 Hálózati cím
11111111
.
255
00000000
.
0
I
Host cím
3.1-8. ábra. „C” osztályú IP címek subnet maszkja
72
Mint azt az osztályos IP címeknél láttuk, egy hálózatban ha „n” bit határozza meg a host címet, akkor az adott hálózatban 2n – 2db eszköz kaphat helyet, ugyanis 1 cím magát a hálózatot azonosítja (ekkor az összes host címbit ’0’) és egy cím pedig az adott hálózatban a mindenkinek szóló úgynevezett „broadcast” üzenetet jelenti. Ez ugyanígy van az alhálózati kialakításoknál is! Ezen okból az alhálózati maszk képzésének egy újabb szabályát állapíthatjuk meg, miszerint a subnet maszk alsó két bitjének értéke minden esetben ’0’-nak kell lennie. Ez logikus, hiszen nincs értelme olyan hálózatot létrehozni, amelyben nincs eszköz (vagyis host). A 2n – 2db összefüggés szerint pedig csakis akkor kapunk pozitív egész számot, ha az „n” értéke legalább kettő. A kialakítható legkisebb alhálózat méret ezek szerint az a hálózat, melyben a host cím 2 bites, ekkor ebben a hálózatban 2 eszköz kaphat helyet.
A következő példában egy „C” osztályú IP címtartomány 8 elemű (6 végpont, hálózati cím, broadcast cím) alhálózatokra bontását vizsgáljuk meg. A kiinduló hálózati IP címünk legyen 220.10.5.0. A 8 címhez (ami 6 végpont címet, egy broadcast címet és egy, magát a hálózatot azonosító címet jelenti) 3 bit használata szükséges, tehát a hálózati bitek számát kell az eredeti 24 bitről 29 bitre megnövelni a végpont bitek rovására. Ekkor 29 hálózati bitre és 3 host bitre bomlik a 32 bites cím. Magát az alap hálózatot a 220.10.5.0 IP cím azonosítja és ebben a hálózatban található összes host-ot a 220.10.5.255 cím szólítja meg. Subnet nélkül maximum 254 db eszköz kaphatna helyet, a 220.10.5.1 címtől egészen a 220.10.5.254 címig. A „C” osztályhoz tartozó alapértelmezett subnet maszk értéke 255.255.255.0. A 8 elemű alhálózat kialakításához a hálózati maszk értékének 29 darab ’1’és 3 darab ’0’ bitet kell tartalmaznia. Ezt a bináris számot átalakítva az IP címeknél megismert módszerrel, a maszk értékének 255.255.255.248-at kapunk. Ha az IP cím és a maszk bitjei között logikai ÉS kapcsolatot képezünk, akkor megkapjuk a hálózati címet:
11111111
255
11111111
.
11011100
255
11111111
.
00001010
255
11111000
.
00000101
248 00000xxx
220
.
10
.
5
.
0-7
220
.
10
.
5
.
0
A továbbiakban ehhez az alhálózathoz tartozik mindazon eszköz, mely saját IP címükkel és a példában szerepelő 255.255.255.248 maszkkal képzett eredmény a 220.10.5.0 címmel 73
megegyező eredményt adja. Jelen hálózatban összesen 6 db eszköz lehet. Az egyes eszközök címe pedig a következő: 220.10.5.1 : 255.255.255.248 220.10.5.2 : 255.255.255.248 220.10.5.3 : 255.255.255.248 220.10.5.4 : 255.255.255.248 220.10.5.5 : 255.255.255.248 220.10.5.6 : 255.255.255.248 A fenti IP címek bármelyikével ÉS kapcsolatot alakítunk ki a 255.255.255.248 maszkkal, az eredmény mindig 220.10.5.0-nak fog adódni, vagyis az eszközök egy alhálózatban találhatók. Fontos megemlíteni, hogy a fenti példában megadott – és minden, nem alapértelmezett maszkot használó - IP címhez a maszkot mindig hozzá kell írni, hiszen csak így értelmezhető helyesen! A maszk leírása hosszú és „fáradságos”, ezért elterjedt egy rövidített leírás mód is, mely az IP címet követő ’/’ (per) jel után található szám megadja a subnet maszkban szereplő egyesek számát, vagyis azt, hogy a hálózati cím hány bites. Például a 220.10.5.1 : 255.255.255.248 megegyezik a 220.10.5.1/29 értékkel. Minden más cím (kivéve maga a hálózat címe: 220.10.5.0 és a hálózat broadcast címe: 220.10.5.7) a vizsgált alhálózaton kívül esik! Az alhálózati maszkok szerepének fontosságát szemlélteti az alábbi néhány példa: A 220.10.5.16/24 cím jelentése a 220.10.5.0 hálózat 16-os host azonosítóval rendelkező végpont címe. Más subnet maszk esetén a jelentés változik! A 220.10.5.16/29 jelentése viszont a 220.10.5.16 alhálózat címe (vagyis nem végpontcím!).
Egy másik példa szerint a 220.10.5.24/29-et vizsgáljuk meg! Ekkor a host cím 3 bites, ennek az alhálózatnak a címe a 220.10.5.24. A fentivel egyező címet, de más maszkkal másképpen kell értelmeznünk! A 220.10.5.24/28 jelentése a 220.10.5.16 alhálózat 8-as host azonosítóval rendelkező végpontja!
Az IP címek és a hálózati maszk bináris ÉS kapcsolatával határozható meg az adott IP cím befoglaló hálózatának értéke. Az adott hálózat host azonosítóját pedig úgy kapjuk, ha az IP cím és a subnet maszk bitenkénti invertáltjával képzünk logikai ÉS kapcsolatot.
74
3.2. IPv6 Mint azt az előző alfejezetben láttuk, az IPv4 alulméretezése a címek és a címtartományok terén sok gondot jelent, emellett az IPv4 rengeteg biztonsági problémával is küszködik. Az Internet egyre több nyilvános kapcsolódási ponttal rendelkezik, melyekhez egyedi IP címek szükségesek. A probléma korántsem új, a kibővített IP címek rendszerét már 1998-ban kidolgozták és szabványba foglalták. Az IPv6 esetében az IP cím 128 bitből áll. A könnyebb leírhatóság miatt 16 bitenként ábrázoljuk az IP cím számértékeit, de ezt most már nem decimális számokkal, hanem hexadecimális számokkal tesszük. Az egyes 16 bites egységeket kettősponttal ’:’ választjuk el. A 16 bites egységek négy karakterrel írhatók le, ahol az ábrázolás tartománya 0000-FFFF lehet. Aki hadilábon áll a hexadecimális számrendszerrel (mert mondjuk a két kezén 2⋅5=0AH db ujja van és nem 10H db ☺ ), akkor javaslom a melléklet fellapozását! Az ábrázolásnál további egyszerűsítés is megengedett, miszerint, ha az egymás melletti, és egy ábrázolási csoportba tartozó minden digit ’0’ értéken áll, akkor nem kell kiírni azt, hogy 0000, hanem elegendő egy nulla leírása. Például a 2001:0252:0000:0001:0000:0000:2008:0006 címet17 írhatjuk 2001:0252:0:0001:0:0:2008:0006 -nak További egyszerűsítés esetén, ha az egy nullának (ami valójában négy nulla és 16 bit értékét határozza meg) a leírását is elhagyjuk, ekkor a kettőspont helyett úgynevezett „négyespont” jelenik meg, valamint az egységenként a felső helyértékeken szereplő nullák is mindent további jelölés nélkül elhagyhatók. Mindezek tükrében az IP cím egyszerűbben: 2001:252:0:1::2008:6 Abban az esetben, ha a négyespont helyén több ’0000’ csoport elhagyása történt, akkor a címben ezzel az egyszerűsítéssel csak egyszer élhetünk, hiszen ellenkező esetben a teljes cím visszaállításra több lehetőség adódna. Az IPv6 kiemelkedő előnye az, hogy a címek mennyisége miatt 2128 (körülbelül 3,4×1038 db cím) a címtartomány kimeríthetetlennek tűnik (bár az IBM PC-k 640 kbyte méretű RAM területe, valamint az IPv4 címek is kimeríthetetlennek tűntek egykor). A Föld minden egyes négyzetméterére 6,67×1023 darab IPv6 címet lehetne kiosztani.
17
2008-as Pekingi Olimpia hivatalos honlapjának IPv6 címe (http://ipv6.beijing2008.cn/en)
75
Még egy fontos dolog az IPv6 esetében az, hogy nincs hálózati maszk (vagyis, ha úgy fogjuk fel, hogy van, akkor az fix érték), a cím prefixek 64 bitesek. A továbbiakban néhány speciális IPv6 címet mutatunk be felsorolás szinten: ::/128 – csupa 0-ból áll, ez a cím nem kiosztható ::1/128 – localhost cím ::ffff:0:0:0/96 – átfordított (mapped) IPv4-es címekre 2001:db8::/32 – dokumentációkban és IPv6 leírásokban használt cím fe80::/64 – analóg az IPv4-es 169.254.x.x autókonfigurációs címmel ff00::/8 – multicast prefix a multicast címekhez 2002::/16 - 6to4 címek, a IANA speciális allokációja, ipv4-be ágyazott ipv6 Az IPv4-ről az IPv6 címek használatára folyamatos az átállás, ezért gondoskodni kellett az együttműködésről. Lehetőség van az IPv4 címek IPv6 leképezésére, ezt „átfordításnak” szokták emlegetni, az angol szakkifejezés pedig a „mapped IPv4”. Az átfordított IPv4 címet onnan lehet felismerni, hogy az első 96 bit értéke egy előre definiált prefix (::ffff:0:0:0) és ehhez fűzik hozzá a 32 bites IPv4 –es IP címet. Az IPv4 hálózaton az IPv6 csomagok úgynevezett „tuneling” eljárással továbbíthatók, ezt részletesebben később fejtjük ki.
76
3.3. IP – Internet Protocol Az IP címek kezelése, valamint a csomagok IP cím alapján történő irányítása az OSI rétegmodell szerint a 3. rétegben (hálózati – „network”) valósul meg. A kapcsolást végző protokoll, úgynevezett „megbízhatatlan” kategóriába sorolt, hiszen maga a kapcsoló protokoll garanciát nem vállal arra, hogy a csomagok a cél állomáshoz rendben és hibamentesen megérkezzenek. A hibajavítás (ha ez szükséges) általában a felsőbb rétegekben valósul meg (például a szállítási rétegben működő TCP – erre majd később kitérünk). A továbbítandó adat csomag (datagram) a hálózati rétegben egy úgynevezett IP fejlécet kap, mely IPv4 esetén a következőképpen néz ki:
4 bit
Version
4 bit
IHL
8 bit
8 bit
Type of service
Identification Time to Live
8 bit
Total Length Flags
Protocol
Fragment offset Header Checksum
Source IP address Destination IP address Option
Padding
DATAGRAM
3.3-1. ábra. IPv4 fejléccel kiegészített datagram A „Version” mező (4 bites hosszúságú) hordozza a verziószámot, ami IPv4 esetén a 4-es értéket kapta (bináris ’0100’).
IHL – „IP Header Length” mező adja meg az IP fejléc hosszát. A fenti ábra nem szemlélteti, de az IP fejléc „Option” mezője változó hosszúságú lehet. Az IHL értéke 5 – 15 közé eső szám lehet, és azt mondja meg, hogy az IP fejléc mennyi 32 bites szóból áll (minimum: 5 ⋅ 32 = 160bit → 20bájt illetve maximum: 15 ⋅ 32 = 480bit → 60bájt ). A „Type of Service” mező jelentése menetközben megváltozott (talán helyesebb, ha azt mondjuk, hogy kibővült). A napjainkban használatos elnevezés a „Differenciated Services”, 77
vagyis DS. A DS tartalmára vonatkozó előírásokat az RFC3168 határozza meg. Korábban ebben a mezőben (Type of Service) lehetett jelezni azt, hogy az adott csomag úgynevezett „normál”, vagy „hálózatvezérlő” csomag-e. Ennek jelentése a szolgáltatás-osztály azonosítása, mely alapján a csomagtovábbítás priorizálható.
A „Total Length” mező adja meg a teljes csomagméretet byte-ban (ebbe az IP Header is beletartozik). A mező 16 bites, így a csomag maximális mérete 65535 byte, vagyis 64 kbyte-1 byte lehet. Mivel a fejléc mérete 20 és 60 byte közti lehet, így a datagram maximális mérete a tényleges fejléctől függően 20 illetve 60 byte híján 64 kbyte – 1 byte méretű lehet.
Az „Identification” mezőt elsődlegesen az eredeti IP datagram töredékeinek (fragmentjeinek) beazonosítására használjuk, amennyiben a datagram továbbítása csak kisebb méretű töredékekben volt lehetséges.
A „Flags” nevű mező három jelzőbitet tartalmaz és az úgynevezett fragmentálással kapcsolatos. Itt talán célszerű megállnunk és áttekintenünk, hogy mi az, és miért szükséges a „fragmentálás”! Az eljárás során a továbbítandó csomagot darabokra vághatjuk. Erre azért lehet szükség, mert az egyes útirányok átvitel technikai jellemzői (leginkább a bit hibaarány érdekes most) különbözők lehetnek. Abban az esetben, ha a bit hibaarány (hibás bitek/összes átvitt bitek aránya) érték azt mutatja, hogy egy adott keretben igen nagy valószínűséggel előfordul hibás bit, és a hibajavítást újraküldéssel kívánjuk megoldani, akkor az átvitel ellehetetlenedik. Példaképpen vizsgáljunk meg egy 64 kbyte méretű csomagot (65536 bitből áll). Amennyiben ezt a méretű csomagot olyan átviteli útra irányítanánk, mely 2 ⋅ 10 −5 BER jellemzőt mutat (vagyis a bithibák egyenletes eloszlását feltételezve minden ötvenezredik bit meghibásodik), akkor az átvitel lehetetlenné válik. Viszont, ha ezt az átküldendő csomagot tíz részre bontjuk, akkor az egymás után küldött csomagok közül nagy (előzőnél nagyobb) valószínűséggel csak egy vagy kettő fog meghibásodni, mely hibák a hibás csomagok újraküldésével már javíthatók. Bizonyos átviteli technológiák a keretszervezésük során (ami az OSI rétegmodell szerinti második rétegben történik) figyelembe veszik a fizikai közeg jellemzőit. Például Ethernet esetében ez 1500 byte, vagyis 12 000 bit. Amennyiben a csomagunk egy ilyen hálózat felé irányítódik, a tördelés (fragmentálás) elkerülhetetlen. 78
A kapcsoló eszközökben az egyes irányokra (interfészekre) vonatkozó maximális hosszt az MTU (Maximum Transmission Unit) tartalmazza. Az MTU byte-okban adja meg a maximális méretet. Miután tisztáztuk a csomag-tördelés szükségességét, nézzük meg a konkrét Flag bitek jelentését! A 0. bit értéke fix ’0’, további fejlesztésekhez tartották fenn. Az 1. bit a DF (Don’t Fragment). Abban az esetben, ha ezt a bitet ’1’-be állítjuk, az azt jelenti, hogy a csomag tördelése nem megengedett. Ekkor, ha a csomagunk olyan irányba menne, ahol a tördelés elkerülhetetlen, akkor a csomagot a kapcsoló eszköz el fogja dobni és a feladót egy ICMP „Destination Unreachable” típusú üzenettel értesíti („Fragmentation needed and DF set” kód). A 2. bit elnevezése MF (More Fragment). Abban az esetben áll ez a bit ’1’ értéken, ha a csomagunk feldarabolt és a most érkező csomagot még további „töredék” csomag követi. Az utolsó „töredék” csomag esetén ez a bit már ’0’-ban áll. Ezt a bitet a tördelést végző eszköz állítja be.
A „Fragment offset” mező szintén a tördeléssel kapcsolatos, 13 bit hosszúságú, és 8 byte (64 bit) egységekből álló blokkokban adja meg az adott töredék helyét (offset-jét) a teljes IP csomagon belül. Az első töredék esetében ez a mező összes bitje ’0’-ban áll. Példaként vizsgáljuk meg a következő esetet: Egy 4500 byte hosszúságú datagrammot, amely 20 byte-os IP fejléccel rendelkezik, az útválasztó eszköz egy olyan interfész felé irányítja, melynek MTU értéke 2500 (vagyis maximum 2500 byte méretű lehet a továbbított csomag). •
Abban az esetben, ha a DF bit ’1’ értékű, akkor a csomagot az útválasztó eldobja;
•
Abban az esetben, ha a DF bit ’0’ értéken áll, akkor az eszköz a csomagot jelen esetben két részre fogja bontani. Az első csomag az IP fejléccel együtt 2500 byte méretű lesz (első fragment datagram mérete 2480 byte), a Fragment offset = ’0000000000000’, míg az MF bit ’1’-ben fog állni. A második töredék csomag mérete 2020 byte, melyből a datagram mérete 2000 byte és a fejléc pedig ismét 20 byte (az eddigi összes IP fejlécben nulla Option mezőt feltételeztünk). Ebben a csomagban az MF bit ’0’-ban áll, míg a Fragment offset a decimális 310 értéket (2480/8) tárolja.
Fontos megemlíteni, hogy egy fragmentált csomagot a köztes útválasztó eszközök nem állíthatnak újra össze, ez a feladat a címzett végpontra marad. A csomagok tördelése rengeteg
79
biztonsági problémát vet fel (például a teljes csomagon kívülre mutató Fragment Offset érték, egymást átlapoló töredékek), ezért az IPv6 nem tartalmazza ezt a funkciót.
A „Time to Live” – TTL egy 8 bites mező, amely eredetileg a csomag hálózati továbbítás során eltölthető idejét tartalmazta másodpercben, maximális értéke 255 lehet. Minden útválasztó eszköz levonja belőle a továbbításhoz szükségessé vált időt, és ha ez nullára csökken, akkor a csomagot eldobja. Emellett azonban az is kikötés, hogy a TTL mező minden routolásnál eggyel csökkenjen. Mivel a tipikus útválasztási idő kevesebb, mint 1 másodperc, ezért általánosságban ez az érték a továbbítási lánc maximális hosszát definiálja (szokás ezért „Hop-count”-nak is nevezni). A mező feladata az, hogy segítségével az „eltévedt” (például végtelen továbbítási hurokba került) csomagok automatikusan törlődjenek egy idő múlva és ne bolyongjanak a hálózatban végtelen ideig, a hasznos sávszélességet csökkentve.
A „Protocol” mező hordozza azt az információt, hogy az adott IP csomag milyen protokoll szerinti információt (jelen esetben a „Datagramm”-ról van szó) hordoz. Az RFC1700 értelmében a mező néhány értékét és annak jelentését adjuk meg (a teljes táblázat a mellékletben megtatlálható): 1 – ICMP; 2 – IGMP; 6 – TCP; 7 – UDP.
A „Header Checksum” segítségével a fogadó oldal képes ellenőrizni az IP fejléc hibátlanságát. Ez a mező 16 bites, és minden útválasztó berendezésnek ezt az értéket újra kell számítania, mert a TTL mező csökkentése új ellenőrző mező tartalmat igényel. Az ellenőrző összeg számítás módját az RFC 1071 írja elő.
A „Source IP address” a forrás állomás (küldő), míg a „Destination IP address” a cél állomás (címzett) IP címe ami IPv4 esetén mindkét mezőben 32bit. Nem szabad elfelejtenünk azt, hogy az IP hálózatban megjelenő csomagok esetén a „Source IP address” nem minden esetben a konkrét küldő címe! A magán hálózatról indított csomag esetében a nem publikus IP cím átfordításra kerül (NAT – Network Address Translation).
80
Az „Option” mező jelenléte nem kötelező, mint a nevében benne szerepel, opcionális. Abban az esetben, ha az IP keret tartalmaz „Option” mezőt, akkor az IHL > 5 értéken áll. Az „Option” mező hosszúsága változó lehet, ezért a végén egy byte lezáró kódnak kell szerepelnie, ami minden esetben 0x00 tartalmú byte (End of Option List lezáró karakternek is szokás nevezni). A „Padding” mező feladata mindössze annyi, hogy az Option mezőt kiegészítse 32 bit egész számú többszörösére (gondoljunk az IHL mező jelentésére).
Az IPv6 csomag fejléc (IPv6 header) felépítésében hasonló az IPv4 fejléchez. Az egyes mezők mérete természetesen megváltozott és esetenként azok új nevet is kaptak. A fejléc fix hosszúságú része 40 byte-ból áll, melyet opcionális mezők („Extension Headers”) követhetnek.
4 bit
Version
4 bit
8 bit
8 bit
Traffic Class Payload Length
8 bit
Flow Label Next Header
Hop Limit
Source IP address
Destination IP address
3.3-2. ábra. IPv6 fejléc fix hosszúságú része (RFC2460) A „Version” mező (4 bites hosszúságú) hordozza a verziószámot, ami IPv6 esetén a 6-os értéket kapta (bináris ’0110’).
A „Traffic Class” 8 bites, és két információt hordoz. A felső hat biten kap helyet az úgynevezett DSCP (Differentiated Services Code Point), mely a csomagot osztályhoz rendeli, míg a maradék két bit, mely a legkisebb helyértéken helyezkedik el az ECN (Explicit Congestion Notification).
81
A DSCP valójában az IPv4-nél megismert Type of Service funkcióját tölti be, az adott csomag QoS osztályba sorolása adható meg itt. A DSCP mező kitöltését a következő táblázat adja meg (RFC4594):
Szolgáltatás
DSCP mező
DSCP bináris
osztály neve:
neve:
értéke:
CS6
110000
Hálózat routing
Telephony
EF
101110
IP telefon adatátvitel
Signaling
CS5
101000
IP telefon jelzésátvitel
Multimedia
AF41
100010
H.323/V2 videó konferencia
Conferencing
AF42
100100
AF43
100110
CS4
100000
Network Control
Real-Time Interactive
Videó konferencia és interaktív játék
Multimedia
AF31
011010
Streaming
AF32
011100
AF33
011110
CS3
011000
Broadcast Video
Alkalmazási példa:
Streaming vidó és audió
Broadcast TV adás és valós idejű események közvetítése
Low-Latency
AF21
010010
Kliens – szerver tranzakciók,
Data
AF22
010100
WEB alapú felhasználás
AF23
010110
CS2
010000
Hálózat üzemeltetés
High-Throughput
AF11
001010
Úgynevezett „Store and
Data
AF12
001100
forward” alkalmazások,
AF13
001110
OAM,
OAM&P
(Operation, Administration, Maintenance and Provisoring)
például: SMS, MMS, e-mail
Standard
DF (CS0)
000000
applications Low-Priority Data
Ekkor kapjuk a jól ismert „Best effort”-ot
CS1
001000
Bármilyen adatátviteli szolgáltatás, mely nem igényel sávszélesség garanciát
82
Az ECN bitek segítségével a torlódások jelezhetők, és mintegy az IP és a TCP protokoll kiegészítésének tekinthetők. Korábban a TCP/IP hálózatok csomag eldobással voltak csak képesek jelezni a hálózati torlódásokat. A torlódás jelzés a végpontok között zajlik (ha mindketten úgy akarják) és persze csak akkor jöhet létre mindez, ha a hálózat ezt az információt nem nyeli le. Abban az esetben, ha az ECN = ’00’, akkor az azt jelenti, hogy az átvitel nem ECN kompatibilis. Az ’10’ és a ’01’ jelzi az ECN kompatibilitás képes átvitelt, míg torlódás esetén vált ez a két bit ’11’-be (korábban ekkor volt csomageldobás).
A „Flow Label” nevű 20 bites mezőt a valós idejű alkalmazásokhoz alakították ki.
A „Payload length” mező 16 bit hosszúságú és megadja azt, hogy a szállított információ mérete hány oktetből áll. Abban az esetben, ha az IPv6 csomag úgynevezett „Extension Header”-t is tartalmaz, akkor az is beleszámít ebbe a hosszba. Amennyiben a Payload length mezőt 0x0000-ra állítjuk, akkor úgynevezett „Jumbo” méretű payload (Jumbogram) fűzhető az IPv6 fejléchez. A Jumbogram mérete közel 4 Gbyte lehet.
A „Next Header” a konstans IPv6 header típusát adja meg. Az azonosító 8 bites, kitöltését az RFC1700 írja elő. A „Hop Limit” az IPv4-ben már megismert TTL mezővel egyenértékű. A csomag indításakor akkora számértéket kell beállítani, amennyi router eszközön való áthaladást megengedünk a csomagnak. Minden router ezt az értéket eggyel csökkenti. Amikor ez a 8 bites mező eléri a nullát, a router a csomagot nem továbbítja, hanem eldobja azt.
A „Source IP address” a forrás állomás (küldő) IP címe, míg a „Destination IP address” ami IPv6 esetén 128 bit – 128 bit.
IPv4 – IPv6 átállás Az IPv4 IP címek fogyása miatt egyre égetőbbé vált az IPv6 bevezetése. Természetesen az átállás nem mehet végbe egyik napról a másikra, vagyis folyamatos átállás szükséges. Elméletben a hálózatban működő útválasztók esetében szoftvercserével megoldható lenne az átállás, de a gyakorlatban sajnos ez az út nem mindig járható, ugyanis az IPv6 routing sokkal erőforrás igényesebb, mint az IPv4 kapcsolás. A nagyobb erőforrást felemésztő szoftver, ahhoz, hogy a korábbival megegyező forgalmat legyen képes lebonyolítani, nagyobb 83
teljesítményű hardvert feltételez, vagyis az ilyen esetekben csakis a komplett berendezés lecserélése ad megoldást. A fentiekből látszik, hogy jelenleg találhatók olyan hálózatrészek, melyek IPv6 átállása csak igen költségesen valósítható meg, így mindenképpen számolni kell az IPv4 – IPv6 együttműködéssel. A két rendszer együttéléséhez szükséges az IP címek megegyezés szerinti konvertálása, valamint az átjárás biztosítása a különböző hálózatokba. Az együttműködést képes garantálni az úgynevezett dual IP stack megoldás, Ebben az esetben, a rendszerben az IPv4 és az IPv6 kapcsolás működik.
IP címek konvertálása
Az IPv4 címek átalakítása IPv6 címmé úgy történik, hogy az első 80 bit értékét ’0’-ba állítják. Az azt követő 16 bitet ’1’-be, majd az azt követő 32 bitre írják az IPv4 címet.
0000:0000:0000:0000:0000:ffff:IPv4_cím Egyszerűsített leírás esetén az egymás mellett lévő nullákat és azok csoportjait négyesponttal helyettesíthetjük:
::ffff:IPv4_cím Természetesen az „IPv4_cím” sztring helyére a tényleges IP címnek megfelelő értékeket kell behelyettesíteni.
IPv6 tunneling
Az IPv6 hálózatok elérését IPv4 hálózaton, vagy azok közbeiktatásával is el kell tudnunk érni. A feladat mindössze annyi, hogy meg kell keresni azt a módszert, hogy miképpen lehet IPv6 szerint összeállított csomagokat az IPv4 hálózaton továbbítani. Az ilyen feladatokra jó bevált módszer a „tunneling”. Ebben az esetben az IPv4 datagramját egy IPv6 csomag fogja jelenteni. A konkrét eljárást az RFC 3056 definiálja. Az IPv4 fejléc protokoll azonosítóját (Protocol Type) ekkor 41 értékre kell állítani.
3.3-3. ábra. IPv6 átvitele IPv4 hálózaton
84
Az IPv4 hálózaton a kapcsolók számára az IP csomag IPv4 csomagnak látszik, így azok a kapcsolási irányt a többi IPv4 csomaggal megegyezően képesek irányítani. Abban az esetben, ha az IPv4-nek látszó IPv6 csomag egy olyan kapcsolóhoz ér, mely valamely interfésze IPv6 hálózathoz kapcsolódik, akkor kicsomagolja az IPv6-ot az IPv4-ből és már IPv6 csomagként továbbítja. Azt a tényt, hogy egy IPv4-be burkolt IPv6 csomagról van szó, a router a protokoll azonosítóból („Protocol Type” = 41) veszi észre.
Ver=4
IHL
Type of service
Total Length
Identification Time to Live
Flags
Protocol = 41
Fragment offset Header Checksumm
Source IP address (IPv4) Destination IP address (IPv4) Option Ver=6
Padding
Traffic Class Payload Length
Flow Label Next Header
Hop Limit
Source IP address (IPv6)
Destination IP address (IPv6)
DATAGRAM
3.3-4. ábra. IPv4-be csomagolt IPv6 csomag (tunneling) Természetesen minden ilyen át- és visszafordítás erőforrás igényes feladat.
85
3.4. ICMP – Internet Control Message Protocol Általában a Host-ok (állomások) közti datagram átvitelre az Internet Protokollt (IP-t) használjuk. A datagram átvitelét hálózatok biztosítják. A hálózatok között a Gateway eszközök teremtik meg a kapcsolatot. A Gateway-ek, valamint a célállomások (cél Host-ok) a forrás Host eszközökkel kommunikálnak (például error riport az adatátvitel során). Az ilyen típusú kommunikációkra alakították ki az ICMP-t (Internet Control Message Protocol). Az ICMP-t az RFC792 ajánlás definiálja. Az IP nem garantálja azt, hogy az elküldött adatok 100% biztonsággal megérkeznek a célállomáshoz. Amennyiben szükséges a garancia, akkor azt a felsőbb rétegekben működő protokolloknak kell biztosítaniuk.
Az ICMP a harmadik rétegben (hálózati rétegben) működő protokoll, minden IP implementáció köteles ezt is megvalósítani. Az ICMP Header az IPv4 Header után következik, ekkor az IP fejléc „Protocol” mező ’1’értéket kap.
8 bit
8 bit
Type
Code
8 bit
ID
8 bit
Checksum Sequence
3.4-1. ábra. IPv4 fejlécet követő ICMP fejléc Az operációs rendszerekben jól ismert PING parancs hatására is egy ICMP üzenet kerül kiküldésre (ICMP – Ping; Echo Reply), mely esetén a Type mező = 0, valamint a Code mező = 0 értéken áll. A további ICMP üzenetek kódjait a mellékletben adtuk meg.
86
3.5. TCP – Transmission Control Protocol A TCP az OSI rétegmodell szerinti negyedik, úgynevezett szállítási (Transport) rétegében működik. A TCP feladata az, hogy az elveszett, megsérült, duplikálódott, nem helyes sorrendben érkezett csomagokat érzékelje és az ilyen problémákat kiküszöbölje. A felsorolt problémák elhárítása úgy lehetséges, hogy minden egyes kiküldött byte-ot számolunk (a TCP egy byte orientált protokoll), és a fogadó oldalnak pozitív nyugtázást kell adnia a beérkezett byte-ról. Ha egy bizonyos időn belül nem jön pozitív megerősítés, akkor a küldő oldal újraküldi az adatot. Az újraküldés persze a vételi oldalon duplikációt okozhat, ráadásul előfordulhat csomagsorrend csere is. A duplikációs probléma, valamint a csomagsorrend csere a sorszám alapján a vételi oldalon kezelhetővé válik. A TCP-t az RFC793 ajánlás rögzíti.
8 bit
8 bit
8 bit
Source Port
8 bit
Destination Port Sequence Number Acknowledgement Number
Data
Fenntartott
Control bitek
Offset (4)
bitek (6)
( 6 bit )
Window
Checksum
Urgent Pointer Options
Padding Data
3.5-1. ábra. TCP keret felépítése A TCP keretet egy IP csomag szállítja (vagyis az IP datagram egy TCP csomag), és ekkor az IP fejléc „Protocol” mezőben ’6’ érték áll.
A TCP keret „Source Port” elnevezésű mezője a forrás port sorszámát hordozza. A „Destination Port” mezőben a cél port sorszám található. Mindkét mező 16 bites. A Port azonosító feladata a végponton működő küldő- és a fogadó alkalmazás azonosítása, ennek segítségével válik lehetővé az, hogy egy végponton egy időben több különböző
87
alkalmazás is képes legyen adatokat küldeni és fogadni. Az IP önmagában erre nem képes, hiszen az IP csomaginformációi csak a küldő és fogadó végpont IP címét tartalmazza. A port címek hasonlíthatók egy telefonszám (mint az IP cím analógiája) mögött működő mellékek azonosítójához. A port címeket három csoportba (kategóriába) soroljuk: •
„well-known” portok, melyek fixen egy adott szolgáltatáshoz tartoznak (Táblázatosan a mellékletben ismertetjük);
•
„registered” portok;
•
„dynamic/private” portok.
A „Sequence Number” mező 32 bites, mely ebben a csomagban elküldött első oktet sorszámát hordozza, kivéve, ha a „SYN” Control bit ’1’ben áll, mert ekkor a „Sequence Number” egy kezdeti értéket (ISN – Initial Sequence Number) jelöl. Ebben az esetben az első adat oktet sorszáma ISN+1. Az ISN generálása során a végpont egy 32 bites számlálót üzemeltet, amelyet minden 4µs-ban megnövel18. Új ISN esetén a számláló aktuális értékét használják, így garantálható hogy közel öt óra időtartamon belül nem ismétlődjön meg egy korábbi érték. Az „Acknowledgement Number” mező 32 bites és a feladata a fogadott adatok nyugtázása. Abban az esetben, ha ez a mező egy visszanyugtázott „Sequence Number”-t tartalmaz, akkor az ACK bit ’1’ értéken áll. A „Data Offset” 4 bites mező, mely a TCP Header végét mutatja (vagyis a TCP által hordozott adatmező elejét). Ez azért szükséges, mert a TCP Header hosszúsága az Option mező miatt változhat. A „Data Offset” biteket 6, további fejlesztésekhez fenntartott bit követi, melyek értéke ’0’.
A „Control” biteket (6 bit) a következő bitek alkotják: URG ACK PSH RST SYN FIN
- Urgent Pointer field significant - Acknowledgment field significant - Push Function - Reset the connection - Synchronize sequence numbers - No more data from sender
A „Window” mező 16 bitből áll, segítségével jelezhetjük a fogadó eszköz rendelkezésére álló buffer méretét, vagyis itt adhatjuk meg a fogadni kész maximális adatmennyiség méretét.
18
RFC793 ajánlás szerint
88
Jelentősége a csúszó ablakos (sliding window) nyugtázásnál van. A csúszó ablakos nyugtázás azt jelenti, hogy az adó oldalnak nem kell megvárnia azt, hogy az elküldött TCP csomagra megérkezzen a pozitív nyugta, mert ez nagyon lelassítaná a kommunikációt. E helyett az adó eszköz több csomagot küldhet el a célállomás felé (maximum annyit, amennyit a Window mező engedélyezett), melyekre a nyugta majd később fog érkezni. Amint a nyugta megérkezik az egyik csomagra, az ablak „továbbcsúszik” és ismét további üzenetek elküldésére van lehetőség. Másik használati célja a torlódásvezérlés. Abban az esetben, ha a fogadó eszköz valamilyen okból nem tud éppen adatot fogadni (éppen kifogyott a szükséges erőforrásból), akkor egy „0” méretű Window mezővel ideiglenesen leállíthatja az adatok küldését, majd ha ismét képes adatokat fogadni, akkor egy újabb csomaggal ismét engedélyezheti a küldést. A „Checksum” mező 16 bites, mely értéke, a „header” és a „text” minden egyes 16 bites szavának egyes komplemenséből képzett összeg. Az „Urgent Pointer” mező kizárólag akkor értelmezett, ha az URG bit ’1’-ben áll. Ezen a 16 biten adható meg egy eltolási érték, mely a datagramban szereplő „sürgős” adatokra mutat. Sürgős adat lehet például egy megszakítási üzenet.
A TCP kapcsolatfelvétel úgynevezett háromutas kézfogással („Three-way handshake”) történik, melyet a következő ábra szemléltet:
3.5-2. ábra. TCP kapcsolatfelvétel „A” és „B” állomás között A fenti ábrán az „A” állomás kezdeményezi a TCP kapcsolat kiépítést egy TCP csomag küldésével, melynek fejlécében egy „x” értékű (véletlen) sorszám (Sequence Number) található. Azt, hogy ez egy kiinduló érték, a fejlécben található „SYN” bit ’1’ értéke mutatja. A „B” állomás miután vette a csomagot, egy másik csomaggal válaszol, melyben „B” is megad egy kiinduló sorszámot (Sequence Number = y és a SYN bit = ’1’), valamint az „Acknowledgement Number” mezőben visszaküldi az előzőleg vett, „A”-tól kapott Sequence
89
Number eggyel megnövelt (x+1) értékét. Miután ezt fogadta az „A” állomás, az is visszanyugtázza az „Acknowledgement Number” mezőben az y+1 értéket. A nyugtázások során, azt, hogy az „Acknowledgement Number” mezőben érvényes (nyugta) sorszám szerepel, az ACK bit ’1’ értéke jelzi. A kapcsolat során a SYN bit a továbbiakban ’0’ értéken fog állni, hiszen az adatküldések során a „Sequence Number” mező az átküldött okteteknek megfelelően inkrementálódik. A kapcsolat bontás folyamata úgy indul, hogy a bontani kívánó állomás a TCP fejléc FIN bitjét ’1’-be állítja. A másik fél ezt nyugtázza (ACK-val), és nem feltétlenül szükséges, hogy a másik fél is ekkor küldjön bontási kérelmet. A következő ábrán egy olyan bontási folyamatot mutatunk be, ahol az „A” állomás kezdeményezi a TCP kapcsolat bontását.
3.5-3. ábra. TCP bontási folyamat A teljes bontás akkor zajlik le, ha mindkét állomás a FIN bit ’1’-be állításával kérte a bontást és ezt a másik fél ACK-val nyugtázta. A következő ábrán a teljes TCP állapotdiagramját tüntettük fel.
90
3.5-4. ábra. TCP állapotok és a köztük lévő átmenetek A fenti ábrán az állapotok elnevezése és értelmezése a következő: CLOSED
= Nincs nyitott, vagy függő kapcsolat
LISTEN
= Bejövő kapcsolatra vár
SYN RCVD
= Kapcsolatfelvételi kérés hatására a kapcsolatfelvétel indul
SYN SENT
= Kapcsolatfelvétel kezdeményezés indult
ESTABLISHED = Kapcsolat állapot (Adatátviteli állapot) FIN WAIT1 = Az alkalmazás a kapcsolat bontását kezdeményezte FIN WAIT1 = A másik fél egyetért a kapcsolat bontással TIMED WAIT = Várakozás a csomagok kihalására CLOSING
= Szimultán kapcsolatbontási kísérlet
CLOSE WAIT = Másik oldalról a kapcsolatbontást kezdeményezték LAST ACK
= Utolsó ACK-ra vár
Az előző ábrán a „CLOSED” állapotot kétszer tüntettük fel, de ez ne zavarjon senkit, hiszen ugyan arról az állapotról beszélünk. Az, hogy kétszer jelent meg az ábrán, az csak rajztechnikai kérdés és az átláthatóságot segíti.
91
3.6. UDP-User Datagram Protocol Az UDP - User Datagram Protocol szavakból képezett mozaikszó. A „Datagram” a csomagkapcsolt hálózaton továbbított olyan adatcsomag, amely adatcsomag érkezési sorrendje, valamint a csomag sikeres átvitele, vagyis annak megérkezése a célállomáshoz, nem garantált.
Az UDP-t elsősorban rövid üzenetek célba juttatására szolgáló protokoll (RFC 768), ott használjuk, ahol fontos szempont a gyorsaság. Az UDP nem garantálja a csomag megérkezését. Az UDP úgynevezett „connectionless” protokoll, így az ezzel küldött csomagok a hálózatban duplikálódhatnak, el is veszhetnek, és a csomag érkezési sorrend sem minden esetben egyezik a csomag küldési sorrenddel. Az UDP keretet a következő ábrán tüntettük fel:
Source port address (2 byte) Destination port address (2 byte) Length (2 byte) Checksumm (2 byte) Data
3.6-1. ábra. Az UDP csomagformátum UDP mezők jelentése a következő: A „Source port address” 16 bites és a küldő, forrásalkalmazás (source) portjának száma. A „Destination port address” 16 bites és a fogadó alkalmazás portjának sorszámát hordozza. A „Length” mező 16 bites. Az UDP csomag payloadjának hossza változó lehet, az aktuális hosszt itt kell megadni. A hossz indikátor magába foglalja a fejléc hosszát is! A legrövidebb UDP csomag hossza (amely payload-ot nem tartalmaz) 8 byte.
92
A „Checksum” mező 2 byte méretű, segítségével a csomag tartalmának megsérülése fedezhető fel. Használata opcionális. Abban az esetben, ha az ellenőrző összeg nem kerül kiszámításra, akkor ezt a mezőt 0-nak kell hagyni.
93
4. Csomagkapcsolt helyi hálózatok, LAN-ok A csomagkapcsolt helyi hálózatok kialakításának több oka van. Ezek közül talán a legfontosabbak a következők: •
Erőforrás megosztás;
•
Helyi, hatékony (gyors és védett) kommunikáció az egyes „épületen belüli” számítógépek között;
•
Költséghatékony hozzáférés a nyilvános csomagkapcsolt hálózathoz, Internethez.
A felsorolásban az elsőnek megjelölt szempont akár lehet a közös tárhely kialakítás. Ez régebben a költséghatékonyságot biztosította, manapság inkább a közös tárhelyek hozzáférhetősége az információ megosztását teszi lehetővé (például vállalati / intézményi tudásbázisok formájában). Az információ hozzáférése (annak írása, illetve olvasása) jogosultsági szintekkel szabályozható. A felsorolás második pontjának értelmében a közös hálózatban szereplő számítógépek a fizikailag védett hálózaton keresztül költséghatékonyan, gyorsan és biztonságosan kommunikálhatnak egymással. Forgalomméretezési számításokkal meghatározható, hogy egy „n” számú végpontból álló helyi hálózat célszerűen mekkora sávszélességgel kapcsolódjon a nyilvános hálózathoz. A helyi hálózat átviteli technikákat alapvetően két nagy csoportra szoktuk osztani az alkalmazott átviteli közeg szerint. Vezetékes helyi számítógép hálózatok napjainkban többnyire rézvezeték alapúak, de az optikai közeg alkalmazása is egyre inkább elképzelhető alternatíva. A vezetékes helyi hálózatok kialakulását 1960-tól jegyzik. Elsősorban egyetemeknél jelent meg az igény, hogy a számítógépeiket összekapcsolják. 1970-ben publikálták az „Octopus” hálózatot, valamint 1974-ben mutatták be a „Cambridge Ring” nevű hálózatot, mely elméletben maximum 255 számítógép összekapcsolását volt képes biztosítani. Az „Ethernet” hálózatot a Xerox PARC19 fejlesztette 1973 – 1975 között. A másik nagy csoportot a vezeték nélküli helyi hálózati kialakítások jelentik. Az úgynevezett WLAN (Wireless LAN) rendszerek esetén a helyi kapcsolatot az infravörös tartományban működő optikai, vagy valamely ISM sávban működő rádiós összeköttetés képviseli.
19
Xerox PARC - Palo Alto Research Center a XEROX cég kutatóhelye, melyet 1970-ben alapítottak
94
4.1. Vezetékes helyi számítógép hálózatok Számos vezetékes helyi hálózati megoldás látott napvilágot, voltak köztük sikeresek és kevésbé sikeresek is. A helyi hálózati megoldások fejlődése robbanásszerűen történt, fejlődésük napjainkban is töretlen. A fejlődés tendenciája itt is az egyre nagyobb sávszélesség irányába mutat. Ebben az alfejezetben elsősorban az Ethernet rendszerekkel foglalkozunk. Az „Ethernet” neve az „éter” (ether)20 szóból származik és viccesen a fizikai közegre utal. Az első Ethernet hálózat fizikai közege egy vastag koaxiális kábel volt, mely a „monda” szerint inkább egy locsolócsőre hasonlított, melynek külső szigetelése sárga színű volt. Az így kialakított hálózat maximális hossza 2,5 km volt, mely aktív jelismétlőket (jelerősítő és regenerátor) építőelemeket is tartalmazott 500 méteres távolságonként. Az átviteli sebesség 3 Mbit/s alatt volt.
4.1-1. ábra. 1970 táján készült Ethernet vázlatrajz Mivel a kísérletek akkor nagyon biztatóak voltak (és néhány PhD. értekezés is készült belőle)21, a DEC (Digital Equipment Corporation), az Intel és a Xerox jelentős anyagi támogatást biztosított a további munkához. Hamarosan kidolgozták az úgynevezett DIX szabványt, mely az IEEE 802.3 ajánlás alapjainak tekinthető. 20
Ether (éter) - az elektromágneses hullámok terjedéséhez szükséges hipotetikus közeg. Az elnevezést a 19. században vezették be, amikor a fizikai jelenségek magyarázatához felállított modellek nélkülözhetetlen kelléke volt egy olyan rugalmas közeg, mellyel a fény és a rádióhullámok terjedését magyarázta. 21 Robert Metcalfe Ph.D. disszertációja az ALOHAnet-ből indult, és 1973-ban védte meg azt a Harvard-on.
95
Érdekes módon, a sikerek ellenére a Xerox és a többi cég, akik az Ethernet hálózati és szabványosítási eljárásokban úttörő szerepet vállaltak, mintha nem láttak volna nagy fantáziát tovább a kialakított rendszerben, a támogatás intenzitását jelentősen csökkentették, ezért Robert Metcalfe megalapította saját cégét 3Com néven és ezzel vitte tovább a témát22. Az IEEE 802.3-tól eltérő más Ethernet szabványok is napvilágot láttak, melyek egymással nem kompatibilisek. Például az IEEE 802.4-et (vezérjeles sín – Token Bus - rendszerű) a General Motors hozta létre, míg az úgynevezett „vezérjeles gyűrű” (Token Ring - IEEE 802.5) szabványhoz az IBM ragaszkodott.
4.1.1. Fizikai átviteli közeg A vezetékes megoldások közül először a réz alapon működőket vizsgáljuk. A fizikai közeg ekkor lehet elektromos szempontból aszimmetrikus, vagy szimmetrikus. Az aszimmetrikus közeget úgynevezett koaxiális kábellel alakítják ki. A koaxiális kábel első ere (ha a kábel metszetét tekintjük) koncentrikus elhelyezkedést mutat az árnyékoló harisnyával.
4.1-2. ábra. Koaxiális kábel kialakítása A koaxiális kábelek jó nagyfrekvenciás tulajdonságokkal (magas felső határfrekvencia) rendelkeznek, és a hullámparaméterei (például a hullámimpedanciájuk) is jó homogenitást mutatnak. Természetesen nem csak jó tulajdonságaik vannak (gondoljunk csak a csinos nőkre! ☺). A koaxkábelek előállítása viszonylag drága, a csatlakozásokat és leágazásokat biztosító szerelvények ára is meglehetősen magas. Érzékenyek a mechanikai behatásokra, a geometriában bekövetkező változások (kis sugárban történő meghajlítás, esetleg megtörés) elrontják a hullám impedancia homogenitását és reflexiós helyek kialakulásához vezetnek.
22
Nyilván a 3Com alapításának oka ennél sokkal bonyolultabb történet, akit mindez bővebben érdekel, az tájékozódjon az Internetről és döntse el, hogy mely verziót fogadja el ☺
96
4.1-3. ábra. Koaxiális kábel dx szakaszának helyettesítő képe A fenti ábrán látható koncentrált paraméterű helyettesítő kép alkotóelemeinek értéke a geometriai méretektől és a felhasznált anyag jellemzőitől függ. A fajlagos kapacitása egy méteres hossz esetén az alábbi összefüggéssel határozható meg:
C[F / m] =
(2 ⋅ π ⋅ ε0 ⋅ ε r ) (ln(D )) d
A fajlagos induktivitása egy méteres hossz esetén az alábbi összefüggéssel határozható meg: L[H / m] =
(µ 0 ⋅ µ r ) ⋅ ln(D ) d ( 2 ⋅ π)
Ideális távvezeték esetén a vezeték „rézveszteségi” ellenállása (ábrán az R) nulla, vagyis végtelenül jó vezető. Abban az esetben, ha a belső ér és az árnyékoló harisnya között elhelyezkedő szigetelőanyag végtelenül jó szigetelőképességekkel rendelkezik, vagyis az átvezetés
mértéke
(az
ábrán
G-vel
jelölt
paraméter)
nulla,
akkor
a
vezeték
hullámimpedanciája (Z0) viszonylag egyszerűen számítható:
Z=
L C
Abban az esetben, ha az összefüggésbe, behelyettesítjük L és C paramétert:
Z0 =
1 µ ⋅µ D 138Ω D log10 ⋅ ⋅ 0 r ⋅ ln ≈ 2 ⋅ π ε0 ⋅ ε r d d εr
A kábel meghajtása aszimmetrikusan történik, vagyis az árnyékoló harisnya földpotenciálra csatlakoztatott. Az árnyékolás hivatott a zavarjelek föld felé történő elvezetésére. Ez természetesen csak akkor valósulhat meg, ha az árnyékolás tökéletes, azon nem találhatók rések. A tökéletes árnyékolást megközelítő megoldás az, ha az árnyékolás több rétegű (fém fólia és réz harisnya együttese).
97
4.1-4. ábra. Aszimmetrikus meghajtású koaxiális kábel Illesztett lezárás esetén biztosítható a reflexiómentesség, ezért a Z0 hullámimpedanciájú kábel esetén a forrás meghajtó belső impedanciájának ZS és a vételi oldalon a lezárást biztosító vevő bemeneti impedanciája ZL értékének egyeznie kell Z0 értékkel. A koaxiális kábeleknek több változata terjedt el. Hullámimpedanciák tekintetében az 50, 52, 75, vagy 93 Ω értékeket szabványosították. A koaxiális kábelek típusait szabványos jelekkel jelölik. A szabványt az USA-ban alkották 1962-ben (MIL-HDBK-216), mely katonai szabvány volt (úgynevezett MILitary-standard). A civil szférában az RG-# és az RG-#U jelölésű kábelek terjedtek el leginkább. Az ’R’ jelentése a rádiófrekvenciára (Radio Guide) utal. A ’#’ egy azonosító sorszám, majd a végén az ’U’ (ha alkalmazzák ezt a jelölést), az univerzális (Universal) felhasználhatóságra utal. Az alábbi táblázatban néhány koaxiális kábelt és annak jelölését foglaltuk össze. A csoportosítást hullámimpedancia (Z0) paraméter szerint végeztük:
Hullámimpedancia
Kábeltípusok:
értékek: 93 Ohm
RG-62, RG-62U
75 Ohm
RG-11, RG-11U, RG-59, RG-59U, RG-6, RG-6U, RG-6QS
52 Ohm
RG-9, RG-9U
50 Ohm
RG-58, RG-58U, RG-8, RG-8U, RG-8M, RG-8X
A koaxiális kábelek csatlakoztatását leggyakrabban úgynevezett BNC, valamint „F” csatlakozókkal valósítják meg. A leágazások „T” elosztókkal alakíthatók ki. Fontos, hogy a csatlakozó szerelvények mechanikailag és hullámimpedancia paraméter tekintetében illeszkedjenek a kábelhez. Ellenkező esetben impedancia illesztettlenség lép fel, és ez jelreflexiót (jel visszaverődést) okoz.
98
4.1-5. ábra. BNF és „F” típusú csatlakozó ajzatok Olcsóbb, költséghatékonyabb megoldást jelentenek a csavart érpáras (TP – Twisted Pair) átviteli közeg kialakítások. A két ér összecsavarása nem csak mechanikai okokból történik, hanem zavarjel kiejtés célja van. Azt feltételezzük, hogy ugyanaz a zavarjel egy viszonylag hosszú szakaszon hat a kábelre. A viszonylagosságot a csavarási hosszhoz állapítjuk meg, vagyis azt feltételezzük, hogy több „csavarásnyi” szakaszt gerjeszt a zavaró jel. Abban az esetben, ha ez így van, akkor a különböző pozícióból érkező zavarás ellentétes előjelű áramot indukál a vezetékbe, így azok kiejtik (vagy legalábbis jelentősen csillapítják) egymást. A zavar kiejtés és a párhuzamosan futó kábelek közti áthallás csillapítás akkor hatékony a csavart érpáras kábelek esetében, ha a kábelszakasz betáplálása és a vételi oldali lezárás a földpotenciálhoz viszonyítottan elektromosan szimmetrikus.
4.1-6. ábra. UTP kábel metszeti képe
99
4.1-7. ábra. Szimmetrikus meghajtású TP kábel A csavart érpáras kábeleket felső határfrekvenciájuk szerint kategorizálták. A besorolás során a CAT-x jellel jelölik az adott kábelt. A besorolási osztályokat, ahogy a kábelek gyártástechnológiája fejlődik, természetesen folyamatosan bővítik. A csavart érpáras megoldást már korábban (mint azt az előzőekben már láttuk) a PSTN hálózat hozzáférési szakaszán alkalmazták, a kategorizálás során ezek a kábelek a CAT-1 jelzést kapták. A besoroláskor a CAT-1 kábelekre azt mondták, hogy kizárólag alapsávi beszédátvitelre alkalmasak. Ha ez így lenne, akkor sem az alapsávi ISDN, sem pedig az xDSL adatátviteli technológiák nem működnének a PSTN előfizetői hálózaton! A PSTN hozzáférési hálózaton már korábban azt láttuk, hogy a hullámimpedancia az átviteli sávban 600 Ohm volt. Az Ethernet hálózatok esetében a csavart érpáras közegek hullámimpedanciája ennél jóval alacsonyabb: 100 Ohm (Az ajánlásokban megtalálható a 120 Ohm és a 150 Ohm érték is). A következő táblázatban az egyes „CAT” osztályokat gyűjtöttük össze és megjelöltük azt a minimum elvárást, ami a felső határfrekvenciára irányul.
Besorolás: CAT-1
Felső határfrekvencia: körülbelül 150 kHz
Tipikus alkalmazás POTS – PSTN, alapsávi ISDN, xDSL
(TIE/EIA nem szabványosította) CAT-2
(TIE/EIA nem
4 Mbit/s token ring hálózatok
szabványosította) CAT-3
16 MHz
10 Mbit/s Ethernet hálózatok
CAT-4
20 MHz
16 Mbit/s token ring hálózatok
CAT-5
100 MHz
Fast Ethernet hálózatok (100 Mbit/s)
CAT-5e
100 MHz
Fast Ethernet hálózatok (100 Mbit/s),
(250 MHz)
100
1000BASE-T Gigabit Ethernet hálózatok
CAT-6
250 MHz
Fast Ethernet hálózatok (100 Mbit/s), 1000BASE-T Gigabit Ethernet hálózatok
CAT-6a
500 MHz
10GBase-T.
CAT-7
600 MHz
Ultra Fast Ethernet hálózatok
CAT-7a
1 GHz
40 Gbit/s Ethernet (maximum 50 méteres szegmenshosszig) 100 Gbit/s Ethernet (maximum 15 méteres szegmenshosszig)
Fontos megjegyeznünk, hogy a kábelek besorolása minden esetben a felső határfrekvencia szerint történik és nem az adatátviteli sebesség szerint, hiszen ez utóbbi technológiafüggő! A felső határfrekvencia definíciója az, hogy illesztett lezárások között mekkora frekvenciájú harmonikus jel okozza a távolvégen a jelszint 3dB-es esését. A fenti definíció értelmében tehát a felső határfrekvencia semmiképpen sem azt jelenti, hogy a megadott frekvencia felett a kábel nem továbbítja a jeleket, hanem azt, hogy a jelek csillapítása e frekvencia fölött nagyobb, mint 3dB. Ezt láthatjuk a CAT-1 kábeleknél, ahol az ADSL átviteli módszerek 1,1 MHz, illetve a fejlettebb VDSL2+ technológiák akár 12 MHz frekvenciáig is kihasználják a spektrumot. A csavart érpáras kábeleket sok esetben árnyékolás nélkül állítják elő. Ez jelentős költségmegtakarítást jelent, de ebben az esetben kizárólag az érpárak csavarása jelenti a zavarvédelmet. Az ilyen kábeleket UTP kábeleknek hívjuk (UTP = Unshilded Twisted Pair, vagyis árnyékolatlan csavart érpár). Komolyabban zavartatott környezetben (például ipari környezet), vagy fokozottan védett információk továbbítása esetén az árnyékolt csavart érpáras kialakítást használjuk, melynek elnevezése STP (Shilded Twisted Pair). Az STP kábelek esetén, ha több érpárra (például 4 érpárra) közös árnyékolást alkalmaznak, akkor plusz költségként nemcsak a beépített árnyékolás jelentkezik, hanem a megnövekedett szórt kapacitások miatti felső határfrekvencia csökkenés hatásának kiküszöbölésére alkalmas jobb minőségű szigetelőanyagok használata is. A kábelárnyékolás többféle módon történhet. Abban az esetben, ha több érpár (általában négy érpár) árnyékolása együttesen történik, akkor S/UTP kábelnek nevezzük a vezetéket.
101
4.1-8. ábra. STP (S/UTP) kábel kialakítása A CAT-7 rendszereknél az érpárakat minden esetben külön-külön árnyékolják, majd az összefogott és árnyékolt párok egy közös árnyékoló védőköpenyt is kapnak. A magasfrekvencián is jó paraméterek elérése érdekében az érpárakat távtartókkal szeparálják.
4.1-9. ábra. S/STP kábel kialakítása A TP kábelek esetében (CAT5, illetve CAT5e jelölésig) az RJ-45 nyolcpólusú csatlakozást preferálják. Az RJ-45csatlakozó ajzat mechanikai kialakítása olyan, hogy képes befogadni az RJ-11 hatpólusú csatlakozó dugót, melyet elterjedten alkalmazunk a POTS interfészeknél. Ez a befogadókészség is egyszerűsíti egy iroda, illetve egy irodaház informatikai bekábelezését.
102
4.1-10. ábra. RJ-45 csatlakozó ajzat A helyi hálózatok vezetékezését szabványok írják elő. A kábelezés filozófiája az univerzalitást célozza meg. Az irodákban, irodaházakban úgynevezett strukturált kábelezés jelenik meg, és kábelezés hierarchikus struktúráját a TIA/EIA-568-B ajánlás szabályozza.
4.1-11. ábra. Példa a strukturált kábelezésre A strukturált kábelezés fontos eleme az úgynevezett „patch” panel. A patch panel több RJ-45 csatlakozó aljzatot képes befogadni. A patch panelban helyet kapott RJ-45 csatlakozókba 103
(hátulról) futnak be az épület (irodaház) telepített kábelei. Patch panel általában a telepített kábelek mindkét végén megtalálhatók (egyik az informatikai gépteremben, a másik vége pedig az épület egyes emeleti szintjein szokott helyet kapni)
4.1-12. ábra. RJ-45 rendező csatlakozó sáv (patch-panel) A rendező csatlakozó sávok mérete általában 19”, így a szokásos rendezőszekrényekbe azok becsavarozhatók. A patch panelek „magasságát” általában „unit23” egységben adják meg (1U, 2U, 3U stb.) A csatlakozó bekötések elkészítését, a szerelők munkáját színkódok segítik. Az UTP kábelek vezetékei és összetartozó érpárai a színkódok alapján egyértelműen azonosíthatók. Gyakran a csatlakozó ajzatok hátsó csatlakozása is színkódos.
Kivezetés száma (PIN)
Színkód
1
Fehér – zöld
2
Zöld
3
Fehér – narancs
4
Kék
5
Fehér – kék
6
Narancs
7
Fehér – barna
8
barna
4.1-13. ábra. RJ-45 csatlakozók bekötése és színkódok (T568A)
23
Egy unit 1,75 coll, vagyis 44,45mm.
104
Kivezetés száma (PIN)
Színkód
1
Fehér – narancs
2
Narancs
3
Fehér – zöld
4
Kék
5
Fehér – kék
6
Zöld
7
Fehér – barna
8
barna
4.1-14. ábra. RJ-45 csatlakozók bekötése és színkódok (T568B) A kábelek színjelölésénél a zöld és a fehér-zöld, a kék és fehér-kék, narancs és fehér narancs, valamint a barna és fehér-barna egy-egy érpárat jelöl. Az érpárban szereplő két vezetéket csavarják össze és ezek szimmetrikus meghajtása esetén nyújt a kábelben a csavarás zavarvédelmet. Az egyes erek felcserélése működésképtelen kábelt eredményez még akkor is, ha a két végponton a megfelelő csatlakozópontok összeköttetése rendben biztosított.
4.1-15. ábra. RJ-45 csatlakozók bekötése az érpárak jelölésével
Már a 10 Mbit/s sávszélességű Ethernet hálózatok szabványai is definiálták az optikai átvitelt. Az üvegszál, mint átviteli közeg számos előnyt mutat a réz alapú átviteli közegekhez képest. Esősorban sokkal jobb a zavarvédettségük, és a jelenlegi technológiákkal lényegesen olcsóbb
105
az előállításuk. Ami megdrágítja az alkalmazásukat, az elsősorban az optikai adó és vevő áramkörök magas árában keresendő. Költséges továbbá a szerelvényezésük, illetve az optikai szál toldása, csatlakoztatása is. Kis csillapítású és kis reflexiós kötések viszonylag drága eszközzel, az úgynevezett optikai szálhegesztővel alakíthatók ki. Napjainkban természetesen a jó minőségű optikai csatlakozást biztosító csatlakozók és optikai rendezők is hozzáférhetők, melyekből néhányat a következő ábrán szemléltetünk:
4.1-16. ábra. Üvegszálas hálózati csatlakozások
106
4.1.2. Adatbitek illesztése a vezetékes fizikai átviteli közegre A fizikai réteg feladata, hogy a logikai ’1’ és ’0’ információkat, vagyis az egyes bitek állapotát a rendelkezésre álló fizikai közegen továbbítsa, és a vevő oldalon detektálja. Lehetőség szerint ezt a feladatot minél hatékonyabban kell ellátni, vagyis a lehetőségekhez mérten a legnagyobb átviteli sebességet kell biztosítani és ezt a legkisebb hibával kell megoldani. Az átvitel úgy valósulhat meg, hogy a logikai jelszintekhez, vagy azok képzett csoportjához fizikai mennyiségeket (például feszültség, vagy áram szinteket stb.) rendelünk. Az átviteli közegen (ami jelen esetben réz vezető) megjelenő, és logikai információkat szállító egységeket szimbólumoknak hívjuk. A szimbólum „létrehozásának módszerét” vezetékes Ethernet hálózatok esetén vonali
kódolásnak nevezzük. Az IEEE 802.3 ajánlás szerint a vonali kódolás úgynevezett Manchester kódolással történik. A kódolási szabály szerint a logikai ’1’-nek megfelelő szimbólum egy bitközépnél megjelenő felfutó él, míg a logikai nullát egy bitközépi lefutó él szimbolizálja.
4.1-17. ábra. Manchester kód szimbólum készlete A következő ábrán egy példa azt szemlélteti az időtartományban, hogy az ’1 0 1 0 0 1 1 1 0 0 1’ bitfolyam miképpen jelenik meg a fizikai közegben.
107
4.1-18. ábra. Manchester kódolás szemléltetése az időtartományban A Manchester kódolás több előnyös tulajdonsággal rendelkezik, de már megszokhattuk azt, hogy az előnyök mellett hátrányokkal is kell számolnunk. A fenti ábrán a „Data” jelfolyam akár TTL jelszint-sorozat is lehet. A TTL jelfolyam megfigyelésénél azt tapasztalhatjuk, hogy logikai ’1’ esetén a vonalon U1 feszültség jelenik meg, míg ’0’ esetében a jelszint 0. Ez azt jelenti, hogy a jel egyenfeszültség átlaga az átvitt jelfolyamtól függő érték. Csupa ’1’ esetén a DC szint átlag U1-el megegyező, míg csupa ’0’ esetében ez az érték nullának adódik, ’1010101…’ jelfolyam esetén átlagértéknek ½ U1-et kapunk. Egy adatjel esetében előnytelen, ha a DC tartalom nem nulla, hiszen az egyenszintet a transzformátoros csatolás nem viszi át. Transzformátoros csatolást pedig előszeretettel alkalmazunk, mert galvanikus leválasztást jelent a hálózati közeg és az interfész belső áramkörei között. TTL kódolás esetén (az ábrán szereplő „Data” jelfolyam), ha sok egyforma jelszintet továbbítunk, akkor értelemszerűen nincs jelszint változás. Adat továbbításkor ez azért lehet hátrányos, mert az adatfolyamból nem derülnek ki a szimbólum határok, vagyis jelen esetben a bithatárok sem. Természetesen lehetőség van egy másik vezetéken egy szinkronizáló jel átvitelére, de ez költségnövelő tényező. Manchester kódolásnál minden szimbólumban +U2 és –U2 feszültségszint jelenik meg. Szabályos (torzítatlan) szimbólum esetén a két jelszint egy szimbólumra vett átlaga mindig nullának adódik, vagyis a jelfolyam DC átlaga az átvitt adatsorozattól teljesen függetlenül mindig nulla értéket mutat. Az ilyen jelek úgynevezett impulzus transzformátorokkal csatolhatók. További előnyként jelentkezik az, ha egy jelfolyam DC átlaga az adattartalomtól függetlenül nulla, ugyanis ekkor az adatjel egy DC jelre ráültethető, vagyis digitális vonalon is megvalósulhat a berendezés távtáplálása. A PoE24 kialakítások részben ezt a módszert alkalmazzák például az Ethernet interfészes IP telefonok esetén.
24
PoE – Power over Ethernet
108
Elterjedten alkalmazzák a Manchester kódolás differenciális változatát. Ebben az esetben a szimbólumok megegyeznek a Manchester kód szimbólumaival, csak a jelentéstartalmuk más. Az elemkészletünk most is egy szimbólum középnél lefutó él, valamint egy szimbólum középnél felfutó él. A továbbított szimbólum most két paramétertől függ. Az első paramétert az előzőleg küldött szimbólum jelenti, míg a másikat a ténylegesen átvinni kívánt logikai szint. Abban az esetben, ha az átvinni kívánt logikai szint ’0’, akkor az előző szimbólummal megegyezőt teszünk a közegbe, míg logikai ’1’ esetén a másik elemet választjuk.
4.1-19. ábra. Differenciális Manchester kódolás szemléltetése az időtartományban A Manchester kódolás elvitathatatlan előnye az, hogy bármilyen logikai információt is közvetítünk a segítségével, szimbólum középnél, ami éppen megegyezik a bitközéppel, egy átmenetet biztosan találunk. Az ilyen jelfolyamból az órajel viszonylag könnyen kinyerhető, vagyis a bitszinkronizáció adó és vevő között külön vezeték nélkül megvalósítható. A bitszinkronizálásnál arra kell ügyelni, hogy az adó és a vevő órajele egy szimbólumidő alatt nehogy annyira „elhangolódjon”, hogy a szimbólumhatáron előforduló esetleges átmenetet tekintse szimbólumközépnek. Az ilyen feladat költséghatékonyan egy PLL25-lel elhangolható kristály oszcillátorral valósítható meg.
A vonalra kapcsolt kódolt jel közel sem ideális. A jelalak bizonyos torzításokat szenved el, valamint zaj is ül rá. Az ajánlások úgynevezett maszkábrákat definiálnak, amelyeket ráillesztve a megfigyelt jelre, könnyen eldönthetjük a jelalak megfelelőségét, vagy nem megfelelőségét. A
következő
ábrán
egy
Gigabit
Ethernet
(1000BASE-KX)
maszkábráját
és
szemléltetésképpen abba berajzolt jelalakot láthatunk: 25
PLL – Phase Locked Loop – Fázis zárt hurok, mely szabályozástechnikában és a híradástechnikában egyaránt rutinszerűen alkalmazott áramköri megoldás.
109
4.1-20. ábra. 1000BASE-KX maszkábra és egy rávetített jelalak
Eddig áttekintettük a Manchester kódolás előnyeit, de nem mondtuk ki annak hátrányát (bár ez a hátrány jól látható a kódolásokat bemutató ábrákon). Abban az esetben, ha egy TTL jelszinteknek megfelelően kódoljuk az adatbiteket, akkor az ’01010101…stb’ sorozatnál kapjuk a legmagasabb frekvenciát a vonalon. Az így kapott jel periódus ideje (T) alatt két szimbólum, valamint 2 bit információ halad át az átviteli közegen. A vonalon a jel alapharmonikus frekvenciája f =
1 1 , viszont a szimbólumok vonali frekvenciája f SYM = T 2⋅T
, vagyis f SYM = 2 ⋅ f . A fenti összefüggés alapján az derül ki, hogy a bitsebesség kétszer akkora, mint a vonalon a jel frekvenciája, vagyis ha a közegen átvitt jel alapharmonikus frekvenciája 100 MHz, akkor a bitsebesség 200 Mbit/s. Most vizsgáljuk meg a jelfolyamot Manchester kódolás esetén! A manchester kód bitideje és a szimbólum frekvenciája számszerűen megegyezik, vagyis, ha az átvitt jel alapharmonikus frekvenciája 100 MHz, akkor a bitsebesség csak 100 Mbit/s érték lesz.
Feltétlenül érdemes megemlíteni, hogy az Ethernet ajánlások a Manchester kódoláson kívül más vonali kódolási eljárásokat is magukba foglaltak. Ilyen volt a korai Fast Ethernet (100BASE-T4) esetében a 8B6T (8 Binary – 6 Ternary) kódolás, amely CAT-3, Cat-4 és Cat5 közegre terveztek. A hálózatban a maximális közeghossz ezzel az eljárással 100m volt.
110
4.1.3. Adatkapcsolati réteg A fizikai réteg feladata az volt, hogy gondoskodjon az adott fizikai közegen a logikai ’1’ és logikai ’0’ bitek továbbításáról. A fizikai közegen szimbólumok jelentek meg, míg az adatkapcsolati – fizikai réteghatáron a logikai szintek. Az OSI rétegmodell a két réteget ugyan kettéválasztotta, de a gyakorlat bebizonyította, hogy azok teljes mértékű szeparálása nem lehetséges. Általában egy adott fizikai közegre illeszkedő fizikai réteg feltétlenül igényli az adatkapcsolati réteg hathatós támogatását. Az adatkapcsolati réteg feladata, hogy az „ömlesztett” logikai egyesekből és nullákból egységet képezzen. Az egységet ezen a szinten az úgynevezett keret jelenti. A vezetékes Ethernet hálózatok esetén a közös-közeghozzáférés módszerét a CSMA/CD-t is a második réteg implementálja, a MAC (Media Access Control) és az LLC (Logical Link Control) nevű alrétegekben.
Keretszervezés Az Ethernet keret (ami a fizikai közegben megjelenik) nyolc mezőből áll. Az első mező az úgynevezett „Preamble”, mely 7 byte-on keresztül fix ’101010…’ bitfolyam. Ez adatinformációt nem hordoz, kizárólag a bitszinkronizálást segíti elő a fizikai rétegben. 7 ⋅ 8 bit
8 bit
6 ⋅ 8 bit
6 ⋅ 8 bit
2 ⋅ 8 bit
(46 – 1500) ⋅ 8 bit
4 ⋅ 8 bit
Preamble
SOF
Destination
Source
Type/Length
Payload
CRC32
MAC
MAC
4.1-21. ábra. Az IEEE 802.3 (Ethernet) keret Az „SOF” (Start Of Frame) szintén a fizikai réteg működését támogatja. Ez a nyolcbites egység (oktet), fix ’10101011’ és a tényleges keret elejét jelöli. Amikor ezt a bitfolyamot veszi az interfész, akkor a bitszinkronizálásnak már tökéletesnek kell lennie. Fontos megemlíteni, hogy az Ethernet (Xerox alapú ajánlás) és az IEEE 802.3 ajánlás terminológiában apró eltérést mutat. Az Ethernet valójában az első nyolc oktetet nevezi preamble-nek, és a benne (annak végén) szereplő utolsó két bitet, melynek értéke ’11’ SOFnek hívja. Ez a lényegen nem változtat, hiszen a végeredmény ugyanaz!
111
A MAC cím az interfész fizikai azonosítója, nevét a Media Access Control-ból kapta. A MAC cím eredetileg teljesen egyedi, a felhasználó által módosíthatatlan volt, azonban jelenleg már egyszerű eszközökkel módosítható, így a globális egyediséget nem lehet garantálni. A MAC cím 48 bitből (6 byte) áll, és azt hexadecimális számrendszerben, 8 bitenként kettősponttal elválasztva ábrázoljuk. A cím egyedisége úgy garantálható, hogy a cím felső 3 byte-ját az IEEE szervezet osztja ki, a cím másik része pedig egy futó sorszám, melyben a gyártó gondoskodik az egyediségről. Mivel a MAC cím átírható, ezért manapság a néhány gyártó nem veszi olyan komolyan az egyediséget, azonban az ismétlődések és ugyanazzal a MAC címmel rendelkező eszközök egy hálózatba kerülésének valószínűsége csekély. Az Ethernet / IEEE 802.3 keret SOF-jét követően a küldött keretben a célállomás MAC címe található, majd ezt követő 6 byte a küldő eszköz interfészének MAC címét hordozza.
A „Type / Length” mező két byte-ból áll. A korábbi Ethernet szabvány ezt a mezőt kizárólag a keret hossz indikálására használta (Length). Tizenhat biten 0-65535 között ábrázolhatunk számokat, ugyanakkor a payload maximális hosszát 1500 byteban határozták meg. A hosszindikátor értéke (preamble és SOF nem szerepel benne) így maximum 6+6+2+1500+4=1518 byte-ot jelezhet (opcionális mezőt figyelembe véve ez maximum 1538 byte, ezt az Ethernet keret ábrán az „opcionális mezőt” nem tüntettük fel! ). A szabvány alkotói úgy döntöttek, hogyha a Type / Length mező értéke 1536 (0x0600) vagy ennél nagyobb szám, akkor a mező jelentése a szállított protokoll azonosítására szolgál. A mező tartalmát ekkor EtherType-nak szokás nevezni. Abban az esetben, ha az Ethernet keret IPv4 protokoll szerinti adatot szállít a payload mezőben, akkor az EtherType értéke 0x0800. IPv6 protokoll szerinti payload esetén az EtherType ezt a 0x86dd értékkel indikálja. A további EtherType értékeket tartalmazó táblázat a mellékletben található.
Az adatkapcsolati réteg feladata a keretek hibaellenőrzése. Kizárólag hibamentes keret továbbítható a felsőbb rétegek irányába. A hibaellenőrzés a „payload”-ot követő négy oktetből álló mező segítségével valósítható meg. Az összeállított kerethez egy úgynevezett
FCS-t (Frame Check Sequence) fűznek. Az FCS számítás úgynevezett CRC-vel (Cyclic Redundancy Check) történik, mely eljárás lényege az, hogy egy „generátor polinommal”
112
elosztjuk a teljes, összeállított keretet (ebbe a preamble és az SOF nem tartozik bele), majd az osztás során kapott maradékot hozzáfűzzük a keret végéhez. A vételi oldalon a vétel akkor tekinthető hibátlannak, ha a teljes keret (ebbe a hozzáfűzött CRC, vagy FCS is beletartozik és természetesen a Preamble és SOF viszont nem) a generátor polinommal maradék nélkül osztható. A generátor polinom jelen esetben egy 33 bites digitális szám, melyet a következőképpen szoktak megadni: x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x10 + x 8 + x 7 + x 5 + x 4 + x1 + x 0 Valójában a generátor polinom által reprezentált digitális szám a következő: 100000100110000010001110110110011 Az osztás maradéka ebben az esetben egy maximum 32 bites bináris szám, melyet a keretszervezésben CRC32-vel jelölt mező fog szállítani. Abban az esetben, ha a kalkulált maradék hossza kisebb, mint 32 bit, akkor az értékesebb bitek felől a kapott eredményt ’0’ értékkel töltik fel.
Közeghozzáférési eljárás Elsőre bármilyen meglepőnek is hangzik, az Ethernet hálózatok ugyanazon szegmensében lévő számítógépek közös átviteli közeget használnak. A koaxiális kialakítás esetén a számítógép hálózati kártyáknál ez még jól megfigyelhető volt, de a sodrott érpárú médium esetén a kialakításból adódóan ez rejtett marad.
4.1-22. ábra. Ethernet hálózat koaxiális közegen
113
4.1-23. ábra. Ethernet hálózat csavart érpáras átviteli közegen Közeghozzáférés A közeghozzáférési modell (egy szegmensen belül) mindkét közeg esetén leginkább a BUS topológiával egyenértékű, holott láthattuk, hogy a TP kábelezés esetén a hálózat vezetékezése csillagpont rendszerű. Ez utóbbi esetben az átviteli közeg „közösítés” a HUB nevű eszközben valósul meg. A HUB eszköz (legyen az akár aktív, vagy passzív eszköz) úgy viselkedik, hogy bármely portján beadott információ az összes többi porton megjelenik. Aktív esetben az eszköz jel regenerálást is végez, de a vett információkat sosem értelmezi. A HUB-ra ezért azt mondjuk, hogy az egyes sorszámú OSI rétegben (fizikai rétegben) működő eszköz.
4.1-24. ábra. Ethernet hálózat egy szegmensen belül található eszközei Az ugyanazon szegmensen lévő eszközök tehát kénytelenek megosztozni a közegen. A megosztozás lényege a közös közeg minél hatékonyabb kihasználása és a békés egymás mellett élés filozófiáján alapul. A vezetékes, közös közegű hálózatok esetében több módszert is kidolgoztak, de az Ethernet megoldásoknál (és mi elsősorban ezzel foglalkozunk) az úgynevezett CSMA/CD eljárás honosodott meg. Az eljárást az IEEE 802.3 Part 3 foglalja össze. A CSMA/CD betűszó feloldása a „Carryer Sense Multiply Access / Collision Detect”, amit a következőképpen értelmezhetünk: •
114
Van egy közös közegünk, melyhez több eszköz fér hozzá;
•
A hozzáférés során (mielőtt adatot küldenénk a közegbe), figyeljük azt, hogy a közeget más eszköz nem használja – ez a „vivő figyelés”;
•
Abban az esetben, ha balszerencsések vagyunk, akkor előfordulhat ütközés, tehát az ütközés tényét igyekszünk detektálni.
A fenti három pontban össze is foglaltuk a CSMA/CD működésének lényegét, de most vizsgáljuk meg azt egy kicsit részletesebben! Bár a CSMA/CD az OSI második (adatkapcsolati) rétegben működő eljárás, foglaljuk össze ismereteinket a fizikai réteggel kapcsolatban (szükségünk lesz rá). •
Az adatbitek kódolása úgynevezett Manchester kódolással történik, melynek egyik fontos jellemzője az, hogy egy szimbólum DC (egyenfeszültség) átlaga mindig nulla.
•
Az üres közegben (ha éppen egyik eszköz sem forgalmaz) a váltakozó feszültség értéke is nulla (természetesen a zajokat, zavarokat most figyelmen kívül hagyjuk), vagyis semmilyen olyan jel nem áll rendelkezésre, melyet valamiféle szinkronizálásra fel tudnánk használni, ezért ha egy eszköz adatokat kezd küldeni a hálózatba, azt a saját órajelének ütemében teszi.
Az összefoglalót követően nézzük a konkrét folyamatot:
4.1-25. ábra. Ethernet hálózat közeghozzáférés Tételezzük fel, hogy az „A” eszköz adatot kíván küldeni. Mielőtt ezt megtenné, ránéz a közegre („Carryer Sense”), hiszen a közös szegmensben mindenki, mindenkinek az adását érzékeli. Ha üresnek találja a közeget, akkor megkezdi az adást. Adás közben pedig folyamatosan figyeli, hogy volt-e ütközés („Collision Detect”). Miután az „A” állomás befejezte az adást, nemsokára az ütközés figyelést is lekapcsolja, és ha ebben a periódusban ütközést nem detektált, úgy veszi, hogy a küldött keret rendben áthaladt a fizikai közegen.
115
A folyamat olvasása közben felmerülhet a kérdés, hogy miért is szükséges az ütközés detekció, ha üres közegbe kezdtük meg az adást? Más eszköz talán nem így tesz? Abban az esetben, ha azt feltételezzük, hogy a közös szegmensben lévő eszközök közül egyik sem hibás, akkor hasonló módon jár el, mint az „A” eszköz. Egy dolgot viszont nem szabad elfelejtenünk, ez pedig a jel véges terjedési sebessége! Az adott végponttól egy másik végpontig, melyek egymástól „l” távolságban vannak, a jel eljutásához „t” idő szükséges, akkor, ha a jel terjedési sebessége „v”. t=
l v
A jel terjedési sebessége rézhálózatban körülbelül a fény vákuumbeli terjedési sebességének (c=299 792 458 m/s) körülbelül a kétharmada (a gyakorlatban általában 200 000 000 m/s értékkel szoktunk számolni). Abban az esetben, ha megvizsgálunk egy 100Mbit/s átviteli sebességű (például Fast Ethernet) esetet, ahol a vonali kódolás Manchester kóddal történik, akkor a szimbólum sebesség 100Msym/s-nak adódik. A szimbólum idő ekkor 10 ns. Egy 100 m hosszúságú vonalszakaszon a vonalra adott szimbólum áthaladásához körülbelül 500 ns időre van szükség. A 100 méteres vonalszakaszba tehát 50 szimbólum (jelen esetben ez 50 bitet jelent) fér bele, vagyis a kábel úgy viselkedik, mint egy memória. A fenti példában számított 500 ns idő a feltételezett 100 m vonalszakasz esetén sajnos lehetővé teszi azt, hogy amikor az „A” és a „B” állomás is információt szeretne továbbítani, a vivő figyelést követően jóhiszeműen megkezdik az adást, ugyanis mindkét állomás úgy érzékelte, hogy a közös közeg szabad. Abban az esetben, ha „A” és „B” állomás által küldött információ az átviteli közegen találkozik, akkor ezt a jelenséget ütközésnek (collision) nevezzük. Az „A” és a „B” állomás adása egymáshoz képest szinkronizálatlan, így a két jel szuperpozíciója
(„összege”)
gyakorlatilag
visszafejthetetlen
lesz.
Az
összeütközött
információk elvesztek, így azok pótlásáról (újraküldéséről) az állomásoknak kell gondoskodniuk. Ehhez az szükséges, hogy az ütközésben résztvevő eszközök értesüljenek az ütközés tényéről (collision detect). Az ütközés tényét a fizikai rétegben lehet felismerni. A szinkronizálatlan jelfolyamok találkozása esetén már nem lesz igaz az egy szimbólumra jellemzően az, hogy a DC átlag nulla (valójában ekkor nem is igazán értelmezhető a szimbólum idő), vagyis az ütközés jelentős és jól detektálható feszültség kilengéseket okoz az átviteli közegben.
116
Fontos megemlíteni, hogy az Ethernet hálózatok közös közeg alkalmazása esetén csak félduplex (Half - Duplex) működésre képesek. Abban az esetben, ha valamely állomás ütközést detektál, akkor a vonalra egy úgynevezett JAM szignált kapcsol, mely jel segítségével a többi állomás is biztos, hogy értesül az ütközés tényéről. A JAM jel tulajdonképpen egy fizikai rétegben működő jelzés. A JAM szignál 32 bitből álló logikai ’1’ sorozat. A fentiek szerint feltételezzük, hogy az ütköző állomások detektálták az ütközés tényét, adásukat befejezték, és arra várnak, hogy az elveszett kereteket újraküldhessék. Az újraküldés egy „véletlen” időzítéssel fog elindulni, de természetesen csak akkor, ha a vivő figyelés (Carryer Sense) eredménye ezt megengedi. Az újraküldési időt minden eszközben az úgynevezett „truncated binary exponential backoff algorithm” nevű eljárás fogja kiszámítani. Az eljárás lényege röviden a következő: Minden állomás rendelkezik egy újraküldés számlálóval (szokás ütközés számlálónak is nevezni), mely normál esetben nulla értéken áll. Elveszett keret esetén a küldő állomás az újraküldés számlálójának értékét eggyel növeli meg. Az újraküldés idejét az állomás saját magának sorsolja a 0 és a 2n - 1 tartományban elhelyezkedő egész számok közül, ahol az „n” az ütközések számával egyezik meg, ha az ütközések száma kisebb vagy egyenlő, mint tíz. Tíz egymást követő ütközés esetén az „n” értéke 10 marad! Az első ütközést követően, az ütközésben résztvevő eszköz (eszközök) a 0 és az 1 közül választhatnak. A második ütközés (ha ugyanazon keret küldése újra meghiúsul), akkor az algoritmus a 0, 1, 2 és 3 számok közül sorsolhat. A határ kiterjesztése kettő hatványai szerint növekszik, vagyis a sorsolható lehetőségek tárháza minden újabb ütközés esetén duplázódik. Az algoritmus szerint a tizedik és az azt követő ütközések után 1024 lehetőség közül (0, 1, 2, … 1023) történik a sorsolás. A kisorsolt szám az újraküldés időzítést határozza meg. Az időzítés egysége szintén szabvány által rögzített érték, mely az úgynevezett „slotTime” értékével egyezik meg. A „slotTime” értéke az Ethernet hálózat fajtájától függő idő, amit a bitidő egységéhez adják meg:
117
Ethernet hálózat típus:
slotTime:
Eth 10Mbit; 1BASE5
512 bit times
Eth 100 Mbit/s
512 bit times
Eth 1000 Mbit/s
4096 bit times
A közeg megfigyelhetőségét javítja az egyes keretek közé kötelezően beiktatott úgynevezett „InterFrame Gap time” (IFG). Ezt az időzítést az adó eszköznek kötelezően be kell szúrnia, miután elküldte a keret végén található ellenőrző összeget (CRC-t). Az időzítés mértéke minimum 12 oktet idő, ami 96 bit idővel egyezik meg. A fent leírtak (problémák és azok kezelése) a normál működés szerves részét képezik, vagyis teljesen természetes, hogy egy közös közegben ütközések fordulnak elő, és addig nincs is gond, míg ezeket az időzítéseket pontosan detektáljuk és a hibát újraküldéssel javítani tudjuk. Természetesen ezek az esetek nem okoznak örömöt, hiszen mindez a hasznos adatátviteli sávszélesség rovására történik. A normál, és kezelhető ütközéseket „Early Collision”-nak szokták nevezni. Az ütközés számlálás 16-ig engedélyezett, ha ezután is előfordul ütközés, akkor az adott interfész leállítja az újraküldési algoritmust és rendszer hibaüzenetet küld a felsőbb rétegek irányába.
Problémát jelentenek azok az ütközések, melyek detektálása valamely adó eszköz számára nem lehetséges. Ez abban az esetben fordulhat elő, ha egy keret (mondjuk a legrövidebb) „belefér” a teljes átviteli szegmensbe. Tételezzük fel, hogy „A” és „B” állomások ugyanazon szegmensben találhatók és egymástól olyan távol esnek, hogy amikor „A” befejezi az adást, akkor „B”-hez még nem érkezett meg az „A” által küldött keret eleje. E tekintetben a legrövidebb keretek jelentik a veszélyt, ami Ethernet esetében 64 byte méretű, vagyis 512 bit. Néhány bit késleltetést jelenthetnek a szegmensben található jel regenerátor eszközök (Repeater) és aktív HUB-ok is. A jel késleltetést okozó eszközök, a szegmens virtuális hosszát növelik.
118
4.1-26. ábra. Késői ütközés (Late Collision) szemléltetése A fent megfogalmazott körülmények között előálló ütközést „késői ütközésnek” (Late Collision) nevezzük. A késői ütközés esetén a példában szereplő „A” eszköz már befejezte az adását, amikor „B” éppen elkezdte és az ütközés létrejött. Az „A” ugyan detektálja az ütközés tényét (JAM signal segítségével), de mivel ő már az ütközés detekció pillanatában nem adott, ezért joggal feltételezi azt, hogy a szegmens más állomásai által küldött adatok sérültek. Nincs oka „A”-nak feltételezni azt, hogy az előzőleg általa küldött adat nem ért célba, hiszen az adás során semmi probléma sem állt elő. Az így elveszett keret második rétegben történő kezelése (újraküldése) nem valósul meg. Az elveszett információt, ha az feltétlenül szükséges, a felsőbb rétegek fogják hiányolni (például TCP) és az újraküldés igény a felsőbb rétegek kérésére generálódik. Természetesen ez jelentős erőforrás pazarlást jelent, és a hálózat váratlanul extrém módon képes „lelassulni”, főleg akkor, ha ezeknek az eseményeknek a száma hirtelen megnövekszik. A késői ütközés, mint esemény elkerülhető, ha a szegmens hosszát és a jel regenerátorok (repeater) számát úgy határozzuk meg, hogy a legrövidebb keret se férjen bele az átviteli szegmensbe. Az ilyen irányú hálózat tervezésre jó iránymutatást adnak az IEEE 802.3 ajánlások, melyek pontosan megadják a maximálisan alkalmazható vezeték hosszát (valójában a két legtávolabbi állomás vezeték-távolságát) és a beépíthető jel ismétlők számát is.
Hálózat szegmentálás Az Ethernet hálózatok közös közeg problémái napjainkban viszonylag könnyen feloldhatók. Strukturált TP kábelezés esetén a vezeték rendszert is változatlanul hagyhatjuk! A feladatunk mindössze annyi, hogy az adatforgalom irányítását már a második rétegben megkezdjük. A kapcsolás, vagyis jelen esetben a keret irányítás a MAC cím alapján történik.
119
Az ilyen irányítási feladatokat az úgynevezett „Switch” eszköz képes megtenni. A Switch eszközök árai az utóbbi években jelentősen csökkentek és körülbelül a HUB eszközök árszintjét érték el. A HUB eszközök telepítése helyett célszerű a Switch telepítése. A Switch eszköz az első üzenetváltást követően megtanulja az adott portjához kapcsolódó hálózati eszköz (például a számítógép Ethernet kártyája) MAC azonosítóját és azt a belső memóriájában fel is jegyzi. A feljegyzések alapján irányítási táblát alakít ki és az adott eszköznek szóló üzenetet csakis a tábla alapján meghatározott portra küldi ki. A Switch eszközzel szeparálást szegmentálásnak nevezzük. Abban az esetben, ha a Switch eszköz egy portjához csak egy eszköz kapcsolódik, akkor lehetőség van a teljes kétirányú adatátvitelre (full-duplex működésre). Az úgynevezett „Switch-elt hálózatok” további előnye az, hogy az egyes portokon található számítógépek adatforgalmai szeparálttá válnak, vagyis „nem lát mindenki minden adatot”. Ez csökkenti a hálózaton a biztonsági kockázatot (például egymás lehallgatását).
Egy Switch portra természetesen több eszközt is kapcsolhatunk, az illesztési szabályok betartásával (például egy HUB eszközzel). Ekkor viszont az adott porton ismét közös közeget alakítottunk ki. Ebben a szegmensben a közeghozzáférés ismét a CSMA/CD eljárással történik. Természetesen az adott porthoz most a Switch-nek több MAC címet kell eltárolnia. A Switch eszközök MAC irányítási táblája véges méretű. Túl sok eszköz rákapcsolás esetén a táblázat megtelne, akkor az eszköz kénytelen átállni „HUB-szerű” működésre. Korábban a Switch eszközök ellen hatékony támadási forma volt a MAC irányítási tábla túltöltése,
mely segítségével
láthatóvá
váltak
a
szomszédos
gépek
adatátvitelei.
Természetesen ezt nem úgy érték el, hogy kellően nagyszámú számítógépet kapcsoltak az adott switch portjára, hanem csak annyit kellett tenni, hogy különböző forrás MAC című Ethernet kereteket kellett küldeni a támadó számítógépről a Switch számára. A menedzselhető Switch eszközök kellően nagy memóriával rendelkeznek, ezért normál működés esetén nehezen elképzelhető a MAC irányítási táblájuk túltöltése. Abban az esetben, ha valaki egy ilyen támadást indít az adott porton, akkor egy bizonyos számú „eszköz” láttán a Switch tiltja az adott portot, és a többi port zavartalanul működhet tovább.
120
4.2. Vezeték nélküli helyi számítógép hálózatok Sok esetben kényelmetlen az, ha a számítógépünket vezetékkel hozzá kell kapcsolnunk egy hálózathoz, azért hogy hozzáférjünk a leveleinkhez, tudjunk böngészni az Interneten, illetve akár egy irodai belső adatbázist is tudjunk használni a munkánk során. Ez a kényelmetlenség nem elsősorban a telepített, úgynevezett asztali számítógépeknél (Desktop PC), hanem inkább a mobil eszközöknél (PDA, Laptop, Netbook stb.) jelentkezik. Szintén problémás lenne a vezetékes kapcsolat kialakítása például utazáskor (vasúti pályaudvar, reptér, benzinkút stb.), ha éppen az e-mailjeinket szeretnénk megnézni. Előfordulhat persze az is, hogy egy mikrovállalkozás egy családi házban, vagy egy régi belvárosi bérház lakásában alakít ki egy irodát. Az ilyen helyszíneken nem ritka, hogy nincs kiépített strukturált kábelhálózat és annak utólagos kiépítésére nincs is lehetőség, vagy a kiépítés költségei extrém magasak lennének. A fenti néhány sorban megfogalmaztuk azt az igényt (és meg is indokoltuk), hogy miért szükségesek a vezeték nélküli magánhálózatok. A vezeték nélküli magánhálózatokat WLAN (Wireless LAN) hálózatoknak nevezzük. A vezeték nélküli kapcsolatok többfélék lehetnek: •
Optikai (például infra) átvitel;
•
Rádiós kapcsolat.
Az optikai átvitel esetén leginkább az infra tartományt szoktuk használni. A legelterjedtebb eljárásokat az IrDA (Infrared Data Association) foglalja össze. Az átvitelhez az áthidalható távolságok meglehetősen alacsonyak (néhányszor 10 cm, illetve néhány méter), és a kommunikáló eszközök között a közvetlen rálátás szükséges.
A rádiós kapcsolatok esetén az áthidalható távolság általában magasabb az optikai interfészhez viszonyítottan (néhány méter, illetve néhányszor 10 méter nagyságrend). A rádiós kapcsolatok közvetlen optikai rálátást nem igényelnek.
Első ránézésre úgy tűnik, hogy a rádiós kapcsolat minden paraméterében jobb az optikainál. Egy fontos dologról viszont nem esett szó, ez pedig a lehallgathatóság. Az optikai interfész (például egy úgynevezett „low power option” esetén, ahol a kapcsolati távolság néhányszor 10cm és az irányszög körülbelül 20°), a lehallgathatóság védelmet már fizikai réteg szinten 121
biztosítja, míg a rádiós átvitel nem. A rádiós kapcsolatok esetében az átvitt adatok védelméről felsőbb rétegek eljárásai gondoskodnak – több-kevesebb sikerrel. A jegyzet további részében a rádiós WLAN kialakításokat tekintjük át. Rádiós átvitelt használó vezeték nélküli hálózatok struktúrája alapvetően kétféle lehet: •
Pear to Pear (P2P), melyet WLAN esetében szoktak Ad-Hoc hálózatnak is nevezni;
•
AP (Access Point) – Client kapcsolatú (Hozzáférési pont – kliens kapcsolat).
Ad-Hoc esetben a BSS-ek (Basic Service Set – azok a WLAN interfésszel rendelkező eszközök, melyek képesek egymással kommunikálni), a kapcsolatot közvetlenül egymás között építik fel.
4.2-1. ábra. Ad-Hoc hálózat (A és B állomás P2P kapcsolata) Abban az esetben, ha a kliens számítógépek nem közvetlenül egymással építenek ki kapcsolatot, hanem egy úgynevezett hozzáférési ponton keresztül, akkor a hálózat menedzselése átláthatóbb, jobban kézben tartható.
4.2-2. ábra. Ap-vel kialakított WLAN hálózat Még mielőtt rátérnénk a konkrét működés vizsgálatára, további fontos terminológiák tisztázását célszerű megtenni. Gyakran hallani a Wi-Fi kifejezést, de mi is az?
122
A Wi-Fi a Wireless Fidelity szavakból képzett „védjegy”. Leginkább a „Hi-Fi” terminológiához hasonlítható, amit szintén sokszor használunk a hétköznapokban.
4.2-3. ábra. Wi-Fi jelölés A Wi-Fi logó védett, tehát nem szabadon használható védjegy, a „WiFi Alliance” (WFA) tulajdonát képezi. A WFA-t több gyártó hozta létre, melyek közül az ismertebbek a következők: 3Com, Aironet (Jelenleg Cisco tulajdon), Harris Semiconductor (jelenleg Intersil tulajdon),
Lucent (jelenleg Agere),
Symbol
Technologies
(jelenleg Motorola),
Sony
Corporation, Apple, Matshusita (Panasonic). A Wi-Fi logót kizárólag olyan WLAN interfészek kaphatják meg, melyek átesnek egy úgynevezett együttműködési teszten, ugyanis a „Wi-Fi certified” eszköz azt garantálja, hogy biztosan képes együttműködésre egy másik gyártótól származó olyan eszközzel, mely szintén „Wi-Fi” logóval rendelkező. A Wi-Fi minősítés során a tesztek kötelezően kiterjednek a rádiós interfészre, az adatformátumra és a titkosítási eljárásra. Opcionális paraméterként jelenik meg az úgynevezett konformancia tesztben a QoS kezelés és a tápmenedzsment. A tanúsításon átesett, és megfelelőnek bizonyult eszközök listája, a megfelelőségi vizsgálatok időpontja a WFA honlapon26 nyilvánosan közzétett adat. Mivel az IEEE802.11 ajánlások egyre bővülnek, a Wi-Fi megfelelőség tesztjeinek ezt állandóan követniük kell. Egy berendezés esetében a korábban kiadott Wi-Fi megfelelőség a felülről kompatibilitás miatt a továbbiakban is garantálja az együttműködési képességet, de logikusan nem várhatunk együttműködést két különböző frekvenciasávban működő eszköztől. Az egyértelmű beazonosíthatóság kedvéért a Wi-Fi logóban megjelennek az IEE802.11 ajánlás betűkódjai (ezekről a későbbiekben lesz szó).
4.2-4. ábra. Wi-Fi megfelelőséget tanúsító jel
26
www.wi-fi.org
123
4.2.1. Rádiós fizikai átviteli közeg, fizikai réteg A rádiós átvitelre kijelölt frekvenciasáv szükséges. Az egyes rádiófrekvenciák kiosztása a Nemzetközi Frekvenciagazdálkodási Stratégia, valamint a Nemzeti Frekvenciakiosztási Stratégia szerint történik. Természetesen a stratégiák harmonizálására szükség van. Az egyes frekvenciasávokért a felhasználók (például rádió-, és televízió csatornák, rádiótelefon társaságok) komoly összegeket fizetnek. Vannak viszont olyan felhasználások, melyek esetén a felhasználóktól szinte lehetetlen beszedni a frekvenciahasználati díjat. Gondoljunk az egyszerű rádiós kapunyitó, vagy személygépkocsi nyitó eszközre. Ilyen kategóriába esnek például az igen kis hatótávolságú személyes hálózati eszközök (például Bluetooth), valamint a vezeték nélküli rádiós helyi hálózatok is. Azért, hogy ezen felhasználások, és azok frekvenciaigénye jól kézben tartható legyen, szabadon felhasználható sávokat jelöltek ki, mind nemzeti, mind pedig nemzetközi szinteken. Az így kijelölt frekvenciasávokat ISM (Industrial, Sientific and Medical) sávoknak nevezik. Természetesen a szabadon felhasználható frekvenciasávok esetén a kijelölt frekvenciasávon belül sem szabad korlátlanul bármit megtenni! A cél az, hogy ehhez a közös lehetőséghez mindenki hozzáférjen, és az eszközök békés egymás mellett élés elvén működni tudjanak. Az ISM sávokban definiált csatornákban tartózkodás limitált. Az adás maximális kitöltési tényezője korlátozott, valamint pontosan definiált a maximálisan kisugározható teljesítmény is. A fontosabb ISM frekvenciákat a következő táblázatban foglaltuk össze:
ISM Frekvenciasáv határok Sávközép frekvencia
Rendelkezésre állás Helyi döntés szerint
6,765 – 6,795 MHz
6,780 MHz
(Nemzeti Frekvenciagazdálkodási Terv szerint)
124
13,553 – 13,567 MHz
13,560 MHz
Általános
26,957 – 27,283 MHz
27,120 MHz
Általános
40,66 – 40,70 MHz
40,68 MHz
Általános
433,05 – 434,79 MHz
433,92 MHz
Általános
902 – 928 MHz
915 MHz
2,400 – 2,500 GHz
2,450 GHz
Általános
5,725 – 5,875 GHz
5,800 GHz
Általános
24 – 24,25 GHz
24,125 GHz
Általános
Kizárólag az úgynevezett 2-es régióban használható27 szabadon
Helyi döntés szerint 61 – 61,5 GHz
61,25 GHz
(Nemzeti Frekvenciagazdálkodási Terv szerint) Helyi döntés szerint
122 – 123 GHz
122,5 GHz
(Nemzeti Frekvenciagazdálkodási Terv szerint)
244 – 246 GHz
245 GHz
Általános
A fontosabb WLAN specifikációkat az IEEE802.11 ajánlások foglalják össze. Mint már megszoktuk az IEEE802 ajánlásoktól, most is két réteg (fizikai és adatkapcsolati réteg) elemeinek definícióját adja. A hétköznapi használatban lévő WLAN rendszerek leginkább a 2,4 GHz frekvencia környéki, valamint az 5 GHz frekvencia érték körüli sávot használják. Az IEEE802.11a szabvány kizárólag 5 GHz-en definiálja a fizikai réteg működését, míg az IEEE802.11 „b” és „g” jelű a 2,4 GHz frekvenciát jelöli ki. Az IEEE802.11n szerint a működés mindkét sávban definiált. Az egyes ajánlások értelmében az elérhető legnagyobb digitális sávszélességek a következők:
Ajánlás sorszám:
Elméleti legmagasabb sávszélesség:
IEEE802.11a
54 Mbit/s
IEEE802.11b
11 Mbit/s
IEEE802.11g
54 Mbit/s
IEEE802.11n
450 Mbit/s
27
Az ITU szerint a frekvenciagazdálkodás szempontjából 3 régió definiált. 1-es régió Európa, Afrika, Oroszország, Irak és Mongólia; 2-es régió Amerika és Grönland; 3-as régió Ázsia, Irán és Óceánia.
125
Az adatinformációk átvitele a rádiós közegben történhet szórt spektrumú átvitellel, és ortogonális frekvenciaosztásos multiplexeléssel is. A korábbi szabványok kizárólag a szórt spektrumú adásokat támogatták, melyek közül az úgynevezett FHSS (Frequency Hopping Spread Spectrum) és a DSSS (Direct Sequence Spread Spectrum) a legelterjedtebb.
FHSS Az IEEE802.11 ajánlás az FHSS eljárást kizárólag a 2,4GHz ISM sávra definiálta. A frekvenciasáv határai Európában 2,400 GHz – 2,4835 GHz terjednek, kivéve Spanyolországot (itt 2,445 GHz – 2,475 GHz), valamint Franciaországot (itt 2,4465 GHz – 2,4835 GHz). A rendelkezésre álló európai sávot 79 db 1 MHz sávszélességű csatornára bontották. Az adók és a vevők egymással összhangban, egy előre meghatározott séma szerint váltják a frekvenciát. Egy
csatornában
a
maximális
tartózkodási
időt,
vagyis
a
kötelező
minimális
frekvenciaugratási sebességet (Hop – rate) a nemzeti frekvenciagazdálkodási előírások szabályozzák. A csatornaváltási szekvenciát az alábbi táblázat foglalja össze:
Az adó és a vevő eszközök szinkronizálása értelemszerűen a fizikai rétegben történik, ezért a második réteg kereteit szinkronizáló információkkal kell kiegészíteni, melyet PLCP preamble (physical layer convergence procedure) mezőnek neveznek. Ez a mező két almezőből (SYNC és SFD - Start Frame Delimiter) áll. A SYNC mező 80 bites, és az órajelek összeszinkronizálását segíti. Az SFD 16 bites és fix jelsorozatból áll, ami megfelel a ’0000 1100 1011 1101’ bitsorozatnak.
126
Ezt követi a PLCP header, mely három almezőből áll (PLW - PSDU Length Word, PSF PLCP Signaling Field, és a HEC - Header Error Check). A PLW mező 12 bit hosszúságú, és a továbbított csomag utolsó bitjének meghatározása válik ezzel lehetővé (úgynevezett 32/33 coding algoritmus). A PSF mező 4 bitből áll, melyből a 0. sorszámú fix ’0’ szinten áll. A maradék három bit az átviteli sebességet adja meg, melyet a következő táblázatban foglaltunk össze:
PSF mező bitjei
Átviteli sebesség
b1 b2 b3 000
1 Mbit / s
001
1,5 Mbit/s
010
2 Mbit/s
011
2,5 Mbit/s
100
3 Mbit/s
101
3,5 Mbit/s
110
4 Mbit/s
111
4,5 Mbit/s
A HEC mező 16 bites és a fejléc hibáit hivatott felderíteni. A hibaellenőrzés CRC-vel történik, a generátor polinom: x16 + x12 + x 5 + x 0 . Az alkalmazott modulációs módszer az úgynevezett 2GFSK. Ez a modulációs módszer két állapotot definiál. Abban az esetben, ha a csatorna vivőfrekvencia sávközépen áll (modulálatlan vivő), akkor a logikai ’1’ szimbólum +500 kHz frekvenciával fogja azt elhangolni, míg a logikai ’0’ szimbólum -500 kHz frekvenciával. Így 1 Mbit/s átviteli sebesség alapján a szimbólum sebessége az átviteli csatornában 1 Msym/s. 2 Mbit/s átvitel esetén szintén az 1 MHz sávszélességű csatorna áll rendelkezésre. Ekkor a 4GFSK modulációt használjuk. A 4GFSK moduláció esetén a bitfolyamból 2 bites bitpárokat képzünk, és ehhez rendelünk egy szimbólumot. Mivel 2 biten négy állapot adható meg, ezért a szimbólum készlet ekkor négy, a szimbólum sebesség pedig marad 1 Msym/s.
127
DSSS Mint azt az FHSS módszernél láttuk, a második rétegben kialakított kereteket (MPDU) a DSSS (Direct Sequence Spread Spectrum) eljárásnál is ki kell egészíteni szinkronizáló és a fizikai réteg számára információt nyújtó bitekkel.
4.2-5. ábra. Fizikai keret felépítés DSSS esetén DSSS esetén a szinkronizáló bitek (SYNC) száma 128, míg az SFD (Start Frame Delimiter) 16 bitből áll, mely utóbbi az ’1111 0011 1010 0000’ bitsorozat. A SYNC és az SFD együttesen alkotja a PLCP Preamble mezőt, melyet a PLCP Header követ. A PLCP fejléc egy 8 bites SIGNAL mezőből, egy 8 bites SERVICE mezőből egy 16 bites LENGTH mezőből, valamint egy 16 bites hibaellenőrzést szolgáló CRC kódból épül fel. A SIGNAL mező jelzi a fizikai réteg számára azt, hogy mely moduláció használatos. A ’00001010’ sorozat 1 Mbit/s átviteli sebességet és DBPSK moduláció használatát jelzi, míg, ha a mező a ’00010100’ kódot szállítja, akkor 2 Mbit/s az átviteli sebesség és a DQPSK moduláció alkalmazott. A SERVICE biteket a további fejlesztésekhez tartották fenn (IEEE802.11 – 2007 ajánlás szerint az alap DSSS eljárás esetén). A LENGTH mezőben egy előjel nélküli egész számként értelmezett kódot találunk, mely mikroszekundumban fejezi ki azt, hogy mennyi idő szükséges az MPDU mező továbbításához.
Az IEEE802.11 ajánlás is folyamatosan változik és bővül. A DSSS kiterjesztéseként az ajánlásba bekerült az úgynevezett HR/DSSS (High Rate DSSS), mely eljárás segítségével az adatkommunikáció sebessége már a 2 Mbit/s felett is támogatást nyújt, vagyis 5,5 Mbit/s, valamint 11 Mbit/s átvitel is megvalósítható a segítségével. A fizikai rétegben kialakított keret struktúra megegyezik a DSSS keretszervezéssel (úgynevezett „long PPDU” esetén).
128
Definiáltak egy úgynevezett rövid keretformátumot („short PPDU”) is, melyet a következő ábra szemlélteti:
4.2-6. ábra. Fizikai keret felépítés HR/DSSS esetén (short - PPDU) A DSSS-el a kompatibilitást úgy biztosították, hogy a fizikai keret elejét (SYNC és FSD mezők) DBPSK modulációval viszik át 1 Mbit/s sebességgel. A PLCP fejléc átvitele viszont már 2 Mbit/s sebességgel történik. A tényleges („hasznos”) adatok továbbítása viszont a 2 Mbit/s-on kívül, 5,5 Mbit/s vagy 11 Mbit/ s sebességgel is történhet. A PSDU átviteli sebességet most is a PLCP „SIGNAL” mező adja meg: 1 Mbit/s sebesség esetén PLCP SIGNAL = ’0000 1010’; 2 Mbit/s sebesség esetén PLCP SIGNAL = ’0001 0100’; 5,5 Mbit/s sebesség esetén PLCP SIGNAL = ’0011 0111’; 11 Mbit/s sebesség esetén PLCP SIGNAL = ’0110 1110’. Az alap DSSS-ben már definiált, de még „további fejlesztéshez fenntartott” SERVICE mező bitjei a HR/DSSS-ben már jelentéssel bírnak, például a b3 bit pozíció az úgynevezett „Modulation Selection Bit”.
129
OFDM Az OFDM (Orthogonal Frequency Division Multiplexing) többvivős modulációs eljárás elméletét már az 1960-as években kidolgozták, de az áramköri megvalósítás bonyolultsága miatt csak napjainkban terjedt el a felhasználása. Az átviteli elv hasonló, mint azt az ADSL-nél alkalmazott DMT (Discrete Multi Tone) eljárásnál láttunk, ugyanis itt is több, egymás mellett fix távolságra lévő vivőjelek találhatók, így az átviteli spektrumban megjelenő zavarjelek nem teszik teljesen tönkre az átvitelt, esetleg a digitális sávszélességet csökkenti az egyes csatornák kiesése. Az OFDM-nél az egyes vivőket valamilyen digitális szögmodulációval, vagy digitális QAMmel modulálják. Abban az esetben, ha a vivők távolságát okosan választjuk meg, valamint egy szimbólumba a vivő jel egész számú periódusa fér be, akkor így biztosítható a vivők függetlensége, vagyis úgynevezett ortogonalitása. A megértéshez szükséges ismernünk a digitálisan fázismodulált jel spektrumát, ahol a fázisváltás a szimbólumhatáron következik be. Az ilyen jel spektrumképe sin(x)/x jellegű formát mutat.
4.2-7. ábra. Fázismodulált vivőjel teljesítmény-spektrum abszolút értéke A Ts a szimbólum időt jelenti. Abban az esetben, ha a szomszédos vivők távolságát ∆f értékre választjuk meg, ahol ∆f = 1/Ts, akkor a vivőfrekvencia értékeknél a spektrumok egymást nem zavarják, a vivők egymástól függetlenek, ortogonálisak. Ebben az esetben az egyes vivők által szállított szimbólumok nem hallatszanak át, ezáltal az egyes csatornákban szállított információk dekódolhatók.
130
4.2-8. ábra. OFDM csatornák (7 vivő) spektrumképe Az OFDM eljárás legnagyobb előnye a fentieken túl még az, hogy a spektrumot igen hatékonyan használja ki, hiszen az egyes csatornák szeparálását nem véges fokszámú szűrők biztosítják, hanem a spektrumok jellegzetes alakja. Véges fokszámú szűrők esetén az egyes sávok között átmeneti sáv is szükséges lenne (lásd DMT), ami spektrumpazarlást jelent. Az IEEE 802.11g ajánlás értelmében az OFDM eljárással az átviteli sebesség maximuma 54 Mbit/s lehet. Az egyes OFDM csatornák vivői a digitális logikai kódokat BPSK, QPSK, 16QAM vagy 64QAM modulációs eljárással szállítják. Az OFDM-et a WLAN, nem kizárólag az ISM 2,4 GHz sávban használja, hanem az 5 GHz sávban is. Az alábbi ábra az egyes vivőkön alkalmazott digitális modulációs eljárások konstellációs ábráit láthatjuk, melyek jelzik a lehetséges szimbólumok pozícióit és a hozzájuk tartozó digitális kódokat is.
131
4.2-9. ábra. IEEE802.11g OFDM-nél alkalmazott BPSK, QPSK, 16QAM és 64QAM konstellációs ábrái
132
4.2.2. WLAN Adatkapcsolati réteg, közeghozzáférési eljárás Az adatkapcsolati réteg feladata a jelek keretszervezése, az interfészek fizikai címzése, a hibaellenőrzés és nem utolsó sorban a közös közeg hozzáférés szabályozása.
Az általános keret az alábbi alap komponenseket tartalmazza: •
Úgynevezett MAC-Header (MAC fejléc), ami tartalmazhat „Fame Control” mezőt, címeket, sorrendiség vezérlést és QoS információt;
•
Változó hosszúságú keret törzset, mely a felsőbb rétegek üzeneteit hordozza;
•
Ellenőrző összeget, ami 32 bites CRC kód.
Az általános keret felépítését a következő ábra szemlélteti: 2 byte
2 byte
6 byte
6 byte
6 byte
2 byte
6 byte
2 byte
0 -23124
4 byte
byte
Frame
Duration Addr1
Control /ID
Addr2
Addr3
Sequence Addr4
QoS
Control
Control
DATA FCS
←MAC Header→
4.2-10. ábra. Az általános keretformátum
A Frame Control mező bitjeit a következő ábra szemlélteti:
4.2-11. ábra. A Frame Control mező bitjei A „Protocol Version” mező azonosítja a kommunikációs protokoll verzióját. Jelenleg mindkét bit ’0’ értéken áll, a többi lehetőség (’01’, ’10’ és ’11’) használata nem megengedett. A „Type” mező két bitje szintén négy állapotot jelöl, melyből az ’11’-et további fejlesztésekhez tartottak fenn. A ’00’ esetén a keret úgynevezett menedzsment információt
133
hordoz. A ’01’ állapot vezérlő (Control) információt jelöl, míg ’10’ esetén a tényleges adatátvitel történik. Az adott üzenet típuson belül (Menedzsment/Control/Data), melyet a Type kód azonosított, a továbbítandó kerettípust a „Subtype” mező jelöli. Normál adatátvitel esetén a „Subtype” a ’0000’ értéket kapja (a Type értéke ekkor ’10’).
A „To DS” és a „From DS” mezők, melyek 1 – 1 bitesek együttesen értelmezhetők és azt jelzik, hogy az adott adatkeret egy elosztott rendszer felé halad-e, vagy AP-nek szól. Mindkét bit ’0’ értéken áll, ha az adatáramlás állomás-állomás (STA – STA) között zajlik és az egyik STA sem AP (Access Point).
A „More Fragment” bit az átvitt adatcsomag tördelése esetén ’1’-el jelzi azt, hogy további töredék fog érkezni.
A „Retry” bit ’1’ értéke azt jelzi, hogy az éppen küldött keret egy ismételt küldés, vagyis ezt a keretet egyszer már továbbítottuk, de pozitív nyugtaüzenetet nem vettünk. A pozitív nyugtaüzenet vételének elmaradása több okra vezethető vissza. Abban az esetben, ha a küldött keret sérül, vagy nem érkezik meg, akkor a vevő ezt logikusan nem nyugtázza. Másik esetben maga a nyugta üzenet veszhet el (ütközés, rádiós zavar stb.). Ez utóbbi esetben a vevőhöz valójában megérkezett a küldött keret, és az újraküldés során az duplikálódhat. A vételi oldalon a duplikált vételek kiszűrésében nyújthat segítséget a „Retry” bit.
A „Pwr Mgt” (Power Management) szintén egy egybites mező. A hozzáférési pont (AP – Access Point) által küldött keretek esetében ez a bit mindig logikai ’0’ értéken áll, mely aktív állapotot jelent. Az állomásoknak lehetőségük van az energiatakarékos üzemmódra és ezt a PS bit’1’-be állításával jelzik, míg úgynevezett aktív üzemmódban ezt a bitet ’0’-ba állítják.
A „More Data” mező egy egybites indikátor, melynek az ’1’ állása azt jelzi, hogy az eszközben további adatmezők buffereltek és elküldésre várnak.
A „Protected Frame” bit ’1’ értéke azt jelzi, hogy a keretben küldendő adatok titkosítottak. A titkosítás úgynevezett „titkosítási enkapszulációs eljárással” történik. Titkosításkor a keret „DATA” mezőbe, a titkosított adatsor kerül.
134
Az „Order” bit olyan, nem QoS osztályhoz rendelt keretek esetén állhat logikai ’1’ értékre, melyek MSDU-t (MAC Service Data Unit) szállítanak, vagy olyan tördelt adatot továbbítanak, melyeknél a sorrend fontos. Egyéb más esetekben ez a bit ’0’ értékű.
A „Frame Control” mező bitjeinek tárgyalását követően most térjünk vissza a keret további mezőinek áttekintéséhez. A MAC fejlécben a következő mező az úgynevezett „Duration/ID”, amely 2 byte-ból áll. Vezérlő üzenetek esetén a mező egy azonosítót (AID – Association Identifier) szállít, mely értéke 14 biten ábrázolt és a 14 biten megjelenő szám értékkészlete 1 – 2007 között értelmezett. A két legértékesebb bit (MSB) ekkor fix ’11’ értéken áll. Abban az esetben, ha a keret nem QoS keretet szállít, vagy az adatot PC (Point Coordinator) küldi, akkor a mező 16 bitjén fix 32768 szám található. Abban az esetben, ha a 16 biten ábrázolt szám a 0 – 32767 tartományba esik, akkor a mező mikroszekundumban értelmezett időtartamot jelent.
Az „Address” (Addr1, Addr2, Addr3 és Addr4) mezők 48 bitesek és MAC címeket szállítanak. Nem feltétlenül szállít az összes mező MAC címet. A szállítható címek a következők lehetnek: BSSID – Basic Service Set Identification; SA – Source Address; DA – Destination Address; TA – Transmitting Address; RA – Receiving Address.
Az „FCS” mező 32 bites és szerepe a hibafelfedés. Az FCS tartalmát ugyanúgy, mint a vezetékes Ethernet hálózatoknál láttuk egy polinom osztás (illetve annak maradéka) adja. A generátor polinom jelen esetben is egy 33 bites digitális szám, melyet a következőképpen szoktak megadni: x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x10 + x 8 + x 7 + x 5 + x 4 + x1 + x 0 Valójában a generátor polinom által reprezentált digitális szám a következő: 100000100110000010001110110110011 Az osztás maradéka ebben az esetben egy maximum 32 bites bináris szám, melyet a keretszervezésben CRC32-vel jelölt mező fog szállítani. Abban az esetben, ha a kalkulált
135
maradék hossza kisebb, mint 32 bit, akkor az értékesebb bitek felől a kapott eredményt ’0’-kal töltik fel.
Az adatátvitel során a hibátlanul vett keretek pozitív nyugtázása kötelező. A pozitív nyugta elmaradása negatív nyugtának számít, és a küldő a keretet elveszett keretnek jegyzi fel, így megismétli annak újraküldését. Pozitív nyugtázás az ACK kerettel valósítható meg.
2 byte
2 byte
6 byte
4 byte
Frame control
Duration
RA
FCS
←MAC Header→
4.2-12. ábra. ACK keretformátum A Frame Control Type mező bitjei ’01’ értéken állnak, valamint a „Subtype” bitek az ’1101’ logikai értéket hordozzák a CTS keret esetén. Az RA (Receiver Address) mező hordozza a vevő eszköz címét. Az FCS (Frame Check Sequence) 32 bites CRC ellenőrző kódot hordoz.
136
CSMA/CA A közös közeg hozzáférés problémát, már a vezetékes számítógép-hálózatok esetén megvizsgáltuk. Ethernet hálózatok esetén a CSMA/CD az elterjedt közeghozzáférés, de ez a módszer rádiós közeg esetén nem alkalmazható. A rádiós interfészek esetén az egyidejű adás és vétel csak igen költségesen oldható meg és a sávszélesség is pazarló lenne. Van egy másik probléma, ami még magas anyagi ráfordítás esetén sem orvosolható, ez pedig az úgynevezett „rejtőzködő állomások” esete. Egy WLAN interfész, adás irányban rendelkezik egy maximális kimenő teljesítménnyel, vétel irányban pedig egy úgynevezett bemeneti érzékenységgel. Ez a két paraméter határozza meg a kommunikáció során az áthidalható távolságot, vagyis az egyes eszközök hatókörét.
4.2-13. ábra. „Rejtőzködő” állomások Egymástól rejtőzködő állomásoknak nevezzük azokat az eszközöket, melyek egymás hatókörén kívül esnek, de mégis azonos WLAN hálózathoz tartoznak. A fenti ábra szerint „A” és „B” ugyanazon hozzáférési pont (AP) hatókörén belül található, de az „A” és „B” állomás egymás adását nem érzékeli. Ebből az derül ki, hogy a vivő figyelés a rádiós hozzáférések esetén más eredményt nyújt, mint a vezetékes közeg esetén. A WLAN eszközöknél az úgynevezett CSMA/CA közeghozzáférési módszert alkalmazzuk. A módszer legfontosabb működési jellemzői a következők (AP-vel kialakított kapcsolatot vizsgáljuk): •
Van vivő figyelés (Carrier Sense), de nem ad pontos információt;
•
Minden hibátlanul vett keretet az AP pozitívan nyugtáz;
•
Nincs negatív nyugta üzenet, de negatív nyugtának számít a hibásan megérkezett, vagy elmaradt pozitív nyugta;
•
A kliensek adatot kizárólag a nekik dedikált időablakban küldhetnek az AP felé; 137
•
Az időablak kérés és jóváhagyás rövid, adatinformációt nem tartalmazó jelzés keretekkel történik (RTS és CTS).
Az alapfogalmak összefoglalását követően nézzük a működést! Tételezzük fel, hogy az „A” állomás adatot kíván küldeni az AP-nek, de mielőtt ezt megtehetné, előtte engedélyt kell kérnie. Az engedélykérés úgynevezett RTS (Request To Send) kerettel történik, melyet az „A” fog felküldeni az AP-nek, de természetesen ez a küldés csakis akkor kezdődhet, ha a vivőfigyelés során a használandó csatorna üresnek látszott. Ezt az RTS keretet nem feltétlenül látta az összes érintett állomás, ugyanúgy, mint ahogy az „A” sem biztos, hogy látta mindenki adását (itt gondoljunk a rejtőzködő állomásokra!). Abban az esetben, ha az „A” RTS üzenete rendben megérkezett az AP felé, és az AP ki kívánja elégíteni az „A” igényét, akkor egy CTS (Clear To Send) üzenettel fog válaszolni, ami egyértelműen az „A”-nak szól. Az „A”-nak szóló CTS egyben egy pozitív nyugta az előzőleg küldött RTS-re, és egy engedély megadást is jelent az „A” adásának megkezdésére. Az AP által küldött CTS üzenetet az AP hatókörén belül található összes kliens érzékelte (a fenti ábrán látható „B” is) és számukra egy időablaknyi intervallumban ez tiltó üzenetként jelentkezik. Reményeink szerint a CTS mindenkinek eljutott, de természetesen hiba itt is előfordulhat, vagyis nem biztos, hogy mindenki számára megérkezett. Először vizsgáljuk meg azt az esetet, hogy a CTS az RTS küldő felé nem érkezett meg, de a többi állomás fogadta a jelet. Ekkor az RTS-t küldő negatív nyugtának vette azt, hogy nem jött számára CTS, vagyis a küldeni kívánt adatait türelemmel tárolja, és majd egy későbbi időpontban egy újabb RTS kéréssel jelentkezik.
Vizsgáljuk meg másodszor azt az esetet, hogy mi történhet akkor, ha az RTS-t küldő (jelen esetben „A”) rendben fogadta az AP CTS keretét, de egy az „A” számára rejtőzködő állomás (például „B”) nem, vagy hibásan vette, ezért nem tudta értelmezni azt. Ekkor sajnos előfordulhat az, hogy a CTS hatására az „A” állomás megkezdi a számára engedélyezett időablakban az adatainak felküldését az AP felé, de ebből „B” semmit sem hall, ezért nyugodt lelkiismerettel egy RTS kerettel ő is adási engedélyt kér. Ez az RTS ekkor összeütközik az „A” állomás keretével, ezért elképzelhető, hogy az megsérül. Az AP-hez, ha az „A” adása sérülten érkezik meg (vagy nem érkezik meg), akkor az ilyen keretek pozitív nyugtázása elmarad. A pozitívan nem nyugtázott kereteket újra kell küldeni. Az ismételt küldés időpillanatát háttéralgoritmus kalkulálja. A vivőfigyelést követően az úgynevezett CW (Contention Window) tároló 7 értéken áll. Az úgynevezett „Backoff_time” számítása sorsolással történik: 138
Backoff_time = Rand [0 - CW] ⋅ SlotTime Az első újraküldésnél a CW értéke 15-re vált, vagyis a véletlen szám 0 – 15 lehet. A második újraküldésnél a CW = 31, a harmadiknál a CW = 63, a negyediknél a CW = 127 és az ötödiktől felfelé a CW = 255, és értéke a továbbiakban nem inkrementálódik.
4.2-14. ábra. Példa a „Backoff” algoritmus működésére28 Normál (normál alatt most a „szerencsés” is beletartozik az eseményhalmazba) körülmények között az „A” adása rendben megérkezett, melyet az AP rendben vett, és le is nyugtázott. A fentiekből látszik, hogy a CSMA/CA egy olyan vivőfigyelést (Carrier Sense) alkalmazó közös közeg hozzáférési eljárás, mely igyekszik elkerülni az ütközést (Collision Avoidance). Ez persze nem mindig sikerülhet, de minden eszköz legjobb képességei szerint igyekszik ennek eleget tenni. Az ütközések legnagyobb valószínűséggel az RTS-CTS üzenetváltás közben következhetnek be, ugyanis ekkor a jóhiszemű állomás, a vivőfigyelést követően (ha a közeget szabadnak érzékelte) elküldi az AP felé az RTS-t. Ugyanígy járhat el egy másik állomás is, ha azok egymás adását nem látják, vagyis egymás hatókörén kívül esnek. Az RTS-ek ütközésének valószínűségét úgy lehet hatékonyan csökkenteni, ha ezen üzenetek hosszát a lehető legrövidebbre szabjuk. Az RTS, a CTS és a nyugtázó ACK üzenetek külön keretformátumot kaptak, azok az adatátvitel során használt keretektől eltérnek. 2 byte
2 byte
6 byte
6 byte
4 byte
Frame Control
Duration
RA
TA
FCS
←MAC Header→
4.2-15. ábra. RTS keretformátum 28
A kép forrása IEEE802.11
139
A Frame Control Type mező bitjei ’01’ értéken állnak, valamint a „Subtype” bitek állása ’1011’ logikai értéknek felel meg az RTS keret esetén. Az RA (Receiver Address) mező hordozza a vevő eszköz címét, míg a TA az pedig az adó címet (Transmitter Address). Az FCS (Frame Check Sequence) 32 bites CRC ellenőrző kódot hordoz.
2 byte
2 byte
6 byte
4 byte
Frame control
Duration
RA
FCS
←MAC Header→
4.2-16. ábra. CTS keretformátum A Frame Control Type mező bitjei ’01’ értéken állnak, valamint a „Subtype” bitek az ’1100’ logikai értéket hordozzák a CTS keret esetén. Az RA (Receiver Address) mező hordozza a vevő eszköz címét. Az FCS (Frame Check Sequence) 32 bites CRC ellenőrző kódot hordoz.
A következő példában egy komplett kommunikációt fogunk áttekinteni. A forrás állomás (Source) a vivőfigyelést követően egy RTS keretet küld a célállomásnak (Destination). A célállomás egy CTS kerettel megadja az engedélyt az adásra, és ezzel egyidőben a többi eszköz adását tiltja. A forrás állomás a vett CTS keretet követően elküldi az adatot tartalmazó keretet, mely ha rendben megérkezik a célállomáshoz, az azt egy ACK keret küldésével nyugtázza. Az ACK keret végét követően a DIFS (Distributed Interframe Space) elteltével a többi állomás (jelen esetben az „Other”) a háttéralgoritmussal adási időt sorsolhat magának, amely az úgynevezett „Connection Window”-ba fog esni, természetesen csakis akkor, ha a másik állomásnak van küldendő adata.
140
4.2-17. ábra. RTS-CTS-Data és ACK példa29 A fenti ábrán a NAV(RTS) és a NAV(CTS) a kommunikációban nem részt vevő „Other” eszköz számára tiltó üzenetként jelentkezik. Valójában ez a megfigyelő állomás a forrás (source) állomás RTS jelét veszi (ha egymás elől nem rejtőzködnek), valamint a célállomás CTS jelét.
29
Kép forrása IEEE802.11
141
4.2.3. IEEE 802.11n – „Next generation” WLAN A jegyzet írásakor a WLAN interfészek úgynevezett következő generációjának a szabványosítása már megtörtént (IEEE 802.11n - 2009). Ez az eljárás felülről kompatibilis a korábbi ajánlásokkal, de a maximális sebesség eléréséhez ez a rendszer már 40 MHz csatorna sávszélességet használ. A 40 MHz sávszélességű csatorna valójában kettő 20 MHz sávszélességű csatorna összefogásával áll elő. A maximális adatátviteli sebesség 600 Mbit/s, ami jelentős sebesség növekedést jelent az IEEE 802.11g-ben megadott 54 Mbit/s értékhez képest. A legnagyobb adatátviteli sebesség eléréséhez a rendszer 64 állapotú QAM-et használ és az adás és vétel úgynevezett „diversity” antenna rendszeren történik. Az antenna rendszert több antenna alkotja. Azt, hogy egy adott rendszer hány adó és vevő antennát képes kezelni, azt az eszközön egy szabványosított séma szerint jelölik, mely a következő: a x b:c Az a azt adja meg, hogy a rendszerben mennyi az egyidejűleg kezelhető adó-antennák száma. A második szám, amit b –vel jelöltünk a vevő antennák számát jelöli, míg a c, a maximális rádiós csatornaszám kezelést mutatja. A 802.11n ajánlás a legnagyobb kapacitás esetén a 4 x 4:4 konfigurációt definiálja. További konfigurációk a következők lehetnek: 2 x 2:2 , 2 x 3:2, valamint 3 x 3:2. A több antennából álló antennarendszer úgynevezett MIMO (Multiply Input Multiply Output) adatátvitelt tesz lehetővé a fizikai rétegben, mely javítja az átvitel minőségét. A csatornákban a jelátvitel OFDM eljárással történik, vagyis ez a rendszer is multivivős.
142
5. IP alapú hangátvitel A csomagkapcsolt hálózatokat elsősorban adatok továbbítására találták ki, és fejlesztették. Az egyre nagyobb kapacitású és teljesítőképességű hálózat csábítóan hat, hogy multimédiás tartalmakat is küldjünk rajta, illetve töltsünk le magunknak. Amíg a multimédiás tartalom lejátszás nem valós időben történik, addig nincs is igazán nagy probléma. A sikeres tartalom letöltést követően gond nélkül lejátszhatjuk azokat. Itt meg kell állnunk egy pillanatra, és tisztáznunk kell azt, hogy mit értünk „valós időben” történő lejátszásnak! Jelen esetben egy csomagokra bontott digitális jelfolyam vételéről van szó, ahol az egyes információ egységek a csomagkapcsolt hálózaton a továbbítás közben sérülhetnek, valamint különböző késleltetést szenvedhetnek el. Előfordulhat olyan helyzet is, hogy a változó késleltetések és természetesen a más útvonal miatt a vétel helyén a csomagok sorrendje felcserélődik. A fenti okokból egyértelműen látszik, hogy igazi valós idejű adattovábbítás az IP hálózatokban nem valósulhat meg, csak a felhasználó számára tűnhet annak. A multimédiás tartalom letöltése közben történő lejátszást mégis sok esetben valós idejű lejátszásnak nevezzük, holott az csak egy bizonyos késleltetéssel történik. A letöltött tartalomtól függően a késleltetési idővel kapcsolatosan elvárásokat, konkrétan késleltetési idő maximumokat határozunk meg.
A multimédiás adatátvitel minőségét természetesen több tényező együttese határozza meg. A hozzáférhető szolgáltatásokat úgynevezett minőségi mutatókkal jellemzik. A jellemzés egyértelművé tétele érdekében QoS kategóriákat definiáltak. A végfelhasználó multimédia QoS kategóriákat az ITU-T G.1010 ajánlás definiálja, mely a végfelhasználó (előfizető) szemszögéből nyolc különböző kategóriát jelent. A kategória meghatározás az információ felhasználási helyén előálló adatvesztés és az erre vonatkozó tolerancia, valamint a késleltetési idő alapján történik. A QoS kategóriák meghatározásánál az ajánlásban az alábbi átviteltechnikai kulcsparaméterek meghatározása történt: •
Késleltetés (Delay);
•
Késleltetés változás (Delay variation);
•
Információvesztés (Information loss);
143
A késleltetés fogalom alatt definíciószerűen azt az időt értjük, mely a szolgáltatás igénybevétele során a felhasználó kéréstől a kért információ vételéig telik el. A csomagokra bontott adat esetében a késleltetés változás kiemelt fontosságú jellemző (transzport réteg vonatkozásában). A fogalom alatt az egyes csomagok késleltetés (megérkezési idejének) változását értjük. Olyan szolgáltatások esetén, melyek a késleltetés tekintetében magas toleranciával rendelkeznek, vagyis nagy késleltetést képesek elviselni, a késleltetés változás alkalmasan megválasztott puffereléssel kiküszöbölhető. A pufferelés természetesen a konstans késleltetést növeli meg, ami a pufferelés mértékétől függ. Az információvesztés közvetlen hatással van a végfelhasználónál megjelenő információra, ami lehet hang, kép, videó vagy adat. Az ITU G.1010 ajánlás szemléletes ábrán foglalja össze azokat az elvárásokat, melyek teljesülése esetén az információ átvitel még elfogadható minőséget képvisel.
4.2-1. ábra. Minőségi jellemzők határértékeinek szemléltetése ITU G.1010 ajánlás szerint A fenti ábrából látszik, hogy a párbeszéd átvitele esetén legkevésbé tolerálható a késleltetés, ugyanakkor néhány százalék adatinformáció veszteség megengedett. Bizonyos esetekben a párbeszéd átvitel során akár 400ms késleltetést is megengednek az ajánlások, de ezt kizárólag azért teszik, mert a rendelkezésre álló hálózatok, eszközök és protokollok nem teszik lehetővé kisebb késleltetési idők (például 150ms, vagy az alatti) elérését.
A csomagkapcsolt hálózaton történő beszéd-, és egyéb hangátviteli kérdéseket az ITU-T G.1020 ajánlás tárgyalja részletesen (természetesen a G.1010 ajánlással összhangban). Az
144
ajánlás elsősorban a csomagkapcsolt hálózat és a végberendezés paramétereit definiálja. A fókuszban a minőség romlás szerepel, melyet az időzítés változás és a csomagvesztés okoz. A beszédcélú hangátvitel esetén három egységet kell megkülönböztetni: •
Forrás terminál;
•
Átviteli hálózat;
•
Cél terminál.
A hangátvitelt érintő egységeket és protokollokat a következő ábra szemlélteti. Az ITU-T G.1020 ajánlás a forrás előfizetői berendezés mikrofonjától egészen a cél végberendezés hangszórójáig veszi figyelembe a beszédjel minőségromlását. Az ajánlás fókuszát a következő ábra szemlélteti:
4.2-2. ábra. Az ITU G.1020 ajánlás hatóköre és környezete30 A valós idejű hangátvitel RTP-vel és az azt vezérlő RTCP-vel történik, melyeket UDP keretbe foglalnak és ezek fogják az IP számára a „datagram”-ot jelenteni. A forrás terminál az emberi száj által előállított hangnyomásból elektroakusztikus átalakítóval (mikrofonnal) elektromos jelet állít elő. A mérések elvégzéséhez az ajánlások „száj referencia pontot” definiálnak. A rendszer első elektromos mérőpontja az úgynevezett „send electrical reference point” (forrás oldali elektromos referencia pont), ahol idő- és halmaz folytonos 30
Az ábra az ITU-T G.1020 ajánlásból származik
145
(értelmezési tartományon és értékkészleten folytonos időfüggvény) analóg jel jelenik meg. A mintavételező és kvantáló, kódoló áramkör (A/D konverter) kimenetén diszkrét idejű és diszkrét értékkészletű jel (digitális jel) jelenik meg. Az A/D konverziónál alkalmazott mintavételi frekvencia 8000 Hz. Ez a mintavételi frekvencia természetesen megkívánja azt, hogy az elektroakusztikai átalakító (mikrofon) kimenetén megjelenő analóg jel sávkorlátozott legyen. Ha a jel 4000 Hz feletti frekvencia komponenst is tartalmaz, akkor a spektrum a mintavételezésnél átlapolódik (aliasing jelenség).
4.2-3. ábra. Az IP hangátvitel adási-irány blokksémája az ITU-T G.1020 ajánlás szerint31 Nézzünk meg néhány definíciót, mely fogalmak általánosságban a VoIP átvitel esetén igazak. A definíciók az ITU-T G.1020 ajánlásból származnak:
Csomag információs mező hossz (Packet information field size) megadja a beszéd, hullámforma kódolt mennyiségét, amelyet az adott csomag tartalmaz. A tipikus információs mező egy vagy kettő kódolt keretet tartalmaz (egy szimpla csomagban tipikusan 10 vagy 20 ms időszeletnek megfelelő kódot).
Forrás terminál késleltetési időnek (Source terminal delay) nevezzük azt az időt, amely a „száj referencia pont”-on (mouth reference point) megjelenő analóg jel belépési időpontja és a terminál kimeneti referenciaponton e jel beszédmintájához tartozó adatcsomag első bitjének kilépési időpontja között telik el.
Forrás terminál késleltetés változás (Source terminal delay variation)
31
Az ábra az ITU-T G.1020 ajánlás ábrája alapján készült
146
A forrás terminál késleltetés változásának ideje alatt definíciószerűen azt az időt értjük, ami a „terminál kimeneti referencia ponton” kilépő – a hanginformáció elemeit szállító - csomagok kezdeti bitjei közti időzítés változása: Forrás terminál késleltetés változás = t(n-edik csomag) – t(referencia csomag)
A vételi oldal (cél terminál) késleltetése jelentős mértékben befolyásolja a továbbított hanginformáció minőségét. A fogalmak tisztázásához az ITU-T G.1020 ajánlás itt is három „mérő” referencia pontot definiált, melyek a következők: •
Terminál bemeneti referencia pont (Terminal input reference point);
•
Vételi elektromos referencia pont (Receive electrical reference point);
•
Fül referencia pont (Ear reference point).
4.2-4. ábra. Az IP hangátvitel vételi-irány blokksémája az ITU-T G.1020 ajánlás szerint32 A hálózaton továbbított adatok a vevő fizikai interfészén keresztül jutnak a berendezésbe. A kibontott keretekből a hanginformációt továbbító adatok az úgynevezett „De-jittering” bufferbe íródnak. A De-jittering buffer ad lehetőséget arra is, hogy sorrendbe állítsuk a hálózatban esetlegesen felcserélődött csomagokat. Erre természetesen csak akkor van lehetőség, ha egy „késő” csomag még azelőtt megérkezik, még mielőtt esedékes lenne annak „lejátszása”. Ellenkező esetben a csomag beillesztésére már nincs lehetőség, vagyis a nagy
32
Az ábra az ITU-T G.1020 ajánlás ábrája alapján készült
147
késleltetéssel megérkező csomag (hiába érkezik meg az hibátlanul), már vesztett csomagnak számít. A hálózati forgalom, valamint az esetleges pillanatnyi torlódások miatt késő csomagoknak akkor van a legjobb esélyük, hogy még a felhasználásuk (jelen esetben lejátszásuk) időpontja előtt megérkezzenek, ha minél nagyobb De-jittering buffert alkalmazunk. A nagyméretű buffer tehát kellemes a csomagvesztés szempontjából, de a késleltetett lejátszás jelkésleltetést jelent, ami (mint azt fent már láttuk) egy párbeszéd esetében igen zavaró, ezért azt 150 ms fölé vinni nemkívánatos. A De-jittering buffer kialakításánál tehát egymásnak ellentmondó szempontok alapján kell megtalálni az optimális kialakítást. Alapvetően kétféle de-jittering buffer típust különböztetünk meg: •
Fix hosszúságú;
•
Adaptív hosszúságú.
A jelkésleltetés, ami minőség változást okoz alapvetően három paraméterből áll elő: •
Forrás késleltetés,
•
Hálózat késleltetés (ennek részleteit később tárgyaljuk),
•
Cél terminál késleltetés.
Az egyes késleltetési időket az alábbi ábrán szemléltetjük:
4.2-5. ábra. A VoIP késleltetés A fenti ábrán szemléltetett késleltetések a rendszerben akkumulálódnak. A késleltetések összege adja a végpont-végpont közti eredő késleltetést.
148
A vétel oldali de-jittering buffernek olyan méretűnek kell lennie, ami képes kikompenzálni a forrásterminál késleltetés és a hálózat késleltetés változás időket, vagyis az „aszinkron” módon érkező csomagokból folyamatos, az eredeti digitalizálással azonos mintavételezési idejű és fázisú digitális jelfolyamot olvashatunk ki.
Abban az esetben, ha az átvitel során véletlen bithiba áll elő, akkor az UDP keret ellenőrző összege jelzi a hibás kerettartalmat. A hibás keretek ilyenkor elvesznek, mert eldobásra kerülnek az OSI alkalmazási rétegben. A fenti okból tehát a veszteség kategorizálást beszédátviteli alkalmazás esetén, az alkalmazási rétegben kell meghatározni. Abban az esetben, ha a hálózat átlagos késleltetése ismert, akkor összegezni kell azt a dejittering buffer átlagos foglaltsági idővel, így kapjuk meg a teljes átlagos késleltetést. Amennyiben csak a hálózat minimum késleltetése ismert, akkor ehhez hozzá kell adnunk a maximális de-jitter buffer foglaltsági időt, ekkor ez fogja adni a teljes átlagos késleltetési időt.
Fix méretű de-jittering bufferrel felépített cél terminál modell szerint tudjuk legegyszerűbben értelmezni a kommunikáció során elveszett csomagokat. A legegyszerűbb modell esetén az összes olyan csomag eldobásra kerül, melyek késleltetése nagyobb, mint a hálózat minimális átviteli ideje plusz a fix hosszúságú de-jittering buffer tárolási ideje (vagyis a csomagot elveszettnek tekintjük, ha az később érkezik meg, mint azt a valós idejű alkalmazás felhasználná). Ebben az esetben a következő eljárás gondoskodik az IP és az alkalmazási rétegek közti leképzésről: • Eldobásra jelöl minden olyan csomagot, mely UDP ellenőrző összeg hibát jelez. • Eldobásra jelöl minden olyan csomagot, mely késleltetése nagyobb, mint a hálózat minimum késleltetése plusz a fix hosszúságú de-jittering buffer tároló képessége, vagy a késleltetése kisebb, mint egy megállapított minimum. • Összegzi a hálózat átlagos késletetését (IPTD – IP Packet Transfer Delay) a forrásterminál és a célterminál átlagos késleltetésével, hogy megkapja a teljes átlagos késleltetési időt, vagy összegzi a forrásterminál „minimum időt” a minimum hálózati késleltetési idővel, valamint a célterminál maximum késleltetéssel.
Adaptív de-jittering buffer és a cél terminál modell szerint az eljárás egymástól kissé különbözik. Adaptív de-jittering buffer alkalmazásakor a buffer mérete változik, így a teljes késleltetés is változik a buffer méretétől függően. Ilyenkor ugyanis, ha egy sorrendben előbb 149
álló csomag az IP hálózat késleltetése miatt később érkezik meg a sorrendben később lévő csomagoknál, a buffer csak akkor olvasható ki, ha már egy mintasorozathoz tartozó összes csomag megérkezett. A dekódoló ugyanis csak ilyenkor tudja a mintához tartozó csomagokat feldolgozni. Ez az alkalmazás esetenként megnöveli a teljes késleltetési időt, azonban a beszéd minősége jobb lesz, mint a fix bufferméret esetében.
A fentiekben megszerzett ismereteink alapján a csomagvesztésre egyszerű leírást adhatunk. A csomagvesztés azt az arányt jelenti, amely megmutatja, hogy az elküldött csomagok hány százaléka nem éri el a célcsomópontot. Egy egyszerű példa: telefonáláskor az elvesztett csomagokat a célállomás üres csomagokkal helyettesíti. Amennyiben túl sok üres csomag lesz a dekódolandó hangban, akkor akár szavak is hiányozhatnak az átvitt beszélgetésből. A csomagvesztés („packet loss”) leggyakoribb okai a következők: •
Az átviteli berendezés meghibásodása (linkszakadás, csomóponthiba).
•
Az útvonal csomópontjainak száma nagyobb, mint a csomag TTL (Time-To-Live) értéke, ilyenkor ugyanis az ezt érzékelő csomópont eldobja a csomagot.
•
Torlódás (congestion): Az adatkommunikáció burst-ös jellege miatt gyakran előfordulnak esetek, amikor a router-ek pufferei megtelnek a kimenő linkek kis sávszélessége vagy a CPU túlterhelése miatt. Ilyenkor eldobják az összes várakozó csomagot a szállítási protokollnak megfelelően, vagy elvész a csomag (UDP), vagy újraküldi a forrás (TCP). Érdekes, hogy a torlódás nem növeli meg tartósan a késleltetést a hálózatban, mert a TCP forgalomszabályozás rögtön lecsökkenti az adás sebességét, ezért csak néhány csomagnak lesz nagy késleltetése, összességében az átbocsátóképesség csökken (ritkábban küldik a csomagokat).
A mai kódolók 3-5%-os csomagvesztést is elviselnek a beszédminőség jelentős degradációja nélkül, különböző interpolációs technikákat használva a hiányzó minták közelítésére. Még 58%-os csomagvesztés mellett is kielégítő minőségű lehet a beszélgetés, de ilyenkor a beszédátvitel már nem alkalmas üzleti kommunikációra, inkább csak magánbeszélgetések lebonyolítására. Több lehetséges módszer is létezik az elvesztett csomagok kijavítására. Amennyiben a „packet loss” alacsony, akkor járható út az előző hangminta megismétlése. Létezik azonban jobb módszer a hiba kiküszöbölésére, mégpedig a Packet Loss Concealment (PLC). Ezzel a technikával a már fogadott beszédmintákból állítja elő azt a csomagot, ami valószínűleg következni fog (predikciós - jósló módszer).
150
5.1. RTP és RTCP Az RTP és RTCP protokoll páros az OSI szállítási (Transport) rétegében kapott helyet. Az RTP-t az RFC 1889, míg az RTCP-t az RFC 3550 definiálja.
5.1.1. RTP – Real-time Transport Protocol Az RTP valós idejű adatok átvitelére alkotott eljárás, ezért VoIP adatátvitelre előszeretettel alkalmazzuk. Ez a protokoll IP hálózaton történő időszinkronizált adatátvitelre képes unicast, vagy multicast csatornán. Az RTP tipikus alkalmazása a digitális hang, vagy videó jeltovábbítás, de folytonos adatfolyam szállítására is alkalmazható. Az RTP overhead tartalmaz egy payload típusazonosítót, ami megadja a továbbított adat típusát. A protokoll legfontosabb tulajdonsága, hogy minden keret tartalmaz egy időbélyeget („payload timestamp”). Az RTP keret felépítését a következő ábrán tüntettük fel: V M
P
X
CC
PT SQ (2 byte) TStamp (4 byte) SSRC (4 byte) CSRC list (4 byte) Hasznos adat illetve helykitöltő (Padding)
5.1-1. ábra. Az RTP csomag felépítése Az egyes adategységek jelentését és méretét a következőkben foglaltuk össze: A „V” mező 2 bit hosszúságú („Version”), a protokoll verziószám jelölésére szolgál, jelenleg az RTP 2-es verzió használatos. A „P” egybites („Padding”). Ez a bit jelzi, hogy a csomag payload helytöltő „padding” byteokat is tartalmaz.
151
Az „X” mező szintén egy bitből áll, jelentése „Extension”. Ez a bit lehetőséget biztosít az RTP fejléc opcionális kibővítésére. A „CC” mező 4 bites (CSRC Count). Az RTP csomagban előforduló CSRC azonosítók számát adja meg. A CSRC azonosítók az RTP fejlécben, annak CSRC mezőjében (32 bit) találhatóak. Az „M” egybites („Marker”). Ennek a bitnek az aktuális jelentése a profiltól függ. Használható a felsőbb rétegek határvonalainak megjelölésére, vagy extra payload megjelölésre. Számos alkalmazásban ez a bit nem használatos. A „PT” (Payload Type) mező, mely 7 bitből áll a payload típus és a média típus azonosítására szolgál. Az „SQ” 16 bites mező (SeQuence number). Ez a sorszám minden egyes keret küldése során inkrementálódik (modulo 65536 módszerrel). A vevő ezen szám alapján képes felderíteni az esetleges csomagvesztést. Az adás megkezdésekor ez a szám egy véletlen szám. A „TStamp” (Timestamp) 32 bitből áll. Ez a szám reprezentálja az RTP csomag payload első byte-hoz tartozó mintavételi pillanatot. Erre az értékre alapozottan képes a vevő a vett adatokból (burst jellegű) helyreállítani a mintavételi ütemezésnek megfelelő folyamatos digitális jelfolyamot. Az egyes alkalmazások esetén a mintavételi frekvencia egymástól eltérő, melynek azonosítása a payload formátum specifikációban szerepel. Ennek a számnak a kezdeti értéke véletlen szám. Az „SSRC” (Syncronization Source) mező 32 bites. Tartalma egy véletlen számként generált azonosító, melynek feladata az RTP adatfolyam eredetének azonosítása. Az „CSRC” (Contributing Source list) mező szintén 32 bitből áll. A listában maximum 15 azonosító szerepelhet. Azt, hogy ebben a listában ténylegesen hány azonosító található, a CC mező száma adja meg.
152
5.1.2. RTCP – Real TimeControl Protocol Az RTCP az RTP komplemens protokollja (RFC 3550). Elsődleges feladata, hogy visszacsatolást adjon a küldő félnek az átvitel minőségéről. Ezzel a funkcióval lehetőség nyílik az átvitel- és a torlódásvezérlésre, melyeket más transzport rétegbeli protokollok hajtanak végre. Az RTCP folyamatosan szállítja az RTP forrás felé a szállítási (Transport) réteg azonosítót, kiegészítő forrásazonosítást végez. Némely alkalmazásnak az SSRC mező nem elegendő a forrásazonosításra, mivel ez az azonosító megváltozhat ütközés, vagy a felhasználó végberendezés újraindulása esetén. Az RTCP öt csomagtípust definiál, melyek elnevezése és azonosítója (PT) a következő táblázatban látható:
RTCP csomagtípusok RTCP csomag típus SR
PT azonosító
Csomag funkciója
200
RR
201
SDES
202
BYE APP
203 204
„Sender Report” minőségi statisztikák az aktív küldőtől. „Receive Report” Minőségi statisztikák azon vevőktől, melyek nem végeznek adást. „Source DEScription items” Információk az adóról. Részvétel végét jelzi. Alkalmazás specifikus funkciók.
A fenti funkciók megvalósítása kötelező érvényű a multicast, és ajánlott minden más alkalmazás esetén. Az RTCP csomagok és az RTP jelfolyam multiplexelt. Általában az RTP a páros számú portot, míg az RTCP az eggyel magasabb számú páratlan portot használja. Az RTCP csomag felépítése a funkciójától függő, de a fejléc (header) formátuma minden csomag esetén azonos mezőket tartalmaz: V
P
RC PT Length (2 byte) Küldő SSRC-je (4 byte)
5.1-2. ábra. Az RTCP fejléc (Header) felépítése 153
Az RTCP Header első két bitje (V) a verzió számot hordozza, melynek egyeznie kell a jelfolyam átvitelére alkalmazott RTP verziószámával. A „P” bit, (Padding) jelzi, hogy a csomag payload helytöltő „padding” byteokat is tartalmaz. A PT mező (Payload Type) csomagtípus azonosítást végez, melynek lehetséges kódjait a fenti táblázatban foglaltuk össze. A csomag hosszát a „Length” mezőben (16 bit) kell megadni. A következő ábrán az SR csomagformátum látható: RTCP Header NTP időbélyeg RTP időbélyeg Küldő csomagszámlálója Küldő byte számlálója SSRC1 Fraction Elveszett csomagszám Lost (kumulatív) Legmagasabb vett sorszám Jitter LSR DLSR „Report Block n” … Profil specifikus bővítések
5.1-3. ábra. Az RTCP SR csomagformátum Az RTCP fejlécet az úgynevezett „Sender Info” mező (ábrán dupla keretezett mező) követi, mely négy egységből áll. A „Sender Info” mező után a „Report Block 1” következik. Egy SR csomag több Report blokkot is tartalmazhat. A Report blokkok számát a fejlécben (Header) található RC mező jelzi, ami egy 5 biten ábrázolt szám. A Report blokk első adategysége a forrás azonosító sorszáma (SSRC1). Ezután következik a „Fraction Lost” mező, melyben az elveszett töredékek számát tüntetik fel. A „Fraction Lost” mezőt követi az elveszett csomagok darabszámát rögzítő mező, ami komulatív szám. Az LSR mező - Last SR. A DLSR mező – Delay since last SR.
154
RTCP Header SSRC1 Fraction Elveszett csomagszám lost (kumulatív) Legmagasabb vett sorszám Jitter LSR DLSR „Report Block n” … Profil specifikus bővítések
5.1-4. ábra. Az RTCP RR csomagformátum
Az RTCP fejlécet az úgynevezett riport blokk 1 („Report Block 1”) követi. Az RR üzenet esetén a „Report Block” ugyanazon mezőket tartalmazza, mint azt az SR üzenetnél láttuk. Az RR-ben szintén több (maximum 31), egymást követő Report Block mező lehet. A mezők aktuális számát a Header RC mezőjében kell megadni.
155
5.2. H.323 A H.323 a csomagkapcsolt adathálózaton alkalmazható, OSI „session” rétegben működő kapcsolat felépítést és bontást megvalósító protokoll. Az eljárást az ITU-T definiálta (ITU-T H.323). A H.323 első változata 1996. novemberben jelent meg. A H.323 négy eszköztípust definiál, melyek a következők: •
H.323 Gateway (átjáró), mely átjárást biztosít, a VoIP hálózat és a PSTN, ISDN és a Mobil hálózat között. Alkalmazása opcionális.
•
H.323 Gatekeeper (zónavezérlő), mely feladata a címfordítás, sávszélesség vezérlés, hitelesítés.
•
H.323 Terminal (végberendezés), mely segítségével a VoIP szolgáltatás igénybe vehető.
•
H.323 Multipoint Control Unit (konferenciavezérlő). Segítségével több VoIP képes eszköz léphet kapcsolatba, vagyis konferenciacsatornát épít ki. Ez az eszköz nem feltétlenül része a VoIP hálózatnak.
A H.323-at protokoll családnak is szokták nevezni, hiszen az egy komplett rendszerben képes működni. A H.323 gyűjtemény legfontosabb elemei a H.225 és H.245. A hívásvezérlés a H.225-ben valósul meg (Call Control) és az üzenetek TCP/UDP csomagként haladnak át az IP hálózaton. A jelzésüzenetek felépítése az ISDN Q.931 jelzés-üzenetein (Digital subscriber Signaling System No. 1) alapulnak. A jegyzet írásakor a H.225.0 12/2009 ajánlás volt érvényben. A jelzésüzenetek felépítése a következő: Protocol discriminator (1 byte) 0000
Length of call ref. (4 bit) Call reference (1 vagy 2 byte)
0
Message Type (7 bit) Info. elements
5.2-1. ábra. Jelzésüzenet felépítése
156
A „Protocol Discriminator” mező szerepe a jelzésprotokoll-típus azonosítás. Jelen esetben ennek a mezőnek az értéke ’00001000’ (vagyis hexadecimálisan 0x08). A „Call reference” a Q.931 szerint 1 vagy 2 byte hosszúságú mező, de H.225 jelzésüzenet esetén ez mindig 2 byte. Ennek a mezőnek mindig a hívó oldal ad egy, a hívó oldalon egyedi azonosítót, mely az adott hívás teljes tartama alatt változatlan marad. A „Message Type” 7 bitből álló mező, mely mező azonosítja magát a jelzésüzenetet. A jelzésüzenetek négy csoportba sorolhatók, mely csoportok a következők: •
Hívást felépítő üzenetek (Call establishment);
•
Hívás információs fázis üzenetek (Call information phase);
•
Hívás bontó üzenetek (Call clearing);
•
Egyéb üzenetek.
A fontosabb hívásfelépítő üzenetek és bináris kódjaik a következők: ALERTING
(’000 0001’)
CALL PROCEEDING
(’000 0010’)
CONNECT
(’000 0111’)
CONNECT ACKNOWLEDGE
(’000 1111’)
PROGRESS
(’000 0011’)
SETUP
(’000 0101’)
SETUP ACKNOWLEDGE
(’000 1101’)
A fontosabb bontás üzenetek és bináris kódjaik a következők: DISCONNECT
(’100 0101’)
RELEASE
(’100 1101’)
RELEASE COMPLETE
(’101 1010 ’)
RESTART
(’100 0110’)
RESTART ACKNOWLEDGE
(’100 1110’)
Az „Info elements” mező az adott protokoll elem (jelzésüzenet) paramétereit tartalmazza, mely például lehet a hívó oldali, vagy hívott oldali azonosító, dátum, hordozó szolgálati információ stb. Ezen mezők értelmezését a Q.931 és H.225 ajánlások táblázatosan foglalják össze. Egy H.323 protokollon alapuló hívás felépítés és bontás folyamatát a következő ábra szemlélteti:
157
5.2-2. ábra. H.323 hívás felépítés és bontás folyamata33
33
Az ábra Lőcsei Péter szakdolgozatából származik
158
A hívásfelépítés első fázisában a „Hívó Terminál” úgynevezett RAS protokoll használatával (RAS ARQ és RAS AFC) regisztrálja magát a zónavezérlőnél.34 A sikeres regisztrációt követően a hívásfelépítés a H.225 Call Control üzenetekkel folytatódik. A hívó terminál SETUP üzenetet küld a hívott terminálnak. A SETUP üzenet tartalmazza a kezdeményező IP címét és a portszámot is (az ábrán nem látszik – mert az alsóbb rétegekkel most nem foglalkozunk, de ne felejtsük el, a SETUP üzenet TCP/UDP csomagként halad át az IP hálózaton). A hívott terminál a CALL PROCEEDING üzenettel válaszol. Ezzel fogadta el a bejövő hívást (de azt még nem válaszolta meg!). Természetesen a hívott terminálnak is be kell regisztrálnia magát a zónavezérlőbe (ez szintén RAS protokollal történik). Az ALERTING üzenet hatására a hívó terminál csengetés visszhangot hall. Abban az esetben, ha a hívott megválaszolja a hívást (pl. billentyű lenyomás, kézibeszélő beemelés), akkor azt a CONNECT üzenet fogja jelezni. A hívás megválaszolását követően jön az úgynevezett „vezérlés-jelzés”. A vezérlés-jelzés üzenetváltás H.245 protokollal történik, mely során a terminálok megállapodnak, hogy a kommunikáció során milyen kodeket (kóder-dekóder páros) fognak használni (természetesen itt a terminál képességeket is megküldik egymásnak), majd megnyitják a logikai csatornát (OLC – Open Logical Channel). A logikai csatorna megnyitását követően az RTP/RTCP segítségével megindulhat a hanginformációt szállító csomagok küldése. A hívásfolyamat itt is bontással zárul. Először bezárják a logikai csatornát (H.245), majd H.225 RELEASE, RELEASE COMPLETE üzenettel bontják a kapcsolatot. A kapcsolatbontást követően H.225 RAS üzenetekkel a terminálok lejelentkezhetnek a zónavezérlőről.
34
A RAS (Registration, Administration and Status) protokollról - mely a végberendezések, átjárók (Gateway) és zónavezérlők (Gatekeeper) protokollja - részletes információk a H.225 ajánlásban találhatók.
159
5.3. SIP – Session Initiation Protocol A SIP-et az IETF dolgozta ki és az RFC3261 ajánlásban foglalta össze. A SIP úgynevezett „text” alapú protokoll (hasonlóan, mint például a HTTP). A SIP feladata a H.323-hoz hasonló, hiszen IP alapú csomagkapcsolt hálózatokon lehet segítségével olyan kapcsolatokat felépíteni, melyeken multimédiás tartalmak továbbíthatók. A H.323 és a SIP egymással „vetélytársak”, jelenleg a SIP tűnik elterjedtebbnek, ami az egyszerűségének és nagyfokú rugalmasságának tudható be. A SIP az alkalmazási (application) rétegben, a szállítási réteg felett helyezkedik el, ezért attól független, de a gyakorlatban a SIP üzenetek továbbítása TCP/UDP-vel történik. A hívásfelépítést követően a valós idejű adatok átvitele természetesen RTP/RTCP-vel megy végbe, hiszen ennek már nincs köze a jelzésátvitelhez. A SIP öt eszköztípust definiál, melyek a következők: •
SIP Proxy szerver, melynek szerepe a „kliens” és „szerver” ügyfél közötti jelzésváltások átvitelénél van. Feladata az, hogy megkeresse a célfelhasználóhoz legközelebb eső szervert, továbbá a hitelesítés és a házirend definiálása is.
•
SIP redirect szerver, mely átirányító funkcióval rendelkezik. A kérések célcíme alapján (ha az szükséges) új célcímet határoz meg és azt visszaküldi az ügyfélnek. A Proxy számára más tartományok is ismertté válnak.
•
SIP registrar szerver, melynek feladata a tartományon belüli kliensek adatainak tárolása, vagyis domain-en belül adatbázis szerverként működik.
•
SIP user agent (UA), mely eszközök csoportja alkotja a felhasználói végberendezéseket (SIP-VoIP telefon, PDA, laptop stb.).
•
SIP gateway, mely eszköz átjárást biztosíthat más hálózatok felé. Feladata a jelzés, és átviteli konverziók végrehajtása.
A fent felsorolt elemek (elsősorban a szerveralkalmazások) akár ugyanazon a fizikai eszközön (szerver számítógép, router) is működhetnek.
A SIP jelzésüzeneteket két csoportba sorolhatjuk:
160
•
Kérések (request);
•
Válaszok (response).
Mindkét jelzésüzenet típus úgynevezett „start-line”-nal (kezdő sorral) kezdődik, melyet egy, vagy több „header” mező követ. A „header” (fejléc) mező végét egy üres sor jelzi. Az üres sorban két vezérlő karakter található (CR – kocsi vissza; LF - soremelés). Ezen felül minden sort (start-line és message header line) a CR és az LF vezérlőkaraktereknek kell zárnia. A „header” mezőt opcionálisan egy üzenet törzs (message-body) követheti. generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line
Request típusú üzenetek REGISTER
- A „jelenlévő” felhasználók ezzel az üzenettel regisztrálhatnak a szerverre.
INVITE
- Kapcsolat kezdeményezésre, és élő kapcsolat paramétereinek módosítására szolgáló üzenet.
ACK
- Nyugtázó üzenet.
OPTIONS
- A szerver nyújtotta szolgáltatásokról tájékoztatja a kapcsolatban résztvevő feleket.
CANCEL
- A teljesítetlen kérések kiszolgálását megakadályozó üzenet.
BYE
- Hívásbontást kezdeményező jelző üzenet.
Response típusú üzenetek A „response” üzeneteket három számjegyből álló státuszkód adja, a HTTP-hez hasonló módon. Az első karakter alapján a válaszüzenetek csoportosítottak, úgynevezett válasz osztályba (response-class) rendezettek, melyek a következők: 1XX
- A küldött kérelem kiszolgálásának állapotáról ad információt.
2XX
- A kérés elfogadásáról tájékoztatja a címzettet.
3XX
- Ez a válasz azt jelzi, hogy a kérelem végrehajtásához további teendők szükségesek.
4XX
- Kliens oldali hibákról ad tájékoztatást.
5XX
- Szerver oldali hibákról tájékoztatást adó üzenet.
6XX
- Általános jellegű hibák jelzésére szolgál.
Egy SIP protokollon alapuló hívás felépítés és bontás folyamatát a következő ábra szemlélteti:
161
5.3-1. ábra. SIP hívás felépítés és bontás folyamata35 A fenti ábrán az „A” végberendezés egy INVITE üzenettel jelzi a szervernek, hogy hívást kíván kezdeményezni. A proxy szerver a példa szerint 407 üzenettel visszajelzi a hitelesítési igényt, melyet a végberendezés egy ACK elküldésével nyugtáz. Az ACK küldését követően az „A” végberendezés egy újabb INVITE üzenetet küld, melyben szerepelnek a hitelesítési adatok is (és természetesen a „B” végberendezés (UA) címe is). Erre a proxy egy TRYING üzenetet küld visszaigazolásképpen, miszerint megpróbálja „B” UA-t elérni, ugyanekkor a proxy egy INVITE üzenet küldéssel próbálja „B” UA-t elérni. A kicsengésről a hívó („A” UA) a 180 (RINGING) válasz alapján értesül. A 200 kódú válasz (OK) jelzi, hogy a „B” UA elfogadta a szerver meghívást, melyet a proxy egy ACK-val nyugtáz.
35
Az ábra Lőcsei Péter szakdolgozatából származik
162
A hívás tényleges megválaszolását a 200 (OK) fogja jelenteni, mely után felépül az RTP/RTCP csatorna és megkezdődik a beszédmintákat szállító csomagok átvitele a végpontok között. A beszédkapcsolat bontását a példa szerint a hívó („A” UA) kezdeményezi, és ezt a BYE üzenet küldésével jelzi.
163
6. Összegzés Kedves Olvasó! Remélem a jegyzet olvasása során sikerült áttekintő képet szerezni az informatikai hálózatokról és azok működésének alapjairól. Reménykedem továbbá abban, hogy a könyv elolvasását követően az olvasóban több ponton hiányérzet jelent meg, valamint sok kérdés fogalmazódott meg. Abban az esetben, ha ez így van, akkor a hiba nem az Olvasóban van, hiszen a jegyzet nem beszélt arról, hogy miként valósul meg egy áramkörkapcsolás, vagy egy IP kapcsolás, inkább csak arról, hogy mi alapján jöhet létre az. Sok felsőbb rétegbeli alkalmazásról sem esett szó. A könyvben bemutatott adatátviteli eljárásokat sok esetben leegyszerűsítettem, vagy egy lehetséges példán mutattam be annak működését. Természetesen az így bemutatott protokoll megadás nem lehet teljeskörű, ezt a jegyzet terjedelme sem tette lehetővé. Minden ismertetett protokollnál igyekeztem megadni azokat a referenciákat (RFC-k, ITU-T, ETSI és IEEE ajánlások), melyek a teljes protokoll definíciókat tartalmazzák. Ezek a leírások gyakran több száz oldalasak és nem túl olvasmányosak, de segítségükkel minden részletkérdésre magyarázatot kaphatunk.
A jegyzettel kapcsolatban bármilyen észrevételt, és kritikát a
[email protected] e-mail címen örömmel fogadok, és ezek alapján igyekszem legjobb tudásom szerint hasznosabbá tenni ezt a jegyzetet.
Végezetül a Kedves Olvasónak szeretnék köszönetet mondani a kitartó munkáért, és eredményes további tanulást kívánok!
164
7. Mellékletek 7.1. OSI referenciamodell Az OSI (Open System Interconnection) referencia modell hét hierarchikus réteget határoz meg, és a hálózati megoldások funkcióit igyekszik szétválasztani. A rétegmodell kialakítása 1978-ban
kezdődött
és
az
ISO
( International
Organization
for
Standardization) hozta létre. A modell egy folyamatos fejlődésen esett át és az ITU is rögzítette azt. Az ITU-T X.200 sorozatú ajánlásban a teljes OSI referenciamodell összes részletét megtaláljuk (ITU honlapról szabadon letölthető). A hét réteg egymásra épül és csakis szomszédos rétegek kommunikálnak egymással. Az egyes rétegeket és azok elnevezését a következő ábra szemlélteti:
7.1-1. ábra. A hét rétegű OSI referenciamodell szerint kapcsolódó eszközök36 A fenti ábrán két eszköz kapcsolódását láthatjuk, ami az átviteli közegen „Physical media”- n keresztül és az eszközök fizikai interfészén valósulhat meg. A fizikai interfész elektromos paramétereit az úgynevezett Fizikai réteg (Physical Layer) definiálja. A fizikai réteg meghatározza azt az átviteltechnikai eljárást is, mely segítségével a logikai ’1’ és ’0’ sorozatok az adott fizikai közegen átvihetők. Az átviteltechnikai eljárások lehetnek modulációs és demodulációs eljárások, vonali kódolások. A fizikai rétegben kell megvalósítani az órajel szinkronizációt is. 36
Az ábra az ITU-T X.200 ajánlásból származik
165
Még mielőtt továbblépnénk a többi réteg, és azok funkcióinak tárgyalására, fontos megemlíteni, hogy a 7.1.-1. ábrán a „Peer protocol” jelzésű nyilak az egyes rétegek virtuális kapcsolatát jelzik! A tényleges kommunikáció minden esetben a fizikai rétegen keresztül történik, hiszen ha azt ki lehetne hagyni, akkor annak definiálása értelmetlen lenne.
A második réteg az úgynevezett adatkapcsolati réteg (data link layer). Az adatkapcsolati rétegnek az elsődleges feladata az, hogy az „ömlesztett” ’1’ és ’0’ halmazból rendszerezett adategységeket formáljon, vagyis létrehozza a keretszervezést. A keret szinkronizálás folyamata erősen összefügg a fizikai réteggel, az egyes szimbólumok és bitek szinkronizálásával, ezért sokszor ez a két réteg nehezen, vagy egyáltalán nem szétválasztható. Az IEEE 802.x ajánlások a fenti okból az adatkapcsolati és a fizikai réteget tartalmazzák, azok egymástól elválaszthatatlanok. Az adatkapcsolati rétegnek további feladata a hiba felfedés (például paritásvizsgálat, vagy CRC ellenőrzés), de a hibajavítás is szóba jöhet (FEC – Forward Error Correction kód alkalmazással, vagy úgynevezett kézfogásos módszerrel a második réteg képes újrakérni, illetve újraküldeni a hibás keretet). Szintén az adatkapcsolati rétegben szokás megvalósítani a közeg hozzáférési (média hozzáférés) eljárást is, például CSMA/CD, CSMA/CA, vezérjeles megoldások stb. A média hozzáférés részét képezik a fizikai azonosítók kezelése is. A fizikai cím (például MAC address), - ami elméletben teljesen egyedi - a második rétegben tárolódik és értelmeződik.
A harmadik réteg az úgynevezett hálózati réteg (network layer). Ennek a rétegnek a feladata, hogy biztosítsa a csomagok célállomáshoz érkezését. Az útvonal meghatározás történhet statikus táblák segítségével, de az útvonal választás lehet dinamikus is. A statikus irányító táblák lehetnek fixen konfiguráltak, de feltöltésük történhet a kapcsolat felépítési eljárás során is. A dinamikus útvonal-választást a hálózat mindenkori állapota (például a pillanatnyi terhelése) határozza meg. A hálózati torlódások szabályozása és a szolgáltatásminőséggel (QoS – Quality of Service) kapcsolatos paraméterek (csomagvesztések aránya, késleltetési idők, késleltetési idők ingadozása) kézbentartása is a harmadik réteg feladata.
166
A negyedik réteg az úgynevezett szállítási réteg (transport layer). A szállítási réteg elsődleges feladata, hogy a viszonyrétegtől érkező adatokat feldarabolja (ha az egyébként szükséges), valamint a hálózati rétegtől érkező „darabokat”, csomag tartalmakat összeillessze és a viszony réteg felé továbbítsa. A szállítási réteg feladata továbbá az, hogy biztosítsa a teljes hibamentességet, természetesen akkor, ha ez követelmény (nem minden esetben a legfontosabb dolog az adatok hibamentessége!). Fontos feladat lehet a csomagsorrend helyreállítása, az is itt valósulhat meg. A szállítási réteget szokták egy „igazi végpontok közötti rétegnek” is nevezni, hiszen ezen réteg (és e felettiek is) a cél- és a forrásgépen valósul meg, a hálózat építőelemein nem.
7.1-2. ábra. A hét rétegű OSI referenciamodell szerint kapcsolódó eszközök, hálózati építőelem (például router) közbeiktatásával37 Az ötödik réteg az úgynevezett viszony réteg (session layer). A viszony réteg segítségével a végpontokon található, egymással kommunikáló számítógépek úgynevezett „viszonyt” építenek ki egymás között. A viszonyba beletartozik az, hogy egy kommunikáció full-duplex, fél-duplex vagy szimplex. Ennek a rétegnek a segítségével építhetők be úgynevezett ellenőrzési pontok a kommunikációba.
A hatodik réteg az úgynevezett megjelenítési réteg (presentation layer).
37
Az ábra az ITU-T X.200 ajánlásból származik
167
A megjelenítési réteg feladata az, hogy a különböző adatábrázolást használó számítógépek kommunikációját tegye lehetővé. Ez a réteg úgynevezett absztrakt adatszerkezetekkel foglalkozik, például ASCII kódolás, ASN.1 (Abstract Syntax Notation one), XML (Extensible Markup Language) adatstruktúrák stb.
A hetedik réteg az úgynevezett alkalmazási réteg (application layer), olyan protokollok gyűjteményét tartalmazza, amelyek a felhasználókhoz a legközelebb állnak.
Adategység
A réteg neve:
A réteg fontosabb funkciói:
elnevezése az adott rétegben Alkalmazási réteg
Felhasználókhoz közel álló
adat
(Application layer)
protokollok gyűjteménye
(Data)
Megjelenítési réteg
Absztrakt adatábrázolási
(Presentation layer)
szerkezetek létrehozása, illetve azok értelmezése
Viszony réteg
A viszony meghatározása a
(Session layer)
kommunikáció során, valamint ellenőrzési pontok beépítése a kommunikációba.
szegmens
Szállítási réteg (Transport layer) Hálózati réteg
csomag
(Network layer) Adatkapcsolati réteg
keret
(Data link layer)
Adatok tördelése, illetve újraegyesítése Logikai címzés, útvonal választás a csomagok számára. Keretszervezés, hiba felfedés, esetleg javítás, közeghozzáférés vezérlés, fizikai címzés.
Fizikai réteg bit
168
(Physical layer)
Bitek szállítása a fizikai médiumon, órajel szinkron.
7.2. Számrendszerek áttekintése A számrendszerek és az átváltás az egyes számrendszerek között nem informatikai kérdés, de az egyes informatikai kifejezések teljesen érthetetlenek bizonyos számrendszerek ismerete nélkül. Ezen okból úgy gondolom, itt a mellékletben néhány számrendszer áttekintése „megér egy misét”. Az áttekintés korántsem teljes értékű! A tízes számrendszer használata triviális, hiszen ovis korunkban az ujjaink számolgatásával tanultunk számolni és többnyire a két kezünkön 10 db ujj található. Az egyes helyértékek a következők (10 hatványai szerint értelmezhetők): Helyértékek alakulása a 10-es számrendszer esetén …..stb
1000
100
10
1
Ezután már csak azt kell „megmondani”, hogy az egyes helyértékeknek megfelelő számból hány darab szerepel az adott számban. Például az 542-ben 5db százas, 4 db tízes és 2 db egyes szerepel, vagyis a számértéket megkapjuk, hogyha a következőt kiszámoljuk: 5 ⋅ 100 + 4 ⋅ 10 + 2 ⋅ 1 = 542 A kettes számrendszer esetén a helyértékek 2 hatványai szerint értelmezettek: Helyértékek alakulása a 2-es számrendszer esetén …..stb
8
4
2
1
Az előbb említett 542-es decimális számmal megegyező kettes számrendszerben ábrázolt szám: 1000011110, vagyis van 1 db 512-es számunk, 1 db 16-os, 1 db 8-as, 1 db 4-es és 1 db 2-es. A többi helyértéken nulla szerepel. Abban az esetben, ha kiszámoljuk a következő összefüggést, akkor a decimális 542 számhoz jutunk: 1 ⋅ 512 + 0 ⋅ 256 + 0 ⋅ 128 + 0 ⋅ 64 + 0 ⋅ 32 + 1 ⋅ 16 + 1 ⋅ 8 + 1 ⋅ 4 + 1 ⋅ 2 + 0 ⋅ 1 = 542
A tizenhatos (hexadecimális) számrendszer nagyon hatékonyan és kifejezően ábrázolja a 4 biten eltárolható információt. A szokatlan mindössze csak annyi lehet, hogy az egyes helyértékeken előforduló „darabszám” 0 - 15 közé eshet. 0 – 9 tartományban
semmi
gondunk,
hiszen
itt
nyugodtan
használhatjuk
a
tízes
számrendszerben alkalmazott számkaraktereket, de ha valamiből már 10 db-unk van, akkor ezt az „A” vagy „a” karakterrel helyettesítjük. 11 esetén a „B”-t, 12 esetén a „C”-
169
t, 13 esetén a „D”-t, 14 esetén az „E”-t és a 15 esetén az „F” karaktert használjuk az ábrázoláshoz. Helyértékek alakulása a 16-os számrendszer esetén …..stb
4096
256
16
1
A fenti táblázat értelmében a 16-os számrendszerben a helyértékek a 16 hatványai szerint értelmezettek. Az előző példákban előforduló decimális 542 hexadecimális formában 11E. A hexadecimális számokat (vagyis az ábrázolás formátumát) többféleképpen szoktuk jelölni. Az egyik jelölés mód szerint a szám után írunk egy „h” vagy „H” karaktert, így 11Eh-t kapunk, de gyakori a „0x” prefix használata is, miszerint 0x11e a konvertált eredmény. Egyértelmű konvenciók esetén (például MAC cím, vagy IPv6 cím esetén) sem a „h”, sem pedig a „0x” jelet nem alkalmazzuk. Meg kell említenünk azt, hogy az egyes helyértékek nemcsak a számrendszer alapszámának egész kitevőjű hatványa szerinti lehet megadni, hanem lehetőség van törtszámok ábrázolására is. Természetesen az előjeles számok ábrázolására is vannak nagyszerű módszerek, de ez utóbbiakat inkább a digitális jelfeldolgozás terén szokás alkalmazni, ezért erre itt nem térünk ki.
170
7.3. Az IP fejléc „Protocol” mező értékei és jelentése Az IP fejlécben (IP Header) található „Protocol” mező azonosítja azt, hogy az IP csomag milyen protokoll szerinti datagrammot hordoz. Ez a 8 bites mező 0 – 255 között vehet fel értékeket. Az egyes értékek és jelentése (RFC1700 szerint) a következő:
„Protocol” mező értéke (decimális): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
Protokoll típusa
Fenntartott ICMP Internet Control Message IGMP Internet Group Management GGP Gateway-to-Gateway enkapszuláció ST Stream TCP Transmission Control UCL EGP Exterior Gateway Protocol IGP any private interior gateway BBN-RCC-MON BBN RCC Monitoring NVP-II Network Voice Protocol PUP ARGUS EMCON XNET Cross Net Debugger CHAOS UDP User Datagram MUX Multiplexing DCN-MEAS DCN Measurement Subsystems HMP Host Monitoring PRM Packet Radio Measurement XNS-IDP XEROX NS IDP TRUNK-1 TRUNK-2 LEAF-1 LEAF-2 RDP Reliable Data Protocol IRTP Internet Reliable Transaction ISO-TP4 ISO Transport Protocol Class 4 NETBLT Bulk Data Transfer Protocol MFE-NSP MFE Network Services Protocol MERIT-INP MERIT Internodal Protocol SEP Sequential Exchange Protocol 3PC Third Party Connect Protocol IDPR Inter-Domain Policy Routing Protocol XTP DDP Datagram Delivery Protocol
Protokollra vonatkozó ajánlás:
RFC792 RFC1112 RFC823 RFC1190,IEN119 RFC793 RFC888
RFC741
IEN158 RFC768
RFC869
RFC908 RFC938 RFC905 RFC969
171
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 - 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 172
IDPR-CMTP IDPR Control Message Transport Protocol TP++ TP++ Transport Protocol IL Transport Protocol SIP Simple Internet Protocol SDRP Source Demand Routing Protocol SIP-SR SIP Source Route SIP-FRAG SIP Fragment IDRP Inter-Domain Routing Protocol RSVP Reservation Protocol GRE General Routing Encapsulation MHRP Mobile Host Routing Protocol BNA SIPP-ESP SIPP Encap Security Payload SIPP-AH SIPP Authentication Header I-NLSP Integrated Net Layer Security SWIPE IP with Encryption NHRP NBMA Next Hop Resolution Protocol Ezt a tartományt protokollhoz nem rendelték any host internal protocol CFTP any local network SAT-EXPAK SATNET and Backroom EXPAK KRYPTOLAN RVD MIT Remote Virtual Disk Protocol IPPC Internet Pluribus Packet Core any distributed file system SAT-MON SATNET Monitoring VISA Protocol IPCV Internet Packet Core Utility CPNX Computer Protocol Network Executive CPHB Computer Protocol Heart Beat WSN Wang Span Network PVP Packet Video Protocol BR-SAT-MON Backroom SATNET Monitoring SUN-ND SUN ND PROTOCOL-Temporary WB-MON WIDEBAND Monitoring WB-EXPAK WIDEBAND EXPAK ISO-IP ISO Internet Protocol VMTP SECURE-VMTP VINES TTP NSFNET-IGP DGP Dissimilar Gateway Protocol TCF IGRP RFC1583 OSPFIGP
90 91 92 93 94 95 96 97 98 99 100 101 - 254 255
Sprite RPC Protocol LARP Locus Address Resolution Protocol MTP Multicast Transport Protocol AX.25 IPIP IP-within-IP Encapsulation Protocol MICP Mobile Internetworking Control Pro. SCC-SP Semaphore Communications Sec. Pro. ETHERIP Ethernet-within-IP Encapsulation ENCAP Encapsulation Header any private encryption scheme GMTP Ezt a tartományt protokollhoz nem rendelték Fenntartott
RFC1241
A fent felsorolt protokollok számos olyat találunk, melyek valamely vállalat egyedi megoldásához tartozik, és RFC ajánlás nem rögzíti azt.
173
7.4. ICMP üzenetek Az ICMP (Internet Control Message Protocol) néhány üzenetét az alábbi táblázat adja meg. A teljes üzenet készlet, valamint azok értelmezése az Interneten szabadon letölthető RFC79238 ajánlásból ismerhető meg.
„Type” mező
„Code”
értéke
mező értéke 0
0
1 és 2
ICMP üzenet leírása
Echo Reply További fejlesztésre fenntartott
0
Destination network unreachable
1
Destination host unreachable
2
Destination protocol unreachable
3
Destination port unreachable
4
Fragmentation required
3
5
Source route failed
„A cél
6
Destination network unknown
elérhetetlen”
7
Destination host unknown
8
Source host isolated
9
Network administratively prohibited
10
Host administratively prohibited
11
Network unreachable for TOS
12
Host unreachable for TOS
13
Communication administratively prohibited
…
…
…
13
0
Timestamp
13
0
Timestamp reply
…
…
…
42 - 255
38
www.ietf.org/rfc
174
További fejlesztésre fenntartott
7.5. TCP és UDP Portszámok táblázata A TCP és az UDP port azonosítók a végpontokon futó alkalmazások azonosítására szolgálnak. A port számot 16 biten ábrázoljuk. A 0 – 1023 tartományba az úgynevezett jól ismert portok („well-known ports”) találhatók, melyeket a lenti táblázatban meg is adunk. Az 1024 – 49151 tartományba az úgynevezett regisztrált portok („Registered ports”) találhatók. A 49152 – 65535 számtartományba az úgynevezett dinamikus, vagy privát portok kerülhetnek. Port
TCP
0
TCP
0
UDP
Végpont alkalmazás Shirt Pocket software (netTunes, launchTunes)
UDP
Fenntartott
1
TCP
UDP
TCP Port Service Multiplexer
2
TCP
UDP
Management Utility
3
TCP
UDP
Compression Process
4
TCP
UDP
Unassigned
5
TCP
UDP
Remote Job Entry
6
TCP
UDP
Alkalmazáshoz nem rendelt
7
TCP
UDP
Echo
8
TCP
UDP
Alkalmazáshoz nem rendelt
9
TCP
UDP
Discard
10
TCP
UDP
Alkalmazáshoz nem rendelt
11
TCP
UDP
Active Users
12
TCP
UDP
Alkalmazáshoz nem rendelt
13
TCP
UDP
DAYTIME – (RFC 867)
14
TCP
UDP
Alkalmazáshoz nem rendelt
16
TCP
UDP
Alkalmazáshoz nem rendelt
17
TCP
UDP
Quote of the Day
18
TCP
UDP
Message Send Protocol
19
TCP
UDP
Character Generator
20
TCP
21
TCP
22
TCP
23
TCP
24
TCP
25
TCP
34
TCP
UDP
Remote File (RF)— gépek közti fájl traszferre használatos
35
TCP
UDP
Bármely privát printer szerver protokoll
37
TCP
UDP
TIME protokoll
39
TCP
UDP
Resource Location Protocol (RLP)
41
TCP
UDP
Graphics
42
TCP
UDP
nameserver, ARPA Host Name Server Protocol
42
TCP
UDP
WINS
FTP – data transfer FTP – control (command) UDP
Secure Shell (SSH)— secure login-hez használt, file transzferek (scp,sftp) és port forwarding Telnet protokoll— titkosítattlan text kommunikáció
UDP
Priv-mail : bármely privát levelező rendszer Simple Mail Transfer Protocol (SMTP)
175
43
TCP
WHOIS protocol
47
TCP
GRE protocol
49
TCP
UDP
TACACS Login Host protocol
50
TCP
UDP
Encapsulating Security Payload (ESP)
51
TCP
UDP
Authentication Header (AH)
52
TCP
UDP
XNS (Xerox Network Systems) Time Protocol
53
TCP
UDP
Domain Name System (DNS)
54
TCP
UDP
XNS (Xerox Network Systems) Clearinghouse
55
TCP
UDP
ISI Graphics Language (ISI-GL)
56
TCP
UDP
XNS (Xerox Network Systems) Authentication
56
TCP
UDP
Route Access Protocol (RAP)
57
TCP
58
TCP
UDP
XNS (Xerox Network Systems) Mail
67
UDP
Bootstrap Protocol (BOOTP) Server; also used by Dynamic Host Configuration Protocol (DHCP)
68
UDP
Bootstrap Protocol (BOOTP) Client; also used by Dynamic Host Configuration Protocol (DHCP)
69
UDP
Trivial File Transfer Protocol (TFTP)
70
TCP
Gopher protocol
79
TCP
Finger protocol
80
TCP
81
TCP
82
UDP
Hypertext Transfer Protocol (HTTP) Torpark—Onion routing
UDP
Torpark—Control
83
TCP
88
TCP
UDP
Kerberos—authentication system
90
TCP
UDP
dnsix (DoD Network Security for Information Exchange) Securit Attribute Token Map
90
TCP
UDP
Pointcast
MIT ML Device
99
TCP
WIP Message Protocol
101
TCP
NIC host name
102
TCP
104
TCP
UDP
ACR/NEMA Digital Imaging and Communications in Medicine
105
TCP
UDP
CCSO Nameserver Protocol (Qi/Ph)
107
TCP
108
TCP
109
TCP
110
TCP
111
TCP
113
TCP
113
TCP
115
TCP
Simple File Transfer Protocol (SFTP)
117
TCP
UUCP Path Service
118
TCP
119
TCP
123
176
Mail Transfer Protocol (MTP)
ISO-TSAP (Transport Service Access Point) Class 0 protocol
Remote TELNET Service protocol UDP
SNA Gateway Access Server Post Office Protocol 2 (POP2) Post Office Protocol 3 (POP3)
UDP
ONC RPC (SunRPC) ident—user identification system, used by IRC servers to identify users
UDP
UDP
Authentication Service (auth)
SQL (Structured Query Language) Services Network News Transfer Protocol (NNTP)—used for retrieving newsgroup messages
UDP
Network Time Protocol (NTP)—used for time synchronization
135
TCP
UDP
DCE endpoint resolution
135
TCP
UDP
Microsoft EPMAP (End Point Mapper)
137
TCP
UDP
NetBIOS NetBIOS Name Service
138
TCP
UDP
NetBIOS NetBIOS Datagram Service
139
TCP
UDP
NetBIOS NetBIOS Session Service
143
TCP
UDP
Internet Message Access Protocol (IMAP)
152
TCP
UDP
Background File Transfer Program (BFTP)
153
TCP
UDP
SGMP, Simple Gateway Monitoring Protocol
156
TCP
UDP
SQL Service
158
TCP
161
UDP
DMSP, Distributed Mail Service Protocol
UDP
Simple Network Management Protocol (SNMP)
UDP
Simple Network Management Protocol Trap (SNMPTRAP)
162
TCP
170
TCP
177
TCP
179
TCP
194
TCP
UDP
IRC (Internet Relay Chat)
199
TCP
UDP
SMUX, SNMP Unix Multiplexer
201
TCP
UDP
AppleTalk Routing Maintenance
209
TCP
UDP
The Quick Mail Transfer Protocol
210
TCP
UDP
ANSI Z39.50
213
TCP
UDP
Internetwork Packet Exchange (IPX)
218
TCP
UDP
Message posting protocol (MPP)
220
TCP
UDP
Internet Message Access Protocol (IMAP), version 3
256
TCP
UDP
2DEV "2SP" Port
259
TCP
UDP
ESRO, Efficient Short Remote Operations
264
TCP
UDP
BGMP, Border Gateway Multicast Protocol
308
TCP
Novastor Online Backup
311
TCP
Mac OS X Server Admin (officially AppleShare IP Web administration)
318
TCP
319 320
Print-srv, Network PostScript UDP
X Display Manager Control Protocol (XDMCP) BGP (Border Gateway Protocol)
UDP
PKIX TSP, Time Stamp Protocol
UDP
Precision time protocol event messages
UDP
Precision time protocol general messages
323
TCP
UDP
IMMP, Internet Message Mapping Protocol
350
TCP
UDP
MATIP-Type A, Mapping of Airline Traffic over Internet Protocol
351
TCP
UDP
MATIP-Type B, Mapping of Airline Traffic over Internet Protocol
366
TCP
UDP
ODMR, On-Demand Mail Relay
369
TCP
UDP
Rpc2portmap
370
TCP
UDP
codaauth2 – Coda authentication server securecast1 – Outgoing packets to NAI's servers,http://www.nai.com/asp_set/anti_virus/alerts/faq.as
370
TCP
UDP
371
TCP
UDP
ClearCase albd
383
TCP
UDP
HP data alarm manager
384
TCP
UDP
A Remote Network Server System
387
TCP
UDP
AURP, AppleTalk Update-based Routing Protocol
389
TCP
UDP
Lightweight Directory Access Protocol (LDAP)
401
TCP
UDP
UPS Uninterruptible Power Supply
402
TCP
Altiris, Altiris Deployment Client
411
TCP
Direct Connect Hub
412
TCP
427
TCP
443
TCP
444
TCP
445
TCP
445
TCP
464
TCP
465
TCP
Cisco protocol
465
TCP
SMTP over SSL
475
TCP
tcpnethaspsrv (Aladdin Knowledge Systems Hasp services, TCP/IP version)
Direct Connect Client-to-Client UDP
Service Location Protocol (SLP) HTTPS (Hypertext Transfer Protocol over SSL/TLS)
UDP
SNPP, Simple Network Paging Protocol (RFC 1568) Microsoft-DS Active Directory, Windows shares Microsoft-DS SMB file sharing
UDP
Kerberos Change/Set password
177
497
TCP
500
_
501
TCP
502
TCP
UDP
Modbus, Protocol
504
TCP
UDP
Citadel – multiservice protocol for dedicated clients for the Citadel groupware system
510
TCP
512
TCP
512 513
515
Rexec, Remote Process Execution comsat, together with biff rlogin UDP
TCP
Who Shell (Remote Shell, rsh, remsh)
UDP TCP
Syslog—used for system logging Line Printer Daemon—print service
517
UDP
Talk
518
UDP
NTalk
UDP
Routing Information Protocol (RIP)
UDP
NetWare Core Protocol (NCP) is used for a variety things such as access to primary NetWare server resources, Time Synchronization, etc.
UDP
Timed, Timeserver
520
TCP
520 524
TCP
525
efs, extended file name server
530
TCP
UDP
RPC
531
TCP
UDP
AOL Instant Messenger, IRC
532
TCP UDP
netwall, For Emergency Broadcasts
533
netnews
540
TCP
542
TCP
543
TCP
klogin, Kerberos login
544
TCP
kshell, Kerberos Remote shell
545
TCP
546
TCP
UDP
547
TCP
UDP
548
TCP
550 554
TCP
556
TCP
560 561
UUCP (Unix-to-Unix Copy Protocol) UDP
commerce (Commerce Applications)
OSIsoft PI (VMS), OSISoft PI Server Client Access DHCPv6 client DHCPv6 server Apple Filing Protocol (AFP) over TCP UDP
new-rwho, new-who
UDP
Real Time Streaming Protocol (RTSP)
UDP
rmonitor, Remote Monitor
Remotefs, RFS, rfs_server
UDP
monitor
UDP
NNTP protocol over TLS/SSL (NNTPS)
563
TCP
587
TCP
e-mail message submission (SMTP)
591
TCP
FileMaker 6.0 (and later) Web Sharing (HTTP Alternate, also see port 80)
593
TCP
604
TCP
623
178
First Class Protocol
TCP
514
Internet Security Association and Key Management Protocol(ISAKMP) STMF, Simple Transportation Management Framework – DOT NTCIP 1101
UDP
513 514
Dantz Retrospect UDP
UDP
HTTP RPC Ep Map, Remote procedure call over Hypertext Transfer Protocol TUNNEL profile, a protocol for BEEP peers to form anapplication layer tunnel
UDP
ASF Remote Management and Control Protocol (ASF-RMCP)
631
TCP
UDP
Internet Printing Protocol (IPP)
636
TCP
UDP
Lightweight Directory Access Protocol over TLS/SSL (LDAPS)
639
TCP
UDP
MSDP, Multicast Source Discovery Protocol
641
TCP
UDP
SupportSoft Nexus Remote Command (control/listening): A proxy gateway connecting remote control traffic
646
TCP
UDP
LDP, Label Distribution Protocol, a routing protocol used in MPLSnetworks
647
TCP
DHCP Failover protokoll
648
TCP
RRP (Registry Registrar Protocol)
652
TCP
653
TCP
654
TCP
657
TCP
660
TCP
Mac OS X Server administration
665
TCP
sun-dr, Remote Dynamic Reconfiguration
666
DTCP (Dynamic Tunnel Configuration Protocol) UDP
SupportSoft Nexus Remote Command (data): A proxy gateway connecting remote control traffic Media Management System (MMS) Media Management Protocol (MMP)
UDP
UDP
IBM RMC (Remote monitoring and Control) protokoll
Doom, first online first-person shooter
674
TCP
ACAP (Application Configuration Access Protocol)
691
TCP
MS Exchange Routing
692
TCP
694
TCP
695
TCP
698 699
Hyperwave-ISP UDP
Linux-HA High availability Heartbeat IEEE-MMS-SSL (IEEE Media Management System over SSL)
UDP
OLSR (Optimized Link State Routing)
TCP
Access Network
700
TCP
EPP (Extensible Provisioning Protocol), a protocol for communication between domain name registries and registrars(RFC 5734)
701
TCP
LMP (Link Management Protocol (Internet)), a protocol that runs between a pair of nodes and is used to manage traffic engineering(TE)
702
TCP
IRIS (Internet Registry Information Service) over BEEP(Blocks Extensible Exchange Protocol) (RFC 3983)
706
TCP
Secure Internet Live Conferencing (SILC)
711
TCP
Cisco Tag Distribution Protocol—being replaced by theMPLS Label Distribution Protocol
712
TCP
Topology Broadcast based on Reverse-Path Forwarding routing protocol (TBRPF) (RFC 3684)
712
UDP
720
TCP
749
TCP
750
TCP
Promise RAID Controller SMQP, Simple Message Queue Protocol
UDP
Kerberos (protocol) administration rfile
750
UDP
loadav
750
UDP
kerberos-iv, Kerberos version IV
751
TCP
UDP
pump
751
TCP
UDP
kerberos_master, Kerberos authentication
752
TCP
752 752 753
qrh UDP
qrh
UDP
passwd_server, Kerberos Password (kpasswd) server
UDP
Reverse Routing Header (rrh)
UDP
userreg_server, Kerberos userreg server
TCP
753 753 754
TCP
754
TCP
754
Reverse Routing Header (rrh)
tell send krb5_prop, Kerberos v5 slave propagation UDP
tell send
760
TCP
UDP
ns
760
TCP
UDP
krbupdate [kreg], Kerberos registration
782
TCP
Conserver serial-console management server
783
TCP
SpamAssassin spamd daemon
829
TCP
CMP (Certificate Management Protocol)
843
TCP
Adobe Flash socket policy server
860
TCP
iSCSI (RFC 3720)
873
TCP
rsync file synchronisation protocol
888
TCP
cddbp, CD DataBase (CDDB) protocol (CDDBP)—unassigned but widespread use
901
TCP
Samba Web Administration Tool (SWAT)
901
TCP
UDP
VMware Virtual Infrastructure Client (UDP from server being managed to management console)
179
180
902
TCP
ideafarm-door 902/tcp self documenting Door: send 0x00 for info
902
TCP
VMware Server Console (TCP from management console to server being Managed)
902
UDP
ideafarm-door
902
UDP
VMware Server Console (UDP from server being managed to management console)
903
TCP
VMware Remote Console
904
TCP
VMware Server Alternate (if 902 is in use, i.e. SUSE linux)
911
TCP
953
TCP
Network Console on Acid (NCA)—local tty redirection overOpenSSH UDP
Domain Name System (DNS) RNDC Service SofaWare Technologies Remote HTTPS management for firewall devices running embedded Check Point FireWall-1 software
981
TCP
989
TCP
UDP
FTPS Protocol (data): FTP over TLS/SSL
990
TCP
UDP
FTPS Protocol (control): FTP over TLS/SSL
991
TCP
UDP
NAS (Netnews Administration System)
992
TCP
UDP
993
TCP
Internet Message Access Protocol over SSL (IMAPS)
995
TCP
Post Office Protocol 3 over TLS/SSL (POP3S)
999
TCP
ScimoreDB Database System
1001
TCP
JtoMB
1002
TCP
1023
TCP
TELNET protocol over TLS/SSL
Opsware agent (aka cogbot) UDP
Fejlesztéshez fenntartott
7.6. Az EtherType mező értékei és jelentése Az IEEE 802.3 keret EtherType mezője (ha annak értéke 0x0600 vagy ennél nagyobb szám) azt mutatja, hogy milyen felsőbb protokoll szerinti payload-ot szállít az adott Ethernet keret.
EtherType
Protocol
0x0800
Internet Protocol, Version 4 (IPv4)
0x0806
Address Resolution Protocol (ARP)
0x0842
Wake-on-LAN Magic Packet, as used by ether-wake and Sleep Proxy Service
0x1337
SYN-3 heartbeat protocol (SYNdog)
0x8035
Reverse Address Resolution Protocol (RARP)
0x809B
AppleTalk (Ethertalk)
0x80F3
AppleTalk Address Resolution Protocol (AARP)
0x8100
VLAN-tagged frame (IEEE 802.1Q)
0x8137
Novell IPX (alt)
0x8138
Novell
0x86DD
Internet Protocol, Version 6 (IPv6)
0x8808
MAC Control
0x8819
CobraNet
0x8847
MPLS unicast
0x8848
MPLS multicast
0x8863
PPPoE Discovery Stage
0x8864
PPPoE Session Stage
0x886F
Microsoft NLB heartbeat [3]
0x8870
Jumbo Frames
0x888E
EAP over LAN (IEEE 802.1X)
0x889A
HyperSCSI (SCSI over Ethernet)
0x88A2
ATA over Ethernet
0x88A4
EtherCAT Protocol
0x88A8
Provider Bridging (IEEE 802.1ad)
0x88AB
Ethernet Powerlink
0x88CC
LLDP
0x88CD
SERCOS III
0x88D8
Circuit Emulation Services over Ethernet (MEF-8)
0x88E1
HomePlug
181
0x88E5
MAC security (IEEE 802.1AE)
0x88F7
Precision Time Protocol (IEEE 1588)
0x8902
IEEE 802.1ag Connectivity Fault Management (CFM) Protocol / ITU-T Recommendation Y.1731 (OAM)
0x8906
Fibre Channel over Ethernet
0x8914
FCoE Initialization Protocol
0x9100
Q-in-Q
0xCAFE
Veritas Low Latency Transport (LLT)
182
7.7. Irodalom [1]
RFC ajánlások az IETF honlapról a következő címen letölthetők: http://www.ietf.org/rfc/
[2]
ITU-T ajánlások az ITU honlapról elérhetők: http://www.itu.int/itudoc/itu-t/
[3]
ETSI ajánlások az ETSI honlapján elérhetők: http://www.etsi.org
[4]
CableLabs ajánlások a CableLabs oldalán elérhetők: http://www.cablelabs.com/specifications/
[5]
Wi-Fi előírások: www.wi-fi.org/
[6]
www.iana.org
[5]
Lőcsei Péter „IP alapú telefonrendszer bemutatása, és virtuális tesztlabor kialakítása” című szakdolgozat, 2010.
183
7.8. Rövidítések jegyzéke ADSL –
Assymmetrical Digital Subscriber Line
ASK –
Amlitude Shift Keying
ATM –
Asyncronous Transfer Mode
ÁSZF –
Általános Szerződési Feltételek
BORSCHT Battery feeding Oveervoltage protection Ringing Supervision of subscriber loop / Signaling Coding Hybrid Test BSSID –
Basic Service Set Identification;
CAP
Carryerless Amplitude Phase
–
CATV –
Cable TeleVision
CRC –
Cyclic Redundancy Check
CSMA/CD – Carryer Sense Multiply Access / Collision Detect CSMA/CA – Carryer Sense Multiply Access / Collision Avoidance DA
–
Destination Address;
DF
–
Dont Fragment
DMT –
Discrete Multi Tone
DOCSIS –
Data Over Cable Service Interface Specification
DS
Down Stream
–
DSCP –
Differenciated Services Code Point
DSSS –
Direct Sequence Spread Spectrum
DSL
Digital Subscriber Line
–
DSLAM –
DSL Access Multiplexer
ECN –
Explicit Congestion Notification
EFM –
Ethernet to the First Mile
ETSI –
European Telecommunications Standards Institute
FCS
Frame Check Sequence
184
–
FEC
–
Forward Error Correction
FHSS –
Frequency Hopping Spread Spectrum
FSK
Frequency Shift Keying
–
FTTx –
Fiber To The x
HD
High Definition
–
IANA –
Internet Assigned Numbers Authory
ICMP –
Internet Control Message Protocol
IGMP –
Internet Group Message Protocol
IHL
IP Header Length
–
ISDN –
Integrated Services Digital Network
ISP
–
Internet Service Provider
IP
–
Internet Protocol
ITU
–
International Telecommunication Union
JPE
–
Jelentő Piaci Erő
LAN –
Local Area Network
LLID –
Logical Link ID
MAC –
Media Access Contol
MDU –
Multi Dwelling Unit
MF
More Fragment
–
MPCP –
Multi-Point Control Protocol
MPEG –
Moving Picture Experts Group
NAT –
Network Address Translation
NHH –
Nemzeti Hírközlési Hatóság
ODN –
Optical Distribution Network
OFDM –
Orthogonal Frequency Division Multiplexing
OH
–
OverHead
OLT
–
Optical Line Termination
ONT –
Optical Network Termination
ONU –
Optical Network Unit
OSI
Open System Interconnection
–
P2MP –
Point to Multi Point
PON –
Passive Optical Network
POTS –
Plain Old Telephone Services
PSK
Phase Shift Keying
–
185
PSTN –
Public Switched Telephone Network
QAM –
Quadrature Amplitude Modulation
QPSK –
Quadrature PSK
RFC
–
Requests for Comment
RLL
–
Radio in Local Loop
SA
–
Source Address;
S-CDMA –
Synchronous Code Division Multiple Access
SDSL –
Symmetrical Digital Subscriber Line
SHDSL –
Single pair High speed DSL
SLA
–
Service Level Agrement
SNI
–
Service Network Interface
SOF
–
Start Of Frame
STP
–
Shilded Twisted Pair
RA
–
Receiving Address.
TA
–
Transmitting Address
TCP
–
Transmission Control Protocol
TD
–
Time Division
TDMA –
Time Division Multiply Access
TP
–
Twisted Pair
TTL
–
Time To Live
UDP –
User Datagram Protocol
UNI
–
User Network Interface
US
–
Upp Stream
UTP
–
Unshilded Twisted Pair
VDSL –
Very high bitrate Digital Subscriber Line
VoIP –
Voice over IP
WDM –
Wawe Division Multiplex
WiFi –
Wireless Fidelity
WLAN–
Wireless LAN
186
