draft-ietf-ccamp-gmpls-mln-eval-02.txt		draft-ietf-ccamp-gmpls-mln-eval-03.txt
	Network Working Group J.L. Le Roux (France Telecom)		Network Working Group J.L. Le Roux (Ed.)
	Internet Draft D. Brungard (AT&T)		Internet Draft France Telecom
	Category: Informational E. Oki (NTT)		Category: Informational
	Expires: April 2007 D. Papadimitriou (Alcatel)		Expires: January 2008 D. Papadimitriou (Ed.)
	K. Shiomoto (NTT)		Alcatel-Lucent
	M. Vigoureux (Alcatel)
	October 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-02.txt		draft-ietf-ccamp-gmpls-mln-eval-03.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 13		skipping to change at page 2, line 13
	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. Terminology.................................................3		1. Introduction................................................3
	2. Introduction................................................3		2. MLN/MRN Requirements Overview...............................4
	3. MLN/MRN Requirements Overview...............................4		3. Analysis....................................................4
	4. Analysis....................................................4		3.1. Multi Layer Network Aspects.................................4
	4.1. Multi-Layer Aspects.........................................4		3.1.1. Support for Virtual Network Topology Reconfiguration........4
	4.1.1. Support for Virtual Network Topology Reconfiguration........4		3.1.1.1. Control of FA-LSPs Setup/Release..........................5
	4.1.1.1. Control of FA-LSPs Setup/Release..........................5		3.1.1.2. Virtual TE-Links..........................................6
	4.1.1.2. Virtual TE-Links..........................................6		3.1.1.3. Traffic Disruption Minimization During FA Release.........7
	4.1.1.3. Traffic Disruption Minimization During FA Release.........8		3.1.1.4. Stability.................................................8
	4.1.1.4. Stability.................................................8		3.1.2. Support for FA-LSP Attributes Inheritance...................8
	4.1.2. Support for FA-LSP Attributes Inheritance...................8		3.1.3. FA-LSP Connectivity Verification............................8
	4.1.3. Support for Triggered Signaling.............................8		3.2. Specific Aspects for Multi-Region Networks..................9
	4.1.4. FA Connectivity Verification................................9		3.2.1. Support for Multi-Region Signaling..........................9
	4.2. Multi-Region Specific Aspects...............................9		3.2.2. Advertisement of Internal Adaptation Capabilities...........9
	4.2.1. Support for Multi-Region Signaling..........................9		4. Evaluation Conclusion......................................12
	4.2.2. Advertisement of Internal Adaptation Capabilities..........10		5. Security Considerations....................................12
	5. Evaluation Conclusion......................................12		6. Acknowledgments............................................12
	6. Security Considerations....................................13		7. References.................................................13
	7. Acknowledgments............................................13		7.1. Normative..................................................13
	8. References.................................................13		7.2. Informative................................................13
	8.1. Normative..................................................13		8. Editors' Addresses:........................................14
	8.2. Informative................................................13		9. Contributors' Addresses:...................................14
	9. Authors' Addresses:........................................14
	10. Intellectual Property Statement............................15		10. Intellectual Property Statement............................15
	1. Terminology		1. Introduction
	This document uses terminologies defined in [RFC3945], [RFC4206], and
	[MLN-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 (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 are three different layers.
	layers. A network comprising transport nodes with different data		A network comprising transport nodes with different data plane
	plane switching layers controlled by a single GMPLS control plane		switching layers controlled by a single GMPLS control plane instance
	instance is called a Multi-Layer Network (MLN).		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 Label
	is defined in [RFC4206]. A network comprised of multiple switching		Switched Path (LSP) Region is defined in [RFC4206]. A network
	types (e.g. PSC and TDM) controlled by a single GMPLS control plane		comprised of multiple switching types (for example PSC and TDM)
	instance is called a Multi-Region Network (MRN).		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 multiple data plane layers of the same switching
	within a region). Hence, in the following, we use the term layer if		technology. Hence, in the following, we use the term "layer" if the
	the mechanism discussed applies equally to layers and regions (e.g.		mechanism discussed applies equally to layers and regions (for
	VNT, virtual TE-link, etc.), and we specifically use the term region		example VNT, virtual TE-link, etc.), and we specifically use the term
	if the mechanism applies only for supporting a MRN.		"region" if the mechanism applies only to the support of 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], [RFC4202], [RFC3471]) against		mechanisms and protocols ([RFC 3945], [RFC4202], [RFC3471,
	the requirements for MLN and MRN, defined in [MLN-REQ]. From this		[RFC3473]]) against the requirements for MLN and MRN, defined in
	evaluation, we identify several areas where additional protocol		[MLN-REQ]. From this evaluation, we identify several areas where
	extensions and modifications are required to meet these requirements,		additional protocol extensions and modifications are required to meet
	and provide guidelines for potential extensions.		these requirements, and provide guidelines for potential extensions.
	An overview of MLN/MRN requirements is provided in section 3. Then		A summary of MLN/MRN requirements is provided in section 2. Then
	section 4 evaluates for each of these requirements, whether current		section 3 evaluates for each of these requirements, whether current
	GMPLS protocols and mechanisms allow addressing the requirements.		GMPLS protocols and mechanisms meet the requirements. When the
	When the requirements are not met, the document identifies whether		requirements are not met by existing protocols, the document
	the required mechanisms could rely on GMPLS protocols and procedure		identifies whether the required mechanisms could rely on GMPLS
	extensions or if it is entirely out of the scope of GMPLS protocols.		protocols and procedure extensions or whether 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. Partitions of the control plane where
			separate layers are under distinct administrative control are for
			future study.
	3. MLN/MRN Requirements Overview		This document uses terminologies defined in [RFC3945], [RFC4206], and
			[MLN-REQ].
	[MLN-REQ] lists a set of functional requirements for Multi		2. MLN/MRN Requirements Overview
	Layer/Region Networks (MLN/MRN). These requirements are summarized
	below:
	- Support of robust Virtual Network Topology (VNT)		Section 5 of [MLN-REQ] lists a set of functional requirements for
			Multi Layer/Region Networks (MLN/MRN). These requirements are
			summarized below, and a mapping with sub-sections of [MLN-REQ] is
			provided.
			Here is the list of requirements that apply to MLN:
			- Support for robust Virtual Network Topology (VNT)
	reconfiguration. This implies the following requirements:		reconfiguration. This implies the following requirements:
	- Optimal control of FA-LSP setup and release;		- Optimal control of Forwarding Adjacency LSP (FA-LSP)
	- Support for virtual TE-links;		setup and release (section 5.8.1 of [MLN-REQ]);
			- Support for virtual TE-links (section 5.8.2 of [MLN-
			REQ]);
	- Traffic Disruption minimization during FA-LSP release		- Traffic Disruption minimization during FA-LSP release
	(e.g. network reconfiguration events);		(section 5.5 of [MLN-REQ]);
	- Stability;		- Stability (section 5.4 of [MLN-REQ]);
	- Support for FA-LSP attributes inheritance;		- Support for FA-LSP attributes inheritance (section 5.6 of
			[MLN-REQ]);
	- Support for Triggered Signaling;		- Support for FA-LSP data plane connectivity verification
			(section 5.9 of [MLN-REQ]);
	- Support for FA-LSP data plane connectivity verification;		Here is the list of requirements that apply to MRN only:
	- Support for Multi-Region signaling;		- Support for Multi-Region signaling (section 5.7 of [MLN-REQ]);
	- Advertisement of the adaptation capabilities and resources;		- Advertisement of the adaptation capabilities and resources
			(section 5.2 of [MLN-REQ]);
	4. Analysis		3. Analysis
	4.1. Multi-Layer Aspects		3.1. Multi Layer Network Aspects
	4.1.1. Support for Virtual Network Topology Reconfiguration		3.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 [MLN-REQ]. By reconfiguring the VNT (FA-LSP
	setup/release) according to traffic demands between source and		setup/release) according to traffic demands between source and
	destination node pairs of a layer, network performance factors such		destination node pairs within a layer, network performance factors
	as maximum link utilization and residual capacity of the network can		such as maximum link utilization and residual capacity of the network
	be optimized. Such optimal VNT reconfiguration implies several		can be optimized. Such optimal VNT reconfiguration implies several
	mechanisms that are 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 possible approach to perform
	perform inter-layer Traffic Engineering.		inter-layer Traffic Engineering.
	4.1.1.1. Control of FA-LSPs Setup/Release		3.1.1.1. Control of FA-LSPs Setup/Release
	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 and setup a new VNT.
	Several functional building blocks are required to support such TE		Several functional building blocks are required to support such TE
	mechanism:		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 upper layer traffic demands.
	- VNT resources policing/scheduling with regards to traffic		- Policing and scheduling of VNT resources with regard to
	demands and usage (i.e. decision to setup/release FAs); The		traffic demands and usage (that is, decision to setup/release
	functional component in charge of this function is called a		FA-LSPs); The functional component in charge of this function
	VNT Manager (VNTM), it may be distributed on network		is called a VNT Manager (VNTM).
	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		- VNT Paths Computation according to TE topology, and
	taking into account old VNT (to minimize changes); The		potentially taking into account the old (existing) VNT to
	Functional component in charge of VNT computation may be		minimize changes. The Functional component in charge of VNT
	distributed on network elements or may be centralized on an		computation may be distributed on network elements or may be
	external tool (such as e.g. a PCE).		centralized on an external tool (such as a Path Computation
			Element (PCE), [RFC4655]).
	- FA-LSP setup/release.		- FA-LSP setup/release.
	GMPLS routing protocols support TE topology discovery. GMPLS		GMPLS routing protocols provide TE topology discovery.
	signaling protocols allow setting up/releasing FA-LSPs.		GMPLS signaling protocols allow setting up/releasing FA-LSPs.
	VNT Management functions (resources policing/scheduling, decision to		VNT Management functions (resources policing/scheduling, decision to
	setup/release FA, FA configuration) are out of the scope of GMPLS		setup/release FA-LSPs, FA-LSP configuration) are out of the scope of
	protocols. Such functionalities can be achieved directly on layer		GMPLS protocols. Such functionalities can be achieved directly on
	border LSRs, and/or on one or more external tools. When an external		layer border LSRs, or through one or more external tools. When an
	tool is used, an interface is required between the VNTM and network		external tool is used, an interface is required between the VNTM and
	elements so has to setup/releases FA-LSPs. This may rely on SNMP (TE		the network elements so as to setup/releases FA-LSPs. This could use
	MIB) or on proprietary interfaces.		standard management interfaces such as [RFC4802].
	The set of traffic demands of the upper layer is required for the VNT
	Manager to take decisions to setup/release FAs. This requires
	knowledge of the aggregated bandwidth reserved by upper layer LSPs
	established between any pair of border LSRs.
	Existing GMPLS routing allows for the collection of traffic demands
	of the upper region. It can be deduced from FA TE-link advertisements.
	The set of traffic demands can be inferred:
	- either directly, based on upper-layer FA TE-link advertisements.
	The traffic demands between two points correspond to the
	cumulated bandwidth reserved by upper-layer LSPs between these
	two points;
	- or indirectly, based on lower-layer FA TE-link advertisements.
	In this case a mechanism to infer the upper-layer traffic demand
	from the aggregated bandwidth reserved in lower-layer LSPs might
	be required, as all pairs of border nodes may not be directly
	connected by a lower layer LSP.
	Collection of traffic demands of an upper region may actually be		The set of traffic demands of the upper layer is required for the
	achieved in several ways depending on the location of VNT Managers:		VNT Manager to take decisions to setup/release FA-LSPs. Such
	- If a VNTM is distributed on border layer LSRs, then the		traffic demands include satisfied demands, for which one or more
	collection of traffic demands would rely on existing GMPLS		upper layer LSP have been successfully satisfied, as well as
	routing, as per described above;		unsatisfied demands and future demands, for which no upper layer LSP
	- If a VNTM is centralized on an external tool, then the		has been setup yet. The collection of such information is beyond the
	collection of traffic demands may be achieved using existing		scope of GMPLS protocols, but may be partially inferred from
	GMPLS routing, provided that the tool relies on GMPLS routing to		parameters carried in GMPLS signaling or advertised in GMPLS routing.
	discover TE link information, or it may rely on another
	mechanism out of the scope of GMPLS protocols (e.g. SNMP TE-link
	MIB).
	Finally, VNT computation can be performed directly on layer border		Finally, the computation of FA-LSPs that form the VNT can be
	LSRs or on an external tool (such as an external PCE) and this		performed directly on layer border LSRs or on an external tool (such
	independently of the location of the VNTM. VNT computation is		as a Path Computation Element (PCE), [RFC4655]), and this is
	triggered by the VNTM (e.g. when the Path computation is externalized		independent of the location of the VNTM. VNT computation is triggered
	on a PCE, the VNTM acts as PCC).		by the VNTM (for example, when the path computation is externalized
			on a PCE, the VNTM acts as Path Computation Client (PCC)).
	Hence no GMPLS protocol extensions are required to control FA-LSP		Hence, to summarize, no GMPLS protocol extensions are required to
	setup/release.		control FA-LSP setup/release.
	4.1.1.2. Virtual TE-Links		3.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 upper layer nodes that is
	associated to a fully provisioned FA-LSP. A Virtual TE-link		not actually associated with a fully provisioned FA-LSP in a lower
	represents the potentiality to setup a FA-LSP. There is no IGP		layer. A Virtual TE-link represents the potentiality to setup an FA-
	adjacency associated to a Virtual TE-link. A Virtual TE-link is		LSP in the lower layer to support the TE-link that has been
	advertised as any classical TE-link, i.e. following the rules in		advertised. A Virtual TE-link is advertised as any TE-link, following
	[RFC4206] defined for fully provisioned TE-links. Particularly, the		the rules in [RFC4206] defined for fully provisioned TE-links. In
	flooding scope of a Virtual TE-link is within an IGP area, as any TE-		particular, the flooding scope of a Virtual TE-link is within an IGP
	link.		area, as is the case for any TE-link.
	During its signalling, if an upper-layer LSP makes use of a Virtual		If an upper-layer LSP attempts (through a signalling message) to make
	TE-link, the underlying FA-LSP is immediately signalled and		use of a Virtual TE-link, the underlying FA-LSP is immediately
	provisioned.		signalled and provisioned in the process known as triggered
			signaling.
	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 the computation of an LSP path using TE-links
	without taking into account the actual status of the		without needing to take into account the actual provisioning
	corresponding FA-LSP in the lower layer in terms of provisioning;		status of the corresponding FA-LSP in the lower layer;
	- stability: allows stability of TE-links in the upper layer, while
			- Stability: allows stability of TE-links in the upper layer, while
	avoiding wastage of bandwidth in the lower layer, as data plane		avoiding wastage of bandwidth in the lower layer, as data plane
	connections are not established.		connections are not established until they are actually needed.
	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 signalling 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 requires a		virtual TE-links. Setting up a virtual TE-link requires a
	signalling mechanism allowing an end-to-end association		signaling mechanism allowing an end-to-end association
	between Virtual TE-link end points so as to exchange link		between Virtual TE-link end points so as to 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 signalling does not allow setting up and releasing		Current GMPLS signalling does not allow setting up and releasing
	Virtual TE-links. Hence GMPLS signalling must be extended to support		Virtual TE-links. Hence GMPLS signalling must be extended to support
	Virtual TE-links.		Virtual TE-links.
	We can distinguish two options for setting up Virtual TE-links:		We can distinguish two options for setting up Virtual TE-links:
	- The Soft FA approach, that consists of setting up the FA-LSP		- The Soft FA approach that consists of setting up the FA-LSP in the
	in the control plane without actually activating cross connections in		control plane without actually activating cross connections in the
	the data plane. One the one hand, this requires state maintenance on		data plane. On the one hand, this requires state maintenance on all
	all transit LSRs (N square issue), but on the other hand this may		transit LSRs (N square issue), but on the other hand this may allow
	allow for some admission control. Indeed, when a soft-FA is		for some admission control. Indeed, when a soft-FA is activated,
	activated, there may be no longer available resources for other soft-		the resources may be no longer available for use by other soft-FAs
	FAs that were sharing common links, these soft-FA will be dynamically		that have common links. These soft-FA will be dynamically released
	released and corresponding virtual TE-links are deleted. The soft-FA		and corresponding virtual TE-links are deleted. The soft-FA LSPs
	LSPs may be setup using procedures similar to those described in		may be setup using procedures similar to those described in
	[GMPLS-RECOVERY] for setting up secondary LSPs.		[RFC4872] for setting up secondary LSPs.
	-The remote association approach, that simply consists of		- The remote association approach that simply consists of exchanging
	exchanging virtual TE-links ids and parameters directly between TE-		virtual TE-links IDs and parameters directly between TE-link end
	link end points. This does not require state maintenance on transit		points. This does not require state maintenance on transit LSRs,
	LSRs, but reduce admission control capabilities. Such an association		but reduces admission control capabilities. Such an association
	between Virtual TE-link end-points may rely on extensions to the		between Virtual TE-link end-points may rely on extensions to the
	RSVP-TE ASON Call procedure ([ASON-CALL]).		RSVP-TE ASON Call procedure ([RSVP-CALL]).
	Note that the support of Virtual TE-link does not require any GMPLS		Note that the support of Virtual TE-links does not require any GMPLS
	routing extension.		routing extension.
	4.1.1.3. Traffic Disruption Minimization During FA Release		3.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
	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 were using the TE-link.
	GMPLS protocols do not provide for explicit indication to trigger
	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 utilize the
	instance, on new signaling Error code to notify head-end LSRs that a		procedures described in [GR-SHUT]: A transit LSR notifies a head-end
	TE-link along the path of a LSP is going to disappear, and also on		LSR that a TE-link along the path of a LSP is going to be torn down,
	new routing attributes (if limited to a single IGP area), such as		and also withdraws the bandwidth on the TE-link so that it is not
	defined in [GR-SHUT].		used for new LSPs.
	4.1.1.4. Stability		3.1.1.4. Stability
	The upper-layer LSP stability may be impaired if the VNT undergoes		The stability of upper-layer LSP 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 the 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 the TE and VNT management
	routing perturbations. This requires that the TE algorithm takes into		algorithms to minimize routing perturbations. This requires that the
	account the old VNT when computing a new VNT, and tries to minimize		algorithms takes into account the old VNT when computing a new VNT,
	the perturbation.		and try to minimize the perturbation.
	4.1.2. Support for FA-LSP Attributes Inheritance
	When FA TE-link parameters are inherited from FA-LSP parameters,
	specific inheritance rules are applied.
	This relies on local procedures and policies and is out of the scope
	of GMPLS protocols.
	Note that this requires that both head-end and tail-end of the FA-LSP
	are driven by same policies.
	4.1.3. Support for Triggered Signaling.
	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
	does not exist the LSP may be established dynamically. Such a
	mechanism is referred to as "Triggered signaling".
	Triggered signaling requires the following building blocks:		A full mesh of upper-layer LSPs MAY be created between every pair of
	- The identification of layer boundaries.		border nodes between the upper and lower layers. The merit of a full
	- A path computation engine capable of computing a path		mesh of upper-layer LSPs is that it provides stability to the upper
	containing multiple layers.		layer routing. That is, forwarding table used in the upper layer is
			not impacted if the VNT undergoes changes. Further, there is always
			full reachability and immediate access to bandwidth to support LSPs
			in the upper layer. But it also has significant drawbacks, since it
			requires the maintenance of n^2 RSVP-TE sessions, which may be quite
			CPU and memory consuming (scalability impact). Also this may lead to
			significant bandwidth wastage. Note that the use of virtual TE-links
			solves the bandwidth wastage issue, and may reduce the control plane
			overload.
	- A mechanism for nested signaling.		3.1.2. Support for FA-LSP Attributes Inheritance
	The identification of layer boundaries is supported by GMPLS routing		When a FA TE Link is advertised, its parameters are inherited from
	protocols. The identification of layer boundaries is performed using		the parameters of the FA-LSP, and specific inheritance rules are
	the interface switching capability descriptor associated to the TE-		applied.
	link (see [RFC4206] and [RFC4202]).
	The capability to compute a path containing multiple layers is a		This relies on local procedures and policies and is out of the scope
	local implementation issue and is out of the scope of GMPLS protocols.		of GMPLS protocols. Note that this requires that both head-end and
			tail-end of the FA-LSP are driven by same policies.
	A mechanism for nested signaling is defined in [RFC4206].		3.1.3. FA-LSP Connectivity Verification
	Hence, GMPLS protocols already meet this requirement.		Once fully provisioned, FA-LSP liveliness may be achieved by
			verifying its data plane connectivity.
	4.1.4. FA Connectivity Verification		FA-LSP connectivity verification relies on technology specific
			mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using BFD;
			etc.) as for any other LSP. Hence this requirement is out of the
			scope of GMPLS protocols.
	Once fully provisioned, FA liveliness may be achieved by verifying		3.2. Specific Aspects for Multi-Region Networks
	its data plane connectivity.
	FA connectivity verification relies on technology specific mechanisms		3.2.1. Support for Multi-Region Signaling
	(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.
	Note that the time to establish the FA-LSP must be minimized.		There are actually several cases where a transit node could choose
			between multiple SCs to be used for a lower region FA-LSP:
	4.2. Multi-Region Specific Aspects		- ERO expansion with loose hops: The transit node has to expand the
			path, and may have to select among a set of lower region SCs.
	4.2.1. Support for Multi-Region Signaling		- Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of
			an upper region LSP, comprises a multi-SC TE-link, the region
			border node has to select among these SCs.
	Applying the triggered signaling procedure discussed above, in a MRN		Existing GMPLS signalling procedures does not allow solving this
	environment may lead to the setup of one-hop FA-LSPs between each		ambiguous choice of SC that may be used along a given path.
	node. Therefore, considering that the path computation is able to
	take into account richness of information with regard to the
	Switching Capability (SC) available on given nodes belonging to the
	path, it is consistent to provide enough signaling information to
	indicate the SC to be used and on over which link.
	Limited extension to existing GMPLS signaling procedures is required		Hence an extension to GMPLS signalling has to be defined to indicate
	for this purpose as it only mandates indication of the SCs to be		the SC(s) that can be used and the SC(s) that cannot be used along
	included or excluded before initiating the LSP provisioning procedure.		the path.
	This enhancement would solve the ambiguous choice of SC that are
	potentially used along a given path, particularly in case of ERO
	expansion, or when an ERO sub-object identifies a multi-SC TE-link.
	This would give the possibility to optimize resource usage on a
	multi-region basis.
	4.2.2. Advertisement of Internal Adaptation Capabilities		3.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 ([MLN-
	nodes contain at least two distinct switching elements that are		REQ]). Hybrid nodes contain at least two distinct switching elements
	interconnected by internal links to provide adaptation between the		that are interconnected by internal links to provide adaptation
	supported switching capabilities. These internal links have finite		between the supported switching capabilities. These internal links
	capacities and must be taken into account when computing the path of		have finite capacities and must be taken into account when computing
	a multi-region TE-LSP. The advertisement of the internal adaptation		the path of a multi-region TE-LSP. The advertisement of the internal
	capability is required as it provides critical information when		adaptation capability is required as it provides critical information
	performing multi-region path computation.		when performing multi-region path computation.
	Figure 1a below shows an example of hybrid node. The hybrid node has		Figure 1a below shows an example of hybrid node. The hybrid node has
	two switching elements (matrices), which support here TDM and PSC		two switching elements (matrices), which support here TDM and PSC
	switching respectively. The node terminates two PSC and TDM ports		switching respectively. The node terminates two PSC and TDM ports
	(port1 and port2 respectively). It also has internal link connecting		(port1 and port2 respectively). It also has internal link connecting
	the two switching elements.		the two switching elements.
	The two switching elements are internally interconnected in such a		The two switching elements are internally interconnected in such a
	way that it is possible to terminate some of the resources of the TDM		way that it is possible to terminate some of the resources of the TDM
	port 2 and provide through them adaptation for PSC traffic,		port 2 and provide through them adaptation for PSC traffic,
	received/sent over the internal PSC interface (#b). Two ways are		received/sent over the internal PSC interface (#b). Two ways are
	possible to set up PSC LSPs (port 1 or port 2). Available resources		possible to set up PSC LSPs (port 1 or port 2). Available resources
	advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover		advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover
	both ways.		both ways.
	Network element		Network element
	.............................		.............................
	skipping to change at page 10, line 34		skipping to change at page 10, line 9
	port 2 and provide through them adaptation for PSC traffic,		port 2 and provide through them adaptation for PSC traffic,
	received/sent over the internal PSC interface (#b). Two ways are		received/sent over the internal PSC interface (#b). Two ways are
	possible to set up PSC LSPs (port 1 or port 2). Available resources		possible to set up PSC LSPs (port 1 or port 2). Available resources
	advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover		advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover
	both ways.		both ways.
	Network element		Network element
	.............................		.............................
	: -------- :		: -------- :
	PSC : | PSC | :		PSC : | PSC | :
	Port1-------------<->--|#a | :		Port1-------------<->---|#a | :
	: +--<->---|#b | :		: +--<->---|#b | :
	: | -------- :		: | -------- :
	TDM : | ---------- :		TDM : | ---------- :
	+PSC : +--<->--|#c TDM | :		+PSC : +--<->--|#c TDM | :
	Port2 ------------<->--|#d | :		Port2 ------------<->--|#d | :
	: ---------- :		: ---------- :
	:............................		:............................
	Figure 1a. Hybrid node.		Figure 1a. Hybrid node.
	skipping to change at page 11, line 47		skipping to change at page 11, line 17
	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 [RFC4202] this advertisement is possible		With current GMPLS routing [RFC4202] 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		- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb
	bandwidth = 622Mb.		- Unreserved bandwidth = 622Mb.
	TE-Link 2 (port 2):		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.
	- 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 (equivalent): 777 Mb.
	The ISCD 2 in TE-link 2 represents actually the internal TDM-PSC		The ISCD 2 in TE-link 2 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.
	- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,		- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,
	unreserved bandwidth = 777 Mb.		- Unreserved bandwidth (equivalent): 1399 Mb.
	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 capability		could rely on the advertisement of the internal adaptation capability
	as a new TE link attribute (that would complement the Interface		as a new TE link attribute (that would complement the Interface
	Switching Capability Descriptor TE-link attribute).		Switching Capability Descriptor TE-link attribute).
	5. Evaluation Conclusion		Note: Multiple ISCDs MAY be associated to a single switching
			capability. This can be performed to provide e.g. for TDM interfaces
			the Min/Max LSP Bandwidth associated to each (set of) layer for that
			switching capability. As an example, an interface associated to TDM
			switching capability and supporting VC-12 and VC-4 switching, can be
			associated one ISCD sub-TLV or two ISCD sub-TLVs. In the first case,
			the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to
			VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and
			the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the
			Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4,
			in the second ISCD sub-TLV. Hence, in the first case, as long as the
			Min LSP Bandwidth is set to VC-12 (and not VC-4) and in the second
			case, as long as the first ISCD sub-TLV is advertised there is
			sufficient capacity across that interface to setup a VC-12 LSP."
			4. Evaluation Conclusion
	Most of the required MLN/MRN functions will rely on mechanisms and		Most of the required MLN/MRN functions will rely on mechanisms and
	procedures that are out of the scope of the GMPLS protocols, and thus		procedures that are out of the scope of the GMPLS protocols, and thus
	do not require any GMPLS protocol extensions. They will rely on local		do not 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 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 signalling 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;
	provisioning);
	- GMPLS routing and signalling 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);		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		5. 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].
	7. Acknowledgments		6. Acknowledgments
	We would like to thank Julien Meuric and Igor Bryskin for their		We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel
	useful comments.		for their useful comments.
	8. References		7. References
	8.1. Normative		7.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
	[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing		[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
	Extensions in Support of Generalized Multi-Protocol Label Switching",		Extensions in Support of Generalized Multi-Protocol
	draft-ietf-ccamp-gmpls-routing, RFC4202, October 2005.		Label Switching", draft-ietf-ccamp-gmpls-routing,
			RFC4202, October 2005.
	[RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label		[RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Functional Description", RFC 3471,		Switching (GMPLS) Signaling Functional Description", RFC
	January 2003.		3471, January 2003.
	8.2. Informative		7.2. Informative
	[ASON-CALL] Papadimitriou, D., Farrel, A., et. al., "Generalized MPLS		[RSVP-CALL] Papadimitriou, D., Farrel, A., et. al., "Generalized
	(GMPLS) RSVP-TE Signaling Extensions in support of Calls", draft-		MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
	ietf-ccamp-gmpls-rsvp-te-call, work in progress.		Calls", draft-ietf-ccamp-gmpls-rsvp-te-call, work in
			progress.
	[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,		[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L.,
	M., Brungard, D., "Requirements for GMPLS-based multi-region and		Vigoureux, M., Brungard, D., "Requirements for GMPLS-
	multi-layer networks", draft-ietf-ccamp-gmpls-mrn-reqs, work in		based multi-region and multi-layer networks", draft-
	progess.		ietf-ccamp-gmpls-mrn-reqs, work in progess.
	[RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized		[RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with
	MPLS TE", draft-ietf-mpls-lsp-hierarchy, RFC4206, October 2005.		generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,
			RFC4206, 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-ietf-ccamp-mpls-graceful-shutdown, work		Engineering Network", draft-ietf-ccamp-mpls-graceful-
	in progress.		shutdown, work in progress.
	[GMPLS-RECOVERY] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in		[RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
	support of End-to-End Generalized Multi-Protocol Label Switching		support of End-to-End Generalized Multi-Protocol Label
	(GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-		Switching (GMPLS)-based Recovery", RFC4872, July 2007.
	signaling, work in progress.
	[VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network		[VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network
	Topology Manager (VNTM) for PCE-based Inter-Layer MPLS and GMPLS		Topology Manager (VNTM) for PCE-based Inter-Layer MPLS
	Traffic Engineering", draft-oki-pce-vntm-def, work in progress.		and GMPLS Traffic Engineering", draft-oki-pce-vntm-def,
			work in progress.
	[IW-MIG-FMWK] Shiomoto, K et al., "Framework for IP/MPLS-GMPLS		[IW-MIG-FMWK] Shiomoto, K et al., "Framework for IP/MPLS-GMPLS
	interworking in support of IP/MPLS to GMPLS migration", draft-ietf-		interworking in support of IP/MPLS to GMPLS migration",
	ccamp-mpls-gmpls-interwork-fmwk, work in progress.		draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in
			progress.
	9. Authors' Addresses:		[RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions",
			RFC3473, January 2003.
	Jean-Louis Le Roux (Editor)		[RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based
			Architecture", RFC4655, August 2006.
			[RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802,
			February 2007.
			8. Editors' Addresses
			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@orange-ft.com		Email: jeanlouis.leroux@orange-ftgroup.com
			Dimitri Papadimitriou
			Alcatel-Lucent
			Francis Wellensplein 1,
			B-2018 Antwerpen, Belgium
			Email: dimitri.papadimitriou@alcatel-lucent.be
			9. Contributors' Addresses
	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
	Alcatel
	Francis Wellensplein 1,
	B-2018 Antwerpen, Belgium
	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
	Alcatel		M. Vigoureux
	Route de Nozay,		Alcatel-Lucent France
	91461 Marcoussis Cedex, France		Route de Villejust
	Email: martin.vigoureux@alcatel.fr		91620 Nozay
			FRANCE
			Email: martin.vigoureux@alcatel-lucent.fr
	10. 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
	skipping to change at page 15, line 31		skipping to change at page 15, line 27
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard.
	ietf-ipr@ietf.org.
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
			FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject		Copyright (C) The IETF Trust (2007). This document is subject to the
	to the rights, licenses and restrictions contained in BCP 78, and		rights, licenses and restrictions contained in BCP 78, and except as
	except as set forth therein, the authors retain all their rights.		set forth therein, the authors retain all their rights.
End of changes. 107 change blocks.
	328 lines changed or deleted		329 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/