Summary

  • RFC 2205 made an RSVP reservation a receiver-initiated, hop-by-hop arrangement. Each node still had to pass resource and policy tests, install traffic-control state and keep that state alive with matching refreshes.
  • A ResvConf is not proof of end-to-end service; the standard says it gives no guarantee. A defensible claim joins path, request, local decisions, installed rules, refresh epoch, confirmation scope and measured data-plane outcome.

The most honest reservation is the one that disappears

Suppose a dashboard says a flow is reserved. The signal is comforting precisely because the word appears durable. Yet the most revealing event in RSVP is not the first affirmative message. It is the moment a router deletes state because the matching refresh stopped arriving.

That deletion is not an embarrassing exception. It is the contract. RFC 2205 describes Path and reservation state as “soft state”: Path and Resv messages create it, later messages refresh it, and a cleanup timer removes it when refresh ceases. The protocol can tolerate a bounded run of lost signalling packets, but it does not let yesterday’s request become a permanent claim on today’s path.

This design turns time into part of the evidence. “Reserved” is incomplete unless it names a receiver, sender set, route, traffic specification, policy decision, installed treatment, last matching refresh and expiry horizon. Without those fields, the status has lost the mechanism that makes it true.

The request travels against the data

RSVP’s directionality matters. A sender periodically sends Path messages downstream along the route that data would take. Each RSVP-capable node records path state, including the previous hop. A receiver then originates a Resv request that moves hop-by-hop upstream, using that recorded path information.

The receiver-led model was built for unicast and changing multicast groups. Different receivers may ask for different service, and their requests can merge as they move toward a sender. The request a router forwards upstream may therefore differ from the one it received: local traffic control can adjust a flow specification, and multiple downstream branches can be combined.

A captured Resv packet is consequently evidence of a request at one point, not a complete map of the reservation. A captured Path packet shows the route state visible to one node, not that reverse signalling reached every relevant hop. Even before admission is considered, the two messages describe different halves of a distributed conversation.

Every hop answers two separate questions

At each intermediate node, RSVP passes the request to admission control and policy control. Admission asks whether enough resources are available. Policy asks whether the requester is allowed to reserve them. RFC 2205 requires both answers to be favourable.

Only then does the node configure the packet classifier and packet scheduler, or the appropriate link-layer mechanism, for the requested service. RSVP transports the QoS and policy parameters but does not interpret all of their substance. That authority remains with local traffic-control and administrative systems.

These boundaries defeat a common shortcut. Sufficient capacity is not permission. Permission is not installation. Installation on one outgoing interface is not installation on the rest of the path. An accepted control message does not show that live packets matched the classifier or received the scheduled treatment.

The 1997 applicability statement, RFC 2208, made the institutional problem plain. Router processing and storage, aggregation, security and policy control all affected deployment. Those cautions should not be converted into a current census, but they explain why a signalling format could never supply the entire operating system around a reservation.

The confirmation that disowns certainty

RSVP lets a receiver ask for confirmation. Where a request reaches a merge point and an equal or larger reservation already exists, a node can return a ResvConf rather than forward that request farther. This looks like the ideal green receipt.

RFC 2205 refuses that interpretation. It says receipt of a ResvConf gives no guarantees. The document supplies a concrete case: requests from two receivers merge; one can receive confirmation while the other request has not yet propagated to a matching sender and may still fail. A ResvConf can be followed by a ResvErr.

The safe statement is narrower. A named node processed a confirmation request using the state visible there. The confirmation does not prove that every hop admitted the flow, that every classifier and scheduler reflects the request, that routing remained unchanged, or that the application experienced the promised quality.

This is not semantic modesty for its own sake. It is protection against turning one affirmative control-plane event into an end-to-end service certificate.

Route changes make old truth expire

Path and Resv messages are idempotent. A route change lets the next Path message establish state on the new route; later Resv messages build reservation state there. The unused segment of the old route is allowed to time out.

Explicit PathTear and ResvTear messages can remove state faster, but they are not delivered reliably. Lost teardown is survivable because the lease expires. RSVP’s clean-up property is therefore stronger than any single deletion message: absence of continued refresh eventually withdraws the old claim.

That same mechanism produces a subtle partial state. When admission fails at one node, reservations downstream of the failure can remain. The standard preserves them so a receiver can obtain service on part of the path or recover quickly from a transient route failure. A downstream router may truthfully report installed reservation state while no end-to-end reservation exists.

A useful record must therefore show where the request stopped, which state remains, and why. Collapsing a distributed path into one Boolean hides the very condition the protocol was designed to manage.

Fewer refresh bytes do not create a permanent reservation

Full Path and Resv refreshes can be expensive. RFC 2961 introduced refresh-reduction extensions: message identifiers, per-hop acknowledgements for specified signalling, bundling, and Summary Refresh messages that can refresh known state without repeating every object.

The efficiency improvement changes the representation of a refresh, not its meaning. A Summary Refresh must preserve the synchronization properties of ordinary Path and Resv refreshes. If a receiver cannot find the named state, it can return a refresh NACK. Message acknowledgement is hop-specific evidence that signalling arrived; it is not proof of end-to-end service.

The relevant clocks remain separate. The request has an epoch. Each node has a refresh interval and cleanup deadline. A message identifier has an epoch and neighbour scope. Installed traffic control has its own version. Measured service has an observation window. Saving bandwidth by compressing a refresh does not merge those clocks into one.

A diagnostic reply is a snapshot, not an outcome

RFC 2745 added DREQ and DREP messages so a requester could collect path or reservation state from RSVP nodes. Each hop can attach a diagnostic response, and the collected reply can expose where expected state is missing or differs.

But the diagnostic mechanism has its own limits. Replies may be fragmented, may terminate early on an error, can take a different return route, may encounter firewalls and can time out. More fundamentally, DREP reports stored control state at an observation time. It does not prove that a scheduler applied the state to the intended packets or that delay, loss and throughput met an application’s need.

Diagnosis is valuable because it adds another witness. It becomes dangerous only when the witness is asked to testify to something it did not observe.

Zhang’s contribution, without the jurisdiction myth

The IETF Datatracker lists Lixia Zhang among the authors of RFC 2205 and records a wider body of protocol work. Her UCLA biography says RSVP was conceived and developed during her time at Xerox PARC. RFC 2205 itself credits a research collaboration and a larger standards community; Robert Braden edited the specification alongside Zhang, Steven Berson, Shai Herzog and Sugih Jamin.

The Internet Hall of Fame connects Zhang’s work to RSVP and to later RSVP-TE practice. That recognition is not a deployment measurement, and RSVP-TE is not identical to the original integrated-services protocol. The evidence supports co-design and sustained contribution. It does not make Zhang the sole inventor, present operator, IETF consensus owner or guarantor of any live service.

That attribution boundary mirrors the protocol. An author can help specify the messages. A receiver chooses what to request. Routing chooses the path. Each domain applies admission and policy. Equipment installs local state. Operations observes performance. Authority stays distributed even when a name gives the history a human centre.

Seven receipts for one careful word

The word “reserved” becomes defensible when seven records can be joined.

First is the path receipt: sender, session, route, previous-hop state and time. Second is the request receipt: receiver, exact Resv content, flow and filter specifications, confirmation request and epoch. Third is the authority receipt: admission and policy decisions at each relevant hop.

Fourth is installation: classifier and scheduler target, transaction result and configuration readback. Fifth is renewal: refresh interval, last matching refresh, cleanup deadline, Summary Refresh identifier and any NACK. Sixth is the scope of ResvConf or DREP: which node spoke, about which state, at what time. Seventh is outcome: the actual data path and measured service during a bounded window.

No one receipt upgrades the others. Together they support a precise claim: a particular receiver requested treatment for a defined flow; named nodes accepted it under named policies, installed stated controls and retained them through a known refresh epoch; observed traffic then received a measured result. That conclusion is narrower than a timeless green badge. It is also far more useful.

Sources