draft-ietf-rap-framework-00.txt   draft-ietf-rap-framework-01.txt 
Internet Engineering Task Force Raj Yavatkar, Intel Internet Engineering Task Force Raj Yavatkar, Intel
INTERNET-DRAFT Dimitrios Pendarakis, IBM INTERNET-DRAFT Dimitrios Pendarakis, IBM
Roch Guerin, IBM Roch Guerin, U. Of Pennsylvania
November 21, 1997 November 1998
Expires: May 20, 1998 Expires: June 1999
A Framework for Policy-based Admission Control A Framework for Policy-based Admission Control
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
Coast). Coast).
This document is a product of the RSVP Admission Policy (RAP) working This document is a product of the RSVP Admission Policy (RAP) working
group in the Transport Area of the Internet Engineering Task Force. group in the Transport Area of the Internet Engineering Task Force.
Comments are Comments are
solicited and should be addressed to the working group's mailing list at solicited and should be addressed to the working group's mailing list at
ipc@iphighway.com, and/or the author(s). ipc@iphighway.com, and/or the author(s).
Abstract A Framework for Policy-based Admission Control Nov. 1998
TO BE FILLED IN.
1. Introduction 1. Abstract
The IETF working groups such as Integrated Services (called ''int-serv'') The IETF working groups such as Integrated Services (called "int-serv")
and RSVP [1] have developed extensions to the IP architecture and the and RSVP [1] have developed extensions to the IP architecture and the
best-effort service model so that applications or end users can request best-effort service model so that applications or end users can request
specific quality (or levels) of service from an internetwork in addition specific quality (or levels) of service from an internetwork in addition
to the current IP best-effort service. The int-serv model for these new 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) services requires explicit signaling of the QoS (Quality of Service)
requirements from the end points and provision of admission and traffic requirements from the end points and provision of admission and traffic
control at Integrated Services routers. The proposed standards for RSVP control at Integrated Services routers. The proposed standards for RSVP
[RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a [RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a
new reservation setup protocol and new service definitions respectively. new reservation setup protocol and new service definitions respectively.
Under the int-serv model, certain data flows receive preferential treat- Under the int-serv model, certain data flows receive preferential treat-
ment over other flows; the admission control component only takes into ment over other flows; the admission control component only takes into
account the requester's resource reservation request and available capa- account the requester's resource reservation request and available capa-
city to determine whether or not to accept a QoS request. However, the 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- 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: network managers and service providers must be able to monitor, con-
trol, and enforce use of network resources and services based on policies trol, and enforce use of network resources and services based on policies
derived from criteria such as the identity of users and applications, derived from criteria such as the identity of users and applications,
traffic/bandwidth requirements, security considerations, and time-of- traffic/bandwidth requirements, security considerations, and time-of-
day/week. 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 This document is concerned with specifying a framework for providing
policy-based control over admission control decisions. In particular, it policy-based control over admission control decisions. In particular, it
focuses on policy-based control over admission control using RSVP as an 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 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 is on RSVP-based admission control, the document outlines a framework that
can provide policy-based admission control in other QoS contexts. For can provide policy-based admission control in other QoS contexts. We argue
instance, it may be argued that policy-based control must be applicable to that policy-based control must be applicable to different kinds and quali-
different kinds and qualities of services offered in the same network and ties of services offered in the same network and our goal is to consider
our goal is to consider such extensions whenever possible. such extensions whenever possible.
We begin with a list of definitions in Section 2. Section 3 lists the We begin with a list of definitions in Section 2. Section 3 lists the
requirements and goals of the mechanisms capable of controlling and requirements and goals of the mechanisms capable of controlling and
enforcing access to better QoS. We then outline the architectural ele- enforcing access to better QoS. We then outline the architectural ele-
ments of the framework in Section 4 and describe the functionality assumed ments of the framework in Section 4 and describe the functionality assumed
for each component. Section 5 discusses example policies, possible for each component. Section 5 discusses example policies, possible
scenarios, and policy support needed for those scenarios. Section 6 evalu- scenarios, and policy support needed for those scenarios. Section 6 speci-
ates existing solutions such as RADIUS and LDAP and discusses their appli- fies the requirements for a client-serv protocol for communication between
cability to the problem of policy control. a policy server (PDP) and its client (PEP) and evaluates suitability of
some of the existing protocols for this purpose.
A Framework for Policy-based Admission Control Nov. 1998
2. Terminology 2. Terminology
The following is a list of terms used in this document. The following is a list of terms used in this document.
- Administrative Domain: A collection of networks under the same - Administrative Domain: A collection of networks under the same
administrative control and grouped together for administrative pur- administrative control and grouped together for administrative pur-
poses. poses.
- Network Element or Node: Routers, switches, hubs are examples of - Network Element or Node: Routers, switches, hubs are examples of
skipping to change at page 4, line 31 skipping to change at page 3, line 37
- QoS Signaling Protocol: A signaling protocol that carries an admis- - QoS Signaling Protocol: A signaling protocol that carries an admis-
sion control request for a bandwidth resource, e.g., RSVP. sion control request for a bandwidth resource, e.g., RSVP.
- Policy: The combination of rules and services where rules define - Policy: The combination of rules and services where rules define
the criteria for resource access and usage. the criteria for resource access and usage.
- Policy control: The application of rules to determine whether or - Policy control: The application of rules to determine whether or
not access to a particular resource should be granted. not access to a particular resource should be granted.
- Policy Object: Contains policy-related info such as policy ele- - Policy Object: Contains policy-related info such as policy ele-
ments and is carried by the QoS signaling protocol. ments and is carried in a request or response related to resource
allocation decision.
- Policy Element: Subdivision of policy objects; contains single - Policy Element: Subdivision of policy objects; contains single
units of information necessary for the evaluation of policy rules. units of information necessary for the evaluation of policy rules.
A single policy element carries an user or application identifica- A single policy element carries an user or application identifica-
tion whereas another policy element may carry user credentials or tion whereas another policy element may carry user credentials or
credit card information. Examples of policy elements include iden- credit card information. Examples of policy elements include iden-
tity of the requesting user or application, user/app credentials, tity of the requesting user or application, user/app credentials,
etc. The policy elements themselves are expected to be independent 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. of which QoS signaling protocol is used.
- Policy Decision Point (PDP): The point where policy decisions are - Policy Decision Point (PDP): The point where policy decisions are
made. made.
- Policy Enforcement Point (PEP): The point where the policy deci- - Policy Enforcement Point (PEP): The point where the policy deci-
sions are actually enforced. sions are actually enforced.
- Policy Ignorant Node (PIN): A network element that does not expli- - Policy Ignorant Node (PIN): A network element that does not expli-
citly support policy control using the mechanisms defined in this citly support policy control using the mechanisms defined in this
skipping to change at page 5, line 37 skipping to change at page 5, line 5
- Installed State: A new and unique request made from a PEP to a PDP - Installed State: A new and unique request made from a PEP to a PDP
that must be explicitly deleted. that must be explicitly deleted.
- Trusted Node: A node that is within the boundaries of an adminis- - Trusted Node: A node that is within the boundaries of an adminis-
trative domain (AD) and is trusted in the sense that the admission trative domain (AD) and is trusted in the sense that the admission
control requests from such a node do not necessarily need a PDP control requests from such a node do not necessarily need a PDP
decision. decision.
3. Policy-based Admission Control: Goals and Requirements 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 In this section, we describe the goals and requirements of mechanisms and
protocols designed to provide policy-based control over admission control protocols designed to provide policy-based control over admission control
decisions. decisions.
- Policies vs Mechanisms: An important point to note is that the - Policies vs Mechanisms: An important point to note is that the
framework does not include any discussion of any specific policy framework does not include any discussion of any specific policy
behavior or does not require use of specific policies. Instead, the behavior or does not require use of specific policies. Instead, the
framework only outlines the architectural elements and mechanisms framework only outlines the architectural elements and mechanisms
needed to allow a wide variety of possible policies to be carried needed to allow a wide variety of possible policies to be carried
out. out.
- RSVP-specific: The mechanisms must be designed to meet the policy- - RSVP-specific: The mechanisms must be designed to meet the policy-
based control requirements specific to the problem of bandwidth based control requirements specific to the problem of bandwidth
reservation using RSVP as the signaling protocol. However, our goal reservation using RSVP as the signaling protocol. However, our goal
is to allow for the application of this framework for admission is to allow for the application of this framework for admission
control involving other types of resources as long as we do not control involving other types of resources and QoS services (e.g.,
diverge from our central goal. Diff-Serv) as long as we do not diverge from our central goal.
- Support for preemption: The mechanisms designed must include sup- - Support for preemption: The mechanisms designed must include sup-
port for preemption. By preemption, we mean an ability to remove a port for preemption. By preemption, we mean an ability to remove a
previously installed state in favor of accepting a new admission previously installed state in favor of accepting a new admission
control request. For example, in the case of RSVP, preemption control request. For example, in the case of RSVP, preemption
involves the ability to remove one or more currently installed involves the ability to remove one or more currently installed
reservations to make room for a new resource reservation request. reservations to make room for a new resource reservation request.
- Support for many styles of policies: The mechanisms designed must - Support for many styles of policies: The mechanisms designed must
include support for many policies and policy configurations includ- include support for many policies and policy configurations includ-
ing bi-lateral and multi-lateral service agreements and policies ing bi-lateral and multi-lateral service agreements and policies
based on the notion of relative priority. In general, the determi- based on the notion of relative priority. In general, the determi-
nation and configuration of viable policies are the responsibility nation and configuration of viable policies are the responsibility
of the service provider. of the service provider.
- Provision for Monitoring and Accounting Information: The mechanisms - Provision for Monitoring and Accounting Information: The mechan-
must include support for monitoring policy state resource usage and isms must include support for monitoring policy state, resource
provide access information. In particular, mechanisms must be usage, and provide access information. In particular, mechanisms
included to provide usage and access information that may be used must be included to provide usage and access information that may
for accounting and billing purposes. be used for accounting and billing purposes.
- Fault tolerance and recovery: The mechanisms designed on the basis - Fault tolerance and recovery: The mechanisms designed on the basis
of this framework must include provisions for fault tolerance and of this framework must include provisions for fault tolerance and
recovery from failure cases such as failure of PDPs, disruption in 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) communication including network partitions (and subsequent merging)
that separate a PDP from its peer PEPs. that separate a PDP from its peer PEPs.
- Support for Policy-Ignorant Nodes (PINs): Support for the mechan- - Support for Policy-Ignorant Nodes (PINs): Support for the mechan-
isms described in this document should not be mandatory for every isms described in this document should not be mandatory for every
node in a network. Policy based admission control could be enforced node in a network. Policy based admission control could be enforced
at a subset of nodes, for example the boundary nodes within an at a subset of nodes, for example the boundary nodes within an
administrative domain. These policy capable nodes would function as administrative domain. These policy capable nodes would function as
trusted nodes from the point of view of the policy-ignorant nodes trusted nodes from the point of view of the policy-ignorant nodes
in that administrative domain. in that administrative domain.
skipping to change at page 7, line 40 skipping to change at page 7, line 4
architecture must be secure as far as the following aspects are architecture must be secure as far as the following aspects are
concerned. First, the mechanisms proposed under the framework must concerned. First, the mechanisms proposed under the framework must
minimize theft and denial of service threats. Second, it must be minimize theft and denial of service threats. Second, it must be
ensured that the entities (such as PEPs and PDPs) involved in pol- ensured that the entities (such as PEPs and PDPs) involved in pol-
icy control can verify each other's identity and establish neces- icy control can verify each other's identity and establish neces-
sary trust before communicating. sary trust before communicating.
4. Architectural Elements 4. Architectural Elements
The two main architectural elements for policy control are the PEP (Policy 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 Enforcement Point) and the PDP (Policy Decision Point). Figure 1 shows a
simple configuration involving these two elements; PEP is a component at 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 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 server. The PEP represents the component that always runs on the policy
aware node. It is the point at which policy decisions are actually aware node. It is the point at which policy decisions are actually
enforced. Policy decisions are made primarily at the PDP. The PDP itself enforced. Policy decisions are made primarily at the PDP. The PDP itself
may make use of additional mechanisms and protocols to achieve additional may make use of additional mechanisms and protocols to achieve additional
functionality such as user authentication, accounting, policy information functionality such as user authentication, accounting, policy information
storage, etc. This document does not include discussion of these addi- storage, etc. For example, the PDP is likely to use an LDAP-based direc-
tional mechanisms and protocols and how they are used. 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 The basic interaction between the components begins with the PEP. The PEP
will receive a notification or a message that requires a policy decision. 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- 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 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 to the PDP may contain one or more policy elements (encapsulated into one
or more policy objects) in addition to the admission control information or more policy objects) in addition to the admission control information
(such as a flowspec or amount of bandwidth requested) in the original mes- (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 sage or event that triggered the policy decision request. The PDP returns
the policy decision and the PEP then enforces the policy decision by the policy decision and the PEP then enforces the policy decision by
skipping to change at page 8, line 36 skipping to change at page 7, line 49
| | | | | | policy database, authentication,etc. | | | | | | policy database, authentication,etc.
| | PEP |<-----|------->| PDP |-------------> | | PEP |<-----|------->| PDP |------------->
| |_____| | |_____| | |_____| | |_____|
| | | |
|________________| |________________|
Figure 1: A simple configuration with the primary policy control Figure 1: A simple configuration with the primary policy control
architecture components. PDP may use additional mechanisms and protocols architecture components. PDP may use additional mechanisms and protocols
for the purpose of accounting, authentication, policy storage, etc. for the purpose of accounting, authentication, policy storage, etc.
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 used for this communication. While the specific type of access
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
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- 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 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 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 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- with the PEP at the same network node. Figure 2 shows the possible confi-
gurations. gurations.
The configurations shown in Figures 1 and 2 illustrate the flexibility in The configurations shown in Figures 1 and 2 illustrate the flexibility in
division of labor. On one hand, a centralized policy server, which could division of labor. On one hand, a centralized policy server, which could
be responsible for policy decisions on behalf of multiple network nodes in be responsible for policy decisions on behalf of multiple network nodes in
an administrative domain, might be implementing policies of a wide scope, an administrative domain, might be implementing policies of a wide scope,
common across the AD. On the other hand, policies which depend on informa- 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 tion and conditions local to a particular router and which are more
dynamic, might be better implemented locally, at the router. dynamic, might be better implemented locally, at the router.
A Framework for Policy-based Admission Control Nov. 1998
________________ ____________________ ________________ ____________________
| | | | | | | |
| Network Node | Policy Server | Network Node | | Network Node | Policy Server | Network Node |
| _____ | _____ | _____ _____ | | _____ | _____ | _____ _____ |
| | | | | | | | | | | | | | | | | | | | | | | |
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | | | | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | |
| |_____| | |_____| | |_____| |_____| | | |_____| | |_____| | |_____| |_____| |
| ^ | | | | ^ | | |
| | _____ | |____________________| | | _____ | |____________________|
| \-->| | | | \-->| | |
| | LDP | | | | LPDP| |
| |_____| | | |_____| |
| | | |
|________________| |________________|
Figure 2: Two other possible configurations of policy control Figure 2: Two other possible configurations of policy control
architecture components. The configuration on left shows a local decision architecture components. The configuration on left shows a local decision
point at a network node and the configuration on the left shows PEP and point at a network node and the configuration on the left shows PEP and
PDP co-located at the same node. PDP co-located at the same node.
If it is available, the PEP will first use the LDP to reach a local deci- If it is available, the PEP will first use the LPDP to reach a local deci-
sion. This partial decision and the original policy request are next sent sion. This partial decision and the original policy request are next sent
to the PDP which renders a final decision (possibly, overriding the LDP). to the PDP which renders a final decision (possibly, overriding the
It must be noted that the PDP acts as the final authority for the decision LPDP). It must be noted that the PDP acts as the final authority for the
returned to the PEP and the PEP must enforce the decision rendered by the decision returned to the PEP and the PEP must enforce the decision ren-
PDP. Finally, if a shared state has been established for the request and dered by the PDP. Finally, if a shared state has been established for the
response between the PEP and PDP, it is the responsibility of the PEP to request and response between the PEP and PDP, it is the responsibility of
notify the PDP that the original request is no longer in use. 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 Unless otherwise specified, we will assume the configuration shown on the
left in Figure 2 in the rest of this document. left in Figure 2 in the rest of this document.
Under this policy control model, the PEP module at a network node must use Under this policy control model, the PEP module at a network node must use
the following steps to reach a policy decision: the following steps to reach a policy decision:
1. When a local event or message invokes PEP for 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- the PEP creates a request that includes information from the mes-
sage (or local state) that describes the admission control request. sage (or local state) that describes the admission control request.
In addition, the request include appropriate policy elements to the In addition, the request includes appropriate policy elements as
request as described below. described below.
2. The PEP may consult a local configuration database to identify a 2. The PEP may consult a local configuration database to identify a
set of policy elements (called set A) that are to be evaluated set of policy elements (called set A) that are to be evaluated
locally. The local configuration specifies the types of policy ele- locally. The local configuration specifies the types of policy ele-
ments that are evaluated locally. The PEP passes the request with ments that are evaluated locally. The PEP passes the request with
the set A to the Local Decision point (LDP) and collects the result
of the LDP (called "partial result" and referred to as D(A) ). A Framework for Policy-based Admission Control Nov. 1998
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)
).
3. The PEP then passes the request with ALL the policy elements and 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 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 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) D(Q)). It then combines its result with the partial result D(A)
using a combination operation to reach a final decision. using a combination operation to reach a final decision.
4. The PDP returns the final policy decision (one after the combina- 4. The PDP returns the final policy decision (one after the combina-
tion operation) to the PEP. tion operation) to the PEP.
Note that in the above model, the PEP *must* contact the PDP even if no Note that in the above model, the PEP *must* contact the PDP even if no
or NULL policy objects are received in the admission control request. This (or NULL) policy objects are received in the admission control request.
requirement would help ensure that a request cannot bypass policy control This requirement would help ensure that a request cannot bypass policy
by omitting policy elements in a reservation request. However, ``short control by omitting policy elements in a reservation request. However,
circuit'' processing is permitted, i.e., if the result of D(A), above, is ``short circuit'' processing is permitted, i.e., if the result of D(A),
``no'', then there is no need to proceed with further policy processing at above, is ``no'', then there is no need to proceed with further policy
the policy server. Still, the PDP must be informed of the failure of local processing at the policy server. Still, the PDP must be informed of the
policy processing. The same applies to the case when policy processing is failure of local policy processing. The same applies to the case when pol-
successful but admission control (at the resource management level due to icy processing is successful but admission control (at the resource
unavailable capacity) fails; again the policy server has to be informed of management level due to unavailable capacity) fails; again the policy
the failure. server has to be informed of the failure.
It must also be noted that the PDP may, at any time, send an asynchronous 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 notification to the PEP to change its earlier decision or to generate a
policy error/warning message. policy error/warning message.
4.1. Example of a RSVP Router 4.1. Example of a RSVP Router
In the case of a RSVP router, Figure 3 shows the interaction between a PEP 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 and other int-serv components within the router. For the purpose of this
discussion, we represent all the components of RSVP-related processing by discussion, we represent all the components of RSVP-related processing by
a single RSVP module, but more detailed discussion of the exact interac- 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 tion and interfaces between RSVP and PEP will be described in a separate
document [3]. document [3].
A Framework for Policy-based Admission Control Nov. 1998
______________________________ ______________________________
| | | |
| Router | | Router |
| ________ _____ | _____ | ________ _____ | _____
| | | | | | | | | | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP | | | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____| | |________| |_____| | |_____|
| ^ | | ^ |
| | Traffic control | | | Traffic control |
| | _____________ | | | _____________ |
skipping to change at page 11, line 32 skipping to change at page 11, line 34
| |_____________| | | |_____________| |
| | | |
|______________________________| |______________________________|
Figure 3: Relationship between PEP and other int-serv components Figure 3: Relationship between PEP and other int-serv components
within an RSVP router. PC -- Packet Classifier, PS -- Packet Scheduler within an RSVP router. PC -- Packet Classifier, PS -- Packet Scheduler
When a RSVP message arrives at the router (or an RSVP related event 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 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 request (corresponding to the event or message) to its PEP module. The PEP
will use the PDP (and LDP) to obtain the policy decision and communicate will use the PDP (and LPDP) to obtain the policy decision and communicate
it back to the RSVP module. it back to the RSVP module.
4.2. Additional functionality at the PDP 4.2. Additional functionality at the PDP
Typically, PDP returns the final policy decision based on an admission Typically, PDP returns the final policy decision based on an admission
control request and the associated policy elements. However, it should be control request and the associated policy elements. However, it should be
possible for the PDP to sometimes ask the PEP (or the admission control possible for the PDP to sometimes ask the PEP (or the admission control
module at the network element where PEP resides) to generate policy- module at the network element where PEP resides) to generate policy-
related error messages. For example, in the case of RSVP, the PDP may 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 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 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 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- 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 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 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 needed. Such a policy error returned by the PDP must be able to also
specify whether the reservation request should still be accepted, specify whether the reservation request should still be accepted,
installed, and forwarded to allow continued normal RSVP processing. In installed, and forwarded to allow continued normal RSVP processing. In
particular, when a PDP sends back an error, it specifies that: particular, when a PDP sends back an error, it specifies that:
1. the message that generated the adm control request should be pro- A Framework for Policy-based Admission Control Nov. 1998
cessed further as usual, but an error message (or warning) be sent in
1. the message that generated the admission control request should be
processed further as usual, but an error message (or warning) be sent in
the other direction and include the policy objects supplied in that the other direction and include the policy objects supplied in that
error message error message
2. or, specifies that an error be returned, but the RSVP message should 2. or, specifies that an error be returned, but the RSVP message should
not be forwarded as usual. not be forwarded as usual.
OPEN ISSUE -- What happens in case of the blockade state in RSVP? 4.3. Interactions between PEP, LPDP, and PDP at a RSVP router
4.3. Interactions between PEP, LDP, and PDP at a RSVP router
[NOTE: This section only reflects the ongoing discussion].
At the interim meeting held in October, the working group members present
discussed the issue 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 and installed or forwarded on 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 All the details of RSVP message processing and associated interactions
avoid checking with the PDP every time. However, this raises an between different elements at an RSVP router (PEP, LPDP) and PDP are
interesting issue as the PEP must be able to detect changes to the included in separate documents [3,8]. In the following, a few, salient
previously received policy elements/objects so that the PEP can points related to the framework are listed:
contact the PDP whenever changes occur.
* LDP is optional and may be used for making decisions based on pol- * LPDP is optional and may be used for making decisions based on pol-
icy elements handled locally. The LDP, in turn, may have to go to icy elements handled locally. The LPDP, in turn, may have to go to
external entities (such as a directory server or an authentication external entities (such as a directory server or an authentication
server, etc.) for making its decisions. server, etc.) for making its decisions.
* PDP is stateful and may make decisions even if no policy objects * PDP is stateful and may make decisions even if no policy objects
are received (e.g., make decisions based on information such as are received (e.g., make decisions based on information such as
flowspecs and session object in the RSVP messages). The PDP may flowspecs and session object in the RSVP messages). The PDP may
consult other PDPs, but discussion of inter-PDP communication and consult other PDPs, but discussion of inter-PDP communication and
coordination is outside the scope of this document coordination is outside the scope of this document.
* PDP sends asynchronous notifications to PEP whenever necessary to * PDP sends asynchronous notifications to PEP whenever necessary to
change earlier decisions, generate errors etc. change earlier decisions, generate errors etc.
* PDP exports the information useful for usage monitoring and * PDP exports the information useful for usage monitoring and
accounting purposes: Examples of such information may include a accounting purposes. An example of a useful mechanism for this pur-
MIB. pose is a MIB or a relational database. However, this document does
not specify any particular mechanism for this purpose and discus-
* How or when to merge policy elements and default rules on merging? sion of such mechanisms is out of the scope of this document.
In case of RSVP node without a PEP, what and if default behavior
for merging should be specified?
4.4. Placement of Policy Elements in a Network 4.4. Placement of Policy Elements in a Network
By allowing division of labor between an LDP and a PDP, the policy 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 A Framework for Policy-based Admission Control Nov. 1998
concerned, to communicate with policy servers. Figure 4 depicts an
example set of nodes belonging to three different administrative control architecture allows staged deployment by enabling routers of
domains (AD) (Each AD could correspond to a different service pro- varying degrees of sophistication, as far as policy control is con-
vider in this case). Nodes A, B and C belong to administrative cerned, to communicate with policy servers. Figure 4 depicts an exam-
domain AD-1, advised by PDP PS-1, while D and E belong to AD-2 and ple set of nodes belonging to three different administrative domains
AD-3, respectively. E communicates with PDP PS-3. In general, it is (AD) (Each AD could correspond to a different service provider in
expected that there will be at least one PDP per administrative this case). Nodes A, B and C belong to administrative domain AD-1,
domain. advised by PDP PS-1, while D and E belong to AD-2 and AD-3, 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, Policy capable network nodes could range from very unsophisticated,
such as E, which have no LDP, and thus have to rely on an external 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 PDP for every policy processing operation, to self-sufficient, such
as D, which essentially encompasses both an LDP and a PDP locally, as D, which essentially encompasses both an LPDP and a PDP locally,
at the router. at the router.
AD-1 AD-2 AD-3 AD-1 AD-2 AD-3
________________/\_______________ __/\___ __/\___ ________________/\_______________ __/\___ __/\___
{ } { } { } { } { } { }
A B C D E A B C D E
+-------+ +-----+ +-------+ +-------+ +-------+ +-------+ +-----+ +-------+ +-------+ +-------+
| RSVP | | RSVP| | RSVP | | RSVP | | RSVP | | RSVP | | RSVP| | RSVP | | RSVP | | RSVP |
+----+ |-------| |-----| |-------| |-------| |-------| +----+ |-------| |-----| |-------| |-------| |-------|
| S1 |--| P | L |---| |----| P | L |----| P | P |----| P | +----+ | S1 |--| P | L |---| |----| P | L |----| P | P |----| P | +----+
skipping to change at page 14, line 26 skipping to change at page 13, line 51
|------| +-------+ |------| +-------+
| | PS-2 | | PS-2
+------+ +------+
PS-1 PS-1
Figure 4: Placement of Policy Elements in an internet Figure 4: Placement of Policy Elements in an internet
5. Example Policies, Scenarios, and Policy Support 5. Example Policies, Scenarios, and Policy Support
In the following, we present examples of desired policies and In the following, we present examples of desired policies and
scenarios requiring policy control that should possibly be scenarios requiring policy control that should possibly be addressed
addressed 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- A Framework for Policy-based Admission Control Nov. 1998
Day, User Identity or credentials
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,
User Identity, or credentials
Policy control must be able to express and enforce rules with tem- Policy control must be able to express and enforce rules with tem-
poral dependencies. For example, a group of users might be allowed poral dependencies. For example, a group of users might be allowed to
to make reservations at certain levels only during off-peak hours. make reservations at certain levels only during off-peak hours. In
In addition, the policy control must also support policies that addition, the policy control must also support policies that take
take into account identity or credentials of users requesting a into account identity or credentials of users requesting a particular
particular service or resource. For example, an RSVP reservation service or resource. For example, an RSVP reservation request may be
request may be denied or accepted based on the credentials or iden- denied or accepted based on the credentials or identity suppled in
tity suppled in the request. the request.
5.2. Bilateral agreements between service providers 5.2. Bilateral agreements between service providers
Today, usage agreements between service providers for traffic Until recently, usage agreements between service providers for
crossing their boundaries tend to be quite simple, for example, two traffic crossing their boundaries have been quite simple. For exam-
ISPs might agree to accept all traffic from each other, often ple, two ISPs might agree to accept all traffic from each other,
without performing any accounting or billing for the ``foreign'' often without performing any accounting or billing for the
traffic carried. There are strong reasons to expect that such a ``foreign'' traffic carried. However, with the availability of QoS
model cannot survive once traffic differentiation and quality of mechanisms based on Integrated and Differentiated Services, traffic
service guarantees begin to be phased in the Internet. Once ISPs differentiation and quality of service guarantees are being phased
start charging end users based on usage and quality of service, it into the Internet. As ISPs start to sell their customers different
is only natural that they will also seek mechanisms for charging grades of service and can differentiate among different sources of
each other for reservations transiting their networks. One addi- traffic, they will also seek mechanisms for charging each other for
tional incentive in establishing such mechanisms is the potential traffic (and reservations) transiting their networks. One additional
asymmetry in terms of the customer base that different providers incentive in establishing such mechanisms is the potential asymmetry
will exhibit: ISPs focused on servicing corporate traffic are in terms of the customer base that different providers will exhibit:
likely to experience much higher demand for reserved services than ISPs focused on servicing corporate traffic are likely to experience
those that service the consumer market. Lack of sophisticated much higher demand for reserved services than those that service the
accounting schemes for inter-ISP traffic could lead to inefficient consumer market. Lack of sophisticated accounting schemes for inter-
allocation of costs among different service providers. (ISSUE: ISP traffic could lead to inefficient allocation of costs among dif-
ISn't this an accounting issue among ISPs? We can only provide ferent service providers.
mechanism to facilitate resolution of such issues, but not suggest
solutions.)
Bilateral agreements could fall into two broad categories. In the Bilateral agreements could fall into two broad categories; local or
first, providers which manage a network cloud or administrative global. Due to the complexity of the problem, it is expected that
domain contract with their closest point of contact (neighbor) to initially only the former will be deployed. In these, providers which
establish ground rules and arrangements for access control and manage a network cloud or administrative domain contract with their
accounting. These contracts are mostly local and do not rely on closest point of contact (neighbor) to establish ground rules and
global agreements; consequently, a policy node maintains informa- arrangements for access control and accounting. These contracts are
tion about its neighboring nodes only. Referring to Figure 4, this mostly local and do not rely on global agreements; consequently, a
model implies that provider AD-1 has established arrangements with policy node maintains information about its neighboring nodes only.
AD-2, but not with AD-3, for usage of each other's network. Pro- Referring to Figure 4, this model implies that provider AD-1 has
vider AD-2, in turn, has in place agreements with AD-3 and so on. established arrangements with AD-2, but not with AD-3, for usage of
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 pro-
vider 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.
Bilateral agreements could also be established on a *global* scale. A Framework for Policy-based Admission Control Nov. 1998
In this second category, providers contract with an arbitrary
number of other providers, not necessarily neighboring. The objec-
tive of global agreements would be to provide a global network
picture that allows a provider to satisfy (most) reservation
requests without reliance on third party agreements. This category
of agreements can also be supported in the context of the policy
control architecture. As above, the originating node includes a
policy object containing identity and account information in the
RSVP message; however, as long as global agreements are in place,
this object is not rewritten as the message crosses administrative
boundaries. Instead, each provider ``charges'' to the account the
incremental cost incurred in carrying the reservation request
through its network.
5.3. Pre-paid calling card or Tokens 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) 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 provider
that generated them and the equivalent of an account number where
charges can be accumulated. Since agreements only hold among neigh-
boring nodes, policy objects have to be rewritten as RSVP messages
cross the boundaries of administrative domains or provider's net-
works.
A model of increasing popularity in the telephone network is that 5.3. Priority based admission control policies
of the pre-paid calling card. This concept could also be applied to
the Internet; users purchase ``tokens'' which can be redeemed at a In many settings, it is useful to distinguish between reservations on
later time for access to network services. When a user makes a the basis of some level of "importance". For example, this can be
reservation request through, say, an RSVP RESV message, the user useful to avoid that the first reservation being granted the use of
supplies a unique identification number of the ``token'', embedded some resources, be able to hog those resources for some indefinite
in a policy object. Processing of this object at policy capable period of time. Similarly, this may be useful to allow emergency
routers results in decrementing the value, or number of remaining calls to go through even during periods of congestion. Such func-
units of service, of this token. tionality can be supported by associating priorities with reservation
requests, and conveying this priority information together with other
policy information.
In its basic form, the priority associated with a reservation
directly determines a reservation's rights to the resources it
requests. For example, assuming that priorities are expressed
through integers in the range 0 to 32 with 32 being the highest
priority, a reservation of priority, say, 10, will always be
accepted, if the amount of resources held by lower priority reserva-
tions is sufficient to satisfy its requirements. In other words, in
case there are not enough free resources (bandwidth, buffers, etc.)
at a node to accommodate the priority 10 request, the node will
attempt to free up the necessary resources by preempting existing
lower priority reservations.
There are a number of requirements associated with the support of
priority and their proper operation. First, traffic control in the
router needs to be aware of priorities, i.e., classify existing
reservations according to their priority, so that it is capable of
determining how many and which ones to preempt, when required to
accommodate a higher priority reservation request. Second, it is
important that preemption be made consistently at different nodes, in
order to avoid transient instabilities. Third and possibly most
A Framework for Policy-based Admission Control Nov. 1998
important, merging of priorities needs to be carefully architected
and its impact clearly understood as part of the associated policy
definition.
Of the three above requirements, merging of priority information is
the more complex and deserves additional discussions. The complexity
of merging priority information arises from the fact that this merg-
ing is to be performed in addition to the merging of reservation
information. When reservation (FLOWSPEC) information is identical,
i.e., homogeneous reservations, merging only needs to consider prior-
ity information, and the simple rule of keeping the highest priority
provides an adequate answer. However, in the case of heterogeneous
reservations, the * two-dimensional nature} of the (FLOWSPEC, prior-
ity) pair makes their ordering, and therefore merging, difficult. A
description of the handling of different cases of RSVP priority
objects is presented in [7].
5.4. Pre-paid calling card or Tokens
A model of increasing popularity in the telephone network is that of
the pre-paid calling card. This concept could also be applied to the
Internet; users purchase ``tokens'' which can be redeemed at a later
time for access to network services. When a user makes a reservation
request through, say, an RSVP RESV message, the user supplies a
unique identification number of the ``token'', embedded in a policy
object. Processing of this object at policy capable routers results
in decrementing the value, or number of remaining units of service,
of this token.
Referring to Figure 4, suppose receiver R1 in the administrative Referring to Figure 4, suppose receiver R1 in the administrative
domain AD3 wants to request a reservation for a service originating domain AD3 wants to request a reservation for a service originating
in AD1. R1 generates a policy data object of type PD(prc, CID), in AD1. R1 generates a policy data object of type PD(prc, CID), where
where ``prc'' denotes pre-paid card and CID is the card identifica- ``prc'' denotes pre-paid card and CID is the card identification
tion number. Along with other policy objects carried in the RESV number. Along with other policy objects carried in the RESV message,
message, this object is received by node E, which forwards it to this object is received by node E, which forwards it to its PEP,
its PEP, PEP_E, which, in turn, contacts PDP PS-3. PS-3 either PEP_E, which, in turn, contacts PDP PS-3. PS-3 either maintains
maintains locally, or has remote access to, a database of pre-paid locally, or has remote access to, a database of pre-paid card
card numbers. If the amount of remaining credit in CID is suffi- numbers. If the amount of remaining credit in CID is sufficient, the
cient, the PDP accepts the reservation and the policy object is PDP accepts the reservation and the policy object is returned to
returned to PEP_E. Two issues have to be resolved here: PEP_E. Two issues have to be resolved here:
* What is the scope of these charges? * What is the scope of these charges?
* When are charges (in the form of decrementing the remaining credit) * When are charges (in the form of decrementing the remaining credit)
first applied? first applied?
A Framework for Policy-based Admission Control Nov. 1998
The answer to the first question is related to the bilateral agreement The answer to the first question is related to the bilateral agreement
model in place. If, on the one hand, provider AD-3 has established model in place. If, on the one hand, provider AD-3 has established agree-
agreements with both AD-2 and AD-1, it could charge for the cost of the ments with both AD-2 and AD-1, it could charge for the cost of the com-
complete reservation up to sender S1. In this case PS-2 removes the plete reservation up to sender S1. In this case PS-2 removes the
PD(prc,CID) object from the outgoing RESV message. PD(prc,CID) object from the outgoing RESV message.
On the other hand, if AD-3 has no bilateral agreements in place, it will 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 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 forward PD(prc,CID) in the outgoing RESV message. Subsequent PDPs in other
other administrative domains will charge CID for their respective reser- administrative domains will charge CID for their respective reservations.
vations. Since multiple entities are both reading (remaining credit) Since multiple entities are both reading (remaining credit) and writing
and writing (decrementing credit) to the same database, some coordina- (decrementing credit) to the same database, some coordination and con-
tion and concurrency control might be needed. The issues related to currency control might be needed. The issues related to location, manage-
location, management, coordination of credit card (or similar) databases ment, coordination of credit card (or similar) databases is outside the
is outside the scope of this document. scope of this document.
Another problem in this scenario is determining when the credit is Another problem in this scenario is determining when the credit is
exhausted. The PDPs should contact the database periodically to submit a exhausted. The PDPs should contact the database periodically to submit a
charge against the CID; if the remaining credit reaches zero, there must 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 be a mechanism to detect that and to cause revocation or termination of
privileges granted based on the credit. privileges granted based on the credit.
Regarding the issue of when to initiate charging, ideally that should Regarding the issue of when to initiate charging, ideally that should hap-
happen only after the reservation request has succeeded. In the case of pen only after the reservation request has succeeded. In the case of local
local charges, that could be communicated by the router to the PDP. 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
the basis of some level of "importance". For example, this can be use-
ful 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 to reservation requests, and convey-
ing this priority information together with other policy information.
In its basic form, the priority associated with a reservation directly
determines a reservation's rights to the resources it requests. For
example, assuming that priorities are expressed through integers in the
range 0 to 32 with 32 being the highest priority, a reservation of
priority, say, 10, will always be accepted, if the amount of resources
held by lower priority reservations is sufficient to satisfy its
requirements. In other words, in case there are not enough free
resources (bandwidth, buffers, etc.) at a node to accommodate the prior-
ity 10 request, the node will attempt to free up the necessary resources
by preempting existing lower priority reservations.
There are a number of requirements associated with the support of
priority and their proper operation. First, traffic control in the
router needs to be aware of priorities, i.e., classify existing reserva-
tions according to their priority, so that it is capable of determining
how many and which ones to preempt, when required to accommodate a
higher priority reservation request. Second, it is important that
preemption be made consistently at different nodes, in order to avoid
transient instabilities. Third and possibly most important, merging of
priorities needs to be carefully architected and its impact clearly
understood as part of the associated policy definition.
Of the three above requirements, merging of priority information is the
more complex and deserves additional discussions. The complexity of
merging priority information arises from the fact that this merging is
to be performed in addition to the merging of reservation information.
When reservation (FLOWSPEC) information is identical, i.e., homogeneous
reservations, merging only needs to consider priority information, and
the simple rule of keeping the highest priority provides an adequate
answer. However, in the case of heterogeneous reservations, the * two-
dimensional nature} of the (FLOWSPEC, priority) pair makes their order-
ing, and therefore merging, difficult. Two possible cases can be iden-
tified:
1. (FLOWSPEC1, priority1)= (high, high); 5.5. Sender Specified Restrictions on Receiver Reservations
(FLOWSPEC2, priority2)= (low, low)
2. (FLOWSPEC1, priority1) = (high, low);
(FLOWSPEC2, priority2) = (low, high)
In the first case, the ordering is immediate, i.e., 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).
(FLOWSPEC1, priority1) >= (FLOWSPEC2, priority2), In the policy based admission control framework such a scheme could be
achieved by having the sender generate appropriate policy objects, carried
in a PATH message, which install state in routers on the path to
receivers. In accepting reservations, the routers would have to compare
the RESV requests to the installed state.
so that the merged value can readily be chosen as (FLOWSPEC1, prior- A number of different solutions can be built to address this scenario;
ity1). However, in the second case, no obvious ordering is available, precise description of a solution is beyond the scope of this document.
and each possible merged combination introduces a problem of its own
which we briefly review.
2.a (FLOWSPEC_OUT, priority_OUT) = (high, high) = {FLOWSPEC1, prior- A Framework for Policy-based Admission Control Nov. 1998
ity2}
The main problem with this selection is the so-called "free-rider" 6. Interaction Between the Policy Enforcement Point (PEP) and the Policy
problem, in that the high bandwidth requirement of a low priority Decision Point (PDP)
request is now entitled to the higher priority that was initially
granted to a low bandwidth request. Such "upgrades" can all but dis-
able the ability of priorities to give preference to certain flows,
and are therefore not acceptable.
2.b (FLOWSPEC_OUT, priority_OUT) = (high, low) = (FLOWSPEC1, In the case of an external PDP, the need for a communication protocol
priority1) 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.
This selection amounts to (initially) giving preference to high 6.1. PEP to PDP Protocol Requirements
bandwidth requests, irrespective of their priority. The main benefit
is that larger reservations are allowed to try and succeed in case the
resources are available. The main disadvantage is that if a high
FLOWSPEC and low priority reservation is preempted, the entire reser-
vation is taken down. As a result, a high priority and low FLOWSPEC
reservation is left without resources until a new reservation is ulti-
mately reestablished at the higher priority level.
2.c (FLOWSPEC_OUT, priority_OUT) = (low, high) = (FLOWSPEC2, prior- This section describes a set of general requirements for the communication
ity2) protocol between the PEP and an external PDP.
This is the opposite selection to 2.b, and as a result, it has the * Reliability: The sensitivity of policy control information necessi-
opposite disadvantages and benefits. Specifically, a low FLOWSPEC but tates reliable operation. Undetected loss of policy queries or
high priority request can preclude higher FLOWSPEC but lower priority responses may lead to inconsistent network control operation and are
requests, *irrespective* of how lightly loaded the network is. On the clearly unacceptable for actions such as billing and accounting. One
other hand, the high priority request is *guaranteed* unperturbed ser- option for providing reliability is the re-use of the TCP as the
vice unless it itself needs to be preempted. transport protocol.
2.d (FLOWSPEC_OUT, priority_OUT) = (low, low) * Small delays: The timing requirements of policy decisions related to
QoS signaling protocols are expected to be quite strict. The PEP to
PDP protocol should add small amount of delay to the response delay
experienced by queries placed by the PEP to the PDP.
This last option is mentioned for completeness, but is not particu- * Ability to carry opaque objects: The protocol should allow for
larly meaningful as it offers no benefits and only disadvantages. delivery of self-identifying, opaque objects, of variable length,
such as RSVP messages, RSVP policy objects and other objects that
might be defined as new policies are introduced. The protocol should
not have to be changed every time a new object has to be exchanged.
As can be seen from the above discussion, support for priorities and the * Support for PEP-initiated, two-way Transactions: The protocol must
associated merging operations raises a number issues. There are possi- allow for two-way transactions (request-response exchanges) between a
ble solutions to most of the above problems, e.g., PEP and a PDP. In particular, PEPs must be able to initiate requests
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.
- Disable or limit the amount of merging that can take place, - Select A Framework for Policy-based Admission Control Nov. 1998
one of the above rules 2.b or 2.c based on the relative difference
between the FLOWSPEC being merged,
but it is likely that different environments (set of criteria) may man- * Support for asynchronous notification: This is required in order to
date different selections. In addition, it may be desirable to extend allow both the policy server and client to notify each other in the
the concept of priorities to let applications specify both holding and case of an asynchronous change in state, i.e., a change that is not
preemption priorities, with the former being always greater than the triggered by a signaling message. For example, the server would need
latter. The preemption priority would be a function of the urgency of to notify the client if a particular reservation has to be terminated
satisfying the reservation request being made, while the holding prior- due to expiration of a user's credentials or account balance. Like-
ity would reflect the application's tolerance to being interrupted. wise, the client has to inform the server of a reservation rejection
which is due to admission control failure.
In general, support for priority provides a powerful tool to manage * Handling of multicast groups: The protocol should provision for han-
access to network resources, and should represent one of the key bene- dling of policy decisions related to multicast groups.
fits of the introduction of policy support. However, rules determining
how priorities are to be handled may differ, and likely to be specified
in the context of each policy supporting priorities. (OPEN ISSUE:
Should we specify default merging rules?)
5.5. Sender Specified Restrictions on Receiver Reservations * QoS Specification: The protocol should allow for precise specifica-
tion of level of service requirements in the PEP requests forwarded
to the PDP.
The ability of senders to specify restrictions on reservations, based on 6.2. Evaluation of Existing Protocols
receiver identity, number of receivers or reservation cost might be use-
ful 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 satis-
fies 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 In view of the above requirements, we believe that protocols
achieved by having the sender generate appropriate policy objects, car- developed earlier within a different context are inadequate for pro-
ried in a PATH message, which install state in routers on the path to viding policy support for QoS. In the following sections, we summar-
receivers. In accepting reservations, the routers would have to compare ize the reasons for some candidate protocols.
the RESV requests to the installed state.
A number of different solutions can be built to address this scenario; 6.2.1. RADIUS
precise description of a solution is beyond the scope of this document.
6. Evaluation of Existing Frameworks or Solutions The Remote Authentication Dial In User Service (RADIUS) [5] protocol,
specifies how authentication, authorization and configuration infor-
mation is exchanged between a network access server wishing to
authenticate its users and a (shared) authentication server. RADIUS
has been designed to operate at the level of a "session", which is
defined as the interval between the time that service is first pro-
vided and the time service is ended. The latter definition is geared
towards login-type service, for example network access for dial up
users through PPP.
6.1. RADIUS RADIUS is an important protocol for authenticating login users. 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:
The Remote Authentication Dial In User Service (RADIUS) [REF] protocol, * Use of the UDP protocol: As mentioned in section 6.1, the sensi-
specifies how authentication, authorization and configuration informa- tivity of policy control information requires reliable operation.
tion is exchanged between a network access server wishing to authenti- Use of UDP would mandate specifying retry and fallback algorithms,
cate its users and a (shared) authentication server. RADIUS has been which can be quite complicated. In addition, while timing
designed to operate at the level of a * session}, which is defined as
the interval between the time that service is first provided and the
time service is ended. The latter definition is geared towards login-
type service, for example network access for dial up users through PPP.
RADIUS is an important protocol for authenticating login users. However, A Framework for Policy-based Admission Control Nov. 1998
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 of policy control requirements for a user logging onto a network might permit a delay
information requires reliable operation. Use of UDP would mandate of several seconds ([5]), this will not be the case for reserva-
specifying retry and fallback algorithms, which can be quite tions proceeding in the network. Moreover, acknowledgments are
complicated. In addition, while timing requirements for a user essential for actions like billing and accounting.
logging onto a network might permit a delay of several seconds
([REF]), this will not be the case for reservations 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- * Difficulty in carrying opaque objects: Use of RADIUS for QoS policy
icy control would require defining additional RADIUS * attri- control would require defining additional RADIUS * attributes. To
butes. To carry opaque objects of variable length, the format of carry opaque objects of variable length, the format of RADIUS
RADIUS attributes would have to be extended; it currently sup- attributes would have to be extended; it currently supports four
ports four data types of pre-specified length; string, address, data types of pre-specified length; string, address, integer and
integer and time. time.
* No support for asynchronous notification: Asynchronous notifica- * No support for asynchronous notification: Asynchronous notification
tion is required in order to allow both the policy server and is required in order to allow both the PDP and a PEP to notify each
client to notify each other in the case of an asynchronous change other in the case of an asynchronous change in state, i.e., a
in state, i.e., a change that is not triggered by a signaling change that is not triggered by a signaling message. For example,
message. For example, the server would need to notify the client the server would need to notify the client if a particular reserva-
if a particular reservation has to be terminated due to expira- tion has to be terminated due to expiration of a user's credentials
tion of a user's credentials or account balance. Likewise, the or account balance. Likewise, the client has to inform the server
client has to inform the server of a reservation rejection which of a reservation rejection which is due to admission control
is due to admission control failure. failure.
* Restricted Message Types: The restriction to messages of type * Restricted Message Types: The restriction to messages of type
``access-request'' and ``access-accept'' (or reject) does not ``access-request'' and ``access-accept'' (or reject) does not
facilitate information gathering for monitoring and accounting facilitate information gathering for monitoring and accounting pur-
purposes. New message types would have to be defined. poses. New message types would have to be defined.
* Multicast Groups: It is not clear how requests from a group of * Multicast groups: It is not clear how requests from a group of mul-
multicast receivers could be handled in the context of RADIUS. ticast receivers could be handled in the context of RADIUS.
* Identifying Requests: Several changes will be needed in the way * Identifying Requests: Several changes will be needed in the way
requests are identified. Currently this is done using a user requests are identified. Currently this is done using a user
name/IP address attribute. This might be too narrow for reserva- name/IP address attribute. This might be too narrow for reservation
tion protocols, i.e. one might need to specify a source port, a protocols, i.e. one might need to specify a source port, a destina-
destination address/port and provide some user credentials as tion address/port and provide some user credentials as well.
well.
* QoS Specification: Changes will be needed to incorporate the new * QoS Specification: Changes will be needed to incorporate the new
service (resource reservation) and the ability to specify the service (resource reservation) and the ability to specify the
desired level of service (QoS, Tspec) desired level of service (QoS, Tspec).
A Framework for Policy-based Admission Control Nov. 1998
In short, we believe that if the RADIUS protocol were to be used for the In short, we believe that if the RADIUS protocol were to be used for the
purpose of QoS policy control, the number of changes required would make 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 the task as difficult or more than defining a new protocol designed with
QoS reservations in mind. QoS reservations in mind.
6.2. LDAP 6.2.2. LDAP
LDAP is very effective as a directory service protocol. Nevertheless, it LDAP is very effective as a directory service protocol. Nevertheless, it
restricts the flexibility of an implementation by requiring a very restricts the flexibility of an implementation by requiring a very
specific and well understood format of policy information and policy specific and well understood format of policy information and policy
rules, common to both a policy server and a client (e.g., a standardized 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 schema). The client must be able to interpret the format of policy infor-
information and rules directly. In addition, LDAP is more suitable for mation and rules directly. In addition, LDAP is more suitable for access-
accessing directory information, information that is predefined and ing directory information, information that is predefined and changes
changes infrequently. infrequently.
Given the rather experimental state of policy control for QoS reserva- Given the rather experimental state of policy control for QoS reservation
tion protocols, the dynamic nature of policy decisions and rules and the protocols, the dynamic nature of policy decisions and rules and the limi-
limitations of clients (routers) in interpreting policy information, an tations of clients (routers) in interpreting policy information, an LDAP
LDAP based solution for client-server communication would be inadequate based solution for client-server communication would be inadequate at this
at this point. Also, a wideer variety of policy element types and point. Also, a wider variety of policy element types and objects need to
objects need to be represented using a policy control protocol than sup- be represented using a policy control protocol than supported by LDAP.
ported 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 However, LDAP could conceivably be used in downloading policy rules from
an LDAP server to policy servers. Furthermore, future versions of LDAP an LDAP server to policy servers. Furthermore, future versions of LDAP
promise to make it more suitable for the exchange of dynamic informa- promise to make it more suitable for the exchange of dynamic information.
tion. As these modifications are introduced the role of LDAP in QoS pol- As these modifications are introduced the role of LDAP in QoS policy con-
icy control should be reevaluated. trol could be reevaluated.
6.2.3. SNMP
SNMP was designed for the specific purpose of monitoring network devices
from a central network management station (NMS). Our investigation of SNMP
led us to believe that it does not provide adequate support for the pur-
pose of communication between a PEP and its PDP for the following reasons:
* Lack of support for large messages: Policy information carried in
messages exchanged between a PEP and a PDP typically consists of
several policy elements. Each policy element itself may contain siz-
able amount of information. For example, a Kerberos-based credential
(a single policy 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 large message. Similarly, a report message
containing monitoring information will also contain a large amount of
information. Therefore, the protocol must support reliable delivery
of 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 requires an additional protocol
to ensure reliable delivery of large messages.
* Master-Slave relationship: SNMP is designed for a Master-slave rela-
tionship in which a Network Management Station (NMS) acts as a master
for a group of devices. NMS is always in charge and initiates any
communication for retrieval of monitoring information except for
traps that can be asynchronously generated by the 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 exchange
between a PEP and PDP is stateful and establishes shared state that
is referred to in 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 data content (authentication failure) as well as
errors specific to RSVP semantics.
7. Security Considerations 7. Security Considerations
The communication tunnel between policy clients and policy servers The communication tunnel between policy clients and policy servers should
should be secured by the use of an IPSEC [4] channel. It is advisable be secured by the use of an IPSEC [4] channel. It is advisable that this
that this tunnel makes use of both the AH (Authentication Header) and tunnel makes use of both the AH (Authentication Header) and ESP (Encapsu-
ESP (Encapsulating Security Payload) protocols, in order to provide con- lating Security Payload) protocols, in order to provide confidentiality,
fidentiality, data origin authentication, integrity and replay preven- data origin authentication, integrity and replay prevention.
tion.
In the case of the RSVP signaling mechanism, RSVP MD5 [2] message In the case of the RSVP signaling mechanism, RSVP MD5 [2] message authen-
authentication can be used to secure communications between network ele- tication can be used to secure communications between network elements.
ments.
8. References 8. References
[1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional Specification ", RFC
2205, September 1997.
[2] F. Baker., "RSVP Cryptographic Authentication", draft-ietf-rsvp- A Framework for Policy-based Admission Control Nov. 1998
md5-05.txt, August 1997.
[1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSer-
Vation Protocol (RSVP) -- Version 1 Functional Specification ", RFC 2205,
September 1997.
[2] F. Baker., "RSVP Cryptographic Authentication", draft-ietf-rsvp-md5-
05.txt, August 1997.
[3] S. Herzog., "RSVP Extensions for Policy Control", Internet Draft}, [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. [4] R. Atkinson. Security Architecture for the Internet Protocol. RFC1825,
RFC1825, Aug. 1995. Aug. 1995.
[5] C. Rigney, A Rubens, W. Simpson and S. Willens. Remote Authentica- [5] C. Rigney, A Rubens, W. Simpson and S. Willens. Remote Authentication
tion Dial In User Service (RADIUS). RFC 2138. 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 8. Acknowledgements
This is a result of an ongoing discussion among many members of the RAP This is a result of an ongoing discussion among many members of the RAP
group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, Shai
Shai Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry. Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry.
9. Authors` Addresses 9. Authors` Addresses
Raj Yavatkar Raj Yavatkar
Intel Corporation Intel Corporation
2111 N.E. 25th Avenue, 2111 N.E. 25th Avenue,
Hillsboro, OR 97124 Hillsboro, OR 97124
USA USA
phone: +1 503-264-9077 phone: +1 503-264-9077
email: yavatkar@ibeam.intel.com email: raj.yavatkar@intel.com
Dimitrios Pendarakis Dimitrios Pendarakis
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
P.O. Box 704 P.O. Box 704
Yorktown Heights Yorktown Heights
NY 10598 NY 10598
phone: +1 914-784-7536 phone: +1 914-784-7536
email: dimitri@watson.ibm.com email: dimitris@watson.ibm.com
A Framework for Policy-based Admission Control Nov. 1998
Roch Guerin Roch Guerin
IBM T.J. Watson Research Center University of Pennsylvania
P.O. Box 704 Dept. of Electrical Engineering
Yorktown Heights 200 South 33rd Street
NY 10598 Philadelphia, PA 19104
phone: +1 914-784-7038
email: guerin@watson.ibm.com phone: +1 215 898-9351
email: guerin@ee.upenn.edu
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/