COPS usage for RSVP
Extracted elements (25)
Bundling multiple context flags into a single COPS query is restricted to two unambiguous cases (Unicast FF and single-Resv multicast) to significantly optimize protocol operations while guaranteeing no semantic ambiguity. These two cases represent a substantial portion of expected COPS transactions.
PathTear and ResvTear are excluded from policy control based on two assumptions: MD5 authentication verifies the Tear originates from the same node that sent the reservation, and receiving a Tear is functionally equivalent to that node simply withholding refreshes for the reservation.
PEP caching of COPS decisions for RSVP refreshes (rather than re-querying on each refresh) is justified because valid credentials are already established, RSVP refresh periods are relatively long, and PEP-PDP response times are short — the tradeoff between expedient updates and attack prevention leans toward expediency for refreshes of already-admitted flows.
Stateless policy objects are designed to be well understood but not necessarily supported by all PEPs; a PEP that lacks support (e.g., no preemption) may silently ignore them. The PDP must account for this and not rely on universal enforcement of stateless objects.
The Resource-Allocation context is decoupled from any specific RSVP message because in multicast sessions it represents the merge of multiple incoming reservations; therefore its ClientSI carries merged FLOWSPEC and FILTERSPEC rather than copying a single message's objects.
The COPS-RSVP specification requires that the PDP implement the same RSVP functional specification as the PEP, enabling the PDP and PEP to share RSVP state and for the PDP to interpret ClientSI object content and determine associations (including multicast blockade state transitions) from REQ message contents.
After a PDP-approved reservation is successfully installed, the PEP notifies the PDP with a Report message of Commit type, signaling when billing may begin. If admission fails due to lack of resources despite PDP approval, the PEP must issue a no-commit report and revert to the prior state, or issue a DRQ if no prior state existed.
After reconnecting to a new or original PDP that issues an SSQ request, the PEP must reissue requests corresponding to all current RSVP state (as if recently updated) and should include the current cached decision for each state in LPDPDecision.
Before sending a PathErr or ResvErr, the PEP queries the PDP, which returns the constructed ERROR_SPEC content (sub-codes) in the Replacement Data Decision Object for use in the error message.
If the PDP detects the absence of objects required by RSVP, it should return an Error in the Decision message indicating 'Mandatory client-specific info missing'. If optional but policy-needed objects are absent, the PDP should return a negative Decision.
If the PEP-PDP connection is lost, cached RSVP state may be retained for the RSVP timeout period for previously admitted flows only (not for new or updated state). If the PDP cannot be reestablished after the timeout, the PEP is expected to purge all cached decisions and must then reject new flows or resort to the LPDP.
Multiple context flags in a single COPS REQ are allowed only for Unicast FF [Incoming + Allocation + Outgoing] and Multicast with a single Resv on the interface [Incoming + Allocation]. Context events are time-ordered; all ClientSI objects in a multi-flag request are processed according to the latest (most advanced) flag.
Multiple FF flows packed into a single Resv message must be unpacked, with a separate COPS request issued for each packed flow as if it were an individual RSVP message. Each request should include all POLICY_DATA objects from the packed message by default.
Once a COPS decision is cached, the PEP can apply it to RSVP refreshes without re-querying the PDP. When the PEP detects a change in corresponding Resv or Path state, it should update the PDP with a new request; PEPs may continue using cached state until receiving the PDP response.
When a ResvTear or PathTear is received at the PEP, all affected states installed on the PDP should either be deleted or updated by the PEP.
COPS Decision Commands for RSVP are limited to Install (positive: accept/allow/admit an RSVP message or resource allocation) and Remove (negative: deny/reject). The single applicable Decision Flag is Trigger Error, which when set causes RSVP to schedule a PathErr (for Path) or ResvErr (for Resv).
Policy control is performed per RSVP flow, defined as the atomic unit of an RSVP reservation (TC reservation). Under WF reservation style, multiple senders form a single flow; under FF style, each sender is an individual flow.
Replacement Data allows the PDP to replace RSVP objects by C-Num: an object of a given C-Num replaces ALL instances of that C-Num in the RSVP message; an empty replacement (length 4) removes all instances without adding anything. PEPs are required to support replacement of POLICY_DATA, ERROR_SPEC, and FLOWSPEC; replacement of other objects is optional.
RSVP is assigned COPS client-type 1. This value appears in the COPS Common Header to identify the client type for all RSVP policy requests.
Stateless Policy Data carries one or more RSVP policy elements (per RFC 2750) assumed understood by the LPDP. It adds to the PDP decision but cannot override it, and may apply individually to each context flagged in REQ messages with different semantic interpretations per context.
The ClientSI (Signaled ClientSI) object encapsulates all objects received in an RSVP message and is sent from the PEP to the PDP. For the Resource-Allocation context in multicast, it specifically carries SESSION, STYLE, merged FLOWSPEC, FILTERSPEC list, and SCOPE rather than raw message objects.
The COPS Context Object for RSVP defines three R-Type flags: Incoming-Message (PEP received an RSVP message), Resource-Allocation (PEP about to commit local resources, applies to Resv only and represents merged reservations), and Outgoing-Message (PEP about to forward an RSVP message). The M-Type field uses values identical to the 'msg type' field in the RSVP header.
The supported RSVP M-Type values in the Context Object are: Path, Resv, PathErr, and ResvErr. PathTear, ResvTear, and ResvConfirm are explicitly not supported; the set may only be extended in later versions of RSVP or this document.
COPS usage for RSVP relies on the COPS protocol's own security mechanisms for signaling. RSVP message security is provided by inter-router MD5 authentication operating under a chain-of-trust model, with PEPs deployed at network edges and policy-ignorant PIN nodes forming the backbone.
In deployments where PIN nodes populate the network core, MD5 trust between non-neighboring boundary PEPs can be achieved through internal integrity signing of the Policy Data object itself, which PIN nodes pass through unmodified.