draft-ietf-ccamp-pc-spc-rsvpte-ext-03.txt		draft-ietf-ccamp-pc-spc-rsvpte-ext-04.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: January 28, 2010 Ericsson		Expires: March 26, 2010 Ericsson
	D. Li		D. Li
	Huawei Technologies		Huawei Technologies
	S. Bardalai		S. Bardalai
	Fujitsu Network		Fujitsu Network
	July 27, 2009		September 22, 2009
	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-03		draft-ietf-ccamp-pc-spc-rsvpte-ext-04
	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 1, line 38
	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 January 28, 2010.		This Internet-Draft will expire on March 26, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 16		skipping to change at page 2, line 16
	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.
	In a transport network scenario, where Data Plane connections		In a transport network scenario, where Data Plane connections
	controlled either by GMPLS Control Plane (Soft Permanent Connections		controlled either by GMPLS Control Plane (Soft Permanent Connections
	- SPC) or by Management System (Permanent Connections - PC) may		- SPC) or by Management System (Permanent Connections - PC) may
	independently coexist, the ability of transforming an existing PC		independently coexist, the ability of transforming an existing PC
	into a SPC and vice versa - without actually affecting Data Plane		into a SPC and vice versa - without actually affecting Data Plane
	traffic being carried over it - is a requirement [RFC5493].		traffic being carried over it - is a requirement.
	This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471],		This memo describes an extension to GMPLS RSVP-TE signaling that
	[RFC3473], [RFC4872] signaling protocol, within GMPLS architecture,		enables the transfer of connection ownership between the Management
	to enable such connection ownership transfer and describes the		and the Control Planes. Such a transfer is referred to as a
	defined procedures. Failure conditions and subsequent roll back are		Handover. This document defines all Handover related procedures.
	also defined taking into account that an handover failure MUST NOT		This includes the handling of failure conditions and subsequent
	impact the already established data plane connections.		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
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4		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 . . . . . . . 6
	4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6		4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6
	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 . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . 7
	4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8		4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8
	4.2.2.1. MP to CP Handover Failure - Resv Error and		4.2.2.1. MP to CP Handover Failure - Resv Error and
	skipping to change at page 4, line 22		skipping to change at page 4, line 22
	The adoption of a GMPLS Control Plane (CP) over networks that are		The adoption of a GMPLS Control Plane (CP) over networks that are
	already in service - controlled by NMS at MP level - introduces the		already in service - controlled by NMS at MP level - introduces the
	need for a procedure able to coordinate a control handover of a		need for a procedure able to coordinate a control handover of a
	generic data plane connection from MP to CP.		generic 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 any kind of LSP and network architecture.
			This memo describes an extension to Generalized Multi-Protocol Label
			Switching (GMPLS) RSVP-TE (see [RFC3471] and [RFC3473]) signaling
			that enables the handover of connection ownership between the
			Management and the Control Planes. All handover related procedures
			are defined below. 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.
	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 impacting procedure that satisfies the requirements
	skipping to change at page 4, line 45		skipping to change at page 5, line 7
	disrupting user traffic flowing on them. Handover from MP to CP		disrupting user traffic flowing on them. Handover from MP to CP
	(i.e. when existing DP connection ownership and control is passed		(i.e. when existing DP connection ownership and control is passed
	from MP to CP) has been defined as mandatory requirement, while the		from MP to CP) has been defined as mandatory requirement, while the
	opposite operation, CP to MP handover, has been considered as a nice-		opposite operation, CP to MP handover, has been considered as a nice-
	to-have feature that can be seen as an emergency procedure to disable		to-have feature that can be seen as an emergency procedure to disable
	the CP and take the manual control of the LSP. For more details on		the CP and take the manual control of the LSP. For more details on
	requirements and motivations please refer to [RFC5493].		requirements and motivations please refer to [RFC5493].
	4. Procedures		4. Procedures
	The modification defined in this document refers only to		The modification defined in this document refers only to ADMIN_STATUS
	Administrative Status object, that is, the message flow is left		Object, that is, the message flow is left unmodified for both LSP
	unmodified for both LSP set-up and deletion. Moreover a new Error		set-up and deletion. Moreover a new Error Value is defined to
	Value is defined to identify the failure of a Handover procedure.		identify the failure of a Handover procedure.
	Following paragraphs give detailed description of defined "MP to CP		The following paragraphs give detailed description of defined "MP to
	handover" and "CP to MP handover" procedures, based on the usage a		CP handover" and "CP to MP handover" procedures, based on the usage a
	newly define bit called H bit.		newly define bit called H bit.
	MP to CP handover procedure foreseen 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 on
	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		A standard RSVP-TE signaling flow MUST be used to inform nodes about
	the ownership handover request. Such flow MUST be tagged with a		the ownership handover request. Such flows MUST be tagged with a new
	newly introduced flag, here named H bit and described in Section 7.1,		flag that is carried within the ADMIN_STATUS Object ([RFC3471] and
	that is set in the Administrative Status Object ([RFC3471] and		[RFC3473]). The new flag is referred to as the H bit and is
	[RFC3473]) of RSVP-TE messages. The H bit MUST be set in order to		described in Section 7.1. The H bit MUST be set in order to
	discriminate the handover procedure from normal, DP affecting, LSP		discriminate the handover procedure from normal, DP affecting, LSP
	setup/release procedure. The DP MUST NOT be affected from the		setup/release procedure. The DP MUST NOT be affected from the
	handover procedure.		handover procedure.
	The ingress node MUST send a Path message in the downstream direction		The ingress node MUST send a Path message in the downstream direction
	with the H and R ([RFC3471]) bit set. Upon receiving a Path Message		with the H and R ([RFC3471]) bit set. Upon receiving a Path Message
	containing an Administrative Status Object with the H bit set, each		containing an ADMIN_STATUS Object with the H bit set, each node MUST
	node MUST check if there is a local Path State matching the MP to CP		check if there is a local Path State matching the MP to CP Handover
	Handover request. If no local Path State exists, the node MUST		request. If no local Path State exists, the node MUST confirm that
	confirm that there is an existing DP state that corresponds to the		there is an existing DP state that corresponds to the Path message.
	Path message. In case such DP state exists (failure cases are
	defined in the next sections), local Path state MUST be installed.		In the case of DP state lack (failure cases are defined in the next
	The H bit MUST be stored in the local Path state.		sections), local Path state MUST be installed. The H bit MUST be
			stored in the local Path state.
	After propagating a Path message with the H bit set, a node MUST wait		After propagating a Path message with the H bit set, a node MUST wait
	for a Resv message including Administrative Status Object with H bit		for a Resv message including ADMIN_STATUS Object with H bit set.
	set. After the ingress node receives it, the actual migration of LSP		After the ingress node receives it, the actual migration of LSP
	information is complete, the LSP is left completely under control of		information is complete, the LSP is left completely under control of
	RSVP-TE within Control Plane.		RSVP-TE within Control Plane.
	If the Resv message is not received by the expiration of a timer		If the Resv message is not received by the expiration of a timer
	(called Expiration timer in the following) set by the ingress LER,		(called Expiration timer in the following) set by the ingress LER,
	the handover procedure is aborted, that is, a PathTear message MUST		the handover procedure is aborted, that is, a PathTear message MUST
	be sent in the downstream direction.		be sent in the downstream direction.
	In order to complete the Handover process the ingress node MUST send		In order to complete the Handover process the ingress node MUST send
	a Path message with the H bit cleared (set to zero) upon receipt of a		a Path message with the H bit cleared (set to zero) upon receipt of a
	corresponding Resv message. The R bit SHOULD NOT be set in this		corresponding Resv message. The R bit SHOULD NOT be set in this
	message. Downstream nodes MUST clear their local "Handover" state		message. Downstream nodes MUST clear their local "Handover" state
	based on a received Path message with the H bit cleared. This means		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		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		H bit, any state related to the former MP ownership of the LSP is
	lost. Normal ResvConf process occurs as normal. The handover		lost. Normal ResvConf process occurs as normal. The handover
	procedure does not modify the Confirmation procedure.		procedure does not modify the Confirmation procedure.
	In case the path of the LSP is not fully passed to the ingress LER,		When the path of the LSP is not fully passed to the ingress LER, each
	each node can determine the next hop looking at its data plane and		node can determine the next hop looking at its data plane and exploit
	exploit the similarity between the MP to CP Handover procedure and		the similarity between the MP to CP Handover procedure and the
	the Restart Procedure. Please refer to Section 5.		Restart Procedure. Please refer to Section 5.
	4.2. MP to CP Handover Procedure Failure Handling		4.2. MP to CP Handover Procedure Failure Handling
	In case of MP to CP Procedure, two different failure scenarios can		In the case of MP to CP Procedure, two different failure scenarios
	happen: Path Failure and Resv Failure. Moreover, each failure can be		can happen: Path Failure and Resv Failure. Moreover, each failure
	due to two different causes: DP failure or Communication Failure. In		can be due to two different causes: DP failure or Communication
	any case the LSP ownership MUST be immediately roll backed to the one		Failure. In any case the LSP ownership MUST be immediately roll
	previous to the handover procedure. A section for each combination		backed to the one previous to the handover procedure. A section for
	will be analyzed in the following.		each combination 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 | | |
	skipping to change at page 8, line 29		skipping to change at page 8, line 29
	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 by 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.
	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 case a failure occurs during the Resv message processing, the node		In the case of failure occurrence during the Resv message processing,
	MUST send a PathErr message in the upstream direction. The PathErr		the node MUST send a PathErr message in the upstream direction. The
	message is constructed and processed as defined above in		PathErr message is constructed and processed as defined above in
	Section 4.2.1.1. The failure detection node MUST also send a		Section 4.2.1.1. The failure detection node MUST also send a
	PathTear message downstream. The PathTear message is constructed and		PathTear message downstream. The PathTear message is constructed and
	processed as defined above in Section 4.2.1.1.		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 |
	skipping to change at page 9, line 19		skipping to change at page 9, line 19
	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.
	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
	In case a Resv message cannot reach one or more of the upstream		When a Resv message cannot reach one or more of the upstream nodes,
	nodes, the procedure is quite similar to the one previously seen		the procedure is quite similar to the one previously seen about the
	about the Path message. Even in this case it is possible to		Path message. Even in this case it is possible to distinguish two
	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 LER or
	an LSR, say LSR A. LSR B MUST send a Resv message again for a		an LSR, say LSR A. LSR B MUST send a Resv message again for a
	configurable number of times and then, if the delivery does not		configurable number of times and then, if the delivery does not
	succeed, the adoption procedure will be aborted (via the Expiration		succeed, the adoption procedure will be aborted (via the Expiration
	timer).		timer).
	skipping to change at page 10, line 30		skipping to change at page 10, line 30
	| | | |		| | | |
	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 case one of the nodes restarts and graceful restart is enabled		In the case of node restart and graceful restart is enabled then one
	then one of the following scenarios will happen.		of the following scenarios will happen.
	Case I		Case I - Finite Restart Time
	Restart timer is not infinite. In the sequence diagram below, assume		In this case, the Restart Time (see [RFC3473]) is finite, i.e., not a
	LSR A restarts. In case the ingress LER does not receive the Resv		value of 0xffffffff. In the sequence diagram below, assume LSR A
	message in time it MUST abort the handover process by generating a		restarts. If the ingress LER does not receive the Resv message in
	PathTear message downstream. Also, if LSR A does not complete the		time it MUST abort the handover process by generating a PathTear
	restart process within the restart time interval then LSR B MUST		message downstream. Also, if LSR A does not complete the restart
	start tearing down all LSPs between LSR A and LSR B and this includes		process within the restart time interval then LSR B MUST start
	the LSP that is being used to carry out the handover of MP resources		tearing down all LSPs between LSR A and LSR B and this includes the
	to CP. LSP B MUST generate a PathTear message downstream and a		LSP that is being used to carry out the handover of MP resources to
	PathErr message upstream. Both LSR B and the egress LER MUST NOT		CP. LSP B MUST generate a PathTear message downstream and a PathErr
	release the DP resources because in both nodes the H bit is set in		message upstream. Both LSR B and the egress LER MUST NOT release the
	the local Path state.		DP resources because in both nodes the H bit is set in the local Path
			state.
	| Path | Path | Path |		| Path | Path | Path |
	|--------------->|--------------->|--------------->|		|--------------->|--------------->|--------------->|
	| | | Resv |		| | | Resv |
	| | Resv |<---------------|		| | Resv |<---------------|
	| X X---------| |		| X X---------| |
	| 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		MP2CP - Node graceful restart - Case I
	Case II		Case II - Infinite Restart Time
	Restart timer is infinite. The sequence is quite similar to the		In this case, the Restart Time (see [RFC3473]) indicates that the
			restart of the sender's control plane may occur over an indeterminate
			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
	LSR A given the ingress node had already removed the local Path state		LSR A given the ingress node had already removed the local Path state
	after it aborts the handover process. Thus LSR B MUST tear-down the		after it aborts the handover process. Thus LSR B MUST tear-down the
	specific LSP that is being used to convert the MP resources to CP by		specific LSP that is being used to convert the MP resources to CP by
	generating a PathTear message downstream and PathErr message		generating a PathTear message downstream and PathErr message
	upstream. Similarly to the previous case both LSR B and the egress		upstream. Similarly to the previous case both LSR B and the egress
	LER MUST NOT release the DP resources because the H bit is set in the		LER MUST NOT release the DP resources because the H bit is set in the
	skipping to change at page 13, line 9		skipping to change at page 13, line 9
	|<---------------|<---------------|--------------->|		|<---------------|<---------------|--------------->|
	| | | |		| | | |
	Ingress LER LSR A LSR B Egress LER		Ingress LER LSR A LSR B Egress LER
	MP2CP - Node graceful restart - Case III		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 sections 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
	ownership and control of the LSP. The CP to MP handover procedure		ownership and control of the LSP. The CP to MP handover procedure
	MUST delete the existing RSVP-TE session information and MUST NOT		MUST delete the existing RSVP-TE session information and MUST NOT
	affect the cross-connected resources, but just move their ownership		affect the cross-connected resources, but just move their ownership
	to the MP.		to the MP.
	In other words, after LSP ownership transfer from CP to MP, the LSP		In other words, after LSP ownership transfer from CP to MP, the LSP
	is no longer under control of RSVP-TE, which is no more able to "see"		is no longer under control of RSVP-TE, which is no more able to "see"
	the LSP itself. The CP to MP handover procedure MUST be a standard		the LSP itself. The CP to MP handover procedure MUST be a standard
	LSP deletion procedure as described in Section 7.2.1 of [RFC3473].		LSP deletion procedure as described in Section 7.2.1 of [RFC3473].
	The procedure is initiated at the ingress node of the LSP by a MP		The procedure is initiated at the ingress node of the LSP by a MP
	entity. Ingress node and MP exchange the relevant information for		entity. Ingress node and MP exchange the relevant information for
	this task and then propagate it over CP by means of RSVP-TE tear down		this task and then propagate it over CP by means of RSVP-TE tear down
	signaling as described below.		signaling as described below.
	The ingress node MUST send a Path message in the downstream direction		The ingress node MUST send a Path message in the downstream direction
	with Handover and Reflect bits set in the Admin Status Object. No		with Handover and Reflect bits set in the ADMIN_STATUS Object. No
	action is taken over the DP and transit LSRs must forward such		action is taken over the DP and transit LSRs must forward such
	message towards the egress node. All of the nodes MUST keep track of		message towards the egress node. All of the nodes MUST keep track of
	the procedure storing the H and R bits in their local Path and Resv		the procedure storing the H bit in their local Path and Resv states.
	states. Then every node waits for the H bit to be received within		Then every node waits for the H bit to be received within the related
	the related Resv message. After the Resv message is received by the		Resv message. After the Resv message is received by the ingress LER,
	ingress LER, it MUST send a PathTear message in order to clear the		it MUST send a PathTear message in order to clear the whole LSP
	whole LSP information recorded on the RSVP-TE data structures of the		information recorded on the RSVP-TE data structures of the nodes.
	nodes. Downstream nodes processing a PathTear message which follows		Downstream nodes processing a PathTear message which follows a Path
	a Path message with the H bit set, MUST NOT remove any associated		message with the H bit set, MUST NOT remove any associated data plane
	data plane state. In other words, a normal LSP tear down signaling		state. In other words, a normal LSP tear down signaling is exchanged
	is exchanged between nodes traversed by the LSP, but H bit set in the		between nodes traversed by the LSP, but H bit set in the Path message
	Path message indicates that no DP action has to correspond to CP		indicates that no DP action has to correspond to CP signaling.
	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 be managed at		Failures during CP to MP handover procedure MUST NOT result in the
	signaling level as in normal LSP tear down procedure. The only		removal of any associated data plane state. To that end, when a Resv
	difference is the H bit set in Administrative Status Object inside		message containing an ADMIN_STATUS Object with the H bit is not
	Path message which MUST be read by receiving node and imposes that no		received during the period of time described in Section 7.2.2. of
	action has to be made over DP resource whose corresponding Control		[RFC3473] different processing is required. Specifically, the
	Plane record is involved in handover procedure.		ingress node MUST NOT send a PathTear message before a Resv message
			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
	5. Alternative Way Of Retrieving Information Needed For MP To CP		5. Alternative Way Of Retrieving Information Needed For MP To CP
	Handover		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. At the ingress node, the information needed
	to specify the LSP is the outgoing interface ID, upstream label and		to specify the LSP is the outgoing interface ID, upstream label and
	downstream label of this interface and the egress node ID. The		downstream label of this interface and the egress node ID. The
	remaining information about an existing LSP can then be collected hop		remaining information about an existing LSP can then be collected hop
	by hop, as the signalling is going on, by looking up the cross-		by hop, as the signaling is going on, by looking up the cross-
	connection table in DP at each node along the LSP path.		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
	objects, the Path message MUST include the Administrative Status		objects, the Path message MUST include the ADMIN_STATUS Object with H
	Object with H bit set, as already defined in previous chapters for		bit set, as already defined in previous chapters for the detailed ERO
	the detailed ERO based way of proceeding. Such handover Path is sent		based way of proceeding. Such handover Path is sent to the incoming
	to the incoming interface of next hop. When this Path message		interface of next hop. When this Path message reaches the second
	reaches the second node along the LSP path, the information about		node along the LSP path, the information about incoming interface ID
	incoming interface ID and the upstream and downstream labels of this		and the upstream and downstream labels of this interface is extracted
	interface is extracted from it and it is used to find next hop		from it and it is used to find next hop outgoing interface ID and the
	outgoing interface ID and the upstream/downstream labels by looking		upstream/downstream labels by looking up the DP cross-connection
	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 path,
	it is possible to make the handover Path message reach the egress		it is possible to make the handover Path message reach the egress
	node, exactly following the LSP that is in place over DP. The ERO		node, exactly following the LSP that is in place over DP. The ERO
	MAY in this case be included in the Path message as an optional		MAY in this case be included in the Path message as an optional
	skipping to change at page 15, line 19		skipping to change at page 15, line 19
	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.
	7. Objects Modification		7. Objects Modification
	The modifications required concern two RSVP Objects: the		The modifications required concern two RSVP objects: the ADMIN_STATUS
	Administrative 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 Administrative Status		This memo introduces a new flag into the ADMIN_STATUS object. The
	object. The Admin_Status Object is defined in [RFC3473]. This		ADMIN_STATUS Object is defined in [RFC3473]. This document uses the
	document uses the H bit of the Admin_Status object. The bit is bit		H bit of the ADMIN_STATUS Object. The bit is bit number (TBD by
	number (TBD by IANA). The format of the Admin_Status Object is:		IANA). The format of the ADMIN_STATUS Object is:
	0 1 2 3		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		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) |		| Length | Class-Num(196)| C-Type (1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Reserved |H|L|I|C|T|A|D|		|R| Reserved |H|L|I|C|T|A|D|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The different flags are defined as follows:		The different flags are defined as follows:
	skipping to change at page 16, line 16		skipping to change at page 16, line 16
	- Testing (T): 1 bit - Defined in [RFC3471]		- Testing (T): 1 bit - Defined in [RFC3471]
	- Administratively down (A): 1 bit - Defined in [RFC4974]		- Administratively down (A): 1 bit - Defined in [RFC4974]
	- Deletion in progress (D): 1 bit - Defined in [RFC3471]		- 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 is interrupted and the ownership of the		In this case the LSP handover procedure is interrupted, the ownership
	LSP moved back to the Plane it belonged to. It is important that the		of the LSP must remain with the ownership prior to the initiation of
	transaction failure does not affect the DP. The LSP is kept in place		the handover procedure. It is important that the transaction failure
	and no traffic hit occurs.		does not affect the DP. The LSP is kept in place and no traffic hit
			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)(33). For this Error Code the following Error Values
	are defined:		are defined:
	1 = Cross-connection mismatch		1 = Cross-connection mismatch
	2 = DCN error		2 = Other failure
	3 = 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. In		along the path MUST support the extension defined in this draft.
	case a node does not support the Handover procedure, the upstream		This requirement translates to an administrative requirement as it is
	node along the path MUST send a PathErr message in the upstream		not enforced at the protocol level. As defined, non-supporting will
	direction including an Error_Spec_Object specifying the causes of the		simply propagate the H bit without setting local state. This may
	failure.		result in an impact data traffic during the handover procedure.
	9. Acknowledgments		9. Acknowledgments
	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, that contributed to initial stage of		wish to thank Nicola Ciulli (Nextworks), that contributed to the
	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
	skipping to change at page 17, line 33		skipping to change at page 17, line 32
	Email: ibryskin@advaoptical.com		Email: ibryskin@advaoptical.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. So, no additional or special issues are
	arisen by adopting this procedure, that aren't already brought up by		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.		the use of the same messages, without H bit setting, for LSP control.
	For RSVP-TE Security please refer to [RFC3473].		For RSVP-TE Security please refer to [RFC3473].
	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
	Administrative 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.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[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.
End of changes. 40 change blocks.
	120 lines changed or deleted		135 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/