Summary

  • ATM UNI could not change QoS parameters on a live VC, so RFC 2380 required a replacement circuit to be built while the old one continued carrying traffic; only a completed replacement authorized cutover and teardown.
  • If replacement failed, an increase request returned an error, but a decrease request was treated as successful while the larger old allocation remained—making requested state, protocol response, installed resources and observed service different receipts.

Success without a matching circuit

RSVP allowed reservations to change at any time. ATM UNI 3.x and 4.0 did not allow the QoS parameters of an established virtual circuit to be edited in place. RFC 2380 bridged the mismatch with replacement rather than mutation.

The old VC had to remain unmodified while a correctly sized new VC was established. Traffic moved only after the replacement existed; only then could the old VC close. If setup failed, the old circuit stayed in use. This was make-before-break before the phrase became routine operational shorthand: continuity had priority over making the installed network immediately mirror the newest request.

The surprising part appeared when replacement failed. If the new reservation was larger, the requester received an error because the old circuit could not provide the added resources. If the new reservation was smaller, the modification was treated as successful even though the larger allocation remained. The RFC called the result suboptimal, but preferred continued service and RSVP error-handling conformance to an interruption made merely for accounting symmetry.

That reply did not assert that ATM had shrunk the allocation. It said the service obligation of the smaller request could be met by the larger incumbent. A truthful system therefore needed two records: what RSVP now required and what the physical VC still held.

Silence did not retire a reservation

Ordinary IP-over-ATM VCs were often removed after inactivity because connectionless IP offered no explicit end signal. RSVP did provide messages and timeouts governing resource lifetime. RFC 2380 therefore prohibited inactivity teardown for RSVP-controlled data VCs. The initiator's timer had to be effectively infinite, and a receiver could not clear an incoming connection merely because it had been quiet.

The distinction mattered because silence on the data plane was not a release instruction on the control plane. An inactivity counter described observed traffic; RSVP state carried authority over the reservation. Treating the first as the second could destroy a valid allocation.

Receiver request, sender-built circuit

Another mismatch concerned direction. RSVP reservation requests originated at receivers, while ATM connection control belonged to senders. RFC 2380 required the subnet sender to establish QoS VCs and the subnet receiver to accept them. The request and the actuator were separated across the subnet, so a RESV message could not itself serve as a circuit-creation receipt.

Control and data were also kept apart. RSVP messages could use best effort or a separate control VC, but could not share the associated QoS data VC. That separation created explicit failure semantics. An unrecoverable data-VC failure was an allocation failure. An unrecoverable control-VC failure required associated QoS VCs to be released so forwarding state could not outlive reservation state invisibly.

Multicast chose bounded duplication over a gap

Changing a point-to-multipoint VC forced a choice. Sending on both old and partly built new VCs could duplicate packets; sending only on the incomplete replacement could omit receivers. For a new multicast QoS VC, RFC 2380 required waiting until every party had been added before carrying traffic. When one endpoint moved from best effort to an existing QoS VC, however, it had to be added first and removed from the old VC second. Brief duplication was acceptable because add-before-drop avoided loss.

The two rules are not inconsistent. They protect the same outcome under different transition shapes. A system must record membership completion, cutover and duplicate windows rather than reducing the event to “VC active.”

A transition has more than one truth

RFC 2380's historical lesson is that continuity creates temporary divergence. The request may be smaller, the reply successful, the circuit larger, the resource bill unchanged and delivery uninterrupted. In multicast, one receiver may briefly see two copies so that it never sees none. The architecture works only if those truths are preserved separately and reconciled after transition.