IP Multicast
Cíl kapitoly
Cílem kapitoly je pochopit smysl skupinového vysílání (multicastingu) a naučit
se jej využívat v prostředí lokální i rozlehlé sítě. Student bude rozumět principům
směrování multicastů a dokáže zvolit vhodný směrovací protokol s ohledem na rozložení
potenciálních přijímačů jednotlivých multicastových skupin.
Prekrekvizity
Studium této kapitoly předpokládá obecnou znalost problematiky směrování
protokolu IP a mechanismu enkapsulace IP paketů v rámcích spojové vrstvy,
zejména na Ethernetu.
Princip a aplikace multicastingu
- Výhodou omezení zabrané šířky pásma ve větvích vedoucích k více přijímačům
oproti distribuci pro každý přijímač zvlášť.
- Pakety se kopírují až v místech, kde se datový tok rozděluje do více větví sítě
obsahujících příjemce multicastové skupiny.
Typické aplikace
- distribuce vysílání videa, hlasu
- videokonference
- vyhledávání služeb
- distribuované simulace (včetně her)
Multicastové skupiny
- Skupiny jsou "otevřené" - může do nich vysílat i stanice, která není členem skupiny
- Do skupiny se může přihlásit kterákoli stanice
- Stanice může být členem i více skupin
Adresování multicastových skupin v IP
Adresy třídy D: 224.0.0.0 - 239.255.255.255
Rezervované lokální adresy
- Rozsah adres 224.0.0.0 - 224.0.0.255
- Šíření multicastů omezeno na lokální segment, pakety vždy TTL=1
- Používáno hlavně směrovacími protokoly (komunikace sousedních směrovačů)
Adresy s globálním dosahem (Globally Scoped Addresses)
- rozsah 224.0.1.0 - 238.255.255.255
- přiděluje IANA (např. 224.0.1.1 - Network Time Protocol (NTP))
GLOP adresy
- rozsah 233.0.0.0 - 233.255.255.255
- automaticky přiděleny sítím, které mají své číslo AS
- číslo AS zakódováno ve 2. a 3. bajtu
- poslední bajt umožňuje v AS zřídit až 255 lokálních multicast skupin
Adresy s omezeným dosahem (Limited Scope Addresses, RFC 2365)
- rozsah 239.0.0.0 - 239.255.255.255
- obdoba privátních IP adres, mohou výt opakovaně využívány v nezávislých sítích
- oblast sítě, kam se šíří, vymezená konfigurací směrovačů
Poznámka
Multicastové adresy mohou být v IP paketech jen adresami cíle
(zdrojová adresa je vždy unicast)
Multicasting na LAN a WAN
Problémy:
- Mapování IP adres multicastových skupin na MAC adresy (neřeší ARP)
- Šíření multicastů (kopírování paketů) jen do větví sítě, kde je zájem o příjem příslušné skupiny
Šíření ve stromové sítí (L2):
Kopie na porty (mimo příchozího) vycházející do větví, ve kterých existuje nějaký příjemce dané skupiny.
Šíření v síti obsahující smyčky:
- Smyčky by vedly k cyklování paketů, proto konstrukce distribučního stromu.
- Kořenem distribučního stromu buďto směrovač sítě se zdrojem multicastů
nebo dohodnutý směrovač (kořen, RP-Rendezvous Point,Core). Ve druhém případě
zdroj zasílá multicastové pakety unicast IP tunelem na kořenový směrovač.
- Směrovače musí rozlišit, která rozhraní vedou ke kořeni stromu a která ke větvím,
proto pro multicasty existuje zvláštní forma směrovací tabulky.
Mapování multicast IP adres na MAC adresy (Ethernet)
- Pro multicast MAC adresy vyhrazena polovina rozsahu dáného prefixem 0x01-00-5E
(všimněte si, že příznak "multicast" v nejvyšším bitu je hodnotou 0x01 nastaven)
- V v nejvyšším bitu 4. bajtu MAC adresy musí být 0, pro mapování zbývá 23 bitů MAC adresy
- Multicast IP adresy (třída D) vždy začínají 1110, musí se mapovat 28 bitů (32-4)
- Posledních 23 bitů multicast IP adresy se přímo zkopíruje do posledních 23 bitů MAC adresy
- 5 nejvyšších bitů multicast IP adresy se nemapuje, takže 32 IP multicast skupin
se vždy mapuje na jednu multicast MAC adresu (mapování není jednoznačné)
Příklad: 224.10.8.5 -> 01.00.5e.0a.08.05
Internet Group Membership Protocol (IGMP)
IGMPv1 - RFC 1112, IGMPv2 - RFC 2236
- používají stanice (přijímače multicastu) pro přihlášení (u v2 i odhlášení) do multicastové skupiny
u nejbližšího směrovače a směrovač pro ověření, zda ve větvi ještě existuje stanice se zájmem
o danou multicastovou skupinu
- používají směrovače pro přihlášení své větve sítě do distribučního multicastového stromu
- směrovače přes IGMP získávají informaci, zda je na jednotivých rozhraních
nějaký (aspoň jeden) přijímač jednotlivých multicastových skupin
Protokol IGMP v.1
Protokol IGMP v.1 obsahuje pouze dvě zprávy:
- MEMBERSHIP REPORT - zasílá stanice při přihlášení do skupiny a jako pozitivní odpověď na dotaz směrovače,
zda je na segmentu zájemce o danou skupinu. Zasílá se na adresu požadované multicast skupiny.
- MEMBERSHIP QUERY - periodicky zasílá směrovač na každém rozhraní pro zjištění, zda je na segmentu
nějaká stanice se zájmem o některou multicastovou skupinu.
Pokud stanice přestane mít zájem o multicast skupinu, přestane na dotaz směrovače odpovídat
zprávou MEMBERSHIP REPORT.
Poznámka:
Na segmentu sítě s velkým množstvím přijímačů multicastové skupiny by dotaz
směrovače zprávou MEMBERSHIP QUERY vygeneroval smršť odpovědí MEMBERSHIP REPORT.
Proto je do protokolu vnesena optimalizace: stanice neodpovídá na zprávu MEMBERSHIP QUERY
ihned, ale jistou náhodnou dobu s odpovědí posečká. Pokud uslyší, že mezitím na dotaz
odpověděla některá jiná stanice, zprávu u MEMBERSHIP REPORT sama generovat nebude.
Protokol IGMP v.2
Novější verze protokolu IGMP v.2 přináší novou zprávu LEAVE GROUP, kterou se stanice může
explicitně odhlásit z multicastové skupiny. Výhodou je zkrácení latence odhlašování, tedy
doby, po kterou je segment zbytečně zahlcován provozem multicastové
skupiny, kterou již nikdo neposlouchá.
Dalším rozšířením verze 2 je možnost specifického dotazu na zájemce o jednu konkrétní
multicast skupinu ve zprávě MEMBERSHIP QUERY (nikoli jen na zájemce o jakoukoli skupinu,
jako v IGMP v.1). To je užitečné zejména když router přijme zprávu LEAVE GROUP pro nějakou
multicastovou skupinu a chce
bezprostředně poté ověřit, zda má ještě stále smysl na segment provoz dané skupiny vysílat.
Poznámka:
Všimněte si, že kvůli možnosti havárie stanic bez odhlášení ze skupiny a také kvůli
optimalizaci ve vysílání odpovědí na MEMBERSHIP QUERY pouze jedinou stanicí není možné,
aby směrovač počítal počet přijímačů na segmentu pouze na základě zvyšování, resp. snižování
čítače při příchodu zpráv MEMBERSHIP REPORT a LEAVE GROUP pro danou skupinu. Proto je nezbytné,
aby nepřítomnost přijímačů pro danou skupinu zjišťoval dotazem pomocí zprávy MEMBERSHIP QUERY.
Protokol IGMP v.3
Nejnovější specifikace protokolu IGMP obohacuje protokol o možnost filtrování požadovaného
provozu na základě zdrojových adres. Tím se je možné bránit před nekorektně se chovajícími
stanicemi, které multicastovou skupinu nežádoucím způsobem zahlcují. Při žádosti o provoz
multicastové skupiny je potom možné explicitně zadat buďto zadat seznam zdrojů, ze kterých
jedině mají být zprávy přebírány nebo naopak seznam zdrojů, od nichž mají být zprávy
zaslané do multicastové skupiny filtrovány.
Zpracování multicastů v aktivních prvcích 2. vrstvy
Jelikož multicast pakety se šíří v rámcích 2. vrstvy, je třeba, aby přepínače
věděly, na které porty mají příchozí multicast rámec zaslat. Jednodušší přepínače,
které multicast nepodporují, pracují s multicasty stejně jako s broadcasty -
zasílají je na všechny porty mimo příchozího. Tím se síť značně zatěžuje, protože
všechny multicasty na segmentu sítě (broadcast doméně) jsou zasílány i do těch větví,
kde nejsou požadovány žádnou stanicí.
OBRAZEK.
Je proto třeba, aby přepínače věděly, na kterém portu jsou příjemci které multicast skupiny.
To se lze nejlépe dozvědět z protokolu IGMP, včetně monitoringu MAC adres stanic,
si které zprávy protokolu IGMP vyměňují. Protože známe způsob mapování multicast IP adres
a multicast MAC adresy, postačí přepínači zjistit, na které (unicast) MAC adresy stanic má rozkopírovat
příchozí rámec s každou jednotlivou multicast MAC adresou. Čísla portů, na které jsou
stanice s těmito MAC adresami připojeny, se již najdou v normální přepínací tabulce.
Poznámka:
Všimněte si však, že sledování zpráv protokolu IGMP je mimo rozsah běžných "kompetencí"
přepínače.
Existují dva základní způsoby, jak může přepínač informaci z IGMP získat:
- IGMP Snooping
- pomocný protokol mezi přepínačem a směrovačem segmentu
IGMP Snooping
IGMP Snooping spočívá v tom, že přepínač nahlíží do dat 3. vrstvy v přenášených
rámcích a pokud je v ní obsažená zpráva IGMP (MEMBERSHIP REPORT, LEAVE GROUP), získá z ní potřebnou informaci
o příslušnosti MAC adres stanic do jednotlivých multicastových skupin. Tato metoda
samozřejmě přepínač zatěžuje a zpravidla má smysl jen v případě, že že je realizována
hardwarově.
Poznámka
Všimněte si, že se zprávy MEMBERSHIP REPORT a LEAVE GROUP podle protokolu IGMP zasílají na adresu
příslušné IP multicastové skupiny a tedy na 2. vrstvě na multicastovou MAC adresu, na kterou
se daná IP multcastová adresa mapuje. Postačí tedy, aby přepínač zkoumal 3. vrstvu jen
u rámců zasílaných na multicastové MAC adresy.
Pomocný protokol mezi směrovačem a přepínači segmentu
Aplikace pomocného protokolu mezi přepínačem a směrovačem segmentu je výhodná tím, že
přepínač není zatěžován nahlížením do 3. vrstvy a může být tak aplikována i na méně výkonných
přepínačích. O informování všech přepínačů o MAC adresách stanic aktuálně přihlášených
do jednotlivých multicastových skupin se stará směrovač příslušného segmentu, který
protokol IGMP zpracovává. Protokol, kterým směrovač přepínače na segmentu o mapování
MAC adres stanic do jednotlivých skupin informuje, však bohužel není standardizován.
Musí tedy být použit přepínač a směrovač téhož výrobce, pokud však výrobce vůbec tuto
metodu podporuje. Například firma Cisco pro tento účel implementuje svůj vlastní protokol
CGMP (Cisco Group Management Protocol). V něm je rezervována speciální multicast MAC adresa,
na kterou směrovač s aktivovaným protokolem CGMP na příslušném rozhraní informuje všechny
směrovače segmentu o událostech zjištěných pomocí IGMP na tomto rozhraní.
Distribuční stromy
Distribuční strom tvoří acyklický podgraf grafu topologie sítě a spojuje všechny
sítě, na nichž jsou přijímače dané multicastové skupiny. Jak se do skupiny přihlašují
nové přijímače a odhlašují existující, musí se do stromu připojovat nové větve a odstraňovat
("prořezávat", angl. "prune") staré.
SPT (Shortest-Path Tree, Source Tree)
Sdílený strom (Shared Tree)
Šíření ve stromu buďto jednosměrné (od kořene k listům) nebo obousměrné
SPT (Shortest-Path Tree, Source Tree)
- Strom nejkratších cest ze zdroje ke všem sítím s přijímači
- Značení < S,G >, kde S je zdrojová adresa, G je adresa multicastové skupiny
- Existuje samostatný strom pro každý zdroj vysílání do každé multicastové skupiny
- => Optimální, ale málo škálovatelné řešení
Příklad: strom < 192.2.2.2, 224.1.1.1 >
Sdílený strom (Shared Tree)
- Strom společný pro všechny zdroje ve skupině
- Kořenem je vhodně zvolený směrovač (RP)
- Zdroj musí zasílat každý paket na kořen
- Značení < *,G >, kde * označuje všechny zdrojové adresy vysílající do skupiny G
- => Poněkud delší cesta paketů (navíc cesta ke kořeni), ale jen jediný strom pro skupinu
Příklad: strom < *, 224.2.2.2 >
Směrování multicastů
Na rozdíl od běžného směrování se směrování multicastů děje podle
zdrojové adresy . Cílem je šířit paket po distribučním stromu stále dál od
zdroje vysílání.
Reverse Path Forwarding
Reverse Path Forwarding je metoda šíření multicast paketů od zdroje vysílání
dolů po distribučním stromu. K určení rozhraní, kterými se má příchozí multicast
paket dále šířit, slouží běžná (unicast) směrovací tabulka.
Z pohledu distribučního stromu pro danou multicastovou skupinu (a případně pro daný
zdroj u < S,G >stromů) dělíme rozhraní každého směrovače na "downstream" a "upstream".
Upstream rozhraní je právě jedno a vede směrem ke kořeni distribučního stromu.
Je to rozhraní, kterým se vysílají běžné (unicast) pakety na adresu odpovídající kořeni
distribučního stromu. Downstream rozhraní jsou rozhraní, která vedou do segmentů sítě v nichž
se vyskytují příjemci dané multicastové skupiny, ať už přímo stanice nebo směrovače, které
mají takovté příjemce za svými downstream rozhraními.
Aby bylo zajištěno šíření každého multicast paketu od kořeni k listům distribučního stromu,
nezpůsobili cyklování multicast paketů ve smyčce a pokud možno vyloučili vícenásobné vysílání
téhož multicast paketu na segment, postupuje směrovač při přijeté multicast paketu podle
následujího pravidla (tzv. RPF Check):
Pokud paket přišel z rozhraní, které se podle směrovací tabulky používá pro směrování
paketů ke zdrojové adrese multicastového paketu, paket se rozešle na downstream rozhraní.
V opačném případě se paket zahodí.
Pokud na základě RPF check směrujeme paket na všechna rozhraní mimo příchozího, vyloučí
se cyklování paketů ve smyčce a zajistí jeho rozšíření do celé sítě. Nezajistí se tim
však, že paket neprojde některou síti vícekrát, jak je uvedeno na obr. X.
Pro vyloučení tohoto případu multicastové směrovací protokoly určují ke každému
distribučnímu stromu nejen upstream, ale i množinu downstream rozhraní. Pakety
vyhovující podmínce RPF check se pak neposílají na všechna rozhraní mimo příchozího,
ale pouze na downstream rozhraní. Přiřazení upstream a downstream rozhraní každému
distribučnímu stromu tak tvoří směrovací tabulku pro multicasty, jejíž záznamy mají
pro zdrojové stromy (source trees) tvar:
< cílová multicast adresa, adresa zdroje multicastu, upstream rozhraní, množina downstream rozhraní >
Záznamů musí být tolik, kolik je vysílačů v multicast skupině.
Pro sdílené stromy (shared trees) se uchovává pro celou skupinu pouze jediný záznam.
Upstream rozhraní je určeno rozhraním, z něhož vychází nejkratší cesta k RP. Záznam
směrovací tabulky pak má tvar
< cílová multicast adresa, upstream rozhraní, množina downstream rozhraní >
Některé multicastové směrovací protokoly používají nejprve sdílený strom a až v případě
příliš intenzivního provozu z některé zdrojové adresy (S) zřídí pro danou multicastovou
skupinu a tento zdroj < S,G > strom. Pokud tedy existuje v multicastové směrovací
tabulce záznam < S,G > i < *,G > a multicastový paket vyhoví oběma z nich,
bude se směrování provádět podle < S,G > záznamu.
Směrovací protokoly pro multicast
Podle režimu funkce dělíme směrovací protokoly do dvou základních skupin:
- Dense Mode - protokoly DVMRP, PIM-DM, MOSPF
- Sparse Mode - protokoly PIM-SM, CBT
Rozdíl spočívá v tom, jestli je předpokládáno hustý (dense) nebo řídký (sparse) výskyt
příjemců multicast provozu v jednotlivých větvích sítě.
Dále si vysvětlíme základní princip práce v hustém a řídkém režimu.
Hustý režim
V hustém režimu se předpokládá, že zájemci o multicastovou skupinu jsou skoro na všech segmentech
sítě. Proto je provoz implicitně směrován do všech segmentů. Pokud směrovač časem (na základě
protokolu IGMP) zjistí, že na žádném svém rozhraní nemá zájemce o multicastovou skupinu, pošle
směrovači ve vyšší úrovni distribučního stromu žádost o "prořezání" (prune). Směrovač ve vyšší úrovni
stromu na jejím základě přestane do větve multicastový provoz dané skupiny vysílat. Pokud se ve větvi
časem objeví zájemce o multicastovou skupinu, může lokální směrovač segmentu větev do distribučního
stromu opětovně přihlásit.
Řídký režim
Na rozdíl od hustého režimu nejsou v řídkém režimu implicitně multicast pakety zasílány nikam.
Většina větví by totiž z důvodu řídkého výskytu příjemců byla multicasty zaplavována zbytečně.
Až když se na segmentu objeví zájemce o danou skupinu, pošle se směrem ke kořeni žádost o připojení nové větve
distribučního stromu. Po této větvi pak k novému zájemci poteče provoz požadované multicastové
skupiny.
Připojení větve do distribučního stromu v řídkém režimu nebo její odpojení v režimu hustém
není trvalé. Každý směrovač distribučního stromu si totiž žádost o připojení, resp. odpojení
pamatuje pouze po jistou omezenou dobu a po jejím vypršení přejde k původnímu chování.
Proto se musí žádost o připojení a odpojení větve distribučního stromu periodicky opakovat.
Žádosti o připojení a odpojení větve stromu se mezi směrovači zpravidla zasílají prostřednictvím
zpráv protokolu IGMP. Z hlediska směrovače tak není rozdílu, jestli mulicastový provoz
na rozhraní vyžaduje na segmentu připojená stanice nebo jiný směrovač, který multicastový
provoz požaduje pro segmenty na jeho rozhraní připojené větve distribučního stromu.
V řídkém režimu se na řízení směrování účastní méně směrovačů-pouze ty, které vytvářejí
ne příliš rozvětvený distribuční strom. Proto jsou protokoly pracující v řídkém režimu
vhodnější pro rozlehlé WAN sítě.
Směrování řídících zpráv
V hustém i řídkém režimu směrování se musí šířit řídící zprávy, obsahující žádosti
o připojení větve do distribučního stromu nebo naopak o její odpojení. Z pohledu
distribučního stromu se tyto zprávy šíří od listů směrem ke kořeni. Je tedy třeba zajistit
směrování těchto zpráv na všech směrovačích distribučního stromu.
Protože distribuční strom je vždy stromem nejkratších cest ze zdroje nebo z RP k listovým směrovačům,
lze pro směrování řídících zpráv použít běžné směrovací tabulky. Řídící zprávu tak
zašleme o úroveň distribučního stromu výše tím, že zvolíme rozhraní, kterým bychom se podle směrovací
tabulky dostali nejkratší cestou ke kořeni distribučního stromu.
Směrovací protokoly pro pro hustý režim
Distance Vector Multicast Routing Protocol (DVMRP) - RFC 1075
- první reálně používaný protokol pro směrování multicastů
- multicast pakety kopíruje na všechny interface mimo toho, které
vede ke zdroji multicastu (reverse-path flooding)
- pruning na základě žádosti z větví bez přijímačů multicastové skupiny
- periodicky se obnovuje flooding do prořezaných větví
pro případ, že by se ve větvi objevili přijemci
- pro určení upstream interface DVMRP implementuje svůj vlastní unicast distance-vector směrovací protokol
podobný RIPu založený na počtu přeskoků. Maximální počet přeskoků 32, periodický update každých 60 s.
Protože multicast je směrován na základě svého vlastního směrovacího potokolu,
může multicastový provoz mezi sítěmi procházet po jiných cestách než normální
unicast.
Protocol independent multicast dense mode (PIM-DM)
- nezávislý na používaném unicast směrovacím protokolu, využívá jeho směrovací tabulku
- multicasty směruje na základě RPF check
- není ve skutečnosti směrovacím protokolem, neposílá a nepřijímá žádné routing updates
- flooduje provoz do všech větví; větev může požádat o prořezání, pokud neobsahuje příjemce multicast skupiny
(refresh každé 3 minuty)
Podmínky pro efektivní funkci:
- přijímače a vysílače blízko
- málo vysílačů a mnoho příjemců
- intenzivní multicastový tok
- konstantní proud multicast dat
Multicast OSPF (RFC 1584)
- směrování multicastů závislé na použitém směrovacím protokolu (OSPF)
- použitelné v rámci jedné směrovací domény (OSPF)
- šíření informací o členství ve skupinách na jednotlivých segmentech v link state updates.
- pro prostředí s nevelkým počtem současně aktivních skupin a zdrojů multicastů (< S,G > párů)
- každý směrovač provádí nezávislý výpočet distribučního stromu pro každý pár < S,G >
Směrovací protokoly pro pro řídký režim
Core-Based Tree (CBT) - RFC 2201
jediný sdílený distribuční strom pro skupinu
kořenem stromu je "core" směrovač, ostatní směrovače posílají žádosti o připojení do
stromu směrem k core směrovači
když core router přijme žádost o připojení větve, pošle zpět acknowledgement, ten
ve směrovačích na cestě vytváří stavovou informaci o nové větvi
pokud žádost o připojení na cestě k core směrovači narazí na směrovač, který
je již součástí požadovaného stromu, tento směrovač žádost potvrdí namísto core směrovače
dosud ve vývoji, tři vzájemně nekompatibilní verze
Protocol independent multicast sparse mode (PIM-SM)
- vhodný pro malý počet příjemců ve skupině a pro nepravidelné datové toky
- odesílatelé zasílají multicast pakety na RP
- příjemci se registrují u RP
- Směrovače na cestě mohou optimalizovat trasu datového toku od zdroje k příjemci
Rendezvous point (RP) pro jednotlivé multicast skupiny musí být nakonfigurován
ve všech směrovačích. Existují také (zatím nestandardizované) protokoly, které
šíří informaci o aktivních RP pomocí multicastingu.
Poznámka:
PIM může pro některé skupiny pracovat v dense módu a pro některé ve sparse módu.
Designated router lokální sítě
Pokud je na LAN připojeno více směrovačů, je třeba, aby zprávy IGMP MEMBERSHIP QUERY
zasílal jen jeden z nich. Stejně tak je třeba, aby interakci s protokolem
PIM vně sítě zajišťoval jen jeden z nich. Směrovačem pověřeným
těmito činnostmi (tzv. designated router) bude směrovač s nejvyšší IP adresou.
Takovíto sousedé schopní pracovat s protokolem PIM se nalézají pomocí zpráv
PIM QUERY vysílaných periodicky (každých 30 s) na adresu 224.0.0.2 (all-routers).
Internet Multicast Backbone (MBONE)
Ne všechny směrovače Internetu podporují multicasting. MBONE je experimentální
multicastová páteř Internetu.