sűrű mód a multicast egy olyan mód, amelyet a multicast felhasználhat egy fa létrehozására csomagok küldésére a multicast előfizetőknek. Ez a ritka mód alternatívája.
a sűrű mód mögött az az alapfeltevés áll, hogy a multicast csomagfolyamnak a legtöbb helyen van vevője. A ritka mód viszonylag kevesebb vevőt feltételez. A sűrű mód ideális olyan csoportok számára, ahol sok csomópont feliratkozik a multicast csomagok fogadására, így a legtöbb útválasztónak ezeket a csomagokat kell fogadnia és továbbítania (nagy sűrűségű csoportok).
Ez a különbség a két protokoll kezdeti viselkedésében és mechanizmusaiban jelenik meg. A sűrű mód meglehetősen egyszerű megközelítést alkalmaz az IP multicast útválasztás kezelésére. A forrás kezdetben minden közvetlenül csatlakoztatott útválasztóra sugároz. Ezek a szomszédos útválasztók tovább továbbítják az adatokat szomszédaiknak. Ha egy útválasztó nem kívánja megkapni ennek a csoportnak az adatait (ha nincs más szomszédos PIM útválasztó, és egyetlen gazdagépet sem érdekel a csoport), akkor Prune üzenetet küld az érdeklődés hiányának jelzésére. A Prune üzenet fogadása után az útválasztó módosítja állapotát, hogy ne továbbítsa ezeket a csomagokat az interfészen. Ha az útválasztó minden interfészét metszik, akkor az útválasztót is metszik.
a régebbi Cisco IOS kiadásokban a PIM-DM 3 percenként újra elárasztja az összes multicast forgalmat. Ez rendben van kis volumenű multicast esetén, de nem nagyobb sávszélességű multicast csomagfolyamok esetén. Az újabb Cisco IOS verziók támogatják a PIM sűrű módú Állapotfrissítés nevű új funkciót, mivel 12.1(5)T. Ez a funkció PIM állapotfrissítési üzeneteket használ a Prune állapot frissítéséhez a kimenő interfészeken. További előny, hogy a topológia változásait gyorsabban felismerik. Alapértelmezés szerint a PIM állapotfrissítési üzenetek 60 másodpercenként kerülnek elküldésre.
ezenkívül az útválasztók fordított irányú továbbítást fognak használni annak biztosítására, hogy a multicast csomagokat fogadni kívánó útválasztók között ne legyenek hurkok a csomag továbbításához. Ha egy adatcsomagot nem RPF interfészen fogadnak, a hurkok megakadályozásához mechanizmusra van szükség. Ha a nem RPF interfész LAN, akkor egy Assert üzenet kerül elküldésre. A nem szállítmányozó útválasztók ezután Prune-t küldenek az RPF felületükön, ha nincs szükségük a multicast folyamra. Csak egy ilyen aszalt szilva kerül elküldésre, abban az időben, amikor nincs interfész a kimenő interfész listában (OILIST). A LAN Prune vevő 3 másodpercig késlelteti a műveletet, így ha egy másik LAN útválasztónak továbbra is szüksége van a multicast folyamra, akkor PIM csatlakozási üzenetet küldhet az aszalt szilva ellensúlyozására (visszavonására). (“Ennek az útválasztónak nincs szüksége rá, de még mindig van!”)
tegyük fel, hogy egy útválasztó metszett, és valamivel később egy vevő kéri a multicast adatfolyamot IGMP üzenettel. Az útválasztó ezután Graft üzenetet küld. Valójában, “Hé, szükségem van arra a multicast streamre itt most”.