Hour 102: PIM Dense Mode vs PIM Sparse Mode Part 2

In my previous post, I made an analogy comparing PIM-DM to PIM-SM. In this Part, I will describe in technical detail how exactly PIM-DM and PIM-SM work. Before talking about PIM-DM and PIM-SM it’s important to do a quick review of the Internet Group Management Protocol (IGMP), routing protocol considerations and Neighbor Discovery process.

IGMP is used to establish multicast group memberships from hosts to routers. A host will send an IGMP join message (IGMP membership report) in order to join a multicast group. It is important to remember that PIM is a communication protocol used between routers and IGMP is used from hosts to routers.

A routing protocol must be configured throughout the network in order to ensure that all devices can communicate with each other using unicast communications. PIM relies on unicast routing to forward multicast traffic because a unicast routing table is needed to perform Reverse Path Forwarding (RPF) checks. RPF checks are a mechanism in which unicast is used to determine the closest interface on a multicast router that leads to the source of a multicast transmission. Similarly to split-horizon, RPF checks prevent multicast loops in the network by ensuring that multicast traffic received is forwarded only if the traffic has been received on the closest interface.

The first step that happens in a PIM multicast network is the Neighbor Discovery (ND) event. Each multicast router will announce itself by multicasting PIM Hello messages every 30 seconds (by default) to the group address, which is a reserved address for all PIM routers. All routers on the segment that hear Hello messages both ways will form an adjacency with each other. In a multi-access network, similarly to OSPF, if multiple PIM routers are attached to the segment a Designated Router (DR) will be elected. The same election rules that OSPF uses apply to PIM.


In PIM-DM the DR is not actually used unless the hosts are using IGMPv1. In IGMPv1 the DR is selected to perform the Querier role, which is responsible for determining if receivers exist on the network for a specific group address (Since IGMPv1 doesn’t have a query router election).

Step 1. Source generates multicast traffic

Step 2. First hop router gets this and performs an RPF check.

Step 3. If the RPF check passes then PIM looks at its neighbor list and forwards the multicast packet out every PIM enabled interface. If not, the interface is pruned (see Step 4.) This will continue until there is no downstream PIM neighbors left to forward the multicast packet.

Step 4. Pruning will occur. This is the process of stopping multicast packets from being forwarded to routers. PIM routers will generate a prune message if the router has no downstream PIM neighbor and has no connected receivers.

Step 5. The client requests a multicast group by sending an IGMPv2 join message (membership report) to all multicast routers on the local segment.

Step 6. Because the router receiving the IGMP join message has pruned all interfaces, it will send a PIM Graft message to the next upstream multicast router to cancel a pruned interface. The Graft messages will continue upstream until it reaches the multicast source and receives a GraftAck back or until the PIM-DM ages out its pruned interface (default 3 minutes) resulting in a flood of the entire PIM network.

Note: Since IOS 12.1(5)T PIM-DM introduced a new feature called PIM-DM state refresh. This feature uses PIM state refresh messages to refresh the prune state on outgoing interfaces (default 60seconds). This command has to be configured on the interface facing the source of the multicast traffic.

PIM-DM ensures only a single multicast router forwards traffic per multi-access segment. In order to do this, PIM-DM uses asserts. An assert message is generated by a multicast router every time it receives traffic associated with a multicast group on a multi-access interface that is listed in the outgoing interface list for the multicast group. When this happens a PIM forwarder will be elected to prevent sending duplicate packets to the host. The election process is done by comparing lowest AD of the source of the multicast stream > lowest unicast routing source towards the source > highest IP address on the segment.


PIM-SM is much more complex because of how multicast distribution trees are created and how different trees are used to forward traffic for a multicast group. PIM-SM will also do RPF checks and because it is so complex and long to explain, I will skip this part in my overview, but be aware that RPF functions the same way as in PIM-DM. PIM-SM, as you will see, is much more efficient in the way it distributes multicast traffic as it does not flood unnecessary segments of the network.

First let’s define two things important to understand PIM-SM. The Rendez-vous point (RP) and the Designated Router (DR).

As defined by RFC 4601: “An RP is a router that has been configured to be used as the root of the non-source-specific distribution tree for a multicast group.” What this means is that an RP is used as meeting place for sources and receivers of multicast data. “Join messages from receivers for a group are sent towards the RP, and data from senders is sent to the RP so that receivers can discover who the senders are and start to receive traffic destined for the group.”

Also, in PIM-SM the DR is used to forward the PIM join message from the receiver to the RP. By default the highest IP address determines who will become the DR. You can set the priority of the DR using the [(INT)ip pim dr-priority <#>] (default is 1) where the highest priority becomes the DR. As stated before, PIM-DM does not use the DR because it doesn’t have a RP.


The registration of the multicast source to the RP is made: Step 1 – 3

The client requests a multicast group: Step 4 – 5

The RP informs the first hop router and starts forwarding traffic: Step 6 – 7

The merging of the trees occur: Step 8

The Switching to the overall shortest path occurs: Step 9 – 13

Step 1. Source generates multicast traffic

Step 2. The first hop router gets this traffic and informs the RP using a unicast message (PIM register) about Shortest Path Tree (SPT) of the sender (S,G). The first hop router and the RP are the only ones who have an (S,G) entry at this stage.

Step 3. The RP sends a register stop message to the first hop router. This means that the first hop router does not need to send a specific unicast register message any longer to the RP, because the multicast path is established. Only PIM Hello messages are sent.

Step 4. The client requests a multicast group by sending an IGMPv2 join message (membership report) to all multicast routers on the local segment.

Step 5. The last hop router then sends a PIM join message downstream to the RP. The join message goes from router to router (hop by hop) until it reaches the RP. If there are multiple routers on a multi-access network then the DR of that segment will send the PIM join message. Every router in the chain from the multicast receiver to the RP gets a shared-tree entry (*,G) in their multicast routing table on how to get to that group.

Step 6. The RP gets the PIM join message and sends a join message towards the first hop router of the multicast source (hop by hop again). Every router in that chain will get a shared-tree entry (*,G) in their multicast routing table on how to get to that group.

Step 7. When the first hop router of the multicast source gets the PIM join message it starts forwarding the multicast payload towards the RP. At this point, every router who forwards those packets will have a Shared Tree (*,G) or SPT (S,G) entry for that particular group in its routing table.

Step 8. Now the RP has the mapping of the SPT (S,G) and Shared-tree (*,G). The RP merges those two trees and sends the packets coming from the SPT (S,G) down the shared tree (*,G). Every router from sender to receiver then has a (*,G) and (S,G) entry in its multicast routing table.

Step 9. Since the traffic through the RP is not always the best path from the sender to the destination, the last-hop router may, after a specific amount of bandwidth used, send a PIM join message to the first-hop router (the multicast source) instead of the RP in order to switch to the SPT (S,G) and not send the multicast flow through the RP. The spt-threshold bandwidth value will determine when the switchover occurs. If the default is used (default is 0) the last-hop router will do the switchover after the first packet is transmitted to the receiver. Let’s assume the default value here and that the threshold always exceeds the traffic rate. Before the last-hop router sends the SPT (S,G) PIM join message towards the first hop router (the multicast source), it will mark the shared-tree entry (*,G) in its routing table with a “J” flag.

Step 10. As each multicast packet is received on the Shared Tree (*,G), the “J” bit is checked in the shared tree (*,G) entry. If the “J” flag is set, a new SPT (S,G) entry is created for the source of the packet and an (S,G) PIM join request is sent hop by hop towards the multicast source.

Step 11. On the router where the SPT (S,G) entry and the Shared tree (*,G) begin to differ (are not equal any longer) the corresponding router will send a PIM prune message upstream to the RP. The prune message is sent only after the SPT (S,G) entry to the first hop router is built. For that amount of time and before the switchover, the traffic is redundant. The prune message is sent because the router where the tree begins to differ has a different interface mapping to the RP than to the multicast source.

Step 12. The RP receives the prune message and prunes the traffic of the old SPT to the last hop router

Step 13. After that, the traffic of the shared tree (*,G) gets torn down when the RP sends a prune downwards to the first hop router.

Note: You can set the spt-threshold to infinity so there is never a switchover to the SPT (S,G)

In conclusion, PIM-SM only sends multicasts only when requested to do so. Whereas PIM-DM starts by flooding the multicast traffic, and then stopping it each link where it is not needed, using a Flood and Prune method.


One thought on “Hour 102: PIM Dense Mode vs PIM Sparse Mode Part 2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s