draft-ietf-ccamp-confirm-data-channel-status-04.txt		draft-ietf-ccamp-confirm-data-channel-status-05.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 22, 2009		Expires: November 2009 May 25, 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-04.txt		draft-ietf-ccamp-confirm-data-channel-status-05.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 2, line 26		skipping to change at page 2, line 26
	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........................................5
	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
	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..................................................13
	9.1. Normative References...................................12		9.1. Normative References...................................13
	9.2. Informative References.................................13		9.2. Informative References.................................13
	10. Authors' Addresses.........................................13		10. Authors' Addresses.........................................13
	11. Full Copyright Statement...................................14		11. Full Copyright Statement...................................15
	12. Intellectual Property Statement............................15		12. Intellectual Property Statement............................15
	13. Disclaimer of Validity.....................................15		13. Disclaimer of Validity.....................................16
	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 10, line 23		skipping to change at page 10, line 23
	ConfirmDataChannelStatusAck messages, which is defined in section		ConfirmDataChannelStatusAck messages, which is defined in section
	13.12 in [RFC4204].		13.12 in [RFC4204].
	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
			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
			new types of LMP message (Message Type from 21 to 23) defined in this
			document can not be recognized by these nodes. The unknown message
			behavior is not being specified in [RFC4204], it's suggested to
			discard the unknown message silently. This document's defined
			mechanisms presume a certain non-standard behavior of existing/non-
			document supporting nodes.
	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
	MUST contain one or more DATA_LINK objects. DATA_LINK object is		MUST contain one or more DATA_LINK objects. DATA_LINK object is
End of changes. 7 change blocks.
	6 lines changed or deleted		18 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/