Network Working Group S. Herzog, Ed. Request for Comments: 2749 IPHighway Category: Standards Track J. Boyle Level3 R. Cohen Cisco D. Durham Intel R. Rajan AT&T A. Sastry Cisco January 2000 COPS usage for RSVP Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis document describes usage directives for supporting COPS policy services in RSVP environments. 1 Introduction....................................................2 2 RSVP values for COPS objects....................................2 2.1 Common Header, client-type...................................2 2.2 Context Object (Context).....................................3 2.3 Client Specific Information (ClientSI).......................4 2.4 Decision Object (Decision)...................................4 3 Operation of COPS for RSVP PEPs.................................6 3.1 RSVP flows...................................................6 3.2 Expected Associations for RSVP Requests......................6 3.3 RSVP's Capacity Admission Control: Commit and Delete.........7 3.4 Policy Control Over PathTear and ResvTear....................7
3.5 PEP Caching COPS Decisions...................................7 3.6 Using Multiple Context Flags in a single query...............8 3.7 RSVP Error Reporting.........................................9 4 Security Considerations.........................................9 5 Illustrative Examples, Using COPS for RSVP......................9 5.1 Unicast Flow Example.........................................9 5.2 Shared Multicast Flows......................................11 6 References.....................................................14 7 Author Information and Acknowledgments.........................15 8 Full Copyright Statement.......................................17 COPS]. COPS is being developed within the RSVP Admission Policy Working Group (RAP WG) of the IETF, primarily for use as a mechanism for providing policy-based admission control over requests for network resources [RAP]. This document is based on and assumes prior knowledge of the RAP framework [RAP] and the basic COPS [COPS] protocol. It provides specific usage directives for using COPS in outsourcing policy control decisions by RSVP clients (PEPs) to policy servers (PDPs). Given the COPS protocol design, RSVP directives are mainly limited to RSVP applicability, interoperability and usage guidelines, as well as client specific examples.
RSVP]. The following RSVP message types are supported in COPS: Path Resv PathErr ResvErr Other message types such as PathTear, ResvTear, and Resv Confirm are not supported. The list of supported message types can only be extended in later versions of RSVP and/or later version of this document.
Section 3.1. on multiple flows packed in a single RSVP message). The PEP and PDP share RSVP state, and the PDP is assumed to implement the same RSVP functional specification as the PEP. In the case where a 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, on the other hand, the PDP detects the absence of optional RSVP objects that are needed to approve the Request against current policies, the PDP should return a negative <Decision>. Unlike the Incoming and Outgoing contexts, "Resource Allocation" is not always directly associated with a specific RSVP message. In a multicast session, it may represent the merging of multiple incoming reservations. Therefore, the ClientSI object should specifically contain the SESSION and STYLE objects along with the merged FLOWSPEC, FILTERSPEC list, and SCOPE object (whenever relevant).
DECISION FLAGS The only decision flag that applies to RSVP: Trigger Error If this flag is set, RSVP should schedule a PathErr, in response to a Path message, or a ResvErr (in response of a Resv message). STATELESS POLICY DATA This object may include one or more policy elements (as specified for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be well understood by the client's LPDP. The PEP should consider these as an addition to the decision already received from the PDP (it can only add, but cannot override it). For example, given Policy Elements that specify a flow's preemption priority, these elements may be included in an incoming Resv message or may be provided by the PDP responding to a query. Stateless objects must be well understood, but not necessarily supported by all PEPs. For example, assuming a standard policy element for preemption priority, it is perfectly legitimate for some PEPs not to support such preemption and to ignore it. The PDP must be careful when using such objects. In particular, it must be prepared for these objects to be ignored by PEPs. Stateless Policy Data may be returned in decisions and apply individually to each of the contexts flagged in REQ messages. When applied to Incoming, it is assumed to have been received as a POLICY_DATA object in the incoming message. When applied to Resource Allocation it is assumed to have been received on all merged incoming messages. Last, when applied to outgoing messages it is assumed to have been received in all messages contributing to the outgoing message. REPLACEMENT DATA The Replacement object may contain multiple RSVP objects to be replaced (from the original RSVP request). Typical replacement is performed on the "Forward Outgoing" request (for instance, replacing outgoing Policy Data), but is not limited, and can also be performed on other contexts (such as "Resources-Allocation Request"). In other cases, replacement of the RSVP FlowSpec object may be useful for controlling resources across a trusted zone (with policy ignorant
nodes (PINs). Currently, RSVP clients are only required to allow replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, but could optionally support replacement of other objects. RSVP object replacement is performed in the following manner: If no Replacement Data decision appears in a decision message, all signaled objects are processed as if the PDP was not there. When an object of a certain C-Num appears, it replaces ALL the instances of C-Num objects in the RSVP message. If it appears empty (with a length of 4) it simply removes all instances of C-Num objects without adding anything.
For example, the PDP should be able to recognize activation and deactivation of RSVP blockade state following discrete events like the arrival of a ResvErr message (activate the blockade state) as well as the change in the outgoing Resv message.
If the connection is lost between the PEP and the PDP, the cached RSVP state may be retained for the RSVP timeout period to be used for previously admitted flows (but cannot be applied to new or updated state). If the connection can not be reestablished with the PDP or a backup PDP after the timeout period, the PEP is expected to purge all its cached decisions. Without applicable cached decision, the PEP must either reject the flow or resort to its LPDP (if available) for decisions. Once a connection is reestablished to a new (or the original) PDP the PDP may issue a SSQ request. In this case, the PEP must reissue requests that correspond to the current RSVP state (as if all the state has been updated recently). It should also include in its LPDPDecision the current (cached) decision regarding each such state. Section 2.2). In many cases, setting multiple context flags for bundling two or three operations together in one request may significantly optimize protocol operations. The following rules apply for setting multiple Context flags: a. Multiple context flags can be set only in two generic cases, which represent a substantial portion of expected COPS transactions, and can be guaranteed not to cause ambiguity. Unicast FF: [Incoming + Allocation + Outgoing] Multicast with only one Resv message received on the interface [Incoming + Allocation] b. Context events are ordered by time since every message must first be processed as Incoming, then as Resource allocation and only then as Outgoing. When multiple context flags are set, all ClientSI objects included in the request are assumed to be processed according to the latest flag. This rule applies both to the request (REQ) context as well as to the decision (DEC) context.
For example, when combining Incoming + Allocation for an incoming Resv message, the flowspec included in the ClientSI would be the one corresponding to the Resource-Allocation context (TC). c. Each decision is bound to a context object, which determines which portion of the request context it applies to. When individual decisions apply to different sub-groups of the context, the PDP should send each group of decision objects encapsulated by the context flags object with the context flags applicable to these objects set (see the examples in Section 5). RSVP,RSVP-EXT], the PDP is in the best position to provide its contents (sub-codes). This is performed in the following manner: First, the PEP (RSVP) queries the PDP before sending a PathErr or ResvErr, and then the PDP returns the constructed ERROR_SPEC in the Replacement Data Decision Object. section "Security Considerations" in [COPS]. Security for RSVP messages is provided by inter-router MD5 authentication [MD5], assuming a chain-of-trust model. A likely deployment scenario calls for PEPs to be deployed only at the network edge (boundary nodes) while the core of the network (backbone) consists of PIN nodes. In this scenario MD5 trust (authentication) is established between boundary (non-neighboring) PEPs. Such trust can be achieved through internal signing (integrity) of the Policy Data object itself, which is left unmodified as it passes through PIN nodes (see [RSVP-EXT]).
PEP (router) +-----------------+ | | R1 ------------+if1 if2+------------ S1 | | +-----------------+ Figure 1: Unicast Example: a single PEP view The PEP router has two interfaces (if1, if2). Sender S1 sends to receiver R1. A Path message arrives from S1: PEP --> PDP REQ := <Handle A> <Context: in & out, Path> <In-Interface if2> <Out-Interface if1> <ClientSI: all objects in Path message> PDP --> PEP DEC := <Handle A> <Context: in & out, Path> <Decision: Command, Install> A Resv message arrives from R1: PEP --> PDP REQ := <Handle B> <Context: in & allocation & out, Resv> <In-Interface if1> <Out-Interface if2> <ClientSI: all objects in Resv message> PDP --> PEP DEC := <Handle B> <Context: in, Resv> <Decision: command, Install> <Context: allocation, Resv> <Decision: command, Install> <Decision: Stateless, Priority=7> <Context: out, Resv> <Decision: command, Install> <Decision: replacement, POLICY-DATA1> PEP --> PDP RPT := <Handle B> <Report type: commit> Notice that the Decision was split because of the need to specify different decision objects for different context flags.
Time Passes, the PDP changes its decision: PDP --> PEP DEC := <Handle B> <Context: allocation, Resv> <Decision: command, Install> <Decision: Stateless, Priority=3> Because the priority is too low, the PEP preempts the flow: PEP --> PDP DRQ := <Handle B> <Reason Code: Preempted> Time Passes, the sender S1 ceases to send Path messages: PEP --> PDP DRQ := <Handle A> <Reason: Timeout>
PDP --> PEP DEC := <Handle A> <Context: in, Path> <Decision: command, Install> The PEP consults its forwarding table, and finds two outgoing interface for the path (if1, if2). The exchange below is for interface if1, another exchange would likewise be completed for if2 using the new handle B2. PEP --> PDP REQ := <Handle B1> <Context: out, Path> <Out-interface if1> <clientSI: all objects in outgoing Path> PDP --> PEP DEC := <Handle B1> <Context: out, Path> <Decision: command, Install> <Decision: Replacement, POLICY-DATA1> Here, the PDP decided to allow the forwarding of the Path message and provided the appropriate policy-data object for interface if1. Next, a WF Resv message from receiver R2 arrives on interface if2. PEP --> PDP REQ := <Handle C> <Context: in & allocation, Resv> <In-interface if2> <ClientSI: all objects in Resv message including RSpec1 > PDP --> PEP DEC := <Handle C> <Context: in, Resv> <Decision: command, Install> <Context: allocation, Resv> <Decision: command, Install> <Decision: Stateless, priority=5> PEP --> PDP RPT := <handle C> <Commit> Here, the PDP approves the reservation and assigned it preemption priority of 5. The PEP responded with a commit report. The PEP needs to forward the Resv message upstream toward S1: PEP --> PDP REQ := <Handle E> <Context: out, Resv> <out-interface if3> <Client info: all objects in outgoing Resv>
PDP --> PEP DEC := <Handle E> <Context: out, Resv> <Decision: command, Install> <Decision: replacement, POLICY-DATA2> Note: The Context object is part of this DEC message even though it may look redundant since the REQ specified only one context flag. Next, a new WF Resv message from receiver R3 arrives on interface if2 with a higher RSpec (Rspec2). Given two reservations arrived on if2, it cannot perform a request with multiple context flags, and must issue them separately. The PEP re-issues an updated handle C REQ with a new context object <Context: in , Resv>, and receives a DEC for handle C. PEP --> PDP REQ := <Handle F> <Context: in , Resv> <In-interface if2> <ClientSI: all objects in Resv message including RSpec2 > PDP --> PEP DEC := <Handle F> <Context: in , Resv> <Decision: command, Install> PEP --> PDP REQ := <Handle G> <Context: allocation, Resv> <In-interface if2> <ClientSI: all objects in merged Resv including RSpec2 > PDP --> PEP DEC := <Handle G> <Context: allocation, Resv> <Decision: command, Install> <Decision: Stateless, Priority=5> PEP --> PDP RPT := <handle G> <Commit> Given the change in incoming reservations, the PEP needs to forward a new outgoing Resv message upstream toward S1. This repeats exactly the previous interaction of Handle E, except that the ClientSI objects now reflect the merging of two reservations. If an ResvErr arrives from S1, the PEP maps it to R3 only (because it has a higher flowspec: Rspec2) the following takes place: PEP --> PDP REQ := <Handle H> <Context: in, ResvErr> <In-interface if3> <ClientSI: all objects in incoming ResvErr>
PDP --> PEP DEC := <Handle H> <Context: in, ResvErr> <Decision: command, Install> PEP --> PDP REQ := <Handle I> <Context: out, ResvErr> <Out-interface if2> <ClientSI: all objects in outgoing ResvErr> PDP --> PEP DEC := <Handle I> <Context: out, ResvErr> <Decision: command, Install> <Decision: Replacement, POLICY-DATA3> When S2 joins the session by sending a Path message, incoming and outgoing Path requests are issued for the new Path. A new outgoing Resv request would be sent to S2. [RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000. [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997.
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone: 508.620.1141 EMail: email@example.com Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK Phone: +44-208-756-8693 EMail: firstname.lastname@example.org
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.