#acl All:read <> = 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 (mutlicast, 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ű mutlicast 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) 1. Cisco CGMP (Cisco Group Mangement Protocol 1. 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 multicast 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 multicasttal 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. 1. 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. 1. 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). 1. 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 multicast 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 multicast-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) mutlicastra. 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 multicast 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. == IPv4 é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]] == Multicast alkalmazások (video, hang konferencia, menedzsment) == A dokumentum további részében nagyon röviden felsoroljuk az átlagos felhasználók lehetőségeit a multicaston alapuló szolgáltatások igénybevételére. A munkaszakaszban megvizsgáltuk a más, nem LAN adathálózati kapcsolódás esetén felmerülő lehetőségeket, korlátokat és a fejllesztés várható irányait. Ha megnézzük mégegyszer a Triple Play táblázatát, akkor a gyorsan fejlődő xDSL szolgáltatás már alkalmas lesz ilyen szolgáltatások használatára. A kapcsolt telefon-modemes kapcsolat is korlátozottan alkalmazható. === Felhasználói alkalmazások === * [[http://research.microsoft.com/conferencexp/|ConferenceXP]] * [[http://isabel.dit.upm.es/|Isabel]] * [[http://atm.tut.fi/mad/|MAD Flute]] * [[http://www-mice.cs.ucl.ac.uk/multimedia/software/|NTE ]] * [[http://www.ecs.soton.ac.uk/~njh/pcm6cast/|pcm6cast]] * [[http://www-mice.cs.ucl.ac.uk/multimedia/software/|RAT ]] * [[http://www-mice.cs.ucl.ac.uk/multimedia/software/|SDR ]] * [[http://www-mice.cs.ucl.ac.uk/multimedia/software/|VIC ]] * [[http://www.videolan.org/|VideoLAN client]] * [[http://www-mice.cs.ucl.ac.uk/multimedia/software/|WBD ]] === Rendszergazdai/Monitoring alkalmazások === * [[http://beacon.man.poznan.pl/|Beacon ]] * [[http://artemis.av.it.pt/~hsantos/dbeacon/|Dbeacon ]] * NetSpotter * [[http://www.venaas.no/multicast/ssmping/|ssmping]] == Foglalt IPv6 multicast címek == {{{ INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES (last updated 2006-08-17) IPv6 multicast addresses are defined in "IP Version 6 Addressing Architecture" [RFC4291]. This defines fixed scope and variable scope multicast addresses. IPv6 multicast addresses are distinguished from unicast addresses by the value of the high-order octet of the addresses: a value of 0xFF (binary 11111111) identifies an address as a multicast address; any other value identifies an address as a unicast address. The rules for assigning new IPv6 multicast addresses are defined in [RFC3307]. IPv6 multicast addresses not listed below are reserved. Current IPv6 multicast addresses are listed below. Fixed Scope Multicast Addresses ------------------------------- These permanently assigned multicast addresses are valid over a specified scope value. Node-Local Scope ---------------- FF01:0:0:0:0:0:0:1 All Nodes Address [RFC4291] FF01:0:0:0:0:0:0:2 All Routers Address [RFC4291] FF01:0:0:0:0:0:0:FB mDNSv6 [Cheshire] Link-Local Scope ---------------- FF02:0:0:0:0:0:0:1 All Nodes Address [RFC4291] FF02:0:0:0:0:0:0:2 All Routers Address [RFC4291] FF02:0:0:0:0:0:0:3 Unassigned [JBP] FF02:0:0:0:0:0:0:4 DVMRP Routers [RFC1075,JBP] FF02:0:0:0:0:0:0:5 OSPFIGP [RFC2328,Moy] FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers [RFC2328,Moy] FF02:0:0:0:0:0:0:7 ST Routers [RFC1190,KS14] FF02:0:0:0:0:0:0:8 ST Hosts [RFC1190,KS14] FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080] FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci] FF02:0:0:0:0:0:0:B Mobile-Agents [Bill Simpson] FF02:0:0:0:0:0:0:C SSDP [Kostic] FF02:0:0:0:0:0:0:D All PIM Routers [Farinacci] FF02:0:0:0:0:0:0:E RSVP-ENCAPSULATION [Braden] FF02:0:0:0:0:0:0:F UPnP [Fairman] FF02:0:0:0:0:0:0:16 All MLDv2-capable routers [RFC3810] FF02:0:0:0:0:0:0:6A All-Snoopers [RFC4286] FF02:0:0:0:0:0:0:FB mDNSv6 [Cheshire] FF02:0:0:0:0:0:1:1 Link Name [Harrington] FF02:0:0:0:0:0:1:2 All-dhcp-agents [RFC3315] FF02:0:0:0:0:0:1:3 Link-local Multicast Name Resolu [Aboba] FF02:0:0:0:0:0:1:4 DTCP Announcement [Vieth,Terst.] FF02:0:0:0:0:1:FFXX:XXXX Solicited-Node Address [RFC4291] FF02:0:0:0:0:2:FF00::/104 Node Information Queries [RFC4620] Site-Local Scope ---------------- FF05:0:0:0:0:0:0:2 All Routers Address [RFC4291] FF05:0:0:0:0:0:0:FB mDNSv6 [Cheshire] FF05:0:0:0:0:0:1:3 All-dhcp-servers [RFC3315] FF05:0:0:0:0:0:1:4 Deprecated (2003-03-12) FF0X:0:0:0:0:0:1:1000 Service Location, Version 2 [RFC3111] -FF0X:0:0:0:0:0:1:13FF Variable Scope Multicast Addresses ---------------------------------- These permanently assigned multicast addresses are valid over all scope ranges. This is shown by an "X" in the scope field of the address that means any legal scope value. Note that, as defined in [RFC4291], IPv6 multicast addresses which are only different in scope represent different groups. Nodes must join each group individually. The IPv6 multicast addresses with variable scope are listed below. FF0X:0:0:0:0:0:0:0 Reserved Multicast Address [RFC4291] FF0X:0:0:0:0:0:0:C SSDP [Kostic] FF0X:0:0:0:0:0:0:FB mDNSv6 [Cheshire] FF0X:0:0:0:0:0:0:100 VMTP Managers Group [RFC1045,DRC3] FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119,DLM1] FF0X:0:0:0:0:0:0:102 SGI-Dogfight [AXC] FF0X:0:0:0:0:0:0:103 Rwhod [SXD] FF0X:0:0:0:0:0:0:104 VNP [DRC3] FF0X:0:0:0:0:0:0:105 Artificial Horizons - Aviator [BXF] FF0X:0:0:0:0:0:0:106 NSS - Name Service Server [BXS2] FF0X:0:0:0:0:0:0:107 AUDIONEWS - Audio News Multicast [MXF2] FF0X:0:0:0:0:0:0:108 SUN NIS+ Information Service [CXM3] FF0X:0:0:0:0:0:0:109 MTP Multicast Transport Protocol [SXA] FF0X:0:0:0:0:0:0:10A IETF-1-LOW-AUDIO [SC3] FF0X:0:0:0:0:0:0:10B IETF-1-AUDIO [SC3] FF0X:0:0:0:0:0:0:10C IETF-1-VIDEO [SC3] FF0X:0:0:0:0:0:0:10D IETF-2-LOW-AUDIO [SC3] FF0X:0:0:0:0:0:0:10E IETF-2-AUDIO [SC3] FF0X:0:0:0:0:0:0:10F IETF-2-VIDEO [SC3] FF0X:0:0:0:0:0:0:110 MUSIC-SERVICE [G van Rossum] FF0X:0:0:0:0:0:0:111 SEANET-TELEMETRY [Andrew Maffei] FF0X:0:0:0:0:0:0:112 SEANET-IMAGE [Andrew Maffei] FF0X:0:0:0:0:0:0:113 MLOADD [Braden] FF0X:0:0:0:0:0:0:114 any private experiment [JBP] FF0X:0:0:0:0:0:0:115 DVMRP on MOSPF [Moy] FF0X:0:0:0:0:0:0:116 SVRLOC [Guttman] FF0X:0:0:0:0:0:0:117 XINGTV FF0X:0:0:0:0:0:0:118 microsoft-ds FF0X:0:0:0:0:0:0:119 nbc-pro FF0X:0:0:0:0:0:0:11A nbc-pfn FF0X:0:0:0:0:0:0:11B lmsc-calren-1 [Uang] FF0X:0:0:0:0:0:0:11C lmsc-calren-2 [Uang] FF0X:0:0:0:0:0:0:11D lmsc-calren-3 [Uang] FF0X:0:0:0:0:0:0:11E lmsc-calren-4 [Uang] FF0X:0:0:0:0:0:0:11F ampr-info [Janssen] FF0X:0:0:0:0:0:0:120 mtrace [Casner] FF0X:0:0:0:0:0:0:121 RSVP-encap-1 [Braden] FF0X:0:0:0:0:0:0:122 RSVP-encap-2 [Braden] FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Guttman] FF0X:0:0:0:0:0:0:124 rln-server [Kean] FF0X:0:0:0:0:0:0:125 proshare-mc [Lewis] FF0X:0:0:0:0:0:0:126 dantz [Yackle] FF0X:0:0:0:0:0:0:127 cisco-rp-announce [Farinacci] FF0X:0:0:0:0:0:0:128 cisco-rp-discovery [Farinacci] FF0X:0:0:0:0:0:0:129 gatekeeper [Toga] FF0X:0:0:0:0:0:0:12A iberiagames [Marocho] FF0X:0:0:0:0:0:0:12B X Display [McKernan] FF0X:0:0:0:0:0:0:12C oap-multicast [Eastham] FF0X:0:0:0:0:0:0:12D DvbServDisc [Willigen] FF0X:0:0:0:0:0:0:12E Ricoh-device-ctrl [Ohhira] FF0X:0:0:0:0:0:0:12F Ricoh-device-ctrl [Ohhira] FF0X:0:0:0:0:0:0:201 "rwho" Group (BSD) (unofficial) [JBP] FF0X:0:0:0:0:0:0:202 SUN RPC PMAPPROC_CALLIT [BXE1] FF0X:0:0:0:0:0:0:300 Mbus/Ipv6 [RFC3259] FF0X:0:0:0:0:0:2:0000 -FF0X:0:0:0:0:0:2:7FFD Multimedia Conference Calls [SC3] FF0X:0:0:0:0:0:2:7FFE SAPv1 Announcements [SC3] FF0X:0:0:0:0:0:2:7FFF SAPv0 Announcements (deprecated) [SC3] FF0X:0:0:0:0:0:2:8000 -FF0X:0:0:0:0:0:2:FFFF SAP Dynamic Assignments [SC3] FF3X:0::0-FF3X:0000:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF (FF3X:0000:/32) Source-Specific Multicast block Registration Rules: Addresses in FF3X:0000:/32 but not listed below are reserved for future SSM address use, but are currently invalid. FF3X::4000:1-FF3X::7FFF:FFFF - IETF consensus FF3X::8000:0-FF3X::FFFF:FFFF - Dynamically allocated by hosts when needed [RFC-ietf-ssm-arch-07.txt]. Address/Range Description Reference --------------------------- ---------------------------------- --------- FF3X::0:0-FF3X::3FFF:FFFF Invalid addresses [RFC-07.t] FF3X::4000:0 Reserved [RFC-07.t] FF3X::4000:1-FF3X::7FFF:FFFF Reserved for IANA allocation [RFC-07.t] FF3X::8000:0-FF3X::FFFF:FFFF Reserved for local host allocation [RFC-ietf-ssm-arch-07.txt] }}} == Referenciák == * [[attachment:6net_d3.4.1.pdf|6NET D3.4.1 IPv6 Intra-domain multicast service]] * [[attachment:6net_d3.4.2.pdf|6NET D3.4.2 IPv6 Inter-domain multicast service]] * [[attachment:6net_d3.1.2v2.pdf|6NET D.3.1.2v2 IPv6 cookbook for routing, DNS, intra-domain multicast, inter-domain multicast]] * [[attachment:6net_ipv6deployment_guide.pdf|6NET IPv6 deployment guide]] * [[http://www.m6bone.net|m6bone - IPv6 multicast teszt hálózat]] * RFC-k és draftok: * Definitions and Addressing * RFC 1112 Host Extensions for IP Multicasting. S. Deering, Stanford University, August 1989. (Obsoletes RFCs 988, 1054) (Updated by RFC2236) (Status: RECOMMENDED STANDARD) * RFC 1546 Host Anycasting Service. C. Partridge, T. Mendez, W. Milliken. November 1993. (Status: INFORMATIONAL) * RFC 2373 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. July 1998. (Obsoletes RFC1884) (Status: PROPOSED STANDARD) * RFC 2375 IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July 1998. (Status: INFORMATIONAL) * RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. (Updated by RFC3956, RFC4489) (Status: PROPOSED STANDARD) * RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B. Haberman. November 2004. (Updates RFC3306) (Status: PROPOSED STANDARD) * RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses. J-S. Park, M-K. Shin, H-J. Kim. April 2006. (Updates RFC3306) (Status: PROPOSED STANDARD) * Management of multicast groups on the link-local * RFC 2710 Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999. (Status: PROPOSED STANDARD) * RFC 3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol. B. Haberman. September 2003. (Updates RFC2710) (Status: PROPOSED STANDARD) * RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed.. June 2004. (Updates RFC2710) (Status: PROPOSED STANDARD) * Management of multicast on L2 * RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches. M. Christensen, K. Kimball, F. Solensky. May 2006. (Status: INFORMATIONAL) * Multicast routing * RFC 1075 Distance Vector Multicast Routing Protocol. D. Waitzman, C. Partridge, S.E. Deering. Nov-01-1988. (Status: EXPERIMENTAL) * RFC 1458 Requirements for Multicast Protocols, May 1993 (Status: INFORMATIONAL) * RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1998. (Obsoletes RFC2117) (Status: EXPERIMENTAL) * RFC 2715 Interoperability Rules for Multicast Routing Protocols. D.Thaler. October 1999. (Status: INFORMATIONAL) * Allocation of IPv6 multicast addresses * RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP). S.Hanna, B. Patel, M. Shah. December 1999. (Status: PROPOSED STANDARD) * RFC 2771 An Abstract API for Multicast Address Allocation. R. Finlayson. February 2000. (Status: INFORMATIONAL) * RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP). M. Handley, D. Thaler, R. Kermode. February 2000. (Status: PROPOSED STANDARD) * RFC 2907 MADCAP Multicast Scope Nesting State Option. R. Kermode. September 2000. (Status: PROPOSED STANDARD) * RFC 2908 The Internet Multicast Address Allocation Architecture. D. Thaler, M. Handley, D. Estrin. September 2000. (Status: INFORMATIONAL) * Monitoring * RFC 2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks. C. Chung, M. Greene. September 1998. (Obsoletes RFC2366) (Status: PROPOSED STANDARD) * RFC 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol. B. Haberman, R. Worzella. January 2001. (Status: PROPOSED STANDARD) * Security * RFC 1949 Scalable Multicast Key Distribution. A. Ballardie. May 1996. (Status: EXPERIMENTAL) * RFC 2588 IP Multicast and Firewalls. R. Finlayson. May 1999. (Status: INFORMATIONAL) * Performances * RFC 2432 Terminology for IP Multicast Benchmarking. K. Dubray. October 1998. (Status: INFORMATIONAL) * Applications * RFC 2090 TFTP Multicast Option. A. Emberson. February 1997. (Status: EXPERIMENTAL) * RFC 3170 IP Multicast Applications: Challenges and Solutions. B. Quinn, K. Almeroth. September 2001. (Status: INFORMATIONAL)