Summary

  • MARS maintained and returned a cluster-local map from a Layer 3 multicast group to ATM endpoints; it did not carry the multicast data.
  • A sender—even one that was not a group member—had to collect a complete MARS_MULTI reply and then create its own point-to-multipoint VC, or receive an MCS address that hid a separate redistribution path.
  • Membership, an attached leaf, an unbroken control sequence or a successful send call described one stage of the system. None alone proved a live receiver, packet delivery, identity, authorization, QoS or security.

The most revealing sentence in RFC 2022 is also the easiest to overlook: MARS does not take part in actual Layer 3 multicasting. The server could know the current association between an IP multicast address and ATM endpoints, answer queries, and announce joins or leaves. The packet did not pass through it.

That separation mattered because ATM supplied connections while IP multicast presented a group address. A sender could not simply place the group address into an ATM call. It first asked MARS which ATM addresses currently represented that group inside the MARS Cluster. Once the answer was complete, the sender asked its local ATM signalling manager to create a point-to-multipoint virtual circuit and add the returned addresses as leaves.

RFC 1112 sharpened the distinction: a host may transmit to a multicast group without joining it. RFC 2022 preserved that rule. A successful request therefore did not certify that the source belonged to the group. It meant only that the source had asked for the server's present map.

A list arrived in pieces

The answer itself had a state machine. If a mapping contained several endpoints, MARS could divide it across multiple MARS_MULTI messages. The x bit marked the final part, while the sequence field y allowed the requester to notice a missing part. An endpoint could act only after receiving the terminating message with a coherent sequence. A gap, timeout or incompatible sequence meant discarding the partial result and trying again.

This is stronger than treating any reply as an answer, but narrower than treating the answer as truth about the world. It established that one protocol exchange had delivered one complete server-side snapshot. A receiver could leave after the snapshot; a leaf addition could fail; or the endpoint could be registered yet unable to consume data.

After resolution, call construction was separate. The endpoint issued a point-to-multipoint setup request and added leaves one by one. RFC 2022 allowed failed additions to be retried and allowed data to flow while some additions were still pending. A VC could therefore be “up” without containing every intended receiver. A successful send invocation proved that data entered a local path, not that every leaf existed or every application received a packet.

The server address might conceal another fan-out

MARS could also return the address of a Multicast Server. From the sender's perspective, the procedure barely changed: resolve the group, open a VC, transmit. The returned leaf might be an actual group member or an MCS, and the endpoint did not need to distinguish them. Yet the MCS—not MARS—would receive and redistribute the traffic.

This transparency simplified senders while making the evidence boundary more important. Seeing an MCS address said nothing about the final receiver set. RFC 2149 later explored MCS architecture and coordination; that later work must not be read backward as if RFC 2022 had already settled multiple-server operation or failure handling.

Joins and leaves repaired local circuit state

Members listened on ClusterControlVC for asynchronous MARS_JOIN and MARS_LEAVE messages. An endpoint used those notices to add or remove leaves from every affected outgoing VC. When removal deleted the last leaf, it closed the VC. The next packet for that group began a fresh query-and-build cycle.

Each control message carried a Cluster Sequence Number. MARS incremented the CSN for every transmission on the control VC, even when the underlying membership register had not changed. A jump therefore meant that a prior control message might have been missed; it did not reveal which event was lost. The prescribed response was to revalidate all open group VCs against fresh MARS mappings, and data could continue during that work.

The sequence number was thus a detector of uncertainty, not a reconstruction of reality. Continuity showed that this receiver had observed an ordered control stream. It did not prove that signalling operations succeeded, that leaves remained live, or that packets traversed the completed path.

What the architecture deliberately did not certify

RFC 2022 confined itself to a MARS Cluster. Inter-cluster routing was outside its model. Mapping Layer 3 QoS onto ATM attributes was left unresolved. Backup-MARS coordination, cleanup of dead members and coordination among multiple MCSs were absent or deferred. Its security section says security is not discussed.

Those omissions prevent a broad operational claim from being smuggled into a narrow record. A registration says an endpoint registered. A complete reply says the server's multipart snapshot arrived. A leaf says signalling attached one ATM address. An MCS address says where the sender submitted traffic. None of these records, alone, establishes present liveness, end-to-end membership, delivery, application receipt, real-world identity, authorization or security.

RFC 2022's enduring contribution was to expose the gap rather than conceal it. The receiver directory and the forwarding path could be synchronized, but they remained different objects owned by different actors. Multicast over a connection-oriented network worked only because endpoints repeatedly converted one into the other—and retained enough state to admit when the conversion might be stale.

Sources