Summary

  • RFC 2379 recommended carrying RSVP control messages on an already available best-effort path, even when those messages would cause separate ATM virtual circuits with explicit quality-of-service parameters to be created.
  • Its deeper lesson is evidentiary: a PATH or RESV message, RSVP state, an admitted reservation, a configured VC and delivered application performance are related events, not interchangeable proof.

A request without the service it requested

The memorable fact in RFC 2379 is also the easiest to flatten into a paradox. RSVP existed to request resource reservations. ATM could construct virtual circuits with specified service characteristics. Yet the implementation guidance did not begin by demanding a protected signaling circuit for the signaling itself. It recommended that RSVP messages use the best-effort data path already used to reach the destination or, for multicast, the existing best-effort path to the group.

The reason was practical. Before a session could be established and a reservation initiated, some path already had to carry ordinary traffic. Reusing it for RSVP control reduced the number of ATM virtual circuits an implementation had to create and maintain. The design therefore began with an asymmetry: the control plane could ask for a stronger data service while travelling over a weaker one.

RFC 2379 did not pretend that the weak path had become strong. It acknowledged that a best-effort VC might not offer all the reliability RSVP control would prefer. The answer lay in RSVP's temporal design. Reservation state was soft state, refreshed over time rather than made permanent by one transaction. Some packet loss could be tolerated without losing synchronization, because another refresh could repair what one missed message had failed to maintain.

That is not the same as saying loss did not matter. It says the meaning of one lost control packet depended on later observations: whether refreshes arrived, whether state expired, whether admission remained valid and whether the associated circuit survived. Reliability came from a process unfolding through time, not from reclassifying the transport of one message as guaranteed.

One reservation, one circuit—for then

ATM rewarded aggregation. A network could, in principle, carry several RSVP sessions on shared virtual circuits and gain efficiency. RFC 2379 treated that possibility cautiously. Aggregation was still a research topic, so the implementation recommendation was to use an independent VC for each RSVP reservation.

The choice exposed another boundary. An RSVP session was not automatically an ATM circuit, and an ATM circuit was not automatically evidence of the requested service. The implementation had to translate a reservation into ATM service parameters, create or select a VC, classify traffic onto it and maintain the relevant state. Each stage could be observed separately.

The companion documents published with RFC 2379 divided the work deliberately. RFC 2380 set implementation requirements. RFC 2381 described mappings from Integrated Services controlled-load and guaranteed service to ATM. RFC 2382 supplied the broader framework. The partition matters because it prevents a single successful signal from standing in for the entire chain.

Shortcuts inherited their destination

ATM shortcuts complicated the picture. A shortcut could cross logical IP subnet boundaries, so PATH and RESV messages might encounter asymmetric routes. RFC 2379 relied on established RSVP behavior—the NHOP object and forwarding of a message that arrived at the wrong interface—to cope with that asymmetry.

Its more consequential shortcut rule concerned authority over the endpoint. A QoS shortcut was not supposed to invent a destination independently. When best-effort traffic had already selected a shortcut endpoint, the RSVP-triggered QoS VC should use the same endpoint. Under the recommended model, if a best-effort shortcut was never established, a cross-subnet QoS shortcut would not appear either.

This was not a ban on reserved service. Hop-by-hop QoS VCs remained possible. It was a constraint on how a shortcut learned where to terminate. Discovery belonged to the best-effort forwarding context; QoS construction followed that prior decision. The resulting circuit was downstream evidence of configuration, not retroactive proof that discovery, admission or delivery had all succeeded.

Multicast resisted one neat answer

Multicast receivers made uniformity impossible to assume. Some could request different service levels; others could request no QoS at all. The companion framework described fully heterogeneous, limited heterogeneous, homogeneous and modified homogeneous models. RFC 2379 did not crown one model as universally correct. It required support for at least limited heterogeneity or modified homogeneity, preferably both with a way to choose.

That restraint is part of the document's historical value. The BCP did not erase operational diversity to produce a cleaner diagram. It specified a workable minimum while leaving the mismatch among receivers visible.

Four receipts, not one

The safest reading of RFC 2379 separates at least four receipts. First, a best-effort path carried a control message. Second, RSVP state recorded and refreshed a request. Third, an admission and configuration process could create an ATM VC with service parameters. Fourth, counters and application observations could show what traffic actually received.

None should be used as a substitute for the next. A transmitted PATH message does not prove a RESV returned. A RESV does not prove admission. A live VC does not prove packets were correctly classified. A QoS label does not prove delay, loss or delivery. The architecture worked precisely because it connected those layers without declaring them identical.