< draft-leroux-ccamp-gmpls-mrn-eval-01.txt		draft-leroux-ccamp-gmpls-mrn-eval-02.txt >
	Network Working Group J.L. Le Roux (France Telecom)		Network Working Group J.L. Le Roux (France Telecom)
	Internet Draft D. Brungard (AT&T)		Internet Draft D. Brungard (AT&T)
	Category: Informational E. Oki (NTT)		Category: Informational E. Oki (NTT)
	Expires: January 2006 D. Papadimitriou (Alcatel)		Expires: April 2006 D. Papadimitriou (Alcatel)
	K. Shiomoto (NTT)		K. Shiomoto (NTT)
	M. Vigoureux (Alcatel)		M. Vigoureux (Alcatel)
	July 2005		October 2005
	Evaluation of existing GMPLS Protocols against Multi Layer		Evaluation of existing GMPLS Protocols against Multi Layer
	and Multi Region Networks (MLN/MRN)		and Multi Region Networks (MLN/MRN)
	draft-leroux-ccamp-gmpls-mrn-eval-01.txt		draft-leroux-ccamp-gmpls-mrn-eval-02.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.
	This document is an Internet-Draft and is in full conformance with		Internet-Drafts are working documents of the Internet Engineering
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		Task Force (IETF), its areas, and its working groups. Note that other
	documents of the Internet Engineering Task Force (IETF), its areas,		groups may also distribute working documents as Internet-Drafts.
	and its working groups. Note that 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.
	Abstract		Abstract
	This document provides an evaluation of Generalized Multi-Protocol		This document provides an evaluation of Generalized Multi-Protocol
	Label Switching (GMPLS) protocols and mechanisms against the		Label Switching (GMPLS) protocols and mechanisms against the
	requirements for Multi-Layer Networks (MLN) and Multi Region Networks		requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
	(MRN). In addition, this document identifies areas where additional		(MRN). In addition, this document identifies areas where additional
	protocol extensions or procedures are needed to satisfy these		protocol extensions or procedures are needed to satisfy these
	requirements, and provides guidelines for potential extensions.		requirements, and provides guidelines for potential extensions.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119.		document are to be interpreted as described in RFC-2119.
	Table of Contents		Table of Contents
	1. Introduction................................................3		1. Terminology.................................................3
	2. MLN/MRN Requirements overview...............................4		2. Introduction................................................3
	3. Analysis....................................................4		3. MLN/MRN Requirements Overview...............................4
	3.1. Multi-layer aspects.........................................4		4. Analysis....................................................4
	3.1.1. Support for Virtual Network Topology Reconfiguration........4		4.1. Multi-Layer Aspects.........................................4
	3.1.1.1. Control of Forwarding Adjacencies (FA) setup/release......4		4.1.1. Support for Virtual Network Topology Reconfiguration........4
	3.1.1.2. Virtual TE-link...........................................6		4.1.1.1. Control of FA-LSPs Setup/Release..........................5
	3.1.1.3. Traffic Disruption minimization during FA release.........7		4.1.1.2. Virtual TE-Links..........................................6
	3.1.1.4. Stability.................................................7		4.1.1.3. Traffic Disruption Minimization During FA Release.........7
	3.1.2. Support for FA LSP attributes inheritance...................7		4.1.1.4. Stability.................................................7
	3.1.3. Support for Triggered signaling.............................7		4.1.2. Support for FA-LSP Attributes Inheritance...................7
	3.1.4. FA connectivity verification................................8		4.1.3. Support for Triggered Signaling.............................8
	3.2. Multi-Region specific aspects...............................8		4.1.4. FA Connectivity Verification................................8
	3.2.1. Support for Multi-region signaling..........................8		4.2. Multi-Region Specific Aspects...............................8
	3.2.2. Advertisement of Internal Adaptation Capabilities...........9		4.2.1. Support for Multi-Region Signaling..........................8
	4. Evaluation Conclusion......................................10		4.2.2. Advertisement of Internal Adaptation Capabilities...........9
	5. Security considerations....................................10		5. Evaluation Conclusion......................................12
	6. Acknowledgments............................................10		6. Security Considerations....................................12
	7. References.................................................10		7. Acknowledgments............................................12
	8. Authors' Addresses:........................................11		8. References.................................................13
	9. Intellectual Property Statement............................12		8.1. Normative..................................................13
			8.2. Informative................................................13
			9. Authors' Addresses:........................................13
			10. Intellectual Property Statement............................14
	1. Introduction		1. Terminology
			This document uses terminologies defined in [RFC3945], [HIER], and
			[MRN-REQ].
			2. Introduction
	Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to		Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to
	handle multiple switching technologies: packet switching, layer-two		handle multiple switching technologies: packet switching (PSC),
	switching, TDM switching, wavelength switching and fiber switching		layer-two switching (L2SC), TDM switching (TDM), wavelength switching
	(see [RFC 3945]).		(LSC) and fiber switching (FSC) (see [RFC 3945]).
	A data plane layer is a collection of network resources capable of		A data plane layer is a collection of network resources capable of
	terminating and/or switching data traffic of a particular format. For		terminating and/or switching data traffic of a particular format. For
	example, LSC, TDM VC-11 and TDM VC-4-64c represent three different		example, LSC, TDM VC-11 and TDM VC-4-64c represent three different
	layers. A network comprising transport nodes with different data		layers. A network comprising transport nodes with different data
	plane switching layers controlled by a single GMPLS control plane		plane switching layers controlled by a single GMPLS control plane
	instance is called a Multi-Layer Network (MLN).		instance is called a Multi-Layer Network (MLN).
	A GMPLS switching type (PSC, TDM, etc.) describes the ability of a		A GMPLS switching type (PSC, TDM, etc.) describes the ability of a
	node to forward data of a particular data plane technology, and		node to forward data of a particular data plane technology, and
	uniquely identifies a control plane region. The notion of LSP Region		uniquely identifies a control plane region. The notion of LSP Region
	is defined in [HIER]. A MLN comprising of multiple switching types		is defined in [HIER]. A network comprised of multiple switching types
	(e.g. PSC and TDM) is called a Multi-Region Network (MRN).		(e.g. PSC and TDM) controlled by a single GMPLS control plane
			instance is called a Multi-Region Network (MRN).
	Note that the region is a control plane only concept. That is, layers		Note that the region is a control plane only concept. That is, layers
	of the same region share the same switching technology and,		of the same region share the same switching technology and,
	therefore, need the same set of technology specific signaling		therefore, need the same set of technology specific signaling
	objects.		objects.
	Note that a MRN is necessarily a MLN, but not vice versa, as a MLN		Note that a MRN is necessarily a MLN, but not vice versa, as a MLN
	may consist of a single region (control of multiple data plane layers		may consist of a single region (control of multiple data plane layers
	within a region). Hence, in the following, we use the term layer if		within a region). Hence, in the following, we use the term layer if
	the mechanism discussed applies equally to layers and regions (e.g.		the mechanism discussed applies equally to layers and regions (e.g.
	VNT, virtual TE-link, etc.), and we specifically use the term region		VNT, virtual TE-link, etc.), and we specifically use the term region
	if the mechanism applies only for supporting a MRN.		if the mechanism applies only for supporting a MRN.
	The objectives of this document are to evaluate existing GMPLS		The objectives of this document are to evaluate existing GMPLS
	mechanisms and protocols ([RFC 3945], [GMPLS-RTG], [GMPLS-SIG])		mechanisms and protocols ([RFC 3945], [GMPLS-RTG], [GMPLS-SIG])
	against the requirements for MLN and MRN, defined in [MRN-REQ]. From		against the requirements for MLN and MRN, defined in [MRN-REQ]. From
	this evaluation, we identify several areas where additional protocol		this evaluation, we identify several areas where additional protocol
	extensions and modifications are required to meet these requirements,		extensions and modifications are required to meet these requirements,
	and provide guidelines for potential extensions.		and provide guidelines for potential extensions.
	Section 2 provides an overview of MLN/MRN requirements.		Section 3 provides an overview of MLN/MRN requirements.
	Section 3 evaluates for each of these requirements, whether current		Section 4 evaluates for each of these requirements, whether current
	GMPLS protocols and mechanisms allow addressing the requirements.		GMPLS protocols and mechanisms allow addressing the requirements.
	When the requirements are not met, the document identifies whether		When the requirements are not met, the document identifies whether
	the required mechanisms could rely on GMPLS protocols and procedure		the required mechanisms could rely on GMPLS protocols and procedure
	extensions or if it is entirely out of the scope of GMPLS protocols.		extensions or if it is entirely out of the scope of GMPLS protocols.
	Note that this document specifically addresses GMPLS control plane		Note that this document specifically addresses GMPLS control plane
	functionality for MLN/MRN in the context of a single administrative		functionality for MLN/MRN in the context of a single administrative
	control plane partition.		control plane partition.
	2. MLN/MRN Requirements overview		3. MLN/MRN Requirements Overview
	[MRN-REQ] lists a set of functional requirements for Multi		[MRN-REQ] lists a set of functional requirements for Multi
	Layer/Region Networks (MLN/MRN). These requirements are summarized		Layer/Region Networks (MLN/MRN). These requirements are summarized
	below:		below:
	-Support of robust Virtual Network Topology reconfiguration.		- Support of robust Virtual Network Topology (VNT)
	This implies the following requirements:		reconfiguration. This implies the following requirements:
	-Optimal control of Forwarding Adjacencies (FA) setup		- Optimal control of FA-LSP setup
	and release;		and release;
	-Support for virtual TE-links;		- Support for virtual TE-links;
	-Traffic Disruption minimization during FA release (e.g.		- Traffic Disruption minimization during FA-LSP release
	network reconfiguration events);		(e.g. network reconfiguration events);
	-Stability		- Stability
	-Support for FA LSP attributes inheritance;		- Support for FA-LSP attributes inheritance;
	-Support for Triggered Signaling;		- Support for Triggered Signaling;
	-Support for FA data plane connectivity verification;		- Support for FA data plane connectivity verification;
	-Support for Multi-region signaling;		- Support for Multi-region signaling;
	-Advertisement of the adaptation capabilities and resources;		- Advertisement of the adaptation capabilities and resources.
	3. Analysis		4. Analysis
	3.1. Multi-layer aspects		4.1. Multi-Layer Aspects
	3.1.1. Support for Virtual Network Topology Reconfiguration		4.1.1. Support for Virtual Network Topology Reconfiguration
	A set of lower-layer FAs provides a Virtual Network Topology (VNT) to		A set of lower-layer FA-LSPs provides a Virtual Network Topology
	the upper-layer. By reconfiguring the VNT (FA-LSP setup/release)		(VNT) to the upper-layer. By reconfiguring the VNT (FA-LSP
	according to traffic demands between source and destination node		setup/release) according to traffic demands between source and
	pairs of a layer, network performance factors such as maximum link		destination node pairs of a layer, network performance factors such
	utilization and residual capacity of the network can be optimized.		as maximum link utilization and residual capacity of the network can
	Such optimal VNT reconfiguration implies several mechanisms that are		be optimized. Such optimal VNT reconfiguration implies several
	analyzed in the following sections.		mechanisms that are analyzed in the following sections.
	Note that the VNT approach is just one approach among others, to		Note that the VNT approach is just one approach among others, to
	perform inter-layer Traffic Engineering.		perform inter-layer Traffic Engineering.
	3.1.1.1. Control of Forwarding Adjacencies (FA) setup/release		4.1.1.1. Control of FA-LSPs Setup/Release
	In a multi-layer network, FAs are created, modified, released		In a Multi-Layer Network, FA-LSPs are created, modified, released
	periodically according to the change of incoming traffic demands from		periodically according to the change of incoming traffic demands from
	the upper layer.		the upper layer.
	This implies a TE mechanism that takes into account the demands		This implies a TE mechanism that takes into account the demands
	matrix, the TE topology and potentially the current VNT in order to		matrix, the TE topology and potentially the current VNT, in order to
	compute a new VNT.		compute a new VNT.
	Several building blocks are required to support such TE mechanism:		Several building blocks are required to support such TE mechanism:
	- Discovery of TE topology and available resources;		- Discovery of TE topology and available resources;
	- Collection of traffic demands of the upper layer;		- Collection of traffic demands of the upper layer;
	- VNT engine, ensuring VNT computation and reconfiguration		- VNT engine, ensuring VNT computation and reconfiguration
	according to upper layer traffic demands and TE topology		according to upper layer traffic demands and TE topology
	(and potentially old VNT);		(and potentially old VNT);
	- FA setup/release;		- FA-LSP setup/release;
	GMPLS routing protocols support TE topology discovery and		GMPLS routing protocols support TE topology discovery and
	GMPLS signaling protocols allow setting up/releasing FAs.		GMPLS signaling protocols allow setting up/releasing FA-LSPs.
	VNT computation and reconfiguration is out of the scope of GMPLS		VNT computation and reconfiguration is out of the scope of GMPLS
	protocols. Such functionality can be achieved directly on layer		protocols. Such functionality can be achieved directly on layer
	border LSRs, or one or more external tools, as for instance Path		border LSRs, or one or more external tools, as for instance Path
	Computation Elements (PCE) (see [PCE-ARCH]).		Computation Elements (PCE) (see [PCE-ARCH]).
	The set of traffic demands of the upper layer is required to		The set of traffic demands of the upper layer is required to
	recompute and re-optimize the VNT. This functionality must have		recompute and re-optimize the VNT. This requires knowledge of the
	knowledge of the aggregated bandwidth reserved by upper layer LSPs		aggregated bandwidth reserved by upper layer LSPs established between
	established between any pair of border LSRs.		any pair of border LSRs.
	Existing GMPLS routing allows for the collection of traffic demands		Existing GMPLS routing allows for the collection of traffic demands
	of the upper region. It can be deduced from FA TE-link		of the upper region. It can be deduced from FA TE-link
	advertisements.		advertisements.
	The set of traffic demands can be inferred:		The set of traffic demands can be inferred:
	- either directly, based on upper-layer FA TE-link		- either directly, based on upper-layer FA TE-link
	advertisements. The traffic demands between two points		advertisements. The traffic demands between two points
	correspond to the cumulated bandwidth reserved by upper-layer		correspond to the cumulated bandwidth reserved by upper-layer
	LSPs between these two points;		LSPs between these two points;
	- or indirectly, based on lower-layer FA TE-link		- or indirectly, based on lower-layer FA TE-link
	advertisements. In this case a mechanism to infer the upper-		advertisements. In this case a mechanism to infer the upper-
	skipping to change at page 5, line 50 ¶		skipping to change at page 6, line 6 ¶
	Collection of traffic demands of an upper region may actually be		Collection of traffic demands of an upper region may actually be
	achieved in several ways depending on the location of VNT engines:		achieved in several ways depending on the location of VNT engines:
	- If a VNT engine is distributed on border region LSRs, then the		- If a VNT engine is distributed on border region LSRs, then the
	collection of traffic demands would rely on existing GMPLS		collection of traffic demands would rely on existing GMPLS
	routing, as per described above;		routing, as per described above;
	- If a VNT engine is located on an external tool (e.g. a PCE)		- If a VNT engine is located on an external tool (e.g. a PCE)
	then the collection of traffic demands may be achieved using		then the collection of traffic demands may be achieved using
	existing GMPLS routing, provided that the tool relies on GMPLS		existing GMPLS routing, provided that the tool relies on GMPLS
	routing to discover TE link information, or it may rely on		routing to discover TE link information, or it may rely on
	another mechanism out of the scope of GMPLS protocols (e.g.		another mechanism out of the scope of GMPLS protocols (e.g.
	SNMP, PCC-PCE communication protocolà).		SNMP, PCC-PCE communication protocol…).
	3.1.1.2. Virtual TE-link		4.1.1.2. Virtual TE-Links
	A virtual TE-link is a TE-link between two nodes, not actually		A Virtual TE-link is a TE-link between two nodes, not actually
	associated to a fully provisioned FA-LSP. A virtual TE-link		associated to a fully provisioned FA-LSP. A Virtual TE-link
	represents the potentiality to setup a FA-LSP. There is no IGP		represents the potentiality to setup a FA-LSP. There is no IGP
	adjacency associated to a virtual TE-link. A virtual TE-link is		adjacency associated to a Virtual TE-link. A Virtual TE-link is
	advertised as any classical TE-link, i.e. following the rules in		advertised as any classical TE-link, i.e. following the rules in
	[HIER] defined for fully provisioned TE-links. Particularly, the		[HIER] defined for fully provisioned TE-links. Particularly, the
	flooding scope of a virtual TE link is within an IGP area, as any TE-		flooding scope of a Virtual TE-link is within an IGP area, as any TE-
	link.		link.
	During its signalling, if an upper-layer LSP makes use of a virtual		During its signaling, if an upper-layer LSP makes use of a Virtual
	TE-link, the underlying FA-LSP is immediately signalled and		TE-link, the underlying FA-LSP is immediately signaled and
	provisioned.		provisioned.
	The use of virtual TE-links has two main advantages:		The use of Virtual TE-links has two main advantages:
	- flexibility: allows to compute a LSP path using TE links and this		- flexibility: allows to compute a LSP path using TE-links and this
	without taking into account the actual status of the		without taking into account the actual status of the
	corresponding FA-LSP in the lower layer in terms of provisioning;		corresponding FA-LSP in the lower layer in terms of provisioning;
	- stability: allows stability of TE-links, while		- stability: allows stability of TE-links, while
	avoiding wastage of bandwidth in the lower layer, as data		avoiding wastage of bandwidth in the lower layer, as data
	plane connections are not established.		plane connections are not established.
	Note also that it avoids state maintenance but is susceptible to		Note also that it avoids state maintenance but is susceptible to
	create contention if no adequate/consistent admission control is put		create contention if no adequate/consistent admission control is put
	in place.		in place.
	Virtual TE-links are setup/deleted/modified dynamically, according to		Virtual TE-links are setup/deleted/modified dynamically, according to
	the change of the (forecast) traffic demand, operator's policies for		the change of the (forecast) traffic demand, operator's policies for
	capacity utilization, and the available resources in the lower layer.		capacity utilization, and the available resources in the lower layer.
	The support of Virtual TE-links requires two main building blocks:		The support of Virtual TE-links requires two main building blocks:
	-A TE mechanism for dynamic modification of virtual TE-link		- A TE mechanism for dynamic modification of Virtual TE-link
	Topology;		Topology;
	-A signaling mechanism for the dynamic setup and deletion of		- A signaling mechanism for the dynamic setup and deletion of
	virtual TE-links. Setting up a virtual TE-link		virtual TE-links. Setting up a virtual TE-link
	requires a signalling mechanism allowing an end-to-end		requires a signaling mechanism allowing an end-to-end
	association between virtual TE-link end points so as to		association between Virtual TE-link end points so as to
	exchange link identifiers as well as some TE parameters.		exchange link identifiers as well as some TE parameters.
	The TE mechanism responsible for triggering/policing dynamic		The TE mechanism responsible for triggering/policing dynamic
	modification of virtual TE-links is out of the scope of GMPLS		modification of Virtual TE-links is out of the scope of GMPLS
	protocols.		protocols.
	Current GMPLS signalling does not allow setting up and releasing		Current GMPLS signaling does not allow setting up and releasing
	virtual TE-links. Hence GMPLS signalling must be extended to support		Virtual TE-links. Hence GMPLS signaling must be extended to support
	virtual TE-links. The association between virtual TE-link end-points		Virtual TE-links. The association between Virtual TE-link end-points
	may rely on extensions to the RSVP-TE ASON Call procedure ([GMPLS-		may rely on extensions to the RSVP-TE ASON Call procedure ([GMPLS-
	ASON]).		ASON]).
	Note that the support of virtual TE-link does not require any GMPLS		Note that the support of Virtual TE-link does not require any GMPLS
	routing extension.		routing extension.
	3.1.1.3. Traffic Disruption minimization during FA release		4.1.1.3. Traffic Disruption Minimization During FA-LSP Release
	Before deleting a given FA-LSP, all nested LSPs have to be rerouted		Before deleting a given FA-LSP, all nested LSPs have to be rerouted
	and removed from the FA-LSP to avoid traffic disruption.		and removed from the FA-LSP to avoid traffic disruption.
	The mechanisms required here are similar to those required for		The mechanisms required here are similar to those required for
	graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism		graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism
	allows for the deletion of a TE-link without disrupting traffic of		allows for the deletion of a TE-link without disrupting traffic of
	TE-LSPs that where using the TE-link.		TE-LSPs that where using the TE-link.
	GMPLS protocols do not provide for explicit indication to trigger		GMPLS protocols do not provide for explicit indication to trigger
	such operation.		such operation.
	Hence, GMPLS routing and/or signaling extensions are required		Hence, GMPLS routing and/or signaling extensions are required
	to support graceful deletion of TE-links. This may rely, for		to support graceful deletion of TE-links. This may rely, for
	instance, on new signaling Error code to notify head-end LSRs that a		instance, on new signaling Error code to notify head-end LSRs that a
	TE-link along the path of a LSP is going to disappear, and also on		TE-link along the path of a LSP is going to disappear, and also on
	new routing attributes (if limited to a single IGP area), such as		new routing attributes (if limited to a single IGP area), such as
	defined in [GR-SHUT].		defined in [GR-SHUT].
	3.1.1.4. Stability		4.1.1.4. Stability
	The upper-layer LSP stability may be impaired if the VNT undergoes		The upper-layer LSP stability may be impaired if the VNT undergoes
	frequent changes. In this context robustness of the VNT is defined as		frequent changes. In this context robustness of the VNT is defined as
	the capability to smooth impact of these changes and avoid their		the capability to smooth impact of these changes and avoid their
	subsequent propagation.		subsequent propagation.
	Guaranteeing VNT stability is out of the scope of GMPLS protocols and		Guaranteeing VNT stability is out of the scope of GMPLS protocols and
	relies entirely on the capability of TE algorithms to minimize		relies entirely on the capability of TE algorithms to minimize
	routing perturbations. This requires that the TE algorithm takes into		routing perturbations. This requires that the TE algorithm takes into
	account the old VNT when computing a new VNT, and tries to minimize		account the old VNT when computing a new VNT, and tries to minimize
	the perturbation.		the perturbation.
	3.1.2. Support for FA LSP attributes inheritance		4.1.2. Support for FA-LSP Attributes Inheritance
	When FA TE-link parameters are inherited from FA-LSP parameters,		When FA TE-link parameters are inherited from FA-LSP parameters,
	specific inheritance rules are applied.		specific inheritance rules are applied.
	This relies on local procedures and policies and is out of the scope		This relies on local procedures and policies and is out of the scope
	of GMPLS protocols.		of GMPLS protocols.
	Note that this requires that both head and tail-ends of the FA-LSP		Note that this requires that both head-end and tail-end of the FA-LSP
	are driven by same policies.		are driven by same policies.
	3.1.3. Support for Triggered signaling.		4.1.3. Support for Triggered Signaling.
	When a LSP crosses the boundary from an upper to a lower layer, it		When a LSP crosses the boundary from an upper to a lower layer, it
	may be nested in or stitched to a lower-layer LSP. If such an LSP		may be nested in or stitched to a lower-layer LSP. If such an LSP
	does not exist the LSP may be established dynamically. Such a		does not exist the LSP may be established dynamically. Such a
	mechanism is referred to as "Triggered signaling".		mechanism is referred to as "Triggered signaling".
	Triggered signaling requires the following building blocks:		Triggered signaling requires the following building blocks:
	-The identification of layer boundaries.		- The identification of layer boundaries.
	-A path computation engine capable of computing a path		- A path computation engine capable of computing a path
	containing multiple layers.		containing multiple layers.
	-A mechanism for nested signaling.		- A mechanism for nested signaling.
	The identification of layer boundaries is supported by GMPLS routing		The identification of layer boundaries is supported by GMPLS routing
	protocols. The identification of layer boundaries is performed using		protocols. The identification of layer boundaries is performed using
	the interface switching capability descriptor associated to the TE-		the interface switching capability descriptor associated to the TE-
	link (see [HIER] and [GMPLS-RTG]).		link (see [HIER] and [GMPLS-RTG]).
	The capability to compute a path containing multiple layers is a		The capability to compute a path containing multiple layers is a
	local implementation issue and is out of the scope of GMPLS protocols.		local implementation issue and is out of the scope of GMPLS protocols.
	A mechanism for nested signaling is defined in [HIER].		A mechanism for nested signaling is defined in [HIER].
	Hence, GMPLS protocols already meet this requirement.		Hence, GMPLS protocols already meet this requirement.
	3.1.4. FA connectivity verification		4.1.4. FA Connectivity Verification
	Once fully provisioned, FA liveliness may be achieved by verifying		Once fully provisioned, FA liveliness may be achieved by verifying
	its data plane connectivity.		its data plane connectivity.
	FA connectivity verification relies on technology specific mechanisms		FA connectivity verification relies on technology specific mechanisms
	(e.g. for SDH, G.707, G.783, for MPLS, BFD, etc.) as for any other		(e.g. for SDH, G.707, G.783, for MPLS, BFD, etc.) as for any other
	LSP. Hence this requirement is out of the scope of GMPLS protocols.		LSP. Hence this requirement is out of the scope of GMPLS protocols.
	Note that the time to establish the FA-LSP must be minimized.		Note that the time to establish the FA-LSP must be minimized.
	3.2. Multi-Region specific aspects		4.2. Multi-Region Specific Aspects
	3.2.1. Support for Multi-region signaling		4.2.1. Support for Multi-Region Signaling
	Applying the triggered signaling procedure discussed above, in a MRN		Applying the triggered signaling procedure discussed above, in a MRN
	environment may lead to setup of one-hop FA-LSPs between each node.		environment may lead to the setup of one-hop FA-LSPs between each
	Therefore, considering that the path computation is able to take into		node. Therefore, considering that the path computation is able to
	account richness of information with regard to the Switching		take into account richness of information with regard to the
	Capability (SC) available on given nodes belonging to the path, it is		Switching Capability (SC) available on given nodes belonging to the
	consistent to provide enough signaling information to indicate the SC		path, it is consistent to provide enough signaling information to
	to be used and on over which link.		indicate the SC to be used and on over which link.
	Limited extension to existing GMPLS signaling procedures is required		Limited extension to existing GMPLS signaling procedures is required
	for this purpose as it only mandates indication of the SCs to be		for this purpose as it only mandates indication of the SCs to be
	included or excluded before initiating the LSP provisioning procedure.		included or excluded before initiating the LSP provisioning procedure.
	This enhancement would solve the ambiguous choice of SC that are		This enhancement would solve the ambiguous choice of SC that are
	potentially used along a given path, particularly in case of ERO		potentially used along a given path, particularly in case of ERO
	expansion, or when an ERO sub-object identifies a multi-SC TE link.		expansion, or when an ERO sub-object identifies a multi-SC TE-link.
	This would give the possibility to optimize resource usage on a		This would give the possibility to optimize resource usage on a
	multi-region basis.		multi-region basis.
	3.2.2. Advertisement of Internal Adaptation Capabilities		4.2.2. Advertisement of Internal Adaptation Capabilities
	In the MRN context, nodes supporting more than one switching		In the MRN context, nodes supporting more than one switching
	capability on at least one interface are called Hybrid nodes. Hybrid		capability on at least one interface are called Hybrid nodes. Hybrid
	nodes contain at least two distinct switching elements that are		nodes contain at least two distinct switching elements that are
	interconnected by internal links, to provide adaptation between the		interconnected by internal links to provide adaptation between the
	supported switching capabilities.		supported switching capabilities.
	These internal links have finite capacities and must be taken into		These internal links have finite capacities and must be taken into
	account when computing the path of a multi-region TE-LSP.		account when computing the path of a multi-region TE-LSP.
	The advertisement of the internal adaptation capability is required		The advertisement of the internal adaptation capability is required
	as it provides critical information when performing multi-region path		as it provides critical information when performing multi-region path
	computation.		computation.
	The advertisement of the internal adaptation capability, using		Figure 1a below shows an example of hybrid node. The hybrid node has
	existing GMPLS routing, would require dividing a hybrid node, in the		two switching elements (matrices), which support here TDM and PSC
	routing plane, in several logical nodes, and advertising internal		switching respectively. The node terminates two PSC and TDM ports
	adaptation capabilities as TE-links between logical nodes. Of course		(port1 and port2 respectively). It also has internal link connecting
	such approach must be avoided as it leads to the introduction of		the two switching elements.
	internal node states.		The two switching elements are internally interconnected in such a
			way that it is possible to terminate some of the resources of the TDM
			port 2 and provide through them adaptation for PSC traffic,
			received/sent over the internal PSC interface (#b). Two ways are
			possible to set up PSC LSPs (port 1 or port 2). Available resources
			advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover
			both ways.
			Network element
			.............................
			: -------- :
			PSC : | PSC | :
			Port1-------------<->--|#a | :
			: +--<->---|#b | :
			: | -------- :
			TDM : | ---------- :
			+PSC : +--<->--|#c TDM | :
			Port2 ------------<->--|#d | :
			: ---------- :
			:............................
			Figure 1a. Hybrid node.
			Port 1 and Port 2 can be grouped together thanks to internal DWDM, to
			result in a single interface: Link 1. This is illustrated in figure
			1b below.
			Network element
			.............................
			: -------- :
			: | PSC | :
			: | | :
			: --|#a | :
			: | | #b | :
			: | -------- :
			: | | :
			: | ---------- :
			: /| | | #c | :
			: | |-- | | :
			Link1 ========| | | TDM | :
			: | |----|#d | :
			: \| ---------- :
			:............................
			Figure 1b. Hybrid node.
			Let's assume that all interfaces are STM16 (with VC4-16c capable
			as Max LSP bandwidth). After, setting up several PSC LSPs via port #a
			and setting up and terminating several TDM LSPs via port #d and port
			#b, there is only 155 Mb capacities still available on port #b.
			However a 622 Mb capacity remains on port #a and VC4-5c capacity on
			port #d.
			When computing the path for a new VC4-4c TDM LSP, one must know, that
			this node cannot terminate this LSP, as there is only 155Mb still
			available for TDM-PSC adaptation. Hence the internal TDM-PSC
			adaptation capability must be advertised.
			With current GMPLS routing [GMPLS-RTG] this advertisement is possible
			if link bundling is not used and if two TE-links are advertised for
			link1:
			We would have the following TE-link advertisements:
			TE-link 1 (port 1):
			- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
			unreserved bandwidth = vc4-5c.
			- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,
			unreserved bandwidth = 155 Mb.
			TE-Link 2 (port 2):
			- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb, unreserved
			bandwidth = 622Mb.
			The ISCD 2 in TE-link 1 represents actually the internal TDM-PSC
			adaptation capability.
			However if for obvious scalability reasons link bundling is done then
			the adaptation capability information is lost with current GMPLS
			routing, as we have the following TE-link advertisement:
			TE-link 1 (port 1 + port 2):
			- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
			unreserved bandwidth = vc4-5c.
			- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,
			unreserved bandwidth = 777 Mb.
			With such TE-link advertisement an element computing the path of a
			VC4-4C LSP cannot know that this LSP cannot be terminated on the
			node.
			Thus current GMPLS routing can support the advertisement of the
			internal adaptation capability but this precludes performing link
			bundling and thus faces significant scalability limitations.
	Hence, GMPLS routing must be extended to meet this requirement. This		Hence, GMPLS routing must be extended to meet this requirement. This
	could rely on the advertisement of the internal adaptation		could rely on the advertisement of the internal adaptation
	capabilities as a new TE link attribute (that would complement the		capabilities as a new TE link attribute (that would complement the
	Interface Switching Capability Descriptor TE link attribute).		Interface Switching Capability Descriptor TE-link attribute).
	4. Evaluation Conclusion		5. Evaluation Conclusion
	Most of MLN/MRN requirements will rely on mechanisms and procedures		Most of MLN/MRN requirements will rely on mechanisms and procedures
	that are out of the scope of the GMPLS protocols, and thus do not		that are out of the scope of the GMPLS protocols, and thus do not
	require any GMPLS protocol extensions. They will rely on local		require any GMPLS protocol extensions. They will rely on local
	procedures and policies, and on specific TE mechanisms and		procedures and policies, and on specific TE mechanisms and
	algorithms.		algorithms.
	As regards Virtual Network Topology (VNT) computation and		As regards Virtual Network Topology (VNT) computation and
	reconfiguration, specific TE mechanisms that could, for instance,		reconfiguration, specific TE mechanisms that could for instance rely
	rely on PCE based mechanisms and protocols need to be defined, but		on PCE based mechanisms and protocols, need to be defined, but these
	these mechanisms are out of the scope of GMPLS protocols		mechanisms are out of the scope of GMPLS protocols.
	Four areas for extensions of GMPLS protocols and procedures have been		Four areas for extensions of GMPLS protocols and procedures have been
	identified:		identified:
	- GMPLS signaling extension for the setup/deletion of		- GMPLS signaling extension for the setup/deletion of
	the virtual TE links (as well as exact trigger for its actual		the virtual TE-links (as well as exact trigger for its actual
	provisioning);		provisioning);
	- GMPLS routing and signaling extension for graceful TE link		- GMPLS routing and signaling extension for graceful TE-link
	deletion;		deletion;
	- GMPLS signalling extension for constrained multi-region		- GMPLS signaling extension for constrained multi-region
	signalling (SC inclusion/exclusion);		signaling (SC inclusion/exclusion);
	- GMPLS routing extension for the advertisement of the		- GMPLS routing extension for the advertisement of the
	internal adaptation capability of hybrid nodes.		internal adaptation capability of hybrid nodes.
	5. Security considerations		6. Security Considerations
	This document specifically addresses GMPLS control plane		This document specifically addresses GMPLS control plane
	functionality for MLN/MRN in the context of a single administrative		functionality for MLN/MRN in the context of a single administrative
	control plane partition and hence does not introduce additional		control plane partition and hence does not introduce additional
	security threats beyond those described in [RFC3945].		security threats beyond those described in [RFC3945].
	6. Acknowledgments		7. Acknowledgments
	We would like to thank Julien Meuric and Igor Bryskin for their		We would like to thank Julien Meuric and Igor Bryskin for their
	useful comments.		useful comments.
	7. References		8. References
			8.1. Normative
	[RFC3979] Bradner, S., "Intellectual Property Rights in IETF		[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
	Technology", BCP 79, RFC 3979, March 2005.		Technology", BCP 79, RFC 3979, March 2005.
	[RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label		[RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label
	Switching Architecture", RFC 3945, October 2004		Switching Architecture", RFC 3945, October 2004
	[GMPLS-RTG] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing		[GMPLS-RTG] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
	Extensions in Support of Generalized Multi-Protocol Label Switching",		Extensions in Support of Generalized Multi-Protocol Label Switching",
	draft-ietf-ccamp-gmpls-routing, work in Progress.		draft-ietf-ccamp-gmpls-routing, work in Progress.
	[GMPLS-SIG] Berger, L., et. al. "Generalized Multi-Protocol Label		[GMPLS-SIG] Berger, L., et. al. "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Functional Description", RFC 3471,		Switching (GMPLS) Signaling Functional Description", RFC 3471,
	January 2003.		January 2003.
			8.2. Informative
	[GMPLS-ASON] Papadimitriou, D., et. al., " Generalized MPLS (GMPLS)		[GMPLS-ASON] Papadimitriou, D., et. al., " Generalized MPLS (GMPLS)
	RSVP-TE Signalling in support of Automatically Switched Optical		RSVP-TE Signaling in support of Automatically Switched Optical
	Network (ASON)", draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progess.		Network (ASON)", draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progess.
	[MRN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,		[MRN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,
	M., Brungard, D., "Requirements for GMPLS-based multi-region and		M., Brungard, D., "Requirements for GMPLS-based multi-region and
	multi-layer networks", draft-shiomoto-ccamp-gmpls-mrn-reqs, work in		multi-layer networks", draft-shiomoto-ccamp-gmpls-mrn-reqs, work in
	progess.		progess.
	[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation		[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
	Element (PCE) Architecture", draft-ietf-pce-architecture, work in		Element (PCE) Architecture", draft-ietf-pce-architecture, work in
	progress.		progress.
	[GTEP] Oki, E., et. al., "Generalized Traffic Engineering Protocol",		[GTEP] Oki, E., et. al., "Generalized Traffic Engineering Protocol",
	draft-oki-pce-gtep, work in progress.		draft-oki-pce-gtep, work in progress.
	[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized		[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized
	MPLS TE", draft-ietf-mpls-lsp-hierarchy-08, work in progress.		MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in progress.
	[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic		[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic
	Engineering Network", draft-ali-ccamp-mpls-graceful-shutdown, work in		Engineering Network", draft-ali-ccamp-mpls-graceful-shutdown, work in
	progress.		progress.
	8. Authors' Addresses:		9. Authors' Addresses:
	Jean-Louis Le Roux		Jean-Louis Le Roux
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex, France		22307 Lannion Cedex, France
	Email: jeanlouis.leroux@francetelecom.com		Email: jeanlouis.leroux@francetelecom.com
	Deborah Brungard		Deborah Brungard
	AT&T		AT&T
	Rm. D1-3C22 - 200 S. Laurel Ave.		Rm. D1-3C22 - 200 S. Laurel Ave.
	Middletown, NJ, 07748 USA		Middletown, NJ, 07748 USA
	E-mail: dbrungard@att.com		E-mail: dbrungard@att.com
	Eiji Oki		Eiji Oki
	NTT		NTT
	3-9-11 Midori-Cho		3-9-11 Midori-Cho
	Musashino, Tokyo 180-8585, Japan		Musashino, Tokyo 180-8585, Japan
	Email: oki.eiji@lab.ntt.co.jp		Email: oki.eiji@lab.ntt.co.jp
	Dimitri Papadimitriou		Dimitri Papadimitriou
	Alcatel		Alcatel
	Francis Wellensplein 1,		Francis Wellensplein 1,
	B-2018 Antwerpen, Belgium		B-2018 Antwerpen, Belgium
	Email: dimitri.papdimitriou@alcatel.be		Email: dimitri.papadimitriou@alcatel.be
	Kohei Shiomoto		Kohei Shiomoto
	NTT		NTT
	3-9-11 Midori-Cho		3-9-11 Midori-Cho
	Musashino, Tokyo 180-8585, Japan		Musashino, Tokyo 180-8585, Japan
	Email: shiomoto.kohei@lab.ntt.co.jp		Email: shiomoto.kohei@lab.ntt.co.jp
	Martin Vigoureux		Martin Vigoureux
	Alcatel		Alcatel
	Route de Nozay,		Route de Nozay,
	91461 Marcoussis Cedex, France		91461 Marcoussis Cedex, France
	Email: martin.vigoureux@alcatel.fr		Email: martin.vigoureux@alcatel.fr
	9. Intellectual Property Statement		10. 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.
End of changes. 70 change blocks.
	138 lines changed or deleted		240 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/