Summary

  • RFC 3446 let multiple active PIM-SM rendezvous points advertise one Anycast address so sources and receivers moved toward the topologically nearest instance, reducing dependence on a distant single RP.
  • The shared address could not identify replica-to-replica coordination: MSDP peerings, router IDs and Source-Active origin/RPF semantics required unique unicast addresses, and successful route selection still did not prove synchronized state or multicast delivery.

One active mapping made geography expensive

The rendezvous point in sparse-mode multicast was a meeting place. Senders registered there; receivers joined toward it; the shared tree could begin there. Under the PIM-SM design recorded in RFC 2362, several RPs could be configured for a multicast group, but only one group-to-RP mapping could be active at a time.

That singular mapping concentrated more than an address. It concentrated register decapsulation, lengthened recovery when the active RP failed and could pull traffic toward a topologically distant location. RFC 3446 gave a concrete continental example: sources and receivers in Europe might initially send traffic to an RP in the United States and back over expensive links.

Operators could divide the multicast range 224.0.0.0/4 among several RPs. Yet a static partition required advance knowledge of traffic distribution. As groups changed, balance required periodic reconfiguration. Address-space symmetry was not workload symmetry.

Published in January 2003 by Dorian Kim, David Meyer, Hank Kilmer and Dino Farinacci, RFC 3446 described an operational mechanism rather than an Internet Standard. Its plain text, RFC Editor record, Datatracker file, history, references, later citations and errata search establish the documentary record. They do not establish how any particular backbone performed.

The front door was shared

Every RP serving the same group range received an identical Anycast address, often on a logical loopback. Group-to-RP mappings named that shared address. Each RP injected reachability for the /32 into the IGP. Ordinary unicast routing then drew a sender's register or a receiver's join toward the closest advertised path.

This was a powerful reuse of an existing decision system. PIM did not need a new global load balancer to choose an instance. Changes in reachability could move clients toward another RP, while multiple RPs could share register-decapsulation work.

But the apparent simplicity depended on configuration equality. All participating RPs needed the same group mappings. Non-RP routers had to learn them through static configuration, Auto-RP or the PIMv2 bootstrap mechanism later specified in RFC 5059. The shared front door coordinated selection only if every control surface agreed about what the door represented.

The backplane required names that did not move

The RPs also needed a consistent view of active sources. RFC 3446 used MSDP, later documented in RFC 3618, for that coordination. MBGP was optional; MSDP was required by this mechanism.

MSDP peerings could not use the Anycast address. Their endpoints had to be unique unicast addresses. A router also had to avoid choosing the shared address as its router ID, because peerings or adjacencies might not form. Most sharply, the Anycast address must not be carried as the RP address in Source-Active messages: the MSDP peer-RPF check would fail.

This is the architectural heart of the document. The public identity answered “which nearby instance should receive this request?” The unique identity answered “which specific peer originated this state, and toward which endpoint should the reverse-path check succeed?” One intentionally hid instance identity; the other depended on it.

Using the shared name in the unique role did not merely make logs confusing. It broke the accountability needed by the coordination algorithm. Anycast was not an identity system for replicas; it was a routing method for reaching one of them.

More RPs changed state as well as distance

The design promised faster failover and distributed decapsulation, not cost-free redundancy. Using MSDP this way forced (S,G) state along the receiver-to-source path. That state might not have existed if receivers remained on a single RP-rooted shared tree. Moving the rendezvous architecture altered state placement and therefore memory, churn and troubleshooting surfaces.

Nor was selection stable by definition. RFC 3446 noted that unicast routing instability changed which actual RP a source or receiver used. The Anycast address remained the same while the serving instance moved. A stable name could conceal an unstable path.

Security followed the same split. Unicast routing and RPs needed protection against spoofing; PIM messages and MSDP peerings required integrity controls. A legitimate-looking route to the shared address did not authenticate the state of the RP reached through it.

The later PIM-SM specifications RFC 4601 and RFC 7761, the general Anycast guidance in RFC 4786, and the PIM-based Anycast-RP alternative in RFC 4610 show how the surrounding architecture evolved. They provide context, not proof that RFC 3446 alone caused later choices. The IANA multicast-address registry and PIM parameters prove assigned symbols, not working trees or delivered packets.

Availability had several receipts

Heng Lu's reality-layer discipline separates the shared address, IGP route, selected instance, MSDP source knowledge, PIM forwarding state, observed packet and receiver outcome. An Anycast route proves a routing choice. It does not prove RP health, consistent mapping, a live peer mesh, complete source state, successful register decapsulation or delivery.

Running-code primacy gives the operational evidence its proper weight. Continental deployments exposed the cost of a distant single RP and the weak scaling of static group-space partitions. The response was not to declare one universal controller, but to let topology choose locally while running an explicit synchronization protocol behind the entrance.

The minimum-initial-specification idea clarifies the restraint: standardize the narrow shared address and the rules needed to coordinate instances; leave deployment topology and voluntary adoption to operators. This is an editorial interpretation, not a claim about the authors' private intent.

RFC 3446's durable lesson is that horizontal replication requires two opposite kinds of naming. Clients need a stable identity that hides the replica. Replicas need stable identities that reveal one another. Confusing those roles turns the convenience of one address into the loss of provenance that coordination needs.

Sources