What is PIM (Protocol Independent Multicast)?

What is PIM (Protocol Independent Multicast)?

Introduction

PIM (Protocol Independent Multicast) is a multicast routing protocol, that is used to send traffic from a single source to multiple destinations across a network.

PIM is a collection of three protocols - PIM Sparse Mode, PIM Dense Mode and PIM Bi-directional .  PIM is termed protocol-independent because PIM does not include its own topology discovery mechanism, but instead uses routing information supplied by other routing protocols .  [1]

Multicast Forwarding

The first thing to understand about multicast forwarding is unlike unicast forwarding, multicast forwarding is based on where the packet came from.

Multicast uses RPF (Reverse Path Forwarding) to prevent flooding/loops within the network. The RPF check uses the routing table to check against the source IP within the packet. If the packet came in on an interface that is specified against the source of the multicast stream, the RPF check succeeds, otherwise, the RPF check fails and the packet is dropped. 

PIM Components

In order for multicast traffic to be sent through a network, there are two key elements - state and the multicast distribution tree.

State

State is the information network devices must track in order for the router to know where it should send the traffic. State includes the component known as (S, G); S (multicast source), G (multicast group).  Of course, state comes with a cost; in the event of state change, CPU and memory are required by the system to process the convergence. Therefore we typically we will find the more state that is held, the higher the convergence times are.

Distribution Tree

The distribution tree is a path through the network used to distribute multicast traffic. There are two types of distribution trees - shortest path (also known as source tree) and shared. 

Source Distribution Tree

The Shortest Path (Source) Distribution tree is, quite simply the shortest path from the source to the multicast group member. Because it represents an optimal path, a source distribution tree minimizes the latency in the network. [2] At the same time, the multicast router must track all sources and maintain state information for each source. As a result, source trees can become a burden to the multicast router, especially as the number of sources grows. [3]

SPT1

Figure 1 - Source Tree.

Shared Distribution Tree

Whereas source trees that have their root at the source, shared trees use a single common root, called a Rendezvous Point (RP) as the root of the distribution tree.

In this model, other routers do not need to know the addresses of the sources for every multicast group. All they need to know is the IP address of the RP router. The RP router discovers the sources for all multicast groups. [4] This means the overhead of finding the multicast source from each router (S, G) is moved to the RP. The key benefits to shared trees is the reduction in resources required, as each router no longer needs to keep state of the multicast source. However, the downside is based on the location of the RP,  the path from the receiver to the RP, may not present the most optimal path.

sharedtree1--1-

Figure 2 - Shared Tree.

PIM Protocols

PIM Dense-Mode

PIM Dense Mode (RFC 3973) operates by initially flooding the multicast traffic for all groups out of all enabled interfaces (Figure 3). [5] Routers that do not have any interested hosts send PIM Prune messages to remove themselves from the tree (Figure 4). Based on this “Flood and Prune” behavior, eventually, the traffic is only sent to the necessary routers that require the traffic. This, in turn, results in a source distribution tree i.e optimal network path being built back to the sender.

pim-dm111

Figure 3 - PIM-DM Flooding ; (S, G).

pim-dm21

Figure 4 - PIM-DM Pruning.

 

As we mentioned previously when discussing the source distribution trees, this results in each router holding state (S, G), and therefore presents overhead challenges to each of our routers. Additionally, each Prune state is subject to a timeout. After 4 minutes, the Prune state will age out (shown below), the traffic is then flooded and the pruning process is performed again.  

Because of PIM-DMs "Flood and Prune" model, and the disadvantages that come with it, PIM-DM is only recommended for large-scale networks or lab-based environments.

# show ip mroute
IP Multicast Routing Table
!
(*, 239.1.1.1), 00:00:56/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
	GigabitEthernet0/2, Forward/Dense, 00:00:56/stopped
	GigabitEthernet0/1, Forward/Dense, 00:00:56/stopped

(10.0.0.3, 239.1.1.1), 00:00:56/00:02:03, flags: PT Incoming interface: GigabitEthernet0/1, RPF nbr 10.0.0.3 Outgoing interface list: GigabitEthernet0/2, Prune/Dense, 00:00:56/00:02:03, A

PIM Sparse-Mode

PIM-SM works in the opposite manner to PIM-DM; with PIM sparse mode no multicast traffic is forwarded unless some requests it. PIM-SM works via the use of an RP (Rendezvous Point).

Let us look at the process that PIM-SM takes:

1. Shared Tree (RP to Receiver) - The receiver sends an IGMP Join message to the first hop router (FHR), i.e its direct neighboring router. This router will then send a PIM Join to the RP. A shared tree is then built from the receiver to RP based upon (*, G).

2. Shortest Path Tree (Source to RP) - Next, the source starts to send multicast traffic. The FHR encapsulates the multicast packet into a PIM register message and sends via unicast to the RP router. The RP decapsulates the packet and checks the multicast group to see if it has any state for any receivers for the multicast group. If so the RP sends a PIM Join message back towards the source, in order to build an SPT (Shortest Path Tree) back to the source.

The source sends another multicast packet, however now there is a SPT (aka source tree) from the RP to the FHR. Therefore the packet is now sent across the distribution tree to the RP. The RP receives the packet nativity (with S, G), and in turn, sends a register-stop message back to the sources FHR to stop receiving the register messages (via unicast).

NOTE In the event of multicast sources being present. Multiple SPT distribution trees would be formed from the RP back to the FHRs.

At this point (Figure 5), we now have a

  • source tree from RP to the source,
  • shared tree from RP to the receiver.

pim-sm11

Figure 5 - PIM Sparse, SPT and Shared Tree.

3. Shortest Path Tree Switchover - Although having the RP join back towards the source removes the encapsulation overhead, it does not completely optimize the forwarding paths. [6] As for our receivers, the path via the RP (shared tree) still may be suboptimal. To overcome this, the process to migrate the shared tree to source tree, as known as the SPT switchover begins.

First, the LHR sees the source address of the multicast stream. Now that the LHR knows the source address, it sends an (S, G) Join to the source of the multicast stream. This builds an SPT from LHR to FHR. Finally, a Prune message is sent from the LHR to the RP in order to remove the previously used (RP to LHR) shared tree (Figure 6).

pim-sm21

Figure 6 - SPT Switchover.

Additional Links

 https://tools.ietf.org/html/rfc4601

References

[1] "Protocol Independent Multicast - Wikipedia." https://en.wikipedia.org/wiki/Protocol_Independent_Multicast . Accessed 22 Feb. 2018.
[2] "Source distribution trees - Brocade." http://www.brocade.com/content/html/en/vrouter5600/42r1/vrouter-42r1-pim/GUID-C14BF5F9-074C-4E38-8E3C-5ADB44FE7165.html . Accessed 26 Feb. 2018.
[3] "Source distribution trees - Brocade." http://www.brocade.com/content/html/en/vrouter5600/42r1/vrouter-42r1-pim/GUID-C14BF5F9-074C-4E38-8E3C-5ADB44FE7165.html . Accessed 26 Feb. 2018.
[4] "Understanding Multicast Rendezvous Points, Shared Trees, and ...." https://www.juniper.net/documentation/en_US/junos/topics/concept/multicast-rendevous-point-trees.html . Accessed 26 Feb. 2018.
[5] "PIM crash course - PacketLife.net." http://packetlife.net/blog/2008/oct/16/pim-crash-course/ . Accessed 6 Feb. 2018.
[6] "RFC 4601 - Protocol Independent Multicast - Sparse ... - IETF Tools." https://tools.ietf.org/html/rfc4601 . Accessed 3 Mar. 2018.

Subscribe to our newsletter and stay updated.

Don't miss anything. Get all the latest posts delivered straight to your inbox.
Great! Check your inbox and click the link to confirm your subscription.
Error! Please enter a valid email address!