draft-ietf-rap-framework-02.txt   rfc2753.txt 
Internet Engineering Task Force Raj Yavatkar, Intel Network Working Group R. Yavatkar
INTERNET-DRAFT Dimitrios Pendarakis, IBM Request for Comments: 2753 Intel
draft-ietf-rap-framework-02.txt Roch Guerin, U. Of Pennsylvania Category: Informational D. Pendarakis
IBM
April 1999 R. Guerin
Expires: December 1999 U. Of Pennsylvania
January 2000
A Framework for Policy-based Admission Control
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A Framework for Policy-based Admission Control March 1999
1. Abstract
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 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. We argue
that policy-based control must be applicable to different kinds and 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 speci-
fies the requirements for a client-server protocol for communication
between a policy server (PDP) and its client (PEP) and evaluates suitabil-
ity of some of the existing protocols for this purpose.
A Framework for Policy-based Admission Control March 1999
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 in a request or response related to resource
allocation decision.
- Policy Element: Subdivision of policy objects; contains single A Framework for Policy-based Admission Control
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 March 1999 Status of this Memo
of which QoS signaling protocol is used. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
- Policy Decision Point (PDP): The point where policy decisions are Copyright Notice
made.
- Policy Enforcement Point (PEP): The point where the policy deci- Copyright (C) The Internet Society (2000). All Rights Reserved.
sions are actually enforced.
- Policy Ignorant Node (PIN): A network element that does not expli- 1. Introduction
citly support policy control using the mechanisms defined in this
document.
- Resource: Something of value in a network infrastructure to which The IETF working groups such as Integrated Services (called "int-
rules or policy criteria are first applied before access is serv") and RSVP [1] have developed extensions to the IP architecture
granted. Examples of resources include the buffers in a router and and the best-effort service model so that applications or end users
bandwidth on an interface. 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-
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.
- Service Provider: Controls the network infrastructure and may be This document is concerned with specifying a framework for providing
responsible for the charging and accounting of services. 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.
- Soft State Model - Soft state is a form of the stateful model that We begin with a list of definitions in Section 2. Section 3 lists the
times out installed state at a PEP or PDP. It is an automatic way requirements and goals of the mechanisms used to control and enforce
to erase state in the presence of communication or network element access to better QoS. We then outline the architectural elements of
failures. For example, RSVP uses the soft state model for instal- the framework in Section 4 and describe the functionality assumed for
ling reservation state at network elements along the path of a data each component. Section 5 discusses example policies, possible
flow. 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.
- Installed State: A new and unique request made from a PEP to a PDP 2. Terminology
that must be explicitly deleted.
- Trusted Node: A node that is within the boundaries of an adminis- The following is a list of terms used in this document.
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 - Administrative Domain: A collection of networks under the same
administrative control and grouped together for administrative
purposes.
A Framework for Policy-based Admission Control March 1999 - 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 section, we describe the goals and requirements of mechanisms and In this document, we use the terms router, network element, and
protocols designed to provide policy-based control over admission control network node interchangeably, but the should all be interpreted as
decisions. references to a network element.
- Policies vs Mechanisms: An important point to note is that the - QoS Signaling Protocol: A signaling protocol that carries an
framework does not include any discussion of any specific policy admission control request for a resource, e.g., RSVP.
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- - Policy: The combination of rules and services where rules define
based control requirements specific to the problem of bandwidth the criteria for resource access and usage.
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- - Policy control: The application of rules to determine whether or
port for preemption. By preemption, we mean an ability to remove a not access to a particular resource should be granted.
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 - Policy Object: Contains policy-related information such as policy
include support for many policies and policy configurations includ- elements and is carried in a request or response related to a
ing bi-lateral and multi-lateral service agreements and policies resource allocation decision.
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 mechan- - Policy Element: Subdivision of policy objects; contains single
isms must include support for monitoring policy state, resource units of information necessary for the evaluation of policy rules.
usage, and provide access information. In particular, mechanisms A single policy element may carry an user or application
must be included to provide usage and access information that may identification whereas another policy element may carry user
be used for accounting and billing purposes. credentials or credit card information. The policy elements
themselves are expected to be independent of which QoS signaling
protocol is used.
- Fault tolerance and recovery: The mechanisms designed on the basis - Policy Decision Point (PDP): The point where policy decisions are
of this framework must include provisions for fault tolerance and made.
recovery from failure cases such as failure of PDPs, disruption in
A Framework for Policy-based Admission Control March 1999 - Policy Enforcement Point (PEP): The point where the policy
decisions are actually enforced.
communication including network partitions (and subsequent merging) - Policy Ignorant Node (PIN): A network element that does not
that separate a PDP from its peer PEPs. explicitly support policy control using the mechanisms defined in
this document.
- Support for Policy-Ignorant Nodes (PINs): Support for the mechan- - Resource: Something of value in a network infrastructure to which
isms described in this document should not be mandatory for every rules or policy criteria are first applied before access is
node in a network. Policy based admission control could be enforced granted. Examples of resources include the buffers in a router and
at a subset of nodes, for example the boundary nodes within an bandwidth on an interface.
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 - Service Provider: Controls the network infrastructure and may be
designed for policy control is scalability. The mechanisms must responsible for the charging and accounting of services.
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 - Soft State Model - Soft state is a form of the stateful model that
architecture must be secure as far as the following aspects are times out installed state at a PEP or PDP. It is an automatic way
concerned. First, the mechanisms proposed under the framework must to erase state in the presence of communication or network element
minimize theft and denial of service threats. Second, it must be failures. For example, RSVP uses the soft state model for
ensured that the entities (such as PEPs and PDPs) involved in pol- installing reservation state at network elements along the path of
icy control can verify each other's identity and establish neces- a data flow.
sary trust before communicating.
4. Architectural Elements - Installed State: A new and unique request made from a PEP to a PDP
that must be explicitly deleted.
The two main architectural elements for policy control are the PEP (Policy - 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.
A Framework for Policy-based Admission Control March 1999 3. Policy-based Admission Control: Goals and Requirements
Enforcement Point) and the PDP (Policy Decision Point). Figure 1 shows a In this section, we describe the goals and requirements of mechanisms
simple configuration involving these two elements; PEP is a component at a and protocols designed to provide policy-based control over admission
network node and PDP is a remote entity that may reside at a policy control decisions.
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 additional mechanisms and
protocols and how they are used.
The basic interaction between the components begins with the PEP. The PEP - Policies vs Mechanisms: An important point to note is that the
will receive a notification or a message that requires a policy decision. framework does not include any discussion of any specific policy
Given such an event, the PEP then formulates a request for a policy deci- behavior or does not require use of specific policies. Instead,
sion and sends it to the PDP. The request for policy control from a PEP the framework only outlines the architectural elements and
to the PDP may contain one or more policy elements (encapsulated into one mechanisms needed to allow a wide variety of possible policies to
or more policy objects) in addition to the admission control information be carried out.
(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 - RSVP-specific: The mechanisms must be designed to meet the
| | ______ policy-based control requirements specific to the problem of
| Network Node | | |-------------> bandwidth reservation using RSVP as the signaling protocol.
| _____ | | | May use LDAP,SNMP,.. for accessing However, our goal is to allow for the application of this
| | | | | | policy database, authentication,etc. framework for admission control involving other types of resources
| | PEP |<-----|------->| PDP |-------------> and QoS services (e.g., Diff-Serv) as long as we do not diverge
| |_____| | |_____| from our central goal.
| |
|________________|
Figure 1: A simple configuration with the primary policy control - Support for preemption: The mechanisms designed must include
architecture components. PDP may use additional mechanisms and protocols support for preemption. By preemption, we mean an ability to
for the purpose of accounting, authentication, policy storage, etc. 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.
The PDP might optionally contact other external servers, e.g., for access- - Support for many styles of policies: The mechanisms designed must
ing configuration, user authentication, accounting and billing databases. include support for many policies and policy configurations
Protocols defined for network management (SNMP) or directory access (LDAP) including bi-lateral and multi-lateral service agreements and
might be used for this communication. While the specific type of access policies based on the notion of relative priority. In general,
and the protocols used may vary among different implementations, some of the determination and configuration of viable policies are the
responsibility of the service provider.
A Framework for Policy-based Admission Control March 1999 - 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.
these interactions will have network-wide implications and could impact - Fault tolerance and recovery: The mechanisms designed on the basis
the interoperability of different devices. 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.
Of particular importance is the "language" used to specify the policies - Support for Policy-Ignorant Nodes (PINs): Support for the
implemented by the PDP. The number of policies applicable at a network mechanisms described in this document should not be mandatory for
node might potentially be quite large. At the same time, these policies every node in a network. Policy based admission control could be
will exhibit high complexity, in terms of number of fields used to arrive enforced at a subset of nodes, for example the boundary nodes
at a decision, and the wide range of decisions. Furthermore, it is likely within an administrative domain. These policy capable nodes would
that several policies could be applicable to the same request profile. For function as trusted nodes from the point of view of the policy-
example, a policy may prescribe the treatment of requests from a general ignorant nodes in that administrative domain.
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 - Scalability: One of the important requirements for the mechanisms
coherent and consistent application of policies network-wide, the policy designed for policy control is scalability. The mechanisms must
specification language should ensure unambiguous mapping of a request pro- scale at least to the same extent that RSVP scales in terms of
file to a policy action. It should also permit the specification of the accommodating multiple flows and network nodes in the path of a
sequence in which different policy rules should be applied and/or the flow. In particular, scalability must be considered when
priority associated with each one. Some of these issues are addressed in specifying default behavior for merging policy data objects and
[6]. 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.
In some cases, the simple configuration shown in Figure 1 may not be suf- - Security and denial of service considerations: The policy control
ficient as it might be necessary to apply local policies (e.g., policies architecture must be secure as far as the following aspects are
specified in access control lists) in addition to the policies applied at concerned. First, the mechanisms proposed under the framework must
the remote PDP. In addition, it is possible for the PDP to be co-located minimize theft and denial of service threats. Second, it must be
with the PEP at the same network node. Figure 2 shows the possible confi- ensured that the entities (such as PEPs and PDPs) involved in
gurations. policy control can verify each other's identity and establish
necessary trust before communicating.
The configurations shown in Figures 1 and 2 illustrate the flexibility in 4. Architectural Elements
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 March 1999 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
may reside at a policy server. The PEP represents the component that
always runs on the policy aware node. It is the point at which policy
decisions are actually enforced. Policy decisions are made primarily
at the PDP. The PDP itself may make use of additional mechanisms and
protocols to achieve additional functionality such as user
authentication, accounting, policy information storage, etc. For
example, the PDP is likely to use an LDAP-based directory service for
storage and retrieval of policy information[6]. This document does
not include discussion of these additional mechanisms and protocols
and how they are used.
________________ ____________________ The basic interaction between the components begins with the PEP. The
| | | | PEP will receive a notification or a message that requires a policy
| Network Node | Policy Server | Network Node | decision. Given such an event, the PEP then formulates a request for
| _____ | _____ | _____ _____ | a policy decision and sends it to the PDP. The request for policy
| | | | | | | | | | | | control from a PEP to the PDP may contain one or more policy elements
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | | (encapsulated into one or more policy objects) in addition to the
| |_____| | |_____| | |_____| |_____| | admission control information (such as a flowspec or amount of
| ^ | | | bandwidth requested) in the original message or event that triggered
| | _____ | |____________________| the policy decision request. The PDP returns the policy decision and
| \-->| | | the PEP then enforces the policy decision by appropriately accepting
| | LPDP| | or denying the request. The PDP may also return additional
| |_____| | information to the PEP which includes one or more policy elements.
| | This information need not be associated with an admission control
|________________| decision. Rather, it can be used to formulate an error message or
outgoing/forwarded message.
Figure 2: Two other possible configurations of policy control ________________ Policy server
architecture components. The configuration on left shows a local decision | | ______
point at a network node and the configuration on the left shows PEP and | Network Node | | |------------->
PDP co-located at the same node. | _____ | | | May use LDAP,SNMP,.. for accessing
| | | | | | policy database, authentication,etc.
| | PEP |<-----|------->| PDP |------------->
| |_____| | |_____|
| |
|________________|
If it is available, the PEP will first use the LPDP to reach a local deci- Figure 1: A simple configuration with the primary policy control
sion. This partial decision and the original policy request are next sent architecture components. PDP may use additional mechanisms and
to the PDP which renders a final decision (possibly, overriding the protocols for the purpose of accounting, authentication, policy
LPDP). It must be noted that the PDP acts as the final authority for the storage, etc.
decision returned to the PEP and the PEP must enforce the decision 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 The PDP might optionally contact other external servers, e.g., for
left in Figure 2 in the rest of this document. accessing configuration, user authentication, accounting and billing
databases. Protocols defined for network management (SNMP) or
directory access (LDAP) might be used for this communication. While
the specific type of access and the protocols used may vary among
different implementations, some of these interactions will have
network-wide implications and could impact the interoperability of
different devices.
Under this policy control model, the PEP module at a network node must use Of particular importance is the "language" used to specify the
the following steps to reach a policy decision: policies implemented by the PDP. The number of policies applicable at
a network node might potentially be quite large. At the same time,
these policies will exhibit high complexity, in terms of number of
fields used to arrive at a decision, and the wide range of decisions.
Furthermore, it is likely that several policies could be applicable
to the same request profile. For example, a policy may prescribe the
treatment of requests from a general user group (e.g., employees of a
company) as well as the treatment of requests from specific members
of that group (e.g., managers of the company). In this example, the
user profile "managers" falls within the specification of two
policies, one general and one more specific.
1. When a local event or message invokes PEP for a policy decision, In order to handle the complexity of policy decisions and to ensure a
the PEP creates a request that includes information from the mes- coherent and consistent application of policies network-wide, the
sage (or local state) that describes the admission control request. policy specification language should ensure unambiguous mapping of a
In addition, the request includes appropriate policy elements as request profile to a policy action. It should also permit the
described below. 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].
2. The PEP may consult a local configuration database to identify a In some cases, the simple configuration shown in Figure 1 may not be
set of policy elements (called set A) that are to be evaluated sufficient as it might be necessary to apply local policies (e.g.,
locally. The local configuration specifies the types of policy ele- policies specified in access control lists) in addition to the
ments that are evaluated locally. The PEP passes the request with policies applied at the remote PDP. In addition, it is possible for
the PDP to be co-located with the PEP at the same network node.
Figure 2 shows the possible configurations.
A Framework for Policy-based Admission Control March 1999 The configurations shown in Figures 1 and 2 illustrate the
flexibility in division of labor. On one hand, a centralized policy
server, which could be responsible for policy decisions on behalf of
multiple network nodes in an administrative domain, might be
implementing policies of a wide scope, common across the AD. On the
other hand, policies which depend on information and conditions local
to a particular router and which are more dynamic, might be better
implemented locally, at the router.
the set A to the Local Decision point (LPDP) and collects the ________________ ____________________
result of the LPDP (called "partial result" and referred to as D(A) | | | |
). | Network Node | Policy Server | Network Node |
| _____ | _____ | _____ _____ |
| | | | | | | | | | | |
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | |
| |_____| | |_____| | |_____| |_____| |
| ^ | | |
| | _____ | |____________________|
| \-->| | |
| | LPDP| |
| |_____| |
| |
|________________|
3. The PEP then passes the request with ALL the policy elements and Figure 2: Two other possible configurations of policy control
D(A) to the PDP. The PDP applies policies based on all the policy architecture components. The configuration on the left shows a local
elements and the request and reaches a decision (let us call it decision point at a network node and the configuration on the right
D(Q)). It then combines its result with the partial result D(A) shows PEP and PDP co-located at the same node.
using a combination operation to reach a final decision.
4. The PDP returns the final policy decision (one after the combina- If it is available, the PEP will first use the LPDP to reach a local
tion operation) to the PEP. decision. This partial decision and the original policy request are
next sent to the PDP which renders a final decision (possibly,
overriding the LPDP). It must be noted that the PDP acts as the final
authority for the decision returned to the PEP and the PEP must
enforce the decision rendered by the PDP. Finally, if a shared state
has been established for the request and response between the PEP and
PDP, it is the responsibility of the PEP to notify the PDP that the
original request is no longer in use.
Note that in the above model, the PEP *must* contact the PDP even if no Unless otherwise specified, we will assume the configuration shown on
(or NULL) policy objects are received in the admission control request. the left in Figure 2 in the rest of this document.
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 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 Under this policy control model, the PEP module at a network node
notification to the PEP to change its earlier decision or to generate a must use the following steps to reach a policy decision:
policy error/warning message.
4.1. Example of a RSVP Router 1. When a local event or message invokes PEP for a policy decision,
the PEP creates a request that includes information from the
message (or local state) that describes the admission control
request. In addition, the request includes appropriate policy
elements as described below.
In the case of a RSVP router, Figure 3 shows the interaction between a PEP 2. The PEP may consult a local configuration database to identify a
and other int-serv components within the router. For the purpose of this set of policy elements (called set A) that are to be evaluated
discussion, we represent all the components of RSVP-related processing by locally. The local configuration specifies the types of policy
a single RSVP module, but more detailed discussion of the exact interac- elements that are evaluated locally. The PEP passes the request
tion and interfaces between RSVP and PEP will be described in a separate with the set A to the Local Decision point (LPDP) and collects the
document [3]. result of the LPDP (called "partial result" and referred to as
D(A) ).
A Framework for Policy-based Admission Control March 1999 3. The PEP then passes the request with ALL the policy elements and
D(A) to the PDP. The PDP applies policies based on all the policy
elements and the request and reaches a decision (let us call it
D(Q)). It then combines its result with the partial result D(A)
using a combination operation to reach a final decision.
______________________________ 4. The PDP returns the final policy decision (obtained from the
| | combination operation) to the PEP.
| Router |
| ________ _____ | _____
| | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____|
| ^ |
| | Traffic control |
| | _____________ |
| \---->| _________ | |
| | |capacity | | |
| | | ADM CTL | | |
| | |_________| | |
--|----------->| ____ ____ | |
| Data | | PC | PS | | |
| | |____|____| | |
| |_____________| |
| |
|______________________________|
Figure 3: Relationship between PEP and other int-serv components Note that in the above model, the PEP MUST contact the PDP even if no
within an RSVP router. PC -- Packet Classifier, PS -- Packet Scheduler (or NULL) policy objects are received in the admission control
request. This requirement helps ensure that a request cannot bypass
policy control by omitting policy elements in a reservation request.
However, "short circuit" processing is permitted, i.e., if the result
of D(A), above, is "no", then there is no need to proceed with
further policy processing at the PDP. Still, the PDP must be informed
of the failure of local policy processing. The same applies to the
case when policy processing is successful but admission control (at
the resource management level due to unavailable capacity) fails;
again the PDP has to be informed of the failure.
When a RSVP message arrives at the router (or an RSVP related event It must also be noted that the PDP may, at any time, send an
requires a policy decision), the RSVP module is expected to hand off the asynchronous notification to the PEP to change an earlier decision or
request (corresponding to the event or message) to its PEP module. The PEP to generate a policy error/warning message.
will use the PDP (and LPDP) to obtain the policy decision and communicate
it back to the RSVP module.
4.2. Additional functionality at the PDP 4.1. Example of a RSVP Router
Typically, PDP returns the final policy decision based on an admission In the case of a RSVP router, Figure 3 shows the interaction between
control request and the associated policy elements. However, it should be a PEP and other int-serv components within the router. For the
possible for the PDP to sometimes ask the PEP (or the admission control purpose of this discussion, we represent all the components of RSVP-
module at the network element where PEP resides) to generate policy- related processing by a single RSVP module, but a more detailed
related error messages. For example, in the case of RSVP, the PDP may discussion of the exact interaction and interfaces between RSVP and
accept a request and allow installation and forwarding of a reservation to the PEP is provided in a separate document [3].
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 March 1999 ______________________________
| |
| Router |
| ________ _____ | _____
| | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____|
| ^ |
| | Traffic control |
| | _____________ |
| \---->| _________ | |
| | |capacity | | |
| | | ADM CTL | | |
| | |_________| | |
--|----------->| ____ ____ | |
| Data | | PC | PS | | |
| | |____|____| | |
| |_____________| |
| |
|______________________________|
1. the message that generated the admission control request should be Figure 3: Relationship between PEP and other int-serv components
processed further as usual, but an error message (or warning) be sent in within an RSVP router. PC -- Packet Classifier, PS -- Packet
the other direction and include the policy objects supplied in that Scheduler
error message
2. or, specifies that an error be returned, but the RSVP message should When a RSVP message arrives at the router (or an RSVP related event
not be forwarded as usual. requires a policy decision), the RSVP module is expected to hand off
the request (corresponding to the event or message) to its PEP
module. The PEP will use the PDP (and LPDP) to obtain the policy
decision and communicate it back to the RSVP module.
4.3. Interactions between PEP, LPDP, and PDP at a RSVP router 4.2. Additional functionality at the PDP
All the details of RSVP message processing and associated interactions Typically, PDP returns the final policy decision based on an
between different elements at an RSVP router (PEP, LPDP) and PDP are admission control request and the associated policy elements.
included in separate documents [3,8]. In the following, a few, salient However, it should be possible for the PDP to sometimes ask the PEP
points related to the framework are listed: (or the admission control module at the network element where PEP
resides) to generate policy-related error messages. For example, in
the case of RSVP, the PDP may accept a request and allow installation
and forwarding of a reservation to a previous hop, but, at the same
time, may wish to generate a warning/error message to a downstream
node (NHOP) to warn about conditions such as "your request may have
to be torn down in 10 mins, etc." Basically, an ability to create
policy-related errors and/or warnings and to propagate them using the
native QoS signaling protocol (such as RSVP) is needed. Such a policy
error returned by the PDP must be able to also specify whether the
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:
* LPDP is optional and may be used for making decisions based on pol- 1. the message that generated the admission control request should
icy elements handled locally. The LPDP, in turn, may have to go to be processed further as usual, but an error message (or warning)
external entities (such as a directory server or an authentication be sent in the other direction and include the policy objects
server, etc.) for making its decisions. supplied in that error message
* PDP is stateful and may make decisions even if no policy objects 2. or, specifies that an error be returned, but the RSVP message
are received (e.g., make decisions based on information such as should not be forwarded as usual.
flowspecs and session object in the RSVP messages). The PDP may
consult other PDPs, but discussion of inter-PDP communication and
coordination is outside the scope of this document.
* PDP sends asynchronous notifications to PEP whenever necessary to 4.3. Interactions between PEP, LPDP, and PDP at a RSVP router
change earlier decisions, generate errors etc.
* PDP exports the information useful for usage monitoring and All the details of RSVP message processing and associated
accounting purposes. An example of a useful mechanism for this pur- interactions between different elements at an RSVP router (PEP, LPDP)
pose is a MIB or a relational database. However, this document does and PDP are included in separate documents [3,8]. In the following, a
not specify any particular mechanism for this purpose and discus- few, salient points related to the framework are listed:
sion of such mechanisms is out of the scope of this document.
4.4. Placement of Policy Elements in a Network * LPDP is optional and may be used for making decisions based on
policy elements handled locally. The LPDP, in turn, may have to go
to external entities (such as a directory server or an
authentication server, etc.) for making its decisions.
A Framework for Policy-based Admission Control March 1999 * 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.
By allowing division of labor between an LPDP and a PDP, the policy con- * PDP sends asynchronous notifications to PEP whenever necessary to
trol architecture allows staged deployment by enabling routers of varying change earlier decisions, generate errors etc.
degrees of sophistication, as far as policy control is concerned, to com-
municate with policy servers. Figure 4 depicts an example set of nodes
belonging to three different administrative domains (AD) (Each AD could
correspond to a different service provider in this case). Nodes A, B and
C belong to administrative domain AD-1, advised by PDP PS-1, while D and E
belong to AD-2 and AD-3, respectively. E communicates with PDP PS-3. In
general, it is expected that there will be at least one PDP per adminis-
trative domain.
Policy capable network nodes could range from very unsophisticated, such * PDP exports the information useful for usage monitoring and
as E, which have no LPDP, and thus have to rely on an external PDP for accounting purposes. An example of a useful mechanism for this
every policy processing operation, to self-sufficient, such as D, which purpose is a MIB or a relational database. However, this document
essentially encompasses both an LPDP and a PDP locally, at the router. does not specify any particular mechanism for this purpose and
discussion of such mechanisms is out of the scope of this
document.
AD-1 AD-2 AD-3 4.4. Placement of Policy Elements in a Network
________________/\_______________ __/\___ __/\___
{ } { } { }
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 By allowing division of labor between an LPDP and a PDP, the policy
control architecture allows staged deployment by enabling routers of
varying degrees of sophistication, as far as policy control is
concerned, to communicate with policy servers. Figure 4 depicts an
example set of nodes belonging to three different administrative
domains (AD) (Each AD could correspond to a different service
provider in this case). Nodes A, B and C belong to administrative
domain AD-1, advised by PDP PS-1, while D and E belong to AD-2 and
AD-3, respectively. E communicates with PDP PS-2. In general, it is
expected that there will be at least one PDP per administrative
domain.
5. Example Policies, Scenarios, and Policy Support Policy capable network nodes could range from very unsophisticated,
such as E, which have no LPDP, and thus have to rely on an external
PDP for every policy processing operation, to self-sufficient, such
as D, which essentially encompasses both an LPDP and a PDP locally,
at the router.
In the following, we present examples of desired policies and scenarios AD-1 AD-2 AD-3
requiring policy control that should possibly be addressed by the policy ________________/\_______________ __/\___ __/\___
{ } { } { }
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
A Framework for Policy-based Admission Control March 1999 Figure 4: Placement of Policy Elements in an internet
control framework. In some cases, possible approach(es) for achieving the 5. Example Policies, Scenarios, and Policy Support
desired goals are also outlined with a list of open issues to be resolved.
5.1. Admission control policies based on factors such as Time-of-Day, User In the following, we present examples of desired policies and
Identity, or credentials scenarios requiring policy control that the policy control framework
should be able to support. In some cases, possible approach(es) for
achieving the desired goals are also outlined with a list of open
issues to be resolved.
Policy control must be able to express and enforce rules with temporal 5.1. Admission control policies based on factors such as Time-of-Day,
dependencies. For example, a group of users might be allowed to make User Identity, or credentials.
reservations at certain levels only during off-peak hours. In addition,
the policy control must also support policies that take into account iden-
tity or credentials of users requesting a particular service or resource.
For example, an RSVP reservation request may be denied or accepted based
on the credentials or identity supplied in the request.
5.2. Bilateral agreements between service providers Policy control must be able to express and enforce rules with
temporal dependencies. For example, a group of users might be allowed
to make reservations at certain levels only during off-peak hours.
In addition, the policy control must also support policies that take
into account identity or credentials of users requesting a particular
service or resource. For example, an RSVP reservation request may be
denied or accepted based on the credentials or identity supplied in
the request.
Until recently, usage agreements between service providers for traffic 5.2. Bilateral agreements between service providers
crossing their boundaries have been quite simple. For example, two ISPs
might agree to accept all traffic from each other, often without perform-
ing any accounting or billing for the ``foreign'' traffic carried. How-
ever, with the availability of QoS mechanisms based on Integrated and Dif-
ferentiated Services, traffic differentiation and quality of service
guarantees are being phased into the Internet. As ISPs start to sell their
customers different grades of service and can differentiate among dif-
ferent sources of traffic, they will also seek mechanisms for charging
each other for traffic (and reservations) transiting their networks. One
additional incentive in establishing such mechanisms is the potential
asymmetry in terms of the customer base that different providers will
exhibit: ISPs focused on servicing corporate traffic are likely to experi-
ence much higher demand for reserved services than those that service the
consumer market. Lack of sophisticated accounting schemes for inter-ISP
traffic could lead to inefficient allocation of costs among different ser-
vice providers.
Bilateral agreements could fall into two broad categories; local or glo- Until recently, usage agreements between service providers for
bal. Due to the complexity of the problem, it is expected that initially traffic crossing their boundaries have been quite simple. For
only the former will be deployed. In these, providers which manage a net- example, two ISPs might agree to accept all traffic from each other,
work cloud or administrative domain contract with their closest point of often without performing any accounting or billing for the "foreign"
contact (neighbor) to establish ground rules and arrangements for access traffic carried. However, with the availability of QoS mechanisms
control and accounting. These contracts are mostly local and do not rely based on Integrated and Differentiated Services, traffic
on global agreements; consequently, a policy node maintains information differentiation and quality of service guarantees are being phased
about its neighboring nodes only. Referring to Figure 4, this model into the Internet. As ISPs start to sell their customers different
implies that provider AD-1 has established arrangements with AD-2, but not grades of service and can differentiate among different sources of
with AD-3, for usage of each other's network. Provider AD-2, in turn, has traffic, they will also seek mechanisms for charging each other for
in place agreements with AD-3 and so on. Thus, when forwarding a reserva- traffic (and reservations) transiting their networks. One additional
tion request to AD-2, provider AD-2 will charge AD-1 for use of all incentive in establishing such mechanisms is the potential asymmetry
resources beyond AD-1's network. This information is obtained by in terms of the customer base that different providers will exhibit:
ISPs focused on servicing corporate traffic are likely to experience
much higher demand for reserved services than those that service the
consumer market. Lack of sophisticated accounting schemes for inter-
ISP traffic could lead to inefficient allocation of costs among
different service providers.
A Framework for Policy-based Admission Control March 1999 Bilateral agreements could fall into two broad categories; local or
global. Due to the complexity of the problem, it is expected that
initially only the former will be deployed. In these, providers which
manage a network cloud or administrative domain contract with their
closest point of contact (neighbor) to establish ground rules and
arrangements for access control and accounting. These contracts are
mostly local and do not rely on global agreements; consequently, a
policy node maintains information about its neighboring nodes only.
Referring to Figure 4, this model implies that provider AD-1 has
established arrangements with AD-2, but not with AD-3, for usage of
each other's network. Provider AD-2, in turn, has in place agreements
with AD-3 and so on. Thus, when forwarding a reservation request to
AD-2, provider AD-2 will charge AD-1 for use of all resources beyond
AD-1's network. This information is obtained by recursively applying
the bilateral agreements at every boundary between (neighboring)
providers, until the recipient of the reservation request is reached.
To implement this scheme under the policy control architecture,
boundary nodes have to add an appropriate policy object to the RSVP
message before forwarding it to a neighboring provider's network.
This policy object will contain information such as the identity of
the provider that generated them and the equivalent of an account
number where charges can be accumulated. Since agreements only hold
among neighboring nodes, policy objects have to be rewritten as RSVP
messages cross the boundaries of administrative domains or provider's
networks.
recursively applying the bilateral agreements at every boundary between 5.3. Priority based admission control policies
(neighboring) providers, until the recipient of the reservation request is
reached. To implement this scheme under the policy control architecture,
boundary nodes have to add an appropriate policy object to the RSVP mes-
sage before forwarding it to a neighboring provider's network. This policy
object will contain information such as the identity of the provider that
generated them and the equivalent of an account number where charges can
be accumulated. Since agreements only hold among neighboring nodes, policy
objects have to be rewritten as RSVP messages cross the boundaries of
administrative domains or provider's networks.
5.3. Priority based admission control policies In many settings, it is useful to distinguish between reservations on
the basis of some level of "importance". For example, this can be
useful to avoid that the first reservation being granted the use of
some resources, be able to hog those resources for some indefinite
period of time. Similarly, this may be useful to allow emergency
calls to go through even during periods of congestion. Such
functionality can be supported by associating priorities with
reservation requests, and conveying this priority information
together with other policy information.
In many settings, it is useful to distinguish between reservations on the In its basic form, the priority associated with a reservation
basis of some level of "importance". For example, this can be useful to directly determines a reservation's rights to the resources it
avoid that the first reservation being granted the use of some resources, requests. For example, assuming that priorities are expressed
be able to hog those resources for some indefinite period of time. Simi- through integers in the range 0 to 32 with 32 being the highest
larly, this may be useful to allow emergency calls to go through even dur- priority, a reservation of priority, say, 10, will always be
ing periods of congestion. Such functionality can be supported by associ- accepted, if the amount of resources held by lower priority
ating priorities with reservation requests, and conveying this priority reservations is sufficient to satisfy its requirements. In other
information together with other policy information. words, in case there are not enough free resources (bandwidth,
buffers, etc.) at a node to accommodate the priority 10 request, the
node will attempt to free up the necessary resources by preempting
existing lower priority reservations.
In its basic form, the priority associated with a reservation directly There are a number of requirements associated with the support of
determines a reservation's rights to the resources it requests. For exam- priority and their proper operation. First, traffic control in the
ple, assuming that priorities are expressed through integers in the range router needs to be aware of priorities, i.e., classify existing
0 to 32 with 32 being the highest priority, a reservation of priority, reservations according to their priority, so that it is capable of
say, 10, will always be accepted, if the amount of resources held by lower determining how many and which ones to preempt, when required to
priority reservations is sufficient to satisfy its requirements. In other accommodate a higher priority reservation request. Second, it is
words, in case there are not enough free resources (bandwidth, buffers, important that preemption be made consistently at different nodes, in
etc.) at a node to accommodate the priority 10 request, the node will order to avoid transient instabilities. Third and possibly most
attempt to free up the necessary resources by preempting existing lower important, merging of priorities needs to be carefully architected
priority reservations. and its impact clearly understood as part of the associated policy
definition.
There are a number of requirements associated with the support of priority Of the three above requirements, merging of priority information is
and their proper operation. First, traffic control in the router needs to the more complex and deserves additional discussions. The complexity
be aware of priorities, i.e., classify existing reservations according to of merging priority information arises from the fact that this
their priority, so that it is capable of determining how many and which merging is to be performed in addition to the merging of reservation
ones to preempt, when required to accommodate a higher priority reserva- information. When reservation (FLOWSPEC) information is identical,
tion request. Second, it is important that preemption be made con- i.e., homogeneous reservations, merging only needs to consider
sistently at different nodes, in order to avoid transient instabilities. priority information, and the simple rule of keeping the highest
Third and possibly most important, merging of priorities needs to be care- priority provides an adequate answer. However, in the case of
fully architected and its impact clearly understood as part of the associ- heterogeneous reservations, the *two-dimensional nature* of the
ated policy definition. (FLOWSPEC, priority) pair makes their ordering, and therefore
merging, difficult. A description of the handling of different cases
of RSVP priority objects is presented in [7].
Of the three above requirements, merging of priority information is the 5.4. Pre-paid calling card or Tokens
more complex and deserves additional discussions. The complexity of merg-
ing priority information arises from the fact that this merging is to be
performed in addition to the merging of reservation information. When
A Framework for Policy-based Admission Control March 1999 A model of increasing popularity in the telephone network is that of
the pre-paid calling card. This concept could also be applied to the
Internet; users purchase "tokens" which can be redeemed at a later
time for access to network services. When a user makes a reservation
request through, say, an RSVP RESV message, the user supplies a
unique identification number of the "token", embedded in a policy
object. Processing of this object at policy capable routers results
in decrementing the value, or number of remaining units of service,
of this token.
reservation (FLOWSPEC) information is identical, i.e., homogeneous reser- Referring to Figure 4, suppose receiver R1 in the administrative
vations, merging only needs to consider priority information, and the sim- domain AD3 wants to request a reservation for a service originating
ple rule of keeping the highest priority provides an adequate answer. in AD1. R1 generates a policy data object of type PD(prc, CID), where
However, in the case of heterogeneous reservations, the * two-dimensional "prc" denotes pre-paid card and CID is the card identification
nature} of the (FLOWSPEC, priority) pair makes their ordering, and there- number. Along with other policy objects carried in the RESV message,
fore merging, difficult. A description of the handling of different cases this object is received by node E, which forwards it to its PEP,
of RSVP priority objects is presented in [7]. PEP_E, which, in turn, contacts PDP PS-3. PS-3 either maintains
locally, or has remote access to, a database of pre-paid card
numbers. If the amount of remaining credit in CID is sufficient, the
PDP accepts the reservation and the policy object is returned to
PEP_E. Two issues have to be resolved here:
5.4. Pre-paid calling card or Tokens * What is the scope of these charges?
A model of increasing popularity in the telephone network is that of the * When are charges (in the form of decrementing the remaining
pre-paid calling card. This concept could also be applied to the Internet; credit) first applied?
users purchase ``tokens'' which can be redeemed at a later time for access
to network services. When a user makes a reservation request through, say,
an RSVP RESV message, the user supplies a unique identification number of
the ``token'', embedded in a policy object. Processing of this object at
policy capable routers results in decrementing the value, or number of
remaining units of service, of this token.
Referring to Figure 4, suppose receiver R1 in the administrative domain The answer to the first question is related to the bilateral
AD3 wants to request a reservation for a service originating in AD1. R1 agreement model in place. If, on the one hand, provider AD-3 has
generates a policy data object of type PD(prc, CID), where ``prc'' denotes established agreements with both AD-2 and AD-1, it could charge for
pre-paid card and CID is the card identification number. Along with other the cost of the complete reservation up to sender S1. In this case
policy objects carried in the RESV message, this object is received by PS-2 removes the PD(prc,CID) object from the outgoing RESV message.
node E, which forwards it to its PEP, PEP_E, which, in turn, contacts PDP
PS-3. PS-3 either maintains locally, or has remote access to, a database
of pre-paid card numbers. If the amount of remaining credit in CID is suf-
ficient, the PDP accepts the reservation and the policy object is returned
to PEP_E. Two issues have to be resolved here:
* What is the scope of these charges? On the other hand, if AD-3 has no bilateral agreements in place, it
will simply charge CID for the cost of the reservation within AD-3
and then forward PD(prc,CID) in the outgoing RESV message. Subsequent
PDPs in other administrative domains will charge CID for their
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.
* When are charges (in the form of decrementing the remaining credit) Another problem in this scenario is determining when the credit is
first applied? 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.
The answer to the first question is related to the bilateral agreement Regarding the issue of when to initiate charging, ideally that should
model in place. If, on the one hand, provider AD-3 has established agree- happen only after the reservation request has succeeded. In the case
ments with both AD-2 and AD-1, it could charge for the cost of the com- of local charges, that could be communicated by the router to the
plete reservation up to sender S1. In this case PS-2 removes the PDP.
PD(prc,CID) object from the outgoing RESV message.
On the other hand, if AD-3 has no bilateral agreements in place, it will 5.5. Sender Specified Restrictions on Receiver Reservations
simply charge CID for the cost of the reservation within AD-3 and then
forward PD(prc,CID) in the outgoing RESV message. Subsequent PDPs in other
administrative domains will charge CID for their respective reservations.
A Framework for Policy-based Admission Control March 1999 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).
Since multiple entities are both reading (remaining credit) and writing In the policy based admission control framework such a scheme could
(decrementing credit) to the same database, some coordination and con- be achieved by having the sender generate appropriate policy objects,
currency control might be needed. The issues related to location, manage- carried in a PATH message, which install state in routers on the path
ment, coordination of credit card (or similar) databases is outside the to receivers. In accepting reservations, the routers would have to
scope of this document. compare the RESV requests to the installed state.
Another problem in this scenario is determining when the credit is A number of different solutions can be built to address this
exhausted. The PDPs should contact the database periodically to submit a scenario; precise description of a solution is beyond the scope of
charge against the CID; if the remaining credit reaches zero, there must this document.
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 hap- 6. Interaction Between the Policy Enforcement Point (PEP) and the Policy
pen only after the reservation request has succeeded. In the case of local Decision Point (PDP)
charges, that could be communicated by the router to the PDP.
5.5. Sender Specified Restrictions on Receiver Reservations 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.
The ability of senders to specify restrictions on reservations, based on 6.1. PEP to PDP Protocol Requirements
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 This section describes a set of general requirements for the
achieved by having the sender generate appropriate policy objects, carried communication protocol between the PEP and an external PDP.
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; * Reliability: The sensitivity of policy control information
precise description of a solution is beyond the scope of this document. 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.
6. Interaction Between the Policy Enforcement Point (PEP) and the Policy * Small delays: The timing requirements of policy decisions related
Decision Point (PDP) 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.
In the case of an external PDP, the need for a communication protocol * Ability to carry opaque objects: The protocol should allow for
between the PEP and PDP arises. In order to allow for interoperability delivery of self-identifying, opaque objects, of variable length,
between different vendors networking elements and (external) policy such as RSVP messages, RSVP policy objects and other objects that
servers, this protocol should be standardized. 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.
6.1. PEP to PDP Protocol Requirements * 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.
A Framework for Policy-based Admission Control March 1999 * 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.
This section describes a set of general requirements for the communication * Handling of multicast groups: The protocol should provision for
protocol between the PEP and an external PDP. handling of policy decisions related to multicast groups.
* Reliability: The sensitivity of policy control information necessi- * QoS Specification: The protocol should allow for precise
tates reliable operation. Undetected loss of policy queries or specification of level of service requirements in the PEP requests
responses may lead to inconsistent network control operation and are forwarded to the PDP.
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 7. Security Considerations
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 The communication tunnel between policy clients and policy servers
delivery of self-identifying, opaque objects, of variable length, should be secured by the use of an IPSEC [4] channel. It is advisable
such as RSVP messages, RSVP policy objects and other objects that that this tunnel makes use of both the AH (Authentication Header) and
might be defined as new policies are introduced. The protocol should ESP (Encapsulating Security Payload) protocols, in order to provide
not have to be changed every time a new object has to be exchanged. confidentiality, data origin authentication, integrity and replay
prevention.
* Support for PEP-initiated, two-way Transactions: The protocol must In the case of the RSVP signaling mechanism, RSVP MD5 [2] message
allow for two-way transactions (request-response exchanges) between a authentication can be used to secure communications between network
PEP and a PDP. In particular, PEPs must be able to initiate requests elements.
for policy decision, re-negotiation of previously made policy deci-
sion, 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 8. References
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. Like-
wise, the client has to inform the server of a reservation rejection
which is due to admission control failure.
A Framework for Policy-based Admission Control March 1999 [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
* Handling of multicast groups: The protocol should provision for han- [2] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
dling of policy decisions related to multicast groups. Authentication", RFC 2747, January 2000.
* QoS Specification: The protocol should allow for precise specifica- [3] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
tion of level of service requirements in the PEP requests forwarded January 2000.
to the PDP.
7. Security Considerations [4] Atkinson, R., "Security Architecture for the Internet Protocol",
RFC 1825, August 1995.
The communication tunnel between policy clients and policy servers should [5] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
be secured by the use of an IPSEC [4] channel. It is advisable that this Authentication Dial In User Service (RADIUS)", RFC 2138, April
tunnel makes use of both the AH (Authentication Header) and ESP (Encapsu- 1997.
lating 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 authen- [6] Rajan, R., et al., "Schema for Differentiated Services and
tication can be used to secure communications between network elements. Integrated Services in Networks", Work in Progress.
8. References [7] Herzog, S., "RSVP Preemption Priority Policy", Work in Progress.
[1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSer- [8] Herzog, S., "COPS Usage for RSVP", RFC 2749, January 2000.
Vation Protocol (RSVP) -- Version 1 Functional Specification ", RFC 2205,
September 1997.
[2] F. Baker., "RSVP Cryptographic Authentication", draft-ietf-rsvp-md5- 9. Acknowledgements
05.txt, August 1997.
[3] S. Herzog., "RSVP Extensions for Policy Control", Internet Draft}, This is a result of an ongoing discussion among many members of the
draft-ietf-rsvp-policy-ext-03.[ps,txt], August 1998. RAP group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave
Durham, Shai Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry.
[4] R. Atkinson. Security Architecture for the Internet Protocol. RFC1825, 10. Authors' Addresses
Aug. 1995.
[5] C. Rigney, A Rubens, W. Simpson and S. Willens. Remote Authentication Raj Yavatkar
Dial In User Service (RADIUS). RFC 2138. Intel Corporation
2111 N.E. 25th Avenue,
Hillsboro, OR 97124
USA
[6] R. Rajan et al. Schema for Differentiated Services and Integrated Ser- Phone: +1 503-264-9077
vices in Networks, draft-rajan-policy-qosschema-00.txt, October 1998. EMail: raj.yavatkar@intel.com
[7] S. Herzog, "RSVP Preemption Priority Policy", Internet Draft, draft- Dimitrios Pendarakis
ietf-rap-priority-00.txt, Nov. 1998. IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights
NY 10598
[8] S. Herzog, "COPS Usage for RSVP", Internet Draft, draft-ietf-rap- Phone: +1 914-784-7536
EMail: dimitris@watson.ibm.com
A Framework for Policy-based Admission Control March 1999 Roch Guerin
University of Pennsylvania
Dept. of Electrical Engineering
200 South 33rd Street
Philadelphia, PA 19104
cops-rsvp-00.txt, August 1998. Phone: +1 215 898-9351
EMail: guerin@ee.upenn.edu
8. Acknowledgements 11. Full Copyright Statement
This is a result of an ongoing discussion among many members of the RAP Copyright (C) The Internet Society (2000). All Rights Reserved.
group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, Shai
Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry.
9. Authors` Addresses 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.
Raj Yavatkar The limited permissions granted above are perpetual and will not be
Intel Corporation revoked by the Internet Society or its successors or assigns.
2111 N.E. 25th Avenue,
Hillsboro, OR 97124
USA
phone: +1 503-264-9077
email: raj.yavatkar@intel.com
Dimitrios Pendarakis This document and the information contained herein is provided on an
IBM T.J. Watson Research Center "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
P.O. Box 704 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
Yorktown Heights BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
NY 10598 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
phone: +1 914-784-7536 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
email: dimitris@watson.ibm.com
Roch Guerin Acknowledgement
University of Pennsylvania
Dept. of Electrical Engineering
200 South 33rd Street
Philadelphia, PA 19104
phone: +1 215 898-9351 Funding for the RFC Editor function is currently provided by the
email: guerin@ee.upenn.edu Internet Society.
 End of changes. 144 change blocks. 
745 lines changed or deleted 756 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/