RSVP Extensions for Admission Priority
Extracted elements (25)
The Priority Bypass Model (PrBM) admits priority sessions unconditionally regardless of current load, on the rationale that in practice priority traffic volume is very low most of the time and even during congestion remains a small enough fraction to be absorbed within the engineered capacity safety margin without noticeable QoS degradation.
These extensions are intentionally scoped to a single administrative domain because a subset of RSVP messages use the IP Router Alert Option (RAO), whose security aspects and risks for cross-domain leakage are discussed in RFC 6398. End-to-end Internet use is explicitly out of scope.
This document deliberately does not recommend any particular merge strategy for Admission Priority (unlike RFC 3181, which recommends a specific strategy for Preemption Priority), because no single strategy is universally appropriate for admission control across multicast merges.
Two separate policy elements are defined rather than one: APP_RESOURCE_PRI carries application-level semantics for PDPs at policy boundaries, while ADMISSION_PRI is deliberately simple, stateless, and lightweight so it can be processed by LPDPs and enforced at every RSVP hop, including hops with no understanding of application-level resource priority.
Policy Ignorant Nodes (PINs) and policy-capable nodes that do not recognize the ADMISSION_PRI or APP_RESOURCE_PRI policy elements apply the default POLICY_DATA handling defined in RFC 2750 Section 4.2, allowing these elements to transit such nodes transparently.
The Admission Priority Policy Element does NOT indicate preemption of existing RSVP reservations. If a priority session requires both admission priority and preemption priority, it MUST carry both an Admission Priority Policy Element (this document) and a Preemption Priority Policy Element (RFC 3181) as separate, independent mechanisms.
The APP_RESOURCE_PRI element can also be used at boundaries with non-RSVP QoS signaling protocols such as the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling (RFC 5974) to remap application-level resource priority into RSVP admission or preemption priority.
Flags in the Admission Priority Policy Element SHALL be set to zero on transmit and SHALL be ignored on reception; likewise the Reserved fields.
Multiple models of bandwidth allocation MAY be used with the RSVP Admission Priority Policy Element to allocate bandwidth preferentially to prioritized sessions (e.g., MAM, RDM, MAR, or Priority Bypass Model).
RSVP authentication as specified in RFC 2747 and RFC 3097 SHOULD be supported by an implementation of this document to protect integrity of ADMISSION_PRI and APP_RESOURCE_PRI policy elements between RSVP neighbors.
The INTEGRITY object within the POLICY_DATA object MAY be supported by an implementation to guarantee integrity between non-neighboring RSVP PEPs, which is useful when some RSVP nodes are Policy Ignorant Nodes (PINs).
The Length field of the Application-Level Resource Priority Policy Element MUST be a multiple of 4 octets and indicates the end of the ALRP list.
When merging Application-Level Resource Priority Elements in the multicast case (where POLICY_DATA is not integrity-protected), the outgoing ALRP List MUST be the union of all incoming ALRP Lists, and a given ALRP MUST NOT appear more than once.
When POLICY_DATA objects are protected by integrity, LPDPs MUST forward them without modification to ensure the security envelope is not invalidated; they should not attempt to modify such objects.
The Admission Priority Policy Element (P-Type=0x05) is a 12-byte policy element carried inside RSVP POLICY_DATA objects. It contains a Merge Strategy field (8 bits), an Error Code field (8 bits), and an Admission Priority field (8 bits, unsigned) indicating access priority to network bandwidth for session establishment.
The Application-Level Resource Priority Policy Element (P-Type=0x06) carries a variable-length list of ALRPs (Application-Level Resource Priority entries) inside RSVP POLICY_DATA objects. It is intended to be processed by Policy Decision Points (PDPs) at policy area boundaries, not by LPDPs inside the domain.
IANA allocated two new P-Type values from the standard RSVP policy element range: 0x05 (ADMISSION_PRI) for the Admission Priority Policy Element and 0x06 (APP_RESOURCE_PRI) for the Application-Level Resource Priority Policy Element.
IANA created an Error Code registry for the Error Code field of the Admission Priority Policy Element: 0=NO_ERROR (regular ADMISSION_PRI elements), 1=Reserved, 2=HETEROGENEOUS (element encountered heterogeneous merge). Range 0–127 IETF Review, 128–240 First Come First Served, 241–255 Private Use.
IANA created (or extended, shared with RFC 3181) a Merge Strategy registry for the Merge Strategy field in Admission Priority and Preemption Priority Policy Elements. Values: 0=Reserved, 1=Take priority of highest QoS, 2=Take highest priority, 3=Force Error on heterogeneous merge. Range 0–127 is IETF Review, 128–240 First Come First Served, 241–255 Private Use.
IANA extended the existing Resource-Priority Namespaces registry (under SIP Parameters) by adding a 'Namespace Numerical Value' column assigning a unique numerical value to each namespace, enabling those values to be carried in the ALRP Namespace field of APP_RESOURCE_PRI elements.
IANA extended the Resource-Priority Priority-Values registry (under SIP Parameters) by adding a 'Priority Numerical Value' column for each namespace. Within each namespace, values are allocated in decreasing order ending at 0 (greatest priority = 0), and values must be unique within a namespace.
The extensions are intended for use within a single administrative domain. Network operators SHOULD use router alert protection (per RFC 6398) or tunnel/drop incoming RSVP messages at domain edges to prevent RSVP signaling carrying these policy elements from leaking across domain boundaries.
The integrity of ADMISSION_PRI and APP_RESOURCE_PRI policy elements can be protected by two mechanisms: (1) RSVP authentication (RFC 2747/RFC 3097) using the INTEGRITY object in RSVP messages for a chain of trust among policy-capable neighbors, or (2) the INTEGRITY object within the POLICY_DATA object for end-to-end integrity between non-neighboring RSVP PEPs across PINs.
Each ALRP entry within the APP_RESOURCE_PRI element is 4 bytes: ALRP Namespace (16 bits, unsigned, referencing the Resource Priority Namespaces IANA registry), Reserved (8 bits, set to zero), and ALRP Value (8 bits, unsigned, referencing the Resource-Priority Priority-Value IANA registry).
The Admission Priority Policy Element is exactly 12 bytes: Length (16 bits, always 12), P-Type (16 bits, 0x05), Flags (8 bits, reserved), Merge Strategy (8 bits), Error Code (8 bits), Reserved (8 bits), Reserved (24 bits), and Adm. Priority (8 bits, unsigned). Higher priority values represent higher priority.