Signaled Preemption Priority Policy Element
obsoleted by
- rfc-3181 — Signaled Preemption Priority Policy Element
Extracted elements (20)
A wide gap between preemption and defending priority provides added stability: moderate preemption priority makes it harder for a flow to preempt others, but once admitted the higher defending priority makes it easier to avoid preemption itself, balancing order dependency against priority.
PREEMPTION_PRI elements are created by PDPs at the periphery of a policy domain and can be processed by LDPs at downstream nodes that lack a controlling PDP, enabling distributed policy enforcement without requiring a PDP at every node.
PREEMPTION_PRI elements are designed to be simple, stateless, and lightweight so they can be implemented internally within a node's LDP (Local Decision Point), avoiding the need for a controlling PDP at every node.
The 'Force error on heterogeneous merge' strategy assumes heterogeneous merges are rare and too complicated to handle, so they are prohibited. However, it is susceptible to denial of service when a single receiver with incompatible QoS can block all others.
The 'Take highest priority' strategy is not recommended because it disassociates priority from QoS level and is highly subject to free-rider problems (a low-QoS flow gaining undeserved high priority) and denial of service.
The 'Take priority of highest QoS' merging strategy is recommended because the highest QoS flow dominates the merged reservation and its priority should dominate as well, making it most resistant to priority distortions such as free-riders and denial of service.
PREEMPTION_PRI elements are stateless and when carried in COPS messages for outsourcing policy decisions, they are included as COPS Stateless Policy Data Decision objects per [COPS] and [COPS-RSVP].
There is no known algorithm to merge PREEMPTION_PRI elements of different merging strategies without losing information that may affect other nodes; therefore merging must be performed separately for each merging strategy.
For any specific flow, its preemption priority MUST always be less than or equal to its defending priority.
LDPs must follow the merging strategy that was encoded by PDPs in the PREEMPTION_PRI objects when computing merged priority.
When POLICY_DATA objects are protected by integrity, LDPs SHOULD NOT attempt to modify them and must forward them as-is or else their security envelope would be invalidated.
Error processing: when a flow is preempted, a copy of the preempting flow's PREEMPTION_PRI element (with PREEMPTION error code) is sent back toward the PDP that originated the preempted element, allowing the PDP to construct a higher-priority element to reinstate the flow.
Heterogeneity error: when a flow with the Force Error merge strategy encounters heterogeneity, its PREEMPTION_PRI element is sent back toward receivers with the HETEROGENEOUS error code (value 2) set.
LDPs may compress multiple PREEMPTION_PRI elements by merging per strategy: for each strategy, the highest priority of all participating elements is placed in a single outgoing element, reducing forwarded elements to at most the number of different merging strategies.
Merge Strategy field encodes one of three strategies: (1) Take priority of highest QoS (recommended), (2) Take highest priority (aggressive, not recommended), (3) Force error on heterogeneous merge (recommended when reservation homogeneity is enforced).
Merging algorithm: (a) preemption priority and defending priority are merged separately; (b) participating elements are selected per their merging strategy; (c) the highest priority among participating elements is taken as the merged result.
The PREEMPTION_PRI policy element is a 12-byte structure containing Flags (8 bits), Merge Strategy (8 bits), Error Code (8 bits), Reserved (8 bits), Preemption Priority (16 bits unsigned), and Defending Priority (16 bits unsigned). P-Type is assigned value 3.
P-Type PREEMPTION_PRI is assigned value 3 in the RSVP Standard Policy Elements registry. Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action as described in [RSVP-EXT].
The integrity of PREEMPTION_PRI elements is guaranteed by encapsulation into a Policy Data object [RSVP-EXT]. Further security mechanisms are not warranted given that preemption priority is intended for use within a trusted zone or single zone without crossing zone boundaries.
Length field is 16 bits, always 12 (bytes). P-Type field is 16 bits with value PREEMPTION_PRI=3. Preemption Priority and Defending Priority are each 16-bit unsigned integers. Merge Strategy is 8 bits encoding one of three strategies (1=Highest QoS, 2=Highest Priority, 3=Force Error). Error Code is 8 bits (0=NO_ERROR, 1=PREEMPTION, 2=HETEROGENEOUS).