rfc2753.txt

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


RFC 2753      Framework for Policy-based Admission Control  January 2000


   reservation request should still be accepted, installed, and
   forwarded to allow continued normal RSVP processing. In particular,
   when a PDP sends back an error, it specifies that:

      1. the message that generated the admission control request should
      be processed further as usual, but an error message (or warning)
      be sent in the other direction and include the policy objects
      supplied in that error message

      2. or, specifies that an error be returned, but the RSVP message
      should not be forwarded  as usual.

4.3. Interactions between PEP, LPDP, and PDP at a RSVP router

   All the details of RSVP message processing and associated
   interactions between different elements at an RSVP router (PEP, LPDP)
   and PDP are included in separate documents [3,8]. In the following, a
   few, salient points related to the framework are listed:

   *  LPDP is optional and may be used for making decisions based on
      policy elements handled locally. The LPDP, in turn, may have to go
      to external entities (such as a directory server or an
      authentication server, etc.) for making its decisions.

   *  PDP is stateful and  may make decisions even if no policy objects
      are received (e.g., make decisions based on information such as
      flowspecs and session object in the RSVP messages). The PDP may
      consult other PDPs, but discussion of inter-PDP communication and
      coordination is outside the scope of this document.

   *  PDP sends asynchronous notifications to PEP whenever necessary to
      change earlier decisions, generate errors etc.

   *  PDP exports the information useful for usage monitoring  and
      accounting purposes. An example of a useful mechanism for this
      purpose is a MIB or a relational database. However, this document
      does not specify any particular mechanism for this purpose and
      discussion of such mechanisms is out of the scope of this
      document.

4.4. Placement of Policy Elements in a Network

   By allowing division of labor between an LPDP and a PDP, the policy
   control architecture allows staged deployment by enabling routers of
   varying degrees of sophistication, as far as policy control is
   concerned, to communicate with policy servers. Figure 4 depicts an
   example set of nodes belonging to three different administrative
   domains (AD) (Each AD could correspond to a different service



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


   provider in this case).  Nodes A, B and C belong to administrative
   domain AD-1, advised by PDP PS-1, while D and E belong to AD-2 and
   AD-3, respectively. E communicates with PDP PS-2.  In general, it is
   expected that there will be at least one PDP per administrative
   domain.

   Policy capable network nodes could range from very unsophisticated,
   such as E, which have no LPDP, and thus have to rely on an external
   PDP for every policy processing operation, to self-sufficient, such
   as D, which essentially encompasses both an LPDP and a PDP locally,
   at the router.

                        AD-1                    AD-2         AD-3
      ________________/\_______________     __/\___      __/\___
     {                                 }   {       }    {       }
             A           B            C            D            E
        +-------+  +-----+    +-------+    +-------+    +-------+
        | RSVP  |  | RSVP|    | RSVP  |    | RSVP  |    | RSVP  |
+----+  |-------|  |-----|    |-------|    |-------|    |-------|
| S1 |--| P | L |--|     |----| P | L |----| P | P |----|   P   | +----+
+----+  | E | D |  +-----+    | E | D |    | E | D |    |   E   |-| R1 |
        | P | P |             | P | P |    | P | P |    |   P   | +----+
        +-------+             +-------+    +-------+    +-------+
           ^                        ^                           ^
           |                        |                           |
           |                        |                           |
           |                        |                       +-------+
           |                        |                       | PDP   |
           |         +------+       |                       |-------|
           +-------->| PDP  |<------+                       |       |
                     |------|                               +-------+
                     |      |                                  PS-2
                     +------+
                       PS-1

         Figure 4: Placement of Policy Elements in an internet

5. Example Policies, Scenarios, and  Policy Support

   In the following, we present examples of desired policies and
   scenarios requiring policy control that the policy control framework
   should be able to support.  In some cases,  possible approach(es) for
   achieving the desired goals are also outlined with a list of open
   issues to be resolved.

5.1. Admission control policies based on factors such as Time-of-Day,
     User Identity, or credentials.




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


   Policy control must be able to express and enforce rules with
   temporal dependencies. For example, a group of users might be allowed
   to make reservations at certain levels only during off-peak hours.
   In addition, the policy control must also support policies that take
   into account identity or credentials of users requesting a particular
   service or resource. For example, an RSVP reservation request may be
   denied or accepted based on the credentials or identity supplied in
   the request.

5.2. Bilateral agreements between service providers

   Until recently, usage agreements between service providers for
   traffic crossing their boundaries have been quite simple. For
   example, two ISPs might agree to accept all traffic from each other,
   often without performing any accounting or billing for the "foreign"
   traffic carried.  However, with the availability of QoS mechanisms
   based on Integrated and Differentiated Services, traffic
   differentiation and quality of service guarantees are being phased
   into the Internet. As ISPs start to sell their customers different
   grades of service and can differentiate among different sources of
   traffic, they will also seek mechanisms for charging each other for
   traffic (and reservations) transiting their networks. One additional
   incentive in establishing such mechanisms is the potential asymmetry
   in terms of the customer base that different providers will exhibit:
   ISPs focused on servicing corporate traffic are likely to experience
   much higher demand for reserved services than those that service the
   consumer market. Lack of sophisticated accounting schemes for inter-
   ISP traffic could lead to inefficient allocation of costs among
   different service providers.

   Bilateral agreements could fall into two broad categories; local or
   global. Due to the complexity of the problem, it is expected that
   initially only the former will be deployed. In these, providers which
   manage a network cloud or administrative domain contract with their
   closest point of contact (neighbor) to establish ground rules and
   arrangements for access control and accounting. These contracts are
   mostly local and do not rely on global agreements; consequently, a
   policy node maintains information about its neighboring nodes only.
   Referring to Figure 4, this model implies that provider AD-1 has
   established arrangements with AD-2, but not with AD-3, for usage of
   each other's network. Provider AD-2, in turn, has in place agreements
   with AD-3 and so on. Thus, when forwarding a reservation request to
   AD-2, provider AD-2 will charge AD-1 for use of all resources beyond
   AD-1's network.  This information is obtained by recursively applying
   the bilateral agreements at every boundary between (neighboring)
   providers, until the recipient of the reservation request is reached.
   To implement this scheme under the policy control architecture,
   boundary nodes have to add an appropriate policy object to the RSVP



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


   message before forwarding it to a neighboring provider's network.
   This policy object will contain information such as the identity of
   the provider that generated them and the equivalent of an account
   number where charges can be accumulated. Since agreements only hold
   among neighboring nodes, policy objects have to be rewritten as RSVP
   messages cross the boundaries of administrative domains or provider's
   networks.

5.3. Priority based admission control policies

   In many settings, it is useful to distinguish between reservations on
   the basis of some level of "importance".  For example, this can be
   useful to avoid that the first reservation being granted the use of
   some resources, be able to hog those resources for some indefinite
   period of time.  Similarly, this may be useful to allow emergency
   calls to go through even during periods of congestion.  Such
   functionality can be supported by associating priorities with
   reservation requests, and conveying this priority information
   together with other policy information.

   In its basic form, the priority associated with a reservation
   directly determines a reservation's rights to the resources it
   requests.  For example, assuming that priorities are expressed
   through integers in the range 0 to 32 with 32 being the highest
   priority, a reservation of priority, say, 10, will always be
   accepted, if the amount of resources held by lower priority
   reservations is sufficient to satisfy its requirements.  In other
   words, in case there are not enough free resources (bandwidth,
   buffers, etc.) at a node to accommodate the priority 10 request, the
   node will attempt to free up the necessary resources by preempting
   existing lower priority reservations.

   There are a number of requirements associated with the support of
   priority and their proper operation.  First, traffic control in the
   router needs to be aware of priorities, i.e., classify existing
   reservations according to their priority, so that it is capable of
   determining how many and which ones to preempt, when required to
   accommodate a higher priority reservation request.  Second, it is
   important that preemption be made consistently at different nodes, in
   order to avoid transient instabilities.  Third and possibly most
   important, merging of priorities needs to be carefully architected
   and its impact clearly understood as part of the associated policy
   definition.

   Of the three above requirements, merging of priority information is
   the more complex and deserves additional discussions.  The complexity
   of merging priority information arises from the fact that this
   merging is to be performed in addition to the merging of reservation



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


   information.  When reservation (FLOWSPEC) information is identical,
   i.e., homogeneous reservations, merging only needs to consider
   priority information, and the simple rule of keeping the highest
   priority provides an adequate answer.  However, in the case of
   heterogeneous reservations, the *two-dimensional nature* of the
   (FLOWSPEC, priority) pair makes their ordering, and therefore
   merging, difficult. A description of the handling of different cases
   of RSVP priority objects is presented in [7].

5.4. Pre-paid calling card or Tokens

   A model of increasing popularity in the telephone network is that of
   the pre-paid calling card. This concept could also be applied to the
   Internet; users purchase "tokens" which can be redeemed at a later
   time for access to network services. When a user makes a reservation
   request through, say, an RSVP RESV message, the user supplies a
   unique identification number of the "token", embedded in a policy
   object. Processing of this object at policy capable routers results
   in decrementing the value, or number of remaining units of service,
   of this token.

   Referring to Figure 4, suppose receiver R1 in the administrative
   domain AD3 wants to request a reservation for a service originating
   in AD1. R1 generates a policy data object of type PD(prc, CID), where
   "prc" denotes pre-paid card and CID is the card identification
   number. Along with other policy objects carried in the RESV message,
   this object is received by node E, which forwards it to its PEP,
   PEP_E, which, in turn, contacts PDP PS-3. PS-3 either maintains
   locally, or has remote access to, a database of pre-paid card
   numbers. If the amount of remaining credit in CID is sufficient, the
   PDP accepts the reservation and the policy object is returned to
   PEP_E. Two issues have to be resolved here:

   *  What is the scope of these charges?

   *  When are charges (in the form of decrementing the remaining
      credit) first applied?

   The answer to the first question is related to the bilateral
   agreement model in place. If, on the one hand, provider AD-3 has
   established agreements with both AD-2 and AD-1, it could charge for
   the cost of the complete reservation up to sender S1. In this case
   PS-2 removes the PD(prc,CID) object from the outgoing RESV message.

   On the other hand, if AD-3 has no bilateral agreements in place, it
   will simply charge CID for the cost of the reservation within AD-3
   and then forward PD(prc,CID) in the outgoing RESV message. Subsequent
   PDPs in other administrative domains will charge CID for their



Yavatkar, et al.             Informational                     [Page 15]