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 <In, Path> 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, <draft-ietf-rsvp-proxy-01.txt>, 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