draft-ietf-ccamp-confirm-data-channel-status-07.txt		draft-ietf-ccamp-confirm-data-channel-status-08.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: March 2010 September 3, 2009		Expires: May 2010 November 10, 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-07.txt		draft-ietf-ccamp-confirm-data-channel-status-08.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.
	skipping to change at page 2, line 28		skipping to change at page 2, line 28
	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
	6. Security Considerations.....................................11		6. Security Considerations.....................................12
	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.............................................13
	9. References..................................................13		9. References..................................................13
	9.1. Normative References...................................13		9.1. Normative References...................................13
	9.2. Informative References.................................13		9.2. Informative References.................................13
	10. Authors' Addresses.........................................13		10. Authors' Addresses.........................................14
	11. Full Copyright Statement...................................15		11. Full Copyright Statement...................................15
	12. Intellectual Property Statement............................15		12. Intellectual Property Statement............................15
	13. Disclaimer of Validity.....................................16		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).
	A data channel status mismatch exists if the LSR at one end of a TE		A data channel status mismatch exists if the LSR at one end of a TE
	link believes that the data channel is assigned to carry data, but		link believes that the data channel is assigned to carry data, but
	the LSR at the other end does not. The term "ready to carry data"		the LSR at the other end does not. The term "ready to carry data"
	means cross-connected or bound to an end-point for the receipt or		means cross-connected or bound to an end-point for the receipt or
	delivery of data.		delivery of data.
	Data channel mismatches cannot be detected from the TE information		Data channel mismatches cannot be detected from the TE information
	advertised by the routing protocols [RFC4203], [RFC4205]. The		advertised by the routing protocols [RFC4203], [RFC5307]. The
	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
	skipping to change at page 7, line 15		skipping to change at page 7, line 15
	4. Extensions to LMP		4. Extensions to LMP
	A control plane tool to detect and isolate data channel mismatches is		A control plane tool to detect and isolate data channel mismatches is
	provided in this document by simple additions to the Link Management		provided in this document by simple additions to the Link Management
	Protocol (LMP) [RFC4204]. It can assist in the location of stranded		Protocol (LMP) [RFC4204]. It can assist in the location of stranded
	resources by allowing adjacent LSRs to confirm data channel statuses.		resources by allowing adjacent LSRs to confirm data channel statuses.
	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.
			The message formats in the sections that follow use Backus-Naur Form
			(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). The new LMP messages run over the control channel,		resource). The new LMP messages run over the control channel,
	encapsulated in UDP with an LMP port number and IP addressing as		encapsulated in UDP with an LMP port number and IP addressing as
	defined in Link Management Protocol (LMP) [RFC4204].		defined in Link Management Protocol (LMP) [RFC4204].
	skipping to change at page 10, line 8		skipping to change at page 10, line 13
	the length of the subobject up to, but not including, the first byte		the length of the subobject up to, but not including, the first byte
	of padding. Thus, the amount of padding is deduced and not		of padding. Thus, the amount of padding is deduced and not
	represented 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
	Data_Link Class is included in ConfirmDataChannelStatus and		Data_Link Class is included in ConfirmDataChannelStatus and
	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.
	skipping to change at page 13, line 15		skipping to change at page 13, line 24
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,		[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,
	October 2005.		October 2005.
			[RFC5511] A. Farrel, Ed., "Routing Backus-Naur Form (RBNF): A
			Syntax Used to Form Encoding Rules in Various Routing
			Protocol Specifications", RFC 5511, April 2009.
	9.2. Informative References		9.2. Informative References
	[RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) --		[RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) --
	Version 1 Functional Specification", RFC 2205, September		Version 1 Functional Specification", RFC 2205, September
	1997		1997
	[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.		[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
	Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",		Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
	RFC 3209, December 2001		RFC 3209, December 2001
	[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label		[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation		Switching (GMPLS) Signaling Resource ReserVation
	Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC		Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
	3473, January 2003		3473, January 2003
	[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP		[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP
	Graceful Restart", RFC 5063, September 2007		Graceful Restart", RFC 5063, September 2007
	[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		[RFC4606] E. Mannie, Ed., "Generalized Multi-Protocol Label
	System (IS-IS) Extensions in Support of Generalized		Switching (GMPLS) Extensions for Synchronous Optical
	Multi-Protocol Label Switching (GMPLS) ", RFC 4205,		Network (SONET) and Synchronous Digital Hierarchy (SDH)
	October 2005		Control", RFC 4606, August 2006
			[RFC5307] K. Kompella, Ed., "IS-IS Extensions in Support of
			Generalized Multi-Protocol Label Switching (GMPLS)", RFC
			5307, October 2008
	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
End of changes. 11 change blocks.
	12 lines changed or deleted		23 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/