Summary

  • RFC 3317 made a DiffServ device report the kinds, depth and legal connections of packet-processing elements it generally supported before a policy server constructed the installed data path.
  • The report was guidance, not a promise: if the complete graph still could not be implemented, the device had to return a failure report, and neither acceptance nor installation proved the resulting service.

The attractive fiction of centralized policy is that intent travels intact. An operator says which traffic deserves which treatment; a controller converts that desire into rules; the router obeys. RFC 3317 documented the harder middle. A service promise had to be decomposed into a graph that one particular class of device could realize, and the device had to describe its constraints before the controller began.

The document's subject was Differentiated Services. In the DiffServ model, packets may be classified, measured, marked or otherwise acted upon, exposed to a dropping algorithm, queued, and scheduled. RFC 3317 encoded those functions as provisioning classes in a Policy Information Base, or PIB. A Policy Decision Point could use COPS-PR to send instances of those classes to a Policy Enforcement Point. The vocabulary sounds like a database, but its operational object was a packet path.

That path had an order. A Traffic Conditioning Block placed classifier, meter, action, algorithmic dropper, queue and scheduler in sequence. If a treatment needed to repeat an earlier kind of element, the model represented another block. Each element carried a Next reference, so policy became a directed graph: a classifier could branch to different meters; meter outcomes could point to actions or droppers; queues could feed schedulers; a final zero value could end the chain and return to ordinary forwarding.

RFC 3317 separated this wiring from the numbers attached to it. A meter row could point to a reusable token-bucket parameter row. A scheduler could refer to minimum- and maximum-rate parameters. That indirection allowed more than one policy element to share a parameter object and allowed later PIBs to define additional kinds. It also made a distinction that mattered for accountability: knowing a rate or burst size did not reveal where that parameter sat in the packet path, while knowing the graph did not prove that the chosen numbers fitted the hardware.

The device therefore spoke first. After communication was established, the PEP reported the provisioning classes it understood, the interface types and role combinations it supported, and capability sets for ingress or egress. Those sets could say which packet fields were available for classification, how out-of-profile traffic could be handled, which dropping methods existed, how many queues or scheduler inputs were supported, how much buffer was available, and how many maximum-rate levels could be expressed.

Two less obvious capabilities turned this inventory into a graph boundary. One limited the maximum number of functional elements that could be linked consecutively. Another said which type of element was allowed to follow another. A device might understand classifiers, meters and queues in isolation yet still be unable to realize the controller's proposed chain. Capability was not merely a list of nouns; it constrained the edges and depth of the policy graph.

With that report, the PDP could send policy for an administrative domain, interface type, role combination and direction. A data-path entry selected the first element. An absent entry or an explicit zeroDotZero meant normal device processing rather than a DiffServ treatment. The scheme described interface types, not every physical interface individually, so it traded per-port detail for a reusable capability class.

The authors did not pretend this language could enumerate every realizable configuration. They called the capability classes general guidelines. Combinations among buffers, queue counts, scheduler methods, internal processors and linkages could still defeat a graph that looked valid when its parts were checked separately. In that case the PEP had to tell the PDP that installation failed. The failure report was not an embarrassment outside the model; it was the last boundary of the model.

Several receipts must therefore remain separate. A capability row records what a device says it generally supports. A policy graph records what the controller intends to install. A COPS-PR response records the result of a provisioning transaction. Device state may show that rows were stored. None of those, without packet observation, proves that traffic received the promised differentiated service. A customer outcome is another question again.

The security section showed why both directions mattered. Installable policy rows could expose service contracts or traffic filters and could change DiffServ behavior if altered. Capability rows could reveal device characteristics. RFC 3317 referred to IPsec protection between PDP and PEP, because a forged capability report could mislead construction while a forged policy could change resource allocation.

The architecture did not become the lasting management foundation its designers sought. In 2016, the IESG moved RFC 3317, the Framework PIB, COPS-PR and SPPI to Historic. The rationale said the technology had seen limited deployment and that network-configuration work had centered on NETCONF and YANG. That later status is evidence about the path of the standards family, not evidence that capability-aware planning became unnecessary.

Its durable lesson is narrower. A controller cannot manufacture realizability from intent. The system being controlled must expose enough about its limits to bound the plan, and the planner must still accept a definitive failure when an approximate capability model meets a full configuration. If those two receipts are collapsed, a policy system will eventually mistake a plausible graph for an executable one.

Sources: RFC 3317, RFC 3318, RFC 3290, RFC 3084, RFC 3159, RFC 2475, and the 2016 IESG status change.