Protocol independent multicast, or PIM, is the family of routing protocols that decides how one stream of multicast traffic reaches every receiver that asked for it.
It is called protocol independent because it does not build a routing table of its own: it reads whatever unicast routing table the network already has, from OSPF, BGP or static routes, and uses it to work out the path back toward the source.
That reverse-path check keeps multicast loop-free. The main variant is PIM sparse mode, which builds a shared tree rooted at a rendezvous point and can then switch to the shortest path from receiver to source.
- PIM is the routing protocol family that builds the distribution tree for multicast
- It is protocol independent because it reuses the existing unicast routing table
- It uses a reverse-path forwarding check to keep multicast loop-free
- PIM sparse mode builds a shared tree at a rendezvous point, then switches to the shortest path
- IGMP signals which receivers want a group; PIM connects the routers between them
On this page
What PIM isWhat protocol independent multicast is
PIM sits one layer up from the group membership that hosts signal, and it is where multicast actually gets routed.
It routes one stream to many receivers. Protocol independent multicast is a family of multicast routing protocols that provide one-to-many and many-to-many distribution of data over a LAN, WAN or the internet. The sender transmits once; PIM arranges for the network to replicate the stream only where the paths to different receivers diverge.
It builds a distribution tree. The job of PIM is to build and maintain a tree of routers from the source out to every receiver, so a packet is copied at each branch rather than unicast separately to each destination. That tree is the whole point, and the variants differ mainly in how the tree is built.
It is a router-to-router protocol. PIM runs between multicast routers. Hosts do not speak PIM; they use IGMP to say which groups they want, and the routers use PIM to connect those requests back toward the source.
Protocol independentWhy it is called protocol independent
The name is the most distinctive thing about it, and it describes exactly how PIM works.
It has no routing table of its own. PIM does not include its own topology discovery mechanism. Instead it uses the routing information supplied by other routing protocols, whatever unicast routing table the network already maintains.
It works with any unicast protocol. PIM is not dependent on a specific unicast routing protocol; it can use OSPF, EIGRP, BGP, IS-IS or static routes equally. Whatever put the routes in the table, PIM reads them. That independence is why it is deployed on top of almost any network design.
It checks the reverse path. PIM uses that unicast table to run a reverse path forwarding check: a multicast packet is only accepted on the interface the router would use to send unicast traffic back toward the source. The RPF check is what prevents multicast loops, and it depends entirely on the unicast table being correct.
Sparse mode and RPPIM sparse mode and the rendezvous point
Sparse mode is the variant deployed most often, and it is the one RFC 7761 specifies.
It assumes receivers are scattered. PIM sparse mode is built for the common case where receivers for a group are spread thinly across the network. Rather than flood, it uses explicit joins: a router only becomes part of the tree when a receiver below it actually asks for the group.
It starts at a rendezvous point. PIM-SM explicitly builds a unidirectional shared tree rooted at a rendezvous point, or RP, one per group. The RP is a known meeting place: sources register with it, receivers join toward it, and traffic initially flows down the shared tree from the RP.
It can switch to the shortest path. Once traffic is flowing, PIM-SM can optionally create a shortest-path tree per source, cutting over from the shared tree at the RP to the direct path between receiver and source. That switch trades the simplicity of one meeting point for a shorter, more efficient path.
The four variantsThe four variants of protocol independent multicast
The other modes exist because different receiver patterns call for different trees.
Dense mode floods and prunes. PIM dense mode implicitly builds shortest-path trees by flooding multicast traffic across the whole domain, then pruning back the branches where no receivers are present. It is straightforward but scales poorly, and it suits only networks where receivers are almost everywhere.
Source-specific mode roots at one source. PIM source-specific multicast builds trees rooted in a single source, with no rendezvous point, offering a more secure and scalable model for applications such as content broadcasting where receivers know exactly which source they want.
Bidirectional mode carries many-to-many. Bidirectional PIM explicitly builds shared bidirectional trees and never builds a shortest-path tree, so it may add end-to-end delay but scales well for many-to-many applications with many sources.
Sparse mode is the default choice. For most networks, sparse mode is the right starting point: it does not waste bandwidth flooding, and its shortest-path switch recovers efficiency once streams are established.
Messages and statePIM messages and the state routers keep
Protocol independent multicast runs directly over IP rather than over TCP or UDP. RFC 7761 assigns all PIM control messages IP protocol number 103, and it sends link-local messages to the ALL-PIM-ROUTERS group, 224.0.0.13 for IPv4 and ff02::d for IPv6. The same protocol serves both address families.
Hello messages find neighbors. A router sends a Hello message on every PIM-enabled interface, every 30 seconds by default in RFC 7761. Routers that hear each other become PIM neighbors, and a neighbor that stays silent past the hold time is removed.
Hellos also elect the designated router. On a LAN with several multicast routers, the one with the highest DR priority wins, and the highest IP address breaks a tie. The designated router sends joins for the receivers on that segment and registers its local sources with the RP.
Join and prune messages build the tree. A Join message travels hop by hop toward the RP or the source and adds a branch. A Prune message removes it. In dense mode a pruned branch grows back when the prune state times out, which is why dense mode floods the network again at intervals.
Register messages introduce a source. In sparse mode the first-hop router wraps the source's multicast packets in unicast Register messages to the RP. When native traffic arrives, or when the group has no receivers, the RP answers with a Register-Stop message.
Assert messages settle duplicates. When two routers forward the same group onto one LAN, an Assert message exchange picks a single forwarder for that segment.
All of this leaves multicast state in each router's multicast routing table.
A (*,G) entry means any source for group G and belongs to the shared tree. An (S,G) entry names one source and belongs to a shortest-path tree. Each entry holds an incoming interface, chosen by the RPF check, and a list of outgoing interfaces.
PIM and IGMPHow PIM works with IGMP
PIM and IGMP are often confused because both involve multicast, but they do different jobs.
IGMP is host to router. A receiver uses IGMP to tell its local router which multicast group it wants to join. That is the last hop, between the host and the first router.
PIM is router to router. Once the local router knows a receiver wants a group, PIM is what builds the path from that router back through the network toward the source or the rendezvous point. IGMP gets the request to the edge; PIM carries it across the core.
Together they complete the path. A multicast stream reaches a host because IGMP signaled the want at the edge and PIM built the tree across the network. Neither alone delivers the traffic; the two hand off at the first-hop router.
PitfallsWhere people go wrong
Thinking PIM has its own routing. It does not. PIM leans entirely on the unicast routing table, so a broken or asymmetric unicast path breaks multicast through a failed RPF check, even when PIM itself is configured correctly.
Confusing PIM with IGMP. IGMP is how hosts join groups; PIM is how routers build the tree between them. A working design needs both, and blaming one for the other's failure wastes time.
Reaching for dense mode to keep it simple. Flood-and-prune looks simpler but scales badly and wastes bandwidth on networks where receivers are sparse. Sparse mode is the safer default despite needing a rendezvous point.
Forgetting the rendezvous point is a single meeting place. In sparse mode the RP matters: if it is unreachable or badly placed, group traffic suffers until the shortest-path switch happens. RP placement and redundancy are part of the design, not an afterthought.
Ignoring the RPF check when troubleshooting. Most multicast faults trace back to reverse path forwarding: the packet arrived on an interface that does not match the unicast route to the source, so the router drops it. Check the unicast path first.
ComparisonThe four PIM modes side by side
| Criterion | Sparse mode | Dense mode | Source-specific | Bidirectional |
|---|---|---|---|---|
| Tree | Shared at an RP, then shortest path | Shortest path by flooding | Shortest path from one source | Shared bidirectional |
| Rendezvous point | Yes | No | No | Yes |
| Best when | Receivers are scattered | Receivers are everywhere | Receivers pick the source | Many sources, many receivers |
| Scaling | Good for wide area | Poor | Good | Good for many-to-many |
| How it starts | Explicit join | Flood then prune | Explicit join to a source | Explicit join |
Sparse mode is the usual choice; the others each answer a specific pattern of where the receivers are.
FAQFrequently asked questions
What is protocol independent multicast?
A family of multicast routing protocols that build the distribution tree carrying one stream to many receivers over a LAN, WAN or the internet. It is called protocol independent because it uses the existing unicast routing table instead of building its own.
Why is PIM called protocol independent?
Because it does not have its own topology discovery or routing table. It relies on whatever unicast routing protocol the network already runs, OSPF, BGP, EIGRP, IS-IS or static routes, and reads that table to forward multicast.
What is the difference between PIM sparse mode and dense mode?
Sparse mode uses explicit joins and a rendezvous point, adding routers to the tree only when a receiver asks, which suits scattered receivers. Dense mode floods traffic everywhere and prunes back where there are no receivers, which suits receivers that are almost everywhere but scales poorly.
What is a rendezvous point in PIM?
A router that acts as the shared meeting place for a multicast group in sparse mode. Sources register with it and receivers join toward it, so traffic first flows down a shared tree rooted at the rendezvous point before any switch to a shortest-path tree.
What is reverse path forwarding?
The loop-prevention check PIM uses. A multicast packet is only accepted if it arrives on the interface the router would use to reach the source by unicast. If it arrives on any other interface, it is dropped, which stops multicast loops.
What are the four variants of PIM?
Sparse mode (PIM-SM), dense mode (PIM-DM), source-specific multicast (PIM-SSM), and bidirectional PIM (Bidir-PIM). They differ in how they build the distribution tree and which receiver patterns they suit.
How does PIM relate to IGMP?
IGMP works between a host and its local router, telling the router which group the host wants. PIM works between routers, building the path from that router back toward the source. IGMP handles the last hop; PIM handles the network in between.
What is PIM-SM?
PIM sparse mode, specified in RFC 7761. It builds a unidirectional shared tree rooted at a rendezvous point per group and can optionally create a shortest-path tree per source once traffic is flowing.
What is PIM source-specific multicast?
A variant that builds trees rooted in a single source with no rendezvous point. It is more secure and scalable for applications where receivers know exactly which source they want, such as content broadcasting.
Does PIM need a specific unicast routing protocol?
No. That is the point of protocol independence: PIM works with any unicast routing protocol or with static routes, because it only reads the resulting routing table to perform its reverse path forwarding check.
Why does multicast fail even when PIM looks configured?
Usually because of the unicast path. PIM depends on the unicast routing table for its RPF check, so an asymmetric or broken unicast route makes multicast packets fail the check and be dropped, even though PIM itself is fine.
Which PIM mode should I use?
Sparse mode is the default for most networks: it does not flood, and it recovers efficiency by switching to the shortest path. Dense, source-specific and bidirectional modes are chosen only when the receiver pattern specifically calls for them.
Keep readingRelated concepts
Read next · Protocols What IGMP Is, and Why Multicast Floods Without It The protocol receivers use to join a group, one layer below PIM. Open this next9 min- Routing · 10 min OSPF LSA Types, Explained by Who Sends Them and How Far They Flood One of the unicast routing protocols whose table PIM can read.
- Routing · 11 min EIGRP Configuration, and the Feasible Successor Logic That Makes It Work Another unicast routing protocol PIM can run on top of.