< draft-bitar-zhang-interas-pcecp-reqs-00.txt		draft-bitar-zhang-interas-pcecp-reqs-01.txt >
			Network Working Group Nabil Bitar (Editor)
			Verizon
			Internet Draft Raymond Zhang (Editor)
			BT Infonet
			Kenji Kumaki (Editor)
			KDDI Corporation
	Internet Draft draft-bitar-zhang-interaS-pcecp-reqs-00 February 2006		Expires: December 2006 June 2006
	Network Working Group Nabil Bitar (Editor)
	Verizon
	Internet Draft Raymond Zhang (Editor)
	BT Infonet
	Kenji Kumaki (Editor)
	KDDI Corporation
	Expires: August 2006 February 2006
	Inter-AS Requirements for the Path Computation Element Communication		Inter-AS Requirements for the Path Computation Element Communication
	Protocol (PCECP)		Protocol (PCECP)
	draft-bitar-zhang-interas-pcecp-reqs-00.txt		draft-bitar-zhang-interas-pcecp-reqs-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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	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 in December 2006.
			Copyright Notice
			Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document discusses requirements for the support of the Path		This document discusses requirements for the support of the Path
	Computation Element Communication Protocol (PCECP) in inter-AS		Computation Element Communication Protocol (PCECP) in inter-AS
	applications. Its main objective is to present a set of requirements		applications. Its main objective is to present a set of requirements
	which would result in guidelines for the definition, selection and		which would result in guidelines for the definition, selection and
	specification development for any technical solution(s) meeting these		specification development for any technical solution(s) meeting these
	requirements.		requirements.
	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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this document are to be interpreted as described in RFC-2119.		document are to be interpreted as described in RFC 2119.
	Table of Contents		Table of Contents
	1. Introduction.....................................................2		1. Introduction.....................................................2
	2. Definitions......................................................3		2. Definitions......................................................3
	3. Reference Model..................................................4		3. Reference Model..................................................4
	4. Application Scenarios............................................6		4. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............4
	4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub-regional		4.1.1. PCC/PCE-PCE Communication Protocol Requirements..............4
	Networks............................................................6		4.1.1.1. Requirements on path computation requests..................4
	4.2. Inter-AS Path Computation over a GMPLS Transport Core..........8		4.1.1.2. Requirements on path computation responses.................6
	5. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............8		4.1.2. Scalability and Performance Requirements.....................6
	5.1. Requirements within one SP Administrative Domain...............9		4.1.3. Management, Aliveness Detection and Recovery Requirements....7
	5.1.1. PCC/PCE-PCE Communication Protocol Requirements..............9		4.1.4. Confidentiality..............................................8
	5.1.1.1. Requirements on path computation requests.................10		4.1.5. Policy Controls Effecting inter-AS PCECP.....................8
	5.1.1.2. Requirements on path computation responses................11		4.1.5.1. Inter-AS PCE Peering Policy Controls.......................8
	5.1.2. Scalability and Performance Requirements....................12		4.1.5.2. Inter-AS PCE Reinterpretation Polices......................9
	5.1.3. Complexity and Risks........................................12		5. Security Considerations..........................................9
	5.1.4. Management, Aliveness Detection and Recovery Requirements...12		6. IANA Considerations..............................................9
	5.2. Requirements Across SP Administrative Domains.................13		7. Acknowledgments..................................................9
	5.2.1. Confidentiality.............................................13		8. Authors' Addresses...............................................9
	5.2.2. Policy Controls Effecting inter-AS PCECP....................13		9. Normative References............................................10
	5.2.2.1. Inter-AS PCE Peering Policy Controls......................13		10. Informative References.........................................10
	5.2.2.2. Inter-AS PCE Reinterpretation Polices.....................14
	6. Security Considerations.........................................14
	7. Authors' Addresses..............................................15
	8. Normative References............................................16
	9. Informative References..........................................16
	1.		1.
	Introduction		Introduction
	MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ]		MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ]
	defined the scenarios motivating the deployment of inter-AS MPLS		defined the scenarios motivating the deployment of inter-AS MPLS
	traffic engineering. [INTERAS-TE-REQ] also specified the requirements		traffic engineering. [INTERAS-TE-REQ] also specified the requirements
	for inter-AS MPLS traffic engineering when the ASes are under one		for inter-AS MPLS traffic engineering when the ASes are under one
	Service Provider (SP) administration or the administration of		Service Provider (SP) administration or the administration of
	different SPs.		different SPs.
	Today, there are three signaling options in setting up an inter-AS		Today, there are three signaling options in setting up an inter-AS
	TE LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2)		TE LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2)
	Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE		Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE
	LSP as in[LSP-HIERARCHY]. In addition, [INTERD-TE-PDPC] defines		LSP as in [LSP-HIERARCHY]. In addition, [INTERD-TE-PDPC] defines
	mechanisms for inter-domain path computation using network elements		mechanisms for inter-domain path computation using network elements
	along the signaling and data paths. The mechanisms in [INTERD-TE-		along the signaling and data paths. The mechanisms in [INTERD-TE-
	PDPC] do not provide the capability to guarantee an optimum TE path		PDPC] do not provide the capability to guarantee an optimum TE path
	across multiple ASes. A (G)MPLS-TE optimum path for an LSP is one		across multiple ASes. A (G)MPLS-TE optimum path for an LSP is one
	that has the smallest cost, according to a normalized TE metric		that has the smallest cost, according to a normalized TE metric
	(based upon a TE-metric or IGP metric adopted in each transit AS),		(based upon a TE-metric or IGP metric adopted in each transit AS),
	among all possible paths that satisfy the LSP TE-constraints.		among all possible paths that satisfy the LSP TE-constraints.
	The requirements for a PCE have risen from SP needs to compute a more		The requirements for a PCE have risen from SP needs to compute a more
	optimum path than that can be achieved by mechanisms provided		optimum path than that can be achieved by mechanisms provided in
	in[INTERD-TE-PDPC], and be able to separate the path computation		[INTERD-TE-PDPC], and be able to separate the path computation
	elements from the forwarding elements.		elements from the forwarding elements.
	Generic requirements for the PCE discovery protocol (PCEDP) and		Generic requirements for the PCE discovery protocol (PCEDP) and
	PCC/PCE-PCE communication protocol (PCECP) are discussed in [PCEDP-		PCC/PCE-PCE communication protocol (PCECP) are discussed in [PCEDP-
	REQ] and [PCECP-REQ], respectively. Complementary to these already-		REQ] and [PCECP-REQ], respectively. Complementary to these already-
	defined generic requirements, this document provides a set of PCECP		defined generic requirements, this document provides a set of PCECP
	requirements that are specific to (G)MPLS-TE inter-AS path		requirements that are specific to (G)MPLS-TE inter-AS path
	computation using a PCE-based approach.		computation using a PCE-based approach.
	Section 2 of this document states some definitions. Section 3 defines		Section 2 of this document states some definitions. Section 3 defines
	a reference model, while section 4 describes use cases of inter-AS		a reference model. Section 4 states inter-AS PCECP requirements.
	path computation using a PCE-based approach. Section 5 states inter-		Section 5 discusses security issues.
	AS PCECP requirements when the ASes are under a single SP
	administrative domain. Section 5 also discusses additional
	requirements for inter-AS multi-SP PCE applications related to
	confidentiality and policies. Section 6 discusses security issues.
	2.		2.
	Definitions		Definitions
	The following provides a list of abbreviations or acronyms		This document adopts the definitions and acronyms defined in
	specifically pertaining to this document:		[INTERAS-TE-REQ] Section 3.1 and [PCE-ARCH] Section 2. In addition,
			we use the following terminology:
	SP: Service Providers including regional or global providers
	SP Administrative Domain: a single SP administration over a
	network or networks that may consist of one AS or multiple ASes.
	IP/MPLS networks: SP's networks where MPLS switching capabilities and
	signaling controls are activated in addition to IP routing protocols.
	Intra-AS TE: A generic definition for traffic engineering mechanisms
	operating over IP-only and/or IP/(G)MPLS network within an AS.
	Inter-AS TE: A generic definition for traffic engineering mechanisms
	operating over IP-only and/or IP/(G)MPLS network across one or
	multiple ASes. Since this document only addresses IP/(G)MPLS
	networks, any reference to Inter-AS TE in this document refers only
	to IP/(G)MPLS networks and is not intended to address IP-only TE
	requirements.
	TE LSP: MPLS Traffic Engineering Label Switched Path.
	Intra-AS MPLS-TE: An MPLS Traffic Engineering mechanism where its
	Label Switched Paths (LSP), Head-end Label Switching Routers (LSRs),
	and Tail-end LSRs reside in the same AS for traffic engineering
	purposes.
	Inter-AS MPLS-TE: An MPLS-Traffic Engineering mechanism where
	its TE LSPs, Head-end LSRs and Tail-end LSRs do not reside within the
	same AS
	ASBR Routers: Border routers used to connect one AS to another AS of
	a different or the same SP via one or more links between the ASes.
	Inter-AS TE Path: A TE path traversing multiple ASes and ASBRs, e.g.
	AS1-ASBR1-inter-AS link(s)-ASBR2-AS2-ASBRn-ASn.
	Inter-AS TE Path Segment: A portion of the Inter-AS TE path.
	Inter-AS DS-TE: Diffserv-aware Inter-AS TE.
	SRLG: A set of links may constitute a 'shared risk link group'		PCECP: PCE Communication Protocol
	(SRLG) if they share a resource whose failure may affect all
	links in the set as defined in [GMPLS-ROUT].
	PCE: Path computation element		PCEDP: PCE Discovery Protocol
	PCC: Path computation client		Inter-AS (G)MPLS-TE path: A (G)MPLS-TE path that traverses two or
			more ASes
	PCECP: PCE communication protocol		Intra-AS (G)MPLS-TE path: A (G)MPLS-TE path that is confined to a
			single AS. It may traverse on or more IGP areas.
	PCEDP: PCE Discovery Protocol		Inter-area PCE: A PCE responsible for computing (G)MPLS-TE paths or
			path segments traversing across multi-IGP areas.
	Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths		Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths
	traversing a single AS.		traversing a single AS.
	Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS-TE		Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS-
	and/or intra-AS(G)MPLS-TE paths, by possibly cooperating with intra-		TE paths or path segments, by possibly cooperating with intra-AS
	AS PCEs and other inter-AS PCEs, across one or more AS(es).		PCEs, across one or more ASes.
	3.		3.
	Reference Model		Reference Model
	Figure 1 depicts the reference model for PCEs in an inter-AS		Figure 1 depicts the reference model for PCEs in an inter-AS
	application. In this document, we define two types of PCE functions:		application. We refer to two types of PCE functions in this document:
	inter-AS PCEs and intra-AS PCEs. Figure 1 shows the case where there		inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the procedures
	are three ASes, each having an inter-AS PCE. Each inter-AS PCE		needed for inter-AS (G)MPLS-TE path computation while intra-AS PCEs
	communicates with inter-AS PCEs of neighboring ASes to compute inter-		perform the functions needed for intra-AS (G)MPLS-TE path
	AS (G)MPLS-TE paths. An inter-AS PCE may also communicate with intra-		computation. This document focuses on the PCE Communication Protocol
	AS PCEs within the scope of its AS to compute a path segment within		requirements used by inter-AS PCEs to communicate path
	its AS. An inter-AS PCE can be an external server that is not part of		requests/responses to other inter-AS PCEs and by intra-AS PCEs to
	the routing topology or an LSR (e.g., ASBR),known as composite PCE,		communicate path requests/responses to inter-AS PCEs and vice versa.
	as described in [PCE-ARCH]).
	Inter-AS Inter-AS Inter AS		Inter-AS Inter-AS Inter AS
	PCE1<---------->PCE2<--------------> PCE3		PCE1<---------->PCE2<--------------> PCE3
	:: :: ::		:: :: ::
	R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7		R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
	| | | | | |		| | | | | |
	| | | | | |		| | | | | |
	R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8		R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
	::		::
	Intra-AS		Intra-AS
	PCE		PCE
	<==AS1=> <====AS2======> <=====AS3===>		<==AS1=> <====AS2======> <=====AS3===>
	Figure 1: Inter and Intra-AS PCE Reference Model		Figure 1 Inter and Intra-AS PCE Reference Model
	In general, an inter-AS PCE is associated with one ore more ASes that
	Defines its scope. It receives path computation requests for (G)MPLS-
	TE LSPs from PCCs or other inter-AS PCEs and responds to these
	requests. An intra-AS PCE (e.g., inter-area PCE) is one responsible
	for path computation within a single AS. It should be emphasized that
	the differentiation between these two PCE types is functional as both
	can be implemented and enabled on the same physical device, but
	scalability requirements and/or security considerations may require
	their separation. An inter-AS PCE can be an intermediate-PCE or a
	terminating-PCE for a given LSP. An intermediate-PCE is associated
	with transit ASes whereas a terminating-PCE is associated with the AS
	originating or terminating the path computation request. If the head-
	end and tail-end of an LSP are in ASes within the scope of a single
	inter-AS PCE, the full path computation can be solely done by that
	inter-AS PCE, possibly cooperating with other intra-AS PCEs if it
	does not have the full topological and TE knowledge of the ASes
	within its scope. Otherwise, multiple inter-AS PCEs need to cooperate
	to compute the LSP path as described in [PCE-ARCH].
	The LSR at the head-end of an LSP or a proxy on its behalf (either
	being a PCC) sends a path computation request to one of its inter-
	AS PCEs upon determining, via configuration or dynamic routing, that
	the tail-end is an AS-external destination. There could be one or
	more inter-AS PCEs associated with a given LSR AS. The selection of
	an inter-AS PCE among many can be based on the corresponding
	destination AS, configuration, and/or load-balancing criteria. An
	inter-AS PCE in the originating AS sends a path computation request
	to one or more neighboring AS-PCEs based on the AS(es) through which
	it learned reachability (maybe the best path ) to the destination
	tail-end and/or based on policy. Each neighboring inter-AS PCE that
	receives the request determines its "downstream" neighbor inter-AS
	PCE that it progresses the path request to. In determining the
	"downstream" inter-AS PCE to which the path request must be sent, an
	inter-AS PCE may first qualify the path to an ASBR associated with
	that inter-AS PCE and may exclude paths that do not satisfy the
	constraints of the LSP (e.g., by excluding ASBRs and inter-AS links
	between the two neighboring ASes when there is not sufficient
	bandwidth on the paths to these ASBRs or ASes to sastisfy the LSP
	bandwidth constraints). Before an inter-AS PCE decides to send a path
	computation request to a neighbor inter-AS PCE, it may also qualify
	the paths to the neighbor AS by consulting its intra-AS PCE(s). When
	setting up a bi-directional LSP using GMPLS signaling, a PCE may
	qualify the path in both directions according to the LSP constraints.
	In an all-PCE enabled environment, the last inter-AS PCE, serving the
	AS of the LSP tail-end computes one or more path in the AS(es) within
	its scope by cooperating with intra-AS PCEs. If the immediate
	requestor (e.g., the previous inter-AS PCE) is under another SP
	administrative domain, the inter-AS PCE may not return a path with
	strict hops. What could be returned in the path computation response
	can be generally controlled by policy configuration. The inter-AS PCE
	may return one or more paths, each of which is composed of a list of
	one or more ASBRs and/or ASes as loose hops and a cost associated
	with each path. The returned path(s) must at least include ASBRs
	connected to the ASes affiliated with the responding PCE. This
	process proceeds recursively until the inter-AS PCE serving the LSP
	head-end receives a response to its request(s) from the immediate
	inter-AS PCE(s) it sent requests to. Every time an inter-AS PCE
	responds to a requestor it concatenates each path it computes with a
	path it received from the next immediate PCE, composes a cost for the
	total path and returns the concatenated path(s) to the previous
	immediate requestor. It should be noted that the path(s) computed by
	a PCE will be constrained by the path(s) received from the next
	inter-AS PCE(s) and any other constraints in the received request.
	If the original PCC (LSR at the head-end of the LSP or proxy) selects
	a path out of the received ones and the path is composed of all
	strict hops, the head-end LSR will use the signaling procedures
	defined in [INTERD-TESIG] to signal the LSP with an explicit route
	object (ERO) consisting of these strict hops. There will be no need
	for computing path segments to loose hops at intermediate nodes. If
	the path selected by the head-end LSR is composed of strict and loose
	hops, there needs to be a way for an intermediate node to complete
	the path between that node and the next loose hop with strict hops.
	How this is most efficiently done SHOULD be subject for further
	study.
	4.		4.
	Application Scenarios
	4.1.
	Inter-AS Path Computation for Virtual PoP (VPOP) or
	Sub-regional Networks
	A number of application scenarios are discussed in section 4 of
	[INTERAS-TE-REQ] where computing an inter-AS TE-LSP path could rely
	on per-domain path computation using procedures documented in
	[INTERD-TE-PDPC]. However, as noted above, a per-domain computing
	method does not always yield optimum paths. In this section, a
	similar inter-AS TE application scenario using PCEs with inter-AS
	scope to compute optimum paths across AS boundaries is presented.
	Section 4.1.1 and section 4.2.2 of [INTERAS-TE-REQ] have presented
	two cases where a global service provider (SP1) would like to extend
	its reach into a region using a regional network (SP2) as MPLS
	transport. SP1 in these cases would either co-locate its regional
	POP as a virtual PoP within SP2's POP or link its own sub-regional
	network back to SP1's main backbone over SP2's network. This is
	further illustrated in the diagram of Figure 2:
	<=Inter-AS MPLS TE Tunnel T1(R13,R15)=>
	R16(PCE)
	|
	R11(PCC)-R13(PCC)<===>R21-R23-R26(PCE)<===>R15(PCC)-R19-R112
	\ /| \ |\ / | \ / | \ / |
	\ / | \ | \ / | \ / | \_R110 |
	\/ | \ | \ / | \ | \/ |
	/\ | \ | R24(PCE)| / \ | _ R111 |
	/ \ | \ | / \R25 | / \ | / \ |
	/ \| || / \ | / \ | / \ |
	R12(PCC)-R14(PCC)<===>R22----R27(PCE)<===>R17(PCC)----R113(PCC)
	|
	R18(PCE)
	<=Inter-AS MPLS TE Tunnel T2(R14,R17)=>
	<=============Inter-ASS TE Tunnel T3(R11,R113)============>
	+=SP1 VPOP/sub=+ +===SP2 As2===+ +=SP1 backbone AS1=+
	network AS1
	Figure 2: SP1 extended reach linking vPOP or Sub-regional network
	over SP2 MPLS Transport
	In the example diagram depicted in Figure 2, ASBRs R13 and R14 as
	PCCs, dynamically or statically discover their corresponding PCEs R16
	and R18 which in turn maintain meshed peering with AS2 PCEs R26 and
	R27. R13 and R14 then send PCC/PCE path requests to their own primary
	PCEs (R16 or R18) for two optimum yet diversified inter-AS paths for
	T1(R13,R15) and T2(R14,R17) across AS2. In addition, R11 require
	building a separate inter-TE tunnel (T3) to R113 directly to support
	a customer voice-trunk, for example.
	With per-domain path computation, the three tunnels (T1, T2, and T3)
	would be built with paths as shown below, assuming all links have a
	metric value of 1 and all inter-AS links between ASes have the same
	maximum reservable bandwidth:
	- T1's path: (R13,R15) expanding at R21 to have the path R13-R21-R23-
	R26-R15;
	- T2's path: (R14,R17) expanding at R22 to have the path R14-R22-R27-
	R17;
	- T3's path: (R11,R113) expanding at R21 to have the path R11-R13-
	R21-R23-R26-R15-R17-R113
	For T1 and T2, the requirement for diversification is paramount where
	R26 and R27 (as PCEs) will need to maintain synchronized states of
	both T1 and T2 in order to compute two diverse routes for these two
	inter-AS TE LSPs.
	For T3, a more optimum path should be R11-R14-R22-R27-R17-R113 which
	can be obtained through AS1 PCEs (R16 or R17) where R22 and R17 are
	selected as better exits for neighbor ASes.
	In this environment, PCE R24 in AS2 is only for intra-AS TE path
	computation while R26 and R27 are intra-AS PCEs as well as inter-AS
	PCEs for AS1 among others. R16 and R17 are dedicated routers running
	PCE process for AS2.
	Please note that we could also configure R13 and R14 as PCEs with
	direct peering to R26 and R27. In this case, the ASBR routers
	function as the PCE, PCC and the inter-AS tunnel-head end or tail-end
	at the same time. It is also worth noting that the reachability
	between R13 and R14 and their primary PCEs (R16 and R18) will be
	required via, for example either static or BGP routing in the global
	space across inter-ASBR links.
	4.2.
	Inter-AS Path Computation over a GMPLS Transport Core
	This section illustrates a simplified case where inter-AS scoped PCEs
	are used for path computations across a GMPLS transport core.
	(PCC) (PCC)
	R1--ASBR1(PCE)<==>ASBR2(PCE)-GMPLS-ASBR3(PCE)<==>ASBR4(PCE)--R2
	MPLS(PSC) GMPLS(PSC) GMPLS(PSC) MPLS(PSC)
	+===SP1 AS1===+ +=======SP2 As2=============+ +===SP3 AS3===+
	Figure 3 Inter-AS TE LSP over a GMPLS Transport Core
	In Figure 3, R1 (a PCC) sends an MPLS-TE based request message to its
	own PCE ASBR1 to compute an inter-As TE LSP between R1 and R2. ASBR1
	in turns requests path computation from its downstream peering PCE,
	ASBR2, for this LSP to AS3 via AS2. This would require ASBR2 to have
	the ability to receive MPLS-TE based request messages and reinterpret
	the portion corresponding to GMPLS specific attributes (if any) for
	carrying out path computations.
	In this application scenario, AS2 is a pure GMPLS core. It is worth
	noting that AS2 could have outer MPLS edge where the inter-AS TE LSPs
	may get aggregated onto the GMPLS TE LSP on the core GMPLS PSC.
	5.
	Detailed PCECP Requirements for Inter-AS (G)MPLS-TE		Detailed PCECP Requirements for Inter-AS (G)MPLS-TE
	This section discusses detailed PCECP requirements in two principal
	areas for inter-AS (G)MPLS-TE path computtion using a PCE-based
	approach: 1) requirements for inter-AS (G)MPLS-TE in the same SP
	administrative domain (i.e., intra-provider) and 2) requirements for
	inter-AS (G)MPLS-TE/ across different SP administrative domains
	(i.e., inter-provider).
	5.1.		This section discusses detailed PCECP requirements for inter-AS
	Requirements within one SP Administrative Domain		(G)MPLS-TE applications using a PCE-based approach. Depending on the
			operation environment, service providers may use some or all of the
	This section presents detailed PCECP requirements for inter-AS		capabilities of a PCECP that satisfies these requirements.
	(G)MPLS-TE within the same SP administrative domain. It should be		Specifically, some requirements are more applicable to inter-AS
	noted that ASes in a single SP administrative domain can have various		inter-provider (G)MPLS-TE operation than intra-provider operations.
	restrictions and policies among the ASes, as in the inter-provider
	case. The additional PCE requirements for the inter-provider case are
	documented in section 5.2.
	5.1.1.		4.1.1.
	PCC/PCE-PCE Communication Protocol Requirements		PCC/PCE-PCE Communication Protocol Requirements
	Requirements specific to requests or responses are discussed in the		Requirements specific to inter-AS PCECP path computation requests
	next subsections. Following are additional requirements to those		and responses are discussed in section 4.1.1.1 and 4.1.1.2,
	described in [PCECP-REQ] for PCC/PCE-PCE communication. Some of these		respectively.
	requirements apply to the process handling PCC/PCE-PCE communication
	and not the protocol itself:
	- An inter-AS PCE must be able to locally prioritize messages on an
	AS basis in addition to message-level priority.
	- An inter-AS PCE must be able to change the message priority when
	sending a path computation request from the priority it received for
	the same LSP. A notification message should be sent to the requestor
	indicating that change. Such notification must be suppressed by
	configuration action on a neighboring inter-AS PCE basis.
	- An inter-AS PCE must be able to perform translation on class-type
	identifiers carried in a request/response for a DS-TE packet-LSP when
	the two ASes attempting to set an LSP or LSP segment between them use
	different class-type identifier values. Such a situation may arise
	when ASes become part of one service provider domain as a result of
	mergers and acquisitions.
	- In inter-AS operation, an inter-AS PCE must be able to silently
	drop PCECP messages arriving from an AS that it does not wish to
	communicate with. It must also be able to limit the aggregate rate of
	PCECP requests/responses arriving from PCEs affiliated with one ore
	more ASes or from a group of one or more ASes by silently droping
	messages when a pre-configured rate threshold is exceeded.
	5.1.1.1.		4.1.1.1.
	Requirements on path computation requests		Requirements on path computation requests
	Following are inter-AS specific requirements on PCECP requests for		Following are inter-AS specific requirements on PCECP requests for
	path computation		path computation
	- Path computation requests must be able to carry all constraint		- PCECP MUST allow the specification of a path computation request
	attributes necessary for setting up an LSP via (G)MPLS-TE signaling		priority as specified in [PCECP-REQ]. Priority-based message
	as stated in [PCECP-REQ]. A path computation request to an inter-AS		processing is a local decision to a PCE and is out of the scope of
	PCE must be able to specify ASBRs and/or ASes as strict and loose		this document. However, in inter-AS operation, a policy may be
	nodes in the path of the LSP to the destination. A PCE must also be		enforced on a path computation request so that the path computation
	able to specify a preferred ASBR for exiting to the next AS and		request priority is altered when progressing the request within the
	reach the destination through that AS.		same AS or across other ASes. PCECP SHOULD allow the notification of
			the requester of such a change when it happens. Such notification MAY
			be suppressed by configuration action on a neighboring inter-AS PCE
			basis.
	- An inter-AS PCE must be able to specify in its request a list		- A path computation request to an inter-AS PCE MUST be able to
	of ASes and/or ASBRs to be excluded in the path computation. It must		specify ASBRs and/or ASes as strict and loose nodes in the path of
	also be able to include links with specific affinity in the		the LSP to the destination. A PCE MUST also be able to specify a
	exclude/include list. Boundary policies can be deployed to interpret		preferred ASBR for exiting to the next AS for reaching the
	and translate incoming affinity to one significant to the local AS.		destination through a neighboring AS. If such a constraint cannot
			be satisfied at a PCE, PCECP SHOULD allow a PCE to notify the
			requestor of that fact in the path error message.
	- If an inter-AS PCE learns reachability to a destination from		- PCECP MUST enable enlisting a list of ASes and/or ASBRs to be
	different ASes, it should be able to send simultaneous requests to		excluded in the path computation.
	the inter-AS PCEs associated with these ASes. The maximum number of
	inter-AS PCEs, an inter-AS PCE may send simultaneous requests to,
	SHOULD be configurable. The choice of inter-AS PCEs could be
	influenced by policies which prefer some paths over others or some
	PCEs over others. When sending simultaneous requests, the tradeoff
	between signaling and path computation activity on one hand and the
	likelihood of setting an end-to-end optimum path should be
	considered.
	- The PCC/PCE-PCE communication protocol must enable an inter-AS PCE		- PCECP MUST enable an inter-AS PCE to specify the AS on whose behalf
	to specify the AS on whose behalf it is sending the request. This is		it is sending the request. This is specifically important when the
	specifically important when the inter-AS PCE has identified many ASes		inter-AS PCE has identified many ASes within its scope to the other
	within its scope to the other inter-AS PCE at the other end of the		inter-AS PCE at the other end of the communication.
	communication.
	- A PCC or PCE (including inter-AS PCE) must be able to specify in		- A PCC or PCE (including inter-AS PCE) MUST be able to specify in
	its request the need for computing an end-end path with protection		its PCECP path computation request the need for computing an end-to-
	against node and/or link, and/or SRLG failure using 1:1 detours or		end path with protection against node, link, and/or SRLG
	facility backup. An inter-AS PCE may itself ask for a similarly		failure using 1:1 detours or facility backup. An inter-AS PCE may
	protected path. In addition, it may ask for protection across all		itself ask for a similarly protected path. In addition, it may ask
	ASes the path can traverse or across specific ASes. A path		for protection across all ASes the path can traverse or across
	computation client must also be able to ask for a minimum of two		specific ASes.
	paths that are diversified (i.e., do not share common nodes, links or
	SRLGs) its request to an inter-AS PCE.
	- An inter-AS PCE must be able to reject a request based on policies		- A PCC or PCE MUST be able to specify in its path request to an
	applied at a neighboring AS basis. Such policies may include any		inter-AS PCE the retturn of a minimum of two diversified paths
	valid request attributes, including class-types for packet LSPs,		(i.e., paths that do not share common nodes, links and/or SRLGs).
	bandwidth that exceeds a preset threshold per LSP or AS, preemption
	priorities, setup priorities, restriction on links with certain
	affinities, and desired protection. When a path request is rejected,
	the requestor must be informed of the rejection reason along with any
	information that may help the requestor avoid the points and/or
	reasons of rejections in subsequent requests.
	5.1.1.2.		- A PCECP path computation request message MUST enable the
			specification of AS-only diversified path computation.
			- A PCECP path computation request message MUST be able to identify
			the scope of diversified path computation to be end-to-end (i.e.,
			between the endpoints of the (G)MPLS-TE tunnel) or to be limited to a
			specific AS.
			4.1.1.2.
	Requirements on path computation responses		Requirements on path computation responses
	Following are inter-AS specific requirements on PCECP responses for		Following are inter-AS specific requirements on PCECP responses for
	path computation:		path computation:
	- A path computation response must be able to include nodes (e.g.,		- A path computation response MUST be able to include ASBRs and ASes
	ASBRs), abstract nodes such as ASes, and links as described in [PCE-		on the computed path. In inter-AS intra-provider path
	ARCH]. In inter-AS intra-provider path computation, there may not be		computation, there may not be any confidentiality issues or
	any confidentiality issues or restrictions that prevent one AS from		restrictions that prevent one AS from returning a path with strict
	returning a path with strict hops and no loose hops (i.e., nodes and		hops and no loose hops (i.e., nodes and links) within its AS to the
	links) within its AS to the requesting inter-AS PCE. In this case,		requesting inter-AS PCE. In this case, the head-end of an LSP could
	the head-end of an LSP could receive, as a result of the work of		receive, as a result of the work of multiple cooperating intra-AS and
	multiple cooperating intra-AS and inter-AS PCEs, a path that contains		inter-AS PCEs, a path that contains nodes and links as strict hops
	nodes and links as strict hops from LSP head-end to tail-end.		from LSP head-end to tail-end. In the inter-provider case,
			confidentially and security considerations may require only the
			return of AS numbers and/or ASBRs in path computation response
			messages.
	- In a path computation response, each path must contain the ASBR		- A PCECP response message MUST be able to carry an identifier for a
	that connects to the requestor AS at a minimum. In addition, a cost		path segment computed by the responding PCE. Such an identifier could
	associated with each path should be returned to enable selection of		be used in a (G)MPLS-TE path setup message for path expansion at an
	an optimum end-end path. The cost could reflect the cumulative		ASBR.
	administrative cost of the path. The PCC/PCE-PCE PCECP must be able
	to carry this information.
	- In its response, an inter-AS PCE must identify diversified paths,		- A PCECP response message MUST be able to carry an inter-AS
	when it is requested to compute such paths. End-to-end diversified		path cost. Path cost normalization across ASes is out
	paths are paths that do not share nodes, links or SRLGs		of the scope of this document and it is expected to be addressed
	except for the LSP head-end and tail-end. In cases, where diversified		in other work on path computation.
	path segments are desired within one or more ASes, the diversified
	path segments may share only the ASBRs of the first AS and the ASBR
	of the last AS across these ASes.
	- If an inter-AS PCE cannot find a path to the destination or it		- A PCECP response message SHOULD be able to carry an intra-AS cost
	cannot find a path that satisfies the LSP constraints, it must send		for a path segment separately from an inter-AS path segment cost.
	a reject-type message to the requestor with a reject reason. Upon		Best path selection procedures based on these costs are out of the
	receiving this reject message, an inter-AS PCE or a PCC SHOULD		scope of this document.
	attempt an alternative path by sending a request to an alternative
	AS-PCE. If it exhausted all AS-PCEs it SHOULD send a reject message
	to the previous requesting inter-AS PCE if there is one.
	5.1.2.		- A PCECP response message MUST be able to identify diversified paths
			for the same(G)MPLS-TE LSP when the responding PCE is requested to
			compute such paths. End-to-end (i.e., between the two endpoints of
			the (G)MPLS-TE tunnel) disjoint diversified paths are paths that do
			not share nodes, links or SRLGs except for the LSP head-end and tail-
			end. In cases where diversified path segments are desired within one
			or more ASes, the diversified path segments may share only the ASBRs
			of the first AS and the ASBR of the last AS across these ASes.
			4.1.2.
	Scalability and Performance Requirements		Scalability and Performance Requirements
	When evaluating a PCECP for inter-AS case, the following scalability		When evaluating a PCECP for the inter-AS case, the following
	and performance criteria SHOULD be considered:		scalability and performance criteria SHOULD be considered:
	- Message load on the inter-AS PCEs and intra-AS PCEs.		- Message Processing load on the inter-AS PCEs and intra-AS PCEs.
	- Scalability with network size, number of inter-AS PCEs, number of		- Scalability as a function of the following parameters:
	intra-AS PCEs and the effect of these parameters on PCC/PCE-PCE
	sessions		- number of PCCs within the scope of an inter-AS PCE
			- number of intra-area PCEs within the scope of an inter-AS PCE
			- number of peering inter-AS PCEs
	- Added complexity and features to the PCC/PCE-PCE communication		- Added complexity and features to the PCC/PCE-PCE communication
	protocol		protocol
	5.1.3.		4.1.3.
	Complexity and Risks		Management, Aliveness Detection and Recovery Requirements
	The proposed solution(s) SHOULD NOT introduce unnecessary complexity		[PCECP-REQ] specifies generic requirements for PCECP management. This
	to the current operating network to such a degree that it would		document addresses new requirements that apply to inter-AS
	affect the stability and diminish the benefits of deploying such		operations.
	a solution over SP networks.
	5.1.4.		The PCECP MIB module MUST provide objects to control the behavior of
	Management, Aliveness Detection and Recovery Requirements		PCECP in inter-AS applications, including the ASes within its scope,
			the ASes the PCE cannot communicate with via PCECP, the ASes that the
			PCE can communicate with, confidentiality policies, and traffic
			engineering policies. Each of these two latter requirements SHOULD
			apply per inter-AS PCE and/or AS peer.
	Especially, in terms of MIB, inter-AS PCEs should support a specific		The built-in diagnostic tools MUST enable failure detection and
	inter-AS traffic engineering MIB as specified in section 5.1.10.1 of		status checking of PCC/PCE-PCE PCECP. Diagnotic tools include
	[INTERAS-TE-REQ]. This MIB relates to security consideration in this		statistics collection on the historical behavior of PCECP as
	document. The new MIB module must provide trap functions when		specified in [PCECP-REQ]. For inter-AS operations, this statistics
	thresholds are crossed or when important events occur for inter-AS		SHOULD be collected on per inter-AS PCE peer basis and per AS. For
	PCEs.		instance, the following statistics SHOULD be collected:
			- number of successfully satisfied requests
			- number of rejected requests per reason
			- number of PCE requests
			- number of malformed PCECP messages
			- number of unauthenticated PCECP messages
	The built-in diagnostic tools must detect failures of PCC/PCE-PCE		The MIB module MUST support trap functions when thresholds are
	PCECP and allow checking the status of PCECP related to inter-AS		crossed or when important events occur for inter-AS PCEs. These
	PCEs. The new MIB module should support the status of PCECP related		thresholds SHOULD be specifiable per peer AS as well as per peer
	to inter-AS PCEs. Here, it is assumed that inter-AS PCEs exist in		inter-AS PCE and traps should be accordingly generated.
	different AS or different SP administrative domains.
	Basic aliveness detection for PCC/PCE-PCE communication is described		Basic liveliness detection for PCC/PCE-PCE communication is described
	in [PCECP-REQ]. Specifically, the PCECP must allow an inter-AS PCE to		in [PCECP-REQ]. Specifically, the PCECP must allow an inter-AS PCE to
	check the liveliness of the neighboring inter-AS PCE(s) it is		check the liveliness of the neighboring inter-AS PCE(s) it is
	communicating with for inter-AS (G)MPLS-TE path computation.		communicating with for inter-AS (G)MPLS-TE path computation. The
			inter-AS PCECP MIB module SHOULD allow control of liveliness check
	Basic PCC/PCE failure response is described in [PCECP-REQ]. But, an		behavior by providing a liveliness message frequency MIB object. This
	inter-AS PCE must address inter-AS PCE to inter-AS PCE communication		frequency SHOULD be specified per inter-AS PCE peer. In addition,
	failure response. It must be defined how an inter-AS PCE deals with		there SHOULD a MIB object that specifies the dead-interval as a
	the failures of neighboring inter-AS PCEs. It is recommended that an		multiplier of the liveliness message frequency so that if no
	inter-AS PCE selects another neighboring inter-AS PCE that serves the		liveliness message is received within that time from an inter-A PCE,
	same AS or group of ASes so that to obtain equivalent coverage, on		the inter-AS PCE is declared unreachable.
	detection of an inter-AS PCE failure or non-rechability of an inter-
	AS PCE. But note that inter-AS PCE selection procedure is out of the
	scope of this document.
	5.2.
	Requirements Across SP Administrative Domains
	The inter-AS PCECP requirements in the inter-provider case include
	all requirements discussed in section 5.1 in addition to those
	discussed in this section. Please also note that the SP with
	multiple ASes may choose not to include inter-provider inter-AS
	PCE requirements presented here in its inter-AS TE implementation
	within its own administrative domain.
	5.2.1.		4.1.4.
	Confidentiality		Confidentiality
	Each SP will in most cases designate some PCEs for inter-AS (G)MPLS-		Confidentiality mainly applies to inter-provider PCE communication.
	TE path computation within its own administrative domain and some		However, confidentiality rules may also apply among ASes under a
	other PCEs for inter-provider inter-As (G)MPLS-TE path computation.		single provider. Each SP will in most cases designate some PCEs for
	Among the inter-provider-scoped inter-AS PCEs in each SP domain,		inter-AS (G)MPLS-TE path computation within its own administrative
	there may also be a subset of the PCEs specifically enabled for path		domain and some other PCEs for inter-provider inter-As (G)MPLS-TE
	computation across a specific set of ASes of different peer SPs.		path computation. Among the inter-provider-scoped inter-AS PCEs in
			each SP domain, there may also be a subset of the PCEs specifically
			enabled for path computation across a specific set of ASes of
			different peer SPs.
	PCECP should allow an SP to hide from other SPs the set of hops,		PCECP SHOULD allow an SP to hide from other SPs the set of hops,
	within its own AS(es,) traversed by an inter-AS inter-provider		within its own AS(es,) traversed by an inter-AS inter-provider
	(G)MPLS-TE LSP (c.f., Section 5.2.1 of [INTERAS-TE-REQ]). In a		(G)MPLS-TE LSP (c.f., Section 5.2.1 of [INTERAS-TE-REQ]). In a
	multi-SP administrative domain environment, SPs want to hide their		multi-SP administrative domain environment, SPs want to hide their
	network topologies for security reasons. In addition, SPs do not want		network topologies for security reasons. In addition, SPs do not want
	to reveal the path traversed by an LSP segment within their domains		to reveal the path traversed by an LSP segment within their domains
	to other SPs' domains. Thus, for each partial inter-AS LSP path a PCE		to other SPs' domains. Thus, for each partial inter-AS LSP path a PCE
	computes, it should return to its peering PCE in the upstream		computes, it may return to its peering PCE in the upstream neighbor
	neighbor AS(es) an inter-AS TE LSP segment from its own AS(es)		AS(es) an inter-AS TE LSP segment from its own AS(es) without
	without detailing the explicit intra-AS hops plus partial paths with		detailing the explicit intra-AS hops plus partial paths with an
	an aggregated TE LSP cost it receives from its downstream PCE. A PCE		aggregated TE LSP cost it receives from its downstream PCE. As stated
	should be able to compute the inter-AS TE LSP across AS boundaries		earlier, PCECP responses SHOULD be able to carry path-segment
	without detailed knowledge of the list of hops, TE link metrics and		identifiers without the details of that path segment. An ASBR that
	paths within each transit AS.		receives an RSVP-TE path message with an identifier object
			(new object), it can use that object to contact the PCE keyed by
			that identifier and extract the identified path segment as well.
	5.2.2.		4.1.5.
	Policy Controls Effecting inter-AS PCECP		Policy Controls Effecting inter-AS PCECP
	Section 5.2.2. of [INTERAS-TE-REQ] discusses the policy control		Section 5.2.2 of [INTERAS-TE-REQ] discusses the policy control
	requirements on the inter-AS RSVP-TE signaling at the AS boundaries		requirements on the inter-AS RSVP-TE signaling at the AS boundaries
	for the enforcement of interconnect agreements, attribute/parameter		for the enforcement of interconnect agreements, attribute/parameter
	translation and security hardening.		translation and security hardening.
	This section discusses those policy control requirements for PCECP.		This section discusses those policy control requirements for PCECP.
	Please note that SPs may still require ingress policy controls on the		Please note that SPs may still require ingress policy controls on the
	actual signaling paths mentioned above to enforce their bilateral or		actual signaling paths mentioned above to enforce their bilateral or
	multi-lateral agreements at the AS boundaries.		multi-lateral agreements at the AS boundaries.
	5.2.2.1.		4.1.5.1.
	Inter-AS PCE Peering Policy Controls		Inter-AS PCE Peering Policy Controls
	A PCE SHOULD have the ability to enforce policies, defined for a set
	of parameters listed in section 5.2.2.1 of [INTERAS-TE-REQ], on the
	incoming PCECP path computation requests.
	In a multi-SP administrative domain environment, each SP itself has		In a multi-SP administrative domain environment, each SP itself has
	some policies for a (G)MPLS-TE enabled network. An inter-AS PCE sends		some policies for a (G)MPLS-TE enabled network. An inter-AS PCE sends
	path computation requests with some parameters to its neighboring		path computation requests with some parameters to its neighboring
	inter-AS PCEs. In terms of parameters, see section 5.2.2.1 of		inter-AS PCEs. An inter-AS PCE that receives such requests enforces
	[INTERAS-TE-REQ]. In this case, an inter-AS PCE enforces some		some policies applied to its neighboring inter-AS PCEs. These
	policies applied to its neighboring inter-AS PCEs. These policies may		policies may include rewriting some of the parameters' values and
	include rewriting some of the parameters' values or rejecting		rejecting requests based on some parameters' values. Such policies
	requests based on some parameters' values. Inter-AS PCEs should also		may also be applied in the case of multiple ASes within a single SP
	have the ability to exclude and/or filter internally-scoped		administrative domain. Parameters subject to policy include
	information and capability information based on policies. Such		bandwidth, setup/holding priority, Fast Reroute request,
	policies may also be applied in the case of multiple ASes within a		Differentiated Services Traffic Engineering (DS-TE) Class Type (CT),
	single SP administrative domain.		and others as specified in section 5.2.2.1 of [INTERAS-TE-REQ].
	For path computation requests that are not compliant with configured		For path computation requests that are not compliant with configured
	policies, the policy enforcing PCE SHOULD generate an error message		policies, PCECP SHOULD enable a PCE to send an error message to the
	to the requesting PCC or PCE indicating the cause of errors or a		requesting PCC or PCE indicating the cause of errors.
	reject message with a reason.
	5.2.2.2.		4.1.5.2.
	Inter-AS PCE Reinterpretation Polices		Inter-AS PCE Reinterpretation Polices
	Each SP may have different definitions in its use of for example,		Each SP may have different definitions in its use of for example,
	RSVP-TE session attributes, DS-TE TE classes, etc. The PCEs		RSVP-TE session attributes, DS-TE TE classes, etc. A PCE receiving
	receiving these path requests need to be able to reinterpret some of		path computation requests needs to be able to reinterpret some of the
	the attributes and adapt them to the native environment in their own		attributes and adapt them to the native environment in its own AS for
	AS for path computation. A list of such parameters subject to policy		path computation. A list of such parameters subject to policy
	reinterpretation can be found in section 5.2.2.2 of [INTERAS-TE-REQ].		reinterpretation can be found in section 5.2.2.2 of [INTERAS-TE-REQ].
	Also the transit SPs along the inter-AS TE path may be a GMPLS		In addition, the transit SPs along the inter-AS TE path may be GMPLS
	transport provider which may require reinterpretation of MPLS		transport providers which may require reinterpretation of MPLS
	specific PCE path request message for path computation over a GMPLS		specific PCECP path request messages for path computation over a
	network.		GMPLS network. These interpretation policies must be specifiable on
			a per-peer inter-AS PCE or AS basis as part of PCECP MIBs discussed
	The PCECP implementation SHOULD allow for the policy enforcing PCEs		earlier.
	to reinterpret some of these parameters in the incoming PCC or PCE
	requests from other AS(es) for its own AS TE implementations or to
	signal to PCEs in the downstream AS(es).
	6.		5.
	Security Considerations		Security Considerations
	Security concerns arise between any two communicating elements		Security concerns arise between any two communicating elements
	especially when the elements belong to different administrative		especially when the elements belong to different administrative
	entities. In this case, there are security concerns that need to be		entities. In this case, there are security concerns that need to be
	addressed for communication among inter-AS PCEs and other PCEs in a		addressed for communication among inter-AS PCEs and other PCEs in a
	single SP administrative domain as well as among inter-AS PCEs under		single SP administrative domain as well among inter-AS PCEs under
	different SP administrative domains. Following are requirements that		different SP administrative domains. [PCECP-REQ] specifies
	apply to inter-AS PCECP messages:		requirements on PCECP to protect against spoofing, snooping and DoS
			attacks. These requirements become especially important in the multi-
	- Authentication, permission and rejection for path computation		AS case.
	requests:
	In a multi-SP administrative domain environment, SPs want to
	authenticate inter-AS path computation requests to confirm whether
	they should trust the requests or not. They also want to allow
	or deny the requests after inter-AS PCEs authenticate them.
	In case multiple ASes exist within a single SP administrative domain,
	the SP may authenticate inter-AS path computation requests to confirm
	whether it should trust the requests or not, depending on SP policy.
	An inter-AS PCE may allow or deny the requests after it authenticates
	them. Inter-AS PCEs should also be able to authenticate inter-AS
	PCECP path computation responses.
	Inter-AS PCEs should be able to authenticate inter-AS path		6.
	computation requests and confirm whether they should allow or deny		IANA Considerations
	them. Inter-AS PCEs should be able to authenticate all PCECP
	messages.
	- Traffic policing: In multi-SP administrative domain environment or		This document makes no requests for IANA action.
	in case multiple ASes exist within a single SP administrative domain,
	inter-AS PCEs may receive a large number of PCE requests within a
	short time (i.e., resulting in a high path-computation-request rate).
	Inter-AS PCEs should be able to limit the amount of PCE requests.
	- Protection from DoS attacks: In multi-SP administrative domain		7.
	environment, inter-AS PCEs may be subject to malicious DoS attacks		Acknowledgments
	using PCECP. Inter-AS PCEs should be able protect themselves from
	such attacks.
	- PCC/PCE spoofing: In multi-SP administrative domain environment,		We would like to thank Adrian Farrel, Jean-Philippe Vasseur,
	inter-AS PCEs have the possibility of spoofing the PCC/PCE-PCE		and Jean Louis Le Roux for their useful comments and suggestions.
	communication. Inter-AS PCEs should have functions to avoid spoofing
	PCC/PCE-PCE communication.
	7.		8.
	Authors' Addresses		Authors' Addresses
	Nabil Bitar		Nabil Bitar
	Verizon		Verizon
	40 Sylvan Road		40 Sylvan Road
	Waltham, MA 02451		Waltham, MA 02451
	Email: nabil.n.bitar@verizon.com		Email: nabil.n.bitar@verizon.com
	Kenji Kumaki		Kenji Kumaki
	KDDI Corporation		KDDI Corporation
	Garden Air Tower		Garden Air Tower
	Iidabashi, Chiyoda-ku,		Iidabashi, Chiyoda-ku,
	Tokyo 102-8460, JAPAN		Tokyo 102-8460, JAPAN
	Phone: +81-3-6678-3103		Phone: +81-3-6678-3103
	Email: ke-kumaki@kddi.com		Email: ke-kumaki@kddi.com
	Raymond Zhang		Raymond Zhang
	BT INFONET Services Corporation		BT INFONET Services Corporation
	2160 E. Grand Ave.		2160 E. Grand Ave.
	El Segundo, CA 90245 USA		El Segundo, CA 90245 USA
	Email: Raymond_zhang@bt.infonet.com		Email: Raymond_zhang@bt.infonet.com
	8.		9.
	Normative References		Normative References
	[INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic		[INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic
	Engineering Requirements", RFC4216, November 2005.		Engineering Requirements", RFC4216, November 2005.
	[PCE-ARCH] Farrel, Vasseur & Ash, "A Path Computation Element		[PCE-ARCH] Farrel, Vasseur & Ash, "A Path Computation Element
	(PCE)Based Architecture", draft-ietf-pce-architecture-04.txt, January		(PCE) Based Architecture", draft-ietf-pce-architecture-05.txt
	2006 (Work in Progress)		(Work in Progress).
	[PCECP-REQ] J. Ash, J.L Le Roux et al., "PCE Communication Protocol		[PCECP-REQ] J. Ash, J.L Le Roux et al., "PCE Communication Protocol
	Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-		Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-
	04.txt(work in progress).		06.txt (work in progress).
	[PCEDP-REQ] J.L. Le Roux et al., "Requirements for Path Computation
	Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (work in
	progress).
	[TE-REQ] Awduche et. al., "Requirements for Traffic Engineering over
	MPLS", RFC2702, September 1999.
	[TE-RSVP] Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001
	[INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, "A Per-domain path
	computation method for computing Inter-domain Traffic Engineering
	(TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
	path-comp-02.txt, February 2006, (Work in Progress).
	9.		10.
	Informative References		Informative References
	[INTERD-TESIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic		[INTERD-TESIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic
	Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-		Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-
	rsvp-te-02.txt, April 2006 (Work in Progress)		rsvp-te-02.txt, April 2006 (Work in Progress)
	[ISP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with		[LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with
	Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt,		Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt,
	September 2005, (work in progress).		September 2005, (work in progress).
	[LSP-HIERARCHY] Kompella K., Rekhter Y., "Label switched Paths (LSP)		[LSP-HIERARCHY] Kompella K., Rekhter Y., "Label switched Paths (LSP)
	Hierarchy with Generalized MPLS TE", RFC4206, October 2005.		Hierarchy with Generalized MPLS TE", RFC4206, October 2005.
	[GMPLS-ROUT] Kompella, et. al., "Generalized Multi-Protocol Label		[PCEDP-REQ] J.L. Le Roux et al., "Requirements for Path Computation
	Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic		Element(PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (work in
	Engineering (RSVP-TE) Extensions, RFC 3473, January 2003.		progress).
	Full Copyright Statement
	Copyright (C) The Internet Society (2006). 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		[INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, "A Per-domain path
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		computation method for computing Inter-domain Traffic Engineering
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		(TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		path-comp-02.txt, February 2006, (Work in Progress).
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property Statement
	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
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	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		this standard. Please address the information to the IETF at ietf-
	ietf@ipr@ietf.org.		ipr@ietf.org.
			Disclaimer of Validity
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Copyright Statement
			Copyright (C) The Internet Society (2006). 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.
End of changes. 81 change blocks.
	607 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/