rfc2748.txt

RFC 的详细文档！

   <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
   the PDP's state will be able to accurately mirror the PEP's state.
























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


   The format of the Request message is as follows:

               <Request Message> ::=  <Common Header>
                                      <Client Handle>
                                      <Context>
                                      [<IN-Int>]
                                      [<OUT-Int>]
                                      [<ClientSI(s)>]
                                      [<LPDPDecision(s)>]
                                      [<Integrity>]

               <ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>

               <LPDPDecision(s)> ::= <LPDPDecision> |
                                     <LPDPDecision(s)> <LPDPDecision>

               <LPDPDecision> ::= [<Context>]
                                  <LPDPDecision: Flags>
                                  [<LPDPDecision: Stateless Data>]
                                  [<LPDPDecision: Replacement Data>]
                                  [<LPDPDecision: ClientSI Data>]
                                  [<LPDPDecision: Named Data>]


   The context object is used to determine the context within which all
   the other objects are to be interpreted. It also is used to determine
   the kind of decision to be returned from the 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 signaling protocol message was received or is
   about to be sent. They are typically used if the client is
   participating along the path of a signaling protocol or if the client
   is requesting configuration data for a particular interface.

   ClientSI, the client specific information object, holds the client-
   type specific data for which a policy decision needs to be made. In
   the case of configuration, the Named ClientSI may include named
   information about the module, interface, or functionality to be
   configured. The ordering of multiple ClientSIs is not important.

   Finally, LPDPDecision object holds information regarding the local
   decision made by the LPDP.

   Malformed Request messages MUST result in the PDP specifying a
   Decision message with the appropriate error code.




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


3.2 Decision (DEC)  PDP -> PEP

   The PDP responds to the REQ with a DEC message that includes the
   associated client handle and one or more decision objects grouped
   relative to a Context object and Decision Flags object type pair. If
   there was a protocol error an error object is returned instead.

   It is required that the first decision message for a new/updated
   request will have the solicited message flag set (value = 1) in the
   COPS header. 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, there be at most one outstanding solicited decision per
   request. This essentially means that the PEP SHOULD NOT issue more
   than one REQ (for a given handle) before it receives a corresponding
   DEC with the solicited message flag set. The PDP MUST always issue
   decisions for requests on a particular handle in the order they
   arrive and all requests MUST have a corresponding decision.

   To avoid deadlock, the PEP can always timeout after issuing a request
   that does not receive a decision. It MUST then delete the timed-out
   handle, and may try again using a new handle.

   The format of the Decision message is as follows:

               <Decision Message> ::= <Common Header>
                                      <Client Handle>
                                      <Decision(s)> | <Error>
                                      [<Integrity>]

               <Decision(s)> ::= <Decision> | <Decision(s)> <Decision>

               <Decision> ::= <Context>
                              <Decision: Flags>
                              [<Decision: Stateless Data>]
                              [<Decision: Replacement Data>]
                              [<Decision: ClientSI Data>]
                              [<Decision: Named Data>]

   The Decision message may include either an Error object or one or
   more context plus associated decision objects. COPS protocol problems
   are reported in the Error object (e.g. an error with the format of
   the original request including malformed request messages, unknown
   COPS objects in the Request, etc.). The applicable Decision object(s)
   depend on the context and the type of client. The only ordering
   requirement for decision objects is that the required Decision Flags
   object type MUST precede the other Decision object types per context
   binding.



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


3.3 Report State (RPT)  PEP -> PDP

   The RPT message is used by the PEP to communicate to the PDP its
   success or failure in carrying out the PDP's decision, or to report
   an accounting related change in state. The Report-Type specifies the
   kind of report and the optional ClientSI can carry additional
   information per Client-Type.

   For every DEC message containing a configuration context that is
   received by a PEP, the PEP MUST generate a corresponding Report State
   message with the Solicited Message flag set describing its success or
   failure in applying the configuration decision. In addition,
   outsourcing decisions from the PDP MAY result in a corresponding
   solicited Report State from the PEP depending on the context and the
   type of client. RPT messages solicited by decisions for a given
   Client Handle MUST set the Solicited Message flag and MUST be sent in
   the same order as their corresponding Decision messages were
   received. There MUST never be more than one Report State message
   generated with the Solicited Message flag set per Decision.

   The Report State may also be used to provide periodic updates of
   client specific information for accounting and state monitoring
   purposes depending on the type of the client. In such cases the
   accounting report type should be specified utilizing the appropriate
   client specific information object.

              <Report State> ::== <Common Header>
                                  <Client Handle>
                                  <Report-Type>
                                  [<ClientSI>]
                                  [<Integrity>]

3.4 Delete Request State (DRQ)  PEP -> PDP

   When sent from the PEP this message indicates to the remote PDP that
   the state identified by the client handle is no longer
   available/relevant. This information will then be used by the remote
   PDP to initiate the appropriate housekeeping actions. The reason code
   object is interpreted with respect to the client-type and signifies
   the reason for the removal.

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

              <Delete Request>  ::= <Common Header>
                                    <Client Handle>
                                    <Reason>
                                    [<Integrity>]




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


   Given the stateful nature of COPS, it is important that when a
   request state is finally removed from the PEP, a DRQ message for this
   request state is sent to the PDP so the corresponding state may
   likewise be removed on the PDP. Request states not explicitly deleted
   by the PEP will be maintained by the PDP until either the client
   session is closed or the connection is terminated.

   Malformed Decision messages MUST trigger a DRQ specifying the
   appropriate erroneous reason code (Bad Message Format) and any
   associated state on the PEP SHOULD either be removed or re-requested.
   If a Decision contained an unknown COPS Decision Object, the PEP MUST
   delete its request specifying the Unknown COPS Object reason code
   because the PEP will be unable to comply with the information
   contained in the unknown object. In any case, after issuing a DRQ,
   the PEP may retry the corresponding Request again.

3.5 Synchronize State Request (SSQ)  PDP -> PEP

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

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

   This message indicates that the remote PDP wishes the client (which
   appears in the common header) to re-send its state. If the optional
   Client Handle is present, only the state associated with this handle
   is synchronized. If the PEP does not recognize the requested handle,
   it MUST immediately send a DRQ message to the PDP for the handle that
   was specified in the SSQ message. If no handle is specified in the
   SSQ message, all the active client state MUST be synchronized with
   the PDP.

   The client performs state synchronization by re-issuing request
   queries of the specified client-type for the existing state in the
   PEP. When synchronization is complete, the PEP MUST issue a
   synchronize state complete message to the PDP.

3.6 Client-Open (OPN)  PEP -> PDP

   The Client-Open message can be used by the PEP to specify to the PDP
   the client-types the PEP can support, the last PDP to which the PEP
   connected for the given client-type, and/or client 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).





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


        <Client-Open>  ::= <Common Header>
                           <PEPID>
                           [<ClientSI>]
                           [<LastPDPAddr>]
                           [<Integrity>]

   The PEPID is a symbolic, variable length name that uniquely
   identifies the specific client to the PDP (see Section 2.2.11).

   A named ClientSI object can be included for relaying additional
   global information about the PEP to the PDP when required (as
   specified in the appropriate extensions document for the client-
   type).

   The PEP may also provide a Last PDP Address object in its Client-Open
   message specifying the last PDP (for the given client-