RSVP Extensions for Policy Control
updates
- rfc-2205 — Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
Extracted elements (25)
A separate policy SCOPE object is required within POLICY_DATA to prevent policy loops in WF reservations, because the RSVP SCOPE object is ineffective when PIN nodes are present—PIN nodes may alter the set of reserved flows on a per-hop basis, breaking Edge-to-Edge PDP assumptions.
PathTear and ResvTear are excluded from policy control because RSVP integrity verification already guarantees the Tear originates from the node that installed the reservation, making it functionally equivalent to that node withholding refreshes—no independent policy decision is required.
Policy enforcement is expected initially to concentrate on border nodes between autonomous systems, with core nodes operating as policy-ignorant PIN nodes. This allows incremental deployment without requiring every RSVP node to be policy-capable.
The INTEGRITY option is embedded inside POLICY_DATA (rather than relying solely on RSVP-level integrity) because boundary PEPs separated by untrusted PIN nodes need a security channel that bypasses intermediate nodes that are RSVP-trusted but not policy-trusted.
The PRT option is designed to support mixing strong (high-overhead) and weak (low-overhead) authentication certificates: weak certificates are included in every refresh while strong certificates are sent infrequently, reducing per-refresh POLICY_DATA processing overhead.
This document updates RFC 2205 Section A.13 by defining the POLICY_DATA object (Class=14, C-Type=1), which was only a placeholder in the original RSVP functional specification. Existing RFC 2205 nodes that do not process policy information are treated as PIN nodes and must forward POLICY_DATA objects unmodified.
A PIN node is required at a minimum to forward received POLICY_DATA objects unchanged (without any modification) in the appropriate outgoing RSVP messages.
A receiving policy node should ignore any POLICY_DATA object that carries a destination RSVP_HOP whose IP address does not match the node's own IP address.
At multicast merging nodes (upstream direction), PIN nodes must concatenate all POLICY_DATA objects arriving from downstream and forward the combined list upstream. In the downstream direction, a single upstream POLICY_DATA object must be copied to all downstream multicast branches.
Only one policy element of a given P-Type may be active at any time. A new element of the same P-Type from the same PDP instantaneously replaces the previous one; an empty element of a P-Type deletes all policy state of that type.
Policy elements expire in the exact same manner and timeframe as the RSVP state received in the same message (per RFC 2205 Section 3.7), except PRT-controlled elements which expire N times slower.
Policy errors must be reported using ResvErr or PathErr with a policy failure error code in ERROR_SPEC. The error message must include a POLICY_DATA object whose policy element carries P-Type-specific error details.
This memo mandates enforcing policy control for Path, Resv, PathErr, and ResvErr messages. PathTear and ResvTear are explicitly excluded from policy control requirements.
When a multicast reservation fails for policy reasons, RSVP should deliver the policy ResvErr to ALL downstream hops rather than attempting to identify the culprit reservation (as Blockade State would). The PDP then decides which next-hops to inform and may suppress further propagation via local repair.
An optional Destination RSVP_HOP (second RSVP_HOP object in the option list) targets POLICY_DATA at a specific policy node. It can emulate unicast delivery in multicast Path messages and guards against replay by scoping the object to the intended recipient.
POLICY_DATA objects are carried by RSVP messages and contain policy information. Any policy-capable node along the data path can generate, modify, or remove them, independent of whether senders or receivers are policy-aware.
Policy errors are signaled via Error Code 02 (Policy Control failure) in the ERROR_SPEC object. Defined error values range from ERR_INFO (0) through ERR_FL_SPEC (19), covering rejection, quota violation, preemption, PDP unavailability, integrity failure, and syntax errors; values 32768–65535 are site/vendor-specific.
The FILTER_SPEC (list) or SCOPE option within POLICY_DATA associates the object with specific flows; the two types are mutually exclusive. In WF/SE styles the FILTER_SPEC option preserves the original flow/POLICY_DATA association across PIN nodes that may independently alter flow lists.
The INTEGRITY object option within POLICY_DATA establishes direct secure communications between non-neighboring PEPs without involving untrusted PIN nodes. The digest is computed over the POLICY_DATA object with a temporarily appended SESSION object, per the algorithm in Appendix B.
The Originating RSVP_HOP option inside POLICY_DATA identifies the neighbor policy-capable node that constructed the object. If absent, the data is implicitly attributed to the RSVP_HOP indicated in the enclosing RSVP message.
The Policy Refresh TIME_VALUES (PRT) option slows policy refresh frequency by computing a multiplier N = Floor(PRT/R) and stretching the effective refresh period to R' = N*R. PRT-controlled policy state expires N times slower than normal RSVP state; the multiplier applies only to no-change periodic refreshes.
RSVP Policy Element P-Type registry: values 0–49151 are standard policy elements allocated by IETF Consensus; 49152–53247 are vendor-specific (one per vendor) allocated First Come First Serve; 53248–65535 are reserved for private use and not assigned by IANA.
Two optional integrity mechanisms protect POLICY_DATA: RSVP-level integrity (RFC 2747/MD5) provides a chain of trust when all nodes are policy-capable; the INTEGRITY object within POLICY_DATA provides end-to-end integrity between non-neighboring PEPs traversing untrusted PIN nodes.
POLICY_DATA object (Class=14, C-Type=1) begins with a 16-bit Data Offset indicating the byte offset of the policy element list from the object header, followed by a 16-bit reserved field (always 0), a variable-length Option List, and a variable-length Policy Element List.
Policy Elements have a 16-bit Length field and a 16-bit P-Type codepoint, followed by opaque policy information of variable length. The content is opaque to RSVP and interpreted only by policy peers (LDP or PDP).