rfc2753.txt

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

Yavatkar, et al.             Informational                      [Page 5]

RFC 2753      Framework for Policy-based Admission Control  January 2000


   may reside at a policy server.  The PEP represents the component that
   always runs on the policy aware node. It is the point at which policy
   decisions are actually enforced. Policy decisions are made primarily
   at the PDP. The PDP itself may make use of additional mechanisms and
   protocols to achieve additional functionality such as user
   authentication, accounting, policy information storage, etc. For
   example, the PDP is likely to use an LDAP-based directory service for
   storage and retrieval of policy information[6]. This document does
   not include discussion of these additional mechanisms and protocols
   and how they are used.

   The basic interaction between the components begins with the PEP. The
   PEP will receive a notification or a message that requires a policy
   decision.  Given such an event, the PEP then formulates a request for
   a policy decision and sends it to the PDP.  The request for policy
   control from a PEP to the PDP may contain one or more policy elements
   (encapsulated into one or more policy objects) in addition to the
   admission control information (such as a flowspec or amount of
   bandwidth requested) in the original message or event that triggered
   the policy decision request.  The PDP returns the policy decision and
   the PEP then enforces the policy decision by appropriately accepting
   or denying the request.  The PDP may also return additional
   information to the PEP which includes one or more policy elements.
   This information need not be associated with an admission control
   decision. Rather, it can be used to formulate an error message or
   outgoing/forwarded message.

 ________________         Policy server
|                |        ______
|  Network Node  |        |     |------------->
|    _____       |        |     |   May use LDAP,SNMP,.. for accessing
|   |     |      |        |     |  policy database, authentication,etc.
|   | PEP |<-----|------->| PDP |------------->
|   |_____|      |        |_____|
|                |
|________________|

   Figure 1: A simple configuration with the primary policy control
   architecture components. PDP may use additional mechanisms and
   protocols for the purpose of accounting, authentication, policy
   storage, etc.

   The PDP might optionally contact other external servers, e.g., for
   accessing configuration, user authentication, accounting and billing
   databases. Protocols defined for network management (SNMP) or
   directory access (LDAP) might be used for this communication. While
   the specific type of access and the protocols used may vary among




Yavatkar, et al.             Informational                      [Page 6]

RFC 2753      Framework for Policy-based Admission Control  January 2000


   different implementations, some of these interactions will have
   network-wide implications and could impact the interoperability of
   different devices.

   Of particular importance is the "language" used to specify the
   policies implemented by the PDP. The number of policies applicable at
   a network node might potentially be quite large. At the same time,
   these policies will exhibit high complexity, in terms of number of
   fields used to arrive at a decision, and the wide range of decisions.
   Furthermore, it is likely that several policies could be applicable
   to the same request profile. For example, a policy may prescribe the
   treatment of requests from a general user group (e.g., employees of a
   company) as well as the treatment of requests from specific members
   of that group (e.g., managers of the company). In this example, the
   user profile "managers" falls within the specification of two
   policies, one general and one more specific.

   In order to handle the complexity of policy decisions and to ensure a
   coherent and consistent application of policies network-wide, the
   policy specification language should ensure unambiguous mapping of a
   request profile to a policy action. It should also permit the
   specification of the sequence in which different policy rules should
   be applied and/or the priority associated with each one. Some of
   these issues are addressed in [6].

   In some cases, the simple configuration shown in Figure 1 may not be
   sufficient as it might be necessary to apply local policies (e.g.,
   policies specified in access control lists) in addition to the
   policies applied at the remote PDP. In addition, it is possible for
   the PDP to be co-located with the PEP at the same network node.
   Figure 2 shows the possible configurations.

   The configurations shown in Figures 1 and 2 illustrate the
   flexibility in division of labor. On one hand, a centralized policy
   server, which could be responsible for policy decisions on behalf of
   multiple network nodes in an administrative domain, might be
   implementing policies of a wide scope, common across the AD. On the
   other hand, policies which depend on information and conditions local
   to a particular router and which are more dynamic, might be better
   implemented locally, at the router.











Yavatkar, et al.             Informational                      [Page 7]

RFC 2753      Framework for Policy-based Admission Control  January 2000


    ________________                        ____________________
   |                |                      |                    |
   |  Network Node  |  Policy Server       |    Network Node    |
   |    _____       |      _____           |  _____      _____  |
   |   |     |      |     |     |          | |     |    |     | |
   |   | PEP |<-----|---->| PDP |          | | PEP |<-->| PDP | |
   |   |_____|      |     |_____|          | |_____|    |_____| |
   |    ^           |                      |                    |
   |    |    _____  |                      |____________________|
   |    \-->|     | |
   |        | LPDP| |
   |        |_____| |
   |                |
   |________________|

   Figure 2: Two other possible configurations of policy control
   architecture components. The configuration on the left shows a local
   decision point at a network node and the configuration on the right
   shows PEP and PDP co-located at the same node.

   If it is available, the PEP will first use the LPDP to reach a local
   decision. This partial decision and the original policy request are
   next sent to the PDP which  renders a final decision (possibly,
   overriding the LPDP). It must be noted that the PDP acts as the final
   authority for the decision returned to the PEP and the PEP must
   enforce the decision rendered by the PDP. Finally, if a shared state
   has been established for the request and response between the PEP and
   PDP, it is the responsibility of the PEP to notify the PDP that the
   original request is no longer in use.

   Unless otherwise specified, we will assume the configuration shown on
   the left in Figure 2 in the rest of this document.

   Under this policy control model, the PEP module at a network node
   must use the following steps to reach a policy decision:

   1. When a local event or message invokes PEP for a policy decision,
      the PEP creates a request that includes information from the
      message (or local state) that describes the admission control
      request. In addition, the request includes appropriate policy
      elements as described below.

   2. The PEP may consult a local configuration database to identify a
      set of policy elements (called set A) that are to be evaluated
      locally. The local configuration specifies the types of policy
      elements that are evaluated locally. The PEP passes the request





Yavatkar, et al.             Informational                      [Page 8]

RFC 2753      Framework for Policy-based Admission Control  January 2000


      with the set A to the Local Decision point (LPDP) and collects the
      result of the LPDP (called "partial result" and referred to as
      D(A) ).

   3. The PEP then passes the request with ALL the policy elements and
      D(A) to the PDP. The PDP applies policies based on all the policy
      elements and the request and reaches a decision (let us call it
      D(Q)). It then combines its result with the partial result D(A)
      using a combination operation to reach a final decision.

   4. The PDP returns the final policy decision (obtained from the
      combination operation) to the PEP.

   Note that in the above model, the PEP MUST contact the PDP even if no
   (or NULL) policy objects are received in the admission control
   request.  This requirement helps ensure that a request cannot bypass
   policy control by omitting policy elements in a reservation request.
   However, "short circuit" processing is permitted, i.e., if the result
   of D(A), above, is "no", then there is no need to proceed with
   further policy processing at the PDP. Still, the PDP must be informed
   of the failure of local policy processing. The same applies to the
   case when policy processing is successful but admission control (at
   the resource management level due to unavailable capacity) fails;
   again the PDP has to be informed of the failure.

   It must also be noted that the PDP may, at any time, send an
   asynchronous notification to the PEP to change an earlier decision or
   to generate a policy error/warning message.

4.1. Example of a RSVP Router

   In the case of a RSVP router, Figure 3 shows the interaction between
   a PEP and other int-serv components within the router.  For the
   purpose of this discussion, we represent all the components of RSVP-
   related processing by a single RSVP module, but a more detailed
   discussion of the exact interaction and interfaces between RSVP and
   the PEP is provided in a separate document [3].














Yavatkar, et al.             Informational                      [Page 9]

RFC 2753      Framework for Policy-based Admission Control  January 2000


        ______________________________
       |                              |
       |           Router             |
       |  ________           _____    |            _____
       | |        |         |     |   |           |     |
       | |  RSVP  |<------->| PEP |<--|---------->| PDP |
       | |________|         |_____|   |           |_____|
       |      ^                       |
       |      |      Traffic control  |
       |      |      _____________    |
       |      \---->|  _________  |   |
       |            | |capacity | |   |
       |            | | ADM CTL | |   |
       |            | |_________| |   |
     --|----------->|  ____ ____  |   |
       |   Data     | | PC | PS | |   |
       |            | |____|____| |   |
       |            |_____________|   |
       |                              |
       |______________________________|

   Figure 3: Relationship between PEP and other int-serv components
   within an RSVP router. PC -- Packet Classifier, PS -- Packet
   Scheduler

   When a RSVP message arrives at the router (or an RSVP related event
   requires a policy decision), the RSVP module is expected to hand off
   the request (corresponding to the event or message) to its PEP
   module. The PEP will use the PDP (and LPDP) to obtain the policy
   decision and communicate it back to the RSVP module.

4.2. Additional functionality at the PDP

   Typically, PDP returns the final policy decision based on an
   admission control request and the associated policy elements.
   However, it should be possible for the PDP to sometimes ask the PEP
   (or the admission control module at the network element where PEP
   resides) to generate policy-related error messages. For example, in
   the case of RSVP, the PDP may accept a request and allow installation
   and forwarding of a reservation to a previous hop, but, at the same
   time, may wish to generate a warning/error message to a downstream
   node (NHOP) to warn about conditions such as "your request may have
   to be torn down in 10 mins, etc."  Basically, an ability to create
   policy-related errors and/or warnings and to propagate them using the
   native QoS signaling protocol (such as RSVP) is needed. Such a policy
   error returned by the PDP must be able to also specify whether the





Yavatkar, et al.             Informational                     [Page 10]