Summary

  • RFC 2366 modelled MARS clients, MARS servers and multicast servers through SNMP tables, but explicitly allowed a parent row to be deleted while associated virtual-circuit rows still existed or were in use.
  • A read-create object described the widest interface the model allowed, not a promise that every conformant agent accepted writes; an active row, counter, trap or successful SET still did not prove data-plane teardown or delivery.

Imagine an operator looking at an ATM multicast system in 1998. The console shows a client, its address, a registration state, several timers and a set of virtual circuits. The operator removes the client row. The command succeeds. The row vanishes.

What, exactly, has ended?

RFC 2366 refused to let the interface answer more than it knew. Its marsClientRowStatus object could create, modify or delete a client row. Yet the specification expressly permitted that deletion even when rows in an associated table—its example was the client VC table—still existed or were in use. Afterward, the agent or management station was advised, where possible, to delete stale associated rows with further SET operations.

The deletion was therefore not a cascade. It was one management-plane transition followed by a reconciliation obligation. The virtual circuit might have been released, might still have been carrying traffic, or might have survived only as an obsolete table entry. The missing parent row proved none of those alternatives by itself.

That was not an isolated drafting accident. RFC 2366 repeated the same rule for the MARS server row and the multicast-server, or MCS, row. A MARS row could be removed while marsVcTable entries remained or were in use. An MCS row could be removed while its VC rows remained or were in use. In all three roles, cleanup was a separate act, qualified by the agent's or management station's ability to perform it.

The structure reflected the system it was trying to expose. RFC 2022 had described a Multicast Address Resolution Server that distributed membership information inside an ATM cluster. A sender could construct point-to-multipoint virtual circuits to receivers, or hand traffic to an MCS that built and maintained circuits on its behalf. RFC 2366 did not become that machinery. It projected parts of it into a virtual information store.

The projection was broad. The client group contained the client's ATM address, default MARS, registration state, cluster identifiers, timers, multicast address ranges, backup servers, open VCs and message counters. The MARS group exposed server status and priority, host and MCS maps, registered parties, VCs and statistics. The MCS group had its own registration, backup, circuit and counter tables. These rows could be correlated, but correlation was not identity.

A registered-client entry was not the client's whole configuration. A host map was not an open circuit. A VC row described VPI/VCI coordinates, group ranges, party addresses, connection type, control role, idle timer, revalidation flag, encapsulation and negotiated MTU. It still did not show that the ATM switch retained the connection, that packets traversed it, that every leaf received them or that an application consumed them.

RFC 2366 also divided management authority more finely than its repeated read-create labels first suggested. Configured host and server maps could be manipulated through RowStatus, while dynamically learned rows could not be modified or deleted that way. A VC row could be taken out of service and edited in some circumstances, but an SVC row could not be modified or deleted through that path. The agent, the signaling system and the manager did not possess the same powers over every record.

There was another qualification at the end of the MIB. Many objects declared MAX-ACCESS read-create: the model allowed an implementation to expose them as writable and creatable. Its compliance statements, however, lowered the required access for those objects to read-only and repeated that write access was not required. RFC 1904 explains why the distinction matters: a writable implementation must be able to influence the underlying managed entity in response to a SET. A conformant observation-only agent did not need to make that promise.

Thus the ASN.1 definition described a ceiling, while the compliance statement set a floor. Software that generated an “edit” control merely from MAX-ACCESS could meet a perfectly conformant agent that refused the SET. Conversely, a successful SET established only that this agent accepted and processed this operation. It did not establish who was authorized to request it, whether the change persisted, whether a circuit signal followed or whether service improved.

The counters were bounded in the same way. Clients counted requests, joins, leaves, multipart replies, NAKs, migrations and timeouts waiting for the last MARS_MULTI. MARS servers counted transmitted and received control-message families and groups with registered members or MCSs. Multicast servers counted their requests, service messages, multipart responses and timeout events. These values answered “how many did this instance record?” They did not answer which packet reached which receiver.

Even apparently direct state had layers. A default MTU lived in the client or MCS row, while a VC carried a negotiated MTU that could differ. A registration enum reported the agent's current state, not an independent acknowledgement by every other participant. Sequence values helped expose missed control messages or membership changes, but did not certify the data path. The single fault notification carried a MARS address and service status; generation, transport, manager receipt, diagnosis, repair and recovery remained separate events.

The document's security section made the control surface explicit. Unprotected SET operations against read-write or read-create objects could damage network operations. SNMPv1 alone did not decide which party on an otherwise secured network was entitled to change, create or delete them. RFC 2366 pointed to SNMPv3's user-based security and view-based access control, then added a quieter warning: even read access might need control.

That warning followed from the data itself. A read-only observer could learn ATM addresses, membership, mappings, backup preference, circuit parties, negotiated MTUs, timers and failure state. Confidential transport, authenticated identity, an authorized view and a legitimate operational purpose were four different checks.

The MIB's own identifier soon supplied a final historical lesson. RFC 2366 rooted the module under snmpModules. Two months later RFC 2417 obsoleted it because that assignment was a clerical error and re-rooted the same model under mib-2 57. The rows' semantics had not required reinvention; the public coordinate used to find them did. A correct management value under the wrong module identity was still difficult to exchange reliably.

RFC 2366's contribution was therefore not a glass cockpit that made the ATM cluster self-evident. It was a common language for asking narrower questions. Which role did this agent expose? Which row did it return? Was the row configured or learned? Was the operation readable, writable or only theoretically writable? What associated state remained after deletion?

The hardest question came last. When the row was gone, what evidence showed that the circuit was gone too? The RFC left that answer outside the row—and that was the honest boundary.

Sources