Modalità densa multicast è una modalità che multicast può utilizzare per costruire un albero per l’invio di pacchetti agli abbonati multicast. È un’alternativa alla modalità sparse.

L’ipotesi di base alla base della modalità densa è che il flusso di pacchetti multicast abbia ricevitori nella maggior parte delle posizioni. Modalità Sparse assume relativamente meno ricevitori. La modalità densa è ideale per i gruppi in cui molti dei nodi si iscriveranno per ricevere i pacchetti multicast, in modo che la maggior parte dei router debba ricevere e inoltrare questi pacchetti (gruppi ad alta densità).

Questa differenza si manifesta nel comportamento iniziale e nei meccanismi dei due protocolli. La modalità densa utilizza un approccio abbastanza semplice per gestire il routing multicast IP. La sorgente trasmette inizialmente a tutti i router direttamente collegati ad essa. Questi router vicini inoltrano ulteriormente i dati ai loro vicini. Quando un router non desidera ricevere i dati di questo gruppo (se non sono presenti altri router PIM vicini e nessun host è interessato al gruppo), invia un messaggio Prune per indicare la sua mancanza di interesse. Dopo aver ricevuto un messaggio Prune, il router modificherà il suo stato in modo che non inoltrerà quei pacchetti fuori quell’interfaccia. Se ogni interfaccia su un router viene potata, anche il router verrà potato.

Nelle versioni precedenti di Cisco IOS, PIM-DM ri-inonderebbe tutto il traffico multicast ogni 3 minuti. Questo va bene per multicast a basso volume, ma non per flussi di pacchetti multicast a larghezza di banda superiore. Le versioni più recenti di Cisco IOS supportano una nuova funzionalità chiamata PIM Dense Mode State Refresh, da 12.1 (5) T. Questa funzionalità utilizza un messaggio di aggiornamento dello stato PIM per aggiornare lo stato di Prune sulle interfacce in uscita. Un altro vantaggio è che le modifiche della topologia vengono riconosciute più rapidamente. Per impostazione predefinita, i messaggi di aggiornamento dello stato PIM vengono inviati ogni 60 secondi.

Inoltre, i router useranno l’inoltro del percorso inverso per garantire che non ci siano loop per l’inoltro dei pacchetti tra i router che desiderano ricevere pacchetti multicast. Quando un pacchetto di dati viene ricevuto su un’interfaccia non RPF, è necessario un meccanismo per impedire i loop. Se l’interfaccia non RPF è una LAN, viene inviato un messaggio Assert. I router non spedizionieri inviano quindi una prugna sulla loro interfaccia RPF se non hanno bisogno del flusso multicast. Solo una di queste prugne viene inviata, al momento della transizione verso l’assenza di interfacce nell’elenco delle interfacce in uscita (OILIST). Il ricevitore LAN Prune ritarda di agire su di esso per 3 secondi, in modo che se un altro router LAN ha ancora bisogno del flusso multicast, può inviare un messaggio PIM Join per contrastare (annullare) la prugna. (“Quel router non ne ha bisogno, ma lo faccio ancora!”)

Supponiamo che un router sia stato tagliato, e qualche tempo dopo un ricevitore richiede il flusso multicast con un messaggio IGMP. Il router invia quindi un messaggio di innesto. In effetti, “ehi, ho bisogno di quel flusso multicast qui ora”.