Summary

  • RFC 2382 warned that sharing a data VC with RSVP signalling saved circuits and setup time but exposed reservation refreshes to drops caused by non-conforming data.
  • A separate signalling VC supplied an independent traffic contract, not a proof of successful service; operators still needed receipts for admission, carriage, state refresh and data treatment.

The loop was easy to miss because each local decision looked efficient. RSVP maintained a reservation with periodic PATH and RESV messages. ATM carried packets over virtual circuits governed by traffic contracts. If the control messages followed the associated data on the same VC, no extra circuit was needed and PATH messages incurred no additional ATM setup delay.

Then the data exceeded its contract.

An ATM network could discard non-conforming traffic. When control and data shared the same treatment, the discard set could include the RSVP message that refreshed the reservation. Occasional loss was part of RSVP's design assumptions. Sustained loss was different: soft state could expire, the QoS VC could be torn down and the system could start constructing it again. A design chosen to avoid additional signalling could create a cycle of additional signalling.

RFC 2382's historical value lies in making that dependency explicit. Control traffic was not outside the service architecture. It needed a path, a traffic contract and a failure model of its own.

Soft state made receipt time part of correctness

RSVP did not install permanent truth. RFC 2205 defined reservation state in routers and hosts as soft state, periodically refreshed by PATH and RESV messages. If matching refreshes did not arrive before a cleanup timeout, the state was deleted. A teardown could remove it immediately, but silence would eventually remove it as well.

This was deliberate. Routes and multicast membership changed. Soft state let obsolete reservations disappear without depending on a perfectly reliable deletion transaction. PATH and RESV messages were idempotent, and periodic transmission could absorb occasional packet loss. RFC 2205 even described how several consecutive losses might be tolerated when the cleanup interval was a multiple of the refresh period.

Tolerance was not immunity. The same specification recommended that traffic control reserve some minimum bandwidth for RSVP messages so congestion would not erase the mechanism maintaining the reservation. A sender-side counter saying “refresh emitted” therefore proved only the first step. The operational result depended on classification, carriage, timely receipt and state update at each relevant hop.

ATM sharpened this distinction. A virtual circuit could remain physically or logically present while the RSVP state associated with the intended service expired. Conversely, a refresh could arrive while the QoS call needed to support the data had been rejected. “VC up,” “RSVP state present” and “promised data treatment observed” were three different propositions.

Four ways to carry the lifeline

RFC 2382 described four broad arrangements for RSVP control traffic. Signalling could share the data VC. A separate signalling VC could be paired with every reservation. Multiple sessions with the same ingress and egress set could share one point-to-multipoint signalling VC. Or several point-to-point signalling VCs could be multiplexed among sessions.

The list was an allocation of failure domains as much as an allocation of circuits.

The shared arrangement minimized VC count. It also avoided the latency of building a new ATM control circuit before a PATH message could proceed. Yet it made signalling subject to the data VC's traffic treatment. The RFC singled out non-conforming data as the dangerous case: RSVP messages might be dropped with it, and excessive loss could produce repeated teardown and re-establishment of QoS VCs.

Using the best-effort data path was a variation. It separated signalling from non-conformance on the QoS VC, but moved the risk to congestion. RSVP could survive moderate loss, not an indefinitely starved path. RFC 2382 said control messages should be offered a preferred service class and noted that giving them priority in an IP scheduler before ATM was promising but difficult.

A dedicated signalling VC took the clearer route. Each data reservation gained a parallel circuit with its own traffic contract. Compliant control messages would no longer be discarded because data on the other VC violated its contract. The price was concrete: twice the minimum VC count, more ATM signalling and extra setup latency.

None of these choices was “control plane good, data plane bad.” They moved costs and dependencies. Sharing economised on state in the ATM network. Separation purchased isolation with circuits and setup work.

Multiplexing changed what had to be proven

Multiplexing tried to keep isolation without paying for a signalling VC per reservation. A point-to-multipoint control VC could serve sessions that shared one ingress and the same set of egress routers. But multicast membership changed. When that egress set changed, the ingress had to find another matching VC, create one, modify the existing circuit or keep sending to an endpoint that no longer needed the traffic.

The efficiency claim therefore depended on the actual traffic and topology. The same was true for multiplexed point-to-point VCs. Long-lived circuits in the core could amortize setup cost and exploit reverse channels, while the number needed still followed the set of participating IP nodes and their communication pattern.

Reuse of a best-effort VC reduced the count again but raised the probability of losing RSVP messages. A circuit inventory alone could not settle the design. The useful denominator was maintained reservations per reliably delivered control path under the conditions that mattered.

This changed the receipt. For a dedicated control VC, operators could link a PATH or RESV packet to a control-circuit identifier and its traffic contract. For a multiplexed VC, they also needed the session-to-VC mapping and the egress set valid at that moment. Without those records, a control packet capture could not show which reservations depended on the path that failed.

Even control QoS could be overprovisioned

One might answer every risk by assigning a strong QoS class to signalling. RFC 2382 refused that shortcut. RSVP traffic was infrequent—typically on the order of one refresh every thirty seconds—so a relatively small allocation should suffice. Asking for a large one could cause the signalling VC itself to be rejected when resources were scarce.

The fallback was equally awkward. If a QoS call failed because the ATM network was congested, moving the control messages to best effort placed them in the same congested network with less protection. “Fallback available” was not “fallback carried.”

This is where RFC 1755's earlier concern about connection thrashing becomes useful context. ATM signalling rules were already designed to prevent needless creation and destruction of parallel connections. RFC 2382 showed another path to instability: packet loss in the control carriage could make RSVP's dynamic state repeatedly remove and rebuild the service circuit.

The correct abstraction was not a green control-channel indicator. It was a sequence of bounded claims:

  1. a specific RSVP message was generated;
  2. it was assigned to a specific VC and traffic treatment;
  3. that VC was admitted and active;
  4. the message crossed the ATM segment;
  5. matching state was refreshed before expiry;
  6. the data VC remained installed; and
  7. observed packets received the intended service.

Every step could succeed while the next failed. That was the point of separating them.

RFC 2382 did not choose one universal topology. It defined enough of the problem that implementations could choose among shared, dedicated and multiplexed control paths without pretending they had the same cost or evidence. The minimum invariant was narrower: the mechanism maintaining soft state had to remain observable and sufficiently protected to make that state truthful.