IPv6 multicast áttekintése

Bevezetés

Ez a dokumentáció meg probálja összefoglalni az IPv6 multicast tapasztalatainkat, amelyek hasznosak lehetnek egy Campus méretű rendszer tervezéséhez és üzemeltetéséhez. A dokumentáció további részében nem használjuk a többesküldést, mint a multicast magyar megfelelőjét, mert ez a terminólógia még nem terjedt el.

Az IPv6 multicast alapfogalmak, a működési típusok és a fejlesztést inspiráló alkalmazások rövid bemutatása után következik a két leglényegibb feladat a csoportok megszervezése és maga csomagtovábbítás megvalósítása. A zárórészben néhány IPv6 multicast megvalósítást ismertetünk, többnyire Campus méretűek, de a világméretű hálózatok sem az álmok kategóriájába tartoznak. Ennek csíráit már láthatjuk, a néhány világméretű tervvel és megvalósítással is találkozhatunk. Nem véletlenül került a végére az IPv4 multicast hálózatokkal levő kapcsolat kérdése. Nem szerettük volna a korlátozott IPv4 multicast megvalósításokkal kezdeni (bár nagyon sok kipróbált ötlet innen jön), mert az IPv6-ban mások a lehetőségek (alkalmasabb protokoll erre a feladatra), nem csak IPv4 továbbfejlesztések, hanem új protokollok tervezésére is sor került és még az alkalmazási történet elején vagyunk. A dokumentum végére kerültek a fejezethez tartozó rövidebb eredeti leírások, referenciák és ajánlások.

A mutlicast jelentősége (TriplePlay, IPTV, VoD, VPN)

Az informatika (számítástechnika) gyors fejlődése és alkalmazása a távközlésben (beágyazott rendszerekben) közel hozta egymáshoz a két területet (egy csatlakozó segítségével, egy hálózatból kapjuk a korábban több hálózattal biztosított szolgáltatásokat. A Triple Play egy hármas szolgáltatást takar: nagy sebességű internet, televízió (video on demand/kívánságra vagy hagyományosan sugárzott) és telefonszolgáltatás együttese egyetlen szélessávú kapcsolaton keresztül. Az átjárhatóság nem tervezési cél ugyan, de az IP mindegyik implementációban központi szerepet játszik.

A Triple Play lehet: {{{VoIP, IPTV, internet VoIP, VoD, VPN-kapcsolat IPTV, VoD, internet.}}}

A Triple Play architektúrája változatos, több fizikai közegen (a fizikai rétegben) lehet megvalósítani a kapcsolatot (rézvezeték, kábeltelevíziós koax, optika és drótnélkül).

Miért kell tesztelni ?

Nagyon fontos, hogy a különböző szolgáltatások minősége magas színvonalú legyen. Ez azt jelenti, hogy minden szolgáltatásnak biztosítani kell a jó minőségű (QoS, Quality of Service) működéshez a szükséges sávszélességet. Megnőtt az igény azon felügyelő és monitorozó rendszerek iránt, amelyekkel tesztelni is lehet (pl. NetSpotter iránt is).

Mit kell tesztelni Triple Play-ben?

Hiba lehet a hardver infrastruktúrában, a szolgáltatásban, az alkalmazásban, a QoS-ben, … . Így tehát egy sor vizsgálatra lehet szükség az ügyfél telephelyén, illetve a hozzáférési hálózatokon, pl.:

A 3. réteg folytonosságának felmérése, IP ping
QoS minősítés kis-közepes forgalomszinten
Adatteljesítmény és áteresztőképesség a felhasználói végberendezésnél (CPE-nél)
Hangminőség video- és adatforgalom mellett
Hangátkódoló VoIP PSTN/ISDN-be/-ből
Videóminőség mérése hang- és adatforgalom mellett
Csoportos IP adás (többesküldés, szörfölés csatornák között).

A fenti tesztek közöl mindegyikre szükségünk lehet, hogy jó minőségű legyen a szolgáltatás, a nagyvonalú specifikációt a következő táblázatban ismertetjük:

	Adat	Voip	Steraming audió (Mp3)	Steraming videó (MPEG4)
Sávszélesség	Változó	12-106 kbit/s	32-320 kbit/s	0,005-10Mbit/s
Veszteség	Érzékeny	<1%	<2%	<2%
Késleltetés	Érzéketlen (ha interaktív használat esetén < 5s)	<250 ms	< 5s	< 5s
Jitter	Érzéketlen	< 25ms	Jitterpuffer	Jitterpuffer

IPv6 multicast alapvető müködése

Az IPv6 három adattovábbítási formát támogat az adó(k) és vevő(k), mint interfészek között. Az unicast továbbítás esetén az adatokat eljuttatjuk az egyedi, individuális címmel ellátott vevőhöz. A multicast csoportos szállítást jelent, az adatokat el kell juttatni a csoport minden tagjához. A anycast továbbítás szintén egy jól meghatározott csoporttal kapcsolatos, ekkor a csoport egy (valamilyen módon egyértelműen meghatározott, legközelebbi) tagjának továbbítjuk az adatot. Az anycast továbbításban résztvevők címei megegyeznek az unicast továbbításban használatos címtartománnyal. Az üzenetszórás (broadcast) az IPv6-ban nem használatos, ez a multicast egy speciális esetének tekinthető.

Miért jó a multicast?

A multicast alkalmazása számottevően csökkenti az adathálózat terhelését, a multimédiás konferenciázás esetén és az információ szétosztásánál rendkívül hatékony. Az adatokat egy példányban tudjuk eljuttatni egy vagy több felhasználónak. A multicast akkor hasznos, amikor a forrásállomás több címzettnek is szeretné elküldeni ugyanazt a csomagot. Ilyen esetben az egyedi küldés nagyon kis hatékonyságú.

Multicast megvalósítás problémai

A gyakorlati megvalósításnál számtalan elvi probléma felmerül, a számítógép-hálózati architektúra második (L2) és harmadik (L3) rétege érintett:

Mi legyen az L3 szintű, IP címzéssel, amely végponttól végpontig kíséri az adatcsomagot? Fordított a feladat jellege, a végpontok döntenek, hogy kitől szeretnének csomagot kapni, ezt kell dinamikusan optimalizálni. Erre külön vezérlő protokollokra van szükség.
Hogyan tudják meg az L3 útvonalválasztók a vevőkről (hosztokról), hogy ők milyen multicast csoportba tartoznak (ha az adott csoport tagjai különböző irányban vannak, akkor több példányban elő kell állítani a csomagot és el kell küldeni az érintett irányokba)? Erre többféle is megoldás született, amelyeket a későbbiekben ismertetünk.
Hogyan lehetne az L2 szintű hálózati kártyák egy csoportjának megmondani, hogy ők azonos multicast csoportba tartoznak?
Az L2 (második rétegbeli) kapcsolók (switch) nagyarányú elterjedése egyre nagyobb állomásszámú, ütközésmentes kapcsolt hálózatot (switched 802.3/Ethernet) eredményez. Az L3 útvonalválasztók (routerek) nélkül a címtér egyszerűbb,„lapos” (flat) lesz, mert nem kell az útképzéshez szükséges cím-hiearchiát használni. A mutlicast szempontjából a kapcsolók műsorszórási (broadcast) és multicast képességeit használjuk ki (ez igaz mind az IPv6, mind az IPv4 L3-as harmadik szintű többesküldési környezete hasonló módon használhatjuk a kapcsolók L2-s műsorszórási képességeit).
A nagyméretű, sok állomásos L2-es hálózatok pazarolják a sávszélességet és igazán nem lesznek alkalmasak a multicast (multimédiás) funkció megvalósítására.
Ha a célállomás MAC (fizikai) címe broadcast vagy multicast jellegű a kapcsoló elárásztja a keret tartalmával az összes portot (kivéve azt, amelyről vette ezt a keretet).
A kapcsolók korszerűsödésével több módszert (protokollt) dolgoztak ki az L2-es mutlicast forgalom optimalizálására (csak a multicastban érintett portokra küldik az információt, ezt nagyobb adminisztrációval érik el, CAM táblák vezetésével):
1. IGMP hallgatózás (Internet Group Membership Protocol Snooping)
2. Cisco CGMP (Cisco Group Mangement Protocol
3. IEEE’s GARP (Generic Attribute Resolution Protocol, IEEE 802.1p)
Mivel az L2 broadcast nem hatékony (külön tanulmányban bemutatjuk a fenti 3 darab L2 szintű optimalizálási eljárást: Áttekintés az L2 eszközök IPv6 multicast támogatásáról).
A projekt harmadik alszakaszában megtörtént az L2 eszközök vizsgálata is (az előző dokumentumokban is érintőlegesen szerepel ez a téma, az L2 LAN a leggyakoribb adatkapcsolat, amellyel a felhasználó kapcsolódik az adathálózathoz).

IPv6 mutlicast címzés

Mielőtt az IPv6 multicast típusait bemutatjuk, nézzük meg az IPv6 16 bájtos címzését, amely a többesküldéssel kapcsolatos. A típusok a multicast címzés által is meghatározottak. A mutlicast csoportok címében a 128 bit hosszú címmező első 8 bitje csupa 1-es (ff00::/8). A következő 4 bit a jelző biteket tartalmazó bitmező. Ezt követi újabb 4 bites mező, amely az adatszórás tartományát azaz scope-ját határozza meg. A maradék 112 bitet használjuk a csoportok címzésére (még ebben is van néhány foglalt, előre definiált cím, amely speciális jelentéssel bíró csoportot jelöl).

A 4 darab jelzőbit:

                       0RPT      T = 0 állandó (permanens) cím
                                 T = 1 időleges (temporális) cím
                                 P = 1 egyedi címmel kombinált (unicast prefix)
                                 R = 1 randevú pont (RP) címének beágyazása.

Az adatszórási tartom'nz 4-es bitcsoportjának néhány jellemző hexadecimális értéke :

        1 =  a csomópont saját maga (node, loopback)
        2 =  helyi kapcsolat (link-local), fizikai réteg interfésze (soros vonal, Ethernet)
        5 =  helyi kiszolgáló (helyen, site-local)
        8 =  helyi szervezet (organization-local)
        e =  globális, az egész internet.

Előre definiált statikus címek (T = 0 a jelzőrészben, a 12-edik bit 0):

        ff01::1  az összes csomópont az adott interfészen
        ff02::1  az összes csomópont az adott linken
        ff01::2  az összes útvonalválasztó az adott interfészen
        ff02::2  az összes  útvonalválasztó az adott linken
        ff05::2  az összes  útvonalválasztó az adott kiszolgálón (helyen)
        ff01::101  az összes NTP szerver az adott interfészen
        ff02::101  az összes NTP szerver az adott linken
        ff0e::101  az összes NTP szerver az egész Interneten.

További elődefiniált multicast címcsoport a szomszédok keresésénél használt solicited-node címét határozza meg, az utolsó 24 biten a csomópont egyedi vagy szelektív címe helyezkedik el:

        ff02:0:0:0:0:1:ff00:0/104

Ideiglenes (transient) címek (T = 1 a jelzőrészben):

Általános ideiglenes cím:

ff1::groupid32/128

Unicast prefix alapú multicast cím:

ff3s:prefixlength:prefix64:groupid32

Beágyazott randevú pontú cím (embedded RP):

ff7s:rRpl:RPprefix64:groupid32

Forrás specifikus (SSM) cím:

ff3s:allzeros80:groupid32

A mutlicast címek változatainak, a foglalt címek aktuális listáját a [http://www.iana.org/assignments/ipv6-multicast-addresses Assigned IPv6 Multicast] címen találhatjuk meg.

A mutlicast típusai (ASM, SSM)

Két multicast típust mutatunk be:

Tetszőleges forrású mutlicast(Any-Source Multicast, ASM). Ez a klasszikusnak mondható típus, az IP csomagot el kell juttatni a vevők csoportjához. Itt megengedett a több forrás is (nemcsak az egy-a-többes, hanem a több-a-többes kommunikáció). A forrásnak nem kell a csoporthoz tartoznia, a vevő hosztok bármikor csatlakozhatnak a csoporthoz és bármikor ki is jelentkezhetnek. A csoport adminisztrálási feladatokat a routerek az MLD v1 (Multicast Listener Discovery) protokollal tudják végrehajtani.
Forrás specifikus multicast (SSource-Specific Multicast, SSM). A csoport hosztjai meg tudják határozni, hogy csak mely forrásoktól (only), vagy mely forrásoktól nem (all except) fogadnak el IP csomagokat. A szűrést az MLD v2 protokoll segítségével tudjuk beállítani.

Multicast táblák

A címzés és a típusok után három adminisztrációs tábla (adatbázist) bemutatása is az alapkoncepcióhoz tartozik:

Az MRIB (Multicast Information Base) tábla a forrás állomás helyének megállapítását és RFP (Reverse Path Forwarding) útképzéssel való leellenőrzését támogatja.
A TIB (Tree Information Base) tábla állapotinformációkat tartalmaz, amelyeket az útképző és csoport kommunikációt végrehajtó protokollok állítanak be (PIM, MLD).
Az MFIB (Multicast Forwarding Information Base) tábla kizárólag a továbbítás irányával foglalkozik, az MRIB és TIB információiból épül fel.

A multicast útvonal meghatározása egy fa struktúra felépítését jelenti. Több protokoll együttműködéséből keletkezik ez a fa. A felhasználókkal az MLD (Multicast Listener Protocol) kommunikál, a résztvevők jelentik a fa leveleit (küldő, fogadó). A fa elágazási pontjai az adathálózati csomópontok (routerek) és az ezek közötti forgalmat a PIM (Protocol Independent Multicast) portokoll bonyolítja le.