<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-6lo-fragment-recovery-21" indexInclude="true" ipr="trust200902" number="8931" prepTime="2020-11-16T16:01:38" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="4944" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery-21" rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8931" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<front>
<title abbrev="Selective RFRAG">IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery</title>
<seriesInfo name="RFC" value="8931" stream="IETF"/>
<author fullname="Pascal Thubert" initials="P." role="editor" surname="Thubert">
<organization abbrev="Cisco Systems" showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address>
<postal>
<extaddr>Building D</extaddr>
<street>45 Allee des Ormes - BP1200</street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>France</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<date month="11" year="2020"/>
<area>Internet</area>
<workgroup>6lo</workgroup>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">
This document updates RFC 4944 with a protocol that forwards individual fragments
across a route-over mesh and recovers them end to end, with
congestion control
capabilities to protect the network.
</t>
</abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8931" brackets="none"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-other-terms">Other Terms</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-updating-rfc-4944">Updating RFC 4944</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-extending-rfc-8930">Extending RFC 8930</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-slack-in-the-first-fragment">Slack in the First Fragment</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-gap-between-frames">Gap between Frames</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-congestion-control">Congestion Control</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-modifying-the-first-fragmen">Modifying the First Fragment</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-new-dispatch-types-and-head">New Dispatch Types and Headers</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-recoverable-fragment-dispat">Recoverable Fragment Dispatch Type and Header </xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rfrag-acknowledgment-dispat">RFRAG Acknowledgment Dispatch Type and Header</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-fragment-recovery">Fragment Recovery</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-forwarding-fragments">Forwarding Fragments</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.1.2">
<li pn="section-toc.1-1.6.2.1.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.2.1.1"><xref derivedContent="6.1.1" format="counter" sectionFormat="of" target="section-6.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-the-first-fragmen">Receiving the First Fragment</xref></t>
</li>
<li pn="section-toc.1-1.6.2.1.2.2">
<t indent="0" pn="section-toc.1-1.6.2.1.2.2.1"><xref derivedContent="6.1.2" format="counter" sectionFormat="of" target="section-6.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-the-next-fragment">Receiving the Next Fragments</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-rfrag-acknowledgm">Receiving RFRAG Acknowledgments</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-aborting-the-transmission-o">Aborting the Transmission of a Fragmented Packet</xref></t>
</li>
<li pn="section-toc.1-1.6.2.4">
<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-applying-recoverable-fragme">Applying Recoverable Fragmentation along a Diverse Path</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-management-considerations">Management Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-parameters">Protocol Parameters</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-observing-the-network">Observing the Network</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rationale">Rationale</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements">Requirements</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-on-congestio">Considerations on Congestion Control</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">
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 bytes
to a few tens of bytes) at a time. Given that an
<xref target="IEEE.802.15.4" format="default" sectionFormat="of" derivedContent="IEEE.802.15.4">IEEE Std 802.15.4</xref>
frame can carry a payload of 74 bytes or more, fragmentation is
usually not required. However, and though this happens only
occasionally, a number of mission-critical applications do require
the capability to transfer larger chunks of data, for instance, to
support the firmware upgrade of the LLN nodes or the extraction of logs
from LLN nodes.
</t>
<t indent="0" pn="section-1-2">
In the former case, the large chunk of data is
transferred to the LLN node, whereas in the latter case, the large chunk
flows away from the LLN node.
In both cases, the size can be on the
order of 10 KB or more, and an end-to-end reliable transport
is required.
</t>
<t indent="0" pn="section-1-3">
<xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944">"Transmission of IPv6 Packets over IEEE 802.15.4
Networks"</xref> defines the original IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) datagram fragmentation
mechanism for LLNs. One critical issue with this original design is that
routing an IPv6 <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> packet across a route-over mesh
requires the reassembly of the packet at each hop. <xref target="I-D.ietf-6tisch-architecture" format="default" sectionFormat="of" derivedContent="6TiSCH">"An
Architecture for IPv6 over the TSCH mode of IEEE 802.15.4"</xref>
indicates that this may cause latency along a path and impact critical
resources such as memory and battery; to alleviate those
undesirable effects, it recommends using a 6LoWPAN Fragment Forwarding
(6LFF) technique.
</t>
<t indent="0" pn="section-1-4">
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930">
"On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network"</xref> specifies the generic behavior
that all 6LFF techniques including this specification follow, and it presents
the associated caveats. In particular, the routing information is fully
indicated in the first fragment, which is always forwarded first.
With this specification, the first fragment is identified by a Sequence
of 0 as opposed to a dispatch type in <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/>.
A state is formed and used to forward all the next fragments along the
same path. The Datagram_Tag is locally significant to the Layer 2 source
of the packet and is swapped at each hop; see <xref target="ffc" format="default" sectionFormat="of" derivedContent="Section 6"/>.
This specification encodes the Datagram_Tag in 1 byte, which will
saturate if more than 256 datagrams transit in fragmented
form over a single hop at the same 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
several link-layer addresses to increase its indexing capacity.
</t>
<t indent="0" pn="section-1-5">
<xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly" format="default" sectionFormat="of" derivedContent="LWIG-FRAG">
"Virtual reassembly buffers in 6LoWPAN"</xref> proposes a 6LFF
technique that is compatible with <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/> without the
need to define a new protocol.
However, adding that capability alone to the local implementation of the
original 6LoWPAN fragmentation would not address the inherent fragility
of fragmentation (see <xref target="RFC8900" format="default" sectionFormat="of" derivedContent="RFC8900"/>), in
particular, the issues of resources locked on the reassembling endpoint and the wasted
transmissions due to the loss of a single fragment in a whole datagram.
<xref target="Kent" format="default" sectionFormat="of" derivedContent="Kent"/> compares the unreliable delivery of fragments with
a mechanism it calls "selective acknowledgments" that recovers the loss
of a fragment individually. The paper illustrates the benefits that can
be derived from such a method; see Figures 1, 2, and 3 in Section 2.3 of <xref target="Kent" format="default" sectionFormat="of" derivedContent="Kent"/>.
<xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/> has no selective recovery, and the whole datagram
fails when one fragment is not delivered to the reassembling endpoint.
Constrained memory resources are blocked on the reassembling endpoint until
it times out, possibly causing the loss of subsequent packets
that cannot be received for the lack of buffers.
</t>
<t indent="0" pn="section-1-6">
That problem is exacerbated when forwarding fragments over multiple hops
since a loss at an intermediate hop will not be discovered by either the
fragmenting or the reassembling endpoints. Should this happen, the source will keep on sending
fragments, wasting even more resources in the network since the datagram
cannot arrive in its entirety, which possibly contributes to the
condition that caused the loss.
<xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/> is lacking a congestion control to avoid
participating in a saturation that may have caused the loss of the
fragment.
It has no signaling to abort a multi-fragment transmission at any
time and from either end, and if the
capability to forward fragments is implemented, clean up the related
state in the network.
</t>
<t indent="0" pn="section-1-7">
This specification provides a method to forward fragments over, typically,
a few hops in a route-over 6LoWPAN mesh and a selective acknowledgment
to recover individual fragments between 6LoWPAN endpoints. The method
can help limit the congestion loss in the network and addresses the
requirements in <xref target="req" format="default" sectionFormat="of" derivedContent="Appendix B"/>. Flow control is out of scope since
the endpoints are expected to be able to store the full datagram.
Deployments are expected to be managed and homogeneous, and an
incremental transition requires a flag day.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<section anchor="bcp" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
<name slugifiedName="name-requirements-language">Requirements Language</name>
<t indent="0" pn="section-2.1-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="lo" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
<name slugifiedName="name-background">Background</name>
<t indent="0" pn="section-2.2-1">
This document uses 6LoWPAN terms and concepts
that are presented in <xref target="RFC4919" format="default" sectionFormat="of" derivedContent="RFC4919">"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref>; <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944">
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>; and
<xref target="RFC6606" format="default" sectionFormat="of" derivedContent="RFC6606"> "Problem Statement and Requirements for
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
Routing" </xref>.
</t>
<t indent="0" pn="section-2.2-2"><xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> discusses the generic concept
of a Virtual Reassembly Buffer (VRB) and specifies behaviors
and caveats that are common to a large family of 6LFF techniques
including the mechanism specified by this document,
which is fully inherited from that specification.
It also defines terms used in this document: Compressed Form,
Datagram_Tag, Datagram_Size, Fragment_Offset, and
6LoWPAN Fragment Forwarding endpoint (commonly abbreviated as only
"endpoint").
</t>
<t indent="0" pn="section-2.2-3">
Past experience with fragmentation has shown that misassociated or lost
fragments can lead to poor network behavior and, occasionally, trouble
at the application layer. The reader is encouraged to read
<xref target="RFC4963" format="default" sectionFormat="of" derivedContent="RFC4963">"IPv4 Reassembly Errors at High Data Rates"</xref>
and follow the references for more information.
That experience led to the definition of the <xref target="RFC8201" format="default" sectionFormat="of" derivedContent="RFC8201">"Path
MTU Discovery for IP version 6"</xref> protocol that limits fragmentation over the
Internet.
Specifically, in the case of UDP, valuable additional information can be
found in <xref target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085">"UDP Usage Guidelines"</xref>.
</t>
<t indent="0" pn="section-2.2-4"><xref target="RFC8087" format="default" sectionFormat="of" derivedContent="RFC8087">
"The Benefits of Using Explicit Congestion Notification (ECN)"</xref>
provides useful information on the potential benefits and pitfalls of
using ECN.
</t>
<t indent="0" pn="section-2.2-5">Quoting <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031">
"Multiprotocol Label Switching Architecture"</xref>:
</t>
<blockquote pn="section-2.2-6">With MPLS, "packets are "labeled" before they are forwarded [along a Label Switched
Path (LSP)]. At subsequent hops, there is no further analysis of the packet's
network layer header. Rather, the label is used as an index into a
table which specifies the next hop, and a new label".</blockquote>
<t indent="0" pn="section-2.2-7">
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> leverages
MPLS to forward fragments that actually
do not have a network-layer header, since the fragmentation occurs below
IP, and this specification makes it reversible so the reverse path can
be followed as well.
</t>
</section>
<section anchor="new" numbered="true" removeInRFC="false" toc="include" pn="section-2.3">
<name slugifiedName="name-other-terms">Other Terms</name>
<t indent="0" pn="section-2.3-1">
This specification uses the following terms:
</t>
<dl indent="3" newline="false" spacing="normal" pn="section-2.3-2">
<dt pn="section-2.3-2.1">RFRAG:</dt>
<dd pn="section-2.3-2.2">Recoverable Fragment
</dd>
<dt pn="section-2.3-2.3">RFRAG-ACK:</dt>
<dd pn="section-2.3-2.4">Recoverable Fragment Acknowledgment
</dd>
<dt pn="section-2.3-2.5">RFRAG Acknowledgment Request:</dt>
<dd pn="section-2.3-2.6">An RFRAG with the
Acknowledgment Request flag ("X" flag) set.
</dd>
<dt pn="section-2.3-2.7">NULL bitmap:</dt>
<dd pn="section-2.3-2.8">Refers to a bitmap with all bits set to zero.
</dd>
<dt pn="section-2.3-2.9">FULL bitmap:</dt>
<dd pn="section-2.3-2.10">Refers to a bitmap with all bits set to one.
</dd>
<dt pn="section-2.3-2.11">Reassembling endpoint:</dt>
<dd pn="section-2.3-2.12">The receiving endpoint.
</dd>
<dt pn="section-2.3-2.13">Fragmenting endpoint:</dt>
<dd pn="section-2.3-2.14">The sending endpoint.
</dd>
<dt pn="section-2.3-2.15">Forward direction:</dt>
<dd pn="section-2.3-2.16">The direction of a path, which is followed by the RFRAG.
</dd>
<dt pn="section-2.3-2.17">Reverse direction:</dt>
<dd pn="section-2.3-2.18">The reverse direction of a path, which is taken by the
RFRAG-ACK.
</dd>
</dl>
<t indent="0" pn="section-2.3-3">
</t>
</section>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3">
<name slugifiedName="name-updating-rfc-4944">Updating RFC 4944</name>
<t indent="0" pn="section-3-1">This specification updates the fragmentation mechanism that is
specified in <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/> for use in route-over
LLNs by providing a model where fragments can be forwarded
end to end across a 6LoWPAN LLN and where fragments that are lost on
the way can be recovered individually.
A new format for fragments is introduced, and new dispatch types are defined
in <xref target="dispatch" format="default" sectionFormat="of" derivedContent="Section 5"/>.
</t>
<t indent="0" pn="section-3-2">
<xref target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138"/> allows modifying the size of a packet en route by
removing the consumed hops in a compressed Routing Header.
This requires that
Fragment_Offset and Datagram_Size (defined in <xref target="RF2" format="default" sectionFormat="of" derivedContent="Section 5.1"/>) also be
modified en route, which is difficult to do in the uncompressed form.
This specification expresses those fields in the compressed form and
allows modifying them en route easily (more in <xref target="mod" format="default" sectionFormat="of" derivedContent="Section 4.4"/>).
</t>
<t indent="0" pn="section-3-3">
To be consistent with <xref target="RFC6282" sectionFormat="of" section="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6282#section-2" derivedContent="RFC6282"/>, for the
fragmentation mechanism described in <xref target="RFC4944" sectionFormat="of" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4944#section-5.3" derivedContent="RFC4944"/>,
any header that cannot fit within the first fragment <bcp14>MUST NOT</bcp14> be compressed
when using the fragmentation mechanism described in this specification.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-4">
<name slugifiedName="name-extending-rfc-8930">Extending RFC 8930</name>
<t indent="0" pn="section-4-1">This specification implements the generic 6LFF technique defined in
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> and provides end-to-end fragment
recovery and congestion control mechanisms.
</t>
<section numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
<name slugifiedName="name-slack-in-the-first-fragment">Slack in the First Fragment</name>
<t indent="0" pn="section-4.1-1">
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> allows for a refragmentation operation
in intermediate nodes, whereby the trailing bytes from a given fragment may be
left in the VRB to be added as the heading bytes in the next fragment.
This solves the case when the outgoing fragment needs more space than the incoming fragment; that case may arise when
the 6LoWPAN header compression is not as efficient on the outgoing link or
if the Link MTU is reduced.
</t>
<t indent="0" pn="section-4.1-2">
This specification cannot allow that refragmentation operation since
the fragments are recovered end to end based on a sequence number. The
Fragment_Size <bcp14>MUST</bcp14> be tailored to fit the minimal MTU along the path, and
the first fragment that contains a 6LoWPAN compressed header <bcp14>MUST</bcp14> have enough
slack to enable a less-efficient compression in the next hops to still
fit within the Link MTU.
</t>
<t indent="0" pn="section-4.1-3">
For instance, if the fragmenting endpoint is also the 6LoWPAN compression endpoint, it will
elide the Interface ID (IID) of the source IPv6 address when it matches the link-layer address
<xref target="RFC6282" format="default" sectionFormat="of" derivedContent="RFC6282"/>. In that case, it <bcp14>MUST</bcp14> leave slack in the first fragment as the if MTU on the first hop was 8 bytes less, so the next hop can expand the IID within the same fragment within MTU.
</t>
</section>
<section anchor="gap" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
<name slugifiedName="name-gap-between-frames">Gap between Frames</name>
<t indent="0" pn="section-4.2-1"><xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> requires that a
configurable interval of time be inserted between transmissions to the same
next hop and, in particular, between fragments of a same datagram.
In the case of half duplex interfaces, this inter-frame gap ensures that the
next hop is done forwarding the previous frame and is capable of receiving
the next one.
</t>
<t indent="0" pn="section-4.2-2">
In the case of a mesh operating at a single frequency with omnidirectional
antennas, a larger inter-frame gap is required to protect the frame against
hidden terminal collisions with the previous frame of the same flow that is
still progressing along a common path.
</t>
<t indent="0" pn="section-4.2-3">
The inter-frame gap is useful even for unfragmented datagrams, but it
becomes a necessity for fragments that are typically generated in a fast
sequence and are all sent over the exact same path.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
<name slugifiedName="name-congestion-control">Congestion Control</name>
<t indent="0" pn="section-4.3-1">
The inter-frame gap is the only protection that
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> imposes by default. This
document enables grouping fragments in windows and requesting intermediate
acknowledgments, so the number of in-flight fragments can be bounded.
This document also adds an
ECN mechanism that can be used to protect the network by adapting the
size of the window, the size of the fragments, and/or the inter-frame gap.
</t>
<t indent="0" pn="section-4.3-2">
This specification enables the fragmenting endpoint to apply a congestion control
mechanism to tune those parameters, but the mechanism itself is out of scope.
In most cases, the expectation is that most datagrams will require only a
few fragments, and that only the last fragment will be acknowledged. A
basic implementation of the fragmenting endpoint is NOT <bcp14>REQUIRED</bcp14> to vary
the size of the window, the duration of the inter-frame gap, or the size of a
fragment in the middle of the transmission of a datagram, and it <bcp14>MAY</bcp14> ignore
the ECN signal or simply reset the window to 1 (see <xref target="onECN" format="default" sectionFormat="of" derivedContent="Appendix C"/>)
until the end of this datagram upon detecting a congestion.
</t>
<t indent="0" pn="section-4.3-3">
An intermediate node that experiences a congestion <bcp14>MAY</bcp14> set the ECN bit in a
fragment, and the reassembling endpoint echoes the ECN bit at most once at
the next opportunity to acknowledge back.
</t>
<t indent="0" pn="section-4.3-4">
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 and the duration of the inter-frame
gap <bcp14>SHOULD</bcp14> be configurable, to reduce the chances of congestion and to
follow the general recommendations
in <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>, respectively.
</t>
</section>
<section anchor="mod" numbered="true" removeInRFC="false" toc="include" pn="section-4.4">
<name slugifiedName="name-modifying-the-first-fragmen">Modifying the First Fragment</name>
<t indent="0" pn="section-4.4-1">
The compression of the hop limit, of the source and destination addresses
in the IPv6 header, and of the Routing Header, which are all in the first fragment, may change en route in a
route-over mesh LLN.
If the size of the first fragment is modified, then the intermediate node
<bcp14>MUST</bcp14> adapt the Datagram_Size, encoded in the Fragment_Size field,
to reflect that difference.
</t>
<t indent="0" pn="section-4.4-2">
The intermediate node <bcp14>MUST</bcp14> also save the difference of Datagram_Size 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. In the case of a Source Routing
Header 6LoWPAN Routing Header (SRH-6LoRH)
<xref target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138"/> being consumed and thus reduced, that
difference is negative, meaning that the Fragment_Offset is decremented by
the number of bytes that were consumed.
</t>
</section>
</section>
<section anchor="dispatch" numbered="true" removeInRFC="false" toc="include" pn="section-5">
<name slugifiedName="name-new-dispatch-types-and-head">New Dispatch Types and Headers</name>
<t indent="0" pn="section-5-1"> This document specifies an alternative to the 6LoWPAN fragmentation
sub-layer <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/> to emulate a Link MTU up to 2048 bytes
for the upper layer, which can be the 6LoWPAN header compression sub-layer
that is defined in <xref target="RFC6282" format="default" sectionFormat="of" derivedContent="RFC6282">"Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks"</xref>. This specification also provides a reliable
transmission of the fragments over a multi-hop 6LoWPAN route-over mesh
network and a minimal congestion control to reduce the chances of congestion loss.
</t>
<t indent="0" pn="section-5-2">
A 6LoWPAN Fragment Forwarding <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>
technique derived from MPLS enables the forwarding of individual fragments
across a 6LoWPAN route-over mesh without reassembly at each hop.
The Datagram_Tag is used as a label; it is locally unique to the
node that owns the source link-layer address of the fragment, so together
the link-layer address and the label can identify the fragment globally
within the lifetime of the datagram.
A node may build the Datagram_Tag in its own locally significant way,
as long as the chosen Datagram_Tag stays unique to the particular datagram
for its lifetime.
The result is that the label does not need to be globally unique, but
it must be swapped at each hop as the source link-layer address changes.
</t>
<t indent="0" pn="section-5-3">
In the following sections, a Datagram_Tag extends the semantics defined in
"Fragmentation Type and Header" (see <xref target="RFC4944" sectionFormat="of" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4944#section-5.3" derivedContent="RFC4944"/>).
The Datagram_Tag is a locally unique identifier for the datagram from the
perspective of the sender. This means that the Datagram_Tag identifies a
datagram uniquely in the network when associated with the source of the
datagram. As the datagram gets forwarded, the source changes, and the
Datagram_Tag must be swapped as detailed in
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>.
</t>
<t indent="0" pn="section-5-4">This specification extends <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/>
with two new dispatch types for RFRAG and the RFRAG-ACK that is received back.
The new 6LoWPAN dispatch types are taken from
<xref target="RFC8025" format="default" sectionFormat="of" derivedContent="RFC8025"/>, as indicated in <xref target="difig" format="default" sectionFormat="of" derivedContent="Table 1"/>
of <xref target="ianacon" format="default" sectionFormat="of" derivedContent="Section 9"/>.</t>
<section anchor="RF2" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
<name slugifiedName="name-recoverable-fragment-dispat">Recoverable Fragment Dispatch Type and Header </name>
<t indent="0" pn="section-5.1-1">
In this specification, if the packet is compressed, the size and offset
of the fragments are expressed with respect to the compressed form of the
packet, as opposed to the uncompressed (native) form.
</t>
<t indent="0" pn="section-5.1-2">
The format of the fragment header is shown in <xref target="RFfigalt" format="default" sectionFormat="of" derivedContent="Figure 1"/>.
It is the same for all fragments even though the Fragment_Offset is overloaded.
The format has a length and an offset, as
well as a Sequence field. This would be redundant if the offset was computed
as the product of the Sequence by the length, but this is not the case.
The position of a fragment in the
reassembly buffer is correlated with neither the value of the Sequence
field nor the order in which the fragments are received.
This enables splitting fragments to cope with an MTU deduction; see the example of
fragment Sequence 5 that is retried end to end as smaller fragment Sequences 13
and 14 in <xref target="ura" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.
</t>
<t indent="0" pn="section-5.1-3">
The first fragment is recognized by a Sequence of 0; it carries its
Fragment_Size and the Datagram_Size of the compressed packet before it is
fragmented, whereas the other fragments carry their Fragment_Size and
Fragment_Offset. The last fragment
for a datagram is recognized when its Fragment_Offset and its Fragment_Size
add up to the stored Datagram_Size of the packet identified by the
sender link-layer address and the Datagram_Tag.
</t>
<figure anchor="RFfigalt" align="left" suppress-title="false" pn="figure-1">
<name slugifiedName="name-rfrag-dispatch-type-and-hea">RFRAG Dispatch Type and Header</name>
<artwork align="center" pn="section-5.1-4.1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 0|E| Datagram_Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Sequence| Fragment_Size | Fragment_Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X set == Ack-Request
</artwork>
</figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.1-5">
<dt pn="section-5.1-5.1">X:</dt>
<dd pn="section-5.1-5.2">1 bit; Ack-Request. When set, the fragmenting endpoint requires an
RFRAG Acknowledgment from the reassembling endpoint.
</dd>
<dt pn="section-5.1-5.3">E:</dt>
<dd pn="section-5.1-5.4">1 bit; Explicit Congestion Notification. The "E"
flag is cleared by the source of the fragment and set by intermediate
routers to signal that this fragment experienced congestion along
its path.
</dd>
<dt pn="section-5.1-5.5">Fragment_Size:</dt>
<dd pn="section-5.1-5.6">10-bit unsigned integer. The size of this
fragment in a unit that depends on link-layer technology. Unless
overridden by a more specific specification, that unit is the byte,
which allows fragments up to 1023 bytes.
</dd>
<dt pn="section-5.1-5.7">Datagram_Tag:</dt>
<dd pn="section-5.1-5.8">8 bits. An identifier of the datagram that
is locally unique to the link-layer sender.
</dd>
<dt pn="section-5.1-5.9">Sequence:</dt>
<dd pn="section-5.1-5.10">5-bit unsigned integer.
The sequence number of the fragment in the acknowledgment bitmap.
Fragments are numbered as [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 the position in the reassembly buffer.
</dd>
<dt pn="section-5.1-5.11">Fragment_Offset:</dt>
<dd pn="section-5.1-5.12">
<t indent="0" pn="section-5.1-5.12.1">16-bit unsigned integer.</t>
<t indent="0" pn="section-5.1-5.12.2">
When the Fragment_Offset is set to a non-zero value, its semantics depend
on the value of the Sequence field as follows:
</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-5.12.3">
<li pn="section-5.1-5.12.3.1">
For a first fragment (i.e., with a Sequence of 0), this field indicates
the Datagram_Size of the compressed datagram, to help the reassembling endpoint
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 <xref target="ff" format="default" sectionFormat="of" derivedContent="Section 6.1.1"/>.
</li>
<li pn="section-5.1-5.12.3.2">
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 <xref target="nf" format="default" sectionFormat="of" derivedContent="Section 6.1.2"/>.
</li>
</ul>
<t indent="0" pn="section-5.1-5.12.4">
A Fragment_Offset that is set to a value of 0 indicates
an abort condition, and all states regarding the datagram should be
cleaned up once the processing of the fragment is complete;
the processing of the fragment depends on whether there is a VRB already
established for this datagram and if the next hop is still reachable:
</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-5.12.5">
<li pn="section-5.1-5.12.5.1">
if a VRB already exists and the next hop is still reachable, the fragment
is to be
forwarded along the associated LSP
as described in <xref target="nf" format="default" sectionFormat="of" derivedContent="Section 6.1.2"/>, without checking the value
of the Sequence field.
</li>
<li pn="section-5.1-5.12.5.2">
else, if the Sequence is 0, then the fragment is to be routed as
described in <xref target="ff" format="default" sectionFormat="of" derivedContent="Section 6.1.1"/>, but no state is conserved 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 along the
path indicated by the IPv6 header (possibly including a Routing Header).
</li>
<li pn="section-5.1-5.12.5.3">
else (the Sequence is non-zero and either no VRB exists or the next hop
is unavailable), the fragment cannot be forwarded or routed; the fragment
is discarded and an abort RFRAG-ACK
is sent back to the source as described in <xref target="nf" format="default" sectionFormat="of" derivedContent="Section 6.1.2"/>.
</li>
</ul>
<t indent="0" pn="section-5.1-5.12.6">
</t>
</dd>
</dl>
<t indent="0" pn="section-5.1-6">
Recoverable Fragments are sequenced, and a bitmap is used in the RFRAG
Acknowledgment to indicate the received fragments by setting the individual
bits that correspond to their sequence.
</t>
<t indent="0" pn="section-5.1-7">
There is no requirement on the reassembling endpoint to check that the
received fragments are consecutive and non-overlapping.
This may be useful, in particular, in the case where the MTU changes and a
fragment Sequence is retried with a smaller Fragment_Size, with the remainder of
the original fragment being retried with new Sequence values.
The fragmenting endpoint knows that the datagram is fully received
when the acknowledged fragments cover the whole datagram, which is implied
by a FULL bitmap.
</t>
</section>
<section anchor="ackfrag" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
<name slugifiedName="name-rfrag-acknowledgment-dispat">RFRAG Acknowledgment Dispatch Type and Header</name>
<t indent="0" pn="section-5.2-1">This specification also defines a 4-byte RFRAG Acknowledgment Bitmap
that is used by the reassembling endpoint
to selectively confirm the reception of individual fragments.
A given offset in the bitmap maps one to one with a given sequence number
and indicates which fragment is acknowledged as follows:
</t>
<figure anchor="dCack3" align="left" suppress-title="false" pn="figure-2">
<name slugifiedName="name-rfrag-acknowledgment-bitmap">RFRAG Acknowledgment Bitmap Encoding</name>
<artwork align="center" pn="section-5.2-2.1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFRAG Acknowledgment Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^
| | bitmap indicating whether:
| +----- Fragment with Sequence 9 was received
+----------------------- Fragment with Sequence 0 was received
</artwork>
</figure>
<t indent="0" pn="section-5.2-3"> <xref target="dCack2" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows an example RFRAG Acknowledgment Bitmap that
indicates that all fragments from Sequence 0 to 20 were received, except
for fragments 1, 2, and 16, which were lost and must be retried.
</t>
<figure anchor="dCack2" align="left" suppress-title="false" pn="figure-3">
<name slugifiedName="name-example-rfrag-acknowledgmen">Example RFRAG Acknowledgment Bitmap</name>
<artwork align="center" pn="section-5.2-4.1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t indent="0" pn="section-5.2-5">The RFRAG Acknowledgment Bitmap is included in
an RFRAG Acknowledgment header, as follows:
</t>
<figure anchor="ackfig" align="left" suppress-title="false" pn="figure-4">
<name slugifiedName="name-rfrag-acknowledgment-dispatc">RFRAG Acknowledgment Dispatch Type and Header</name>
<artwork align="center" pn="section-5.2-6.1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 1|E| Datagram_Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFRAG Acknowledgment Bitmap (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.2-7">
<dt pn="section-5.2-7.1">E:</dt>
<dd pn="section-5.2-7.2">1 bit; Explicit Congestion Notification Echo.</dd>
<dt pn="section-5.2-7.3"/>
<dd pn="section-5.2-7.4">When set, the fragmenting endpoint 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. See more details in
<xref target="onECN" format="default" sectionFormat="of" derivedContent="Appendix C"/>.
</dd>
<dt pn="section-5.2-7.5">Datagram_Tag:</dt>
<dd pn="section-5.2-7.6">8 bits; an identifier of the datagram that
is locally unique to the link-layer recipient.
</dd>
<dt pn="section-5.2-7.7">RFRAG Acknowledgment Bitmap:</dt>
<dd pn="section-5.2-7.8">An RFRAG Acknowledgment Bitmap, whereby setting the bit at offset x
indicates that fragment x was received, as shown in <xref target="dCack3" format="default" sectionFormat="of" derivedContent="Figure 2"/>.
A NULL bitmap indicates that the fragmentation process is aborted.
A FULL bitmap indicates that the fragmentation process is complete;
all fragments were received at the reassembly endpoint.
</dd>
</dl>
</section>
</section>
<section anchor="ffc" numbered="true" removeInRFC="false" toc="include" pn="section-6">
<name slugifiedName="name-fragment-recovery">Fragment Recovery</name>
<t indent="0" pn="section-6-1">
The RFRAG header is used to transport
a fragment and optionally request an RFRAG-ACK that
confirms the reception of one or more fragments.
An RFRAG-ACK is carried as a standalone fragment header (i.e.,
with no 6LoWPAN payload) in a message that is propagated back to the
fragmenting endpoint.
To achieve this, each hop that performed an MPLS-like operation on fragments
reverses that operation for the RFRAG-ACK by sending a frame from the next
hop to the previous hop as known by its link-layer address in the VRB.
The Datagram_Tag in the RFRAG-ACK is unique to the reassembling endpoint and is enough
information for an intermediate hop to locate the VRB that contains the
Datagram_Tag used by the previous hop and the Layer 2 information associated with it (interface and link-layer address).
</t>
<t indent="0" pn="section-6-2"> The fragmenting endpoint (i.e., the node that fragments the packets at the 6LoWPAN level)
also controls the number of acknowledgments by setting the Ack-Request flag in the RFRAG packets.
</t>
<t indent="0" pn="section-6-3">
The fragmenting endpoint may set the Ack-Request flag on any fragment to perform
congestion control by limiting the number of outstanding fragments, which
are the fragments that have been sent but for which reception or loss
was not positively confirmed by the reassembling endpoint. The maximum
number of outstanding fragments is controlled by the Window-Size. It is configurable and
may vary in case of ECN notification. When the endpoint that
reassembles the packets at the 6LoWPAN level receives a fragment with the Ack-Request flag set, it <bcp14>MUST</bcp14> send an
RFRAG-ACK back to the originator to confirm reception of all the
fragments it has received so far.
</t>
<t indent="0" pn="section-6-4">
The Ack-Request ("X") set in an RFRAG marks the end of a window. This flag
<bcp14>MUST</bcp14> be set on the last fragment if the fragmenting endpoint wishes to perform
an automatic repeat request (ARQ) process for the datagram,
and it <bcp14>MAY</bcp14> be set in any intermediate fragment for the purpose of congestion control.
</t>
<t indent="0" pn="section-6-5">
This ARQ process <bcp14>MUST</bcp14> be protected by a Retransmission Timeout (RTO) timer,
and the fragment that carries the "X"
flag <bcp14>MAY</bcp14> be retried upon a timeout for a configurable number of times (see
<xref target="protp" format="default" sectionFormat="of" derivedContent="Section 7.1"/>) with an exponential backoff.
Upon exhaustion of the retries, the fragmenting endpoint may either abort the
transmission of the datagram or resend the first fragment with an "X" flag
set in order to establish a new path for the datagram and obtain the list of
fragments that were received over the old path in the acknowledgment bitmap.
When the fragmenting endpoint knows that an underlying link-layer
mechanism protects the fragments, it may refrain from using the RFRAG
Acknowledgment mechanism and never set the Ack-Request bit.
</t>
<t indent="0" pn="section-6-6">The reassembling endpoint <bcp14>MAY</bcp14> issue unsolicited acknowledgments.
An unsolicited acknowledgment signals to the fragmenting endpoint that it
can resume sending in case it has reached its maximum number
of outstanding fragments. Another use is to inform the fragmenting endpoint
that the reassembling endpoint aborted the processing of an individual
datagram.
</t>
<t indent="0" pn="section-6-7">
The RFRAG Acknowledgment carries an ECN indication for congestion
control (see <xref target="onECN" format="default" sectionFormat="of" derivedContent="Appendix C"/>).
The reassembling endpoint of a fragment with the "E" (ECN) flag set <bcp14>MUST</bcp14>
echo that information at most once by setting the "E" (ECN) flag
in the next RFRAG-ACK.
</t>
<t indent="0" pn="section-6-8">
In order to protect the datagram, the fragmenting endpoint transfers a controlled number
of fragments and flags to the last
fragment of a window with an RFRAG Acknowledgment Request. The reassembling endpoint <bcp14>MUST</bcp14>
acknowledge a fragment with the acknowledgment request bit set.
If any fragment immediately preceding
an acknowledgment request is still missing, the reassembling endpoint <bcp14>MAY</bcp14> intentionally
delay its acknowledgment to allow in-transit fragments to arrive.
Because it might defeat the round-trip time computation, delaying the
acknowledgment should be configurable and not enabled by default.
</t>
<t indent="0" pn="section-6-9">
When enough fragments are received to cover the whole datagram, the reassembling endpoint reconstructs
the packet, passes it to the upper layer, sends an RFRAG-ACK on
the reverse path with a FULL bitmap, and arms a short timer, e.g.,
on the order of an average round-trip time in the network. The FULL bitmap
is used as opposed to a bitmap that acknowledges only the received fragments
to let the intermediate nodes know that the datagram is fully received.
As the timer runs, the reassembling endpoint absorbs the fragments that were
still in flight for that datagram without creating a new state, acknowledging
the ones that bear an Ack-Request with an FRAG Acknowledgment and the
FULL bitmap.
The reassembling endpoint aborts the communication if fragments with a
matching source and Datagram-Tag continue to be received
after the timer expires.</t>
<t indent="0" pn="section-6-10">
Note that acknowledgments might consume precious resources, so the use of
unsolicited acknowledgments <bcp14>SHOULD</bcp14> be configurable and not enabled by
default.
</t>
<t indent="0" pn="section-6-11">
An observation is that streamlining the forwarding of fragments generally
reduces the latency over the LLN mesh, providing room for retries within
existing upper-layer reliability mechanisms.
The fragmenting endpoint protects the transmission over the LLN mesh with a retry timer
that is configured for a use case and may be adapted dynamically, e.g.,
according to the method detailed in <xref target="RFC6298" format="default" sectionFormat="of" derivedContent="RFC6298"/>.
It is expected that the upper-layer retry mechanism obeys the recommendations in
<xref target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085"/>, in which case a single
round of fragment recovery should fit within the upper-layer recovery timers.
</t>
<t indent="0" pn="section-6-12">
Fragments <bcp14>MUST</bcp14> be sent in a round-robin fashion: the sender <bcp14>MUST</bcp14> send all
the fragments for a first time before it retries any lost fragment; lost
fragments <bcp14>MUST</bcp14> be retried in sequence, oldest first. This mechanism
enables the receiver to acknowledge fragments that were delayed in
the network before they are retried.
</t>
<t indent="0" pn="section-6-13">
When a single radio frequency is used by contiguous hops, the fragmenting endpoint <bcp14>SHOULD</bcp14> insert a delay between the frames (e.g., carrying fragments) that are sent to the same next hop. The delay <bcp14>SHOULD</bcp14> cover multiple transmissions so as to let a frame progress a few hops and avoid hidden terminal issues.
This precaution is not required on channel hopping technologies such as Time-Slotted Channel Hopping (TSCH)
<xref target="RFC6554" format="default" sectionFormat="of" derivedContent="RFC6554"/>, where nodes that communicate at Layer 2 are scheduled to send
and receive, respectively, and different hops operate on different channels.
</t>
<section anchor="ffg" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
<name slugifiedName="name-forwarding-fragments">Forwarding Fragments</name>
<t indent="0" pn="section-6.1-1">
This specification inherits from <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>
and proposes a Virtual Reassembly Buffer technique to forward fragments with no intermediate reconstruction of the entire datagram.
</t>
<t indent="0" pn="section-6.1-2">
The IPv6 header <bcp14>MUST</bcp14> be placed in the first fragment in full to enable the routing decision. The first fragment is routed and creates an LSP from the fragmenting endpoint to the reassembling endpoint. The next fragments are label switched along that LSP.
As a consequence, the next fragments can only follow the path that was set
up by the first fragment; they cannot follow an alternate route.
The Datagram_Tag is used to carry the label, which is swapped in each hop.
</t>
<t indent="0" pn="section-6.1-3">
If the first fragment is too large for the path MTU, it will repeatedly fail
and never establish an LSP. In that case,
the fragmenting endpoint <bcp14>MAY</bcp14> retry the same datagram with a smaller
Fragment_Size, in which case it <bcp14>MUST</bcp14> abort the original attempt and use a
new Datagram_Tag for the new attempt.
</t>
<section anchor="ff" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.1">
<name slugifiedName="name-receiving-the-first-fragmen">Receiving the First Fragment</name>
<t indent="0" pn="section-6.1.1-1">
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 the
Datagram_Tag by the sender is associated with the source link-layer address and only valid (and temporarily unique) for that source link-layer address.
</t>
<t indent="0" pn="section-6.1.1-2">
Upon receiving the first fragment (i.e., with a Sequence of 0), an intermediate router
creates a VRB and the associated
LSP state indexed by the incoming interface, the previous-hop link-layer address,
and the Datagram_Tag and forwards the fragment along the IPv6 route that matches
the destination IPv6 address in the IPv6 header until it reaches the
reassembling endpoint, as prescribed by
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>.
The LSP state enables matching the next incoming fragments of a datagram to
the abstract forwarding information of the next interface, source and next-hop
link-layer addresses, and the swapped Datagram_Tag.
</t>
<t indent="0" pn="section-6.1.1-3">
In addition, the router also forms a reverse LSP state indexed by the interface to the next hop, the link-layer address the router uses as source for that datagram, and the swapped Datagram_Tag. This reverse LSP state
enables matching the tuple (interface, destination link-layer address, Datagram_Tag) found in an RFRAG-ACK to the abstract forwarding information (previous interface, previous link-layer address, Datagram_Tag) used to forward the RFRAG-ACK back to the fragmenting endpoint.
</t>
</section>
<section anchor="nf" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.2">
<name slugifiedName="name-receiving-the-next-fragment">Receiving the Next Fragments</name>
<t indent="0" pn="section-6.1.2-1">Upon receiving the next fragment (i.e., with a non-zero Sequence),
an intermediate router looks up
an LSP indexed by the tuple (incoming interface, previous-hop link-layer address, Datagram_Tag) found in the fragment.
If it is found, the router forwards the fragment using the associated VRB as
prescribed by <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>.
</t>
<t indent="0" pn="section-6.1.2-2">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 the
following information:
</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.2-3">
<li pn="section-6.1.2-3.1">The source and destination link-layer addresses are swapped from those found
in the fragment, and the same interface is used</li>
<li pn="section-6.1.2-3.2">The Datagram_Tag is set to the Datagram_Tag found in the fragment</li>
<li pn="section-6.1.2-3.3">A NULL bitmap is used to signal the abort condition</li>
</ul>
<t indent="0" pn="section-6.1.2-4">
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 all the way
to the source using the reverse LSP state in the VRBs in the intermediate
routers as described in the next section.
</t>
<t indent="0" pn="section-6.1.2-5">
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> indicates that the
reassembling endpoint stores
"the actual packet data from the fragments received so far, in a form that
makes it possible to detect when the whole packet has been received and can
be processed or forwarded".
How this is computed is implementation specific,
but it relies on receiving all the bytes up to the Datagram_Size indicated in
the first fragment.
An implementation may receive overlapping fragments as the result of retries
after an MTU change.
</t>
</section>
</section>
<section anchor="ura" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
<name slugifiedName="name-receiving-rfrag-acknowledgm">Receiving RFRAG Acknowledgments</name>
<t indent="0" pn="section-6.2-1">Upon receipt of an RFRAG-ACK, the router looks up a reverse LSP indexed by the interface and destination link-layer address of the received frame and the received Datagram_Tag in the RFRAG-ACK.
If it is found, the router forwards the fragment using the associated VRB as
prescribed by <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>, but it uses
the reverse LSP so that the RFRAG-ACK flows back to the fragmenting endpoint.
</t>
<t indent="0" pn="section-6.2-2">If the reverse LSP is not found, the router <bcp14>MUST</bcp14> silently drop the RFRAG-ACK message.</t>
<t indent="0" pn="section-6.2-3">Either way, if the RFRAG-ACK indicates that the fragment was entirely received (FULL bitmap), it arms a short timer, and upon timeout, the VRB and all the associated states are destroyed. Until the timer elapses, fragments of that datagram may still be received, e.g., if the RFRAG-ACK was lost on the path back, and the source retried the last fragment. In that
case, the router generates an RFRAG-ACK with a FULL bitmap back to the fragmenting endpoint if an acknowledgment was requested; else, it silently drops the fragment. </t>
<t indent="0" pn="section-6.2-4">
This specification does not provide a method to discover the number of hops
or the minimal value of MTU along those hops. In a typical case, the MTU is
constant and is the same across the network. But should the minimal MTU along
the path decrease, it is possible to retry a long fragment (say a Sequence of 5) with
several shorter fragments with a Sequence that was not used before (e.g.,
13 and 14). Fragment 5 is marked as abandoned and will not be retried
anymore. Note that when this mechanism is in place, it is hard to predict
the total number of fragments that will be needed or the final shape of the
bitmap that would cover the whole packet. This is why the FULL bitmap is used
when the reassembling endpoint gets the whole datagram regardless of which
fragments were actually used to do so. Intermediate nodes will know unambiguously
that the process is complete. Note that Path MTU Discovery is out of scope for this document.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
<name slugifiedName="name-aborting-the-transmission-o">Aborting the Transmission of a Fragmented Packet</name>
<t indent="0" pn="section-6.3-1">
A reset is signaled on the forward path with a pseudo fragment that has the Fragment_Offset set to 0. The sender of a reset <bcp14>SHOULD</bcp14> also set the Sequence and Fragment_Size field to 0.
</t>
<t indent="0" pn="section-6.3-2">
When the fragmenting endpoint or a router on the path decides that a packet should be dropped and the fragmentation process aborted, it generates a reset pseudo fragment and forwards it down the fragment path.
</t>
<t indent="0" pn="section-6.3-3">Each router along the path forwards the pseudo fragment in
turn based on the VRB state. If an acknowledgment is not requested, the VRB and all associated states are destroyed.
</t>
<t indent="0" pn="section-6.3-4">
Upon reception of the pseudo fragment, the reassembling endpoint cleans up all resources for the packet
associated with the Datagram_Tag. If an acknowledgment is requested, the reassembling endpoint responds with a NULL bitmap.
</t>
<t indent="0" pn="section-6.3-5">On the other hand, the reassembling endpoint might need to abort the processing of a fragmented packet for internal reasons, for instance, if it is out of reassembly buffers, already uses all 256 possible values of the Datagram_Tag, or keeps receiving fragments beyond a reasonable time while it considers that this packet is already fully reassembled and was passed to the upper layer. In that case, the reassembling endpoint <bcp14>SHOULD</bcp14> indicate so to the fragmenting endpoint with a NULL bitmap in an RFRAG-ACK.
</t>
<t indent="0" pn="section-6.3-6">
The RFRAG-ACK is forwarded all the way back to the source of the packet and cleans up all resources on the path.
Upon an acknowledgment with a NULL bitmap, the fragmenting endpoint <bcp14>MUST</bcp14> abort the transmission of the fragmented datagram with one exception: in the particular case of the first fragment, it <bcp14>MAY</bcp14> decide to retry via an alternate next hop instead.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
<name slugifiedName="name-applying-recoverable-fragme">Applying Recoverable Fragmentation along a Diverse Path</name>
<t indent="0" pn="section-6.4-1">
The text above can be read with the assumption of a serial path between a
source and a destination. The IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) architecture (see
<xref target="I-D.ietf-6tisch-architecture" sectionFormat="of" section="4.5.3" format="default" derivedLink="https://tools.ietf.org/html/draft-ietf-6tisch-architecture-29#section-4.5.3" derivedContent="6TiSCH"/>)
defines the concept of a Track that can be a complex path between a source
and a destination with Packet ARQ, Replication,
Elimination, and Overhearing (PAREO) along the Track. This specification
can be used along any subset of
the complex Track where the first fragment is flooded. The last RFRAG
Acknowledgment is flooded on that same subset in the reverse direction.
Intermediate RFRAG Acknowledgments can be flooded on any sub-subset of that
reverse subset that reaches back to the source.
</t>
</section>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-7">
<name slugifiedName="name-management-considerations">Management Considerations</name>
<t indent="0" pn="section-7-1">
This specification extends <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> and requires the same parameters in the reassembling endpoint and on intermediate nodes. There is no new parameter as echoing ECN is always on. These parameters typically include the reassembly timeout at the reassembling endpoint, an inactivity cleanup timer on the intermediate nodes, and the number of messages that can be processed in parallel in all nodes.
</t>
<t indent="0" pn="section-7-2">
The configuration settings introduced by this specification only apply to the fragmenting endpoint, which is in full control of the transmission.
LLNs vary a lot in size (there can be thousands of nodes in a mesh), in
speed (from 10 Kbps to several Mbps at the PHY layer), in traffic density, and in optimizations that are desired (e.g., the selection of a Routing Protocol for LLNs (RPL) <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> Objective Function <xref target="RFC6552" format="default" sectionFormat="of" derivedContent="RFC6552"/> impacts the shape of the routing graph).
</t>
<t indent="0" pn="section-7-3">
For that reason, only very generic guidance can be given on the settings of the fragmenting endpoint and on whether complex algorithms are needed to perform congestion control or to estimate the round-trip time. To cover the most complex use cases, this specification enables the fragmenting endpoint to vary the fragment size, the window size, and the inter-frame gap based on the number of losses, the observed variations of the round-trip time, and the setting of the ECN bit.
</t>
<section anchor="protp" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
<name slugifiedName="name-protocol-parameters">Protocol Parameters</name>
<t indent="0" pn="section-7.1-1">
The management system <bcp14>SHOULD</bcp14> be capable of providing the parameters listed in this section, and an
implementation <bcp14>MUST</bcp14> abide by those parameters and, in particular, never exceed the minimum and maximum configured boundaries.
</t>
<t indent="0" pn="section-7.1-2">
An implementation should consider the generic recommendations from the IETF in the matter of congestion control and rate management for IP datagrams in
<xref target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085"/>.
An implementation may perform congestion control by using a dynamic value of the window size (Window_Size), adapting the fragment size (Fragment_Size), and potentially
reducing the load by inserting an inter-frame gap that is longer than necessary. In a large network where nodes contend for the bandwidth, a larger Fragment_Size consumes less bandwidth but also reduces fluidity and incurs higher chances of loss in transmission. </t>
<t indent="0" pn="section-7.1-3">
This is controlled by the following parameters:
</t>
<dl indent="3" newline="false" spacing="normal" pn="section-7.1-4">
<dt pn="section-7.1-4.1">inter-frame gap:</dt>
<dd pn="section-7.1-4.2">
The inter-frame gap indicates the minimum amount of time between transmissions.
The inter-frame gap controls the rate at which fragments are sent, the ratio of air time, and the amount of memory in intermediate nodes that a particular datagram will use. It can be used as a flow control, a congestion control, and/or a collision
control measure.
It <bcp14>MUST</bcp14> be set at a minimum to a value that protects the propagation of one transmission against collision with next <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>. In a wireless network that uses the same frequency along a path, this may represent the time for a frame to progress over multiple hops (see more in <xref target="gap" format="default" sectionFormat="of" derivedContent="Section 4.2"/>).
It <bcp14>SHOULD</bcp14> be augmented beyond this as necessary to protect the network against congestion.
</dd>
<dt pn="section-7.1-4.3">MinFragmentSize:</dt>
<dd pn="section-7.1-4.4">
The MinFragmentSize is the minimum value for the Fragment_Size. It <bcp14>MUST</bcp14> be lower than the minimum value of smallest 1-hop MTU that can be encountered along the path.
</dd>
<dt pn="section-7.1-4.5">OptFragmentSize:</dt>
<dd pn="section-7.1-4.6">
The OptFragmentSize is the value for the Fragment_Size that the fragmenting endpoint
should use to start with. It is greater than or equal to MinFragmentSize. It is less than or equal to MaxFragmentSize. For the
first fragment, it must account for the expansion of the IPv6 addresses and of the Hop Limit field within MTU. For all fragments, it is a balance between the expected fluidity and the overhead of link-layer and 6LoWPAN headers. For a small MTU, the idea is to keep it close to the maximum, whereas for larger MTUs, it might make sense to keep it short enough so that the duty cycle of the transmitter is bounded, e.g., to transmit at least 10 frames per second.
</dd>
<dt pn="section-7.1-4.7">MaxFragmentSize:</dt>
<dd pn="section-7.1-4.8">
The MaxFragmentSize is the maximum value for the Fragment_Size.
It <bcp14>MUST</bcp14> be lower than the maximum value of the smallest 1-hop MTU that can be encountered along the path. A large
value augments the chances of buffer bloat and transmission loss.
The value <bcp14>MUST</bcp14> be less than 512 if the unit that is defined
for the PHY layer is the byte.
</dd>
<dt pn="section-7.1-4.9">Window_Size:</dt>
<dd pn="section-7.1-4.10">
<t indent="0" pn="section-7.1-4.10.1">
The Window_Size <bcp14>MUST</bcp14> be at least 1 and less than 33.
</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.1-4.10.2">
<li pn="section-7.1-4.10.2.1">
If the round-trip time is known, the Window_Size <bcp14>SHOULD</bcp14> be set to the round-trip time divided by the time per fragment; that is, the time to transmit a fragment plus the inter-frame gap.
</li>
</ul>
<t indent="0" pn="section-7.1-4.10.3">
Otherwise:
</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.1-4.10.4">
<li pn="section-7.1-4.10.4.1">
A window_size of 32 indicates that only the last fragment is to be acknowledged in each round. This is the <bcp14>RECOMMENDED</bcp14> value in a half-duplex LLN
where the fragment acknowledgment consumes roughly the same bandwidth on the
same links as the fragments themselves.
</li>
<li pn="section-7.1-4.10.4.2">
If it is set to a smaller value, more acks are generated.
In a full-duplex network, the load on the forward path will be lower, and
a small value of 3 <bcp14>SHOULD</bcp14> be configured.
</li>
</ul>
</dd>
</dl>
<t indent="0" pn="section-7.1-5">
An implementation may perform its estimate of the RTO or use a configured one. The ARQ process is controlled by the following parameters:
</t>
<dl indent="3" newline="false" spacing="normal" pn="section-7.1-6">
<dt pn="section-7.1-6.1">MinARQTimeOut:</dt>
<dd pn="section-7.1-6.2">
The minimum amount of time a node should wait for an RFRAG Acknowledgment before it takes the next action.
It <bcp14>MUST</bcp14> be more than the maximum expected round-trip time in the respective network.
</dd>
<dt pn="section-7.1-6.3">OptARQTimeOut:</dt>
<dd pn="section-7.1-6.4">
The initial value of the RTO, which is the amount of time that a fragmenting endpoint should wait for an RFRAG Acknowledgment before it takes the next action. It is greater than or equal to MinARQTimeOut. It is less than or equal to MaxARQTimeOut. See <xref target="onECN" format="default" sectionFormat="of" derivedContent="Appendix C"/> for recommendations on computing the round-trip time. By default, a value of 3 times the maximum expected round-trip time in the respective network is <bcp14>RECOMMENDED</bcp14>.
</dd>
<dt pn="section-7.1-6.5">MaxARQTimeOut:</dt>
<dd pn="section-7.1-6.6">
The maximum amount of time a node should wait for the RFRAG Acknowledgment before it takes the next action. It must cover the longest expected round-trip time and be several times less than the timeout that covers the recomposition buffer at the reassembling endpoint, which is typically on the order of the minute.
An upper bound can be estimated to ensure that the datagram is either fully transmitted or dropped
before an upper layer decides to retry it.
</dd>
<dt pn="section-7.1-6.7">MaxFragRetries:</dt>
<dd pn="section-7.1-6.8">
The maximum number of retries for a particular fragment. A default value of 3 is <bcp14>RECOMMENDED</bcp14>.
An upper bound can be estimated to ensure that the datagram is either fully transmitted or dropped
before an upper layer decides to retry it.
</dd>
<dt pn="section-7.1-6.9">MaxDatagramRetries:</dt>
<dd pn="section-7.1-6.10">
The maximum number of retries from scratch for a particular datagram.
A default value of 1 is <bcp14>RECOMMENDED</bcp14>.
An upper bound can be estimated to ensure that the datagram is either fully transmitted or dropped
before an upper layer decides to retry it.
</dd>
</dl>
<t indent="0" pn="section-7.1-7">
An implementation may be capable of performing congestion control based on ECN; see <xref target="onECN" format="default" sectionFormat="of" derivedContent="Appendix C"/>. This is controlled by the following parameter:
</t>
<dl indent="3" newline="false" spacing="normal" pn="section-7.1-8">
<dt pn="section-7.1-8.1">UseECN:</dt>
<dd pn="section-7.1-8.2">
Indicates whether the fragmenting endpoint should react to ECN.
The fragmenting endpoint may react to ECN by varying the Window_Size between
MinWindowSize and MaxWindowSize, varying the Fragment_Size between MinFragmentSize and MaxFragmentSize, and/or increasing or reducing the inter-frame gap.
With this specification, if UseECN is set and a fragmenting
endpoint detects a congestion, it may apply a congestion control method until the end of the datagram, whereas if UseECN is reset, the endpoint does not react to congestion.
Future specifications may provide additional parameters and capabilities.
</dd>
</dl>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
<name slugifiedName="name-observing-the-network">Observing the Network</name>
<t indent="0" pn="section-7.2-1">The management system should monitor the number of retries
and ECN settings that can be observed from the perspective of
the fragmenting endpoint with respect to the reassembling endpoint and reciprocally.
It may then tune the optimum size of
Fragment_Size and of Window_Size, OptFragmentSize, and OptWindowSize,
respectively, at the fragmenting endpoint towards a particular reassembling endpoint, which is applicable to the
next datagrams.
It will preferably tune the inter-frame gap to
increase the spacing between fragments of the same datagram and reduce the
buffer bloat in the intermediate node that holds one or more fragments of that
datagram.
</t>
</section>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-8">
<name slugifiedName="name-security-considerations">Security Considerations</name>
<t indent="0" pn="section-8-1">
This document specifies an instantiation of a 6LFF technique and inherits
from the generic description in <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>.
The considerations in the Security Considerations section of <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> equally apply to this document.
</t>
<t indent="0" pn="section-8-2">
In addition to the threats detailed therein, an attacker that is on path can
prematurely end the transmission of a datagram by sending a RFRAG Acknowledgment
to the fragmenting endpoint. It can also cause extra transmissions of
fragments by resetting bits in the RFRAG Acknowledgment Bitmap and of
RFRAG Acknowledgments by forcing the Ack-Request bit in fragments that it
forwards.
</t>
<t indent="0" pn="section-8-3">
As indicated in <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/>, secure joining and link-layer security are <bcp14>REQUIRED</bcp14> to protect against those attacks, as the fragmentation protocol does not include any native
security mechanisms.
</t>
<t indent="0" pn="section-8-4">
This specification does not recommend a particular algorithm for the
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 on the
path may slow down or discard packets, which in turn can affect the
throughput of fragmented packets.
</t>
<t indent="0" pn="section-8-5">Compared to
<xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/>, this specification reduces the Datagram_Tag to 8 bits, and
the tag wraps faster than with <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/>.
But for a constrained network where a node is expected to be able to hold
only one or a few large packets in memory, 256 is still a large number.
Also, the acknowledgment mechanism allows cleaning up the state rapidly
once the packet is fully transmitted or aborted.
</t>
<t indent="0" pn="section-8-6">
The abstract Virtual Recovery Buffer from
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> may be used to perform a
Denial-of-Service (DoS) attack against the intermediate routers since the
routers need to maintain a state per flow. The particular VRB implementation
technique described in
<xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly" format="default" sectionFormat="of" derivedContent="LWIG-FRAG"/> allows realigning
which data goes in which fragment; this causes the intermediate node to
store a portion of the data, which adds an 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.
</t>
</section>
<section anchor="ianacon" numbered="true" removeInRFC="false" toc="include" pn="section-9">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-9-1">
This document allocates two patterns for a total of four dispatch values for Recoverable Fragments from the
"Dispatch Type Field" registry that was created by <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/> and
reformatted by <xref target="RFC8025" format="default" sectionFormat="of" derivedContent="RFC8025">"IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Paging Dispatch"</xref>.
</t>
<table anchor="difig" align="center" pn="table-1">
<name slugifiedName="name-additional-dispatch-value-b">Additional Dispatch Value Bit Patterns</name>
<thead>
<tr>
<td align="left" colspan="1" rowspan="1">Bit Pattern</td>
<td align="left" colspan="1" rowspan="1">Page</td>
<td align="left" colspan="1" rowspan="1">Header Type</td>
<td align="left" colspan="1" rowspan="1">Reference</td>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">11 10100x</td>
<td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">RFRAG - Recoverable
Fragment</td>
<td align="left" colspan="1" rowspan="1">RFC 8931</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">11 10100x</td>
<td align="left" colspan="1" rowspan="1">1-14</td>
<td align="left" colspan="1" rowspan="1">Unassigned</td>
<td align="left" colspan="1" rowspan="1"/>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">11 10100x</td>
<td align="left" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">Reserved for Experimental Use</td>
<td align="left" colspan="1" rowspan="1">RFC 8025</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">11 10101x</td>
<td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">RFRAG-ACK - RFRAG
Acknowledgment</td>
<td align="left" colspan="1" rowspan="1">RFC 8931</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">11 10101x</td>
<td align="left" colspan="1" rowspan="1">1-14</td>
<td align="left" colspan="1" rowspan="1">Unassigned</td>
<td align="left" colspan="1" rowspan="1"/>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">11 10101x</td>
<td align="left" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">Reserved for Experimental Use</td>
<td align="left" colspan="1" rowspan="1">RFC 8025</td>
</tr>
</tbody>
</table>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-lwig-6lowpan-virtual-reassembly" to="LWIG-FRAG"/>
<displayreference target="I-D.ietf-6tisch-architecture" to="6TiSCH"/>
<references pn="section-10">
<name slugifiedName="name-references">References</name>
<references pn="section-10.1">
<name slugifiedName="name-normative-references">Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC4919" target="https://www.rfc-editor.org/info/rfc4919" quoteTitle="true" derivedAnchor="RFC4919">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals</title>
<author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Montenegro" fullname="G. Montenegro">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Schumacher" fullname="C. Schumacher">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="August"/>
<abstract>
<t indent="0">This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4919"/>
<seriesInfo name="DOI" value="10.17487/RFC4919"/>
</reference>
<reference anchor="RFC4944" target="https://www.rfc-editor.org/info/rfc4944" quoteTitle="true" derivedAnchor="RFC4944">
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author initials="G." surname="Montenegro" fullname="G. Montenegro">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Culler" fullname="D. Culler">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="September"/>
<abstract>
<t indent="0">This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4944"/>
<seriesInfo name="DOI" value="10.17487/RFC4944"/>
</reference>
<reference anchor="RFC6282" target="https://www.rfc-editor.org/info/rfc6282" quoteTitle="true" derivedAnchor="RFC6282">
<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title>
<author initials="J." surname="Hui" fullname="J. Hui" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="September"/>
<abstract>
<t indent="0">This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6282"/>
<seriesInfo name="DOI" value="10.17487/RFC6282"/>
</reference>
<reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6298" quoteTitle="true" derivedAnchor="RFC6298">
<front>
<title>Computing TCP's Retransmission Timer</title>
<author initials="V." surname="Paxson" fullname="V. Paxson">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Chu" fullname="J. Chu">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Sargent" fullname="M. Sargent">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract>
<t indent="0">This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6298"/>
<seriesInfo name="DOI" value="10.17487/RFC6298"/>
</reference>
<reference anchor="RFC6606" target="https://www.rfc-editor.org/info/rfc6606" quoteTitle="true" derivedAnchor="RFC6606">
<front>
<title>Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing</title>
<author initials="E." surname="Kim" fullname="E. Kim">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Kaspar" fullname="D. Kaspar">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Gomez" fullname="C. Gomez">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="May"/>
<abstract>
<t indent="0">IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.</t>
<t indent="0">This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6606"/>
<seriesInfo name="DOI" value="10.17487/RFC6606"/>
</reference>
<reference anchor="RFC8025" target="https://www.rfc-editor.org/info/rfc8025" quoteTitle="true" derivedAnchor="RFC8025">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Cragie" fullname="R. Cragie">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="November"/>
<abstract>
<t indent="0">This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8025"/>
<seriesInfo name="DOI" value="10.17487/RFC8025"/>
</reference>
<reference anchor="RFC8138" target="https://www.rfc-editor.org/info/rfc8138" quoteTitle="true" derivedAnchor="RFC8138">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Toutain" fullname="L. Toutain">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Cragie" fullname="R. Cragie">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="April"/>
<abstract>
<t indent="0">This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8138"/>
<seriesInfo name="DOI" value="10.17487/RFC8138"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200" quoteTitle="true" derivedAnchor="RFC8200">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="July"/>
<abstract>
<t indent="0">This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC8930" target="https://www.rfc-editor.org/info/rfc8930" quoteTitle="true" derivedAnchor="RFC8930">
<front>
<title>On Forwarding 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network) Fragments over a Multi-Hop IPv6 Network</title>
<author initials="T" surname="Watteyne" fullname="Thomas Watteyne" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Bormann" fullname="Carsten Bormann">
<organization showOnFrontPage="true"/>
</author>
<date month="November" year="2020"/>
</front>
<seriesInfo name="RFC" value="8930"/>
<seriesInfo name="DOI" value="10.17487/RFC8930"/>
</reference>
</references>
<references pn="section-10.2">
<name slugifiedName="name-informative-references">Informative References</name>
<reference anchor="I-D.ietf-6tisch-architecture" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-6tisch-architecture-29" derivedAnchor="6TiSCH">
<front>
<title>An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4</title>
<author fullname="Pascal Thubert">
<organization showOnFrontPage="true">Cisco Systems, Inc</organization>
</author>
<date month="August" day="27" year="2020"/>
<abstract>
<t indent="0"> This document describes a network architecture that provides low-
latency, low-jitter and high-reliability packet delivery. It
combines a high-speed powered backbone and subnetworks using IEEE
802.15.4 time-slotted channel hopping (TSCH) to meet the requirements
of LowPower wireless deterministic applications.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-architecture-29"/>
<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-6tisch-architecture-29.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="IEEE.802.15.4" target="http://ieeexplore.ieee.org/document/7460875/" quoteTitle="true" derivedAnchor="IEEE.802.15.4">
<front>
<title>IEEE Standard for Low-Rate Wireless Networks</title>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date month="April" year="2016"/>
</front>
<seriesInfo name="IEEE" value="Standard 802.15.4-2015"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
</reference>
<reference anchor="Kent" target="http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf" quoteTitle="true" derivedAnchor="Kent">
<front>
<title>Fragmentation Considered Harmful</title>
<author fullname="Kent" initials="C." surname="Kent">
<organization showOnFrontPage="true"/>
</author>
<author fullname="Mogul" initials="J." surname="Mogul">
<organization showOnFrontPage="true"/>
</author>
<date month="August" year="1987"/>
</front>
<seriesInfo name="DOI" value="10.1145/55483.55524"/>
<refcontent>SIGCOMM '87: Proceedings of the ACM workshop on Frontiers in computer communications technology, pp. 390-401</refcontent>
</reference>
<reference anchor="I-D.ietf-lwig-6lowpan-virtual-reassembly" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reassembly-02" derivedAnchor="LWIG-FRAG">
<front>
<title>Virtual reassembly buffers in 6LoWPAN</title>
<author fullname="Carsten Bormann">
<organization showOnFrontPage="true">Universitaet Bremen TZI</organization>
</author>
<author fullname="Thomas Watteyne">
<organization showOnFrontPage="true">Analog Devices</organization>
</author>
<date month="March" day="9" year="2020"/>
<abstract>
<t indent="0"> When employing adaptation layer fragmentation in 6LoWPAN, it may be
beneficial for a forwarder not to have to reassemble each packet in
its entirety before forwarding it.
This has been always possible with the original fragmentation design
of RFC 4944. Apart from a brief mention of the way to do this in
Section 2.5.2 of the 6LoWPAN book, this has not been extensively
described in the literature. The present document attempts to fill
that gap.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lwig-6lowpan-virtual-reassembly-02"/>
<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-lwig-6lowpan-virtual-reassembly-02.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC2914" target="https://www.rfc-editor.org/info/rfc2914" quoteTitle="true" derivedAnchor="RFC2914">
<front>
<title>Congestion Control Principles</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization showOnFrontPage="true"/>
</author>
<date year="2000" month="September"/>
<abstract>
<t indent="0">The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="41"/>
<seriesInfo name="RFC" value="2914"/>
<seriesInfo name="DOI" value="10.17487/RFC2914"/>
</reference>
<reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031" quoteTitle="true" derivedAnchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Viswanathan" fullname="A. Viswanathan">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Callon" fullname="R. Callon">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="January"/>
<abstract>
<t indent="0">This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031"/>
<seriesInfo name="DOI" value="10.17487/RFC3031"/>
</reference>
<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3168" quoteTitle="true" derivedAnchor="RFC3168">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="September"/>
<abstract>
<t indent="0">This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="RFC4963" target="https://www.rfc-editor.org/info/rfc4963" quoteTitle="true" derivedAnchor="RFC4963">
<front>
<title>IPv4 Reassembly Errors at High Data Rates</title>
<author initials="J." surname="Heffner" fullname="J. Heffner">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Mathis" fullname="M. Mathis">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Chandler" fullname="B. Chandler">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="July"/>
<abstract>
<t indent="0">IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4963"/>
<seriesInfo name="DOI" value="10.17487/RFC4963"/>
</reference>
<reference anchor="RFC5033" target="https://www.rfc-editor.org/info/rfc5033" quoteTitle="true" derivedAnchor="RFC5033">
<front>
<title>Specifying New Congestion Control Algorithms</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="August"/>
<abstract>
<t indent="0">The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="133"/>
<seriesInfo name="RFC" value="5033"/>
<seriesInfo name="DOI" value="10.17487/RFC5033"/>
</reference>
<reference anchor="RFC5681" target="https://www.rfc-editor.org/info/rfc5681" quoteTitle="true" derivedAnchor="RFC5681">
<front>
<title>TCP Congestion Control</title>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Paxson" fullname="V. Paxson">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Blanton" fullname="E. Blanton">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="September"/>
<abstract>
<t indent="0">This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5681"/>
<seriesInfo name="DOI" value="10.17487/RFC5681"/>
</reference>
<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6550" quoteTitle="true" derivedAnchor="RFC6550">
<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
<author initials="T." surname="Winter" fullname="T. Winter" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Brandt" fullname="A. Brandt">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Kelsey" fullname="R. Kelsey">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Levis" fullname="P. Levis">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Struik" fullname="R. Struik">
<organization showOnFrontPage="true"/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Alexander" fullname="R. Alexander">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6550"/>
<seriesInfo name="DOI" value="10.17487/RFC6550"/>
</reference>
<reference anchor="RFC6552" target="https://www.rfc-editor.org/info/rfc6552" quoteTitle="true" derivedAnchor="RFC6552">
<front>
<title>Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.</t>
<t indent="0">This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6552"/>
<seriesInfo name="DOI" value="10.17487/RFC6552"/>
</reference>
<reference anchor="RFC6554" target="https://www.rfc-editor.org/info/rfc6554" quoteTitle="true" derivedAnchor="RFC6554">
<front>
<title>An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization showOnFrontPage="true"/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Culler" fullname="D. Culler">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Manral" fullname="V. Manral">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6554"/>
<seriesInfo name="DOI" value="10.17487/RFC6554"/>
</reference>
<reference anchor="RFC7554" target="https://www.rfc-editor.org/info/rfc7554" quoteTitle="true" derivedAnchor="RFC7554">
<front>
<title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement</title>
<author initials="T." surname="Watteyne" fullname="T. Watteyne" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Palattella" fullname="M. Palattella">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Grieco" fullname="L. Grieco">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="May"/>
<abstract>
<t indent="0">This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7554"/>
<seriesInfo name="DOI" value="10.17487/RFC7554"/>
</reference>
<reference anchor="RFC7567" target="https://www.rfc-editor.org/info/rfc7567" quoteTitle="true" derivedAnchor="RFC7567">
<front>
<title>IETF Recommendations Regarding Active Queue Management</title>
<author initials="F." surname="Baker" fullname="F. Baker" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="July"/>
<abstract>
<t indent="0">This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.</t>
<t indent="0">Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="197"/>
<seriesInfo name="RFC" value="7567"/>
<seriesInfo name="DOI" value="10.17487/RFC7567"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085" quoteTitle="true" derivedAnchor="RFC8085">
<front>
<title>UDP Usage Guidelines</title>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Shepherd" fullname="G. Shepherd">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t indent="0">The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
<t indent="0">Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.</t>
<t indent="0">Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</t>
<t indent="0">This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8087" target="https://www.rfc-editor.org/info/rfc8087" quoteTitle="true" derivedAnchor="RFC8087">
<front>
<title>The Benefits of Using Explicit Congestion Notification (ECN)</title>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Welzl" fullname="M. Welzl">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t indent="0">The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8087"/>
<seriesInfo name="DOI" value="10.17487/RFC8087"/>
</reference>
<reference anchor="RFC8201" target="https://www.rfc-editor.org/info/rfc8201" quoteTitle="true" derivedAnchor="RFC8201">
<front>
<title>Path MTU Discovery for IP version 6</title>
<author initials="J." surname="McCann" fullname="J. McCann">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="July"/>
<abstract>
<t indent="0">This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981.</t>
</abstract>
</front>
<seriesInfo name="STD" value="87"/>
<seriesInfo name="RFC" value="8201"/>
<seriesInfo name="DOI" value="10.17487/RFC8201"/>
</reference>
<reference anchor="RFC8900" target="https://www.rfc-editor.org/info/rfc8900" quoteTitle="true" derivedAnchor="RFC8900">
<front>
<title>IP Fragmentation Considered Fragile</title>
<author initials="R." surname="Bonica" fullname="R. Bonica">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Huston" fullname="G. Huston">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Troan" fullname="O. Troan">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Gont" fullname="F. Gont">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="September"/>
<abstract>
<t indent="0">This document describes IP fragmentation and explains how it introduces fragility to Internet communication.</t>
<t indent="0">This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="230"/>
<seriesInfo name="RFC" value="8900"/>
<seriesInfo name="DOI" value="10.17487/RFC8900"/>
</reference>
</references>
</references>
<section anchor="rationale" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
<name slugifiedName="name-rationale">Rationale</name>
<t indent="0" pn="section-appendix.a-1">
There are a number of uses for large packets in Wireless Sensor Networks. Such usages
may not be the most typical or represent the largest amount of traffic over the LLN;
however, the associated functionality can be critical enough to justify extra care for
ensuring effective transport of large packets across the LLN.
</t>
<t indent="0" pn="section-appendix.a-2">
The list of those usages includes:
</t>
<t indent="0" pn="section-appendix.a-3">Towards the LLN node:</t>
<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-appendix.a-4">
<li pn="section-appendix.a-4.1">
<dl indent="3" newline="false" spacing="normal" pn="section-appendix.a-4.1.1">
<dt pn="section-appendix.a-4.1.1.1">Firmware update:</dt>
<dd pn="section-appendix.a-4.1.1.2">
For example, a new version of the LLN node software is downloaded from a system
manager over unicast or multicast services.
Such a reflashing operation typically involves updating a large number of similar
LLN nodes over a relatively short period of time.
</dd>
<dt pn="section-appendix.a-4.1.1.3">Packages of commands:</dt>
<dd pn="section-appendix.a-4.1.1.4">
A number of commands or a full configuration can be packaged as a single message
to ensure consistency and enable atomic execution or complete rollback.
Until such commands are fully received and interpreted, the intended operation will not take effect.
</dd>
</dl>
</li>
</ul>
<t indent="0" pn="section-appendix.a-5">From the LLN node:</t>
<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-appendix.a-6">
<li pn="section-appendix.a-6.1">
<dl indent="3" newline="false" spacing="normal" pn="section-appendix.a-6.1.1">
<dt pn="section-appendix.a-6.1.1.1">Waveform captures:</dt>
<dd pn="section-appendix.a-6.1.1.2">
A number of consecutive samples are measured at a high rate for a short time and then are transferred
from a sensor to a gateway or an edge server as a single large report.
</dd>
<dt pn="section-appendix.a-6.1.1.3">Data logs:</dt>
<dd pn="section-appendix.a-6.1.1.4">
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.
</dd>
<dt pn="section-appendix.a-6.1.1.5">Large data packets:</dt>
<dd pn="section-appendix.a-6.1.1.6">
Rich data types might require more than one fragment.
</dd>
</dl>
</li>
</ul>
<t indent="0" pn="section-appendix.a-7">
Uncontrolled firmware download or waveform upload can easily result in a massive
increase of the traffic and saturate the network.
</t>
<t indent="0" pn="section-appendix.a-8">
When a fragment is lost in transmission, the lack of recovery in
the original fragmentation system of RFC 4944 implies that all
fragments would need to be resent, further contributing
to the congestion that caused the initial loss
and potentially leading to congestion collapse.
</t>
<t indent="0" pn="section-appendix.a-9">
This saturation may lead to excessive radio interference or random early discard
(leaky bucket) in relaying nodes. Additional queuing and memory congestion may
result while waiting for a low-power next hop to emerge from its sleep state.
</t>
<t indent="0" pn="section-appendix.a-10">
Considering that RFC 4944
defines an MTU as 1280 bytes, and that in most incarnations
(except 802.15.4g) an IEEE Std 802.15.4 frame can limit the link-layer payload
to as few as 74 bytes, a packet might be fragmented into at
least 18 fragments at the 6LoWPAN shim layer. Taking into
account the worst-case header overhead for 6LoWPAN
Fragmentation and Mesh Addressing headers will increase
the number of required fragments to around 32. This level
of fragmentation is much higher than that traditionally
experienced over the Internet with IPv4 fragments. At the
same time, the use of radios increases the probability of
transmission loss, and mesh-under techniques compound that
risk over multiple hops.
</t>
<t indent="0" pn="section-appendix.a-11">
Mechanisms such as TCP or application-layer segmentation
could be used to support end-to-end reliable transport. One
option to support bulk data transfer over a frame-size-constrained
LLN is to set the Maximum Segment Size to fit within the link
maximum frame size. However, doing so can add significant header
overhead to each 802.15.4 frame and cause extraneous acknowledgments
across the LLN compared to the method in this specification.
</t>
</section>
<section anchor="req" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
<name slugifiedName="name-requirements">Requirements</name>
<t indent="0" pn="section-appendix.b-1">
For one-hop communications, a number of LLN
link layers propose a local acknowledgment mechanism that is enough to
detect and recover the loss of fragments. In a multi-hop environment, an
end-to-end fragment recovery mechanism might be a good complement to a
hop-by-hop Medium Access Control (MAC) recovery.
This document introduces a simple protocol to recover individual fragments
between 6LFF endpoints that may be multiple hops away.
</t>
<t indent="0" pn="section-appendix.b-2">
The method addresses the following requirements of an LLN:
</t>
<dl indent="3" newline="false" spacing="normal" pn="section-appendix.b-3">
<dt pn="section-appendix.b-3.1">Number of fragments:</dt>
<dd pn="section-appendix.b-3.2">The recovery mechanism must support highly fragmented packets, with a maximum of 32 fragments per packet.
</dd>
<dt pn="section-appendix.b-3.3">Minimum acknowledgment overhead:</dt>
<dd pn="section-appendix.b-3.4"> Because the radio is half duplex, and because of silent time spent in the
various medium access mechanisms, an acknowledgment consumes roughly as many resources as a data fragment.
</dd>
<dt pn="section-appendix.b-3.5"/>
<dd pn="section-appendix.b-3.6">The new end-to-end fragment recovery mechanism should be able to acknowledge multiple fragments in a single message and
not require an acknowledgment at all if fragments are already protected at a lower layer.
</dd>
<dt pn="section-appendix.b-3.7">Controlled latency:</dt>
<dd pn="section-appendix.b-3.8">The recovery mechanism must succeed or give up within the time boundary imposed by the recovery process
of the upper-layer protocols.
</dd>
<dt pn="section-appendix.b-3.9">Optional congestion control:</dt>
<dd pn="section-appendix.b-3.10"> The aggregation of multiple concurrent flows may lead to the saturation of the radio network and congestion collapse.
</dd>
<dt pn="section-appendix.b-3.11"/>
<dd pn="section-appendix.b-3.12">The recovery mechanism should provide means for controlling the number of fragments in transit over the LLN.
</dd>
</dl>
</section>
<section anchor="onECN" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.c">
<name slugifiedName="name-considerations-on-congestio">Considerations on Congestion Control</name>
<t indent="0" pn="section-appendix.c-1">Considering that a multi-hop LLN can be a very sensitive environment
due to the limited queuing capabilities of a
large population of its nodes, this document recommends a simple and
conservative approach to congestion control, based on TCP congestion avoidance.
</t>
<t indent="0" pn="section-appendix.c-2">Congestion on the forward path is assumed in case of packet loss, and
packet loss is assumed upon timeout. This document allows controlling the number
of outstanding fragments that have been transmitted, but for which an
acknowledgment was not yet received, and that are still covered by the ARQ timer.
</t>
<t indent="0" pn="section-appendix.c-3">Congestion on the forward path can also be indicated by an ECN mechanism.
Though whether and how ECN <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/> is carried out over the
LoWPAN is out of scope, this document provides a way for the destination
endpoint to echo an ECN indication back to the fragmenting endpoint in an
acknowledgment message as represented in
<xref target="ackfig" format="default" sectionFormat="of" derivedContent="Figure 4"/> in <xref target="ackfrag" format="default" sectionFormat="of" derivedContent="Section 5.2"/>.
</t>
<t indent="0" pn="section-appendix.c-4">
While the support of echoing the ECN at the reassembling endpoint is mandatory, this
specification only provides a minimalistic behavior on the fragmenting endpoint.
If an "E" flag is received, the window <bcp14>SHOULD</bcp14> be reduced at least by 1 and at max to 1. Halving the window for each "E" flag received could be a good compromise, but it needs further experimentation. A very simple implementation may just reset the window to 1, so the fragments are sent and acknowledged one by one.
</t>
<t indent="0" pn="section-appendix.c-5">
Note that any action that has been performed upon detection of congestion
only applies for the transmission of one datagram, and the next datagram
starts with the configured Window_Size again.
</t>
<t indent="0" pn="section-appendix.c-6">
The exact use of the Acknowledgment Request flag and of the window are left to implementation. An optimistic implementation could send all the fragments up to Window_Size, setting the Acknowledgment Request "X" flag only on the last fragment; wait for the bitmap, which means a gap of half a round-trip time; and resend the losses.
A pessimistic implementation could set the "X" flag on the first fragment to check that the path works and open the window only upon receiving the RFRAG-ACK. It could then set an "X" flag again on the second fragment and use the window as a credit to send up to Window_Size before it is blocked. In that case, if the RFRAG-ACK comes back before the window starves, the gating factor is the inter-frame gap. If the RFRAG-ACK does not arrive in time, the Window_Size is the gating factor, and the
transmission of the datagram is delayed.
</t>
<t indent="0" pn="section-appendix.c-7">
It must be noted that even though the inter-frame gap can be used as a flow
control or a congestion control measure, it also plays a critical role in
wireless collision avoidance.
In particular, when a mesh operates on the same channel over multiple hops,
the forwarding of a fragment over a certain hop may collide with the
forwarding of the next fragment that is following over a previous hop but that is in the same interference domain. To prevent this, the fragmenting endpoint is required to pace individual fragments within a transmit window with an inter-frame gap. This is needed to ensure that a given fragment is sent only when the previous fragment has had a chance to progress beyond the interference domain of this hop.
In the case of
6TiSCH <xref target="I-D.ietf-6tisch-architecture" format="default" sectionFormat="of" derivedContent="6TiSCH"/>, which operates
over the
Time-Slotted Channel Hopping (TSCH) mode
of operation of IEEE 802.15.4 <xref target="RFC7554" format="default" sectionFormat="of" derivedContent="RFC7554"/>, a fragment is forwarded over a different
channel at a different time, and it makes full sense to transmit the next fragment as
soon as the previous fragment has had its chance to be forwarded at the next
hop.
</t>
<t indent="0" pn="section-appendix.c-8">
Depending on the setting of the Window_Size and the inter-frame gap,
how the window is used, and the number of hops, the Window_Size may or
may not become the gating factor that blocks the transmission.
If the sender uses the Window_Size as a credit:
</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.c-9">
<li pn="section-appendix.c-9.1">
a conservative Window_Size of, say, 3 will be the gating factor that limits the transmission rate of the sender -- and causes transmission gaps longer than the inter-frame gap -- as soon as the
number of hops exceeds 3 in a TSCH network and 5-9 in a single frequency mesh.
The more hops the more the starving window will add to latency of the transmission.
</li>
<li pn="section-appendix.c-9.2">
The recommendation to align the Window-Size to the round-trip time divided by
the time per fragment aligns the Window-Size to the time it takes to get the
RFAG_ACK before the window starves. A Window-Size that is higher than that increases
the chances of a congestion but does not improve the forward throughput. Considering that the RFRAG-ACK takes the same path as the fragment with the assumption that it travels at roughly the same speed, an inter-frame gap that separates fragments by 2
hops leads to a Window_Size that is roughly the number of hops.
</li>
<li pn="section-appendix.c-9.3">
Setting the Window-Size to 32 minimizes the cost of the acknowledgment
in a constrained network and frees bandwidth for the fragments in a half-duplex
network. Using it increases the risk of congestion if a bottleneck forms, but it
optimizes the use of resources under normal conditions. When it is used, the
only protection for the network is the inter-frame gap, which must be chosen
wisely to prevent the formation of a bottleneck.
</li>
</ul>
<t indent="0" pn="section-appendix.c-10">
From the standpoint of a source 6LoWPAN endpoint, an outstanding
fragment is a fragment that was
sent but for which no explicit acknowledgment was yet received.
This means that the fragment might be on the path or received but not yet
acknowledged, or the acknowledgment might be on the path back. It is also
possible that either the fragment or the acknowledgment was lost on the
way.
</t>
<t indent="0" pn="section-appendix.c-11">From the fragmenting endpoint standpoint,
all outstanding fragments might still be in the network and contribute to its congestion.
There is an assumption, though, that after a certain amount of time, a frame is either received
or lost, so it is not causing congestion anymore. This amount of time can be estimated based on the round-trip
time between the 6LoWPAN endpoints. For the lack of a more adapted technique, the method detailed in <xref target="RFC6298" format="default" sectionFormat="of" derivedContent="RFC6298">"Computing TCP's Retransmission Timer"</xref> may be used for that computation.
</t>
<t indent="0" pn="section-appendix.c-12">
This specification provides the necessary tools for the fragmenting endpoint
to take congestion control actions and protect the network, but it leaves the
implementation free to select the action to be taken. The intention is to
use it to build experience and specify more precisely the congestion control actions
in one or more future specifications. <xref target="RFC2914" format="default" sectionFormat="of" derivedContent="RFC2914">"Congestion Control Principles"</xref> and <xref target="RFC5033" format="default" sectionFormat="of" derivedContent="RFC5033">"Specifying New Congestion Control Algorithms"</xref> provide indications and wisdom that should help through this process.
</t>
<t indent="0" pn="section-appendix.c-13">
<xref target="RFC7567" format="default" sectionFormat="of" derivedContent="RFC7567"/> and <xref target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/> provide deeper information on why congestion control is needed and how TCP handles it. Basically, the goal here is to
manage the number of fragments present in the network; this is achieved by reducing the number of outstanding fragments over a congested path by throttling the sources.
</t>
</section>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.d">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.d-1">The author wishes to thank <contact fullname="Michel Veillette"/>, <contact fullname="Dario Tedeschi"/>, <contact fullname="Laurent Toutain"/>,
<contact fullname="Carles Gomez Montenegro"/>, <contact fullname="Thomas Watteyne"/>, and <contact fullname="Michael Richardson"/> for their in-depth
reviews and comments.
Also, many thanks to <contact fullname="Roman Danyliw"/>, <contact fullname="Peter Yee"/>, <contact fullname="Colin Perkins"/>, <contact fullname="Tirumaleswar Reddy.K"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Magnus Westerlund"/>, <contact fullname="Erik Nordmark"/>, and especially <contact fullname="Benjamin Kaduk"/> and <contact fullname="Mirja Kühlewind"/> for
their careful reviews and help during the IETF Last Call and IESG review process.
Thanks to <contact fullname="Jonathan Hui"/>, <contact fullname="Jay Werb"/>, <contact fullname="Christos Polyzois"/>, <contact fullname="Soumitri Kolavennu"/>,
<contact fullname="Pat Kinney"/>, <contact fullname="Margaret Wasserman"/>, <contact fullname="Richard Kelsey"/>, <contact fullname="Carsten Bormann"/>, and
<contact fullname="Harry Courtice"/> for their various contributions in the long process that lead to this document.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e">
<name slugifiedName="name-authors-address">Author's Address</name>
<author fullname="Pascal Thubert" initials="P." role="editor" surname="Thubert">
<organization abbrev="Cisco Systems" showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address>
<postal>
<extaddr>Building D</extaddr>
<street>45 Allee des Ormes - BP1200</street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>France</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
</section>
</back>
</rfc>