rfc2748.txt

中、英文RFC文档大全打包下载完全版 .

       +--------------+--------------+--------------+--------------+
       |                   IPv4 Address format                     |
       +--------------+--------------+--------------+--------------+
       |  /////////////////////////  |       TCP Port Number       |
       +-----------------------------+-----------------------------+

       C-Type = 2, IPv6 Address + TCP Port
                0             1              2             3
       +--------------+--------------+--------------+--------------+
       |                                                           |
       +                                                           +
       |                                                           |
       +                    IPv6 Address format                    +
       |                                                           |
       +                                                           +
       |                                                           |
       +--------------+--------------+--------------+--------------+
       |  /////////////////////////  |       TCP Port Number       |
       +-----------------------------+-----------------------------+

2.2.14 Last PDP Address (LastPDPAddr)

   When a PEP sends a Client-Open message for a particular client-type
   the PEP SHOULD specify the last PDP it has successfully opened
   (meaning it received a Client-Accept) since the PEP last rebooted.
   If no PDP was used since the last reboot, the PEP will simply not
   include this object in the Client-Open message.

       C-Num = 14,

       C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)

       C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)

2.2.15 Accounting Timer Object (AcctTimer)

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

           C-Num = 15,

           C-Type = 1, Accounting timer value





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


   Optional timer value used to determine the minimum interval between
   periodic accounting type reports. It is used by the PDP to describe
   to the PEP an acceptable interval between unsolicited accounting
   updates via Report messages where applicable. It provides a method
   for the PDP to control the amount of accounting traffic seen by the
   network. The range of finite time values is 1 to 65535 seconds
   represented as an unsigned two-octet integer. A value of zero means
   there SHOULD be no unsolicited accounting updates.

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

2.2.16 Message Integrity Object (Integrity)

   The integrity object includes a sequence number and a message digest
   useful for authenticating and validating the integrity of a COPS
   message. When used, integrity is provided at the end of a COPS
   message as the last COPS object. The digest is then computed over all
   of a particular COPS message up to but not including the digest value
   itself. The sender of a COPS message will compute and fill in the
   digest portion of the Integrity object. The receiver of a COPS
   message will then compute a digest over the received message and
   verify it matches the digest in the received Integrity object.

           C-Num = 16,

           C-Type = 1, HMAC digest

   The HMAC integrity object employs HMAC (Keyed-Hashing for Message
   Authentication) [HMAC] to calculate the message digest based on a key
   shared between the PEP and its PDP.

   This Integrity object specifies a 32-bit Key ID used to identify a
   specific key shared between a particular PEP and its PDP and the
   cryptographic algorithm to be used. The Key ID allows for multiple
   simultaneous keys to exist on the PEP with corresponding keys on the
   PDP for the given PEPID. The key identified by the Key ID was used to
   compute the message digest in the Integrity object. All
   implementations, at a minimum, MUST support HMAC-MD5-96, which is
   HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to
   96-bits to calculate the message digest.

   This object also includes a sequence number that is a 32-bit unsigned
   integer used to avoid replay attacks. The sequence number is
   initiated during an initial Client-Open Client-Accept message
   exchange and is then incremented by one each time a new message is



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


   sent over the TCP connection in the same direction. If the sequence
   number reaches the value of 0xFFFFFFFF, the next increment will
   simply rollover to a value of zero.

   The variable length digest is calculated over a COPS message starting
   with the COPS Header up to the Integrity Object (which MUST be the
   last object in a COPS message) INCLUDING the Integrity object's
   header, Key ID, and Sequence Number. The Keyed Message Digest field
   is not included as part of the digest calculation. In the case of
   HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then to
   be truncated to 96-bits before being stored in or verified against
   the Keyed Message Digest field as specified in [HMAC]. The Keyed
   Message Digest MUST be 96-bits when HMAC-MD5-96 is used.

             0             1              2             3
       +-------------+-------------+-------------+-------------+
       |                        Key ID                         |
       +-------------+-------------+-------------+-------------+
       |                    Sequence Number                    |
       +-------------+-------------+-------------+-------------+
       |                                                       |
       +                                                       +
       |               ...Keyed Message Digest...              |
       +                                                       +
       |                                                       |
       +-------------+-------------+-------------+-------------+

2.3 Communication

   The COPS protocol uses a single persistent TCP connection between the
   PEP and a remote PDP. One PDP implementation per server MUST listen
   on a well-known TCP port number (COPS=3288 [IANA]). The PEP is
   responsible for initiating the TCP connection to a PDP. 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.

   If a single PEP can support multiple client-types, it may send
   multiple Client-Open messages, each specifying a particular client-
   type to a PDP over one or more TCP connections. Likewise, a PDP
   residing at a given address and port number may support one or more
   client-types. Given the client-types it supports, a PDP has the
   ability to either accept or reject each client-type independently.
   If a client-type is rejected, the PDP can redirect the PEP to an
   alternative PDP address and TCP port for a given client-type via
   COPS.  Different TCP port numbers can be used to redirect the PEP to
   another PDP implementation running on the same server. Additional
   provisions for supporting multiple client-types (perhaps from



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


   independent PDP vendors) on a single remote PDP server are not
   provided by the COPS protocol, but, rather, are left to the software
   architecture of the given server platform.

   It is possible a single PEP may have open connections to multiple
   PDPs. This is the case when there are physically different PDPs
   supporting different client-types as shown in figure 2.

       +----------------+
       |                |
       |  Network Node  |                  Policy Servers
       |                |
       |   +-----+      | COPS Client Type 1  +-----+
       |   |     |<-----|-------------------->| PDP1|
       |   + PEP +      | COPS Client Type 2  +-----+
       |   |     |<-----|---------\           +-----+
       |   +-----+      |          \----------| PDP2|
       |    ^           |                     +-----+
       |    |           |
       |    \-->+-----+ |
       |        | LPDP| |
       |        +-----+ |
       |                |
       +----------------+

       Figure 2: Multiple PDPs illustration.

   When a TCP connection is torn down or is lost, the PDP is expected to
   eventually clean up any outstanding request state related to
   request/decision exchanges with the PEP. When the PEP detects a lost
   connection due to a timeout condition it SHOULD explicitly send a
   Client-Close message for each opened client-type containing an
   <Error> object indicating the "Communication Failure" Error-Code.
   Additionally, the PEP SHOULD continuously attempt to contact the
   primary PDP or, if unsuccessful, any known backup PDPs. Specifically
   the PEP SHOULD keep trying all relevant PDPs with which it has been
   configured until it can establish a connection. If a PEP is in
   communication with a backup PDP and the primary PDP becomes
   available, the backup PDP is responsible for redirecting the PEP back
   to the primary PDP (via a <Client-Close> message containing a
   <PDPRedirAddr> object identifying the primary PDP to use for each
   affected client-type). Section 2.5 details synchronization behavior
   between PEPs and PDPs.








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


2.4 Client Handle Usage

   The client handle is used to identify a unique request state for a
   single PEP per client-type. Client handles are chosen by the PEP and
   are opaque to the PDP. The PDP simply uses the request handle to
   uniquely identify the request state for a particular Client-Type over
   a particular TCP connection and generically tie its decisions to a
   corresponding request. Client handles are initiated in request
   messages and are then used by subsequent request, decision, and
   report messages to reference the same request state. When the PEP is
   ready to remove a local request state, it will issue a delete message
   to the PDP for the corresponding client handle. A handle MUST be
   explicitly deleted by the PEP before it can be used by the PEP to
   identify a new request state. Handles referring to different request
   states MUST be unique within the context of a particular TCP
   connection and client-type.

2.5 Synchronization Behavior

   When disconnected from a PDP, 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 have passed local admission
   control. Additionally, the remote PDP may request that all the PEP's
   internal state be resynchronized (all previously installed requests
   are to be reissued) by sending a Synchronize State message.

   After a failure and before a 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 appropriate
   length of time. Specific rules for such behavior are to be defined in
   the appropriate COPS client-type extension specifications.

   A PEP that caches state from a previous exchange with a disconnected
   PDP MUST communicate this fact to any PDP with which it is able to
   later reconnect. This is accomplished by including the address and
   TCP port of the last PDP for which the PEP is still caching state in
   the Client-Open message. The <LastPDPAddr> object will only be
   included for the last PDP with which the PEP was completely in sync.
   If the service interruption was temporary and the PDP still contains
   the complete state for the PEP, the PDP may choose not to synchronize
   all states. It is still the responsibility of the PEP to update the
   PDP of all state changes that occurred during the disruption of
   service including any states communicated to the previous PDP that
   had been deleted after the connection was lost.  These MUST be
   explicitly deleted after a connection is reestablished. If the PDP
   issues a synchronize request the PEP MUST pass all current states to
   the PDP followed by a Synchronize State Complete message (thus




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


   completing the synchronization process). If the PEP crashes and loses
   all cached state for a client-type, it will simply not include a
   <LastPDPAddr> in its Client-Open message.

3. Message Content

   This section describes the basic messages exchanged between a PEP and
   a remote PDP as well as their contents. As a convention, object
   ordering is expected as shown in the BNF for each COPS message unless
   otherwise noted. The Integrity object, if included, MUST always be
   the last object in a message. If security is required and a message
   was received without a valid Integrity object, the receiver MUST send
   a Client-Close message for Client-Type=0 specifying the appropriate
   error code.

3.1 Request (REQ)  PEP -> PDP

   The PEP establishes a request state client handle for which the
   remote PDP may maintain state. The remote PDP then uses this handle
   to refer to the exchanged information and decisions communicated over
   the TCP connection to a particular PEP for a given client-type.

   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