draft-ietf-pce-policy-enabled-path-comp-00.txt		draft-ietf-pce-policy-enabled-path-comp-01.txt
	Internet Draft Igor Bryskin (Movaz Networks)		Internet Draft Igor Bryskin (Adva Optical)
	Category: Informational Dimitri Papadimitriou (Alcatel)		Category: Informational Dimitri Papadimitriou (Alcatel)
	Expiration Date: January 2007 Lou Berger (LabN Consulting, LLC)		Expiration Date: September 2, 2007 Lou Berger (LabN Consulting)
			Jerry Ash (AT&T)
			March 2, 2007
	Policy-Enabled Path Computation Framework		Policy-Enabled Path Computation Framework
	draft-ietf-pce-policy-enabled-path-comp-00.txt		draft-ietf-pce-policy-enabled-path-comp-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 32		skipping to change at page 1, line 36
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
			This Internet-Draft will expire on September 2, 2007.
			Copyright Notice
			Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The PCE architecture [PCE-ARCH] introduces the concept of policy in		The PCE architecture [RFC4655] introduces the concept of policy in
	the context of path computation. This document provides additional		the context of path computation. This document provides additional
	details on policy within the PCE Architecture and also provides		details on policy within the PCE Architecture and also provides
	context for the support of PCE Policy. This document introduces the		context for the support of PCE Policy. This document introduces the
	use of the Policy Core Information Model (PCIM) as a framework for		use of the Policy Core Information Model (PCIM) as a framework for
	supporting path computation policy. This document also provides		supporting path computation policy. This document also provides
	representative scenarios for the support of PCE Policy.		representative scenarios for the support of PCE Policy.
	Contents		Contents
	1 Terminology ............................................... 3		1 Terminology ............................................... 3
	2 Introduction .............................................. 3		2 Introduction .............................................. 3
	3 Background ................................................ 4		3 Background ................................................ 4
	3.1 Motivations ............................................... 4		3.1 Motivations ............................................... 4
	3.2 Representative Policy Scenarios ........................... 6		3.2 Representative Policy Scenarios ........................... 6
	3.2.1 Scenario: Policy Configured Paths ......................... 6		3.2.1 Scenario: Policy Configured Paths ......................... 6
	3.2.2 Scenario: Provider Selection Policy ....................... 7		3.2.2 Scenario: Provider Selection Policy ....................... 9
	3.2.3 Scenario: Policy Based Constraints ........................ 8		3.2.3 Scenario: Policy Based Constraints ........................ 10
	4 Requirements .............................................. 10		3.2.4 Scenario: Advanced Load Balancing (ALB) Example .......... 11
	5 Path Computation Policy Information Model (PCPIM) ......... 11		4 Requirements .............................................. 13
	6 Policy-Enabled Path Computation Framework Components ...... 13		5 Path Computation Policy Information Model (PCPIM) ......... 15
	7 Policy Component Configurations ........................... 15		6 Policy-Enabled Path Computation Framework Components ...... 16
	7.1 PCC-PCE Configurations .................................... 15		7 Policy Component Configurations ........................... 18
	7.2 Policy Repositories ....................................... 17		7.1 PCC-PCE Configurations .................................... 18
	7.3 Cooperating PCE Configurations ............................ 18		7.2 Policy Repositories ....................................... 20
	7.4 Policy Configuration Management ........................... 20		7.3 Cooperating PCE Configurations ............................ 21
	8 Inter-Component Communication ............................. 20		7.4 Policy Configuration Management ........................... 23
	8.1 Policy Communication ..................................... 20		8 Inter-Component Communication ............................. 23
	8.2 PCE Discovery Policy Considerations ....................... 22		8.1 Policy Communication ..................................... 23
	9 Path Computation Sequence of Events ....................... 22		8.2 PCE Discovery Policy Considerations ....................... 25
	9.1 Policy-enabled PCC, Policy-enabled PCE .................... 23		9 Path Computation Sequence of Events ....................... 25
	9.2 Policy-ignorant PCC, Policy-enabled PCE ................... 24		9.1 Policy-enabled PCC, Policy-enabled PCE .................... 26
	10 Introduction of New Constraints ........................... 25		9.2 Policy-ignorant PCC, Policy-enabled PCE ................... 27
	11 Security Considerations ................................... 26		10 Introduction of New Constraints ........................... 28
	12 Acknowledgements .......................................... 27		11 Security Considerations ................................... 29
	13 IANA Considerations ....................................... 27		12 Acknowledgements .......................................... 30
	14 References ................................................ 27		13 IANA Considerations ....................................... 30
	14.1 Normative References ...................................... 27		14 References ................................................ 30
	14.2 Informative References .................................... 28		14.1 Normative References ...................................... 30
	15 Authors' Addresses ........................................ 28		14.2 Informative References .................................... 31
	16 Full Copyright Statement .................................. 29		15 Authors' Addresses ........................................ 32
	17 Intellectual Property ..................................... 29		16 Full Copyright Statement .................................. 32
			17 Intellectual Property ..................................... 33
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1. Terminology		1. Terminology
	The reader is assumed to be familiar with the following terms:		The reader is assumed to be familiar with the following terms:
	CSPF: Constraint-based Shortest Path First, see [RFC3630].		CSPF: Constraint-based Shortest Path First, see [RFC3630].
	LSP: Label Switched Path, see [RFC3031].		LSP: Label Switched Path, see [RFC3031].
	LSR: Label Switching Router, see [RFC3031].		LSR: Label Switching Router, see [RFC3031].
	PCC: Path Computation Client, see [PCE-ARCH].		PCC: Path Computation Client, see [RFC4655].
	PCE: Path Computation Element, see [PCE-ARCH].		PCE: Path Computation Element, see [RFC4655].
	TE LSP: Traffic Engineering MPLS Label Switched Path, see		TE LSP: Traffic Engineering MPLS Label Switched Path, see
	[RFC3209] and [RFC3473].		[RFC3209] and [RFC3473].
	CIM: Common Information Model, see [DMTF].		CIM: Common Information Model, see [DMTF].
	PCIM: Policy Core Information Model, see [RFC3060].		PCIM: Policy Core Information Model, see [RFC3060].
	PC: Path Computation.		PC: Path Computation.
	PCCIM: Path Computation Core Information Model.		PCCIM: Path Computation Core Information Model.
	QPIM: QoS Policy Information Model, see [RFC3644].		QPIM: QoS Policy Information Model, see [RFC3644].
	PBM: Policy-based Management, see [RFC3198].		PBM: Policy-based Management, see [RFC3198].
	PEP: Policy Enforcement Points, see [RFC2753].		PEP: Policy Enforcement Points, see [RFC2753].
	PDP: Policy Decision Points, see [RFC2753].		PDP: Policy Decision Points, see [RFC2753].
	COPS: Common Open Policy Service, see [RFC2748].		COPS: Common Open Policy Service, see [RFC2748].
	COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084].		COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084].
	2. Introduction		2. Introduction
	The PCE architecture is introduced in [PCE-ARCH]. This document		The PCE architecture is introduced in [RFC4655]. This document
	describes the impact of policy on the PCE architecture and provides		describes the impact of policy on the PCE architecture and provides
	additional details on, and context for, policy within the PCE		additional details on, and context for, policy within the PCE
	Architecture.		Architecture.
	Policy-based Management (PBM) enables network administrators to		Policy-based Management (PBM) enables network administrators to
	operate in a high-level manner through rule-based policies; the		operate in a high-level manner through rule-based policies; the
	latter are translated automatically into individual device		latter are translated automatically into individual device
	configuration directives, aimed at controlling a network as a whole.		configuration directives, aimed at controlling a network as a whole.
	Two IETF Working Groups have considered policy networking in the		Two IETF Working Groups have considered policy networking in the
	past: The Resource Allocation Protocol working group and the Policy		past: The Resource Allocation Protocol working group and the Policy
	skipping to change at page 4, line 36		skipping to change at page 4, line 36
	This section provides some general background on the use of policy		This section provides some general background on the use of policy
	within the PCE architecture. It presents some rational behind the use		within the PCE architecture. It presents some rational behind the use
	of policy, as well as representative policy usage scenarios. This		of policy, as well as representative policy usage scenarios. This
	information is intended to provide context for the presented policy		information is intended to provide context for the presented policy
	framework. This section does not attempt to present an exhaustive		framework. This section does not attempt to present an exhaustive
	list of rational or scenarios.		list of rational or scenarios.
	3.1. Motivations		3.1. Motivations
	The PCE architecture is introduced in [PCE-ARCH]. It includes policy		The PCE architecture is introduced in [RFC4655]. It includes policy
	as an integral part of the PCE architecture. This section presents		as an integral part of the PCE architecture. This section presents
	some of the rational for this inclusion.		some of the rational for this inclusion.
	Network operators require a certain level of flexibility to shape the		Network operators require a certain level of flexibility to shape the
	TE path computation process, so that the process can be aligned with		TE path computation process, so that the process can be aligned with
	their business and operational needs. Many aspects of the path		their business and operational needs. Many aspects of the path
	computation may be governed by policies. For example, a PCC may use		computation may be governed by policies. For example, a PCC may use
	policies configured by the operator to decide which optimizations,		policies configured by the operator to decide which optimizations,
	constraints, diversities and their relaxation strategies to request		constraints, diversities and their relaxation strategies to request
	while computing path(s) for a particular service. Depending on SLAs,		while computing path(s) for a particular service. Depending on SLAs,
	skipping to change at page 5, line 44		skipping to change at page 5, line 44
	need to be standardized, all PCCs may need to be upgraded with new		need to be standardized, all PCCs may need to be upgraded with new
	software, and new interoperability problems may need to be resolved,		software, and new interoperability problems may need to be resolved,
	etc.		etc.
	Within the context of the PCE architecture, it is therefore highly		Within the context of the PCE architecture, it is therefore highly
	desirable to find a way to introduce new path computation		desirable to find a way to introduce new path computation
	capabilities without requiring modifying either the		capabilities without requiring modifying either the
	discovery/communication protocols or PCC software. One way to achieve		discovery/communication protocols or PCC software. One way to achieve
	this objective is to consider path selection constraints, their		this objective is to consider path selection constraints, their
	relaxations and objective functions, as path computation request		relaxations and objective functions, as path computation request
	specific policies. Furthermore that such policies may, on one hand,		specific policies. Furthermore such policies may, on one hand, be
	be configured and managed by an operator as any other policies or, on		configured and managed by an operator as any other policies or, on
	the other hand, may be interpreted in real time by PCCs and PCEs.		the other hand, may be interpreted in real time by PCCs and PCEs.
	There are a number of advantages and useful by-products of such an		There are a number of advantages and useful by-products of such an
	approach:		approach:
	- New path computation capabilities may be introduced without		- New path computation capabilities may be introduced without
	changing PCE-PCC communication and discovery protocols or PCC		changing PCE-PCC communication and discovery protocols or PCC
	software. Only the PCE module providing the path computation		software. Only the PCE module providing the path computation
	capabilities (referred in this document as path computation		capabilities (referred in this document as path computation
	engine) needs to be updated.		engine) needs to be updated.
	skipping to change at page 7, line 10		skipping to change at page 7, line 10
	alternate approach is possible.		alternate approach is possible.
	In particular, service specific policies can be installed that will		In particular, service specific policies can be installed that will
	provide configured path(s) for a specific service request. The		provide configured path(s) for a specific service request. The
	request may be identified based on service parameters such as end-		request may be identified based on service parameters such as end-
	points, requested QoS or even a token that identifies the end-user.		points, requested QoS or even a token that identifies the end-user.
	The configured path(s) would then be used as input to PCE computation		The configured path(s) would then be used as input to PCE computation
	process, which would return explicit routes by expanding of all		process, which would return explicit routes by expanding of all
	specified loose hops.		specified loose hops.
			----------------------
			| ----- |
			| | TED |<-+------------>
			| ----- | TED synchronization
			| | | mechanism (e.g., routing protocol)
			| | |
			| v |
			| ------ ----- | Inter-PCE Request/Response
			| |Policy|<-->| PCE |<.+...........> (when present)
			| ------ ----- |
			----------------------
			^
			| Request/
			| Response
			v
			Service ------------- Signaling
			Request|[PCC][Policy]| Protocol
			...--->| Node |<----....
			or Signaling -------------
			Protocol
			Figure 1: Policy Enabled PCC and PCE
	The described policies may be applied at either PCC or PCE, see		The described policies may be applied at either PCC or PCE, see
	Figure 5. In the PCC case, the configured path would be processed at		Figure 1. In the PCC case, the configured path would be processed at
	the PCC and then passed to the PCE along with the PCE request,		the PCC and then passed to the PCE along with the PCE request,
	probably in the form of (inclusion) constraints. When applied at the		probably in the form of (inclusion) constraints. When applied at the
	PCE, the configured path would be used locally. Both cases require		PCE, the configured path would be used locally. Both cases require
	some method to configure and manage policies. In the PCC case, the		some method to configure and manage policies. In the PCC case, the
	real benefit would come when there is an automated policy		real benefit would come when there is an automated policy
	distribution mechanism.		distribution mechanism.
			------------------ -------------------
			| | | |
			| PCE | | PCE |
			| | | |
			| ------ ----- | | ----- ------ |
			| |Policy| | TED | | | | TED | |Policy| |
			| ------ ----- | | ----- ------ |
			------------------ -------------------
			^ ^
			| Request/ | Request/
			| Response | Response
			v v
			Service -------- Signaling ------------ Signaling ------------
			Request|Head-End| Protocol |Intermediate| Protocol |Intermediate|
			---->| Node |<--------->| Node |<--------->| Node |
			-------- ------------ ------------
			Figure 2. Multiple PCE Path Computation
			------------------ ------------------
			| | Inter-PCE Request/Response | |
			| PCE |<-------------------------->| PCE |
			| | | |
			| ------ ----- | | ------ ----- |
			| |Policy| | TED | | | |Policy| | TED | |
			| ------ ----- | | ------ ----- |
			------------------ ------------------
			^
			| Request/
			| Response
			v
			Service ---------- Signaling ---------- Signaling ----------
			Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
			---->| Node |<---------->| Node |<---------->| Node |
			---------- ---------- ----------
			Figure 3. Multiple PCE Path Computation with Inter-PCE Communication
	Policy-configured paths may also be used in multiple PCE environments		Policy-configured paths may also be used in multiple PCE environments
	(see Figures 7 and 8). For example, consider the case when there is		(see Figures 2 and 3). For example, consider the case when there is
	limited TE visibility and independent PCEs are used to determine		limited TE visibility and independent PCEs are used to determine
	path(s) within each area of the TE visibility. In such a case, it may		path(s) within each area of the TE visibility. In such a case, it may
	not be possible (or desirable) to configure entire explicit path(s)		not be possible (or desirable) to configure entire explicit path(s)
	on a single PCE. However, it is possible to configure explicit		on a single PCE. However, it is possible to configure explicit
	path(s) for each area of the TE visibility and each responsible PCE.		path(s) for each area of the TE visibility and each responsible PCE.
	One by one, the PCEs would then map an incoming signaling request to		One by one, the PCEs would then map an incoming signaling request to
	appropriate configured path(s). Note that to make such scenario work		appropriate configured path(s). Note that to make such scenario work
	it would likely be necessary to start and finish the configured paths		it would likely be necessary to start and finish the configured paths
	on TE domain boundary nodes. Clearly, consistent PC Policy		on TE domain boundary nodes. Clearly, consistent PC Policy
	Repositories are also critical in this example.		Repositories are also critical in this example.
	skipping to change at page 7, line 42		skipping to change at page 9, line 17
	3.2.2. Scenario: Provider Selection Policy		3.2.2. Scenario: Provider Selection Policy
	A potentially more interesting usage scenario is applying PC policies		A potentially more interesting usage scenario is applying PC policies
	in multi-domain multi-provider networks. There are numerous		in multi-domain multi-provider networks. There are numerous
	interesting policy applications in such networks. A rudimentary		interesting policy applications in such networks. A rudimentary
	example is simple access control, that is, deciding which clients are		example is simple access control, that is, deciding which clients are
	permitted to request inter-domain path computation.		permitted to request inter-domain path computation.
	A more complicated example is applying policy to determine which		A more complicated example is applying policy to determine which
	domain or provider network will be used to support a particular PCE		domain or provider network will be used to support a particular PCE
	request. Consider the topology presented in Figure 1. In this example		request. Consider the topology presented in Figure 4. In this example
	there are multiple transit networks available to provide a path from		there are multiple transit networks available to provide a path from
	a source domain to a destination domain. Furthermore, each transit		a source domain to a destination domain. Furthermore, each transit
	network may have one or more options for reaching a particular		network may have one or more options for reaching a particular
	domain. Each domain will need to select which of the multiple		domain. Each domain will need to select which of the multiple
	available paths will be used to satisfy a particular PCE request.		available paths will be used to satisfy a particular PCE request.
	Clearly, TE reachability, availability and optimality are the basic		Clearly, TE reachability, availability and length are the basic
	criterions for path selection, however, policies can provide an		criterions for path selection, however, policies can provide an
	important added consideration in the decision process. For example,		important added consideration in the decision process. For example,
	transit network A may be more expensive and provide lower delay or		transit network A may be more expensive and provide lower delay or
	loss than transit network C. Likewise, a transit network may wish to		loss than transit network C. Likewise, a transit network may wish to
	treat PCE requests from its own customers differently than requests		treat PCE requests from its own customers differently than requests
	from other providers. In both cases, computation based on traffic		from other providers. In both cases, computation based on traffic
	engineering databases will result in multiple transit networks that		engineering databases will result in multiple transit networks that
	provide reachability, and policies can be used to govern which PCE		provide reachability, and policies can be used to govern which PCE
	requests get better service.		requests get better service.
	skipping to change at page 8, line 24		skipping to change at page 9, line 46
	|Transit Domain A| +----------------+		|Transit Domain A| +----------------+
	+----------------+ |Transit Domain D|		+----------------+ |Transit Domain D|
	+------+ +----------------+ +----------------+ +------+		+------+ +----------------+ +----------------+ +------+
	|Source| |Transit Domain B| +----------------+ |Target|		|Source| |Transit Domain B| +----------------+ |Target|
	|Domain| +----------------+ |Transit Domain E| |Domain|		|Domain| +----------------+ |Transit Domain E| |Domain|
	+------+ +----------------+ +----------------+ +------+		+------+ +----------------+ +----------------+ +------+
	|Transit Domain C| +----------------+		|Transit Domain C| +----------------+
	+----------------+ |Transit Domain F|		+----------------+ |Transit Domain F|
	+----------------+		+----------------+
	Figure 1: Multi-domain network with multiple transit options		Figure 4: Multi-domain network with multiple transit options
	There are multiple options for differentiating which PCE requests use		There are multiple options for differentiating which PCE requests use
	a particular transit domain and get a particular (better or worse)		a particular transit domain and get a particular (better or worse)
	level of service. For example, a PCE in the source domain may use		level of service. For example, a PCE in the source domain may use
	user and request specific policies to determine the level of service		user and request specific policies to determine the level of service
	to provide. A PCE in the source domain may also use domain specific		to provide. A PCE in the source domain may also use domain specific
	policies to choose which transit domains are acceptable. A PCE in a		policies to choose which transit domains are acceptable. A PCE in a
	transit domain may use request specific policies to determine if a		transit domain may use request specific policies to determine if a
	request is from a direct customer or another provider, and then use		request is from a direct customer or another provider, and then use
	domain specific policies to identify how the request should be		domain specific policies to identify how the request should be
	processed.		processed.
	3.2.3. Scenario: Policy Based Constraints		3.2.3. Scenario: Policy Based Constraints
	Another usage scenario is the use of policy to provide new		Another usage scenario is the use of policy to provide new
	constraints in a PCE request. Consider an LSR with a policy enabled		constraints in a PCE request. Consider an LSR with a policy enabled
	PCC, as shown in Figure 3, which receives a service request via		PCC, as shown in Figure 1, which receives a service request via
	signaling, including over a NNI or UNI reference point, or receives a		signaling, including over a NNI or UNI reference point, or receives a
	configuration request over a management interface to establish a		configuration request over a management interface to establish a
	service. In either case the path(s) needed to support the service are		service. In either case the path(s) needed to support the service are
	not explicitly specified in the message/request, and hence path		not explicitly specified in the message/request, and hence path
	computation is needed.		computation is needed.
	In this case, the PCC may apply user or service specific policies to		In this case, the PCC may apply user or service specific policies to
	decide how the path selection process should be constrained, that is,		decide how the path selection process should be constrained, that is,
	which constraints, diversities, optimizations and relaxations should		which constraints, diversities, optimizations and relaxations should
	be applied in order for the service LSP(s) to have a likelihood to be		be applied in order for the service LSP(s) to have a likelihood to be
	skipping to change at page 10, line 5		skipping to change at page 11, line 27
	PCE. It then combines the resulting paths and sends the result back		PCE. It then combines the resulting paths and sends the result back
	to the requesting PCC. The response may indicate policies describing		to the requesting PCC. The response may indicate policies describing
	the resulting paths, their characteristics (summary cost, expected		the resulting paths, their characteristics (summary cost, expected
	end-to-end delay, etc.) as well as additional information related to		end-to-end delay, etc.) as well as additional information related to
	the request, e.g., which of constraints were honored, which were		the request, e.g., which of constraints were honored, which were
	dismissed and which were relaxed and in what way.		dismissed and which were relaxed and in what way.
	The PCC processes the response and instructs the LSR to encode the		The PCC processes the response and instructs the LSR to encode the
	received path(s) into the outgoing signaling message(s).		received path(s) into the outgoing signaling message(s).
			3.2.4. Scenario: Advanced Load Balancing (ALB) Example
			Figure 5 illustrates a problem that stems from the coupling between
			BGP and IGP in the BGP decision process. If a significant portion of
			the traffic destined to the data center (or customer network) enters
			a PCE-enabled network from AS 1 and all IGP links weights are the
			same, then both PE3 and PE4 will prefer to reach the data center
			using the routes advertised by PE2. PE5 will use the router-IDs of
			PE1 and PE2 to break the tie and might therefore also select to use
			the path through PE2 (if the router ID of PE2 is smaller than that of
			PE1). Either way the net result is that the link between PE2 and CE
			will carry most of the traffic while the link between PE1 and CE will
			be mostly idle.
			..............................
			. AS 1 .
			. .
			. +---+ +---+ +----+ .
			....|PE8|...|PE9|...|PE10|....
			+---+ +---+ +----+
			| | |
			+---+ +---+ +---+
			......|PE3|...|PE4|...|PE5|......
			. +---+ +---+ +---+ .
			.............. +---+ \ / ___/ +---+
			. . _|PE2|_____+--+__/ / _|PE6|
			. +--+ / +---+ |P1|_____+--+_______/ +---+
			. Customer |CE|= . +--+ |P2| .
			. Network +--+ \_+---+ \ +--+ .
			. . |PE1|________+--+___/| x===x . PCE used
			.............. +---+ |P3| | |PCE| . by all
			. +--+ | x===x . AS0 nodes
			. AS 0 +---+ .
			..................|PE7|..........
			+---+
			Figure 5: Advanced Load Balancing
			This is a common problem for providers and customers alike. Analysis
			of Netflow records, see [IRSCP], for a large ISP network on a typical
			day has shown that for 71.8% of multi-homed customers there is a
			complete imbalance, where the most loaded link carries all the
			traffic and the least loaded link carries none.
			PCE policies can address this problem by basing the routing decision
			at the ingress routers on the offered load towards the multi-homed
			customer. For example, in Figure 5 PCE policies could be configured
			such that traffic load is monitored (e.g., based on Netflow data) at
			ingress routers PE3 to PE7 towards the data center prefixes served by
			egress routers PE1 and PE2. Using this offered load information, the
			path computations returned by PCE, based on the enabled PCE policies,
			can direct traffic to the appropriate egress router, on a per-ingress
			router basis. For example, the PCE path computation might direct
			traffic from both PE4 and PE5 to egress PE1, thus overriding the
			default IGP based selection. Alternatively, traffic from each
			ingress router to each egress link could be split 50-50.
			This scenario is a good example of how a policy governed PCE can
			account for some information that was not or cannot be advertised as
			TE link/node attributes, and, therefore, cannot be subject for
			explicit path computation constraints. More generally, such
			information can be pretty much anything. For example, traffic demand
			forecasts, flow monitoring feedback, any administrative policies,
			etc. Further examples are described in [IRSCP] of how PCE policies
			might address certain network routing problems, such as selective
			DDoS blackholing, planned maintenance dryout, and VPN gateway
			selection.
	4. Requirements		4. Requirements
	The following requirements must be addressed by mechanisms and		The following requirements must be addressed by mechanisms and
	protocols that enable policy-based control over path computation		protocols that enable policy-based control over path computation
	requests and decisions:		requests and decisions:
	- (G)MPLS path computation-specific		- (G)MPLS path computation-specific
	The mechanisms must meet the policy-based control requirements		The mechanisms must meet the policy-based control requirements
	specific to the problem of path computation using RSVP-TE as the		specific to the problem of path computation using RSVP-TE as the
	signaling protocol on MPLS and GMPLS LSRs.		signaling protocol on MPLS and GMPLS LSRs.
	skipping to change at page 12, line 9		skipping to change at page 15, line 22
	- structural classes representing policy information and control of		- structural classes representing policy information and control of
	policies		policies
	- association classes that indicate how instances of the structural		- association classes that indicate how instances of the structural
	classes are related to each other.		classes are related to each other.
	These classes can be mapped to various concrete implementations, for		These classes can be mapped to various concrete implementations, for
	example, to a directory that uses LDAPv3 as its access protocol.		example, to a directory that uses LDAPv3 as its access protocol.
	Figure 2 shows an abstract from the class inheritance hierarchy for		Figure 6 shows an abstract from the class inheritance hierarchy for
	PCIM.		PCIM.
	ManagedElement (abstract)		ManagedElement (abstract)
	|		|
	+--Policy (abstract)		+--Policy (abstract)
	| |		| |
	| +---PolicySet (abstract)		| +---PolicySet (abstract)
	| | |		| | |
	| | +---PolicyGroup		| | +---PolicyGroup
	| | |		| | |
	skipping to change at page 13, line 7		skipping to change at page 16, line 19
	| | |		| | |
	| | +---PolicyImplicitVariable		| | +---PolicyImplicitVariable
	| | |		| | |
	| | +---(subtree of more specific classes)		| | +---(subtree of more specific classes)
	| |		| |
	| +---PolicyValue (abstract)		| +---PolicyValue (abstract)
	| |		| |
	| +---(subtree of more specific classes)		| +---(subtree of more specific classes)
	|		|
	Figure 2: PCIM Class Inheritance		Figure 6: PCIM Class Inheritance
	The policy classes and associations defined in PCIM are sufficiently		The policy classes and associations defined in PCIM are sufficiently
	generic to allow them to represent policies related to anything.		generic to allow them to represent policies related to anything.
	Policy models for application-specific areas such as the Path		Policy models for application-specific areas such as the Path
	Computation Service may extend the PCIM in several ways. The		Computation Service may extend the PCIM in several ways. The
	preferred way is to use the PolicyGroup, PolicyRule, and		preferred way is to use the PolicyGroup, PolicyRule, and
	PolicyTimePeriodCondition classes directly as a foundation for		PolicyTimePeriodCondition classes directly as a foundation for
	representing and communicating policy information. Then, specific		representing and communicating policy information. Then, specific
	subclasses derived from PolicyCondition and PolicyAction can capture		subclasses derived from PolicyCondition and PolicyAction can capture
	application-specific definitions of conditions and actions of		application-specific definitions of conditions and actions of
	policies. Two subclasses, VendorPolicyCondition and		policies.
	VendorPolicyAction, are also defined to provide a standard extension
	mechanism for vendor-specific extensions to the Policy Core
	Information Model.
	Policy Quality of Service Information Model [RFC3644] further extends		Policy Quality of Service Information Model [RFC3644] further extends
	the PCIM to represent QoS policy information for large-scale policy		the PCIM to represent QoS policy information for large-scale policy
	domains. New classes introduced in this document describing QoS and		domains. New classes introduced in this document describing QoS and
	RSVP related variables, conditions and actions can be used as a		RSVP related variables, conditions and actions can be used as a
	foundation for the PCPIM.		foundation for the PCPIM.
	Detailed description of the PCPIM will be provided in a separate		Detailed description of the PCPIM will be provided in a separate
	documents.		documents.
	skipping to change at page 15, line 16		skipping to change at page 18, line 24
	7. Policy Component Configurations		7. Policy Component Configurations
	7.1. PCC-PCE Configurations		7.1. PCC-PCE Configurations
	The PCE policy architecture supports policy being applied at a PCC		The PCE policy architecture supports policy being applied at a PCC
	and at a PCE. While the architecture supports policy being applied at		and at a PCE. While the architecture supports policy being applied at
	both, there is no requirement for policy to always be applied at		both, there is no requirement for policy to always be applied at
	both, or even at either. The use of policy in a network, on PCCs and		both, or even at either. The use of policy in a network, on PCCs and
	on PCEs, is a specific network design choice. Some networks may		on PCEs, is a specific network design choice. Some networks may
	choose to apply policy only at PCCs (Figure 3), some at PCEs (Figure		choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure
	4), and others at both PCCs and PCEs (Figure 5). Regardless of where		8), and others at both PCCs and PCEs (Figure 9). Regardless of where
	policy is applied it must be applied in a consistent fashion in order		policy is applied it must be applied in a consistent fashion in order
	to achieve the intended results.		to achieve the intended results.
	........................		........................
	. .		. .
	. PC Policy Management .		. PC Policy Management .
	. .		. .
	........................		........................
	.		.
	.		.
	--------- Policy ----------------------		--------- Policy ----------------------
	| PCC-PDP |<--------- | PC Policy Repository |		| PCC-PDP |<--------- | PC Policy Repository |
	--------- ----------------------		--------- ----------------------
	^		^
	| e.g., COPS		| e.g., COPS
	v		v
	--------- ---------		--------- ---------
	| PCC-PEP |<------------------------------------------->| PCE |		| PCC-PEP |<------------------------------------------->| PCE |
	--------- PCC-PCE Communication Protocol ---------		--------- PCC-PCE Communication Protocol ---------
	Figure 3: Policies are applied on PCC only		Figure 7: Policies are applied on PCC only
	Along with supporting flexibility in where policy may be applied, the		Along with supporting flexibility in where policy may be applied, the
	PCE architecture is also flexible in terms of where specific types of		PCE architecture is also flexible in terms of where specific types of
	policies may be applied. Also the PCE architecture allows for the		policies may be applied. Also the PCE architecture allows for the
	application of only a subset of policy types. [PCE-ARCH] defines		application of only a subset of policy types. [RFC4655] defines
	several PC policy types. Each of these may be applied at either a PCC		several PC policy types. Each of these may be applied at either a PCC
	or a PCE or both. Clearly when policy is only applied at PCCs or at		or a PCE or both. Clearly when policy is only applied at PCCs or at
	PCEs, all PC policy types used in the network must be applied at		PCEs, all PC policy types used in the network must be applied at
	those locations.		those locations.
	........................		........................
	. .		. .
	. PC Policy Management .		. PC Policy Management .
	. .		. .
	........................		........................
	skipping to change at page 16, line 22		skipping to change at page 19, line 27
	---------------------- Policy ---------		---------------------- Policy ---------
	| PC Policy Repository | -------->| PCE-PDP |		| PC Policy Repository | -------->| PCE-PDP |
	---------------------- ---------		---------------------- ---------
	^		^
	e.g., COPS |		e.g., COPS |
	v		v
	--------- ---------		--------- ---------
	| PCC |<------------------------------------------->| PCE-PEP |		| PCC |<------------------------------------------->| PCE-PEP |
	--------- PCC-PCE Communication Protocol ---------		--------- PCC-PCE Communication Protocol ---------
	Figure 4: Policies are applied on PCE only		Figure 8: Policies are applied on PCE only
	In the case where policy is only applied at a PCE, it is expected		In the case where policy is only applied at a PCE, it is expected
	that the PCC will pass to the PCE all information about the service		that the PCC will pass to the PCE all information about the service
	that it can gather in the path computation request (most likely in		that it can gather in the path computation request (most likely in
	the form of PCPIM policy variables). The PCE is expected to		the form of PCPIM policy variables). The PCE is expected to
	understand this information and apply appropriate policies while		understand this information and apply appropriate policies while
	defining the actual parameters of the path computation to be		defining the actual parameters of the path computation to be
	performed. Note that in this scenario the PCC cannot apply server-		performed. Note that in this scenario the PCC cannot apply server-
	specific or any other policies, and PCE selection is static.		specific or any other policies, and PCE selection is static.
	skipping to change at page 17, line 33		skipping to change at page 20, line 35
	--------- Policy a ---------------------- Policy b ---------		--------- Policy a ---------------------- Policy b ---------
	| PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP |		| PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP |
	--------- ---------------------- ---------		--------- ---------------------- ---------
	^ ^		^ ^
	| e.g., COPS e.g., COPS |		| e.g., COPS e.g., COPS |
	v v		v v
	--------- ---------		--------- ---------
	| PCC-PEP |<------------------------------------------->| PCE-PEP |		| PCC-PEP |<------------------------------------------->| PCE-PEP |
	--------- PCC-PCE Communication Protocol ---------		--------- PCC-PCE Communication Protocol ---------
	Figure 5: Single PCC/PCE Policy Repository		Figure 9: Single PCC/PCE Policy Repository
	o) Multiple PC Policy Repositories		o) Multiple PC Policy Repositories
	The repositories in this case may be fully or partially synchronized		The repositories in this case may be fully or partially synchronized
	by some discovery/ synchronization management protocol or may be		by some discovery/ synchronization management protocol or may be
	completely independent. Note that the situation when PC Policy		completely independent. Note that the situation when PC Policy
	Repository A exactly matches PC Policy Repository B, results in the		Repository A exactly matches PC Policy Repository B, results in the
	single PC Policy Repository configuration case.		single PC Policy Repository configuration case.
	-------------- --------------		-------------- --------------
	skipping to change at page 18, line 23		skipping to change at page 21, line 23
	--------- ---------		--------- ---------
	| PCC-PDP | | PCE-PDP |		| PCC-PDP | | PCE-PDP |
	--------- ---------		--------- ---------
	^ ^		^ ^
	| e.g., COPS e.g., COPS |		| e.g., COPS e.g., COPS |
	v v		v v
	--------- ---------		--------- ---------
	| PCC-PEP |<------------------------------------------->| PCE-PEP |		| PCC-PEP |<------------------------------------------->| PCE-PEP |
	--------- PCC-PCE Communication Protocol ---------		--------- PCC-PCE Communication Protocol ---------
	Figure 6: Multiple PCE/PCC Policy Repositories		Figure 10: Multiple PCE/PCC Policy Repositories
	7.3. Cooperating PCE Configurations		7.3. Cooperating PCE Configurations
	The previous section shows the relationship between PCCs and PCEs. A		The previous section shows the relationship between PCCs and PCEs. A
	parallel relationship exists between cooperating PCEs, and, in fact,		parallel relationship exists between cooperating PCEs, and, in fact,
	this relationship can be viewed as the same as the relationship		this relationship can be viewed as the same as the relationship
	between PCCs and PCEs. The one notable difference is that there will		between PCCs and PCEs. The one notable difference is that there will
	be cases where having a shared PC Policy Repository will not be		be cases where having a shared PC Policy Repository will not be
	desirable, for example, when the PCEs are managed by different		desirable, for example, when the PCEs are managed by different
	entities. Note that in this case it still remains necessary for the		entities. Note that in this case it still remains necessary for the
	skipping to change at page 19, line 22		skipping to change at page 22, line 22
	--------- Policy a ---------------------- Policy b ---------		--------- Policy a ---------------------- Policy b ---------
	| PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP |		| PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP |
	--------- ---------------------- ---------		--------- ---------------------- ---------
	^ ^		^ ^
	| e.g., COPS e.g., COPS |		| e.g., COPS e.g., COPS |
	v v		v v
	--------- ---------		--------- ---------
	| PCE-PEP |<------------------------------------------->| PCE-PEP |		| PCE-PEP |<------------------------------------------->| PCE-PEP |
	--------- PCE-PCE Communication Protocol ---------		--------- PCE-PCE Communication Protocol ---------
	Figure 7: Single PCC Policy Repository		Figure 11: Single PCC Policy Repository
	o) Multiple Policy Repositories		o) Multiple Policy Repositories
	The repositories in this case may be fully or partially synchronized		The repositories in this case may be fully or partially synchronized
	by some discovery/synchronization management protocol(s) or may be		by some discovery/synchronization management protocol(s) or may be
	completely independent. In the multi-domain case it is expected that		completely independent. In the multi-domain case it is expected that
	the repositories will be distinct, providing, however. consistent		the repositories will be distinct, providing, however. consistent
	policies.		policies.
	-------------- --------------		-------------- --------------
	skipping to change at page 19, line 50		skipping to change at page 22, line 50
	--------- ---------		--------- ---------
	| PCE-PDP | | PCE-PDP |		| PCE-PDP | | PCE-PDP |
	--------- ---------		--------- ---------
	^ ^		^ ^
	| e.g., COPS e.g., COPS |		| e.g., COPS e.g., COPS |
	v v		v v
	--------- ---------		--------- ---------
	| PCE-PEP |<------------------------------------------->| PCE-PEP |		| PCE-PEP |<------------------------------------------->| PCE-PEP |
	--------- PCC-PCE Communication Protocol ---------		--------- PCC-PCE Communication Protocol ---------
	Figure 8: Multiple PCC Policy Repositories		Figure 12: Multiple PCC Policy Repositories
	7.4. Policy Configuration Management		7.4. Policy Configuration Management
	The management of path computation policy information used by PCCs		The management of path computation policy information used by PCCs
	and PCEs is largely out of scope of the described framework. The		and PCEs is largely out of scope of the described framework. The
	framework assumes that such information is installed, removed and		framework assumes that such information is installed, removed and
	otherwise managed using typical policy management techniques. Policy		otherwise managed using typical policy management techniques. Policy
	Repositories may be populated and managed via static configuration,		Repositories may be populated and managed via static configuration,
	standard and proprietary policy management tools, or even dynamically		standard and proprietary policy management tools, or even dynamically
	via policy management/discovery protocols and applications.		via policy management/discovery protocols and applications.
	skipping to change at page 25, line 36		skipping to change at page 28, line 36
	dismissed and which were relaxed and in what way)		dismissed and which were relaxed and in what way)
	- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to		- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to
	encode the received path(s) into the outgoing Setup message(s).		encode the received path(s) into the outgoing Setup message(s).
	10. Introduction of New Constraints		10. Introduction of New Constraints
	An important aspect of the policy-enable path computation framework		An important aspect of the policy-enable path computation framework
	discussed above is the ability to introduce new constraints with		discussed above is the ability to introduce new constraints with
	minimal impact. In particular, only those components and mechanisms		minimal impact. In particular, only those components and mechanisms
	that will use a new constraint need to change in order to support a		that will use a new constraint need to change in order to support the
	new constraints. Importantly, those components and mechanisms that		new constraint. Importantly, those components and mechanisms that
	will not use a new constraint must not require change for a new		will not use the new constraint, must not require any change in order
	constraint to be utilized. For example, the PCE communication		for the new constraint to be utilized. For example, the PCE
	protocols must not require any changes to support a new constraint.		communication protocols must not require any changes to support new
	Likewise, PCC and PCEs that will not process a new constraint must		constraints. Likewise, PCC and PCEs that will not process new
	not require any modification.		constraints must not require any modification.
	Consider the case where a PCE has been upgraded with software		Consider the case where a PCE has been upgraded with software
	supporting optical physical impairment constraint, such as		supporting optical physical impairment constraint, such as
	Polarization Mode Dispersion (PMD), that previously was not supported		Polarization Mode Dispersion (PMD), that previously was not supported
	in the domain. In this case, one or more new policies will be		in the domain. In this case, one or more new policies will be
	installed in the PC Policy Repository (associated with the PCE)		installed in the PC Policy Repository (associated with the PCE)
	defining the constraint (rules that determine application criteria,		defining the constraint (rules that determine application criteria,
	set of policy variables, conditions, actions, etc.) and its		set of policy variables, conditions, actions, etc.) and its
	relaxation strategy(ies). The new policies will be also propagated		relaxation strategy(ies). The new policies will be also propagated
	into other PC Policy Repositories within the domain via discovery and		into other PC Policy Repositories within the domain via discovery and
	skipping to change at page 26, line 24		skipping to change at page 29, line 24
	working in a single PC Policy Repository configuration starts to		working in a single PC Policy Repository configuration starts to
	support a new constraint. Once a corresponding policy installed in		support a new constraint. Once a corresponding policy installed in
	the repository, it automatically becomes available for all repository		the repository, it automatically becomes available for all repository
	users, that is, PCCs. In the multi-repository case some policy		users, that is, PCCs. In the multi-repository case some policy
	synchronization must be provided, however, this problem is one of the		synchronization must be provided, however, this problem is one of the
	management plane which is solved already.		management plane which is solved already.
	11. Security Considerations		11. Security Considerations
	This document adds to the policy security considerations mentioned in		This document adds to the policy security considerations mentioned in
	[PCE-ARCH]. In particular it is now necessary to consider the		[RFC4655]. In particular it is now necessary to consider the security
	security of policy information maintained in PC Policy Repositories		of policy information maintained in PC Policy Repositories and policy
	and policy related transactions. The most notable issues, some of		related transactions. The most notable issues, some of which are also
	which are also listed in [PCE-ARCH], are:		listed in [RFC4655], are:
	- Unauthorized access to the PC Policy Repositories;		- Unauthorized access to the PC Policy Repositories;
	- Interception of policy information when it is retrieved from		- Interception of policy information when it is retrieved from
	the repositories and/or transported from PDPs to PEPs;		the repositories and/or transported from PDPs to PEPs;
	- Interception of policy related information in path computation		- Interception of policy related information in path computation
	requests and responses;		requests and responses;
	o Impersonation of user and client identities;		o Impersonation of user and client identities;
	o Falsification of policy information and/or PCE capabilities;		o Falsification of policy information and/or PCE capabilities;
	o Denial of service attacks on policy related communication		o Denial of service attacks on policy related communication
	mechanisms.		mechanisms.
	As with [PCE-ARCH], it is expected that PCE solutions will address		As with [RFC4655], it is expected that PCE solutions will address
	these issues in detail.		these issues in detail.
	12. Acknowledgements		12. Acknowledgements
	We would like to thank Bela Berde for fruitful discussions on PBM		We would like to thank Bela Berde for fruitful discussions on PBM and
	and Policy-driven path computation.		Policy-driven path computation. We would also like to thank Kobus Van
			der Merwe for providing insights and examples regarding PCE policy
			applications.
	13. IANA Considerations		13. IANA Considerations
	None.		None.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[PCE-ARCH] Farrel, A., Vasseur, JP., Ash, J., "Path Computation
	Element (PCE) Architecture", April 2006.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," BCP 14, RFC 2119, March 1997.		Requirement Levels," BCP 14, RFC 2119, March 1997.
	[RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for		[RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for
	Policy Based Admission Control, RFC 2753, January 2000.		Policy Based Admission Control, RFC 2753, January 2000.
	[RFC2748] D. Durham, et al., The COPS (Common Open Policy Service)		[RFC2748] D. Durham, et al., The COPS (Common Open Policy Service)
	protocol, RFC 2748, IETF, January 2000.		protocol, RFC 2748, IETF, January 2000.
	[RFC3060] B. Moore, et al., Policy Information Model Version1		[RFC3060] B. Moore, et al., Policy Core Information Model --
	Specification, RFC 3060, February 2001.		Version 1 Specification, RFC 3060, February 2001.
	[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP		[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM)		[RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM)
	Extensions", RFC 3460, January 2003.		Extensions", RFC 3460, January 2003.
	[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label		[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation		Switching (GMPLS) Signaling Resource ReserVation
	Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC		Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
	3473, January 2003.		3473, January 2003.
	[RFC3644] Y. Snir, et al., Policy Quality of Service (QoS)		[RFC3644] Y. Snir, et al., Policy Quality of Service (QoS)
	Information Model, RFC 3644, November 2003.		Information Model, RFC 3644, November 2003.
	[RFC4216] Zhang, R., Vasseur, J-P., Eds., "MPLS Inter-Autonomous		[RFC4216] Zhang, R., Vasseur, J-P., Eds., "MPLS Inter-Autonomous
	System (AS) Traffic Engineering (TE) Requirements",		System (AS) Traffic Engineering (TE) Requirements",
	RFC4216, November 2005.		RFC4216, November 2005.
			[RFC4655] Farrel, A., Vasseur, JP., Ash, J., "Path Computation
			Element (PCE) Architecture", RFC 4655, August 2006.
	[INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS		[INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS
	Requirements for the Path Computation Element		Requirements for the Path Computation Element
	Communication Protocol (PCECP)", February 2006.		Communication Protocol (PCECP)", February 2006.
	[PCECP-IA-REQ] Le Roux, J-L., Ed., "PCE Communication Protocol		[PCECP-IA-REQ] Le Roux, J-L., Ed., "PCE Communication Protocol
	(PCECP) Specific Requirements for Inter-Area		(PCECP) Specific Requirements for Inter-Area
	(G)MPLS Traffic Engineering", February 2006.		(G)MPLS Traffic Engineering", February 2006.
	14.2. Informative References		14.2. Informative References
	[DMTF] Common Information Model (CIM) Schema, version 2.x.		[DMTF] Common Information Model (CIM) Schema, version 2.x.
	Distributed Management Task Force, Inc. The components		Distributed Management Task Force, Inc. The components
	of the CIM v2.x schema are available via links on the		of the CIM v2.x schema are available via links on the
	following DMTF web page:		following DMTF web page:
	http://www.dmtf.org/standards/standard_cim.php.		http://www.dmtf.org/standards/standard_cim.php.
			[IRSCP] Van der Merwe, J., et. al., "Dynamic Connectivity
			Management with an Intelligent Route Service Control
			Point," ACM SIGCOMM Workshop on Internet Network
			Management (INM), Pisa, Italy, September 11, 2006.
	[RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol		[RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol
	Label Switching Architecture", RFC 3031, January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,		[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
	K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A.		K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A.
	Smith, "COPS Usage for Policy Provisioning (COPS-PR)",		Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
	RFC 3084, February 2001.		RFC 3084, February 2001.
	[RFC3198] Westerinen, A., et al., "Terminology for Policy-Based		[RFC3198] Westerinen, A., et al., "Terminology for Policy-Based
	Management", RFC 3198, November 2001.		Management", RFC 3198, November 2001.
	[RFC3630] Katz, D., Kompella, K., Yeung., D., "Traffic Engineering		[RFC3630] Katz, D., Kompella, K., Yeung., D., "Traffic Engineering
	(TE) Extensions to OSPF Version 2", RFC 3630, September		(TE) Extensions to OSPF Version 2", RFC 3630, September
	2003.		2003.
	15. Authors' Addresses		15. Authors' Addresses
	Igor Bryskin		Igor Bryskin
	Movaz Networks, Inc.		ADVA Optical
	7926 Jones Branch Drive		7926 Jones Branch Drive
	Suite 615		Suite 615
	McLean, VA 22102		McLean, VA 22102
	Email: ibryskin@movaz.com		Email: ibryskin@advaoptical.com
	Dimitri Papadimitriou (Alcatel)		Dimitri Papadimitriou (Alcatel)
	Fr. Wellesplein 1,		Fr. Wellesplein 1,
	B-2018 Antwerpen, Belgium		B-2018 Antwerpen, Belgium
	Phone: +32 3 240-8491		Phone: +32 3 240-8491
	Email: dimitri.papadimitriou@alcatel.be		Email: dimitri.papadimitriou@alcatel.be
	Lou Berger		Lou Berger
	LabN Consulting, LLC		LabN Consulting, LLC
	Phone: +1 301 468 9228		Phone: +1 301 468 9228
	Email: lberger@labn.net		Email: lberger@labn.net
			Jerry Ash
			AT&T
			Room MT D5-2A01
			200 Laurel Avenue
			Middletown, NJ 07748, USA
			Phone: (732)-420-4578
			Fax: (732)-368-8659
			Email: gash@att.com
	16. Full Copyright Statement		16. Full Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject		Copyright (C) The IETF Trust (2007).
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	17. Intellectual Property		17. Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	skipping to change at line 1312		skipping to change at page 33, line 29
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	Generated on: Thu Jun 22 19:34:07 EDT 2006		Acknowledgement
			Funding for the RFC Editor function is provided by the IETF
			Administrative Support Activity (IASA).
			Generated on: Fri Mar 2 08:55:00 EST 2007
End of changes. 45 change blocks.
	85 lines changed or deleted		241 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/