< draft-ietf-6lo-fragment-recovery-16.txt		draft-ietf-6lo-fragment-recovery-17.txt >
	6lo P. Thubert, Ed.		6lo P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Updates: 4944 (if approved) 9 March 2020		Updates: 4944 (if approved) 18 March 2020
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 10 September 2020		Expires: 19 September 2020
	6LoWPAN Selective Fragment Recovery		6LoWPAN Selective Fragment Recovery
	draft-ietf-6lo-fragment-recovery-16		draft-ietf-6lo-fragment-recovery-17
	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 10 September 2020.		This Internet-Draft will expire on 19 September 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 52 ¶		skipping to change at page 2, line 52 ¶
	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 (on the order of a few		the traffic consists of small chunks of data (on the order of a few
	bytes to a few tens of bytes) at a time. Given that an IEEE Std.		bytes to a few tens of bytes) at a time. Given that an IEEE Std.
	802.15.4 [IEEE.802.15.4] frame can carry a payload of 74 bytes or		802.15.4 [IEEE.802.15.4] frame can carry a payload of 74 bytes or
	more, fragmentation is usually not required. However, and though		more, fragmentation is usually not required. However, and though
	this happens only occasionally, a number of mission critical		this happens only occasionally, a number of mission critical
	applications do require the capability to transfer larger chunks of		applications do require the capability to transfer larger chunks of
	data, for instance to support the firmware upgrade of the LLN nodes		data, for instance to support the firmware upgrade of the LLN nodes
	or the extraction of logs from LLN nodes. In the former case, the		or the extraction of logs from LLN nodes.
	large chunk of data is transferred to the LLN node, whereas in the
	latter, the large chunk flows away from the LLN node. In both cases,		In the former case, the large chunk of data is transferred to the LLN
	the size can be on the order of 10 kilobytes or more and an end-to-		node, whereas in the latter, the large chunk flows away from the LLN
	end reliable transport is required.		node. In both cases, the size can be on the order of 10 kilobytes or
			more and an end-to-end reliable transport is required.
	"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]		"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]
	defines the original 6LoWPAN datagram fragmentation mechanism for		defines the original 6LoWPAN datagram fragmentation mechanism for
	LLNs. One critical issue with this original design is that routing		LLNs. One critical issue with this original design is that routing
	an IPv6 [RFC8200] packet across a route-over mesh requires the		an IPv6 [RFC8200] packet across a route-over mesh requires the
	reassembly of the packet at each hop. The "6TiSCH Architecture"		reassembly of the packet at each hop. The "6TiSCH Architecture"
	[I-D.ietf-6tisch-architecture] indicates that this may cause latency		[I-D.ietf-6tisch-architecture] indicates that this may cause latency
	along a path and impact critical resources such as memory and		along a path and impact critical resources such as memory and
	battery; to alleviate those undesirable effects it recommends using a		battery; to alleviate those undesirable effects it recommends using a
	6LoWPAN Fragment Forwarding (6FF) technique .		6LoWPAN Fragment Forwarding (6FF) technique .
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 31 ¶
	behavior that all 6FF techniques including this specification follow,		behavior that all 6FF techniques including this specification follow,
	and presents the associated caveats. In particular, the routing		and presents the associated caveats. In particular, the routing
	information is fully indicated in the first fragment, which is always		information is fully indicated in the first fragment, which is always
	forwarded first. With this specification, the first fragment is		forwarded first. With this specification, the first fragment is
	identified by a Sequence of 0 as opposed to a dispatch type in		identified by a Sequence of 0 as opposed to a dispatch type in
	[RFC4944]. A state is formed and used to forward all the next		[RFC4944]. A state is formed and used to forward all the next
	fragments along the same path. The Datagram_Tag is locally		fragments along the same path. The Datagram_Tag is locally
	significant to the Layer-2 source of the packet and is swapped at		significant to the Layer-2 source of the packet and is swapped at
	each hop, more in Section 6. This specification encodes the		each hop, more in Section 6. This specification encodes the
	Datagram_Tag in one byte, which will saturate if more than 256		Datagram_Tag in one byte, which will saturate if more than 256
	datagram transit in the fragmented form over a same hop at the same		datagrams transit in fragmented form over a single hop at the same
	time. This is not realistic at the time of this writing. Should		time. This is not realistic at the time of this writing. Should
	this happen in a new 6LoWPAN technology, a node will need to use		this happen in a new 6LoWPAN technology, a node will need to use
	several Link-Layer addresses to increase its indexing capacity.		several Link-Layer addresses to increase its indexing capacity.
	"Virtual reassembly buffers in 6LoWPAN" [LWIG-FRAG](VRB) proposes a		"Virtual reassembly buffers in 6LoWPAN" [LWIG-FRAG](VRB) proposes a
	6FF technique that is compatible with [RFC4944] without the need to		6FF technique that is compatible with [RFC4944] without the need to
	define a new protocol. However, adding that capability alone to the		define a new protocol. However, adding that capability alone to the
	local implementation of the original 6LoWPAN fragmentation would not		local implementation of the original 6LoWPAN fragmentation would not
	address the inherent fragility of fragmentation (see [FRAG-ILE]) in		address the inherent fragility of fragmentation (see [FRAG-ILE]) in
	particular the issues of resources locked on the reassembling		particular the issues of resources locked on the reassembling
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	[RFC4944] is also missing signaling to abort a multi-fragment		[RFC4944] is also missing signaling to abort a multi-fragment
	transmission at any time and from either end, and, if the capability		transmission at any time and from either end, and, if the capability
	to forward fragments is implemented, clean up the related state in		to forward fragments is implemented, clean up the related state in
	the network. It is also lacking flow control capabilities to avoid		the network. It is also lacking flow control capabilities to avoid
	participating in congestion that may in turn cause the loss of a		participating in congestion that may in turn cause the loss of a
	fragment and potentially the retransmission of the full datagram.		fragment and potentially the retransmission of the full datagram.
	This specification provides a method to forward fragments over		This specification provides a method to forward fragments over
	typically a few hops in a route-over 6LoWPAN mesh, and a selective		typically a few hops in a route-over 6LoWPAN mesh, and a selective
	acknowledgment to recover individual fragments between 6LoWPAN		acknowledgment to recover individual fragments between 6LoWPAN
	endpoints. The method is designed to limit congestion loss in the		endpoints. The method can help limit the congestion loss in the
	network and addresses the requirements that are detailed in		network and addresses the requirements in Appendix B. Deployments
	Appendix B.		are expected to be managed and homogeneous, and an incremental
			transition requires a flag day.
	2. Terminology		2. Terminology
	2.1. BCP 14		2.1. BCP 14
	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		This document uses 6LoWPAN terms and concepts that are presented in
	discussed in "IPv6 over Low-Power Wireless Personal Area Networks		"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
	(6LoWPANs): Overview, Assumptions, Problem Statement, and Goals"		Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
	[RFC4919], "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"		"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944],
	[RFC4944], and "Problem Statement and Requirements for IPv6 over		and "Problem Statement and Requirements for IPv6 over Low-Power
	Low-Power Wireless Personal Area Network (6LoWPAN) Routing"		Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606].
	[RFC6606].
	"LLN Minimal Fragment Forwarding" [FRAG-FWD] discusses the generic		"LLN Minimal Fragment Forwarding" [FRAG-FWD] discusses the generic
	concept of a Virtual Reassembly Buffer (VRB) and specifies behaviors		concept of a Virtual Reassembly Buffer (VRB) and specifies behaviors
	and caveats that are common to a large family of 6FF techniques		and caveats that are common to a large family of 6FF techniques
	including the mechanism specified by this document, which fully		including the mechanism specified by this document, which fully
	inherits from that specification. It also defines terms used in this		inherits from that specification. It also defines terms used in this
	document: Compressed Form, Datagram_Tag, Datagram_Size,		document: Compressed Form, Datagram_Tag, Datagram_Size,
	Fragment_Offset, and 6LoWPAN Fragment Forwarding endpoint (commonly		Fragment_Offset, and 6LoWPAN Fragment Forwarding endpoint (commonly
	abbreviated as only "endpoint").		abbreviated as only "endpoint").
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 35 ¶
	The inter-frame gap is the only protection that [FRAG-FWD] imposes by		The inter-frame gap is the only protection that [FRAG-FWD] imposes by
	default. This document enables to group fragments in windows and		default. This document enables to group fragments in windows and
	request intermediate acknowledgements so the number of in-flight		request intermediate acknowledgements so the number of in-flight
	fragments can be bounded. This document also adds an ECN mechanism		fragments can be bounded. This document also adds an ECN mechanism
	that can be used to adapt the size of the window, the size of the		that can be used to adapt the size of the window, the size of the
	fragments, and/or the inter-frame gap to protect the network.		fragments, and/or the inter-frame gap to protect the network.
	This specification enables the fragmenting endpoint to apply a flow		This specification enables the fragmenting endpoint to apply a flow
	control mechanism to tune those parameters, but the mechanism itself		control mechanism to tune those parameters, but the mechanism itself
	is out of scope. In most cases, the expectation is that most		is out of scope. In most cases, the expectation is that most
	datagrams will represent only a few fragments, and that only the last		datagrams will require only a few fragments, and that only the last
	fragment will be acknowledged. A basic implementation of the		fragment will be acknowledged. A basic implementation of the
	fragmenting endpoint is NOT REQUIRED to variate the size of the		fragmenting endpoint is NOT REQUIRED to vary the size of the window,
	window, the duration of the inter-frame gap or the size of a fragment		the duration of the inter-frame gap or the size of a fragment in the
	in the middle of the transmission of a datagram, and it MAY ignore		middle of the transmission of a datagram, and it MAY ignore the ECN
	the ECN signal or simply reset the window to 1 (see Appendix C for		signal or simply reset the window to 1 (see Appendix C for more)
	more) till the end of this datagram upon detecting a congestion.		until the end of this datagram upon detecting a congestion.
	An intermediate node that experiences a congestion MAY set the ECN		An intermediate node that experiences a congestion MAY set the ECN
	bit in a fragment, and the reassembling endpoint echoes the ECN bit		bit in a fragment, and the reassembling endpoint echoes the ECN bit
	at most once at the next opportunity to acknowledge back.		at most once at the next opportunity to acknowledge back.
	The size of the fragments is typically computed from the Link MTU to		The size of the fragments is typically computed from the Link MTU to
	maximize the size of the resulting frames. The size of the window		maximize the size of the resulting frames. The size of the window
	and the duration of the inter-frame gap SHOULD be configurable, to		and the duration of the inter-frame gap SHOULD be configurable, to
	roughly adapt the size of the window to the number of hops in an		roughly adapt the size of the window to the number of hops in an
	average path, and to follow the general recommendations in		average path, and to follow the general recommendations in
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 19 ¶
	route in a Route-Over mesh LLN. If the size of the first fragment is		route in a Route-Over mesh LLN. If the size of the first fragment is
	modified, then the intermediate node MUST adapt the Datagram_Size,		modified, then the intermediate node MUST adapt the Datagram_Size,
	encoded in the Fragment_Size field, to reflect that difference.		encoded in the Fragment_Size field, to reflect that difference.
	The intermediate node MUST also save the difference of Datagram_Size		The intermediate node MUST also save the difference of Datagram_Size
	of the first fragment in the VRB and add it to the Fragment_Offset of		of the first fragment in the VRB and add it to the Fragment_Offset of
	all the subsequent fragments that it forwards for that datagram.		all the subsequent fragments that it forwards for that datagram.
	5. New Dispatch types and headers		5. New Dispatch types and headers
	This document specifies an alternate to the 6LoWPAN fragmentation		This document specifies an alternative to the 6LoWPAN fragmentation
	sublayer [RFC4944] to emulate an Link MTU up to 2048 bytes for the		sublayer [RFC4944] to emulate an Link MTU up to 2048 bytes for the
	upper layer, which can be the 6LoWPAN Header Compression sublayer		upper layer, which can be the 6LoWPAN Header Compression sublayer
	that is defined in the "Compression Format for IPv6 Datagrams"		that is defined in the "Compression Format for IPv6 Datagrams"
	[RFC6282] specification. This specification also provides a reliable		[RFC6282] specification. This specification also provides a reliable
	transmission of the fragments over a multihop 6LoWPAN route-over mesh		transmission of the fragments over a multihop 6LoWPAN route-over mesh
	network and a minimal flow control to reduce the chances of		network and a minimal flow control to reduce the chances of
	congestion loss.		congestion loss.
	A 6LoWPAN Fragment Forwarding [FRAG-FWD] technique derived from MPLS		A 6LoWPAN Fragment Forwarding [FRAG-FWD] technique derived from MPLS
	enables the forwarding of individual fragments across a 6LoWPAN		enables the forwarding of individual fragments across a 6LoWPAN
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	|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
	X: 1 bit; Ack-Request: when set, the fragmenting endpoint requires		X: 1 bit; Ack-Request: when set, the fragmenting endpoint requires
	an RFRAG Acknowledgment from the reassembling endpoint.		anLink-layer RFRAG Acknowledgment from the reassembling endpoint.
	E: 1 bit; Explicit Congestion Notification; the "E" flag is cleared		E: 1 bit; Explicit Congestion Notification; the "E" flag is cleared
	by the source of the fragment and set by intermediate routers to		by 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 Link-Layer technology. Unless		a unit that depends on the Link-Layer technology. Unless
	overridden by a more specific specification, that unit is the		overridden by a more specific specification, that unit is the
	byte, which allows fragments up to 1024 bytes.		byte, which allows fragments up to 1024 bytes.
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	carrying fragments) that are sent to the same next hop. The delay		carrying fragments) that are sent to the same next hop. The delay
	SHOULD cover multiple transmissions so as to let a frame progress a		SHOULD cover multiple transmissions so as to let a frame progress a
	few hops and avoid hidden terminal issues. This precaution is not		few hops and avoid hidden terminal issues. This precaution is not
	required on channel hopping technologies such as Time Slotted Channel		required on channel hopping technologies such as Time Slotted Channel
	Hopping (TSCH) [RFC6554], where nodes that communicate at Layer-2 are		Hopping (TSCH) [RFC6554], where nodes that communicate at Layer-2 are
	scheduled to send and receive respectively, and different hops		scheduled to send and receive respectively, and different hops
	operate on different channels.		operate on different channels.
	6.1. Forwarding Fragments		6.1. Forwarding Fragments
	It is assumed that the first fragment is large enough to carry the		This specification inherits from [FRAG-FWD] and proposes a Virtual
	IPv6 header and make routing decisions. If that is not so, then this		Reassembly technique to forward fragments with no intermediate
	specification MUST NOT be used.		reconstruction of the entire datagram.
	This specification extends the Virtual Reassembly Buffer (VRB)		The IPv6 Header MUST be placed in full in the first fragment to
	technique to forward fragments with no intermediate reconstruction of		enable the routing decision. The first fragment is routed and
	the entire packet. It inherits operations like Datagram_Tag		creates an LSP from the fragmenting endpoint to the reassembling
	switching and using a timer to clean the VRB once the traffic ceases.		endpoint. The next fragments are label-switched along that LSP. As
	The first fragment carries the IP header and creates a path from the		a consequence, the next fragments can only follow the path that was
	fragmenting endpoint to the reassembling endpoint that all the other		set up by the first fragment and cannot follow an alternate route.
	fragments follow. Upon receiving the first fragment, the routers		The Datagram_Tag is used to carry the label, which is swapped in each
	along the path install a label-switched path (LSP), and the following		hop.
	fragments are label-switched along that path. As a consequence, the
	next fragments can only follow the path that was set up by the first		If the first fragment is too large for the path MTU, it will
	fragment and cannot follow an alternate route. The Datagram_Tag is		repeatedly fail and never establish an LSP. In that case, the
	used to carry the label, which is swapped in each hop.		fragmenting endpoint MAY retry the same datagram with a smaller
			Fragment_Size, in which case it MUST abort the original attempt and
			use a new Datagram_Tag for the new attempt.
	6.1.1. Receiving the first fragment		6.1.1. Receiving the first fragment
	In Route-Over mode, the source and destination Link-Layer addresses		In Route-Over mode, the source and destination Link-Layer addresses
	in a frame change at each hop. The label that is formed and placed		in a frame change at each hop. The label that is formed and placed
	in the Datagram_Tag by the sender is associated with the source Link-		in the Datagram_Tag by the sender is associated with the source Link-
	Layer address and only valid (and temporarily unique) for that source		Layer address and only valid (and temporarily unique) for that source
	Link-Layer address.		Link-Layer address.
	Upon receiving the first fragment (i.e., with a Sequence of 0), an		Upon receiving the first fragment (i.e., with a Sequence of 0), an
	skipping to change at page 22, line 10 ¶		skipping to change at page 22, line 10 ¶
	This document specifies an instantiation of a 6FF technique and		This document specifies an instantiation of a 6FF technique and
	inherits from the generic description in [FRAG-FWD]. The		inherits from the generic description in [FRAG-FWD]. The
	considerations in the Security Section of [FRAG-FWD] equally apply to		considerations in the Security Section of [FRAG-FWD] equally apply to
	this document.		this document.
	In addition to the threats detailed therein, an attacker that is on-		In addition to the threats detailed therein, an attacker that is on-
	path can prematurely end the transmission of a datagram by sending a		path can prematurely end the transmission of a datagram by sending a
	RFRAG Acknowledgment to the fragmenting endpoint. It can also cause		RFRAG Acknowledgment to the fragmenting endpoint. It can also cause
	extra transmissions of fragments by resetting bits in the RFRAG		extra transmissions of fragments by resetting bits in the RFRAG
	Acknowledgment bitmap, and of RFRAG Acknowledgments by forcing the		Acknowledgment bitmap, and of RFRAG Acknowledgments by forcing the
	Ack-Request bit in fragments that it forwards. As indicated in		Ack-Request bit in fragments that it forwards.
	[FRAG-FWD], Secure joining and the Link-Layer security are REQUIRED
	to protect against those attacks.		As indicated in [FRAG-FWD], Secure joining and the Link-Layer
			security are REQUIRED to protect against those attacks, as the
			fragmentation protocol does not include any native security
			mechanisms.
	This specification does not recommend a particular algorithm for the		This specification does not recommend a particular algorithm for the
	estimation of the duration of the RTO that covers the detection of		estimation of the duration of the RTO that covers the detection of
	the loss of a fragment with the 'X' flag set; regardless, an attacker		the loss of a fragment with the 'X' flag set; regardless, an attacker
	on the path may slow down or discard packets, which in turn can		on the path may slow down or discard packets, which in turn can
	affect the throughput of fragmented packets.		affect the throughput of fragmented packets.
	Compared to "Transmission of IPv6 Packets over IEEE 802.15.4		Compared to "Transmission of IPv6 Packets over IEEE 802.15.4
	Networks" [RFC4944], this specification reduces the Datagram_Tag to 8		Networks" [RFC4944], this specification reduces the Datagram_Tag to 8
	bits and the tag wraps faster than with [RFC4944]. But for a		bits and the tag wraps faster than with [RFC4944]. But for a
	skipping to change at page 29, line 42 ¶		skipping to change at page 29, line 42 ¶
	the number of outstanding fragments that have been transmitted but		the number of outstanding fragments that have been transmitted but
	for which an acknowledgment was not received yet and are still		for which an acknowledgment was not received yet and are still
	covered by the ARQ timer.		covered by the ARQ timer.
	Congestion on the forward path can also be indicated by an Explicit		Congestion on the forward path can also be indicated by an Explicit
	Congestion Notification (ECN) mechanism. Though whether and how ECN		Congestion Notification (ECN) mechanism. Though whether and how ECN
	[RFC3168] is carried out over the LoWPAN is out of scope, this draft		[RFC3168] is carried out over the LoWPAN is out of scope, this draft
	provides a way for the destination endpoint to echo an ECN indication		provides a way for the destination endpoint to echo an ECN indication
	back to the fragmenting endpoint in an acknowledgment message as		back to the fragmenting endpoint in an acknowledgment message as
	represented in Figure 4 in Section 5.2. While the support of echoing		represented in Figure 4 in Section 5.2. While the support of echoing
	the ECN at the reassembling endpoint in mandatory, this specification		the ECN at the reassembling endpoint is mandatory, this specification
	does not provide the flow control mechanism that react to the		only provides a minimalistic behaviour on the fragmenting endpoint,
	congestion at the fragmenting endpoint. A minimalistic behaviour		that is to reset the window to 1 so the fragments are sent and
	could be to reset the window to 1 so the fragments are sent and
	acknowledged one by one till the end of the datagram.		acknowledged one by one till the end of the datagram.
	It must be noted that congestion and collision are different topics.		It must be noted that congestion and collision are different topics.
	In particular, when a mesh operates on the same channel over multiple		In particular, when a mesh operates on the same channel over multiple
	hops, then the forwarding of a fragment over a certain hop may		hops, then the forwarding of a fragment over a certain hop may
	collide with the forwarding of the next fragment that is following		collide with the forwarding of the next fragment that is following
	over a previous hop but in the same interference domain. This draft		over a previous hop but in the same interference domain. This draft
	enables end-to-end flow control, but leaves it to the fragmenting		enables end-to-end flow control, but leaves it to the fragmenting
	endpoint stack to pace individual fragments within a transmit window,		endpoint stack to pace individual fragments within a transmit window,
	so that a given fragment is sent only when the previous fragment has		so that a given fragment is sent only when the previous fragment has
End of changes. 16 change blocks.
	50 lines changed or deleted		55 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/