< draft-ietf-rap-framework-02.txt		draft-ietf-rap-framework-03.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
	draft-ietf-rap-framework-02.txt Roch Guerin, U. Of Pennsylvania		Roch Guerin, U. Of Pennsylvania
	April 1999		April 1999
	Expires: December 1999		Expires: December 1999
			draft-ietf-rap-framework-03.txt
	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 and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	skipping to change at page 2, line 13 ¶		skipping to change at page 2, line 13 ¶
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	A Framework for Policy-based Admission Control March 1999		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
	tiated Services Working Group are also directed at definition of mechan-		Differentiated Services Working Group are also directed at definition of
	isms that support aggregate QoS services. The int-serv model for these new		mechanisms that support aggregate QoS services. The int-serv model for
	services requires explicit signaling of the QoS (Quality of Service)		these new services requires explicit signaling of the QoS (Quality of
	requirements from the end points and provision of admission and traffic		Service) requirements from the end points and provision of admission and
	control at Integrated Services routers. The proposed standards for RSVP		traffic control at Integrated Services routers. The proposed standards for
	[RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a		RSVP [RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples
	new reservation setup protocol and new service definitions respectively.		of a new reservation setup protocol and new service definitions
	Under the int-serv model, certain data flows receive preferential treat-		respectively. Under the int-serv model, certain data flows receive
	ment over other flows; the admission control component only takes into		preferential treatment over other flows; the admission control component
	account the requester's resource reservation request and available capa-		only takes into account the requester's resource reservation request and
	city to determine whether or not to accept a QoS request. However, the		available capacity to determine whether or not to accept a QoS request.
	int-serv mechanisms do not include an important aspect of admission con-		However, the int-serv mechanisms do not include an important aspect of
	trol: network managers and service providers must be able to monitor, con-		admission control: network managers and service providers must be able to
	trol, and enforce use of network resources and services based on policies		monitor, control, and enforce use of network resources and services based
	derived from criteria such as the identity of users and applications,		on policies derived from criteria such as the identity of users and
	traffic/bandwidth requirements, security considerations, and time-of-		applications, traffic/bandwidth requirements, security considerations, and
	day/week. Similarly, diff-serv mechanisms also need to take into account		time-of-day/week. Similarly, diff-serv mechanisms also need to take into
	policies that take into account various criteria such as customer iden-		account policies that take into account various criteria such as customer
	tity, ingress points, and so on.		identity, ingress points, and so on.
	This document is concerned with specifying a framework for providing		This document is concerned with specifying a framework for providing
	policy-based control over admission control decisions. In particular, it		policy-based control over admission control decisions. In particular, it
	focuses on policy-based control over admission control using RSVP as an		focuses on policy-based control over admission control using RSVP as an
	example of the QoS signaling mechanism. Even though the focus of the work		example of the QoS signaling mechanism. Even though the focus of the work
	is on RSVP-based admission control, the document outlines a framework that		is on RSVP-based admission control, the document outlines a framework that
	can provide policy-based admission control in other QoS contexts. We argue		can provide policy-based admission control in other QoS contexts. We argue
	that policy-based control must be applicable to different kinds and quali-		that policy-based control must be applicable to different kinds and
	ties of services offered in the same network and our goal is to consider		qualities of services offered in the same network and our goal is to
	such extensions whenever possible.		consider 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
	ments of the framework in Section 4 and describe the functionality assumed		elements of the framework in Section 4 and describe the functionality
	for each component. Section 5 discusses example policies, possible		assumed for each component. Section 5 discusses example policies,
	scenarios, and policy support needed for those scenarios. Section 6 speci-		possible scenarios, and policy support needed for those scenarios. Section
	fies the requirements for a client-server protocol for communication		6 specifies the requirements for a client-server protocol for
	between a policy server (PDP) and its client (PEP) and evaluates suitabil-		communication between a policy server (PDP) and its client (PEP) and
	ity of some of the existing protocols for this purpose.
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
			evaluates suitability of some of the existing protocols for this purpose.
	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
	poses.		purposes.
	- Network Element or Node: Routers, switches, hubs are examples of		- Network Element or Node: Routers, switches, hubs are examples of
	network nodes. They are the entities where resource allocation		network nodes. They are the entities where resource allocation
	decisions have to be made and the decisions have to be enforced. A		decisions have to be made and the decisions have to be enforced. A
	RSVP router which allocates part of a link capacity (or buffers) to		RSVP router which allocates part of a link capacity (or buffers) to
	a particular flow and ensures that only the admitted flows have		a particular flow and ensures that only the admitted flows have
	access to their reserved resources is an example of a network ele-		access to their reserved resources is an example of a network
	ment of interest in our context.		element of interest in our context.
	In this document, sometimes we use the terms router, network ele-		In this document, sometimes we use the terms router, network
	ment, and network node interchangeably, but should be interpreted		element, and network node interchangeably, but should be
	as reference to a network element.		interpreted as reference to a network element.
	- QoS Signaling Protocol: A signaling protocol that carries an admis-		- QoS Signaling Protocol: A signaling protocol that carries an
	sion control request for a bandwidth resource, e.g., RSVP.		admission control request for a bandwidth resource, e.g., RSVP.
	- Policy: The combination of rules and services where rules define		- Policy: The combination of rules and services where rules define
	the criteria for resource access and usage.		the criteria for resource access and usage.
	- Policy control: The application of rules to determine whether or		- Policy control: The application of rules to determine whether or
	not access to a particular resource should be granted.		not access to a particular resource should be granted.
	- Policy Object: Contains policy-related info such as policy ele-		- Policy Object: Contains policy-related info such as policy
	ments and is carried in a request or response related to resource		elements and is carried in a request or response related to
	allocation decision.		resource allocation decision.
	- Policy Element: Subdivision of policy objects; contains single		- Policy Element: Subdivision of policy objects; contains single
	units of information necessary for the evaluation of policy rules.		units of information necessary for the evaluation of policy rules.
	A single policy element carries an user or application identifica-		A single policy element carries an user or application
	tion whereas another policy element may carry user credentials or		identification whereas another policy element may carry user
	credit card information. Examples of policy elements include iden-		credentials or credit card information. Examples of policy
	tity of the requesting user or application, user/app credentials,
	etc. The policy elements themselves are expected to be independent
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
	of which QoS signaling protocol is used.		elements include identity of the requesting user or application,
			user/app credentials, etc. The policy elements themselves are
			expected to be independent 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
	sions are actually enforced.		decisions are actually enforced.
	- Policy Ignorant Node (PIN): A network element that does not expli-		- Policy Ignorant Node (PIN): A network element that does not
	citly support policy control using the mechanisms defined in this		explicitly support policy control using the mechanisms defined in
	document.		this document.
	- Resource: Something of value in a network infrastructure to which		- Resource: Something of value in a network infrastructure to which
	rules or policy criteria are first applied before access is		rules or policy criteria are first applied before access is
	granted. Examples of resources include the buffers in a router and		granted. Examples of resources include the buffers in a router and
	bandwidth on an interface.		bandwidth on an interface.
	- Service Provider: Controls the network infrastructure and may be		- Service Provider: Controls the network infrastructure and may be
	responsible for the charging and accounting of services.		responsible for the charging and accounting of services.
	- Soft State Model - Soft state is a form of the stateful model that		- Soft State Model - Soft state is a form of the stateful model that
	times out installed state at a PEP or PDP. It is an automatic way		times out installed state at a PEP or PDP. It is an automatic way
	to erase state in the presence of communication or network element		to erase state in the presence of communication or network element
	failures. For example, RSVP uses the soft state model for instal-		failures. For example, RSVP uses the soft state model for
	ling reservation state at network elements along the path of a data		installing reservation state at network elements along the path of
	flow.		a data flow.
	- 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
	trative domain (AD) and is trusted in the sense that the admission		administrative domain (AD) and is trusted in the sense that the
	control requests from such a node do not necessarily need a PDP		admission control requests from such a node do not necessarily need
	decision.		a PDP decision.
	3. Policy-based Admission Control: Goals and Requirements
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
			3. Policy-based Admission Control: Goals and Requirements
	In this section, we describe the goals and requirements of mechanisms and		In this section, we describe the goals and requirements of mechanisms and
	protocols designed to provide policy-based control over admission control		protocols designed to provide policy-based control over admission control
	decisions.		decisions.
	- Policies vs Mechanisms: An important point to note is that the		- Policies vs Mechanisms: An important point to note is that the
	framework does not include any discussion of any specific policy		framework does not include any discussion of any specific policy
	behavior or does not require use of specific policies. Instead, the		behavior or does not require use of specific policies. Instead, the
	framework only outlines the architectural elements and mechanisms		framework only outlines the architectural elements and mechanisms
	needed to allow a wide variety of possible policies to be carried		needed to allow a wide variety of possible policies to be carried
	out.		out.
	- RSVP-specific: The mechanisms must be designed to meet the policy-		- RSVP-specific: The mechanisms must be designed to meet the policy-
	based control requirements specific to the problem of bandwidth		based control requirements specific to the problem of bandwidth
	reservation using RSVP as the signaling protocol. However, our goal		reservation using RSVP as the signaling protocol. However, our goal
	is to allow for the application of this framework for admission		is to allow for the application of this framework for admission
	control involving other types of resources and QoS services (e.g.,		control involving other types of resources and QoS services (e.g.,
	Diff-Serv) as long as we do not diverge from our central goal.		Diff-Serv) as long as we do not diverge from our central goal.
	- Support for preemption: The mechanisms designed must include sup-		- Support for preemption: The mechanisms designed must include
	port for preemption. By preemption, we mean an ability to remove a		support for preemption. By preemption, we mean an ability to remove
	previously installed state in favor of accepting a new admission		a previously installed state in favor of accepting a new admission
	control request. For example, in the case of RSVP, preemption		control request. For example, in the case of RSVP, preemption
	involves the ability to remove one or more currently installed		involves the ability to remove one or more currently installed
	reservations to make room for a new resource reservation request.		reservations to make room for a new resource reservation request.
	- Support for many styles of policies: The mechanisms designed must		- Support for many styles of policies: The mechanisms designed must
	include support for many policies and policy configurations includ-		include support for many policies and policy configurations
	ing bi-lateral and multi-lateral service agreements and policies		including bi-lateral and multi-lateral service agreements and
	based on the notion of relative priority. In general, the determi-		policies based on the notion of relative priority. In general, the
	nation and configuration of viable policies are the responsibility		determination and configuration of viable policies are the
	of the service provider.		responsibility of the service provider.
	- Provision for Monitoring and Accounting Information: The mechan-		- Provision for Monitoring and Accounting Information: The
	isms must include support for monitoring policy state, resource		mechanisms must include support for monitoring policy state,
	usage, and provide access information. In particular, mechanisms		resource usage, and provide access information. In particular,
	must be included to provide usage and access information that may		mechanisms must be included to provide usage and access information
	be used for accounting and billing purposes.		that may 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
	recovery from failure cases such as failure of PDPs, disruption in
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
			of this framework must include provisions for fault tolerance and
			recovery from failure cases such as failure of PDPs, disruption in
	communication including network partitions (and subsequent merging)		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
	isms described in this document should not be mandatory for every		mechanisms described in this document should not be mandatory for
	node in a network. Policy based admission control could be enforced		every node in a network. Policy based admission control could be
	at a subset of nodes, for example the boundary nodes within an		enforced at a subset of nodes, for example the boundary nodes
	administrative domain. These policy capable nodes would function as		within an administrative domain. These policy capable nodes would
	trusted nodes from the point of view of the policy-ignorant nodes		function as trusted nodes from the point of view of the policy-
	in that administrative domain.		ignorant nodes in that administrative domain.
	- Scalability: One of the important requirements for the mechanisms		- Scalability: One of the important requirements for the mechanisms
	designed for policy control is scalability. The mechanisms must		designed for policy control is scalability. The mechanisms must
	scale at least to the same extent that RSVP scales in terms of		scale at least to the same extent that RSVP scales in terms of
	accommodating multiple flows and network nodes in the path of a		accommodating multiple flows and network nodes in the path of a
	flow. In particular, scalability must be considered when specifying		flow. In particular, scalability must be considered when specifying
	default behavior for merging policy data objects and merging should		default behavior for merging policy data objects and merging should
	not result in duplicate policy elements or objects. There are		not result in duplicate policy elements or objects. There are
	several sensitive areas in terms of scalability for policy control		several sensitive areas in terms of scalability for policy control
	over RSVP. First, not every policy aware node in an infrastructure		over RSVP. First, not every policy aware node in an infrastructure
	should be expected to contact a remote PDP. This would cause poten-		should be expected to contact a remote PDP. This would cause
	tially long delays in verifying requests that must travel up hop by		potentially long delays in verifying requests that must travel up
	hop. Secondly, RSVP is capable of setting up resource reservations		hop by hop. Secondly, RSVP is capable of setting up resource
	for multicast flows. This implies that the policy control model		reservations for multicast flows. This implies that the policy
	must be capable of servicing the special requirements of large mul-		control model must be capable of servicing the special requirements
	ticast flows. Thus, the policy control architecture must scale at		of large multicast flows. Thus, the policy control architecture
	least as well as RSVP based on factors such as the size of RSVP		must scale at least as well as RSVP based on factors such as the
	messages, the time required for the network to service an RSVP		size of RSVP messages, the time required for the network to service
	request, local processing time required per node, and local memory		an RSVP request, local processing time required per node, and local
	consumed per node.		memory consumed per node.
	- Security and denial of service considerations: The policy control		- Security and denial of service considerations: The policy control
	architecture must be secure as far as the following aspects are		architecture must be secure as far as the following aspects are
	concerned. First, the mechanisms proposed under the framework must		concerned. First, the mechanisms proposed under the framework must
	minimize theft and denial of service threats. Second, it must be		minimize theft and denial of service threats. Second, it must be
	ensured that the entities (such as PEPs and PDPs) involved in pol-		ensured that the entities (such as PEPs and PDPs) involved in
	icy control can verify each other's identity and establish neces-		policy control can verify each other's identity and establish
	sary trust before communicating.		necessary trust before communicating.
	4. Architectural Elements		4. Architectural Elements
	The two main architectural elements for policy control are the PEP (Policy
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
			The two main architectural elements for policy control are the PEP (Policy
	Enforcement Point) and the PDP (Policy Decision Point). Figure 1 shows a		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
	tory service for storage and retrieval of policy information[6]. This		directory service for storage and retrieval of policy information[6]. This
	document does not include discussion of these additional mechanisms and		document does not include discussion of these additional mechanisms and
	protocols and how they are used.		protocols and how they are used.
	The basic interaction between the components begins with the PEP. The PEP		The basic interaction between the components begins with the PEP. The PEP
	will receive a notification or a message that requires a policy decision.		will receive a notification or a message that requires a policy decision.
	Given such an event, the PEP then formulates a request for a policy deci-		Given such an event, the PEP then formulates a request for a policy
	sion and sends it to the PDP. The request for policy control from a PEP		decision and sends it to the PDP. The request for policy control from a
	to the PDP may contain one or more policy elements (encapsulated into one		PEP to the PDP may contain one or more policy elements (encapsulated into
	or more policy objects) in addition to the admission control information		one or more policy objects) in addition to the admission control
	(such as a flowspec or amount of bandwidth requested) in the original mes-		information (such as a flowspec or amount of bandwidth requested) in the
	sage or event that triggered the policy decision request. The PDP returns		original message or event that triggered the policy decision request. The
	the policy decision and the PEP then enforces the policy decision by		PDP returns the policy decision and the PEP then enforces the policy
	appropriately accepting or denying the request. The PDP may also return		decision by appropriately accepting or denying the request. The PDP may
	additional information to the PEP which includes one or more policy ele-		also return additional information to the PEP which includes one or more
	ments. This information need not be associated with an admission control		policy elements. This information need not be associated with an admission
	decision. Rather, it can be used to formulate an error message or		control decision. Rather, it can be used to formulate an error message or
	outgoing/forwarded message.		outgoing/forwarded message.
	________________ Policy server		________________ Policy server
	| | ______		| | ______
	| Network Node | | |------------->		| Network Node | | |------------->
	| _____ | | | May use LDAP,SNMP,.. for accessing		| _____ | | | May use LDAP,SNMP,.. for accessing
	| | | | | | policy database, authentication,etc.		| | | | | | policy database, authentication,etc.
	| | PEP |<-----|------->| PDP |------------->		| | PEP |<-----|------->| PDP |------------->
	| |_____| | |_____|		| |_____| | |_____|
	| |		| |
	|________________|		|________________|
	Figure 1: A simple configuration with the primary policy control		Figure 1: A simple configuration with the primary policy control
	architecture components. PDP may use additional mechanisms and protocols		architecture components. PDP may use additional mechanisms and protocols
	for the purpose of accounting, authentication, policy storage, etc.		for the purpose of accounting, authentication, policy storage, etc.
	The PDP might optionally contact other external servers, e.g., for access-		The PDP might optionally contact other external servers, e.g., for
	ing configuration, user authentication, accounting and billing databases.		accessing configuration, user authentication, accounting and billing
	Protocols defined for network management (SNMP) or directory access (LDAP)		databases. Protocols defined for network management (SNMP) or directory
	might be used for this communication. While the specific type of access		access (LDAP) might be used for this communication. While the specific
	and the protocols used may vary among different implementations, some of
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
	these interactions will have network-wide implications and could impact		type of access and the protocols used may vary among different
	the interoperability of different devices.		implementations, some of these interactions will have network-wide
			implications and could impact the interoperability of different devices.
	Of particular importance is the "language" used to specify the policies		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
	example, a policy may prescribe the treatment of requests from a general		example, a policy may prescribe the treatment of requests from a general
	user group (e.g., employees of a company) as well as the treatment of		user group (e.g., employees of a company) as well as the treatment of
	requests from specific members of that group (e.g., managers of the com-		requests from specific members of that group (e.g., managers of the
	pany). In this example, the user profile "managers" falls within the		company). In this example, the user profile "managers" falls within the
	specification of two policies, one general and one more specific.		specification of two policies, one general and one more specific.
	In order to handle the complexity of policy decisions and to ensure a		In order to handle the complexity of policy decisions and to ensure a
	coherent and consistent application of policies network-wide, the policy		coherent and consistent application of policies network-wide, the policy
	specification language should ensure unambiguous mapping of a request pro-		specification language should ensure unambiguous mapping of a request
	file to a policy action. It should also permit the specification of the		profile to a policy action. It should also permit the specification of the
	sequence in which different policy rules should be applied and/or the		sequence in which different policy rules should be applied and/or the
	priority associated with each one. Some of these issues are addressed in		priority associated with each one. Some of these issues are addressed in
	[6].		[6].
	In some cases, the simple configuration shown in Figure 1 may not be suf-		In some cases, the simple configuration shown in Figure 1 may not be
	ficient as it might be necessary to apply local policies (e.g., policies		sufficient as it might be necessary to apply local policies (e.g.,
	specified in access control lists) in addition to the policies applied at		policies specified in access control lists) in addition to the policies
	the remote PDP. In addition, it is possible for the PDP to be co-located		applied at the remote PDP. In addition, it is possible for the PDP to be
	with the PEP at the same network node. Figure 2 shows the possible confi-		co-located with the PEP at the same network node. Figure 2 shows the
	gurations.		possible configurations.
	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
	tion and conditions local to a particular router and which are more		information 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 March 1999		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 9, line 27 ¶		skipping to change at page 9, line 27 ¶
	| | LPDP| |		| | LPDP| |
	| |_____| |		| |_____| |
	| |		| |
	|________________|		|________________|
	Figure 2: Two other possible configurations of policy control		Figure 2: Two other possible configurations of policy control
	architecture components. The configuration on left shows a local decision		architecture components. The configuration on left shows a local decision
	point at a network node and the configuration on the left shows PEP and		point at a network node and the configuration on the left shows PEP and
	PDP co-located at the same node.		PDP co-located at the same node.
	If it is available, the PEP will first use the LPDP to reach a local deci-		If it is available, the PEP will first use the LPDP to reach a local
	sion. This partial decision and the original policy request are next sent		decision. This partial decision and the original policy request are next
	to the PDP which renders a final decision (possibly, overriding the		sent to the PDP which renders a final decision (possibly, overriding the
	LPDP). It must be noted that the PDP acts as the final authority for the		LPDP). It must be noted that the PDP acts as the final authority for the
	decision returned to the PEP and the PEP must enforce the decision ren-		decision returned to the PEP and the PEP must enforce the decision
	dered by the PDP. Finally, if a shared state has been established for the		rendered by the PDP. Finally, if a shared state has been established for
	request and response between the PEP and PDP, it is the responsibility of		the request and response between the PEP and PDP, it is the responsibility
	the PEP to notify the PDP that the original request is no longer in use.		of the PEP to notify the PDP that the original request is no longer in
			use.
	Unless otherwise specified, we will assume the configuration shown on the		Unless otherwise specified, we will assume the configuration shown on the
	left in Figure 2 in the rest of this document.		left in Figure 2 in the rest of this document.
	Under this policy control model, the PEP module at a network node must use		Under this policy control model, the PEP module at a network node must use
	the following steps to reach a policy decision:		the following steps to reach a policy decision:
	1. When a local event or message invokes PEP for a policy decision,		1. When a local event or message invokes PEP for a policy decision,
	the PEP creates a request that includes information from the mes-		the PEP creates a request that includes information from the
	sage (or local state) that describes the admission control request.		message (or local state) that describes the admission control
	In addition, the request includes appropriate policy elements as		request. In addition, the request includes appropriate policy
	described below.		elements as 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
	ments that are evaluated locally. The PEP passes the request with
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
	the set A to the Local Decision point (LPDP) and collects the		elements that are evaluated locally. The PEP passes the request
			with 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.
	4. The PDP returns the final policy decision (one after the combina-		4. The PDP returns the final policy decision (one after the
	tion operation) to the PEP.		combination operation) to the PEP.
	Note that in the above model, the PEP *must* contact the PDP even if no		Note that in the above model, the PEP *must* contact the PDP even if no
	(or NULL) policy objects are received in the admission control request.		(or NULL) policy objects are received in the admission control request.
	This requirement would help ensure that a request cannot bypass policy		This requirement would help ensure that a request cannot bypass policy
	control by omitting policy elements in a reservation request. However,		control by omitting policy elements in a reservation request. However,
	``short circuit'' processing is permitted, i.e., if the result of D(A),		``short circuit'' processing is permitted, i.e., if the result of D(A),
	above, is ``no'', then there is no need to proceed with further policy		above, is ``no'', then there is no need to proceed with further policy
	processing at the policy server. Still, the PDP must be informed of the		processing at the policy server. Still, the PDP must be informed of the
	failure of local policy processing. The same applies to the case when pol-		failure of local policy processing. The same applies to the case when
	icy processing is successful but admission control (at the resource		policy processing is successful but admission control (at the resource
	management level due to unavailable capacity) fails; again the policy		management level due to unavailable capacity) fails; again the policy
	server has to be informed of the failure.		server has to be informed of the failure.
	It must also be noted that the PDP may, at any time, send an asynchronous		It must also be noted that the PDP may, at any time, send an asynchronous
	notification to the PEP to change its earlier decision or to generate a		notification to the PEP to change its earlier decision or to generate a
	policy error/warning message.		policy error/warning message.
	4.1. Example of a RSVP Router		4.1. Example of a RSVP Router
	In the case of a RSVP router, Figure 3 shows the interaction between a PEP		In the case of a RSVP router, Figure 3 shows the interaction between a PEP
	and other int-serv components within the router. For the purpose of this		and other int-serv components within the router. For the purpose of this
	discussion, we represent all the components of RSVP-related processing by		discussion, we represent all the components of RSVP-related processing by
	a single RSVP module, but more detailed discussion of the exact interac-		a single RSVP module, but more detailed discussion of the exact
	tion and interfaces between RSVP and PEP will be described in a separate		interaction and interfaces between RSVP and PEP will be described in a
	document [3].		separate document [3].
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
	______________________________		______________________________
	| |		| |
	| Router |		| Router |
	| ________ _____ | _____		| ________ _____ | _____
	| | | | | | | |		| | | | | | | |
	| | RSVP |<------->| PEP |<--|---------->| PDP |		| | RSVP |<------->| PEP |<--|---------->| PDP |
	| |________| |_____| | |_____|		| |________| |_____| | |_____|
	skipping to change at page 11, line 47 ¶		skipping to change at page 11, line 47 ¶
	4.2. Additional functionality at the PDP		4.2. Additional functionality at the PDP
	Typically, PDP returns the final policy decision based on an admission		Typically, PDP returns the final policy decision based on an admission
	control request and the associated policy elements. However, it should be		control request and the associated policy elements. However, it should be
	possible for the PDP to sometimes ask the PEP (or the admission control		possible for the PDP to sometimes ask the PEP (or the admission control
	module at the network element where PEP resides) to generate policy-		module at the network element where PEP resides) to generate policy-
	related error messages. For example, in the case of RSVP, the PDP may		related error messages. For example, in the case of RSVP, the PDP may
	accept a request and allow installation and forwarding of a reservation to		accept a request and allow installation and forwarding of a reservation to
	a previous hop, but, at the same time, may wish to generate a		a previous hop, but, at the same time, may wish to generate a
	warning/error message to a downstream node (NHOP) to warn about conditions		warning/error message to a downstream node (NHOP) to warn about conditions
	such as "your request may have to be torn down in 10 mins, etc." Basi-		such as "your request may have to be torn down in 10 mins, etc."
	cally, an ability to create policy-related errors and/or warnings and to		Basically, an ability to create policy-related errors and/or warnings and
	propagate them using the native QoS signaling protocol (such as RSVP) is		to propagate them using the native QoS signaling protocol (such as RSVP)
	needed. Such a policy error returned by the PDP must be able to also		is 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 March 1999		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
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 22 ¶
	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
	All the details of RSVP message processing and associated interactions		All the details of RSVP message processing and associated interactions
	between different elements at an RSVP router (PEP, LPDP) and PDP are		between different elements at an RSVP router (PEP, LPDP) and PDP are
	included in separate documents [3,8]. In the following, a few, salient		included in separate documents [3,8]. In the following, a few, salient
	points related to the framework are listed:		points related to the framework are listed:
	* LPDP is optional and may be used for making decisions based on pol-		* LPDP is optional and may be used for making decisions based on
	icy elements handled locally. The LPDP, in turn, may have to go to		policy elements handled locally. The LPDP, in turn, may have to go
	external entities (such as a directory server or an authentication		to external entities (such as a directory server or an
	server, etc.) for making its decisions.		authentication server, etc.) for making its decisions.
	* PDP is stateful and may make decisions even if no policy objects		* PDP is stateful and may make decisions even if no policy objects
	are received (e.g., make decisions based on information such as		are received (e.g., make decisions based on information such as
	flowspecs and session object in the RSVP messages). The PDP may		flowspecs and session object in the RSVP messages). The PDP may
	consult other PDPs, but discussion of inter-PDP communication and		consult other PDPs, but discussion of inter-PDP communication and
	coordination is outside the scope of this document.		coordination is outside the scope of this document.
	* PDP sends asynchronous notifications to PEP whenever necessary to		* PDP sends asynchronous notifications to PEP whenever necessary to
	change earlier decisions, generate errors etc.		change earlier decisions, generate errors etc.
	* PDP exports the information useful for usage monitoring and		* PDP exports the information useful for usage monitoring and
	accounting purposes. An example of a useful mechanism for this pur-		accounting purposes. An example of a useful mechanism for this
	pose is a MIB or a relational database. However, this document does		purpose is a MIB or a relational database. However, this document
	not specify any particular mechanism for this purpose and discus-		does not specify any particular mechanism for this purpose and
	sion of such mechanisms is out of the scope of this document.		discussion 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
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
	By allowing division of labor between an LPDP and a PDP, the policy con-		By allowing division of labor between an LPDP and a PDP, the policy
	trol architecture allows staged deployment by enabling routers of varying		control architecture allows staged deployment by enabling routers of
	degrees of sophistication, as far as policy control is concerned, to com-		varying degrees of sophistication, as far as policy control is concerned,
	municate with policy servers. Figure 4 depicts an example set of nodes		to communicate with policy servers. Figure 4 depicts an example set of
	belonging to three different administrative domains (AD) (Each AD could		nodes belonging to three different administrative domains (AD) (Each AD
	correspond to a different service provider in this case). Nodes A, B and		could correspond to a different service provider in this case). Nodes A,
	C belong to administrative domain AD-1, advised by PDP PS-1, while D and E		B and C belong to administrative domain AD-1, advised by PDP PS-1, while D
	belong to AD-2 and AD-3, respectively. E communicates with PDP PS-3. In		and E belong to AD-2 and AD-3, respectively. E communicates with PDP PS-3.
	general, it is expected that there will be at least one PDP per adminis-		In general, it is expected that there will be at least one PDP per
	trative domain.		administrative domain.
	Policy capable network nodes could range from very unsophisticated, such		Policy capable network nodes could range from very unsophisticated, such
	as E, which have no LPDP, and thus have to rely on an external PDP for		as E, which have no LPDP, and thus have to rely on an external PDP for
	every policy processing operation, to self-sufficient, such as D, which		every policy processing operation, to self-sufficient, such as D, which
	essentially encompasses both an LPDP and a PDP locally, at the router.		essentially encompasses both an LPDP and a PDP locally, 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
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 16 ¶
	control framework. In some cases, possible approach(es) for achieving the		control framework. In some cases, possible approach(es) for achieving the
	desired goals are also outlined with a list of open issues to be resolved.		desired goals are also outlined with a list of open issues to be resolved.
	5.1. Admission control policies based on factors such as Time-of-Day, User		5.1. Admission control policies based on factors such as Time-of-Day, User
	Identity, or credentials		Identity, or credentials
	Policy control must be able to express and enforce rules with temporal		Policy control must be able to express and enforce rules with temporal
	dependencies. For example, a group of users might be allowed to make		dependencies. For example, a group of users might be allowed to make
	reservations at certain levels only during off-peak hours. In addition,		reservations at certain levels only during off-peak hours. In addition,
	the policy control must also support policies that take into account iden-		the policy control must also support policies that take into account
	tity or credentials of users requesting a particular service or resource.		identity or credentials of users requesting a particular service or
	For example, an RSVP reservation request may be denied or accepted based		resource. For example, an RSVP reservation request may be denied or
	on the credentials or identity supplied in the request.		accepted based on the credentials or identity supplied in the request.
	5.2. Bilateral agreements between service providers		5.2. Bilateral agreements between service providers
	Until recently, usage agreements between service providers for traffic		Until recently, usage agreements between service providers for traffic
	crossing their boundaries have been quite simple. For example, two ISPs		crossing their boundaries have been quite simple. For example, two ISPs
	might agree to accept all traffic from each other, often without perform-		might agree to accept all traffic from each other, often without
	ing any accounting or billing for the ``foreign'' traffic carried. How-		performing any accounting or billing for the ``foreign'' traffic carried.
	ever, with the availability of QoS mechanisms based on Integrated and Dif-		However, with the availability of QoS mechanisms based on Integrated and
	ferentiated Services, traffic differentiation and quality of service		Differentiated Services, traffic differentiation and quality of service
	guarantees are being phased into the Internet. As ISPs start to sell their		guarantees are being phased into the Internet. As ISPs start to sell their
	customers different grades of service and can differentiate among dif-		customers different grades of service and can differentiate among
	ferent sources of traffic, they will also seek mechanisms for charging		different sources of traffic, they will also seek mechanisms for charging
	each other for traffic (and reservations) transiting their networks. One		each other for traffic (and reservations) transiting their networks. One
	additional incentive in establishing such mechanisms is the potential		additional incentive in establishing such mechanisms is the potential
	asymmetry in terms of the customer base that different providers will		asymmetry in terms of the customer base that different providers will
	exhibit: ISPs focused on servicing corporate traffic are likely to experi-		exhibit: ISPs focused on servicing corporate traffic are likely to
	ence much higher demand for reserved services than those that service the		experience much higher demand for reserved services than those that
	consumer market. Lack of sophisticated accounting schemes for inter-ISP		service the consumer market. Lack of sophisticated accounting schemes for
	traffic could lead to inefficient allocation of costs among different ser-		inter-ISP traffic could lead to inefficient allocation of costs among
	vice providers.		different service providers.
	Bilateral agreements could fall into two broad categories; local or glo-		Bilateral agreements could fall into two broad categories; local or
	bal. Due to the complexity of the problem, it is expected that initially		global. Due to the complexity of the problem, it is expected that
	only the former will be deployed. In these, providers which manage a net-		initially only the former will be deployed. In these, providers which
	work cloud or administrative domain contract with their closest point of		manage a network cloud or administrative domain contract with their
	contact (neighbor) to establish ground rules and arrangements for access		closest point of contact (neighbor) to establish ground rules and
	control and accounting. These contracts are mostly local and do not rely		arrangements for access control and accounting. These contracts are mostly
	on global agreements; consequently, a policy node maintains information		local and do not rely on global agreements; consequently, a policy node
	about its neighboring nodes only. Referring to Figure 4, this model		maintains information about its neighboring nodes only. Referring to
	implies that provider AD-1 has established arrangements with AD-2, but not		Figure 4, this model implies that provider AD-1 has established
	with AD-3, for usage of each other's network. Provider AD-2, in turn, has		arrangements with AD-2, but not with AD-3, for usage of each other's
	in place agreements with AD-3 and so on. Thus, when forwarding a reserva-		network. Provider AD-2, in turn, has in place agreements with AD-3 and so
	tion request to AD-2, provider AD-2 will charge AD-1 for use of all		on. Thus, when forwarding a reservation request to AD-2, provider AD-2
	resources beyond AD-1's network. This information is obtained by		will charge AD-1 for use of all resources beyond AD-1's network. This
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
	recursively applying the bilateral agreements at every boundary between		information is obtained by recursively applying the bilateral agreements
	(neighboring) providers, until the recipient of the reservation request is		at every boundary between (neighboring) providers, until the recipient of
	reached. To implement this scheme under the policy control architecture,		the reservation request is reached. To implement this scheme under the
	boundary nodes have to add an appropriate policy object to the RSVP mes-		policy control architecture, boundary nodes have to add an appropriate
	sage before forwarding it to a neighboring provider's network. This policy		policy object to the RSVP message before forwarding it to a neighboring
	object will contain information such as the identity of the provider that		provider's network. This policy object will contain information such as
	generated them and the equivalent of an account number where charges can		the identity of the provider that generated them and the equivalent of an
	be accumulated. Since agreements only hold among neighboring nodes, policy		account number where charges can be accumulated. Since agreements only
	objects have to be rewritten as RSVP messages cross the boundaries of		hold among neighboring nodes, policy objects have to be rewritten as RSVP
	administrative domains or provider's networks.		messages cross the boundaries of administrative domains or provider's
			networks.
	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 the		In many settings, it is useful to distinguish between reservations on the
	basis of some level of "importance". For example, this can be useful to		basis of some level of "importance". For example, this can be useful to
	avoid that the first reservation being granted the use of some resources,		avoid that the first reservation being granted the use of some resources,
	be able to hog those resources for some indefinite period of time. Simi-		be able to hog those resources for some indefinite period of time.
	larly, this may be useful to allow emergency calls to go through even dur-		Similarly, this may be useful to allow emergency calls to go through even
	ing periods of congestion. Such functionality can be supported by associ-		during periods of congestion. Such functionality can be supported by
	ating priorities with reservation requests, and conveying this priority		associating priorities with reservation requests, and conveying this
	information together with other policy information.		priority information together with other policy information.
	In its basic form, the priority associated with a reservation directly		In its basic form, the priority associated with a reservation directly
	determines a reservation's rights to the resources it requests. For exam-		determines a reservation's rights to the resources it requests. For
	ple, assuming that priorities are expressed through integers in the range		example, assuming that priorities are expressed through integers in the
	0 to 32 with 32 being the highest priority, a reservation of priority,		range 0 to 32 with 32 being the highest priority, a reservation of
	say, 10, will always be accepted, if the amount of resources held by lower		priority, say, 10, will always be accepted, if the amount of resources
	priority reservations is sufficient to satisfy its requirements. In other		held by lower priority reservations is sufficient to satisfy its
	words, in case there are not enough free resources (bandwidth, buffers,		requirements. In other words, in case there are not enough free resources
	etc.) at a node to accommodate the priority 10 request, the node will		(bandwidth, buffers, etc.) at a node to accommodate the priority 10
	attempt to free up the necessary resources by preempting existing lower		request, the node will attempt to free up the necessary resources by
	priority reservations.		preempting existing lower priority reservations.
	There are a number of requirements associated with the support of priority		There are a number of requirements associated with the support of priority
	and their proper operation. First, traffic control in the router needs to		and their proper operation. First, traffic control in the router needs to
	be aware of priorities, i.e., classify existing reservations according to		be aware of priorities, i.e., classify existing reservations according to
	their priority, so that it is capable of determining how many and which		their priority, so that it is capable of determining how many and which
	ones to preempt, when required to accommodate a higher priority reserva-		ones to preempt, when required to accommodate a higher priority
	tion request. Second, it is important that preemption be made con-		reservation request. Second, it is important that preemption be made
	sistently at different nodes, in order to avoid transient instabilities.		consistently at different nodes, in order to avoid transient
	Third and possibly most important, merging of priorities needs to be care-		instabilities. Third and possibly most important, merging of priorities
	fully architected and its impact clearly understood as part of the associ-		needs to be carefully architected and its impact clearly understood as
	ated policy definition.		part of the associated policy definition.
	Of the three above requirements, merging of priority information is the		Of the three above requirements, merging of priority information is the
	more complex and deserves additional discussions. The complexity of merg-		more complex and deserves additional discussions. The complexity of
	ing priority information arises from the fact that this merging is to be		merging priority information arises from the fact that this merging is to
	performed in addition to the merging of reservation information. When
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
	reservation (FLOWSPEC) information is identical, i.e., homogeneous reser-		be performed in addition to the merging of reservation information. When
	vations, merging only needs to consider priority information, and the sim-		reservation (FLOWSPEC) information is identical, i.e., homogeneous
	ple rule of keeping the highest priority provides an adequate answer.		reservations, merging only needs to consider priority information, and the
			simple rule of keeping the highest priority provides an adequate answer.
	However, in the case of heterogeneous reservations, the * two-dimensional		However, in the case of heterogeneous reservations, the * two-dimensional
	nature} of the (FLOWSPEC, priority) pair makes their ordering, and there-		nature} of the (FLOWSPEC, priority) pair makes their ordering, and
	fore merging, difficult. A description of the handling of different cases		therefore merging, difficult. A description of the handling of different
	of RSVP priority objects is presented in [7].		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 the		A model of increasing popularity in the telephone network is that of the
	pre-paid calling card. This concept could also be applied to the Internet;		pre-paid calling card. This concept could also be applied to the Internet;
	users purchase ``tokens'' which can be redeemed at a later time for access		users purchase ``tokens'' which can be redeemed at a later time for access
	to network services. When a user makes a reservation request through, say,		to network services. When a user makes a reservation request through, say,
	an RSVP RESV message, the user supplies a unique identification number of		an RSVP RESV message, the user supplies a unique identification number of
	the ``token'', embedded in a policy object. Processing of this object at		the ``token'', embedded in a policy object. Processing of this object at
	policy capable routers results in decrementing the value, or number of		policy capable routers results in decrementing the value, or number of
	remaining units of service, of this token.		remaining units of service, of this token.
	Referring to Figure 4, suppose receiver R1 in the administrative domain		Referring to Figure 4, suppose receiver R1 in the administrative domain
	AD3 wants to request a reservation for a service originating in AD1. R1		AD3 wants to request a reservation for a service originating in AD1. R1
	generates a policy data object of type PD(prc, CID), where ``prc'' denotes		generates a policy data object of type PD(prc, CID), where ``prc'' denotes
	pre-paid card and CID is the card identification number. Along with other		pre-paid card and CID is the card identification number. Along with other
	policy objects carried in the RESV message, this object is received by		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		node E, which forwards it to its PEP, PEP_E, which, in turn, contacts PDP
	PS-3. PS-3 either maintains locally, or has remote access to, a database		PS-3. PS-3 either maintains locally, or has remote access to, a database
	of pre-paid card numbers. If the amount of remaining credit in CID is suf-		of pre-paid card numbers. If the amount of remaining credit in CID is
	ficient, the PDP accepts the reservation and the policy object is returned		sufficient, the PDP accepts the reservation and the policy object is
	to PEP_E. Two issues have to be resolved here:		returned to 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?
	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
	ments with both AD-2 and AD-1, it could charge for the cost of the com-		agreements with both AD-2 and AD-1, it could charge for the cost of the
	plete reservation up to sender S1. In this case PS-2 removes the		complete 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.
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
			administrative domains will charge CID for their respective reservations.
	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
	currency control might be needed. The issues related to location, manage-		concurrency control might be needed. The issues related to location,
	ment, coordination of credit card (or similar) databases is outside the		management, coordination of credit card (or similar) databases is outside
	scope of this document.		the scope of this document.
	Another problem in this scenario is determining when the credit is		Another problem in this scenario is determining when the credit is
	exhausted. The PDPs should contact the database periodically to submit a		exhausted. The PDPs should contact the database periodically to submit a
	charge against the CID; if the remaining credit reaches zero, there must		charge against the CID; if the remaining credit reaches zero, there must
	be a mechanism to detect that and to cause revocation or termination of		be a mechanism to detect that and to cause revocation or termination of
	privileges granted based on the credit.		privileges granted based on the credit.
	Regarding the issue of when to initiate charging, ideally that should hap-		Regarding the issue of when to initiate charging, ideally that should
	pen only after the reservation request has succeeded. In the case of local		happen only after the reservation request has succeeded. In the case of
	charges, that could be communicated by the router to the PDP.		local charges, that could be communicated by the router to the PDP.
	5.5. Sender Specified Restrictions on Receiver Reservations		5.5. Sender Specified Restrictions on Receiver Reservations
	The ability of senders to specify restrictions on reservations, based on		The ability of senders to specify restrictions on reservations, based on
	receiver identity, number of receivers or reservation cost might be useful		receiver identity, number of receivers or reservation cost might be useful
	in future network applications. An example could be any application in		in future network applications. An example could be any application in
	which the sender pays for service delivered to receivers. In such a case,		which the sender pays for service delivered to receivers. In such a case,
	the sender might be willing to assume the cost of a reservation, as long		the sender might be willing to assume the cost of a reservation, as long
	as it satisfies certain criteria, for example, it originates from a		as it satisfies certain criteria, for example, it originates from a
	receiver who belongs to an access control list (ACL) and satisfies a limit		receiver who belongs to an access control list (ACL) and satisfies a limit
	skipping to change at page 17, line 52 ¶		skipping to change at page 18, line 5 ¶
	precise description of a solution is beyond the scope of this document.		precise description of a solution is beyond the scope of this document.
	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
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
			6.1. PEP to PDP Protocol Requirements
	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
	tates reliable operation. Undetected loss of policy queries or		necessitates 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.
	* Small delays: The timing requirements of policy decisions related to		* Small delays: The timing requirements of policy decisions related to
	QoS signaling protocols are expected to be quite strict. The PEP to		QoS signaling protocols are expected to be quite strict. The PEP to
	PDP protocol should add small amount of delay to the response delay		PDP protocol should add small amount of delay to the response delay
	experienced by queries placed by the PEP to the PDP.		experienced by queries placed by the PEP to the PDP.
	* Ability to carry opaque objects: The protocol should allow for		* Ability to carry opaque objects: The protocol should allow for
	delivery of self-identifying, opaque objects, of variable length,		delivery of self-identifying, opaque objects, of variable length,
	such as RSVP messages, RSVP policy objects and other objects that		such as RSVP messages, RSVP policy objects and other objects that
	might be defined as new policies are introduced. The protocol should		might be defined as new policies are introduced. The protocol should
	not have to be changed every time a new object has to be exchanged.		not have to be changed every time a new object has to be exchanged.
	* Support for PEP-initiated, two-way Transactions: The protocol must		* Support for PEP-initiated, two-way Transactions: The protocol must
	allow for two-way transactions (request-response exchanges) between a		allow for two-way transactions (request-response exchanges) between a
	PEP and a PDP. In particular, PEPs must be able to initiate requests		PEP and a PDP. In particular, PEPs must be able to initiate requests
	for policy decision, re-negotiation of previously made policy deci-		for policy decision, re-negotiation of previously made policy
	sion, and exchange of policy information. To some extent, this		decision, 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.
	* 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.
	wise, the client has to inform the server of a reservation rejection		Likewise, the client has to inform the server of a reservation
	which is due to admission control failure.
	A Framework for Policy-based Admission Control March 1999		A Framework for Policy-based Admission Control March 1999
	* Handling of multicast groups: The protocol should provision for han-		rejection which is due to admission control failure.
	dling of policy decisions related to multicast groups.
	* QoS Specification: The protocol should allow for precise specifica-		* Handling of multicast groups: The protocol should provision for
	tion of level of service requirements in the PEP requests forwarded		handling of policy decisions related to multicast groups.
	to the PDP.
			* QoS Specification: The protocol should allow for precise
			specification of level of service requirements in the PEP requests
			forwarded to the PDP.
	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
	lating Security Payload) protocols, in order to provide confidentiality,		(Encapsulating Security Payload) protocols, in order to provide
	data origin authentication, integrity and replay prevention.		confidentiality, 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
	tication can be used to secure communications between network elements.		authentication can be used to secure communications between network
			elements.
	8. References		8. References
	[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
	Vation Protocol (RSVP) -- Version 1 Functional Specification ", RFC 2205,		ReSerVation Protocol (RSVP) -- Version 1 Functional Specification ", RFC
	September 1997.		2205, 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.
	[4] R. Atkinson. Security Architecture for the Internet Protocol. RFC1825,		[4] R. Atkinson. Security Architecture for the Internet Protocol. RFC1825,
	Aug. 1995.		Aug. 1995.
	[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
	vices in Networks, draft-rajan-policy-qosschema-00.txt, October 1998.		Services in Networks, draft-rajan-policy-qosschema-00.txt, October 1998.
			A Framework for Policy-based Admission Control March 1999
	[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
End of changes. 79 change blocks.
	284 lines changed or deleted		288 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/