draft-ietf-ccamp-inter-domain-framework-00.txt		draft-ietf-ccamp-inter-domain-framework-01.txt
	Network Working Group Adrian Farrel		Network Working Group Adrian Farrel
	IETF Internet Draft Olddog Consulting		IETF Internet Draft Olddog Consulting
	Proposed Status: Informational		Proposed Status: Informational
	Expires: January 2004 Jean-Philippe Vasseur		Expires: August 2005 Jean-Philippe Vasseur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Arthi Ayyangar		Arthi Ayyangar
	Juniper Networks		Juniper Networks
	August 2004		February 2005
	draft-ietf-ccamp-inter-domain-framework-00.txt
	A Framework for Inter-Domain MPLS Traffic Engineering		A Framework for Inter-Domain MPLS Traffic Engineering
			draft-ietf-ccamp-inter-domain-framework-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any 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 become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Working documents of the Internet Engineering Task Force (IETF), its		Internet-Drafts are working documents of the Internet Engineering
	areas, and its working groups. Note that other groups may also		Task Force (IETF), its areas, and its working groups. Note that
	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.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	This document provides a framework for establishing and controlling		This document provides a framework for establishing and controlling
	Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)		Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
	Label Switched Paths (LSPs) in multi-domain networks.		Label Switched Paths (LSPs) in multi-domain networks.
	For the purposes of this document, a domain is considered to be any		For the purposes of this document, a domain is considered to be any
	collection of network elements within a common sphere of address		collection of network elements within a common sphere of address
	management or path computational responsibility. Examples of such		management or path computational responsibility. Examples of such
	domains include IGP areas and Autonomous Systems.		domains include IGP areas and Autonomous Systems.
			Contents
			1. Introduction ...............................................
			1.1. Nested Domains .........................................
			1.2. Conventions used in this document ......................
			2. Signaling Options ..........................................
			2.1. LSP Nesting ............................................
			2.2. Contiguous LSP .........................................
			2.3. LSP Stitching ..........................................
			2.4. Hybrid Methods .........................................
			2.5. Control of Downstream Choice of Signaling Method ....... x
			3. Path Computation Techniques ................................
			3.1. Management Configuration ...............................
			3.2. Head End Computation ...................................
			3.2.1. Multi-Domain Visibility Computation ................
			3.2.2. Partial Visibility Computation .....................
			3.2.3. Local Domain Visibility Computation ................
			3.3. Domain Boundary Computation ............................
			3.4. Path Computation Element ...............................
			3.4.1. Multi-Domain Visibility Computation ................
			3.4.2. Path Computation Use of PCE When Preserving
			Confidentiality ....................................
			3.4.3. Per-Domain Computation Servers .....................
			3.5. Optimal Path Computation ...............................
			4. Distributing Reachability and TE Information ...............
			5. Comments on Advanced Functions .............................
			5.1. LSP Re-Optimization ....................................
			5.2. LSP Setup Failure ......................................
			5.3. LSP Repair .............................................
			5.4. Fast Reroute ...........................................
			5.5. Comments on Path Diversity .............................
			5.6. Domain-Specific Constraints ............................
			5.7. Policy Control .........................................
			5.8. Inter-domain OAM .......................................
			5.9. Point-to-Multipoint ....................................
			5.10. Applicability to Non-Packet Technologies ..............
			6. Security Considerations ....................................
			7. IANA Considerations ........................................
			8. Acknowledgements ...........................................
			9. Intellectual Property Considerations .......................
			10. Normative References ......................................
			11. Informational References ..................................
			12. Authors' Addresses ........................................
			13. Full Copyright Statement ..................................
	1. Introduction		1. Introduction
	The Traffic Engineering Working Group has developed requirements for		The Traffic Engineering Working Group has developed requirements for
	inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and		inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and
	[INTER-AS].		[INTER-AS].
	Various proposals have subsequently been made to address some or all		Various proposals have subsequently been made to address some or all
	of these requirements through extensions to the RSVP-TE and IGP		of these requirements through extensions to the RSVP-TE and IGP
	(ISIS, OSPF) protocols and procedures.		(ISIS, OSPF) protocols and procedures.
	This document introduces the techniques for establishing TE LSPs		This document introduces the techniques for establishing TE LSPs
	across multiple domains. The functional components of these		across multiple domains. The functional components of these
	techniques are separated into the mechanisms for discovering		techniques are separated into the mechanisms for discovering
	reachability and TE information, for computing the paths of LSPs, and		reachability and TE information, for computing the paths of LSPs, and
	for signaling the LSPs. Note that the aim is this document is not to		for signaling the LSPs. Note that the aim of this document is not to
	detail each of those techniques which are covered in separate		detail each of those techniques which are covered in separate
	documents, but rather to propose a framework for inter-domain MPLS		documents, but rather to propose a framework for inter-domain MPLS
	Traffic Engineering.		Traffic Engineering.
			Note that in the remainder of this document, the term 'MPLS Traffic
			Engineering' is used equally to apply to MPLS and GMPLS traffic
			engineering in packet and non-packet environments.
	For the purposes of this document, a domain is considered to be any		For the purposes of this document, a domain is considered to be any
	collection of network elements within a common sphere of address		collection of network elements within a common sphere of address
	management or path computational responsibility. Examples of such		management or path computational responsibility. Examples of such
	domains include IGP areas and Autonomous Systems. However, domains of		domains include IGP areas and Autonomous Systems. However, domains of
	computational responsibility may also exist as sub-domains of areas		computational responsibility may also exist as sub-domains of areas
	or ASs. Wholly or partially overlapping domains are not within the		or ASs. Wholly or partially overlapping domains are not within the
	scope of this document.		scope of this document.
	1.1. Nested Domains		1.1. Nested Domains
	skipping to change at line 106		skipping to change at line 157
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Signaling Options		2. Signaling Options
	Three distinct options for signaling TE LSPs across multiple domains		Three distinct options for signaling TE LSPs across multiple domains
	are identified. The choice of which options to use may be influenced		are identified. The choice of which options to use may be influenced
	by the path computation technique used (see section 3), although some		by the path computation technique used (see section 3), although some
	path computation may apply to multiple TE LSP types. The choice may		path computation techniques may apply to multiple TE LSP types. The
	further depend on the application to which the TE LSPs are put and		choice may further depend on the application to which the TE LSPs are
	the nature, topology and switching capabilities of the network.		put and the nature, topology and switching capabilities of the
			network.
	A comparison of the usages of the different signaling options is		A comparison of the usages of the different signaling options is
	beyond the scope of this document and should be the subject of a		beyond the scope of this document and should be the subject of a
	separate applicability statement.		separate applicability statement.
	2.1. LSP Nesting		2.1. LSP Nesting
	Forwarding Adjacencies (FAs) are introduced and explained in detail		Forwarding Adjacencies (FAs) are introduced and explained in detail
	in [HIER]. No further description is necessary in this document.		in [HIER]. No further description is necessary in this document.
	skipping to change at line 141		skipping to change at line 193
	The signaling trigger for the establishment of an FA LSP may be the		The signaling trigger for the establishment of an FA LSP may be the
	receipt of a signaling request for the TE LSP that it will carry, or		receipt of a signaling request for the TE LSP that it will carry, or
	may be a management action to 'pre-engineer' a domain to be crossed		may be a management action to 'pre-engineer' a domain to be crossed
	by TE LSPs that would be used as FAs by the traffic that has to		by TE LSPs that would be used as FAs by the traffic that has to
	traverse the domain. Furthermore, the mapping (inheritance rules)		traverse the domain. Furthermore, the mapping (inheritance rules)
	between attributes of the nested and FA LSPs (including bandwidth)		between attributes of the nested and FA LSPs (including bandwidth)
	may be statically pre-configured or, for on-demand FA LSPs, may be		may be statically pre-configured or, for on-demand FA LSPs, may be
	dynamic according to the properties of the nested LSPs.		dynamic according to the properties of the nested LSPs.
	Note that a hierarchical LSP may be constructed to span multiple		Note that a hierarchical LSP may be constructed to span multiple
	domains or parts of domains, however how or whether such an LSP could		domains or parts of domains. However, how or whether such an LSP
	be advertised as an FA that spans domains is open for study. The end		could be advertised as an FA that spans domains is open for study.
	points of a hierarchical LSP are not necessarily on domain		The end points of a hierarchical LSP are not necessarily on domain
	boundaries, so nesting is not limited to domain boundaries.		boundaries, so nesting is not limited to domain boundaries.
	Note also that the IGP/EGP routing topology is maintained unaffected		Note also that the IGP/EGP routing topology is maintained unaffected
	by the LSP connectivity and TE links introduced by FA LSPs. That is,		by the LSP connectivity and TE links introduced by FA LSPs. That is,
	the routing protocols do not exchange messages over the FA LSPs, and		the routing protocols do not exchange messages over the FA LSPs, and
	such LSPs do not create adjacencies between routers. During this		such LSPs do not create routing adjacencies between routers.
	operation the SENDER_TEMPLATE and SESSION objects remain unchanged
	along the entire length of the LSP.		During the operation of establishing a nested LSP that uses a
			hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain
			unchanged along the entire length of the nested LSP.
	2.2. Contiguous LSP		2.2. Contiguous LSP
	A single contiguous LSP is established from ingress to egress in a		A single contiguous LSP is established from ingress to egress in a
	single signaling exchange. No further LSPs are required be		single signaling exchange. No further LSPs are required to be
	established to support this LSP. Signaling occurs between adjacent		established to support this LSP. Signaling occurs between adjacent
	neighbors only (no tunneling), and hop-by-hop signaling is used.		neighbors only (no tunneling), and hop-by-hop signaling is used.
	2.3. LSP Stitching		2.3. LSP Stitching
			LSP Stitching is described in [STITCH].
	In the LSP stitching model separate LSPs (referred to as a TE LSP		In the LSP stitching model separate LSPs (referred to as a TE LSP
	segments) are established and are "stitched" together in the data		segments) are established and are "stitched" together in the data
	plane so that a single end-to-end label switched path is achieved.		plane so that a single end-to-end label switched path is achieved.
	The distinction is that the component LSP segments are signaled as		The distinction is that the component LSP segments are signaled as
	distinct TE LSPs in the control plane. Each signaled TE LSP segment		distinct TE LSPs in the control plane. Each signaled TE LSP segment
	has a different source and destination.		has a different source and destination.
	LSP stitching can be used in support of inter-domain TE LSPs. In		LSP stitching can be used in support of inter-domain TE LSPs. In
	particular, an LSP segment may be used to achieve connectivity		particular, an LSP segment may be used to achieve connectivity
	between any pair of LSRs within a domain. The ingress and egress of		between any pair of LSRs within a domain. The ingress and egress of
	the LSP segment could be the edge nodes of the domain in which case		the LSP segment could be the edge nodes of the domain in which case
	connectivity is achieved across the entire domain, or they could be		connectivity is achieved across the entire domain, or they could be
	any other pair of LSRs in the domain.		any other pair of LSRs in the domain.
	The signaling trigger for the establishment of a TE LSP segment may		The signaling trigger for the establishment of a TE LSP segment may
	be the establishment of the previous TE LSP segment, the receipt of		be the establishment of the previous TE LSP segment, the receipt of
	setup request for TE LSP that it plans to stitch to a local TE LSP		setup request for TE LSP that it plans to stitch to a local TE LSP
	segment, or may be a management action.		segment, or may be a management action.
			LSP segments may be managed as FAs and advertised as TE links.
	2.4. Hybrid Methods		2.4. Hybrid Methods
	There is nothing to prevent the mixture of signaling methods		There is nothing to prevent the mixture of signaling methods
	described above when establishing a single, end-to-end, inter-domain		described above when establishing a single, end-to-end, inter-domain
	TE LSP. It may be desirable in this case for the choice of the		TE LSP. It may be desirable in this case for the choice of the
	various methods to be indicated along the path perhaps through the		various methods to be indicated along the path perhaps through the
	RRO.		RRO.
	If there is a desire to restrict which methods are used, this MUST be		If there is a desire to restrict which methods are used, this MUST be
	signaled as described in the next section.		signaled as described in the next section.
	skipping to change at line 221		skipping to change at line 279
	The techniques used are closely tied to the signaling methodologies		The techniques used are closely tied to the signaling methodologies
	described in the previous section in that certain computation		described in the previous section in that certain computation
	techniques may require the use of particular signaling approaches and		techniques may require the use of particular signaling approaches and
	vice versa.		vice versa.
	Any discussion of the appropriateness of a particular path		Any discussion of the appropriateness of a particular path
	computation technique in any given circumstance is beyond the scope		computation technique in any given circumstance is beyond the scope
	of this document and should be described in a separate applicability		of this document and should be described in a separate applicability
	statement.		statement.
			Path computation algorithms are firmly out of scope of this document.
	3.1. Management Configuration		3.1. Management Configuration
	Path computation may be performed by offline tools or by a network		Path computation may be performed by offline tools or by a network
	planner. The resultant path may be supplied to the ingress LSR as		planner. The resultant path may be supplied to the ingress LSR as
	part of the TE LSP or service request, and encoded by the ingress LSR		part of the TE LSP or service request, and encoded by the ingress LSR
	as an ERO on the Path message that is sent out.		as an ERO on the Path message that is sent out.
	There is no reason why the path provided by the operator should not		There is no reason why the path provided by the operator should not
	span multiple domains if the relevant information is available to the		span multiple domains if the relevant information is available to the
	planner or the offline tool. The definition of what information is		planner or the offline tool. The definition of what information is
	skipping to change at line 246		skipping to change at line 306
	The head end, or ingress, LSR may assume responsibility for path		The head end, or ingress, LSR may assume responsibility for path
	computation when the operator supplies part or none of the explicit		computation when the operator supplies part or none of the explicit
	path. The operator MUST, in any case, supply at least the destination		path. The operator MUST, in any case, supply at least the destination
	address (egress) of the LSP.		address (egress) of the LSP.
	3.2.1. Multi-Domain Visibility Computation		3.2.1. Multi-Domain Visibility Computation
	If the ingress has sufficient visibility of the topology and TE		If the ingress has sufficient visibility of the topology and TE
	information for all of the domains across which it will route the LSP		information for all of the domains across which it will route the LSP
	to its destination then it may compute and provide the entire path.		to its destination then it may compute and provide the entire path.
	The quality of this path is best if the ingress has full visibility		The quality of this path (that is, its optimality as discussed in
	into all relevant domains rather than just sufficient visibility to		section 3.5) is best if the ingress has full visibility into all
	provide some path to the destination.		relevant domains rather than just sufficient visibility to provide
			some path to the destination.
	Extreme caution must be exercised in consideration of the		Extreme caution must be exercised in consideration of the
	distribution of the requisite TE information. See section 4.		distribution of the requisite TE information. See section 4.
	3.2.2. Partial Visibility Computation		3.2.2. Partial Visibility Computation
	It may be that the ingress does not have full visibility of the		It may be that the ingress does not have full visibility of the
	topology of all domains, but does have information about the		topology of all domains, but does have information about the
	connectedness of the domains and the TE resource availability across		connectedness of the domains and the TE resource availability across
	the domains. In this case, the ingress is not able to provide a fully		the domains. In this case, the ingress is not able to provide a fully
	skipping to change at line 323		skipping to change at line 384
	3.4. Path Computation Element		3.4. Path Computation Element
	The computation techniques in sections 3.2 and 3.3 rely on topology		The computation techniques in sections 3.2 and 3.3 rely on topology
	and TE information being distributed to the ingress LSR and those		and TE information being distributed to the ingress LSR and those
	LSRs at domain boundaries. These LSRs are responsible for computing		LSRs at domain boundaries. These LSRs are responsible for computing
	paths. Note that there may be scaling concerns with distributing the		paths. Note that there may be scaling concerns with distributing the
	required information - see section 4.		required information - see section 4.
	An alternative technique places the responsibility for path		An alternative technique places the responsibility for path
	computation with a Path Computation Element (PCE). There may be		computation with a Path Computation Element (PCE) [PCE]. There may be
	either a centralized PCE, or multiple PCEs (each having a local		either a centralized PCE, or multiple PCEs (each having local
	visibility and collaborating in a distributed fashion to compute an		visibility and collaborating in a distributed fashion to compute an
	end to end path) across the entire network and even within any one		end-to-end path) across the entire network and even within any one
	domain. The PCE may collect topology and TE information from the same		domain. The PCE may collect topology and TE information from the same
	sources as would be used by LSRs in the paragraph, or though other		sources as would be used by LSRs in the previous paragraph, or though
	means.		other means.
	Each LSR called upon to perform path computation (and even the		Each LSR called upon to perform path computation (and even the
	offline management tools described in section 3.1) may abdicate the		offline management tools described in section 3.1) may abdicate the
	task to a PCE of its choice. The selection of PCE(s) may be driven by		task to a PCE of its choice. The selection of PCE(s) may be driven by
	static configuration or the dynamic discovery by means of IGP or BGP		static configuration or the dynamic discovery by means of IGP or BGP
	extensions.		extensions.
	3.4.1. Multi-Domain Visibility Computation		3.4.1. Multi-Domain Visibility Computation
	A PCE may have full visibility, perhaps through connectivity to		A PCE may have full visibility, perhaps through connectivity to
	skipping to change at line 377		skipping to change at line 438
	the domain may consult its local PCE.		the domain may consult its local PCE.
	This mechanism could be used for all path computations within the		This mechanism could be used for all path computations within the
	domain, or specifically limited to computations for LSPs that will		domain, or specifically limited to computations for LSPs that will
	leave the domain where external connectivity information can then be		leave the domain where external connectivity information can then be
	restricted to just the PCE.		restricted to just the PCE.
	3.5. Optimal Path Computation		3.5. Optimal Path Computation
	An optimal route might be defined as the route that would be computed		An optimal route might be defined as the route that would be computed
	in the absence of domain boundaries. It is easy to construct examples		in the absence of domain boundaries. Another constraint to the
			definition of 'optimal' might be to reduce or limit the number of
			domains crossed by the LSP. It is easy to construct examples
	that show that partitioning a network into domains, and the resulting		that show that partitioning a network into domains, and the resulting
	loss or aggregation of routing information may lead to the		loss or aggregation of routing information may lead to the
	computation of routes that are other than optimal. It is impossible		computation of routes that are other than optimal. It is impossible
	to guarantee optimal routing in the presence of aggregation /		to guarantee optimal routing in the presence of aggregation /
	abstraction / summarization of routing information.		abstraction / summarization of routing information.
	It is beyond the scope of this document to define what is an optimum		It is beyond the scope of this document to define what is an optimum
	path for an inter-domain TE LSP. This debate is abdicated in favor of		path for an inter-domain TE LSP. This debate is abdicated in favor of
	requirements documents and applicability statements. Note, however,		requirements documents and applicability statements. Note, however,
	that the meaning of certain computation metrics may differ between		that the meaning of certain computation metrics may differ between
	skipping to change at line 403		skipping to change at line 466
	make certain demands upon the distribution of reachability		make certain demands upon the distribution of reachability
	information and the TE capabilities of nodes and links within domains		information and the TE capabilities of nodes and links within domains
	as well as the TE connectivity across domains.		as well as the TE connectivity across domains.
	Currently, TE information is distributed within domains by additions		Currently, TE information is distributed within domains by additions
	to IGPs [RFC3630], [RFC3784].		to IGPs [RFC3630], [RFC3784].
	In cases where two domains are interconnected by one or more links		In cases where two domains are interconnected by one or more links
	(that is, the domain boundary falls on a link rather than on a node),		(that is, the domain boundary falls on a link rather than on a node),
	there SHOULD be a mechanism to distribute the TE information		there SHOULD be a mechanism to distribute the TE information
	associated with the links to the corresponding domains. This would		associated with the inter-domain links to the corresponding domains.
	facilitate better path computation and reduce TE-related crankbacks		This would facilitate better path computation and reduce TE-related
	on these links.		crankbacks on these links.
	Where a domain is a subset of an IGP area, filtering of TE		Where a domain is a subset of an IGP area, filtering of TE
	information may be applied at the domain boundary. This filtering may		information may be applied at the domain boundary. This filtering may
	be one way, or two way.		be one way, or two way.
	Where information needs to reach a PCE that spans multiple domains,		Where information needs to reach a PCE that spans multiple domains,
	the PCE may snoop on the IGP traffic in each domain, or play an		the PCE may snoop on the IGP traffic in each domain, or play an
	active part as an IGP-capable node in each domain. The PCE might also		active part as an IGP-capable node in each domain. The PCE might also
	receive TEDB updates from a proxy within the domain.		receive TEDB updates from a proxy within the domain.
	It could be possible that an LSR that performs path computation (for		It could be possible that an LSR that performs path computation (for
	example, and ingress LSR) obtains the topology and TE information of		example, an ingress LSR) obtains the topology and TE information of
	not just its own domain, but other domains as well. This information		not just its own domain, but other domains as well. This information
	may be subject to filtering applied by the advertising domain (for		may be subject to filtering applied by the advertising domain (for
	example, the information may be limited to FAs across other domains,		example, the information may be limited to FAs across other domains,
	or the information may be aggregated or abstracted).		or the information may be aggregated or abstracted).
	Where any cross-domain reachability and TE information needs to be		Where any cross-domain reachability and TE information needs to be
	advertised, consideration must be given to TE extensions to BGP, and		advertised, consideration must be given to TE extensions to BGP, and
	how these may be fed to the IGPs. Techniques for inter-domain TE		how these may be fed to the IGPs. Techniques for inter-domain TE
	aggregation are also for further study. However, it must be noted		aggregation are also for further study. However, it must be noted
	that any extensions that cause a significant increase in the amount		that any extensions that cause a significant increase in the amount
	skipping to change at line 523		skipping to change at line 586
	Fast Reroute may also be used (see below).		Fast Reroute may also be used (see below).
	5.4. Fast Reroute		5.4. Fast Reroute
	MPLS Traffic Engineering Fast Reroute ([FRR]) defines local		MPLS Traffic Engineering Fast Reroute ([FRR]) defines local
	protection schemes intended to provide fast recovery (in 10s of		protection schemes intended to provide fast recovery (in 10s of
	msecs) of fast-reroutable TE LSPs upon link/SRLG/Node failure. A		msecs) of fast-reroutable TE LSPs upon link/SRLG/Node failure. A
	backup TE LSP is configured and signaled at each hop, and activated		backup TE LSP is configured and signaled at each hop, and activated
	upon detecting or being informed of a network element failure. The		upon detecting or being informed of a network element failure. The
	node immediately upstream of the failure (called the PLR (Point of		node immediately upstream of the failure (called the PLR - Point of
	Local Repair)) reroutes the set of protected TE LSPs onto the		Local Repair) reroutes the set of protected TE LSPs onto the
	appropriate backup tunnel(s) and around the failed resource.		appropriate backup tunnel(s) and around the failed resource.
	In the context of inter-domain TE, there are several different		In the context of inter-domain TE, there are several different
	failure scenarios that must be analyzed. Provision of suitable		failure scenarios that must be analyzed. Provision of suitable
	solutions may be further complicated by the fact that [FRR] specifies		solutions may be further complicated by the fact that [FRR] specifies
	two distinct modes of operation referred to as the "one to one mode"		two distinct modes of operation referred to as the "one to one mode"
	and the "facility back-up mode".		and the "facility back-up mode".
	The failure scenarios specific to inter-domain TE are as follows:		The failure scenarios specific to inter-domain TE are as follows:
	- Failure of a domain edge node that is present in both domains.		- Failure of a domain edge node that is present in both domains.
	There are two sub-cases:		There are two sub-cases:
	- The PLR and the MP are in the same domain		- The PLR and the MP are in the same domain
	- The PLR and the MP are in different domains.		- The PLR and the MP are in different domains.
	- Failure of a domain edge node that is only present in one of the		- Failure of a domain edge node that is only present in one of the
	domains.		domains.
	- Failure of an inter-domain link.		- Failure of an inter-domain link.
	The techniques that must be employed to use Fast Reroute for the		The techniques that must be employed to use Fast Reroute for the
	different methods of signaling LSPs identified in section 2 differ		different methods of signaling LSPs identified in section 2 differ
	considerably. These should be explained further in applicability		considerably. These should be explained further in applicability
	statements of, in the case, of a change in base behavior, in		statements of, in the case, of a change in base behavior, in
	implementation guidelines specific to the signaling techniques.		implementation guidelines specific to the signaling techniques.
	Note that after local repair has been performed, it may be desirable		Note that after local repair has been performed, it may be desirable
	to re-optimize the LSP (see section 5.1). If the point of		to re-optimize the LSP (see section 5.1). If the point of
	skipping to change at line 554		skipping to change at line 622
	considerably. These should be explained further in applicability		considerably. These should be explained further in applicability
	statements of, in the case, of a change in base behavior, in		statements of, in the case, of a change in base behavior, in
	implementation guidelines specific to the signaling techniques.		implementation guidelines specific to the signaling techniques.
	Note that after local repair has been performed, it may be desirable		Note that after local repair has been performed, it may be desirable
	to re-optimize the LSP (see section 5.1). If the point of		to re-optimize the LSP (see section 5.1). If the point of
	re-optimization (for example the ingress LSR) lies in a different		re-optimization (for example the ingress LSR) lies in a different
	domain to the failure, it may rely on the delivery of a PathErr or		domain to the failure, it may rely on the delivery of a PathErr or
	Notify message to inform it of the local repair event.		Notify message to inform it of the local repair event.
			It is important to note that Fast Reroute techniques are only
			applicable to packet switching networks because other network
			technologies cannot apply label stacking within the same switching
			type. Segment protection [SEG-PROT] provides a suitable alternative
			that is applicable to packet and non-packet networks.
	5.5. Comments on Path Diversity		5.5. Comments on Path Diversity
	Diverse paths may be required in support of load sharing and/or		Diverse paths may be required in support of load sharing and/or
	protection. Such diverse paths may be required to be node diverse,		protection. Such diverse paths may be required to be node diverse,
	link diverse, fully path diverse (that is, link and node diverse), or		link diverse, fully path diverse (that is, link and node diverse), or
	SRLG diverse.		SRLG diverse.
	Diverse path computation is a classic problem familiar to all graph		Diverse path computation is a classic problem familiar to all graph
	theory majors. The problem is compounded when there are areas of		theory majors. The problem is compounded when there are areas of
	'private knowledge' such as when domains do not share topology		'private knowledge' such as when domains do not share topology
	information. The problem is generally considered to be easier and		information. The problem is generally considered to be easier and
	more efficient when the diverse paths can be computed		more efficient when the diverse paths can be computed
	'simultaneously' on the fullest set of information. That being said,		'simultaneously' on the fullest set of information. That being said,
	various techniques (out of the scope of this document) exist to		various techniques (out of the scope of this document) exist to
	ensure end to end path diversity across multiple domains.		ensure end-to-end path diversity across multiple domains.
	Many network technologies utilize 'protection domains' because they		Many network technologies utilize 'protection domains' because they
	fit well with the capabilities of the technology. As a result, many		fit well with the capabilities of the technology. As a result, many
	domains are operated as protection domains. In this model, protection		domains are operated as protection domains. In this model, protection
	paths converge at domain boundaries.		paths converge at domain boundaries.
			Note that the question of SRLG identification is not yet fully
			answered. There are two classes of SRLG:
			- those that indicate resources that are all contained witin one
			domain
			- those that span domains.
			The former might be identified using a combination of domain ID and
			an SRLG ID that is administered by the domain. The latter requires
			a wider scope to the SRLG ID, and it is not clear how this would be
			administered.
	5.6. Domain-Specific Constraints		5.6. Domain-Specific Constraints
	While the meaning of certain constraints, like bandwidth, can be		While the meaning of certain constraints, like bandwidth, can be
	assumed to be constant across different domains, other TE constraints		assumed to be constant across different domains, other TE constraints
	(such as resource affinity, color, metric, priority, etc.) may have		(such as resource affinity, color, metric, priority, etc.) may have
	different meanings in different domains and this may impact the		different meanings in different domains and this may impact the
	ability to support DiffServ-aware MPLS, or to manage pre-emption.		ability to support DiffServ-aware MPLS, or to manage pre-emption.
	In order to achieve consistent meaning and LSP establishment, this		In order to achieve consistent meaning and LSP establishment, this
	fact must be considered when performing constraint-based path		fact must be considered when performing constraint-based path
	computation or when signaling across domain boundaries.		computation or when signaling across domain boundaries.
	A mapping function can be derived for most constraints based on		A mapping function can be derived for most constraints based on
	policy agreements between the Domain administrators.		policy agreements between the Domain administrators. The details of
			such a mapping function are outside the scope of this document, but
			it is important to note that the default behavior MUST either be
			that a constant mapping is applied or that any requirement to apply
			these constraints across a domain boundary must fail in the absence
			of explicit mapping rules.
	5.7. Policy Control		5.7. Policy Control
	Domain boundaries are natural points for policy control. There is		Domain boundaries are natural points for policy control. There is
	little to add on this subject except to note that a TE LSP that		little to add on this subject except to note that a TE LSP that
	cannot be established on a path through one domain because of a		cannot be established on a path through one domain because of a
	policy applied at the domain boundary, may be satisfactorily		policy applied at the domain boundary, may be satisfactorily
	established using a path that avoids the demurring domain. In any		established using a path that avoids the demurring domain. In any
	case, when a TE LSP signaling attempt is rejected due to non		case, when a TE LSP signaling attempt is rejected due to
	compliance with some policy constraint, this SHOULD be reflected to		non-compliance with some policy constraint, this SHOULD be reflected
	the ingress LSR.		to the ingress LSR.
	5.8. Inter-domain OAM		5.8. Inter-domain OAM
	Some elements of OAM may be intentionally confined within a domain.		Some elements of OAM may be intentionally confined within a domain.
	Others (such as end-to-end liveness and connectivity testing) clearly		Others (such as end-to-end liveness and connectivity testing) clearly
	need to span the entire multi-domain TE LSP. Where issues of		need to span the entire multi-domain TE LSP. Where issues of
	confidentiality are strong, collaboration between PCEs or domain		confidentiality are strong, collaboration between PCEs or domain
	boundary nodes might be required in order to provide end-to-end OAM.		boundary nodes might be required in order to provide end-to-end OAM.
	The different signaling mechanisms described above may need		The different signaling mechanisms described above may need
	refinements to [LSPPING], [BFD-MPLS] or the use of [TUNTRACE] to gain		refinements to [LSPPING], [BFD-MPLS] or the use of [TUNTRACE] to gain
	full end-to-end visibility. These protocols should, however, be		full end-to-end visibility. These protocols should, however, be
	considered in the light of confidentiality requirements.		considered in the light of confidentiality requirements.
	Route recording is a commonly used feature of signaling that provides		Route recording is a commonly used feature of signaling that provides
	OAM information about the path of an established LSP. When an LSP		OAM information about the path of an established LSP. When an LSP
	traverses a domain boundary, the border node may remove or aggregate		traverses a domain boundary, the border node may remove or aggregate
	some of the recorded information for confidentiality or other policy		some of the recorded information for confidentiality or other policy
	reasons.		reasons.
	5.9. Point to Multipoint		5.9. Point-to-Multipoint
	Inter-domain point-to-multipoint (P2MP) requirements are explicitly		Inter-domain point-to-multipoint (P2MP) requirements are explicitly
	out of scope of this document. They may be covered by other documents		out of scope of this document. They may be covered by other documents
	dependent on the details of MPLS TE P2MP solutions.		dependent on the details of MPLS TE P2MP solutions.
			5.10. Applicability to Non-Packet Technologies
			Non-packet switching technologies may present particular issues for
			inter-domain LSPs. While packet switching networks may utilize
			control planes built on MPLS or GMPLS technology, non-packet networks
			are limited to GMPLS.
			The specific architectural considerations and requirements for
			inter-domain LSP setup in non-packet networks are covered in a
			separate document [GMPLS-AS].
	6. Security Considerations		6. Security Considerations
	Requirements for security within domains are unchanged from [RFC3209]		Requirements for security within domains are unchanged from [RFC3209]
	and [RFC3473], but requirements for inter-domain security are, if		and [RFC3473], but requirements for inter-domain security are, if
	anything, more significant.		anything, more significant.
	Authentication techniques identified for use with RSVP-TE can only		Authentication techniques identified for use with RSVP-TE can only
	operate across domain boundaries if there is coordination between the		operate across domain boundaries if there is coordination between the
	administrators of those domains.		administrators of those domains.
	Confidentiality may also be considered to be security factors.		Confidentiality may also be considered to be security factors.
	Applicability statements for particular combinations of signaling,		Applicability statements for particular combinations of signaling,
	routing and path computation techniques are expected to contain		routing and path computation techniques are expected to contain
	detailed security sections.		detailed security sections.
	7. Acknowledgements		7. IANA Considerations
			This document makes no requests for any IANA action.
			8. Acknowledgements
	The authors would like to extend their warmest thanks to Kireeti		The authors would like to extend their warmest thanks to Kireeti
	Kompella for convincing them to expend efforts on this document.		Kompella for convincing them to expend effort on this document.
	Grateful thanks to Dimitri Papadimitriou and Tomohiro Otani for their		Grateful thanks to Dimitri Papadimitriou and Tomohiro Otani for their
	review and suggestions on the text.		review and suggestions on the text.
	8. Intellectual Property Considerations		9. Intellectual Property Considerations
	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.
	skipping to change at line 674		skipping to change at line 781
	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-ipr@ietf.org.		ietf-ipr@ietf.org.
	9. Normative References		10. Normative References
	[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.
	[RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels",		[RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels",
	RFC 3209, December 2001.		RFC 3209, December 2001.
	[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling - Resource ReserVation		Switching (GMPLS) Signaling - Resource ReserVation
	Protocol-Traffic Engineering (RSVP-TE) Extensions",		Protocol-Traffic Engineering (RSVP-TE) Extensions",
	RFC 3473, January 2003.		RFC 3473, January 2003.
	[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,		[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
	RFC 3667, February 2004.		RFC 3667, February 2004.
	[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF		[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
	Technology", BCP 79, RFC 3668, February 2004.		Technology", BCP 79, RFC 3668, February 2004.
	[HIER] Kompella K., Rekhter Y., "LSP Hierarchy with		[HIER] Kompella K., Rekhter Y., "LSP Hierarchy with
	Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.		Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,
	txt, March 2002 (work in progress).		work in progress.
	[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of		[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of
	Inter-Area and Inter-AS MPLS Traffic Engineering",		Inter-Area and Inter-AS MPLS Traffic Engineering",
	draft-ietf-tewg-interarea-mpls-te-req-02.txt, June 2004		draft-ietf-tewg-interarea-mpls-te-req, work in
	(work in progress).		progress.
	[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic		[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic
	Engineering requirements",		Engineering requirements",
	draft-ietf-tewg-interas-mpls-te-req-07.txt, June 2004		draft-ietf-tewg-interas-mpls-te-req, work in progress.
	(work in progress).
	10. Informational References		[STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with
			Generalized MPLS TE",
			draft-ayyangar-ccamp-lsp-stitching, work in progress.
			[PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path
			Computation Element (PCE) Architecture",
			draft-ash-pce-architecture, work in progress.
			11. Informational References
	[RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering		[RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
	Extensions to OSPF Version 2", RFC 3630, September 2003		Extensions to OSPF Version 2", RFC 3630, September 2003
	[RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic		[RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic
	Engineering", RFC 3784, June 2004.		Engineering", RFC 3784, June 2004.
	[ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of		[ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of
	Attributes for Multiprotocol Label Switching (MPLS)		Attributes for Multiprotocol Label Switching (MPLS)
	Label Switched Path (LSP) Establishment Using RSVP-TE",		Label Switched Path (LSP) Establishment Using RSVP-TE",
	draft-ietf-mpls-rsvpte-attributes-03.txt, March 2004		draft-ietf-mpls-rsvpte-attributes, work in progress.
	(work in progress).
	[BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", (work		[BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work
	in progress).		in progress.
	[CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for		[CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for
	MPLS Signaling", draft-ietf-ccamp-crankback-01.txt,		MPLS Signaling", draft-ietf-ccamp-crankback,
	January 2004 (work in progress).		work in progress.
	[EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE,		[EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE,
	draft-ietf-ccamp-rsvp-te-exclude-route-01.txt, December		draft-ietf-ccamp-rsvp-te-exclude-route, work in
	2003 (work in progress).		progress.
	[FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE		[FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
	for LSP Tunnels",		for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,
	draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt,		work in progress.
	(work in progress).
			[GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS
			Traffic Engineering Requirements",
			draft-otani-ccamp-interas-GMPLS-TE, work in progress.
	[LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness		[LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness
	in MPLS", Internet Draft		in MPLS", draft-ietf-mpls-lsp-ping, work in progress.
	draft-ietf-mpls-lsp-ping-05.txt, February 2004 (work in
	progress).
	[MRN] Papadimitriou, D., et al., "Generalized MPLS		[MRN] K. Shiomoto, et al., "Requirements for GMPLS-based
	Architecture for Multi-Region Networks",		multi-region and multi-layer networks",
	draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt,		draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress.
	February 2004 (work in progress).
	[OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay		[OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay
	Model", draft-ietf-ccamp-gmpls-overlay-04.txt, April		Model", draft-ietf-ccamp-gmpls-overlay, work in
	2004 (work in progress).		progress.
			[SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel,
			A., "GMPLS Based Segment Recovery",
			draft-ietf-ccamp-gmpls-segment-recovery, work in
			progress.
	[TUNTRACE] Bonica, R., et al., "Generic Tunnel Tracing Protocol		[TUNTRACE] Bonica, R., et al., "Generic Tunnel Tracing Protocol
	(GTTP) Specification", draft-ietf-ccamp-tunproto-00,		(GTTP) Specification", draft-ietf-ccamp-tunproto,
	March 2004 (work in progress).		work in progress.
	11. Authors' Addresses		12. Authors' Addresses
	Adrian Farrel		Adrian Farrel
	Old Dog Consulting		Old Dog Consulting
	EMail: adrian@olddog.co.uk		EMail: adrian@olddog.co.uk
	Jean-Philippe Vasseur		Jean-Philippe Vasseur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	300 Beaver Brook Road		300 Beaver Brook Road
	Boxborough , MA - 01719		Boxborough , MA - 01719
	USA		USA
	Email: jpv@cisco.com		Email: jpv@cisco.com
	Arthi Ayyangar		Arthi Ayyangar
	Juniper Networks, Inc		Juniper Networks, Inc
	1194 N.Mathilda Ave		1194 N.Mathilda Ave
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	USA		USA
	Email: arthi@juniper.net		Email: arthi@juniper.net
	12. Full Copyright Statement		13. Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		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 AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		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.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/