Summary

  • RFC 2215 separated every network element's local contribution from the value composed across a path and treated characterization as conceptually per-next-hop.
  • It used different algebra for different claims: OR for a break in Integrated Services support, increment for aware-hop count, minimum for available bandwidth and path MTU, and bounded addition for minimum latency.
  • Unknown and indeterminate values were designed to persist. A clean value from a later hop could not repair an unsupported element, an unavailable bandwidth estimate, or an unknowable latency contribution.

One path did not imply one operation

Imagine a setup message arriving at a router with four facts about the route already traversed. One says whether any earlier element failed to support the required control framework. One says how many Integrated-Services-aware elements participated. One estimates the narrowest available bandwidth. One accumulates the smallest possible propagation and processing latency.

The router cannot put all four numbers into the same averaging function. A single unsupported point is enough to contaminate a path claim, so that condition uses logical OR. A participant count must rise by one. A bottleneck quantity can only stay the same or shrink. A delay contribution must be added. RFC 2215, published in 1997, turned those differences into a compact accountability system.

This was not a report of observed service. Characterization was information about the QoS-control environment along a candidate flow's path. It could help an application or another network element decide what to request. The word “could” carries the boundary. The object described what the path claimed under specified rules before a particular reservation had necessarily been made.

Local facts and composed claims had different identities

RFC 2215 gave each characterization two forms. A local value described one network element. A composed value combined the already traversed path with that local contribution and was passed to the next element. Composition could run toward the receiver or toward the sender.

The document called every characterization conceptually per-next-hop. A device controlling a shared medium or a large cloud might need one value for one next hop and another value for a different exit. Treating the number as a permanent property of the box would erase the path choice that made it true. A vendor could store one value only when the alternatives stayed within a documented tolerance.

Local and composed quantities received distinct identifiers. That allowed management to inspect both what an element supplied and what the path had accumulated at that point. Once only the final number survives, the operation can no longer reconstruct the contributors. A minimum does not identify the bottleneck. A sum does not reveal which element contributed how much. An OR flag does not locate the break.

Default was a branch, not a universal fact

General parameters had a common definition across services, but their values could differ. Service number 1 represented the global or default branch. A service-specific value represented an override for one service.

The precedence rules preserved both meanings. If a service-specific value arrived and the local service had its own override, those values composed together. If the local service had no override, the arriving service branch composed with the local global value and remained service-specific. If a global value arrived at an element that exposed an override, a new service branch was created while the global branch continued independently.

The example in the RFC is deliberately concrete. A router might support an ordinary path MTU of 1,500 bytes while its Guaranteed Service implementation could handle only 250 bytes. The smaller override did not claim the physical path had shrunk. It claimed that this service imposed a tighter executable boundary. Collapsing the branches would either mislead the service user or understate the ordinary path.

A break propagated by OR

The local NON_IS_HOP parameter became true when an element lacked the relevant QoS service or knew that the chain had a gap. Its composed form applied logical OR. After one true contribution, every later result remained true.

That monotonic rule matched the claim. Four capable routers after an unsupported tunnel could not make the tunnel retroactively capable. RFC 2215 required conservative treatment: a router sending packets into an IP tunnel had to assume the encapsulated path lacked QoS control unless it or the setup protocol could prove otherwise.

The mechanism contained a structural difficulty. A device that did not understand Integrated Services could not set a flag defined by the specification it did not understand. Detection might therefore belong to an adjacent element, the setup protocol, or manual configuration. The break bit was not a self-authenticating confession from the failing device.

Its consequence was broader than one Boolean. When the global break was set, a receiver was told to treat all other RFC 2215 parameters as possibly inaccurate. A service-specific break similarly weakened the other values for that service. RFC 2210 later described how RSVP carried this state in ADSPEC. Carriage did not narrow the warning: uncertainty applied to the related evidence chain.

The hop count counted only what could count itself

NUMBER_OF_IS_HOPS followed another rule. Each aware element incremented the composed counter by one. The result said how many conforming participants the message had traversed, within the IP hop-count bound.

The count becomes dangerous when read alone. Five aware hops do not prove there were only five physical or logical segments. A non-aware device cannot increment an aware-hop counter. The count and break flag therefore answer different questions: how many known participants contributed, and whether an unsupported gap makes the other claims suspect.

This pairing is an early example of an evidence system refusing to turn absence into zero. “Not counted” and “did not exist” are different states.

Available bandwidth was a minimum of estimates

The bandwidth parameter exposed the hardest temptation. Each element estimated the bandwidth available to packets following the chosen path, considering physical resources as well as administrative and policy controls. The composed value took the minimum.

Mathematically, that found the narrowest advertised availability. Operationally, the inputs were not reservations. RFC 2215 said the value had to be produced before a specific QoS request, when the destination, requested service, or reservation policy might still be unknown. In those circumstances an element could make its best attempt and materially overestimate what would later be available.

A service constrained to only part of the capacity could publish a smaller override. The endpoint then received a path characterization specific to that service without mistaking it for the general forwarding path.

Zero carried no promise at all. It meant the element could not or chose not to estimate bandwidth, and a receiver of composed zero had to treat actual availability as unknown. Because the algebra was minimum, zero survived every later positive contribution. That was not an unfortunate side effect. It prevented downstream precision from laundering an upstream evidentiary gap.

Minimum latency accumulated, then saturated into ignorance

Latency used addition rather than minimum. The local value was the smallest possible delay added by propagation and packet processing. It excluded variable queueing delay. This made it a baseline for services such as the Guaranteed Service in RFC 2212, not an ordinary latency measurement and not the C/R + D bound itself.

The RFC acknowledged that a cloud could have different minimum paths. Ideally it would export a separate value for each next hop. A shared value had to be the smallest possible latency across the cloud, which could understate the actual route. An element could instead report the distinguished indeterminate value.

Composition summed microsecond values but clamped at (2**32)-1. That maximum meant indeterminate latency. It could arise because an element could not predict its contribution or because the numeric range overflowed. Once present, the bounded sum kept it present. The final consumer learned that true latency was unknown, not that the path had exactly the largest representable delay.

Precision requirements mattered because small errors also compose. Millisecond-only estimates were rejected: a positive floor at every hop could manufacture several milliseconds of apparent delay before the path had supplied evidence for it.

Path MTU used minimum, but with a stronger input obligation

Path MTU also took the minimum, yet its contract differed from bandwidth. A local value was the largest IP packet the element could carry without fragmentation, including IP and upper-layer headers but excluding link-layer headers. Every aware element had to provide a correct value.

A service override could lower the global MTU but could not raise it. That asymmetry prevented a service from claiming it could accept a packet larger than the underlying element could carry. The composed result described a ceiling for that route and service branch.

It still was not a delivery receipt. A route could change. A hidden tunnel could escape characterization. A sender could choose another size. A packet could fail for another reason. The minimum answered the precise question encoded by the contributors; it did not inherit authority over later events.

One RFC also carried a thing that did not compose

RFC 2215 included the shared token-bucket TSpec as parameter 127. Its presence is a useful boundary. The structure described expected traffic using rate, bucket depth, peak rate, minimum policed unit and maximum packet size. Intermediate elements did not export local TSpec values for path composition.

An input contract and a path characterization could therefore travel in the same architecture without becoming the same evidence. TSpec described traffic for which service was requested. It did not measure actual conformance, prove admission, or show how packets were treated.

The composition object was an intermediate proof

The Integrated Services architecture in RFC 1633, RSVP in RFC 2205, service semantics in RFC 2211 and RFC 2212, and the specification template in RFC 2216 occupied adjacent layers. A setup protocol could carry characterization. A service could use it to formulate a request. Admission control could accept or reject resources. None of those operations converted the prior path summary into an observed outcome.

Later IEEE 802 mapping work in RFC 2815 kept the distinction visible. MTU and break information had to be accurate, while available bandwidth could remain a loose estimate. Parameters could be calculated, measured or estimated. A common data shape did not give every field the same epistemic quality.

The durable ledger therefore has several rows: parameter and service branch; path direction and epoch; local source and method; prior composed value; composition rule; result and validity state; request; admission; installed behavior; observed traffic; delivery; application result. The temptation to store only the last number is precisely the temptation RFC 2215's algebra resists.

Sources and limits

The primary source is RFC 2215, with status records from the RFC Editor and IETF Datatracker. The adjacent RFCs explain architecture, signaling, services and later link-layer mapping. They establish specification semantics and historical relationships, not current deployment, a named implementation, active reservation, measured performance, incident prevalence or application success.

Heng Lu's essays on running-code primacy, minimum shared rules and local decision, and reality versus symbolic layers supply the editorial lens: a well-formed claim matters, but executable reality requires implementation and observation. They are disclosed framing, not evidence that those later essays caused the 1997 design.