Všechny předchozí díly se zatím zabývaly pouze vlastní strukturou a vlastnostmi IP multicastu. Tento díl nás zavede poněkud hlouběji, do nižších síťových vrstev. Ukážeme si, jaké problémy přináší transportování IP multicastu L2 sítěmi, tedy především ethernetem.
Multicastové ethernetové rámce se od těch běžných poznají celkem snadno. Cílová adresa takového rámce má nastaven nultý bit oktetu číslo 0 na jedničku. Tedy:
oktet 0 oktet 1 oktet 2 oktet 3 oktet 4 oktet 5
+--------+--------+--------+--------+--------+--------+
|xxxxxxx1|xxxxxxxx|xxxxxxxx|xxxxxxxx|xxxxxxxx|xxxxxxxx|
+--------+--------+--------+--------+--------+--------+
76543210 76543210 76543210 76543210 76543210 76543210
Speciálním případem je broadcastový packet, který má všechny bity nastavené na 1, tedy FF:FF:FF:FF:FF:FF.
Konkrétně v případě IP multicastu adresa odpovídajícího rámce začíná 25bitovým prefixem:
oktet 0 oktet 1 oktet 2 oktet 3 oktet 4 oktet 5
+--------+--------+--------+--------+--------+--------+
|00000001|00000000|01011110|0xxxxxxx|xxxxxxxx|xxxxxxxx|
+--------+--------+--------+--------+--------+--------+
76543210 76543210 76543210 76543210 76543210 76543210
tedy 01:00:5E a jeden bit. Pro mapování IP adresy do takovéto MAC adresy se používá zbylých 23 bitů. Jak se taková věc provede? Jak už jsme si říkali, každa multicastová IP adresa začíná bitovým prefixem 1110. Na rozlišení nám tedy zbývá 28 bitů. Mapování do MAC adresy nelze udělat beze ztráty a provede se tak, ze se prvních pět bitů z 28 uřízne a konec IP adresy se uloží do zbytku MAC adresy.
Tedy například IP 224.1.1.1 odpovídá MAC adresa 01:00:5E:01:01:01. Tato MAC adresa ovšem náleží i kupříkladu IP 224.129.1.1 nebo 225.1.1.1 a pod. Do jedné MAC adresy se tedy mapuje 25 = 32 IP adres.
Proč?
Je to poměrně zajímavý příběh. Na začátku devadesátých let, když Steve Deering pracoval na své práci o IP multicastingu, chtěl od IEEE delegovat 16 sousedních OUI (Organizational Unique Identifier – 24 bitový prefix z MAC adresního prostoru). Tím by získal prostor 28 bitů (každý OUI má 24 bitů a počet 16 přidá další 4 bity) a mohl by mapovat IP multicastové adresy jednoznačně. Tehdy ovšem stálo přidělení každého OUI $1000. Jeho nadřízený, Jon Postel, bohužel nebyl schopen takovou sumu vyplatit, a tedy koupil pouze jeden OUI a Deeringovi ještě přiřadil pouze jednu polovinu. Díky tomu tedy teď mapujeme více IP multicastových adres do jedné multicastové MAC adresy.
Pokud tedy nějaký počítač v síti chce poslat packet do nějaké multicastové skupiny, vypočte si příslušnou MAC adresu a v ethernetové síti takový packet pošle v odpovídajícím rámci. Příjemce zprávy už podle svého členství ve skupinách a cílové MAC může určit, bude-li rámec ignorovat, nebo jej přijme. Nicméně díky nedokonalému mapování se může stát, že rámec je předán vyšší vrstvě i v případě, kdy pro tento stroj určen není. Žádný zásadní problém kromě zbytečného vytěžování CPU to přirozeně nezpůsobuje, packet je odhalen a zahozen.
Starší a méně sofistikované ethernetové swiche obvykle rámce s IP multicastovými packety rozešlou na všechny své porty stejně jako broadcast. Tento způsob zacházení s IP multicastem je sice poměrně logický a jednoduchý, nicméně v rozsáhlejších L2 strukturách či při větších tocích může způsobovat značné problémy se zahlcováním sítě. Sofistikovanější switche tedy mívají způsob, jak IP multicast rozesílat pouze na porty, na kterých je očekáván. Způsobů, jak toho docílit, je více, nejrozšířenější z nich je IGMP snooping.
Jak už název napovídá, tato technika zkoumá obsah IGMP zpráv. Switch, který toho je schopen, tedy musí umět nejen zpracovávat L2 rámce, ale musí částečně rozumět i L3 packetům. Dále si musí udržovat ve své (asociativní) paměti tabulku IP multicastových MAC adres se seznamem portů s účastníky přihlášenými do odpovídající multicastové skupiny (a tedy vlastně odpovídajících IP multicastových skupin).
Jak to tedy pracuje?
Switch zpočátku rozesílá IP multicastový provoz pouze připojeným routerům a poslouchá veškeré IGMP zprávy. Pokud od nějakého počítače uslyší IGMP Report, přiřadí si záznam o jeho portu do paměti a začne mu posílat data pro příslušnou multicastovou skupinu. V minulém díle jsme si pověděli, že IGMP má mechanismus, který zajišťuje potlačení zbytečných zpráv typu IGMP Report. Každá taková zpráva je za normálních okolností do sítě zaslána pouze jedním z přihlášených. Ostatní ji slyší a již dál nic neposílají. V takovém případě by ale switch nevěděl o všech přihlášených a některým by neposílal data. Z tohoto důvodu switch nepřepošle IGMP Report zpět do sítě, takže na IGMP Query donutí odpovědět všechny účastníky, protože si každý z nich myslí, že je jediným příjemcem. Pouze jeden IGMP report je poslán routerům, aby dále posílaly data pro skupinu.
Naopak, pokud se chce některý počítač odhlásit ze skupiny, pošle zprávu IGMP Leave. Switch si nemůže být jistý, zda na tom jednom portu neměl připojeno více účastníků skupiny, a tak okamžitě pošle zpět na port zprávu IGMP General Query. Pokud na portu další zájemce o příslušnou skupinu není, switch ji přestane na daný port posílat. Pokud již skupinu nepřijímá žádný klient, switch přepošle zprávu IGMP Leave i routerům.
V běžném provozu, tedy pokud zrovna nikdo neopouští skupinu či se do ní nehlásí, posílá jeden z routerů periodicky zprávy IGMP Query. Switch každou zprávu přepošle na všechny porty a odpovědi (IGMP Report) si naopak nechává pro sebe a pouze si z nich občerstvuje svou tabulku. Nakonec pošle pouze jednu zprávu na porty, na které jsou připojeny routery.
Nyní už zbývá vysvětlit poslední nejasnost. Jak switch pozná, na které porty jsou připojené routery? Pouze podle toho, že router posílá IGMP Query, to bohužel nejde, protože v lokální síti je zvolen pouze jeden router, který tyto zprávy posílá, a ostatní „mlčí“. Switch si tedy musí poradit jinak. Obvykle sleduje nejen IGMP zprávy, ale poslouchá i ostatní IP packety, a pokud například uslyší packety protokolů PIM, DVMRP, OSPF, CGMP apod., pozná, že na příslušném portu je připojen router.
Jak je vidět, na druhou vrstvu nebylo příliš při návrhu IP multicastingu pamatováno a řešení v této oblasti byla až následně „uplácána“. V dalším díle se podíváme na oblast, která by již měla vypadat „učesaněji“, na multicastovou implementaci v IPv6.