Multicastov\u00e9 smerovanie m\u00e1 za \u00falohu dopravi\u0165 spr\u00e1vy medzi v\u0161etk\u00fdmi \u010dlenmi danej multicastovej skupiny. Multicastov\u00e1 skupina je identifikovan\u00e1 \u0161peci\u00e1lnou IP adresou, ktor\u00e1 nie je pridelen\u00e1 \u017eiadnej stanici. V protokole IPv4 sme hovorili o triedach IPv4 adries. IPv4 adresy triedy D s\u00fa pr\u00e1ve IPv4 adresy multicastov\u00fdch skup\u00edn. V protokole IPv6 je multicastov\u00e9 adresovanie mo\u017en\u00e9 aj v r\u00e1mci siete \u010di auton\u00f3mneho syst\u00e9mu (IPv6 nem\u00e1 podporu pre broadcastov\u00e9 spr\u00e1vy).<\/p>\n
Pred t\u00fdm ako sa pust\u00edme do multicastov\u00e9ho smerovania, mus\u00edme spomen\u00fa\u0165 protokol\u00a0IGMP: Internet group management protocol<\/strong>\u00a0(RFC 3376<\/a>). Tento protokol sl\u00fa\u017ei iba na komunik\u00e1ciu medzi stanicou a jej predvolenou br\u00e1nou. M\u00e1 za \u00falohu umo\u017eni\u0165 stanici prihl\u00e1si\u0165 sa k nejakej multicastovej skupine. Protokol IGMP umo\u017e\u0148uje br\u00e1ne informova\u0165 v\u0161etky lok\u00e1lne siete o pon\u00fakan\u00fdch multicastov\u00fdch skupin\u00e1ch, ku ktor\u00fdm sa v pr\u00edpade z\u00e1ujmu m\u00f4\u017eu stanice pripoji\u0165. Tieto skupiny sa br\u00e1na dozvie bu\u010f od multicastov\u00e9ho smerovacieho protokolu, alebo jednoducho preto, \u017ee aj in\u00e1 stanica v niektorej z jej siet\u00ed je \u010dlenom danej multicastovej skupiny.<\/p>\n Stanica si m\u00f4\u017ee vybra\u0165 z pon\u00fakan\u00fdch skup\u00edn, alebo po\u017eiada\u0165 o \u010dlenstvo v nejakej z t\u00fdchto skup\u00edn tie\u017e cez protokol IGMP. Stanica m\u00f4\u017ee tie\u017e po\u017eiada\u0165 o \u010dlenstvo aj v inej multicastovej skupine, ktor\u00e1 nebola pon\u00fakan\u00e1 (pou\u017e\u00edvate\u013e si ju mohol n\u00e1js\u0165 napr\u00edklad cez nejak\u00fa webov\u00fa str\u00e1nku). Ak stanica po\u017eiada o \u010dlenstvo v skupine, je u\u017e na br\u00e1ne, aby pomocou multicastov\u00e9ho smerovacieho protokolu zabezpe\u010dila, \u017ee bude prij\u00edma\u0165 spr\u00e1vy pre t\u00fato multicastov\u00fa skupinu, aby ich mohla posiela\u0165 tejto stanici.<\/p>\n IGMP vy\u017eaduje, aby br\u00e1na raz za \u010das informovala o mo\u017enosti by\u0165 \u010dlenom multicastovej skupiny aj stanici, ktor\u00e1 u\u017e je \u010dlenom. Ak t\u00e1to stanica neodpovie op\u00e4tovnou po\u017eiadavkou o \u010dlenstvo v skupine, je z tejto skupiny automaticky vyl\u00fa\u010den\u00e1.<\/p>\n Multicastov\u00fd smerovac\u00ed protokol mus\u00ed zabezpe\u010di\u0165, aby ka\u017ed\u00fd \u010dlen multicastovej skupiny dost\u00e1val spolo\u010dn\u00e9 spr\u00e1vy. Pr\u00edstupy na sp\u00f4sob distrib\u00facie t\u00fdchto spr\u00e1v sme u\u017e spom\u00ednali pri broadcastovom smerovan\u00ed: RPF (tu naz\u00fdvan\u00fd \u201esource based tree\u201c teda strom zalo\u017een\u00fd na zdroji) a spanning tree (tu naz\u00fdvan\u00fd \u201egroup-shared tree\u201c teda zdie\u013ean\u00fd strom skupiny). Prv\u00fd pr\u00edstup je pou\u017e\u00edvan\u00fd v protokole DVMRP = distance-vector multicast routing protocol(RFC 1075<\/a>) a v protokole PIM-DM = protocol independent multicast routing protocol \u2013 dense mode (RFC 3973<\/a>). Druh\u00fd pr\u00edstup sa pou\u017e\u00edva v protokole PIM-SM = PIM \u2013 sparse mode (RFC 4601<\/a>,RFC 3569<\/a>,RFC 4607<\/a>).<\/p>\n Pri RPF pr\u00edstupe je \u0165a\u017ek\u00e9 ur\u010di\u0165, do ktor\u00e9ho spojenia treba skop\u00edrova\u0165 multicastov\u00fa spr\u00e1vu, aby tieto spr\u00e1vy neboli zbyto\u010dne rozosielan\u00e9 uzlom, ktor\u00e9 nechc\u00fa a nemusia by\u0165 s\u00fa\u010das\u0165ou multicastov\u00e9ho rozosielacieho stromu. Vykon\u00e1 sa teda to, \u017ee sa broadcastov\u00fdm sp\u00f4sobom rozpo\u0161le inform\u00e1cia o mo\u017enosti prij\u00edmania spr\u00e1v danej multicastovej skupiny. Koncov\u00e9 routre, ktor\u00e9 nemaj\u00fa pripojen\u00fdch \u017eiadnych \u010dlenov danej multicastovej skupiny, po\u0161l\u00fa orez\u00e1vaciu spr\u00e1vu, \u017ee o dan\u00e9 d\u00e1ta nemaj\u00fa z\u00e1ujem. V pr\u00edpade vn\u00fatorn\u00e9ho routra, ktor\u00fd rozosielal inform\u00e1ciu o skupine \u010fal\u0161\u00edm susedom, m\u00f4\u017ee odosla\u0165 orez\u00e1vaciu spr\u00e1vu, iba ak od v\u0161etk\u00fdch t\u00fdchto susedov pr\u00eddu orez\u00e1vacie spr\u00e1vy. Orez\u00e1vacie spr\u00e1vy sa posielaj\u00fa v\u017edy t\u00fdm routrom, ktor\u00e9 dan\u00e9mu routru poslali spr\u00e1vu o mo\u017enosti pripojenia k multicastovej skupine. Ak router orez\u00e1vaciu spr\u00e1vu nepo\u0161le, po \u010dase za\u010dne dost\u00e1va\u0165 spr\u00e1vy tejto multicastovej skupiny, ktor\u00e9 mus\u00ed \u010falej posiela\u0165 v\u0161etk\u00fdm neorezan\u00fdm routrom a prihl\u00e1sen\u00fdm staniciam v niektorej zo svojich lok\u00e1lnych siet\u00ed.<\/p>\n Ak sa pou\u017e\u00edva pr\u00edstup zalo\u017een\u00fd na spanning tree, v\u0161etci \u00fa\u010dastn\u00edci sa prip\u00e1jaj\u00fa k stromu rozosielania cez unicastov\u00fa prip\u00e1jaciu spr\u00e1vu na centr\u00e1lny uzol. \u017diadne orez\u00e1vanie sa robi\u0165 nemus\u00ed, lebo routre, ktor\u00e9 nie s\u00fa s\u00fa\u010das\u0165ou spanning tree \u017eiadne inform\u00e1cie o tejto skupine nedost\u00e1vaj\u00fa (nevedia, \u017ee existuje). \u0160peci\u00e1lnym pr\u00edpadom kedy sa spanning tree vyplat\u00ed je, ak je v skupine v\u017edy len jeden zdroj vysielania. V tom pr\u00edpade je odosielate\u013e automaticky zvolen\u00fd za centr\u00e1lny uzol a spr\u00e1vy putuj\u00fa po optim\u00e1lnych cest\u00e1ch.<\/p>\n Multicast m\u00e1 podporu aj pre cel\u00fd internet cez protokol MSDP = Multicast source discovery protocol (RFC 3618<\/a>,\u00a0RFC 4611<\/a>). Op\u00e4\u0165 ide o hierarchick\u00fd typ smerovania, ktor\u00e9 funguje ako multicastov\u00fd variant BGP protokolu.<\/p>\n","protected":false},"excerpt":{"rendered":" Multicastov\u00e9 smerovanie m\u00e1 za \u00falohu dopravi\u0165 spr\u00e1vy medzi v\u0161etk\u00fdmi \u010dlenmi danej multicastovej skupiny. Multicastov\u00e1 skupina je identifikovan\u00e1 \u0161peci\u00e1lnou IP adresou, ktor\u00e1 nie je pridelen\u00e1 \u017eiadnej…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"_links":{"self":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/362"}],"collection":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/comments?post=362"}],"version-history":[{"count":2,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/362\/revisions"}],"predecessor-version":[{"id":539,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/362\/revisions\/539"}],"wp:attachment":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/media?parent=362"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/categories?post=362"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/tags?post=362"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}