rfc2748.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   or attempt to connect to a backup/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 deleted state or new 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. Sections
   2.3 and 2.5 detail COPS mechanisms for achieving reliability.

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| Flags|    Op Code   |       Client-type           |
     +--------------+--------------+--------------+--------------+
     |                      Message Length                       |
     +--------------+--------------+--------------+--------------+

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





Durham, et al.              Standards Track                     [Page 6]

RFC 2748                          COPS                      January 2000


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

         Flags: 4 bits
             Defined flag values (all other flags MUST be set to 0):
               0x1 Solicited Message Flag Bit
                This flag is set when the message is solicited by
                another COPS message. This flag is NOT to be set
                (value=0) unless otherwise specified in section 3.

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

       Client-type: 16 bits

        The Client-type identifies the policy client. Interpretation of
        all encapsulated objects is relative to the 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 the specific client usage documents for particular
        client-type IDs). For KA Messages, the client-type in the header
        MUST always be set to 0 as the KA is used for connection
        verification (not per client session verification).

        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.












Durham, et al.              Standards Track                     [Page 7]

RFC 2748                          COPS                      January 2000


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 header, using the
   following format:

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

   The length is a two-octet value that describes the number of octets
   (including the header) that compose the object. If the 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 next 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  = Context
               3  = In Interface
               4  = Out Interface
               5  = Reason code
               6  = Decision
               7  = LPDP Decision
               8  = Error
               9  = Client Specific Info
               10 = Keep-Alive Timer
               11 = PEP Identification
               12 = Report Type
               13 = PDP Redirect Address
               14 = Last PDP Address
               15 = Accounting Timer
               16 = Message Integrity

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




Durham, et al.              Standards Track                     [Page 8]

RFC 2748                          COPS                      January 2000


2.2.1 Handle Object (Handle)

   The Handle Object encapsulates a unique value that identifies an
   installed state. This identification is used by most COPS operations.
   A state corresponding to a handle MUST be explicitly deleted when it
   is no longer applicable. See Section 2.4 for details.

           C-Num = 1

           C-Type = 1, Client Handle.

   Variable-length field, no implied format other than it is unique from
   other client handles from the same PEP (a.k.a. COPS TCP connection)
   for a particular client-type. It is always initially chosen by the
   PEP and then deleted by the PEP when no longer applicable. The client
   handle is used to refer to a request state initiated by a particular
   PEP and installed at the PDP for a client-type. 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 a particular PEP's request for a client-type.

   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 of other currently
   installed requests.

2.2.2 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 = 2, C-Type = 1








Durham, et al.              Standards Track                     [Page 9]

RFC 2748                          COPS                      January 2000


              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.3 In-Interface Object (IN-Int)

   The In-Interface Object is used to identify the incoming interface on
   which a particular request applies and the address where the received
   message originated. For flows or messages generated from the PEP's
   local host, the loop back address and ifindex are used.

   This Interface object is also used to identify the incoming
   (receiving) interface via its ifindex. The ifindex may be used to
   differentiate between sub-interfaces and unnumbered interfaces (see
   RSVP's LIH for an example). When SNMP is supported by the PEP, this
   ifindex integer MUST correspond to the same integer value for the
   interface in the SNMP MIB-II interface index table.

   Note: The ifindex specified in the In-Interface is typically relative
   to the flow of the underlying protocol messages. The ifindex is the
   interface on which the protocol message was received.

           C-Num = 3

           C-Type = 1, IPv4 Address + Interface

               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |                   IPv4 Address format                     |
       +--------------+--------------+--------------+--------------+
       |                          ifindex                          |
       +--------------+--------------+--------------+--------------+

   For this type of the interface object, the IPv4 address specifies the
   IP address that the incoming message came from.




Durham, et al.              Standards Track                    [Page 10]

RFC 2748                          COPS                      January 2000


           C-Type = 2, IPv6 Address + Interface

               0             1              2             3
       +--------------+--------------+--------------+--------------+
       |                                                           |
       +                                                           +
       |                                                           |
       +                    IPv6 Address format                    +
       |                                                           |
       +                                                           +
       |                                                           |
       +--------------+--------------+--------------+--------------+
       |                          ifindex                          |
       +--------------+--------------+--------------+--------------+

   For this type of the interface object, the IPv6 address specifies the
   IP address that the incoming message came from. The ifindex is used
   to refer to the MIB-II defined local incoming interface on the PEP as
   described above.

2.2.4 Out-Interface Object (OUT-Int)

   The Out-Interface is used to identify the outgoing interface to which
   a specific request applies and the address for where the forwarded
   message is to be sent. For flows or messages destined to the PEP's
   local host, the loop back address and ifindex are used.  The Out-
   Interface has the same formats as the In-Interface Object.

   This Interface object is also used to identify the outgoing
   (forwarding) interface via its ifindex. The ifindex may be used to
   differentiate between sub-interfaces and unnumbered interfaces (see
   RSVP's LIH for an example). When SNMP is supported by the PEP, this
   ifindex integer MUST correspond to the same integer value for the
   interface in the SNMP MIB-II interface index table.

   Note: The ifindex specified in the Out-Interface is typically
   relative to the flow of the underlying protocol messages. The ifindex
   is the one on which a protocol message is about to be forwarded.