Přeskočit na obsah

IP multicast

Z Wikipedie, otevřené encyklopedie

IP multicast (adresný oběžník) je metoda přeposílání IP datagramů z jednoho zdroje skupině více koncových stanic. Místo odesílání jednotlivých datagramů ke každému cíli je odeslán jediný datagram. IP směrování přenosu multicast bylo vyvinuto, aby doplnilo technologie unicast a broadcast, které účinně nezvládaly nové aplikace. Přenášené informace většinou bývají v podobě multimédií, dále pak to mohou například být opravy chyb v operačních systémech apod. Vzhledem k využívání multicastu pro přenos multimediálních dat (upřednostňujeme výpadky v příjmu před zpožděním dat), je pro přenos využíváno nespolehlivého protokolu UDP.

Metoda funguje na principu posílání informací (s IP adresou zdroje a adresou cílové skupiny) ze zdrojového uzlu přes spojení k síti (většinou routery) jen jedním datovým tokem a pokud je informace v lokální síti vyžadována, tak se informace do ní replikuje. Cílem zavedení multicastu je tedy zmenšení zátěže vysílajícího uzlu a přenosové sítě.

Typy multicastových IPv4 adres

[editovat | editovat zdroj]

K identifikaci jednotlivých multicastových skupin se používají IP adresy třídy D (224.0.0.0 – 239.255.255.255), v tomto rozsahu rozeznáváme tři typy adres:

  • Rezervované adresy (224.0.0.0 – 224.0.0.255) – pro lokální sítě, hodnota TTL je nastavena na 1, provoz tedy nemůže projít žádným routerem. (např. 224.0.0.1 – všechny prvky v LAN, 224.0.0.2 – všechny routery v LAN, atd.)
  • Administrativní adresy (239.0.0.0 – 239.255.255.255) – pro soukromé použití v rámci jedné sítě
  • Veřejné adresy (224.0.1.0 – 224.0.1.255, 224.0.2.0 – 238.255.255.255) – provoz může putovat napříč celým internetem, využívají například internetová rádia a televize.

Skupinové adresování

[editovat | editovat zdroj]

Aby cílová stanice mohla přijímat multicastová data, musí být přihlášena alespoň do jedné skupiny a samozřejmě router sítě musí multicasting podporovat, udržovat tedy v sobě tabulku skupin, které má odchytávat. Router, který přijímá informace z multicastových skupin, se od uzlů snaží zjistit, které skupiny mají být vysílány uzlům do bezprostředně připojené sítě. Tuto službu nám zajišťuje IGMP protokol, díky kterému se uzly mohou přidávat do skupin.

IGMP protokol

[editovat | editovat zdroj]

Protokol IGMP, definovaný v RFC 1112, dynamicky registruje jednotlivé hostitele, patřící do skupiny adres D. Hostitel identifikuje členství ve skupině odesláním zpráv protokolu IGMP a data zasílá vždy všem členům skupiny. Směrovače používající protokol IGMP pravidelně naslouchají zprávám protokolu IGMP a systematicky odesílají dotazy s cílem zjistit, které skupiny jsou v síti LAN aktivní. Směrovače spolu komunikují pomocí dalších protokolů a pro každou skupinu připravují cesty pro spoje s přenosem typu multicast.

Směrování

[editovat | editovat zdroj]

O zaslaném multicastovém paketu se musí dozvědět i koncový uzel velmi vzdálený od zdroje, k tomu se používá směrování. Při směrování multicastových paketů se nepoužívají standardní směrovací protokoly, protože jednotlivé uzly patřící do multicastových skupin často vznikají a zanikají. Jedny z používaných směrovacích protokolů k identifikaci skupin náležejících k přenosu multicast a k vytváření cest pro každou skupinu jsou PIM (Protocol Independent Multicast), DVMRP (Distance Vector Multicast Routing Protocol) a MOSPF (Multicast Open Shortest Path First).

Nezávislý protokol PIM

[editovat | editovat zdroj]

Tento protokol je popsán v RFC 2362 a popisuje dva režimy chování pro:

  • Hustý provoz - kde PIM využívá proces reverzního zaplavování cesty.
  • Režim PIM pro řídký provoz - je navržen pro sítě s mnoha datovými toky, ale s malým počtem LAN. Definuje společné místo v síti (rendezvous point), které se používá jako registrační bod pro usnadnění správného směrování paketů.

Směrovací protokol multicast s vektorem vzdálenosti DVMRP

[editovat | editovat zdroj]

Protokol používá reverzní techniku zaplavování cesty. Je definován v RFC 1075 a je základem pro páteřní IP síť. Protokol má některé nedostatky, např. špatně se přizpůsobuje škálování sítě, což má za následek násobné zaplavování, hlavně u verzí bez pročisťovacího algoritmu. Zpětné zaplavování cesty vyžaduje, aby směrovač odeslal kopii paketu při jeho přijetí do všech cest. Poté směrovač odešle zpět zprávu ke zdroji, aby zastavil datový tok, pokud je směrovač napojen na LAN, jenž si nepřeje přijímat data příslušné skupiny s přenosem multicast.

Další metody DVMRP protokolu:

  • Opětovné zaplavování, kdy DVMRP směrovače periodicky znovu zaplavují síť, s cílem dosáhnout žádaného nového hostitele. Zaplavovací mechanismus bere v úvahu frekvenci a dobu zaplavování, nutnou pro nového člena skupiny multicast, aby mohl zahájit příjem skupinového datového toku.
  • DVMRP unicast se používá ke stanovení rozhraní, které vede zpět ke zdroji datového toku.

Protokol první nejkratší cesty s přenosem multicast MOSPF

[editovat | editovat zdroj]

Používá směrovací protokol s unicastovou adresací a požaduje po každém směrovači v síti, aby znal všechna dostupná spojení. Směrovač MOSPF vypočítává cestu od zdroje ke všem členům skupiny. Jakmile směrovač přijme provoz, vypočtená cesta je uložena do doby, než dojde ke změně topologie a novému výpočtu.

Multicast v LAN síti (L2 multicast)

[editovat | editovat zdroj]

Každá IP adresa se v síti musí překládat na MAC adresu tedy i multicastová, právě díky této adrese se přenáší multicastová data v lokální síti. Zde však nastává problém v možné nejednoznačnosti, protože 48bitová MAC adresa musí mít pro multicast prefix 01:00:5e následovaný nulovým bitem a zbylých 23 bitů MAC adresy je vyplněno posledními 23 bity IP adresy. Více stejně končícím IP adresám je tak přiřazena stejná multicastová MAC adresa. Tento problém se někdy nazývá 32-to-1 overlapping, protože právě 32 multicastových IP adres je mapováno na jedinou multicastovou MAC adresu.

Literatura

[editovat | editovat zdroj]
  • JIROVSKÝ, Václav. Vademecum správce sítě. Praha: Grada, 2001. ISBN 80-7169-745-1. 

Externí odkazy

[editovat | editovat zdroj]
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy