Introduction to PIM and PIM Dense Mode

23 May 2020 07:56

So far we saw how the multicast receivers and senders express their intent to receive/send multicast data, conveyed to the LHR/FHR routers.
Now, we will see how the LHR and FHR routers signal the rest of the multicast core and actually get the traffic from the sources to the receivers.
This is the job of the multicast routing protocol - PIM, popular in enterprise networks.

PIM depends 100% on the information in the unicast routing table but it doesn’t matter which unicast routing protocol you use to fill it. Other multicast routing protocols like
DVMRP and MOSPF don’t use the unicast routing table but build their own tables.
Previous generation's multicast routing protocols DVMRP, MOSPF actually maintain their own multicast routing databases.
PIM however can perform its duties as long as the unicast routing table is populated by any unicast routing protocol(OSPF/EIGRP). It is therefore INDEPENDENT of the protocol being
used in the network. This applies to both PIM dense mode and PIM sparse mode.

One of the major duties of PIM is to perform reliable RPF checks on the multicast traffic.

All PIM enabled routers listen on Destination IP 224.0.0.13 i.e. all PIM messages are sent with that destination IP.
PIM packets go as IP payload(like TCP, UDP, ICMP, IGMP) and have a TTL of 1 (only directly connected neighbors)
Options are carried as TLVs(type length value format) => Within data communication protocols, TLV (type-length-value or tag-length-value) is an encoding scheme used for optional
information element in a certain protocol.
PIM doesn't indicate whether it is SPARSE mode(SM) or DENSE mode(DM) in the HELLO messages which means SM and DM can become adjacent with each other => Not desired

PIM version 2 is used mostly.

Important TLV options:

1 - Hold time: How long are you going to wait for a neighbor that you haven't heard from
19 - DR priority: Designated Router priority. PIM routers can indicate their priority to each other. This is used in DR(designated router) election process.
20 - Generation ID: Handles device reloads. Refresh PIM (S, G), (*, G) states with prune or state refresh messages
21 - State refresh: Enhancement over the original dense mode. Applies to dense mode only.

Since IGMPv1 can't elect a designated querier router, it relies on PIM DM to elect a designated router(DR) which becomes the designated querier for IGMPv1.
Except for this purpose, PIM DM has nothing to do with the Designated Router(DR). PIM sparse mode requires designated routers but not PIM DM.

Designated router is elected for every multi-access segment which is described below:

Are Designated Routers elected on point to point links?

Yes, for PIM they are still considered multi-access ethernet segments.

Here’s the key difference between sparse and dense mode:

• Dense mode: we forward multicast traffic on all interfaces until a downstream router requests us to stop forwarding.
• Sparse mode: we don’t forward multicast traffic on any interface until a downstream router requests us to forward it.

Source Distribution Tree (Shortest Path Trees):

Source distribution trees are rooted at the Multicast source. This model works on the simple assumption that every router has recipients for every multicast feed (S, G). Every router
receives MC traffic on its IIF which it replicates and forwards to all members of the OIL => every non-RPF multicast interface. Replicate the traffic onto every PIM dense mode enabled
interface. This is called push or implicit join model.

PIM Dense Mode Page 1

interface. This is called push or implicit join model.

PIM JOIN/PRUNE message: There is no separate PRUNE message. This message itself is capable of signaling both PRUNEs and JOINs.
In dense mode, since joins are IMPLICIT, this message is used only for pruning. But, there is one case in dense mode where in this message is used for explicit join.

PIM JOIN/PRUNE message is targeted for a specific upstream neighbor who is indicated in the PIM header and NOT the IP header. The destination IP address of this message is
224.0.0.13. The same join/prune message can be used to signal join/prune for multiple multicast groups. The number of such groups is indicated in the PIM header - N. Typically, N is 1.
The rest of the header contains N entries, one for each group. Within each group entry, the number of joined sources(J) and the number of pruned sources(P) are indicated.
In PIM dense mode, J is typically 0(because you prune often)

As can be seen above, R7 has signaled its disinterest in receiving MC feed for a certain S,G combination to R4. R4 removes the single interface that feeds the entire multi-access
segment from the OIL preventing R5 and R6 from receiving the feed!
On a multi-access interface, a prune from a disinterested downstream neighbor can thus affect the traffic being received by an interested neighbor.
How to solve this problem?
The prune message is multicasted on 224.0.0.13 => Even R5 and R6 receive the prune message sent by R7 although they aren't the intended recipients(only R4 is, as indicated in the
PIM header). One of them will send an explicit join(as indicated above, this is the only case where JOIN message is sent in dense mode; Otherwise, it is typically prune in dense mode)
message to R4. The idea is the nullify the prune.
The prune delay timer on R4 allows neighbors like R5/R6 to send explicit joins before removing the interface from the OIL for (S,G). This ensures seamless data-flow for the receiver(s)
connected to R5/R6.
R7 however continues to receive unwanted traffic from R4 due to this selective prune override, for a period of 3 minutes - the hold-down timer. It will send the next prune message
only after the expiry of this hold-down timer. Again, R5/R6 will send the selective prune override to prevent the MC receiver from not receiving the MC feed. This cycle repeats.

PIM Dense mode Pruning:

When data arrives on non-RPF interface (i.e. an interface that is not used to reach the source) and the interface is point-to-point (P2P), a Prune is immediately sent to the upstream
neighbor in an attempt to shut off the flow of traffic.
Note that when data arrives on a non-RPF interface that is not a P2P interface(i.e. which means it is a multi-access interface), an Assert is triggered instead of a Prune.

Prunes are sent on the RPF interface when the router has no downstream members that need the multicast traffic.

PIM Assert messages in Multi-Access segments:

When two routers both forward the same (S, G) multicast traffic onto a common multi-access LAN, duplicate traffic is generated. When this occurs, Assert messages are generated by
both routers to determine which router should continue forwarding on the LAN and which router(s) should stop (prune).

Both R5 and R6 receive the multicast feed from R4 and forward their respective copies to the receiver who receives both the copies. To solve this problem, one of these routers is
chosen as the designated forwarder for that segment using the PIM Assert mechanism.

To stop this duplication of shared traffic, PIM routers connected to a shared segment will elect a single forwarder for that particular segment. Since PIM does not have its own routing
protocol that could be used to determine the best path to send data across, it relies on a special process called the PIM Assert Mechanism to make this determination. This mechanism
tells a router that when it receives a multicast packet from a particular source on an interface that is already listed in its own Outbound Interface List (OIL) for the same (S,G) pair, that
it needs to send an Assert Message. Assert Messages contain the metric of the unicast route to the source in question, the Administrative Distance of the protocol that discovered the
route, the multicast source and the group itself, and are used to elect what is called the PIM Forwarder.

In the above example, R5 and R6 receive each other's packets along with the receiver. On R6, the packets received from R5 fail the RPF check. R6 doesn't send a prune in response to
this event. Prune messages are sent upon RPF check failures only on point-to-point interfaces. On multi-access interfaces, PIM Assert messages
are sent which contain the below info:
• (S,G)
• Metric preference: Administrative distance of the route to the source on IOS
• Metric of the route to the Source

The router selected as DF has:

Lowest Metric preference (if there is a tie)=> lowest metric (if there is a tie)=> highest IP

All routers other than the designated PIM forwarder prune the interface and send a prune message on the segment.

PIM Dense Mode Page 2

R5 wins and becomes the designated PIM forwarder which sends the Assert message to R6. So, R5 tells(Asserts) R6 to prune its interface. R6 will remove its interface towards the
receiver from its OIL for (S, G). Now, the receiver will receive the feed from R5 alone.

PIM Graft message:

PIM Graft messages are used to reduce the join latency when a previously pruned branch of the Source Tree must be “grafted” back. This can be the case when a member joins the
group after the router has sent a Prune message to prune off unwanted traffic, earlier.
If Grafts were not used, the member would have to wait up to three minutes for the periodic re-flooding to occur to begin receiving the multicast traffic. By using Grafts, the Prune can
be reversed almost immediately.

R8 was pruned earlier as it had no connected receivers. Another receiver signals interest in S,G to R8. Unless R8 remembers the upstream PIM neighbor for the (S,G) state, despite
getting pruned earlier, it can't send unicast PIM graft message to R7 as indicated below. This is the reason why routers remember (S,G) states even after getting pruned.

State Refresh Enhancement:

(A parent (*, G) entry must first be created before the (S, G) entry can be created)

The “Expiration” countdown timer of the (S, G) entry will be reset to 00:03:00 whenever an (S, G) packet is forwarded.
If the counter reaches zero, the (S, G) entry will be deleted. If it is the last (S,G) entry, the (*, G) entry will also be deleted.

Even though the flow of multicast traffic is no longer reaching most of the routers in the network, (S, G) state still remains in ALL routers in the network.
This (S, G) state will remain until the source stops transmitting. In PIM DM, all (S, G) entries have an expiration countdown timer which is reset to 3 minutes by the receipt of an (S, G)
packet received via the Shortest-Path Tree (SPT). If no further packets are received from the source, this expiration timer goes to zero and the (S, G) entry is deleted.

In PIM-DM, Prunes expire after three minutes. This causes the multicast traffic to be re-flooded to all routers just as was done in the “Initial Flooding” drawing.
This periodic (every 3 minutes) “Flood and Prune” behavior is normal and must be taken into account when the network is designed to use PIM-DM.

When a dense mode (S, G) entry is created, the status of each interface in the outgoing interface list is marked Dense/Forward to initially flood the traffic out of all outgoing interfaces.
Pruning one of these interfaces as a result of receiving a Prune message from a downstream neighbor for this (S, G), doesn't delete the interface from the OIL. Instead it is marked
Dense/Prune and a 3 minute timer is started exclusively for that pruned interface. When this timer expires, the interface is returned to Dense/Forward state and traffic begins flooding
out this interface again. When a Prune message is received in PIM Dense mode, the interface on which the Prune was received is marked as “Prune/Dense” and a prune countdown
timer is set to 3 minutes. When this timer expires, the interface is set back to “Forward/Dense” and traffic is again flooded out the interface. This will re-create the S,G state
on the downstream router which he can use to send graft messages if need arises. The downstream router will again send another (S, G) Prune to stop the
unwanted traffic; therefore the “Flood and Prune” behavior occurs every 3 minutes.

The pruned state in PIM dense mode times out approximately every 3 minutes and the entire PIM dense mode network is reflooded with multicast packets and prune messages. This
reflooding of unwanted traffic throughout the PIM dense mode network consumes network bandwidth.

The PIM Dense Mode State Refresh feature keeps the pruned state in PIM dense mode from timing out by periodically forwarding a control message down the source-based
distribution tree. The control message refreshes the prune state on the outgoing interfaces of each router in the distribution tree.

PIM Dense Mode Page 3

The PIM Dense Mode State Refresh feature keeps the pruned state in PIM dense mode from timing out, which saves network bandwidth by greatly reducing the reflooding of
unwanted multicast traffic to pruned branches of the PIM dense mode network. This feature also enables PIM routers in a PIM dense mode multicast network to recognize topology
changes (sources joining or leaving a multicast group) before the default 3-minute state refresh timeout period.

The state-refresh message for a (S, G) must be configured on the FHR that is closest to the source. This FHR will periodically send the refresh messages as long as the source actively
sends MC traffic. Each receiving Middle hop router(MHR) will:
1. Refresh the timer on the prune state interfaces. It also refreshes the timer of the entire (S, G) as a whole.
2. Send it down the OIL regardless of whether the interfaces are fwd/prune at the moment. Thus it reaches all the way till the leaf routers.
The final result of this refresh message is same as that if a MC flooding has really happened( but without the detrimental effects of the flood).
Among the MHRs, Only the Assert winners will forward these refresh messages. Assert Losers don’t.

More on PIM DM:

In PIM Dense mode, the control plane and the data plane are one in the same. This implies the following:
– (S, G) state, and hence the Source Tree, is created “on the fly” by the arrival of (S, G) multicast traffic.
– (S, G) state, and hence the Source Tree, is deleted when the source goes inactive and no multicast traffic is received by the router for 3 minutes.

Because the control plane and data plane are mixed in PIM Dense mode, its maintenance of the Source Tree is considerably less deterministic than Sparse mode. This can sometimes
result in instabilities and temporary loss of data during some network topology changes.

Dense mode only has source trees - no shared trees are used

PIM Dense Mode Page 4