8.2 Protocol Independent Multicast Sparse Mode (PIM-SM) and Rendezvous Point Discovery

Protocol Independent Multicast Sparse Mode (PIM-SM) and Rendezvous Point Discovery

In enterprise campus and wide area networks, dynamic multicast routing protocols construct distribution trees that deliver streams from senders to receivers. Protocol Independent Multicast (PIM) is the industry standard for constructing these distribution trees. PIM is termed "protocol independent" because it does not maintain its own topology discovery mechanism; instead, it relies on the router's existing unicast routing table—populated by OSPF, EIGRP, BGP, or static routes—to perform Reverse Path Forwarding (RPF) checks. PIM Sparse Mode (PIM-SM, standardized in RFC 7761) uses an explicit-join forwarding model, delivering traffic only to network segments with active, verified receivers.

Multicast Distribution Trees: Shared Trees (*, G) vs. Source Trees (S, G)

Multicast data traverses networks across two architectural tree topologies:

• Source-Based Shortest Path Trees (SPT): An SPT is rooted directly at the transmitting source host and creates branches downward toward every active receiver. In the multicast routing table (mroute), an SPT entry is designated as (S, G), pronounced "S comma G," where S represents the specific unicast IP address of the source and G represents the multicast group address. Because packets flow along the most direct path calculated by the underlying unicast IGP, SPTs provide optimal latency and throughput. However, if a network contains hundreds of sources transmitting to various groups, every transit router must maintain individual state information for every (S, G) pair, significantly increasing router memory consumption.
• Shared Distribution Trees (RPT - Rendezvous Point Tree): A shared tree is rooted at a centralized anchor node called the Rendezvous Point (RP) rather than at the source itself. Shared tree entries are designated as (*, G), pronounced "star comma G," where the asterisk (*) acts as a wildcard representing any source sending to group G. All sources transmit their data to the RP, which then replicates the packets down the branches of the shared tree to active receivers. Shared trees drastically reduce memory utilization on core routers because all sources for a given group consolidate into a single (*, G) state entry. However, routing traffic through an intermediate RP can introduce sub-optimal, dog-legged forwarding paths that increase packet latency and create bandwidth bottlenecks at the RP.

Shortest Path Tree (S, G) vs. Shared Tree (*, G)

Protocol Independent Multicast Sparse Mode (PIM-SM) Architecture

PIM-SM operates on a "pull" model: network segments receive multicast streams only if they explicitly request them by sending PIM Join messages upstream.

PIM Designated Router (DR) Election Mechanics

On multiaccess shared media (such as Ethernet segments where multiple routers connect to the same switch VLAN), having every router forward multicast traffic or send registration messages would cause packet duplication. PIM-SM resolves this by electing a single Designated Router (DR) on each multiaccess LAN:

1. Hello Exchange: Routers exchange periodic PIM Hello messages (sent every 30 seconds to 224.0.0.13 with a hold time of 105 seconds) to discover neighbors and negotiate capabilities.
2. Priority Evaluation: The router with the highest configured PIM DR priority (configured via ip pim dr-priority <value>, default value of 1) wins the election.
3. IP Tiebreaker: If all routers share the same DR priority, the router with the highest numerical IP address on the interface becomes the DR.

The DR fulfills two critical responsibilities:

• On the Source Subnet (First-Hop Router / FHR): The DR is solely responsible for intercepting multicast packets sent by local hosts and encapsulating them into unicast PIM Register messages directed to the RP.
• On the Receiver Subnet (Last-Hop Router / LHR): The DR receives IGMP Membership Reports from local hosts and originates upstream PIM Join/Prune messages toward the RP or source.

PIM-SM End-to-End Operational Lifecycle

The operation of PIM-SM progresses through three structured phases: shared tree construction, source registration, and Shortest Path Tree switchover.

[Source] ---> (FHR / DR) ===== Unicast PIM Register =====> [ RP ]
                                                           |
                                                           | (*, G) Shared
                                                           | Tree
                                                           v
[Receiver] <-- (LHR / DR) <========= (S, G) Join ========= [Transit Router]
                            (SPT Switchover initiates)

Phase 1: Receiver Joins and Shared Tree Construction

1. A client host signals its intention to receive group 239.1.1.1 by transmitting an IGMP Membership Report onto its local subnet.
2. The Last-Hop Router (LHR), acting as the receiver DR, receives the IGMP report, instantiates a (*, 239.1.1.1) entry in its multicast routing table, and adds its local host-facing interface to the Outgoing Interface List (OIL).
3. The LHR determines the IP address of the Rendezvous Point (RP) for group 239.1.1.1 and performs an RPF lookup toward the RP.
4. The LHR transmits a PIM (*, G) Join message out its RPF interface toward the RP.
5. Each intermediate router along the path processes the Join, instantiates a (*, G) entry, adds the incoming interface to its OIL, and forwards the Join hop-by-hop until it reaches the RP. This establishes the shared Rendezvous Point Tree (RPT).

Phase 2: Source Registration and Unicast Tunneling

1. A multicast source begins transmitting packets destined for 239.1.1.1.
2. The First-Hop Router (FHR), acting as the source DR, intercepts these native multicast packets. Because the FHR does not yet have an established tree to the RP, it encapsulates the entire multicast packet inside a unicast IP packet header (protocol 103) called a PIM Register message.
3. The FHR unicasts the PIM Register packet directly to the RP's IP address.
4. Upon receiving the Register packet, the RP decapsulates the packet and injects the original multicast data into the (*, G) shared tree, delivering it down to active receivers.
5. Concurrently, the RP initiates a native (S, G) Join hop-by-hop back toward the source IP address. Once intermediate routers complete this path, multicast packets flow natively from the FHR to the RP without encapsulation.
6. The RP then transmits a unicast PIM Register-Stop message back to the FHR, instructing the FHR to cease CPU-intensive unicast encapsulation.

Phase 3: Shortest Path Tree (SPT) Switchover and Pruning

1. The Last-Hop Router (LHR) receives the first native multicast packet flowing down the (*, G) shared tree from the RP.
2. By default in Cisco IOS XE, the SPT switchover threshold is set to zero (ip pim spt-threshold 0). This instructs the LHR to switch immediately to the optimal Shortest Path Tree upon receiving the very first packet.
3. The LHR inspects the source IP address in the packet header and performs an RPF lookup directly toward the source.
4. The LHR sends an (S, G) Join upstream toward the source along the shortest IGP path.
5. As native packets begin arriving over the new (S, G) tree, the LHR transmits a PIM Prune message (with the RPT-bit set) upstream toward the RP along the shared tree. This prunes the LHR from the (*, G) tree for that specific source, preventing duplicate packet delivery. Traffic now flows along the low-latency Shortest Path Tree directly from source to receiver.

Dynamic Rendezvous Point Discovery Mechanisms

Deploying static RP configurations (ip pim rp-address <ip>) requires manual provisioning across every network router. If an RP fails, static configurations cannot automate failover without third-party scripting. To resolve this, dynamic RP discovery mechanisms automate RP assignment and redundancy.

Cisco Auto-RP

Auto-RP is a Cisco-proprietary protocol that automates RP discovery using two primary functional roles:

• Candidate RPs (C-RPs): Routers configured to act as potential RPs advertise their availability by sending periodic RP-Announce messages every 60 seconds to the reserved multicast address 224.0.1.39 (CISCO-RP-ANNOUNCE).
• RP Mapping Agents (MAs): Specialized routers listen to 224.0.1.39, collect all C-RP announcements, resolve conflicts by electing the candidate with the highest IP address for each group range, and broadcast the active group-to-RP mappings every 60 seconds to 224.0.1.40 (CISCO-RP-DISCOVERY).

Because Auto-RP relies on multicast packets (224.0.1.39 and 224.0.1.40) to distribute RP information, routers face a circular dependency: they cannot route multicast traffic without an RP, but they need multicast to find the RP. Cisco addresses this using PIM Sparse-Dense Mode (where interfaces operate in dense mode for groups without an RP) or by configuring ip pim autorp listener, which selectively floods the two Auto-RP control groups in dense mode across sparse-mode interfaces.

IETF Bootstrap Router (BSR) Protocol

Standardized in RFC 5059, the Bootstrap Router (BSR) protocol is an open-standard dynamic RP discovery mechanism integrated into PIM version 2. BSR eliminates the circular dependency of Auto-RP by using hop-by-hop link-local multicast:

1. BSR Election: Routers configured as Candidate BSRs (C-BSRs) exchange Bootstrap Messages (BSMs) sent to the link-local multicast address 224.0.0.13 with TTL=1. The router with the highest BSR priority (default 0) is elected; ties are broken by the highest IP address.
2. C-RP Registration: Candidate RPs (C-RPs) transmit unicast Candidate-RP-Advertisement messages directly to the elected BSR's IP address.
3. RP-Set Flooding: The elected BSR compiles all valid C-RPs into an RP-Set and floods BSM packets hop-by-hop throughout the PIM domain every 60 seconds using 224.0.0.13. Routers validate BSMs using RPF checks toward the BSR.
4. Deterministic Hash Selection: Every router in the domain receives the complete RP-Set and independently runs a standardized hash function over the group address and candidate list, selecting the exact same RP for any given multicast group without requiring a centralized mapping agent.

Comparison of Rendezvous Point Discovery Methods