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.