draft-ietf-ccamp-pc-spc-rsvpte-ext-04.txt		draft-ietf-ccamp-pc-spc-rsvpte-ext-05.txt
	CCAMP Working Group D. Caviglia		CCAMP Working Group D. Caviglia
	Internet-Draft D. Ceccarelli		Internet-Draft D. Ceccarelli
	Intended status: Standards Track D. Bramanti		Intended status: Standards Track D. Bramanti
	Expires: March 26, 2010 Ericsson		Expires: July 12, 2010 Ericsson
	D. Li		D. Li
	Huawei Technologies		Huawei Technologies
	S. Bardalai		S. Bardalai
	Fujitsu Network		Fujitsu Network
	September 22, 2009		January 08, 2010
	RSVP-TE Signaling Extension For Management Plane To Control Plane LSP		RSVP-TE Signaling Extension For Management Plane To Control Plane LSP
	Handover In A GMPLS Enabled Transport Network.		Handover In A GMPLS Enabled Transport Network.
	draft-ietf-ccamp-pc-spc-rsvpte-ext-04		draft-ietf-ccamp-pc-spc-rsvpte-ext-05
			Abstract
			In a transport network scenario, where Data Plane connections are
			controlled either by a Generalized Multi-Protocol Label Switching
			(GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a
			Management System (Permanent Connections - PC) may independently
			coexist, the ability of transforming an existing PC into a SPC and
			vice versa - without actually affecting Data Plane traffic being
			carried over it - is a requirement. The requirements for the
			conversion between permanent connections and switched connections in
			a GMPLS Network are defined in [RFC5493].
			This memo describes an extension to GMPLS RSVP-TE signaling that
			enables the transfer of connection ownership between the Management
			and the Control Planes. Such a transfer is referred to as a
			Handover. This document defines all Handover related procedures.
			This includes the handling of failure conditions and subsequent
			reversion to original state. A basic premise of the extension is
			that the handover procedures must never impact an already established
			Data plane.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 38		skipping to change at page 2, line 13
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 26, 2010.		This Internet-Draft will expire on July 12, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	We would like to dedicate this work to our friend and colleague Dino		described in the BSD License.
	Bramanti, who passed away at the early age of 38. Dino has been
	involved in this work since its beginning.
	In a transport network scenario, where Data Plane connections
	controlled either by GMPLS Control Plane (Soft Permanent Connections
	- SPC) or by Management System (Permanent Connections - PC) may
	independently coexist, the ability of transforming an existing PC
	into a SPC and vice versa - without actually affecting Data Plane
	traffic being carried over it - is a requirement.
	This memo describes an extension to GMPLS RSVP-TE signaling that
	enables the transfer of connection ownership between the Management
	and the Control Planes. Such a transfer is referred to as a
	Handover. This document defines all Handover related procedures.
	This includes the handling of failure conditions and subsequent
	reversion to original state. A basic premise of the extension is
	that the handover procedures must never impact an already established
	Data plane.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
			1.1. Dedication . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. MP to CP handover: LSP Ownership Transfer From		4.1. MP to CP handover: LSP Ownership Transfer From
	Management Plane To Control Plane . . . . . . . . . . . . 5		Management Plane To Control Plane . . . . . . . . . . . . 5
	4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 6		4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7
	4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6		4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7
	4.2.1.1. MP to CP Handover Failure - Path message and		4.2.1.1. MP to CP Handover Failure - Path message and
	Data Plane Failure . . . . . . . . . . . . . . . . 6		Data Plane Failure . . . . . . . . . . . . . . . . 7
	4.2.1.2. MP to CP Handover Failure - Path message and		4.2.1.2. MP to CP Handover Failure - Path message and
	Communication failure . . . . . . . . . . . . . . 7		Communication failure . . . . . . . . . . . . . . 8
	4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8		4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 9
	4.2.2.1. MP to CP Handover Failure - Resv Error and		4.2.2.1. MP to CP Handover Failure - Resv Error and
	Data Plane failure . . . . . . . . . . . . . . . . 8		Data Plane failure . . . . . . . . . . . . . . . . 9
	4.2.2.2. MP to CP Handover Failure - Resv Error and		4.2.2.2. MP to CP Handover Failure - Resv Error and
	Communication failure . . . . . . . . . . . . . . 9		Communication failure . . . . . . . . . . . . . . 10
	4.2.2.3. MP to CP Handover Failure - Node Graceful		4.2.2.3. MP to CP Handover Failure - Node Graceful
	Restart . . . . . . . . . . . . . . . . . . . . . 10		Restart . . . . . . . . . . . . . . . . . . . . . 11
	4.3. CP to MP handover : LSP Ownership Transfer From		4.3. CP to MP handover : LSP Ownership Transfer From
	Control Plane To Management Plane . . . . . . . . . . . . 13		Control Plane To Management Plane . . . . . . . . . . . . 14
	4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 13		4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 14
	5. Alternative Way Of Retrieving Information Needed For MP To		5. Minimum Information for MP to CP Handover . . . . . . . . . . 16
	CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 14		6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 17
	6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 15		7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17
	7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 15		7.1. Administrative Status Object . . . . . . . . . . . . . . . 17
	7.1. Administrative Status Object . . . . . . . . . . . . . . . 15		7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 17
	7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 16		8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18
	8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17		11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 17		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 18		13.2. Informational References . . . . . . . . . . . . . . . . . 21
	13.2. Informational References . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	In a typical traditional transport network scenario, Data Plane (DP)		In a typical traditional transport network scenario, Data Plane (DP)
	connections between two endpoints are controlled by means of a		connections between two endpoints are controlled by means of a
	Network Management System (NMS) operating within Management Plane		Network Management System (NMS) operating within Management Plane
	(MP). NMS/MP is the owner of such transport connections, being		(MP). NMS/MP is the owner of such transport connections, being
	responsible of their set up, tear down and maintenance.		responsible of their set up, tear down and maintenance.
	The adoption of a GMPLS Control Plane (CP) over networks that are		The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane
	already in service - controlled by NMS at MP level - introduces the		(CP) in a network that is already in service - controlled by NMS at
	need for a procedure able to coordinate a control handover of a		MP level - introduces the need for a procedure able to coordinate a
	generic data plane connection from MP to CP.		controlled handover of a data plane connection from MP to CP.
	In addition, the control handover in the opposite direction, from CP		In addition, the control handover in the opposite direction, from CP
	to MP SHOULD be possible as well. The procedures described in this		to MP should be possible as well. The procedures described in this
	memo can be applied to any kind of LSP and network architecture.		memo can be applied to an LSP in any DP switching technology and any
			network architecture.
	This memo describes an extension to Generalized Multi-Protocol Label		This memo describes an extension to GMPLS RSVP-TE signaling that
	Switching (GMPLS) RSVP-TE (see [RFC3471] and [RFC3473]) signaling		enables the handover of connection ownership between the Management
	that enables the handover of connection ownership between the		and the Control Planes. All handover related procedures are defined
	Management and the Control Planes. All handover related procedures		below. This includes the handling of failure conditions and
	are defined below. This includes the handling of failure conditions		subsequent reversion to original state. A basic premise of the
	and subsequent reversion to original state. A basic premise of the		extension is that the handover procedures must never impact the
	extension is that the handover procedures must never impact an		exchange of user data on LSPs that are already established in the DP.
	already established Data plane.
			1.1. Dedication
			We would like to dedicate this work to our friend and colleague Dino
			Bramanti, who passed away at the early age of 38. Dino has been
			involved in this work since its beginning.
	2. Terminology		2. Terminology
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Motivation		3. Motivation
	The main motivation behind this work is the definition of a simple		The main motivation behind this work is the definition of a simple
	and very low impacting procedure that satisfies the requirements		and very low impact procedure that satisfies the requirements defined
	defined in [RFC5493]. Such procedure is aimed at giving the		in [RFC5493]. Such a procedure is aimed at giving the transport
	transport network operators the chance to handover the ownership of		network operators the chance to handover the ownership of existing
	existing LSPs provisioned by NMS from the MP to the CP without		LSPs provisioned by NMS from the MP to the CP without disrupting user
	disrupting user traffic flowing on them. Handover from MP to CP		traffic flowing on them. Handover from MP to CP (i.e. when existing
	(i.e. when existing DP connection ownership and control is passed		DP connection ownership and control is passed from MP to CP) has been
	from MP to CP) has been defined as mandatory requirement, while the		defined as a mandatory requirement, while the opposite operation, CP
	opposite operation, CP to MP handover, has been considered as a nice-		to MP handover, has been considered as a nice-to-have feature that
	to-have feature that can be seen as an emergency procedure to disable		can be seen as an emergency procedure to disable the CP and take the
	the CP and take the manual control of the LSP. For more details on		manual control of the LSP. For more details on requirements and
	requirements and motivations please refer to [RFC5493].		motivations please refer to [RFC5493].
	4. Procedures		4. Procedures
	The modification defined in this document refers only to ADMIN_STATUS		The modification defined in this document refers only to the
	Object, that is, the message flow is left unmodified for both LSP		ADMIN_STATUS Object, that is, the message flow is left unmodified for
	set-up and deletion. Moreover a new Error Value is defined to		both LSP set-up and deletion. Moreover a new Error Value is defined
	identify the failure of a Handover procedure.		to identify the failure of a Handover procedure.
	The following paragraphs give detailed description of defined "MP to		The following paragraphs give detailed description of the "MP to CP
	CP handover" and "CP to MP handover" procedures, based on the usage a		handover" and "CP to MP handover" procedures, based on the usage a
	newly define bit called H bit.		newly defined bit called H bit.
	The MP to CP handover procedures support two different methods for		The MP to CP handover procedures support two different methods for
	retrieving required information. The primary one consists on		retrieving required information. The primary one consists of
	receiving the full Explicit Route Object (ERO) from the MP while the		receiving the full Explicit Route Object (ERO) from the MP while the
	alternative one is described in Section 5.		alternative one is described in Section 5.
	Please note that if the primary method is used the labels SHOULD be		Please note that if the primary method is used the labels SHOULD be
	included in the ERO and for bidirectional LSPs both upstream and		included in the ERO and for bidirectional LSPs both upstream and
	downstream labels SHOULD be included. Per Section 5.1.1. of		downstream labels SHOULD be included. Per Section 5.1.1. of
	[RFC3473], the labels are indicated on an output basis. As		[RFC3473], the labels are indicated on an output basis. As
	described, this means that the labels are used by the upstream node		described, this means that the labels are used by the upstream node
	to create the LABEL_SET Object and, for bidirectional LSPs,		to create the LABEL_SET Object and, for bidirectional LSPs,
	UPSTREAM_LABEL Object used in the outgoing Path message.		UPSTREAM_LABEL Object used in the outgoing Path message.
	4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To		4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To
	Control Plane		Control Plane
	The MP to CP handover procedure MUST create an RSVP-TE session along		The MP to CP handover procedure MUST create an RSVP-TE session along
	the path of the LSP to be moved from MP to CP, associating it to the		the path of the LSP to be moved from MP to CP, associating it to the
	existing cross-connected resources owned by the MP (e.g. lambdas,		existing cross-connected resources owned by the MP (e.g. lambdas,
	time slots or reserved bandwidth) and at the same time transferring		time slots or reserved bandwidth) and at the same time transferring
	their ownership to the CP.		their ownership to the CP.
	A standard RSVP-TE signaling flow MUST be used to inform nodes about		The operator instructs the ingress node to handover control of the
	the ownership handover request. Such flows MUST be tagged with a new		LSP from the MP to the CP. In this handover mode, it supplies the
	flag that is carried within the ADMIN_STATUS Object ([RFC3471] and		exact path of the LSP including any resource reservation and label
	[RFC3473]). The new flag is referred to as the H bit and is		information.
	described in Section 7.1. The H bit MUST be set in order to
	discriminate the handover procedure from normal, DP affecting, LSP
	setup/release procedure. The DP MUST NOT be affected from the
	handover procedure.
	The ingress node MUST send a Path message in the downstream direction		The ingress MUST check that no corresponding Path state exists and
	with the H and R ([RFC3471]) bit set. Upon receiving a Path Message		that corresponding Data Plane state does exist. If there is an
	containing an ADMIN_STATUS Object with the H bit set, each node MUST		error, this MUST be reported to the operator and further protocol
	check if there is a local Path State matching the MP to CP Handover		action MUST NOT be taken.
	request. If no local Path State exists, the node MUST confirm that
	there is an existing DP state that corresponds to the Path message.
	In the case of DP state lack (failure cases are defined in the next		The ingress signals the LSP using a Path message with the H bit and R
	sections), local Path state MUST be installed. The H bit MUST be		bit set in the ADMIN_STATUS object. In this mode of handover, the
	stored in the local Path state.		Path message also carries an ERO that includes Label subobjects
			indicating the labels used by the LSP at each hop. The ingress MUST
			start the Expiration timer (see Section 4.2.1.2 for expiration of
			this timer). Such timer SHOULD be configurable per LSP.
	After propagating a Path message with the H bit set, a node MUST wait		Each LSR that receives a Path message with the H bit set checks to
	for a Resv message including ADMIN_STATUS Object with H bit set.		see whether there is any matching Path state.
	After the ingress node receives it, the actual migration of LSP
	information is complete, the LSP is left completely under control of
	RSVP-TE within Control Plane.
	If the Resv message is not received by the expiration of a timer		- If matching Path state is found with the H bit set, this is a
	(called Expiration timer in the following) set by the ingress LER,		Path refresh and should be treated accordingly [RFC3473].
	the handover procedure is aborted, that is, a PathTear message MUST		- If matching Path state is found with the H bit clear, this is an
	be sent in the downstream direction.		error and MUST be treated according to the error case description
			in Section 4.2.xx
			- If no Path state is found, the LSR goes on to check whether
			there is any matching Data Plane state.
			- If no matching Data Plane state is found (including only
			partially matching Data Plane state), this is an error or a race
			condition. It MUST be handled according to the description in
			Section 4.2.xx
			- If matching Data Plane state is found, the LSR MUST save the
			Path state (including the set H bit), and MUST forward the Path
			message to the egress. The LSR MUST retain any MP state
			associated with the LSP at this point.
	In order to complete the Handover process the ingress node MUST send		An egress LSR MUST act as any other LSR, except that there is no
	a Path message with the H bit cleared (set to zero) upon receipt of a		downstream node to which to forward the Path message. If all checks
	corresponding Resv message. The R bit SHOULD NOT be set in this		are passed, the egress MUST respond with a Resv with the H bit set.
	message. Downstream nodes MUST clear their local "Handover" state
	based on a received Path message with the H bit cleared. This means
	that once a downstream node processes a Path message with the cleared
	H bit, any state related to the former MP ownership of the LSP is
	lost. Normal ResvConf process occurs as normal. The handover
	procedure does not modify the Confirmation procedure.
	When the path of the LSP is not fully passed to the ingress LER, each		A transit LSR MUST process each Resv according to the normal rules of
	node can determine the next hop looking at its data plane and exploit		[RFC3473].
	the similarity between the MP to CP Handover procedure and the
	Restart Procedure. Please refer to Section 5.		When an ingress LSR receives a Resv message carrying the H bit set,
			it checks the Expiration Timer.
			- If the timer is not running, the Resv is treated as a refresh and
			no special action is taken [RFC3473].
			- If the timer is running, the ingress MUST cancel the timer and MAY
			notify the operator that the first stage of handover is complete.
			The ingress MUST send a Path message that is no different from the
			previous message except that the H bit MUST be clear.
			The Path message with the H bit clear will travel the length of the
			LSP and will result in the return of a Resv with the H bit clear
			according to normal processing [RFC3473]. As a result, the H bit
			will be cleared in the stored Path state at each transit LSR and at
			the egress LSR. Each LSR SHOULD release any associated MP state
			associated with the LSP when it receives the Path message with H bit
			clear.
			When the ingress receives a Resv with the H bit clear, the handover
			is completed. The ingress SHOULD notify the operator that the
			handover is correctly completed.
	4.2. MP to CP Handover Procedure Failure Handling		4.2. MP to CP Handover Procedure Failure Handling
	In the case of MP to CP Procedure, two different failure scenarios		In the case of MP to CP Handover, two different failure scenarios can
	can happen: Path Failure and Resv Failure. Moreover, each failure		happen: Path Failure and Resv Failure. Moreover, each failure can be
	can be due to two different causes: DP failure or Communication		due to two different causes: DP failure or Communication Failure. In
	Failure. In any case the LSP ownership MUST be immediately roll		any case the LSP ownership MUST be immediately rolled back to the one
	backed to the one previous to the handover procedure. A section for		previous to the handover procedure. A section for each combination
	each combination will be analyzed in the following.		will be analyzed in the following.
	4.2.1. MP to CP Handover Failure - Path Failure		4.2.1. MP to CP Handover Failure - Path Failure
	4.2.1.1. MP to CP Handover Failure - Path message and Data Plane		4.2.1.1. MP to CP Handover Failure - Path message and Data Plane
	Failure		Failure
	In this paragraph we will analyze the case where the handover		In this paragraph we will analyze the case where the handover
	procedure fails during the Path message processing.		procedure fails during the Path message processing.
	| Path | | |		| Path | | |
	|--------------->| Path | |		|--------------->| Path | |
	| |---------------X| |		| |---------------X| |
	| | | |		| | PathErr | |
	| PathErr | | |		| PathErr |<---------------| |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Path Msg and DP Failure		MP2CP - Path Msg and DP Failure
	If an error occurs in an LSR or a LER, the last node that has		If an error occurs in an LSR or a LER, the last node that has
	received the Path message MUST send a PathErr message in the upstream		received the Path message MUST send a PathErr message in the upstream
	direction and the handover procedure is aborted. The PathErr message		direction and the handover procedure is aborted. Upon receiving the
	SHOULD have the Path_State_Removed flag set.		PathErr message the Path state of the node MUST be removed. The
			PathErr message SHOULD have the Path_State_Removed flag set.
	Nodes receiving a PathErr message MUST follow standard PathErr		Nodes receiving a PathErr message MUST follow standard PathErr
	message processing with the exception that when their local state		message processing with the exception that when their local state
	indicates that a Handover is in progress (based on the H bit in the		indicates that a Handover is in progress (based on the H bit in the
	Path message) the associated DP resources MUST NOT be impacted during		Path message) the associated DP resources MUST NOT be impacted during
	such processing.		such processing and the LSR MUST revert the LSP ownership to the MP.
	4.2.1.2. MP to CP Handover Failure - Path message and Communication		4.2.1.2. MP to CP Handover Failure - Path message and Communication
	failure		failure
	Other possible scenarios are shown in the following pictures and		Other possible scenarios are shown in the following pictures and are
	consist on inability to reach a node along the path of the LSP.		based on the inability to reach a node along the path of the LSP.
	The below scenario postulates the usage of a reliable message		The below scenario postulates the usage of a reliable message
	delivery based on the mechanism defined in [RFC2961].		delivery based on the mechanism defined in [RFC2961].
	| Path | | |		| Path | | |
	|--------------->| Path | |		|--------------->| Path | |
	| |---------------X| |		| |---------------X| |
	| |---------------X| |		| |---------------X| |
	| | ... | |		| | ... | |
	| |---------------X| |		| |---------------X| |
	skipping to change at page 8, line 9		skipping to change at page 8, line 38
	The Path message sent from LSR A towards LSR B is lost or does not		The Path message sent from LSR A towards LSR B is lost or does not
	reach the destination for any reason. As a reliable delivery		reach the destination for any reason. As a reliable delivery
	mechanism is implemented, LSR A retransmits the Path message for a		mechanism is implemented, LSR A retransmits the Path message for a
	configurable number of times and if no ack is received the handover		configurable number of times and if no ack is received the handover
	procedure will be aborted (via the Expiration timer).		procedure will be aborted (via the Expiration timer).
	In the next scenario RSVP-TE messages are sent without reliable		In the next scenario RSVP-TE messages are sent without reliable
	message delivery, that is, no [RFC2961] MessageID procedure is used.		message delivery, that is, no [RFC2961] MessageID procedure is used.
	| Path | | |		| Path | | |
	|--------------->| Path | |		|--------------->| Path | |
	| |----------X | |		| |----------X | |
	| | | |		| | | |
	|-TIMER EXPIRES--| | |		TIMER EXPIRES | | |
	| Path Tear | | |		| Path Tear | Path Tear | Path Tear |
	|--------------->| | |		|--------------->|--------------->|--------------->|
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Path Msg and Communication Failure (no reliable delivery)		MP2CP - Path Msg and Communication Failure (no reliable delivery)
	If the Resv message is not received by the expiration of the		If the Resv message is not received before the expiration of the
	Expiration timer the handover procedure is aborted as described in		Expiration timer the handover procedure is aborted as described in
	Section 4.1.		Section 4.1. Please note that any node that has forwarded a Path
			(LSR A), i.e. has installed local path state, MUST send a PathTear
			when that state is removed.
	4.2.2. MP to CP Handover Failure - Resv Error		4.2.2. MP to CP Handover Failure - Resv Error
	4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure		4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure
	In the case of failure occurrence during the Resv message processing,		In the case of failure occurrence during the Resv message processing,
	the node MUST send a PathErr message in the upstream direction. The		(in case there has been any change in the data plane during the
	PathErr message is constructed and processed as defined above in		signaling) the node MUST send a PathErr message in the upstream
	Section 4.2.1.1. The failure detection node MUST also send a		direction. The PathErr message is constructed and processed as
	PathTear message downstream. The PathTear message is constructed and		defined above in Section 4.2.1.1. The failure detection node MUST
	processed as defined above in Section 4.2.1.1.		also send a PathTear message downstream. The PathTear message is
			constructed and processed as defined above in Section 4.2.1.1.
	| Path | Path | Path |		| Path | Path | Path |
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| | | Resv |		| | | Resv |
	| | Resv |<---------------|		| | Resv |<---------------|
	| | X---------| |		| |X---------------| |
	| PathErr | PathTear | PathTear |		| PathErr | PathTear | PathTear |
	|<---------------|--------------->|--------------->|		|<---------------|--------------->|--------------->|
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Resv Error and DP Failure		MP2CP - Resv Error and DP Failure
	In the case shown in the above picture, the failure occurs in LSR A.		In the case shown in the above picture, the failure occurs in LSR A.
	A PathTear message is sent towards B and a PathErr message is sent in		A PathTear message is sent towards B and a PathErr message (with
	the upstream direction. The PathErr and PathTear messages remove the		ErrorCode set to "Handover Procedure Failure") is sent in the
			upstream direction. The PathErr and PathTear messages remove the
	Path state established by the Path messages along the nodes of the		Path state established by the Path messages along the nodes of the
	LSP and abort the handover procedure.		LSP and abort the handover procedure.
	Please note that the failure occurred after the handover procedure		Please note that the failure occurred after the handover procedure
	was successfully completed in LSR B, but Handover state will still be		was successfully completed in LSR B, but Handover state will still be
	maintained locally as, per Section 4.1, a Path message with the H bit		maintained locally as, per Section 4.1, a Path message with the H bit
	clear will have not yet been sent or received.		clear will have not yet been sent or received. A node that receives
			a PahTear when it has Path state with the H bit set MUST remove Path
			state, but MUST NOT change data plane state. It MUST return LSP
			ownership to the MP.
	4.2.2.2. MP to CP Handover Failure - Resv Error and Communication		4.2.2.2. MP to CP Handover Failure - Resv Error and Communication
	failure		failure
	When a Resv message cannot reach one or more of the upstream nodes,		When a Resv message cannot reach one or more of the upstream nodes,
	the procedure is quite similar to the one previously seen about the		the procedure is quite similar to the one previously seen about the
	Path message. Even in this case it is possible to distinguish two		Path message. Even in this case it is possible to distinguish two
	different scenarios.		different scenarios.
	In the first scenario we consider the utilization of a reliable		In the first scenario we consider the utilization of a reliable
	skipping to change at page 10, line 12		skipping to change at page 11, line 5
	is highly probable that the PathErr would fail too. Due to this		is highly probable that the PathErr would fail too. Due to this
	fact, the Expiration timer is used on the Ingress LER after sending		fact, the Expiration timer is used on the Ingress LER after sending
	the path and on LSR A after forwarding it. When the timer expires,		the path and on LSR A after forwarding it. When the timer expires,
	if no Resv or PathErr message is received, the handover procedure is		if no Resv or PathErr message is received, the handover procedure is
	aborted as described in Section 4.1 and the LSP ownership returned to		aborted as described in Section 4.1 and the LSP ownership returned to
	the Management Plane.		the Management Plane.
	The following picture, on the other hand, shows the scenario in which		The following picture, on the other hand, shows the scenario in which
	no reliable delivery mechanism is implemented.		no reliable delivery mechanism is implemented.
	| Path | Path | Path |		| Path | Path | Path |
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| | | Resv |		| | | Resv |
	| | Resv |<---------------|		| | Resv |<---------------|
	| | X---------| |		| | X---------| |
	|-TIMER EXPIRES--| | |		TIMER EXPIRES | | |
	| Path Tear | Path Tear | Path Tear |		| Path Tear | Path Tear | Path Tear |
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Resv Error and Communication Failure (no reliable delivery)		MP2CP - Resv Error and Communication Failure (no reliable delivery)
	If non Resv message is received before the Expiration timer expires,		If non Resv message is received before the Expiration timer expires,
	the ingress LER follows the same procedure defined in Section 4.1.		the ingress LER follows the same procedure defined in Section 4.1.
	4.2.2.3. MP to CP Handover Failure - Node Graceful Restart		4.2.2.3. MP to CP Handover Failure - Node Graceful Restart
	In the case of node restart and graceful restart is enabled then one		In the case of node restart and graceful restart is enabled then one
	of the following scenarios will happen.		of the following scenarios will happen.
	skipping to change at page 13, line 52		skipping to change at page 14, line 52
	4.4. CP to MP Handover Procedure Failure		4.4. CP to MP Handover Procedure Failure
	Failures during CP to MP handover procedure MUST NOT result in the		Failures during CP to MP handover procedure MUST NOT result in the
	removal of any associated data plane state. To that end, when a Resv		removal of any associated data plane state. To that end, when a Resv
	message containing an ADMIN_STATUS Object with the H bit is not		message containing an ADMIN_STATUS Object with the H bit is not
	received during the period of time described in Section 7.2.2. of		received during the period of time described in Section 7.2.2. of
	[RFC3473] different processing is required. Specifically, the		[RFC3473] different processing is required. Specifically, the
	ingress node MUST NOT send a PathTear message before a Resv message		ingress node MUST NOT send a PathTear message before a Resv message
	containing the H bit is received. The ingress node MAY choose to		containing the H bit is received. The ingress node MAY choose to
	report the failure in the CP to MP handover procedure via the MP		report the failure in the CP to MP handover procedure via the MP.
	5. Alternative Way Of Retrieving Information Needed For MP To CP		The CP to MP handover procedure can fail also due to two causes:
	Handover		PathTear lost or node down. In the former case, if the LSP is not
			under MP control after the Expiration Timer elapses, a manual
			intervention from the network operator is requested, while in the
			latter case different scenarios may happen:
			- CASE I - Path message and node down
			| Path | Path X |
			|--------------->|--------------X |
			| | |
			| | X |
			| | | |
			| | | |
			Ingress LER LSR A LSR B Egress LER
			Per [RFC 3473] section 7.2.2 the ingress node should wait for a
			configurable amount of time (30 seconds by default) and then send a
			PathTear message. In this case the normal deletion procedure MUST
			NOT be followed. When the Expiration timer elapses a manual
			intervention from network operator is requested.
			- CASE II - Resv message and node down
			| Path | Path | Path |
			|--------------->|--------------->|--------------->|
			| | | Resv |
			| | Resv |<---------------|
			| X X---------| |
			| | |
			| X | |
			| | | |
			Ingress LER LSR A LSR B Egress LER
			The procedure to be followed is the same depicted in CASE I. The
			network operator can ask for the automatic CP to MP procedure again
			after the failed node comes back up. Per [RFC 3473] section 7.2 the
			nodes will forward the new Path and Resv messages correctly.
			- CASE III - PathTear message and node down
			| Path | Path | Path |
			|--------------->|--------------->|--------------->|
			| Resv | Resv | Resv |
			|<---------------|<---------------|<---------------|
			| PathTear | | |
			|--------------->| PathTear X |
			| |------------X |
			| | X |
			| | | |
			Ingress LER LSR A LSR B Egress LER
			This scenario can be managed as a normal PathTear lost described
			above in this section.
			5. Minimum Information for MP to CP Handover
	An alternative way of getting the LSP related information required		An alternative way of getting the LSP related information required
	for the MP to CP handover is also defined in this draft. The		for the MP to CP handover is also defined in this draft. The
	rationale behind this way is that only a minimal set of information		rationale behind this way is that only a minimal set of information
	is handed over from MP to CP at LSPs Ingress node. Instead of		is handed over from MP to CP at LSPs Ingress node. Instead of
	collecting within MP all the LSP relevant information down to the		collecting within MP all the LSP relevant information down to the
	Label level, formatting it to an ERO and passing it to CP, as in		Label level, formatting it to an ERO and passing it to CP, as in
	previously described solution, it is possible to start with a minimum		previously described solution, it is possible to start with a minimum
	amount of information. At the ingress node, the information needed		amount of information. The full ERO method and the partial/no ERO
	to specify the LSP is the outgoing interface ID, upstream label and		one do not exclude each other; both methods are required.
	downstream label of this interface and the egress node ID. The
	remaining information about an existing LSP can then be collected hop		At the ingress node, the information needed to specify the LSP is the
	by hop, as the signaling is going on, by looking up the cross-		outgoing interface ID, upstream label and downstream label of this
	connection table in DP at each node along the LSP path.		interface and the egress node ID. The remaining information about an
			existing LSP can then be collected hop by hop, as the signaling is
			going on, by looking up the cross-connection table in DP at each node
			along the LSP path.
	Starting from the information available at ingress LER about the		Starting from the information available at ingress LER about the
	outgoing interface ID of that ingress node, the incoming interface ID		outgoing interface ID of that ingress node, the incoming interface ID
	of next hop can be found by looking up the link resource table/		of next hop can be found by looking up the link resource table/
	database in the LER itself.		database in the LER itself.
	The Path message is hence built with the LABEL_SET Object ([RFC3473])		The Path message is hence built with the LABEL_SET Object ([RFC3473])
	and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label		and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label
	and downstream label of ingress outgoing interface of the LSP are		and downstream label of ingress outgoing interface of the LSP are
	included in these two objects. In addition to above mentioned		included in these two objects. In addition to above mentioned
	skipping to change at page 14, line 46		skipping to change at page 17, line 14
	and the upstream and downstream labels of this interface is extracted		and the upstream and downstream labels of this interface is extracted
	from it and it is used to find next hop outgoing interface ID and the		from it and it is used to find next hop outgoing interface ID and the
	upstream/downstream labels by looking up the DP cross-connection		upstream/downstream labels by looking up the DP cross-connection
	table.		table.
	After having determined in this way the parameters describing the		After having determined in this way the parameters describing the
	LSPs next hop, the outgoing Path message to be sent is built		LSPs next hop, the outgoing Path message to be sent is built
	replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with		replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with
	the looked-up values of upstream and downstream labels.		the looked-up values of upstream and downstream labels.
	By repeating this procedure for each transit node along the LSP path,		By repeating this procedure for each transit node along the LSP, it
	it is possible to make the handover Path message reach the egress		is possible to make the handover Path message reach the egress node,
	node, exactly following the LSP that is in place over DP. The ERO		exactly following the LSP that is in place over DP. The ERO MAY in
	MAY in this case be included in the Path message as an optional		this case be included in the Path message as an optional object, and
	object, and MAY be filled with the LSP relevant information down to		MAY be filled with the LSP relevant information down to either the
	either the port level with interface ID or the Label level with		port level with interface ID or the Label level with upstream and
	upstream and downstream labels. The ERO can be used to check the		downstream labels. The ERO can be used to check the consistency of
	consistency of resource in DP down to the port level or label level		resource in DP down to the port level or label level at each
	at each intermediate node along the LSP path.		intermediate node along the LSP path.
	Where the DP path continues beyond the egress, by indicating the		Where the DP path continues beyond the egress, by indicating the
	Egress label at the head-end of an LSP, the traffic can be directed		Egress label at the head-end of an LSP, the traffic can be directed
	to the right destination. The GMPLS Signaling Procedure for Egress		to the right destination. The GMPLS Signaling Procedure for Egress
	Control is described in [RFC4003]		Control is described in [RFC4003]
	6. RSVP Message Formats		6. RSVP Message Formats
	This memo does not introduce any modification in RSVP messages object		This memo does not introduce any modification in RSVP messages object
	composition.		composition.
	skipping to change at page 15, line 27		skipping to change at page 17, line 44
	7. Objects Modification		7. Objects Modification
	The modifications required concern two RSVP objects: the ADMIN_STATUS		The modifications required concern two RSVP objects: the ADMIN_STATUS
	and the ERROR_SPEC Object.		and the ERROR_SPEC Object.
	7.1. Administrative Status Object		7.1. Administrative Status Object
	This memo introduces a new flag into the ADMIN_STATUS object. The		This memo introduces a new flag into the ADMIN_STATUS object. The
	ADMIN_STATUS Object is defined in [RFC3473]. This document uses the		ADMIN_STATUS Object is defined in [RFC3473]. This document uses the
	H bit of the ADMIN_STATUS Object. The bit is bit number (TBD by		H bit of the ADMIN_STATUS Object. The bit is bit number (TBD by
	IANA). The format of the ADMIN_STATUS Object is:		IANA) (25).
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num(196)| C-Type (1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Reserved |H|L|I|C|T|A|D|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The different flags are defined as follows:
	- Reflect (R): 1 bit - Defined in [RFC3471]
	- Handover (H): 1bit
	When set, the H bit indicates that a Handover procedure for the
	transfer of LSP ownership between Management and Control Planes is
	ongoing.
	- Lockout (L): 1 bit - Defined in [RFC4872]
	- Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783]
	- Call Control (C): 1 bit - Defined in [RFC3471]
	- Testing (T): 1 bit - Defined in [RFC3471]
	- Administratively down (A): 1 bit - Defined in [RFC4974]
	- Deletion in progress (D): 1 bit - Defined in [RFC3471]
	7.2. Error Spec Object		7.2. Error Spec Object
	It is possible that a failure, such as the loss of DCN connection or		It is possible that a failure, such as the loss of DCN connection or
	the restart of a node, occurs during the LSP ownership handing over.		the restart of a node, occurs during the LSP ownership handing over.
	In this case the LSP handover procedure is interrupted, the ownership		In this case the LSP handover procedure is interrupted, the ownership
	of the LSP must remain with the ownership prior to the initiation of		of the LSP must remain with the ownership prior to the initiation of
	the handover procedure. It is important that the transaction failure		the handover procedure. It is important that the transaction failure
	does not affect the DP. The LSP is kept in place and no traffic hit		does not affect the DP. The LSP is kept in place and no traffic hit
	occurs.		occurs.
	The failure is signaled by PathErr in the upstream direction and		The failure is signaled by PathErr in the upstream direction and
	PathTear Messages in the downstream direction. The PathErr messages		PathTear Messages in the downstream direction. The PathErr messages
	include an ERROR_SPEC Object specifying the causes of the failure.		include an ERROR_SPEC Object specifying the causes of the failure.
	skipping to change at page 16, line 30		skipping to change at page 18, line 19
	occurs.		occurs.
	The failure is signaled by PathErr in the upstream direction and		The failure is signaled by PathErr in the upstream direction and
	PathTear Messages in the downstream direction. The PathErr messages		PathTear Messages in the downstream direction. The PathErr messages
	include an ERROR_SPEC Object specifying the causes of the failure.		include an ERROR_SPEC Object specifying the causes of the failure.
	This memo introduces a new Error Code (with different Error Values)		This memo introduces a new Error Code (with different Error Values)
	into the ERROR_SPEC Object, defined in [RFC2205].		into the ERROR_SPEC Object, defined in [RFC2205].
	The defined Error Code is "Handover Procedure Failure", and its value		The defined Error Code is "Handover Procedure Failure", and its value
	is (TBD by IANA)(33). For this Error Code the following Error Values		is (TBD by IANA)(35). For this Error Code the following Error Values
	are defined:		are defined:
	1 = Cross-connection mismatch		1 = Cross-connection mismatch
	2 = Other failure		2 = Other failure
	8. Compatibility		8. Compatibility
	The main requirement for Handover procedure to work is that all nodes		The main requirement for Handover procedure to work is that all nodes
	along the path MUST support the extension defined in this draft.		along the path MUST support the extension defined in this draft.
	skipping to change at page 17, line 12		skipping to change at page 18, line 47
	We wish to thank Adrian Farrel and Lou Berger for their assistance		We wish to thank Adrian Farrel and Lou Berger for their assistance
	and precious advices to prepare this draft for publication. We also		and precious advices to prepare this draft for publication. We also
	wish to thank Nicola Ciulli (Nextworks), that contributed to the		wish to thank Nicola Ciulli (Nextworks), that contributed to the
	initial stage of this draft.		initial stage of this draft.
	10. Contributors		10. Contributors
	Shan Zhu		Shan Zhu
	Fujitsu Network Communications Inc.		Fujitsu Network Communications Inc.
	2801 Telecom Parkway,		2801 Telecom Parkway,
	Richardson, Texas 75082		Richardson, Texas 75082 USA
	USA
	Email: Shan.Zhu@us.fujitsu.com		Email: Shan.Zhu@us.fujitsu.com
	Tel: +1-972-479-2041		Tel: +1-972-479-2041
	Igor Bryskin		Igor Bryskin
	ADVA Optical Networking Inc		ADVA Optical Networking Inc
	7926 Jones Branch Drive		7926 Jones Branch Drive
	Suite 615		Suite 615
	McLean, VA - 22102		McLean, VA - 22102
	Email: ibryskin@advaoptical.com		Email: ibryskin@advaoptical.com
			Francesco Fondelli
			Ericsson
			Via Negrone 1/A
			Genova - 16145
			Email: francesco.fondelli@ericsson.com
	Lou Berger		Lou Berger
	LabN Consulting, LLC		LabN Consulting, LLC
	Phone: +1 301 468 9228		Phone: +1 301 468 9228
	EMail: lberger@labn.net		EMail: lberger@labn.net
	11. Security Considerations		11. Security Considerations
	The procedures described in this document rely completely on RSVP-TE		The procedures described in this document rely completely on RSVP-TE
	messages and mechanism. The use of H bit set in ADMIN_STATUS Object		messages and mechanism. The use of H bit set in ADMIN_STATUS Object
	basically informs the receiving entity that no operations are to be		basically informs the receiving entity that no operations are to be
	done over DP as consequence of such special signaling flow. Using		done over DP as consequence of such special signaling flow. Using
	specially flagged signaling messages we want to limit the function of		specially flagged signaling messages we want to limit the function of
	setup and tear down messages to CP, making them not effective over		setup and tear down messages to CP, making them not effective over
	related DP resource usage. So, no additional or special issues are		related DP resource usage.
	arisen by adopting this procedure, that aren't already brought up by
	the use of the same messages, without H bit setting, for LSP control.		However the handover procedures allow the control plane to be used to
	For RSVP-TE Security please refer to [RFC3473].		take an LSP out of the control of the Management Plane. This could
			cause considerable disruption and could introduce a new security
			concern. As a consequence the use of GMPLS security techniques is
			more important. For RSVP-TE Security please refer to [RFC3473],
			while for GMPLS security framework please refer to [sec-fwk].
	12. IANA Considerations		12. IANA Considerations
	IANA has been asked to manage the bit allocations for the		IANA has been asked to manage the bit allocations for the
	ADMIN_STATUS Object ([RFC3473]). This document requires the		ADMIN_STATUS Object ([RFC3473]). This document requires the
	allocation of the Handover bit: the H bit. IANA is requested to		allocation of the Handover bit: the H bit. IANA is requested to
	allocate a bit for this purpose.		allocate a bit for this purpose.
			Bit Number Hex Value Name Reference
			---------- ----------- ------------------------------------ ---------
			25 0x00000040 Handover (H) [This.I-D]
			IANA has also been asked to allocate a new error code:
			35 Handover failure
			This Error Code has the following globally-defined Error
			Value sub-code:
			1 = Cross-connection mismatch
			2 = Other failure
	13. References		13. References
	13.1. Normative References		13.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.		Functional Specification", RFC 2205, September 1997.
	[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,		[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
	and S. Molendini, "RSVP Refresh Overhead Reduction		and S. Molendini, "RSVP Refresh Overhead Reduction
	Extensions", RFC 2961, April 2001.		Extensions", RFC 2961, April 2001.
			[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
			(GMPLS) Signaling Functional Description", RFC 3471,
			January 2003.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		(GMPLS) Signaling Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
			[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
			(GMPLS) Architecture", RFC 3945, October 2004.
	[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress		[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
	Control", RFC 4003, February 2005.		Control", RFC 4003, February 2005.
	[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
	RSVP-TE Signaling Extensions in Support of Calls",
	RFC 4974, August 2007.
	13.2. Informational References		13.2. Informational References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Functional Description", RFC 3471,
	January 2003.
	[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information",
	RFC 4783, December 2006.
	[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
	Extensions in Support of End-to-End Generalized Multi-
	Protocol Label Switching (GMPLS) Recovery", RFC 4872,
	May 2007.
	[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,		[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
	"Requirements for the Conversion between Permanent		"Requirements for the Conversion between Permanent
	Connections and Switched Connections in a Generalized		Connections and Switched Connections in a Generalized
	Multiprotocol Label Switching (GMPLS) Network", RFC 5493,		Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
	April 2009.		April 2009.
			[sec-fwk] Fang, L., "Security Framework for MPLS and GMPLS
			Networks", July 2009.
	Authors' Addresses		Authors' Addresses
	Diego Caviglia		Diego Caviglia
	Ericsson		Ericsson
	Via A. Negrone 1/A		Via A. Negrone 1/A
	Genova - Sestri Ponente		Genova - Sestri Ponente
	Italy		Italy
	Email: diego.caviglia@ericsson.com		Email: diego.caviglia@ericsson.com
	Daniele Ceccarelli		Daniele Ceccarelli
	Ericsson		Ericsson
	Via A. Negrone 1/A		Via A. Negrone 1/A
	Genova - Sestri Ponente		Genova - Sestri Ponente
	Italy		Italy
	Email: daniele.ceccarelli@ericsson.com		Email: daniele.ceccarelli@ericsson.com
	Dino Bramanti		Dino Bramanti
	Ericsson		Ericsson
	Via Moruzzi 1 C/O Area Ricerca CNR
	Pisa
	Italy
	Email: dino.bramanti@ericsson.com
	Dan Li		Dan Li
	Huawei Technologies		Huawei Technologies
	F3-5-B R&D Center, Huawei Base		F3-5-B R&D Center, Huawei Base
	Shenzhen 518129		Shenzhen 518129
	P.R.China		P.R.China
	Email: danli@huawei.com		Email: danli@huawei.com
	Snigdho Bardalai		Snigdho Bardalai
	Fujitsu Network		Fujitsu Network
	2801 Telecom Parkway		2801 Telecom Parkway
	Richrdson, Texas 75082		Richrdson, Texas 75082
	USA		USA
	Email: Snigdho.Bardalai@us.fujitsu.com		Email: Snigdho.Bardalai@us.fujitsu.com
End of changes. 60 change blocks.
	250 lines changed or deleted		327 lines changed or added
This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/