In the last lesson, we introduced PIM at a high level and briefly discussed the concept of multicast distribution trees (MDT) and the Rendezvous Point (RP).
In this lesson, we start our more detailed examination of PIM by discussing the most basic operational mode of the protocol. Protocol Independent Multicast (PIM) supports two different modes of operations:
- PIM Dense Mode
- PIM Sparse Mode
This lesson discusses the first and most basic one, PIM Dense Mode. We are going to use the following topology to explain how this mode works.
What is PIM Dense Mode (PIM-DM)?
Let's keep it simple. What does a multicast routing protocol do? It delivers multicast packets from a source to interested receivers over the most optimal path. However, two different approaches achieve the same goal: using a push model or a pull model.
PIM Dense Mode (PIM-DM) is the brute-force approach to delivering multicast. It uses the push logic that if we flood the multicast to all routers in the network, eventually, all interested receivers will receive it, as shown in the diagram below.
Figure 2 visualizes the initial flooding process. You can see that each router in the network receives a copy of the multicast traffic. Subsequently, the routers with directly connected receivers (R4 and R7) get the multicast and forward it to their respective connected receivers. However, routers with no connected receivers also receive a copy of the multicast (R3, R5, and R7), which is the main inefficiency of this PIM mode.
PIM Dense mode assumes that all routers in the network have interested receivers. If that is the case, it can be very efficient to use PIM Dense mode. For example, in small LAN/Campus networks with many receivers distributed over a small number of routers.
How does PIM-DM work?
Let's zoom in a little bit. PIM Dense mode uses a flood-and-prune delivering model that works in three steps:
Step 1. Initial Flooding
Every router floods the initial multicast to all PIM interfaces except the incoming one (like the broadcast logic in Ethernet). The process starts from the source's local gateway router(s), the First-Hop Router (FHR), and continues to every corner of the network. The result is that every router receives the multicast stream.
One question that arises at this point is how PIM prevents traffic loops. If you look at routers R3 through R6, you will see that it is a redundant topology that is susceptible to loops. Ethernet switching has the spanning-tree protocol (STP) that breaks redundant LAN topologies into a loop-free tree, which prevents traffic loops. However, let's see how PIM does it at the multicast routing level.
Reverse Path Forwarding (RPF) Check
Reverse Path Forwarding (RPF) is the loop-prevention mechanism of PIM. Each router performs an RPF check to ensure the multicast traffic is received on the best interface to reach the source, according to the unicast routing table. Each router has only one best interface to reach the multicast source IP address according to the unicast protocol (in this case, OSPF). This interface is called the RPF interface.
- If a router receives multicast traffic on the RPF interface (the best interface for reaching the source), it accepts and forwards the traffic.
- If a router receives multicast traffic on another interface, it discards the traffic.
For example, executing the show ip route 10.1.1.1 command on R3 shows that the next hop to reach multicast source 10.1.1.1 is via e0/1. Hence, e0/1 is R3's RPF interface. When R3 receives multicast from 10.1.1.1 on e0/1, it accepts the traffic. When it receives copies of the same multicast on interfaces e0/0, e0/2, or e0/3 - it drops the traffic.
Using this logic, PIM prevents traffic loops and ensures that multicast flows over the shortest path from the source because multicast traffic is accepted only on the interfaces closest to the source IP address. We have a more detailed lesson on RPF—Reverse Path Forwarding (RPF).
RPF in the Data Plane
The result of the Reverse Path Forwarding (RPF) check is that traffic is only accepted on RPF interfaces in the data plane. However, there are three inefficiencies that the RPF check cannot solve on its own:
- On all non-RPF interfaces, the traffic is still there but simply discarded by the receiving side router (grey lines), wasting bandwidth and CPU cycles.
- On shared segments with multiple routers, the multicast traffic is duplicated. Both R1 and R2 forward the stream on the shared segment, and R3 and R4 accept both streams because they receive them on the RPF interface.
- Routers with no interested receivers (for example, R5 and R7) still receive the multicast stream, wasting unnecessary resources.
To account for those three inefficiencies, the PIM Dense mode implements additional control plane operations that eliminate traffic on non-RPF interfaces and routers with no interested receivers.
PIM Assert Mechanism
The problem: When multiple routers want to forward multicast traffic on the same shared segment, the traffic gets duplicated. For example, R1 and R2 forward the same multicast stream (10.1.1.1, 239.1.1.1) onto the segment highlighted in orange. Subsequently, R3 and R4 receive two copies of the same multicast stream, which they forward along.
The solution: The PIM assert mechanism eliminates multicast traffic duplication on a shared segment by electing a single forwarder called Assert Winner (A). For example, when both R1 and R2 put the initial multicast stream onto the shared LAN, the PIM Assert mechanism detects the duplication and elects R2 as Assert Winner for this segment. Hence, only R2 forwards multicast into the Vlan, and R3 and R4 receive only a single copy of the multicast stream.
Notice that the PIM Assert mechanism does not prevent the initial duplication from occurring. The duplicated multicast packets trigger the PIM Assert mechanism to activate and elect a single forwarder for this shared segment.
We have a more detailed lesson on this topic here - PIM Assert Mechanism.
Step 2. Pruning
After the initial flooding is completed, routers start pruning unnecessary multicast traffic:
- If a router does not have any interested receivers for the multicast group (either directly connected or via downstream routers), it sends a PIM Prune message to its upstream neighbor (the router from which it received the multicast traffic).
- If a router receives a multicast stream on a non-RPF interface, it sends a PIM Prune message back to the upstream router. Upon receiving the prune message, the upstream router stops forwarding multicast traffic down the pruned interface.
The PIM Prune message includes the multicast group address and the source address. This indicates that the sending router no longer wishes to receive multicast traffic for that specific group from the specific source.
Upstream Propagation
Upon receiving a PIM Prune message, the upstream router stops forwarding multicast traffic for the pruned group to the interface from which the prune message was received. If the upstream router also has no interested receivers on other interfaces, it propagates the prune message further upstream. The process continues until the prune message reaches a router with interested receivers or until it reaches the source (if no interested receivers are present in the network).
For example, R6 sends a PIM Prune message for (10.1.1.1, 239.1.1.1) to R5. Since R5 has no connected receivers or other downstream routers that want the multicast, it sends a PIM Prune to R3, which in turn sends a Prune message towards the shard segment of R1 and R2.
Pruning on Shared Segments
The PIM pruning mechanism is generally simple. However, on shared segments, it is a bit more complex. Let's look at the LAN highlighted in yellow in the diagram below.
During the initial flooding, R6 sends the multicast stream onto the LAN. Both R7 and R8 receive the multicast. Since R7 has no interested receivers or any downstream PIM neighbors, it immediately sends a PIM Prune message back onto the LAN. However, R8 hears R7's Prune message and replies with a PIM Join message for the source-group pair (10.1.1.1, 239.1.1.1) because it has connected interested receivers. If R8 does not reply to R7's PIM prune with a Join message, R6 will prune its interface on the shared segment and cut the multicast stream.
Prune Timer
When a router prunes an interface, it simultaneously starts a prune expiration timer for that interface, which is 3 minutes by default. When the timer expires, the router resumes sending multicast traffic to the pruned interface unless it receives a new Prune message before the timer expires.
Grafting (Rejoining)
If a router that previously pruned itself from a multicast group later receives a join request from a downstream PIM neighbor or connected receiver, it sends a PIM Graft message to the upstream router to rejoin the multicast distribution tree. The upstream router receiving the Graft message starts forwarding the multicast traffic to the previously pruned interface.
The PIM Graft message is sent during the 3-minute prune expiration time for the interface. Otherwise, the router sends another Join message.
Step 3. State Refresh
The initial flood-and-prune operation results in the multicast distribution tree rooted at the source - the source path tree (SPT). In our example, the SPT is shown in the following diagram. This is the shortest unicast path from the receivers to the source.
However, the control plane operation is not done. PIM Dense Mode relies on periodic state refreshes. The prune state is not permanent; it has a timer associated with it. Periodically, routers re-flood multicast traffic to ensure any new receivers are reached. If there are still no receivers, the pruning process repeats.