< draft-thubert-roll-forwarding-frags-00.txt		draft-thubert-roll-forwarding-frags-01.txt >
	ROLL P. Thubert, Ed.		ROLL P. Thubert, Ed.
	Internet-Draft J. Hui		Internet-Draft J. Hui
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: September 30, 2012 March 29, 2012		Expires: August 29, 2013 February 25, 2013
	LLN Fragment Forwarding and Recovery		LLN Fragment Forwarding and Recovery
	draft-thubert-roll-forwarding-frags-00		draft-thubert-roll-forwarding-frags-01
	Abstract		Abstract
	In order to be routed, a fragmented packet must be reassembled at		In order to be routed, a fragmented packet must be reassembled at
	every hop of a multihop link where lower layer fragmentation occurs.		every hop of a multihop link where lower layer fragmentation occurs.
	Considering that the IPv6 minimum MTU is 1280 bytes and that an an		Considering that the IPv6 minimum MTU is 1280 bytes and that an an
	802.15.4 frame can have a payload limited to 74 bytes in the worst		802.15.4 frame can have a payload limited to 74 bytes in the worst
	case, a packet might end up fragmented into as many as 18 fragments		case, a packet might end up fragmented into as many as 18 fragments
	at the 6LoWPAN shim layer. If a single one of those fragments is		at the 6LoWPAN shim layer. If a single one of those fragments is
	lost in transmission, all fragments must be resent, further		lost in transmission, all fragments must be resent, further
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on September 30, 2012.		This Internet-Draft will expire on August 29, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	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 . . . . . . . . . . . . . . . . 8
	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 . . . . 9
	7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . . 10		7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . . 10
	8. Forwarding Fragments . . . . . . . . . . . . . . . . . . . . . 12		8. Forwarding Fragments . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Upon the first fragment . . . . . . . . . . . . . . . . . 12		8.1. Upon the first fragment . . . . . . . . . . . . . . . . . 12
	8.2. Upon the next fragments . . . . . . . . . . . . . . . . . 13		8.2. Upon the next fragments . . . . . . . . . . . . . . . . . 13
	8.3. Upon the fragment acknowledgements . . . . . . . . . . . . 14		8.3. Upon the fragment acknowledgements . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 15		12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	12.2. Informative References . . . . . . . . . . . . . . . . . . 15		12.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	In most Low Power and Lossy Network (LLN) applications, the bulk of		In most Low Power and Lossy Network (LLN) applications, the bulk of
	the traffic consists of small chunks of data (in the order few bytes		the traffic consists of small chunks of data (in the order few bytes
	to a few tens of bytes) at a time. Given that an 802.15.4 frame can		to a few tens of bytes) at a time. Given that an 802.15.4 frame can
	carry 74 bytes or more in all cases, fragmentation is usually not		carry 74 bytes or more in all cases, fragmentation is usually not
	required. However, and though this happens only occasionally, a		required. However, and though this happens only occasionally, a
	number of mission critical applications do require the capability to		number of mission critical applications do require the capability to
	transfer larger chunks of data, for instance to support a firmware		transfer larger chunks of data, for instance to support a firmware
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 15 ¶
	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 LLN.		number of fragments in transit over the LLN.
	5. Overview		5. Overview
	Considering that a multi-hop LLN can be a very sensitive environment		Considering that a multi-hop LLN can be a very sensitive environment
	due to the limited queuing capabilities of a large population of its		due to the limited queuing capabilities of a large population of its
	nodes, this draft recommends a simple and conservative approach to		nodes, this draft recommends a simple and conservative approach to
	congestion control, based on TCP congestion avoidance.		congestion control, based on TCP congestion avoidance.
			Congestion on the forward path is assumed in case of packet loss, and
			packet loss is assumed upon time out.
			Congestion on the forward path can also be indicated by an Explicit
			Congestion Notification (ECN) mechanism. Though whether and how ECN
			[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
			back to the source endpoint in an acknowledgment message as
			represented in Figure 5 in Section 6.2.
	From the standpoint of a source 6LoWPAN endpoint, an outstanding		From the standpoint of a source 6LoWPAN endpoint, an outstanding
	fragment is a fragment that was sent but for which no explicit		fragment is a fragment that was sent but for which no explicit
	acknowledgment was received yet. This means that the fragment might		acknowledgment was received yet. This means that the fragment might
	be on the way, received but not yet acknowledged, or the		be on the way, received but not yet acknowledged, or the
	acknowledgment might be on the way back. It is also possible that		acknowledgment might be on the way back. It is also possible that
	either the fragment or the acknowledgment was lost on the way.		either the fragment or the acknowledgment was lost on the way.
	Because a meshed LLN might deliver frames out of order, it is		Because a meshed LLN might deliver frames out of order, it is
	virtually impossible to differentiate these situations. In other		virtually impossible to differentiate these situations. In other
	words, from the sender standpoint, all outstanding fragments might		words, from the sender standpoint, all outstanding fragments might
	still be in the network and contribute to its congestion. There is		still be in the network and contribute to its congestion. There is
	an assumption, though, that after a certain amount of time, a frame		an assumption, though, that after a certain amount of time, a frame
	is either received or lost, so it is not causing congestion anymore.		is either received or lost, so it is not causing congestion anymore.
	This amount of time can be estimated based on the round trip delay		This amount of time can be estimated based on the round trip delay
	between the 6LoWPAN endpoints. The method detailed in [RFC2988] is		between the 6LoWPAN endpoints. The method detailed in [RFC2988] is
	recommended for that computation.		recommended for that computation.
			The reader is encouraged to read through "Congestion Control
			Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide
			deeper information on why this mechanism is needed and how TCP
			handles Congestion Control. Basically, the goal here is to manage
			the amount of fragments present in the network; this is achieved by
			to reducing the number of outstanding fragments over a congested path
			by throttling the sources.
			Section 7 describes how the sender decides how many fragments are
			(re)sent before an acknowledgment is required, and how the sender
			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 4 new dispatch types, for		802.15.4 Networks" [RFC4944] with 4 new dispatch types, for
	Recoverable Fragments (RFRAG) headers with or without Acknowledgment		Recoverable Fragments (RFRAG) headers with or without Acknowledgment
	Request, and for the Acknowledgment back.		Request, and for the Acknowledgment 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 Ack Request |		| 11 101001 | RFRAG-AR - RFRAG with Ack Request |
	| 11 10101x | RFRAG-ACK - RFRAG Acknowledgment |		| 11 101010 | RFRAG-ACK - RFRAG Acknowledgment |
			| 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
	changed from [RFC4944] Section 5.3. "Fragmentation Type and Header."		changed from [RFC4944] Section 5.3. "Fragmentation Type and Header."
	The size and offset are expressed on the compressed packet as opposed		The size and offset are expressed on the compressed packet per
	to the uncompressed form.		[RFC6282] as opposed to the uncompressed - native packet - form.
	6.1. Recoverable Fragment Dispatch type and Header		6.1. Recoverable Fragment 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 0 X|datagram_offset| datagram_tag |		|1 1 1 0 1 0 0 X|datagram_offset| datagram_tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Sequence | datagram_size |		|Sequence | datagram_size |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 8, line 25 ¶		skipping to change at page 9, 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 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		The specification also defines a 4-octet acknowledgement bitmap that
	to carry selective acknowlegements for the received fragments. A		is used to carry selective acknowlegements for the received
	given offset in the bitmap maps one to one with a given sequence		fragments. A given offset in the bitmap maps one to one with a given
	number.		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		The offset of the bit in the bitmap indicates which fragment is
			acknowledged as follows:
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|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|		| Acknowledgment Bitmap |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			^ ^
			| | bitmap indicating whether:
			| +--- Fragment with sequence 10 was received
			+----------------------- Fragment with sequence 00 was received
	Figure 5: Expanding 3 octets encoding		Figure 3: Acknowledgement bitmap encoding
	whereas the 4 octets encoding is expanded by simply setting the first		So in the example below Figure 4 it appears that all fragments from
	3 bits to 0. The 32 bits uncompressed bitmap is written and read as		sequence 0 to 20 were received but for sequence 1, 2 and 16 that were
	follows:		either lost or are still in the network over a slower path.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Acknowledgment Bitmap |		|1|0|0|1|1|1|1|1|1|1|1|1|1|1|1|1|0|1|1|1|1|0|0|0|0|0|0|0|0|0|0|0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	^ ^
	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		Figure 4: Expanding 3 octets encoding
	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		The acknowledgement bitmap is carried in a Fragment Acknowledgement
	Fragment Acknowledgement as follows:		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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Compressed Acknowledgment Bitmap (8 to 32 bits)		| Acknowledgment Bitmap (32 bits) |
	+-+-+-+-+-+-+-+-+-+ ....		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 5: Fragment Acknowledgement Dispatch type and Header
	Figure 7: Fragment Acknowledgement Dispatch type and Header
	Y bit		Y bit
	Reserved for Explicit Congestion Notification (ECN) signalling		Explicit Congestion Notification (ECN) signalling
	Compressed Acknowledgement Bitmap		When set, the sender indicates that at least one of the
			acknowledged fragments was received with an Explicit Congestion
			Notification, indicating that the path followed by the fragments
			is subject to congestion.
	An encoded form of an acknowledgement bitmap.		Acknowledgement Bitmap
			An acknowledgement bitmap, whereby but at offset x indicates that
			fragment x was received.
	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 15, line 4 ¶		skipping to change at page 14, line 35 ¶
	Need extensions for formats defined in "Transmission of IPv6 Packets		Need extensions for formats defined in "Transmission of IPv6 Packets
	over IEEE 802.15.4 Networks" [RFC4944].		over IEEE 802.15.4 Networks" [RFC4944].
	11. Acknowledgments		11. Acknowledgments
	The author wishes to thank Jay Werb, Christos Polyzois, Soumitri		The author wishes to thank Jay Werb, Christos Polyzois, Soumitri
	Kolavennu and Harry Courtice for their contribution and review.		Kolavennu and Harry Courtice for their contribution and review.
	12. References		12. References
	12.1. Normative References		12.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.
	[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.
	12.2. Informative References		[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
			Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
			September 2011.
	[I-D.ietf-roll-rpl]		12.2. Informative References
	Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
	Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
	Winter, "RPL: IPv6 Routing Protocol for Low power and
	Lossy Networks", draft-ietf-roll-rpl-19 (work in
	progress), March 2011.
	[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,
			S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
			Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
			S., Wroclawski, J., and L. Zhang, "Recommendations on
			Queue Management and Congestion Avoidance in the
			Internet", RFC 2309, April 1998.
			[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
			Control", RFC 2581, April 1999.
			[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
			RFC 2914, September 2000.
			[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
			of Explicit Congestion Notification (ECN) to IP",
			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		[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
	Errors at High Data Rates", RFC 4963, July 2007.		Errors at High Data Rates", RFC 4963, July 2007.
	[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines		[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
	for Application Designers", BCP 145, RFC 5405,		for Application Designers", BCP 145, RFC 5405,
	November 2008.		November 2008.
			[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
			Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
			Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
			Lossy Networks", RFC 6550, March 2012.
	Authors' Addresses		Authors' Addresses
	Pascal Thubert (editor)		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
End of changes. 35 change blocks.
	90 lines changed or deleted		95 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/