Summary

  • RFC 2102 left multicast route generation and packet-forwarding mechanisms outside Nimrod’s core because dynamic groups, state creators and tree heuristics admitted several legitimate designs.
  • Interoperability moved to a narrower contract: implementations could use shared or source-rooted trees and let senders, receivers or routers install state, provided the resulting forwarding information was interpreted uniformly.
  • A joined branch or populated forwarding row therefore proved one executable replication relation—not membership, authorization, full coverage, shortest paths, reserved quality, resource sharing or delivery.

The most important object in RFC 2102 is not a tree. It is a row of state inside a router.

That is a surprising center of gravity for a document about multicast. A multicast design is usually introduced through the picture everyone remembers: one source, a branching network and many receivers. RFC 2102 began one level earlier. Who should calculate the branches? Who should ask for them? Should all sources share one tree, or should each source have its own? Should a router infer state, should a receiver join, or should a sender install a route? The document refused to turn any one answer into the Nimrod answer.

Two freedoms, not one omission

Unicast and multicast both require route generation and packet forwarding. RFC 2102 says Nimrod defined unicast forwarding modes while leaving unicast route generation to the routing agent. For multicast, it left both phases unspecified.

The omission was deliberate. Group membership changes. A new member requires a branch; a departure may permit a prune. State can be initiated by a sender, a receiver, both, or neither. Tree heuristics also optimize different objectives. A low-cost tree can impose greater end-to-end delay. A collection of shortest paths can consume more total resources. Computation time, state scale, policy and optimality pull in different directions.

The document surveyed the consequences rather than naming a winner. DVMRP used reverse-path machinery to form source-rooted trees, but could spread state and control work widely. CBT reduced state through a receiver-initiated shared tree around a core, at the price of path stretch and dependence on core placement. PIM allowed shared and source-specific trees to coexist. MOSPF let routers calculate trees from link-state and group information. IDPR let a source compute a policy route and install duplication state in intermediate entities.

These were not cosmetic variations. They located knowledge, computation and authority in different places.

The common layer was the installed relation

RFC 2102 still needed different implementations to forward together. Its answer was agreement at a lower layer. A delivery tree is defined by the forwarding information present in routers, the document argued, not by the mechanism that created it. If implementations shared the structure and interpretation of that information, several construction methods could coexist.

The Nimpim example makes the abstraction executable. A Join carries a flow identifier, direction, target and source route. At a router, an existing flow may gain the preceding node as another child. A new flow installs a parent, a child and a target before the request continues. A Prune removes a child and deletes the flow only when no child remains. Packets later carry the flow identifier; forwarding agents use the installed state to duplicate them toward the child list.

That state can be produced by different histories. A sender may have created the original tree. A receiver may then build a path to a router already on it and attach a new branch without the sender knowing. A shared tree may later give way to a source-based tree. RFC 2102 explicitly allowed simultaneous approaches and switching as group distribution changed, provided the installed state could still be interpreted uniformly.

This is the thin common layer: not one algorithm, one authority or one global picture, but one mutually legible execution grammar.

The branch says less than it appears to say

Once forwarding state is treated as the receipt, its evidentiary limit becomes visible. A child entry says that packets for a particular flow are currently meant to be copied toward one neighboring relation. It does not contain the entire membership process that justified the relation. RFC 1112 and later group-management work place listener evidence on attached networks, with timers and aggregation of their own. A forwarding row is downstream of that evidence, not a substitute for it.

Nor does the row certify policy. RFC 2102 observed that destination-specific restrictions could require one group to be served by multiple trees over disjoint destination partitions. The installed branch does not reveal whether every intended destination was included, whether the transit policy remained valid or whether a hidden destination-to-locator association was complete.

It does not certify optimality either. CBT’s shared path may not be shortest. PIM’s reverse shortest path is truly shortest only under assumptions about metric symmetry. MOSPF and IDPR reach forwarding state from very different calculations. A common state shape allows execution; it does not erase the trade-offs that preceded it.

Quality and resources remain separate again. RFC 2102 wanted every path to satisfy requested quality and access restrictions, and wanted information about which tree resources could be shared with reservation systems. Those are additional claims. The mere existence of a branch does not prove delay, jitter, reservation admission or safe sharing.

Finally, a populated row is not a delivery receipt. It does not show that the source emitted traffic, that every intermediate state survived, that a link carried the packet, that the last-hop network delivered it or that an application consumed it. RFC 2102 did not discuss security at all, so the row also cannot stand in for authenticated membership or authorization.

A 1997 argument for a minimal interoperability surface

RFC 1992 had already made Nimrod comfortable with multiple maps, abstractions and forwarding modes. RFC 1753 separated user state from service state and emphasized subsystem boundaries. RFC 2102 applied the same instinct to multicast: standardize only what had to cross an implementation boundary, while leaving tree construction open to new methods and local needs.

Lu Heng’s “Minimum Initial Specification” supplies a modern vocabulary for the move. A common layer should carry only deterministic rules required for interoperability; later choices should remain with participants running code. “Running-Code Primacy” adds the adoption test: a document or algorithm becomes operational only through implementation and use. The parallel is interpretive, not genealogical. The RFC does not prove Nimrod deployment, and the later essay did not cause its design. But both expose the same engineering question: which invariant must be shared, and which decision can remain local?

RFC 2102’s answer was precise. Multicast needed no single calculator. It needed forwarding state that another implementation could execute without first sharing the calculator’s worldview. The cost of that freedom was evidentiary discipline. A branch proved a branch. Everything else still needed its own receipt.

Sources