draft-ietf-ccamp-confirm-data-channel-status-03.txt		draft-ietf-ccamp-confirm-data-channel-status-04.txt
	Network Working Group D. Li		Network Working Group D. Li
	Internet Draft H. Xu		Internet Draft H. Xu
	Category: Standards Track Huawei		Category: Standards Track Huawei
	S. Bardalai		S. Bardalai
	Fujitsu		Fujitsu
	J. Meuric		J. Meuric
	France Telecom		France Telecom
	D. Caviglia		D. Caviglia
	Ericsson		Ericsson
	Expires: November 2009 May 6, 2009		Expires: November 2009 May 22, 2009
	Data Channel Status Confirmation Extensions		Data Channel Status Confirmation Extensions
	for the Link Management Protocol		for the Link Management Protocol
	draft-ietf-ccamp-confirm-data-channel-status-03.txt		draft-ietf-ccamp-confirm-data-channel-status-04.txt
	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-Drafts.		other groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	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.
	Abstract		Abstract
	As LMP is already used to verify data plane connectivity, it is
	considered to be an appropriate candidate to support this feature.
	This document defines simple additions to the Link Management		This document defines simple additions to the Link Management
	Protocol (LMP) to provide a control plane tool that can assist in		Protocol (LMP) to provide a control plane tool that can assist in
	the location of stranded resources by allowing adjacent LSRs to		the location of stranded resources by allowing adjacent LSRs to
	confirm data channel statuses, and provides triggers for notifying		confirm data channel statuses, and provides triggers for notifying
	the management plane if any discrepancies are found.		the management plane if any discrepancies are found. As LMP is
			already used to verify data plane connectivity, it is considered to
			be an appropriate candidate to support this feature.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction.................................................2		1. Introduction.................................................2
	2. Problem Explanation..........................................4		2. Problem Explanation..........................................4
	2.1. Mismatch Caused by Manual Configuration.................4		2.1. Mismatch Caused by Manual Configuration.................4
	2.2. Mismatch Caused by LSP Deletion.........................5		2.2. Mismatch Caused by LSP Deletion.........................5
	2.3. Manual Change of the Cross-Connection State.............5		2.3. Failed Resources........................................5
	2.4. Failed Resources........................................6
	3. Motivation...................................................6		3. Motivation...................................................6
	4. Extensions to LMP............................................7		4. Extensions to LMP............................................7
	4.1. Confirm Data Channel Status Messages....................7		4.1. Confirm Data Channel Status Messages....................7
	4.1.1. ConfirmDataChannelStatus Messages..................7		4.1.1. ConfirmDataChannelStatus Messages..................7
	4.1.2. ConfirmDataChannelStatusAck Messages...............8		4.1.2. ConfirmDataChannelStatusAck Messages...............8
	4.1.3. ConfirmDataChannelStatusNack Messages..............8		4.1.3. ConfirmDataChannelStatusNack Messages..............8
	4.2. Data Channel Status Subobject...........................9		4.2. Data Channel Status Subobject...........................9
			4.3. Message Construction...................................10
	5. Procedures..................................................10		5. Procedures..................................................10
	6. Security Considerations.....................................11		6. Security Considerations.....................................11
	7. IANA Considerations.........................................12		7. IANA Considerations.........................................12
	7.1. LMP Message Types......................................12		7.1. LMP Message Types......................................12
	7.2. LMP Data Link Object Subobject.........................12		7.2. LMP Data Link Object Subobject.........................12
	8. Acknowledgments.............................................12		8. Acknowledgments.............................................12
	9. References..................................................12		9. References..................................................12
	9.1. Normative References...................................12		9.1. Normative References...................................12
	9.2. Informative References.................................13		9.2. Informative References.................................13
	10. Authors' Addresses.........................................13		10. Authors' Addresses.........................................13
	11. Full Copyright Statement...................................15		11. Full Copyright Statement...................................14
	12. Intellectual Property Statement............................15		12. Intellectual Property Statement............................15
	13. Disclaimer of Validity.....................................16		13. Disclaimer of Validity.....................................15
	1. Introduction		1. Introduction
	Generalized Multiprotocol Label Switching (GMPLS) networks are		Generalized Multiprotocol Label Switching (GMPLS) networks are
	constructed from Traffic Engineering (TE) links connecting Label		constructed from Traffic Engineering (TE) links connecting Label
	Switching Routers (LSRs). The TE links are constructed from a set of		Switching Routers (LSRs). The TE links are constructed from a set of
	data channels. In this context, a data channel corresponds to a		data channels. In this context, a data channel corresponds to a
	resource label in a non-packet technology (such as a timeslot or a		resource label in a non-packet technology (such as a timeslot or a
	lambda).		lambda).
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	described as "stranded resources". They are not in use for any LSP,		described as "stranded resources". They are not in use for any LSP,
	but they cannot be assigned for use by a new LSP because they appear		but they cannot be assigned for use by a new LSP because they appear
	to be in use. Although it is theoretically possible for management		to be in use. Although it is theoretically possible for management
	plane applications to audit all network resources to locate stranded		plane applications to audit all network resources to locate stranded
	resources and to release them, this process is rarely performed		resources and to release them, this process is rarely performed
	because of the difficulty of coordinating different Element		because of the difficulty of coordinating different Element
	Management Systems (EMSs), and the associated risks of accidentally		Management Systems (EMSs), and the associated risks of accidentally
	releasing in-use resources. It is desirable to have a control plane		releasing in-use resources. It is desirable to have a control plane
	mechanism that detects and reports stranded resources.		mechanism that detects and reports stranded resources.
	As LMP is already used to verify data plane connectivity, it is
	considered to be an appropriate candidate to support this feature.
	This document defines simple additions to the Link Management		This document defines simple additions to the Link Management
	Protocol (LMP) [RFC4204] to provide a control plane tool that can		Protocol (LMP) [RFC4204] to provide a control plane tool that can
	assist in the location of stranded resources by allowing adjacent		assist in the location of stranded resources by allowing adjacent
	LSRs to confirm data channel statuses, and provides triggers for		LSRs to confirm data channel statuses, and provides triggers for
	notifying the management plane if any discrepancies are found.		notifying the management plane if any discrepancies are found. As LMP
			is already used to verify data plane connectivity, it is considered
			to be an appropriate candidate to support this feature.
	2. Problem Explanation		2. Problem Explanation
	Examples of data channel mismatches are described in the following		Examples of data channel mismatches are described in the following
	three scenarios.		three scenarios.
	In all of the scenarios, the specific channel resource of a data link		In all of the scenarios, the specific channel resource of a data link
	will be unavailable because of the data channel status mismatch, and		will be unavailable because of the data channel status mismatch, and
	this channel resource will be wasted. Furthermore, a data channel		this channel resource will be wasted. Furthermore, a data channel
	status mismatch may reduce the possibility of successful LSP		status mismatch may reduce the possibility of successful LSP
	skipping to change at page 5, line 28		skipping to change at page 5, line 28
	of node B still being in use. So the data channel statuses between		of node B still being in use. So the data channel statuses between
	nodes A and B, and between nodes B and C are both mismatched.		nodes A and B, and between nodes B and C are both mismatched.
	<---------LSP--------->		<---------LSP--------->
	+-+-------+-+-------+-+		+-+-------+-+-------+-+
	| | |X| | |		| | |X| | |
	+-+-------+-+-------+-+		+-+-------+-+-------+-+
	A B C		A B C
	Figure 2. Mismatch caused by LSP deletion		Figure 2. Mismatch caused by LSP deletion
	RSVP-TE restart processes [RFC2205], [RFC3209], [RFC3473], [RFC5063]		In [RFC2205] and [RFC3209], a soft state mechanism was defined to
	define mechanisms where adjacent LSRs may resynchronize their control		prevent state discrepancies between LSRs. RSVP-TE restart processes
	plane state to reinstate information about LSPs that have persisted		([RFC3473], [RFC5063]) have been defined: adjacent LSRs may
	in the data plane. The mechanisms allow LSRs to detect mismatched		resynchronize their control plane state to reinstate information
	data plane state after the expiry of the Recovery Timer. It is a		about LSPs that have persisted in the data plane. Both mechanisms aim
	local policy decision how this mismatched state is handled. Some		at keeping state consistency among nodes and allow LSRs to detect
			mismatched data plane states. The data plane handling of such
			mismatched state can be treated as a local policy decision. Some
	deployments may decide to automatically clean up the data plane state		deployments may decide to automatically clean up the data plane state
	so it matches the control plane state, but others may choose to raise		so it matches the control plane state, but others may choose to raise
	an alert to the management plane and leave the data plane untouched		an alert to the management plane and leave the data plane untouched
	just in case it is in use.		just in case it is in use.
	In such cases, data channel mismatches may arise after restart and		In such cases, data channel mismatches may arise after restart and
	might not be cleared up by the restart procedures.		might not be cleared up by the restart procedures.
	2.3. Manual Change of the Cross-Connection State		2.3. Failed Resources
	In transport nodes it is possible to perform certain manual
	operations on a cross-connect such as forced protection switch
	(refer to [G.841]) on a protected link. These operations will make
	it impossible to release the cross-connect when an LSP is being
	deleted.
	2.4. Failed Resources
	Even if the situation is not common, it might happen that a		Even if the situation is not common, it might happen that a
	termination point of a TE-link is seen as failed by one end, while		termination point of a TE-link is seen as failed by one end, while
	on the other end it is seen as OK. This problem may arise due to		on the other end it is seen as OK. This problem may arise due to
	some failure either in the hardware or in the status detection of		some failure either in the hardware or in the status detection of
	the termination point.		the termination point.
	This mismatch in the termination point status can lead to failure		This mismatch in the termination point status can lead to failure
	in case of bidirectional LSP set-up.		in case of bidirectional LSP set-up.
	skipping to change at page 7, line 29		skipping to change at page 7, line 26
	Extensions to LMP to confirm a data channel status are described		Extensions to LMP to confirm a data channel status are described
	below. In order to confirm a data channel status, the new LMP		below. In order to confirm a data channel status, the new LMP
	messages are sent between adjacent nodes periodically or driven by		messages are sent between adjacent nodes periodically or driven by
	some event (such as an operator command, a configurable timer, or the		some event (such as an operator command, a configurable timer, or the
	rejection of an LSP setup message because of an unavailable resource).		rejection of an LSP setup message because of an unavailable resource).
	The new LMP messages run over the control channel, encapsulated in		The new LMP messages run over the control channel, encapsulated in
	UDP with an LMP port number and IP addressing as defined in Link		UDP with an LMP port number and IP addressing as defined in Link
	Management Protocol (LMP) [RFC4204].		Management Protocol (LMP) [RFC4204].
	Nodes processing incoming messages SHOULD check to see if a newly
	received message is out of order and can be ignored. Out-of-order
	messages can be identified by examining the value in the Message_Id
	field. If a message is determined to be out-of-order, that message
	should be silently dropped.
	Three new messages are defined to check data channel status. Message		Three new messages are defined to check data channel status. Message
	Type numbers are found in Section 7.1.		Type numbers are found in Section 7.1.
			If the message is a Confirm Data Channel Status message, and the
			Message_Id value is less than the largest Message_Id value previously
			received from the sender for the specified TE link, then the message
			SHOULD be treated as being out-of-order.
	4.1.1. ConfirmDataChannelStatus Messages		4.1.1. ConfirmDataChannelStatus Messages
	The ConfirmDataChannelStatus message is used to tell the remote end		The ConfirmDataChannelStatus message is used to tell the remote end
	of the data channel what the status of the local end of the data		of the data channel what the status of the local end of the data
	channel is, and to ask the remote end to report its data channel. The		channel is, and to ask the remote end to report its data channel. The
	message may report on (and request information about) more than one		message may report on (and request information about) more than one
	data channel.		data channel.
	<ConfirmDataChannelStatus Message> ::= <Common Header>		<ConfirmDataChannelStatus Message> ::= <Common Header>
	<LOCAL_LINK_ID>		<LOCAL_LINK_ID>
	skipping to change at page 10, line 20		skipping to change at page 10, line 10
	in the Length field.		in the Length field.
	Note that the Data Channel ID is given in the context of the sender		Note that the Data Channel ID is given in the context of the sender
	of the ConfirmChannelStatus message.		of the ConfirmChannelStatus message.
	The data-channel ID must be encoded as a label value. Based on the		The data-channel ID must be encoded as a label value. Based on the
	type of signal e.g. SONET/SDH, Lambda etc. the encoding methodology		type of signal e.g. SONET/SDH, Lambda etc. the encoding methodology
	used will be different. For SONET/SDH the label value is encoded as		used will be different. For SONET/SDH the label value is encoded as
	per RFC4606.		per RFC4606.
			4.3. Message Construction
			Data_Link Class is included in ConfirmDataChannelStatus and
			ConfirmDataChannelStatusAck messages, which is defined in section
			13.12 in [RFC4204].
			The status of the TE link end MUST be carried by the Data Channel
			Status subobject which is defined in section 4.2 of this document.
			The new subobject MUST be part of Data_Link Class.
			In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD
			be used to identify each timeslot of the data link.
	5. Procedures		5. Procedures
	The data channel status confirmation related LMP messages are sent		The data channel status confirmation related LMP messages MAY be sent
	between adjacent nodes periodically or driven by some events to		between adjacent nodes which are triggered by timer periodically or
	confirm the channel status for the data links. The procedure is		driven by some events to confirm the channel status for the data
	described below:		links. It's a local police decision to start the data channel status
			confirmation process. The procedure is described below:
	. The SENDER constructs a ConfirmDataChannelStatus message which		. The SENDER constructs a ConfirmDataChannelStatus message which
	contains one or more DATA_LINK objects. DATA_LINK object is		MUST contain one or more DATA_LINK objects. DATA_LINK object is
	defined in [RFC4204]. Each DATA_LINK object contains one or more		defined in [RFC4204]. Each DATA_LINK object MUST contain one or
	Data Channel Status subobject. The Data Channel ID field in the		more Data Channel Status subobjects. The Data Channel ID field in
	Data Channel Status subobject indicates which data channel needs		the Data Channel Status subobject MUST indicate which data channel
	to be confirmed, and reports the data channel status at the SENDER.		needs to be confirmed, and MUST report the data channel status at
	The ConfirmDataChannelStatus message is sent to the RECEIVER.		the SENDER. The ConfirmDataChannelStatus message is sent to the
			RECEIVER.
	. The RECEIVER extracts the data channel statuses from the		. The RECEIVER MUST extract the data channel statuses from the
	ConfirmDataChannelStatus message, and compares these with its data		ConfirmDataChannelStatus message, and SHOULD compare these with
	channel statuses for the reported data channels. If a data channel		its data channel statuses for the reported data channels. If a
	status mismatch is found, the mismatch result SHOULD be reported		data channel status mismatch is found, the mismatch result SHOULD
	to the management plane for further action. The RECEIVER also		be reported to the management plane for further action. The
	sends the ConfirmDataChannelStatusAck message which carries all		RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message
	the local end statuses of the requested data channels to the		which MUST carry all the local end statuses of the requested data
	SENDER.		channels to the SENDER.
	. If the RECEIVER is not able to support or to begin the		. If the RECEIVER is not able to support or to begin the
	confirmation procedure, the ConfirmDataChannelStatusNack message		confirmation procedure, the ConfirmDataChannelStatusNack message
	MUST be responded with the ERROR_CODE which indicates the reason		MUST be responded with the ERROR_CODE which indicates the reason
	of rejection.		of rejection.
	. The SENDER receives the response ConfirmDataChannelStatusAck		. When the SENDER receives the response ConfirmDataChannelStatusAck
	message, and compares the received data channel statuses at the		message, and MUST compare the received data channel statuses at
	remote end with the data channel statuses at the local end. If a		the remote end with the data channel statuses at the local end. If
	data channel status mismatch is found, the mismatch result SHOULD		a data channel status mismatch is found, the mismatch result
	be reported to the management plane for further action.		SHOULD be reported to the management plane for further action.
	. The ConfirmDataChannelStatus message SHOULD be resent, if the
	ConfirmDataChannelStatusNack message is received or no response
	message is received in the configured time by the SENDER.
	The data channel status mismatch issue identified by LMP may be		The data channel status mismatch issue identified by LMP may be
	automatically resolved by RSVP restart. For example, the restarting		automatically resolved by RSVP restart. For example, the restarting
	node may also have damaged its data plane. This leaves the data		node may also have damaged its data plane. This leaves the data
	channels mismatched. But RSVP restart will re-install the data plane		channels mismatched. But RSVP restart will re-install the data plane
	state in the restarting node. The issue may also be resolved via RSVP		state in the restarting node. The issue may also be resolved via RSVP
	soft state timeout.		soft state timeout.
	If the ConfirmDataChannelStatus message is not recognized by the		If the ConfirmDataChannelStatus message is not recognized by the
	RECEIVER, the RECEIVER ignores this message, and will not send out an		RECEIVER, the RECEIVER ignores this message, and will not send out an
	acknowledgment message to the SENDER.		acknowledgment message to the SENDER.
	Due to message loss problem, the SENDER may not be able to receive		Due to message loss problem, the SENDER may not be able to receive
	the acknowledgment message.		the acknowledgment message.
	In the above two cases, if the ConfirmDataChannelStatusAck or		ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
	ConfirmDataChannelStatusNack message is not received by the SENDER		transmission mechanisms. If after the retry limit is reached, a
	within the configured time, the SENDER SHOULD terminate the data		ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
	channel confirmation procedure. A default value of 1 minute is		message is not received by the SENDER, the SENDER SHOULD terminate
	suggested for this timer.		the data channel confirmation procedure.
	6. Security Considerations		6. Security Considerations
	[RFC4204] describes how LMP messages between peers can be secured,		[RFC4204] describes how LMP messages between peers can be secured,
	and these measures are equally applicable to the new messages defined		and these measures are equally applicable to the new messages defined
	in this document.		in this document.
	The operation of the procedures described in this document does not		The operation of the procedures described in this document does not
	of themselves constitute a security risk since they do not cause any		of themselves constitute a security risk since they do not cause any
	change in network state. It would be possible, if the messages were		change in network state. It would be possible, if the messages were
	skipping to change at page 13, line 32		skipping to change at page 13, line 32
	[RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of		[RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of
	Generalized Multi-Protocol Label Switching (GMPLS) ", RFC		Generalized Multi-Protocol Label Switching (GMPLS) ", RFC
	4203, October 2005		4203, October 2005
	[RFC4205] K. Kompella, Ed., "Intermediate System to Intermediate		[RFC4205] K. Kompella, Ed., "Intermediate System to Intermediate
	System (IS-IS) Extensions in Support of Generalized		System (IS-IS) Extensions in Support of Generalized
	Multi-Protocol Label Switching (GMPLS) ", RFC 4205,		Multi-Protocol Label Switching (GMPLS) ", RFC 4205,
	October 2005		October 2005
	[G.841] ITU-T "Types and characteristics of SDH network
	protection architectures", October 1998.
	10. Authors' Addresses		10. Authors' Addresses
	Dan Li		Dan Li
	Huawei Technologies		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Shenzhen 518129 China		Shenzhen 518129 China
	Phone: +86 755-289-70230		Phone: +86 755-289-70230
	Email: danli@huawei.com		Email: danli@huawei.com
	Huiying Xu		Huiying Xu
	Huawei Technologies		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Shenzhen 518129 China		Shenzhen 518129 China
	Phone: +86 755-289-72910		Phone: +86 755-289-72910
	Email: xuhuiying@huawei.com		Email: xuhuiying@huawei.com
	Fatai Zhang		Fatai Zhang
	Huawei Technologies		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Shenzhen 518129 China		Shenzhen 518129 China
	Phone: +86 755-289-72912		Phone: +86 755-289-72912
	Email: zhangfatai@huawei.com		Email: zhangfatai@huawei.com
	Snigdho C. Bardalai		Snigdho C. Bardalai
	Fujitsu Network Communications		Fujitsu Network Communications
End of changes. 23 change blocks.
	69 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/