TableOfContents

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:

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:

1. 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.
2. 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:

1. 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.
2. 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).
3. 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.

A multicast csoportcímek kiválasztása (különböző stratégiák előnyei, hátrányai)

A multicast címek megadásánál jó lenne bizonyos értelemben globálisan egyedi címeket megadni. Így elkerülhetőek a címütközések. Az SSM típusban (modellben) nem fordul elő, hogy a küldőnek két azonos című csoportnak kelljen küldeni. Az ASM típus esetén nemcsak a cím-ütközés elkerülése a fontos, hanem a port-ütközésé is.

Az általános multicast címstruktúrát már ismertettük az előzőekben, itt csak a rövid összefoglalást tesszük meg:

        ff0x::/16       állandó (fix) multicast cím
        ff1x::/16       ideiglenes multicast cím
        ff3x::/16       unicast alapú ideiglenes multicast cím
        ff3x::/96       SSM típusú multicast cím
        ff7x::/16       beágyazott RP típusú ideiglenes multicast cím

A számos multicast címkiosztási módszerből hetet említünk meg:

1. Csak az általános útmutatás szerint osztunk címeket, a teljes címtérből választhatunk.
2. Véletlenszerű (random) választást biztosító algoritmussal osztunk címeket,
   • akkor csináljuk ezt, ha nincs ennél jobb módszerünk.
3. SAP mehanizmus, a SAP kihirdeti a címkiválasztást.
4. MADCAP egy kliens-szerver architektúra, amelz támogatja az IPv6 és IPv4 címkiosztást is.
5. DHCPv6 hasonló a DHCPv4 és MADCAP-hez, kiemelhető az IA (Identify Association) kommukáción kívül a kliens kreatív szerepe.
6. ZMAAP, egy mini-MAAS szerver osztja a címeket. A SAP és a ZMAAP kis számú címet igénylő esetekben alkalmazható.
7. Az absztrakt API egy paraméterekkel ellátott kérés a címkiosztó rendszer felé.

A kiosztott címeket megtalálhatjuk a SAP, Web, e-mail, és DNS rendszerekben.

A multicast csoportok meghirdetése

Az elérhető szolgáltatások megtekintésére (session announcement) három katalógus eszköz áll rendelkezésre, amelyeken kívül természetesen használhatjuk azt az egyszerű módszert, hogy valamilyen egyéb csatornán (pl. e-mail) meghírdetjük a a multicast csoportot.

1. SDR (Session Directory Tool) az Mbone hálozaton a multicast konferenciákat adminisztrálja
2. SCS (Secure Conference Store) rendszer egy web alapú konfrencia menedzselő rendszer az UCL-en fejlesztették ki
3. LDAP-ban tároljuk az SDP üléseket.

Összefoglalásként ismertetjük a különböző metodikáknak kijelölt intervallumokat:

0x80000000 – 0x8fffffff MADCAP
0x90000000 – 0x9fffffff DHCPv6
0xa0000000 – 0xafffffff Véletlenszerű (Random)
0xb0000000 – 0x8bffffff ZMAAP
0xc0000000 – 0xffffffff nem használt.

Az IPv6 multicast megvalósítása

Az IPv6 multicast csoport a vevők egy tetszőleges csoportja, akik egy kiválasztott adatfolyamot szeretnének venni. A csoport elhelyezkedésének nincsenek fizikai és földrajzi korlátai. A vevőknek csatlakozniuk kell az adott csoporthoz, ezt a csatlakoztatást végzi az MLD protokoll - a legközelebbi routeren.

Az útvonalválasztók szintén az MLD protokollt használják, hogy megtudják vajon vannak-e csoport-tagok a hozzájuk tartozó alhálózatokban. Azután az adathálózaton a potenciálisan korlátlan számú vevő felé az adat alhálózatonként egy példányban továbbítódik.

A korábbiakban tárgyaltuk a címkiosztás megoldásait. A csoporthoz való tartozás dinamikus, bármikor fel és le tudunk jelentkezni a csoportbeli listákról. Egy munkaállomás, vevő (host) több csoportohoz is tartozhat. A csoportok működése nem kell , hogy folyamatos aktivitást jelentsen. Lehet olyan csoport, amelynek vannak tagjai, de a csoport nem aktív.

Az útképzés megvalósításához szükségesek a szintén korábban említett adatbázisok (MRIB, TIB és MFIB). Az útképzés egy útvonalat jelentő fa felépítése. Ezt az adathálózati oldalon a PIM (Protocol Indpendent Protocol) végzi, a felhasználói, vevői oldalom az MLD (Multicast Listener Discovery) protokoll kommunikál a vevőkkel. Erről a két protokollról ismertetünk további informácikat a következőkben.

Multicast csoporthoz tartozás menedzselése (MLD v1, v2)

MLD protokollt használnak a routerek, hogy felfedezzék a direkt kapcsolataikon a multicast használó vevőket és felfedezzék, hogy milyen muulticast címek találhatók a szomszédos csomópontokban. Az MLD automatikusan vezérli és limitálja a multicast forgalmat a többesküldési lekérdezők (queriers) és a végpontok (vevők, hostok) segítségével. A lekérdező az, aki kérdő üzeneteket küld ki, hogy felfedezze kik az adott csoport tagjai. A végpont az, aki riportot küld a kérdezőnek a csoportbeli tagságról. A lekérdezők és végpontok, akik ugyanattól a forrástól veszik az adatokat egy multicast csoportot alkotnak. A lekérdezők és végpontok MLD riportokat generálnak a csatlakozáshoz és a csoport elhagyásához is.

Az MLD ICMPv6 (Internet Control Message Protocol) protokollt használ az üzeneteinek a továbbítására. Minden MLD üzenet link-local 1-es ugrásszámmal (hop limit 1) és mindegyik csomóponti (router) riasztási opcióval ellátott, hogy minden csomópont végrehajtsa az opcionális fejlécben meghatározott feladatokat. Ebben a fejlécben háromféle üzenet van:

• Kérdés (Query), lehet általános, csoport-specifikus és többesküldési-cím-specifikus

• Riport (Report), itt a multicast címmezőben az a cím van, amit a riportküldő hallani szeretne

• Kész (Done), ez a leiratkozás üzenete, ezt a multicast címet nem akarja az üzenet küldője tovább hallgatni.

Az MLD riportban érvényes link-lokál cím vagy nemspecifikált cím van (ez utóbbi eset csak akkor, ha NDP/Neighbour Discovery Protokol szomszédokat felderító protokoll használata engedélyezett). Több multicast cím fogadása (DAD, Duplicate Address Detection) esetén kötelező a nemspecifikált cím használata az egy igazi interfész-címen kívül a többi cím nemspecifikált lesz. Az MLDv2 támogatja a forrás szűrését (SSM). A csoport elhagyása kb. 2 másodpercet vesz igénybe.

A multicast forgalomirányítás (alapok, PIM-SM, PIM-SSM)

A PIM egy hatékony IPv4 és IPv6 útképzési protokoll, amely független mindenféle egyedi útképző táblától az RPF (Reverse Path Forwarding) saját fordított útvonalának a végrehajtásánál. Az IPv6 multicast esetében a PIM-SM vagy a PIM_SSM működésmód a használatos (a kettő együtt is alkalmazható).

PIM-SM (Sparse Mode) azaz ritka mód, amely azt jelenti, hogy kevés számú útvonalválasztó érintett és ezeket is a lekérdezésekkel direkt módon kell bekapcsolni a forgalomba. Az adatkérési csatlakozás áthalad a csomópontokon (PIM join) a győkér csomóponthoz (RP, Rendezvous Point vagy SPT, Shortest Path Tree-nél a forrás felőli első útvonalválsztó, first-hop router). A leiratkozás, megszüntetés (PIM prune) üzenet felszámolja a csoportot és a forrást is.

A PIM-SM alapvető fogalmai közé tartozik a megjelölt útvonalválasztó (DR, Designated Router), amelynek a feladata a PIM üzenetek (join, prune, register) továbbíttása az RP felé egy adott LAN-ból. Ha több erre alkalmas útvonalválasztó van, akkor egyszerű szavazással dől el az egyedi DR-kérdés, a nagyobb IPv6-os című lesz a DR.

Az RP kihirdetése három módon történhet:

• Statikusan beírjuk minden egyes hálózati eszköznél

• BSR (BootStrap Router) alkalmazásával terjed a RP cím

• Beágyazott RP címzés (címzési konstrucióknál említésre került).

Az RP által meghatározott Osztott fa (Shared Tree) kilenc lépésben átalakítható esetlegesen optimálisabb fává. Ez lesz a Forrás fa (Source Tree vagy Shortest Path Tree), amely hatékonyabb csomagtovábbítást tesz lehetővé.

PIM-SSM (Source Specific Multicast) csak a forrás és csoport párra vonatkozó eljárásokat tartalmaz (S, G, Source, Group). A vevő oldalon a már említett MLDv2, a hálózati oldalon az SSM megvalósítás (PIM join-ek továbbítása az RPF (Reverse Path Forwarding) szerint) eredményezi a hatékony működést.

Az SSM jó nemcsak a tartományokon belüli (intra domain), de a tartományok közötti (inter domain) többesküldésre.

A téma iránt mélyebben érdeklődőknek ajánljuk nemcsak a harmadik rétegben (data network) használatos, jól ismert protokollok többesküldési módosításait (MRoute, MOSPF, MBGP, PIM-SM, PIM-DM, PIM-SSM, BIDIR), hanem a második rétegben (LAN, lokális hálózatokban, data link-ben) megvalósított protokollokat (IGMP, CGMP, GARP).

IPv6 multicast mintahálózatok (mbone, m6bone, 6net)

A sikeres 6net projekt eredményeinek egyik egyre erősödő szelete a mutlicast. Az első minta hálózat 10 évvel ezelőtt, 1996 már működött. A már említett IPTV alkalmazás egyre gyorsabb elterjedése előbb az IPv4-ben erősíti a gyakorlati megvalósítást. Talán az eddigiekből is kitűnhet, hogy az alkalmazások IPv4-ből történő átvitele nem túl bonyolult (természetesen az IPv6 alapinfrastruktúra megteremtése után). Az Interneten ezek a rendszerek saját, részletes beszámolókat tartalmazó honlapokon ismertetik fejlesztési terveiket és tapasztalataikat.

Pv4 és IPv6 multicast hálózatok közötti átjárás (reflektor,gateway)

Ebben a résztémában talán a [http:://www.m6bone.net M6Bone] projekt ért el szép eredményeket. Elkészültek azok az eljárások, amelyek a multicast szolgáltatást olyan vevőknek is biztosítják, akik nem az eddig említett eljárások szerint tudnak kapcsolódni a hálózathoz.

A [http:://www.m6bone.net M6Bone] honlapján az alkalmazások között három kiterjesztést találhatunk:

• [http://www.uninett.no/testnett/multicast/mcgw/ IPv4 – IPv6 multicast gateway]

• [http://www.kabassanov.com/reflectors/ IPv6 multicast – IPv6 unicast reflector]

• [http://www.kabassanov.com/reflectors/ IPv4 – IPv6 multicast reflector]