draft-ietf-rap-framework-01.txt   draft-ietf-rap-framework-02.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, U. Of Pennsylvania draft-ietf-rap-framework-02.txt Roch Guerin, U. Of Pennsylvania
November 1998 April 1999
Expires: June 1999 Expires: December 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 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, 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 The list of current Internet-Drafts can be accessed at
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
Coast).
This document is a product of the RSVP Admission Policy (RAP) working The list of Internet-Draft Shadow Directories can be accessed at
group in the Transport Area of the Internet Engineering Task Force. http://www.ietf.org/shadow.html.
Comments are
solicited and should be addressed to the working group's mailing list at
ipc@iphighway.com, and/or the author(s).
A Framework for Policy-based Admission Control Nov. 1998 A Framework for Policy-based Admission Control March 1999
1. Abstract 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. Recent efforts in the Differen- to the current IP best-effort service. Recent efforts in the Differen-
tiated Services Working Group are also directed at definition of mechan- tiated Services Working Group are also directed at definition of mechan-
isms that support aggregate QoS services. The int-serv model for these new isms that support aggregate QoS services. The int-serv model for these new
skipping to change at page 2, line 50 skipping to change at page 2, line 50
that policy-based control must be applicable to different kinds and quali- 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 ties of services offered in the same network and 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 speci- scenarios, and policy support needed for those scenarios. Section 6 speci-
fies the requirements for a client-serv protocol for communication between fies the requirements for a client-server protocol for communication
a policy server (PDP) and its client (PEP) and evaluates suitability of between a policy server (PDP) and its client (PEP) and evaluates suitabil-
some of the existing protocols for this purpose. ity of some of the existing protocols for this purpose.
A Framework for Policy-based Admission Control Nov. 1998 A Framework for Policy-based Admission Control March 1999
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 5 skipping to change at page 4, line 5
allocation decision. 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 A Framework for Policy-based Admission Control March 1999
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-
skipping to change at page 5, line 5 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 A Framework for Policy-based Admission Control March 1999
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
skipping to change at page 6, line 5 skipping to change at page 6, line 5
- Provision for Monitoring and Accounting Information: The mechan- - Provision for Monitoring and Accounting Information: The mechan-
isms must include support for monitoring policy state, resource isms must include support for monitoring policy state, resource
usage, and provide access information. In particular, mechanisms usage, and provide access information. In particular, mechanisms
must be included to provide usage and access information that may must be included to provide usage and access information that may
be used 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 A Framework for Policy-based Admission Control March 1999
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
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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 A Framework for Policy-based Admission Control March 1999
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. For example, the PDP is likely to use an LDAP-based direc- storage, etc. For example, the PDP is likely to use an LDAP-based direc-
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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- The PDP might optionally contact other external servers, e.g., for access-
ing configuration, user authentication, accounting and billing databases. ing configuration, user authentication, accounting and billing databases.
Protocols defined for network management (SNMP) or directory access (LDAP) Protocols defined for network management (SNMP) or directory access (LDAP)
might be used for this communication. While the specific type of access might be used for this communication. While the specific type of access
and the protocols used may vary among different implementations, some of and the protocols used may vary among different implementations, some of
A Framework for Policy-based Admission Control Nov. 1998 A Framework for Policy-based Admission Control March 1999
these interactions will have network-wide implications and could impact these interactions will have network-wide implications and could impact
the interoperability of different devices. the interoperability of different devices.
Of particular importance is the "language" used to specify the policies Of particular importance is the "language" used to specify the policies
implemented by the PDP. The number of policies applicable at a network implemented by the PDP. The number of policies applicable at a network
node might potentially be quite large. At the same time, these policies 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 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 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 that several policies could be applicable to the same request profile. For
skipping to change at page 9, line 5 skipping to change at page 9, line 5
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 A Framework for Policy-based Admission Control March 1999
________________ ____________________ ________________ ____________________
| | | | | | | |
| Network Node | Policy Server | Network Node | | Network Node | Policy Server | Network Node |
| _____ | _____ | _____ _____ | | _____ | _____ | _____ _____ |
| | | | | | | | | | | | | | | | | | | | | | | |
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | | | | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | |
| |_____| | |_____| | |_____| |_____| | | |_____| | |_____| | |_____| |_____| |
| ^ | | | | ^ | | |
| | _____ | |____________________| | | _____ | |____________________|
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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 includes appropriate policy elements as In addition, the request includes appropriate policy elements 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
A Framework for Policy-based Admission Control Nov. 1998 A Framework for Policy-based Admission Control March 1999
the set A to the Local Decision point (LPDP) and collects the 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) 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.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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 A Framework for Policy-based Admission Control March 1999
______________________________ ______________________________
| | | |
| Router | | Router |
| ________ _____ | _____ | ________ _____ | _____
| | | | | | | | | | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP | | | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____| | |________| |_____| | |_____|
| ^ | | ^ |
| | Traffic control | | | Traffic control |
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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:
A Framework for Policy-based Admission Control Nov. 1998 A Framework for Policy-based Admission Control March 1999
1. the message that generated the admission control request should be 1. the message that generated the admission control request should be
processed further as usual, but an error message (or warning) be sent in 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.
4.3. Interactions between PEP, LPDP, and PDP at a RSVP router 4.3. Interactions between PEP, LPDP, and PDP at a RSVP router
skipping to change at page 12, line 44 skipping to change at page 13, line 5
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. An example of a useful mechanism for this pur- accounting purposes. An example of a useful mechanism for this pur-
pose is a MIB or a relational database. However, this document does pose is a MIB or a relational database. However, this document does
not specify any particular mechanism for this purpose and discus- not specify any particular mechanism for this purpose and discus-
sion of such mechanisms is out of the scope of this document. sion of such mechanisms is out of the scope of this document.
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 LPDP and a PDP, the policy A Framework for Policy-based Admission Control March 1999
A Framework for Policy-based Admission Control Nov. 1998
control architecture allows staged deployment by enabling routers of By allowing division of labor between an LPDP and a PDP, the policy con-
varying degrees of sophistication, as far as policy control is con- trol architecture allows staged deployment by enabling routers of varying
cerned, to communicate with policy servers. Figure 4 depicts an exam- degrees of sophistication, as far as policy control is concerned, to com-
ple set of nodes belonging to three different administrative domains municate with policy servers. Figure 4 depicts an example set of nodes
(AD) (Each AD could correspond to a different service provider in belonging to three different administrative domains (AD) (Each AD could
this case). Nodes A, B and C belong to administrative domain AD-1, correspond to a different service provider in this case). Nodes A, B and
advised by PDP PS-1, while D and E belong to AD-2 and AD-3, respec- C belong to administrative domain AD-1, advised by PDP PS-1, while D and E
tively. E communicates with PDP PS-3. In general, it is expected that belong to AD-2 and AD-3, respectively. E communicates with PDP PS-3. In
there will be at least one PDP per administrative domain. 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, Policy capable network nodes could range from very unsophisticated, such
such as E, which have no LPDP, and thus have to rely on an external as E, which have no LPDP, and thus have to rely on an external PDP for
PDP for every policy processing operation, to self-sufficient, such every policy processing operation, to self-sufficient, such as D, which
as D, which essentially encompasses both an LPDP and a PDP locally, 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 | +----+
+----+ | E | D | +-----+ | E | D | | E | D | | E |----| R1 | +----+ | E | D | +-----+ | E | D | | E | D | | E |----| R1 |
skipping to change at page 13, line 50 skipping to change at page 13, line 50
+-------->| PDP |<-------+ | | +-------->| PDP |<-------+ | |
|------| +-------+ |------| +-------+
| | 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
scenarios requiring policy control that should possibly be addressed requiring policy control that should possibly be addressed by the policy
A Framework for Policy-based Admission Control Nov. 1998 A Framework for Policy-based Admission Control March 1999
by the policy control framework. In some cases, possible control framework. In some cases, possible approach(es) for achieving the
approach(es) for achieving the desired goals are also outlined with a desired goals are also outlined with a list of open issues to be resolved.
list of open issues to be resolved.
5.1. Admission control policies based on factors such as Time-of-Day, 5.1. Admission control policies based on factors such as Time-of-Day, User
User Identity, or credentials 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 temporal
poral dependencies. For example, a group of users might be allowed to dependencies. For example, a group of users might be allowed to make
make reservations at certain levels only during off-peak hours. In reservations at certain levels only during off-peak hours. In addition,
addition, the policy control must also support policies that take the policy control must also support policies that take into account iden-
into account identity or credentials of users requesting a particular tity or credentials of users requesting a particular service or resource.
service or resource. For example, an RSVP reservation request may be For example, an RSVP reservation request may be denied or accepted based
denied or accepted based on the credentials or identity suppled in on the credentials or identity supplied in the request.
the request.
5.2. Bilateral agreements between service providers 5.2. Bilateral agreements between service providers
Until recently, usage agreements between service providers for Until recently, usage agreements between service providers for traffic
traffic crossing their boundaries have been quite simple. For exam- crossing their boundaries have been quite simple. For example, two ISPs
ple, two ISPs might agree to accept all traffic from each other, might agree to accept all traffic from each other, often without perform-
often without performing any accounting or billing for the ing any accounting or billing for the ``foreign'' traffic carried. How-
``foreign'' traffic carried. However, with the availability of QoS ever, with the availability of QoS mechanisms based on Integrated and Dif-
mechanisms based on Integrated and Differentiated Services, traffic ferentiated Services, traffic differentiation and quality of service
differentiation and quality of service guarantees are being phased guarantees are being phased into the Internet. As ISPs start to sell their
into the Internet. As ISPs start to sell their customers different customers different grades of service and can differentiate among dif-
grades of service and can differentiate among different sources of ferent sources of traffic, they will also seek mechanisms for charging
traffic, they will also seek mechanisms for charging each other for each other for traffic (and reservations) transiting their networks. One
traffic (and reservations) transiting their networks. One additional additional incentive in establishing such mechanisms is the potential
incentive in establishing such mechanisms is the potential asymmetry asymmetry in terms of the customer base that different providers will
in terms of the customer base that different providers will exhibit: exhibit: ISPs focused on servicing corporate traffic are likely to experi-
ISPs focused on servicing corporate traffic are likely to experience ence much higher demand for reserved services than those that service the
much higher demand for reserved services than those that service the consumer market. Lack of sophisticated accounting schemes for inter-ISP
consumer market. Lack of sophisticated accounting schemes for inter- traffic could lead to inefficient allocation of costs among different ser-
ISP traffic could lead to inefficient allocation of costs among dif- vice providers.
ferent service providers.
Bilateral agreements could fall into two broad categories; local or Bilateral agreements could fall into two broad categories; local or glo-
global. Due to the complexity of the problem, it is expected that bal. Due to the complexity of the problem, it is expected that initially
initially only the former will be deployed. In these, providers which only the former will be deployed. In these, providers which manage a net-
manage a network cloud or administrative domain contract with their work cloud or administrative domain contract with their closest point of
closest point of contact (neighbor) to establish ground rules and contact (neighbor) to establish ground rules and arrangements for access
arrangements for access control and accounting. These contracts are control and accounting. These contracts are mostly local and do not rely
mostly local and do not rely on global agreements; consequently, a on global agreements; consequently, a policy node maintains information
policy node maintains information about its neighboring nodes only. about its neighboring nodes only. Referring to Figure 4, this model
Referring to Figure 4, this model implies that provider AD-1 has implies that provider AD-1 has established arrangements with AD-2, but not
established arrangements with AD-2, but not with AD-3, for usage of 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 reserva-
tion 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
A Framework for Policy-based Admission Control Nov. 1998 A Framework for Policy-based Admission Control March 1999
each other's network. Provider AD-2, in turn, has in place agreements recursively applying the bilateral agreements at every boundary between
with AD-3 and so on. Thus, when forwarding a reservation request to (neighboring) providers, until the recipient of the reservation request is
AD-2, provider AD-2 will charge AD-1 for use of all resources beyond reached. To implement this scheme under the policy control architecture,
AD-1's network. This information is obtained by recursively applying boundary nodes have to add an appropriate policy object to the RSVP mes-
the bilateral agreements at every boundary between (neighboring) pro- sage before forwarding it to a neighboring provider's network. This policy
viders, until the recipient of the reservation request is reached. To object will contain information such as the identity of the provider that
implement this scheme under the policy control architecture, boundary generated them and the equivalent of an account number where charges can
nodes have to add an appropriate policy object to the RSVP message be accumulated. Since agreements only hold among neighboring nodes, policy
before forwarding it to a neighboring provider's network. This policy objects have to be rewritten as RSVP messages cross the boundaries of
object will contain information such as the identity of the provider administrative domains or provider's networks.
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.
5.3. Priority based admission control policies 5.3. Priority based admission control policies
In many settings, it is useful to distinguish between reservations on In many settings, it is useful to distinguish between reservations on the
the basis of some level of "importance". For example, this can be basis of some level of "importance". For example, this can be useful to
useful to avoid that the first reservation being granted the use of avoid that the first reservation being granted the use of some resources,
some resources, be able to hog those resources for some indefinite be able to hog those resources for some indefinite period of time. Simi-
period of time. Similarly, this may be useful to allow emergency larly, this may be useful to allow emergency calls to go through even dur-
calls to go through even during periods of congestion. Such func- ing periods of congestion. Such functionality can be supported by associ-
tionality can be supported by associating priorities with reservation ating priorities with reservation requests, and conveying this priority
requests, and conveying this priority information together with other information together with other policy information.
policy information.
In its basic form, the priority associated with a reservation In its basic form, the priority associated with a reservation directly
directly determines a reservation's rights to the resources it determines a reservation's rights to the resources it requests. For exam-
requests. For example, assuming that priorities are expressed ple, assuming that priorities are expressed through integers in the range
through integers in the range 0 to 32 with 32 being the highest 0 to 32 with 32 being the highest priority, a reservation of priority,
priority, a reservation of priority, say, 10, will always be say, 10, will always be accepted, if the amount of resources held by lower
accepted, if the amount of resources held by lower priority reserva- priority reservations is sufficient to satisfy its requirements. In other
tions is sufficient to satisfy its requirements. In other words, in words, in case there are not enough free resources (bandwidth, buffers,
case there are not enough free resources (bandwidth, buffers, etc.) etc.) at a node to accommodate the priority 10 request, the node will
at a node to accommodate the priority 10 request, the node will attempt to free up the necessary resources by preempting existing lower
attempt to free up the necessary resources by preempting existing priority reservations.
lower priority reservations.
There are a number of requirements associated with the support of There are a number of requirements associated with the support of priority
priority and their proper operation. First, traffic control in the and their proper operation. First, traffic control in the router needs to
router needs to be aware of priorities, i.e., classify existing be aware of priorities, i.e., classify existing reservations according to
reservations according to their priority, so that it is capable of their priority, so that it is capable of determining how many and which
determining how many and which ones to preempt, when required to ones to preempt, when required to accommodate a higher priority reserva-
accommodate a higher priority reservation request. Second, it is tion request. Second, it is important that preemption be made con-
important that preemption be made consistently at different nodes, in sistently at different nodes, in order to avoid transient instabilities.
order to avoid transient instabilities. Third and possibly most Third and possibly most important, merging of priorities needs to be care-
fully architected and its impact clearly understood as part of the associ-
ated policy definition.
A Framework for Policy-based Admission Control Nov. 1998 Of the three above requirements, merging of priority information is the
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
important, merging of priorities needs to be carefully architected A Framework for Policy-based Admission Control March 1999
and its impact clearly understood as part of the associated policy
definition.
Of the three above requirements, merging of priority information is reservation (FLOWSPEC) information is identical, i.e., homogeneous reser-
the more complex and deserves additional discussions. The complexity vations, merging only needs to consider priority information, and the sim-
of merging priority information arises from the fact that this merg- ple rule of keeping the highest priority provides an adequate answer.
ing is to be performed in addition to the merging of reservation However, in the case of heterogeneous reservations, the * two-dimensional
information. When reservation (FLOWSPEC) information is identical, nature} of the (FLOWSPEC, priority) pair makes their ordering, and there-
i.e., homogeneous reservations, merging only needs to consider prior- fore merging, difficult. A description of the handling of different cases
ity information, and the simple rule of keeping the highest priority of RSVP priority objects is presented in [7].
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 5.4. Pre-paid calling card or Tokens
A model of increasing popularity in the telephone network is that of A model of increasing popularity in the telephone network is that of the
the pre-paid calling card. This concept could also be applied to the pre-paid calling card. This concept could also be applied to the Internet;
Internet; users purchase ``tokens'' which can be redeemed at a later users purchase ``tokens'' which can be redeemed at a later time for access
time for access to network services. When a user makes a reservation to network services. When a user makes a reservation request through, say,
request through, say, an RSVP RESV message, the user supplies a an RSVP RESV message, the user supplies a unique identification number of
unique identification number of the ``token'', embedded in a policy the ``token'', embedded in a policy object. Processing of this object at
object. Processing of this object at policy capable routers results policy capable routers results in decrementing the value, or number of
in decrementing the value, or number of remaining units of service, remaining units of service, of this token.
of this token.
Referring to Figure 4, suppose receiver R1 in the administrative Referring to Figure 4, suppose receiver R1 in the administrative domain
domain AD3 wants to request a reservation for a service originating AD3 wants to request a reservation for a service originating in AD1. R1
in AD1. R1 generates a policy data object of type PD(prc, CID), where generates a policy data object of type PD(prc, CID), where ``prc'' denotes
``prc'' denotes pre-paid card and CID is the card identification pre-paid card and CID is the card identification number. Along with other
number. Along with other policy objects carried in the RESV message, policy objects carried in the RESV message, this object is received by
this object is received by node E, which forwards it to its PEP, node E, which forwards it to its PEP, PEP_E, which, in turn, contacts PDP
PEP_E, which, in turn, contacts PDP PS-3. PS-3 either maintains PS-3. PS-3 either maintains locally, or has remote access to, a database
locally, or has remote access to, a database of pre-paid card of pre-paid card numbers. If the amount of remaining credit in CID is suf-
numbers. If the amount of remaining credit in CID is sufficient, the ficient, the PDP accepts the reservation and the policy object is returned
PDP accepts the reservation and the policy object is returned to 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 agree- model in place. If, on the one hand, provider AD-3 has established agree-
ments with both AD-2 and AD-1, it could charge for the cost of the com- ments with both AD-2 and AD-1, it could charge for the cost of the com-
plete 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 other forward PD(prc,CID) in the outgoing RESV message. Subsequent PDPs in other
administrative domains will charge CID for their respective reservations. administrative domains will charge CID for their respective reservations.
A Framework for Policy-based Admission Control March 1999
Since multiple entities are both reading (remaining credit) and writing Since multiple entities are both reading (remaining credit) and writing
(decrementing credit) to the same database, some coordination and con- (decrementing credit) to the same database, some coordination and con-
currency control might be needed. The issues related to location, manage- currency control might be needed. The issues related to location, manage-
ment, coordination of credit card (or similar) databases is outside the ment, coordination of credit card (or similar) databases 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
skipping to change at page 18, line 5 skipping to change at page 17, line 44
In the policy based admission control framework such a scheme could be In the policy based admission control framework such a scheme could be
achieved by having the sender generate appropriate policy objects, carried achieved by having the sender generate appropriate policy objects, carried
in a PATH message, which install state in routers on the path to in a PATH message, which install state in routers on the path to
receivers. In accepting reservations, the routers would have to compare receivers. In accepting reservations, the routers would have to compare
the RESV requests to the installed state. the RESV requests to the installed state.
A number of different solutions can be built to address this scenario; A number of different solutions can be built to address this scenario;
precise description of a solution is beyond the scope of this document. precise description of a solution is beyond the scope of this document.
A Framework for Policy-based Admission Control Nov. 1998
6. Interaction Between the Policy Enforcement Point (PEP) and the Policy 6. Interaction Between the Policy Enforcement Point (PEP) and the Policy
Decision Point (PDP) Decision Point (PDP)
In the case of an external PDP, the need for a communication protocol 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 the PEP and PDP arises. In order to allow for interoperability
between different vendors networking elements and (external) policy between different vendors networking elements and (external) policy
servers, this protocol should be standardized. servers, this protocol should be standardized.
6.1. PEP to PDP Protocol Requirements 6.1. PEP to PDP Protocol Requirements
A Framework for Policy-based Admission Control March 1999
This section describes a set of general requirements for the communication This section describes a set of general requirements for the communication
protocol between the PEP and an external PDP. protocol between the PEP and an external PDP.
* Reliability: The sensitivity of policy control information necessi- * Reliability: The sensitivity of policy control information necessi-
tates reliable operation. Undetected loss of policy queries or tates reliable operation. Undetected loss of policy queries or
responses may lead to inconsistent network control operation and are responses may lead to inconsistent network control operation and are
clearly unacceptable for actions such as billing and accounting. One clearly unacceptable for actions such as billing and accounting. One
option for providing reliability is the re-use of the TCP as the option for providing reliability is the re-use of the TCP as the
transport protocol. transport protocol.
skipping to change at page 19, line 5 skipping to change at page 18, line 41
for policy decision, re-negotiation of previously made policy deci- for policy decision, re-negotiation of previously made policy deci-
sion, and exchange of policy information. To some extent, this sion, and exchange of policy information. To some extent, this
requirement is closely tied to the goal of meeting the requirements requirement is closely tied to the goal of meeting the requirements
of RSVP-specific, policy-based admission control. RSVP signaling of RSVP-specific, policy-based admission control. RSVP signaling
events such as arrival of RESV refresh messages, state timeout, and events such as arrival of RESV refresh messages, state timeout, and
merging of reservations require that a PEP (such as an RSVP router) merging of reservations require that a PEP (such as an RSVP router)
request a policy decision from PDP at any time. Similarly, PEP must request a policy decision from PDP at any time. Similarly, PEP must
be able to report monitoring information and policy state changes to be able to report monitoring information and policy state changes to
PDP at any time. PDP at any time.
A Framework for Policy-based Admission Control Nov. 1998
* Support for asynchronous notification: This is required in order to * Support for asynchronous notification: This is required in order to
allow both the policy server and client to notify each other in the 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 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 triggered by a signaling message. For example, the server would need
to notify the client if a particular reservation has to be terminated to notify the client if a particular reservation has to be terminated
due to expiration of a user's credentials or account balance. Like- due to expiration of a user's credentials or account balance. Like-
wise, the client has to inform the server of a reservation rejection wise, the client has to inform the server of a reservation rejection
which is due to admission control failure. which is due to admission control failure.
A Framework for Policy-based Admission Control March 1999
* Handling of multicast groups: The protocol should provision for han- * Handling of multicast groups: The protocol should provision for han-
dling of policy decisions related to multicast groups. dling of policy decisions related to multicast groups.
* QoS Specification: The protocol should allow for precise specifica- * QoS Specification: The protocol should allow for precise specifica-
tion of level of service requirements in the PEP requests forwarded tion of level of service requirements in the PEP requests forwarded
to the PDP. to the PDP.
6.2. Evaluation of Existing Protocols
In view of the above requirements, we believe that protocols
developed earlier within a different context are inadequate for pro-
viding policy support for QoS. In the following sections, we summar-
ize the reasons for some candidate protocols.
6.2.1. RADIUS
The Remote Authentication Dial In User Service (RADIUS) [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.
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:
* Use of the UDP protocol: As mentioned in section 6.1, the sensi-
tivity of policy control information requires reliable operation.
Use of UDP would mandate specifying retry and fallback algorithms,
which can be quite complicated. In addition, while timing
A Framework for Policy-based Admission Control Nov. 1998
requirements for a user logging onto a network might permit a delay
of several seconds ([5]), this will not be the case for reserva-
tions proceeding in the network. Moreover, acknowledgments are
essential for actions like billing and accounting.
* Difficulty in carrying opaque objects: Use of RADIUS for QoS policy
control would require defining additional RADIUS * attributes. To
carry opaque objects of variable length, the format of RADIUS
attributes would have to be extended; it currently supports four
data types of pre-specified length; string, address, integer and
time.
* No support for asynchronous notification: Asynchronous notification
is required in order to allow both the PDP and a PEP to notify each
other in the case of an asynchronous change in state, i.e., a
change that is not triggered by a signaling message. For example,
the server would need to notify the client if a particular reserva-
tion 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.
* Restricted Message Types: The restriction to messages of type
``access-request'' and ``access-accept'' (or reject) does not
facilitate information gathering for monitoring and accounting pur-
poses. New message types would have to be defined.
* Multicast groups: It is not clear how requests from a group of mul-
ticast receivers could be handled in the context of RADIUS.
* Identifying Requests: Several changes will be needed in the way
requests are identified. Currently this is done using a user
name/IP address attribute. This might be too narrow for reservation
protocols, i.e. one might need to specify a source port, a destina-
tion address/port and provide some user credentials as well.
* QoS Specification: Changes will be needed to incorporate the new
service (resource reservation) and the ability to specify the
desired level of service (QoS, Tspec).
A Framework for Policy-based Admission Control Nov. 1998
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
the task as difficult or more than defining a new protocol designed with
QoS reservations in mind.
6.2.2. LDAP
LDAP is very effective as a directory service protocol. Nevertheless, it
restricts the flexibility of an implementation by requiring a very
specific and well understood format of policy information and policy
rules, common to both a policy server and a client (e.g., a standardized
schema). The client must be able to interpret the format of policy infor-
mation and rules directly. In addition, LDAP is more suitable for access-
ing directory information, information that is predefined and changes
infrequently.
Given the rather experimental state of policy control for QoS reservation
protocols, the dynamic nature of policy decisions and rules and the limi-
tations of clients (routers) in interpreting policy information, an LDAP
based solution for client-server communication would be inadequate at this
point. Also, a wider variety of policy element types and objects need to
be represented using a policy control protocol than supported by LDAP.
LDAP currently does not provide support for asynchronous notification from
servers to clients and is not suitable for exchange of dynamic information
such as policy state and resource usage information.
However, LDAP could conceivably be used in downloading policy rules from
an LDAP server to policy servers. Furthermore, future versions of LDAP
promise to make it more suitable for the exchange of dynamic information.
As these modifications are introduced the role of LDAP in QoS policy con-
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 should The communication tunnel between policy clients and policy servers should
be secured by the use of an IPSEC [4] channel. It is advisable that this be secured by the use of an IPSEC [4] channel. It is advisable that this
tunnel makes use of both the AH (Authentication Header) and ESP (Encapsu- tunnel makes use of both the AH (Authentication Header) and ESP (Encapsu-
lating Security Payload) protocols, in order to provide confidentiality, lating Security Payload) protocols, in order to provide confidentiality,
data origin authentication, integrity and replay prevention. data origin authentication, integrity and replay prevention.
In the case of the RSVP signaling mechanism, RSVP MD5 [2] message authen- In the case of the RSVP signaling mechanism, RSVP MD5 [2] message authen-
tication can be used to secure communications between network elements. tication can be used to secure communications between network elements.
8. References 8. References
A Framework for Policy-based Admission Control Nov. 1998
[1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSer- [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSer-
Vation Protocol (RSVP) -- Version 1 Functional Specification ", RFC 2205, Vation Protocol (RSVP) -- Version 1 Functional Specification ", RFC 2205,
September 1997. September 1997.
[2] F. Baker., "RSVP Cryptographic Authentication", draft-ietf-rsvp-md5- [2] F. Baker., "RSVP Cryptographic Authentication", draft-ietf-rsvp-md5-
05.txt, August 1997. 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-03.[ps,txt], August 1998. draft-ietf-rsvp-policy-ext-03.[ps,txt], August 1998.
skipping to change at page 23, line 30 skipping to change at page 20, line 4
[5] C. Rigney, A Rubens, W. Simpson and S. Willens. Remote Authentication [5] C. Rigney, A Rubens, W. Simpson and S. Willens. Remote Authentication
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- [6] R. Rajan et al. Schema for Differentiated Services and Integrated Ser-
vices in Networks, draft-rajan-policy-qosschema-00.txt, October 1998. vices in Networks, draft-rajan-policy-qosschema-00.txt, October 1998.
[7] S. Herzog, "RSVP Preemption Priority Policy", Internet Draft, draft- [7] S. Herzog, "RSVP Preemption Priority Policy", Internet Draft, draft-
ietf-rap-priority-00.txt, Nov. 1998. ietf-rap-priority-00.txt, Nov. 1998.
[8] S. Herzog, "COPS Usage for RSVP", Internet Draft, draft-ietf-rap- [8] S. Herzog, "COPS Usage for RSVP", Internet Draft, draft-ietf-rap-
A Framework for Policy-based Admission Control March 1999
cops-rsvp-00.txt, August 1998. 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, Shai group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, 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
skipping to change at page 24, line 4 skipping to change at page 20, line 32
phone: +1 503-264-9077 phone: +1 503-264-9077
email: raj.yavatkar@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: dimitris@watson.ibm.com email: dimitris@watson.ibm.com
A Framework for Policy-based Admission Control Nov. 1998
Roch Guerin Roch Guerin
University of Pennsylvania University of Pennsylvania
Dept. of Electrical Engineering Dept. of Electrical Engineering
200 South 33rd Street 200 South 33rd Street
Philadelphia, PA 19104 Philadelphia, PA 19104
phone: +1 215 898-9351 phone: +1 215 898-9351
email: guerin@ee.upenn.edu 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/