Tiheätila multicast on yksi tila, jota multicast voi käyttää rakentaakseen puun pakettien lähettämistä varten multicast-tilaajille. Se on vaihtoehto harvakseltaan.

perusoletus tiheän tilan takana on, että multicast-pakettivirrassa on vastaanottimia useimmissa paikoissa. Sparse mode olettaa suhteellisen vähemmän vastaanottimia. Tiheä tila on ihanteellinen ryhmille, joissa monet solmut tilaavat vastaanottaa multicast paketteja, niin että useimmat reitittimet on vastaanottaa ja välittää nämä paketit (ryhmät, joilla on korkea tiheys).

tämä ero näkyy kahden protokollan alkukäyttäytymisessä ja mekanismeissa. Tiheä tila käyttää melko yksinkertaista lähestymistapaa IP multicast-reitityksen käsittelyyn. Lähde lähettää aluksi jokaiseen reitittimeen, joka on suoraan yhteydessä siihen. Nämä naapurireitittimet välittävät tiedot edelleen naapureilleen. Kun reititin ei halua vastaanottaa tämän ryhmän tietoja (jos muita naapureita PIM-reitittimiä ei ole eikä ryhmä ole kiinnostunut isännästä), se lähettää Luumuisen viestin osoittaakseen kiinnostuksen puutteensa. Saatuaan Luumuviestin reititin muuttaa tilaansa niin, että se ei välitä kyseisiä paketteja kyseisestä rajapinnasta. Jos reitittimen jokaista liitäntää karsitaan, myös reititintä karsitaan.

vanhemmissa Ciscon IOS-julkaisuissa PIM-DM täyttäisi kaiken moniliikenteen uudelleen 3 minuutin välein. Tämä on hieno pieni määrä multicast, mutta ei suurempi kaistanleveys multicast pakettivirtoja. Uudemmat Ciscon IOS-versiot tukevat uutta ominaisuutta nimeltä PIM Dense Mode State Refresh, koska 12.1 (5) T. Tämä ominaisuus käyttää PIM state refresh-viestejä Prune-tilan päivittämiseen lähtevillä rajapinnoilla. Toinen etu on, että topologian muutokset tunnistetaan nopeammin. Oletusarvoisesti PIM-tilan päivitysviestit lähetetään 60 sekunnin välein.

lisäksi reitittimet käyttävät käänteispolkujen välitystä varmistaakseen, että pakettivälitykselle ei ole silmukoita reitittimissä, jotka haluavat vastaanottaa monilähetyspaketteja. Kun datapaketti vastaanotetaan muulla kuin RPF-rajapinnalla, tarvitaan mekanismi silmukoiden estämiseksi. Jos muu kuin RPF-käyttöliittymä on LAN, lähetetään Assert-viesti. Ei-huolitsija reitittimet sitten lähettää luumu niiden RPF käyttöliittymä, jos ne eivät tarvitse multicast stream. Vain yksi tällainen luumu lähetetään, kun siirrytään siihen, että lähtevien rajapintojen luettelossa (Oilist) ei ole rajapintoja. LAN Prune-vastaanotin viivyttää sitä 3 sekuntia, niin että jos toinen LAN-reititin tarvitsee vielä multicast-virtaa, se voi lähettää Pim Join-viestin luumun vastapainoksi (peruuta). (”That router doesn’ t need it, but I still do!”)

Oletetaan, että reititin on karsinut, ja jonkin ajan kuluttua vastaanotin pyytää multicast streamia IGMP-viestillä. Tämän jälkeen reititin lähettää Siirtoviestin. Itse asiassa, ”Hei, tarvitsen sen multicast stream täällä nyt”.