How PIM-SM works

PIM-SM (PIM Sparse Mode) assumes that most hosts do not want to receive multicast traffic. It uses a nonflooding multicast model to direct traffic from the source to the interface when there are multicast receivers in the group. As a result, this model sends traffic only to the routers that specifically request it.

In a given PIM-SM domain, routers identified as DRs, RPs, and a BSR participate in delivering multicast traffic to the IP multicast receivers that request it. This approach avoids the flooding method of distributing multicast traffic (employed by PIM-DM) and is best suited for lower bandwidth situations.

The software supports the following operation to enable multicast traffic delivery within a PIM-SM domain:

  • From a pool of eligible DR candidates in each LAN segment, one DR is elected for each LAN segment interface having at least one PIM-SM router. In a multinetted domain, this DR supports multicast traffic from a source on any subnet in the LAN segment.

  • From a pool of eligible BSR candidates in the domain, one BSR is elected for the entire domain.

  • From a pool of eligible C-RPs, one is elected to support each multicast group or range of groups allowed in the domain, excluding any group supported only by static RPs. The multicast groups allowed in the domain are determined by the aggregation of the groups allowed by the individually configured RPs and any static RPs. C-RPs and static RPs can be configured with overlapping support for a given set of multicast groups.

Neighbor discovery

In a PIM domain, each PIM interface on a router periodically multicasts PIM hello messages to all other PIM routers (identified by the address 224.0.0.13 for V4 and ff02::d for V6) on the local subnet. Through the exchanging of hello messages, all PIM routers on the subnet determine their PIM neighbors, maintain PIM neighboring relationship with other routers, and build and maintain shortest path trees (SPTs).

DR election

A designated router (DR) is required on both the source-side network and receiver-side network. A source-side DR acts on behalf of the multicast source to send register messages to the RP. The receiver-side DR acts on behalf of the multicast receivers to send join messages to the RP.

The DR election process is as follows:

  1. The routers on the shared-media LAN send hello messages to one another. The hello messages contain the DR priority for DR election. The router with the highest DR priority is elected as the DR.

  2. The router with the highest IP address wins the DR election under one of following conditions:

    • All the routers have the same DR election priority.

    • A router does not support carrying the DR priority in hello messages.

If the DR fails, its PIM neighbor lifetime expires and the other routers will initiate to elect a new DR.

Rendezvous point tree (RPT)

When a DR in a VLAN receives traffic for a particular multicast group from a source on that VLAN, the DR encapsulates the traffic and forwards it to the RP elected to support that multicast group. The RP decapsulates the traffic and forwards it on toward the multicast receivers requesting that group. This forms an RPT extending from the DR through any intermediate PIM-SM routers leading to the PIM-SM edge routers for the multicast receivers requesting the traffic. (If the RP has no current join requests for the group, the traffic is dropped at the RP.)

Shortest path tree (SPT)

SPTs are especially useful in high data-rate applications where reducing unnecessary traffic concentrations and throughput delays are significant. In the default PIM-SM configuration, SPT operation is automatically enabled.

In the default PIM-SM configuration, after an edge router receives the first packet of traffic for a multicast group requested by a multicast receiver on that router, it uses Reverse Path Forwarding (RPF) to learn the shortest path to the group source. The edge router then stops using the RPT and begins using the shortest path tree (SPT) connecting the multicast source and the multicast receiver. In this case, when the edge router begins receiving group traffic from the multicast source through the SPT, it sends a prune message to the RP tree to terminate sending the requested group traffic on that route. (This results in entries for both the RP path and the STP in the routing table.) When completed, the switchover from the RPT to a shorter SPT can reduce unnecessary traffic concentrations in the network and reduce multicast traffic throughput delays.

The switchover from RPT to SPT is not instantaneous. For a short period, packets for a given multicast group may be received from both the RPT and the SPT. Also, in some topologies, the RPT and SPT to the same edge router may be identical.

Reverse Path Forward

Reverse Path Forward (RPF) checking is a core multicast routing mechanism that ensures that multicast traffic received arrived on the expected router interface before it is considered for further processing. If the RPF check fails for a multicast packet, the packet is discarded.

For traffic arriving on the SPT, the expected incoming interface for a given source/group multicast flow is the interface towards the source address of the traffic (as determined by the unicast routing system). For traffic arriving on the RP tree, the expected incoming interface is the interface towards the RP. PIM must be enabled on all paths where the unicast route points an ECMP path to the source.

RPF override is a feature that allows the override of the normal RPF lookup mechanism and indicates to the router that it may accept multicast traffic on an interface other than that which would be normally selected by the RPF lookup mechanism. This includes accepting traffic from a source directly connected to the router when the source IP address is invalid for the subnet or VLAN to which it is connected. Traffic may also be accepted from a valid PIM neighbor that is not on the reverse path towards the source of the received multicast traffic.

RPF checking is applied to all multicast traffic and is significant in preventing network loops. Up to eight manual RPF overrides can be specified.

The RPF-address indicates one of two distinct RPF candidates:

  1. A valid PIM neighbor address from which forwarded multicast traffic is accepted with a source address of <source-addr/src-mask>.

  2. A local router address on a PIM-enabled interface to which <source-addr/src-mask> is directly connected. The local router will assume the role of DR for this flow and registers the flow with an RP, if configured.