< draft-thubert-6lowpan-simple-fragment-recovery-05.txt		draft-thubert-6lowpan-simple-fragment-recovery-06.txt >
	6LoWPAN P. Thubert, Ed.		6LoWPAN P. Thubert, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track J. Hui		Intended status: Standards Track J. Hui
	Expires: September 29, 2009 Arch Rock Corporation		Expires: January 1, 2010 Arch Rock Corporation
	March 28, 2009		June 30, 2009
	LoWPAN simple fragment Recovery		LoWPAN simple fragment Recovery
	draft-thubert-6lowpan-simple-fragment-recovery-05		draft-thubert-6lowpan-simple-fragment-recovery-06
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 September 29, 2009.		This Internet-Draft will expire on January 1, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	Considering that 6LoWPAN packets can be as large as 2K bytes and that		Considering that the IPv6 minimum MTU is 1280 bytes and that an an
	an 802.15.4 frame with security will carry in the order of 80 bytes		802.15.4 frame can have a payload limited to 74 bytes in the worst
	of effective payload, a packet might end up fragmented into as many		case, a packet might end up fragmented into as many as 18 fragments
	as 25 fragments at the 6LoWPAN shim layer. If a single one of those		at the 6LoWPAN shim layer. If a single one of those fragments is
	fragments is lost in transmission, all fragments must be resent,		lost in transmission, all fragments must be resent, further
	further contributing to the congestion that might have caused the		contributing to the congestion that might have caused the initial
	initial packet loss. This draft introduces a simple protocol to		packet loss. This draft introduces a simple protocol to recover
	recover individual fragments that might be lost over multiple hops		individual fragments that might be lost over multiple hops between
	between 6LoWPAN endpoints.		6LoWPAN endpoints.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7		6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7
	6.1. Recoverable Fragment Dispatch type and Header . . . . . . 8		6.1. Recoverable Fragment Dispatch type and Header . . . . . . 8
	6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8		6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8
	7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . . 9		7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . . 11		11.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	In many 6LoWPAN applications, the majority of traffic is spent		In many 6LoWPAN applications, the majority of traffic is spent
	sending small chunks of data (order few bytes to few tens of bytes)		sending small chunks of data (order few bytes to few tens of bytes)
	per packet. Given that an 802.15.4 frame can carry on the order of		per packet. Given that an 802.15.4 frame can carry 74 bytes or more
	80 bytes in the worst case, fragmentation is often not needed for		in all cases, fragmentation is often not needed for most application
	most application traffic. However, many applications also require		traffic. However, many applications also require occasional bulk
	occasional bulk data transfer capabilities to support firmware		data transfer capabilities to support firmware upgrades of 6LoWPAN
	upgrades of 6LoWPAN devices or extraction of logs from 6LoWPAN		devices or extraction of logs from 6LoWPAN devices. In the former
	devices. In the former case, bulk data is transferred to the 6LoWPAN		case, bulk data is transferred to the 6LoWPAN device, and in the
	device, and in the latter, bulk data flows away from the 6LoWPAN		latter, bulk data flows away from the 6LoWPAN device. In both cases,
	device. In both cases, the bulk data size is often on the order of		the bulk data size is often on the order of 10K bytes or more and
	10K bytes or more and end-to-end reliable transport is required.		end-to-end reliable transport is required.
	Mechanisms such as TCP or application-layer segmentation will be used		Mechanisms such as TCP or application-layer segmentation will be used
	to support end-to-end reliable transport. One option to support bulk		to support end-to-end reliable transport. One option to support bulk
	data transfer over 6LoWPAN links is to set the Maximum Segment Size		data transfer over 6LoWPAN links is to set the Maximum Segment Size
	to fit within the 802.15.4 MTU. Doing so, however, can add		to fit within the 802.15.4 MTU. Doing so, however, can add
	significant header overhead to each 802.15.4 frame. This causes the		significant header overhead to each 802.15.4 frame. This causes the
	end-to-end transport to be aware of the delivery properties of		end-to-end transport to be aware of the delivery properties of
	6LoWPAN networks, which is a layer violation.		6LoWPAN networks, which is a layer violation.
	An alternative mechanism combines the use of 6LoWPAN fragmentation in		An alternative mechanism combines the use of 6LoWPAN fragmentation in
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 34 ¶
	Error Recovery Procedure.		Error Recovery Procedure.
	LoWPAN endpoints		LoWPAN endpoints
	The LoWPAN nodes in charge of generating or expanding a 6LoWPAN		The LoWPAN nodes in charge of generating or expanding a 6LoWPAN
	header from/to a full IPv6 packet. The LoWPAN endpoints are the		header from/to a full IPv6 packet. The LoWPAN endpoints are the
	points where fragmentation and reassembly take place.		points where fragmentation and reassembly take place.
	3. Rationale		3. Rationale
	There are a number of usages for large packets in Wireless Sensor		There are a number of uses for large packets in Wireless Sensor
	Networks. Such usages may not be the most typical or represent the		Networks. Such usages may not be the most typical or represent the
	largest amount of traffic over the LoWPAN; however, the associated		largest amount of traffic over the LoWPAN; however, the associated
	functionality can be critical enough to justify extra care for		functionality can be critical enough to justify extra care for
	ensuring effective transport of large packets across the LoWPAN.		ensuring effective transport of large packets across the LoWPAN.
	The list of those usages includes:		The list of those usages includes:
	Towards the LoWPAN node:		Towards the LoWPAN node:
	Packages of Commands: A number of commands or a full		Packages of Commands: A number of commands or a full
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 44 ¶
	hop to emerge from its sleeping state.		hop to emerge from its sleeping state.
	To demonstrate the severity of the problem, consider a fairly		To demonstrate the severity of the problem, consider a fairly
	reliable 802.15.4 frame delivery rate of 99.9% over a single 802.15.4		reliable 802.15.4 frame delivery rate of 99.9% over a single 802.15.4
	hop. The expected delivery rate of a 5-fragment datagram would be		hop. The expected delivery rate of a 5-fragment datagram would be
	about 99.5% over a single 802.15.4 hop. However, the expected		about 99.5% over a single 802.15.4 hop. However, the expected
	delivery rate would drop to 95.1% over 10 hops, a reasonable network		delivery rate would drop to 95.1% over 10 hops, a reasonable network
	diameter for 6LoWPAN applications. The expected delivery rate for a		diameter for 6LoWPAN applications. The expected delivery rate for a
	1280-byte datagram is 98.4% over a single hop and 85.2% over 10 hops.		1280-byte datagram is 98.4% over a single hop and 85.2% over 10 hops.
	Considering that 6LoWPAN packets can be as large as 2K bytes and that		Considering that the IPv6 minimum MTU is 1280 bytes and that a
	a 802.15.4 frame with security will carry in the order of 80 bytes of		802.15.4 frame can limit the MAC payload to as little as 74 bytes, a
	effective payload, a packet might be fragmented into about 25		packet might be fragmented into at least 18 fragments at the 6LoWPAM
	fragments at the 6LoWPAN shim layer. This level of fragmentation is		shim layer. Taking into account the worst-case header overhead for
	much higher than that traditionally experienced over the Internet		6LoWPAN Fragmentation and Mesh Addressing headers will increase the
	with IPv4 fragments. At the same time, the use of radios increases		number of required fragments to around 32. This level of
	the probability of transmission loss and Mesh-Under techniques		fragmentation is much higher than that traditionally experienced over
	compound that risk over multiple hops.		the Internet with IPv4 fragments. At the same time, the use of
			radios increases the probability of transmission loss and Mesh-Under
			techniques compound that risk over multiple hops.
	4. Requirements		4. Requirements
	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
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 29 ¶
	When set, the sender requires an Acknowledgment from the receiver		When set, the sender requires an Acknowledgment 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
			The specification also defines an acknowledgement bitmap that is used
			to carry selective acknowlegements for the received fragments. A
			given offset in the bitmap maps one to one with a given sequence
			number.
			The bitmap is compressed as a variable length field formed by control
			bits and acknowledgement bits. The leftmost bits of the compressed
			form are control bits up to the first 0. The rest is ack bits
			encoded right to left:
			Pattern Size Ack
			+--------------------------------------+----------+----------+
			| 0XXXXXXX | 1 octet | 1 -> 7 |
			| 10XXXXXX XXXXXXXX | 2 octets | 1 -> 14 |
			| 110XXXXX XXXXXXXX XXXXXXXX | 3 octets | 1 -> 21 |
			| 1110XXXX XXXXXXXX XXXXXXXX XXXXXXXX | 4 octets | 1 -> 28 |
			+------------+-----------------------------------------------+
			Figure 3: Compressed acknowledgement bitmap encoding
			The highest sequence number to be acknowledged determines the pattern
			to be used. The format can be extended for more fragments in the
			future but this specification only requires the support of up to 4
			octets encoding, which enables to acknowledge up to 28 fragments.
			A 32 bits uncompressed bitmap is obtained by prepending zeroes to the
			XXX in the pattern above. For instance:
			0 1 2 3 4 5 6 7
			+-+-+-+-+-+-+-+-+
			|0|1|1|0|1|1|1|1| is expanded as:
			+-+-+-+-+-+-+-+-+
			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|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|1|0|1|1|1|1|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 4: Expanding 1 octet encoding
			and
			1 2
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|1|1|0|1|1|1|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|0|0|1| is expanded as:
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			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|0|0|0|0|0|0|0|0|0|0|1|1|1|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|0|0|1|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 5: Expanding 3 octets encoding
			whereas the 4 octets encoding is expanded by simply setting the first
			3 bits to 0. The 32 bits uncompressed bitmap is written and read as
			follows:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Acknowledgment Bitmap |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			^ ^
			bitmap indicating whether: | |
			Fragment with sequence 10 was received --+ |
			Fragment with sequence 00 was received ----------------------+
			Figure 6: Expanded bitmap encoding
			So in the example in Figure 5 it appears that all fragments from
			sequence 0 to 20 were received but for sequence 1, 2 and 16 that were
			either lost or are still in the network over a slower path.
			The compressed form of the acknowledgement bitmap is carried in a
			Fragment Acknowledgement as follows:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Acknowledgment Bitmap |		| Compressed Acknowledgment Bitmap (8 to 32 bits)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+ ....
	^ ^
	| | Y is reserved
	| |
	| | bitmap indicating whether
	| +-----Fragment with sequence 10 was received
	+-------------------------Fragment with sequence 00 was received
	Figure 3: Fragment Acknowledgement Dispatch type and Header		Figure 7: Fragment Acknowledgement Dispatch type and Header
	Acknowledgement Bitmap		Compressed Acknowledgement Bitmap
	Each bit in the Bitmap refers to a particular fragment: bit n set		An encoded form of an acknowledgement bitmap.
	indicates that fragment with sequence n was received, for n in
	[0..31]. A NULL bitmap (All zeroes) means that the fragment was
	dropped .
	7. Fragments Recovery		7. Fragments Recovery
	The Recoverable Fragments header RFRAG and RFRAG-AR deprecate the		The Recoverable Fragments header RFRAG and RFRAG-AR deprecate the
	original fragment headers from [RFC4944] and replace them in the		original fragment headers from [RFC4944] and replace them in the
	fragmented packets. The Fragment Acknowledgement RFRAG-ACK is		fragmented packets. The Fragment Acknowledgement RFRAG-ACK is
	introduced as a standalone header in message that is sent back to the		introduced as a standalone header in message that is sent back to the
	fragment source endpoint as known by its MAC address. This assumes		fragment source endpoint as known by its MAC address. This assumes
	that the source MAC address in the fragment (is any) and datagram_tag		that the source MAC address in the fragment (is any) and datagram_tag
	are enough information to send the Fragment Acknowledgement back to		are enough information to send the Fragment Acknowledgement back to
	skipping to change at page 10, line 26 ¶		skipping to change at page 11, line 43 ¶
	fragments for a first time before it retries any lost fragment; lost		fragments for a first time before it retries any lost fragment; lost
	fragments are retried in sequence, oldest first. This mechanism		fragments are retried in sequence, oldest first. This mechanism
	enables the receiver to acknowledge fragments that were delayed in		enables the receiver to acknowledge fragments that were delayed in
	the network before they are actually retried.		the network before they are actually retried.
	When the sender decides that a packet should be dropped and the		When the sender decides that a packet should be dropped and the
	fragmentation process canceled, it sends a pseudo fragment with the		fragmentation process canceled, it sends a pseudo fragment with the
	datagram_offset, sequence and datagram_size all set to zero, and no		datagram_offset, sequence and datagram_size all set to zero, and no
	data. Upon reception of this message, the receiver should clean up		data. Upon reception of this message, the receiver should clean up
	all resources for the packet associated to the datagram_tag. If an		all resources for the packet associated to the datagram_tag. If an
	acknowledment is requested, the receiver responds with a NULL bitmap.		acknowledgement is requested, the receiver responds with a NULL
			bitmap.
	The receiver might need to cancel the process of a fragmented packet		The receiver might need to cancel the process of a fragmented packet
	for internal reasons, for instance if it is out of recomposition		for internal reasons, for instance if it is out of recomposition
	buffers, or considers that this packet is already fully recomposed		buffers, or considers that this packet is already fully recomposed
	and passed to the upper layer. In that case, the receiver SHOULD		and passed to the upper layer. In that case, the receiver SHOULD
	indicate so to the sender with a NULL bitmap. Upon an		indicate so to the sender with a NULL bitmap. Upon an
	acknowledgement with a NULL bitmap, the sender MUST drop the		acknowledgement with a NULL bitmap, the sender MUST drop the
	datagram.		datagram.
	8. Security Considerations		8. Security Considerations
End of changes. 14 change blocks.
	54 lines changed or deleted		125 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/