draft-ietf-ccamp-pc-spc-rsvpte-ext-06.txt		draft-ietf-ccamp-pc-spc-rsvpte-ext-07.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: July 17, 2010 Ericsson		Expires: August 19, 2010 Ericsson
	D. Li		D. Li
	Huawei Technologies		Huawei Technologies
	S. Bardalai		S. Bardalai
	Fujitsu Network		Fujitsu Network
	January 13, 2010		February 15, 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-06		draft-ietf-ccamp-pc-spc-rsvpte-ext-07
	Abstract		Abstract
	In a transport network scenario, where Data Plane connections are		In a transport network scenario, where Data Plane connections are
	controlled either by a Generalized Multi-Protocol Label Switching		controlled either by a Generalized Multi-Protocol Label Switching
	(GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a		(GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a
	Management System (Permanent Connections - PC) may independently		Management System (Permanent Connections - PC) may independently
	coexist, the ability of transforming an existing PC into a SPC and		coexist, the ability of transforming an existing PC into a SPC and
	vice versa - without actually affecting Data Plane traffic being		vice versa - without actually affecting Data Plane traffic being
	carried over it - is a requirement. The requirements for the		carried over it - is a requirement. The requirements for the
	conversion between permanent connections and switched connections in		conversion between permanent connections and switched connections in
	a GMPLS Network are defined in [RFC5493].		a GMPLS Network are defined in [RFC5493].
	This memo describes an extension to GMPLS RSVP-TE signaling that		This memo describes an extension to GMPLS RSVP-TE signaling that
	enables the transfer of connection ownership between the Management		enables the transfer of connection ownership between the Management
	and the Control Planes. Such a transfer is referred to as a		and the Control Planes. Such a transfer is referred to as a
	Handover. This document defines all Handover related procedures.		Handover. This document defines all Handover related procedures.
	This includes the handling of failure conditions and subsequent		This includes the handling of failure conditions and subsequent
	reversion to original state. A basic premise of the extension is		reversion to original state. A basic premise of the extension is
	that the handover procedures must never impact an already established		that the handover procedures must never impact an already established
	Data plane.		Data plane connection.
	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 2, line 13		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 July 17, 2010.		This Internet-Draft will expire on August 19, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Dedication . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 6
	4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7		4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7
	4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7		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 . . . . . . . . . . . . . . . . 7		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 . . . . . . . . . . . . . . 8		Communication failure . . . . . . . . . . . . . . 8
	4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 9		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 . . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . 10		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 . . . . . . . . . . . . . . . . . . . . . 11		Restart . . . . . . . . . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . 14		Control Plane To Management Plane . . . . . . . . . . . . 14
	4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 14		4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 15
	5. Minimum Information for MP to CP Handover . . . . . . . . . . 16		5. Minimum Information for MP to CP Handover . . . . . . . . . . 17
	6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 17		6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 18
	7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17		7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 18
	7.1. Administrative Status Object . . . . . . . . . . . . . . . 17		7.1. Administrative Status Object . . . . . . . . . . . . . . . 18
	7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 17		7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18
	8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18		8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 19		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 20		13.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	13.2. Informational References . . . . . . . . . . . . . . . . . 21		13.2. Informational References . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	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 the 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 Generalized MPLS (GMPLS) [RFC3945] Control Plane		The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane
	(CP) in a network that is already in service - controlled by NMS at		(CP) in a network that is already in service - controlled by NMS at
	MP level - introduces the need for a procedure able to coordinate a		MP level - introduces the need for a procedure able to coordinate a
	controlled handover of a 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 an LSP in any DP switching technology and any		memo can be applied to a Label Switched Path (LSP) in any DP
	network architecture.		switching technology and any network architecture.
	This memo describes an extension to GMPLS RSVP-TE signaling that		This memo describes an extension to GMPLS Resource reSerVation
	enables the handover of connection ownership between the Management		Protocol - Traffic Engineering (RSVP-TE) [RFC3471], [RFC3473]
	and the Control Planes. All handover related procedures are defined		signaling that enables the handover of connection ownership between
	below. This includes the handling of failure conditions and		the Management and the Control Planes. All handover related
	subsequent reversion to original state. A basic premise of the		procedures are defined below. This includes the handling of failure
	extension is that the handover procedures must never impact the		conditions and subsequent reversion to original state. A basic
	exchange of user data on LSPs that are already established in the DP.		premise of the extension is that the handover procedures must never
			impact the exchange of user data on LSPs that are already established
			in the DP.
	1.1. Dedication		1.1. Dedication
	We would like to dedicate this work to our friend and colleague Dino		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		Bramanti, who passed away at the early age of 38. Dino has been
	involved in this work since its beginning.		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",
	skipping to change at page 5, line 22		skipping to change at page 5, line 24
	The modification defined in this document refers only to the		The modification defined in this document refers only to the
	ADMIN_STATUS Object, that is, the message flow is left unmodified for		ADMIN_STATUS Object, that is, the message flow is left unmodified for
	both LSP set-up and deletion. Moreover a new Error Value is defined		both LSP set-up and deletion. Moreover a new Error Value is defined
	to identify the failure of a Handover procedure.		to identify the failure of a Handover procedure.
	The following paragraphs give detailed description of the "MP to CP		The following paragraphs give detailed description of the "MP to 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 defined bit called H bit.		newly defined bit called H bit.
	The MP to CP handover procedures support two different methods for		Just as when setting up an LSP using the CP [RFC3473], the Path
	retrieving required information. The primary one consists of		message may contain full information about the explicit route
	receiving the full Explicit Route Object (ERO) from the MP while the		including the links and labels traversed by the LSP. This
	alternative one is described in Section 5.		information is encoded in the Explicit Route Object (ERO), and must
			be supplied by the MP using details recorded when the LSP was
			provisioned, or collected by the MP by inspecting the nodes along the
			path.
	Please note that if the primary method is used the labels SHOULD be		Alternatively, and also just as when setting up an LSP using the CP
	included in the ERO and for bidirectional LSPs both upstream and		[RFC3473] the ERO may include less information such that the details
	downstream labels SHOULD be included. Per Section 5.1.1. of		of the next hop have to be determined by each node along the LSP as
	[RFC3473], the labels are indicated on an output basis. As		it processes the Path message. This approach may be desirable when
	described, this means that the labels are used by the upstream node		the full information is not available to the MP or cannot be passed
	to create the LABEL_SET Object and, for bidirectional LSPs,		to the head-end node when initiating the handover from MP to CP.
	UPSTREAM_LABEL Object used in the outgoing Path message.
			This section (Section 4) describes the general procedures and
			protocol extensions for MP to CP handover, and uses the case of a
			fully detailed ERO to describe the mechanism. Section 5 describes
			how each node behaves in the case of a limited amount of information
			in the ERO.
			Note that when handover is being performed for a bidirectional LSP
			and the ERO contains full information including labels, the ERO
			SHOULD include both upstream and downstream labels. Per Section
			5.1.1 of [RFC3473], the labels are indicated on an output basis; this
			means that the labels are used by the upstream node to create the
			LABEL_SET Object and, for bidirectional LSPs, the 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.
	skipping to change at page 6, line 15		skipping to change at page 6, line 33
	action MUST NOT be taken.		action MUST NOT be taken.
	The ingress signals the LSP using a Path message with the H bit and R		The ingress signals the LSP using a Path message with the H bit and R
	bit set in the ADMIN_STATUS object. In this mode of handover, the		bit set in the ADMIN_STATUS object. In this mode of handover, the
	Path message also carries an ERO that includes Label subobjects		Path message also carries an ERO that includes Label subobjects
	indicating the labels used by the LSP at each hop. The ingress MUST		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		start the Expiration timer (see Section 4.2.1.2 for expiration of
	this timer). Such timer SHOULD be configurable per LSP and have a		this timer). Such timer SHOULD be configurable per LSP and have a
	default value of 30 seconds.		default value of 30 seconds.
	Each LSR that receives a Path message with the H bit set checks to		Each Label Switching Router (LSR) that receives a Path message with
	see whether there is any matching Path state.		the H bit set checks to see whether there is any matching Path state.
	- If matching Path state is found with the H bit set, this is a		- If matching Path state is found with the H bit set, this is a
	Path refresh and should be treated accordingly [RFC3473].		Path refresh and should be treated accordingly [RFC3473].
	- If matching Path state is found with the H bit clear, this is an		- If matching Path state is found with the H bit clear, this is an
	error and MUST be treated according to the error case description		error and MUST be treated according to the error case description
	in Section 4.2.1.1		in Section 4.2.1.1
	- If no Path state is found, the LSR goes on to check whether		- If no Path state is found, the LSR goes on to check whether
	there is any matching Data Plane state.		there is any matching Data Plane state.
	- If no matching Data Plane state is found (including only		- If no matching Data Plane state is found (including only
	partially matching Data Plane state), this is an error or a race		partially matching Data Plane state), this is an error or a race
	skipping to change at page 6, line 47		skipping to change at page 7, line 18
	A transit LSR MUST process each Resv according to the normal rules of		A transit LSR MUST process each Resv according to the normal rules of
	[RFC3473].		[RFC3473].
	When an ingress LSR receives a Resv message carrying the H bit set,		When an ingress LSR receives a Resv message carrying the H bit set,
	it checks the Expiration Timer.		it checks the Expiration Timer.
	- If the timer is not running, the Resv is treated as a refresh and		- If the timer is not running, the Resv is treated as a refresh and
	no special action is taken [RFC3473].		no special action is taken [RFC3473].
	- If the timer is running, the ingress MUST cancel the timer and MAY		- If the timer is running, the ingress MUST cancel the timer and
	notify the operator that the first stage of handover is complete.		SHOULD notify the operator that the first stage of handover is
	The ingress MUST send a Path message that is no different from the		complete. The ingress MUST send a Path message that is no different
	previous message except that the H bit MUST be clear.		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		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		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		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		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		the egress LSR. Each LSR SHOULD release any associated MP state
	associated with the LSP when it receives the Path message with H bit		associated with the LSP when it receives the Path message with H bit
	clear.		clear, but MAY retain the information according to local policy for
			use in future MP processing.
	When the ingress receives a Resv with the H bit clear, the handover		When the ingress receives a Resv with the H bit clear, the handover
	is completed. The ingress SHOULD notify the operator that the		is completed. The ingress SHOULD notify the operator that the
	handover is correctly completed.		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 Handover, two different failure scenarios can		In the case of MP to CP Handover, two different failure scenarios can
	happen: Path Failure and Resv Failure. Moreover, each failure can be		happen: Path Failure and Resv Failure. Moreover, each failure can be
	due to two different causes: DP failure or Communication Failure. In		due to two different causes: DP failure or Communication Failure. In
	skipping to change at page 7, line 43		skipping to change at page 8, line 14
	| Path | | |		| Path | | |
	|--------------->| Path | |		|--------------->| Path | |
	| |---------------X| |		| |---------------X| |
	| | PathErr | |		| | 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		Figure 1: 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, the node detecting the error MUST respond to the
	received the Path message MUST send a PathErr message in the upstream		received Path message with a PathErr message, and MUST abort the
	direction and the handover procedure is aborted. Upon receiving the		handover procedure. The PathErr message SHOULD have the
	PathErr message the Path state of the node MUST be removed. The		Path_State_Removed flag set [RFC3473], but implementations MAY retain
	PathErr message SHOULD have the Path_State_Removed flag set.		their local state and wait for Path state timeout as per normal RSVP
			processing.
	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 and the associated DP resources MUST NOT be
	indicates that a Handover is in progress (based on the H bit in the		impacted. If the local CP state indicates that a Handover is in
	Path message) the associated DP resources MUST NOT be impacted during		progress (based on the H bit in the Path message) the LSR MUST revert
	such processing and the LSR MUST revert the LSP ownership to the MP.		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 are		Other possible scenarios are shown in the following pictures and are
	based on the 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| |
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Path Msg and Communication Failure (reliable delivery)		Figure 2: MP2CP - Path Msg and Communication Failure (reliable
			delivery)
	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 | 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)		Figure 3: MP2CP - Path Msg and Communication Failure (no reliable
			delivery)
	If the Resv message is not received before 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. Please note that any node that has forwarded a Path		Section 4.2.1.1. Please note that any node that has forwarded a Path
	(LSR A), i.e. has installed local path state, will send a PathTear		(LSR A), i.e. has installed local path state, will send a PathTear
	when that state is removed (accordingly to [RFC2205]).		when that state is removed (accordingly to [RFC2205]).
	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,
	(in case there has been any change in the data plane during the		(in case there has been any change in the data plane during the
	signaling) the node MUST send a PathErr message in the upstream		signaling) the node MUST send a PathErr message [RFC2205] in the
	direction. The PathErr message is constructed and processed as		upstream direction. The PathErr message is constructed and processed
	defined above in Section 4.2.1.1. The failure detection node MUST		as defined above in Section 4.2.1.1. The failure detection node MUST
	also send a PathTear message downstream. The PathTear message is		also send a PathTear message downstream. The PathTear message is
	constructed and processed as defined above in Section 4.2.1.1.		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		Figure 4: 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 Figure 4, the failure occurs in LSR A. A
	A PathTear message is sent towards B and a PathErr message (with		PathTear message is sent towards B and a PathErr message (with
	ErrorCode set to "Handover Procedure Failure") is sent in the		ErrorCode set to "Handover Procedure Failure") is sent in the
	upstream direction. The PathErr and PathTear messages remove 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. A node that receives		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		a PathTear 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		state, but MUST NOT change data plane state. It MUST return LSP
	ownership to the MP.		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
	message delivery based on the mechanism defined in [RFC2961]. After		message delivery based on the mechanism defined in [RFC2961]. After
	a correct forwarding of the Path message along the nodes of the LSP,		a correct forwarding of the Path message along the nodes of the LSP,
	the Egress LSR sends a Resv message in the opposite direction. It		the Egress LSR sends a Resv message in the opposite direction. It
	might happen that the Resv message does not reach the ingress LER or		might happen that the Resv message does not reach the ingress Label
	an LSR, say LSR A. LSR B MUST send a Resv message again for a		Edge Router (LER) or an LSR, say LSR A. LSR B MUST send a Resv
	configurable number of times and then, if the delivery does not		message again for a configurable number of times and then, if the
	succeed, the adoption procedure will be aborted (via the Expiration		delivery does not succeed, the adoption procedure will be aborted
	timer).		(via the Expiration timer).
	| Path | Path | Path |		| Path | Path | Path |
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| | | Resv |		| | | Resv |
	| | Resv |<---------------|		| | Resv |<---------------|
	| | X---------| |		| | X---------| |
	| | X---------| |		| | X---------| |
	| | ... | |		| | ... | |
	| | X---------| |		| | X---------| |
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress
			LSR A LSR B Egress LER
	MP2CP - Resv Error and Communication Failure (reliable delivery)		Figure 5: MP2CP - Resv Error and Communication Failure (reliable
			delivery)
	Considering that the Resv message did not manage to reach LSR A, it		Considering that the Resv message did not manage to reach LSR A, it
	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.2.1.1 and the LSP ownership
	the Management Plane.		returned to the Management Plane.
	The following picture, on the other hand, shows the scenario in which		Figure 6, on the other hand, shows the scenario in which no reliable
	no reliable delivery mechanism is implemented.		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)		Figure 6: 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.
	Case I - Finite Restart Time		Case I - Finite Restart Time
	skipping to change at page 12, line 20		skipping to change at page 12, line 40
	| PathTear | |		| PathTear | |
	|-------X Restart Timer |		|-------X Restart Timer |
	| Expires |		| Expires |
	| PathErr | PathTear |		| PathErr | PathTear |
	| X--------|--------------->|		| X--------|--------------->|
	| | |		| | |
	| X | |		| X | |
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Node graceful restart - Case I		Figure 7: MP2CP - Node graceful restart - Case I
	Case II - Infinite Restart Time		Case II - Infinite Restart Time
	In this case, the Restart Time (see [RFC3473]) indicates that the		In this case, the Restart Time (see [RFC3473]) indicates that the
	restart of the sender's control plane may occur over an indeterminate		restart of the sender's control plane may occur over an indeterminate
	interval, i.e., is 0xffffffff. The sequence is quite similar to the		interval, i.e., is 0xffffffff. The sequence is quite similar to the
	previous one. In this sequence the restart timer will not expire in		previous one. In this sequence the restart timer will not expire in
	LSR B since it is run infinitely. Instead after LSR A restarts LSR B		LSR B since it is run infinitely. Instead after LSR A restarts LSR B
	MUST start the recovery timer. The recovery timer will expire since		MUST start the recovery timer. The recovery timer will expire since
	there will be no Path message with the RECOVERY LABEL received from		there will be no Path message with the RECOVERY LABEL received from
	skipping to change at page 13, line 22		skipping to change at page 13, line 30
	| | |		| | |
	| X | |		| X | |
	| | | |		| | | |
	| | Recovery Timer |		| | Recovery Timer |
	| | Expires |		| | Expires |
	| PathErr | PathErr | PathTear |		| PathErr | PathErr | PathTear |
	|<---------------|<---------------|--------------->|		|<---------------|<---------------|--------------->|
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Node graceful restart - Case II		Figure 8: MP2CP - Node graceful restart - Case II
	Case III		Case III
	Ingress LER did not abort the handover process. Once LSR A restarts		In this case, the ingress LER does not abort the handover process.
	the ingress LER MUST re-generate the Path message with the H bit set.		When LSR A restarts, the ingress LER detects the restart and MUST re-
	When LSR B receives the Path message it MAY generate a PathErr since		generate the Path message with the H bit set in order to re-start the
	the RECOVERY LABEL may not be present. The reason is LSR A may not		handover.
	have the label. Similarly LSR B and egress LER MUST NOT release the
	DP resources since the H bit is set.		When LSR B receives the Path message, it sees the H-bit set on the
			message and also sees that it has the H-bit set in its own state and
			that it has sent the Resv. But it is also aware that LSR A has
			restarted and could have sent a Path message with a RECOVERY LABEL
			object. LSR B may attempt to resume the handover process or may
			abort the handover. This choice is made according to local policy.
			If resuming the handover, LSR B MUST treat the received Path message
			as a retransmission, and MUST retransmit its Resv. If aborting
			handover, LSR B MUST return a PathErr and MUST send a PathTear
			downstream. In both cases, LSR B MUST NOT modify the DP state.
	| Path | Path | Path |		| Path | Path | Path |
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| | | Resv |		| | | Resv |
	| | Resv |<---------------|		| | Resv |<---------------|
	| X X---------| |		| X X---------| |
	| | |		| | |
	| X | |		| X | |
	| | | |		| | | |
	| Path | Path | |		| Path | Path | |
	|--------------->|--------------->| |		|--------------->|--------------->| |
	| PathErr | PathErr | PathTear |		| PathErr | PathErr | PathTear |
	|<---------------|<---------------|--------------->|		|<---------------|<---------------|--------------->|
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Node graceful restart - Case III		Figure 9: MP2CP - Node graceful restart - Case III
	4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To		4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To
	Management Plane		Management Plane
	Let's now consider the case of LSP Ownership Transfer From Control		Let's now consider the case of LSP Ownership Transfer From Control
	Plane To Management Plane. Also in this section we will analyze the		Plane To Management Plane. Also in this section we will analyze the
	handover procedure success and failure.		handover procedure success and failure.
	The scenario is still a DP connection between two nodes acting as		The scenario is still a DP connection between two nodes acting as
	ingress and egress for a LSP, but in this case the CP has the		ingress and egress for a LSP, but in this case the CP has the
	skipping to change at page 14, line 49		skipping to change at page 15, line 22
	state. In other words, a normal LSP tear down signaling is exchanged		state. In other words, a normal LSP tear down signaling is exchanged
	between nodes traversed by the LSP, but H bit set in the Path message		between nodes traversed by the LSP, but H bit set in the Path message
	indicates that no DP action has to correspond to CP signaling.		indicates that no DP action has to correspond to CP signaling.
	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. While the H bit is set
	ingress node MUST NOT send a PathTear message before a Resv message		in the Path state, a node MUST NOT send a PathTear when a failure is
	containing the H bit is received. The ingress node MAY choose to		detected. Instead, the failure is reported upstream using a PathErr.
	report the failure in the CP to MP handover procedure via the MP.		The only node that can send a PathTear is the ingress node, and it
			can only do this as a step in the procedures specified in this
			document. This applies to both MP to CP and CP to MP handover. The
			ingress node MAY choose to report the failure in the CP to MP
			handover procedure via the MP.
	The CP to MP handover procedure can fail also due to two causes:		The CP to MP handover procedure can fail also due to two causes:
	PathTear lost or node down. In the former case, if the LSP is not		PathTear lost or node down. In the former case, if the LSP is not
	under MP control after the Expiration Timer elapses, a manual		under MP control after the Expiration Timer elapses, a manual
	intervention from the network operator is requested, while in the		intervention from the network operator is requested, while in the
	latter case different scenarios may happen:		latter case different scenarios may happen:
	- CASE I - Path message and node down		- CASE I - Path message and node down
	| Path | Path X |		| Path | Path X |
	|--------------->|--------------X |		|--------------->|--------------X |
	| | |		| | |
	| | X |		| | X |
	| | | |		| | | |
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	Per [RFC 3473] section 7.2.2 the ingress node should wait for a		Figure 10: Case I - Path message and node down
			Per [RFC3473] section 7.2.2 the ingress node should wait for a
	configurable amount of time (30 seconds by default) and then send a		configurable amount of time (30 seconds by default) and then send a
	PathTear message. In this case the normal deletion procedure MUST		PathTear message. In this case the normal deletion procedure MUST
	NOT be followed. When the Expiration timer elapses a manual		NOT be followed. When the Expiration timer elapses a manual
	intervention from network operator is requested and normal, i.e., pre		intervention from network operator is requested and normal, i.e., pre
	CP to MP handover, LSP processing continues.		CP to MP handover, LSP processing continues.
	- CASE II - Resv message and node down		- CASE II - Resv message and node down
	| Path | Path | Path |		| Path | Path | Path |
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| | | Resv |		| | | Resv |
	| | Resv |<---------------|		| | Resv |<---------------|
	| X X---------| |		| X X---------| |
	| | |		| | |
	| X | |		| X | |
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
			Figure 11: Case II - Resv message and node down
	The procedure to be followed is the same depicted in CASE I. The		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		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		after the failed node comes back up. Per [RFC3473] section 7.2 the
	nodes will forward the new Path and Resv messages correctly.		nodes will forward the new Path and Resv messages correctly.
	- CASE III - PathTear message and node down		- CASE III - PathTear message and node down
	| Path | Path | Path |		| Path | Path | Path |
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| Resv | Resv | Resv |		| Resv | Resv | Resv |
	|<---------------|<---------------|<---------------|		|<---------------|<---------------|<---------------|
	| PathTear | | |		| PathTear | | |
	|--------------->| PathTear X |		|--------------->| PathTear X |
	| |------------X |		| |------------X |
	| | X |		| | X |
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	skipping to change at page 16, line 15		skipping to change at page 16, line 42
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| Resv | Resv | Resv |		| Resv | Resv | Resv |
	|<---------------|<---------------|<---------------|		|<---------------|<---------------|<---------------|
	| PathTear | | |		| PathTear | | |
	|--------------->| PathTear X |		|--------------->| PathTear X |
	| |------------X |		| |------------X |
	| | X |		| | X |
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
			Figure 12: Case III - PathTear message and node down
	This scenario can be managed as a normal PathTear lost described		This scenario can be managed as a normal PathTear lost described
	above in this section.		above in this section.
	5. Minimum Information for MP to CP Handover		5. Minimum Information for MP to CP Handover
	An alternative way of getting the LSP related information required		As described in Section 4, it is also possible for the ERO to contain
	for the MP to CP handover is also defined in this draft. The		less than the full set of path information for the LSP being handed
	rationale behind this way is that only a minimal set of information		over. This arises when only a minimal set of information is handed
	is handed over from MP to CP at LSPs Ingress node. Instead of		to the CP by the MP at the LSP's head end. Instead of collecting all
	collecting within MP all the LSP relevant information down to the		of the LSP information (including the labels) and formatting it into
	Label level, formatting it to an ERO and passing it to CP, as in		an ERO, as described in Section 4, it is possible to start with a
	previously described solution, it is possible to start with a minimum		minimum amount of information. The full ERO method and the
	amount of information. The full ERO method and the partial/no ERO		partial/no ERO method are not mutually exclusive; support of both
	one do not exclude each other; both methods are required.		methods are required.
	At the ingress node, the information needed to specify the LSP is the		At the ingress node, the information needed to specify the LSP is the
	outgoing interface ID, upstream label and downstream label of this		outgoing interface ID, upstream label and downstream label of this
	interface and the egress node ID. The remaining information about an		interface and the egress node ID. The remaining information about an
	existing LSP can then be collected hop by hop, as the signaling is		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		going on, by looking up the cross-connection table in DP at each node
	along the LSP path.		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
	skipping to change at page 18, line 31		skipping to change at page 19, line 15
	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.
	This requirement translates to an administrative requirement as it is		This requirement translates to an administrative requirement as it is
	not enforced at the protocol level. As defined, non-supporting will		not enforced at the protocol level. As defined, non-supporting nodes
	simply propagate the H bit without setting local state. This may		will simply propagate the H bit without setting local state. This
	result in an impact data traffic during the handover procedure.		may result in an impact on data traffic during the handover
			procedure.
	9. Acknowledgments
	We wish to thank Adrian Farrel and Lou Berger for their assistance
	and precious advices to prepare this draft for publication. We also
	wish to thank Nicola Ciulli (Nextworks), that contributed to the
	initial stage of this draft.
	10. Contributors
	Shan Zhu
	Fujitsu Network Communications Inc.
	2801 Telecom Parkway,
	Richardson, Texas 75082 USA
	Email: Shan.Zhu@us.fujitsu.com
	Tel: +1-972-479-2041
	Igor Bryskin
	ADVA Optical Networking Inc
	7926 Jones Branch Drive
	Suite 615
	McLean, VA - 22102
	Email: ibryskin@advaoptical.com
	Francesco Fondelli
	Ericsson
	Via Negrone 1/A
	Genova - 16145
	Email: francesco.fondelli@ericsson.com
	Lou Berger
	LabN Consulting, LLC
	Phone: +1 301 468 9228
	EMail: lberger@labn.net
	11. Security Considerations		9. 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.		related DP resource usage.
	However the handover procedures allow the control plane to be used to		However the handover procedures allow the control plane to be used to
	take an LSP out of the control of the Management Plane. This could		take an LSP out of the control of the Management Plane. This could
	cause considerable disruption and could introduce a new security		cause considerable disruption and could introduce a new security
	concern. As a consequence the use of GMPLS security techniques is		concern. As a consequence the use of GMPLS security techniques is
	more important. For RSVP-TE Security please refer to [RFC3473],		more important. For RSVP-TE Security please refer to [RFC3473],
	while for GMPLS security framework please refer to [sec-fwk].		while for GMPLS security framework please refer to [sec-fwk].
	12. IANA Considerations		10. 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		Bit Number Hex Value Name Reference
	25 0x00000040 Handover (H) [This.I-D]		---------- ----------- ----------------------------------- ---------
			25 0x00000040 Handover (H) [This.I-D]
	IANA has also been asked to allocate a new error code:		IANA has also been asked to allocate a new error code:
	35 Handover failure		35 Handover failure
	This Error Code has the following globally-defined Error		This Error Code has the following globally-defined Error
	Value sub-code:		Value sub-code:
	1 = Cross-connection mismatch		1 = Cross-connection mismatch
	2 = Other failure		2 = Other failure
	13. References		11. Acknowledgments
			We wish to thank Adrian Farrel, Lou Berger, Alan Elder, and Ben
			Campbell for their assistance and precious advices to prepare this
			draft for publication. We also wish to thank Nicola Ciulli
			(Nextworks) who contributed to the initial stage of this draft.
			12. Contributors
			Shan Zhu
			Fujitsu Network Communications Inc.
			2801 Telecom Parkway,
			Richardson, Texas 75082 USA
			Email: Shan.Zhu@us.fujitsu.com
			Tel: +1-972-479-2041
			Igor Bryskin
			ADVA Optical Networking Inc
			7926 Jones Branch Drive
			Suite 615
			McLean, VA - 22102
			Email: ibryskin@advaoptical.com
			Francesco Fondelli
			Ericsson
			Via Negrone 1/A
			Genova - 16145
			Email: francesco.fondelli@ericsson.com
			Lou Berger
			LabN Consulting, LLC
			Phone: +1 301 468 9228
			EMail: lberger@labn.net
			13. References
	13.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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.,
End of changes. 53 change blocks.
	151 lines changed or deleted		197 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/