draft-ietf-ccamp-confirm-data-channel-status-00.txt		draft-ietf-ccamp-confirm-data-channel-status-01.txt
	skipping to change at page 1, line 14		skipping to change at page 1, line 14
	Huawei		Huawei
	Snigdho Bardalai		Snigdho Bardalai
	Fujitsu		Fujitsu
	Julien Meuric		Julien Meuric
	France Telecom		France Telecom
	Diego Caviglia		Diego Caviglia
	Ericsson		Ericsson
	Internet Draft		Internet Draft
	Category: Standards Track		Category: Standards Track
	Expires: September 2008 March 27, 2008		Expires: April 2009 October 30, 2008
	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-00.txt		draft-ietf-ccamp-confirm-data-channel-status-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that		By submitting this Internet-Draft, each author represents that
	any applicable patent or other IPR claims of which he or she is		any applicable patent or other IPR claims of which he or she is
	aware have been or will be disclosed, and any of which he or she		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		becomes aware will be disclosed, in accordance with Section 6 of
	BCP 79.		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 months		Internet-Drafts are draft documents valid for a maximum of six
	and may be updated, replaced, or obsoleted by other documents at any		months and may be updated, replaced, or obsoleted by other documents
	time. It is inappropriate to use Internet-Drafts as reference		at any time. It is inappropriate to use Internet-Drafts as
	material or to cite them other than as "work in progress."		reference 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
	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 the		Protocol (LMP) to provide a control plane tool that can assist in
	location of stranded resources by allowing adjacent LSRs to confirm		the location of stranded resources by allowing adjacent LSRs to
	data channel statuses, and provides triggers for notifying the		confirm data channel statuses, and provides triggers for notifying
	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.............5		2.3. Manual Change of the Cross-Connection State.............6
	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.........................................11
	7.1. LMP Message Types......................................11		7.1. LMP Message Types......................................11
	7.2. LMP Data Link Object Subobject.........................11		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.................................12
	10. Author's Addresses.........................................13		10. Author's Addresses.........................................13
	11. Full Copyright Statement...................................14		11. Full Copyright Statement...................................14
	12. Intellectual Property Statement............................14		12. Intellectual Property Statement............................14
	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		Switching Routers (LSRs). The TE links are constructed from a set of
	of data channels. In this context, a data channel corresponds to		data channels. In this context, a data channel corresponds to a
	a resource label in a non-packet technology (such as a timeslot or		resource label in a non-packet technology (such as a timeslot or a
	a lambda).		lambda).
	A data channel status mismatch exists if the LSR at one end of a TE		A data channel status mismatch exists if the LSR at one end of a TE
	link believes that the data channel is assigned to carry data, but		link believes that the data channel is assigned to carry data, but
	the LSR at the other end does not. The term "ready to carry data"		the LSR at the other end does not. The term "ready to carry data"
	means cross-connected or bound to an end-point for the receipt or		means cross-connected or bound to an end-point for the receipt or
	delivery of data.		delivery of data.
	Data channel mismatches cannot be detected from the TE information		Data channel mismatches cannot be detected from the TE information
	advertised by the routing protocols [RFC4203], [RFC4205]. The		advertised by the routing protocols [RFC4203], [RFC4205]. The
	existence of some data channel mismatch problems may be detected by		existence of some data channel mismatch problems may be detected by
	a mismatch in the advertised bandwidths where bidirectional TE links		a mismatch in the advertised bandwidths where bidirectional TE links
	and bidirectional services are in use, but where unidirectional		and bidirectional services are in use, but where unidirectional
	services exist, or where multiple data channel mismatches occur, it		services exist, or where multiple data channel mismatches occur, it
	is not possible to detect such errors through the routing protocol-		is not possible to detect such errors through the routing protocol-
	advertised TE information. In any case, there is no mechanism to		advertised TE information. In any case, there is no mechanism to
	isolate the mismatches by determining which data channels are at		isolate the mismatches by determining which data channels are at
	fault.		fault.
	If a data channel mismatch exists, any attempt to use the data		If a data channel mismatch exists, any attempt to use the data
	channel for a new LSP will fail. One end of the TE link may attempt		channel for a new LSP will fail. One end of the TE link may attempt
	to assign the TE link for use, but the other end will report the data		to assign the TE link for use, but the other end will report the
	channel as unavailable when the control plane or management plane		data channel as unavailable when the control plane or management
	attempts to assign it to an LSP.		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 signaling		procedure is inefficient since it may require an additional
	exchange for each LSP that is set up. When many LSPs are to be set		signaling exchange for each LSP that is set up. When many LSPs are
	up, and when there are many data channel mismatches, such		to be set 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
	skipping to change at page 4, line 32		skipping to change at page 4, line 37
	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		2.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 TE link using an EMS. The resource at one end of the data channel		a TE link using an EMS. The resource at one end of the data channel
	is allocated, but the corresponding resource is still available at		is allocated, but the corresponding resource is still available at
	the other end of the same data channel. In this case, the data		the other end of the same data channel. In this case, the data
	channel may appear to be available for use by the control plane		channel may appear to be available for use by the control plane when
	when viewed from one end of the TE link, but will be considered to		viewed from one end of the TE link, but will be considered to be
	be unavailable by the other end of the TE link. Alternatively, the		unavailable by the other end of the TE link. Alternatively, the
	available end of the data channel may be cross-connected by the		available end of the data channel may be cross-connected by the
	management plane and a misconnection may result from the fact that		management plane and a misconnection may result from the fact that
	the other end of the data channel is already cross-connected.		the other end of the 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 available, so the data
	channel status is mismatched.		channel status is mismatched.
	allocated available		allocated available
	skipping to change at page 5, line 41		skipping to change at page 6, line 5
	state after the expiry of the Recovery Timer. It is a local policy		state after the expiry of the Recovery Timer. It is a local policy
	decision how this mismatched state is handled. Some deployments may		decision how this mismatched state is handled. Some deployments may
	decide to automatically clean up the data plane state so it matches		decide to automatically clean up the data plane state so it matches
	the control 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		the management plane and leave the data plane untouched just in case
	it is in use.		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-Connect 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		red-line, etc. These operations will make it impossible to release
	the cross-connect when an LSP is being deleted.		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 on		termination point of a TE-link is seen as failed by one end, while
	the other end it is seen as OK. This problem may arise due to some		on the other end it is seen as OK. This problem may arise due to
	failure either in the hardware or in the status detection of the		some failure either in the hardware or in the status detection of
	termination point.		the termination point.
	This mismatch in the termination point status can lead to failure in		This mismatch in the termination point status can lead to failure
	case of bidirectional LSP set-up.		in case of bidirectional LSP set-up.
	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
	skipping to change at page 7, line 24		skipping to change at page 7, line 29
	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		rejection of an LSP setup message because of an unavailable resource).
	resource).
	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 44		skipping to change at page 8, line 47
	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 which 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 10 minutes
	is RECOMMENDED for this timer.		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		4.2. Data Channel Status Subobject
	skipping to change at page 9, line 43		skipping to change at page 9, line 43
	This is a series of bit flags to indicate the status of the data		This is a series of bit flags to indicate the status of the data
	channel. The following values are defined.		channel. The following values are defined.
	0x0000 : The channel is available/free.		0x0000 : The channel is available/free.
	0x0001 : The channel is cross-connected/allocated.		0x0001 : The channel is cross-connected/allocated.
	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		subobjects must be padded to a four byte boundary with trailing zeros.
	zeros. If such padding is required, the Length field MUST indicate		If such padding is required, the Length field MUST indicate the
	the length of the subobject up to, but not including, the first		length of the subobject up to, but not including, the first byte of
	byte of padding. Thus, the amount of padding is deduced and not		padding. Thus, the amount of padding is deduced and not represented
	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. SONET/SDH, Lambda etc. the encoding methodology
	used will be different. For SONET/SDH the label value is encoded as		used will be different. For SONET/SDH the label value is encoded as
	per RFC4606.		per RFC4606.
	5. Procedures		5. Procedures
	skipping to change at page 11, line 11		skipping to change at page 11, line 11
	The data channel status mismatch results MAY be stored, and this		The data channel status mismatch results MAY be stored, and this
	information MAY be queried in the future.		information MAY be queried in the future.
	The data channel status mismatch issue warned about by LMP may be		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.
			If the ConfirmDataChannelStatus message is not recognized by the
			RECEIVER, and the RECEIVER may not send out an acknowledgement
			message to the SENDER. In this case, if the
			ConfirmDataChannelStatusAck or ConfirmDataChannelStatusNack message
			is not received by the SENDER within the configured time, the SENDER
			SHOULD terminate the data channel confirmation procedure. A default
			value of 1 minutes is 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
	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 plane
	skipping to change at page 12, line 13		skipping to change at page 12, line 21
	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 and Dimitri Papadimitriou for		We would like to thank Adrian Farrel, Dimitri Papadimitriou for their
	their useful comments.		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.
	skipping to change at page 12, line 39		skipping to change at page 13, line 4
	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
	10. Author's Addresses		10. Authors' Addresses
	Dan Li		Dan Li
	Huawei Technologies Co., Ltd.		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Bantian, Longgang District
	Shenzhen 518129 P.R.China		Shenzhen 518129 P.R.China
	Phone: +86-755-28973237		Phone: +86 755-289-71184
	Email: danli@huawei.com		Email: danli@huawei.com
	Huiying Xu		Huiying Xu
	Huawei Technologies Co., Ltd.		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Bantian, Longgang District
	Shenzhen 518129 P.R.China		Shenzhen 518129 P.R.China
	Phone: +86-755-28972909		Phone: +86 755-289-72909
	Email: xuhuiying@huawei.com		Email: xuhuiying@huawei.com
	Fatai Zhang		Fatai Zhang
	Huawei Technologies Co., Ltd.		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Bantian, Longgang District
	Shenzhen 518129 P.R.China		Shenzhen 518129 P.R.China
	Phone: +86-755-28979791		Phone: +86 755-28979791
	Email: zhangfatai@huawei.com		Email: zhangfatai@huawei.com
	Snigdho C. Bardalai		Snigdho C. Bardalai
	Fujitsu Network Communications, Inc.		Fujitsu Network Communications
	2801 Telecom Parkway,		2801 Telecom Parkway,
	Richardson, Texas 75082		Richardson, Texas 75082
	United States of America		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
	2, avenue Pierre Marzin		2, avenue Pierre Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
End of changes. 30 change blocks.
	54 lines changed or deleted		57 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/