tät läge multicast är ett läge som multicast kan använda för att konstruera ett träd för att skicka paket till multicast abonnenter. Det är ett alternativ till gles läge.

det grundläggande antagandet bakom det täta läget är att multicast-paketströmmen har mottagare på de flesta platser. Sparsamt läge förutsätter relativt färre mottagare. Tätt läge är idealiskt för grupper där många av noderna kommer att prenumerera på att ta emot multicast-paketen, så att de flesta routrarna måste ta emot och vidarebefordra dessa paket (grupper med hög densitet).

denna skillnad visar sig i de två protokollens initiala beteende och mekanismer. Tät läge använder en ganska enkel metod för att hantera IP multicast routing. Källan sänder ursprungligen till varje router som är direkt ansluten till den. Dessa angränsande routrar vidare vidarebefordra data till sina grannar. När en router inte vill ta emot denna grupps data (om inga andra närliggande PIM-routrar finns och ingen värd är intresserad av gruppen) skickar den ett Beskär meddelande för att indikera dess brist på intresse. Efter att ha fått ett Prune-meddelande kommer routern att ändra sitt tillstånd så att det inte kommer att vidarebefordra dessa paket ut det gränssnittet. Om varje gränssnitt på en router beskärs kommer routern också att beskäras.

i äldre Cisco IOS-utgåvor skulle PIM-DM översvämma all multicast-trafik var 3: e minut. Detta är bra för multicast med låg volym, men inte multicast-paketströmmar med högre bandbredd. Nyare Cisco IOS versioner stöder en ny funktion som kallas PIM tät läge State Refresh, eftersom 12.1(5)T. den här funktionen använder en PIM State refresh meddelanden för att uppdatera beskära tillstånd på utgående gränssnitt. En annan fördel är att topologiförändringar erkänns snabbare. Som standard skickas PIM state refresh-meddelanden var 60: e sekund.

dessutom kommer routrarna att använda vidarebefordran av omvänd väg för att säkerställa att det inte finns några slingor för vidarebefordran av paket bland routrar som vill ta emot multicast-paket. När ett datapaket tas emot på ett icke-RPF-gränssnitt krävs en mekanism för att förhindra slingor. Om gränssnittet som inte är RPF är ett LAN skickas ett Assert-meddelande. Routrar som inte är speditörer skickar sedan en beskärning på deras RPF-gränssnitt om de inte behöver multicast-strömmen. Endast en sådan beskärning skickas vid övergången till att inte ha några gränssnitt i utgående gränssnittslista (OILIST). Lan Prune-mottagaren fördröjer att agera på den i 3 sekunder, så att om en annan LAN-router fortfarande behöver multicast-strömmen, kan den skicka ett PIM-Anslutningsmeddelande för att motverka (avbryta) Prune. (”Den routern behöver inte det, men det gör jag fortfarande!”)

Antag att en router har beskuren, och någon gång senare begär en mottagare multicast-strömmen med ett IGMP-meddelande. Routern skickar sedan ett Transplantatmeddelande. I själva verket, ”Hej, jag behöver den multicast-strömmen här nu”.