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

Typické aplikace

Multicastové skupiny

Adresování multicastových skupin v IP

Adresy třídy D: 224.0.0.0 - 239.255.255.255

Rezervované lokální adresy

Adresy s globálním dosahem (Globally Scoped Addresses)

GLOP adresy

Adresy s omezeným dosahem (Limited Scope Addresses, RFC 2365)

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:

Šíř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:

Mapování multicast IP adres na MAC adresy (Ethernet)

Příklad: 224.10.8.5 -> 01.00.5e.0a.08.05

Internet Group Membership Protocol (IGMP)

IGMPv1 - RFC 1112, IGMPv2 - RFC 2236

Protokol IGMP v.1

Protokol IGMP v.1 obsahuje pouze dvě zprávy: 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

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)

Příklad: strom < 192.2.2.2, 224.1.1.1 >

Sdílený strom (Shared Tree)

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: 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

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)

Podmínky pro efektivní funkci:

Multicast OSPF (RFC 1584)

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)

    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.