Summary

  • RFC 3181 let a new RSVP flow compare its Preemption Priority with the Defending Priority of reservations already admitted at an overbooked node. Once the new flow entered, its admission value became irrelevant and its own defending value faced later arrivals.
  • Merging multicast reservations created a second decision. The recommended strategy tied priority to the receiver that contributed the highest quality of service; taking the highest priority invited free-riding, while rejecting heterogeneous merges could let one incompatible receiver deny service to the rest.
  • A priority element, policy decision or preemption error did not prove end-to-end reservation, changed traffic-control state, packet treatment or a usable application result. Those claims needed observations from their own surfaces.

Arrival order stopped being the whole rule

RFC 3181 appeared in October 2001 as a Standards Track specification and obsoleted RFC 2751, correcting an RSVP policy-data codepoint assignment. It described the Signaled Preemption Priority Policy Element for admission systems such as RSVP and COPS. The status establishes the document’s standards path. It does not establish that a named router, provider or network deployed it.

The problem began when capacity was insufficient for every request. A capacity-only controller could admit flows until resources ran out, making arrival order decisive. Policy-based admission introduced another criterion: a later request might be ranked as more important than a reservation already present. A supporting node could reject a low-ranked newcomer or preempt an earlier low-ranked flow to make room for a higher-ranked arrival.

That was not a claim that capacity had increased. Preemption changed who held a constrained resource. One flow’s successful admission could be another flow’s displacement. The relevant record therefore needed both sides of the decision: what entered, what lost protection and which capacity state forced the choice.

The policy element was intentionally simple, stateless and light enough for a Local Decision Point inside a node. Stateless meant that the element did not require external history to interpret. It did not mean the operational result had no history. The node still acted within a changing set of reservations, and later observers still needed the sequence of admissions and preemptions to explain service.

One flow carried two clocks of authority

The format contained both Preemption Priority and Defending Priority. Higher numeric values represented higher rank within the applicable policy context. The first value belonged to a flow trying to enter. It was compared with the defending values of previously admitted flows.

After admission, that first value became irrelevant for the flow. Its Defending Priority was then compared with the preemption values of future arrivals. The same reservation therefore had an arrival claim and a survival claim. A dashboard that stored only one “priority” would erase when the value applied and which comparison it authorized.

RFC 3181 required a flow’s preemption priority to be less than or equal to its defending priority. A wide gap could add stability. A moderate admission rank made it difficult for the flow to displace others, while a higher defending rank made it harder to evict once admitted. The arrangement balanced sensitivity to arrival order against repeated churn.

That stability was conditional, not permanent. An even higher future arrival could still prevail. Capacity could change. Policy mappings could differ at another node. The document defined relative rank, not a universal business class that every administrative domain had to interpret identically.

The distinction also exposes a common measurement error. “Admitted at time A” is a historical event. “Still protected at time B” is a current comparison. Replaying the admission receipt cannot answer the later question because the competitors and resource state may have changed.

Policy travelled through several hands

The document described three roles. A Policy Decision Point could reduce relevant policy rules to a priority criterion. A Local Decision Point could interpret, forward or merge the element at a node without a controlling decision point. A Policy Enforcement Point interacted with traffic control and capacity admission to enforce priorities.

Those roles formed a chain of custody rather than one omniscient controller. The decision point supplied a ranking. The local point applied the encoded merge strategy. The enforcement point changed local admission or traffic-control state. RSVP carried policy data along a signalling path. COPS could outsource a decision. None of those actions alone observed how packets later crossed the full path or how an application experienced the result.

RFC 2750 supplied the RSVP policy-control container, while RFCs 2748 and 2749 supplied COPS and its RSVP client context. Their presence clarifies interfaces and ownership. It does not turn a received policy object into proof of authentication at every later boundary, consistent configuration across domains or successful resource installation.

The Security Considerations section relied on the integrity protection of the containing Policy Data object and placed the simple guidance inside a trusted or single zone. That scope is consequential. A protected object can preserve who said which values within its security envelope. It cannot prove that the originating rule was wise, that a local mapping was current or that a downstream enforcement action produced the intended service.

A merged reservation could distort the rank

RSVP reservations could merge. RFC 3181 used a difficult example: one flow requested high quality with low priority, while another requested low quality with high priority. Their merged reservation needed the higher quality, but which priority should it inherit?

If the merged result took the high priority, the high-quality, low-priority participant could receive an expensive free ride. If it took the low priority, the participant that legitimately carried high priority could lose protection. The document described denial of service as the inverse face of free-riding: an undeserved advantage for one flow can deprive another deserving flow.

The first strategy admitted priority elements only from flows that contributed to the merged quality-of-service level, then selected the highest participating priority. It was recommended because the flow dominating the resource requirement also dominated the rank. This did not eliminate all abuse or configuration error; it aligned the two quantities more closely.

The second strategy simply took the highest priority from all participating elements. It was easier to implement but explicitly not recommended because it separated rank from the quality level consuming the resource. A low-quality receiver could lend its high priority to a more expensive merged reservation.

The third strategy forced an error when quality levels were heterogeneous. It was recommended only where homogeneity was coordinated and enforced across the multicast tree. Its apparent strictness carried another risk: one receiver asking for an incompatible quality level could cause denial of service to all other receivers in the merged reservation.

There was no neutral compression that preserved every meaning. RFC 3181 stated that no known algorithm could merge elements using different strategies without losing information that might matter to other nodes. When integrity protected the Policy Data objects, a local point should not modify them because doing so would invalidate the security envelope. The receiver count, strategy and security boundary therefore shaped what could safely be summarized.

The error returned a contest, not an outcome

The element defined PREEMPTION for a previously admitted flow that had been preempted and HETEROGENEOUS for an incompatible merge. In a preemption case, a copy of the winning flow’s policy element travelled back toward the decision point that originated the losing flow’s element. With knowledge of both ranks, that decision point might construct a higher-priority element in an effort to reinstate the displaced flow.

That response made the contest visible. It did not prove the losing application had received or understood notice, stopped transmitting, released every resource or recovered cleanly. Nor did it prove the winning flow’s reservation was installed at every hop. A local admission and an end-to-end reservation are different scopes.

Reinstatement could also produce instability. The RFC warned that preemption priority, a killer reservation and RSVP blockade state could let a reservation be preempted, reinstated and preempted again. Counting each acceptance as an independent success would reward oscillation. A useful record needed residence time, repeated displacement and application-visible interruption.

The heterogeneous error was similarly bounded. It reported a policy merge condition as locally defined for quality levels. It did not prove that no compatible path or alternative reservation existed. A policy error can be accurate about the attempted composition while remaining silent about the application’s next choice.

Registration and later standards did not fill the evidence gap

The memo assigned the standard RSVP policy-element type for preemption priority. The present IANA registry can show that a value is coordinated. A registry entry cannot show that a node recognizes it, a decision point emitted it, traffic control enforced it or users received a better service.

Later RSVP-TE material used related preemption concepts for label-switched tunnels, and RFC 6401 later specified RSVP admission-priority extensions. They help locate RFC 3181 in a longer design history. They must not be projected backward as implementation evidence, nor should their fields or operational practices be described as if they were part of the 2001 element.

The same caution applies to the Standards Track label. It records the standing of the specification, not a census of deployed code. No source in this evidence set identifies a current operator, traffic class, emergency call, measured admission rate or application outcome.

A defensible ledger kept the loser in view

An auditable decision starts with flow identity, requested quality, policy origin, security context and both priorities. It records each node and policy role that interpreted or merged the element, the chosen strategy, the capacity and competing reservations at the decision instant, and the admission or preemption action.

For a merge, the record must retain which receivers contributed to the resulting quality and which priority elements participated. A single merged number is insufficient when later analysis needs to detect a free ride, an incompatible request or information discarded across a protected boundary.

For preemption, the ledger links the winning arrival to the displaced reservation, the error sent back, traffic-control removal and any attempted reinstatement. It keeps repeated episodes rather than overwriting them with the latest state. It then adds path-level reservation confirmation, packet observations and application response as separate evidence.

This sequence prevents rank from masquerading as service. Priority can guide a decision under scarcity. It cannot create capacity, certify consistent enforcement or speak for the application. RFC 3181’s two values made that temporality unusually clear: the authority that opens a door is not necessarily the authority that keeps it open.

Sources and limits

The protocol’s status, two priorities, policy roles, merge strategies, errors, registration and security scope come from the RFC 3181 text, RFC Editor record, HTML edition, IETF history and errata query. Version comparison is bounded by the obsoleted RFC 2751 text and record.

The surrounding interfaces are documented by RSVP, the RSVP policy-control extensions, COPS and COPS usage for RSVP. Later context comes from RSVP-TE, RSVP admission priority and the IANA RSVP parameters registry.

The analytical separation of policy rank, execution and observed outcome is informed by Lu Heng’s essays on running-code primacy, reality layers and minimum initial specification. The seventeen-source set was frozen on 2 October 2026 in Asia/Shanghai.

These records establish specification and context, not deployment or result. They identify no current implementation, vendor, operator, flow, application, incident, attack, capacity saving, packet treatment or service outcome. Priority values are relative within an applicable policy context and are not universal social or business ranks. The evidence-chain interpretation is Sofia Ren’s editorial analysis, not a claim by the RFC author, IETF, IANA or Lu Heng.