draft-ietf-ccamp-confirm-data-channel-status-09.txt		rfc5818.txt
	Network Working Group D. Li
	Internet Draft H. Xu
	Category: Standards Track Huawei
	S. Bardalai
	Fujitsu
	J. Meuric
	France Telecom
	D. Caviglia
	Ericsson
	Expires: June 2010 December 14, 2009
	Data Channel Status Confirmation Extensions
	for the Link Management Protocol
	draft-ietf-ccamp-confirm-data-channel-status-09.txt		Internet Engineering Task Force (IETF) D. Li
			Request for Comments: 5818 H. Xu
			Category: Standards Track Huawei
			ISSN: 2070-1721 S. Bardalai
			Fujitsu
			J. Meuric
			France Telecom
			D. Caviglia
			Ericsson
			April 2010
	Status of this Memo		Data Channel Status Confirmation Extensions
			for the Link Management Protocol
	This Internet-Draft is submitted to IETF in full conformance with the		Abstract
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document defines simple additions to the Link Management
	Task Force (IETF), its areas, and its working groups. Note that		Protocol (LMP) to provide a control plane tool that can assist in the
	other groups may also distribute working documents as Internet-Drafts.		location of stranded resources by allowing adjacent Label-Switching
			Routers (LSRs) to confirm data channel statuses and provide triggers
			for notifying the management plane if any discrepancies are found.
			As LMP is already used to verify data plane connectivity, it is
			considered to be an appropriate candidate to support this feature.
	Internet-Drafts are draft documents valid for a maximum of six months		Status of This Memo
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This is an Internet Standards Track document.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		This document is a product of the Internet Engineering Task Force
	http://www.ietf.org/shadow.html.		(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	Abstract		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc5818.
	This document defines simple additions to the Link Management		Copyright Notice
	Protocol (LMP) to provide a control plane tool that can assist in
	the location of stranded resources by allowing adjacent Label-
	Switching Routers (LSRs) to confirm data channel statuses, and
	provides triggers for notifying the management plane if any
	discrepancies are found. As LMP is already used to verify data plane
	connectivity, it is considered to be an appropriate candidate to
	support this feature.
	Conventions used in this document		Copyright (c) 2010 IETF Trust and the persons identified as the
			document authors. All rights reserved.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		This document is subject to BCP 78 and the IETF Trust's Legal
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		Provisions Relating to IETF Documents
	document are to be interpreted as described in [RFC2119].		(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction.................................................2		1. Introduction ....................................................3
	2. Problem Explanation..........................................4		2. Specification of Requirements ...................................4
	2.1. Mismatch Caused by Manual Configuration.................4		3. Problem Explanation .............................................4
	2.2. Mismatch Caused by LSP Deletion.........................5		3.1. Mismatch Caused by Manual Configuration ....................4
	2.3. Failed Resources........................................6		3.2. Mismatch Caused by LSP Deletion ............................5
	3. Motivation...................................................6		3.3. Failed Resources ...........................................6
	4. Extensions to LMP............................................7		4. Motivation ......................................................6
	4.1. Confirm Data Channel Status Messages....................7		5. Extensions to LMP ...............................................7
	4.1.1. ConfirmDataChannelStatus Messages..................7		5.1. Confirm Data Channel Status Messages .......................7
	4.1.2. ConfirmDataChannelStatusAck Messages...............8		5.1.1. ConfirmDataChannelStatus Messages ...................8
	4.1.3. ConfirmDataChannelStatusNack Messages..............8		5.1.2. ConfirmDataChannelStatusAck Messages ................8
	4.2. Data Channel Status Subobject...........................9		5.1.3. ConfirmDataChannelStatusNack Messages ...............8
	4.3. Message Construction...................................10		5.2. Data Channel Status Subobject ..............................9
	4.4. Backward Compatibility.................................10		5.3. Message Construction ......................................10
	5. Procedures..................................................10		5.4. Backward Compatibility ....................................10
	6. Security Considerations.....................................12		6. Procedures .....................................................11
	7. IANA Considerations.........................................12		7. Security Considerations ........................................12
	7.1. LMP Message Types......................................12		8. IANA Considerations ............................................12
	7.2. LMP Data Link Object Subobject.........................12		8.1. LMP Message Types .........................................12
	8. Acknowledgments.............................................13		8.2. LMP Data Link Object Subobject ............................13
	9. References..................................................13		8.3. LMP Error_Code Class Type .................................13
	9.1. Normative References...................................13		9. Acknowledgments ................................................13
	9.2. Informative References.................................13		10. References ....................................................13
	10. Authors' Addresses.........................................14		10.1. Normative References .....................................13
	11. Full Copyright Statement...................................15		10.2. Informative References ...................................14
	12. Intellectual Property Statement............................15		Contributor's Address .............................................14
	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], [RFC5307]. 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
	a mismatch in the advertised bandwidths where bidirectional TE links		mismatch in the advertised bandwidths where bidirectional TE links
	and bidirectional services are in use, but where unidirectional		and bidirectional services are in use. However, 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 Label Switched Path (LSP) will fail. One end of		channel for a new Label Switched Path (LSP) will fail. One end of
	the TE link may attempt to assign the TE link for use, but the other		the TE link may attempt to assign the TE link for use, but the other
	end will report the data channel as unavailable when the control		end will report the data channel as unavailable when the control
	plane or management 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
	signaling exchange for each LSP that is set up. When many LSPs are		exchange for each LSP that is set up. When many LSPs are to be set
	to be set up, and when there are many data channel mismatches, such		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.
	Correspondingly, such a mismatch situation may give rise to		Correspondingly, such a mismatch situation may give rise to
	misconnections in the data plane especially when LSPs are set up		misconnections in the data plane, especially when LSPs are set up
	using management plane operations.		using management plane operations.
	Resources (data channels) that are in a mismatched state are often		Resources (data channels) that are in a mismatched state are often
	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.
	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 provide triggers for
	notifying the management plane if any discrepancies are found. As LMP		notifying the management plane if any discrepancies are found. As
	is already used to verify data plane connectivity, it is considered		LMP is already used to verify data plane connectivity, it is
	to be an appropriate candidate to support this feature.		considered to be an appropriate candidate to support this feature.
	2. Problem Explanation		2. Specification of Requirements
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			3. 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.
	In all of the scenarios, the specific channel resource of a data link		In all of the scenarios, the specific channel resource of a data link
	will be unavailable because of the data channel status mismatch, and		will be unavailable because of the data channel status mismatch, and
	this channel resource will be wasted. Furthermore, a data channel		this channel resource will be wasted. Furthermore, a data channel
	status mismatch may reduce the possibility of successful LSP		status mismatch may reduce the possibility of successful LSP
	establishment, because a data channel status mismatch may result in		establishment, because a data channel status mismatch may result in
	failure when establishing an LSP.		failure when establishing an LSP.
	So it is desirable to confirm the data channel statuses as early as		So it is desirable to confirm the data channel statuses as early as
	possible.		possible.
	2.1. Mismatch Caused by Manual Configuration		3.1. Mismatch Caused by Manual Configuration
	The operator may have configured a cross-connect at only one end of		The operator may have configured a cross-connect at only one end of a
	a TE link using an EMS. The resource at one end of the data channel		TE link using an EMS. The resource at one end of the data channel is
	is allocated, but the corresponding resource is still available at		allocated, but the corresponding resource is still available at the
	the other end of the same data channel. In this case, the data		other end of the same data channel. In this case, the data channel
	channel may appear to be available for use by the control plane when		may appear to be available for use by the control plane when viewed
	viewed from one end of the TE link, but will be considered to be		from one end of the TE link but, will be considered to be unavailable
	unavailable by the other end of the TE link. Alternatively, the		by the other end of the TE link. Alternatively, the available end of
	available end of the data channel may be cross-connected by the		the data channel may be cross-connected by the management plane, and
	management plane and a misconnection may result from the fact that		a misconnection may result from the fact that the other end of the
	the other end of the data channel is already cross-connected.		data channel is already cross-connected.
	Figure 1 shows a data channel between nodes A and B. The resource at		Figure 1 shows a data channel between nodes A and B. The resource at
	A's end of the TE link is allocated through manual configuration,		A's end of the TE link is allocated through manual configuration,
	while the resource at B's end of the TE link available, so the data		while the resource at B's end of the TE link is available, so the
	channel status is mismatched.		data channel status is mismatched.
	allocated available		allocated available
	+-+------------+-+		+-+------------+-+
	A |x| | | B		A |x| | | B
	+-+------------+-+		+-+------------+-+
	data channel		data channel
	Figure 1. Mismatch caused by manual configuration
	2.2. Mismatch Caused by LSP Deletion		Figure 1. Mismatch Caused by Manual Configuration
			3.2. Mismatch Caused by LSP Deletion
	The channel status of a data link may become mismatched during the		The channel status of a data link may become mismatched during the
	LSP deletion process. If the LSP deletion process is aborted in the		LSP deletion process. If the LSP deletion process is aborted in the
	middle of the process (perhaps because of a temporary control plane		middle of the process (perhaps because of a temporary control plane
	failure), the cross-connect at the upstream node may be removed while		failure), the cross-connect at the upstream node may be removed while
	the downstream node still keeps its cross-connect, if the LSP		the downstream node still keeps its cross-connect, if the LSP
	deletion was initiated by the source node.		deletion was initiated by the source node.
	For example, in Figure 2 an LSP traverses nodes A, B, and C. Node B		For example, in Figure 2, an LSP traverses nodes A, B, and C. Node B
	resets abnormally when the LSP is being deleted. This results in the		resets abnormally when the LSP is being deleted. This results in the
	cross-connects of node A and C being removed, but the cross-connect		cross-connects of nodes A and C being removed, but the cross-connect
	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
	In [RFC2205] and [RFC3209], a soft state mechanism was defined to		Figure 2. Mismatch Caused by LSP Deletion
	prevent state discrepancies between LSRs. Resource ReserVation
			In [RFC2205] and [RFC3209], a "soft state" mechanism was defined to
			prevent state discrepancies between LSRs. Resource ReSerVation
	Protocol-Traffic Engineering (RSVP-TE) restart processes ([RFC3473],		Protocol-Traffic Engineering (RSVP-TE) restart processes ([RFC3473],
	[RFC5063]) have been defined: adjacent LSRs may resynchronize their		[RFC5063]) have been defined: adjacent LSRs may resynchronize their
	control plane state to reinstate information about LSPs that have		control plane state to reinstate information about LSPs that have
	persisted in the data plane. Both mechanisms aim at keeping state		persisted in the data plane. Both mechanisms aim at keeping state
	consistency among nodes and allow LSRs to detect mismatched data		consistency among nodes and allow LSRs to detect mismatched data
	plane states. The data plane handling of such mismatched state can be		plane states. The data plane handling of such mismatched states can
	treated as a local policy decision. Some deployments may decide to		be treated as a local policy decision. Some deployments may decide
	automatically clean up the data plane state so it matches the control		to automatically clean up the data plane state so it matches the
	plane state, but others may choose to raise an alert to the		control plane state, but others may choose to raise an alert to the
	management plane and leave the data plane untouched just in case it		management plane and leave the data plane untouched just in case it
	is in use.		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		3.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
	on the other end it is seen as OK. This problem may arise due to		the other end it is seen as OK. This problem may arise due to some
	some failure either in the hardware or in the status detection of		failure either in the hardware or in the status detection of the
	the termination point.		termination point.
	This mismatch in the termination point status can lead to failure		This mismatch in the termination point status can lead to failure in
	in case of bidirectional LSP set-up.		the case of bidirectional LSP setup.
	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, the upstream node chooses to use termination point A in
	order to receive traffic from downstream node. From the upstream		order to receive traffic from the downstream node. From the upstream
	node's point of view, the resource is available thus usable; however,		node's point of view, the resource is available and thus usable;
	in the downstream node, the corresponding termination point (resource		however, in the downstream node, the corresponding termination point
	B) is broken. This leads to a set-up failure.		(resource B) is broken. This leads to a setup failure.
	3. Motivation		4. 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 defined in this document are intended to		The protocol extensions defined in this document are intended to
	detect data plane problems resulting from mis-use or mis-		detect data plane problems resulting from misuse or misconfigurations
	configurations triggered by user error, or resulting from failure to		triggered by user error, or resulting from failure to clean up the
	clean up the data plane after control plane disconnection. It is		data plane after control plane disconnection. It is anticipated that
	anticipated that human mistake is probably the major source of errors		human mistakes are probably the major source of errors to deal with.
	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		This document is not intened to provide a protocol mechanism to deal
	on a periodic or on-demand basis. It is NOT RECOMMENDED that the		with broken implementations.
			The procedures defined in this document are designed to be performed
			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		5. 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 6.
	The message formats in the sections that follow use Backus-Naur Form		The message formats in the subsections that follow use Backus-Naur
	(BNF) encoding as defined in [RFC5511].		Form (BNF) encoding as defined in [RFC5511].
	4.1. Confirm Data Channel Status Messages		5.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:		Three new messages are defined to check data channel status:
	ConfirmDataChannelStatus, ConfirmDataChannelStatusAck,		ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, and
	ConfirmDataChannelStatusNack, which are described in detail in the		ConfirmDataChannelStatusNack. These messages are described in detail
	following sections. Message Type numbers are found in Section 7.1.		in the following subsections. Message Type numbers are found in
			Section 8.1.
	4.1.1. ConfirmDataChannelStatus Messages		5.1.1. ConfirmDataChannelStatus Messages
	The ConfirmDataChannelStatus message is used to tell the remote end		The ConfirmDataChannelStatus message is used to provide the remote
	of the data channel what the status of the local end of the data		end of the data channel with the status of the local end of the data
	channel is, and to ask the remote end to report its data channel. The		channel 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>
	<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 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		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.2. ConfirmDataChannelStatusAck Messages		5.1.2. ConfirmDataChannelStatusAck Messages
	The ConfirmDataChannelStatusAck message is sent back to the node		The ConfirmDataChannelStatusAck message is sent back to the node that
	which originated the ConfirmDataChannelStatus message to return the		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 is expected to be		status mismatch is found, the mismatch result is expected to be
	reported to 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.
	4.1.3. ConfirmDataChannelStatusNack Messages		5.1.3. ConfirmDataChannelStatusNack Messages
	When a node receives the ConfirmDataChannelStatus message, if the		When a node receives the ConfirmDataChannelStatus message, if the
	data channel status confirmation procedure is not supported but the		data channel status confirmation procedure is not supported but the
	message is recognized, a ConfirmDataChannelStatusNack message		message is recognized, a ConfirmDataChannelStatusNack message
	containing an ERROR_CODE indicating "Channel Status Confirmation		containing an ERROR_CODE indicating "Channel Status Confirmation
	Procedure not supported" MUST be sent.		Procedure not supported" MUST be sent.
	If the data channel status confirmation procedure is supported, but		If the data channel status confirmation procedure is supported, but
	the node is unable to begin the procedure, a		the node is unable to begin the procedure, a
	ConfirmDataChannelStatusNack message containing an ERROR_CODE		ConfirmDataChannelStatusNack message containing an ERROR_CODE
	indicating "Unwilling to Confirm" MUST be sent. If a		indicating "Unwilling to Confirm" MUST be sent. If a
	ConfirmDataChannelStatusNack message is received with such an		ConfirmDataChannelStatusNack message is received with such an
	ERROR_CODE, the node which originated the ConfirmDataChannelStatus		ERROR_CODE, the node that originated the ConfirmDataChannelStatus
	message MAY schedule the ConfirmDataChannelStatus message		message MAY schedule the ConfirmDataChannelStatus message
	retransmission after a configured time. A default value of 10 minutes		retransmission after a configured time. A default value of
	is suggested for this timer.		10 minutes is suggested for this timer.
	<ConfirmDataChannelStatusNack Message> ::= <Common Header>		<ConfirmDataChannelStatusNack Message> ::= <Common Header>
	[<LOCAL_LINK_ID>]		[<LOCAL_LINK_ID>]
	<MESSAGE_ID_ACK>		<MESSAGE_ID_ACK>
	<ERROR_CODE>		<ERROR_CODE>
	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 rejected.		ConfirmDataChannelStatus message being rejected.
	4.2. Data Channel Status Subobject		The ERROR_CODE object in this message has a new Class Type (see
			Section 8.3), but is formed as the ERROR_CODE object defined in
			[RFC4204]. The following Error Codes are defined:
			0x01 = Channel Status Confirmation Procedure not supported
			0x02 = Unwilling to Confirm
			5.2. Data Channel Status Subobject
	A new Data Channel Status subobject type is introduced to the DATA		A new Data Channel Status subobject type is introduced to the DATA
	LINK object to hold the data channel status and Data Channel		LINK object to hold the Data Channel Status and Data Channel ID.
	Identification.
	See Section 7.2 for the Subobject Type value.		See Section 8.2 for the Subobject Type value.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Data Channel Status |		| Type | Length | Data Channel Status |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// 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 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
			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.
	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., Synchronous Optical Network/Synchronous Digital
	used will be different. For SONET/SDH the label value is encoded as		Hierarchy (SONET/SDH), Lambda, etc.), the encoding methodology
			used will be different. For SONET/SDH, the label value is encoded as
	per [RFC4606].		per [RFC4606].
	4.3. Message Construction		5.3. Message Construction
	Data_Link Class is included in ConfirmDataChannelStatus and		Data_Link Class (as defined in Section 13.12 of [RFC4204]) is
	ConfirmDataChannelStatusAck messages, which is defined in section		included in ConfirmDataChannelStatus and ConfirmDataChannelStatusAck
	13.12 in [RFC4204].		messages.
	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 5.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 SONET/SDH, the Data Channel ID in the new subobject
	be used to identify each timeslot of the data link.		SHOULD be used to identify each timeslot of the data link.
	4.4. Backward Compatibility		5.4. Backward Compatibility
	Some nodes running in the network may only support the LMP Message		Some nodes running in the network might 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
	LMP message defined in this document can not be recognized by these		of LMP messages defined in this document cannot be recognized by
	nodes. The unknown message behavior is not being specified in		these nodes. The behavior of an LMP node that receives an unknown
	[RFC4204], it's suggested to discard the unknown message silently.		message is not specified in [RFC4204] and will be clarified in a
	The mechanism defined in this document presumes a certain non-		separate document.
	standard behavior of existing/non-document supporting nodes. To use
	this mechanism all nodes MUST have the extensions described in this
	document for compatibility.
	5. Procedures		Since the behavior of legacy nodes must be assumed to be unknown,
			this document assumes that a deployment intended to support the
			function described in this document will consist completely of nodes
			that support the protocol extensions also described in this document.
	Adjacent nodes MAY send data channel status confirmation related LMP		In the future, it may be the case that LMP will be extended to allow
	messages. Periodical timers or some other events requesting the		function support to be detected. In that case, it may become
			possible to deploy this function in a mixed environment.
			6. Procedures
			Adjacent nodes MAY send data channel status confirmation-related LMP
			messages. Periodical timers or some other events requesting the
	confirmation of channel status for the data link may trigger these		confirmation of channel status for the data link may trigger these
	messages. It's a local policy decision to start the data channel		messages. It's a local policy decision to start the data channel
	status confirmation process. The procedure is described below:		status confirmation process. The procedure is described below:
	. Initially, the SENDER constructs a ConfirmDataChannelStatus		. Initially, the SENDER constructs a ConfirmDataChannelStatus
	message which MUST contain one or more DATA_LINK objects.		message that MUST contain one or more DATA_LINK objects. The
	DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object		DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object
	MUST contain one or more Data Channel Status subobjects. The Data		MUST contain one or more Data Channel Status subobjects. The Data
	Channel ID field in the Data Channel Status subobject MUST		Channel ID field in the Data Channel Status subobject MUST
	indicate which data channel needs to be confirmed, and MUST report		indicate which data channel needs to be confirmed, and MUST report
	the data channel status at the SENDER. The		the data channel status at the SENDER. The
	ConfirmDataChannelStatus message is sent to the RECEIVER.		ConfirmDataChannelStatus message is sent to the RECEIVER.
	. Upon reception of a ConfirmDataChannelStatus message, the RECEIVER		. Upon receipt of a ConfirmDataChannelStatus message, the RECEIVER
	MUST extract the data channel statuses from the		MUST extract the data channel statuses from the
	ConfirmDataChannelStatus message, and SHOULD compare these with		ConfirmDataChannelStatus message and SHOULD compare these with its
	its data channel statuses for the reported data channels. If a		data channel statuses for the reported data channels. If a data
	data channel status mismatch is found, the mismatch result SHOULD		channel status mismatch is found, the mismatch result SHOULD be
	be reported to the management plane for further action. The		reported to the management plane for further action. The RECEIVER
	RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message		also SHOULD send the ConfirmDataChannelStatusAck message, which
	which MUST carry all the local end statuses of the requested data		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 RECEIVER MUST send a
	MUST be responded with the ERROR_CODE which indicates the reason		ConfirmDataChannelStatusNack message containing the ERROR_CODE
	of rejection.		that indicates the reason for rejection.
	. Upon reception of a ConfirmDataChannelStatusAck message, the		. Upon receipt of a ConfirmDataChannelStatusAck message, the SENDER
	SENDER MUST compare the received data channel statuses at the		MUST compare the received data channel statuses at the remote end
	remote end with the data channel statuses at the local end. If a		with the data channel statuses at the local end. If a data
	data channel status mismatch is found, the mismatch result SHOULD		channel status mismatch is found, the mismatch result SHOULD be
	be reported to the management plane for further action.		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. However, RSVP restart will re-install the data
	state in the restarting node. The issue may also be resolved via RSVP		plane state in the restarting node. The issue may also be resolved
	soft state timeout.		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 ignores this message, and will not send out an		RECEIVER, the RECEIVER ignores this message and will not send out an
	acknowledgment message to the SENDER.		acknowledgment message to the SENDER.
	Due to message loss problem, the SENDER may not be able to receive		Due to the message loss problem, the SENDER may not be able to
	the acknowledgment message.		receive the acknowledgment message.
	ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable		ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
	transmission mechanisms. If after the retry limit is reached, a		transmission mechanisms. If, after the retry limit is reached, a
	ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack		ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
	message is not received by the SENDER, the SENDER SHOULD terminate		message is not received by the SENDER, the SENDER SHOULD terminate
	the data channel confirmation procedure.		the data channel confirmation procedure and SHOULD raise an alert to
			the management plane.
	6. Security Considerations		7. 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 itself constitute a security risk because it does not cause any
	change in network state. It would be possible, if the messages were		change in network state. It would be possible, if the messages were
	intercepted or spoofed to cause bogus alerts in the management plane		intercepted or spoofed, to cause bogus alerts in the management
	and so the use of the LMP security measures are RECOMMENDED.		plane, and so the use of LMP security measures described in [RFC4204]
			is RECOMMENDED.
	Note that operating the procedures described in this document may		Note that performing the procedures described in this document may
	provide a useful additional security measure to verify that data		provide a useful additional security measure to verify that data
	channels have not been illicitly modified.		channels have not been illicitly modified.
	7. IANA Considerations		8. IANA Considerations
	7.1. LMP Message Types		8.1. LMP Message Types
	IANA maintains the "Link Management Protocol (LMP)" registry which		IANA maintains the "Link Management Protocol (LMP)" registry, which
	has a subregistry called "LMP Message Type". IANA is requested to		has a subregistry called "LMP Message Type". IANA has made the
	make three new allocations from this registry as follows. The message		following three new allocations from this registry.
	type values are suggested and to be confirmed by IANA.
	Value Description		Value Description
	------ ---------------------------------		------ ---------------------------------
	32 ConfirmDataChannelStatus		32 ConfirmDataChannelStatus
	33 ConfirmDataChannelStatusAck		33 ConfirmDataChannelStatusAck
	34 ConfirmDataChannelStatusNack		34 ConfirmDataChannelStatusNack
	7.2. LMP Data Link Object Subobject		8.2. LMP Data Link Object Subobject
	IANA maintains the "Link Management Protocol (LMP)" registry which		IANA maintains the "Link Management Protocol (LMP)" registry, which
	has a subregistry called "LMP Object Class name space and Class type		has a subregistry called "LMP Object Class name space and Class type
	(C-Type)". This subregistry has an entry for the DATA_LINK object,		(C-Type)". This subregistry has an entry for the DATA_LINK object,
	and there is a further embedded registry called "DATA_LINK Sub-object		and there is a further embedded registry called "DATA_LINK Sub-object
	Class name space". IANA is requested to make the following allocation		Class name space". IANA has made the following allocation from this
	from this embedded registry. The value shown is suggested and to be		embedded registry.
	confirmed by IANA.
	Value Description		Value Description
	------ ---------------------------------		------ ---------------------------------
	9 Data Channel Status		9 Data Channel Status
	8. Acknowledgments		8.3. LMP Error_Code Class Type
	We would like to thank Adrian Farrel, Dimitri Papadimitriou, Lou		IANA maintains the "Link Management Protocol (LMP)" registry, which
	Berger for their useful comments.		has a subregistry called "LMP Object Class name space and Class type
			(C-Type)". This subregistry has an entry for the ERROR_CODE object.
			IANA has allocated the following new value for an ERROR_CODE class
			type.
	9. References		C-Type Description Reference
			------ ---------------------------- ---------
			4 ConfirmDataChannelStatusNack [This RFC]
	9.1. Normative References		9. Acknowledgments
			The authors would like to thank Adrian Farrel, Dimitri Papadimitriou,
			and Lou Berger for their useful comments.
			10. References
			10.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] Lang, J., Ed., "Link Management Protocol (LMP)",
	October 2005.		RFC 4204, October 2005.
	[RFC5511] A. Farrel, Ed., "Routing Backus-Naur Form (RBNF): A		[RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF):
	Syntax Used to Form Encoding Rules in Various Routing		A Syntax Used to Form Encoding Rules in Various Routing
	Protocol Specifications", RFC 5511, April 2009.		Protocol Specifications", RFC 5511, April 2009.
	9.2. Informative References		10.2. Informative References
	[RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) --		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
	Version 1 Functional Specification", RFC 2205, September		S. Jamin, "Resource ReSerVation Protocol (RSVP) --
	1997		Version 1 Functional Specification", RFC 2205,
			September 1997.
	[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	RFC 3209, December 2001		Tunnels", RFC 3209, December 2001.
	[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label		[RFC3473] Berger, L., 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",
	3473, January 2003		RFC 3473, January 2003.
	[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP		[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
	Graceful Restart", RFC 5063, September 2007		in Support of Generalized Multi-Protocol Label Switching
			(GMPLS)", RFC 4203, October 2005.
	[RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of		[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
	Generalized Multi-Protocol Label Switching (GMPLS)", RFC		Protocol Label Switching (GMPLS) Extensions for
	4203, October 2005		Synchronous Optical Network (SONET) and Synchronous
			Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
	[RFC4606] E. Mannie, Ed., "Generalized Multi-Protocol Label		[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions
	Switching (GMPLS) Extensions for Synchronous Optical		to GMPLS Resource Reservation Protocol (RSVP) Graceful
	Network (SONET) and Synchronous Digital Hierarchy (SDH)		Restart", RFC 5063, October 2007.
	Control", RFC 4606, August 2006
	[RFC5307] K. Kompella, Ed., "IS-IS Extensions in Support of		[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
	Generalized Multi-Protocol Label Switching (GMPLS)", RFC		in Support of Generalized Multi-Protocol Label Switching
	5307, October 2008		(GMPLS)", RFC 5307, October 2008.
	10. Authors' Addresses		Contributor's Address
	Dan Li		Fatai Zhang
	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-72912
	Email: danli@huawei.com		EMail: zhangfatai@huawei.com
	Huiying Xu		Authors' Addresses
			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-72910		Phone: +86 755-289-70230
	Email: xuhuiying@huawei.com		EMail: danli@huawei.com
	Fatai Zhang		Huiying Xu
	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-72912		Phone: +86 755-289-72910
	Email: zhangfatai@huawei.com		EMail: xuhuiying@huawei.com
	Snigdho C. Bardalai		Snigdho C. Bardalai
	Fujitsu Network Communications		Fujitsu Network Communications
	2801 Telecom Parkway,		2801 Telecom Parkway
	Richardson, Texas 75082, USA		Richardson, Texas 75082, USA
	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 Orange Labs		France Telecom Orange Labs
	2, avenue Pierre Marzin		2, avenue Pierre Marzin
	22307 Lannion Cedex, France		22307 Lannion Cedex, 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
	Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal
	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.
	This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November 10,
	2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling
	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
	The IETF Trust takes no position regarding the validity or scope of
	any Intellectual Property Rights or other rights that might be
	claimed to pertain to the implementation or use of the technology
	described in any IETF Document or the extent to which any license
	under such rights might or might not be available; nor does it
	represent that it has made any independent effort to identify any
	such rights.
	Copies of Intellectual Property disclosures made to the IETF
	Secretariat and any assurances of licenses to be made available, or
	the result of an attempt made to obtain a general license or
	permission for the use of such proprietary rights by implementers or
	users of this specification can be obtained from the IETF on-line IPR
	repository at http://www.ietf.org/ipr
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	any standard or specification contained in an IETF Document. Please
	address the information to the IETF at ietf-ipr@ietf.org.
	13. Disclaimer of Validity
	All IETF Documents and the information contained therein are provided
	on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	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. 140 change blocks.
	349 lines changed or deleted		389 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/