rfc8931xml2.original.xml   rfc8931.xml 
<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
nsus="true" docName="draft-ietf-6lo-fragment-recovery-21" indexInclude="true" ip
r="trust200902" number="8931" prepTime="2020-11-16T16:01:38" scripts="Common,Lat
in" 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 N
etwork (6LoWPAN) Selective Fragment Recovery</title>
<seriesInfo name="RFC" value="8931" stream="IETF"/>
<author fullname="Pascal Thubert" initials="P." role="editor" surname="Thube
rt">
<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="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" 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" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="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" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-terminology">Terminology</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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-re
quirements-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-ba
ckground">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 derived
Content="" format="title" sectionFormat="of" target="name-other-terms">Other Ter
ms</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" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-updating-rfc-4944">Updating RFC 49
44</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-extending-rfc-8930">Extending RFC
8930</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-slack-in-the-first-fra
gment">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 derived
Content="" format="title" sectionFormat="of" target="name-gap-between-frames">Ga
p 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 derived
Content="" format="title" sectionFormat="of" target="name-congestion-control">Co
ngestion 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 derived
Content="" format="title" sectionFormat="of" target="name-modifying-the-first-fr
agmen">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" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-new-dispatch-types-and-head">New D
ispatch Types and Headers</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-recoverable-fragment-d
ispat">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 derived
Content="" format="title" sectionFormat="of" target="name-rfrag-acknowledgment-d
ispat">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" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-fragment-recovery">Fragment Recove
ry</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-forwarding-fragments">
Forwarding Fragments</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derived
Content="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 derived
Content="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 derived
Content="" format="title" sectionFormat="of" target="name-receiving-rfrag-acknow
ledgm">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 derived
Content="" format="title" sectionFormat="of" target="name-aborting-the-transmiss
ion-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 derived
Content="" format="title" sectionFormat="of" target="name-applying-recoverable-f
ragme">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" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-management-considerations">Managem
ent Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-protocol-parameters">P
rotocol 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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="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="sectio
n-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 deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">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 deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">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="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-rationale">Rati
onale</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-requirements">R
equirements</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Append
ix 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="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
ss</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
ude" 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 byte
s
to a few tens of bytes) at a time. Given that an
<xref target="IEEE.802.15.4" format="default" sectionFormat="of" derived
Content="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" derivedCon
tent="RFC4944">"Transmission of IPv6 Packets over IEEE 802.15.4
Networks"</xref> defines the original IPv6 over Low-Power Wireless Perso
nal 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="o
f" derivedContent="RFC8200"/> packet across a route-over mesh
requires the reassembly of the packet at each hop. <xref target="I-D.iet
f-6tisch-architecture" format="default" sectionFormat="of" derivedContent="6TiSC
H">"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" derivedConten
t="RFC8930">
"On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network"</xref> sp
ecifies the generic behavior
that all 6LFF techniques including this specification follow, and it pre
sents
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="def
ault" 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" sectionFor
mat="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" derivedConten
t="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 un
til
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 sourc
e 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" derivedConten
t="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, typicall
y,
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" d
erivedContent="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>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT 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="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="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" sectionFor
mat="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>; an
d
<xref target="RFC6606" format="default" sectionFormat="of" derivedConten
t="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 o
r 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" derive
dContent="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="RFC820
1" format="default" sectionFormat="of" derivedContent="RFC8201">"Path
MTU Discovery for IP version 6"</xref> protocol that limits fragmentatio
n over the
Internet.
Specifically, in the case of UDP, valuable additional information
can be
found in <xref target="RFC8085" format="default" sectionFormat="of" deri
vedContent="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 pac
ket'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" derivedConten
t="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 b
y 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 ta
ken 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 fragmentatio
n mechanism that is
specified in <xref target="RFC4944" format="default" sectionFormat="of" deri
vedContent="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" derivedConten
t="Section 5"/>.
</t>
<t indent="0" pn="section-3-2">
<xref target="RFC8138" format="default" sectionFormat="of" derivedContent="R
FC8138"/> 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="def
ault" 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="de
fault" 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" deri
vedContent="RFC6282"/>, for the
fragmentation mechanism described in <xref target="RFC4944" sectionFormat="o
f" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc494
4#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 6
LFF technique defined in
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="R
FC8930"/> 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 Firs
t Fragment</name>
<t indent="0" pn="section-4.1-1">
<xref target="RFC8930" format="default" sectionFormat="of" derivedContent="R
FC8930"/> 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 in
coming 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 t
he path, and
the first fragment that contains a 6LoWPAN compressed header <bcp14>MUST</bc
p14> 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 en
dpoint, 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="R
FC6282"/>. In that case, it <bcp14>MUST</bcp14> leave slack in the first fragmen
t as the if MTU on the first hop was 8 bytes less, so the next hop can expand th
e 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="R
FC8930"/> 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 co
ntrol
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</bcp
14> 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" for
mat="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 th
e 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 congesti
on 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 Fir
st 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 fr
agment, 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 fi
eld,
to reflect that difference.
</t>
<t indent="0" pn="section-4.4-2">
The intermediate node <bcp14>MUST</bcp14> also save the difference of Datagr
am_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 So
urce Routing
Header 6LoWPAN Routing Header (SRH-6LoRH)
<xref target="RFC8138" format="default" sectionFormat="of" derivedContent="R
FC8138"/> 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" derived
Content="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" secti
onFormat="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 i
n
"Fragmentation Type and Header" (see <xref target="RFC4944" sectionFormat="o
f" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc494
4#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="R
FC8930"/>.
</t>
<t indent="0" pn="section-5-4">This specification extends <xref target="RF
C4944" 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="R
FC8025"/>, 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 Fragm
ent 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" for
mat="default" sectionFormat="of" derivedContent="Figure 1"/>.
It is the same for all fragments even though the Fragment_Offset is overload
ed.
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 exam
ple 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" derivedCont
ent="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="secti
on-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 en
dpoint
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" sect
ionFormat="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="secti
on-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" der
ivedContent="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" derive
dContent="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="defa
ult" 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 remainde
r 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 Acknowledgm
ent Dispatch Type and Header</name>
<t indent="0" pn="section-5.2-1">This specification also defines a 4-byt
e 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 Acknowled
gment 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="defau
lt" sectionFormat="of" derivedContent="Figure 3"/> shows an example RFRAG Acknow
ledgment 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 A
cknowledgment 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 incl
uded 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 Acknowle
dgment 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 setti
ng 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 per
form
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 conf
igurable and
may vary in case of ECN notification. When the endpoint that
reassembles the packets at the 6LoWPAN level receives a fragment with the Ac
k-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 purpos
e of congestion control.
</t>
<t indent="0" pn="section-6-5">
This ARQ process <bcp14>MUST</bcp14> be protected by a Retransmission Timeou
t (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="Sec
tion 7.1"/>) with an exponential backoff.
Upon exhaustion of the retries, the fragmenting endpoint may either abort th
e
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 endpoi
nt
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" derive
dContent="Appendix C"/>).
The reassembling endpoint of a fragment with the "E" (ECN) flag set <bcp14>M
UST</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 co
ntrolled number
of fragments and flags to the last
fragment of a window with an RFRAG Acknowledgment Request. The reassembli
ng 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 <bc
p14>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 reassemb
ling 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, acknowledgin
g
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 en
abled 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 recommendation
s in
<xref target="RFC8085" format="default" sectionFormat="of" derivedContent="R
FC8085"/>, 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 mec
hanism
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 en
dpoint <bcp14>SHOULD</bcp14> insert a delay between the frames (e.g., carrying f
ragments) that are sent to the same next hop. The delay <bcp14>SHOULD</bcp14> co
ver multiple transmissions so as to let a frame progress a few hops and avoid hi
dden 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="R
FC6554"/>, 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</na
me>
<t indent="0" pn="section-6.1-1">
This specification inherits from <xref target="RFC8930" format="default" sec
tionFormat="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 a
re 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 s
maller
Fragment_Size, in which case it <bcp14>MUST</bcp14> abort the original attem
pt and use a
new Datagram_Tag for the new attempt.
</t>
<section anchor="ff" numbered="true" removeInRFC="false" toc="include" p
n="section-6.1.1">
<name slugifiedName="name-receiving-the-first-fragmen">Receiving the F
irst 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 intermedi
ate router
creates a VRB and the associated
LSP state indexed by the incoming interface, the previous-hop link-layer add
ress,
and the Datagram_Tag and forwards the fragment along the IPv6 route that mat
ches
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="R
FC8930"/>.
The LSP state enables matching the next incoming fragments of a datagram to
the abstract forwarding information of the next interface, source and next-h
op
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 interf
ace to the next hop, the link-layer address the router uses as source for that d
atagram, and the swapped Datagram_Tag. This reverse LSP state
enables matching the tuple (interface, destination link-layer address, Datag
ram_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" p
n="section-6.1.2">
<name slugifiedName="name-receiving-the-next-fragment">Receiving the N
ext 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 add
ress, 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" der
ivedContent="RFC8930"/>.
</t>
<t indent="0" pn="section-6.1.2-2">If the VRB for the tuple is not fou
nd, 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 add
resses 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_T
ag 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="R
FC8930"/> 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 i
n
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 A
cknowledgments</name>
<t indent="0" pn="section-6.2-1">Upon receipt of an RFRAG-ACK, the route
r looks up a reverse LSP indexed by the interface and destination link-layer add
ress 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" der
ivedContent="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 ro
uter <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, an
d upon timeout, the VRB and all the associated states are destroyed. Until the t
imer elapses, fragments of that datagram may still be received, e.g., if the RFR
AG-ACK was lost on the path back, and the source retried the last fragment. In t
hat
case, the router generates an RFRAG-ACK with a FULL bitmap back to the fragm
enting 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 alon
g
the path decrease, it is possible to retry a long fragment (say a Sequence o
f 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 use
d
when the reassembling endpoint gets the whole datagram regardless of which
fragments were actually used to do so. Intermediate nodes will know unambigu
ously
that the process is complete. Note that Path MTU Discovery is out of scope f
or this document.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-6.3
">
<name slugifiedName="name-aborting-the-transmission-o">Aborting the Tran
smission 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 t
he Fragment_Offset set to 0. The sender of a reset <bcp14>SHOULD</bcp14> also se
t 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 ps
eudo 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 V
RB 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 u
p 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 end
point might need to abort the processing of a fragmented packet for internal rea
sons, for instance, if it is out of reassembly buffers, already uses all 256 pos
sible values of the Datagram_Tag, or keeps receiving fragments beyond a reasonab
le 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>SHOUL
D</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 <bcp1
4>MUST</bcp14> abort the transmission of the fragmented datagram with one except
ion: 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 Recovera
ble 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 (6Ti
SCH) 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-a
rchitecture-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 Considerat
ions</name>
<t indent="0" pn="section-7-1">
This specification extends <xref target="RFC8930" format="default" sectionF
ormat="of" derivedContent="RFC8930"/> and requires the same parameters in the re
assembling endpoint and on intermediate nodes. There is no new parameter as echo
ing ECN is always on. These parameters typically include the reassembly timeout
at the reassembling endpoint, an inactivity cleanup timer on the intermediate no
des, 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 th
e 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, a
nd in optimizations that are desired (e.g., the selection of a Routing Protocol
for LLNs (RPL) <xref target="RFC6550" format="default" sectionFormat="of" derive
dContent="RFC6550"/> Objective Function <xref target="RFC6552" format="default"
sectionFormat="of" derivedContent="RFC6552"/> impacts the shape of the routing g
raph).
</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 comple
x use cases, this specification enables the fragmenting endpoint to vary the fra
gment size, the window size, and the inter-frame gap based on the number of loss
es, the observed variations of the round-trip time, and the setting of the ECN b
it.
</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 para
meters listed in this section, and an
implementation <bcp14>MUST</bcp14> abide by those parameters and, in particu
lar, 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="R
FC8085"/>.
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 necess
ary. In a large network where nodes contend for the bandwidth, a larger Fragment
_Size consumes less bandwidth but also reduces fluidity and incurs higher chance
s 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 transmis
sions.
The inter-frame gap controls the rate at which fragments are sent, the ra
tio of air time, and the amount of memory in intermediate nodes that a particula
r 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 p
ropagation 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 f
or 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 fragmenti
ng 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 a
nd 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 tran
smitter 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 define
d
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="secti
on-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="secti
on-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 acknow
ledged in each round. This is the <bcp14>RECOMMENDED</bcp14> value in a half-dup
lex 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 on
e. 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 fragment
ing endpoint should wait for an RFRAG Acknowledgment before it takes the next ac
tion. It is greater than or equal to MinARQTimeOut. It is less than or equal to
MaxARQTimeOut. See <xref target="onECN" format="default" sectionFormat="of" deri
vedContent="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 respe
ctive 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 Acknowledgmen
t 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 b
uffer at the reassembling endpoint, which is typically on the order of the minut
e.
An upper bound can be estimated to ensure that the datagram is either ful
ly 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 ful
ly 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 ful
ly 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 E
CN; 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 betw
een
MinWindowSize and MaxWindowSize, varying the Fragment_Size between MinFra
gmentSize 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 u
ntil 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 th
e number of retries
and ECN settings that can be observed from the perspective of
the fragmenting endpoint with respect to the reassembling endpoint and recip
rocally.
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 th
at
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" sect
ionFormat="of" derivedContent="RFC8930"/>.
The considerations in the Security Considerations section of <xref target="R
FC8930" 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 Acknowledg
ment
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" d
erivedContent="RFC8930"/>, secure joining and link-layer security are <bcp14>REQ
UIRED</bcp14> to protect against those attacks, as the fragmentation protocol do
es 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" secti
onFormat="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="R
FC8930"/> 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" sec
tionFormat="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" for
mat="default" sectionFormat="of" derivedContent="RFC4944"/> and
reformatted by <xref target="RFC8025" format="default" sectionFormat="of" d
erivedContent="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 Dispat
ch 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 U
se</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 U
se</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</na
me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 ca
pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
e 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/rfc4
919" 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 sta
tement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of g
oals enumerated in this document form an initial set only. This memo provides i
nformation 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/rfc4
944" quoteTitle="true" derivedAnchor="RFC4944">
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</tit
le>
<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 transmi
ssion of IPv6 packets and the method of forming IPv6 link-local addresses and st
atelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifi
cations include a simple header compression scheme using shared context and prov
isions 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/rfc6
282" quoteTitle="true" derivedAnchor="RFC6282">
<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Base
d 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 IPv
6 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 c
ompression of arbitrary prefixes. How the information is maintained in that sha
red context is out of scope. This document specifies compression of multicast ad
dresses 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/rfc6
298" 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 Tr
ansmission Control Protocol (TCP) senders are required to use to compute and man
age 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 SHO
ULD 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/rfc6
606" quoteTitle="true" derivedAnchor="RFC6606">
<front>
<title>Problem Statement and Requirements for IPv6 over Low-Power Wi
reless 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 stan
dard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specif
ication defines how mesh topologies could be obtained and maintained. Thus, it
should be considered how 6LoWPAN formation and multi-hop routing could be suppor
ted.</t>
<t indent="0">This document provides the problem statement and des
ign 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 ro
uting that can lead to further analysis and protocol design. This document is i
ntended as input to groups working on routing protocols relevant to 6LoWPANs, su
ch as the IETF ROLL WG. This document is not an Internet Standards Track specif
ication; 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/rfc8
025" 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 n
ew context switch mechanism for IPv6 over Low-Power Wireless Personal Area Netwo
rk (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Pagi
ng 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/rfc8
138" 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-Po
wer Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN ro
ute-over topologies, which initially covers the needs of Routing Protocol for Lo
w-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-I
P 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/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</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/rfc8
200" 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 Pr
otocol (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/rfc8
930" 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" r
ole="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
e="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" targe
t="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</organizat
ion>
</author>
<date month="August" day="27" year="2020"/>
<abstract>
<t indent="0"> This document describes a network architecture th
at 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-architectur
e-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/doc
ument/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/Compa
q-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-reass
embly-02" derivedAnchor="LWIG-FRAG">
<front>
<title>Virtual reassembly buffers in 6LoWPAN</title>
<author fullname="Carsten Bormann">
<organization showOnFrontPage="true">Universitaet Bremen TZI</orga
nization>
</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-virtu
al-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/rfc2
914" 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 con
gestion control. This document specifies an Internet Best Current Practices for
the Internet Community, and requests discussion and suggestions for improvement
s.</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/rfc3
031" 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 Multipr
otocol 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/rfc3
168" quoteTitle="true" derivedAnchor="RFC3168">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP<
/title>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishn
an">
<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 (Explic
it Congestion Notification) to TCP and IP, including ECN's use of two bits in th
e 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/rfc4
963" 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 us
e 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 assembl
ed IP fragments, and the TCP and UDP checksums are insufficient to prevent the r
esulting corrupted datagrams from being delivered to higher protocol layers. Th
is 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/rfc5
033" 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 ne
tworks). 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 ramific
ations to both the traffic using the new congestion control and to traffic using
the currently standardized congestion control. Therefore, the IETF must procee
d with caution when dealing with alternate congestion control proposals. The go
al of this document is to provide guidance for considering alternate congestion
control algorithms within the IETF. This document specifies an Internet Best Cu
rrent Practices for the Internet Community, and requests discussion and suggesti
ons 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/rfc5
681" 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 congest
ion control algorithms: slow start, congestion avoidance, fast retransmit, and f
ast recovery. In addition, the document specifies how TCP should begin transmis
sion after a relatively long idle period, as well as discussing various acknowle
dgment 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/rfc6
550" 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="ed
itor">
<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 n
etwork in which both the routers and their interconnect are constrained. LLN ro
uters 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 t
o 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 Rou
ting Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism
whereby multipoint-to-point traffic from devices inside the LLN towards a centr
al 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/rfc6
552" quoteTitle="true" derivedAnchor="RFC6552">
<front>
<title>Objective Function Zero for the Routing Protocol for Low-Powe
r 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 Network
s (RPL) specification defines a generic Distance Vector protocol that is adapted
to a variety of network types by the application of specific Objective Function
s (OFs). An OF states the outcome of the process used by a RPL node to select a
nd optimize routes within a RPL Instance based on the Information Objects availa
ble; an OF is not an algorithm.</t>
<t indent="0">This document specifies a basic Objective Function t
hat 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/rfc6
554" quoteTitle="true" derivedAnchor="RFC6554">
<front>
<title>An IPv6 Routing Header for Source Routes with the Routing Pro
tocol 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 const
raints 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 deli
ver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and L
ossy Networks (RPL) can be used in some deployments to store most, if not all, r
outes 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 routin
g tables on memory-constrained routers. This document specifies a new IPv6 Rout
ing header type for delivering datagrams within a RPL routing domain. [STANDARD
S-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/rfc7
554" quoteTitle="true" derivedAnchor="RFC7554">
<front>
<title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in t
he 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 sta
tement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Acces
s 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/rfc7
567" quoteTitle="true" derivedAnchor="RFC7567">
<front>
<title>IETF Recommendations Regarding Active Queue Management</title
>
<author initials="F." surname="Baker" fullname="F. Baker" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="July"/>
<abstract>
<t indent="0">This memo presents recommendations to the Internet c
ommunity concerning measures to improve and preserve Internet performance. It p
resents a strong recommendation for testing, standardization, and widespread dep
loyment of active queue management (AQM) in network devices to improve the perfo
rmance of today's Internet. It also urges a concerted effort of research, measu
rement, and ultimate deployment of AQM mechanisms to protect the Internet from f
lows that are not sufficiently responsive to congestion notification.</t>
<t indent="0">Based on 15 years of experience and new research, th
is 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/rfc8
085" 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. T
his document provides guidelines on the use of UDP for the designers of applicat
ions, tunnels, and other protocols that use UDP. Congestion control guidelines
are a primary focus, but the document also provides guidance on other topics, in
cluding message sizes, reliability, checksums, middlebox traversal, the use of E
xplicit Congestion Notification (ECN), Differentiated Services Code Points (DSCP
s), 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 collap
se and to establish some degree of fairness with concurrent traffic. They may a
lso need to implement additional mechanisms, depending on how they use UDP.</t>
<t indent="0">Some guidance is also applicable to the design of ot
her 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/rfc8
087" 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 potenti
al benefits of applications using a transport that enables Explicit Congestion N
otification (ECN). The document outlines the principal gains in terms of increa
sed throughput, reduced delay, and other benefits when ECN is used over a networ
k path that includes equipment that supports Congestion Experienced (CE) marking
. It also discusses challenges for successful deployment of ECN. It does not p
ropose new algorithms to use ECN nor does it describe the details of implementat
ion of ECN in endpoint devices (Internet hosts), routers, or other network devic
es.</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/rfc8
201" 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="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="July"/>
<abstract>
<t indent="0">This document describes Path MTU Discovery (PMTUD) f
or IP version 6. It is largely derived from RFC 1191, which describes Path MTU D
iscovery 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/rfc8
900" 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 explain
s how it introduces fragility to Internet communication.</t>
<t indent="0">This document also proposes alternatives to IP fragm
entation 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 Network
s. 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-appe
ndix.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 larg
e 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 roll
back.
Until such commands are fully received and interpreted, the in
tended 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-appe
ndix.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 r
esult 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 ra
ndom early discard
(leaky bucket) in relaying nodes. Additional queuing and memor
y congestion may
result while waiting for a low-power next hop to emerge from i
ts 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 environm
ent, 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 frag
ments
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 high
ly 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 b
ecause of silent time spent in the
various medium access mechanisms, an acknowledgment consumes roughly a
s 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 mec
hanism should be able to acknowledge multiple fragments in a single message and
not require an acknowledgment at all if fragments are already pro
tected 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 g
ive 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 m
eans 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 C
ongestion Control</name>
<t indent="0" pn="section-appendix.c-1">Considering that a multi-hop LLN c
an 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 avoi
dance.
</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 nu
mber
of outstanding fragments that have been transmitted, but for which an
acknowledgment was not yet received, and that are still covered by the ARQ ti
mer.
</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" sectio
nFormat="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" deriv
edContent="Section 5.2"/>.
</t>
<t indent="0" pn="section-appendix.c-4">
While the support of echoing the ECN at the reassembling endpoint is mandato
ry, this
specification only provides a minimalistic behavior on the fragmenting endpo
int.
If an "E" flag is received, the window <bcp14>SHOULD</bcp14> be reduced at l
east by 1 and at max to 1. Halving the window for each "E" flag received could b
e a good compromise, but it needs further experimentation. A very simple impleme
ntation may just reset the window to 1, so the fragments are sent and acknowledg
ed 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 fra
gment; wait for the bitmap, which means a gap of half a round-trip time; and res
end 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 gati
ng 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 tha
t 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" sectionFo
rmat="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" section
Format="of" derivedContent="RFC7554"/>, a fragment is forwarded over a different
channel at a different time, and it makes full sense to transmit the next fra
gment 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-app
endix.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 mes
h.
The more hops the more the starving window will add to latency of the transm
ission.
</li>
<li pn="section-appendix.c-9.2">
The recommendation to align the Window-Size to the round-trip time divided b
y
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 i
ncreases
the chances of a congestion but does not improve the forward throughput. Con
sidering that the RFRAG-ACK takes the same path as the fragment with the assumpt
ion 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-dup
lex
network. Using it increases the risk of congestion if a bottleneck forms, bu
t 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 sta
ndpoint,
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 fr
ame 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 techni
que, the method detailed in <xref target="RFC6298" format="default" sectionForma
t="of" derivedContent="RFC6298">"Computing TCP's Retransmission Timer"</xref> ma
y 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 th
e
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"</x
ref> and <xref target="RFC5033" format="default" sectionFormat="of" derivedConte
nt="RFC5033">"Specifying New Congestion Control Algorithms"</xref> provide indic
ations 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="R
FC7567"/> and <xref target="RFC5681" format="default" sectionFormat="of" derived
Content="RFC5681"/> provide deeper information on why congestion control is need
ed and how TCP handles it. Basically, the goal here is to
manage the number of fragments present in the network; this is achieved b
y reducing the number of outstanding fragments over a congested path by throttli
ng the sources.
</t>
</section>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.d">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.d-1">The author wishes to thank <contac
t fullname="Michel Veillette"/>, <contact fullname="Dario Tedeschi"/>, <contact
fullname="Laurent Toutain"/>,
<contact fullname="Carles Gomez Montenegro"/>, <contact fullname="Thomas Watteyn
e"/>, and <contact fullname="Michael Richardson"/> for their in-depth
reviews and comments.
Also, many thanks to <contact fullname="Roman Danyliw"/>, <contact fullname="Pet
er 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="Mir
ja 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"/>, <c
ontact fullname="Christos Polyzois"/>, <contact fullname="Soumitri Kolavennu"/>,
<contact fullname="Pat Kinney"/>, <contact fullname="Margaret Wasserman"/>, <con
tact 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="Thu
bert">
<organization abbrev="Cisco Systems" showOnFrontPage="true">Cisco System
s, 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>
 End of changes. 1 change blocks. 
lines changed or deleted lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/