Summary

  • RFC 2383 mapped one ST2+ hop to one ATM virtual circuit and kept data, control and management functions distinct, so a reserved data path was not the same object as the control path that could report its failure.
  • Because ST2+ recovery was unclear and multiple agents could notice an ATM fault simultaneously, the specification required NoRecover; a refused recovery request was more honest than an interoperable promise the network could not keep.

A circuit can reserve bandwidth without reserving a way back from failure.

That was the uncomfortable boundary exposed by RFC 2383, published in August 1998 as an Informational specification for carrying ST2+ over ATM UNI 3.1. The document described a close mapping: a single ST2+ hop used a single ATM virtual circuit, the circuit was not shared with other hops, and the hop was not striped across several circuits. Admission state could therefore acquire a concrete bearer. Yet when the bearer failed, the architecture did not acquire a single, safe owner for reconstruction.

The specification’s answer was unusually plain. Implementations had to select NoRecover in CONNECT. If a requester tried otherwise, the receiver was to reject the request with REFUSE and the NoRecover reason. RFC 2383 did not call that a successful recovery feature with limitations. It declined to claim the feature at all and left recovery to the application.

This refusal matters because the surrounding system had many of the ingredients that are often mistaken for recovery. ATM could indicate a failed connection. ST2+ agents exchanged control messages. A stream carried a FlowSpec and could reserve resources hop by hop. A new connection could be established. None of those facts, alone or together, proved that every participant would agree on who should rebuild which segment, in what order, without duplicating work or exposing a false result to the application.

One hop, one circuit, several kinds of truth

RFC 2383 separated the user plane, the control plane and the management plane. On the user plane, ST2+ data moved over the ATM connection assigned to its hop. On the control plane, ST2+ agents exchanged SCMP messages. Management covered the local machinery that selected addresses, established circuits and observed their condition.

Those planes did not collapse into one path. The document deliberately left the SCMP virtual circuit unspecified. An implementation could reuse an IPv4 circuit or establish a separate circuit for ST2+ control. Data and SCMP messages for a stream had to follow the same ST2+ routing direction, but the IPv4 route to the same IP address could run in the opposite direction. A control exchange could therefore remain possible while the reserved data circuit was broken, or the control path could fail under conditions different from the data path.

This makes “the network is reachable” a weak statement. Reachability might mean an IPv4 packet found a route, an SCMP message reached an agent, the ATM switch reported a call state, or user data still crossed the particular VC. Each is evidence from a different layer. None automatically certifies the others.

The one-hop-one-VC rule sharpened the evidence model. The virtual circuit was not an abstract promise spread across arbitrary bearers. It was the bearer for that hop. But the mapping also localized the failure: a stream spanning several hops depended on several individually established circuits and agents. Detecting the loss of one circuit identified a broken segment. It did not by itself reconstruct the end-to-end stream.

Failure detection was not recovery coordination

The RFC allowed the ST2+ HELLO function to go unsupported over ATM. ATM was expected to provide adequate notification of connection failure, making periodic HELLO traffic seem redundant. But the document immediately exposed why detection was not enough: ST2+ data and SCMP control could travel on different virtual circuits. A HELLO result on one path could not establish the state of the other.

The same separation complicated recovery. RFC 1819 had described recovery behavior for ST2+, but RFC 2383 judged it unclear and incomplete for this environment. ATM could notify all affected parties of a failure. Multiple ST2+ agents might therefore detect the same fault at nearly the same time. If each independently attempted recovery, their actions could race. One agent might be releasing state while another reconstructed it; two agents might create competing replacement segments; downstream state might be joined to the wrong attempt.

The protocol needed more than a trigger. It needed an authority rule, a shared recovery identity, an ordering discipline and receipts that distinguished detection, teardown, re-establishment, stream reconstruction and application acceptance. RFC 2383 supplied none of those as an interoperable recovery contract. Its mandatory NoRecover setting was recognition of that missing control surface.

This is the difference between fault indication and outcome. A switch can truthfully say that a VC is gone. An agent can truthfully say that it received the indication. A second circuit can truthfully say that admission succeeded. The application can still lack the stream it intended, or receive it with a discontinuity that changes the result. The chain needs separate receipts.

The application inherited the last obligation

RFC 2383 stated that stream recovery was not supported and that the application had to provide it. That sentence did not magically make applications capable of reconstruction. It assigned the unresolved obligation to the layer with enough context to decide what continuity meant.

For one application, recovery might mean reconnecting and resuming from a sequence number. For another it might mean starting a fresh stream, discarding partial output or asking a human whether duplicated delivery is acceptable. The network did not know which semantic outcome preserved the work. It could offer a new path; only the application could determine whether the old and new paths formed one valid operation.

The delegation also created a proof requirement. An operator could not label a stream recovered merely because ATM established a replacement VC. Evidence would need to join the fault indication, the identities of the old and new circuits, the released reservation, the rebuilt ST2+ hop state, the end-to-end stream identity and the application’s own completion signal. Without that join, “recovered” described an aspiration rather than an observed result.

Heng Lu’s reality-layer lens is particularly useful here. A physical link state, an ATM call state, an ST2+ agent state, an SCMP exchange, an application session and a user-visible outcome occupy related but non-identical layers. The temptation to compress them into one green indicator is a form of symbolic power: the dashboard gains clarity by discarding the distinctions that determine whether the claim is true.

Admission remained a policy decision

Even before failure, circuit establishment had a direction and an owner. For switched virtual circuits, RFC 2383 said the party that initiated the ATM connection could be chosen according to operational or billing policy. That direction was independent of the sender-to-receiver orientation used while the ST2+ stream was built.

The distinction matters because control follows incentives. The party paying for a call may initiate it; the party constructing a stream may expect the next hop to act; the agent observing a failure may not be authorized to create the billable replacement. A recovery design that ignores those boundaries can be technically plausible and operationally impossible.

The FlowSpec-to-ATM mapping also had hard edges. ST2+ traffic characteristics and service qualities were translated into ATM parameters, drawing on the service models described in RFCs 2211 and 2212 and the ATM signaling guidance in RFC 1755. UNI 3.1 did not support changing QoS on an established connection. If a supported FlowSpec change required different resources, the implementation had to release the old ATM connections and establish new ones.

That is not an in-place edit. It is a custody transition between resource allocations. The old circuit may still carry traffic while the new request is assessed; or it may be released before replacement succeeds, depending on implementation and policy. RFC 2383 specified the mapping and the need to rebuild, but it did not publish measurements proving lossless changeover, preserved application state or a particular deployment’s behavior.

The boundary distinguishes this history from RFC 2380. RFC 2380’s central problem was changing reservations with reduced allocation and an old/new commitment boundary. RFC 2383’s sharper problem was what happened after an ATM failure when several agents could see the fault but the protocol lacked a complete recovery authority. Both concern resource state, but they assign uncertainty to different decisions.

An explicit refusal was a form of interoperability

It is tempting to view NoRecover as an absence: a feature that the authors did not finish. It was also a positive interoperability choice. If one implementation attempted a private recovery sequence while another interpreted the same state differently, the pair could produce duplication, leaked reservations or a stream whose application meaning diverged at each end.

Requiring the flag made the limitation negotiable in the only safe sense: there was nothing ambiguous to negotiate. A peer requesting recovery received REFUSE with a named reason. The failure was visible at setup rather than hidden inside a later outage.

Through Heng Lu’s minimum-initial-specification lens, that is a disciplined use of incompleteness. A minimum specification should not fill uncertain territory with words that resemble guarantees. It should define the interoperable core, localize the unshared decision and preserve room for later running code to prove a stronger contract. Here, dedicated circuits, addressing, setup and resource mapping belonged to the shared core; stream recovery did not.

The running-code lens raises the next question: what evidence would justify removing NoRecover? A prose extension would be insufficient. Implementers would need adversarial tests in which multiple agents receive the same ATM failure indication, choose one recovery authority, suppress duplicates, account for the old reservation, establish the replacement, rejoin the correct stream and expose an unambiguous result to the application. The test must include lost control messages, asymmetric routes and control/data failures that do not coincide.

RFC 2383 did not claim those results. Its Informational status, and the RFC Editor’s record of that status, constrain historical interpretation. It was a protocol specification, not a deployment survey. The IETF datatracker records its publication history; it does not turn the design into evidence of broad use.

Security protected one edge of the chain

The security discussion was similarly bounded. The document said its minimal ATM extensions and bug fixes did not weaken the security of ST2+ or UNI 3.1. It also noted that a network-supplied calling-party number, if verified, could contribute to authentication.

“Contribute” is the important word. A calling-party identity might help establish who initiated a circuit. It did not prove that the FlowSpec matched application authority, that the indicated caller still controlled the endpoint, that a replacement VC belonged to the failed stream or that the application accepted the reconstructed session. Identity evidence covered one edge; resource, state and outcome evidence remained separate.

The same restraint should govern a modern reading. RFC 2383 cannot be used to claim a particular provider deployed ST2+ over ATM, that a circuit met a latency target, that an outage was recovered, or that billing policy selected a specific initiator. Those are implementation and operational facts requiring their own records.

What the RFC does establish is more durable. Resource reservation, failure detection, control reachability, reconstruction and application success are different claims. A system can possess the first three while lacking the fourth, and can rebuild infrastructure while still failing the fifth. In 1998, RFC 2383 chose to say so with one uncompromising flag: NoRecover.

That flag was not an admission that nothing useful could be done after failure. It was a refusal to let the network promise a completed recovery whose authority, ordering and final receipt had not been standardized. The circuit could reserve resources. The agents could learn that it had broken. The application still owned the meaning of beginning again.

Sources