Internet Draft Dinesh G Dutt File: draft-nitsan-cops-rsvp-proxy-02.txt Nitsan Elfassy Expiration Date: December 2000 Cisco Systems, Inc. David Durham Intel Inc. Keith McCloghrie Cisco Systems, Inc. July 2000 COPS Extensions for RSVP Receiver Proxy Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document proposes an extension to COPS [RFC2748] and COPS Usage for RSVP [RFC2749] documents needed to support RSVP Receiver Proxy [RSVP-PROXY]. Dutt, Elfassy, Durham, McCloghrie [Page 1] COPS extensions for RSVP Receiver Proxy July 2000 1. Introduction RSVP Receiver Proxy[RSVP-PROXY] is an extension to the RSVP message processing in which an intermediate network node originates the Resv message on behalf of the receiver(s) identified by the Path message. Proxying the Resv involves installing reservation state in the proxying node. In other words, the proxying node is responsible for reserving resources on the outgoing interface, sending periodic Resv messages, tearing down the reservation when the Path terminates etc. The decision to proxy is made by the policy control. Policy control can either be performed using local policy or by a policy server using COPS for RSVP[RFC2749]. The current definition of COPS for RSVP does not specify any mechanism whereby the PDP can notify the PEP to act as a RSVP Receiver Proxy in response to an incoming Path message. This document specifies such an extension. 2. Functionality Required to Support RSVP Receiver Proxy Via COPS Some of the requirements to support RSVP Receiver Proxy is already available via the existing COPS for RSVP protocol[RFC2749]. Specifically, support for installing state associated with an incoming Path message and for specifying whether the Path message should be forwarded further or not is already provided. In addition to this, it is required to provide support for the following pieces: o Support for installing/deleting RSVP Receiver Proxy state o Providing a mechanism to notify the PDP about a PEP's capability to act as a RSVP Receiver Proxy. Installing receiver proxy state involves: o Originating Resv message on behalf of the receiver identified in the Path message. o Sending periodic refreshes of the Resv message. o If required, performing admission control on the outgoing interface(s) of the Resv message. o Handling Path tear down and PathErr messages. 2.1 Decision: Install/Delete RSVP Receiver Proxy State The decision to install RSVP receiver proxy state is specified in the context of since it is the incoming Path message that triggered the generation of the Resv. The decision to install receiver proxy state is in addition to accepting the Path message. It is therefore appropriate to add a new flag to the Decision Object [RFC2748] to specify this additional functionality. Dutt, Elfassy, Durham, McCloghrie [Page 2] COPS extensions for RSVP Receiver Proxy July 2000 We propose to use a Decision Flag of 0x03 to specify that a receiver proxy state must be installed/deleted. The PDP MUST return a Decision object with the newly defined decision flag to instruct the PEP to install the receiver proxy state. If the RSVP Receiver Proxy decision flag is set and the command code is Install, a new Resv state MUST be installed and proxy Resv messages MUST be originated according to RSVP messaging rules. If the RSVP Receiver Proxy decision flag is set and the command code is Remove, then the proxied Resv state MUST be removed and proxy Resv messages MUST no longer be generated by the PEP. The "Replacement Data" object specified along with this decision will carry the objects that need to be inserted into the Resv message generated by the PEP. 2.2 The Modified Decision Object The Decision object with the new flag looks as follows: C-Num = 6 C-Type = 1, Decision Flags (Mandatory) 0 1 2 3 +--------------+--------------+--------------+--------------+ | Command-Code | Flags | +--------------+--------------+--------------+--------------+ Commands: 0 = NULL Decision (No configuration data available) 1 = Install (Admit request/Install configuration) 2 = Remove (Remove request/Remove configuration) Flags: 0x01 = Trigger Error (Trigger error message if set) 0x03 = Install/Delete RSVP Receiver Proxy state Note: Trigger Error is applicable to client-types that are capable of sending error notifications for signaled messages. 2.3 Ability to Provide RSVP Receiver Proxy Functionality As per the COPS specification[RFC2748], a client receiving a Decision object with an unrecognized flag MUST ignore the flag. So, a PEP which doesn't recognize the flag to install/delete RSVP Receiver Proxy state will ignore it. Thus, the PDP has no mechanism to determine whether the PEP will support the decision to act as a proxy. To overcome this problem, there must be a mechanism provided for a PEP to notify the PDP about its ability to act as a RSVP Receiver Proxy. This ability is conveyed via a new object called RSVP Capability object. This object is communicated by the PEP to the PDP Dutt, Elfassy, Durham, McCloghrie [Page 3] COPS extensions for RSVP Receiver Proxy July 2000 in the Client-Open message. It is carried in the ClientSI object of the Client-Open message. 2.4 RSVP Capability Object The newly defined RSVP capability object has the following format: C-Num = 9 C-Type = 3, RSVP Capability Object 0 1 2 3 +--------------+--------------+--------------+--------------+ | Flags | +--------------+--------------+--------------+--------------+ Flags: 0x01 = Ability to act as a RSVP Receiver Proxy This object is defined to be a subtype of the ClientSI object. As currently defined, this object carries a single capability, the capability to act as RSVP Receiver Proxy. Any node capable of supporting RSVP Receiver Proxy MUST include this object in the Client-Open message. Any PDP capable of supporting RSVP Receiver Proxy MUST set the flag in the Decision object to install/delete RSVP Receiver Proxy state only if it receives this object in the Client-Open message. 3. Compatibility With Existing COPS For RSVP Implementations It is possible that either the PEP or the PDP does not support RSVP Receiver Proxy. In either case, there are no compatibility problems with existing PDPs or PEPs. If a PDP does not support the extensions specified in this document, the consequence is that the PEP will not be able to implement RSVP Receiver Proxy under COPS policy control. If the PEP that does not support the specified COPS for RSVP extensions receives a DEC message with the newly specified Decision flag, it MUST delete its request specifying the Unknown COPS Object reason code because the PEP will be unable to comply with the information contained in the decision object. This is compliant with [RFC2748]. 4. Security Considerations The use of COPS for RSVP Receiver Proxy introduces no new security issues over the base COPS for RSVP [COPS]. The security mechanism described in that document should be deployed in the scenarios that RSVP Receiver Proxy is deployed as well. Dutt, Elfassy, Durham, McCloghrie [Page 4] COPS extensions for RSVP Receiver Proxy July 2000 5. References [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin S., "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", IETF RFC 2205, Proposed Standard, September 1997. [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", December 1998. [RSVP-PROXY] Gai S., Dutt D., Elfassy N., Bernet Y., RSVP Receiver Proxy, , July 2000. [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., Sastry, A., "COPS usage for RSVP," RFC 2749, January 2000. 6. Author Information Dinesh G Dutt Cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134-1706 Phone: (408) 527-0955 Email: ddutt@cisco.com Nitsan Elfassy Cisco Systems, Inc. 4 Maskit St, P.O.Box 12497 Herzelia Pituach 46766, Israel Phone: +972 9 970 0066 Email: nitsan@cisco.com David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: (503) 264-6232 Email: David.Durham@intel.com Keith McCloghrie Cisco Systems Inc. 170 Tasman Dr. San Jose, CA 95134-1706 Phone: (408) 526-5260 Email: kzm@cisco.com Dutt, Elfassy, Durham, McCloghrie [Page 5] COPS extensions for RSVP Receiver Proxy July 2000 7. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Dutt, Elfassy, Durham, McCloghrie [Page 6] -- Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? - T. S. Eliot