Hlavní navigace

Úvod do IP multicastu (díl čtvrtý)

29. 10. 2004
Doba čtení: 8 minut

Sdílet

Dnes si povíme o možnosti klientů se přihlásit či odhlásit z určité skupiny tak, aby se to příslušný router dozvěděl a mohl se podle toho chovat. K tomu se používá protokol IGMP - verze 1, která je sice zastaralá, ale stále se ještě používá, dnes ale i novější verze 2 a 3. Také si povíme, jak se routery a klienti chovají, jsou-li v síti namixovány různé verze.

Minulý článek vyprávěl o různých multicastových dynamických routovacích protokolech a přitom zcela opomíjel způsob, kterým klienti oznámí členství v jednotlivých skupinách. Dnes se pokusíme tento nedostatek napravit.

Ještě než se pustíme do vlastního protokolu, povíme si něco o adresách používaných v IP multicastu. Jak již zde bylo zmíněno, pro adresaci IP multicastových skupin se používají adresy binárně začínající na 1110, tedy decimálně vyjádřeno 224.0.0.0 – 239.255.255.255­. Tento rozsah je ještě dále vnitřně členěn:

  • Lokální linkové (Link-Local) adresy jsou z rozsahu 224.0.0.0 – 224.0.0.255. Pac­kety posílané na adresy z tohoto rozsahu nesmí být forwardovány dále a tyto adresy tedy slouží pro adresování stojů v lokální síti. Obvykle mají specifický význam, ktery je zaznamenán v databázi IANA. Jako příklad uvedu jen pár z nich:
    • 224.0.0.1 – všechny multicastové stroje v dané lokální síti,
    • 224.0.0.2 – všechny multicastové routery v dané lokální síti,
    • 224.0.0.5 – všechny OSPF routery v dané lokální síti,
    • 224.0.0.6 – všechny designované OSPF routery v dané lokální síti,
    • 224.0.0.22 – všechny multicastové routery v dané lokální síti, které podporují IGMPv3 (Internet Group Management Protocol).
  • Zvláštní rezervované adresy jsou z rozsahu 224.0.1.0 – 224.0.1.255. IANA je obvykle přiděluje významným síťovým službám, jako je třeba 224.0.1.1 pro NTP. Tyto adresy se již forwardují běžně.
  • Adresy s administrativně omezeným rozsahem (Administratively Scoped) patří do rozsahu 239.0.0.0 – 239.255.255.255 a měly by se používat v privátních sítích. Jejich použití je tedy obdobné jako např. u adres 10.0.0.0/8 a podobných, definovaných v RFC-1918.

Internet Group Management Protokol

Základem pro IGMP byl Host Membership Protokol, který navrhl Steve Deering ve své doktorské práci. Verzi nula popisuje RFC-988, kdysi hojně používanou verzi 1 Deering popsal v RFC-1112, další pokračování je v RFC-2236 a zatím poslední verzi 3 popisuje v RFC-3376. Tento protokol především používají multicastoví klienti, aby signalizovali routerům své členství v multicastových skupinách. Nicméně není to jen jediné jeho využití, používá ho například i protokol DVMRP pro přenos svých zpráv a pod.

IGMPv1

Možná se zdá být trochu zbytečné popisovat protokol verze 1, který už je poměrně zastaralý, ale bohužel ještě existuje měřitelná skupina (naštěstí se již rychle zmenšující) operačních systémů, které verzi 1 používají. Je tedy nutné tuto verzi znát a rozumět jejím omezením. Ještě mnohem silněji to pochopitelně platí u verze 2.

Formát IGMP zprávy je poměrně jednoduchý. Po IP hlavičce následuje tato sekvence osmi bytů:


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Type  |    Unused     |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Group Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Význam jednotlivých políček je následujíci:

  • Version – aktuální verze protokolu (1),
  • Type – tato verze podporuje pouze dva typy zpráv:
    • Membership Query, kód 1,
    • Membership Report, kód 2,
  • Unused – nepoužito, při posílání by mělo být nastaveno na 0 a při příjmu ignorováno,
  • Checksum – kontrolní součet IGMP zprávy,
  • Group Address – u zprávy Membership Report obsahuje toto pole multicastovou adresu, jinak by mělo být nastaveno na 0.0.0.0.

Protokol má jednoduché schéma Query-Report. Pokud se nějaký klient chce připojit k multicastové skupině a pošle zprávu typu Membership Report s vyplněným číslem skupiny na adresu té skupiny, příslušný router by ji měl zachytit a postarat se o zprostředkování. Router si průběžně kontroluje členství klientů ve skupinách a občas (jednou za 60 sekund) pošle zprávy typu Membership Query na adresu 224.0.0.1 a čeká na Reporty klientů. Protože je běžné, že klientů pro jednu skupinu je v síti více, byl navržen mechanismus, který zaručí, že pro každou skupinu dorazí pouze jediný Report. Každý z klientů, který uslyší Query, si zvolí náhodné číslo v rozsahu 0–10. Toto číslo vyjadřuje čas v sekundách, za který chce poslat Report. Zároveň ale poslouchá, zda nějaký jeho kolega Report pro danou skupinu pošle. Pokud se tak stane, klient už nic neposílá.

V případě, že klient danou skupinu opustí, přestane jednoduše odpovídat na Query. Pokud router nedostane pro skupinu třikrát po sobě žádný Report, přestane ji posílat. Query se posílají obvykle jednou za minutu – v nejhorším případě tedy router posílá data ještě tři minuty po té, co už o ně nikdo nestojí. Tento jednoduchý mechanismus je velmi nevýhodný, pokud klient často mění členství ve skupinách. V takovém případě může sít snadno přetížit.

IGMPv2

Zprávy IGMPv2 vypadají jakoby nekompatibilně s předchozí verzí. Obsahují trochu jiná políčka:


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     | Max Resp Time |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Group Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Jejich význam je následujíci:

  • Type – hodnoty totoho pole jsou voleny tak, aby bylo možné rozeznat zprávy IGMPv1, které na tomto místě mají políčka dvě – version a type. Protokol rozeznává následující typy zpráv:
    • Membership Query – vlastně jsou dvě, General Query a Group-specific Query, rozlišení se dělá podle obsahu políčka Group Address, číselný kód zprávy je 11, tedy zpráva vypadá podobně jako IGMPv1 Query,
    • IGMPv1 Membership Report – pro zpětnou kompatibilitu, kód zprávy 12,
    • IGMPv2 Membership Report, kód 16,
    • Leave Group, kód 17,
  • Max Resp Time – používá se u Query zprávy a označuje maximální čas na zaslání reportu v desetinách sekundy. Mechanismus je stejný jako u IGMPv1,
  • Checksum – kontrolní součet IGMP zprávy,
  • Group Address – u zpráv Membership Report, Leave Group a Group-specific Query obsahuje toto pole multicastovou adresu, jinak by mělo být 0.0.0.0. Z toho je vidět, že zpráva General Query u IGMPv2 je až na pole Max Resp Time shodná s Membership Query u IGMPv1.

Signalizace přihlášení do skupiny je obdobná jako u IGMPv1. Novinkou je proces opuštění skupiny. Klient může poslat zprávu (a obvykle posílá) Leave Group. Router na takovou zprávu zareaguje posláním Group-specific Query do dané skupiny. Max Resp time je obvykle nastaven na 1 sekundu. Pokud je ještě někdo členem skupiny, odpoví, a router pokračuje v posílání dat.

Další novinkou je volba routeru, ktery posílá Query. Je-li na síti více routerů, je pro posílání Query vybrán ten s nejvyšším IP. Ostatní pouze poslouchají a jsou připraveni převzít jeho roli. Mechanismus pracuje tak, že pokud router uslyší Query zprávu od routeru s vyšším IP, přestane ty své sám posílat a čeká 400 sekund, zda nepřijde další. Pokud nepřijde, vyhodnotí, že vybraný server už asi nefunguje, a začne posílat Query sám, čímž proběhnou nové volby. V IGMPv2 se Query posílá jednou za 125 sekund.

IGMPv2 je zpětně kompatibilní s IGMPv1. Pokud klienti detekují IGMPv1 router dle jeho Query, začnou posílat zprávy také v IGMPv1 a nastaví si časovač na 400 sekund. Pokud nastavený interval uplyne, začnou opět posílat IGMPv2. Naopak server je schopen obsloužit mix IGMPv1 i IGMPv2 klientů, protože umí jejich zprávy rozlišit. IGMPv1 klienti nepoznají žadný rozdíl. Pokud router detekuje IGMPv1 klienty na síti, ignoruje Leave Group zprávy.

IGMPv3

Specifikace IGMPv3 dokázala zatím ještě zhruba přehlednou situaci výrazně zkomplikovat. Problém, který se tato verze snaží řešit, je v tom, že pokud jste členem nějaké multicastové skupiny, nechcete často přijímat zprávy od všech, ale pouze od vybraných zdrojů. Proto se v IGMPv3 nepřihlašujete pouze do skupiny (*, G), ale přihlašujete se k odběru dat z konkrétního zdroje v dané skupině (S, G). Přirozeně se výrazně změnil i formát zpráv. Zprávy již nemají konstantní délku, jako tomu bylo u předchozích verzí. Přesný popis formátu by sám zabral nejméně jeden článek, takže jej vypustíme. IGMPv3 má své dvě vlastní zprávy a pro zpětnou kompatibilitu rozumí dalším třem:

  • Membership Query – kód 11,
  • IGMPv3 Membership Report – kód 22,
  • IGMPv1 Membership Report – kód 12,
  • IGMPv2 Membership Report – kód 16,
  • IGMPv2 Leave Group – kód 17.

Význam zpráv je stejný jako u předchozích verzí, pouze se přidávájí políčka pro členství ve skupinách. Také se trochu změnil význam políčka Max Resp Time. Nyní se jmenuje Max Resp Code a pokud je jeho hodnota nižší než 128, význam se nemění. Pokud se ale používá vyšší hodnota (první bit je 1), změní se význam na:


   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |1| exp | mant  |
  +-+-+-+-+-+-+-+-+




Max Resp Time = (mant | 0x10) << (exp + 3) 

IGMPv3 Report se také neposílá do příslušné skupiny, ale na adresu 224.0.0.22.

BRAND24

Prvních 8 bytů Query zprávy je stejných jako u předchozích verzích, takže klienti s nižší verzí protokolu nepoznají rozdíl a odpoví zprávou Report v odpovídající verzi. Router pak zachází s každou skupinou dle verze přihlášených klientů. Pokud se tedy do stejné skupiny na stejné síti přihlásí IGMPv2 i IGMPv3 klient, router nebude provádět filtrování zdrojových adres a bude posílat všechna data skupiny. Naopak pokud klient dostane zprávu délky 8 bytů, ví, že jeho router používá IGMP nižší verze, a přizpůsobí se mu.

V přístím díle téma IGMP ještě zcela neopustíme, povíme si, jak s IP multicastem pracuje v L2 sítích.

Setkáváte se v praxi s multicastem?

Byl pro vás článek přínosný?

Autor článku

Autor je výkonným ředitelem CZ.NIC a členem představenstva NIX.CZ. Ve volném čase se věnuje vývoji routovacího démona BIRD.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).