draft-ietf-ccamp-confirm-data-channel-status-06.txt		draft-ietf-ccamp-confirm-data-channel-status-07.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: February 2010 August 14, 2009		Expires: March 2010 September 3, 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-06.txt		draft-ietf-ccamp-confirm-data-channel-status-07.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.
	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
	skipping to change at page 7, line 21		skipping to change at page 7, line 21
	Outline procedures are described in this section. More detailed		Outline procedures are described in this section. More detailed
	procedures are found in Section 5.		procedures are found in Section 5.
	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 resource).		rejection of an LSP setup message because of an unavailable
	The new LMP messages run over the control channel, encapsulated in		resource). The new LMP messages run over the control channel,
	UDP with an LMP port number and IP addressing as defined in Link		encapsulated in UDP with an LMP port number and IP addressing as
	Management Protocol (LMP) [RFC4204].		defined in Link Management Protocol (LMP) [RFC4204].
	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		If the message is a Confirm Data Channel Status message, and the
	Message_Id value is less than the largest Message_Id value previously		Message_Id value is less than the largest Message_Id value previously
	received from the sender for the specified TE link, then the message		received from the sender for the specified TE link, then the message
	SHOULD be treated as being out-of-order.		SHOULD be treated as being out-of-order.
	4.1.1. ConfirmDataChannelStatus Messages		4.1.1. ConfirmDataChannelStatus Messages
	skipping to change at page 9, line 43		skipping to change at page 9, line 43
	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 zeros.		subobjects must be padded to a four byte boundary with trailing
	If such padding is required, the Length field MUST indicate the		zeros. If such padding is required, the Length field MUST indicate
	length of the subobject up to, but not including, the first byte of		the length of the subobject up to, but not including, the first byte
	padding. Thus, the amount of padding is deduced and not represented		of padding. Thus, the amount of padding is deduced and not
	in the Length field.		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 26		skipping to change at page 10, line 26
	The status of the TE link end MUST be carried by the Data Channel		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.		Status subobject which is defined in section 4.2 of this document.
	The new subobject MUST be part of Data_Link Class.		The new subobject MUST be part of Data_Link Class.
	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
	Type from 1 to 20, which are already defined in [RFC4204]. The three		Types, which are already defined in [RFC4204]. The three new types of
	new types of LMP message (Message Type from 21 to 23) defined in this		LMP message defined in this document can not be recognized by these
	document can not be recognized by these nodes. The unknown message		nodes. The unknown message behavior is not being specified in
	behavior is not being specified in [RFC4204], it's suggested to		[RFC4204], it's suggested to discard the unknown message silently.
	discard the unknown message silently. This document's defined		This document's defined mechanisms presume a certain non-standard
	mechanisms presume a certain non-standard behavior of existing/non-		behavior of existing/non-document supporting nodes. To use this
	document supporting nodes. To use this mechanisms all nodes MUST have		mechanisms all nodes MUST have the extensions described in this
	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		The data channel status confirmation related LMP messages MAY be sent
	between adjacent nodes which are triggered by timer periodically or		between adjacent nodes which are triggered by timer periodically or
	driven by some events to confirm the channel status for the data		driven by some events to confirm the channel status for the data
	links. It's a local police decision to start the data channel status		links. It's a local police decision to start the data channel status
	confirmation process. The procedure is described below:		confirmation process. The procedure is described below:
	. The SENDER constructs a ConfirmDataChannelStatus message which		. The SENDER constructs a ConfirmDataChannelStatus message which
	skipping to change at page 15, line 17		skipping to change at page 15, line 17
	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 10,		Contributions published or made publicly available before November
	2008. The person(s) controlling the copyright in some of this		10, 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. 7 change blocks.
	22 lines changed or deleted		23 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/