Multicast : PIM-Dense Mode, PIM-Sparse Mode and PIM-Bi-directional

 Today I am going to talk about multicast for the beginners. I will talk about PIM Dense Mode (PIM-DM) and PIM Sparse Mode (PIM-SM). Thanks for such a huge support for the articles, we will try our best to cover most of the articles based on the queries you asked. 

Bidirectional PIM (PIM-BiDir)
We have Bidir PIM, which is also a variation of sparse-mode, and the opposite of SSM. So in Bidir, which is primarily intended for many to many applications with a very large number of sources, we eliminate all S,G state and forward all traffic based only on the shared tree, which is rooted at the RP.

So what this means is, regardless of the number of sources sending to a particular group, you have only one forwarding entry in the mroute table, the *,G entry for that group. And, multicast traffic flows both down and UP the multicast distribution tree, so that’s the bidir part, the mcast distribution tree is bidirectional, traffic flows up and down the tree.

Fig 1.1- Bidirectional PIM

Now we do support bidir in software on Sup2, but the key here is that PFC3, which we have on Sup32 and Sup720, or PFC4, which we have on Sup2T supports hardware bidir forwarding, so we’ll touch on that here & there in the session, how it’s a bit different in the hardware.

PIM Dense Mode (PIM-DM)
Now let’s very quickly touch on the important multicast protocols, starting with PIM dense mode. This was the first implementation of PIM, and uses a simple Flood & Prune design and assumes most (or all) PIM routers have some receivers.

The FHR will simply Flood S,G traffic to all PIM neighbors, who must then Prune if they do not have local receivers. The Flood / Prune repeats every 3 minutes.

Fig 1.2- PIM-Dense Mode

IGMPv1 was also introduced at this time, but IGMPv2 is typically used for receiver signalling.

And of course, Supervisor 2, Supervisor 32, Supervisor 720 and Supervisor 2T all support PIM dense-mode forwarding in hardware, for S,G mroute entries.

PIM Sparse Mode (PIM-SM)
Now let’s quickly touch on PIM sparse mode, which is really the workhorse protocol. It’s a general purpose multicast routing protocol that works with your unicast routing protocol to create loop free multicast distribution trees, both shared trees, rooted at the rendezvous point or RP, and source based trees, rooted at the multicast source.

Fig 1.3- PIM-Sparse Mode

Now IGMPv2 is typically used for receiver signalling in sparse mode, but any of the 3 versions of IGMP can be used to signal group membership in a sparse mode network. MLDv1 or v2 is used for IPv6 PIM-SM.

And of course, Supervisor 2, Supervisor 32, Supervisor 720 and Supervisor 2T all support PIM sparse-mode forwarding in hardware, for S,G mroute entries.

PIM Dense Mode (PIM-DM) Vs PIM Sparse Mode (PIM-SM)

DM multicast traffic goes to ALL routers first before the routers decide to prune themselves from the tree. This means an (S,G) state is instantiated on all routers.This is where the “flood and prune” term come from. This happens for all multicast streams which means before state refresh can kick in to keep pruned links pruned, the traffic has already reached every router which is inefficient.

Even after state refresh takes effect, you are utilizing router resources to maintain the prune state and send the state refresh messages. Additional overhead and resources for the routers in question. All of this adds to how DM is inefficient with resources. 

The routers must remember that they are not part of the tree in order to signal they are not part of the tree. This means the (S,G) state is instantiated on all multicast routers regardless of whether they have receivers for the (S,G) state.

Contrast with SM where multicast routers must signal to join the tree. This constrains the multicast flows to only the places where it must travel to reach the intended receivers. (S,G) or even (*,G) states are only created on routers that need to handle the multicast flow. We save router resources and bandwidth with SM.

This is because of the assumptions the two operating modes make. Dense Mode assumes there are more multicast group members compared to the number of total hosts in the network. In other words, if there are 100 hosts then probably 90 or more of these hosts are joined to a multicast group. Sparse Mode is the opposite. If there are 100 hosts, then maybe only 10 of them are joined to a multicast group.

If you assume most hosts are joined to a multicast group, then sending the traffic everywhere first make sense. If you assume most hosts are not joined to a multicast group then waiting for a host to ask make sense.