draft-ietf-ccamp-confirm-data-channel-status-08.txt		draft-ietf-ccamp-confirm-data-channel-status-09.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: May 2010 November 10, 2009		Expires: June 2010 December 14, 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-08.txt		draft-ietf-ccamp-confirm-data-channel-status-09.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		other groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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.
	Abstract		Abstract
	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 Label-
	confirm data channel statuses, and provides triggers for notifying		Switching Routers (LSRs) to confirm data channel statuses, and
	the management plane if any discrepancies are found. As LMP is		provides triggers for notifying the management plane if any
	already used to verify data plane connectivity, it is considered to		discrepancies are found. As LMP is already used to verify data plane
	be an appropriate candidate to support this feature.		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. Failed Resources........................................5		2.3. 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		4.3. Message Construction...................................10
	4.4. Backward Compatibility.................................10		4.4. Backward Compatibility.................................10
	5. Procedures..................................................10		5. Procedures..................................................10
	skipping to change at page 3, line 23		skipping to change at page 3, line 25
	existence of some data channel mismatch problems may be detected by		existence of some data channel mismatch problems may be detected by
	a mismatch in the advertised bandwidths where bidirectional TE links		a mismatch in the advertised bandwidths where bidirectional TE links
	and bidirectional services are in use, but where unidirectional		and bidirectional services are in use, but where unidirectional
	services exist, or where multiple data channel mismatches occur, it		services exist, or where multiple data channel mismatches occur, it
	is not possible to detect such errors through the routing protocol-		is not possible to detect such errors through the routing protocol-
	advertised TE information. In any case, there is no mechanism to		advertised TE information. In any case, there is no mechanism to
	isolate the mismatches by determining which data channels are at		isolate the mismatches by determining which data channels are at
	fault.		fault.
	If a data channel mismatch exists, any attempt to use the data		If a data channel mismatch exists, any attempt to use the data
	channel for a new LSP will fail. One end of the TE link may attempt		channel for a new Label Switched Path (LSP) will fail. One end of
	to assign the TE link for use, but the other end will report the		the TE link may attempt to assign the TE link for use, but the other
	data channel as unavailable when the control plane or management		end will report the data channel as unavailable when the control
	plane attempts to assign it to an LSP.		plane or management plane attempts to assign it to an LSP.
	Although such a situation can be resolved through the use of the		Although such a situation can be resolved through the use of the
	Acceptable Label Set object in GMPLS signaling [RFC3473], such a		Acceptable Label Set object in GMPLS signaling [RFC3473], such a
	procedure is inefficient since it may require an additional		procedure is inefficient since it may require an additional
	signaling exchange for each LSP that is set up. When many LSPs are		signaling exchange for each LSP that is set up. When many LSPs are
	to be set up, and when there are many data channel mismatches, such		to be set up, and when there are many data channel mismatches, such
	inefficiencies become significant. It is desirable to avoid the		inefficiencies become significant. It is desirable to avoid the
	additional signaling overhead, and to report the problems to the		additional signaling overhead, and to report the problems to the
	management plane so that they can be resolved to improve the		management plane so that they can be resolved to improve the
	efficiency of LSP setup.		efficiency of LSP setup.
	skipping to change at page 5, line 30		skipping to change at page 5, line 33
	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
	In [RFC2205] and [RFC3209], a soft state mechanism was defined to		In [RFC2205] and [RFC3209], a soft state mechanism was defined to
	prevent state discrepancies between LSRs. RSVP-TE restart processes		prevent state discrepancies between LSRs. Resource ReserVation
	([RFC3473], [RFC5063]) have been defined: adjacent LSRs may		Protocol-Traffic Engineering (RSVP-TE) restart processes ([RFC3473],
	resynchronize their control plane state to reinstate information		[RFC5063]) have been defined: adjacent LSRs may resynchronize their
	about LSPs that have persisted in the data plane. Both mechanisms aim		control plane state to reinstate information about LSPs that have
	at keeping state consistency among nodes and allow LSRs to detect		persisted in the data plane. Both mechanisms aim at keeping state
	mismatched data plane states. The data plane handling of such		consistency among nodes and allow LSRs to detect mismatched data
	mismatched state can be treated as a local policy decision. Some		plane states. The data plane handling of such mismatched state can be
	deployments may decide to automatically clean up the data plane state		treated as a local policy decision. Some deployments may decide to
	so it matches the control plane state, but others may choose to raise		automatically clean up the data plane state so it matches the control
	an alert to the management plane and leave the data plane untouched		plane state, but others may choose to raise an alert to the
	just in case it is in use.		management plane and leave the data plane untouched 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. Failed Resources		2.3. 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
	skipping to change at page 7, line 24		skipping to change at page 7, line 27
	The message formats in the sections that follow use Backus-Naur Form		The message formats in the sections that follow use Backus-Naur Form
	(BNF) encoding as defined in [RFC5511].		(BNF) encoding as defined in [RFC5511].
	4.1. Confirm Data Channel Status Messages		4.1. Confirm Data Channel Status Messages
	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		rejection of an LSP setup message because of an unavailable resource).
	resource). The new LMP messages run over the control channel,		The new LMP messages run over the control channel, encapsulated in
	encapsulated in UDP with an LMP port number and IP addressing as		UDP with an LMP port number and IP addressing as defined in Link
	defined in Link Management Protocol (LMP) [RFC4204].		Management Protocol (LMP) [RFC4204].
	Three new messages are defined to check data channel status. Message
	Type numbers are found in Section 7.1.
	If the message is a Confirm Data Channel Status message, and the		Three new messages are defined to check data channel status:
	Message_Id value is less than the largest Message_Id value previously		ConfirmDataChannelStatus, ConfirmDataChannelStatusAck,
	received from the sender for the specified TE link, then the message		ConfirmDataChannelStatusNack, which are described in detail in the
	SHOULD be treated as being out-of-order.		following sections. Message Type numbers are found in Section 7.1.
	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>
	skipping to change at page 8, line 11		skipping to change at page 8, line 11
	When a node receives the ConfirmDataChannelStatus message, and the		When a node receives the ConfirmDataChannelStatus message, and the
	data channel status confirmation procedure is supported at the node,		data channel status confirmation procedure is supported at the node,
	the node compares its own data channel statuses with all of the data		the node compares its own data channel statuses with all of the data
	channel statuses sent by the remote end in the		channel statuses sent by the remote end in the
	ConfirmDataChannelStatus message. If a data channel status mismatch		ConfirmDataChannelStatus message. If a data channel status mismatch
	is found, this mismatch result is expected to be reported to the		is found, this mismatch result is expected to be reported to the
	management plane for further action. Management plane reporting		management plane for further action. Management plane reporting
	procedures and actions are outside the scope of this document.		procedures and actions are outside the scope of this document.
			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.2. ConfirmDataChannelStatusAck Messages		4.1.2. ConfirmDataChannelStatusAck Messages
	The ConfirmDataChannelStatusAck message is sent back to the node		The ConfirmDataChannelStatusAck message is sent back to the node
	which originated the ConfirmDataChannelStatus message to return the		which originated the ConfirmDataChannelStatus message to return the
	requested data channel statuses.		requested data channel statuses.
	When the ConfirmDataChannelStatusAck message is received, the node		When the ConfirmDataChannelStatusAck message is received, the node
	compares the received data channel statuses at the remote end with		compares the received data channel statuses at the remote end with
	those at the local end (the same operation as performed by the		those at the local end (the same operation as performed by the
	receiver of the ConfirmDataChannelStatus message). If a data channel		receiver of the ConfirmDataChannelStatus message). If a data channel
	skipping to change at page 9, line 46		skipping to change at page 9, line 49
	This is a series of bit flags to indicate the status of the data		This is a series of bit flags to indicate the status of the data
	channel. The following values are defined.		channel. The following values are defined.
	0x0000 : The channel is available/free.		0x0000 : The channel is available/free.
	0x0001 : The channel is unavailable/in-use.		0x0001 : The channel is unavailable/in-use.
	Data Channel ID		Data Channel ID
	This identifies the data channel. The length of this field can be		This identifies the data channel. The length of this field can be
	deduced from the Length field in the subobject. Note that all		deduced from the Length field in the subobject. Note that all
	subobjects must be padded to a four byte boundary with trailing		subobjects must be padded to a four byte boundary with trailing zeros.
	zeros. If such padding is required, the Length field MUST indicate
	the length of the subobject up to, but not including, the first byte		If such padding is required, the Length field MUST indicate the
	of padding. Thus, the amount of padding is deduced and not		length of the subobject up to, but not including, the first byte of
	represented in the Length field.		padding. Thus, the amount of padding is deduced and not represented
			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		4.3. Message Construction
	skipping to change at page 10, line 35		skipping to change at page 10, line 38
	In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD		In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD
	be used to identify each timeslot of the data link.		be used to identify each timeslot of the data link.
	4.4. Backward Compatibility		4.4. Backward Compatibility
	Some nodes running in the network may only support the LMP Message		Some nodes running in the network may only support the LMP Message
	Types, which are already defined in [RFC4204]. The three new types of		Types, which are already defined in [RFC4204]. The three new types of
	LMP message defined in this document can not be recognized by these		LMP message defined in this document can not be recognized by these
	nodes. The unknown message behavior is not being specified in		nodes. The unknown message behavior is not being specified in
	[RFC4204], it's suggested to discard the unknown message silently.		[RFC4204], it's suggested to discard the unknown message silently.
	This document's defined mechanisms presume a certain non-standard		The mechanism defined in this document presumes a certain non-
	behavior of existing/non-document supporting nodes. To use this		standard behavior of existing/non-document supporting nodes. To use
	mechanisms all nodes MUST have the extensions described in this		this mechanism all nodes MUST have the extensions described in this
	document for compatibility.		document for compatibility.
	5. Procedures		5. Procedures
	The data channel status confirmation related LMP messages MAY be sent		Adjacent nodes MAY send data channel status confirmation related LMP
	between adjacent nodes which are triggered by timer periodically or		messages. Periodical timers or some other events requesting the
	driven by some events to confirm the channel status for the data		confirmation of channel status for the data link may trigger these
	links. It's a local police decision to start the data channel status		messages. It's a local policy decision to start the data channel
	confirmation process. The procedure is described below:		status confirmation process. The procedure is described below:
	. The SENDER constructs a ConfirmDataChannelStatus message which		. Initially, the SENDER constructs a ConfirmDataChannelStatus
	MUST contain one or more DATA_LINK objects. DATA_LINK object is		message which MUST contain one or more DATA_LINK objects.
	defined in [RFC4204]. Each DATA_LINK object MUST contain one or		DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object
	more Data Channel Status subobjects. The Data Channel ID field in		MUST contain one or more Data Channel Status subobjects. The Data
	the Data Channel Status subobject MUST indicate which data channel		Channel ID field in the Data Channel Status subobject MUST
	needs to be confirmed, and MUST report the data channel status at		indicate which data channel needs to be confirmed, and MUST report
	the SENDER. The ConfirmDataChannelStatus message is sent to the		the data channel status at the SENDER. The
	RECEIVER.		ConfirmDataChannelStatus message is sent to the RECEIVER.
	. The RECEIVER MUST extract the data channel statuses from the		. Upon reception of a ConfirmDataChannelStatus message, the RECEIVER
			MUST extract the data channel statuses from the
	ConfirmDataChannelStatus message, and SHOULD compare these with		ConfirmDataChannelStatus message, and SHOULD compare these with
	its data channel statuses for the reported data channels. If a		its data channel statuses for the reported data channels. If a
	data channel status mismatch is found, the mismatch result SHOULD		data channel status mismatch is found, the mismatch result SHOULD
	be reported to the management plane for further action. The		be reported to the management plane for further action. The
	RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message		RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message
	which MUST carry all the local end statuses of the requested data		which MUST carry all the local end statuses of the requested data
	channels to the 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.
	. When the SENDER receives the response ConfirmDataChannelStatusAck		. Upon reception of a ConfirmDataChannelStatusAck message, the
	message, and MUST compare the received data channel statuses at		SENDER MUST compare the received data channel statuses at the
	the remote end with the data channel statuses at the local end. If		remote end with the data channel statuses at the local end. If a
	a data channel status mismatch is found, the mismatch result		data channel status mismatch is found, the mismatch result SHOULD
	SHOULD be reported to the management plane for further action.		be reported to the management plane for further action.
	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
	skipping to change at page 15, line 32		skipping to change at page 15, line 32
	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
	and restrictions with respect to this document.		and restrictions with respect to this document.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November 10,
	10, 2008. The person(s) controlling the copyright in some of this		2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	12. Intellectual Property Statement		12. Intellectual Property Statement
End of changes. 17 change blocks.
	65 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/