Summary

  • RFC 2210 assigned different meanings and directions to three objects: the sender's unchanged SENDER_TSPEC, the network's hop-by-hop ADSPEC, and the receiver's upstream FLOWSPEC request.
  • A general ADSPEC break bit meant that at least one element lacked RSVP/Integrated Services support; when set, the RFC said every other ADSPEC parameter was unreliable as an end-to-end summary.
  • Service-specific break bits exposed a narrower gap: an RSVP-aware element on the path did not support that particular QoS service.
  • PATH_MTU was reduced across a path and at reservation merge points, while the sender's original maximum packet declaration remained unchanged; packets above the covered maximum could receive only best-effort treatment.
  • None of these signaling stages proved that a route stayed fixed, admission succeeded everywhere, traffic conformed, reserved treatment was delivered, or an application completed.

The warning field mattered more than the measurements

An ADSPEC could look reassuringly quantitative.

Its general information fragment could describe an Integrated Services hop count, an estimate of path bandwidth, a minimum latency and a composed maximum transmission unit. A Guaranteed-service fragment could carry the accumulated error terms used in a delay calculation. Presented together, those values resembled a compact technical portrait of a route.

RFC 2210 made that portrait conditional.

If a network element could not support RSVP and Integrated Services, the general break bit was set. The specification then treated every other ADSPEC parameter as unreliable. It did not say that each number had necessarily been fabricated. It said that the end-to-end premise required to interpret the summary had been broken.

That distinction is the intellectual centre of the document. Precision inside a message does not rescue a missing assumption outside it.

A path could have several RSVP-aware elements that faithfully updated the advertisement and one intervening element that did not participate. The values before and after that point might still be individually intelligible. They could no longer sustain the claim that the object summarized an unbroken Integrated Services path.

The break bit therefore functioned as provenance about the computation. It told the receiver something about whether the path-wide composition was entitled to speak for the whole path.

Three objects, three authors, three directions

RFC 2210 joined RSVP signaling to the IETF Integrated Services model. It did not turn the signaling protocol into the service itself.

The document described three main objects whose names were easy to read as one reservation record. They were not one record.

The SENDER_TSPEC originated with the sender. It described the traffic the sender might generate, using a token-bucket description and a maximum packet size. RSVP carried it downstream in PATH messages. Network elements forwarded the original sender TSpec without rewriting it.

The ADSPEC also traveled downstream, but it had a different author. It was created or updated by network elements. Each participating element composed its local contribution into the advertisement. The result remained roughly constant in size instead of becoming an ever-growing transcript of every hop.

The FLOWSPEC originated with a receiver. It expressed the requested service and traffic parameters, traveled upstream in RESV state, and could be altered through reservation merging or local control processing.

Those directions encode different forms of evidence.

A TSpec is a declaration by the source. It is not a measurement of emitted traffic.

An ADSPEC is a path advertisement assembled by the elements that participate. It is not an admission decision.

A FLOWSPEC is a receiver's request, perhaps later merged with other requests. It is not proof that every element admitted or delivered the requested treatment.

Collapsing the three into “the reservation” erases the very boundaries RFC 2210 was designed to preserve.

A constant-size summary, not a path log

The ADSPEC used the One Pass With Advertising model. As a PATH message moved downstream, capable elements updated composed parameters. The receiver obtained a summary without receiving a complete per-hop ledger.

That economy was important. If every hop appended a new block, the object would grow with path length. Composition instead allowed the signal to stay roughly constant in size.

But composition changes what the object can prove.

The advertised bandwidth is a path-composed value, not a list of the bandwidths observed at every element. The path latency is an accumulated or composed term, not a timestamped trace. The MTU is the minimum relevant value, not a map showing where the restriction occurred. Guaranteed-service error terms are combined according to the service rules rather than preserving every local term separately.

A summary is useful precisely because it discards detail. The break bit compensates for one particularly dangerous kind of discarded detail: the existence of a place where the composition rule could not be applied.

Once set, the bit cannot be repaired by a later capable router. A later hop can support RSVP, update its own local state and understand every object perfectly. It cannot retroactively make the earlier unsupported element part of an unbroken end-to-end computation.

Two different meanings of “break”

RFC 2210 distinguished a general break from a service-specific break.

The general information fragment used service number 1. Its break bit indicated that at least one element lacked the required RSVP/Integrated Services support. That was why the remaining ADSPEC values became unreliable as a path-wide IntServ account.

A service-specific fragment had its own break bit. It answered a narrower question: did every RSVP-aware part of the path support this service?

If a node understood RSVP and Integrated Services but did not implement Guaranteed service, the Guaranteed-service break bit could expose that gap. The same logic applied to another defined service. The node's participation in signaling did not imply support for every service advertised through the signaling framework.

This separation prevented two different failures from being flattened into one.

One failure concerned the path's ability to participate in the general RSVP/IntServ computation. The other concerned the availability of a particular service within the participating path.

It also prevented a common inference in the other direction. A router that understood RSVP was not thereby a Guaranteed-service router. Signaling competence and service capability were separate claims.

An unset bit was not a promise

The break mechanism was strong because it identified a missing premise. It was limited because absence of the warning did not prove every later event.

An unset general break bit meant that the advertisement did not record a hop that lacked RSVP/IntServ processing on the path traversed by that PATH message. It did not freeze the route.

The data path could later change. Reservation state could expire or be refreshed differently. Local resources could be committed elsewhere. Policy could reject a request. Traffic could exceed its declared envelope. A packet could be larger than the size covered by the reservation. Measurement could reveal queueing or loss outside the service's defined assumptions.

The ADSPEC was therefore time- and path-relative evidence.

That does not make it weak. It makes it precise about its scope.

The receiver could use the advertisement, application requirements and local policy to decide what to request. For Guaranteed service, the receiver could use the composed error terms and traffic description to calculate a bound under the service's model. For Controlled-Load, the receiver could request treatment intended to approximate what a conforming flow would see on an unloaded best-effort network.

Neither calculation turned an advertisement into an observed application result.

PATH_MTU exposed the difference between declaration and coverage

The treatment of maximum packet size is one of RFC 2210's clearest examples of layered meaning.

The sender's TSpec included M, the largest packet the sender might generate. That declaration traveled downstream unchanged.

The ADSPEC's PATH_MTU was composed differently. It began with a relevant maximum and was reduced when a participating element encountered a smaller local MTU. The receiver consequently learned the smallest covered value represented by the path summary.

For a reservation involving several senders, the receiver used the smaller applicable value. At reservation merge points, the smaller receiver maximum was carried upstream. The merged value visible to a sender represented the smallest acceptable maximum across the branches included in that merge.

The original SENDER_TSPEC was not rewritten to match.

That was not an inconsistency. The two fields described different realities. The sender's M said what it might send. The path and merged reservation values said what the represented path and receivers could cover under the reservation.

RFC 2210 also preserved the consequence. Packets larger than the covered maximum might receive only best-effort treatment.

A reservation was therefore not a general label attached to all packets from a source. Its scope depended on the traffic and packet-size envelope it actually covered.

The receiver made a request, not a finding

After receiving PATH state, a receiver constructed a FLOWSPEC. That object combined traffic-control information appropriate to the selected service. It then traveled upstream in a RESV message.

The step is easy to narrate as though the receiver merely copied a discovered service level. It did not.

The receiver interpreted an advertisement and expressed a requested service. It could consider its own application needs, the sender description, the ADSPEC and local policy. A Guaranteed-service receiver might calculate a reservation parameter from the desired delay and the advertised composition terms. A Controlled-Load receiver asked for that service's defined treatment.

Network elements then faced their own decisions.

At an RSVP-aware element, the relevant TSpec and FLOWSPEC were passed to the selected traffic-control service. Local policy and admission control still mattered. Requests could also be merged, so the FLOWSPEC continuing upstream need not be byte-for-byte identical to any one receiver's original object.

The upstream object thus recorded another bounded stage: the reservation state produced by receivers, merge rules and local processing. It did not become a data-plane receipt.

Guaranteed and Controlled-Load meant different things

RFC 2210 supplied the mapping between RSVP objects and two service specifications. The service definitions remained in RFC 2211 and RFC 2212.

Controlled-Load service sought behavior closely approximating that received by a conforming flow from an unloaded best-effort network. It required admission control, but it did not offer a specific numerical delay or loss guarantee. Its ADSPEC block did not need a set of additional composed metrics beyond the service-specific break indication.

Guaranteed service used a different model. Its ADSPEC carried Ctot, Dtot, Csum and Dsum, accumulated according to composition rules. Together with the traffic parameters, those terms supported a mathematically derived delay bound under the service assumptions.

The formulas gave real structure to the promise. They did not erase their prerequisites.

The traffic had to fit the described envelope. The path elements had to support the service. The reservation had to be admitted. The represented route and state had to remain applicable. The resulting bound concerned queueing behavior defined by the service; it did not certify remote application execution.

Reading the composed terms without their validity and service conditions would turn a conditional guarantee into an unconditional slogan.

RSVP carried meaning it did not own

The architecture deliberately allowed RSVP to carry service-specific objects without defining every service itself. The setup protocol could treat their internals as opaque while service modules interpreted them.

This was a separation of responsibilities.

RSVP defined how PATH and RESV state moved, refreshed and merged. Service specifications defined traffic parameters and per-element behavior. RFC 2210 defined how the two families met for Controlled-Load and Guaranteed service. RFC 2215 described the composition of local and path parameters. RFC 2216 framed a service as behavior supplied by a network element and composed across elements.

No single layer could truthfully claim the whole outcome.

The sender knew what it declared. A router knew its local capability, policy and admission result. The receiver knew what it requested. RSVP knew the signaling state it maintained. The service module knew the behavior it was asked to provide. Telemetry, if present, knew something about observed packets. The application knew whether its own task completed.

The discipline of RFC 2210 was to connect these roles without pretending they were one observer.