Internet Draft                                  Jim Boyle
 Expiration: September 1998                          MCI February 1999                           Level 3
 File: draft-ietf-rap-cops-01.txt draft-ietf-rap-cops-02.txt                Ron Cohen
                                                     Class Data Systems
                                                     Cisco
                                                 David Durham
                                                     Intel
                                                 Shai Herzog
                                                     IPHighway
                                                 Raju Rajan
                                                     IBM
                                                 Arun Sastry
                                                     Cisco

             The COPS (Common Open Policy Service) Protocol

                    Last Updated: March 12, August 6, 1998

Status of this Memo

   This document is an Internet Draft.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.

   A revised version of this draft document will be submitted to the
   RFC editor as a Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested.  This
   document will expire before September 1998. February 1999. Distribution of this
   draft is unlimited.

Abstract

   This document describes a simple client/server model for supporting
   policy control over QoS Signaling Protocols with similar properties
   as ReSerVation Protocol (RSVP). and provisioned QoS
   resource management. It is designed to be extensible so that other
   kinds of policy clients may be supported in the future. The model
   does not make any assumptions about the decision methods of the policy
   server, but is based on the server returning responses decisions to policy
   requests.

1. Introduction

   This document describes a simple query and response protocol that
   can be used to exchange policy information between a policy server
   (Policy Decision Point or PDP) and its clients (Policy Enforcement
   Points or PEPs).  One example of a policy client is expected to be RSVP routers
   that must exercise policy-based admission control over RSVP usage
   [RSVP].  We assume that at least one policy server exists in each
   controlled administrative domain. The basic model of interaction
   between a policy server and its clients is compatible with
   the framework document for policy based admission control [WRK].

   A chief objective of our proposal policy control protocol is to begin with a
   simple but extensible design. The main characteristics of the proposed COPS
   protocol include:

       1. The protocol employs a client/server model where the PEP
       sends requests, updates, and deletes to the remote PDP and the
       PDP returns decisions back to the PEP.

       2. The protocol uses TCP as its transport protocol for reliable
       exchange of messages between policy clients and a server.
       Therefore, no additional mechanisms are necessary for reliable
       communication between a server and its clients.

       3. The protocol is extensible in that it is designed to leverage
       off self-identifying objects and can support diverse client
       specific information. Thus, even though information without requiring modifications to the COPS
       protocol itself. The protocol was created for the administration general
       administration, configuration, and enforcement of policies in
       conjunction with RSVP, the
       whether signaled or provisioned. The protocol may be extended
       for the administration of other (signaling) a variety of signaling protocols such as multicast
       access and network security.
       well as policy configuration on a device.

       4. The protocol relies on existing protocols for security.
       Namely IPSEC [IPSEC] can be used to authenticate and secure the
       channel between the PEP and the server.

       5. The protocol is stateful in two main aspects:
       (1) Request/Response Request/Decision state is shared between client and server
       and (2) State from various events (Request/Response (Request/Decision pairs) may
       be inter-associated. By (1) we mean that requests from the
       client PEP are installed or remembered by the remote PDP until
       they are explicitly deleted by the PEP. At the same time,
       Responses
       Decisions from the remote PDP can be generated asynchronously at
       any time for a currently installed request state. By (2) we mean
       that the server may respond to new queries differently because
       of previously installed, related Request/Response state (e.g.,
       for RSVP, installed Request/Decision state(s) that are
       related.

       6. Additionally, the protocol is stateful in that it allows the
       server may associate to push configuration information to the client, and then
       allows the server to remove such state from incoming Path and
       Resv requests). the client when it
       is no longer applicable.

1.1. Basic Model

       +----------------+
       |                |
       |  Network Node  |            Policy Server
       |                |
       |   +-----+      |   COPS        +-----+
       |   | PEP |<-----|-------------->| PDP |
       |   |+----+   +-----+      |               +-----+
       |    ^           |
       |    |           |
       |    \-->+-----+ |
       |        | LDP | |
       |        +-----+ |
       |                |
       +----------------+

       Figure 1: A COPS illustration.

   Figure 1 Illustrates the layout of various policy components in a
   typical COPS example (taken from [WRK]). Here, COPS is used to
   communicate policy information between a Policy Enforcement Point
   (PEP) and a remote Policy Decision Point (PDP). (PDP) within the context of
   a particular type of client.

   It is assumed that each participating policy client is functionally
   consistent with a PEP [WRK]. The PEP may communicate with a policy
   server (herein referred to as a remote PDP [WRK]) to obtain policy
   decisions or directives.

   The COPS protocol uses a single persistent TCP connection between
   the PEP and a remote PDP. The remote PDP listens on a well-known
   port number (COPS=3288), and the PEP is responsible for initiating
   the connection. The location of the remote PDP can either be
   configured, or obtained via a service location mechanism [SRVLOC].
   Service discovery is outside the scope of this protocol, however.

   The PEP uses the a TCP connection to send requests to and receive
   responses
   decisions from the remote PDP. Communication between the PEP and
   remote PDP is mainly in the form of a stateful request/response request/decision
   exchange, though the remote PDP may occasionally send an unsolicited
   response
   decisions to the PEP to force a change changes in a previously approved request state.
   states. The PEP also has the capacity to report to the remote PDP
   that it has committed to an accepted request state for purposes of
   accounting and monitoring. The PEP is responsible for notifying the
   PDP when a request state has changed on the PEP. Finally, the PEP is
   responsible for the deletion of a request any state that is no longer
   applicable due to events at the client or
   updating a request state on decisions issued by the PDP when
   server.

   When the PEP sends a configuration request, it likewise changes at expects the
   PEP.

   The policy protocol is designed PDP to communicate self-identifying
   objects which contain the data
   continuously send named units of configuration data to the PEP via
   decision messages as applicable for the configuration request. When
   a unit of named configuration data is successfully installed on the
   PEP, the PEP should send a report message to the PDP confirming the
   installation. The server may then update or remove the named
   configuration information via a new decision message. When the PDP
   sends a decision to remove named configuration data from the PEP,
   the PEP will delete the specified configuration and send a report
   message to the PDP as confirmation.

   The policy protocol is designed to communicate self-identifying
   objects which contain the data necessary for identifying request
   states, establishing the context for a request, identifying the type
   of request, referencing previously installed requests, relaying
   policy decisions, reporting errors, and transferring client specific
   specific/name space information.

   To distinguish between different kinds of clients, the type of
   client is identified in each message. Different types of clients may
   have different client specific data and may require different kinds
   of policy decisions. It is expected that each new client type client-type will
   have a corresponding extensions usage draft specifying the specifics of its
   interaction with this policy protocol.

   The context of each request corresponds to the policy type of event that
   triggered it. COPS identifies three types of controlled outsourcing events: (1)
   the arrival of an incoming message (2) allocation of local
   resources, and (3) the forwarding of an outgoing message. Each of
   these events may require different decisions to be made. Context sub
   types are also defined according available to describe the type of message that
   triggered the policy event. In RSVP, this subtype is used to
   define the RSVP signaling message type (e.g., Path, Resv, etc.). The content of a COPS request/response request/decision
   message depends on the context. A forth type of request is useful
   for types of clients that wish to receive configuration information
   from the PDP. This allows a PEP to issue a configuration request for
   a specific named device or module that requires configuration
   information to be installed.

   The PEP may also have the capability to make a local policy decision
   via its Local Decision Point (LDP) [WRK], however, the PDP remains
   the authoritative decision point at all times. This means that
   any the
   relevant local decision information must always be relayed to the PDP. That
   is, the PDP must be granted access to all relevant information to
   make a final policy decision. To facilitate this functionality, the
   PEP must send its local decision information to the remote PDP via a
   LDP decision object. The PEP must then abide by the PDP's decision
   as it is absolute.

   Finally, fault tolerance is a required capability for this protocol,
   particularly due to the fact it is associated with the security and
   service management of distributed network devices. Fault tolerance
   is achieved by having both the PEP and remote PDP constantly verify
   their connection to each other via keep-alive messages. When a
   failure is detected, the PEP must try to reconnect to the remote PDP
   or attempt to connect to a new/alternative PDP. While disconnected,
   the PEP should revert to making local decisions. Once a connection
   is reestablished, the PEP is expected to notify the PDP of any
   events that passed local admission control after the connection was
   lost. Additionally, the remote PDP may request that all the PEP's
   internal state be resynchronized (all previously installed requests
   are to be reissued). After failure and before the new connection is
   fully functional, disruption of service can be minimized if the PEP
   caches previously communicated decisions and continues to use them
   for some limited amount of time. time, typically in the order of minutes.
   (Discussions of specific provisions for such a mechanism are outside
   of the scope of this draft, and are left to client specific
   implementations).

2. The Protocol

   This section describes the message formats and objects exchanged
   between the PEP and remote PDP.

2.1 Common Header

   Each COPS message consists of the COPS header followed by a number
   of typed objects.

              0              1              2              3
       +--------------+--------------+--------------+--------------+
       |Version| //// |    Op Code   |       Client Type       Client-type           |
       +--------------+--------------+--------------+--------------+
       |                      Message Length                       |
       +--------------+--------------+--------------+--------------+

   Global note: //// implies field is reserved, set to 0.

       The fields in the header are:
         Version: 4 bits
             COPS version number. Current version is 1.

       Op Code: 8 bits
            The COPS operations:
              1 = Request                 (REQ)
              2 = Response                (RES)
              3 = Unsolicited Response    (USR) Decision                (DEC)
              4 = Report State            (RPT)
              5 = Delete Request State    (DRQ)
              6 = Synchronize State Req   (SSQ)
              7 = Client-Open             (OPN)
              8 = Client-Accept           (CAT)
              9 = Keep-Alive              (KA)
              10= Client-Close            (CC)

       Client Type:
              11= Synchronize Complete    (SSC)

       Client-type: 16 bits

       The Client Type Client-type identifies the policy client. Interpretation of
       all encapsulated objects is relative to the client type. client-type. Client-
       types that set the most significant bit in the client-type field
       are enterprise specific (these are client-types 0x8000 -
       0xFFFF). (See Appendix A for the RSVPv1 specific client type ID). usage documents for particular
       client-type IDs).

       Message Length: 32 bits
       Size of message in octets, which includes the standard COPS
       header and all encapsulated objects. Messages must be aligned on
       4 octet intervals.

2.2 COPS Specific Object Formats

   All the objects follow the same object format; each object consists
   of one or more 32-bit words with a four octet four-octet header, using the
   following format:

              0             1              2             3
       +-------------+-------------+-------------+-------------+
       |       Length (octets)     |    C-Num    |   C-Type    |
       +-------------+-------------+-------------+-------------+
       |                                                       |
       //                  (Object contents)                   //
       |                                                       |
       +-------------+-------------+-------------+-------------+

   Typically, C-Num identifies

   The length is a two-octet value that describes the class number of information contained in octets
   (including the object, and header) that compose the C-Type identifies object. If the subtype or version length in
   octets does not fall on a 32-bit word boundary, padding must be
   added to the end of the object so that it is aligned to the next 32-
   bit boundary before the object can be sent on the wire. On the
   receiving side, a subsequent object boundary can be found by simply
   rounding up the previous stated object length to the first 32-bit
   boundary.

   Typically, C-Num identifies the class of information contained in
   the object, and the C-Type identifies the subtype or version of the
   information contained in the object.

      C-num: 8 bits

               1  = Handle
               2  = Handle Reference.
               3  = Context
               4  = In Interface
               5  = Out Interface
               6  = Reason code
               7  = Decision
               8  = LDP Decision
               9  = Protocol Error
               10 = Client Specific Info
               11 = Timer
               12 = PEP Identification
               13 = Report Type
               14 = PDP Address

      C-type: 8 bits
               Values defined per C-num.

2.2.1 Handle Object (Handle)

   Unique

   The Handle Object encapsulates a unique value that identifies an
   installed request state. This identification is used by most COPS
   operations. The request A state corresponding to this a handle must be explicitly
   deleted when it is no longer applicable.

           C-Num = 1

           C-Type = 1, Client Handle.

   Variable-length field, no implied format other than it is unique
   from other client handles. It is always initially chosen by the PEP
   and then deleted by the
   client PEP when no longer applicable. The client
   handle is used to refer to a request state initiated by the PEP and
   installed at the PDP. A PEP will specify a client handle in its
   Request messages, Report messages and Delete messages sent to the
   PDP. In all cases, the client handle is used to uniquely identify
   the PEP request.

   The client handle value is set by the PEP and is opaque to the PDP.
   The PDP simply performs a byte-wise comparison on the value in this
   object with respect to the handle object values for of other currently
   installed requests.

           C-Num = 1, C-Type = 1

   Variable-length field, no implied format.

2.2.2 Handle Reference Object (HandleRef)

   Same C-Type formats as the handle object. This object may appear in
   requests and is used to associate the current request to previously
   installed request states. The presence of a reference handle in a
   request message tells the PDP that it should also consider
   information in the referenced installed state when making a policy
   decision for the current request. Handle References are only used
   for the specific client types that mandate them.

           C-num = 2, C-Type = (same as handle object)

2.2.3 Context Object (Context)

   Specifies the type of event(s) that triggered the query. Required
   for request messages. Admission control, resource allocation, and
   forwarding requests are all amenable to client-types that outsource
   their decision making facility to the PDP. For applicable client-
   types a PEP can also make a request to receive named configuration
   information from the PDP. This named configuration data may be in a
   form useful for setting system attributes on a PEP, or it may be in
   the form of policy rules that are to be directly verified by the
   PEP.

   Multiple flags can be set for the same request. This is only
   allowed, however, if the set of client specific information in the
   combined request is identical to the client specific information
   that would be specified if individual requests were made for each
   specified flag.

           C-num = 3, C-Type = 1

              0             1               2               3
       +--------------+--------------+--------------+--------------+
       |            R-Type           |            M-Type           |
       +--------------+--------------+--------------+--------------+

           R-Type (Request Type Flag)

               0x01 = Incoming-Message/Admission Control request
               0x02 = Resource-Allocation request
               0x04 = Outgoing-Message request
               0x08 = Configuration request
           M-Type (Message Type)

               Client Specific 16 bit values of protocol message types

2.2.4

2.2.3 In-Interface Object (IN-Int)

   The In-Interface Object is used to identify the incoming interface
   on which a particular request/response request/decision applies. For flows or
   messages generated from the PEP's local host, the loop back address
   is used.

   Note: In-Interface is typically relative to the flow of the
   underlying protocol messages. That is, the In-Interface is the
   interface on which the protocol message was received.

           C-Num = 4

           C-Type = 1, IPv4 Address
               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |                   IPv4 Address format                     |
       +--------------+--------------+--------------+--------------+

           C-Type = 2, IPv6 Address
               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |                                                           |
       +                                                           +
       |                                                           |
       +                    IPv6 Address format                    +
       |                                                           |
       +                                                           +
       |                                                           |
       +--------------+--------------+--------------+--------------+

           C-Type = 3, Ifindex value
                   0             1              2             3
       +--------------+--------------+--------------+--------------+
       |                          ifindex                          |
       +--------------+--------------+--------------+--------------+

   Ifindex may be used to differ between sub-interfaces and unnumbered
   interfaces (see RSVP's LIH for an example). When appropriate, this
   ifindex integer should correspond to the same integer value for the
   interface in the SNMP MIB-II interface index table.

2.2.5

2.2.4 Out-Interface Object (OUT-Int)

   The Out-Interface is used to identify the outgoing interface to
   which a specific request/response request/decision applies. It has the same format as
   the In-Interface Object.

           C-Num = 5, C-Type = (same C-Type as for In-Interface)

   Note: In-Interface Out-Interface is typically relative to the flow of the
   underlying protocol messages. That is, the Out-Interface is the one
   on which a protocol message is about to be forwarded.

2.2.6

2.2.5 Reason Object (Reason)

   This object specifies the reason why the request state was deleted.
   It should appear in the delete request (DRQ) message. The Reason
   Sub-code field is reserved for more detailed client-specific reason
   codes defined in the corresponding documents.

           C-Num = 6, C-Type = 1

               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |         Reason-Code         |       Reason Sub-code       |
       +--------------+--------------+--------------+--------------+

           Reason Code:
               1 = Unknown Unspecified
               2 = Management
               3 = Preempted
               4 = Tear
               5 = Timeout
               6 = Route Change
               7 = Insufficient Resources
               8 = PDP's Directive
               9 = Client Specific (details in sub-code) Unsupported decision
               10= Synchronize Handle Unknown

2.2.7
               11= Transient Handle (stateless event)

2.2.6 Decision Object (Decision)

   Decision made by the PDP. Must appear in replies. The specific non-
   mandatory decision objects required in a response decision to a particular
   request depend on the type of client.

               C-Num = 7

               CType = 1, Decision Flags (mandatory!) (Mandatory)

       A flag bit set to 1 implies a negative decision for that flag.
       Flags
       Not setting any flags generally implies a positive decision.
       Flag values not applicable to a given request type should MUST be ignored.
       ignored by the PEP.

               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |                           Flags                           |
       +--------------+--------------+--------------+--------------+
           Flags:
               0x01 = Reject Allow Incoming (Reject if set)
               0x02 = Do Not Allocate Resources (Reject if set)
               0x04 = Drop Forward Outgoing (do not forward message if set)
               0x08 = Trigger Error (Trigger error message if set)
               0x10 = NULL Configuration (No configuration data if set)
               0x20 = Install Configuration (Nothing to install if set)
               0x40 = Remove Configuration (Nothing to remove if set)
               0x80 = Enable Configuration (Nothing to enable if set)
               0x100= Disable Configuration (Nothing to disable if set)
               0x200= Solicited Decision
                  (Initial decision after a new/updated request if set)

              Ctype = 2, Resource Allocation Data (optional)

       It is expected that even outsourcing PEPs would will be able to configure make
       some simple stateless policy information to be processed decisions locally in their LDP. As
       this set is well known and implemented ubiquitously, PDPs are
       aware of it as well (either universally, through configuration,
       or using the Client-Open message). The PDP may also include this
       information in its response, decision, and the PEP should apply it to the
       resource allocation event that generated the request.

       Examples of resource allocation information that can

       As an example, reservations may be found in
       other documents are:

       Preemption Priority

       Priority is used admitted by PEP to decide which of the flows should be
       preempted, when not enough resources are available a PDP contingent
       on the
       interface. For RSVP, when some type of per-session preemption is supported, priority. A RSVP PEP
       could have a higher
       priority reservation can set of stateless policy rules for when to preempt an installed reservation with
       other reservations in favor of a new one (e.g. higher-priority
       pre-empts any of lower priority. priority). The PDP would need to include
       appropriate priority information for each reservation in its
       decisions that the PEP can use to apply its rules.

               CType = 3, Replacement Data (Optional)

       This object is typically applicable as a response decision for an
       outgoing request. Format includes a list of client specific data
       that is to be used in place of information specified in the
       request. Use of this decision type is optional. For RSVP, this
       decision is used to change objects carried in RSVP messages. For
       example, replacing the policy data objects when forwarding a
       Resv message upstream is possible due to this decision type. If
       this decision doesn't appear in a response, decision message, all signaled
       objects are passed as if the PDP was not there. To remove an
       object the decision should carry an empty object of length 4
       (header only).
       Appendix A specifies the list of RSVP objects that can be
       replaced.

               CType = 4, Client Specific Decision Data (Optional)

       Proprietary

       Additional decision types can be introduced using the Client
       Data
       Specific Decision Data Object. Like the Replacement Data object,
       client specific information is encapsulated within the Client
       Data Object.

2.2.8

               Ctype = 5, Named Decision Data

       Named configuration information should be encapsulated in this
       version of the decision object in response to configuration
       requests.

2.2.7 LDP Decision Object (LDPDecision)

   Decision made by the PEP's local decision point (LDP). May appear in
   requests. These objects correspond to and are formatted the same as
   the client specific decision objects defined above.

           C-Num = 8

           CType = (same C-Type as for Decision object)

2.2.9 objects)

2.2.8 Error Object (Error)

   This object is used to identify a particular COPS protocol error.
   The error sub-code field contains additional detailed client
   specific error codes.

            C-Num 9, C-Type = 1

               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |          Error-Code         |        Error Sub-code       |
       +--------------+--------------+--------------+--------------+

           Error-Code:

               1 = Bad handle
               2 = Invalid handle reference
               3 = Bad message format
               4 = Unable to process (server gives up on query)
               5 = Mandatory client-specific info missing
               6 = Unsupported client type client-type
               7 = Mandatory COPS object missing
               8 = Client Failure
               9 = Communication Failure
               10= Client Specific (details in sub-code)

2.2.10 Unspecified
               11= Shutting down

2.2.9 Client Specific Information Object (ClientSI)

   All objects/attributes specific to a client's signaling protocol
   must be encapsulated within one or more Client Information Objects.

   The various types of this object are required for requests, and used
   in reports and opens when required. Additional ClientSI encapsulated
   data unknown to the PDP can be safely ignored by the PDP.

   Class-Num It contains client-related
   information.

           C-Num = 10,

           C-Type = 1, Request Signaled ClientSI.

   Variable-length field. The format of the data All objects/attributes specific to a client's
   signaling protocol or internal state must be encapsulated in the
   ClientSI object is determined by the client type. Used in request
   queries.

   C-Type = 2, Report ClientSI.

   Variable-length field. within one
   or more signaled Client Specific Information Objects. The format of
   the data encapsulated in the ClientSI object is determined by the client type. Used in COPS
   report messages when required.
   client-type.

           C-Type = 3, Client-Open 2, Named ClientSI.

   Variable-length field. The format of the data encapsulated in Contains named configuration information
   useful for relaying specific information about the
   ClientSI object is determined by PEP, a request,
   or configured state to the client type. Used in COPS
   clientSI messages for feature negotiation, etc. when required.

2.2.11 server.

2.2.10 Timer Object (Timer)

   Times are encoded as 2 octet integer values and are in units of
   seconds.  The time timer value is treated as a delta.

           Class-Num

           C-Num = 11,

           C-Type = 1, Keep-alive timer value

   Timer object used to specify the maximum time interval over which a
   COPS message must be sent or received. The value of zero implies
   infinity.

                0             1              2             3
       +--------------+--------------+--------------+--------------+
       |        //////////////       |        KA Timer Value       |
       +--------------+--------------+--------------+--------------+

2.2.12 PEP Identification

           C-Type = 2, Accounting timer value

   Optional timer value used to determine the minimum interval between
   periodic accounting type reports. The value of zero implies
   infinity.

                0             1              2             3
       +--------------+--------------+--------------+--------------+
       |        //////////////       |        ACCT Timer Value     |
       +--------------+--------------+--------------+--------------+

2.2.11 PEP Identification Object (PEPID)

   The PEP Identification Object is used to identify the PEP client to
   the remote PDP. It is required for Client-Open messages.

           C-Num = 12, C-Type = 1

   Variable-length field (zero padded ASCII symbolic name) configured
   by local administrators for the PEP. For example, it can be the
   PEP's main IP address (not to be confused with the actual IP address
   used in the persistent TCP connection). It may also be the PEP's DNS
   name, or any other symbol that uniquely identifies each PEP within
   the policy domain. The choice of configuration bears no significance
   to
   for the COPS protocol. protocol, but does for policy at the PDP that may need
   to uniquely identify individual PEPs. By default, at least the
   primary IP address of the PEP represented as a string is expected in
   the PEPID.

2.2.13

2.2.12 Report-Type Object (Report-Type)

   The Type of Report on the request state associated with a handle:

           C-Num = 13, C-Type = 1

               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |         Report-Type         |        /////////////        |
       +--------------+--------------+--------------+--------------+

           Report-Type:
               1 = Commit    : PEP's local resources now allocated
               2 = Accounting: Accounting update for an installed state
               3 = No Commit : PEP's resource allocation failure

2.2.14
               4 = Installed : Named configuration installed
               5 = Removed   : Named configuration removed
               6 = Enabled   : Named configuration enabled
               7 = Disabled  : Named configuration disabled
               8 = Inst&Enab : Named config. installed and enabled

2.2.13 PDP Address (PDPAddr)

   A PDP when closing a PEP session for a particular client type client-type may
   optionally use this object to redirect the PEP to another PDP server
   via this object:

       C-Num = 14,

       C-Type = 1, IPv4 Address
               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |                   IPv4 Address format                     |
       +--------------+--------------+--------------+--------------+ (4 octets, as shown for In-interface)

       C-Type = 2, IPv6 Address (16 octets, as shown for In-interface)

3. Message Content

   This section describes the basic messages exchanged between

2.3 Communication

   The COPS protocol uses a single persistent TCP connection between
   the PEP and a remote PDP as well as their contents.

3.1 Request (REQ)  PEP -> PDP PDP. The PEP establishes a request state handle for which the remote PDP
   may maintain listens on a state. The remote PDP then uses this handle to refer
   to the exchanged information well-known
   port number (COPS=3288), and decisions.

   Once a stateful handle is established for a new request, any
   subsequent modifications of the request can be made using the REQ
   message specifying the previously installed handle. The PEP is responsible for notifying the PDP whenever its local state changes
   so the PDP's state will mirror initiating
   the PEP's state. connection. The format location of the Request message remote PDP can either be
   configured, or obtained via a service location mechanism [SRVLOC].
   Service discovery is as follows:

                 <Request> ::= <Common Header>
                               <Handle>
                               <Context>
                               [<IN-Int>]
                               [<OUT-Int>]
                               <ClientSI>
                               [<list outside the scope of HandleRefs>]
                               [<LDPDecision>]

   The context object this protocol, however.

   It is used to determine the context within which all
   the other objects are possible a single PEP may have open connections to be interpreted. It also multiple
   PDPs. This is used to
   determine the kind of response to be returned from the policy
   server. This response might be related to admission control,
   resource allocation, or object forwarding and substitution.

   The interface objects case when there are used to determine the corresponding
   interface on which physically different PDPs
   supporting different client-types as shown in figure 2.

       +----------------+
       |                |
       |  Network Node  |            Policy Server
       |                |
       |   +-----+      | COPS Client Type 1  +-----+
       |   |PEP1 |<-----|-------------------->| PDP1|
       |   +-----+  |   | COPS Client Type 2  +-----+
       |    ^ | PEP2|<--|---------\           +-----+
       |    | +-----+   |          \----------| PDP2|
       |    \-->+-----+ |                     +-----+
       |        | LDP | |
       |        +-----+ |
       |                |
       +----------------+

       Figure 2: Multiple PDPs illustration.

   When a signaling protocol message was received TCP connection is torn down or is
   about to be sent. They are only used if lost, both the client PEP and PDP
   is participating
   along the path of a signaling protocol.

   ClientSI (C-Type = 1), the client specific information object holds
   the client type specific data for which a policy decision needs expected to
   be made.

   The handle reference objects are used clean up any outstanding state related to refer any
   pervious request/decision exchanges. Additionally, the PEP should
   continuously attempt to state information
   currently installed on contact the primary PDP that or, if unsuccessful,
   any known backup PDPs. If a PEP is associated in communication with a backup
   PDP and the current
   request.

   Finally, LDPDecision object holds information regarding the local
   decision made by primary PDP becomes available, the LDP.

3.2 Response (RES) backup PDP -> should
   redirect the PEP

   The PDP responds back to the REQ with primary PDP (via a RES close/redirect
   message that includes the
   associated handle and for the decision. If there was a protocol error an
   error object affected client-type).

2.4 Client Handle Usage

   The client handle is returned instead.

   In order used to avoid the issue of keeping track of which Request a
   particular response belongs to, it is important that, for identify a given
   handle, there be at most one outstanding response per query.  This
   essentially means that unique request state. Client
   handles are chosen by the PEP should not issue more than one
   REQ(for a given handle) before it receives a corresponding RES. To
   avoid deadlock, and are opaque to the client can always timeout after issuing a
   request. It can then delete PDP. The PDP
   simply uses the timed-out handle, request handle to uniquely identify the request
   state and try again
   using generically tie its decisions to a different (new) handle.

   The format of the Response message is as follows:

               <Response> ::= <Common Header>
                              <Handle>
                              <Decision(s)> || <Error>

   The response may include either an Error object or one or more
   decision objects. COPS protocol problems corresponding request.
   Client handles are reported initiated in the Error
   object (e.g. an error with the format of the original request).
   Decision object(s) depend on the context of the associated request messages and are then used
   by subsequent request, decision, and report messages to reference
   the same request state. When the type of client.

3.3 Unsolicited Response (USR)  PDP -> PEP

   The remote PDP can also send an unsolicited response is ready to remove a PEP to
   report local
   request state, it will issue a different response than the one previously communicated.
   For example, delete message to the PDP may admit for the
   corresponding client handle. A handle MUST be explicitly deleted by
   the PEP before it can be used to identify a new flow and change its mind request state.
   Handles referring to
   reject it sometime later. The change of mind is communicated using
   the USR message.

   The format for an USR is different request states must be unique.

   3. Message Content

   This section describes the same as that for basic messages exchanged between a RES PEP
   and similarly,
   it dependents on the context of the original request.

3.4 Report State (RPT) a remote PDP as well as their contents.

3.1 Request (REQ)  PEP -> PDP

   This message is used by the

   The PEP to communicate a change in the
   status of establishes a previously installed request state to the server. A
   commit or no commit report indicates to client handle for which the
   remote PDP that a particular
   policy directive has or has not been acted upon as is relevant for
   accounting purposes. (In RSVP this would mean that may maintain a reservation
   passed or failed local capacity admission control). state. The Report State may also be used remote PDP then uses this
   handle to provide periodic updates of
   client specific refer to the exchanged information for accounting and state monitoring
   purposes depending on the type decisions.

   Once a stateful handle is established for a new request, any
   subsequent modifications of the client. In such cases the
   accounting report type should request can be specified utilizing made using the client
   specific information object (C-Type = 2).

              <Report State> ::== <Common Header>
                                  <Handle>
                                  <Report-Type>
                                  [ <Client Specific Information> ]

3.5 Delete Request State (DRQ)  PEP -> PDP

   This REQ
   message indicates to specifying the remote PDP that previously installed handle. The PEP is
   responsible for notifying the request PDP whenever its local state is
   no longer available in changes
   so the PEP and must be deleted. This PDP's state will be
   used by the remote PDP able to initiate accurately mirror the appropriate housekeeping
   actions. The reason code object is interpreted with respect to the
   client type. PEP's
   state.

   The format of the Delete Request State message is as follows:

              <Delete Request>

                 <Request> ::= <Common Header>
                                    <Handle>
                                    <Reason>

   Given the stateful nature of COPS, it
                               <Client Handle>
                               <Context>
                               [<IN-Int>]
                               [<OUT-Int>]
                               <ClientSI(s)>
                               [<LDPDecision>]

   The context object is important that when a
   request state used to determine the context within which all
   the other objects are to be interpreted. It also is finally removed used to
   determine the kind of decision to be returned from the PEP, policy
   server. This decision might be related to admission control,
   resource allocation, object forwarding and substitution, or
   configuration.

   The interface objects are used to determine the corresponding
   interface on which a DRQ signaling protocol message for
   this request state was received or is sent
   about to be sent. They are typically used if the PDP so client is
   participating along the corresponding state may
   likewise be removed on path of a signaling protocol or if the PDP. Request states not explicitly
   deleted by
   client is requesting configuration data for a particular interface.

   ClientSI, the PEP will client specific information object holds the client-
   type specific data for which a policy decision needs to be maintained by made. In
   the PDP until either case of configuration, the
   client session is closed named clientSI may include named
   information about the module, interface, or functionality to be
   configured.

   Finally, LDPDecision object holds information regarding the connection is terminated.

3.6 Synchronize State Request (SSQ) local
   decision made by the LDP.

3.2 Decision (DEC)  PDP -> PEP

   The format of PDP responds to the Synchronize State Query message is as follows:

              <Synchronize State> ::= <Common Header>
                                      [<Handle>]

   This REQ with a DEC message indicates that includes the remote PDP wishes the
   associated client (which
   appears in the common header) to re-send its state. handle and one or more decision objects. If the optional
   Handle there
   was a protocol error an error object is present, only the state associated with this handle returned instead.

   It is
   synchronized. If assumed that the client does not recognize first decision for a new/updated request will
   set the requested solicited decision flag. This avoids the issue of keeping
   track of which updated request (that is, a request reissued for the
   same handle) a particular decision corresponds. It is important
   that, for a given handle,
   it there be at most one outstanding solicited
   decision per request. This essentially means that the PEP should immediately send not
   issue more than one REQ (for a DRQ message to given handle) before it receives a
   corresponding DEC with the PDP for solicited decision flag set.

   To avoid deadlock, the handle
   that was specified in client can always timeout after issuing a
   request. It must then delete the SSQ message. If no handle timed-out handle, and possibly try
   again using a different (new) handle.

   The format of the Decision message is specified as follows:

               <Decision> ::= <Common Header>
                              <Client Handle>
                              <Context>
                              <Decision(s)> || <Error>

   The decision may include either an Error object or one or more
   decision objects. COPS protocol problems are reported in the SSQ message, all the active client state should be synchronized Error
   object (e.g. an error with the PDP.

   The client performs state synchronization by re-issuing request
   queries format of the specified client type for original request).
   Decision object(s) depend on the existing state in context and the
   PEP.

3.7 Client-Open (OPN) type of client.

3.3 Report State (RPT)  PEP -> PDP

   The Client-Open

   This message can be is used by the PEP to specify communicate a change in the
   status of a previously installed state to the PDP PDP. A commit or no-
   commit report-type indicates to the client types the PEP can support, PDP that a *suggested* time interval particular policy
   directive has or has not been acted upon as is relevant for keep-alive messages,
   accounting purposes. (In RSVP this would mean that a reservation
   passed or client specific feature negotiation. A
   Client-Open message can failed local capacity admission control. For a
   configuration decision, it would mean the decision data either could
   or could not be sent to installed by the PDP at any time and multiple
   Client-Open messages PEP).

   The Report State may also be used to provide periodic updates of
   client specific information for accounting and state monitoring
   purposes depending on the same client type are allowed (in case of global state changes).

        <Client-Open>  ::= the client. In such cases the
   accounting report type should be specified utilizing the client
   specific information object.

              <Report State> ::== <Common Header>
                           <PEPID>
                           [<Timer>]
                           [<ClientSI>]

   The PEPID is a symbolic, variable length name
                                  <Client Handle>
                                  <Report-Type>
                                  [<ClientSI(s)>]

3.4 Delete Request State (DRQ)  PEP -> PDP

   When sent from the PEP this message indicates to the remote PDP that identifies
   the
   specific state identified by the client handle is no longer
   available/relevant. This information will then be used by the remote
   PDP to initiate the PDP. Values for appropriate housekeeping actions. The reason
   code object is interpreted with respect to the PEPID are configurable by
   administrators of administrative domains client-type and are of direct
   significance to
   signifies the COPS protocol. By default, reason for the PEPID specifies removal.

   The format of the primary IP address in Delete Request State message is as follows:

              <Delete Request>  ::= <Common Header>
                                    <Client Handle>
                                    <Reason>

   Given the form stateful nature of COPS, it is important that when a string for
   request state is finally removed from the PEP in
   question.

   If included, the timer corresponds to PEP's preference PEP, a DRQ message for
   this request state is sent to the
   maximum intermediate time between PDP so the generation of messages for
   connection verification.

   Finally, a ClientSI (C-Type = 3) object can corresponding state may
   likewise be included for relaying
   global information about removed on the PDP. Request states not explicitly
   deleted by the PEP to will be maintained by the PDP when required (as
   specified in until either the appropriate extensions document).

3.8 Client-Accept (CAT)
   client session is closed or the connection is terminated.

3.5 Synchronize State Request (SSQ)  PDP -> PEP

   The Client-Accept message is used to positively respond to format of the
   Client-Open message. This Synchronize State Query message will return to the PEP a timer
   object indicating the expected time interval between keep-alive
   messages.

              <Client-Accept> is as follows:

              <Synchronize State> ::= <Common Header>
                                   <Timer>

   If
                                      [<Client Handle>]

   This message indicates that the remote PDP refuses wishes the client, it will instead issue a Client-Close
   message.

   The timer corresponds to maximum acceptable intermediate time
   between client (which
   appears in the generation of messages by common header) to re-send its state. If the PDP and PEP. The timer
   value optional
   Client Handle is determined by the PDP taking into account present, only the client's
   preference established state associated with the OPN message. A timer value of 0
   implies no secondary connection verification this handle
   is necessary.

3.9 Keep-Alive (KA)  PEP -> PDP, PDP -> synchronized. If the PEP

   The keep-alive does not recognize the requested handle,
   it should immediately send a DRQ message only needs to be transmitted when there has
   been no activity between the client and server PDP for a period
   approaching half the handle
   that of was specified in the minimum of all timer values negotiated
   with the OPN & CAT messages. It is a validation for each side that
   the connection SSQ message. If no handle is still functioning.

   Note: The client type specified in
   the header SSQ message, all the active client state should always be set to 0 as synchronized
   with the
   KA is used for connection verification (not per client session
   verification).

               <Keep-Alive>  ::= <Common Header>

   Both PDP.

   The client and server may assume performs state synchronization by re-issuing request
   queries of the connection is insufficient specified client-type for the client type with the minimum time value (specified existing state in the CAT
   message) if no communication activity is detected for a period
   exceeding the timer period. For the PEP, such detection implies the
   remote PDP or connection
   PEP. When synchronization is down and complete, the PEP should now attempt must issue a
   synchronize state complete message to
   use an alternative/backup the PDP.

3.10 Client-Close (CC)

3.6 Client-Open (OPN)  PEP -> PDP, PDP -> PEP

   The Client-Close Client-Open message can be issued used by either the PDP or PEP to
   notify specify to the other that PDP
   the client-types the PEP can support, a particular type of *suggested* time interval
   for keep-alive messages, and/or minimum time intervals for
   accounting updates, and/or client is no longer being
   supported.

               <Client-Close> specific feature negotiation. A
   Client-Open message can be sent to the PDP at any time and multiple
   Client-Open messages for the same client-type are allowed (in case
   of global state changes).

        <Client-Open>  ::= <Common Header>
                                   [<Error>]
                                   [<PDPAddr>]

   An Error object
                           <PEPID>
                           [<KA Timer>]
                           [<ACCT Timer>]
                           [<Client ClientSI>]

   The PEPID is optionally included a symbolic, variable length name that identifies the
   specific client to describe the reason PDP. Values for the close due to an error condition (e.g. requested client type is
   not supported PEPID are configurable by the remote PDP or client failure).

   A PDP may optionally include a PDP-Address object in order
   administrators of administrative domains and are of direct
   significance to inform the PEP of COPS protocol. By default, the alternate PDP it should use PEPID specifies
   the primary IP address in the form of a string for the client type
   specified PEP in
   question.

   If included, the common header.

4. Common Operation

   This section describes timer corresponds to PEP's preference for the typical exchanges
   maximum intermediate time between remote PDP
   servers and PEP clients.

   Sometime after a the generation of messages for
   connection is established between verification and/or the PEP and minimum time interval between
   periodic accounting reports.

   Finally, a
   remote PDP, named ClientSI object can be included for relaying
   additional global information about the PEP will send one or more Client-Open messages to the remote PDP, at least one for each client type supported by the
   PEP. The open message should contain PDP when required
   (as specified in the common header noting one
   client type supported by appropriate extensions document for the PEP. The remote client-
   type).

3.7 Client-Accept (CAT)  PDP will then respond
   with a -> PEP

   The Client-Accept message echoing back each of is used to positively respond to the client types
   Client-Open message. This message will return to the PEP supports that it can support as well. If a specific client
   type is not supported by timer
   object indicating the PDP, maximum time interval between keep-alive
   messages. Optionally, a timer specifying the minimum allowed
   interval between accounting report messages may be included when
   applicable.

              <Client-Accept>  ::= <Common Header>
                                   <KA Timer>
                                   [<ACCT Timer>]

   If the PDP refuses the client, it will instead respond with issue a Client-Close specifying
   message.

   The KA Timer corresponds to maximum acceptable intermediate time
   between the generation of messages by the client type is not supported, and
   possibly suggesting an alternate PDP address. Otherwise, and PEP. The timer
   value is determined by the PDP
   will specify taking into account the client's
   preference established with the OPN message. A timer interval between keep-alive messages in its
   Client-Accept and value of 0
   implies no secondary connection verification is necessary.

   The optional accounting timer allows the PDP to indicate to the PEP can begin issuing requests
   that periodic accounting reports should not exceed the specified
   timer interval. This allows the PDP to control the PDP.

   When rate at which
   accounting reports are sent by the PEP receives an event that requires a new policy decision
   it sends a request (when applicable).

3.8 Keep-Alive (KA)  PEP -> PDP, PDP -> PEP

   The keep-alive message only needs to be transmitted when there has
   been no activity between the remote PDP. The remote PDP then
   makes a decision client and sends server for a response back to period
   approaching half that of the PEP. Since minimum of all timer values negotiated
   with the
   request OPN & CAT messages. It is stateful, the request will be remembered, or installed,
   on a validation for each side that
   the remote PDP. connection is still functioning.

   Note: The unique handle, specified client-type in both the request
   and its corresponding response identifies this request state. The
   PEP header should always be set to 0 as the
   KA is responsible used for deleting this request state once connection verification (not per client session
   verification).

               <Keep-Alive>  ::= <Common Header>

   Both client and server may assume the request connection is no longer applicable.

   The PEP can update a previously installed request state by reissuing
   a request insufficient for
   the previously installed handle. The remote PDP is
   then expected to make new decisions and send a response back to the
   PEP. Likewise, client-type with the server may change a previously issued decision on
   any currently installed request state at any minimum time by issuing an
   asynchronous response. At all times value (specified in the PEP module CAT
   message) if no communication activity is expected to
   abide by detected for a period
   exceeding the PDP's decisions and notify timer period. For the PDP on state changes.

   The PEP may also notify PEP, such detection implies the
   remote PDP of or connection is down and the local status of PEP should now attempt to
   use an
   installed request using the report message where appropriate. alternative/backup PDP.

3.9 Client-Close (CC)  PEP -> PDP, PDP -> PEP

   The
   report Client-Close message is to can be used to signify when billing should
   effectively begin, issued by either the PDP or PEP to produce periodic updates for monitoring and
   accounting purposes depending on the client. This message can carry
   client specific information when needed.

   To validate the connection between
   notify the other that a particular type of client and server is still
   functioning, the keep-alive message is used. If no COPS message longer being
   supported.

               <Client-Close>  ::= <Common Header>
                                   [<Error>]
                                   [<PDPAddr>]

   An Error object is
   generated within one half optionally included to describe the minimum timer value interval, a keep-
   alive message needs reason for
   the close due to be generated. Both an error condition (e.g. requested client-type is
   not supported by the PEP and remote PDP are
   expected to follow this procedure.

   Finally, Client-Close messages are used or client failure).

   A PDP may optionally include a PDP-Address object in order to negate inform
   the affects PEP of the
   corresponding Client-Open messages, notifying the other side that alternate PDP it should use for the client-type
   specified client type is no longer supported/active.

5. Security in the common header.

3.10 Synchronize State Complete (SSC) PEP -> PDP

   The security of RSVP messages Synchronize State Complete is provided sent by inter-router MD5
   authentication [MD5].  This assumes a chain-of-trust model for inter the PEP authentication.  Security between to the client (PEP) PDP after
   the PDP sends a synchronize state request to the PEP and server
   (PDP) is provided by IPSEC [IPSEC].

   To ensure the client (PEP) PEP has
   finished synchronization. It is communicating with useful so that the correct policy
   server (PDP) involves two issues: authentication of PDP will know
   when all the policy old client state has been successfully re-requested
   and, thus, the PEP and server using a shared secret, and consistent proof that PDP are completely synchronized.

         <Synchronize State Complete>  ::= <Common Header>
   4. Common Operation

   This section describes the typical exchanges between remote PDP
   servers and PEP clients.

   Sometime after a connection remains valid. The shared secret requires manual
   configuration of keys, which is a maintenance issue. IPSEC AH may be
   used for the validation of established between the connection; IPSEC ESP may be used to
   provide both validation PEP and secrecy.

6. Open issues

   6.1 Bi-directional Connection Establishment:

   Currently, only a
   remote PDP, the PEP is supposed will send one or more Client-Open messages to connect with
   the PDP. It
   might be useful to have remote PDP, at least one for each client-type supported by the
   PEP. The open message should contain the common header noting one
   client-type supported by the PEP. The remote PDP proactive in establishing
   connections will then respond
   with its PEPs (via a separate COPS PEP port). Such would
   potentially simplify Client-Accept message echoing back each of the client-types
   the PEP configuration and allow a primary PDP that
   has failed to notify its clients supports that it is functional again. Such
   functionality can support as well. If a specific client-
   type is not supported by the PDP, the PDP will be specified in instead respond with
   a Client-Close specifying the appropriate COPS Extensions
   document. In client-type is not supported and will
   possibly suggest an alternate PDP address. Otherwise, the meantime, PEPs should at least be locally
   configured to connect PDP will
   specify the timer interval between keep-alive messages in its
   Client-Accept and the PEP can begin issuing its requests to their appropriate Primary PDP/Backup the PDP.

   6.2 RSVP Object Replacement:

   Should

   In the PDP be capable of directing outsourcing scenario, when the RSVP PEP receives an event that
   requires a new policy decision it sends a request message to replace other
   objects than the Policy Data object (e.g. FlowSpec)? If so, which
   RSVP objects and
   remote PDP. What specifically qualifies as an event for which request types?

   6.3 RSVP Policy Data Priority Element Definition.

   The object format of a particular
   client-type should be specified in the Policy Data Element specific document for Priority
   representation that
   client-type. The remote PDP then makes a decision and sends a
   decision message back to the PEP. Since the request is stateful, the
   request will be described remembered, or installed, on the remote PDP. The
   unique handle, specified in another document.

7. References

   [RSVP]  Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP)
           Version 1 - Functional Specification", RFC 2205, September
           1997.

   [WRK]   Yavatkar, R. et al., "A Framework for Policy-Based Admission
           Control", Internet-Draft, draft-ietf-rap-framework-00.txt,
           November 1997.

   [SRVLOC]Guttman, E. et al., "Service Location Protocol", Internet-
           Draft,  draft-ietf-svrloc-protocol-v2-01.txt, October 1997.

   [INSCH] Shenker, S., Wroclawski, J., "General Characterization
           Parameters for Integrated Service Network Elements", RFC
           2215, September 1997.

   [IPSEC] Atkinson, R., "Security Architecture both the request and its corresponding
   decision identifies this request state. The PEP is responsible for
   deleting this request state once the Internet
           Protocol", RFC1825, August 1995.

   [MD5]   Baker, F., "RSVP Cryptographic Authentication", Internet-
           Draft, draft-ietf-rsvp-md5-05.txt, August 1997.

   [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP)
           - Version 1 Message Processing Rules", RFC 2209, September
           1997.

   [UserID]Yadav, S., Pabbati, R., Ford, P., Herzog, S., "User Identity
           Representation request is no longer
   applicable.

   The PEP can update a previously installed request state by reissuing
   a request for RSVP", Internet-Draft, draft-ietf-rap-
           user-identity-00.txt, March 1998.

8. Author Information and Acknowledgments

   Special thanks the previously installed handle. The remote PDP is
   then expected to Timothy O'Malley our WG Chair, Raj Yavatkar,
   Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, make new decisions and Dimitrios Pendarakis for their valuable contributions.

       Jim Boyle                        Ron Cohen
       MCI                              Class Data Systems
       2100 Reston Parkway              13 Hasadna St.
       Reston, VA 20191                 Ra'anana 43650 Israel
       703.715.7006                     972.9.7462020
       jboyle@mci.net                   ronc@classdata.com

       David Durham                     Raju Rajan
       Intel                            IBM T.J. Watson Research Cntr
       2111 NE 25th Avenue              P.O. Box 704
       Hillsboro, OR 97124              Yorktown Heights, NY 10598
       503.264.6232                     914.784.7260
       David_Durham@mail.intel.com      raju@watson.ibm.com

       Shai Herzog                      Arun Sastry
       IPHighway                        Cisco Systems
       2055 Gateway Pl., Suite 400      506210 W Tasman Drive
       San Jose, CA 95110               San Jose, CA 95134
       408.390.3045                     408.526.7685
       herzog@iphighway.com             asastry@cisco.com
          Appendix A. COPS Extensions for Use with RSVP

A.1 Overview of COPS extensions for RSVP

   Building on send a decision message back
   to the foundations described in PEP. Likewise, the previous sections this
   section describes server may change a previously issued
   decision on any currently installed request state at any time by
   issuing another decision message. At all times the specific functionality required for this
   protocol PEP module is
   expected to support policy control over RSVP.

   Setting abide by the client type in PDP's decisions and notify the COPS common header to 1 indicates an
   RSVP client capable PDP of performing admission control and policy data
   substitution using RSVP V1 objects.

A.2 COPS objects for use with RSVP

   The COPS objects defined any
   state changes.

   Likewise, in section 2.2 are applicable the configuration scenario, the PEP will make a
   configuration request to RSVP
   policy control, and their use is described in the text PDP for a particular interface, module,
   or functionality that follows.

   The message type information found may be specified in the RSVP message header is
   represented by the M-Type in named client specific
   information object. The PDP will then send potentially several
   decisions containing named units of configuration data to the COPS Context Object.

   All objects contained within RSVP messaging are PEP.
   The PEP is expected to be
   encapsulated in install and use the Client Specific Information Object without
   alteration. Multiple RSVP objects may configuration locally. A
   particular named configuration can be contained within a single
   Client Specific Information Object exchanged between updated by simply sending
   additional decision messages for the PEP and
   remote PDP.

   In support of same named configuration. When
   the verification integrity of incoming RSVP messages, PDP no longer wishes the COPS protocol may optionally return PEP to use a security key in piece of configuration
   information, it will send a decision message specifying the Client
   Specific Decision Data named
   configuration and a decision flags object (C-Type = 4) useful for future
   integrity checks by with the PEP. Refer remove
   configuration flag set. The PEP should then proceed to remove the document on User Identity
   Representation for RSVP [UserID] for details on the format
   corresponding configuration and
   application of this security key when supported by the PEP.

   Finally, for the COPS outgoing send a report message responses, RSVP objects may
   be returned to the PDP
   that specifies it has been deleted.

   In all cases, the PEP from may notify the remote PDP via of the Replacement Data
   Decision Object. This object may contain multiple RSVP objects, but
   is primarily concerned with returning the Policy Data object.
   Objects included in the Replace Data Decision Object are to replace
   their corresponding object in the RSVP message (typically for
   outgoing RSVP messages).

A.3. Operation of COPS for Policy Control Over RSVP

A.3.1 RSVP values for the Context Object (Context)

   The semantics local status
   of an installed state using the Context object for RSVP is as follows:

   R-Type (Request Type Flag)

   0x01 = Incoming-Message request report message where appropriate.
   The arrival of an incoming RSVP report message

          Allows processing of incoming policy information as well as
          the decision whether to accept an incoming message. If It is
          rejected, to be used to signify when billing should
   begin, what actions were taken, or to produce periodic updates for
   monitoring and accounting purposes depending on the client. This
   message is treated as if it never Arrived.

   0x02 = Resource-Allocation request
          Applies only for Resv messages. can carry client specific information when needed.

   The decision whether keep-alive message is used to admit a reservation validate the connection between
   the client and commit local
          resources to it server is performed for still functioning when there is no other
   messaging between the merge of all
          reservations that arrived on a particular interface
          (potentially from several Previous Hops).

   0x04 = Outgoing-Message request
          The forwarding of an outgoing RSVP message. PEP and PDP. The Decision whether to allow the forwarding of an outgoing
          RSVP PEP must generate a COPS
   message as well as providing within one half the relevant outgoing
          policy information.

   M-Type (Message Type)

   The M-Type field in negotiated minimum timer interval or
   else a keep-alive message must be generated. Likewise, the Context Object may PDP must
   either have one of the
   Following values that correspond sent a COPS message to supported RSVP messages
   In COPS:

   1 = Path
   2 = Resv
   3 = PathErr
   4 = ResvErr

   Note: The PathTear, ResvTear, and every connected PEP within half
   the Resv Confirm negotiated minimum timer interval or a keep-alive must be
   issued. If either side does not receive a keep-alive or any other
   COPS message types within the negotiated timer interval from the other,
   the connection should be considered lost.

   Finally, Client-Close messages are
   not supported.

A.3.2 RSVP flows

   Policy Control is performed per RSVP flow. An RSVP flow corresponds used to an atomic unit negate the effects of reservation as identified by RSVP (TC
   reservation). It should be noted the
   corresponding Client-Open messages, notifying the other side that RSVP allows multiple flows to
   be packed (which
   the specified client-type is different from merged) into a single FF Resv
   message. To support such messages a separate COPS request must be
   issued for each no longer supported/active.

5. Security

   The security of the packed flows as if they were individual RSVP
   messages.

A.3.4 Expected Associations messages is provided by inter-router MD5
   authentication [MD5].  This assumes a chain-of-trust model for RSVP Requests

   RSVP signaling requires inter
   PEP authentication.  Security between the participation of both senders client (PEP) and
   receivers. RSVP processing rules define what server
   (PDP) is provided by IPSEC [IPSEC].

   To ensure the client (PEP) is communicating with the subset correct policy
   server (PDP) involves two issues: authentication of the
   Path state policy
   client and server using a shared secret, and consistent proof that matches each Resv state. In
   the common unicast case, connection remains valid. The shared secret requires manual
   configuration of keys, which is a maintenance issue. IPSEC AH may be
   used for the RSVP session includes one Path state and one Resv state. In
   multicast cases validation of the correspondence might connection; IPSEC ESP may be many to many. Since the
   decision used to admit a reservation for a session may depend on
   information carried
   provide both in Path validation and Resv messages, we term the Path
   States that match with a single Resv state as its associated states.
   It is assumed that the PDP is capable of determining these
   associations based on the RSVP message processing rules given the
   RSVP objects expressed in the COPS Client Specific Information
   Object.

A.3.5 RSVP's Capacity Admission Control: Commit and Delete

   In RSVP, the admission of a new reservation requires both an
   administrative approval (policy control) and capacity admission
   control. Once local admission control accepts the reservation, the
   PEP notifies the remote PDP by sending a report message specifying
   the Commit type. The Commit type report message is to be used to
   signify when billing should effectively begin, and performing
   heavier operations (e.g., debiting a credit card) is permissible.

   If instead a reservation approved by the PDP fails admission due to
   lack of resources, the PEP must notify the PDP by issuing a delete
   message.

A.3.6 Policy Control Over Path and Resv Tear

   Path and Resv Tear messages are not controlled by this policy
   architecture. This relies on two assumptions: First, that MD-5
   authentication verifies that the Tear is received from the same node
   that sent the initial reservation, and second, that it is
   functionally equivalent to that node holding-off refreshes for this
   reservation. When a Resv or Path Tear is received at the PEP, all
   affected states installed on the PDP should either be deleted or
   updated by the PEP.

A.3.7 PEP Caching COPS Decisions

   Because COPS is a stateful protocol, refreshes for RSVP Path and
   Resv messages need not be constantly sent to the remote PDP. Once a
   decision has been returned for a request, the PEP can cache that
   decision and apply it to future refreshes. The PEP is only
   responsible for updating a request state if there is a change
   detected in the corresponding Resv or Path message.

A.3.8 Data Expected in Request Messages for RSVP Support

   The information required in a RSVP request for each applicable
   message type and request type combination is outlined below:

       In, Path -
           <handle><context: in, Path><in-interface>
           <client info: all objects in Path message>
       Out, Path -
           <handle><context: out, Path><out-interface>
           <client info: all objects in outgoing Path message>
       In & Out (unicast combined request), Path -
           <handle><context: in & out, Path><in-interface>
           <out-interface>
           <client info: all objects in Path message>

       In, Resv -
           <handle><context: in, Resv><in-interface>
           <client info: all objects in Resv message>
       Merge, Resv -
           <handle><context: merge, Resv><in-interface>
           <client info: all objects in merged Resv message including
            the merged FLOWSPEC object>
       Out, Resv -
           <handle><context: out, Resv><out-interface>
           <client info: all objects in outgoing Resv message>
       In & Merge (combined request, PEP can merge), Resv -
           <handle><context: in & merge, Resv><in-interface>
           <client info: all objects in Resv message>
       In & Merge & Out (unicast combined request), Resv -
           <handle><context: in & merge & out, Resv><in-interface>
           <out-interface>
           <client info: all objects in Resv message>

       In, PathErr -
           <handle><context: in, PathErr><in-interface>
           <client info: all objects in PathErr message>
       Out, PathErr -
           <handle><context: out, PathErr><out-interface>
           <client info: all objects in outgoing PathErr message>
       In & Out (unicast combined request), PathErr -
           <handle><context: in & out, PathErr><in-interface>
           <out-interface>
           <client info: all objects in PathErr message>

       In, ResvErr -
           <handle><context: in, ResvErr><in-interface>
           <client info: all objects in ResvErr message>
       Out, ResvErr -
           <handle><context: out, ResvErr><out-interface>
           <client info: all objects in outgoing ResvErr message>
       In & Out (unicast combined request), ResvErr
           <handle><context: in & out, ResvErr><in-interface>
           <out-interface>
           <client info: all objects in ResvErr message>

A.3.9 Expected Decisions for RSVP Requests

   The expected decision information relative to a request for each
   applicable message type and request type combination is outlined
   below ([optional]):

       In, Path -
           <handle><Decision Flags>[<Decision Data: Security Key>]
       Out, Path -
           <handle><Decision Flags>[<DecisionReplacement: policy data>]
       In & Out (combined request), Path -
           <handle><Decision Flags>[<DecisionReplacement: policy data>]
          [<Decision Data: Security Key>]

       In, Resv -
           <handle><Decision Flags>[<Decision Data: Security Key>]
       Merge, Resv -
           <handle><Decision Flags>[<Decision Priority>]
       Out, Resv -
           <handle><Decision Flags>[<DecisionReplacement: policy data>]
       In & Merge (combined request, PEP can merge), Resv -
           <handle><Decision Flags>[<Decision Priority>][<Decision
           Data: Security Key>]
       In & Merge & Out (unicast combined request), Resv -
           <handle><Decision Flags>[<Decision Priority>]
           [<DecisionReplacement: policy data>][<Decision Data:
           Security Key>]

       In, PathErr -
           <handle><Decision Flags>
       Out, PathErr -
           <handle><Decision Flags>[<DecisionReplacement: policy data>]
       In & Out (combined request), PathErr -
           <handle><Decision Flags>[<DecisionReplacement: policy data>]

       In, ResvErr -
           <handle><Decision Flags>
       Out, ResvErr -
           <handle><Decision Flags>[<DecisionReplacement: policy data>]
       In & Out (combined request), ResvErr -
           <handle><Decision Flags>[<DecisionReplacement: policy data>]

A.4 Illustrative Examples, Using COPS for RSVP

A.4.1 Unicast Flow Example

   This section details the steps in using COPS for controlling a
   Unicast RSVP flow. It details the contents of the COPS messages
   with respect to the following figure.

                                    PEP (router)
                                 +-----------------+
                                 |                 |
                  R1 ------------+if1           if3+------------ S1
                                 |       if2       |
                                 +--------+--------+
                                          |
                                          |
                                         PDP (server)

                    figure 1: Unicast Example: a single router view

   The PEP router has three interfaces (1,2,3). Sender S1 sends to
   receiver R1.

   A Path message arrives from S1:

          PEP --> PDP   REQ := <Handle A><Context in&out, Path>
                               <In-Interface if3> <Out-Interface if1>
                               <ClientSI: all objects in Path message>

          PDP --> PEP   RES := <Handle A><Decision accept>

   A Resv message arrives from R1:

          PEP --> PDP   REQ := <Handle B><Context in&merge&out, Resv>
                               <In-Interface if1> <Out-Interface if3>
                               <ClientSI: all objects in Resv message>

          PDP --> PEP   RES := <Handle B>
                               <Decisions: accept, Priority=7,
                                Replace: POLICY.DATA1>

          PEP --> PDP   RPT := <Handle B>
                               <Report type: commit>

   Time Passes, the PDP changes its decision:

          PDP --> PEP   USR := <Handle B>
                               <Decisions: accept, Priority=3,
                                Replace: POLICY.DATA2>

   Because the priority is too low, the PEP preempts the flow:

          PEP --> PDP   DRQ := <Handle B>
                               <Reason Code: Preempted>

   Time Passes, the sender S1 ceases to send Path messages:

          PEP --> PDP   DRQ := <Handle A>
                               <Reason: Timeout>

A.4.2 Shared Multicast Flows

   This section details the steps in using COPS for controlling a
   multicast RSVP flow. It details the contents of the COPS messages
   with respect to the following figure.

                               -----------------
                     r1       |                 |
               H1-------------|i1               |      r4
                              |              o1 |---------------- S1
                     r2       |     Router      |
               H2 ------------|i2               |
                     |        |              o2 |---------------- S2
                     | r3     |                 |
                     |         -----------------
                    H3

                figure 1: 2 senders and 3 receivers

   Figure 1 shows an RSVP router which has two senders and three
   receivers for the same multicast session. Interface i2 is connected
   to a shared media.

   First detailed is the request message content for a Path sent by
   sender S1, assuming that both receivers have already joined the
   multicast session, but haven't sent a Resv message as yet. Assume
   sender S2 has not yet sent a path message. The Path message arrives
   on interface o1:

       PEP -----> PDP    REQ   := <handle A><context in, Path>
                                  <in-interface o1><client info: all
                                  objects in Path message>
       PDP -----> PEP    RES   := <handle A><Decision accept>

   Here the PDP decides to allow the Path message. Next, the Router
   consults its forwarding table, and finds two outgoing  interfaces,
   i1 and i2, for the path. The exchange below is for interface i1,
   another exchange would likewise be completed for i2 using the new
   handle B2.

       PEP -----> PDP    REQ   := <handle B1><context out, Path>
                                  <out-interface i1><client info: all
                                  objects in outgoing Path message>
       PDP -----> PEP    RES   := <handle B1><Decision forward>
                                  <Decision replacement object:
                                   policy object>

   Here, the PDP decided to allow the forwarding of the Path message
   via interface i1, and determined the appropriate policy objects for
   the message going out on this interface.

   Next, the receiver r2 sends a Resv message of WF style. The Resv
   arrives on interface i2. Here the PEP queries the PDP which decides
   to accept this reservation with priority 5 as shown below.

       PEP -----> PDP    REQ   := <handle C><context in, Resv>
                                  <in-interface i2><client info: all
                                  objects in Resv message>
       PDP -----> PEP    RES   := <handle C><Decision accept>

   This assumes the PEP is not itself capable of merging priority
   information, and, thus, must make another query for the incoming
   interface merge.

       PEP -----> PDP    REQ   := <handle D><context merge, Resv>
                                  <in-interface i2><client info: all
                                  objects in merged Resv message>
       PDP -----> PEP    RES   := <handle D><Decision Priority: 5>

   After PEP successfully admitted the reservation it sends a report
   message that signals to the PDP that it can start an accounting log
   for this reservation.

       PEP -----> PDP    RPT   := <handle D>
                                  <commit>

   The reservation r2 needs to be sent upstream towards sender S1 out
   interface o1. An outgoing Resv request is made which carries the
   associated handle of the Path message for which this Resv is being
   forwarded.

       PEP -----> PDP    REQ   := <handle E><context out,Resv>
                                  <out-interface o1><client info: all
                                  objects in outgoing Resv message>
       PDP -----> PEP    RES   := <handle E><Decision forward><Decision
                                  replacement object: policy object>

   Next, receiver H3 sends the Resv message r3. The PEP sends an
   incoming request for handle F and the PDP decides to accept the Resv
   (as before). The new reservation also requires the PEP to update the
   merged request (handle D) due to the modified flowspec. The PDP now
   gives this request priority secrecy.

6. Open issues

7. If accepted by local admission
   control, a report is again sent.

       PEP -----> PDP    REQ   := <handle D><context merge, Resv>
                                  <in-interface i2><client info: all
                                  objects in merged Resv message w/
                                  new merged FLOWSPEC>
       PDP -----> PEP    RES   := <handle D><Decision priority 7>
       PEP -----> PDP    RPT   := <handle D>
                                  <commit>

   Now the outgoing request References

   [RSVP]  Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP)
           Version 1 - Functional Specification", RFC 2205, September
           1997.

   [WRK]   Yavatkar, R. et al., "A Framework for Policy-Based Admission
           Control", Internet-Draft, draft-ietf-rap-framework-00.txt,
           November 1997.

   [SRVLOC]Guttman, E. et al., "Service Location Protocol", Internet-
           Draft,  draft-ietf-svrloc-protocol-v2-01.txt, October 1997.

   [INSCH] Shenker, S., Wroclawski, J., "General Characterization
           Parameters for handle E is reissued Integrated Service Network Elements", RFC
           2215, September 1997.

   [IPSEC] Atkinson, R., "Security Architecture for the merged (R2
   & R3) outgoing Resv to be sent towards sender S1 due Internet
           Protocol", RFC1825, August 1995.

   [MD5]   Baker, F., "RSVP Cryptographic Authentication", Internet-
           Draft, draft-ietf-rsvp-md5-05.txt, August 1997.

   [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP)
           - Version 1 Message Processing Rules", RFC 2209, September
           1997.

   [UserID]Yadav, S., Pabbati, R., Ford, P., Herzog, S., "User Identity
           Representation for RSVP", Internet-Draft, draft-ietf-rap-
           user-identity-00.txt, March 1998.

8. Author Information and Acknowledgments

   Special thanks to a modified
   flowspec.

       PEP -----> PDP    REQ   := <handle E><context out,Resv>
                                  <out-interface o1><client info: all
                                  objects in outgoing Resv message w/
                                  new merged FLOWSPEC>
       PDP -----> PEP    RES   := <handle E><Decision forward><Decision
                                  replacement object: policy object>

   When S2 joins the session by sending a Path message, incoming Timothy O'Malley our WG Chair, Raj Yavatkar,
   Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan,
   and
   outgoing Path requests are issued for the new Path. The two incoming
   Resv requests may then be reissued Dimitrios Pendarakis for handle C and handle E if
   there is a change in their shared sender filter list (for SE
   filters) specifying the new sender. A new outgoing Resv request
   would then be issued for the Resv to be sent to s2 out interface o2. valuable contributions.

       Jim Boyle                        Ron Cohen
       Level 3 Communications           Cisco Systems
       1450 Infinite Drive13            Hasadna St.
       Louisville, CO 80027             Ra'anana 43650 Israel
       303.926.3100                     972.9.7462020
       email: jboyle@l3.net             ronc@classdata.com

       David Durham                     Raju Rajan
       Intel                            IBM T.J. Watson Research Cntr
       2111 NE 25th Avenue              P.O. Box 704
       Hillsboro, OR 97124              Yorktown Heights, NY 10598
       503.264.6232                     914.784.7260
       David_Durham@mail.intel.com      raju@watson.ibm.com

       Shai Herzog                      Arun Sastry
       IPHighway                        Cisco Systems
       2055 Gateway Pl., Suite 400      506210 W Tasman Drive
       San Jose, CA 95110               San Jose, CA 95134
       408.390.3045                     408.526.7685
       herzog@iphighway.com             asastry@cisco.com