draft-ietf-ccamp-gmpls-mln-eval-00.txt		draft-ietf-ccamp-gmpls-mln-eval-01.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: July 2006 D. Papadimitriou (Alcatel)		Expires: January 2007 D. Papadimitriou (Alcatel)
	K. Shiomoto (NTT)		K. Shiomoto (NTT)
	M. Vigoureux (Alcatel)		M. Vigoureux (Alcatel)
	January 2006
	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-ietf-ccamp-gmpls-mln-eval-00.txt		draft-ietf-ccamp-gmpls-mln-eval-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 2, line 16		skipping to change at page 2, line 16
	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. Terminology.................................................3		1. Terminology.................................................3
	2. Introduction................................................3		2. Introduction................................................3
	3. MLN/MRN Requirements Overview...............................4		3. MLN/MRN Requirements Overview...............................4
	4. Analysis....................................................4		4. Analysis....................................................5
	4.1. Multi-Layer Aspects.........................................4		4.1. Multi-Layer Aspects.........................................5
	4.1.1. Support for Virtual Network Topology Reconfiguration........4		4.1.1. Support for Virtual Network Topology Reconfiguration........5
	4.1.1.1. Control of FA-LSPs Setup/Release..........................5		4.1.1.1. Control of FA-LSPs Setup/Release..........................5
	4.1.1.2. Virtual TE-Links..........................................6		4.1.1.2. Virtual TE-Links..........................................7
	4.1.1.3. Traffic Disruption Minimization During FA Release.........7		4.1.1.3. Traffic Disruption Minimization During FA Release.........8
	4.1.1.4. Stability.................................................7		4.1.1.4. Stability.................................................8
	4.1.2. Support for FA-LSP Attributes Inheritance...................7		4.1.2. Support for FA-LSP Attributes Inheritance...................8
	4.1.3. Support for Triggered Signaling.............................8		4.1.3. Support for Triggered Signaling.............................9
	4.1.4. FA Connectivity Verification................................8		4.1.4. FA Connectivity Verification................................9
	4.2. Multi-Region Specific Aspects...............................8		4.2. Multi-Region Specific Aspects...............................9
	4.2.1. Support for Multi-Region Signaling..........................8		4.2.1. Support for Multi-Region Signaling..........................9
	4.2.2. Advertisement of Internal Adaptation Capabilities...........9		4.2.2. Advertisement of Internal Adaptation Capabilities..........10
			4.3. Client and server network aspects..........................12
			4.3.1. Administrative boundary....................................12
			4.3.2. Path computation across separated TEDs.....................12
			4.3.3. Association between TE-links in separated TEDs.............12
	5. Evaluation Conclusion......................................12		5. Evaluation Conclusion......................................12
	6. Security Considerations....................................12		6. Security Considerations....................................13
	7. Acknowledgments............................................12		7. Acknowledgments............................................13
	8. References.................................................13		8. References.................................................13
	8.1. Normative..................................................13		8.1. Normative..................................................13
	8.2. Informative................................................13		8.2. Informative................................................14
	9. Authors' Addresses:........................................13		9. Authors' Addresses:........................................14
	10. Intellectual Property Statement............................14		10. Intellectual Property Statement............................15
	1. Terminology		1. Terminology
	This document uses terminologies defined in [RFC3945], [HIER], and		This document uses terminologies defined in [RFC3945], [HIER], and
	[MRN-REQ].		[MLN-REQ].
	2. Introduction		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 (PSC),		handle multiple switching technologies: packet switching (PSC),
	layer-two switching (L2SC), TDM switching (TDM), wavelength switching		layer-two switching (L2SC), TDM switching (TDM), wavelength switching
	(LSC) and fiber switching (FSC) (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 either by a single GMPLS control
	instance is called a Multi-Layer Network (MLN).		plane 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 network comprised of multiple switching types		is defined in [HIER]. A network comprised of multiple switching types
	(e.g. PSC and TDM) controlled by a single GMPLS control plane		(e.g. PSC and TDM) controlled by a single GMPLS control plane
	instance is called a Multi-Region Network (MRN).		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.
			A customer network may be provided on top of a server GMPLS-based
			MRN/MLN which is operated by a service provider. For example, a pure
			IP and/or an IP/MPLS network can be provided on top of GMPLS-based
			packet over optical networks [IW-MIG-FW]. The relationship between
			the networks is a client/server relationship and such services are
			referred to as "MRN/MLN services". In this case, the customer network
			may form part of the MRN/MLN, or may be partially separated, for
			example to maintain separate routing information but retain common
			signalling.
	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 [MLN-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 3 provides an overview of MLN/MRN requirements.		Section 3 provides an overview of MLN/MRN requirements.
	Section 4 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.
	3. MLN/MRN Requirements Overview		3. MLN/MRN Requirements Overview
	[MRN-REQ] lists a set of functional requirements for Multi		[MLN-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 (VNT)		- Support of robust Virtual Network Topology (VNT)
	reconfiguration. This implies the following requirements:		reconfiguration. This implies the following requirements:
	- Optimal control of FA-LSP 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-LSP release		- Traffic Disruption minimization during FA-LSP release
	(e.g. 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;
			Interconnection of MLN/MRN (server) networks with administratively
			separated client networks introduces as set of specific requirements:
			- Support for administrative boundary between client and server
			MLN/MRN network , minimizing impact on the customer network
			design, operation, and administration;
			- Support for path computation across separated TEDs associated
			with client and server MLN/MRN network;
			- Support for association between TE-links in separated TEDs
			associated with client and server MLN/MRN networks;
	4. Analysis		4. Analysis
	4.1. Multi-Layer Aspects		4.1. Multi-Layer Aspects
	4.1.1. Support for Virtual Network Topology Reconfiguration		4.1.1. Support for Virtual Network Topology Reconfiguration
	A set of lower-layer FA-LSPs provides a Virtual Network Topology		A set of lower-layer FA-LSPs provides a Virtual Network Topology
	(VNT) to the upper-layer. By reconfiguring the VNT (FA-LSP		(VNT) to the upper-layer. By reconfiguring the VNT (FA-LSP
	setup/release) according to traffic demands between source and		setup/release) according to traffic demands between source and
	skipping to change at page 5, line 16		skipping to change at page 5, line 33
	In a Multi-Layer Network, FA-LSPs 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
	according to upper layer traffic demands and TE topology		- VNT resources policing/scheduling with regards to traffic
	(and potentially old VNT);		demands and usage (i.e. decision to setup/release FAs); The
	- FA-LSP setup/release;		functional component in charge of this function is called a
			VNT Manager (VNTM), it may be distributed on network
			elements or centralized on an external tool (see [VNTM]). It
			may also be partially centralized and distributed;
			- VNT Path Computation according to TE topology, and
			potentially taking into account old VNT (to minimize
			changes); The Functional component in charge of VNT
			computation may be distributed on network elements or may be
			centralized on an external tool (such as e.g. a PCE);
			- 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 FA-LSPs.		GMPLS signaling protocols allow setting up/releasing FA-LSPs.
	VNT computation and reconfiguration is out of the scope of GMPLS		VNT Management functions (resources policing/scheduling, decision to
	protocols. Such functionality can be achieved directly on layer		setup/release FA, FA configuration) are out of the scope of GMPLS
	border LSRs, or one or more external tools, as for instance Path		protocols. Such functionalities can be achieved directly on layer
	Computation Elements (PCE) (see [PCE-ARCH]).		border LSRs, and/or on one or more external tools. When an external
			tool is used, an interface is required between the VNTM and network
			elements so has to setup/releases FA-LSPs. This may rely on SNMP (TE
			MIB) or proprietary interfaces.
	The set of traffic demands of the upper layer is required to		The set of traffic demands of the upper layer is required for the VNT
	recompute and re-optimize the VNT. This requires knowledge of the		Manager to take decisions to setup/release FAs. This requires
	aggregated bandwidth reserved by upper layer LSPs established between		knowledge of the aggregated bandwidth reserved by upper layer LSPs
	any pair of border LSRs.		established between 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.
	advertisements. The traffic demands between two points		The traffic demands between two points correspond to the
	correspond to the cumulated bandwidth reserved by upper-layer		cumulated bandwidth reserved by upper-layer LSPs between these
	LSPs between these two points;		two points;
	- or indirectly, based on lower-layer FA TE-link		- or indirectly, based on lower-layer FA TE-link advertisements.
	advertisements. In this case a mechanism to infer the upper-		In this case a mechanism to infer the upper-layer traffic demand
	layer traffic demand from the aggregated bandwidth reserved		from the aggregated bandwidth reserved in lower-layer LSPs might
	in lower-layer LSPs might be required, as all pairs of border		be required, as all pairs of border nodes may not be directly
	nodes may not be directly connected by a lower layer LSP.		connected by a lower layer LSP.
	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 Managers:
	- If a VNT engine is distributed on border region LSRs, then the		- If a VNTM is distributed on border layer LSRs, then
	collection of traffic demands would rely on existing GMPLS		the 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 VNTM is centralized on an external tool, then the
	then the collection of traffic demands may be achieved using		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 TE-link MIB).
			Finally, VNT computation can be performed directly on layer border
			LSRs or on an external tool (such as an external PCE) and this
			independently of the location of the VNTM. VNT computation is
			triggered by the VNTM (e.g. when the Path computation is externalized
			on a PCE, the VNTM acts as PCC).
			Hence no GMPLS protocol extensions are required to control FA-LSP
			setup/release.
	4.1.1.2. Virtual TE-Links		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 signaling, if an upper-layer LSP makes use of a Virtual		During its signalling, if an upper-layer LSP makes use of a Virtual
	TE-link, the underlying FA-LSP is immediately signaled and		TE-link, the underlying FA-LSP is immediately signalled 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
	avoiding wastage of bandwidth in the lower layer, as data		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
	create contention if no adequate/consistent admission control is put
	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 signalling 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
	requires a signaling mechanism allowing an end-to-end		signalling mechanism allowing an end-to-end association
	association between Virtual TE-link end points so as to		between Virtual TE-link end points so as to exchange link
	exchange link identifiers as well as some TE parameters.		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 signaling does not allow setting up and releasing		Current GMPLS signaling does not allow setting up and releasing
	Virtual TE-links. Hence GMPLS signaling 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.
	may rely on extensions to the RSVP-TE ASON Call procedure ([GMPLS-
	ASON]).		We can distinguish two options for setting up Virtual TE-links:
			- The Soft FA approach, that consists of setting up the FA-LSP
			in the control plane without actually activating cross connections in
			the data plane. One the one hand, this requires state maintenance on
			all transit LSRs (N square issue), but on the other hand this may
			allow for some admission control. Indeed, when a soft-FA is
			activated, there may be no longer available resources for other soft-
			FAs that were sharing common links, these soft-FA will be dynamically
			released and corresponding virtual TE-links are deleted. The soft-FA
			LSPs may be setup using procedures similar to those described in
			[GMPLS-RECOVERY] for setting up secondary LSPs.
			-The remote association approach, that simply consists of
			exchanging virtual TE-links ids and parameters directly between TE-
			link end points. This does not require state maintenance on transit
			LSRs, but reduce admission control capabilities. Such an association
			between Virtual TE-link end-points may rely on extensions to the
			RSVP-TE ASON Call procedure ([GMPLS-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.
	4.1.1.3. Traffic Disruption Minimization During FA Release		4.1.1.3. Traffic Disruption Minimization During FA 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
	skipping to change at page 10, line 46		skipping to change at page 11, line 46
	this node cannot terminate this LSP, as there is only 155Mb still		this node cannot terminate this LSP, as there is only 155Mb still
	available for TDM-PSC adaptation. Hence the internal TDM-PSC		available for TDM-PSC adaptation. Hence the internal TDM-PSC
	adaptation capability must be advertised.		adaptation capability must be advertised.
	With current GMPLS routing [GMPLS-RTG] this advertisement is possible		With current GMPLS routing [GMPLS-RTG] this advertisement is possible
	if link bundling is not used and if two TE-links are advertised for		if link bundling is not used and if two TE-links are advertised for
	link1:		link1:
	We would have the following TE-link advertisements:		We would have the following TE-link advertisements:
	TE-link 1 (port 1):		TE-link 1 (port 1):
			- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb, unreserved
			bandwidth = 622Mb.
			TE-Link 2 (port 2):
	- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,		- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
	unreserved bandwidth = vc4-5c.		unreserved bandwidth = vc4-5c.
	- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,		- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,
	unreserved bandwidth = 155 Mb.		unreserved bandwidth = 155 Mb.
	TE-Link 2 (port 2):		The ISCD 2 in TE-link 2 represents actually the internal TDM-PSC
	- 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.		adaptation capability.
	However if for obvious scalability reasons link bundling is done then		However if for obvious scalability reasons link bundling is done then
	the adaptation capability information is lost with current GMPLS		the adaptation capability information is lost with current GMPLS
	routing, as we have the following TE-link advertisement:		routing, as we have the following TE-link advertisement:
	TE-link 1 (port 1 + port 2):		TE-link 1 (port 1 + port 2):
	- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,		- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
	unreserved bandwidth = vc4-5c.		unreserved bandwidth = vc4-5c.
	- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,		- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,
	skipping to change at page 11, line 28		skipping to change at page 12, line 28
	With such TE-link advertisement an element computing the path of a		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		VC4-4C LSP cannot know that this LSP cannot be terminated on the
	node.		node.
	Thus current GMPLS routing can support the advertisement of the		Thus current GMPLS routing can support the advertisement of the
	internal adaptation capability but this precludes performing link		internal adaptation capability but this precludes performing link
	bundling and thus faces significant scalability limitations.		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		capabilitiy 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.3. Client and server network aspects
			4.3.1. Administrative boundary
			TBD
			4.3.2. Path computation across separated TEDs
			TBD
			4.3.3. Association between TE-links in separated TEDs
			TBD
	5. 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 rely		reconfiguration, specific TE mechanisms that could for instance rely
	on PCE based mechanisms and protocols, need to be defined, but these		on PCE based mechanisms and protocols, need to be defined, but 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 signalling 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 signalling extension for graceful TE-link
	deletion;		deletion;
	- GMPLS signaling extension for constrained multi-region		- GMPLS signalling extension for constrained multi-region
	signaling (SC inclusion/exclusion);		signalling (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.
	6. 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].
	skipping to change at page 13, line 17		skipping to change at page 13, line 50
	8.1. Normative		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, RFC4202, October 2005.
	[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		8.2. Informative
	[GMPLS-ASON] Papadimitriou, D., et. al., " Generalized MPLS (GMPLS)		[GMPLS-ASON] Papadimitriou, D., et. al., " Generalized MPLS (GMPLS)
	RSVP-TE Signaling 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,		[MLN-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-ietf-ccamp-gmpls-mrn-reqs, work in
	progess.		progess.
	[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
	Element (PCE) Architecture", draft-ietf-pce-architecture, work in
	progress.
	[GTEP] Oki, E., et. al., "Generalized Traffic Engineering Protocol",
	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, work in progress.		MPLS TE", draft-ietf-mpls-lsp-hierarchy, FRC4206, October 2005.
	[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.
			[GMPLS-RECOVERY] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
			support of End-to-End Generalized Multi-Protocol Label Switching
			(GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-
			signaling, work in progress.
			[VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network
			Topology Manager (VNTM) for PCE-based Inter-Layer MPLS and GMPLS
			Traffic Engineering", draft-oki-pce-vntm-def, work in progress.
			[IW-MIG-FMWK] Shiomoto, K et al., "Framework for IP/MPLS-GMPLS
			interworking in support of IP/MPLS to GMPLS migration", draft-ietf-
			ccamp-mpls-gmpls-interwork-fmwk, work in progress.
	9. Authors' Addresses:		9. Authors' Addresses:
	Jean-Louis Le Roux		Jean-Louis Le Roux (Editor)
	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
End of changes. 44 change blocks.
	97 lines changed or deleted		179 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/