Protocol-Independent Multicast
Protocol-Independent Multicast (PIM) is a family of multicast routing protocols designed for Internet Protocol (IP) networks to support efficient one-to-many and many-to-many data distribution, allowing a single source to send data to multiple receivers or multiple sources to a group of receivers without duplicating traffic across the network.[1] It derives its name from operating independently of specific unicast routing protocols, instead using existing unicast routing tables for reverse path forwarding (RPF) checks to build multicast distribution trees and prevent loops.[2] PIM enables routers to dynamically discover multicast sources and receivers, forwarding packets only along paths leading to interested hosts, which is essential for applications like video streaming, online gaming, and stock market data dissemination.[3] PIM supports multiple operational modes tailored to different network characteristics and receiver densities. In Dense Mode (PIM-DM), the protocol assumes most areas of the network are interested in the multicast traffic, initially flooding packets to all interfaces and then pruning branches without receivers using Join/Prune messages; this flood-and-prune approach suits densely populated multicast environments but can be bandwidth-intensive.[2] Conversely, Sparse Mode (PIM-SM) employs a pull model for networks with sparsely distributed receivers, building shared trees rooted at a Rendezvous Point (RP) where sources register and receivers explicitly join groups, optionally switching to source-specific shortest-path trees for efficiency.[1] Additional variants include Source-Specific Multicast (SSM), which extends PIM-SM by allowing receivers to specify sources directly without an RP,[1] and Bidirectional PIM, which supports many-to-many communication by orienting trees toward the RP for reduced state overhead.[4] Developed in the mid-1990s as part of early IP multicast efforts, PIM evolved from foundational work on multicast routing to address limitations in prior protocols like Distance Vector Multicast Routing Protocol (DVMRP).[2] The Dense Mode specification was first outlined experimentally and revised to Proposed Standard status in RFC 3973 (2005), while Sparse Mode progressed from experimental RFCs 2117 (1997) and 2362 (1998) to Proposed Standard in RFC 4601 (2006), advancing to Internet Standard with the revised specification in RFC 7761 (2016).[1][2] A 2013 survey documented widespread implementations by major vendors and deployments in enterprise, campus, and service provider networks since 1998, confirming interoperability and supporting its advancement toward Internet Standard status.[5] Key features of PIM include its use of Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) for host-router signaling, support for both IPv4 and IPv6, and mechanisms like Bootstrap Routers (BSRs) for dynamic RP discovery in Sparse Mode to enhance scalability and redundancy.[1] It also incorporates assert messages to resolve parallel paths and graft messages to quickly restore forwarding after prunes expire, ensuring robust operation in dynamic environments.[2] Deployed extensively in modern IP networks, PIM remains a cornerstone of multicast technology, with ongoing IETF work focusing on YANG models for configuration and extensions for emerging use cases like Segment Routing and simplified variants like PIM Light (RFC 9739, 2025).[6][7]Overview
Purpose and Design Principles
Protocol-Independent Multicast (PIM) is a family of multicast routing protocols designed for Internet Protocol (IP) networks to enable efficient one-to-many and many-to-many distribution of data over local area networks (LANs), wide area networks (WANs), and the Internet.[8] It supports the dynamic construction of multicast distribution trees that deliver packets from sources to interested receivers without requiring prior coordination between them, thereby reducing communication overhead compared to unicast replication.[2] The core design principle of PIM is its protocol independence, meaning it leverages existing unicast routing tables to perform reverse path forwarding (RPF) checks and determine multicast forwarding paths, without dependency on any specific unicast routing protocol such as OSPF or BGP.[8] This independence allows PIM to operate across diverse network environments by using the multicast routing information base (MRIB), which can be derived from unicast tables or maintained separately.[9] PIM also incorporates both pull and push models: the pull model relies on explicit joins from receivers to request traffic, while the push model involves initial flooding followed by pruning to suppress unwanted delivery.[8] These mechanisms ensure scalability for both sparse multicast groups, where receivers are widely dispersed, and dense groups, where traffic is more uniformly distributed, by minimizing unnecessary state and bandwidth usage.[2] PIM was motivated by the shortcomings of earlier multicast protocols, such as Distance Vector Multicast Routing Protocol (DVMRP), which relied on flooding mechanisms inefficient for sparse traffic across wide-area networks, and Multicast OSPF (MOSPF), which was tightly coupled to the OSPF unicast protocol and thus limited in scope and interoperability.[8] At a high level, PIM's architecture involves routers exchanging control messages, such as Join and Prune, to dynamically build and maintain multicast trees in response to source activity and receiver interests.[9] This approach promotes robustness and adaptability in heterogeneous internetworks.[2]Key Components
PIM relies on a network of PIM-enabled routers to facilitate multicast forwarding. These routers include designated routers (DRs), which are elected on multi-access links to represent directly attached hosts by handling source registration and group membership queries, and border routers, which manage multicast traffic across administrative domains or between different multicast routing protocols.[10] In certain operational modes, a Rendezvous Point (RP) serves as a central meeting point where multicast sources and receivers initially converge, enabling efficient shared tree construction without requiring direct source knowledge.[11] PIM employs several message types to maintain neighbor relationships and build forwarding states. Hello messages are periodically exchanged between routers for neighbor discovery and DR election, ensuring adjacency and link-local coordination. Join/Prune messages propagate upstream to construct or remove branches from multicast distribution trees, specifying sources and groups. Register messages allow DRs to encapsulate and tunnel original multicast packets from sources to the RP, facilitating initial data delivery in RP-centric modes. Assert messages resolve parallel paths on shared links by electing a single forwarder to prevent duplicate packet transmission.[12][13][14][15] Routers maintain state information to track multicast forwarding paths. The (S,G) state represents source-specific forwarding entries, enabling shortest-path trees from individual sources to receivers for a particular group G. The (*,G) state denotes shared tree forwarding for group G, typically rooted at the RP, which supports receiver-initiated joins without source specificity. These states are stored in the router's multicast routing information base (MRIB) and updated via Join/Prune messages.[16][17] PIM integrates with host-to-router protocols like IGMP for IPv4 or MLD for IPv6 to detect local group memberships, where DRs act as queriers to learn receiver interests and trigger upstream joins. For path validation, PIM performs Reverse Path Forwarding (RPF) checks using the underlying unicast routing tables, ensuring loop-free forwarding independent of the specific unicast protocol in use.[18][19]History and Standards
Development Timeline
The development of Protocol-Independent Multicast (PIM) originated in the mid-1990s within the Internet Engineering Task Force's (IETF) Inter-Domain Multicast Routing (IDMR) working group, aimed at addressing the scalability limitations of earlier protocols like Distance Vector Multicast Routing Protocol (DVMRP), which relied on a flood-and-prune mechanism that became inefficient in large networks. Initial Internet-Drafts for PIM emerged as early as September 1995 for Sparse Mode, with specifications for Dense Mode following in January 1996, along with key architectural documents released in 1996 outlining the protocol's independence from underlying unicast routing protocols.[20][21][22] PIM-Sparse Mode (PIM-SM) and PIM-Dense Mode (PIM-DM) were formally proposed in 1996 through IDMR working group drafts, marking significant milestones in multicast routing design by introducing shared trees and protocol independence to support inter-domain scalability. Experimental deployments of PIM began in the late 1990s, transitioning multicast infrastructure from DVMRP-dominated setups like the MBone to test PIM's viability in wide-area multicast applications.[23][22] In the early 2000s, PIM evolved with the introduction of Source-Specific Multicast (PIM-SSM) to enhance efficiency by eliminating the need for shared trees and Rendezvous Points in source-known scenarios, as detailed in an IETF overview published in 2003. Bidirectional PIM (BIDIR-PIM) followed in 2005, extending PIM-SM for many-to-many applications such as stock tickers by enabling bidirectional shared trees without explicit source registration, with formal specification in 2007. Recent developments through 2025 have focused on refinements rather than new modes, including enhanced IPv6 support via updates to dynamic multicast address group IDs and protocol specifications, as well as integration considerations with Software-Defined Networking (SDN) for improved multicast control in modern infrastructures. A 2024 IETF draft on multicast lessons learned from deployments highlighted ongoing refinements through RFC errata and operational insights, emphasizing PIM's adaptability without introducing major architectural changes.[24][22][25] More recent extensions include RFC 9128 (October 2021), which defines YANG data models for PIM configuration and monitoring to support network automation, and RFC 9465 (June 2023), which specifies PIM Null-Register Packing to reduce overhead in source registration by bundling multiple messages.[6][26]Relevant RFCs
The Protocol-Independent Multicast (PIM) protocol is specified through a series of Internet Engineering Task Force (IETF) Request for Comments (RFC) documents that define its foundational modes, updates, extensions for source-specific multicast (SSM) and bidirectional operation, rendezvous point (RP) mechanisms, and related architectural overviews. These standards have evolved from experimental specifications to proposed standards, with revisions addressing protocol deficiencies, security considerations, and support for IPv6. Foundational RFCs for PIM-Sparse Mode (PIM-SM) and PIM-Dense Mode (PIM-DM) include RFC 2117, which introduced the initial PIM-SM protocol specification in June 1997, enabling efficient multicast routing using shared trees and explicit joins in sparse environments.[27] This was revised experimentally in RFC 2362 from June 1998, which updated PIM-SM mechanisms including Bootstrap Router (BSR) for RP discovery while maintaining protocol independence from underlying unicast routing.[28] PIM-SM was further revised to proposed standard status in RFC 4601 from August 2006, specifying explicit Join/Prune messages, register mechanisms, and tree-building procedures, obsoleting RFC 2362.[29] For PIM-DM, the revised specification in RFC 3973 from January 2005 details the flood-and-prune behavior for dense multicast environments, using reverse path forwarding checks based on unicast routing tables.[30] Extensions for SSM and bidirectional PIM are covered in RFC 4607 from August 2006, which defines Source-Specific Multicast (SSM) for IP, specifying how PIM builds source-specific trees without RPs for applications requiring known sources, and integrating with PIM-SM for channel-based multicast.[31] RFC 5015 from October 2007 introduces Bidirectional PIM (BIDIR-PIM), a variant of PIM-SM that constructs bidirectional shared trees for many-to-many communication, reducing state overhead in scenarios like conferencing by eliminating source-specific branches.[32] RP mechanisms are addressed in multiple RFCs, including the BSR protocol in RFC 2362 for dynamic RP-set election and advertisement in PIM-SM domains.[28] RFC 3446 from January 2003 specifies Anycast RP using PIM and Multicast Source Discovery Protocol (MSDP), allowing multiple RPs to share a single IP address for load balancing and fault tolerance in shared-tree multicast.[33] This is extended in RFC 4610 from August 2006, which enables Anycast-RP solely within PIM domains without MSDP, using embedded RP address mapping and PIM registers for redundancy and scalability.[34] Additional RFCs include RFC 7761 from March 2016, which updates PIM-SM for IPv6 support, obsoleting RFC 4601 by clarifying address scoping, Hello message options, and compatibility with IPv6 multicast routing architectures.[9] RFC 5110 from January 2008 provides an overview of the Internet multicast routing architecture, describing PIM's role alongside other protocols like DVMRP and MOSPF in embedded and application-level multicast contexts.[35]General Mechanisms
Protocol Independence
Protocol-Independent Multicast (PIM) achieves its independence from underlying unicast routing protocols by querying the existing unicast routing information base—typically derived from protocols such as RIP, OSPF, BGP, or static routes—for next-hop determinations during multicast forwarding decisions, without incorporating any specific unicast routing logic into its own operations.[36][2][9] This design allows PIM to leverage the Multicast Routing Information Base (MRIB), which is populated from unicast tables or multicast-specific extensions like MBGP, ensuring compatibility across diverse network environments without requiring protocol-specific adaptations.[2][9] Central to this independence is the Reverse Path Forwarding (RPF) mechanism, which prevents multicast loops by validating incoming packets against the unicast path to the source. In an RPF check, a router accepts a multicast packet from source S only if it arrives on the interface that the unicast routing table identifies as the next-hop path to S; otherwise, the packet is discarded.[36][37][19] The RPF logic can be expressed as: if the incoming interface equals the RPF interface toward S (determined via MRIB lookup), forward the packet; else, discard it to enforce loop-free delivery.[37][19] This check is performed dynamically as unicast routes change, allowing PIM to adapt without its own topology discovery process.[36] The primary benefits of PIM's protocol independence include enhanced portability, enabling deployment in heterogeneous networks with mixed unicast protocols, and eliminating the need for multicast-specific unicast protocols like MOSPF, which require flooding group membership information.[36][38][39] By relying on established unicast infrastructure, PIM reduces complexity and supports scalable multicast over wide-area internets.[36] However, this approach has limitations, as PIM's correctness depends entirely on the accuracy and consistency of the unicast routing tables; inaccuracies can lead to forwarding failures or suboptimal paths.[40][39] Additionally, asymmetric routing—where inbound and outbound paths differ—can cause RPF checks to fail unnecessarily, potentially disrupting multicast delivery unless mitigated by mechanisms like Assert messages.[41][15]Multicast Distribution Trees
In Protocol-Independent Multicast (PIM), multicast distribution trees are constructed to efficiently forward traffic from sources to receivers, forming a spanning structure that branches at routers based on receiver locations. These trees ensure that multicast packets follow paths determined by the underlying unicast routing table, with leaf nodes typically representing end receivers or stubs where no further downstream forwarding occurs. Routers along the tree maintain per-interface forwarding state to replicate and forward packets only to interfaces with active receivers, preventing loops through Reverse Path Forwarding (RPF) checks.[35] PIM supports two primary tree types: source-specific trees (S,G), which provide the shortest path from a particular source S to all receivers interested in group G, and shared trees (,G), which route traffic via a common root (such as a Rendezvous Point) for multiple sources to group G receivers. Source trees (S,G) offer optimal delay and bandwidth efficiency for individual sources but require routers to maintain state for each active (source, group) pair, potentially leading to high resource consumption in networks with many sources. In contrast, shared trees (,G) aggregate state across sources for a group, reducing per-router overhead at the cost of possibly longer paths due to indirection through the root, making them suitable for scenarios with sparse receiver distributions.[35][42][43] Trees are built and maintained through router state machines that respond to PIM Join messages propagated hop-by-hop toward the source (for S,G trees) or root (for *,G trees), adding outgoing interfaces (oifs) to the outgoing interface list (olist) where receivers are attached. Pruning occurs when no receivers remain on a branch, triggered by Prune messages that remove interfaces from the olist and propagate upstream to eliminate unnecessary forwarding state. This process ensures dynamic adaptation, with branching points forming where multiple downstream paths to receivers diverge from a router. PIM messages, such as periodic Joins, are used to sustain the tree structure.[13][44] For scalability, PIM routers track active (S,G) and (*,G) entries in the Tree Information Base (TIB), with state garbage-collected via timeouts to reclaim resources for inactive entries. Default timers, such as the Join/Prune Expiry Timer (typically 210 seconds or 3.5 minutes) and Keepalive Timer (also 210 seconds), expire if no refreshing Joins or data packets arrive, transitioning states to inactive and removing forwarding entries. This timer-based mechanism balances responsiveness with state management, preventing indefinite retention of obsolete trees while supporting networks with varying source and receiver dynamics.[45][46][47]PIM Messages and States
Protocol-Independent Multicast (PIM) employs a set of control messages to facilitate neighbor discovery, maintain multicast distribution trees, and manage state transitions in a protocol-independent manner, leveraging the underlying unicast routing table. These messages are sent using IP protocol number 103 (for PIMv2), and are common across PIM modes with some variations. The primary messages include Hello for establishing adjacencies, Join/Prune for signaling interest in multicast groups and sources, Assert for resolving forwarding duplicates, and Register (specific to sparse mode operations).[48][49][50] The Hello message is sent periodically by PIM routers to the ALL-PIM-ROUTERS multicast address (224.0.0.13 for IPv4 or ff02::d for IPv6) to discover and maintain neighbor relationships. Its format includes a PIM header followed by optional fields such as Holdtime, DR Priority, Generation ID (GenID), and LAN Prune Delay, which help in electing the Designated Router (DR) on multi-access links based on the highest priority or IP address. Hellos are transmitted every 30 seconds by default, with an initial random delay of 0-5 seconds to avoid synchronization, and include capabilities negotiation to ensure compatibility. Upon receiving a Hello, a router starts a Neighbor Liveness Timer set to the advertised Holdtime (default 105 seconds), expiring which removes the neighbor.[12][51] The Join/Prune message is used to build or tear down multicast forwarding states along distribution trees, sent multicast to the RP address or unicast/multicast along the tree path toward the source or RP. Its format consists of a PIM header, upstream neighbor address, Holdtime, and encoded group and source lists indicating Join (include in outgoing interface list) or Prune (exclude) actions, supporting (*,G), (S,G), and (S,G,rpt) entries with mode-specific flags. These messages propagate state changes, with periodic transmission every 60 seconds or triggered by events, and include a Holdtime default of 210 seconds (3.5 times the Join/Prune interval) to manage state expiration. In dense mode, Prunes suppress flooding on branches without receivers, while Joins override Prunes on shared media within the override interval.[13][44] The Register message, primarily in sparse mode, allows the DR to encapsulate and unicast original multicast data packets from a source to the Rendezvous Point (RP), informing it of active sources. Its format includes a PIM Register header with Border-bit (B) and Null-Register bit (N), followed by the IP header and data payload, sent potentially fragmented if the encapsulated packet exceeds the MTU. Upon RP receipt, it may trigger a Register-Stop message to halt further registrations, with the source's DR restarting transmission after a Register-Stop Timer (default 60 seconds suppression, followed by probes).[52] The Assert message handles error scenarios by resolving duplicate packet delivery on multi-access LANs when multiple routers forward the same multicast traffic. Sent when a router receives a multicast data packet on an interface that is in its outgoing interface list, to resolve potential duplicate forwarding on multi-access links, its format includes the source/group addresses, metric preference, and metric value (RPT-bit set for RP-tree asserts), allowing comparison to elect a winner: the router with the lowest metric (or highest IP if tied) becomes the Assert Winner and continues forwarding, while losers prune toward the winner. Asserts are transmitted with a default timer of 180 seconds, overridden every 3 seconds if needed, and include handling for invalid sources or neighbors lacking prior Hellos, which are discarded.[15][53] PIM maintains a state machine per (S,G) or (*,G) entry on each interface to track forwarding behavior, with states including NoInfo (no state), Join (forwarding active), and Prune (suppressed). Transitions are triggered by message receipt or timer expiry: for example, receiving a Join on an interface moves from NoInfo to Join, restarting the Expiry Timer (set to Holdtime); a Prune shifts to Prune-Pending, starting a short Prune-Pending Timer (typically 3-5 seconds) before full Prune state, allowing overrides. Upstream states (e.g., Joined or NotJoined) manage sends toward the RPF neighbor, while downstream states handle incoming joins/prunes; Assert states (NoInfo, I_am_Assert_Winner, I_am_Assert_Loser) resolve conflicts independently. These per-interface states ensure loop-free trees without mode-specific dependencies.[54][55] Key timers govern message and state lifetimes: the Hello Timer defaults to 30 seconds for periodic transmission; Join/Prune Holdtime is 3.5 times the interval (210 seconds), used for Expiry Timers; the Register-Stop Timer randomizes between 0.5-1.5 times suppression time (60 seconds default) to prevent bursts; Assert Timer is 180 seconds for winners (with 3-second overrides) and 60 seconds for losers. Prune-Pending and Override Intervals (2.5-5 seconds) enable quick reversals on shared links. These values promote stability and rapid convergence across networks.[56][47]Dense Mode
Operation Principles
Protocol-Independent Multicast Dense Mode (PIM-DM) employs a push-based model that assumes multicast receivers are densely distributed across the network, making it ideal for scenarios where most potential hosts are interested in the traffic, such as video broadcasts within enterprise local area networks (LANs). In this approach, the protocol relies on the underlying unicast Multicast Routing Information Base (MRIB) to propagate multicast datagrams without prior knowledge of receiver locations, flooding packets network-wide upon source activation to ensure delivery to all possible destinations. This design prioritizes simplicity and low initial setup overhead, suitable for environments with high-bandwidth streams and a limited number of multicast groups.[30][35] Upon receiving the first multicast packet from a source, a PIM-DM router performs a Reverse Path Forwarding (RPF) check using the unicast routing table to identify the incoming interface and prevent loops. The router then forwards the packet out all other interfaces, effectively flooding it to the entire network except the RPF interface from which it arrived. This initial flooding establishes basic connectivity for the source-specific multicast flow, leveraging the existing unicast infrastructure for path determination without requiring dedicated multicast topology discovery.[30] PIM-DM creates forwarding state on a per-source, per-group basis, installing (S,G) entries in the multicast forwarding table only when packets arrive or are triggered by downstream events. Unlike other modes, pure PIM-DM does not maintain (*,G) shared tree states, focusing exclusively on source-specific paths to simplify operations in dense environments. These states are installed reactively, allowing routers to build the distribution tree incrementally as traffic flows.[30] The protocol's applicability is limited to networks with dense receiver distributions and low group counts, where the flooding overhead is tolerable due to widespread interest, as in campus or enterprise settings with broadcast-style applications. However, it becomes inefficient for sparse, Internet-scale deployments with few receivers per group, as the initial network-wide dissemination consumes excessive bandwidth and router resources before any optimization.[35]Flood-and-Prune Behavior
In PIM Dense Mode (PIM-DM), the flood-and-prune mechanism dynamically refines the source-specific multicast distribution trees by initially flooding traffic to all interfaces and then pruning branches where there is no receiver interest. When a router determines that no local receivers or downstream routers are interested in traffic from a specific source S to group G—indicated by an empty outgoing interface list olist(S,G)—it sends a Prune(S,G) message upstream toward the reverse path forwarding (RPF) neighbor for S. This Prune message propagates upstream, causing intermediate routers to transition their (S,G) upstream state to Pruned and set a Prune Timer to the Prune Hold Time (default 210 seconds or 3.5 minutes) minus the Join/Prune Override Interval (default 3 seconds), effectively removing the forwarding state for that branch along the path to the source.[30] To prevent premature pruning of branches that may still have interested receivers, downstream routers can override a received Prune(S,G) by sending a Join(S,G) message toward the RPF neighbor within the PrunePending Timer period, which is set to the J/P_Override_Interval (default 3 seconds). This override transitions the downstream state back to NoInfo, ensuring continued forwarding. Additionally, to recover from network changes or failures, PIM-DM employs periodic reflooding: upon expiration of the Prune Timer (every 210 seconds or 3.5 minutes by default), the pruned state lapses, and traffic is reflooded to all interfaces, allowing new receivers to signal interest and rebuild the tree. This periodic mechanism ensures adaptability without explicit state refresh in basic PIM-DM, though extensions like State Refresh can maintain prunes longer.[30] For faster recovery from erroneous prunes, such as when a new receiver joins a previously pruned branch, routers use the Graft mechanism: a downstream router sends a Graft(S,G) message upstream to the RPF neighbor when olist(S,G) becomes non-empty, transitioning the upstream state to AckPending and starting a Graft Retry Timer (default 3 seconds). Upon receiving a GraftAck from the upstream router, the state moves to Forwarding, re-establishing the path; if no acknowledgment arrives, the Graft is retried. This provides quicker rejoining than waiting for the Prune Timer to expire.[30] Loop prevention in the flood-and-prune process relies on RPF checks, which ensure that Prune messages and data packets follow the unicast reverse path from the source, discarding any arriving on non-RPF interfaces to avoid forwarding loops. In multi-access networks where multiple routers might forward duplicates, Assert messages are used: upon detecting duplicate packets on a LAN, routers elect an Assert winner (typically the one with the lowest IP address or metric) via Assert(S,G) exchanges, with the winner continuing to forward and losers pruning their interfaces toward the winner, setting an Assert Timer (default 180 seconds) to maintain the decision. Pruning refines the initial source trees built during flooding, optimizing bandwidth by eliminating unnecessary paths.[30]Sparse Mode
Rendezvous Point and Shared Trees
In Protocol-Independent Multicast Sparse Mode (PIM-SM), the Rendezvous Point (RP) serves as a central router that acts as the root for the shared distribution tree associated with a multicast group, enabling efficient coordination between sources and receivers without requiring prior knowledge of each other's locations.[9] The RP facilitates source registration, where the first-hop router for a source encapsulates multicast packets in unicast Register messages sent to the RP, and receiver joins, where the last-hop router for a receiver sends (*,G) Join messages toward the RP to establish the shared tree, denoted as the RP Tree (RPT).[45] This mechanism builds unidirectional shared trees using existing unicast routing tables, avoiding the blind flooding of dense-mode protocols and ensuring data flows only along paths with interested receivers.[42] RP discovery in PIM-SM can occur through static configuration, where network administrators manually assign group-to-RP mappings on all routers, or dynamic methods to automate the process across the domain.[11] The Bootstrap Router (BSR) mechanism, defined in RFC 2362, provides a standards-based dynamic approach: candidate BSRs and candidate RPs are elected based on priority and IP address, with the elected BSR collecting RP advertisements and flooding Bootstrap messages containing the RP-set to all PIM routers via hop-by-hop multicast, allowing each router to hash a group address to select the appropriate RP from the set.[57] Alternatively, Auto-RP, originally a Cisco proprietary protocol, uses mapping agents to announce group-to-RP mappings over a dedicated multicast group, though it relies on PIM dense-mode flooding and is not fully standardized.[11] For IPv6, embedded-RP encodes the RP address directly within the multicast group address for automatic discovery.[11] Once established, the shared tree operates by having the RP decapsulate registered packets from sources and forward them down the RPT to joined receivers, while the RP may also initiate source-specific joins if needed to optimize delivery.[19] Receivers maintain their attachment to the shared tree through periodic (*,G) Join messages sent upstream toward the RP, creating and pruning branches as receivers join or leave, with intermediate routers forwarding these messages based on unicast routes to the RP.[58] Sources continue registering until the RP sends a Register-Stop message, signaling that native multicast forwarding on the shared tree is active.[45] This pull-based model ensures that multicast state is created only on demand, contrasting with push-based flooding. The use of shared trees rooted at the RP enhances scalability in sparse multicast environments by concentrating source-specific state primarily at the RP and edge routers, while core routers maintain minimal per-group state (one entry per (*,G) rather than per source-group pair), reducing memory and processing overhead in wide-area networks.[59] This design is particularly suitable for applications with widely dispersed but low-density receivers, such as stock quote distribution over enterprise WANs, where the shared tree avoids unnecessary traffic replication in the network core.[59]Switching to Source Trees
In Protocol-Independent Multicast Sparse Mode (PIM-SM), the initial distribution of multicast traffic occurs via a shared rendezvous point (RP) tree, which provides a mechanism for receivers to join a group before learning active sources.[43] To optimize delivery, PIM-SM allows last-hop routers to transition to a source-specific shortest path tree (SPT) once data from a source begins arriving.[60] This switchover is triggered when the last-hop router receives the first data packet for source S and group G via the RP tree, prompting it to evaluate theSwitchToSptDesired(S,G) condition if receivers are joined to the group.[60] If the condition holds, the router sends a (S,G) Join message upstream toward the source S, using the unicast routing table to establish the SPT branch.[61]
During the transition, multicast packets from S may arrive via both the RP tree and the emerging SPT, resulting in temporary duplication at the receiver until the prune process completes.[43] Upon receiving the first packet on the SPT, the last-hop router sends a (S,G,rpt) Prune message toward the RP to halt forwarding of S's traffic on the shared tree branch.[60] This prune propagates hop-by-hop upstream, removing the unnecessary shared tree path where all downstream receivers have switched.[62] The switch threshold is configurable and implementation-defined, such as switching after the first packet, after a data rate threshold is exceeded, or based on a time interval, allowing network administrators to balance efficiency and overhead.[60]
Both (*,G) shared tree state and (S,G) source-specific state coexist during and after the switch, with the SPTbit in the (S,G) state set to TRUE to indicate SPT usage.[16] The RP maintains the shared tree state until prunes from all last-hop routers confirm no remaining interest in S via the RP path, at which point the branch is fully pruned.[43] This SPT switch reduces end-to-end latency and bandwidth consumption by avoiding the RP detour, providing a more direct path to the source.[43] However, it increases per-source router state and control message overhead, though this is the default behavior in most PIM-SM implementations to prioritize path optimization.[60]