rfc2753.txt

RFC 的详细文档！

RFC 2753      Framework for Policy-based Admission Control  January 2000


   respective reservations.  Since multiple entities are both reading
   (remaining credit) and writing (decrementing credit) to the same
   database, some coordination and concurrency control might be needed.
   The issues related to location, management, coordination of credit
   card (or similar) databases is outside the scope of this document.

   Another problem in this scenario is determining when the credit is
   exhausted. The PDPs should contact the database periodically to
   submit a charge against the CID; if the remaining credit reaches
   zero, there must be a mechanism to detect that and to cause
   revocation or termination of privileges granted based on the credit.

   Regarding the issue of when to initiate charging, ideally that should
   happen only after the reservation request has succeeded. In the case
   of local charges, that could be communicated by the router to the
   PDP.

5.5. Sender Specified Restrictions on Receiver Reservations

   The ability of senders to specify restrictions on reservations, based
   on receiver identity, number of receivers or reservation cost might
   be useful in future network applications. An example could be any
   application in which the sender pays for service delivered to
   receivers. In such a case, the sender might be willing to assume the
   cost of a reservation, as long as it satisfies certain criteria, for
   example, it originates from a receiver who belongs to an access
   control list (ACL) and satisfies a limit on cost. (Notice that this
   could allow formation of "closed" multicast groups).

   In the policy based admission control framework such a scheme could
   be achieved by having the sender generate appropriate policy objects,
   carried in a PATH message, which install state in routers on the path
   to receivers. In accepting reservations, the routers would have to
   compare the RESV requests to the installed state.

   A number of different solutions can be built to address this
   scenario; precise description of a solution is beyond the scope of
   this document.

6. Interaction Between the Policy Enforcement Point (PEP) and the Policy
   Decision Point (PDP)

   In the case of an external PDP, the need for a communication protocol
   between the PEP and PDP arises. In order to allow for
   interoperability between different vendors networking elements and
   (external) policy servers, this protocol should be standardized.





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


6.1. PEP to PDP Protocol Requirements

   This section describes a set of general requirements for the
   communication protocol between the PEP and an external PDP.

   *  Reliability:  The sensitivity of policy control information
      necessitates reliable operation. Undetected loss of policy queries
      or responses may lead to inconsistent network control operation
      and are clearly unacceptable for actions such as billing and
      accounting. One option for providing reliability is the re-use of
      the TCP as the transport protocol.

   *  Small delays: The timing requirements of policy decisions related
      to QoS signaling protocols are expected to be quite strict. The
      PEP to PDP protocol should add small amount of delay to the
      response delay experienced by queries placed by the PEP to the
      PDP.

   *  Ability to carry opaque objects: The protocol should allow for
      delivery of self-identifying, opaque objects, of variable length,
      such as RSVP messages, RSVP policy objects and other objects that
      might be defined as new policies are introduced. The protocol
      should not have to be changed every time a new object has to be
      exchanged.

   *  Support for PEP-initiated, two-way Transactions:  The protocol
      must allow for two-way transactions (request-response exchanges)
      between a PEP and a PDP. In particular, PEPs must be able to
      initiate requests for policy decision, re-negotiation of
      previously made policy decision, and exchange of policy
      information. To some extent, this requirement is closely tied to
      the goal of meeting the requirements of RSVP-specific, policy-
      based admission control. RSVP signaling events such as arrival of
      RESV refresh messages, state timeout, and merging of reservations
      require that a PEP (such as an RSVP router) request a policy
      decision from PDP at any time. Similarly, PEP must be able to
      report monitoring information and policy state changes to PDP at
      any time.

   *  Support for asynchronous notification: This is required in order
      to allow both the policy server and client to notify each other in
      the case of an asynchronous change in state, i.e., a change that
      is not triggered by a signaling message. For example, the server
      would need to notify the client if a particular reservation has to
      be terminated due to expiration of a user's credentials or account
      balance.  Likewise, the client has to inform the server of a
      reservation rejection which is due to admission control failure.




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


   *  Handling of multicast groups: The protocol should provision for
      handling of policy decisions related to multicast groups.

   *  QoS Specification: The protocol should allow for precise
      specification of level of service requirements in the PEP requests
      forwarded to the PDP.

7. Security Considerations

   The communication tunnel between policy clients and policy servers
   should be secured by the use of an IPSEC [4] channel. It is advisable
   that this tunnel makes use of both the AH (Authentication Header) and
   ESP (Encapsulating Security Payload) protocols, in order to provide
   confidentiality, data origin authentication, integrity and replay
   prevention.

   In the case of the RSVP signaling mechanism, RSVP MD5 [2] message
   authentication can be used to secure communications between network
   elements.

8. References

   [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
       "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
       Specification", RFC 2205, September 1997.

   [2] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
       Authentication", RFC 2747, January 2000.

   [3] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
       January 2000.

   [4] Atkinson, R., "Security Architecture for the Internet Protocol",
       RFC 1825, August 1995.

   [5] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
       Authentication Dial In User Service (RADIUS)", RFC 2138, April
       1997.

   [6] Rajan, R., et al., "Schema for Differentiated Services and
       Integrated Services in Networks", Work in Progress.

   [7] Herzog, S., "RSVP Preemption Priority Policy", Work in Progress.

   [8] Herzog, S., "COPS Usage for RSVP", RFC 2749, January 2000.






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


9. Acknowledgements

   This is a result of an ongoing discussion among many members of the
   RAP group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave
   Durham, Shai Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry.

10.  Authors' Addresses

   Raj Yavatkar
   Intel Corporation
   2111 N.E. 25th Avenue,
   Hillsboro, OR 97124
   USA

   Phone: [phone]
   EMail: [e-mail]


   Dimitrios Pendarakis
   IBM T.J. Watson Research Center
   P.O. Box 704
   Yorktown Heights
   NY 10598

   Phone: [phone]
   EMail: [e-mail]


   Roch Guerin
   University of Pennsylvania
   Dept. of Electrical Engineering
   200 South 33rd Street
   Philadelphia, PA  19104

   Phone: [phone]
   EMail: [e-mail]















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


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Yavatkar, et al.             Informational                     [Page 20]