Internet Draft
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 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]