Multicast

Z pohľadu na spôsob komunikácie medzi klientmi rozlišujeme 3 typy komunikácie:

• unicast, jeden s jedným (konkrétny zdroj, konkrétny cieľ)
• broadcast, jeden všetkým (konkrétny zdroj, cieľom sú všetky stanice v sieti)
• multicast, jeden vybranej skupine (konkrétny zdroj, cieľom je multicastová skupina)

Cieľom multicastovej komunikácie je limitovať doručovanie informácií k používateľom, ktorý o ne javia záujem. Záujem o príslušné dáta stanice samé prejavujú prostredníctvom registrácie do tzv. Multicastových skupín. Vzhľadom na to, že v IP paketoch musí byť pre multikastovú skupinu uvedená cieľová IP adresa, bol vymedzený rozsah IP adries, ktorý sa používa za účelom Multicastovania. Je to Class D rozsah 224.0.0.0/4 tj. od 224.0.0.0 po 239.255.255.255. Aby bolo možné sformovať rámec na úrovni data-linkovej vrstvy v ethernete, je potrebné stanoviť MAC adresu, ktorá sa bude používať ako cieľová MAC adresa pre multicast. Za týmto účelom bol vymedzený prefix 0100.5e, ktorý je doplnený o zvyšných 23 bitov IP adresy. Samozrejme, v tomto prípade sa mapuje iba spodných 23 bitov IP adresy do výslednej MAC adresy, čo má za následok existenciu rovnakých MAC adries, pre rôzne Class D IP adresy. V takomto prípade, dáta doručované multicastovej skupine s rovnakou MAC adresou ako bola vypočítaná druhej multicastovej skupine sú doručované obom skupinám príjemcov.

Skupine s adresou 233.10.47.70 a 233.10.47.70 výpočtom zistíme MAC adresu: 0100.5e05.2f46, kde 10.47.70 = 0 0001010.0101111. 01000110 spodných 23 bitov je hexadecimálne 052f46 (0000 0101 0010 1111 0100 0110)

IGMP a CGMP protokol

Za účelom registrovania do multicastovej skupiny sa využíva podporný protokol IGMP, ktorého cieľom je evidovať voči okrajovému smerovaču, či sa v jeho broadcastovej doméne (LAN sieti) nachádzajú klienti, ktorí sú členmi multicastovej skupiny. IGMP protokol má 3 typy správ:

• IGMP Report - stanica pomocou tohoto paketu prejavuje záujem o príjem dát konkrétnej multicastovej skupiny alebo potvrdzuje, že naďalej javí záujem o príjem dát v tejto skupine
• IGMP Query - smerovač sa pomocou tejto správy dotazuje na prítomnosť staníc, ktoré prijímajú multicastový traffic pre konkrétnu multicastovú skupinu
• IGMP Leave - stanica ohlasuje odpojenie sa od príjmu dát danej multicastovej skupiny

IGMP query je dvoch typov:

• Global query - vysielaná smerovačom na multicastovej adrese 224.0.0.1 1x za každých 60 sekúnd (zmeniteľné príkazom ip igmp query-interval). Ak ľubovoľná stanica neodpovie membership reportom do trojnásobku query-intervalu (3 min, zmeniteľné príkazom ip igmp query-timeout), tak sa automaticky pozastavý odosielanie multicastovej prevádzky do siete, nakoľko sa tam nenachádza žiadna stanica, ktorá o dáta prejavila záujem.
• Group-specific query - vysiela sa smerovačom na multicastovej adrese konkrétnej skupiny, 2x (z odstupom 1s) po prijatí IGMP Leave správy, aby sa mohol smerovač uistiť, že po odchode stanice z multicastovej skupiny sa v nej ešte stále nachádzajú klienti, ktorý o multicastový traffic záujem majú. V takomto prípade, stanice, ktoré príjmu od smerovača query spustia náhodne vypočítaný časovač (max. hranica 10s alebo zmeniteľné cez ip igmp query-max-response-time) a po jeho uplynutí vyšlú group membership report. Cieľom tohoto časovača, je zabezpečiť, aby iba jedna stanica zareagovala na členstvo v skupine nakoľko stačí iba v sieti bola čo len jedna stanica na príjem dát.

IGMP je protokol, ktorý beží nad IP a preto jeho čitateľnosť na úrovni L2 prvkov je výrazne obmedzená. IGMP je schopné povedať, či do danej broadcastovej domény má byť multicastová prevádzka preposlaná alebo nie, nevie však ovplyvňovať druhú vrstvu (prepínače), nakoľko tieto nerozumejú IGMP správam (keďže prepínač nie je L3 zariadenie). Ako dôsledok sa multicastová prevádzka preposiela na všetky porty a teda stáva sa s nej broadcast.

Keďže cieľom multicastu je doručiť informácie iba tým klientom, ktorý o ne majú záujem, je potrebné problem selektívneho doručovania informácie riešiť aj na úrovni druhej vrstvy, teda prepínačov. Spôsobov je niekoľko:

• statické mapovanie MAC adresy multicastovej skupiny (0100.5e.....) na konkrétne porty na ktorých sa nachádzajú členovia multicastovej skupiny
• GMRP (GARP multicast registration protocol), ktorý zaznamenáva členov multicastovej skupiny a dáta replikuje smerom k nim
• IGMP snooping - analýza do hĺbky IGMP paketov a následné upovedomovanie prepínača, ktoré MAC adresy majú prijímať multicastové dáta

CGMP (Cisco Group Membership Protocol) protokol je Cisco proprietárny, ktorý umožňuje komunikáciu voči prístupovej vrstve s oznámením, ktorá MAC adresa v ich tabuľke má prijímať multicastové dáta. Pointa je následovná:

• klient vyšle IGMP membership report správu, ktorá pri prechode prepínačom síce nie je analyzovaná do hĺbky, avšak je zapamataná zdrojová MAC adresa klienta na konkrétnom porte
• smerovač príjme IGMP membership report, zabezpečí doručenie multicastovej prevádzky do lokálnej siete a pomocou protokolu CGMP oznámi (prostredníctvom CGMP Join správy) prepínačom na špecifickej adrese 0100.0cdd.dddd, ktorá MAC adresa patrí k danej multicastovej skupine. V správach CGMP protokolu sa na to používajú GDA (Group Destination Address) a USA (Unicast Source Address) políčka. GDA obsahuje identifikáciu multicastovej skupiny do ktorej používateľ patrí, USA obsahuje reálnu MAC adresu klienta, ktorá je naučená prepínačom v jeho CAM (Content addressable memmory) pamäťi. Prepínač tak má informáciu o tom, na ktorom porte sa nachádza multicastový klient (podľa MAC adresy), vie, že ak dáta prídu na multicastovú MAC adresu 0100.5e...MGROUP, tak ich má preposlať na daný port.
• smerovač označí uplinkové rozhranie prepínača pre multicastovú prevádzku pomocou CGMP správy kde je GDA nastavené na MAC adresu 0000.0000.0000 a USA nastavené na MAC adresu smerovača
• Pri odpojení používateľa prebieha podobný proces ako pri registrácii. Klient vyšle IGMP Leave správu, na čo v zápätí smerovač reaguje vyslaním CGMP Leave správy s GDA a USA pre danú multicastovú skupinu a konkrétneho používateľa.
• V prípade CGMP Leave správy s USA=0000.0000.0000 a GDA=0000.0000.0000 všetky prepínače zrušia preposielanie do všetkých multicastových skupín (dôsledok príkazu clear ip igmp)
• V prípade CGMP Leave správy s USA=MAC_ADRESA smerovača a GDA=0000.0000.0000 smerovač oznamuje prerušenie dodávania multicastu, odstránia sa multicastové skupiny patriace k tomuto smerovaču, ktorý správu vygeneroval

Sparce vs. Dense topológia

• Dense topológiou rozumieme takú topológiu, kde je prevaha klientov, ktorí využívajú multicast oproti unicastovým klientom
• Sparce topológiou rozumieme takú topológiu, kde je prevaha klientov, ktorí využívajú unicast oproti multicastovým klinetom

Implicit Join vs. Explicit Join

Jednou zo základných úloh multicastových dynamických smerovacích protokolov, je zabránenie slučkám a identifikácie akým spôsobom je možné dostať sa ku konkrétnemu zdroju multicastovej prevádzky. Za týmto účelom sa využívajú dve techniky:

• broadcast-and-prune (implicit join)
• explicit registration (explicit join)

Technika broadcast-and-prune (Implicit join) vychádza z toho, že multicast je treba všade a preto v pravidelných intervaloch zahlcuje smerovače multicastovou prevádzkou a až potom smerovače, ktoré nepotrebujú prijímať multicastovú prevádzku (nemajú multicastových príjemcov) odhlásia príjem multicastu pomocou prune správy. Takéto nasadenie je vhodné pre Dense topológie.

Technika explicitnej registrácie vychádza z opačného predpokladu, že multicastová prevádzka nie je potrebná a kto má o ňu záujem registruje sa voči smerovaču, že má záujem o príjem dát (podobne ako keď sa klient registruje voči svojmu okrajovemu smerovaču pomocou IGMP).

Cieľom multicastových dynamických smerovacích protokolov je identifikovať trojicu (S,G) a klientov, kde dvojica (S,G) udáva zdroj multicastovej prevádzky (S), multicastovú skupinu (G). Zoznam existujúcich klientov je potrebný na identifikáciu, ktorým smerom sa má multicastová prevádzka ďalej preposielať.

Source trees vs. Shared trees

Pre algoritmy prehľadávania najkratšej trasy a elimináciu slučiek sa najčastejšie vo všeobecnosti využívajú stromy. Rovnako je to aj v multicastových dynamických smerovacích protokoloch. Strom má na vrchole zdroj multicastovej prevádzky a dotvára bezslučkové vetvy a listy, ktoré prijímajú multicastovú prevádzku. V takomto prípade hovoríme o tzv. Source trees, pretože na vrchole stromu je zdroj prevádzky.

V niektorých prípadoch, ale stromy pre rôzne multicastové skupiny môžu byť stretávajúce sa v jednom alebo viacerých uzloch. Výhodu stretnutia sa viacerých multicastových zdrojov v jednom mieste je možné využiť ako centralizačný prvok (smerovače vedia kam majú za danou multicastovou prevádzkou ísť). Strom, v ktorom sa viacero zdrojov zbieha na jednom komponente nazývame Shared tree. V zdieľanom strome je smerovač na ktorom sa prevádzka "zbehne" označovaný ako RP (Randezvous point).

Platí, že smerovač si eviduje cesty k zdrojom a skupinám následovne:

• (S,G) pre každý zdroj a každú cieľovú multicastovú skupinu (nepoužíva RP). V prípade 30 zdrojov za skupinu v sieti s 200 skupinami je to 6000 záznamov.

• (*,G) pre každú multicastovú skupinu (použitím RP, zdroje sa zbiehajú na jednom bode). V prípade 30 zdrojov za skupinu v sieti s 200 skuipinami je to iba 200 záznamov (*,G)
  

Muticastové dynamické smerovacie protokoly využívajú Source-based trees alebo Shared trees následovne:

Protocol	Source-Based Trees	Shared Trees
DVMRP	X
MOSPF	X
PIM-DM	X
PIM-SM		X
CBT		X

Multicast scoping

Multicastovú prevádzku je možné ovplyvňovať z hľadiska jej dosahu (ako ďaleko sa šíri) prostredníctvom:

• TTL scoping, umožňuje definovať TTL treshold ktorý je ešte priepustný cez daný smerovač s nastaveným TTL scopingom
• Administrative scoping, rozdeľuje dosah multicastovej prevádzky na základe adresného priestoru

Odporúčané hodnoty TTL pre dané obmedzenie:

TTL	Obmedzenie
0	Iba pre lokálnu stanicu
1	Iba pre lokálnu sieť
15	Iba pre lokálnu budovu (site)
63	Iba pre rovnaký región
127	Celosvetová dostupnosť
191	Celosvetová dostupnosť avšak náročná na objem prenosu
255	Nelimitovaný prenos

Administratívny scoping umožňuje definovanie oblasti na základe použitých IP adries. Obmedzenia sú následovné (podľa RFC 2365):

Rozsah	Obmedzenie
239.0.0.0 - 239.255.255.255	Privátne určenie
239.255.0.0/16	lokálne použitie v sieti
239.192.0.0/14	lokálne použitie v rámci spoločnosti