Summary
- RFC 2117 turned an IGMP membership indication into wildcard
(*,G)state and a hop-by-hop join toward a group’s Rendezvous Point. The resulting shared tree was an accumulation of local route entries, not one committed object. - A source’s Designated Router initially encapsulated data in Register messages. Register-Stop suppressed that encapsulation only for a timer interval; it was not an acknowledgement of permanent native-path readiness.
- Join/Prune messages had no explicit acknowledgement. Periodic refresh repaired loss, Holdtimes removed outgoing branches, data timeouts removed silent source state, and the SPT bit changed only after packets arrived on the source-specific incoming interface.
The most revealing sentence in RFC 2117 is not a packet format. It is the admission that Join/Prune messages elicited no explicit acknowledgement. A router sent an instruction upstream, but the protocol did not turn the exchange into a distributed commit. If the packet vanished, the next periodic refresh was expected to rebuild the missing fact.
Published in June 1997 as Experimental, RFC 2117 described the first RFC version of Protocol Independent Multicast—Sparse Mode. “Sparse” meant the network should build distribution state toward places that had asked for the group, rather than assume receivers everywhere and flood first. “Protocol independent” meant PIM could use reverse-path information without belonging to one unicast routing protocol. Neither word meant that the resulting tree possessed a single authoritative record.
One listener indication became several local records
A host first reported group membership through IGMP. That report concerned an attached network. It did not name every listener, and it did not authenticate an application. The local Designated Router used the indication to look up the group’s Rendezvous Point, create (*,G) state and add the receiving interface to its outgoing list.
The asterisk mattered. It meant any source could match this group entry when no more specific record existed. The DR then sent a Join/Prune toward the RP with the wildcard and RP-tree bits set. Each upstream router could create or refresh its own (*,G) record, add the downstream interface and continue the join toward the RP. Taken together, those separate records formed a shared tree rooted at the rendezvous point.
No individual record contained “the tree.” A route entry held an incoming interface, outgoing interfaces, timers, flags and addresses from one router’s perspective. A membership indication proved that this DR had reason to keep one local branch. A Join proved that one downstream neighbor had requested state for a Holdtime. Neither proved the identity of the receivers, the completeness of the tree or the agreement of every router.
A new source travelled inside a Register before it had a native branch
Sparse membership created a bootstrapping problem for senders. When a directly connected source first transmitted to group G, the source’s DR did not yet have a source-specific tree reaching the RP. It encapsulated the multicast packet in a PIM Register and unicasted it to the RP. The RP decapsulated the packet and forwarded it down the shared tree.
This was a bridge between two states of knowledge. The Register carried data through a control relationship while the network learned a native path. If the rate warranted it, the RP could create (S,G) state and send a source-specific join toward S. Routers along that path installed their own source records.
Register-Stop sounds final but was deliberately temporary. The RP sent it when it had no downstream interest or when it was already receiving the source natively. The source DR then started a per-(S,G) suppression timer. When the timer expired, Registers resumed, or a Null-Register probed whether suppression was still justified. A Register-Stop therefore proved only that the RP asked this DR to suppress encapsulation for the current interval. It did not prove that the native path would remain up, that all receivers were served, or that the RP would never need another probe.
The shortest-path tree became real through arriving data
The RP and last-hop routers could choose to move a branch from the shared tree to a source-specific shortest-path tree. RFC 2117 recommended traffic-rate thresholds but said the switching rule could change without global coordination. The common protocol specified how routers represented and signalled the transition; it did not centralize the business decision to make it.
Creating (S,G) state did not itself complete the switch. The new entry began with its SPT bit cleared. While the new branch was being built, the router could continue accepting the source through the shared-tree incoming interface. Only when packets from S arrived on the incoming interface selected for (S,G), and that interface differed from the shared-tree interface, did the router set the SPT bit and send a source-specific prune toward the RP.
That order preserved continuity as far as one router could observe it. It did not prove loss-free transition across the whole tree. Packets on an unexpected incoming interface could still be dropped. The SPT bit recorded that this router had seen packets on its expected source path and could stop using one shared branch. It was not a receipt from every downstream receiver.
Expiry was part of correctness, not merely cleanup
Soft state worked because forgetting was designed alongside remembering. Periodic Join/Prune messages refreshed active route entries. Their Holdtime refreshed individual outgoing interfaces; if no renewal arrived, the branch aged out. Silent-source (S,G) state expired by Data-Timeout. Register suppression expired around a configured mean. Bootstrap and RP-set information also lived behind timers.
The defaults expose the trade. RFC 2117 documented a 60-second Join/Prune period and a 210-second Holdtime. It documented a 210-second Data-Timeout for a silent source. Register suppression centered on 60 seconds: shorter meant more Register bursts at the RP, while longer meant more latency when new receivers appeared. There was no free setting that maximized certainty, speed and efficiency at once.
The Bootstrap Router mechanism made the same locality visible at a larger scale. A BSR periodically distributed an RP-Set; routers used their most recently received set and a hash to map a group to a candidate RP. A partitioned domain could elect different BSRs in its separated regions. When the partition healed, another election reconciled the arrangement, and RFC 2117 acknowledged that packet delivery could be disrupted during the transition.
The historical achievement was disciplined uncertainty
RFC 2117 was replaced by RFC 2362, then by the Standards Track RFC 4601, and finally by Internet Standard RFC 7761. That succession matters. The 1997 document is evidence of an early protocol design, not proof that every detail survived unchanged or that a present network implements it.
Yet the central architecture endured: a shared RP-rooted tree, optional source-specific trees, Register and Register-Stop, Join/Prune state and timers. The current IANA registry still names those message types. What matured was not a fantasy of total knowledge. It was a more rigorous method for coordinating partial, expiring observations.
This is the useful historical lesson. Sparse multicast did not scale by converting every join into a delivery receipt. It scaled by limiting what each signal had to mean. An IGMP report meant local group presence. An RP mapping selected a rendezvous point under the current set. A Join refreshed one upstream relation. A Register carried early data. A Register-Stop paused that carriage. An (S,G) entry proposed a source path. An SPT bit recorded data arriving on that path. Timers withdrew claims that were no longer refreshed.
The system became operational by composing those narrow statements. It became misleading only when an observer promoted one of them into proof of the entire outcome.
Sources
- RFC 2117: Protocol Independent Multicast—Sparse Mode
- RFC 2117 status record
- RFC 2117 errata search
- RFC 1112: Host Extensions for IP Multicasting
- RFC 2236: Internet Group Management Protocol, Version 2
- RFC 2362: PIM-SM Experimental revision
- RFC 4601: PIM-SM revised Standards Track specification
- RFC 7761: PIM-SM Internet Standard
- IANA Protocol Independent Multicast Parameters
- Lu Heng: Reality Layers
- Lu Heng: Minimum Initial Specification
- Lu Heng: Running-Code Primacy
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
