Summary

  • RFC 2386 used resource availability and flow requirements to find promising paths, but stated that routing did not reserve the resources it described.
  • Its practical architecture left fast, detailed decisions inside a domain and exchanged only relatively stable information between domains; each node still retained admission authority when a flow was set up.

The route that existed only on paper

Best-effort routing in the late 1990s usually answered a deliberately narrow question: where is the destination, and which available route has the preferred cost? RFC 2386 asked what would happen if a network also tried to route a flow according to a service requirement. The path might need enough residual bandwidth, a tolerable delay, bounded jitter, or some combination of those properties. A shortest path could be unusable while a longer path could accommodate the request.

That change seems to turn routing into a promise. If the router knows where capacity is, why not simply select it? The framework’s answer was more disciplined. QoS-based routing used knowledge of resource availability to determine a path with a good chance of accommodating the requested service. It did not reserve the bandwidth, create queueing resources or force every node to accept the flow. Resource reservation did that different work. RSVP could request resources along a path, but it did not by itself discover the path with adequate resources.

The distinction produced an evidence ladder. A link measured a property. The routing system encoded and advertised it. Other nodes received a view that could already be delayed, quantized or aggregated. A computation nominated a candidate path. During setup, each node performed flow admission control against its actual local resources. Higher-level policy could still reject the request even when every local check said capacity was available. Only after allocation, coherent forwarding and observation could anyone say what service the packets actually received.

The map mattered. It was not a receipt.

Consumable metrics changed the map by being used

Ordinary reachability is relatively durable. Available bandwidth is consumable. Once a path attracts traffic because it appears underused, its advertised condition can cease to be true. If routers immediately chase the newly “better” path, traffic can swing again. RFC 2386 warned that frequent updates and opportunistic switching could cause route oscillation, delay variation and jitter even when the existing route still met the flow’s requirement.

That made freshness a control problem. Send updates rapidly and the network consumes bandwidth and router CPU while reacting to noise. Slow them down and route calculations use stale information. Quantize values coarsely and updates become cheaper, but distinctions that matter to admission disappear. Smooth measurements and short overloads may be hidden; report every movement and the control plane may amplify the movement it is measuring.

The document therefore treated update triggers as part of route stability, not a clerical detail. It also defined route pinning: hold a flow to a path for a period instead of moving it whenever another route looks marginally better. Pinning did not make the path immortal. It separated continuity for an admitted flow from the surrounding map’s constant revision.

Precision had a storage price

The decision could be made per destination, per source-destination pair, or per flow. Each step toward finer granularity improved the chance of matching one request to one path. It also enlarged the routing state.

Destination-only routing sent all sources toward the same destination along the same choice. Source-destination routing could distinguish where traffic came from, but still grouped unlike flows. Per-flow routing offered the finest fit and the greatest state cost. Worse, state loss created a correctness hazard. If one router forgot the flow-specific path and fell back to ordinary destination forwarding while an earlier router still used the special path, the packet could loop between two inconsistent realities.

More state was therefore not simply more knowledge. It was more memory to maintain, more synchronization to lose and more failure modes to diagnose. The operational question was not whether the network could calculate a detailed route, but whether every forwarding decision that depended on the detail would remain coherent for the route’s life.

Aggregation bought scale with uncertainty

Hierarchical aggregation offered the familiar remedy. A domain could summarize many links and internal paths as a smaller representation. That made a large network calculable and allowed operators to conceal internal topology. It also erased information.

RFC 2386 described the consequence plainly: a computation could accept a flow from aggregated state, then discover that no actual underlying path supported the requested service. The summary was not fraudulent. It was a lossy projection being asked to support a more precise decision than it could reliably answer.

Crankback was one response. When setup failed at a node, the partial setup could retreat to an earlier point capable of choosing another path. This turned a mistaken prediction into a bounded search. Yet crankback consumed setup time and, under some traffic conditions, could worsen performance. It belonged beside admission control, not in place of it.

The sequence matters. Aggregate state narrows the search. A candidate route starts setup. Local nodes confront present resources. Failure produces refusal or a controlled attempt at an alternative. Calling the first step “assurance” would remove the very recovery path the architecture needed.

A minimum common layer between autonomous systems

The RFC’s most consequential choice concerned administrative boundaries. Inside an autonomous system, it encouraged experimentation: link-state schemes, probes, static provisioning, on-demand computation and other designs could compete. Between systems, it wanted interaction to be simple, consistent and stable.

That was not merely a compromise made before a perfect protocol arrived. Highly dynamic interdomain state would scale poorly, expose information operators might not wish to reveal and offer distant routers a lossy view of conditions they could not verify. The framework instead favored relatively sparse information based on engineered topology and capacity. An interdomain metric should change for exceptional conditions such as failure or focused overload, not for every flow arriving within the engineered limit.

This created two different clocks. A domain could react to detailed local conditions on a short clock. Its neighbors received a slower statement of engineered capability, reachability and policy. The common layer coordinated expectations without attempting to reproduce every internal fact.

The division also preserved decision rights. A remote advertisement could say what a domain was prepared to support under stated assumptions. The entry border still tracked aggregate demand and applied admission control. A domain could refuse excess traffic, treat it as best effort or invoke another policy. The advertisement did not transfer ownership of local resources to the route calculator outside the domain.

Cost exposed the missing receipt

RFC 2386 considered monetary cost as one possible routing policy. Providers might publish the expected cost of carrying flows with different requirements, and a path could combine costs across domains. That raised an uncomfortable question: what should be charged when the promised QoS was not actually delivered?

The question is important because it reveals what the control plane could not prove. A route advertisement reported capability. A reservation reported allocation. Neither necessarily measured end-to-end delivery across every domain. Delay, jitter, loss and throughput still needed observation. Without that receipt, a price attached to a promise could travel farther than evidence of performance.

The security section made a related point from the opposite direction. QoS requests had to be validated, and arbitrary requests could become resource-depletion attacks. A requester’s declared need was not self-authorizing. Policy, policing and charging could constrain it, but the document acknowledged that formal protection still required work.

What later mechanisms clarified

The framework stood among a family of documents. RFC 2205 defined RSVP’s receiver-initiated reservation setup. RFCs 2210, 2211 and 2212 described how Integrated Services and controlled-load or guaranteed service related to that signaling. In 1999, RFC 2676 documented QoS routing mechanisms and OSPF extensions. RFC 3272 later placed routing inside a wider traffic-engineering cycle of measurement, modeling, control and evaluation. RFC 3630 defined OSPF extensions for distributing traffic-engineering link attributes.

Those later documents should not be read backward as proof that RFC 2386’s framework was universally deployed. They show the persistence of its separation. Attributes can be advertised and consumed by a path computation. A signaling protocol can request resources. An operator can engineer capacity. Measurement can test the outcome. Combining these functions is useful precisely because none is an honest substitute for the others.

RFC 2386 described adaptive routing as two fundamental acts: gather state and compute routes from it. Its lasting lesson is the set of boundaries around those acts. State is observed under a clock. Advertisements are transformed by scope and policy. Computation produces a candidate. Admission consults local reality. Reservation changes resource state. Forwarding and measurement reveal the outcome.

The path still needed permission at every layer where the map had no authority.

Sources