As per Relevance of the word framework, we have this rfc below:
Network Working Group R.
Request for Comments: 2753
Category: Informational D.
R.
U. Of
January 2000
A Framework for Policy-based Admission
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
1.
The IETF working groups such as Integrated Services (called "int
serv") and RSVP [1] have developed extensions to the IP
and the best-effort service model so that applications or end
can request specific quality (or levels) of service from
internetwork in addition to the current IP best-effort service
Recent efforts in the Differentiated Services Working Group are
directed at the definition of mechanisms that support aggregate
services. The int-serv model for these new services requires
signaling of the QoS (Quality of Service) requirements from the
points and provision of admission and traffic control at
Services routers. The proposed standards for RSVP [RFC 2205]
Integrated Services [RFC 2211, RFC 2212] are examples of a
reservation setup protocol and new service definitions respectively
Under the int-serv model, certain data flows receive
treatment over other flows; the admission control component
takes into account the requester's resource reservation request
available capacity to determine whether or not to accept a
request. However, the int-serv mechanisms do not include
important aspect of admission control: network managers and
providers must be able to monitor, control, and enforce use
network resources and services based on policies derived
criteria such as the identity of users and applications
traffic/bandwidth requirements, security considerations, and time
Yavatkar, et al. Informational [Page 1]
RFC 2753 Framework for Policy-based Admission Control January 2000
of-day/week. Similarly, diff-serv mechanisms also need to take
account policies that involve various criteria such as
identity, ingress points, and so on
This document is concerned with specifying a framework for
policy-based control over admission control decisions. In particular
it focuses on policy-based control over admission control using
as an example of the QoS signaling mechanism. Even though the
of the work is on RSVP-based admission control, the document
a framework that can provide policy-based admission control in
QoS contexts. We argue that policy-based control must be
to different kinds and qualities of services offered in the
network and our goal is to consider such extensions
possible
We begin with a list of definitions in Section 2. Section 3 lists
requirements and goals of the mechanisms used to control and
access to better QoS. We then outline the architectural elements
the framework in Section 4 and describe the functionality assumed
each component. Section 5 discusses example policies,
scenarios, and policy support needed for those scenarios. Section 6
specifies the requirements for a client-server protocol
communication between a policy server (PDP) and its client (PEP)
evaluates the suitability of some existing protocols for
purpose
2.
The following is a list of terms used in this document
- Administrative Domain: A collection of networks under the
administrative control and grouped together for
purposes
- Network Element or Node: Routers, switches, hubs are examples
network nodes. They are the entities where resource
decisions have to be made and the decisions have to be enforced.
RSVP router which allocates part of a link capacity (or buffers
to a particular flow and ensures that only the admitted flows
access to their reserved resources is an example of a
element of interest in our context
In this document, we use the terms router, network element,
network node interchangeably, but the should all be interpreted
references to a network element
- QoS Signaling Protocol: A signaling protocol that carries
admission control request for a resource, e.g., RSVP
Yavatkar, et al. Informational [Page 2]
RFC 2753 Framework for Policy-based Admission Control January 2000
- Policy: The combination of rules and services where rules
the criteria for resource access and usage
- Policy control: The application of rules to determine whether
not access to a particular resource should be granted
- Policy Object: Contains policy-related information such as
elements and is carried in a request or response related to
resource allocation decision
- Policy Element: Subdivision of policy objects; contains
units of information necessary for the evaluation of policy rules
A single policy element may carry an user or
identification whereas another policy element may carry
credentials or credit card information. The policy
themselves are expected to be independent of which QoS
protocol is used
- Policy Decision Point (PDP): The point where policy decisions
made
- Policy Enforcement Point (PEP): The point where the
decisions are actually enforced
- Policy Ignorant Node (PIN): A network element that does
explicitly support policy control using the mechanisms defined
this document
- Resource: Something of value in a network infrastructure to
rules or policy criteria are first applied before access
granted. Examples of resources include the buffers in a router
bandwidth on an interface
- Service Provider: Controls the network infrastructure and may
responsible for the charging and accounting of services
- Soft State Model - Soft state is a form of the stateful model
times out installed state at a PEP or PDP. It is an automatic
to erase state in the presence of communication or network
failures. For example, RSVP uses the soft state model
installing reservation state at network elements along the path
a data flow
- Installed State: A new and unique request made from a PEP to a
that must be explicitly deleted
Yavatkar, et al. Informational [Page 3]
RFC 2753 Framework for Policy-based Admission Control January 2000
- Trusted Node: A node that is within the boundaries of
administrative domain (AD) and is trusted in the sense that
admission control requests from such a node do not
need a PDP decision
3. Policy-based Admission Control: Goals and
In this section, we describe the goals and requirements of
and protocols designed to provide policy-based control over
control decisions
- Policies vs Mechanisms: An important point to note is that
framework does not include any discussion of any specific
behavior or does not require use of specific policies. Instead
the framework only outlines the architectural elements
mechanisms needed to allow a wide variety of possible policies
be carried out
- RSVP-specific: The mechanisms must be designed to meet
policy-based control requirements specific to the problem
bandwidth reservation using RSVP as the signaling protocol
However, our goal is to allow for the application of
framework for admission control involving other types of
and QoS services (e.g., Diff-Serv) as long as we do not
from our central goal
- Support for preemption: The mechanisms designed must
support for preemption. By preemption, we mean an ability
remove a previously installed state in favor of accepting a
admission control request. For example, in the case of RSVP
preemption involves the ability to remove one or more
installed reservations to make room for a new resource
request
- Support for many styles of policies: The mechanisms designed
include support for many policies and policy
including bi-lateral and multi-lateral service agreements
policies based on the notion of relative priority. In general
the determination and configuration of viable policies are
responsibility of the service provider
- Provision for Monitoring and Accounting Information:
mechanisms must include support for monitoring policy state
resource usage, and provide access information. In particular
mechanisms must be included to provide usage and
information that may be used for accounting and billing purposes
Yavatkar, et al. Informational [Page 4]
RFC 2753 Framework for Policy-based Admission Control January 2000
- Fault tolerance and recovery: The mechanisms designed on the
of this framework must include provisions for fault tolerance
recovery from failure cases such as failure of PDPs, disruption
communication including network partitions (and
merging) that separate a PDP from its associated PEPs
- Support for Policy-Ignorant Nodes (PINs): Support for
mechanisms described in this document should not be mandatory
every node in a network. Policy based admission control could
enforced at a subset of nodes, for example the boundary
within an administrative domain. These policy capable nodes
function as trusted nodes from the point of view of the policy
ignorant nodes in that administrative domain
- Scalability: One of the important requirements for the
designed for policy control is scalability. The mechanisms
scale at least to the same extent that RSVP scales in terms
accommodating multiple flows and network nodes in the path of
flow. In particular, scalability must be considered
specifying default behavior for merging policy data objects
merging should not result in duplicate policy elements or objects
There are several sensitive areas in terms of scalability
policy control over RSVP. First, not every policy aware node in
infrastructure should be expected to contact a remote PDP.
would cause potentially long delays in verifying requests
must travel up hop by hop. Secondly, RSVP is capable of setting
resource reservations for multicast flows. This implies that
policy control model must be capable of servicing the
requirements of large multicast flows. Thus, the policy
architecture must scale at least as well as RSVP based on
such as the size of RSVP messages, the time required for
network to service an RSVP request, local processing time
per node, and local memory consumed per node
- Security and denial of service considerations: The policy
architecture must be secure as far as the following aspects
concerned. First, the mechanisms proposed under the framework
minimize theft and denial of service threats. Second, it must
ensured that the entities (such as PEPs and PDPs) involved
policy control can verify each other's identity and
necessary trust before communicating
4. Architectural
The two main architectural elements for policy control are the
(Policy Enforcement Point) and the PDP (Policy Decision Point).
Figure 1 shows a simple configuration involving these two elements
PEP is a component at a network node and PDP is a remote entity
Yavatkar, et al. Informational [Page 5]
RFC 2753 Framework for Policy-based Admission Control January 2000
may reside at a policy server. The PEP represents the component
always runs on the policy aware node. It is the point at which
decisions are actually enforced. Policy decisions are made
at the PDP. The PDP itself may make use of additional mechanisms
protocols to achieve additional functionality such as
authentication, accounting, policy information storage, etc.
example, the PDP is likely to use an LDAP-based directory service
storage and retrieval of policy information[6]. This document
not include discussion of these additional mechanisms and
and how they are used
The basic interaction between the components begins with the PEP.
PEP will receive a notification or a message that requires a
decision. Given such an event, the PEP then formulates a request
a policy decision and sends it to the PDP. The request for
control from a PEP to the PDP may contain one or more policy
(encapsulated into one or more policy objects) in addition to
admission control information (such as a flowspec or amount
bandwidth requested) in the original message or event that
the policy decision request. The PDP returns the policy decision
the PEP then enforces the policy decision by appropriately
or denying the request. The PDP may also return
information to the PEP which includes one or more policy elements
This information need not be associated with an admission
decision. Rather, it can be used to formulate an error message
outgoing/forwarded message
________________ Policy
| | ______
| Network Node | | |------------->
| _____ | | | May use LDAP,SNMP,.. for
| | | | | | policy database, authentication,etc
| | PEP |<-----|------->| PDP |------------->
| |_____| | |_____|
| |
|________________|
Figure 1: A simple configuration with the primary policy
architecture components. PDP may use additional mechanisms
protocols for the purpose of accounting, authentication,
storage, etc
The PDP might optionally contact other external servers, e.g.,
accessing configuration, user authentication, accounting and
databases. Protocols defined for network management (SNMP)
directory access (LDAP) might be used for this communication.
the specific type of access and the protocols used may vary
Yavatkar, et al. Informational [Page 6]
RFC 2753 Framework for Policy-based Admission Control January 2000
different implementations, some of these interactions will
network-wide implications and could impact the interoperability
different devices
Of particular importance is the "language" used to specify
policies implemented by the PDP. The number of policies applicable
a network node might potentially be quite large. At the same time
these policies will exhibit high complexity, in terms of number
fields used to arrive at a decision, and the wide range of decisions
Furthermore, it is likely that several policies could be
to the same request profile. For example, a policy may prescribe
treatment of requests from a general user group (e.g., employees of
company) as well as the treatment of requests from specific
of that group (e.g., managers of the company). In this example,
user profile "managers" falls within the specification of
policies, one general and one more specific
In order to handle the complexity of policy decisions and to ensure
coherent and consistent application of policies network-wide,
policy specification language should ensure unambiguous mapping of
request profile to a policy action. It should also permit
specification of the sequence in which different policy rules
be applied and/or the priority associated with each one. Some
these issues are addressed in [6].
In some cases, the simple configuration shown in Figure 1 may not
sufficient as it might be necessary to apply local policies (e.g.,
policies specified in access control lists) in addition to
policies applied at the remote PDP. In addition, it is possible
the PDP to be co-located with the PEP at the same network node
Figure 2 shows the possible configurations
The configurations shown in Figures 1 and 2 illustrate
flexibility in division of labor. On one hand, a centralized
server, which could be responsible for policy decisions on behalf
multiple network nodes in an administrative domain, might
implementing policies of a wide scope, common across the AD. On
other hand, policies which depend on information and conditions
to a particular router and which are more dynamic, might be
implemented locally, at the router
Yavatkar, et al. Informational [Page 7]
RFC 2753 Framework for Policy-based Admission Control January 2000
________________ ____________________
| | | |
| Network Node | Policy Server | Network Node |
| _____ | _____ | _____ _____ |
| | | | | | | | | | | |
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | |
| |_____| | |_____| | |_____| |_____| |
| ^ | | |
| | _____ | |____________________|
| \-->| | |
| | LPDP| |
| |_____| |
| |
|________________|
Figure 2: Two other possible configurations of policy
architecture components. The configuration on the left shows a
decision point at a network node and the configuration on the
shows PEP and PDP co-located at the same node
If it is available, the PEP will first use the LPDP to reach a
decision. This partial decision and the original policy request
next sent to the PDP which renders a final decision (possibly
overriding the LPDP). It must be noted that the PDP acts as the
authority for the decision returned to the PEP and the PEP
enforce the decision rendered by the PDP. Finally, if a shared
has been established for the request and response between the PEP
PDP, it is the responsibility of the PEP to notify the PDP that
original request is no longer in use
Unless otherwise specified, we will assume the configuration shown
the left in Figure 2 in the rest of this document
Under this policy control model, the PEP module at a network
must use the following steps to reach a policy decision
1. When a local event or message invokes PEP for a policy decision
the PEP creates a request that includes information from
message (or local state) that describes the admission
request. In addition, the request includes appropriate
elements as described below
2. The PEP may consult a local configuration database to identify
set of policy elements (called set A) that are to be
locally. The local configuration specifies the types of
elements that are evaluated locally. The PEP passes the
Yavatkar, et al. Informational [Page 8]
RFC 2753 Framework for Policy-based Admission Control January 2000
with the set A to the Local Decision point (LPDP) and collects
result of the LPDP (called "partial result" and referred to
D(A) ).
3. The PEP then passes the request with ALL the policy elements
D(A) to the PDP. The PDP applies policies based on all the
elements and the request and reaches a decision (let us call
D(Q)). It then combines its result with the partial result D(A
using a combination operation to reach a final decision
4. The PDP returns the final policy decision (obtained from
combination operation) to the PEP
Note that in the above model, the PEP MUST contact the PDP even if
(or NULL) policy objects are received in the admission
request. This requirement helps ensure that a request cannot
policy control by omitting policy elements in a reservation request
However, "short circuit" processing is permitted, i.e., if the
of D(A), above, is "no", then there is no need to proceed
further policy processing at the PDP. Still, the PDP must be
of the failure of local policy processing. The same applies to
case when policy processing is successful but admission control (
the resource management level due to unavailable capacity) fails
again the PDP has to be informed of the failure
It must also be noted that the PDP may, at any time, send
asynchronous notification to the PEP to change an earlier decision
to generate a policy error/warning message
4.1. Example of a RSVP
In the case of a RSVP router, Figure 3 shows the interaction
a PEP and other int-serv components within the router. For
purpose of this discussion, we represent all the components of RSVP
related processing by a single RSVP module, but a more
discussion of the exact interaction and interfaces between RSVP
the PEP is provided in a separate document [3].
Yavatkar, et al. Informational [Page 9]
RFC 2753 Framework for Policy-based Admission Control January 2000
______________________________
| |
| Router |
| ________ _____ | _____
| | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____|
| ^ |
| | Traffic control |
| | _____________ |
| \---->| _________ | |
| | |capacity | | |
| | | ADM CTL | | |
| | |_________| | |
--|----------->| ____ ____ | |
| Data | | PC | PS | | |
| | |____|____| | |
| |_____________| |
| |
|______________________________|
Figure 3: Relationship between PEP and other int-serv
within an RSVP router. PC -- Packet Classifier, PS --
When a RSVP message arrives at the router (or an RSVP related
requires a policy decision), the RSVP module is expected to hand
the request (corresponding to the event or message) to its
module. The PEP will use the PDP (and LPDP) to obtain the
decision and communicate it back to the RSVP module
4.2. Additional functionality at the
Typically, PDP returns the final policy decision based on
admission control request and the associated policy elements
However, it should be possible for the PDP to sometimes ask the
(or the admission control module at the network element where
resides) to generate policy-related error messages. For example,
the case of RSVP, the PDP may accept a request and allow
and forwarding of a reservation to a previous hop, but, at the
time, may wish to generate a warning/error message to a
node (NHOP) to warn about conditions such as "your request may
to be torn down in 10 mins, etc." Basically, an ability to
policy-related errors and/or warnings and to propagate them using
native QoS signaling protocol (such as RSVP) is needed. Such a
error returned by the PDP must be able to also specify whether
Yavatkar, et al. Informational [Page 10]
RFC 2753 Framework for Policy-based Admission Control January 2000
reservation request should still be accepted, installed,
forwarded to allow continued normal RSVP processing. In particular
when a PDP sends back an error, it specifies that
1. the message that generated the admission control request
be processed further as usual, but an error message (or warning
be sent in the other direction and include the policy
supplied in that error
2. or, specifies that an error be returned, but the RSVP
should not be forwarded as usual
4.3. Interactions between PEP, LPDP, and PDP at a RSVP
All the details of RSVP message processing and
interactions between different elements at an RSVP router (PEP, LPDP
and PDP are included in separate documents [3,8]. In the following,
few, salient points related to the framework are listed
* LPDP is optional and may be used for making decisions based
policy elements handled locally. The LPDP, in turn, may have to
to external entities (such as a directory server or
authentication server, etc.) for making its decisions
* PDP is stateful and may make decisions even if no policy
are received (e.g., make decisions based on information such
flowspecs and session object in the RSVP messages). The PDP
consult other PDPs, but discussion of inter-PDP communication
coordination is outside the scope of this document
* PDP sends asynchronous notifications to PEP whenever necessary
change earlier decisions, generate errors etc
* PDP exports the information useful for usage monitoring
accounting purposes. An example of a useful mechanism for
purpose is a MIB or a relational database. However, this
does not specify any particular mechanism for this purpose
discussion of such mechanisms is out of the scope of
document
4.4. Placement of Policy Elements in a
By allowing division of labor between an LPDP and a PDP, the
control architecture allows staged deployment by enabling routers
varying degrees of sophistication, as far as policy control
concerned, to communicate with policy servers. Figure 4 depicts
example set of nodes belonging to three different
domains (AD) (Each AD could correspond to a different
Yavatkar, et al. Informational [Page 11]
RFC 2753 Framework for Policy-based Admission Control January 2000
provider in this case). Nodes A, B and C belong to
domain AD-1, advised by PDP PS-1, while D and E belong to AD-2
AD-3, respectively. E communicates with PDP PS-2. In general, it
expected that there will be at least one PDP per
domain
Policy capable network nodes could range from very unsophisticated
such as E, which have no LPDP, and thus have to rely on an
PDP for every policy processing operation, to self-sufficient,
as D, which essentially encompasses both an LPDP and a PDP locally
at the router
AD-1 AD-2 AD-3
________________/\_______________ __/\___ __/\___
{ } { } { }
A B C D
+-------+ +-----+ +-------+ +-------+ +-------+
| RSVP | | RSVP| | RSVP | | RSVP | | RSVP |
+----+ |-------| |-----| |-------| |-------| |-------|
| S1 |--| P | L |--| |----| P | L |----| P | P |----| P | +----+
+----+ | E | D | +-----+ | E | D | | E | D | | E |-| R1 |
| P | P | | P | P | | P | P | | P | +----+
+-------+ +-------+ +-------+ +-------+
^ ^ ^
| | |
| | |
| | +-------+
| | | PDP |
| +------+ | |-------|
+-------->| PDP |<------+ | |
|------| +-------+
| | PS-2
+------+
PS-1
Figure 4: Placement of Policy Elements in an
5. Example Policies, Scenarios, and Policy
In the following, we present examples of desired policies
scenarios requiring policy control that the policy control
should be able to support. In some cases, possible approach(es)
achieving the desired goals are also outlined with a list of
issues to be resolved
5.1. Admission control policies based on factors such as Time-of-Day
User Identity, or credentials
Yavatkar, et al. Informational [Page 12]
RFC 2753 Framework for Policy-based Admission Control January 2000
Policy control must be able to express and enforce rules
temporal dependencies. For example, a group of users might be
to make reservations at certain levels only during off-peak hours
In addition, the policy control must also support policies that
into account identity or credentials of users requesting a
service or resource. For example, an RSVP reservation request may
denied or accepted based on the credentials or identity supplied
the request
5.2. Bilateral agreements between service
Until recently, usage agreements between service providers
traffic crossing their boundaries have been quite simple.
example, two ISPs might agree to accept all traffic from each other
often without performing any accounting or billing for the "foreign
traffic carried. However, with the availability of QoS
based on Integrated and Differentiated Services,
differentiation and quality of service guarantees are being
into the Internet. As ISPs start to sell their customers
grades of service and can differentiate among different sources
traffic, they will also seek mechanisms for charging each other
traffic (and reservations) transiting their networks. One
incentive in establishing such mechanisms is the potential
in terms of the customer base that different providers will exhibit
ISPs focused on servicing corporate traffic are likely to
much higher demand for reserved services than those that service
consumer market. Lack of sophisticated accounting schemes for inter
ISP traffic could lead to inefficient allocation of costs
different service providers
Bilateral agreements could fall into two broad categories; local
global. Due to the complexity of the problem, it is expected
initially only the former will be deployed. In these, providers
manage a network cloud or administrative domain contract with
closest point of contact (neighbor) to establish ground rules
arrangements for access control and accounting. These contracts
mostly local and do not rely on global agreements; consequently,
policy node maintains information about its neighboring nodes only
Referring to Figure 4, this model implies that provider AD-1
established arrangements with AD-2, but not with AD-3, for usage
each other's network. Provider AD-2, in turn, has in place
with AD-3 and so on. Thus, when forwarding a reservation request
AD-2, provider AD-2 will charge AD-1 for use of all resources
AD-1's network. This information is obtained by recursively
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
Yavatkar, et al. Informational [Page 13]
RFC 2753 Framework for Policy-based Admission Control January 2000
message before forwarding it to a neighboring provider's network
This policy object will contain information such as the identity
the provider that generated them and the equivalent of an
number where charges can be accumulated. Since agreements only
among neighboring nodes, policy objects have to be rewritten as
messages cross the boundaries of administrative domains or provider'
networks
5.3. Priority based admission control
In many settings, it is useful to distinguish between reservations
the basis of some level of "importance". For example, this can
useful to avoid that the first reservation being granted the use
some resources, be able to hog those resources for some
period of time. Similarly, this may be useful to allow
calls to go through even during periods of congestion.
functionality can be supported by associating priorities
reservation requests, and conveying this priority
together with other policy information
In its basic form, the priority associated with a
directly determines a reservation's rights to the resources
requests. For example, assuming that priorities are
through integers in the range 0 to 32 with 32 being the
priority, a reservation of priority, say, 10, will always
accepted, if the amount of resources held by lower
reservations is sufficient to satisfy its requirements. In
words, in case there are not enough free resources (bandwidth
buffers, etc.) at a node to accommodate the priority 10 request,
node will attempt to free up the necessary resources by
existing lower priority reservations
There are a number of requirements associated with the support
priority and their proper operation. First, traffic control in
router needs to be aware of priorities, i.e., classify
reservations according to their priority, so that it is capable
determining how many and which ones to preempt, when required
accommodate a higher priority reservation request. Second, it
important that preemption be made consistently at different nodes,
order to avoid transient instabilities. Third and possibly
important, merging of priorities needs to be carefully
and its impact clearly understood as part of the associated
definition
Of the three above requirements, merging of priority information
the more complex and deserves additional discussions. The
of merging priority information arises from the fact that
merging is to be performed in addition to the merging of
Yavatkar, et al. Informational [Page 14]
RFC 2753 Framework for Policy-based Admission Control January 2000
information. When reservation (FLOWSPEC) information is identical
i.e., homogeneous reservations, merging only needs to
priority information, and the simple rule of keeping the
priority provides an adequate answer. However, in the case
heterogeneous reservations, the *two-dimensional nature* of
(FLOWSPEC, priority) pair makes their ordering, and
merging, difficult. A description of the handling of different
of RSVP priority objects is presented in [7].
5.4. Pre-paid calling card or
A model of increasing popularity in the telephone network is that
the pre-paid calling card. This concept could also be applied to
Internet; users purchase "tokens" which can be redeemed at a
time for access to network services. When a user makes a
request through, say, an RSVP RESV message, the user supplies
unique identification number of the "token", embedded in a
object. Processing of this object at policy capable routers
in decrementing the value, or number of remaining units of service
of this token
Referring to Figure 4, suppose receiver R1 in the
domain AD3 wants to request a reservation for a service
in AD1. R1 generates a policy data object of type PD(prc, CID),
"prc" denotes pre-paid card and CID is the card
number. Along with other policy objects carried in the RESV message
this object is received by node E, which forwards it to its PEP
PEP_E, which, in turn, contacts PDP PS-3. PS-3 either
locally, or has remote access to, a database of pre-paid
numbers. If the amount of remaining credit in CID is sufficient,
PDP accepts the reservation and the policy object is returned
PEP_E. Two issues have to be resolved here
* What is the scope of these charges
* When are charges (in the form of decrementing the
credit) first applied
The answer to the first question is related to the
agreement model in place. If, on the one hand, provider AD-3
established agreements with both AD-2 and AD-1, it could charge
the cost of the complete reservation up to sender S1. In this
PS-2 removes the PD(prc,CID) object from the outgoing RESV message
On the other hand, if AD-3 has no bilateral agreements in place,
will simply charge CID for the cost of the reservation within AD-3
and then forward PD(prc,CID) in the outgoing RESV message.
PDPs in other administrative domains will charge CID for
Yavatkar, et al. Informational [Page 15]
RFC 2753 Framework for Policy-based Admission Control January 2000
respective reservations. Since multiple entities are both
(remaining credit) and writing (decrementing credit) to the
database, some coordination and concurrency control might be needed
The issues related to location, management, coordination of
card (or similar) databases is outside the scope of this document
Another problem in this scenario is determining when the credit
exhausted. The PDPs should contact the database periodically
submit a charge against the CID; if the remaining credit
zero, there must be a mechanism to detect that and to
revocation or termination of privileges granted based on the credit
Regarding the issue of when to initiate charging, ideally that
happen only after the reservation request has succeeded. In the
of local charges, that could be communicated by the router to
PDP
5.5. Sender Specified Restrictions on Receiver
The ability of senders to specify restrictions on reservations,
on receiver identity, number of receivers or reservation cost
be useful in future network applications. An example could be
application in which the sender pays for service delivered
receivers. In such a case, the sender might be willing to assume
cost of a reservation, as long as it satisfies certain criteria,
example, it originates from a receiver who belongs to an
control list (ACL) and satisfies a limit on cost. (Notice that
could allow formation of "closed" multicast groups).
In the policy based admission control framework such a scheme
be achieved by having the sender generate appropriate policy objects
carried in a PATH message, which install state in routers on the
to receivers. In accepting reservations, the routers would have
compare the RESV requests to the installed state
A number of different solutions can be built to address
scenario; precise description of a solution is beyond the scope
this document
6. Interaction Between the Policy Enforcement Point (PEP) and the
Decision Point (PDP
In the case of an external PDP, the need for a communication
between the PEP and PDP arises. In order to allow
interoperability between different vendors networking elements
(external) policy servers, this protocol should be standardized
Yavatkar, et al. Informational [Page 16]
RFC 2753 Framework for Policy-based Admission Control January 2000
6.1. PEP to PDP Protocol
This section describes a set of general requirements for
communication protocol between the PEP and an external PDP
* Reliability: The sensitivity of policy control
necessitates reliable operation. Undetected loss of policy
or responses may lead to inconsistent network control
and are clearly unacceptable for actions such as billing
accounting. One option for providing reliability is the re-use
the TCP as the transport protocol
* Small delays: The timing requirements of policy decisions
to QoS signaling protocols are expected to be quite strict.
PEP to PDP protocol should add small amount of delay to
response delay experienced by queries placed by the PEP to
PDP
* Ability to carry opaque objects: The protocol should allow
delivery of self-identifying, opaque objects, of variable length
such as RSVP messages, RSVP policy objects and other objects
might be defined as new policies are introduced. The
should not have to be changed every time a new object has to
exchanged
* Support for PEP-initiated, two-way Transactions: The
must allow for two-way transactions (request-response exchanges
between a PEP and a PDP. In particular, PEPs must be able
initiate requests for policy decision, re-negotiation
previously made policy decision, and exchange of
information. To some extent, this requirement is closely tied
the goal of meeting the requirements of RSVP-specific, policy
based admission control. RSVP signaling events such as arrival
RESV refresh messages, state timeout, and merging of
require that a PEP (such as an RSVP router) request a
decision from PDP at any time. Similarly, PEP must be able
report monitoring information and policy state changes to PDP
any time
* Support for asynchronous notification: This is required in
to allow both the policy server and client to notify each other
the case of an asynchronous change in state, i.e., a change
is not triggered by a signaling message. For example, the
would need to notify the client if a particular reservation has
be terminated due to expiration of a user's credentials or
balance. Likewise, the client has to inform the server of
reservation rejection which is due to admission control failure
Yavatkar, et al. Informational [Page 17]
RFC 2753 Framework for Policy-based Admission Control January 2000
* Handling of multicast groups: The protocol should provision
handling of policy decisions related to multicast groups
* QoS Specification: The protocol should allow for
specification of level of service requirements in the PEP
forwarded to the PDP
7. Security
The communication tunnel between policy clients and policy
should be secured by the use of an IPSEC [4] channel. It is
that this tunnel makes use of both the AH (Authentication Header)
ESP (Encapsulating Security Payload) protocols, in order to
confidentiality, data origin authentication, integrity and
prevention
In the case of the RSVP signaling mechanism, RSVP MD5 [2]
authentication can be used to secure communications between
elements
8.
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin
"Resource ReSerVation Protocol (RSVP) -- Version 1
Specification", RFC 2205, September 1997.
[2] Baker, F., Lindell, B. and M. Talwar, "RSVP
Authentication", RFC 2747, January 2000.
[3] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[4] Atkinson, R., "Security Architecture for the Internet Protocol",
RFC 1825, August 1995.
[5] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "
Authentication Dial In User Service (RADIUS)", RFC 2138,
1997.
[6] Rajan, R., et al., "Schema for Differentiated Services
Integrated Services in Networks", Work in Progress
[7] Herzog, S., "RSVP Preemption Priority Policy", Work in Progress
[8] Herzog, S., "COPS Usage for RSVP", RFC 2749, January 2000.
Yavatkar, et al. Informational [Page 18]
RFC 2753 Framework for Policy-based Admission Control January 2000
9.
This is a result of an ongoing discussion among many members of
RAP group including Jim Boyle, Ron Cohen, Laura Cunningham,
Durham, Shai Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry
10. Authors'
Raj
Intel
2111 N.E. 25th Avenue
Hillsboro, OR 97124
Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.
Dimitrios
IBM T.J. Watson Research
P.O. Box 704
Yorktown
NY 10598
Phone: +1 914-784-7536
EMail: dimitris@watson.ibm.
Roch
University of
Dept. of Electrical
200 South 33rd
Philadelphia, PA 19104
Phone: +1 215 898-9351
EMail: guerin@ee.upenn.
Yavatkar, et al. Informational [Page 19]
RFC 2753 Framework for Policy-based Admission Control January 2000
11. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Yavatkar, et al. Informational [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
