< draft-ietf-6lo-fragment-recovery-14.txt   draft-ietf-6lo-fragment-recovery-15.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 4944 (if approved) 6 March 2020 Updates: 4944 (if approved) 9 March 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 7 September 2020 Expires: 10 September 2020
6LoWPAN Selective Fragment Recovery 6LoWPAN Selective Fragment Recovery
draft-ietf-6lo-fragment-recovery-14 draft-ietf-6lo-fragment-recovery-15
Abstract Abstract
This draft updates RFC 4944 with a simple protocol to recover This draft updates RFC 4944 with a simple protocol to recover
individual fragments across a route-over mesh network, with a minimal individual fragments across a route-over mesh network, with a minimal
flow control to protect the network against bloat. flow control to protect the network against bloat.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 September 2020. This Internet-Draft will expire on 10 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 11 skipping to change at page 2, line 11
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5
3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 6 3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 6
4. Extending draft-ietf-6lo-minimal-fragment . . . . . . . . . . 6 4. Extending draft-ietf-6lo-minimal-fragment . . . . . . . . . . 6
4.1. Slack in the First Fragment . . . . . . . . . . . . . . . 6 4.1. Slack in the First Fragment . . . . . . . . . . . . . . . 6
4.2. Gap between frames . . . . . . . . . . . . . . . . . . . 7 4.2. Gap between frames . . . . . . . . . . . . . . . . . . . 7
4.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Modifying the First Fragment . . . . . . . . . . . . . . 8 4.4. Modifying the First Fragment . . . . . . . . . . . . . . 8
5. New Dispatch types and headers . . . . . . . . . . . . . . . 8 5. New Dispatch types and headers . . . . . . . . . . . . . . . 8
5.1. Recoverable Fragment Dispatch type and Header . . . . . . 9 5.1. Recoverable Fragment Dispatch type and Header . . . . . . 9
5.2. RFRAG Acknowledgment Dispatch type and Header . . . . . . 11 5.2. RFRAG Acknowledgment Dispatch type and Header . . . . . . 11
6. Fragment Recovery . . . . . . . . . . . . . . . . . . . . . . 12 6. Fragment Recovery . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Forwarding Fragments . . . . . . . . . . . . . . . . . . 14 6.1. Forwarding Fragments . . . . . . . . . . . . . . . . . . 15
6.1.1. Receiving the first fragment . . . . . . . . . . . . 15 6.1.1. Receiving the first fragment . . . . . . . . . . . . 15
6.1.2. Receiving the next fragments . . . . . . . . . . . . 16 6.1.2. Receiving the next fragments . . . . . . . . . . . . 16
6.2. Receiving RFRAG Acknowledgments . . . . . . . . . . . . . 16 6.2. Receiving RFRAG Acknowledgments . . . . . . . . . . . . . 16
6.3. Aborting the Transmission of a Fragmented Packet . . . . 17 6.3. Aborting the Transmission of a Fragmented Packet . . . . 17
6.4. Applying Recoverable Fragmentation along a Diverse 6.4. Applying Recoverable Fragmentation along a Diverse
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Path . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Management Considerations . . . . . . . . . . . . . . . . . . 18 7. Management Considerations . . . . . . . . . . . . . . . . . . 18
7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 18 7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 19
7.2. Observing the network . . . . . . . . . . . . . . . . . . 21 7.2. Observing the network . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. Normative References . . . . . . . . . . . . . . . . . . . . 23 11. Normative References . . . . . . . . . . . . . . . . . . . . 23
12. Informative References . . . . . . . . . . . . . . . . . . . 24 12. Informative References . . . . . . . . . . . . . . . . . . . 24
Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 28
Appendix C. Considerations on Flow Control . . . . . . . . . . . 29 Appendix C. Considerations on Flow Control . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
In most Low Power and Lossy Network (LLN) applications, the bulk of In most Low Power and Lossy Network (LLN) applications, the bulk of
the traffic consists of small chunks of data (on the order of a few the traffic consists of small chunks of data (on the order of a few
bytes to a few tens of bytes) at a time. Given that an IEEE Std. bytes to a few tens of bytes) at a time. Given that an IEEE Std.
802.15.4 [IEEE.802.15.4] frame can carry a payload of 74 bytes or 802.15.4 [IEEE.802.15.4] frame can carry a payload of 74 bytes or
skipping to change at page 3, line 12 skipping to change at page 3, line 12
data, for instance to support the firmware upgrade of the LLN nodes data, for instance to support the firmware upgrade of the LLN nodes
or the extraction of logs from LLN nodes. In the former case, the or the extraction of logs from LLN nodes. In the former case, the
large chunk of data is transferred to the LLN node, whereas in the large chunk of data is transferred to the LLN node, whereas in the
latter, the large chunk flows away from the LLN node. In both cases, latter, the large chunk flows away from the LLN node. In both cases,
the size can be on the order of 10 kilobytes or more and an end-to- the size can be on the order of 10 kilobytes or more and an end-to-
end reliable transport is required. end reliable transport is required.
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944] "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]
defines the original 6LoWPAN datagram fragmentation mechanism for defines the original 6LoWPAN datagram fragmentation mechanism for
LLNs. One critical issue with this original design is that routing LLNs. One critical issue with this original design is that routing
an IPv6 [RFC8200] packet across a route-over mesh requires an IPv6 [RFC8200] packet across a route-over mesh requires the
reassembling the full packet at each hop, which may cause latency reassembly of the packet at each hop. The "6TiSCH Architecture"
along a path and an overall buffer bloat in the network. The "6TiSCH [I-D.ietf-6tisch-architecture] indicates that this may cause latency
Architecture" [I-D.ietf-6tisch-architecture] recommends using a along a path and impact critical resources such as memory and
fragment forwarding (FF) technique to alleviate those undesirable battery; to alleviate those undesirable effects it recommends using a
effects. 6LoWPAN Fragment Forwarding (6FF) technique .
"LLN Minimal Fragment Forwarding" [FRAG-FWD] specifies the general "LLN Minimal Fragment Forwarding" [FRAG-FWD] specifies the generic
behavior that all FF techniques including this specification follow, behavior that all 6FF techniques including this specification follow,
and presents the associated caveats. In particular, the routing and presents the associated caveats. In particular, the routing
information is fully indicated in the first fragment, which is always information is fully indicated in the first fragment, which is always
forwarded first. A state is formed and used to forward all the next forwarded first. With this specification, the first fragment is
identified by a Sequence of 0 as opposed to a dispatch type in
[RFC4944]. A state is formed and used to forward all the next
fragments along the same path. The Datagram_Tag is locally fragments along the same path. The Datagram_Tag is locally
significant to the Layer-2 source of the packet and is swapped at significant to the Layer-2 source of the packet and is swapped at
each hop, more in Section 6. With this specification the each hop, more in Section 6. This specification encodes the
Datagram_Tag is encoded in one byte, and will saturate if there are Datagram_Tag in one byte, which will saturate if more than 256
more than 256 datagram that transit in the fragmented form over a datagram transit in the fragmented form over a same hop at the same
same hop at the same time. This is not realistic at the time of this time. This is not realistic at the time of this writing. Should
writing. Should this happen in a new 6LoWPAN technology, a node will this happen in a new 6LoWPAN technology, a node will need to use
need to use several Link-Layer addresses to increase its indexing several Link-Layer addresses to increase its indexing capacity.
capacity.
"Virtual reassembly buffers in 6LoWPAN" "Virtual reassembly buffers in 6LoWPAN" [LWIG-FRAG](VRB) proposes a
[I-D.ietf-lwig-6lowpan-virtual-reassembly] (VRB) proposes a FF 6FF technique that is compatible with [RFC4944] without the need to
technique that is compatible with [RFC4944] without the need to
define a new protocol. However, adding that capability alone to the define a new protocol. However, adding that capability alone to the
local implementation of the original 6LoWPAN fragmentation would not local implementation of the original 6LoWPAN fragmentation would not
address the inherent fragility of fragmentation (see address the inherent fragility of fragmentation (see [FRAG-ILE]) in
[I-D.ietf-intarea-frag-fragile]) in particular the issues of particular the issues of resources locked on the reassembling
resources locked on the receiver and the wasted transmissions due to endpoint and the wasted transmissions due to the loss of a single
the loss of a single fragment in a whole datagram. [Kent] compares fragment in a whole datagram. [Kent] compares the unreliable
the unreliable delivery of fragments with a mechanism it calls delivery of fragments with a mechanism it calls "selective
"selective acknowledgements" that recovers the loss of a fragment acknowledgements" that recovers the loss of a fragment individually.
individually. The paper illustrates the benefits that can be derived The paper illustrates the benefits that can be derived from such a
from such a method in figures 1, 2 and 3, on pages 6 and 7. method in figures 1, 2 and 3, on pages 6 and 7. [RFC4944] has no
[RFC4944] has no selective recovery and the whole datagram fails when selective recovery and the whole datagram fails when one fragment is
one fragment is not delivered to the destination 6LoWPAN endpoint. not delivered to the reassembling endpoint. Constrained memory
Constrained memory resources are blocked on the receiver until the resources are blocked on the reassembling endpoint until it times
receiver times out, possibly causing the loss of subsequent packets out, possibly causing the loss of subsequent packets that cannot be
that cannot be received for the lack of buffers. received for the lack of buffers.
That problem is exacerbated when forwarding fragments over multiple That problem is exacerbated when forwarding fragments over multiple
hops since a loss at an intermediate hop will not be discovered by hops since a loss at an intermediate hop will not be discovered by
either the source or the destination, and the source will keep on either the fragmenting and reassembling endpoints, and the source
sending fragments, wasting even more resources in the network and will keep on sending fragments, wasting even more resources in the
possibly contributing to the condition that caused the loss to no network since the datagram cannot arrive in its entirety, and
avail since the datagram cannot arrive in its entirety. RFC 4944 is possibly contributing to the condition that caused the loss.
also missing signaling to abort a multi-fragment transmission at any [RFC4944] is also missing signaling to abort a multi-fragment
time and from either end, and, if the capability to forward fragments transmission at any time and from either end, and, if the capability
is implemented, clean up the related state in the network. It is to forward fragments is implemented, clean up the related state in
also lacking flow control capabilities to avoid participating in the network. It is also lacking flow control capabilities to avoid
congestion that may in turn cause the loss of a fragment and participating in congestion that may in turn cause the loss of a
potentially the retransmission of the full datagram. fragment and potentially the retransmission of the full datagram.
This specification provides a method to forward fragments over This specification provides a method to forward fragments over
typically a few hops in a route-over 6LoWPAN mesh, and a selective typically a few hops in a route-over 6LoWPAN mesh, and a selective
acknowledgment to recover individual fragments between 6LoWPAN acknowledgment to recover individual fragments between 6LoWPAN
endpoints. The method is designed to limit congestion loss in the endpoints. The method is designed to limit congestion loss in the
network and addresses the requirements that are detailed in network and addresses the requirements that are detailed in
Appendix B. Appendix B.
2. Terminology 2. Terminology
skipping to change at page 4, line 38 skipping to change at page 4, line 38
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. References 2.2. References
In this document, readers will encounter terms and concepts that are In this document, readers will encounter terms and concepts that are
discussed in "Problem Statement and Requirements for IPv6 over discussed in "IPv6 over Low-Power Wireless Personal Area Networks
Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals"
[RFC4919], "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"
[RFC4944], and "Problem Statement and Requirements for IPv6 over
Low-Power Wireless Personal Area Network (6LoWPAN) Routing"
[RFC6606].
"LLN Minimal Fragment Forwarding" [FRAG-FWD] introduces the generic "LLN Minimal Fragment Forwarding" [FRAG-FWD] discusses the generic
concept of a Virtual Reassembly Buffer (VRB) and specifies behaviours concept of a Virtual Reassembly Buffer (VRB) and specifies behaviors
and caveats that are common to a large family of FF techniques and caveats that are common to a large family of 6FF techniques
including this, which fully inherits from that specification. It including the mechanism specified by this document, which fully
also defines terms used in this document: 6LoWPAN endpoints, inherits from that specification. It also defines terms used in this
Compressed Form, Datagram_Tag, Datagram_Size, and Fragment_Offset. document: Compressed Form, Datagram_Tag, Datagram_Size,
Fragment_Offset, and 6LoWPAN Fragment Forwarding endpoint (commonly
abbreviated as only "endpoint").
Past experience with fragmentation has shown that misassociated or Past experience with fragmentation has shown that misassociated or
lost fragments can lead to poor network behavior and, occasionally, lost fragments can lead to poor network behavior and, occasionally,
trouble at the application layer. The reader is encouraged to read trouble at the application layer. The reader is encouraged to read
"IPv4 Reassembly Errors at High Data Rates" [RFC4963] and follow the "IPv4 Reassembly Errors at High Data Rates" [RFC4963] and follow the
references for more information. references for more information. That experience led to the
definition of "Path MTU discovery" [RFC8201] (PMTUD) protocol that
That experience led to the definition of "Path MTU discovery" limits fragmentation over the Internet. Specifically in the case of
[RFC8201] (PMTUD) protocol that limits fragmentation over the UDP, valuable additional information can be found in "UDP Usage
Internet. Guidelines for Application Designers" [RFC8085].
Specifically in the case of UDP, valuable additional information can
be found in "UDP Usage Guidelines for Application Designers"
[RFC8085].
Readers are expected to be familiar with all the terms and concepts
that are discussed in "IPv6 over Low-Power Wireless Personal Area
Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4
Networks" [RFC4944].
"The Benefits of Using Explicit Congestion Notification (ECN)" "The Benefits of Using Explicit Congestion Notification (ECN)"
[RFC8087] provides useful information on the potential benefits and [RFC8087] provides useful information on the potential benefits and
pitfalls of using ECN. pitfalls of using ECN.
Quoting the "Multiprotocol Label Switching (MPLS) Architecture" Quoting the "Multiprotocol Label Switching (MPLS) Architecture"
[RFC3031]: with MPLS, 'packets are "labeled" before they are [RFC3031]: with MPLS, 'packets are "labeled" before they are
forwarded' along a Label Switched Path (LSP). At subsequent hops, forwarded' along a Label Switched Path (LSP). At subsequent hops,
there is no further analysis of the packet's network layer header. there is no further analysis of the packet's network layer header.
Rather, the label is used as an index into a table which specifies Rather, the label is used as an index into a table which specifies
the next hop, and a new label". The MPLS technique is leveraged in the next hop, and a new label". [FRAG-FWD] leverages MPLS to forward
the present specification to forward fragments that actually do not fragments that actually do not have a network layer header, since the
have a network layer header, since the fragmentation occurs below IP. fragmentation occurs below IP, and this specification makes it
reversible so the reverse path can be followed as well.
2.3. New Terms 2.3. Other Terms
This specification uses the following terms: This specification uses the following terms:
RFRAG: Recoverable Fragment RFRAG: Recoverable Fragment
RFRAG-ACK: Recoverable Fragment Acknowledgement RFRAG-ACK: Recoverable Fragment Acknowledgement
RFRAG Acknowledgment Request: An RFRAG with the Acknowledgement RFRAG Acknowledgment Request: An RFRAG with the Acknowledgement
Request flag ('X' flag) set. Request flag ('X' flag) set.
NULL bitmap: Refers to a bitmap with all bits set to zero. NULL bitmap: Refers to a bitmap with all bits set to zero.
FULL bitmap: Refers to a bitmap with all bits set to one. FULL bitmap: Refers to a bitmap with all bits set to one.
Forward: The direction of a LSP path, followed by the RFRAG. Reassembling endpoint: The receiving endpoint
Reverse: The reverse direction of a LSP path, taken by the RFRAG- Fragmenting endpoint: The sending endpoint
ACK.
Forward direction: The direction of a path, which is followed by the
RFRAG.
Reverse direction: The reverse direction of a path, which is taken
by the RFRAG-ACK.
3. Updating RFC 4944 3. Updating RFC 4944
This specification updates the fragmentation mechanism that is This specification updates the fragmentation mechanism that is
specified in "Transmission of IPv6 Packets over IEEE 802.15.4 specified in "Transmission of IPv6 Packets over IEEE 802.15.4
Networks" [RFC4944] for use in route-over LLNs by providing a model Networks" [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 can be forwarded end-to-end across a 6LoWPAN LLN, and
where fragments that are lost on the way can be recovered where fragments that are lost on the way can be recovered
individually. A new format for fragments is introduced and new individually. A new format for fragments is introduced and new
dispatch types are defined in Section 5. dispatch types are defined in Section 5.
[RFC8138] allows modifying the size of a packet en route by removing [RFC8138] allows modifying the size of a packet en route by removing
the consumed hops in a compressed Routing Header. This requires that the consumed hops in a compressed Routing Header. This requires that
Fragment_Offset and Datagram_Size (see Section 2.3) are also modified Fragment_Offset and Datagram_Size (see Section 2.3) are also modified
en route, which is difficult to do in the uncompressed form. This en route, which is difficult to do in the uncompressed form. This
specification expresses those fields in the Compressed Form and specification expresses those fields in the Compressed Form and
allows modifying them en route (see Section 4.4) easily. allows modifying them en route (see Section 4.4) easily.
Note that consistent with Section 2 of [RFC6282], for the Consistently with Section 2 of [RFC6282], for the fragmentation
fragmentation mechanism described in Section 5.3 of [RFC4944], any mechanism described in Section 5.3 of [RFC4944], any header that
header that cannot fit within the first fragment MUST NOT be cannot fit within the first fragment MUST NOT be compressed when
compressed when using the fragmentation mechanism described in this using the fragmentation mechanism described in this specification.
specification.
4. Extending draft-ietf-6lo-minimal-fragment 4. Extending draft-ietf-6lo-minimal-fragment
This specification implements the generic FF technique defined in This specification implements the generic 6FF technique defined in
"LLN Minimal Fragment Forwarding" [FRAG-FWD], provides end-to-end "LLN Minimal Fragment Forwarding" [FRAG-FWD], provides end-to-end
fragment recovery and mechanisms that can be used for flow control. fragment recovery and mechanisms that can be used for flow control.
4.1. Slack in the First Fragment 4.1. Slack in the First Fragment
[FRAG-FWD] allows for refragmenting in intermediate nodes, meaning [FRAG-FWD] allows for refragmenting in intermediate nodes, meaning
that some bytes from a given fragment may be left in the VRB to be that some bytes from a given fragment may be left in the VRB to be
added to the next fragment. The reason for this happening would be added to the next fragment. The need for more space in the outgoing
the need for space in the outgoing fragment that was not needed in fragment than was needed for the incoming fragment arises when the
the incoming fragment, for instance because the 6LoWPAN Header 6LoWPAN Header Compression is not as efficient on the outgoing link
Compression is not as efficient on the outgoing link, e.g., if the or the Link MTU is reduced.
Interface ID (IID) of the source IPv6 address is elided by the
originator on the first hop because it matches the source Link-Layer
address, but cannot be on the next hops because the source Link-Layer
address changes.
This specification cannot allow this operation since fragments are This specification cannot allow such a refragmentation operation
recovered end-to-end based on a sequence number. This means that the since the fragments are recovered end-to-end based on a sequence
fragments that contain a 6LoWPAN-compressed header MUST have enough number. The Fragment_Size MUST be tailored to fit the minimal MTU
slack to enable a less efficient compression in the next hops that along the path, and the first fragment that contains a 6LoWPAN-
still fits in one MAC frame. For instance, if the IID of the source compressed header MUST have enough slack to enable a less efficient
IPv6 address is elided by the originator, then it MUST compute the compression in the next hops to still fits within the Link MTU. If
Fragment_Size as if the MTU was 8 bytes less. This way, the next hop the fragmenting endpoint is also the 6LoWPAN compression endpoint, it
can restore the source IID to the first fragment without impacting will elide the IID of the source IPv6 address if it matches the Link-
the second fragment. Layer address [RFC6282]. In a network with a consistent MTU, it MUST
compute the Fragment_Size as if the MTU was 8 bytes less, so the next
hop can expand the IID within the same fragment.
4.2. Gap between frames 4.2. Gap between frames
[FRAG-FWD] requires that a configurable interval of time is inserted [FRAG-FWD] requires that a configurable interval of time is inserted
between transmissions to the same next hop and in particular between between transmissions to the same next hop and in particular between
fragments of a same datagram. In the case of half duplex interfaces, 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 this inter-frame gap ensures that the next hop is done forwarding the
previous frame and is capable of receiving the next one. previous frame and is capable of receiving the next one.
In the case of a mesh operating at a single frequency with In the case of a mesh operating at a single frequency with
skipping to change at page 7, line 35 skipping to change at page 7, line 32
4.3. Flow Control 4.3. Flow Control
The inter-frame gap is the only protection that [FRAG-FWD] imposes by The inter-frame gap is the only protection that [FRAG-FWD] imposes by
default. This document enables to group fragments in windows and default. This document enables to group fragments in windows and
request intermediate acknowledgements so the number of in-flight request intermediate acknowledgements so the number of in-flight
fragments can be bounded. This document also adds an ECN mechanism fragments can be bounded. This document also adds an ECN mechanism
that can be used to adapt the size of the window, the size of the that can be used to adapt the size of the window, the size of the
fragments, and/or the inter-frame gap to protect the network. fragments, and/or the inter-frame gap to protect the network.
This specification enables the source endpoint to apply a flow This specification enables the fragmenting endpoint to apply a flow
control mechanism to tune those parameters, but the mechanism itself control mechanism to tune those parameters, but the mechanism itself
is out of scope. In most cases, the expectation is that most is out of scope. In most cases, the expectation is that most
datagrams will represent only a few fragments, and that only the last datagrams will represent only a few fragments, and that only the last
fragment will be acknowledged. A basic implementation of the source fragment will be acknowledged. A basic implementation of the
endpoint is NOT REQUIRED to variate the size of the window, the fragmenting endpoint is NOT REQUIRED to variate the size of the
duration of the inter-frame gap or the size of a fragment in the window, the duration of the inter-frame gap or the size of a fragment
middle of the transmission of a datagram, and it MAY ignore the ECN in the middle of the transmission of a datagram, and it MAY ignore
signal or simply reset the window to 1 (see Appendix C for more) till the ECN signal or simply reset the window to 1 (see Appendix C for
the end of this datagram upon detecting a congestion. more) till the end of this datagram upon detecting a congestion.
An intermediate node that experiences a congestion MAY set the ECN
bit in a fragment, and the reassembling endpoint echoes the ECN bit
at most once at the next opportunity to acknowledge back.
The size of the fragments is typically computed from the Link MTU to The size of the fragments is typically computed from the Link MTU to
maximize the size of the resulting frames. The size of the window maximize the size of the resulting frames. The size of the window
and the duration of the inter-frame gap SHOULD be configurable, to and the duration of the inter-frame gap SHOULD be configurable, to
roughly adapt the size of the window to the number of hops in an roughly adapt the size of the window to the number of hops in an
average path, and to follow the general recommendations in average path, and to follow the general recommendations in
[FRAG-FWD], respectively. [FRAG-FWD], respectively.
4.4. Modifying the First Fragment 4.4. Modifying the First Fragment
The compression of the Hop Limit, of the source and destination The compression of the Hop Limit, of the source and destination
addresses in the IPv6 Header, and of the Routing Header may change en addresses in the IPv6 Header, and of the Routing Header may change en
route in a Route-Over mesh LLN. If the size of the first fragment is route in a Route-Over mesh LLN. If the size of the first fragment is
modified, then the intermediate node MUST adapt the Datagram_Size to modified, then the intermediate node MUST adapt the Datagram_Size,
reflect that difference. encoded in the Fragment_Size field, to reflect that difference.
The intermediate node MUST also save the difference of Datagram_Size The intermediate node MUST also save the difference of Datagram_Size
of the first fragment in the VRB and add it to the Datagram_Size and of the first fragment in the VRB and add it to the Fragment_Offset of
to the Fragment_Offset of all the subsequent fragments for that all the subsequent fragments that it forwards for that datagram.
datagram.
5. New Dispatch types and headers 5. New Dispatch types and headers
This document specifies an alternate to the 6LoWPAN fragmentation This document specifies an alternate to the 6LoWPAN fragmentation
sublayer [RFC4944] to emulate an Link MTU up to 2048 bytes for the sublayer [RFC4944] to emulate an Link MTU up to 2048 bytes for the
upper layer, which can be the 6LoWPAN Header Compression sublayer upper layer, which can be the 6LoWPAN Header Compression sublayer
that is defined in the "Compression Format for IPv6 Datagrams" that is defined in the "Compression Format for IPv6 Datagrams"
[RFC6282] specification. This specification also provides a reliable [RFC6282] specification. This specification also provides a reliable
transmission of the fragments over a multihop 6LoWPAN route-over mesh transmission of the fragments over a multihop 6LoWPAN route-over mesh
network and a minimal flow control to reduce the chances of network and a minimal flow control to reduce the chances of
congestion loss. congestion loss.
A LoWPAN Fragment Forwarding [FRAG-FWD] technique derived from MPLS A 6LoWPAN Fragment Forwarding [FRAG-FWD] technique derived from MPLS
enables the forwarding of individual fragments across a 6LoWPAN enables the forwarding of individual fragments across a 6LoWPAN
route-over mesh without reassembly at each hop. The Datagram_Tag is 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 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 source Link-Layer address of the fragment, so together the Link-Layer
address and the label can identify the fragment globally. A node may address and the label can identify the fragment globally within the
build the Datagram_Tag in its own locally-significant way, as long as lifetime of the datagram. A node may build the Datagram_Tag in its
the chosen Datagram_Tag stays unique to the particular datagram for own locally-significant way, as long as the chosen Datagram_Tag stays
the lifetime of that datagram. The result is that the label does not unique to the particular datagram for its lifetime. The result is
need to be globally unique but also that it must be swapped at each that the label does not need to be globally unique but also that it
hop as the source Link-Layer address changes. must be swapped at each hop as the source Link-Layer address changes.
This specification extends RFC 4944 [RFC4944] with 2 new Dispatch
types, for Recoverable Fragment (RFRAG) and for the RFRAG
Acknowledgment back. The new 6LoWPAN Dispatch types are taken from
Page 0 [RFC8025] as indicated in Table 1 in Section 9.
In the following sections, a "Datagram_Tag" extends the semantics In the following sections, a "Datagram_Tag" extends the semantics
defined in [RFC4944] Section 5.3."Fragmentation Type and Header". defined in [RFC4944] Section 5.3."Fragmentation Type and Header".
The Datagram_Tag is a locally unique identifier for the datagram from The Datagram_Tag is a locally unique identifier for the datagram from
the perspective of the sender. This means that the Datagram_Tag the perspective of the sender. This means that the Datagram_Tag
identifies a datagram uniquely in the network when associated with identifies a datagram uniquely in the network when associated with
the source of the datagram. As the datagram gets forwarded, the the source of the datagram. As the datagram gets forwarded, the
source changes and the Datagram_Tag must be swapped as detailed in source changes and the Datagram_Tag must be swapped as detailed in
[FRAG-FWD]. [FRAG-FWD].
This specification extends RFC 4944 [RFC4944] with 2 new Dispatch
types, for Recoverable Fragment (RFRAG) and for the RFRAG
Acknowledgment back. The new 6LoWPAN Dispatch types are taken from
Page 0 [RFC8025] as indicated in Table 1 in Section 9.
5.1. Recoverable Fragment Dispatch type and Header 5.1. Recoverable Fragment Dispatch type and Header
In this specification, if the packet is compressed then the size and In this specification, if the packet is compressed then the size and
offset of the fragments are expressed with respect to the Compressed offset of the fragments are expressed with respect to the Compressed
Form of the packet form as opposed to the uncompressed (native) Form of the packet form as opposed to the uncompressed (native) form.
packet form.
The format of the fragment header is shown in Figure 1. It is the The format of the fragment header is shown in Figure 1. It is the
same for all fragments. The format has a length and an offset, as same for all fragments though the Fragment_Offset is overloaded. The
well as a Sequence field. This would be redundant if the offset was format has a length and an offset, as well as a Sequence field. This
computed as the product of the Sequence by the length, but this is would be redundant if the offset was computed as the product of the
not the case. The position of a fragment in the reassembly buffer is Sequence by the length, but this is not the case. The position of a
neither correlated with the value of the Sequence field nor with the fragment in the reassembly buffer is neither correlated with the
order in which the fragments are received. This enables value of the Sequence field nor with the order in which the fragments
refragmenting to cope with an MTU deduction, see the example of the are received. This enables refragmenting to cope with an MTU
fragment seq. 5 that is retried end-to-end as smaller fragments seq. deduction, see the example of the fragment seq. 5 that is retried
13 and 14 in Section 6.2. end-to-end as smaller fragments seq. 13 and 14 in Section 6.2.
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.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 0|E| Datagram_Tag | |1 1 1 0 1 0 0|E| Datagram_Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Sequence| Fragment_Size | Fragment_Offset | |X| Sequence| Fragment_Size | Fragment_Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X set == Ack-Request X set == Ack-Request
Figure 1: RFRAG Dispatch type and Header Figure 1: RFRAG Dispatch type and Header
There is no requirement on the receiver to check for contiguity of X: 1 bit; Ack-Request: when set, the fragmenting endpoint requires
the received fragments. The sender knows that the datagram is fully an RFRAG Acknowledgment from the reassembling endpoint.
received when the acknowledged fragments cover the whole datagram.
This may be useful in particular in the case where the MTU changes
and a fragment Sequence is retried with a smaller Fragment_Size, the
remainder of the original fragment being retried with new Sequence
values.
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 Datagram_Size.
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.
X: 1 bit; Ack-Request: when set, the sender requires an RFRAG
Acknowledgment from the receiver.
E: 1 bit; Explicit Congestion Notification; the "E" flag is reset by E: 1 bit; Explicit Congestion Notification; the "E" flag is cleared
the source of the fragment and set by intermediate routers to by the source of the fragment and set by intermediate routers to
signal that this fragment experienced congestion along its path. signal that this fragment experienced congestion along its path.
Fragment_Size: 10-bit unsigned integer; the size of this fragment in Fragment_Size: 10-bit unsigned integer; the size of this fragment in
a unit that depends on the MAC layer technology. Unless a unit that depends on the Link-Layer technology. Unless
overridden by a more specific specification, that unit is the overridden by a more specific specification, that unit is the
byte, which allows fragments up to 1024 bytes. byte, which allows fragments up to 1024 bytes.
Datagram_Tag: 8 bits; an identifier of the datagram that is locally Datagram_Tag: 8 bits; an identifier of the datagram that is locally
unique to the sender. unique to the Link-Layer sender.
Sequence: 5-bit unsigned integer; the sequence number of the Sequence: 5-bit unsigned integer; the sequence number of the
fragment in the acknowledgement bitmap. Fragments are numbered fragment in the acknowledgement bitmap. Fragments are numbered
[0..N] where N is in [0..31]. A Sequence of 0 indicates the first [0..N] where N is in [0..31]. A Sequence of 0 indicates the first
fragment in a datagram, but non-zero values are not indicative of fragment in a datagram, but non-zero values are not indicative of
the position in the reassembly buffer. the position in the reassembly buffer.
Fragment_Offset: 16-bit unsigned integer. Fragment_Offset: 16-bit unsigned integer.
When the Fragment_Offset is set to a non-0 value, its semantics When the Fragment_Offset is set to a non-0 value, its semantics
depend on the value of the Sequence field as follows: depend on the value of the Sequence field as follows:
* For a first fragment (i.e., with a Sequence of 0), this field * For a first fragment (i.e., with a Sequence of 0), this field
indicates the Datagram_Size of the compressed datagram, to help indicates the Datagram_Size of the compressed datagram, to help
the receiver allocate an adapted buffer for the reception and the reassembling endpoint allocate an adapted buffer for the
reassembly operations. The fragment may be stored for local reception and reassembly operations. The fragment may be
reassembly. Alternatively, it may be routed based on the stored for local reassembly. Alternatively, it may be routed
destination IPv6 address. In that case, a VRB state must be based on the destination IPv6 address. In that case, a VRB
installed as described in Section 6.1.1. state must be installed as described in Section 6.1.1.
* When the Sequence is not 0, this field indicates the offset of * When the Sequence is not 0, this field indicates the offset of
the fragment in the Compressed Form of the datagram. The the fragment in the Compressed Form of the datagram. The
fragment may be added to a local reassembly buffer or forwarded fragment may be added to a local reassembly buffer or forwarded
based on an existing VRB as described in Section 6.1.2. based on an existing VRB as described in Section 6.1.2.
A Fragment_Offset that is set to a value of 0 indicates an abort A Fragment_Offset that is set to a value of 0 indicates an abort
condition and all state regarding the datagram should be cleaned condition and all state regarding the datagram should be cleaned
up once the processing of the fragment is complete; the processing up once the processing of the fragment is complete; the processing
of the fragment depends on whether there is a VRB already of the fragment depends on whether there is a VRB already
established for this datagram, and the next hop is still established for this datagram, and the next hop is still
reachable: reachable:
* if a VRB already exists and is not broken, the fragment is to * if a VRB already exists and the next hop is still reachable,
be forwarded along the associated Label Switched Path (LSP) as the fragment is to be forwarded along the associated Label
described in Section 6.1.2, but regardless of the value of the Switched Path (LSP) as described in Section 6.1.2, without
Sequence field; checking the value of the Sequence field;
* else, if the Sequence is 0, then the fragment is to be routed * else, if the Sequence is 0, then the fragment is to be routed
as described in Section 6.1.1, but no state is conserved as described in Section 6.1.1, but no state is conserved
afterwards. In that case, the session if it exists is aborted afterwards. In that case, the session if it exists is aborted
and the packet is also forwarded in an attempt to clean up the and the packet is also forwarded in an attempt to clean up the
next hops along the path indicated by the IPv6 header (possibly next hops along the path indicated by the IPv6 header (possibly
including a routing header). including a routing header).
* else (the Sequence is nonzero 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 Section 6.1.2.
If the fragment cannot be forwarded or routed, then an abort There is no requirement on the reassembling endpoint to check that
RFRAG-ACK is sent back to the source as described in the received fragments are consecutive and non-overlapping. The
Section 6.1.2. fragmenting endpoint knows that the datagram is fully received when
the acknowledged fragments cover the whole datagram, which is always
the case with a FULL bitmap. This may be useful in particular in the
case where the MTU changes and a fragment Sequence is retried with a
smaller Fragment_Size, the remainder of the original fragment being
retried with new Sequence values.
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.
5.2. RFRAG Acknowledgment Dispatch type and Header 5.2. RFRAG Acknowledgment Dispatch type and Header
This specification also defines a 4-byte RFRAG Acknowledgment bitmap This specification also defines a 4-byte RFRAG Acknowledgment bitmap
that is used by the reassembling endpoint to confirm selectively the that is used by the reassembling endpoint to confirm selectively the
reception of individual fragments. A given offset in the bitmap maps reception of individual fragments. A given offset in the bitmap maps
one-to-one with a given sequence number and indicates which fragment one-to-one with a given sequence number and indicates which fragment
is acknowledged as follows: is acknowledged as follows:
1 2 3 1 2 3
skipping to change at page 12, line 20 skipping to change at page 12, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 1|E| Datagram_Tag | |1 1 1 0 1 0 1|E| Datagram_Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFRAG Acknowledgment Bitmap (32 bits) | | RFRAG Acknowledgment Bitmap (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RFRAG Acknowledgment Dispatch type and Header Figure 4: RFRAG Acknowledgment Dispatch type and Header
E: 1 bit; Explicit Congestion Notification Echo E: 1 bit; Explicit Congestion Notification Echo
When set, the sender indicates that at least one of the When set, the fragmenting endpoint indicates that at least one of
acknowledged fragments was received with an Explicit Congestion the acknowledged fragments was received with an Explicit
Notification, indicating that the path followed by the fragments Congestion Notification, indicating that the path followed by the
is subject to congestion. More in Appendix C. fragments is subject to congestion. More in Appendix C.
Datagram_Tag: 8 bits; an identifier of the datagram that is locally
unique to the Link-Layer recipient.
RFRAG Acknowledgment Bitmap: An RFRAG Acknowledgment Bitmap, whereby RFRAG Acknowledgment Bitmap: An RFRAG Acknowledgment Bitmap, whereby
setting the bit at offset x indicates that fragment x was setting the bit at offset x indicates that fragment x was
received, as shown in Figure 2. A NULL bitmap indicates that the received, as shown in Figure 2. A NULL bitmap indicates that the
fragmentation process is aborted. A FULL bitmap indicates that fragmentation process is aborted. A FULL bitmap indicates that
the fragmentation process is complete; all fragments were received the fragmentation process is complete; all fragments were received
at the reassembly endpoint. at the reassembly endpoint.
6. Fragment Recovery 6. Fragment Recovery
The Recoverable Fragment header RFRAG is used to transport a fragment The Recoverable Fragment header RFRAG is used to transport a fragment
and optionally request an RFRAG Acknowledgment that will confirm the and optionally request an RFRAG Acknowledgment that will confirm the
good reception of one or more fragments. An RFRAG Acknowledgment is good reception of one or more fragments. An RFRAG Acknowledgment is
carried as a standalone fragment header (i.e., with no 6LoWPAN carried as a standalone fragment header (i.e., with no 6LoWPAN
payload) in a message that is propagated back to the 6LoWPAN endpoint payload) in a message that is propagated back to the fragmenting
that was the originator of the fragments. To achieve this, each hop endpoint. To achieve this, each hop that performed an MPLS-like
that performed an MPLS-like operation on fragments reverses that operation on fragments reverses that operation for the RFRAG_ACK by
operation for the RFRAG_ACK by sending a frame from the next hop to sending a frame from the next hop to the previous hop as known by its
the previous hop as known by its Link-Layer address in the VRB. The Link-Layer address in the VRB. The Datagram_Tag in the RFRAG_ACK is
Datagram_Tag in the RFRAG_ACK is unique to the receiver and is enough unique to the reassembling endpoint and is enough information for an
information for an intermediate hop to locate the VRB that contains intermediate hop to locate the VRB that contains the Datagram_Tag
the Datagram_Tag used by the previous hop and the Layer-2 information used by the previous hop and the Layer-2 information associated with
associated with it (interface and Link-Layer address). it (interface and Link-Layer address).
The 6LoWPAN endpoint that fragments the packets at the 6LoWPAN level The fragmenting endpoint that fragments the packets at the 6LoWPAN
(the sender) also controls the number of acknowledgments by setting level also controls the number of acknowledgments by setting the Ack-
the Ack-Request flag in the RFRAG packets. The sender may set the Request flag in the RFRAG packets. The fragmenting endpoint may set
Ack-Request flag on any fragment to perform congestion control by the Ack-Request flag on any fragment to perform congestion control by
limiting the number of outstanding fragments, which are the fragments limiting the number of outstanding fragments, which are the fragments
that have been sent but for which reception or loss was not that have been sent but for which reception or loss was not
positively confirmed by the reassembling endpoint. The maximum positively confirmed by the reassembling endpoint. The maximum
number of outstanding fragments is controlled by the Window-Size. It number of outstanding fragments is controlled by the Window-Size. It
is configurable and may vary in case of ECN notification. When the is configurable and may vary in case of ECN notification. When the
6LoWPAN endpoint that reassembles the packets at the 6LoWPAN level endpoint that reassembles the packets at the 6LoWPAN level receives a
(the receiver) receives a fragment with the Ack-Request flag set, it fragment with the Ack-Request flag set, it MUST send an RFRAG
MUST send an RFRAG Acknowledgment back to the originator to confirm Acknowledgment back to the originator to confirm reception of all the
reception of all the fragments it has received so far. fragments it has received so far.
The Ack-Request ('X') set in an RFRAG marks the end of a window. The Ack-Request ('X') set in an RFRAG marks the end of a window.
This flag MUST be set on the last fragment if the sender wishes to This flag MUST be set on the last fragment if the fragmenting
protect the datagram, and it MAY be set in any intermediate fragment endpoint wishes to perform an automatic repeat request (ARQ) process
for the purpose of flow control. for the datagram, and it MAY be set in any intermediate fragment for
the purpose of flow control.
This automatic repeat request (ARQ) process MUST be protected by a This ARQ process MUST be protected by a Retransmission Time Out (RTO)
Retransmission Time Out (RTO) timer, and the fragment that carries timer, and the fragment that carries the 'X' flag MAY be retried upon
the 'X' flag MAY be retried upon a time out for a configurable number a time out for a configurable number of times (see Section 7.1) with
of times (see Section 7.1) with an exponential backoff. Upon an exponential backoff. Upon exhaustion of the retries the
exhaustion of the retries the sender may either abort the fragmenting endpoint may either abort the transmission of the
transmission of the datagram or resend the first fragment with an 'X' datagram or resend the first fragment with an 'X' flag set in order
flag set in order to establish a new path for the datagram and obtain to establish a new path for the datagram and obtain the list of
the list of fragments that were received over the old path in the fragments that were received over the old path in the acknowledgment
acknowledgment bitmap. When the sender of the fragment knows that an bitmap. When the knows that an underlying link-layer mechanism
underlying link-layer mechanism protects the fragments, it may protects the fragments, it may refrain from using the RFRAG
refrain from using the RFRAG Acknowledgment mechanism, and never set Acknowledgment mechanism, and never set the Ack-Request bit.
the Ack-Request bit.
The receiver MAY issue unsolicited acknowledgments. An unsolicited The reassembling endpoint MAY issue unsolicited acknowledgments. An
acknowledgment signals to the sender endpoint that it can resume unsolicited acknowledgment signals to the fragmenting endpoint that
sending if it had reached its maximum number of outstanding it can resume sending in case it has reached its maximum number of
fragments. Another use is to inform the sender that the reassembling outstanding fragments. Another use is to inform the fragmenting
endpoint aborted the processing of an individual datagram. endpoint that the reassembling endpoint aborted the processing of an
individual datagram.
The RFRAG Acknowledgment has an ECN indication for flow control (see The RFRAG Acknowledgment carries an ECN indication for flow control
Appendix C). The receiver of a fragment with the 'E' (ECN) flag set (see Appendix C). The reassembling endpoint of a fragment with the
MUST echo that information by setting the 'E' (ECN) flag in the next 'E' (ECN) flag set MUST echo that information at most once by setting
RFRAG Acknowledgment. the 'E' (ECN) flag in the next RFRAG Acknowledgment.
In order to protect the datagram, the sender transfers a controlled In order to protect the datagram, the fragmenting endpoint transfers
number of fragments and flags the last fragment of a window with an a controlled number of fragments and flags the last fragment of a
RFRAG Acknowledgment Request. The receiver MUST acknowledge a window with an RFRAG Acknowledgment Request. The reassembling
fragment with the acknowledgment request bit set. If any fragment endpoint MUST acknowledge a fragment with the acknowledgment request
immediately preceding an acknowledgment request is still missing, the bit set. If any fragment immediately preceding an acknowledgment
receiver MAY intentionally delay its acknowledgment to allow in- request is still missing, the reassembling endpoint MAY intentionally
transit fragments to arrive. Because it might defeat the round-trip delay its acknowledgment to allow in-transit fragments to arrive.
delay computation, delaying the acknowledgment should be configurable
and not enabled by default. Because it might defeat the round-trip delay computation, delaying
the acknowledgment should be configurable and not enabled by default.
When enough fragments are received to cover the whole datagram, the When enough fragments are received to cover the whole datagram, the
receiving endpoint reconstructs the packet, passes it to the upper reassembling endpoint reconstructs the packet, passes it to the upper
layer, sends an RFRAG Acknowledgment on the reverse path with a FULL layer, sends an RFRAG Acknowledgment on the reverse path with a FULL
bitmap, and arms a short timer, e.g., on the order of an average bitmap, and arms a short timer, e.g., on the order of an average
round-trip delay in the network. The FULL bitmap is used as opposed round-trip delay in the network. The FULL bitmap is used as opposed
to a bitmap that acknowledges only the received fragments to let the to a bitmap that acknowledges only the received fragments to let the
intermediate nodes know that the datagram is fully received. As the intermediate nodes know that the datagram is fully received. As the
timer runs, the receiving endpoint absorbs the fragments that were timer runs, the reassembling endpoint absorbs the fragments that were
still in flight for that datagram without creating a new state. The still in flight for that datagram without creating a new state,
receiving endpoint aborts the communication if it keeps going on acknowledging the ones that that bear an Ack-Request with an FRAG
beyond the duration of the timer. Acknowledgment and the FULL bitmap. The reassembling endpoint aborts
the communication if fragments with matching source and Datagram-Tag
continue to be received after the timer expires.
Note that acknowledgments might consume precious resources so the use Note that acknowledgments might consume precious resources so the use
of unsolicited acknowledgments should be configurable and not enabled of unsolicited acknowledgments should be configurable and not enabled
by default. by default.
An observation is that streamlining forwarding of fragments generally An observation is that streamlining forwarding of fragments generally
reduces the latency over the LLN mesh, providing room for retries reduces the latency over the LLN mesh, providing room for retries
within existing upper-layer reliability mechanisms. The sender within existing upper-layer reliability mechanisms. The fragmenting
protects the transmission over the LLN mesh with a retry timer that endpoint protects the transmission over the LLN mesh with a retry
is configured for a use case and may be adapted dynamically, e.g., timer that is configured for a use case and may be adapted
according to the method detailed in [RFC6298]. It is expected that dynamically, e.g., according to the method detailed in [RFC6298]. It
the upper layer retries obey the recommendations in [RFC8085], in is expected that the upper layer retries obey the recommendations in
which case a single round of fragment recovery should fit within the [RFC8085], in which case a single round of fragment recovery should
upper layer recovery timers. fit within the upper layer recovery timers.
Fragments are sent in a round-robin fashion: the sender sends all the Fragments are sent in a round-robin fashion: the fragmenting endpoint
fragments for a first time before it retries any lost fragment; lost sends all the fragments of the datagram for a first time before it
fragments are retried in sequence, oldest first. This mechanism retries any lost fragment; lost fragments are retried in sequence,
enables the receiver to acknowledge fragments that were delayed in oldest first through the whole datagram. This mechanism enables the
reassembling endpoint to acknowledge fragments that were delayed in
the network before they are retried. the network before they are retried.
When a single frequency is used by contiguous hops, the sender should When a single radio frequency is used by contiguous hops, the
insert a delay between the frames (e.g., carrying fragments) that are fragmenting endpoint should insert a delay between the frames (e.g.,
sent to the same next hop. The delay should cover multiple carrying fragments) that are sent to the same next hop. The delay
transmissions so as to let a frame progress a few hops and avoid should cover multiple transmissions so as to let a frame progress a
hidden terminal issues. This precaution is not required on channel few hops and avoid hidden terminal issues. This precaution is not
hopping technologies such as Time Slotted Channel Hopping (TSCH) required on channel hopping technologies such as Time Slotted Channel
[RFC6554], where nodes that communicate at Layer-2 are scheduled to Hopping (TSCH) [RFC6554], where nodes that communicate at Layer-2 are
send and receive respectively, and different hops operate on scheduled to send and receive respectively, and different hops
different channels. operate on different channels.
6.1. Forwarding Fragments 6.1. Forwarding Fragments
It is assumed that the first fragment is large enough to carry the It is assumed that the first fragment is large enough to carry the
IPv6 header and make routing decisions. If that is not so, then this IPv6 header and make routing decisions. If that is not so, then this
specification MUST NOT be used. specification MUST NOT be used.
This specification extends the Virtual Reassembly Buffer (VRB) This specification extends the Virtual Reassembly Buffer (VRB)
technique to forward fragments with no intermediate reconstruction of technique to forward fragments with no intermediate reconstruction of
the entire packet. It inherits operations like Datagram_Tag the entire packet. It inherits operations like Datagram_Tag
switching and using a timer to clean the VRB once the traffic ceases. switching and using a timer to clean the VRB once the traffic ceases.
The first fragment carries the IP header and it is routed all the way The first fragment carries the IP header and creates a path from the
from the fragmenting endpoint to the reassembling endpoint. Upon fragmenting endpoint to the reassembling endpoint that all the other
receiving the first fragment, the routers along the path install a fragments follow. Upon receiving the first fragment, the routers
label-switched path (LSP), and the following fragments are label- along the path install a label-switched path (LSP), and the following
switched along that path. As a consequence, the next fragments can fragments are label-switched along that path. As a consequence, the
only follow the path that was set up by the first fragment and cannot next fragments can only follow the path that was set up by the first
follow an alternate route. The Datagram_Tag is used to carry the fragment and cannot follow an alternate route. The Datagram_Tag is
label, which is swapped in each hop. All fragments follow the same used to carry the label, which is swapped in each hop.
path and fragments are delivered in the order in which they are sent.
6.1.1. Receiving the first fragment 6.1.1. Receiving the first fragment
In Route-Over mode, the source and destination Link-Layer addresses In Route-Over mode, the source and destination Link-Layer addresses
in a frame change at each hop. The label that is formed and placed in a frame change at each hop. The label that is formed and placed
in the Datagram_Tag is associated with the source Link-Layer address in the Datagram_Tag by the sender is associated with the source Link-
and only valid (and unique) for that source Link-Layer address. Upon Layer address and only valid (and temporarily unique) for that source
receiving the first fragment (i.e., with a Sequence of zero), an Link-Layer address.
intermediate router creates a VRB and the associated LSP state for
the tuple (source Link-Layer address, Datagram_Tag) and the fragment
is forwarded along the IPv6 route that matches the destination IPv6
address in the IPv6 header as prescribed by [FRAG-FWD], where the
receiving endpoint allocates a reassembly buffer.
The LSP state enables to match the (previous Link-Layer address, Upon receiving the first fragment (i.e., with a Sequence of 0), an
Datagram_Tag) in an incoming fragment to the tuple (next Link-Layer intermediate router creates a VRB and the associated LSP state
address, swapped Datagram_Tag) used in the forwarded fragment and indexed by the incoming interface, the previous-hop Link-Layer
points at the VRB. In addition, the router also forms a reverse LSP address, and the Datagram_Tag, and forwards the fragment along the
state indexed by the MAC address of the next hop and the swapped IPv6 route that matches the destination IPv6 address in the IPv6
Datagram_Tag. This reverse LSP state also points at the VRB and header until it reaches the reassembling endpoint, as prescribed by
enables matching the (next Link-Layer address, swapped_Datagram_Tag) [FRAG-FWD]. The LSP state enables to match the next incoming
found in an RFRAG Acknowledgment to the tuple (previous Link-Layer fragments of a datagram to the abstract forwarding information of
address, Datagram_Tag) used when forwarding a Fragment Acknowledgment next interface, source and next-hop Link-Layer addresses, and swapped
(RFRAG-ACK) back to the sender endpoint. Datagram_Tag.
The first fragment may be received a second time, indicating that it In addition, the router also forms a reverse LSP state indexed by the
did not reach the destination and was retried. In that case, it interface to the next hop, the Link-Layer address the router uses as
SHOULD follow the same path as the first occurrence. It is up to source for that datagram, and the swapped Datagram_Tag. This reverse
sending endpoint to determine whether to abort a transmission and LSP state enables matching the tuple (interface, destination Link-
then retry it from scratch, which may build an entirely new path. Layer address, Datagram_Tag) found in an RFRAG Acknowledgment to the
abstract forwarding information (previous interface, previous Link-
Layer address, Datagram_Tag) used to forward the Fragment
Acknowledgment (RFRAG-ACK) back to the fragmenting endpoint.
6.1.2. Receiving the next fragments 6.1.2. Receiving the next fragments
Upon receiving the next fragment (i.e., with a non-zero Sequence), an Upon receiving the next fragment (i.e., with a non-zero Sequence), an
intermediate router looks up a LSP indexed by the tuple (Link-Layer intermediate router looks up a LSP indexed by the tuple (incoming
address, Datagram_Tag) found in the fragment. If it is found, the interface, previous-hop Link-Layer address, Datagram_Tag) found in
router forwards the fragment using the associated VRB as prescribed the fragment. If it is found, the router forwards the fragment using
by [FRAG-FWD]. the associated VRB as prescribed by [FRAG-FWD].
If the VRB for the tuple is not found, the router builds an RFRAG-ACK If the VRB for the tuple is not found, the router builds an RFRAG-ACK
to abort the transmission of the packet. The resulting message has to abort the transmission of the packet. The resulting message has
the following information: the following information:
* The source and destination Link-Layer addresses are swapped from * The source and destination Link-Layer addresses are swapped from
those found in the fragment those found in the fragment and the same interface is used
* The Datagram_Tag is set to the Datagram_Tag found in the fragment * The Datagram_Tag is set to the Datagram_Tag found in the fragment
* A NULL bitmap is used to signal the abort condition * A NULL bitmap is used to signal the abort condition
At this point the router is all set and can send the RFRAG-ACK back At this point the router is all set and can send the RFRAG-ACK back
to the previous router. The RFRAG-ACK should normally be forwarded to the previous router. The RFRAG-ACK should normally be forwarded
all the way to the source using the reverse LSP state in the VRBs in all the way to the source using the reverse LSP state in the VRBs in
the intermediate routers as described in the next section. the intermediate routers as described in the next section.
[FRAG-FWD] indicates that the receiving endpoint stores "the actual [FRAG-FWD] indicates that the reassembling endpoint stores "the
packet data from the fragments received so far, in a form that makes actual packet data from the fragments received so far, in a form that
it possible to detect when the whole packet has been received and can makes it possible to detect when the whole packet has been received
be processed or forwarded". How this is computed is implementation and can be processed or forwarded". How this is computed is
specific but relies on receiving all the bytes up to the implementation specific but relies on receiving all the bytes up to
Datagram_Size indicated in the first fragment. An implementation may the Datagram_Size indicated in the first fragment. An implementation
receive overlapping fragments as the result of retries after an MTU may receive overlapping fragments as the result of retries after an
change. MTU change.
6.2. Receiving RFRAG Acknowledgments 6.2. Receiving RFRAG Acknowledgments
Upon receipt of an RFRAG-ACK, the router looks up a reverse LSP Upon receipt of an RFRAG-ACK, the router looks up a reverse LSP
indexed by the tuple (Link-Layer address, Datagram_Tag), which are indexed by the interface and destination Link-Layer address of the
respectively the source Link-Layer address of the received frame and received frame and the received Datagram_Tag in the RFRAG-ACK. If it
the received Datagram_Tag. If it is found, the router forwards the is found, the router forwards the fragment using the associated VRB
fragment using the associated VRB as prescribed by [FRAG-FWD], but as prescribed by [FRAG-FWD], but using the reverse LSP so that the
using the reverse LSP so that the RFRAG-ACK flows back to the sender RFRAG-ACK flows back to the fragmenting endpoint.
endpoint.
If the reverse LSP is not found, the router MUST silently drop the If the reverse LSP is not found, the router MUST silently drop the
RFRAG-ACK message. RFRAG-ACK message.
Either way, if the RFRAG-ACK indicates that the fragment was entirely Either way, if the RFRAG-ACK indicates that the fragment was entirely
received (FULL bitmap), it arms a short timer, and upon timeout, the received (FULL bitmap), it arms a short timer, and upon timeout, the
VRB and all the associated state are destroyed. Until the timer VRB and all the associated state are destroyed. Until the timer
elapses, fragments of that datagram may still be received, e.g. if elapses, fragments of that datagram may still be received, e.g. if
the RFRAG-ACK was lost on the way back and the source retried the the RFRAG-ACK was lost on the path back and the source retried the
last fragment. In that case, the router forwards the fragment last fragment. In that case, the router forwards the fragment
according to the state in the VRB. according to the state in the VRB.
This specification does not provide a method to discover the number This specification does not provide a method to discover the number
of hops or the minimal value of MTU along those hops. But should the of hops or the minimal value of MTU along those hops. In a typical
minimal MTU decrease, it is possible to retry a long fragment (say case, the MTU is constant and the same across the network. But
Sequence of 5) with several shorter fragments with a Sequence that should the minimal MTU along the path decrease, it is possible to
was not used before (e.g., 13 and 14). Fragment 5 is marked as retry a long fragment (say Sequence of 5) with several shorter
abandoned and will not be retried anymore. Note that when thi fragments with a Sequence that was not used before (e.g., 13 and 14).
smechanism is in place, it is hard to predict the total number of Fragment 5 is marked as abandoned and will not be retried anymore.
fragments that will be needed or the final shape of the bitmap that Note that when this mechanism is in place, it is hard to predict the
would cover the whole packet. This is why the FULL bitmap is used total number of fragments that will be needed or the final shape of
when the receiving endpoint gets the whole datagram regardless of the bitmap that would cover the whole packet. This is why the FULL
which fragments were actually used to do so. Intermediate nodes will bitmap is used when the reassembling endpoint gets the whole datagram
unabiguously knw that the process is complete. Note that Path MTU regardless of which fragments were actually used to do so.
Discovery is out of scope for this document. Intermediate nodes will unabiguously know that the process is
complete. Note that Path MTU Discovery is out of scope for this
document.
6.3. Aborting the Transmission of a Fragmented Packet 6.3. Aborting the Transmission of a Fragmented Packet
A reset is signaled on the forward path with a pseudo fragment that A reset is signaled on the forward path with a pseudo fragment that
has the Fragment_Offset, Sequence, and Fragment_Size all set to 0, has the Fragment_Offset set to 0. The sender of a reset SHOULD also
and no data. set the Sequence and Fragment_Size field to 0.
When the sender or a router on the way decides that a packet should When the fragmenting endpoint or a router on the path decides that a
be dropped and the fragmentation process aborted, it generates a packet should be dropped and the fragmentation process aborted, it
reset pseudo fragment and forwards it down the fragment path. generates a reset pseudo fragment and forwards it down the fragment
path.
Each router next along the path the way forwards the pseudo fragment Each router next along the path the way forwards the pseudo fragment
based on the VRB state. If an acknowledgment is not requested, the based on the VRB state. If an acknowledgment is not requested, the
VRB and all associated state are destroyed. VRB and all associated state are destroyed.
Upon reception of the pseudo fragment, the receiver cleans up all Upon reception of the pseudo fragment, the reassembling endpoint
resources for the packet associated with the Datagram_Tag. If an cleans up all resources for the packet associated with the
acknowledgment is requested, the receiver responds with a NULL Datagram_Tag. If an acknowledgment is requested, the reassembling
bitmap. endpoint responds with a NULL bitmap.
The other way around, the receiver might need to abort the process of The other way around, the reassembling endpoint might need to abort
a fragmented packet for internal reasons, for instance if it is out the processing of a fragmented packet for internal reasons, for
of reassembly buffers, already uses all 256 possible values of the instance if it is out of reassembly buffers, already uses all 256
Datagram_Tag, or if it keeps receiving fragments beyond a reasonable possible values of the Datagram_Tag, or if it keeps receiving
time while it considers that this packet is already fully reassembled fragments beyond a reasonable time while it considers that this
and was passed to the upper layer. In that case, the receiver SHOULD packet is already fully reassembled and was passed to the upper
indicate so to the sender with a NULL bitmap in an RFRAG layer. In that case, the reassembling endpoint SHOULD indicate so to
the fragmenting endpoint with a NULL bitmap in an RFRAG
Acknowledgment. The RFRAG Acknowledgment is forwarded all the way Acknowledgment. The RFRAG Acknowledgment is forwarded all the way
back to the source of the packet and cleans up all resources on the back to the source of the packet and cleans up all resources on the
way. Upon an acknowledgment with a NULL bitmap, the sender endpoint path. Upon an acknowledgment with a NULL bitmap, the fragmenting
MUST abort the transmission of the fragmented datagram with one endpoint MUST abort the transmission of the fragmented datagram with
exception: In the particular case of the first fragment, it MAY one exception: In the particular case of the first fragment, it MAY
decide to retry via an alternate next hop instead. decide to retry via an alternate next hop instead.
6.4. Applying Recoverable Fragmentation along a Diverse Path 6.4. Applying Recoverable Fragmentation along a Diverse Path
The text above can be read with the assumption of a serial path The text above can be read with the assumption of a serial path
between a source and a destination. Section 4.5.3 of the "6TiSCH between a source and a destination. Section 4.5.3 of the "6TiSCH
Architecture" [I-D.ietf-6tisch-architecture] defines the concept of a Architecture" [I-D.ietf-6tisch-architecture] defines the concept of a
Track that can be a complex path between a source and a destination Track that can be a complex path between a source and a destination
with Packet ARQ, Replication, Elimination and Overhearing (PAREO) with Packet ARQ, Replication, Elimination and Overhearing (PAREO)
along the Track. This specification can be used along any subset of along the Track. This specification can be used along any subset of
the complex Track where the first fragment is flooded. The last the complex Track where the first fragment is flooded. The last
RFRAG Acknowledgment is flooded on that same subset in the reverse RFRAG Acknowledgment is flooded on that same subset in the reverse
direction. Intermediate RFRAG Acknowledgments can be flooded on any direction. Intermediate RFRAG Acknowledgments can be flooded on any
sub-subset of that reverse subset that reach back to the source. sub-subset of that reverse subset that reach back to the source.
7. Management Considerations 7. Management Considerations
This specification extends "On Forwarding 6LoWPAN Fragments over a This specification extends "On Forwarding 6LoWPAN Fragments over a
Multihop IPv6 Network" [FRAG-FWD] and requires the same parameters in Multihop IPv6 Network" [FRAG-FWD] and requires the same parameters in
the receiver and on intermediate nodes. There is no new parameter as the reassembling endpoint and on intermediate nodes. There is no new
echoing ECN is always on. These parameters typically include the parameter as echoing ECN is always on. These parameters typically
reassembly time-out at the receiver and an inactivity clean-up timer include the reassembly time-out at the reassembling endpoint and an
on the intermediate nodes, and the number of messages that can be inactivity clean-up timer on the intermediate nodes, and the number
processed in parallel in all nodes. of messages that can be processed in parallel in all nodes.
The configuration settings introduced by this specification only The configuration settings introduced by this specification only
apply to the sender, which is in full control of the transmission. apply to the fragmenting endpoint, which is in full control of the
LLNs vary a lot in size (there can be thousands of nodes in a mesh), transmission. LLNs vary a lot in size (there can be thousands of
in speed (from 10 Kbps to several Mbps at the PHY layer), in traffic nodes in a mesh), in speed (from 10 Kbps to several Mbps at the PHY
density, and in optimizations that are desired (e.g., the selection layer), in traffic density, and in optimizations that are desired
of a RPL [RFC6550] Objective Function [RFC6552] impacts the shape of (e.g., the selection of a RPL [RFC6550] Objective Function [RFC6552]
the routing graph). impacts the shape of the routing graph).
For that reason, only a very generic guidance can be given on the For that reason, only a very generic guidance can be given on the
settings of the sender and on whether complex algorithms are needed settings of the fragmenting endpoint and on whether complex
to perform flow control or estimate the round-trip time. To cover algorithms are needed to perform flow control or estimate the round-
the most complex use cases, this specification enables the sender to trip time. To cover the most complex use cases, this specification
vary the fragment size, the window size, and the inter-frame gap, enables the fragmenting endpoint to vary the fragment size, the
based on the number of losses, the observed variations of the round- window size, and the inter-frame gap, based on the number of losses,
trip time and the setting of the ECN bit. the observed variations of the round-trip time and the setting of the
ECN bit.
7.1. Protocol Parameters 7.1. Protocol Parameters
The management system SHOULD be capable of providing the parameters The management system SHOULD be capable of providing the parameters
listed in this section and an implementation MUST abide by those listed in this section and an implementation MUST abide by those
parameters and in particular never exceed the minimum and maximum parameters and in particular never exceed the minimum and maximum
configured boundaries. configured boundaries.
An implementation must control the rate at which it sends packets An implementation must control the rate at which it sends packets
over the same path to allow the next hop to forward a packet before over the same path to allow the next hop to forward a packet before
skipping to change at page 19, line 33 skipping to change at page 19, line 40
(Fragment_Size), and insert an inter-frame gap that is longer than (Fragment_Size), and insert an inter-frame gap that is longer than
necessary. In a large network where nodes contend for the bandwidth, necessary. In a large network where nodes contend for the bandwidth,
a larger Fragment_Size consumes less bandwidth but also reduces a larger Fragment_Size consumes less bandwidth but also reduces
fluidity and incurs higher chances of loss in transmission. This is fluidity and incurs higher chances of loss in transmission. This is
controlled by the following parameters: controlled by the following parameters:
MinFragmentSize: The MinFragmentSize is the minimum value for the MinFragmentSize: The MinFragmentSize is the minimum value for the
Fragment_Size. Fragment_Size.
OptFragmentSize: The OptFragmentSize is the value for the OptFragmentSize: The OptFragmentSize is the value for the
Fragment_Size that the sender should use to start with. It is Fragment_Size that the fragmenting endpoint should use to start
greater than or equal to MinFragmentSize. It is less than or with. It is greater than or equal to MinFragmentSize. It is less
equal to MaxFragmentSize. For the first fragment, it must account than or equal to MaxFragmentSize. For the first fragment, it must
for the expansion of the IPv6 addresses and of the Hop Limit field account for the expansion of the IPv6 addresses and of the Hop
within MTU. For all fragments, it is a balance between the Limit field within MTU. For all fragments, it is a balance
expected fluidity and the overhead of MAC and 6LoWPAN headers. between the expected fluidity and the overhead of Link-Layer and
For a small MTU, the idea is to keep it close to the maximum, 6LoWPAN headers. For a small MTU, the idea is to keep it close to
whereas for larger MTUs, it might makes sense to keep it short the maximum, whereas for larger MTUs, it might makes sense to keep
enough, so that the duty cycle of the transmitter is bounded, it short enough, so that the duty cycle of the transmitter is
e.g., to transmit at least 10 frames per second. bounded, e.g., to transmit at least 10 frames per second.
MaxFragmentSize: The MaxFragmentSize is the maximum value for the MaxFragmentSize: The MaxFragmentSize is the maximum value for the
Fragment_Size. It MUST be lower than the minimum MTU along the Fragment_Size. It MUST be lower than the minimum MTU along the
path. A large value augments the chances of buffer bloat and path. A large value augments the chances of buffer bloat and
transmission loss. The value MUST be less than 512 if the unit transmission loss. The value MUST be less than 512 if the unit
that is defined for the PHY layer is the byte. that is defined for the PHY layer is the byte.
MinWindowSize: The minimum value of Window_Size that the sender can MinWindowSize: The minimum value of Window_Size that the fragmenting
use. A value of 1 is RECOMMENDED. endpoint can use. A value of 1 is RECOMMENDED.
OptWindowSize: The OptWindowSize is the value for the Window_Size OptWindowSize: The OptWindowSize is the value for the Window_Size
that the sender should use to start with. It is greater than or that the fragmenting endpoint should use to start with. It is
equal to MinWindowSize. It is less than or equal to greater than or equal to MinWindowSize. It is less than or equal
MaxWindowSize. A rule of a thumb for OptWindowSize could be an to MaxWindowSize. A rule of a thumb for OptWindowSize could be an
estimation of the one-way trip time divided by the inter-frame estimation of the one-way trip time divided by the inter-frame
gap. If the acknowledgement back is too costly, it is possible to gap. If the acknowledgement back is too costly, it is possible to
set this to 32, meaning that only the last Fragment is set this to 32, meaning that only the last Fragment is
acknowledged in the first round. acknowledged in the first round.
MaxWindowSize: The maximum value of Window_Size that the sender can MaxWindowSize: The maximum value of Window_Size that the fragmenting
use. The value MUST be strictly less than 33. endpoint can use. The value MUST be strictly less than 33.
An implementation may perform its estimate of the RTO or use a An implementation may perform its estimate of the RTO or use a
configured one. The ARQ process is controlled by the following configured one. The ARQ process is controlled by the following
parameters: parameters:
MinARQTimeOut: The minimum amount of time a node should wait for an MinARQTimeOut: The minimum amount of time a node should wait for an
RFRAG Acknowledgment before it takes the next action. It MUST be RFRAG Acknowledgment before it takes the next action. It MUST be
more than the maximum expected round-trip time in the respective more than the maximum expected round-trip time in the respective
network. network.
OptARQTimeOut: The initial value of the RTO, which is the amount of OptARQTimeOut: The initial value of the RTO, which is the amount of
time that a sender should wait for an RFRAG Acknowledgment before time that a fragmenting endpoint should wait for an RFRAG
it takes the next action. It is greater than or equal to Acknowledgment before it takes the next action. It is greater
MinARQTimeOut. It is less than or equal to MaxARQTimeOut. See than or equal to MinARQTimeOut. It is less than or equal to
Appendix C for recommendations on computing the round-trip time. MaxARQTimeOut. See Appendix C for recommendations on computing
By default a value of 3 times the maximum expected round-trip time the round-trip time. By default a value of 3 times the maximum
in the respective network is RECOMMENDED. expected round-trip time in the respective network is RECOMMENDED.
MaxARQTimeOut: The maximum amount of time a node should wait for the MaxARQTimeOut: The maximum amount of time a node should wait for the
RFRAG Acknowledgment before it takes the next action. It must RFRAG Acknowledgment before it takes the next action. It must
cover the longest expected round-trip time, and be several times cover the longest expected round-trip time, and be several times
less than the time-out that covers the recomposition buffer at the less than the time-out that covers the recomposition buffer at the
receiver, which is typically on the order of the minute. An upper reassembling endpoint, which is typically on the order of the
bound can be estimated to ensure that the datagram is either fully minute. An upper bound can be estimated to ensure that the
transmitted or dropped before an upper layer decides to retry it. datagram is either fully transmitted or dropped before an upper
layer decides to retry it.
MaxFragRetries: The maximum number of retries for a particular MaxFragRetries: The maximum number of retries for a particular
fragment. A default value of 3 is RECOMMENDED. An upper bound fragment. A default value of 3 is RECOMMENDED. An upper bound
can be estimated to ensure that the datagram is either fully can be estimated to ensure that the datagram is either fully
transmitted or dropped before an upper layer decides to retry it. transmitted or dropped before an upper layer decides to retry it.
MaxDatagramRetries: The maximum number of retries from scratch for a MaxDatagramRetries: The maximum number of retries from scratch for a
particular datagram. A default value of 1 is RECOMMENDED. An particular datagram. A default value of 1 is RECOMMENDED. An
upper bound can be estimated to ensure that the datagram is either upper bound can be estimated to ensure that the datagram is either
fully transmitted or dropped before an upper layer decides to fully transmitted or dropped before an upper layer decides to
retry it. retry it.
An implementation may be capable of performing flow control based on An implementation may be capable of performing flow control based on
ECN; see in Appendix C. This is controlled by the following ECN; see in Appendix C. This is controlled by the following
parameter: parameter:
UseECN: Indicates whether the sender should react to ECN. The UseECN: Indicates whether the fragmenting endpoint should react to
sender may react to ECN by varying the Window_Size between ECN. The fragmenting endpoint may react to ECN by varying the
MinWindowSize and MaxWindowSize, varying the Fragment_Size between Window_Size between MinWindowSize and MaxWindowSize, varying the
MinFragmentSize and MaxFragmentSize, and/or by increasing or Fragment_Size between MinFragmentSize and MaxFragmentSize, and/or
reducing the inter-frame gap. by increasing or reducing the inter-frame gap. With this
specification, if UseECN is set and a fragmenting endpoint detects
a congestion, it resets the Window_Size to 1 till 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.
7.2. Observing the network 7.2. Observing the network
The management system should monitor the number of retries and of ECN The management system should monitor the number of retries and of ECN
settings that can be observed from the perspective of both the sender settings that can be observed from the perspective of both the
and the receiver with regards to the other endpoint. It may then fragmenting endpoint and the reassembling endpoint with regards to
tune the optimum size of Fragment_Size and of Window_Size, the other endpoint. It may then tune the optimum size of
OptFragmentSize, and OptWindowSize, respectively, at the sender Fragment_Size and of Window_Size, OptFragmentSize, and OptWindowSize,
towards a particular receiver, applicable to the next datagrams. The respectively, at the fragmenting endpoint towards a particular
values should be bounded by the expected number of hops and reduced reassembling endpoint, applicable to the next datagrams. The values
beyond that when the number of datagrams that can traverse an should be bounded by the expected number of hops and reduced beyond
intermediate point may exceed its capacity and cause a congestion that when the number of datagrams that can traverse an intermediate
loss. The inter-frame gap is another tool that can be used to point may exceed its capacity and cause a congestion loss. The
increase the spacing between fragments of the same datagram and inter-frame gap is another tool that can be used to increase the
reduce the ratio of time when a particular intermediate node holds a spacing between fragments of the same datagram and reduce the ratio
fragment of that datagram. of time when a particular intermediate node holds a fragment of that
datagram.
8. Security Considerations 8. Security Considerations
This document specifies an instantiation of a 6LoWPAN Fragment This document specifies an instantiation of a 6FF technique and
Forwarding technique. [FRAG-FWD] provides the generic description of inherits from the generic description in [FRAG-FWD]. The
Fragment Forwarding and this specification inherits from it. The considerations in the Security Section of [FRAG-FWD] equally apply to
generic considerations in the Security sections of [FRAG-FWD] apply this document.
equally to this document.
In addition to the threats detailed therein, an attacker that is on-
path can prematurely end the transmission of a datagram by sending a
RFRAG Acknowledgment to the fragmenting endpoint. It can also cause
extra transmissions of fragments by resetting bits in the RFRAG
Acknowledgment bitmap, and of RFRAG Acknowledgments by forcing the
Ack-Request bit in fragments that it forwards. As indicated in
[FRAG-FWD], Secure joining and the Link-Layer security are REQUIRED
to protect against those attacks.
This specification does not recommend a particular algorithm for the This specification does not recommend a particular algorithm for the
estimation of the duration of the RTO that covers the detection of estimation of the duration of the RTO that covers the detection of
the loss of a fragment with the 'X' flag set; regardless, an attacker the loss of a fragment with the 'X' flag set; regardless, an attacker
on the path may slow down or discard packets, which in turn can on the path may slow down or discard packets, which in turn can
affect the throughput of fragmented packets. affect the throughput of fragmented packets.
Compared to "Transmission of IPv6 Packets over IEEE 802.15.4 Compared to "Transmission of IPv6 Packets over IEEE 802.15.4
Networks" [RFC4944], this specification reduces the Datagram_Tag to 8 Networks" [RFC4944], this specification reduces the Datagram_Tag to 8
bits and the tag wraps faster than with [RFC4944]. But for a bits and the tag wraps faster than with [RFC4944]. But for a
constrained network where a node is expected to be able to hold only 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. one or a few large packets in memory, 256 is still a large number.
Also, the acknowledgement mechanism allows cleaning up the state Also, the acknowledgement mechanism allows cleaning up the state
rapidly once the packet is fully transmitted or aborted. rapidly once the packet is fully transmitted or aborted.
The abstract Virtual Recovery Buffer inherited from [FRAG-FWD] may be The abstract Virtual Recovery Buffer inherited from [FRAG-FWD] may be
used to perform a Denial-of-Service (DoS) attack against the used to perform a Denial-of-Service (DoS) attack against the
intermediate Routers since the routers need to maintain a state per intermediate Routers since the routers need to maintain a state per
flow. The particular VRB implementation technique described in flow. The particular VRB implementation technique described in
[I-D.ietf-lwig-6lowpan-virtual-reassembly] allows realigning which [LWIG-FRAG] allows realigning which data goes in which fragment,
data goes in which fragment, which causes the intermediate node to which causes the intermediate node to store a portion of the data,
store a portion of the data, which adds an attack vector that is not which adds an attack vector that is not present with this
present with this specification. With this specification, the data specification. With this specification, the data that is transported
that is transported in each fragment is conserved and the state to in each fragment is conserved and the state to keep does not include
keep does not include any data that would not fit in the previous any data that would not fit in the previous fragment.
fragment.
9. IANA Considerations 9. IANA Considerations
This document allocates 2 patterns for a total of 4 dispatch values This document allocates 2 patterns for a total of 4 dispatch values
in Page 0 for recoverable fragments from the "Dispatch Type Field" in Page 0 for recoverable fragments from the "Dispatch Type Field"
registry that was created by "Transmission of IPv6 Packets over IEEE registry that was created by "Transmission of IPv6 Packets over IEEE
802.15.4 Networks" [RFC4944] and reformatted by "6LoWPAN Paging 802.15.4 Networks" [RFC4944] and reformatted by "6LoWPAN Paging
Dispatch" [RFC8025]. Dispatch" [RFC8025].
The suggested patterns (to be confirmed by IANA) are indicated in The suggested patterns (to be confirmed by IANA) are indicated in
skipping to change at page 23, line 11 skipping to change at page 23, line 30
+-------------+------+----------------------------------+-----------+ +-------------+------+----------------------------------+-----------+
Table 1: Additional Dispatch Value Bit Patterns Table 1: Additional Dispatch Value Bit Patterns
10. Acknowledgments 10. Acknowledgments
The author wishes to thank Michel Veillette, Dario Tedeschi, Laurent The author wishes to thank Michel Veillette, Dario Tedeschi, Laurent
Toutain, Carles Gomez Montenegro, Thomas Watteyne, and Michael Toutain, Carles Gomez Montenegro, Thomas Watteyne, and Michael
Richardson for in-depth reviews and comments. Also many thanks to Richardson for in-depth reviews and comments. Also many thanks to
Roman Danyliw, Peter Yee, Colin Perkins, Tirumaleswar Reddy Konda, Roman Danyliw, Peter Yee, Colin Perkins, Tirumaleswar Reddy Konda,
Eric Vyncke, Benjamin Kaduk, Warren Kumari, Magnus Westerlund, Mirja Eric Vyncke, Warren Kumari, Magnus Westerlund, Erik Nordmark, and
Kuhlewind, and Erik Nordmark for their careful reviews and for especially Benjamin Kaduk and Mirja Kuhlewind for their careful
helping through the IETF Last Call and IESG review process, and to reviews and for helping through the IETF Last Call and IESG review
Jonathan Hui, Jay Werb, Christos Polyzois, Soumitri Kolavennu, Pat process, and to Jonathan Hui, Jay Werb, Christos Polyzois, Soumitri
Kinney, Margaret Wasserman, Richard Kelsey, Carsten Bormann, and Kolavennu, Pat Kinney, Margaret Wasserman, Richard Kelsey, Carsten
Harry Courtice for their various contributions in the long process Bormann, and Harry Courtice for their various contributions in the
that lead to this document. long process that lead to this document.
11. Normative References 11. Normative References
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>. <https://www.rfc-editor.org/info/rfc6298>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Routing Header for Source Routes with the Routing Protocol Statement and Requirements for IPv6 over Low-Power
for Low-Power and Lossy Networks (RPL)", RFC 6554, Wireless Personal Area Network (6LoWPAN) Routing",
DOI 10.17487/RFC6554, March 2012, RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6554>. <https://www.rfc-editor.org/info/rfc6606>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch", Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016, RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>. <https://www.rfc-editor.org/info/rfc8025>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network "IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>. April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[FRAG-FWD] Watteyne, T., Thubert, P., and C. Bormann, "On Forwarding [FRAG-FWD] Watteyne, T., Thubert, P., and C. Bormann, "On Forwarding
6LoWPAN Fragments over a Multihop IPv6 Network", Work in 6LoWPAN Fragments over a Multihop IPv6 Network", Work in
Progress, Internet-Draft, draft-ietf-6lo-minimal-fragment- Progress, Internet-Draft, draft-ietf-6lo-minimal-fragment-
13, 5 March 2020, <https://tools.ietf.org/html/draft-ietf- 13, 5 March 2020, <https://tools.ietf.org/html/draft-ietf-
6lo-minimal-fragment-13>. 6lo-minimal-fragment-13>.
12. Informative References 12. Informative References
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
skipping to change at page 24, line 50 skipping to change at page 25, line 33
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007, DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>. <https://www.rfc-editor.org/info/rfc4963>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
<https://www.rfc-editor.org/info/rfc6552>. <https://www.rfc-editor.org/info/rfc6552>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>. <https://www.rfc-editor.org/info/rfc7554>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017, DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>. <https://www.rfc-editor.org/info/rfc8087>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
Control Algorithms", BCP 133, RFC 5033, Control Algorithms", BCP 133, RFC 5033,
DOI 10.17487/RFC5033, August 2007, DOI 10.17487/RFC5033, August 2007,
<https://www.rfc-editor.org/info/rfc5033>. <https://www.rfc-editor.org/info/rfc5033>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem [LWIG-FRAG]
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[I-D.ietf-lwig-6lowpan-virtual-reassembly]
Bormann, C. and T. Watteyne, "Virtual reassembly buffers Bormann, C. and T. Watteyne, "Virtual reassembly buffers
in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf- in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-
lwig-6lowpan-virtual-reassembly-01, 11 March 2019, lwig-6lowpan-virtual-reassembly-01, 11 March 2019,
<https://tools.ietf.org/html/draft-ietf-lwig-6lowpan- <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-
virtual-reassembly-01>. virtual-reassembly-01>.
[I-D.ietf-intarea-frag-fragile] [FRAG-ILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", Work and F. Gont, "IP Fragmentation Considered Fragile", Work
in Progress, Internet-Draft, draft-ietf-intarea-frag- in Progress, Internet-Draft, draft-ietf-intarea-frag-
fragile-17, 30 September 2019, fragile-17, 30 September 2019,
<https://tools.ietf.org/html/draft-ietf-intarea-frag- <https://tools.ietf.org/html/draft-ietf-intarea-frag-
fragile-17>. fragile-17>.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", Work in Progress, Internet-Draft, of IEEE 802.15.4", Work in Progress, Internet-Draft,
draft-ietf-6tisch-architecture-28, 29 October 2019, draft-ietf-6tisch-architecture-28, 29 October 2019,
skipping to change at page 27, line 45 skipping to change at page 28, line 17
would need to be resent, further contributing to the congestion that would need to be resent, further contributing to the congestion that
caused the initial loss, and potentially leading to congestion caused the initial loss, and potentially leading to congestion
collapse. collapse.
This saturation may lead to excessive radio interference, or random This saturation may lead to excessive radio interference, or random
early discard (leaky bucket) in relaying nodes. Additional queuing early discard (leaky bucket) in relaying nodes. Additional queuing
and memory congestion may result while waiting for a low power next and memory congestion may result while waiting for a low power next
hop to emerge from its sleeping state. hop to emerge from its sleeping state.
Considering that RFC 4944 defines an MTU is 1280 bytes and that in Considering that RFC 4944 defines an MTU is 1280 bytes and that in
most incarnations (but 802.15.4g) a IEEE Std. 802.15.4 frame can most incarnations (except 802.15.4g) a IEEE Std. 802.15.4 frame can
limit the MAC payload to as few as 74 bytes, a packet might be 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. fragmented into at least 18 fragments at the 6LoWPAN shim layer.
Taking into account the worst-case header overhead for 6LoWPAN Taking into account the worst-case header overhead for 6LoWPAN
Fragmentation and Mesh Addressing headers will increase the number of Fragmentation and Mesh Addressing headers will increase the number of
required fragments to around 32. This level of fragmentation is much required fragments to around 32. This level of fragmentation is much
higher than that traditionally experienced over the Internet with higher than that traditionally experienced over the Internet with
IPv4 fragments. At the same time, the use of radios increases the IPv4 fragments. At the same time, the use of radios increases the
probability of transmission loss and Mesh-Under techniques compound probability of transmission loss and Mesh-Under techniques compound
that risk over multiple hops. that risk over multiple hops.
Mechanisms such as TCP or application-layer segmentation could be Mechanisms such as TCP or application-layer segmentation could be
skipping to change at page 28, line 21 skipping to change at page 28, line 42
Doing so, however, can add significant header overhead to each Doing so, however, can add significant header overhead to each
802.15.4 frame and cause extraneous acknowledgements across the LLN 802.15.4 frame and cause extraneous acknowledgements across the LLN
compared to the method in this specification. compared to the method in this specification.
Appendix B. Requirements Appendix B. Requirements
For one-hop communications, a number of Low Power and Lossy Network For one-hop communications, a number of Low Power and Lossy Network
(LLN) link-layers propose a local acknowledgment mechanism that is (LLN) link-layers propose a local acknowledgment mechanism that is
enough to detect and recover the loss of fragments. In a multihop enough to detect and recover the loss of fragments. In a multihop
environment, an end-to-end fragment recovery mechanism might be a environment, an end-to-end fragment recovery mechanism might be a
good complement to a hop-by-hop MAC level recovery. This draft good complement to a hop-by-hop MAC recovery. This draft introduces
introduces a simple protocol to recover individual fragments between a simple protocol to recover individual fragments between 6FF
6LoWPAN endpoints that may be multiple hops away. endpoints that may be multiple hops away.
The method addresses the following requirements of an LLN: The method addresses the following requirements of an LLN:
Number of fragments: The recovery mechanism must support highly Number of fragments: The recovery mechanism must support highly
fragmented packets, with a maximum of 32 fragments per packet. fragmented packets, with a maximum of 32 fragments per packet.
Minimum acknowledgment overhead: Because the radio is half duplex, Minimum acknowledgment overhead: Because the radio is half duplex,
and because of silent time spent in the various medium access and because of silent time spent in the various medium access
mechanisms, an acknowledgment consumes roughly as many resources mechanisms, an acknowledgment consumes roughly as many resources
as a data fragment. as a data fragment.
skipping to change at page 29, line 15 skipping to change at page 29, line 33
Appendix C. Considerations on Flow Control Appendix C. Considerations on Flow Control
Considering that a multi-hop LLN can be a very sensitive environment Considering that a multi-hop LLN can be a very sensitive environment
due to the limited queuing capabilities of a large population of its due to the limited queuing capabilities of a large population of its
nodes, this draft recommends a simple and conservative approach to nodes, this draft recommends a simple and conservative approach to
Congestion Control, based on TCP congestion avoidance. Congestion Control, based on TCP congestion avoidance.
Congestion on the forward path is assumed in case of packet loss, and Congestion on the forward path is assumed in case of packet loss, and
packet loss is assumed upon time out. The draft allows controlling packet loss is assumed upon time out. The draft allows controlling
the number of outstanding fragments that have been transmitted but the number of outstanding fragments that have been transmitted but
for which an acknowledgment was not received yet. for which an acknowledgment was not received yet and are still
covered by the ARQ timer.
Congestion on the forward path can also be indicated by an Explicit Congestion on the forward path can also be indicated by an Explicit
Congestion Notification (ECN) mechanism. Though whether and how ECN Congestion Notification (ECN) mechanism. Though whether and how ECN
[RFC3168] is carried out over the LoWPAN is out of scope, this draft [RFC3168] is carried out over the LoWPAN is out of scope, this draft
provides a way for the destination endpoint to echo an ECN indication provides a way for the destination endpoint to echo an ECN indication
back to the source endpoint in an acknowledgment message as back to the fragmenting endpoint in an acknowledgment message as
represented in Figure 4 in Section 5.2. While the support of echoing represented in Figure 4 in Section 5.2. While the support of echoing
the ECN at the receiver in mandatory, this specification does not the ECN at the reassembling endpoint in mandatory, this specification
provide the flow control mechanism that react to the congestion at does not provide the flow control mechanism that react to the
teh sender endpoint. A minimalistic behaviour could be to reset the congestion at the fragmenting endpoint. A minimalistic behaviour
window to 1 so the fragments are sent and acknowledged one by one could be to reset the window to 1 so the fragments are sent and
till the end of the datagram. acknowledged one by one till the end of the datagram.
It must be noted that congestion and collision are different topics. It must be noted that congestion and collision are different topics.
In particular, when a mesh operates on the same channel over multiple In particular, when a mesh operates on the same channel over multiple
hops, then the forwarding of a fragment over a certain hop may hops, then the forwarding of a fragment over a certain hop may
collide with the forwarding of the next fragment that is following collide with the forwarding of the next fragment that is following
over a previous hop but in the same interference domain. This draft over a previous hop but in the same interference domain. This draft
enables end-to-end flow control, but leaves it to the sender stack to enables end-to-end flow control, but leaves it to the fragmenting
pace individual fragments within a transmit window, so that a given endpoint stack to pace individual fragments within a transmit window,
fragment is sent only when the previous fragment has had a chance to so that a given fragment is sent only when the previous fragment has
progress beyond the interference domain of this hop. In the case of had a chance to progress beyond the interference domain of this hop.
6TiSCH [I-D.ietf-6tisch-architecture], which operates over the In the case of 6TiSCH [I-D.ietf-6tisch-architecture], which operates
TimeSlotted Channel Hopping [RFC7554] (TSCH) mode of operation of over the TimeSlotted Channel Hopping [RFC7554] (TSCH) mode of
IEEE802.14.5, a fragment is forwarded over a different channel at a operation of IEEE802.14.5, a fragment is forwarded over a different
different time and it makes full sense to transmit the next fragment channel at a different time and it makes full sense to transmit the
as soon as the previous fragment has had its chance to be forwarded next fragment as soon as the previous fragment has had its chance to
at the next hop. be forwarded at the next hop.
From the standpoint of a source 6LoWPAN endpoint, an outstanding From the standpoint of a source 6LoWPAN endpoint, an outstanding
fragment is a fragment that was sent but for which no explicit fragment is a fragment that was sent but for which no explicit
acknowledgment was received yet. This means that the fragment might acknowledgment was received yet. This means that the fragment might
be on the way, received but not yet acknowledged, or the be on the path, received but not yet acknowledged, or the
acknowledgment might be on the way back. It is also possible that acknowledgment might be on the path back. It is also possible that
either the fragment or the acknowledgment was lost on the way. either the fragment or the acknowledgment was lost on the way.
From the sender standpoint, all outstanding fragments might still be From the fragmenting endpoint standpoint, all outstanding fragments
in the network and contribute to its congestion. There is an might still be in the network and contribute to its congestion.
assumption, though, that after a certain amount of time, a frame is There is an assumption, though, that after a certain amount of time,
either received or lost, so it is not causing congestion anymore. a frame is either received or lost, so it is not causing congestion
This amount of time can be estimated based on the round-trip time anymore. This amount of time can be estimated based on the round-
between the 6LoWPAN endpoints. For the lack of a more adapted trip time between the 6LoWPAN endpoints. For the lack of a more
technique, the method detailed in "Computing TCP's Retransmission adapted technique, the method detailed in "Computing TCP's
Timer" [RFC6298] may be used for that computation. Retransmission Timer" [RFC6298] may be used for that computation.
The reader is encouraged to read through "Congestion Control The reader is encouraged to read through "Congestion Control
Principles" [RFC2914]. Additionally [RFC7567] and [RFC5681] provide Principles" [RFC2914]. Additionally [RFC7567] and [RFC5681] provide
deeper information on why this mechanism is needed and how TCP deeper information on why this mechanism is needed and how TCP
handles Congestion Control. Basically, the goal here is to manage handles Congestion Control. Basically, the goal here is to manage
the number of fragments present in the network; this is achieved by the number of fragments present in the network; this is achieved by
to reducing the number of outstanding fragments over a congested path to reducing the number of outstanding fragments over a congested path
by throttling the sources. by throttling the sources.
Section 6 describes how the sender decides how many fragments are Section 6 describes how the fragmenting endpoint decides how many
(re)sent before an acknowledgment is required, and how the sender fragments are (re)sent before an acknowledgment is required, and how
adapts that number to the network conditions. the fragmenting endpoint adapts that number to the network
conditions.
Author's Address Author's Address
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis
France France
 End of changes. 103 change blocks. 
476 lines changed or deleted 503 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/