Hlavní odlišnost je v tom, že s cílovou adresou packetu router nevystačí. Jeho rozhodnutí co dál je ovlivněno ještě tím, jakou má ten packet zdrojovou adresu a z jakého interface mu přišel.
Proč je to tak komplikované? Jak již bylo zmíněno minule, při multicastovém forwardování je nutné ošetřit více věcí. Protože se packet duplikuje, je nutné pečlivě hlídat, aby těchto duplikací nebylo příliš a aby packet k příjemci došel pouze v jednom exempláři a nikoliv vícekrát. Pokud by se toto dělo, zátěž sítě by mohla být i vyšší než u obyčejného unicastu.
Jak by se to mohlo stát? Pokud bychom to nehlídali, tak poměrně snadno. Představme si model velmi podobný unicastovému světu, ve kterém by si každý router postavil pouze tabulku destinací, kde se nacházejí příjemci dané multicastové skupiny. Pokud by mu někdo zaslal packet určený pro takovou skupinu, prostě by jej jen rozeslal na všechny interface, kde se takoví příjemci nacházejí. Následující sekvence obrázků ilustruje, jak by taková situace mohla vypadat.
Jak vidíte, packet se neustále množí. Díky neustálému snižování parametru TTL (Time To Live) by se sice nemnožil navěky, ale rozhodně by spotřeba pásma byla několikanásobně vyšší, než je nutné. Stejně tak koncová zařízení dostanou svou zprávu několikrát, což se zbytečně zatěžuje.
Mnoho lidí jistě napadne jednoduchá úprava, že by tedy router neposílal packet zpět na interface, ze kterého ten packet obdržel. Taková situace je o něco lepší – k nadměrné duplikaci by v některých jednoduchých sítích nedocházelo, ale obecně nám to nepomůže. Tento příklad ilustruje následující sekvence.
Jak je vidět, stále to ještě není ono. Sice nám v tomto primitivním konkrétním případě packety vymizely dříve, než zasáhl mocný mechanismus TTL, nicméně každý si jistě umí představit topologii, kde tomu tak nebude. Navíc i zde bylo zatížení sítě vyšší, než je nutné, a opět jsou koncová zařízení otravována duplicitními packety.
Proto byl vymyšlen způsob, kterému se říká Reverse Path Forwarding (RPF). Router si stále drží unicastovou routovací tabulku. Tuto tabulku získává buď od operátora, z klasických routovacích protokolů (nebo jejich odvozenin, jako je MBGP), případně si ji sestavuje pomocí speciálních multicastových protokolů (například DVMRP). Často může jít i o více tabulek dohromady.
Pokud pak routeru přijde multicastový packet, zjistí si jeho zdrojovou adresu a interface, ze kterého přišel.
Potom otestuje, zda-li by stejným směrem poslal i unicastový packet, jehož cílová adresa by byla rovna té zdrojové u multicastového. Pokud test neprojde, packet je zahozen, v opačném případě packet pokračuje k dalším zpracování.
Raději se na to podívejme na příkladě. Představme si router A s následující routovací tabulkou:
Síť Maska Interface 192.168.0.0 255.255.255.0 eth0 192.168.1.0 255.255.255.0 eth1 192.168.2.0 255.255.255.0 eth2 192.168.3.0 255.255.255.0 eth3
Tento obrázek ukazuje situaci, kdy RPF test (anglicky RPF check) neuspěje:
Jak je vidět, packet se zdrojovou adresou 192.168.1.1 a cílovou adresou 225.1.1.1 přijde přes interface eth3. Unicastová routovací tabulka ale říká, že packety pro 192.168.1.1 by se posílaly přes interface eth1. Packet je tedy zahozen.
Naopak tento obrázek ukazuje situaci příznivější:
Packet přijde z interface, ze kterého je očekáván, a v dalším kroku tedy bude za odměnu rozeslán dle příslušné multicastové tabulky.
Router přirozeně nedělá toto rozhodnutí s každým packetem, to by ho velmi zatěžovalo. Obvykle je takto zkontrolován pouze první packet a záznam o tomto testu je uložen do cache. Testování následujících packetů je pak již mnohem rychlejší. Tuto cache je nutné obnovovat při změně unicastové routovací tabulky.
Forwardování tedy máme za sebou a v příštím díle si povíme něco více o tom, jak se routery dozví, kam mají packety rozesílat, tedy o multicastových dynamických routovacích protokolech.