< draft-ietf-6lo-fragment-recovery-05.txt		draft-ietf-6lo-fragment-recovery-06.txt >
	6lo P. Thubert, Ed.		6lo P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Updates: 4944 (if approved) July 22, 2019		Updates: 4944 (if approved) 21 October 2019
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 23, 2020		Expires: 23 April 2020
	6LoWPAN Selective Fragment Recovery		6LoWPAN Selective Fragment Recovery
	draft-ietf-6lo-fragment-recovery-05		draft-ietf-6lo-fragment-recovery-06
	Abstract		Abstract
	This draft updates RFC 4944 with a simple protocol to recover		This draft updates RFC 4944 with a simple protocol to recover
	individual fragments across a route-over mesh network, with a minimal		individual fragments across a route-over mesh network, with a minimal
	flow control to protect the network against bloat.		flow control to protect the network against bloat.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 January 23, 2020.		This Internet-Draft will expire on 23 April 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. 6LoWPAN Acronyms . . . . . . . . . . . . . . . . . . . . 4		2.3. 6LoWPAN Acronyms . . . . . . . . . . . . . . . . . . . . 4
	2.4. Referenced Work . . . . . . . . . . . . . . . . . . . . . 4		2.4. Referenced Work . . . . . . . . . . . . . . . . . . . . . 4
	2.5. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5		2.5. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 6		3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 6
	4. Extending draft-ietf-6lo-minimal-fragment . . . . . . . . . . 6		4. Extending draft-ietf-6lo-minimal-fragment . . . . . . . . . . 6
	4.1. Slack in the First Fragment . . . . . . . . . . . . . . . 7		4.1. Slack in the First Fragment . . . . . . . . . . . . . . . 7
	4.2. Gap between frames . . . . . . . . . . . . . . . . . . . 7		4.2. Gap between frames . . . . . . . . . . . . . . . . . . . 7
	4.3. Modifying the First Fragment . . . . . . . . . . . . . . 8		4.3. Modifying the First Fragment . . . . . . . . . . . . . . 7
	5. New Dispatch types and headers . . . . . . . . . . . . . . . 8		5. New Dispatch types and headers . . . . . . . . . . . . . . . 8
	5.1. Recoverable Fragment Dispatch type and Header . . . . . . 9		5.1. Recoverable Fragment Dispatch type and Header . . . . . . 8
	5.2. RFRAG Acknowledgment Dispatch type and Header . . . . . . 11		5.2. RFRAG Acknowledgment Dispatch type and Header . . . . . . 11
	6. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . 12		6. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Forwarding Fragments . . . . . . . . . . . . . . . . . . 14		6.1. Forwarding Fragments . . . . . . . . . . . . . . . . . . 14
	6.1.1. Upon the first fragment . . . . . . . . . . . . . . . 15		6.1.1. Upon the first fragment . . . . . . . . . . . . . . . 14
	6.1.2. Upon the next fragments . . . . . . . . . . . . . . . 15		6.1.2. Upon the next fragments . . . . . . . . . . . . . . . 15
	6.2. Upon the RFRAG Acknowledgments . . . . . . . . . . . . . 16		6.2. Upon the RFRAG Acknowledgments . . . . . . . . . . . . . 15
	6.3. Aborting the Transmission of a Fragmented Packet . . . . 16		6.3. Aborting the Transmission of a Fragmented Packet . . . . 16
	7. Management Considerations . . . . . . . . . . . . . . . . . . 17		7. Management Considerations . . . . . . . . . . . . . . . . . . 16
	7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 17		7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 16
	7.2. Observing the network . . . . . . . . . . . . . . . . . . 18		7.2. Observing the network . . . . . . . . . . . . . . . . . . 18
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		11. Normative References . . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . 19		12. Informative References . . . . . . . . . . . . . . . . . . . 20
	11.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 23		Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 23
	Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 24		Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 24
	Appendix C. Considerations On Flow Control . . . . . . . . . . . 25		Appendix C. Considerations On Flow Control . . . . . . . . . . . 25
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
	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 IEEE Std. 802.15.4		to a few tens of bytes) at a time. Given that an IEEE Std. 802.15.4
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 21 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2.2. References		2.2. References
	In this document, readers will encounter terms and concepts that are		In this document, readers will encounter terms and concepts that are
	discussed in "Problem Statement and Requirements for IPv6 over Low-		discussed in "Problem Statement and Requirements for IPv6 over
	Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606]		Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606]
	2.3. 6LoWPAN Acronyms		2.3. 6LoWPAN Acronyms
	This document uses the following acronyms:		This document uses the following acronyms:
	6BBR: 6LoWPAN Backbone Router		6BBR: 6LoWPAN Backbone Router
			6LBR: 6LoWPAN Border Router
	6LBR: 6LoWPAN Border Router
	6LN: 6LoWPAN Node		6LN: 6LoWPAN Node
	6LR: 6LoWPAN Router		6LR: 6LoWPAN Router
	LLN: Low-Power and Lossy Network		LLN: Low-Power and Lossy Network
	2.4. Referenced Work		2.4. Referenced Work
	Past experience with fragmentation has shown that misassociated or		Past experience with fragmentation has shown that misassociated or
	lost fragments can lead to poor network behavior and, occasionally,		lost fragments can lead to poor network behavior and, occasionally,
	trouble at application layer. The reader is encouraged to read "IPv4		trouble at application layer. The reader is encouraged to read "IPv4
	Reassembly Errors at High Data Rates" [RFC4963] and follow the		Reassembly Errors at High Data Rates" [RFC4963] and follow the
	references for more information.		references for more information.
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 30 ¶
	"LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]		"LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
	introduces the concept of a Virtual Reassembly Buffer (VRB) and an		introduces the concept of a Virtual Reassembly Buffer (VRB) and an
	associated technique to forward fragments as they come, using the		associated technique to forward fragments as they come, using the
	datagram_tag as a label in a fashion similar to MPLS. This		datagram_tag as a label in a fashion similar to MPLS. This
	specification reuses that technique with slightly modified controls.		specification reuses that technique with slightly modified controls.
	2.5. New Terms		2.5. New Terms
	This specification uses the following terms:		This specification uses the following terms:
	6LoWPAN endpoints The LLN nodes in charge of generating or expanding		6LoWPAN endpoints: The LLN nodes in charge of generating or
	a 6LoWPAN header from/to a full IPv6 packet. The 6LoWPAN		expanding a 6LoWPAN header from/to a full IPv6 packet. The
	endpoints are the points where fragmentation and reassembly take		6LoWPAN endpoints are the points where fragmentation and
	place.		reassembly take place.
	Compressed Form This specification uses the generic term Compressed		Compressed Form: This specification uses the generic term Compressed
	Form to refer to the format of a datagram after the action of		Form to refer to the format of a datagram after the action of
	[RFC6282] and possibly [RFC8138] for RPL [RFC6550] artifacts.		[RFC6282] and possibly [RFC8138] for RPL [RFC6550] artifacts.
	datagram_size: The size of the datagram in its Compressed Form		datagram_size: The size of the datagram in its Compressed Form
	before it is fragmented. The datagram_size is expressed in a unit		before it is fragmented. The datagram_size is expressed in a unit
	that depends on the MAC layer technology, by default a byte.		that depends on the MAC layer technology, by default a byte.
	fragment_offset: The offset of a particular fragment of a datagram		fragment_offset: The offset of a particular fragment of a datagram
	in its Compressed Form. The fragment_offset is expressed in a		in its Compressed Form. The fragment_offset is expressed in a
	unit that depends on the MAC layer technology and is by default a		unit that depends on the MAC layer technology and is by default a
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 26 ¶
	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|E| datagram_tag |		|1 1 1 0 1 0 0|E| datagram_tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|X| sequence| fragment_size | fragment_offset |		|X| sequence| fragment_size | fragment_offset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	X set == Ack-Request		X set == Ack-Request
	Figure 1: RFRAG Dispatch type and Header		Figure 1: RFRAG Dispatch type and Header
	There is no requirement on the receiver to check for contiguity of		There is no requirement on the receiver to check for contiguity of
	the received fragments, and the sender MUST ensure that when all		the received fragments, and the sender MUST ensure that when all
	fragments are acknowledged, then the datagram is fully received.		fragments are acknowledged, then the datagram is fully received.
	This may be useful in particular in the case where the MTU changes		This may be useful in particular in the case where the MTU changes
	and a fragment sequence is retried with a smaller fragment_size, the		and a fragment sequence is retried with a smaller fragment_size, the
	remainder of the original fragment being retried with new sequence		remainder of the original fragment being retried with new sequence
	values.		values.
	The first fragment is recognized by a sequence of 0; it carries its		The first fragment is recognized by a sequence of 0; it carries its
	fragment_size and the datagram_size of the compressed packet before		fragment_size and the datagram_size of the compressed packet before
	it is fragmented, whereas the other fragments carry their		it is fragmented, whereas the other fragments carry their
	fragment_size and fragment_offset. The last fragment for a datagram		fragment_size and fragment_offset. The last fragment for a datagram
	is recognized when its fragment_offset and its fragment_size add up		is recognized when its fragment_offset and its fragment_size add up
	to the datagram_size.		to the datagram_size.
	Recoverable Fragments are sequenced and a bitmap is used in the RFRAG		Recoverable Fragments are sequenced and a bitmap is used in the RFRAG
	Acknowledgment to indicate the received fragments by setting the		Acknowledgment to indicate the received fragments by setting the
	individual bits that correspond to their sequence.		individual bits that correspond to their sequence.
	X: 1 bit; Ack-Request: when set, the sender requires an RFRAG		X: 1 bit; Ack-Request: when set, the sender requires an RFRAG
	Acknowledgment from the receiver.		Acknowledgment from the receiver.
	E: 1 bit; Explicit Congestion Notification; the "E" flag is reset by		E: 1 bit; Explicit Congestion Notification; the "E" flag is reset by
	the source of the fragment and set by intermediate routers to		the source of the fragment and set by intermediate routers to
	signal that this fragment experienced congestion along its path.		signal that this fragment experienced congestion along its path.
	Fragment_size: 10 bit unsigned integer; the size of this fragment in		Fragment_size: 10 bit unsigned integer; the size of this fragment in
	a unit that depends on the MAC layer technology. Unless		a unit that depends on the MAC layer technology. Unless
	overridden by a more specific specification, that unit is the		overridden by a more specific specification, that unit is the
	octet which allows fragments up to 512 bytes.		octet which allows fragments up to 512 bytes.
	datagram_tag: 16 bits; an identifier of the datagram that is locally		datagram_tag: 16 bits; an identifier of the datagram that is locally
	unique to the sender.		unique to the sender.
	Sequence: 5 bit unsigned integer; the sequence number of the		Sequence: 5 bit unsigned integer; the sequence number of the
	fragment in the acknowledgement bitmap. Fragments are numbered		fragment in the acknowledgement bitmap. Fragments are numbered
	[0..N] where N is in [0..31]. A Sequence of 0 indicates the first		[0..N] where N is in [0..31]. A Sequence of 0 indicates the first
	fragment in a datagram, but non-zero values are not indicative of		fragment in a datagram, but non-zero values are not indicative of
	the position in the reassembly buffer.		the position in the reassembly buffer.
	Fragment_offset: 16 bit unsigned integer;		Fragment_offset: 16 bit unsigned integer.
	* When the Fragment_offset is set to a non-0 value, its semantics
	depend on the value of the Sequence field.
	+ For a first fragment (i.e. with a Sequence of 0), this field
	indicates the datagram_size of the compressed datagram, to
	help the receiver allocate an adapted buffer for the
	reception and reassembly operations. The fragment may be
	stored for local reassembly. Alternatively, it may be
	routed based on the destination IPv6 address. In that case,
	a VRB state must be installed as described in Section 6.1.1.
	+ When the Sequence is not 0, this field indicates the offset		When the Fragment_offset is set to a non-0 value, its semantics
	of the fragment in the Compressed Form of the datagram. The		depend on the value of the Sequence field as follows:
	fragment may be added to a local reassembly buffer or
	forwarded based on an existing VRB as described in
	Section 6.1.2.
	* A Fragment_offset that is set to a value of 0 indicates an		* For a first fragment (i.e. with a Sequence of 0), this field
	abort condition and all state regarding the datagram should be		indicates the datagram_size of the compressed datagram, to help
	cleaned up once the processing of the fragment is complete; the		the receiver allocate an adapted buffer for the reception and
	processing of the fragment depends on whether there is a VRB		reassembly operations. The fragment may be stored for local
	already established for this datagram, and the next hop is		reassembly. Alternatively, it may be routed based on the
	still reachable:		destination IPv6 address. In that case, a VRB state must be
			installed as described in Section 6.1.1.
			* When the Sequence is not 0, this field indicates the offset of
			the fragment in the Compressed Form of the datagram. The
			fragment may be added to a local reassembly buffer or forwarded
			based on an existing VRB as described in Section 6.1.2.
	+ if a VRB already exists and is not broken, the fragment is		A Fragment_offset that is set to a value of 0 indicates an abort
	to be forwarded along the associated Label Switched Path		condition and all state regarding the datagram should be cleaned
	(LSP) as described in Section 6.1.2, but regardless of the		up once the processing of the fragment is complete; the processing
	value of the Sequence field;		of the fragment depends on whether there is a VRB already
			established for this datagram, and the next hop is still
			reachable:
	+ else, if the Sequence is 0, then the fragment is to be		* if a VRB already exists and is not broken, the fragment is to
	routed as described in Section 6.1.1 but no state is		be forwarded along the associated Label Switched Path (LSP) as
	conserved afterwards. In that case, the session if it		described in Section 6.1.2, but regardless of the value of the
	exists is aborted and the packet is also forwarded in an		Sequence field;
	attempt to clean up the next hops as along the path		* else, if the Sequence is 0, then the fragment is to be routed
	indicated by the IPv6 header (possibly including a routing		as described in Section 6.1.1 but no state is conserved
	header).		afterwards. In that case, the session if it exists is aborted
			and the packet is also forwarded in an attempt to clean up the
			next hops as along the path indicated by the IPv6 header
			(possibly including a routing header).
	If the fragment cannot be forwarded or routed, then an abort		If the fragment cannot be forwarded or routed, then an abort
	RFRAG-ACK is sent back to the source as described in		RFRAG-ACK is sent back to the source as described in
	Section 6.1.2.		Section 6.1.2.
	5.2. RFRAG Acknowledgment Dispatch type and Header		5.2. RFRAG Acknowledgment Dispatch type and Header
	This specification also defines a 4-octet RFRAG Acknowledgment bitmap		This specification also defines a 4-octet RFRAG Acknowledgment bitmap
	that is used by the reassembling end point to confirm selectively the		that is used by the reassembling end point to confirm selectively the
	reception of individual fragments. A given offset in the bitmap maps		reception of individual fragments. A given offset in the bitmap maps
	one to one with a given sequence number and indicates which fragment		one to one with a given sequence number and indicates which fragment
	is acknowledged as follows:		is acknowledged 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RFRAG Acknowledgment Bitmap |		| RFRAG Acknowledgment Bitmap |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	^ ^		^ ^
	| | bitmap indicating whether:		| | bitmap indicating whether:
	| +----- Fragment with sequence 9 was received		| +----- Fragment with sequence 9 was received
	+----------------------- Fragment with sequence 0 was received		+----------------------- Fragment with sequence 0 was received
	Figure 2: RFRAG Acknowledgment bitmap encoding		Figure 2: RFRAG Acknowledgment bitmap encoding
	Figure 3 shows an example Acknowledgment bitmap which indicates that		Figure 3 shows an example Acknowledgment bitmap which indicates that
	all fragments from sequence 0 to 20 were received, except for		all fragments from sequence 0 to 20 were received, except for
	fragments 1, 2 and 16 that were lost and must be retried.		fragments 1, 2 and 16 that were lost and must be retried.
	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|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|		|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|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 4 ¶
	The RFRAG Acknowledgment Bitmap is included in a RFRAG Acknowledgment		The RFRAG Acknowledgment Bitmap is included in a RFRAG Acknowledgment
	header, as follows:		header, 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|E| datagram_tag |		|1 1 1 0 1 0 1|E| datagram_tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RFRAG Acknowledgment Bitmap (32 bits) |		| RFRAG Acknowledgment Bitmap (32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: RFRAG Acknowledgment Dispatch type and Header		Figure 4: RFRAG Acknowledgment Dispatch type and Header
	E: 1 bit; Explicit Congestion Notification Echo		E: 1 bit; Explicit Congestion Notification Echo
	When set, the sender indicates that at least one of the		When set, the sender indicates that at least one of the
	acknowledged fragments was received with an Explicit Congestion		acknowledged fragments was received with an Explicit Congestion
	Notification, indicating that the path followed by the fragments		Notification, indicating that the path followed by the fragments
	is subject to congestion. More in Appendix C.		is subject to congestion. More in Appendix C.
	RFRAG Acknowledgment Bitmap		RFRAG Acknowledgment Bitmap: An RFRAG Acknowledgment Bitmap, whereby
			setting the bit at offset x indicates that fragment x was
	An RFRAG Acknowledgment Bitmap, whereby setting the bit at offset		received, as shown in Figure 2. All 0's is a NULL bitmap that
	x indicates that fragment x was received, as shown in Figure 2.		indicates that the fragmentation process is aborted. All 1's is a
	All 0's is a NULL bitmap that indicates that the fragmentation		FULL bitmap that indicates that the fragmentation process is
	process is aborted. All 1's is a FULL bitmap that indicates that		complete, all fragments were received at the reassembly end point.
	the fragmentation process is complete, all fragments were received
	at the reassembly end point.
	6. Fragments Recovery		6. Fragments Recovery
	The Recoverable Fragment header RFRAG is used to transport a fragment		The Recoverable Fragment header RFRAG is used to transport a fragment
	and optionally request an RFRAG Acknowledgment that will confirm the		and optionally request an RFRAG Acknowledgment that will confirm the
	good reception of one or more fragments. An RFRAG Acknowledgment is		good reception of one or more fragments. An RFRAG Acknowledgment is
	carried as a standalone fragment header (i.e. with no 6LoWPAN		carried as a standalone fragment header (i.e. with no 6LoWPAN
	payload) in a message that is propagated back to the 6LoWPAN endpoint		payload) in a message that is propagated back to the 6LoWPAN endpoint
	that was the originator of the fragments. To achieve this, each hop		that was the originator of the fragments. To achieve this, each hop
	that performed an MPLS-like operation on fragments reverses that		that performed an MPLS-like operation on fragments reverses that
	skipping to change at page 15, line 38 ¶		skipping to change at page 15, line 20 ¶
	Upon a next fragment (i.e. with a non-zero sequence), the router		Upon a next fragment (i.e. with a non-zero sequence), the router
	looks up a LSP indexed by the tuple (MAC address, datagram_tag) found		looks up a LSP indexed by the tuple (MAC address, datagram_tag) found
	in the fragment. If it is found, the router forwards the fragment		in the fragment. If it is found, the router forwards the fragment
	using the associated VRB as prescribed by		using the associated VRB as prescribed by
	[I-D.ietf-6lo-minimal-fragment].		[I-D.ietf-6lo-minimal-fragment].
	if the VRB for the tuple is not found, the router builds an RFRAG-ACK		if the VRB for the tuple is not found, the router builds an RFRAG-ACK
	to abort the transmission of the packet. The resulting message has		to abort the transmission of the packet. The resulting message has
	the following information:		the following information:
	o The source and destination MAC addresses are swapped from those		* The source and destination MAC addresses are swapped from those
	found in the fragment		found in the fragment
			* The datagram_tag set to the datagram_tag found in the fragment
	o The datagram_tag set to the datagram_tag found in the fragment		* A NULL bitmap is used to signal the abort condition
	o A NULL bitmap is used to signal the abort condition
	At this point the router is all set and can send the RFRAG-ACK back		At this point the router is all set and can send the RFRAG-ACK back
	to the previous router. The RFRAG-ACK should normally be forwarded		to the previous router. The RFRAG-ACK should normally be forwarded
	all the way to the source using the reverse LSP state in the VRBs in		all the way to the source using the reverse LSP state in the VRBs in
	the intermediate routers as described in the next section.		the intermediate routers as described in the next section.
	6.2. Upon the RFRAG Acknowledgments		6.2. Upon the RFRAG Acknowledgments
	Upon an RFRAG-ACK, the router looks up a Reverse LSP indexed by the		Upon an RFRAG-ACK, the router looks up a Reverse LSP indexed by the
	tuple (MAC address, datagram_tag), which are respectively the source		tuple (MAC address, datagram_tag), which are respectively the source
	skipping to change at page 17, line 24 ¶		skipping to change at page 16, line 48 ¶
	7. Management Considerations		7. Management Considerations
	7.1. Protocol Parameters		7.1. Protocol Parameters
	There is no particular configuration on the receiver, as echoing ECN		There is no particular configuration on the receiver, as echoing ECN
	is always on. The configuration only applies to the sender, which is		is always on. The configuration only applies to the sender, which is
	in control of the transmission. The management system SHOULD be		in control of the transmission. The management system SHOULD be
	capable of providing the parameters below:		capable of providing the parameters below:
	MinFragmentSize: The MinFragmentSize is the minimum value for the		MinFragmentSize: The MinFragmentSize is the minimum value for the
	Fragment_Size.		Fragment_Size.
	OptFragmentSize: The MinFragmentSize is the value for the		OptFragmentSize: The MinFragmentSize is the value for the
	Fragment_Size that the sender should use to start with.		Fragment_Size that the sender should use to start with.
	MaxFragmentSize: The MaxFragmentSize is the maximum value for the		MaxFragmentSize: The MaxFragmentSize is the maximum value for the
	Fragment_Size. It MUST be lower than the minimum MTU along the		Fragment_Size. It MUST be lower than the minimum MTU along the
	path. A large value augments the chances of buffer bloat and		path. A large value augments the chances of buffer bloat and
	transmission loss. The value MUST be less than 512 if the unit		transmission loss. The value MUST be less than 512 if the unit
	that is defined for the PHY layer is the octet.		that is defined for the PHY layer is the octet.
	UseECN: Indicates whether the sender should react to ECN. When the		UseECN: Indicates whether the sender should react to ECN. When the
	sender reacts to ECN the Window_Size will vary between		sender reacts to ECN the Window_Size will vary between
	MinWindowSize and MaxWindowSize.		MinWindowSize and MaxWindowSize.
	MinWindowSize: The minimum value of Window_Size that the sender can		MinWindowSize: The minimum value of Window_Size that the sender can
	use.		use.
	OptWindowSize: The OptWindowSize is the value for the Window_Size		OptWindowSize: The OptWindowSize is the value for the Window_Size
	that the sender should use to start with.		that the sender should use to start with.
	MaxWindowSize: The maximum value of Window_Size that the sender can		MaxWindowSize: The maximum value of Window_Size that the sender can
	use. The value MUSt be less than 32.		use. The value MUSt be less than 32.
	InterFrameGap: Indicates a minimum amount of time between		InterFrameGap: Indicates a minimum amount of time between
	transmissions. All packets to a same destination, and in		transmissions. All packets to a same destination, and in
	particular fragments, may be subject to receive while		particular fragments, may be subject to receive while transmitting
	transmitting and hidden terminal collisions with the next or		and hidden terminal collisions with the next or the previous
	the previous transmission as the fragments progress along a		transmission as the fragments progress along a same path. The
	same path. The InterFrameGap protects the propagation of one		InterFrameGap protects the propagation of one transmission before
	transmission before the next one is triggered and creates a		the next one is triggered and creates a duty cycle that controls
	duty cycle that controls the ratio of air time and memory in		the ratio of air time and memory in intermediate nodes that a
	intermediate nodes that a particular datagram will use.		particular datagram will use.
	MinARQTimeOut: The maximum amount of time a node should wait for an		MinARQTimeOut: The maximum amount of time a node should wait for an
	RFRAG Acknowledgment before it takes a next action.		RFRAG Acknowledgment before it takes a next action.
	OptARQTimeOut: The starting point of the value of the amount that a		OptARQTimeOut: The starting point of the value of the amount that a
	sender should wait for an RFRAG Acknowledgment before it takes		sender should wait for an RFRAG Acknowledgment before it takes a
	a next action.		next action.
	MaxARQTimeOut: The maximum amount of time a node should wait for an		MaxARQTimeOut: The maximum amount of time a node should wait for an
	RFRAG Acknowledgment before it takes a next action.		RFRAG Acknowledgment before it takes a next action.
	MaxFragRetries: The maximum number of retries for a particular		MaxFragRetries: The maximum number of retries for a particular
	Fragment.		Fragment.
	MaxDatagramRetries: The maximum number of retries from scratch for a		MaxDatagramRetries: The maximum number of retries from scratch for a
	particular Datagram.		particular Datagram.
	7.2. Observing the network		7.2. Observing the network
	The management system should monitor the amount of retries and of ECN		The management system should monitor the amount of retries and of ECN
	settings that can be observed from the perspective of the both the		settings that can be observed from the perspective of the both the
	sender and the receiver, and may tune the optimum size of		sender and the receiver, and may tune the optimum size of
	Fragment_Size and of the Window_Size, OptWindowSize and OptWindowSize		Fragment_Size and of the Window_Size, OptWindowSize and OptWindowSize
	respectively, at the sender. The values should be bounded by the		respectively, at the sender. The values should be bounded by the
	expected number of hops and reduced beyond that when the number of		expected number of hops and reduced beyond that when the number of
	datagrams that can traverse an intermediate point may exceed its		datagrams that can traverse an intermediate point may exceed its
	skipping to change at page 18, line 48 ¶		skipping to change at page 18, line 28 ¶
	8. Security Considerations		8. Security Considerations
	The considerations in the Security section of [I-D.ietf-core-cocoa]		The considerations in the Security section of [I-D.ietf-core-cocoa]
	apply equally to this specification.		apply equally to this specification.
	The process of recovering fragments does not appear to create any		The process of recovering fragments does not appear to create any
	opening for new threat compared to "Transmission of IPv6 Packets over		opening for new threat compared to "Transmission of IPv6 Packets over
	IEEE 802.15.4 Networks" [RFC4944].		IEEE 802.15.4 Networks" [RFC4944].
	The technique of Virtual Recovery Buffers inherited from		The Virtual Recovery Buffer inherited from
	[I-D.ietf-6lo-minimal-fragment] may be used to perform a Denial-of-		[I-D.ietf-6lo-minimal-fragment] may be used to perform a Denial-of-
	Service (DoS) attack against the intermediate Routers since the		Service (DoS) attack against the intermediate Routers since the
	routers need to maintain a state per flow. Note that as opposed to		routers need to maintain a state per flow. The VRB implementation
	the VRB described in [I-D.ietf-lwig-6lowpan-virtual-reassembly] the		technique described in [I-D.ietf-lwig-6lowpan-virtual-reassembly]
	data that is transported in each fragment is conserved and the state		allows to realign which data goes in which fragment which causes the
	to keep does not include any data that would not fit in the previous		intermediate node to store a portion of the data, which adds an
	fragment.		attack vector that is not present with this specification. With this
			specification, the data that is transported in each fragment is
			conserved and the state to keep does not include any data that would
			not fit in the previous fragment.
	9. IANA Considerations		9. IANA Considerations
	This document allocates 4 values in Page 0 for recoverable fragments		This document allocates 4 values in Page 0 for recoverable fragments
	from the "Dispatch Type Field" registry that was created by		from the "Dispatch Type Field" registry that was created by
	"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]		"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]
	and reformatted by "6LoWPAN Paging Dispatch" [RFC8025].		and reformatted by "6LoWPAN Paging Dispatch" [RFC8025].
	The suggested values (to be confirmed by IANA) are indicated in		The suggested values (to be confirmed by IANA) are indicated in
	Table 1.		Table 1.
	+-------------+------+----------------------------------+-----------+		+-------------+------+----------------------------------+-----------+
	| Bit Pattern | Page | Header Type | Reference |		| Bit Pattern | Page | Header Type | Reference |
			+=============+======+==================================+===========+
			| 11 10100x | 0 | RFRAG - Recoverable Fragment | THIS RFC |
	+-------------+------+----------------------------------+-----------+		+-------------+------+----------------------------------+-----------+
	| 11 10100x | 0 | RFRAG - Recoverable Fragment | RFC THIS |		| 11 10101x | 0 | RFRAG-ACK - RFRAG | THIS RFC |
	| 11 10101x | 0 | RFRAG-ACK - RFRAG Acknowledgment | RFC THIS |		| | | Acknowledgment | |
	+-------------+------+----------------------------------+-----------+		+-------------+------+----------------------------------+-----------+
	Table 1: Additional Dispatch Value Bit Patterns		Table 1: Additional Dispatch Value Bit Patterns
	10. Acknowledgments		10. Acknowledgments
	The author wishes to thank Michel Veillette, Dario Tedeschi, Laurent		The author wishes to thank Michel Veillette, Dario Tedeschi, Laurent
	Toutain, Carles Gomez Montenegro, Thomas Watteyne and Michael		Toutain, Carles Gomez Montenegro, Thomas Watteyne and Michael
	Richardson for in-depth reviews and comments. Also many thanks to		Richardson for in-depth reviews and comments. Also many thanks to
	Jonathan Hui, Jay Werb, Christos Polyzois, Soumitri Kolavennu, Pat		Jonathan Hui, Jay Werb, Christos Polyzois, Soumitri Kolavennu, Pat
	Kinney, Margaret Wasserman, Richard Kelsey, Carsten Bormann and Harry		Kinney, Margaret Wasserman, Richard Kelsey, Carsten Bormann and Harry
	Courtice for their various contributions.		Courtice for their various contributions.
	11. References		11. Normative References
	11.1. Normative References
	[I-D.ietf-6lo-minimal-fragment]		[I-D.ietf-6lo-minimal-fragment]
	Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal		Watteyne, T., Bormann, C., and P. Thubert, "6LoWPAN
	Fragment Forwarding", draft-ietf-6lo-minimal-fragment-02		Fragment Forwarding", Work in Progress, Internet-Draft,
	(work in progress), June 2019.		draft-ietf-6lo-minimal-fragment-04, 2 September 2019,
			<https://tools.ietf.org/html/draft-ietf-6lo-minimal-
	[I-D.ietf-lwig-6lowpan-virtual-reassembly]		fragment-04>.
	Bormann, C. and T. Watteyne, "Virtual reassembly buffers
	in 6LoWPAN", draft-ietf-lwig-6lowpan-virtual-reassembly-01
	(work in progress), March 2019.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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, DOI 10.17487/RFC4944, September 2007,		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<https://www.rfc-editor.org/info/rfc4944>.		<https://www.rfc-editor.org/info/rfc4944>.
	skipping to change at page 20, line 40 ¶		skipping to change at page 20, line 21 ¶
	[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,		[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
	"IPv6 over Low-Power Wireless Personal Area Network		"IPv6 over Low-Power Wireless Personal Area Network
	(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,		(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
	April 2017, <https://www.rfc-editor.org/info/rfc8138>.		April 2017, <https://www.rfc-editor.org/info/rfc8138>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		12. Informative References
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work		of IEEE 802.15.4", Work in Progress, Internet-Draft,
	in progress), July 2019.		draft-ietf-6tisch-architecture-27, 18 October 2019,
			<https://tools.ietf.org/html/draft-ietf-6tisch-
			architecture-27>.
	[I-D.ietf-core-cocoa]		[I-D.ietf-core-cocoa]
	Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,		Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
	"CoAP Simple Congestion Control/Advanced", draft-ietf-		"CoAP Simple Congestion Control/Advanced", Work in
	core-cocoa-03 (work in progress), February 2018.		Progress, Internet-Draft, draft-ietf-core-cocoa-03, 21
			February 2018,
			<https://tools.ietf.org/html/draft-ietf-core-cocoa-03>.
	[I-D.ietf-intarea-frag-fragile]		[I-D.ietf-intarea-frag-fragile]
	Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,		Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
	and F. Gont, "IP Fragmentation Considered Fragile", draft-		and F. Gont, "IP Fragmentation Considered Fragile", Work
	ietf-intarea-frag-fragile-15 (work in progress), July		in Progress, Internet-Draft, draft-ietf-intarea-frag-
	2019.		fragile-17, 30 September 2019,
			<https://tools.ietf.org/html/draft-ietf-intarea-frag-
			fragile-17>.
			[I-D.ietf-lwig-6lowpan-virtual-reassembly]
			Bormann, C. and T. Watteyne, "Virtual reassembly buffers
			in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-
			lwig-6lowpan-virtual-reassembly-01, 11 March 2019,
			<https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-
			virtual-reassembly-01>.
	[IEEE.802.15.4]		[IEEE.802.15.4]
	IEEE, "IEEE Standard for Low-Rate Wireless Networks",		IEEE, "IEEE Standard for Low-Rate Wireless Networks",
	IEEE Standard 802.15.4, DOI 10.1109/IEEE		IEEE Standard 802.15.4, DOI 10.1109/IEEE
	P802.15.4-REVd/D01,		P802.15.4-REVd/D01, October 2019,
	<http://ieeexplore.ieee.org/document/7460875/>.		<http://ieeexplore.ieee.org/document/7460875/>.
	[Kent] Kent, C. and J. Mogul, ""Fragmentation Considered		[Kent] Kent, C. and J. Mogul, ""Fragmentation Considered
	Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in		Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in
	Computer Communications Technology",		Computer Communications Technology",
	DOI 10.1145/55483.55524, August 1987,		DOI 10.1145/55483.55524, August 1987,
	<http://www.hpl.hp.com/techreports/Compaq-DEC/		<http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-
	WRL-87-3.pdf>.		87-3.pdf>.
	[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,		[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
	RFC 2914, DOI 10.17487/RFC2914, September 2000,		RFC 2914, DOI 10.17487/RFC2914, September 2000,
	<https://www.rfc-editor.org/info/rfc2914>.		<https://www.rfc-editor.org/info/rfc2914>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
	skipping to change at page 23, line 15 ¶		skipping to change at page 23, line 15 ¶
	Appendix A. Rationale		Appendix A. Rationale
	There are a number of uses 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 LLN; however, the associated		largest amount of traffic over the LLN; 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 LLN.		ensuring effective transport of large packets across the LLN.
	The list of those usages includes:		The list of those usages includes:
	Towards the LLN node:		Towards the LLN node: Firmware update: For example, a new version
			of the LLN node software is downloaded from a system manager
	Firmware update: For example, a new version of the LLN node		over unicast or multicast services. Such a reflashing
	software is downloaded from a system manager over unicast or		operation typically involves updating a large number of similar
	multicast services. Such a reflashing operation typically		LLN nodes over a relatively short period of time.
	involves updating a large number of similar LLN nodes over a		Packages of Commands: A number of commands or
	relatively short period of time.		a full configuration can be packaged as a single message to
			ensure consistency and enable atomic execution or complete roll
	Packages of Commands: A number of commands or a full		back. Until such commands are fully received and interpreted,
	configuration can be packaged as a single message to ensure		the intended operation will not take effect.
	consistency and enable atomic execution or complete roll back.		From the LLN node: Waveform captures: A number of consecutive
	Until such commands are fully received and interpreted, the		samples are measured at a high rate for a short time and then
	intended operation will not take effect.		transferred from a sensor to a gateway or an edge server as a
			single large report.
	From the LLN node:		Data logs: LLN nodes may generate large logs of
			sampled data for later extraction. LLN nodes may also generate
	Waveform captures: A number of consecutive samples are measured		system logs to assist in diagnosing problems on the node or
	at a high rate for a short time and then transferred from a		network.
	sensor to a gateway or an edge server as a single large report.		Large data packets: Rich data types might
			require more than one fragment.
	Data logs: LLN nodes may generate large logs of sampled data for
	later extraction. LLN nodes may also generate system logs to
	assist in diagnosing problems on the node or network.
	Large data packets: Rich data types might require more than one
	fragment.
	Uncontrolled firmware download or waveform upload can easily result		Uncontrolled firmware download or waveform upload can easily result
	in a massive increase of the traffic and saturate the network.		in a massive increase of the traffic and saturate the network.
	When a fragment is lost in transmission, the lack of recovery in the		When a fragment is lost in transmission, the lack of recovery in the
	original fragmentation system of RFC 4944 implies that all fragments		original fragmentation system of RFC 4944 implies that all fragments
	would need to be resent, further contributing to the congestion that		would need to be resent, further contributing to the congestion that
	caused the initial loss, and potentially leading to congestion		caused the initial loss, and potentially leading to congestion
	collapse.		collapse.
	skipping to change at page 26, line 44 ¶		skipping to change at page 26, line 38 ¶
	by throttling the sources.		by throttling the sources.
	Section 6 describes how the sender decides how many fragments are		Section 6 describes how the sender decides how many fragments are
	(re)sent before an acknowledgment is required, and how the sender		(re)sent before an acknowledgment is required, and how the sender
	adapts that number to the network conditions.		adapts that number to the network conditions.
	Author's Address		Author's Address
	Pascal Thubert (editor)		Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D		Building D, 45 Allee des Ormes - BP1200
	45 Allee des Ormes - BP1200		06254 MOUGINS - Sophia Antipolis
	MOUGINS - Sophia Antipolis 06254		France
	FRANCE
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
End of changes. 60 change blocks.
	176 lines changed or deleted		167 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/