< draft-thubert-6lowpan-simple-fragment-recovery-02.txt		draft-thubert-6lowpan-simple-fragment-recovery-03.txt >
	6LoWPAN P. Thubert		6LoWPAN P. Thubert, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track May 29, 2008		Intended status: Standards Track March 23, 2009
	Expires: November 30, 2008		Expires: September 24, 2009
	LoWPAN simple fragment Recovery		LoWPAN simple fragment Recovery
	draft-thubert-6lowpan-simple-fragment-recovery-02		draft-thubert-6lowpan-simple-fragment-recovery-03
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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 months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as 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.
	This Internet-Draft will expire on November 30, 2008.		This Internet-Draft will expire on September 24, 2009.
	Copyright Notice		Copyright Notice
	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 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.
	Abstract		Abstract
	Considering that 6LoWPAN packets can be as large as 2K bytes and that		Considering that 6LoWPAN packets can be as large as 2K bytes and that
	an 802.15.4 frame with security will carry in the order of 80 bytes		an 802.15.4 frame with security will carry in the order of 80 bytes
	of effective payload, a packet might end up fragmented into as many		of effective payload, a packet might end up fragmented into as many
	as 25 fragments at the 6LoWPAN shim layer. If a single one of those		as 25 fragments at the 6LoWPAN shim layer. If a single one of those
	fragments is lost in transmission, all fragments must be resent,		fragments is lost in transmission, all fragments must be resent,
	further contributing to the congestion that might have caused the		further contributing to the congestion that might have caused the
	initial packet loss. This draft introduces a simple protocol to		initial packet loss. This draft introduces a simple protocol to
	skipping to change at page 2, line 23 ¶		skipping to change at page 3, line 4 ¶
	6.1. Recoverable Fragment Dispatch type and Header . . . . . . 7		6.1. Recoverable Fragment Dispatch type and Header . . . . . . 7
	6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8		6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8
	7. Outstanding Fragments Control . . . . . . . . . . . . . . . . 8		7. Outstanding Fragments Control . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Considering that 6LoWPAN packets can be as large as 2K bytes and that		Considering that 6LoWPAN packets can be as large as 2K bytes and that
	a 802.15.4 frame with security will carry in the order of 80 bytes of		a 802.15.4 frame with security will carry in the order of 80 bytes of
	effective payload, a packet might be fragmented into about 25		effective payload, a packet might be fragmented into about 25
	fragments at the 6LoWPAN shim layer. This level of fragmentation is		fragments at the 6LoWPAN shim layer. This level of fragmentation is
	much higher than that traditionally experienced over the Internet		much higher than that traditionally experienced over the Internet
	with IPv4 fragments. At the same time, the use of radios increases		with IPv4 fragments. At the same time, the use of radios increases
	the probability of transmission loss and Mesh-Under techniques		the probability of transmission loss and Mesh-Under techniques
	compound that risk over multiple hops.		compound that risk over multiple hops.
	Past experience with fragmentation has shown that missassociated or		Past experience with fragmentation has shown that missassociated or
	lost fragments can lead to poor network behaviour and, eventually,		lost fragments can lead to poor network behaviour and, eventually,
	trouble at application layer. The reader might start his research		trouble at application layer. The reader is encouraged to read
	from [I-D.mathis-frag-harmful] and follow the references. That		[RFC4963] and follow the references for more information. That
	experience led to the definition of the Path MTU discovery [RFC1191]		experience led to the definition of the Path MTU discovery [RFC1191]
	protocol that avoids fragmentation over the Internet.		protocol that limits fragmentation over the Internet.
	An end-to-end fragment recovery mechanism might be a good complement		An end-to-end fragment recovery mechanism might be a good complement
	to a hop-by-hop MAC level recovery with a limited number of retries.		to a hop-by-hop MAC level recovery with a limited number of retries.
	This draft introduces a simple protocol to recover individual		This draft introduces a simple protocol to recover individual
	fragments between 6LoWPAN endpoints. Specifically in the case of		fragments between 6LoWPAN endpoints. Specifically in the case of
	UDP, valuable additional information can be found in UDP Usage		UDP, valuable additional information can be found in UDP Usage
	Guidelines for Application Designers [I-D.ietf-tsvwg-udp-guidelines].		Guidelines for Application Designers [I-D.ietf-tsvwg-udp-guidelines].
	2. Terminology		2. Terminology
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	This paper proposes a method to recover individual fragments between		This paper proposes a method to recover individual fragments between
	LoWPAN endpoints. The method is designed to fit the following		LoWPAN endpoints. The method is designed to fit the following
	requirements of a LoWPAN (with or without a Mesh-Under routing		requirements of a LoWPAN (with or without a Mesh-Under routing
	protocol):		protocol):
	Number of fragments		Number of fragments
	The recovery mechanism must support highly fragmented packets,		The recovery mechanism must support highly fragmented packets,
	with a maximum of 32 fragments per packet.		with a maximum of 32 fragments per packet.
	Minimimum acknowledgement overhead		Minimum acknowledgement overhead
	Because the radio is half duplex, and because of silent time spent		Because the radio is half duplex, and because of silent time spent
	in the various medium access mechanisms, an acknowledgement		in the various medium access mechanisms, an acknowledgement
	consumes roughly as many resources as data fragment.		consumes roughly as many resources as data fragment.
	The recovery mechanism should be able to acknowledge multiple		The recovery mechanism should be able to acknowledge multiple
	fragments in a single message.		fragments in a single message.
	Controlled latency		Controlled latency
	skipping to change at page 5, line 39 ¶		skipping to change at page 5, line 39 ¶
	boundary imposed by the recovery process of the Upper Layer		boundary imposed by the recovery process of the Upper Layer
	Protocols.		Protocols.
	Support for out-of-order fragment delivery		Support for out-of-order fragment delivery
	A Mesh-Under load balancing mechanism such as the ISA100 Data Link		A Mesh-Under load balancing mechanism such as the ISA100 Data Link
	Layer can introduce out-of-sequence packets. The recovery		Layer can introduce out-of-sequence packets. The recovery
	mechanism must account for packets that appear lost but are		mechanism must account for packets that appear lost but are
	actually only delayed over a different path.		actually only delayed over a different path.
	Optional flow control		Optional congestion control
	The aggregation of multiple concurrent flows may lead to the		The aggregation of multiple concurrent flows may lead to the
	saturation of the radio network and congestion collapse.		saturation of the radio network and congestion collapse.
	The recovery mechanism should provide means for controlling the		The recovery mechanism should provide means for controlling the
	number of fragments in transit over the LoWPAN.		number of fragments in transit over the LoWPAN.
	Backward compatibility		Backward compatibility
	A node that implements this draft should be able to communicate		A node that implements this draft should be able to communicate
	with a node that implements [RFC4944]. This draft assumes that		with a node that implements [RFC4944]. This draft assumes that
	compatibility information about the remote LoWPAN endpoint is		compatibility information about the remote LoWPAN endpoint is
	obtained by external means.		obtained by external means.
	5. Overview		5. Overview
	Considering that a multi-hop LoWPAN can be a very sensitive		Considering that a multi-hop LoWPAN can be a very sensitive
	environment due to the limited queueing capabilities of a large		environment due to the limited queueing capabilities of a large
	population of its nodes, this draft recommends a simple and		population of its nodes, this draft recommends a simple and
	conservative approach to flow control, based on TCP congestion		conservative approach to congestion control, based on TCP congestion
	avoidance.		avoidance.
	Congestion on the forward path is assumed in case of packet loss, and		Congestion on the forward path is assumed in case of packet loss, and
	packet loss is assumed upon time out.		packet loss is assumed upon time out.
	Congestion on the forward path can also be indicated by an Explicit		Congestion on the forward path can also be indicated by an Explicit
	Congestion Notification (ECN) mechanism. Though whether and how ECN		Congestion Notification (ECN) mechanism. Though whether and how ECN
	[RFC3168] is carried out over the LoWPAN is out of scope, this draft		[RFC3168] is carried out over the LoWPAN is out of scope, this draft
	provides a way for the destination endpoint to echo an ECN indication		provides a way for the destination endpoint to echo an ECN indication
	back to the source endpoint in an acknowledgement message as		back to the source endpoint in an acknowledgement message as
	skipping to change at page 7, line 8 ¶		skipping to change at page 7, line 8 ¶
	to reducing the number of outstanding fragments over a congested path		to reducing the number of outstanding fragments over a congested path
	by throttling the sources.		by throttling the sources.
	Section 7 describes how the sender decides how many fragments are		Section 7 describes how the sender decides how many fragments are
	(re)sent before an acknowledgement is required, and how the sender		(re)sent before an acknowledgement is required, and how the sender
	adapts that number to the network conditions.		adapts that number to the network conditions.
	6. New Dispatch types and headers		6. New Dispatch types and headers
	This specification extends "Transmission of IPv6 Packets over IEEE		This specification extends "Transmission of IPv6 Packets over IEEE
	802.15.4 Networks" [RFC4944] with 3 new dispatch types, for		802.15.4 Networks" [RFC4944] with 4 new dispatch types, for
	Recoverable Fragments (RFRAG) headers with or without Acknowledgement		Recoverable Fragments (RFRAG) headers with or without Acknowledgement
	Request, and for the Acknowledgement back.		Request, and for the Acknowledgement back, with or without ECN Echo.
	Pattern Header Type		Pattern Header Type
	+------------+-----------------------------------------------+		+------------+-----------------------------------------------+
	| 11 101000 | RFRAG - Recoverable Fragment |		| 11 101000 | RFRAG - Recoverable Fragment |
	| 11 101001 | RFRAG-AR - RFRAG with Acknowledgement Req |		| 11 101001 | RFRAG-AR - RFRAG with Ack Request |
	| 11 101010 | RFRAG-ACK - RFRAG Acknowledgement |		| 11 101010 | RFRAG-ACK - RFRAG Acknowledgement |
			| 11 101011 | RFRAG-AEC - RFRAG Ack with ECN Echo |
	+------------+-----------------------------------------------+		+------------+-----------------------------------------------+
	Figure 1: Additional Dispatch Value Bit Patterns		Figure 1: Additional Dispatch Value Bit Patterns
	In the following sections, the semantics of "datagram_tag,"		In the following sections, the semantics of "datagram_tag,"
	"datagram_offset" and "datagram_size" and the reassembly process are		"datagram_offset" and "datagram_size" and the reassembly process are
	unchanged from [RFC4944] Section 5.3. "Fragmentation Type and		unchanged from [RFC4944] Section 5.3. "Fragmentation Type and
	Header."		Header."
	6.1. Recoverable Fragment Dispatch type and Header		6.1. Recoverable Fragment Dispatch type and Header
	skipping to change at page 7, line 44 ¶		skipping to change at page 8, line 4 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	X set == Ack Requested		X set == Ack Requested
	Figure 2: Recoverable Fragment Dispatch type and Header		Figure 2: Recoverable Fragment Dispatch type and Header
	X bit		X bit
	When set, the sender requires an Acknowledgement from the receiver		When set, the sender requires an Acknowledgement from the receiver
	Sequence		Sequence
	The sequence number of the fragment. Fragments are numbered		The sequence number of the fragment. Fragments are numbered
	[0..N] where N is in [0..31].		[0..N] where N is in [0..31].
	6.2. Fragment Acknowledgement Dispatch type and Header		6.2. Fragment Acknowledgement Dispatch type and Header
	1 2 3		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1 1 1 0 1 0 1 Y| datagram_tag |		|1 1 1 0 1 0 1 Y| datagram_tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Acknowledgement Bitmap |		| Acknowledgement Bitmap |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	^ ^		^ ^
	| | Y set == ECN echo		| | Y set == ECN echo
	| |		| |
	| | bitmap indicating whether		| | bitmap indicating whether
	| +-----Fragment with sequence 10 was received		| +-----Fragment with sequence 10 was received
	+-------------------------Fragment with sequence 00 was received		+-------------------------Fragment with sequence 00 was received
	Figure 3: Fragment Acknowledgement Dispatch type and Header		Figure 3: Fragment Acknowledgement Dispatch type and Header
	Y bit		Y bit
	skipping to change at page 10, line 37 ¶		skipping to change at page 10, line 40 ¶
	[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission		[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
	Timer", RFC 2988, November 2000.		Timer", RFC 2988, November 2000.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, September 2007.		Networks", RFC 4944, September 2007.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-tsvwg-udp-guidelines]		[I-D.ietf-tsvwg-udp-guidelines]
	Eggert, L. and G. Fairhurst, "Guidelines for Application		Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
	Designers on Using Unicast UDP",		for Application Designers",
	draft-ietf-tsvwg-udp-guidelines-07 (work in progress),		draft-ietf-tsvwg-udp-guidelines-11 (work in progress),
	May 2008.		October 2008.
	[I-D.mathis-frag-harmful]		[I-D.mathis-frag-harmful]
	Mathis, M., "Fragmentation Considered Very Harmful",		Mathis, M., "Fragmentation Considered Very Harmful",
	draft-mathis-frag-harmful-00 (work in progress),		draft-mathis-frag-harmful-00 (work in progress),
	July 2004.		July 2004.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	November 1990.		November 1990.
	[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,		[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 31 ¶
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, September 2001.		RFC 3168, September 2001.
	[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6		[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):		over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals",		Overview, Assumptions, Problem Statement, and Goals",
	RFC 4919, August 2007.		RFC 4919, August 2007.
			[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
			Errors at High Data Rates", RFC 4963, July 2007.
	Author's Address		Author's Address
	Pascal Thubert		Pascal Thubert (editor)
	Cisco Systems		Cisco Systems
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue de Roumanille		400, Avenue de Roumanille
	Batiment T3		Batiment T3
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	Phone: +33 4 97 23 26 34		Phone: +33 4 97 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF 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
	this 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. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR 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
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 22 change blocks.
	27 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/