rfc2753.txt

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

Network Working Group                                         R. Yavatkar
Request for Comments: 2753                                          Intel
Category: Informational                                     D. Pendarakis
                                                                      IBM
                                                                R. Guerin
                                                       U. Of Pennsylvania
                                                             January 2000


             A Framework for Policy-based Admission Control


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

1. Introduction

   The IETF working groups such as Integrated Services (called "int-
   serv") and RSVP [1] have developed extensions to the IP architecture
   and the best-effort service model so that applications or end users
   can request specific quality (or levels) of service from an
   internetwork in addition to the current IP best-effort service.
   Recent efforts in the Differentiated Services Working Group are also
   directed at the definition of mechanisms that support aggregate QoS
   services. The int-serv model for these new services requires explicit
   signaling of the QoS (Quality of Service) requirements from the end
   points and provision of admission and traffic control at Integrated
   Services routers. The proposed standards for RSVP [RFC 2205] and
   Integrated Services [RFC 2211, RFC 2212] are examples of a new
   reservation setup protocol and new service definitions respectively.
   Under the int-serv model, certain data flows receive preferential
   treatment over other flows; the admission control component only
   takes into account the requester's resource reservation request and
   available capacity to determine whether or not to accept a QoS
   request.  However, the int-serv mechanisms do not include an
   important aspect of admission control: network managers and service
   providers must be able to monitor, control, and enforce use of
   network resources and services based on policies derived from
   criteria such as the identity of users and applications,
   traffic/bandwidth requirements, security considerations, and time-




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


   of-day/week. Similarly, diff-serv mechanisms also need to take into
   account policies that involve various criteria such as customer
   identity, ingress points, and so on.

   This document is concerned with specifying a framework for providing
   policy-based control over admission control decisions. In particular,
   it focuses on policy-based control over admission control using RSVP
   as an example of the QoS signaling mechanism. Even though the focus
   of the work is on RSVP-based admission control, the document outlines
   a framework that can provide policy-based admission control in other
   QoS contexts. We argue that policy-based control must be applicable
   to different kinds and qualities of services offered in the same
   network and our goal is to consider such extensions whenever
   possible.

   We begin with a list of definitions in Section 2. Section 3 lists the
   requirements and goals of the mechanisms used to control and enforce
   access to better QoS.  We then outline the architectural elements of
   the framework in Section 4 and describe the functionality assumed for
   each component.  Section 5 discusses example policies, possible
   scenarios, and policy support needed for those scenarios. Section 6
   specifies the requirements for a client-server protocol for
   communication between a policy server (PDP) and its client (PEP) and
   evaluates the suitability of some existing protocols for this
   purpose.

2. Terminology

   The following is a list of terms used in this document.

   -  Administrative Domain: A collection of networks under the same
      administrative control and grouped together for administrative
      purposes.

   -  Network Element or Node: Routers, switches, hubs are examples of
      network nodes. They are the entities where resource allocation
      decisions have to be made and the decisions have to be enforced. A
      RSVP router which allocates part of a link capacity (or buffers)
      to a particular flow and ensures that only the admitted flows have
      access to their reserved resources is an example of a network
      element of interest in our context.

      In this document, we use the terms router, network element, and
      network node interchangeably, but the should all be interpreted as
      references to a network element.

   -  QoS Signaling Protocol: A signaling protocol that carries an
      admission control request for a resource, e.g., RSVP.



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


   -  Policy: The combination of rules and services where rules define
      the criteria for resource access and usage.

   -  Policy control: The application of rules to determine whether or
      not access to a particular resource should be granted.

   -  Policy Object:  Contains policy-related information such as policy
      elements and is carried in a request or response related to a
      resource allocation decision.

   -  Policy Element: Subdivision of policy objects; contains single
      units of information necessary for the evaluation of policy rules.
      A single policy element may carry an user or application
      identification whereas another policy element may carry user
      credentials or credit card information.  The policy elements
      themselves are expected to be independent of which QoS signaling
      protocol is used.

   -  Policy Decision Point (PDP): The point where policy decisions are
      made.

   -  Policy Enforcement Point (PEP): The point where the policy
      decisions are actually enforced.

   -  Policy Ignorant Node (PIN): A network element that does not
      explicitly support policy control using the mechanisms defined in
      this document.

   -  Resource: Something of value in a network infrastructure to which
      rules or policy criteria are first applied before access is
      granted. Examples of resources include the buffers in a router and
      bandwidth on an interface.

   -  Service Provider: Controls the network infrastructure  and may be
      responsible for the charging and accounting of services.

   -  Soft State Model - Soft state is a form of the stateful model that
      times out installed state at a PEP or PDP. It is an automatic way
      to erase state in the presence of communication or network element
      failures. For example, RSVP uses the soft state model for
      installing reservation state at network elements along the path of
      a data flow.

   -  Installed State: A new and unique request made from a PEP to a PDP
      that must be explicitly deleted.






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


   -  Trusted Node: A node that is within the boundaries of an
      administrative domain (AD) and is trusted in the sense that the
      admission control requests from such a node do not necessarily
      need a PDP decision.

3. Policy-based Admission Control: Goals and Requirements

   In this section, we describe the goals and requirements of mechanisms
   and protocols designed to provide policy-based control over admission
   control decisions.

   -  Policies vs Mechanisms: An important point to note is that the
      framework does not include any discussion of any  specific policy
      behavior or does not require use of specific policies. Instead,
      the framework only outlines the architectural elements and
      mechanisms needed to allow a wide variety of possible policies to
      be carried out.

   -  RSVP-specific: The mechanisms must be designed to meet the
      policy-based control requirements specific to the problem of
      bandwidth reservation using RSVP as the signaling protocol.
      However, our goal is to allow for the application of this
      framework for admission control involving other types of resources
      and QoS services (e.g., Diff-Serv) as long as we do not diverge
      from our central goal.

   -  Support for preemption: The mechanisms designed must include
      support for preemption. By preemption, we mean an ability to
      remove a previously installed state in favor of accepting a new
      admission control request.  For example, in the case of RSVP,
      preemption involves the ability to remove one or more currently
      installed reservations to make room for a new resource reservation
      request.

   -  Support for many styles of policies: The mechanisms designed must
      include support for many policies and policy configurations
      including bi-lateral and multi-lateral service agreements and
      policies based on the notion of relative priority.  In general,
      the determination and configuration of viable policies are the
      responsibility of the service provider.

   -  Provision for Monitoring and Accounting Information:  The
      mechanisms must include support for monitoring policy state,
      resource usage, and provide access information. In particular,
      mechanisms must be included to provide usage and access
      information that may be used for accounting and billing purposes.





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


   -  Fault tolerance and recovery: The mechanisms designed on the basis
      of this framework must include provisions for fault tolerance and
      recovery from failure cases such as failure of PDPs, disruption in
      communication including network partitions (and subsequent
      merging) that separate a PDP from its associated PEPs.

   -  Support for Policy-Ignorant Nodes (PINs):  Support for the
      mechanisms described in this document should not be mandatory for
      every node in a network. Policy based admission control could be
      enforced at a subset of nodes, for example the boundary nodes
      within an administrative domain. These policy capable nodes would
      function as trusted nodes from the point of view of the policy-
      ignorant nodes in that administrative domain.

   -  Scalability:  One of the important requirements for the mechanisms
      designed for policy control is scalability. The mechanisms must
      scale at least to the same extent that RSVP scales in terms of
      accommodating multiple flows and network nodes in the path of a
      flow. In particular, scalability must be considered when
      specifying default behavior for merging policy data objects and
      merging should not result in duplicate policy elements or objects.
      There are several sensitive areas in terms of scalability for
      policy control over RSVP. First, not every policy aware node in an
      infrastructure should be expected to contact a remote PDP. This
      would cause potentially long delays in verifying requests that
      must travel up hop by hop. Secondly, RSVP is capable of setting up
      resource reservations for multicast flows. This implies that the
      policy control model must be capable of servicing the special
      requirements of large multicast flows. Thus, the policy control
      architecture must scale at least as well as RSVP based on factors
      such as the size of RSVP messages, the time required for the
      network to service an RSVP request, local processing time required
      per node, and local memory consumed per node.

   -  Security and denial of service considerations: The policy control
      architecture must be secure as far as the following aspects are
      concerned. First, the mechanisms proposed under the framework must
      minimize theft and denial of service threats. Second, it must be
      ensured that the entities (such as PEPs and PDPs) involved in
      policy control can verify each other's identity and establish
      necessary trust before communicating.

4. Architectural Elements

   The two main architectural elements for policy control are the PEP
   (Policy Enforcement Point) and the PDP (Policy Decision Point).
   Figure 1 shows a simple configuration involving these two elements;
   PEP is a component at a network node and PDP is a remote entity that