One document matched: draft-nitsan-cops-rsvp-proxy-01.txt

Differences from draft-nitsan-cops-rsvp-proxy-00.txt

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]