Dr. Wührl Tibor Ph.D. MsC 04 Ea. IP kapcsolás hálózati réteg

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

IPTV alapok

IPv4 IPv4 fejléccel kiegészített datagram: 4 bit

4 bit  

Version

8 bit  

IHL

8 bit  

Type of service

8 bit  

Total Length

(Differenciated Services)

Identification Time To Live

Flags Protocol

Fragment offset Header Checksum

Source IP address Destination IP address Option

Padding

DATAGRAM

3

IPTV alapok

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

IPTV alapok

IPv4 fejléc mezői 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ó. 5

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

IPv6 Az IPv6 fejléc fix hosszúságú része (RFC2460): 4 bit

Version

4 bit

8 bit

8 bit

Traffic Class Payload Length

Flow Label Next Header

Source IP address

Destination IP address

15

IPTV alapok

8 bit

Hop Limit

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

IPv6 csomag továbbítás IPv4 hálózaton Type of Ver=4

IHL

Total Length

service

Identification Time to Live

Flags Protocol =

Fragment offset Header Checksumm

41 Source IP address (IPv4) Destination IP address (IPv4) Option Ver=6

Padding

Traffic Class Payload Length

Flow Label Next Header

Source IP address (IPv6)

Destination IP address (IPv6)

DATAGRAM

24

IPTV alapok

Hop Limit

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

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

IPTV alapok

IP multicast – IGMP (Internet Group Management Protocol) Az IGMP keretformátum:

8

8

16

Type

Max response  time

Checksum

Group address

32

IPTV alapok

IP multicast – IGMP (Internet Group Management Protocol) Type – üzenet típust azonosító mező (8 bites):

Type mező tartalma

33

Üzenet jelentése:

0x11

Membership Query

0x16

Membership Report (IGMP V2)

0x12

Membership Report (IGMP V1)

0x17

Leave Group

IPTV alapok

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

IPTV alapok

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

IPTV alapok

Címkekapcsolás - MPLS MPLS – Multi Protocol Label Switching 1997 elején alakult az IETF – MPLS munkacsoport MPLS RFC-k: • • • • •

36

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).

IPTV alapok

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

IPTV alapok

Címkekapcsolás - MPLS Elvárások az MPLS-sel szemben: • • • • • 38

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. IPTV alapok

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

IPTV alapok

Címkekapcsolás - MPLS Címkekapcsolás (ábra forrás: www.cisco.com)

40

IPTV alapok

Címkekapcsolás - MPLS MPLS fejléc beszúrás (Ethernet keret példa):

Unicast   MT = 0x8847 Multicast MT = 0x8848 41

IPTV alapok

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

IPTV alapok

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

IPTV alapok

Köszönöm a Megtisztelő figyelmet! Dr. Wührl Tibor Ph.D. [email protected]

44

IPTV alapok