draft-ietf-ccamp-confirm-data-channel-status-02.txt		draft-ietf-ccamp-confirm-data-channel-status-03.txt
	Network Working Group Dan Li		Network Working Group D. Li
	Huiying Xu		Internet Draft H. Xu
	Huawei		Category: Standards Track Huawei
	Snigdho Bardalai		S. Bardalai
	Fujitsu		Fujitsu
	Julien Meuric		J. Meuric
	France Telecom		France Telecom
	Diego Caviglia		D. Caviglia
	Ericsson		Ericsson
	Internet Draft
	Category: Standards Track
	Expires: May 2009 November 3, 2008		Expires: November 2009 May 6, 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-02.txt		draft-ietf-ccamp-confirm-data-channel-status-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that		This Internet-Draft is submitted to IETF in full conformance with the
	any applicable patent or other IPR claims of which he or she is		provisions of BCP 78 and BCP 79.
	aware have been or will be disclosed, and any of which he or she
	becomes aware will be disclosed, in accordance with Section 6 of
	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-		other groups may also distribute working documents as Internet-Drafts.
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months and may be updated, replaced, or obsoleted by other documents		and may be updated, replaced, or obsoleted by other documents at any
	at any time. It is inappropriate to use Internet-Drafts as		time. It is inappropriate to use Internet-Drafts as reference
	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
			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.
	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.............6		2.3. Manual Change of the Cross-Connection State.............5
	2.4. Failed Resources........................................6		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
	5. Procedures..................................................10		5. Procedures..................................................10
	6. Security Considerations.....................................11		6. Security Considerations.....................................11
	7. IANA Considerations.........................................11		7. IANA Considerations.........................................12
	7.1. LMP Message Types......................................11		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.................................12		9.2. Informative References.................................13
	10. Author's Addresses.........................................13		10. Authors' Addresses.........................................13
	11. Full Copyright Statement...................................14		11. Full Copyright Statement...................................15
	12. Intellectual Property Statement............................14		12. Intellectual Property Statement............................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 4, line 10		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.
	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.
	skipping to change at page 5, line 34		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 [RFC3473], [RFC5063] define mechanisms		RSVP-TE restart processes [RFC2205], [RFC3209], [RFC3473], [RFC5063]
	where adjacent LSRs may resynchronize their control plane state to		define mechanisms where adjacent LSRs may resynchronize their control
	reinstate information about LSPs that have persisted in the data		plane state to reinstate information about LSPs that have persisted
	plane. The mechanisms allow LSRs to detect mismatched data plane		in the data plane. The mechanisms allow LSRs to detect mismatched
	state after the expiry of the Recovery Timer. It is a local policy		data plane state after the expiry of the Recovery Timer. It is a
	decision how this mismatched state is handled. Some deployments may		local policy decision how this mismatched state is handled. Some
	decide to automatically clean up the data plane state so it matches		deployments may decide to automatically clean up the data plane state
	the control plane state, but others may choose to raise an alert to		so it matches the control plane state, but others may choose to raise
	the management plane and leave the data plane untouched just in case		an alert to the management plane and leave the data plane untouched
	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. Manual Change of the Cross-Connection State
	In transport nodes it is possible to perform certain manual		In transport nodes it is possible to perform certain manual
	operations on a cross-connect such as forced protection switch,		operations on a cross-connect such as forced protection switch
	red-line, etc. These operations will make it impossible to release		(refer to [G.841]) on a protected link. These operations will make
	the cross-connect when an LSP is being deleted.		it impossible to release the cross-connect when an LSP is being
			deleted.
	2.4. Failed Resources		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
	skipping to change at page 6, line 33		skipping to change at page 6, line 26
	Good Failed		Good Failed
	+-+------------+-+		+-+------------+-+
	A | | |X| B		A | | |X| B
	+-+------------+-+		+-+------------+-+
	data channel		data channel
	Path Message with Upstream Label---->		Path Message with Upstream Label---->
	Figure 3. Mismatch caused by resource failure		Figure 3. Mismatch caused by resource failure
	In this case upstream node chooses to use termination point A in		In this case upstream node chooses to use termination point A in
	order to receive traffic from downstream node. From the upstream's		order to receive traffic from downstream node. From the upstream
	point of view, the resource is available thus usable; however, in the		node's point of view, the resource is available thus usable; however,
	downstream node, the corresponding termination point (resource B) is		in the downstream node, the corresponding termination point (resource
	broken. This leads to a set-up failure.		B) is broken. This leads to a set-up failure.
	3. Motivation		3. Motivation
	The requirement does not come from a lack in GMPLS specifications		The requirement does not come from a lack in GMPLS specifications
	themselves but rather from operational concerns because, in most		themselves but rather from operational concerns because, in most
	cases, GMPLS-controlled networks will co-exist with legacy networks		cases, GMPLS-controlled networks will co-exist with legacy networks
	and legacy procedures.		and legacy procedures.
	The protocol extensions are intended to detect data plane problems		The protocol extensions defined in this document are intended to
	resulting from mis-use or mis-configurations triggered by user error,		detect data plane problems resulting from mis-use or mis-
	or resulting from failure to clean up the data plane after control		configurations triggered by user error, or resulting from failure to
	plane disconnection. It is anticipated that human mistake is probably		clean up the data plane after control plane disconnection. It is
	the major factor to deal with. It is not the intention to provide a		anticipated that human mistake is probably the major source of errors
	protocol mechanism to deal with broken implementations.		to deal with. It is not the intention to provide a protocol mechanism
			to deal with broken implementations.
	The procedures defined in this document are designed to be operated		The procedures defined in this document are designed to be operated
	on a periodic or on-demand basis. It is NOT RECOMMENDED that the		on a periodic or on-demand basis. It is NOT RECOMMENDED that the
	procedures be used to provide a continuous and on-line monitoring		procedures be used to provide a continuous and on-line monitoring
	process.		process.
	As LMP is already used to verify data plane connectivity, it is		As LMP is already used to verify data plane connectivity, it is
	considered to be an appropriate candidate to support this feature.		considered to be an appropriate candidate to support this feature.
	4. Extensions to LMP		4. Extensions to LMP
	skipping to change at page 7, line 30		skipping to change at page 7, line 25
	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 resource).
			The new LMP messages run over the control channel, encapsulated in
			UDP with an LMP port number and IP addressing as defined in Link
			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.
	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
	skipping to change at page 8, line 4		skipping to change at page 8, line 15
	<ConfirmDataChannelStatus Message> ::= <Common Header>		<ConfirmDataChannelStatus Message> ::= <Common Header>
	<LOCAL_LINK_ID>		<LOCAL_LINK_ID>
	<MESSAGE_ID>		<MESSAGE_ID>
	<DATA_LINK>[<DATA_LINK>...]		<DATA_LINK>[<DATA_LINK>...]
	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 SHOULD be reported to the management		is found, this mismatch result is expected to be reported to the
	plane for further action. Management plane reporting procedures and		management plane for further action. Management plane reporting
	actions are outside the scope of this document.		procedures and actions are outside the scope of this document.
	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
	status mismatch is found, the mismatch result SHOULD be reported to		status mismatch is found, the mismatch result is expected to be
	the management plane for further action.		reported to the management plane for further action.
	<ConfirmDataChannelStatusAck Message> ::= <Common Header>		<ConfirmDataChannelStatusAck Message> ::= <Common Header>
	<MESSAGE_ID_ACK>		<MESSAGE_ID_ACK>
	<DATA_LINK>[<DATA_LINK>...]		<DATA_LINK>[<DATA_LINK>...]
	The contents of the MESSAGE_ID_ACK objects MUST be obtained from the		The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
	ConfirmDataChannelStatus message being acknowledged.		ConfirmDataChannelStatus message being acknowledged.
	Note that the ConfirmDataChannelStatusAck message is used both when		Note that the ConfirmDataChannelStatusAck message is used both when
	the data channel statuses match and when they do not match.		the data channel statuses match and when they do not match.
	skipping to change at page 9, line 37		skipping to change at page 9, line 47
	// Data Channel ID //		// Data Channel ID //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Data Channel Status:		Data Channel Status:
	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 cross-connected/allocated.		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 zeros.
	If such padding is required, the Length field MUST indicate the		If such padding is required, the Length field MUST indicate the
	length of the subobject up to, but not including, the first byte of		length of the subobject up to, but not including, the first byte of
	padding. Thus, the amount of padding is deduced and not represented		padding. Thus, the amount of padding is deduced and not represented
	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.
	skipping to change at page 10, line 18		skipping to change at page 10, line 28
	per RFC4606.		per RFC4606.
	5. Procedures		5. Procedures
	The data channel status confirmation related LMP messages are sent		The data channel status confirmation related LMP messages are sent
	between adjacent nodes periodically or driven by some events to		between adjacent nodes periodically or driven by some events to
	confirm the channel status for the data links. The procedure is		confirm the channel status for the data links. The procedure is
	described below:		described below:
	. The SENDER constructs a ConfirmDataChannelStatus message which		. The SENDER constructs a ConfirmDataChannelStatus message which
	contains one or more DATA_LINK objects. Each DATA_LINK object		contains one or more DATA_LINK objects. DATA_LINK object is
	contains one or more Data Channel Status subobject. The Data		defined in [RFC4204]. Each DATA_LINK object contains one or more
	Channel ID field in the Data Channel Status subobject indicates		Data Channel Status subobject. The Data Channel ID field in the
	which data channel needs to be confirmed, and reports the data		Data Channel Status subobject indicates which data channel needs
	channel status at the SENDER. The ConfirmDataChannelStatus message		to be confirmed, and reports the data channel status at the SENDER.
	is sent to the RECEIVER.		The ConfirmDataChannelStatus message is sent to the RECEIVER.
	. The RECEIVER extracts the data channel statuses from the		. The RECEIVER extracts the data channel statuses from the
	ConfirmDataChannelStatus message, and compares these with its data		ConfirmDataChannelStatus message, and compares these with its data
	channel statuses for the reported data channels. If a data channel		channel statuses for the reported data channels. If a data channel
	status mismatch is found, the mismatch result SHOULD be reported		status mismatch is found, the mismatch result SHOULD be reported
	to the management plane for further action. The RECEIVER also		to the management plane for further action. The RECEIVER also
	sends the ConfirmDataChannelStatusAck message which carries all		sends the ConfirmDataChannelStatusAck message which carries all
	the local end statuses of the requested data channels to the		the local end statuses of the requested data channels to the
	SENDER.		SENDER.
	skipping to change at page 10, line 49		skipping to change at page 11, line 15
	. The SENDER receives the response ConfirmDataChannelStatusAck		. The SENDER receives the response ConfirmDataChannelStatusAck
	message, and compares the received data channel statuses at the		message, and compares the received data channel statuses at the
	remote end with the data channel statuses at the local end. If a		remote end with the data channel statuses at the local end. 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.		be reported to the management plane for further action.
	. The ConfirmDataChannelStatus message SHOULD be resent, if the		. The ConfirmDataChannelStatus message SHOULD be resent, if the
	ConfirmDataChannelStatusNack message is received or no response		ConfirmDataChannelStatusNack message is received or no response
	message is received in the configured time by the SENDER.		message is received in the configured time by the SENDER.
	The data channel status mismatch results MAY be stored, and this		The data channel status mismatch issue identified by LMP may be
	information MAY be queried in the future.
	The data channel status mismatch issue warned about 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.		state in the restarting node. The issue may also be resolved via RSVP
			soft state timeout.
	If the ConfirmDataChannelStatus message is not recognized by the		If the ConfirmDataChannelStatus message is not recognized by the
	RECEIVER, the RECEIVER will not send out an acknowledgement message		RECEIVER, the RECEIVER ignores this message, and will not send out an
	to the SENDER. In this case, if the ConfirmDataChannelStatusAck or		acknowledgment message to the SENDER.
			Due to message loss problem, the SENDER may not be able to receive
			the acknowledgment message.
			In the above two cases, if the ConfirmDataChannelStatusAck or
	ConfirmDataChannelStatusNack message is not received by the SENDER		ConfirmDataChannelStatusNack message is not received by the SENDER
	within the configured time, the SENDER SHOULD terminate the data		within the configured time, the SENDER SHOULD terminate the data
	channel confirmation procedure. A default value of 1 minutes is		channel confirmation procedure. A default value of 1 minute is
	suggested for this timer.		suggested for this timer.
	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
	skipping to change at page 12, line 21		skipping to change at page 12, line 36
	Class name space". IANA is requested to make the following allocation		Class name space". IANA is requested to make the following allocation
	from this embedded registry. The value shown is suggested and to be		from this embedded registry. The value shown is suggested and to be
	confirmed by IANA.		confirmed by IANA.
	Value Description		Value Description
	------ ---------------------------------		------ ---------------------------------
	9 Data Channel Status		9 Data Channel Status
	8. Acknowledgments		8. Acknowledgments
	We would like to thank Adrian Farrel, Dimitri Papadimitriou for their		We would like to thank Adrian Farrel, Dimitri Papadimitriou, Lou
	useful comments.		Berger for their useful comments.
	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.
	9.2. Informative References		9.2. Informative References
			[RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) --
			Version 1 Functional Specification", RFC 2205, September
			1997
			[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
			Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
			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
	skipping to change at page 13, line 4		skipping to change at page 13, line 26
	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		[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 P.R.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 P.R.China		Shenzhen 518129 China
	Phone: +86 755-289-72909		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 P.R.China		Shenzhen 518129 China
	Phone: +86 755-28979791		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
	2801 Telecom Parkway,		2801 Telecom Parkway,
	Richardson, Texas 75082		Richardson, Texas 75082, USA
	United States of America
	Phone: +1 972 479 2951		Phone: +1 972 479 2951
	Email: snigdho.bardalai@us.fujitsu.com		Email: snigdho.bardalai@us.fujitsu.com
	Julien Meuric		Julien Meuric
	France Telecom		France Telecom Orange Labs
	Orange Labs
	2, avenue Pierre Marzin		2, avenue Pierre Marzin
	22307 Lannion Cedex		22307 Lannion Cedex, France
	France
	Phone: +33 2 96 05 28 28		Phone: +33 2 96 05 28 28
	Email: julien.meuric@orange-ftgroup.com		Email: julien.meuric@orange-ftgroup.com
	Diego Caviglia		Diego Caviglia
	Ericsson		Ericsson
	Via A. Negrone 1/A 16153		Via A. Negrone 1/A 16153
	Genoa Italy		Genoa Italy
	Phone: +39 010 600 3736		Phone: +39 010 600 3736
	Email: diego.caviglia@ericsson.com		Email: diego.caviglia@ericsson.com
	11. Full Copyright Statement		11. Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
	This document is subject to the rights, licenses and restrictions		This document is subject to BCP 78 and the IETF Trust's Legal
	contained in BCP 78, and except as set forth therein, the authors		Provisions Relating to IETF Documents in effect on the date of
	retain all their rights.		publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	This document and the information contained herein are provided on an		This document may contain material from IETF Documents or IETF
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		Contributions published or made publicly available before November 10,
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		2008. The person(s) controlling the copyright in some of this
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		material may not have granted the IETF Trust the right to allow
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		modifications of such material outside the IETF Standards Process.
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		Without obtaining an adequate license from the person(s) controlling
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	12. Intellectual Property Statement		12. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF Trust takes no position regarding the validity or scope of
	Intellectual Property Rights or other rights that might be claimed to		any Intellectual Property Rights or other rights that might be
	pertain to the implementation or use of the technology described in		claimed to pertain to the implementation or use of the technology
	this document or the extent to which any license under such rights		described in any IETF Document or the extent to which any license
	might or might not be available; nor does it represent that it has		under such rights might or might not be available; nor does it
	made any independent effort to identify any such rights. Information		represent that it has made any independent effort to identify any
	on the procedures with respect to rights in RFC documents can be		such rights.
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of Intellectual Property disclosures made to the IETF
	assurances of licenses to be made available, or the result of an		Secretariat and any assurances of licenses to be made available, or
	attempt made to obtain a general license or permission for the use of		the result of an attempt made to obtain a general license or
	such proprietary rights by implementers or users of this		permission for the use of such proprietary rights by implementers or
	specification can be obtained from the IETF on-line IPR repository at		users of this specification can be obtained from the IETF on-line IPR
	http://www.ietf.org/ipr.		repository at http://www.ietf.org/ipr
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		any standard or specification contained in an IETF Document. Please
	ietf-ipr@ietf.org.		address the information to the IETF at ietf-ipr@ietf.org.
	Internet-Drafts are working documents of the Internet Engineering		13. Disclaimer of Validity
	Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet- Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		All IETF Documents and the information contained therein are provided
	months and may be updated, replaced, or obsoleted by other documents		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	at any time. It is inappropriate to use Internet-Drafts as reference		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	material or to cite them other than as "work in progress".		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
			WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
			WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
			ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
			FOR A PARTICULAR PURPOSE. Provisions Relating to IETF Documents in
			effect on the date of publication of this document
			(http://trustee.ietf.org/license-info). Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document.
End of changes. 52 change blocks.
	118 lines changed or deleted		143 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/