Dr. Wührl Tibor Ph.D. MsC 04 Ea IP kapcsolás hálózati réteg
IP kapcsolás 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 hálózat építő elemei a routerek. 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. 2
IPv4 IPv4 fejléccel kiegészített datagram: 4 bit 4 bit 8 bit 8 bit 8 bit Version IHL Type of service Total Length (Differenciated Services) Identification Flags Fragment offset Time To Live Protocol Header Checksum Source IP address Destination IP address Option Padding DATAGRAM 3
IPv4 fejléc mezői 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 (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:160 bit = 20 byte, illetve maximum: 480 bit = 60 byte). 4
IPv4 fejléc mezői 5 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, 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ó.
IPv4 fejléc mezői 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. 6
IPv4 fejléc mezői 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. 7
IPv4 fejléc mezői A Flags nevű mező három jelzőbitet tartalmaz és az úgynevezett fragmentálással kapcsolatos. 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. 8
IPv4 fejléc mezői 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. 9
IPv4 fejléc mezői A Time To Live TTL, 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 az eltévedt csomagok automatikusan törlődjenek. 10
IPv4 fejléc mezői A Protocol mező hordozza azt az információt, hogy az adott IP csomag milyen protokoll szerinti információt hordoz. Az RFC1700 értelmében a mező néhány értékét és annak jelentését adjuk meg: 1 ICMP; 2 IGMP; 6 TCP; 7 UDP. 11
IPv4 fejléc mezői 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ő. 12
IPv4 fejléc mezői 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. 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 nagyobb mint 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). 13
IPv4 fejléc mezői 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). 14
IPv6 Az IPv6 fejléc fix hosszúságú része (RFC2460): 4 bit 4 bit 8 bit 8 bit 8 bit Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source IP address Destination IP address 15
IPv6 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). A DSCP mező (QoS) kitöltését az RFC4594 definiálja. 16
IPv6 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). 17
IPv6 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. 18
IPv6 A Next Header (IPv4-nél Protocol )) az IPv6 fejlécében a következő extension header típusát adja meg. Az azonosító 8 bites, kitöltését az RFC1700 írta elő, de azt hatályon kívül helyezte az RFC3232. 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 engedünk meg 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. 19
IPv6 A Source IP address a forrás állomás (küldő) IP címe (128 bit); Destination IP address célállomás címe (128 bit). 20
IPv4 IPv6 átállás Az IPv4 IP címek fogyása miatt egyre égetőbbé vált az IPv6 bevezetése. Az átállás nem mehet végbe egyik napról a másikra, vagyis folyamatos átállás szükséges. Az IPv6 routing sokkal erőforrás igényesebb, mint az IPv4 kapcsolás, ezért a hálózatban az átállás a hardver elemek cseréjét / bővítését is igényelheti. így mindenképpen számolni kell az IPv4 IPv6 együttműködéssel. 21
IPv4 IPv6 átállás IPv4 címek konvertálása Az első 80 bit értékét 0 -ba állítjuk,majd az azt követő 16 bitet 1 -be és ez utáni 32 bitre írjuk az IPv4 címet: 0000:0000:0000:0000:0000:ffff:IPv4_ cím Egyszerűsített leírási szabály szerint: ::ffff:ipv4_cím 22
IPv6 csomag továbbítás IPv4 hálózaton Az IPv6 hálózatok elérése IPv4-en keresztül is megvalósítható! Az IPv6 határon lévő router, mely az IPv4 felhő felé kapcsolódik Az IPv6 csomagot becsomagolja egy IPv4 csomagba. Az eljárás neve, IPv6 tunneling, az eljárást az RFC 3056 definiálja Connection of IPv6 Domains via IPv4 Clouds. 23
IPv6 csomag továbbítás IPv4 hálózaton Ver=4 IHL Type of service Total Length Identification Flags Fragment offset Time to Live Protocol = 41 Header Checksumm Source IP address (IPv4) Destination IP address (IPv4) Option Padding Ver=6 Traffic Class Flow Label Payload Length Next Header Hop Limit Source IP address (IPv6) Destination IP address (IPv6) DATAGRAM 24
IPv6 csomag továbbítás IPv4 hálózaton Abban az esetben, ha az IPv4-nek látszó IPv6 csomag egy olyan routerhez é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. 25
IP multicast IP többesadás A multicast routingnál hasonló a feladat, mint az unicast-nál, itt is az a cél, hogy a célállomáshoz eljusson az információ. Jelen esetben több célállomásról van szó, melyek ugyan azt az adást kívánják venni. Egy multicast csoporton belül, akár több adó eszköz is előfordulhat. A multicast routing algoritmusok feladata egy fa felépítése, melyen az információ áramlik. Cél az, hogy felesleges, egymással párhuzamos adásokkal a hálózatot ne terheljük! 26
IP multicast IP többesadás A fa ágainak olyannak kell lenniük, hogy a jelfolyam az optimális irányban haladjon. Általában több fa építhető fel, de az egyes útirányok egymástól különböző jellemzőkkel (paraméterekkel) bírnak, így a routing protokollnak (ugyan úgy, mint unicast forgalom irányítás esetén) a több lehetőség közül az optimálisat kell kiválasztania. A különböző paraméterű utak most is költségfüggvénnyel jellemezhetők. 27
IP multicast IP többesadás Multicast szolgáltatástípusok: Forrás specifikus szolgáltatás; Csoport osztott szolgáltatás. Forrás specifikus szolgáltatás (Source specific service) esetén a multicast csoportban egy adó és több vevő található (IPTV). Csoport osztott szolgáltatás (Group shared service) esetén a multicast csoportban több adó és több vevő is előfordul (például: több résztvevős videó konferencia). 28
IP multicast IP többesadás Multicast ímtaromány: 224.0.0.0. 239.255.255.255 ( D osztályú, ami azt jelenti, hogy az első oktet felső 4 bitje 1110 ). Címkiosztás központilag (IETF/operátor) történik. Szabványos multicast csoport kezelő eljárások: IGMP v.1, IGMP v.2, IGMP v.3 29
IP multicast IGMP (Internet Group Management Protocol) Az IGMP a host számára a multicast csoportba be- illetve kijelentkezést teszi lehetővé. IGMP v1, v2 és v3 verziók léteznek felülről kompatibilisek! IGMPv2 - RFC 2236 IGMPv3 RFC 3376, RFC 4604 30
IP multicast IGMP (Internet Group Management Protocol) Az IP multicast architektúrának fontos eleme a multicast agent. Az agent feladata a csoport menedzsment (group management) és a multicast útválasztás. A multicast agent engedélyezi, illetőleg tiltja egy host taggá válását az adott multicast csoportban. IP címek és hozzáférési kulcsok jogosságát kezeli a csoportban és eltávolítja a csoportból az inaktív host-okat. 31
IP multicast IGMP (Internet Group Management Protocol) Az IGMP keretformátum: 8 8 16 Type Max response time Checksum Group address 32
IP multicast IGMP (Internet Group Management Protocol) Type üzenet típust azonosító mező (8 bites): Type mező tartalma 0x11 Üzenet jelentése: Membership Query 0x16 Membership Report (IGMP V2) 0x12 Membership Report (IGMP V1) 0x17 Leave Group 33
IP multicast IGMP (Internet Group Management Protocol) Type IGMP üzenet azonosító Max. Response Time 100ms egységekben értendő, maximáliasan megengedett idő a Query-től a Response megérkezéséig. Checksum Az IGMP üzenetek hibafelfedését segítő ellenőrző összeg, mely hosszúsága 16 bit. 34
IP multicast IGMP (Internet Group Management Protocol) Group Address Azt a multicast ( D osztályba tartozó) címet adjuk meg, amely az adott csoportra jellemző. 35
Címkekapcsolás - MPLS MPLS Multi Protocol Label Switching 1997 elején alakult az IETF MPLS munkacsoport MPLS RFC-k: RFC3032 (MPLS Label Stack Encoding) RFC3270 (Multi-Protocol Label Switching(MPLS) Support of Differentiated Services); RFC5129 (Explicit Congestion Marking in MPLS); RFC5462 (Multiprotocol Label Switching (MPLS) Label Stack Entry:"EXP" Field Renamed to "Traffic Class" Field). 36
Címkekapcsolás - MPLS MPLS előnyök: Gyors kapcsolás a címke alapján Előre kijelölhető útvonalak Előre kijelölhető redundáns útvonalak A címke beszúrás/kivétel a többi réteg formátumára nincs kihatással Jó QoS kezelés. 37
Címkekapcsolás - MPLS Elvárások az MPLS-sel szemben: Különböző hálózati technológiákon megvalósítható legyen Router kapcsolásra szánt erőforrás alacsony legyen QoS képességek Hiba esetén gyors útvonal helyreállás/váltás (50ms) SDH szintű rendelkezésre állás. 38
Címkekapcsolás - MPLS MPLS routerek helye a hálózatban: LER Label Edge Router MPLS hálózat határán helyezkedik el, típus alapján lehet: Ingress Node (MPLS belépési pont); Egress Node (MPLS kilépési pont). LSR Label Switching Router Mindig az MPLS hálózat belsejében helyezkedik el, IP címet nem lát. 39
Címkekapcsolás - MPLS Címkekapcsolás (ábra forrás: www.cisco.com) 40
Címkekapcsolás - MPLS MPLS fejléc beszúrás (Ethernet keret példa): Unicast MT = 0x8847 Multicast MT = 0x8848 41
Címkekapcsolás - MPLS MPLS fejléc: Label címke; EXP mező elnevezése megváltozott TC-re (Trafic Class); S bit = Bottom of Stack, értéke 1 ha ez az utolsó címke a stack-ben; TTL Time To Live ugyan az a funkció, mint az IP-nél! 42
Címkekapcsolás - MPLS MPLS - TTL mező kezelés: A belépési ponton lévő LER-nek (Label Edge Router) az IP header TTL tartalmát át kell másolni az MPLS TTL mezőbe; Kilépési ponton lévő LER az MPLS header eldobása (címke elvétel) előtt az MPLS header-ben lévő TTL-t vissza kell írni az IP header-be (és természetesen IP header ellenőrző összeget újra kell számítani!). 43
Köszönöm a Megtisztelő figyelmet! Dr. Wührl Tibor Ph.D. wuhrl.tibor@kvk.uni-obuda.hu 44