Internet Draft Dinesh G Dutt File: draft-nitsan-cops-rsvp-proxy-01.txt Nitsan Elfassy Expiration Date: August 2000 Cisco Systems David Durham Intel Keith McCloghrie Cisco Systems February 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 February 2000 1. Introduction RSVP Receiver Proxy [RSVP-PROXY] is an extension to RSVP [RFC2205] message processing in which a network device receiving a RSVP Path message generates a Resv message on behalf of the receiver identified by the Path message. The generation of the Resv message is done under 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 however does not specify any mechanism whereby the PDP can notify the PEP to generate a Resv message in response to an incoming Path message. This document specifies such an extension. 2. Functionality Required to Support RSVP Receiver Proxy Via COPS The support for RSVP Receiver Proxy via COPS requires a small extension to the existing functionlity as specified in [RFC2749]. To support RSVP Receiver Proxy via COPS for RSVP, the following decisions need to be communicated to the PEP by the PDP: o Accept the incoming Path message o Forward/Do not forward the Path message o Generate a Proxy Resv message o Objects to be inserted into the Resv message if Resv is proxied o Delete an existing Proxy Resv message state Existing mechanisms handle the first two cases while support for the last three cases needs to be specified. 2.1. Decision: Generate a Proxy Resv Message The decision to genarate a proxy Resv message is specified in the context of <In, Path> since it is the incoming Path message that triggered the generation of the Resv. The decision to generate a Resv 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. We propose to use a Decision Flag of 0x03 to specify that a proxy Resv must be generated/deleted. The PDP MUST return a Decision object with the newly defined decision flag to instruct the PEP to return a Resv message. If the Proxy Resv decision flag is set and the command code is Install, a new Resv state is to be installed and Proxied Resv messages generated according to RSVP messaging rules. Resv messages should continue to be generated according to the RSVP soft state keep-alive rules as long as the Proxied Resv state remains installed and the PATH state remains installed. If the Proxy Resv decision flag is set and the command code is Remove, then the proxied Resv state Dutt, Elfassy, Durham, McCloghrie [Page 2]
COPS extensions for RSVP Receiver Proxy February 2000 MUST be removed and proxied Resv messages are no longer to 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 being generated by the PEP. 2.3. The New Decision Object The modified Decision object 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) 0x02 = Generate Proxy Resv Note: Trigger Error is applicable to client-types that are capable of sending error notifications for signaled messages. 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]. Dutt, Elfassy, Durham, McCloghrie [Page 3]
COPS extensions for RSVP Receiver Proxy February 2000 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. 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. [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated Services," 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, <draft-ietf-rsvp-proxy-00.txt>, February 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 Special thanks to Keith McCloghrie for his valuable feedback on the document. 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 Dutt, Elfassy, Durham, McCloghrie [Page 4]
COPS extensions for RSVP Receiver Proxy February 2000 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 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 5]