Summary

  • RFC 2443 let several ATM multicast address-resolution servers share a view of clients and multicast groups, while each client still belonged to one server.
  • When a server missed two heartbeat updates, its peers had to discard every membership learned from it. Clients then had to register with a backup and rejoin their groups; synchronized copies alone did not restore service.

Three green copies, one missing source

Picture three MARS servers showing the same membership row: a client belongs to a multicast group. The shared view looks healthy. Then the server that first registered the client stops sending its redirect-entry heartbeat. The other two servers still possess identical records, but RFC 2443 does not treat that agreement as proof that the source—or the client attached to it—remains alive. After two consecutive updates are missed, they must flush the memberships learned from that server.

That distinction was the design. RFC 2022 had described MARS, the Multicast Address Resolution Server, as a way to distribute layer-three multicast membership and connection information over ATM. In a distributed MARS service, each server in a Logical IP Subnet (LIS) needed enough information to answer for every multicast group in that subnet. RFC 2443, published as an Experimental RFC in November 1998, adapted the Server Cache Synchronization Protocol (SCSP) to replicate those records among MARS servers.

Replication spread records, not ownership

SCSP supplied a synchronization framework: servers established a relationship, aligned cache contents, and then propagated new state. RFC 2443 assigned the MARS application protocol identifier 0x0003 and bounded the server group by the LIS. When a client registered with one server, that server propagated the registration and later group changes to its peers. Each client nevertheless registered with only one MARS server and was attached through that server's Cluster Control Virtual Circuit or Server Control Virtual Circuit. The copies widened the group's view; they did not move the client's original control relationship to every peer.

That left an ownership problem that replication could not solve. A MARS client needed a unique Cluster Member ID across the LIS. RFC 2443 assumed each server had a distinct range to assign; an external allocation system was possible, but outside the document's scope. Synchronized databases can repeat an identifier consistently. They cannot make a collision-free allocation authority appear by themselves.

A heartbeat was a rule for invalidating stale knowledge

Each server had to refresh its MARS Server Redirect Entry at least once every two minutes; the RFC recommended once per minute. If a peer missed two consecutive updates from a source, it had to flush all client and group-membership state learned from that source. This was more than a server list refresh. The entry supplied evidence about the operational state of a particular origin, and the purge was deliberately scoped to information attributed to that origin.

Recovery then moved back to the client. A client detecting its MARS failure selected a backup, attempted registration, and—only after registration succeeded—rejoined its previous groups. If the attempt failed, it tried another server. A redirect map could tell a client where to try; it could not certify that this particular client had migrated, re-registered, restored its memberships, or resumed receiving multicast.

Nor did a restored membership row prove that an ATM point-to-multipoint circuit was built or that packets reached an application. Those are separate operational transitions in the MARS system. The distinction is familiar in running networks: a replicated control-plane record is an input to action, not the action's receipt.

Authentication created a trust boundary—and a blast radius

RFC 2443 did not encrypt its MARS-specific cache-state record. It pointed to security mechanisms in SCSP's protocol-independent layer. Authentication could cause peers to discard bogus unauthenticated packets, but the RFC also made the trust consequence explicit: information from any properly authenticated server was trusted and propagated across the group. If one authenticated MARS server was compromised, the database could be corrupted from that source throughout the group. Authentication narrowed who could speak; it did not make an authorized speaker's data true or contain the damage of a compromised peer.

The later RFC 3790 observed that RFC 2443 supplied IPv4 defaults while leaving an extension path to IPv6 through appropriate IANA definitions. That is evidence of a documented design intention, not evidence of implementation or deployment. The RFC text tells us what the protocol required and warned about; it does not establish how often the system ran or whether every implementation followed the rules.

The durable lesson is narrower than “replication improves availability.” Ask who originated each record, how fresh the source evidence is, what must be invalidated when that evidence expires, and which actor must perform the next step. Then measure registration, group rejoin, circuit construction, packet forwarding, and application receipt separately. Three matching caches can agree about the past. Only a live client and a working data path can show that the multicast service has returned.

Sources