V súvislosti s broadcastom sa používa pojem broadcastová doména, ktorá určuje množinu sietí a routrov, v ktorej sa majú šíriť broadcastové správy. Ak si vezmeme napríklad protokol OSPF, tak broadcastovú doménu tvoria všetky routre v AS.
Pri broadcastovom smerovaní je cieľom to, aby vyslanú správu dostali všetky uzly (stanice a/alebo routre) v broadcastovej doméne. Broadcastové správy sa nikdy nešíria pre celý internet, ale vždy len v rámci AS alebo v rámci siete. Broadcastové smerovanie sa realizuje buď pre celý AS alebo jeho časť.
Broadcast by sa dal realizovať aj tak, že každému uzlu v broadcastovej doméne pošleme kópiu správy priamo zo zdroja. Ak máme N uzlov, tak vyšleme N správ. Toto riešenie je síce jednoduché, ale neefektívne. Lepšie je, ak zdrojový uzol vyšle do každého spoja iba jednu správu a tá sa rozmnoží až po ceste tak, aby každý uzol dostal svoju kópiu a zároveň, aby žiaden uzol nemusel správu vysielať viackrát tým istým spojením.
Hlavným problémom broadcastového smerovania je teda zistenie, kedy je potrebné vytvárať kópie broadcastových správ a do ktorých spojov ich zasielať. Popíšeme si 3 prístupy k spôsobu broadcastového smerovania: nekontrolované zaplavenie, kontrolované zaplavenie a spanning tree (kostra grafu).
4.13.1 Nekontrolované zaplavenie
Tento prístup používa jednoduché pravidlo. Ak na router príde broadcastová správa, router vytvorí kópiu tejto správy a rozošle túto správu do všetkých rozhraní okrem toho, odkiaľ správa prišla. Tento prístup môže fungovať úplne bezchybne pokiaľ sa v grafe tvorenom routrami a spojmi nevyskytuje cyklus. Vezmime si vyššie nakreslený obrázok. Ak router R1 vyšle správu, dostane ju R2 a rozošle ju k R3 a R4. R3 dostal správu od R2 takže ju pošle na všetky ostatné rozhrania, teda k routru R4, ten ju prepošle opäť k R2, ktorá ju zas prepošle k R1 a R3. Takáto situácia vyústi k nekonečnému cykleniu dvoch správ, jednej v smere a druhé proti smeru hodinových ručičiek. Ak však máme v grafe viac cyklov, dochádza k nekontrolovanému množeniu broadcastových správ. Takému javu hovoríme broadcastová búrka, ktorá vedie k úplnému zahlteniu všetkých routrov v broadcastovej doméne.
4.13.2 Kontrolované zaplavenie
Kľúčom k zabráneniu nekonečných rozosielaní pri kontrolovanom zaplavovaní je zistenie routra, že danú správu už raz rozosielal a nebude to robiť opäť.
Jedným riešením je, že každý pôvodný odosielateľ správy pribalí k správe aj jedinečné číslo broadcastovej správy. Každý uzol si potom musí pamätať všetky čísla správ, ktoré už rozosielal a v prípade, že už áno, tak ich druhýkrát nerozošle. Tento prístup využíva Gnutella.
Druhý prístup ku kontrolovanému zaplaveniu je reverse path forwarding (RPF). Idea RPF je jednoduchá. Pokiaľ príde na nejaký uzol broadcastová správa, tak ju rozpošle cez všetky rozhrania okrem prijímajúceho iba vtedy, ak táto správa prišla cez rozhranie, ktoré je súčasťou najkratšej unicastovej cesty k zdrojovému uzlu. V opačnom prípade je správa zahodená. Využíva teda smerovaciu tabuľku určenú pre unicastové smerovanie. Toto využitie je tak trochu obrátené, lebo smerovacia tabuľka nastavuje smerovanie odchádzajúcich správ a pri RPF filtrujeme prichádzajúce broadcastové správy. Na nasledujúcom obrázku môžeme vidieť, ako sa bude šíriť broadcastová správa z uzla A do celého grafu pri použití RPF. Hrubou čiarou sú naznačené spoje, ktoré sú na najkratšej ceste od jednotlivých uzlov k uzlu A. Šípky s obdĺžničkom označujú správy, ktoré budú prijímajúcim routrom zahodené.
4.13.3 Spanning tree (kostra grafu)
Aj keď predchádzajúce techniky zabraňujú broadcastovým búrkam, predsa len sa stáva, že niektoré uzly dostanú viac kópií tej istej správy. Riešením aj tohto nedostatku je práve smerovacia schéma spanning tree.
Pri spanning tree sa ešte pred odoslaním prvej broadcastovej správy musí vyrobiť strom rozosielania obsahujúci všetky uzly. Hrany tohto stromu tvoria vybrané spojenia medzi uzlami. Ak je už strom rozosielania hotový, broadcastové správy sa šíria iba pozdĺž hrán tohto stromu. Keďže ide o strom, neexistujú v ňom cykly a každý uzol dostane vždy iba jednu kópiu broadcastovej správy.
Samozrejme je ideálne, ak tento strom bude minimálny. Určite si spomínate na minimálnu kostru grafu, ktorá sa preberala v predmete PAZ1b. Kruskalov algoritmus, ktorý sa na PAZ1b preberá, však vyžaduje úplnú znalosť topológie siete. Metóda spanning tree negeneruje vždy minimálny strom. Pred vytvorením stromu sa uzly musia dohodnúť, ktorý z uzlov grafu bude centrálny uzol (nazývaný aj rendezvous point). Potom všetky uzly pošlú pripájaciu unicastovú správu smerom k centrálnemu uzlu. Ako správa prechádza jednotlivými routrami na ceste k centrálnemu uzlu, routre si zaznačujú, že hrany, po ktorých prešla, sú súčasťou stromu. Ak takáto správa dôjde na uzol, ktorý už je súčasťou stromu, správa sa zahadzuje, lebo by aj tak šla iba po tých spojeniach, ktoré už sú súčasťou stromu. Tým pádom aj na vytvorenie stromu je potrebné poslať iba toľko správ, koľko je hrán vo výslednom strome, a teda toľko správ, ako pri šírení už bežnej broadcastovej správy.