Internet Engineering Task Force               Raj Yavatkar, Intel
  INTERNET-DRAFT                                Dimitrios Pendarakis, IBM
                                                Roch Guerin, IBM U. Of Pennsylvania

                                                November 21, 1997
                                                Expires: May 20, 1998
                                                Expires: June 1999

                A Framework for Policy-based Admission Control

                             Status of this Memo

  This document is an Internet-Draft.  Internet-Drafts are working
  documents of the Internet Engineering Task Force (IETF), its areas,
  and its working groups.  Note that other groups may also distribute
  working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as ``work in progress.''

  To learn the current status of any Internet-Draft, please check the
  ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
  (Pacific Rim), ds.internic.net ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
  Coast).

  This document is a product of the RSVP Admission Policy (RAP) working
  group in the Transport Area of the Internet Engineering Task Force.
  Comments are
  solicited and should be addressed to the working group's mailing list at
  ipc@iphighway.com, and/or the author(s).

                                   Abstract

  TO BE FILLED IN.

                A Framework for Policy-based Admission Control     Nov. 1998

  1. Introduction Abstract

  The IETF working groups such as Integrated Services (called ''int-serv'') "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 Differen-
  tiated Services Working Group are also directed at definition of mechan-
  isms 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 treat-
  ment over other flows; the admission control component only takes into
  account the requester's  resource reservation request and available capa-
  city to determine whether or not to accept a QoS request. However, the
  int-serv mechanisms do not include  an important aspect of admission con-
  trol: network managers and service providers must be able to monitor, con-
  trol, 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-of-
  day/week. Similarly, diff-serv mechanisms also need to take into account
  policies that take into account various criteria such as customer iden-
  tity, 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. For
  instance, it may be argued We argue
  that policy-based control must be applicable to different kinds and qualities quali-
  ties 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 capable of controlling and
  enforcing access to better QoS.  We then outline the architectural ele-
  ments 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 evalu-
  ates existing solutions such as RADIUS speci-
  fies the requirements for a client-serv protocol for communication between
  a policy server (PDP) and LDAP its client (PEP) and discusses their appli-
  cability to the problem evaluates suitability of policy control.
  some of the existing protocols for this purpose.

                A Framework for Policy-based Admission Control     Nov. 1998

  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 pur-
         poses.

    -    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 ele-
         ment of interest in our context.

         In this document, sometimes we use the terms router,  network ele-
         ment, and network node interchangeably, but should be interpreted
         as reference to a network element.

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

    -    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 info such as policy ele-
         ments and is carried by the QoS signaling protocol. in a request or response related to 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 carries an user or application identifica-
         tion whereas another policy element may carry user credentials or
         credit card information.  Examples of policy elements include iden-
         tity of the requesting user or application, user/app credentials,
         etc. The policy elements themselves are expected to be independent

                A Framework for Policy-based Admission Control     Nov. 1998

         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 deci-
         sions are actually enforced.

    -    Policy Ignorant Node (PIN): A network element that does not expli-
         citly 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 instal-
         ling 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.

    -    Trusted Node: A node that is within the boundaries of an adminis-
         trative 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

                A Framework for Policy-based Admission Control     Nov. 1998

  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 sup-
         port 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 includ-
         ing bi-lateral and multi-lateral service agreements and policies
         based on the notion of relative priority.  In general, the determi-
         nation and configuration of viable policies are the responsibility
         of the service provider.

    -    Provision for Monitoring and Accounting Information:  The mechanisms mechan-
         isms must include support for monitoring policy state state, resource usage
         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.

    -     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

                A Framework for Policy-based Admission Control     Nov. 1998

         communication including network partitions (and subsequent merging)
         that separate a PDP from its peer PEPs.

    -    Support for Policy-Ignorant Nodes (PINs):  Support for the mechan-
         isms 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 poten-
         tially 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 mul-
         ticast 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 pol-
         icy control can verify each other's identity and establish neces-
         sary trust before communicating.

  4. Architectural Elements

  The two main architectural elements for policy control are the PEP (Policy

                A Framework for Policy-based Admission Control     Nov. 1998

  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 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 direc-
  tory service for storage and retrieval of policy information[6]. This
  document does not include discussion of these addi-
  tional 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 deci-
  sion 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 mes-
  sage 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 ele-
  ments. 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.

  In some cases, the simple configuration shown in Figure 1 may not be suf-
  ficient as it

  The PDP might optionally contact other external servers, e.g., for access-
  ing configuration, user authentication, accounting and billing databases.
  Protocols defined for network management (SNMP) or directory access (LDAP)
  might be necessary to apply local policies (e.g., policies
  specified in used for this communication. While the specific type of access control lists) in addition
  and the protocols used may vary among different implementations, some of

                A Framework for Policy-based Admission Control     Nov. 1998

  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 applied at
  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 com-
  pany). 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 pro-
  file 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 suf-
  ficient 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 confi-
  gurations.

  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 informa-
  tion and conditions local to a particular router and which are more
  dynamic, might be better implemented locally, at the router.

                A Framework for Policy-based Admission Control     Nov. 1998

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

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

  If it is available, the PEP will first use the LDP LPDP to reach a local deci-
  sion. This partial decision and the original policy request are next sent
  to the PDP which  renders a final decision (possibly, overriding the LDP).
  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 ren-
  dered 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 mes-
         sage (or local state) that describes the admission control request.
         In addition, the request include includes appropriate policy elements to the
         request 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 ele-
         ments that are evaluated locally. The PEP passes the request with

                A Framework for Policy-based Admission Control     Nov. 1998

         the set A to the Local Decision point (LDP) (LPDP) and collects the
         result of the LDP 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 (one after the combina-
         tion operation) to the PEP.

  Note that in the above model, the PEP  *must* contact the PDP even if no
  or NULL
  (or NULL) policy objects are received in the admission control request.
  This requirement would help 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 policy server. Still, the PDP must be informed of the
  failure of local policy processing. The same applies to the case when policy pol-
  icy processing is successful but admission control (at the resource
  management level due to unavailable capacity) fails; again the policy
  server 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 its 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 more detailed discussion of the exact interac-
  tion and interfaces between RSVP and PEP will be described in a separate
  document [3].

                A Framework for Policy-based Admission Control     Nov. 1998

     ______________________________
    |                              |
    |           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 LDP) 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." Basi-
  cally, 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 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:

                A Framework for Policy-based Admission Control     Nov. 1998

    1. the message that generated the adm admission control request should be pro-
    cessed
    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.

  OPEN ISSUE -- What happens in case of the blockade state in RSVP?

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

  [NOTE: This section only reflects the ongoing discussion].

  At the interim meeting held in October,

  All the working group members present
  discussed the issue details of defining the interaction (and interfaces) among
  different policy control components at a RSVP router. The discussion was
  inconclusive and the following lists the items covered and the issues
  raised for information purpose:

    *    PEP is invoked whenever RSVP events happen. Examples of events are
         timeout, refresh events, a message arrives on an incoming interface
         or is to be sent on an outgoing interface or reservations have to
         be merged processing and installed or forwarded on associated interactions
  between different elements at an interface.

    *    PEP is responsible for notifying RSVP whenever asynch notifications
         come from the PDP.

    *    PEP may cache the results returned by the PDP  for later use to
         avoid checking with the router (PEP, LPDP) and PDP every time. However, this raises an
         interesting issue as are
  included in separate documents [3,8]. In the PEP must be able to detect changes following, a few, salient
  points related to the
         previously received policy elements/objects so that the PEP can
         contact the PDP whenever changes occur. framework are listed:

    *    LDP    LPDP is optional and may be used for making decisions based on pol-
         icy elements handled locally. The LDP, 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 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:   Examples purposes. An example of such information may include a
         MIB.

    *    How useful mechanism for this pur-
         pose is a MIB or when to merge policy elements and default rules on merging?
         In case of RSVP node without a PEP, what and if  default behavior relational database. However, this document does
         not specify any particular mechanism for merging should be specified? this purpose and discus-
         sion 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 LDP LPDP and a PDP, the policy

                A Framework for Policy-based Admission Control     Nov. 1998

       control architecture allows staged deployment by enabling routers of
       varying degrees of sophistication, as far as policy control is
         concerned, con-
       cerned, to communicate with policy servers. Figure 4 depicts an
         example exam-
       ple set of nodes belonging to three different administrative domains
       (AD) (Each AD could correspond to a different service pro-
         vider 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. respec-
       tively. E communicates with PDP PS-3. 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 LDP, 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 LDP 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 should possibly be addressed

                A Framework for Policy-based Admission Control     Nov. 1998

       by the policy control framework. 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, Time-of-Day,
       User Identity Identity, or credentials

       Policy control must be able to express and enforce rules with tem-
       poral 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 iden-
         tity identity suppled in
       the request.

       5.2. Bilateral agreements between service providers

         Today,

       Until recently, usage agreements between service providers for
       traffic crossing their boundaries tend to be have been quite simple, for example, simple. For exam-
       ple, two ISPs might agree to accept all traffic from each other,
       often without performing any accounting or billing for the
       ``foreign'' traffic carried. There are strong reasons to expect that such a
         model cannot survive once  However, with the availability of QoS
       mechanisms based on Integrated and Differentiated Services, traffic
       differentiation and quality of service guarantees begin to be are being phased in
       into the Internet. Once As ISPs start charging end users based on usage to sell their customers different
       grades of service and quality can differentiate among different sources of service, it
         is only natural that
       traffic, they will also seek mechanisms for charging each other for reservations
       traffic (and reservations) transiting their networks. One addi-
         tional 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 inter-
       ISP traffic could lead to inefficient allocation of costs among different dif-
       ferent service providers.  (ISSUE:
         ISn't this an accounting issue among ISPs? We can only provide
         mechanism to facilitate resolution of such issues, but not suggest
         solutions.)

       Bilateral agreements could fall into two broad categories. In categories; local or
       global. Due to the complexity of the problem, it is expected that
       initially only the
         first, 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 informa-
         tion 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

                A Framework for Policy-based Admission Control     Nov. 1998

       each other's network. Pro-
         vider 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, pro-
       viders, 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 message
       before forwarding it to a neighboring provider's network. This policy
       object will contain information such as the identity of the pro-
         vider provider
       that generated them and the equivalent of an account number where
       charges can be accumulated. Since agreements only hold among
         neighboring neigh-
       boring nodes, *policy policy objects have to be rewritten* rewritten as RSVP messages
       cross the boundaries of administrative domains or provider's networks.

         Bilateral agreements could also be established on a *global* scale. net-
       works.

       5.3. Priority based admission control policies

       In this second category, providers contract with an arbitrary
         number many settings, it is useful to distinguish between reservations on
       the basis of other providers, not necessarily neighboring. The objec-
         tive some level of global agreements would "importance".  For example, this can be
       useful to provide a global network
         picture avoid that allows a provider to satisfy (most) the first reservation
         requests without reliance on third party agreements. This category being granted the use of agreements
       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 func-
       tionality can also be supported in the context of the by associating priorities with reservation
       requests, and conveying this priority information together with other
       policy
         control architecture. As above, information.

       In its basic form, the originating node includes priority associated with a
         policy object containing identity and account information in reservation
       directly determines a reservation's rights to the
         RSVP message; however, as long as global agreements resources it
       requests.  For example, assuming that priorities are expressed
       through integers in place,
         this object is not rewritten as the message crosses administrative
         boundaries. Instead, each provider ``charges'' range 0 to 32 with 32 being the account the
         incremental cost incurred in carrying the highest
       priority, a reservation request
         through its network.

         5.3. Pre-paid calling card or Tokens

         A model of increasing popularity in priority, say, 10, will always be
       accepted, if the telephone network is that amount of the pre-paid calling card. This concept could also be applied resources held by lower priority reserva-
       tions is sufficient to
         the Internet; users purchase ``tokens'' which can be redeemed satisfy its requirements.  In other words, in
       case there are not enough free resources (bandwidth, buffers, etc.)
       at a
         later time for access node to network services. When a user makes a
         reservation request through, say, an RSVP RESV message, accommodate the user
         supplies priority 10 request, the node will
       attempt to free up the necessary resources by preempting existing
       lower priority reservations.

       There are a unique identification number of requirements associated with the ``token'', embedded
         in a policy object. Processing support of this object at policy capable
         routers results
       priority and their proper operation.  First, traffic control in decrementing the value, or number of remaining
         units
       router needs to be aware of service, priorities, i.e., classify existing
       reservations according to their priority, so that it is capable of this token.

         Referring
       determining how many and which ones to Figure 4, suppose receiver R1 in the administrative
         domain AD3 wants preempt, when required to request
       accommodate a higher priority 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 request.  Second, it is the card identifica-
         tion number. Along with other policy objects carried
       important that preemption be made consistently at different nodes, in the RESV
         message, this object is received by node E, which forwards it
       order to avoid transient instabilities.  Third and possibly most

                A Framework for Policy-based Admission Control     Nov. 1998

       important, merging of priorities needs to be carefully architected
       and its PEP, PEP_E, which, in turn, contacts PDP PS-3. PS-3 either
         maintains locally, or has remote access to, a database impact clearly understood as part of pre-paid
         card numbers. If the amount associated policy
       definition.

       Of the three above requirements, merging of remaining credit in CID priority information is suffi-
         cient,
       the PDP accepts the reservation more complex and deserves additional discussions.  The complexity
       of merging priority information arises from the policy object fact that this merg-
       ing is
         returned to PEP_E. Two issues have to be resolved here:

    *    What is performed in addition to the scope merging of these charges?

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

    The answer to the first question reservation (FLOWSPEC) information is related identical,
       i.e., homogeneous reservations, merging only needs to the bilateral agreement
    model in place. If, on the one hand, provider AD-3 has established
    agreements with both AD-2 consider prior-
       ity information, and AD-1, it could charge for the cost simple rule of keeping 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 highest priority
       provides an adequate answer.  However, in place, it will
    simply charge CID for the cost case of heterogeneous
       reservations, the * two-dimensional nature} of the reservation within AD-3 (FLOWSPEC, prior-
       ity) pair makes their ordering, and then
    forward PD(prc,CID) in therefore merging, difficult. A
       description of the outgoing RESV message. Subsequent PDPs in
    other administrative domains will charge CID for their respective reser-
    vations.  Since multiple entities are both reading (remaining credit)
    and writing (decrementing credit) to the same database, some coordina-
    tion and concurrency control might be needed.  The issues related to
    location, management, coordination handling of credit card (or similar) databases different cases of RSVP priority
       objects is outside the scope presented in [7].

       5.4. Pre-paid calling card or Tokens

       A model of this document.

    Another problem increasing popularity in this scenario is determining when the credit telephone network is
    exhausted. The PDPs should contact that of
       the database periodically pre-paid calling card. This concept could also be applied to submit a
    charge against the CID; if the remaining credit reaches zero, there must
       Internet; users purchase ``tokens'' which can be redeemed at a mechanism to detect that and to cause revocation or termination of
    privileges granted based on the credit.

    Regarding the issue of when later
       time for access to initiate charging, ideally that should
    happen only after the network services. When a user makes a reservation
       request has succeeded. In through, say, an RSVP RESV message, the case user supplies a
       unique identification number of
    local charges, that could be communicated by the router to the PDP.

    5.4. Priority based admission control policies

    In many settings, it is useful to distinguish between reservations on ``token'', embedded in a policy
       object. Processing of this object at policy capable routers results
       in decrementing the basis value, or number of some level remaining units of service,
       of "importance".  For example, this can be use-
    ful token.

       Referring to avoid that Figure 4, suppose receiver R1 in the first administrative
       domain AD3 wants to request a 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 a service originating
       in AD1. R1 generates a policy data object of congestion.  Such functionality can be
    supported by associating priorities to reservation requests, type PD(prc, CID), where
       ``prc'' denotes pre-paid card and convey-
    ing this priority information together CID is the card identification
       number. Along 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 objects carried in the
    range 0 RESV message,
       this object is received by node E, which forwards it to 32 with 32 being the highest priority, its PEP,
       PEP_E, which, in turn, contacts PDP PS-3. PS-3 either maintains
       locally, or has remote access to, a reservation database of
    priority, say, 10, will always be accepted, if pre-paid card
       numbers. If the amount of resources
    held by lower priority reservations is sufficient to satisfy its
    requirements.  In other words, remaining credit in case there are not enough free
    resources (bandwidth, buffers, etc.) at a node to accommodate CID is sufficient, the prior-
    ity 10 request,
       PDP accepts the node will attempt reservation and the policy object is returned to free up
       PEP_E. Two issues have to be resolved here:

  *    What is the necessary resources
    by preempting existing lower priority reservations.

    There are a number scope of requirements associated with these charges?

  *    When are charges (in the support form of
    priority and their proper operation.  First, traffic control in decrementing the
    router needs to be aware of priorities, i.e., classify existing reserva-
    tions according to their priority, so that it is capable of determining
    how many and which ones to preempt, when required remaining credit)
       first applied?

                A Framework for Policy-based Admission Control     Nov. 1998

  The answer to accommodate a
    higher priority reservation request.  Second, it the first question 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 related 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 bilateral agreement
  model in place. If, on the
    more complex one hand, provider AD-3 has established agree-
  ments with both AD-2 and deserves additional discussions.  The complexity of
    merging priority information arises from the fact that this merging is
    to be performed in addition to AD-1, it could charge for the merging cost of the com-
  plete reservation information.
    When reservation (FLOWSPEC) information is identical, i.e., homogeneous
    reservations, merging only needs up to consider priority information, and sender S1. In this case PS-2 removes the simple rule of keeping
  PD(prc,CID) object from the highest priority provides an adequate
    answer.  However, outgoing RESV message.

  On the other hand, if AD-3 has no bilateral agreements in place, it will
  simply charge CID for the case cost of heterogeneous reservations, the * two-
    dimensional nature} of reservation within AD-3 and then
  forward PD(prc,CID) in the (FLOWSPEC, priority) pair makes outgoing RESV message. Subsequent PDPs in other
  administrative domains will charge CID for their order-
    ing, respective reservations.
  Since multiple entities are both reading (remaining credit) and therefore merging, difficult.  Two possible cases can be iden-
    tified:

    1. (FLOWSPEC1, priority1)= (high, high);
       (FLOWSPEC2, priority2)= (low, low)
    2. (FLOWSPEC1, priority1) = (high, low);
       (FLOWSPEC2, priority2) = (low, high)

    In the first case, writing
  (decrementing credit) to the ordering same database, some coordination and con-
  currency control might be needed.  The issues related to location, manage-
  ment, coordination of credit card (or similar) databases is immediate, i.e.,

    (FLOWSPEC1, priority1) >= (FLOWSPEC2, priority2),

    so that outside the merged value can readily be chosen as (FLOWSPEC1, prior-
    ity1). However,
  scope of this document.

  Another problem in this scenario is determining when the second case, no obvious ordering credit is available,
    and each possible merged combination introduces
  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 problem mechanism to detect that and to cause revocation or termination of its own
    which we briefly review.

      2.a (FLOWSPEC_OUT, priority_OUT) = (high, high) = {FLOWSPEC1, prior-
      ity2}

      The main problem with this selection is
  privileges granted based on the so-called "free-rider"
      problem, in that credit.

  Regarding the high bandwidth requirement issue of a low priority
      request is now entitled when to initiate charging, ideally that should hap-
  pen only after the higher priority reservation request has succeeded. In the case of local
  charges, that was initially
      granted could be communicated by the router to a low bandwidth request.  Such "upgrades" can all but dis-
      able the PDP.

  5.5. Sender Specified Restrictions on Receiver Reservations

  The ability of priorities to give preference to certain flows,
      and are therefore not acceptable.

      2.b (FLOWSPEC_OUT, priority_OUT) = (high, low) = (FLOWSPEC1,
      priority1)

      This selection amounts to (initially) giving preference senders to high
      bandwidth requests, irrespective specify restrictions on reservations, based on
  receiver identity, number of their priority.  The main benefit
      is that larger reservations are allowed to try and succeed receivers or reservation cost might be useful
  in case future network applications. An example could be any application in
  which the
      resources are available.  The main disadvantage is that if sender pays for service delivered to receivers. In such a high
      FLOWSPEC and low priority reservation is preempted, case,
  the entire reser-
      vation is taken down.  As a result, sender might be willing to assume the cost of a high priority and low FLOWSPEC
      reservation is left without resources until reservation, as long
  as it satisfies certain criteria, for example, it originates from a new reservation is ulti-
      mately reestablished at the higher priority level.

      2.c (FLOWSPEC_OUT, priority_OUT) = (low, high) = (FLOWSPEC2, prior-
      ity2)

      This is the opposite selection
  receiver who belongs to 2.b, an access control list (ACL) and as satisfies a result, it has limit
  on cost. (Notice that this could allow formation of "closed" multicast
  groups).

  In the
      opposite disadvantages and benefits.  Specifically, policy based admission control framework such a low FLOWSPEC but
      high priority request can preclude higher FLOWSPEC but lower priority
      requests, *irrespective* of how lightly loaded scheme could be
  achieved by having the network is.  On sender generate appropriate policy objects, carried
  in a PATH message, which install state in routers on the
      other hand, path to
  receivers. In accepting reservations, the high priority request is *guaranteed* unperturbed ser-
      vice unless it itself needs routers would have to be preempted.

      2.d (FLOWSPEC_OUT, priority_OUT) = (low, low)

      This last option is mentioned for completeness, but is not particu-
      larly meaningful as it offers no benefits and only disadvantages.

    As can be seen from compare
  the above discussion, support for priorities and RESV requests to the
    associated merging operations raises a installed state.

  A number issues.  There are possi-
    ble of different solutions can be built to most address this scenario;
  precise description of a solution is beyond the above problems, e.g.,

    - Disable or limit the amount of merging that can take place, - Select
    one scope of this document.

                A Framework for Policy-based Admission Control     Nov. 1998

  6. Interaction Between the above rules 2.b or 2.c based on Policy Enforcement Point (PEP) and the relative difference
    between Policy
  Decision Point (PDP)

  In the FLOWSPEC being merged,

    but it is likely that different environments (set case of criteria) may man-
    date different selections. an external PDP, the need for a communication protocol
  between the PEP and PDP arises. In addition, it may order to allow for interoperability
  between different vendors networking elements and (external) policy
  servers, this protocol should be desirable standardized.

  6.1. PEP to extend
    the concept PDP Protocol Requirements

  This section describes a set of priorities to let applications specify both holding and
    preemption priorities, with general requirements for the former being always greater than communication
  protocol between the
    latter. PEP and an external PDP.

  *    Reliability:  The preemption priority would be a function sensitivity of the urgency policy control information necessi-
       tates reliable operation. Undetected loss of
    satisfying 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 reservation request being made, while re-use of the holding prior-
    ity would reflect TCP as the application's tolerance
       transport protocol.

  *    Small delays: The timing requirements of policy decisions related to being interrupted.

    In general, support for priority provides a powerful tool
       QoS signaling protocols are expected to manage
    access be quite strict. The PEP to network resources, and
       PDP protocol should represent one add small amount of delay to the key bene-
    fits of response delay
       experienced by queries placed by the PEP to the introduction 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 support.  However, rules determining
    how priorities objects and other objects that
       might be defined as new policies are introduced. The protocol should
       not have to be handled may differ, and likely changed every time a new object has to be specified
    in the context 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 each previously made policy supporting priorities.  (OPEN ISSUE:
    Should we specify default merging rules?)

    5.5. Sender Specified Restrictions on Receiver Reservations

    The ability deci-
       sion, and exchange of senders policy information. To some extent, this
       requirement is closely tied to specify restrictions on reservations, based on
    receiver identity, number the goal of receivers or reservation cost might be use-
    ful in future network applications. An example could be any application
    in which meeting the sender pays for service delivered to receivers. In 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
    case, 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.

                A Framework for Policy-based Admission Control     Nov. 1998

  *    Support for asynchronous notification: This is required in order to
       allow both the sender might be willing policy server and client to assume notify each other in the cost
       case 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 satis-
    fies asynchronous change in state, i.e., a limit on cost. (Notice change that this could allow formation of
    "closed" multicast groups).

    In the policy based admission control framework such a scheme could be
    achieved is not
       triggered by having the sender generate appropriate policy objects, car-
    ried in a PATH message, which install state in routers on signaling message. For example, the path server would need
       to
    receivers. In accepting reservations, notify the routers would have client if a particular reservation has to compare be terminated
       due to expiration of a user's credentials or account balance. Like-
       wise, the RESV requests client has to inform the installed state.

    A number server of different solutions can be built a reservation rejection
       which is due to address this scenario; admission control failure.

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

  *    QoS Specification: The protocol should allow for precise description specifica-
       tion of a solution is beyond the scope level of this document.

    6. service requirements in the PEP requests forwarded
       to the PDP.

       6.2. Evaluation of Existing Frameworks or Solutions

    6.1. Protocols

       In view of the above requirements, we believe that protocols
       developed earlier within a different context are inadequate for pro-
       viding policy support for QoS. In the following sections, we summar-
       ize the reasons for some candidate protocols.

       6.2.1. RADIUS

       The Remote Authentication Dial In User Service (RADIUS) [REF] [5] protocol,
       specifies how authentication, authorization and configuration informa-
    tion infor-
       mation is exchanged between a network access server wishing to authenti-
    cate
       authenticate its users and a (shared) authentication server. RADIUS
       has been designed to operate at the level of a * session}, "session", which is
       defined as the interval between the time that service is first provided pro-
       vided and the time service is ended. The latter definition is geared
       towards login-
    type login-type service, for example network access for dial up
       users through PPP.

       RADIUS is an important protocol for authenticating login users. However, How-
       ever, some of its characteristics make it unsuitable for use, at
       least in its current form, in the context of policy control for QoS
       reservations:

    *    Use of the UDP protocol:  The sensitivity As mentioned in section 6.1, the sensi-
         tivity of policy control information requires reliable operation.
         Use of UDP would mandate specifying retry and fallback algorithms,
         which can be quite complicated. In addition, while timing

                A Framework for Policy-based Admission Control     Nov. 1998

         requirements for a user logging onto a network might permit a delay
         of several seconds
           ([REF]), ([5]), this will not be the case for reservations reserva-
         tions proceeding in the network. Moreover, acknowledgments are
         essential for actions like billing and accounting.

    *    Difficulty in carrying opaque objects: Use of RADIUS for QoS pol-
           icy policy
         control would require defining additional RADIUS * attri-
           butes. attributes. To
         carry opaque objects of variable length, the format of RADIUS
         attributes would have to be extended; it currently sup-
           ports supports four
         data types of pre-specified length; string, address, integer and
         time.

    *    No support for asynchronous notification: Asynchronous notifica-
           tion notification
         is required in order to allow both the policy server PDP and
           client a PEP 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 reserva-
         tion has to be terminated due to expira-
           tion 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.

    *    Restricted Message Types: The restriction to messages of type
         ``access-request'' and ``access-accept'' (or reject) does not
         facilitate information gathering for monitoring and accounting
           purposes. pur-
         poses. New message types would have to be defined.

    *    Multicast Groups: groups: It is not clear how requests from a group of
           multicast mul-
         ticast receivers could be handled in the context of RADIUS.

    *    Identifying Requests: Several changes will be needed in the way
         requests are identified. Currently this is done using a user
         name/IP address attribute. This might be too narrow for reserva-
           tion reservation
         protocols, i.e. one might need to specify a source port, a
           destination destina-
         tion address/port and provide some user credentials as well.

    *    QoS Specification: Changes will be needed to incorporate the new
         service (resource reservation) and the ability to specify the
         desired level of service (QoS, Tspec) Tspec).

                A Framework for Policy-based Admission Control     Nov. 1998

  In short, we believe that if the RADIUS protocol were to be used be used for the
  purpose of QoS policy control, the number of changes required would make
  the task as difficult or more than defining a new protocol designed with
  QoS reservations in mind.

  6.2.2. LDAP

  LDAP is very effective as a directory service protocol. Nevertheless, it
  restricts the flexibility of an implementation by requiring a very
  specific and well understood format of policy information and policy
  rules, common to both a policy server and a client (e.g., a standardized
  schema). The client must be able to interpret the format of policy infor-
  mation and rules directly.  In addition, LDAP is more suitable for access-
  ing directory information, information that is predefined and changes
  infrequently.

  Given the rather experimental state of policy control for QoS reservation
  protocols, the dynamic nature of policy decisions and rules and the limi-
  tations of clients (routers) in interpreting policy information, an LDAP
  based solution for client-server communication would be inadequate at this
  point. Also, a wider variety of policy element types and objects need to
  be represented using a policy control protocol than supported by LDAP.

  LDAP currently does not provide support for asynchronous notification from
  servers to clients and is not suitable for exchange of dynamic information
  such as policy state and resource usage information.

  However, LDAP could conceivably be used in downloading policy rules from
  an LDAP server to policy servers. Furthermore, future versions of LDAP
  promise to make it more suitable for the
    purpose exchange of dynamic information.
  As these modifications are introduced the role of LDAP in QoS policy control, con-
  trol could be reevaluated.

  6.2.3. SNMP

  SNMP was designed for the number specific purpose of changes required would make
    the task as difficult or more than defining a new protocol designed with
    QoS reservations in mind.

    6.2. LDAP

    LDAP is very effective as monitoring network devices
  from a directory service protocol. Nevertheless, central network management station (NMS). Our investigation of SNMP
  led us to believe that it
    restricts does not provide adequate support for the flexibility pur-
  pose of an implementation by requiring communication between a very
    specific PEP and well understood format its PDP for the following reasons:

  *    Lack of policy support for large messages: Policy information carried in
       messages exchanged between a PEP and a PDP typically consists of
       several policy
    rules, common to both elements. Each policy element itself may contain siz-
       able amount of information. For example, a Kerberos-based credential
       (a single policy server element) constitutes as many as 300-plus bytes of
       data. A single request for policy decision will contain several such

                A Framework for Policy-based Admission Control     Nov. 1998

       elements and some  additional information such as flowspecs and,
       thus, will add up to a client (e.g., large message. Similarly, a standardized
    schema). The client must be able to interpret report message
       containing monitoring information will also contain a large amount of
       information. Therefore, the format protocol must support reliable delivery
       of policy
    information large messages whereas SNMP only supports delivery of small mes-
       sages.

  *    Use of UDP as a transport protocol: SNMP uses UDP as the transport
       protocol and, as discussed earlier, UDP is not appropriate as a tran-
       sport protocol for this purpose and rules directly.  In addition, LDAP requires an additional protocol
       to ensure reliable delivery of large messages.

  *    Master-Slave relationship: SNMP is more suitable designed for
    accessing directory information, information that a Master-slave rela-
       tionship in which a Network Management Station (NMS) acts as a master
       for a group of devices. NMS is predefined always in charge and
    changes infrequently.

    Given the rather experimental state initiates any
       communication for retrieval of policy control monitoring information except for QoS reserva-
    tion protocols,
       traps that can be asynchronously generated by the dynamic nature of policy decisions and rules slave devices. The
       relationship between a PEP and its PDP, however, is not master-slave;
       PEP always initiates communication, requests decisions, or  sends
       reports, or re-negotiates a decision. In addition, the
    limitations of clients (routers) in interpreting policy information, an
    LDAP based solution for client-server communication would be inadequate
    at this point. Also, exchange
       between a wideer variety of policy element types PEP and
    objects need PDP is stateful and establishes shared state that
       is referred to be represented using a policy control protocol than sup-
    ported by LDAP.

    However, LDAP could conceivably be used in downloading policy rules from
    an LDAP server subsequent communication. SNMP does not support
       this style of communication.

  *    Lack of support for policy-specific errors:  SNMP provides support
       for generic errors whereas we need support for reporting errors
       specific to policy servers. Furthermore, future versions of LDAP
    promise data content (authentication failure) as well as
       errors specific to make it more suitable for the exchange of dynamic informa-
    tion. As these modifications are introduced the role of LDAP in QoS pol-
    icy control should be reevaluated. RSVP semantics.

  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 (Encapsu-
  lating Security Payload) protocols, in order to provide con-
    fidentiality, confidentiality,
  data origin authentication, integrity and replay preven-
    tion. prevention.

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

  8. References

                A Framework for Policy-based Admission Control     Nov. 1998

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

  [2] F. Baker., "RSVP Cryptographic Authentication", draft-ietf-rsvp-
    md5-05.txt, draft-ietf-rsvp-md5-
  05.txt, August 1997.

  [3] S. Herzog., "RSVP Extensions for Policy Control",  Internet Draft},
    draft-ietf-rsvp-policy-ext-02.[ps,txt], Apr. 1997.
  draft-ietf-rsvp-policy-ext-03.[ps,txt], August 1998.

  [4] R. Atkinson. Security Architecture for the Internet Protocol. RFC1825,
  Aug. 1995.

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

  [6] R. Rajan et al. Schema for Differentiated Services and Integrated Ser-
  vices in Networks, draft-rajan-policy-qosschema-00.txt, October 1998.

  [7] S. Herzog, "RSVP Preemption Priority Policy", Internet Draft, draft-
  ietf-rap-priority-00.txt, Nov. 1998.

  [8] S. Herzog, "COPS Usage for RSVP", Internet Draft, draft-ietf-rap-
  cops-rsvp-00.txt, August 1998.

  8. 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.

  9.  Authors` Addresses

          Raj Yavatkar
          Intel Corporation
          2111 N.E. 25th Avenue,
          Hillsboro, OR 97124
          USA
          phone: +1 503-264-9077
          email: yavatkar@ibeam.intel.com raj.yavatkar@intel.com

          Dimitrios Pendarakis
          IBM T.J. Watson Research Center
          P.O. Box 704
          Yorktown Heights
          NY 10598
          phone: +1 914-784-7536
          email: dimitri@watson.ibm.com dimitris@watson.ibm.com

                A Framework for Policy-based Admission Control     Nov. 1998

          Roch Guerin
            IBM T.J. Watson Research Center
            P.O. Box 704
            Yorktown Heights
            NY 10598
          University of Pennsylvania
          Dept. of Electrical Engineering
          200 South 33rd Street
          Philadelphia, PA  19104

          phone: +1 914-784-7038 215 898-9351
          email: guerin@watson.ibm.com guerin@ee.upenn.edu