One document matched: draft-thubert-6lowpan-simple-fragment-recovery-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2581 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2581.xml">
<!ENTITY RFC2914 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2914.xml">
<!ENTITY RFC2988 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2988.xml">
<!ENTITY RFC3168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4389.xml">
<!ENTITY RFC4429 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4429.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4919 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC4963 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4963.xml">
<!ENTITY I-D.van-beijnum-multi-mtu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.van-beijnum-multi-mtu.xml">
<!ENTITY I-D.thubert-tree-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thubert-tree-discovery.xml">
<!ENTITY I-D.ietf-tsvwg-udp-guidelines SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-udp-guidelines.xml">
<!ENTITY I-D.mathis-frag-harmful SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mathis-frag-harmful.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" ipr="trust200811" docName="draft-thubert-6lowpan-simple-fragment-recovery-03">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>LoWPAN simple fragment Recovery</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization abbrev="Cisco">
Cisco Systems
</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>6LoWPAN</workgroup>
<abstract>
<t>
Considering that 6LoWPAN packets can be as large as 2K bytes and that
an 802.15.4 frame with security will carry in the order of 80 bytes of effective payload,
a packet might end up fragmented into as many as 25 fragments at the 6LoWPAN shim layer.
If a single one of those fragments is lost in transmission, all fragments must be resent,
further contributing to the congestion that might have
caused the initial packet loss. This draft introduces a simple protocol
to recover individual fragments between 6LoWPAN endpoints.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t>
Considering that 6LoWPAN packets can be as large as 2K bytes and that
a 802.15.4 frame with security will carry in the order of 80 bytes of effective payload,
a packet might be fragmented into about 25 fragments at the 6LoWPAN shim layer.
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.
<!--n the other hand, Layer
2 retries alleviate the risk of packet loss but lead to less controlled overall latency,
monopolize a hop, and might not be as efficient as trying an alternate path entirely.
-->
</t>
<t>
<!--
Lessons about fragmentation were learnt with IPv4 that lead to <xref target="RFC1191"> the
Path MTU discovery</xref>.
-->
Past experience with fragmentation has shown that
missassociated or lost fragments can lead to poor network behaviour and,
eventually, trouble at application layer. The reader is encouraged to read
<xref target="RFC4963"/> and follow the references for more information.
That experience led to the definition of <xref target="RFC1191"> the
Path MTU discovery</xref> protocol that limits fragmentation over the Internet.
</t>
<t>
<!--
Because higher QoS packets might require access to the medium, or because an alternate path
might be globally more efficient over the LoWPAN at a given point of time,
-->
An end-to-end fragment recovery mechanism might be a good complement to a
hop-by-hop MAC level recovery with a limited number of retries.
This draft introduces a simple protocol to recover individual fragments between 6LoWPAN endpoints.
Specifically in the case of UDP, valuable additional information can be found in
<xref target="I-D.ietf-tsvwg-udp-guidelines">UDP Usage Guidelines for Application Designers</xref>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
<t>Readers are expected to be familiar with all the terms and concepts
that are discussed in <xref target="RFC4919">"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref> and <xref target="RFC4944">
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>.
</t>
<t>
<list style="hanging">
<t hangText="ERP"></t>
<t>Error Recovery Procedure.
</t>
<t hangText="LoWPAN endpoints"></t>
<t>The LoWPAN nodes in charge of generating or expanding a 6LoWPAN header from/to a full IPv6 packet.
The LoWPAN endpoints are the points where fragmentation and reassembly take place.
</t>
</list>
</t>
</section>
<section anchor='rationale' title="Rationale">
<t>
There are a number of usages for large packets in Wireless Sensor Networks. Such usages
may not be the most typical or represent the largest amount of traffic over the LoWPAN;
however, the associated functionality can be critical enough to justify extra care for
ensuring effective transport of large packets across the LoWPAN.
</t>
<t>
The list of those usages includes:
<list style='hanging'>
<t hangText="Towards the LoWPAN node:">
<list style='hanging'>
<t hangText="Packages of Commands:">
A number of commands or a full configuration can by 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 intended operation will not take effect.
</t>
<t hangText="Firmware update:">
For example, a new version of the LoWPAN node software is downloaded from a system
manager over unicast or multicast services.
Such a reflashing operation typically involves updating a large number of similar
6LoWPAN nodes over a relatively short period of time.
</t>
</list>
</t>
<t hangText="From the LoWPAN node:">
<list style='hanging'>
<t hangText="Waveform captures:">
A number of consecutive samples are measured at a high rate for a short time and then transferred
from a sensor to a gateway or an edge server as a single large report.
</t>
<t hangText="Large data packets:">
Rich data types might require more than one fragment.
</t>
</list>
</t>
</list>
</t>
<t>
Uncontrolled firmware download or waveform upload can easily result in a massive
increase of the traffic and saturate the network.
</t>
<t>
When a fragment is lost in transmission, all fragments are resent, further contributing
to the congestion that caused the initial loss, and potentially leading to congestion collapse.
</t>
<t>
This saturation may lead to excessive radio interference, or random early discard
(leaky bucket) in relaying nodes. Additional queueing and memory congestion may
result while waiting for a low power next hop to emerge from its sleeping state.
</t>
</section>
<section anchor='req' title="Requirements">
<t>
This paper proposes a method to recover individual fragments between LoWPAN endpoints. The
method is designed to fit the following requirements of a LoWPAN (with or without a Mesh-Under
routing protocol):
<list style="hanging">
<t hangText="Number of fragments"></t>
<t>The recovery mechanism must support highly fragmented packets, with a maximum of 32 fragments per packet.
</t>
<t hangText="Minimum acknowledgement overhead"></t>
<t> Because the radio is half duplex, and because of silent time spent in the
various medium access mechanisms, an acknowledgement consumes roughly as many resources as data fragment.
</t><t>The recovery mechanism should be able to acknowledge multiple fragments in a single message.
</t>
<t hangText="Controlled latency"></t>
<t>The recovery mechanism must succeed or give up within the time boundary imposed by the recovery process
of the Upper Layer Protocols.
</t>
<t hangText="Support for out-of-order fragment delivery"></t>
<t> A Mesh-Under load balancing mechanism such as the ISA100 Data Link Layer can introduce out-of-sequence packets.
The recovery mechanism must account for packets that appear lost but are actually only delayed over a different path.
</t>
<t hangText="Optional congestion control"></t>
<t> The aggregation of multiple concurrent flows may lead to the saturation of the radio network and congestion collapse.
</t>
<t>The recovery mechanism should provide means for controlling the number of fragments in transit over the LoWPAN.
</t>
<t hangText="Backward compatibility"></t>
<t> A node that implements this draft should be able to communicate with a node that implements
<xref target="RFC4944"/>. This draft assumes that compatibility information about the
remote LoWPAN endpoint is obtained by external means.
</t>
</list>
</t>
</section>
<section anchor='overview' title="Overview">
<t>Considering that a multi-hop LoWPAN can be a very sensitive environment
due to the limited queueing capabilities of a
large population of its nodes, this draft recommends a simple and
conservative approach to congestion control, based on TCP congestion avoidance.
</t>
<t> Congestion on the forward path is assumed in case of packet loss, and packet loss is assumed upon time out.
</t>
<t> Congestion on the forward path can also be indicated by an Explicit Congestion Notification (ECN) mechanism.
Though whether and how ECN <xref target="RFC3168"/> is carried out over the LoWPAN is out of scope,
this draft provides a way for the destination endpoint to echo an ECN indication
back to the source endpoint in an acknowledgement message as represented in
<xref target='ackfig'/> in <xref target='ackfrag'/>.
</t>
<t> From the standpoint of a source LoWPAN endpoint, an outstanding fragment is a fragment that was
sent but for which no explicit acknowledgement was received yet.
This means that the fragment might be on the way, received but not yet acknowledged,
or the acknowledgement might be on the way back. It is also possible that either
the fragment or the acknowledgement was lost on the way.
</t>
<t>Because a meshed LoWPAN might deliver frames out of order, it is virtually
impossible to differentiate these situations. In other words, from the sender standpoint,
all outstanding fragments might still be in the network and contribute to its congestion.
There is an assumption, though, that after a certain amount of time, a frame is either received
or lost, so it is not causing congestion anymore. This amount of time can be estimated based on the round trip
delay between the LoWPAN endpoints. The method detailed in <xref target="RFC2988"/> is recommended for that computation.
</t>
<t>The reader is encouraged to read through <xref target="RFC2914">"Congestion Control Principles"</xref>.
Additionally <xref target="RFC2309"/> and <xref target="RFC2581"/> provide deeper information on why this
mechanism is needed and how TCP handles Congestion Control. Basically, the goal here is to
manage the amount of fragments present in the network; this is achieved by to reducing the number of outstanding
fragments over a congested path by throttling the sources.
</t>
<t> <xref target="ffc"/> describes how the sender decides how many fragments are (re)sent before
an acknowledgement is required, and how the sender adapts that number to the network conditions.
</t>
</section>
<section anchor='dispatch' title="New Dispatch types and headers">
<t>This specification extends <xref target="RFC4944">
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>
with 4 new dispatch types, for Recoverable Fragments (RFRAG)
headers with or without Acknowledgement Request, and for the Acknowledgement
back, with or without ECN Echo.
</t>
<figure anchor='difig' title="Additional Dispatch Value Bit Patterns">
<artwork>
Pattern Header Type
+------------+-----------------------------------------------+
| 11 101000 | RFRAG - Recoverable Fragment |
| 11 101001 | RFRAG-AR - RFRAG with Ack Request |
| 11 101010 | RFRAG-ACK - RFRAG Acknowledgement |
| 11 101011 | RFRAG-AEC - RFRAG Ack with ECN Echo |
+------------+-----------------------------------------------+
</artwork>
</figure>
<t>
In the following sections, the semantics of "datagram_tag,"
"datagram_offset" and "datagram_size" and the reassembly process
are unchanged from <xref target="RFC4944"/> Section 5.3.
"Fragmentation Type and Header."
</t>
<t>
</t>
<section anchor='RF' title="Recoverable Fragment Dispatch type and Header">
<figure anchor='RFfig' title="Recoverable Fragment Dispatch type and Header">
<artwork>
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 X|datagram_offset| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sequence | datagram_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X set == Ack Requested
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="X bit"></t>
<t>When set, the sender requires an Acknowledgement from the receiver
</t>
<t hangText="Sequence"></t>
<t>The sequence number of the fragment. Fragments are numbered [0..N] where N is in [0..31].
</t>
</list>
</t>
</section>
<section anchor='ackfrag' title="Fragment Acknowledgement Dispatch type and Header">
<figure anchor='ackfig' title="Fragment Acknowledgement Dispatch type and Header">
<artwork>
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 Y| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^
| | Y set == ECN echo
| |
| | bitmap indicating whether
| +-----Fragment with sequence 10 was received
+-------------------------Fragment with sequence 00 was received
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Y bit"></t>
<t>When set, the sender indicates that at least one of the acknowledged fragments
was received with an Explicit Congestion Notification, indicating that the
path followed by the fragments is subject to congestion.
</t>
<t hangText="Acknowledgement Bitmap"></t>
<t>Each bit in the Bitmap refers to a particular fragment:
bit n set indicates that fragment with sequence n was received, for n in [0..31].
</t>
<t>All zeroes means that the fragment was dropped because it corresponds to an
obsolete datagram_tag.
This happens if the packet was already reassembled and passed to the network
upper layer, or the packet expired and was dropped.
</t>
</list>
</t>
</section>
</section>
<section anchor="ffc" title="Outstanding Fragments Control">
<t>A mechanism based on TCP congestion avoidance dictates the maximum number of outstanding fragments.
</t>
<t>
The maximum number of outstanding fragments for a given packet toward a given LoWPAN
endpoint is initially set to a configured value, unless recent history indicates
otherwise.
</t>
<t> Each time that maximum number of fragments is fully acknowledged, that
number can be incremented by 1. ECN echo and packet loss cause the number to
be divided by 2.
</t>
<t>
The sender transfers a controlled number of fragments and flags the last
fragment of a series with an acknowledgement request.
</t>
<t>
The sender arms a timer to cover the fragment that carries the Acknowledgement request. Upon time out,
the sender assumes that all the fragments on the way are received or lost. It divides the maximum number of
outstanding fragments by 2 and resets the number of outstanding fragments to 0.
</t>
<t>Upon receipt of an Acknowledgement request, the receiver responds with an Acknowledgement containing a
bitmap that indicates which fragments were actually received.
The bitmap is a 32bit DWORD, which accommodates up to 32 fragments and is sufficient for the 6LoWPAN MTU.
For all n in [0..31], bit n is set to 1 in the bitmap to indicate that fragment with sequence n was received,
otherwise the bit is set to 0.
</t>
<t>The receiver MAY issue unsolicited acknowledgements. An unsolicited acknowledgement
enables the sender endpoint to resume sending if it had reached its maximum number
of outstanding fragments. Note that acknowledgements might consume precious resources so
the use of unsolicited acknowledgements should be configurable and not enabled by default.
</t>
<t>The received MUST acknowledge a fragment with the acknowledgement request bit set. If any fragment
immediately preceding an acknowledgement request is still missing, the receiver MAY intentionally
delay its acknowledgement to allow in-transit fragments to arrive. This mechanism might defeat the
round trip delay computation so it should be configurable and not enabled by default.
</t>
<t>Fragments are sent in a round robin fashion: the sender sends all the fragments for a first time
before it retries any lost fragment; lost fragments are retried in sequence, oldest first.
This mechanism enables the receiver to acknowledge fragments that were delayed in the network
before they are actually retried.
</t>
<t>The process must complete within an acceptable time that is within the boundaries of upper layer retries.
Additional work is required to define how this is achieved. When the source endpoint decides that a packet should be
dropped and the fragmentation process cancelled, it sends a pseudo fragment with the datagram_offset, sequence and datagram_size all
set to zero, and no data. Upon reception of this message, the receiver should clean up all resources for the packet
associated to the datagram_tag.
</t>
</section>
<section title="Security Considerations">
<t> The process of recovering fragments does not appear to create any opening for new threat.
</t>
</section>
<section title="IANA Considerations">
<t>Need extensions for formats defined in <xref target="RFC4944">
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>.
</t>
</section>
<!------------------------------------------------------>
<!-- SECTION: ACKNOWLEDGMENTS -->
<!------------------------------------------------------>
<section title="Acknowledgments">
<t>The author wishes to thank Jay Werb, Christos Polyzois, Soumitri Kolavennu and Harry Courtice for their contribution and review.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2119;
&RFC2988;
&RFC4944;
</references>
<references title='Informative References'>
&RFC1191;
&RFC2309;
&RFC2581;
&RFC2914;
&RFC3168;
&RFC4919;
&RFC4963;
&I-D.ietf-tsvwg-udp-guidelines;
&I-D.mathis-frag-harmful;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 07:11:32 |