Signaled Preemption Priority Policy Element
obsoletes
- rfc-2751 — Signaled Preemption Priority Policy Element
Extracted elements (25)
A wide gap between preemption priority and defending priority provides stability: moderate preemption priority makes it harder for a flow to preempt others, while a higher defending priority makes it easier to resist future preemption, balancing order-dependency against priority.
Compression of forwarded PREEMPTION_PRI elements is permitted: per merging strategy, only the element with the highest QoS among participants is forwarded, reducing the number of elements to at most the number of distinct merging strategies regardless of receiver count.
Priority merging with heterogeneous QoS flows creates the 'free-rider' problem (a low-QoS flow acquires high priority undeservedly) and 'denial of service' (a high-priority flow is rejected after merging with a lower-priority one), motivating the three distinct merge strategies.
The 'Force error on heterogeneous merge' strategy (merge strategy 3) is recommended only when reservation homogeneity is coordinated for the entire multicast tree; it is easier to implement than strategy 1 but vulnerable to denial of service from a single receiver specifying an incompatible QoS.
The PREEMPTION_PRI element is designed to be stateless, simple, and lightweight so it can be implemented internally within a node's Local Decision Point (LDP) without requiring a controlling PDP.
The 'Take highest priority' strategy (merge strategy 2) is not recommended because it disassociates priority from QoS level, making it highly susceptible to free-riders and denial of service, though it is simpler to implement.
The 'Take priority of highest QoS' strategy (merge strategy 1) is recommended because the highest-QoS flow dominates the merged reservation and its priority should dominate as well, preventing free-rider and denial-of-service priority distortions.
PREEMPTION_PRI elements are created by PDPs, can be processed (interpreted, forwarded, or merged) by LDPs, and are enforced by PEPs interacting with the node's traffic control and capacity admission control modules.
RFC 3181 obsoletes RFC 2751 and corrects an RSVP POLICY_DATA P-Type codepoint assignment error present in that earlier document.
For any specific flow, its preemption priority MUST always be less than or equal to its defending priority.
In merging, preemption priority and defending priority are merged and computed separately, irrespective of each other; the highest priority among participating elements is then selected.
LDPs must follow the merging strategy that was encoded by PDPs in the PREEMPTION_PRI objects when processing or forwarding these elements.
Merging of PREEMPTION_PRI elements must be performed per merging strategy separately; there is no algorithm to merge elements of different strategies without losing information affecting other nodes.
When carried in COPS messages for outsourced policy decisions, PREEMPTION_PRI objects MUST be included as COPS Stateless Policy Data Decision objects.
When POLICY_DATA objects are protected by integrity, LDPs should not attempt to modify them and must forward them as-is; modification would invalidate the security envelope.
On preemption, a copy of the preempting flow's PREEMPTION_PRI element is sent back toward the PDP that originated the preempted element, allowing the PDP to construct a higher-priority element to reinstate the flow.
The Defending Priority field (16-bit unsigned) is used once a flow is admitted; it is compared against the preemption priority of new flows seeking to displace the admitted flow.
The Error Code field (8 bits) encodes: 0 (NO_ERROR), 1 (PREEMPTION — flow was preempted), or 2 (HETEROGENEOUS — element encountered a heterogeneous merge).
The Merge Strategy field (8 bits) encodes one of three strategies: 1 (Take priority of highest QoS, recommended), 2 (Take highest priority, aggressive), or 3 (Force error on heterogeneous merge).
The Preemption Priority field (16-bit unsigned) expresses the priority of a new flow relative to the defending priorities of previously admitted flows; higher values indicate higher priority.
When a flow using the heterogeneous-error merge strategy encounters heterogeneity, its PREEMPTION_PRI element is returned toward receivers with the HETEROGENEOUS error code set.
IANA assigns Standard RSVP Policy Element P-Type values by IETF Consensus as described in RFC 2750; P-Type PREEMPTION_PRI is assigned the value 1.
Preemption priority is intended to provide simple, quick guidance to routers operating within a trusted zone or a single policy domain; it is not designed to cross zone boundaries and additional security mechanisms are not warranted in that context.
The integrity of PREEMPTION_PRI elements is guaranteed by encapsulation within a Policy Data object as defined in RFC 2750 (RSVP Extensions for Policy Control); no additional security mechanisms are defined.
The PREEMPTION_PRI policy element is 12 bytes total, with fields: Length (16 bits, always 12), P-Type (16 bits, value 1), Flags (8 bits, reserved), Merge Strategy (8 bits), Error Code (8 bits), Reserved (8 bits), Preemption Priority (16 bits unsigned), and Defending Priority (16 bits unsigned).