< draft-ietf-6lo-fragment-recovery-17.txt   draft-ietf-6lo-fragment-recovery-18.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 4944 (if approved) 18 March 2020 Updates: 4944 (if approved) 19 March 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 19 September 2020 Expires: 20 September 2020
6LoWPAN Selective Fragment Recovery 6LoWPAN Selective Fragment Recovery
draft-ietf-6lo-fragment-recovery-17 draft-ietf-6lo-fragment-recovery-18
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 19 September 2020. This Internet-Draft will expire on 20 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 16 skipping to change at page 2, line 16
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. Other 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. congestion 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 . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 19 7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 19
7.2. Observing the network . . . . . . . . . . . . . . . . . . 21 7.2. Observing the network . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. Normative References . . . . . . . . . . . . . . . . . . . . 23 11. Normative References . . . . . . . . . . . . . . . . . . . . 23
12. Informative References . . . . . . . . . . . . . . . . . . . 24 12. Informative References . . . . . . . . . . . . . . . . . . . 25
Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 27 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.
skipping to change at page 4, line 11 skipping to change at page 4, line 11
resources are blocked on the reassembling endpoint until it times resources are blocked on the reassembling endpoint until it times
out, possibly causing the loss of subsequent packets that cannot be out, possibly causing the loss of subsequent packets 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 fragmenting and reassembling endpoints, and the source either the fragmenting and reassembling endpoints, and the source
will keep on sending fragments, wasting even more resources in the will keep on sending fragments, wasting even more resources in the
network since the datagram cannot arrive in its entirety, and network since the datagram cannot arrive in its entirety, and
possibly contributing to the condition that caused the loss. possibly contributing to the condition that caused the loss.
[RFC4944] is also missing signaling to abort a multi-fragment [RFC4944] is lacking a congestion control to avoid participating in a
transmission at any time and from either end, and, if the capability saturation that may have caused the loss of the fragment. It has no
to forward fragments is implemented, clean up the related state in signaling to abort a multi-fragment transmission at any time and from
the network. It is also lacking flow control capabilities to avoid either end, and, if the capability to forward fragments is
participating in congestion that may in turn cause the loss of a implemented, clean up the related state in the network.
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 can help limit the congestion loss in the endpoints. The method can help limit the congestion loss in the
network and addresses the requirements in Appendix B. Deployments network and addresses the requirements in Appendix B. Flow Control
are expected to be managed and homogeneous, and an incremental is out of scope since the endpoints are expected to be able to store
transition requires a flag day. the full datagram. Deployments are expected to be managed and
homogeneous, and an incremental transition requires a flag day.
2. Terminology 2. Terminology
2.1. BCP 14 2.1. BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
Consistently with Section 2 of [RFC6282], for the fragmentation Consistently with Section 2 of [RFC6282], for the fragmentation
mechanism described in Section 5.3 of [RFC4944], any header that mechanism described in Section 5.3 of [RFC4944], any header that
cannot fit within the first fragment MUST NOT be compressed when cannot fit within the first fragment MUST NOT be compressed when
using the fragmentation mechanism described in this specification. using the fragmentation mechanism described in this specification.
4. Extending draft-ietf-6lo-minimal-fragment 4. Extending draft-ietf-6lo-minimal-fragment
This specification implements the generic 6FF 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 congestion control mechanisms.
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 need for more space in the outgoing added to the next fragment. The need for more space in the outgoing
fragment than was needed for the incoming fragment arises when the fragment than was needed for the incoming fragment arises when the
6LoWPAN Header Compression is not as efficient on the outgoing link 6LoWPAN Header Compression is not as efficient on the outgoing link
or the Link MTU is reduced. or the Link MTU is reduced.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
In the case of a mesh operating at a single frequency with In the case of a mesh operating at a single frequency with
omnidirectional antennas, a larger inter-frame gap is required to omnidirectional antennas, a larger inter-frame gap is required to
protect the frame against hidden terminal collisions with the protect the frame against hidden terminal collisions with the
previous frame of the same flow that is still progressing along a previous frame of the same flow that is still progressing along a
common path. common path.
The inter-frame gap is useful even for unfragmented datagrams, but it The inter-frame gap is useful even for unfragmented datagrams, but it
becomes a necessity for fragments that are typically generated in a becomes a necessity for fragments that are typically generated in a
fast sequence and are all sent over the exact same path. fast sequence and are all sent over the exact same path.
4.3. Flow Control 4.3. congestion 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 to protect the network by adapting the size of
fragments, and/or the inter-frame gap to protect the network. the window, the size of the fragments, and/or the inter-frame gap.
This specification enables the fragmenting endpoint to apply a flow This specification enables the fragmenting endpoint to apply a
control mechanism to tune those parameters, but the mechanism itself congestion control mechanism to tune those parameters, but the
is out of scope. In most cases, the expectation is that most mechanism itself is out of scope. In most cases, the expectation is
datagrams will require only a few fragments, and that only the last that most datagrams will require only a few fragments, and that only
fragment will be acknowledged. A basic implementation of the the last fragment will be acknowledged. A basic implementation of
fragmenting endpoint is NOT REQUIRED to vary the size of the window, the fragmenting endpoint is NOT REQUIRED to vary the size of the
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) the ECN signal or simply reset the window to 1 (see Appendix C for
until the end of this datagram upon detecting a congestion. more) until the end of this datagram upon detecting a congestion.
An intermediate node that experiences a congestion MAY set the ECN An intermediate node that experiences a congestion MAY set the ECN
bit in a fragment, and the reassembling endpoint echoes the ECN bit bit in a fragment, and the reassembling endpoint echoes the ECN bit
at most once at the next opportunity to acknowledge back. at most once at the next opportunity to acknowledge back.
The size of the fragments is typically computed from the Link MTU to The size of the fragments is typically computed from the Link MTU to
maximize the size of the resulting frames. The size of the window maximize the size of the resulting frames. The size of the window
and the duration of the inter-frame gap SHOULD be configurable, to and the duration of the inter-frame gap SHOULD be configurable, to
roughly adapt the size of the window to the number of hops in an reduce the chances of congestion and to follow the general
average path, and to follow the general recommendations in 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, modified, then the intermediate node MUST adapt the Datagram_Size,
encoded in the Fragment_Size field, to reflect that difference. encoded in the Fragment_Size field, to reflect that difference.
The intermediate node MUST also save the difference of Datagram_Size The intermediate node MUST also save the difference of Datagram_Size
skipping to change at page 8, line 25 skipping to change at page 8, line 25
all the subsequent fragments that it forwards for that datagram. all the subsequent fragments that it forwards for that datagram.
5. New Dispatch types and headers 5. New Dispatch types and headers
This document specifies an alternative to the 6LoWPAN fragmentation This document specifies an alternative to the 6LoWPAN fragmentation
sublayer [RFC4944] to emulate an Link MTU up to 2048 bytes for the sublayer [RFC4944] to emulate an Link MTU up to 2048 bytes for the
upper layer, which can be the 6LoWPAN Header Compression sublayer upper layer, which can be the 6LoWPAN Header Compression sublayer
that is defined in the "Compression Format for IPv6 Datagrams" that is defined in the "Compression Format for IPv6 Datagrams"
[RFC6282] specification. This specification also provides a reliable [RFC6282] specification. This specification also provides a reliable
transmission of the fragments over a multihop 6LoWPAN route-over mesh transmission of the fragments over a multihop 6LoWPAN route-over mesh
network and a minimal flow control to reduce the chances of network and a minimal congestion control to reduce the chances of
congestion loss. congestion loss.
A 6LoWPAN Fragment Forwarding [FRAG-FWD] technique derived from MPLS A 6LoWPAN Fragment Forwarding [FRAG-FWD] technique derived from MPLS
enables the forwarding of individual fragments across a 6LoWPAN enables the forwarding of individual fragments across a 6LoWPAN
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 within the address and the label can identify the fragment globally within the
lifetime of the datagram. A node may build the Datagram_Tag in its lifetime of the datagram. A node may build the Datagram_Tag in its
own locally-significant way, as long as the chosen Datagram_Tag stays own locally-significant way, as long as the chosen Datagram_Tag stays
skipping to change at page 9, line 43 skipping to change at page 9, line 43
|1 1 1 0 1 0 0|E| Datagram_Tag | |1 1 1 0 1 0 0|E| Datagram_Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Sequence| Fragment_Size | Fragment_Offset | |X| Sequence| Fragment_Size | Fragment_Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X set == Ack-Request X set == Ack-Request
Figure 1: RFRAG Dispatch type and Header Figure 1: RFRAG Dispatch type and Header
X: 1 bit; Ack-Request: when set, the fragmenting endpoint requires X: 1 bit; Ack-Request: when set, the fragmenting endpoint requires
anLink-layer RFRAG Acknowledgment from the reassembling endpoint. an RFRAG Acknowledgment from the reassembling endpoint.
E: 1 bit; Explicit Congestion Notification; the "E" flag is cleared E: 1 bit; Explicit Congestion Notification; the "E" flag is cleared
by the source of the fragment and set by intermediate routers to by the source of the fragment and set by intermediate routers to
signal that this fragment experienced congestion along its path. signal that this fragment experienced congestion along its path.
Fragment_Size: 10-bit unsigned integer; the size of this fragment in Fragment_Size: 10-bit unsigned integer; the size of this fragment in
a unit that depends on the Link-Layer technology. Unless a unit that depends on the Link-Layer technology. Unless
overridden by a more specific specification, that unit is the overridden by a more specific specification, that unit is the
byte, which allows fragments up to 1024 bytes. byte, which allows fragments up to 1024 bytes.
skipping to change at page 12, line 35 skipping to change at page 12, line 35
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 RFRAG_ACK that
good reception of one or more fragments. An RFRAG Acknowledgment is confirms the reception of one or more fragments. An RFRAG_ACK 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 fragmenting payload) in a message that is propagated back to the fragmenting
endpoint. To achieve this, each hop that performed an MPLS-like endpoint. To achieve this, each hop that performed an MPLS-like
operation on fragments reverses that operation for the RFRAG_ACK by operation on fragments reverses that operation for the RFRAG_ACK by
sending a frame from the next hop to the previous hop as known by its sending a frame from the next hop to the previous hop as known by its
Link-Layer address in the VRB. The Datagram_Tag in the RFRAG_ACK is Link-Layer address in the VRB. The Datagram_Tag in the RFRAG_ACK is
unique to the reassembling endpoint and is enough information for an unique to the reassembling endpoint and is enough information for an
intermediate hop to locate the VRB that contains the Datagram_Tag intermediate hop to locate the VRB that contains the Datagram_Tag
used by the previous hop and the Layer-2 information associated with used by the previous hop and the Layer-2 information associated with
it (interface and Link-Layer address). it (interface and Link-Layer address).
The fragmenting endpoint that fragments the packets at the 6LoWPAN The fragmenting endpoint (i.e., the node fragments the packets at the
level also controls the number of acknowledgments by setting the Ack- 6LoWPAN level) also controls the number of acknowledgments by setting
Request flag in the RFRAG packets. The fragmenting endpoint may set the Ack-Request flag in the RFRAG packets.
the Ack-Request flag on any fragment to perform congestion control by
limiting the number of outstanding fragments, which are the fragments The fragmenting endpoint may set the Ack-Request flag on any fragment
that have been sent but for which reception or loss was not to perform congestion control by limiting the number of outstanding
positively confirmed by the reassembling endpoint. The maximum fragments, which are the fragments that have been sent but for which
number of outstanding fragments is controlled by the Window-Size. It reception or loss was not positively confirmed by the reassembling
is configurable and may vary in case of ECN notification. When the endpoint. The maximum number of outstanding fragments is controlled
endpoint that reassembles the packets at the 6LoWPAN level receives a by the Window-Size. It is configurable and may vary in case of ECN
fragment with the Ack-Request flag set, it MUST send an RFRAG notification. When the endpoint that reassembles the packets at the
Acknowledgment back to the originator to confirm reception of all the 6LoWPAN level receives a fragment with the Ack-Request flag set, it
fragments it has received so far. MUST send an RFRAG_ACK back to the originator to confirm reception of
all the 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 fragmenting This flag MUST be set on the last fragment if the fragmenting
endpoint wishes to perform an automatic repeat request (ARQ) process endpoint wishes to perform an automatic repeat request (ARQ) process
for the datagram, and it MAY be set in any intermediate fragment for for the datagram, and it MAY be set in any intermediate fragment for
the purpose of flow control. the purpose of congestion control.
This ARQ process MUST be protected by a Retransmission Time Out (RTO) This ARQ process MUST be protected by a Retransmission Time Out (RTO)
timer, and the fragment that carries the 'X' flag MAY be retried upon timer, and the fragment that carries the 'X' flag MAY be retried upon
a time out for a configurable number of times (see Section 7.1) with a time out for a configurable number of times (see Section 7.1) with
an exponential backoff. Upon exhaustion of the retries the an exponential backoff. Upon exhaustion of the retries the
fragmenting endpoint may either abort the transmission of the fragmenting endpoint may either abort the transmission of the
datagram or resend the first fragment with an 'X' flag set in order datagram or resend the first fragment with an 'X' flag set in order
to establish a new path for the datagram and obtain the list of to establish a new path for the datagram and obtain the list of
fragments that were received over the old path in the acknowledgment fragments that were received over the old path in the acknowledgment
bitmap. When the knows that an underlying link-layer mechanism bitmap. When the knows that an underlying link-layer mechanism
protects the fragments, it may refrain from using the RFRAG protects the fragments, it may refrain from using the RFRAG
Acknowledgment mechanism, and never set the Ack-Request bit. Acknowledgment mechanism, and never set the Ack-Request bit.
The reassembling endpoint MAY issue unsolicited acknowledgments. An The reassembling endpoint MAY issue unsolicited acknowledgments. An
unsolicited acknowledgment signals to the fragmenting endpoint that unsolicited acknowledgment signals to the fragmenting endpoint that
it can resume sending in case it has reached its maximum number of it can resume sending in case it has reached its maximum number of
outstanding fragments. Another use is to inform the fragmenting outstanding fragments. Another use is to inform the fragmenting
endpoint that the reassembling endpoint aborted the processing of an endpoint that the reassembling endpoint aborted the processing of an
individual datagram. individual datagram.
The RFRAG Acknowledgment carries an ECN indication for flow control The RFRAG Acknowledgment carries an ECN indication for congestion
(see Appendix C). The reassembling endpoint of a fragment with the control (see Appendix C). The reassembling endpoint of a fragment
'E' (ECN) flag set MUST echo that information at most once by setting with the 'E' (ECN) flag set MUST echo that information at most once
the 'E' (ECN) flag in the next RFRAG Acknowledgment. by setting the 'E' (ECN) flag in the next RFRAG_ACK.
In order to protect the datagram, the fragmenting endpoint transfers In order to protect the datagram, the fragmenting endpoint transfers
a controlled number of fragments and flags the last fragment of a a controlled number of fragments and flags the last fragment of a
window with an RFRAG Acknowledgment Request. The reassembling window with an RFRAG Acknowledgment Request. The reassembling
endpoint MUST acknowledge a fragment with the acknowledgment request endpoint MUST acknowledge a fragment with the acknowledgment request
bit set. If any fragment immediately preceding an acknowledgment bit set. If any fragment immediately preceding an acknowledgment
request is still missing, the reassembling endpoint MAY intentionally request is still missing, the reassembling endpoint MAY intentionally
delay its acknowledgment to allow in-transit fragments to arrive. delay its acknowledgment to allow in-transit fragments to arrive.
Because it might defeat the round-trip delay computation, delaying Because it might defeat the round-trip time computation, delaying the
the acknowledgment should be configurable and not enabled by default. 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
reassembling 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_ACK on the reverse path with a FULL bitmap, and
bitmap, and arms a short timer, e.g., on the order of an average arms a short timer, e.g., on the order of an average round-trip time
round-trip delay in the network. The FULL bitmap is used as opposed in the network. The FULL bitmap is used as opposed to a bitmap that
to a bitmap that acknowledges only the received fragments to let the acknowledges only the received fragments to let the intermediate
intermediate nodes know that the datagram is fully received. As the nodes know that the datagram is fully received. As the timer runs,
timer runs, the reassembling endpoint absorbs the fragments that were the reassembling endpoint absorbs the fragments that were still in
still in flight for that datagram without creating a new state, flight for that datagram without creating a new state, acknowledging
acknowledging the ones that that bear an Ack-Request with an FRAG the ones that that bear an Ack-Request with an FRAG Acknowledgment
Acknowledgment and the FULL bitmap. The reassembling endpoint aborts and the FULL bitmap. The reassembling endpoint aborts the
the communication if fragments with matching source and Datagram-Tag communication if fragments with matching source and Datagram-Tag
continue to be received after the timer expires. 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 fragmenting within existing upper-layer reliability mechanisms. The fragmenting
endpoint protects the transmission over the LLN mesh with a retry endpoint protects the transmission over the LLN mesh with a retry
skipping to change at page 15, line 49 skipping to change at page 15, line 49
header until it reaches the reassembling endpoint, as prescribed by header until it reaches the reassembling endpoint, as prescribed by
[FRAG-FWD]. The LSP state enables to match the next incoming [FRAG-FWD]. The LSP state enables to match the next incoming
fragments of a datagram to the abstract forwarding information of fragments of a datagram to the abstract forwarding information of
next interface, source and next-hop Link-Layer addresses, and swapped next interface, source and next-hop Link-Layer addresses, and swapped
Datagram_Tag. Datagram_Tag.
In addition, the router also forms a reverse LSP state indexed by the In addition, the router also forms a reverse LSP state indexed by the
interface to the next hop, the Link-Layer address the router uses as interface to the next hop, the Link-Layer address the router uses as
source for that datagram, and the swapped Datagram_Tag. This reverse source for that datagram, and the swapped Datagram_Tag. This reverse
LSP state enables matching the tuple (interface, destination Link- LSP state enables matching the tuple (interface, destination Link-
Layer address, Datagram_Tag) found in an RFRAG Acknowledgment to the Layer address, Datagram_Tag) found in an RFRAG_ACK to the abstract
abstract forwarding information (previous interface, previous Link- forwarding information (previous interface, previous Link-Layer
Layer address, Datagram_Tag) used to forward the Fragment address, Datagram_Tag) used to forward the RFRAG-ACK back to the
Acknowledgment (RFRAG-ACK) back to the fragmenting endpoint. 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 (incoming intermediate router looks up a LSP indexed by the tuple (incoming
interface, previous-hop Link-Layer address, Datagram_Tag) found in interface, previous-hop Link-Layer address, Datagram_Tag) found in
the fragment. If it is found, the router forwards the fragment using the fragment. If it is found, the router forwards the fragment using
the associated VRB as prescribed 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
skipping to change at page 17, line 51 skipping to change at page 17, line 51
Datagram_Tag. If an acknowledgment is requested, the reassembling Datagram_Tag. If an acknowledgment is requested, the reassembling
endpoint responds with a NULL bitmap. endpoint responds with a NULL bitmap.
The other way around, the reassembling endpoint might need to abort The other way around, the reassembling endpoint might need to abort
the processing of a fragmented packet for internal reasons, for the processing of a fragmented packet for internal reasons, for
instance if it is out of reassembly buffers, already uses all 256 instance if it is out of reassembly buffers, already uses all 256
possible values of the Datagram_Tag, or if it keeps receiving possible values of the Datagram_Tag, or if it keeps receiving
fragments beyond a reasonable time while it considers that this fragments beyond a reasonable time while it considers that this
packet is already fully reassembled and was passed to the upper packet is already fully reassembled and was passed to the upper
layer. In that case, the reassembling endpoint SHOULD indicate so to layer. In that case, the reassembling endpoint SHOULD indicate so to
the fragmenting endpoint with a NULL bitmap in an RFRAG the fragmenting endpoint with a NULL bitmap in an RFRAG_ACK.
Acknowledgment. The RFRAG Acknowledgment is forwarded all the way
back to the source of the packet and cleans up all resources on the The RFRAG_ACK is forwarded all the way back to the source of the
path. Upon an acknowledgment with a NULL bitmap, the fragmenting packet and cleans up all resources on the path. Upon an
endpoint MUST abort the transmission of the fragmented datagram with acknowledgment with a NULL bitmap, the fragmenting endpoint MUST
one exception: In the particular case of the first fragment, it MAY abort the transmission of the fragmented datagram with one exception:
decide to retry via an alternate next hop instead. In the particular case of the first fragment, it MAY 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
skipping to change at page 18, line 44 skipping to change at page 18, line 45
The configuration settings introduced by this specification only The configuration settings introduced by this specification only
apply to the fragmenting endpoint, which is in full control of the apply to the fragmenting endpoint, which is in full control of the
transmission. LLNs vary a lot in size (there can be thousands of transmission. LLNs vary a lot in size (there can be thousands of
nodes in a mesh), in speed (from 10 Kbps to several Mbps at the PHY nodes in a mesh), in speed (from 10 Kbps to several Mbps at the PHY
layer), in traffic density, and in optimizations that are desired layer), in traffic density, and in optimizations that are desired
(e.g., the selection of a RPL [RFC6550] Objective Function [RFC6552] (e.g., the selection of a RPL [RFC6550] Objective Function [RFC6552]
impacts the shape of 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 fragmenting endpoint and on whether complex settings of the fragmenting endpoint and on whether complex
algorithms are needed to perform flow control or estimate the round- algorithms are needed to perform congestion control or estimate the
trip time. To cover the most complex use cases, this specification round-trip time. To cover the most complex use cases, this
enables the fragmenting endpoint to vary the fragment size, the specification enables the fragmenting endpoint to vary the fragment
window size, and the inter-frame gap, based on the number of losses, size, the window size, and the inter-frame gap, based on the number
the observed variations of the round-trip time and the setting of the of losses, the observed variations of the round-trip time and the
ECN bit. 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
it gets the next. In a wireless network that uses the same frequency it gets the next. In a wireless network that uses the same frequency
along a path, more time must be inserted to avoid hidden terminal along a path, more time must be inserted to avoid hidden terminal
issues between fragments (more in Section 4.2). issues between fragments (more in Section 4.2). An implementation
should consider the generic recommendations from the IETF in the
matter of congestion control and rate management in [RFC5033]. An
implementation may perform a congestion control by using a dynamic
value of the window size (Window_Size), adapting the fragment size
(Fragment_Size), and may reduce the load by inserting an inter-frame
gap that is longer than necessary. In a large network where nodes
contend for the bandwidth, a larger Fragment_Size consumes less
bandwidth but also reduces fluidity and incurs higher chances of loss
in transmission.
This is controlled by the following parameter: This is controlled by the following parameters:
inter-frame gap: Indicates the minimum amount of time between inter-frame gap: Indicates the minimum amount of time between
transmissions. The inter-frame gap protects the propagation of transmissions. The inter-frame gap protects the propagation of
one transmission before the next one is triggered and creates a one transmission before the next one is triggered and creates a
duty cycle that controls the ratio of air time and memory in duty cycle that controls the ratio of air time and memory in
intermediate nodes that a particular datagram will use. intermediate nodes that a particular datagram will use. The
inter-frame gap controls the rate at which fragments are sent and
An implementation should consider the generic recommendations from SHOULD be selected large enough to protect the network.
the IETF in the matter of flow control and rate management in
[RFC5033]. To control the flow, an implementation may use a dynamic
value of the window size (Window_Size), adapt the fragment size
(Fragment_Size), and insert an inter-frame gap that is longer than
necessary. In a large network where nodes contend for the bandwidth,
a larger Fragment_Size consumes less bandwidth but also reduces
fluidity and incurs higher chances of loss in transmission. This is
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. It MUST be lower than the minimum value of
smallest 1-hop MTU that can be encountered along the path.
OptFragmentSize: The OptFragmentSize is the value for the OptFragmentSize: The OptFragmentSize is the value for the
Fragment_Size that the fragmenting endpoint should use to start Fragment_Size that the fragmenting endpoint should use to start
with. It is greater than or equal to MinFragmentSize. It is less with. It is greater than or equal to MinFragmentSize. It is less
than or equal to MaxFragmentSize. For the first fragment, it must than or equal to MaxFragmentSize. For the first fragment, it must
account for the expansion of the IPv6 addresses and of the Hop account for the expansion of the IPv6 addresses and of the Hop
Limit field within MTU. For all fragments, it is a balance Limit field within MTU. For all fragments, it is a balance
between the expected fluidity and the overhead of Link-Layer and between the expected fluidity and the overhead of Link-Layer and
6LoWPAN headers. For a small MTU, the idea is to keep it close to 6LoWPAN headers. For a small MTU, the idea is to keep it close to
the maximum, whereas for larger MTUs, it might makes sense to keep the maximum, whereas for larger MTUs, it might makes sense to keep
it short enough, so that the duty cycle of the transmitter is it short enough, so that the duty cycle of the transmitter is
bounded, 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 maximum value of
path. A large value augments the chances of buffer bloat and smallest 1-hop MTU that can be encountered along the path. A
transmission loss. The value MUST be less than 512 if the unit large value augments the chances of buffer bloat and transmission
that is defined for the PHY layer is the byte. loss. The value MUST be less than 512 if the unit that is defined
for the PHY layer is the byte.
MinWindowSize: The minimum value of Window_Size that the fragmenting Window_Size: The Window_Size MUST be at least 1 and less than 33.
endpoint can use. A value of 1 is RECOMMENDED.
OptWindowSize: The OptWindowSize is the value for the Window_Size * If the round-trip time is known, the Window_Size SHOULD be set
that the fragmenting endpoint should use to start with. It is to the round-trip time divided by the time per fragment, that
greater than or equal to MinWindowSize. It is less than or equal is the time to transmit a fragment plus the inter-frame gap.
to MaxWindowSize. A rule of a thumb for OptWindowSize could be an
estimation of the one-way trip time divided by the inter-frame
gap. If the acknowledgement back is too costly, it is possible to
set this to 32, meaning that only the last Fragment is
acknowledged in the first round.
MaxWindowSize: The maximum value of Window_Size that the fragmenting Otherwise:
endpoint can use. The value MUST be strictly less than 33.
* Setting the window_size to 32 is to be understood as only the
last Fragment is acknowledged in each round. This is the
RECOMMENDED value in a half-duplex LLN where the fragment
acknowledgement consumes roughly the same bandwidth on the same
links as the fragments themselves
* If it is set to a smaller value, more acks are generated. In a
full-duplex network, the load on the forward path will be
lower, and a small value of 3 SHOULD be configured.
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.
skipping to change at page 21, line 23 skipping to change at page 21, line 28
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 fragmenting endpoint should react to UseECN: Indicates whether the fragmenting endpoint should react to
ECN. The fragmenting endpoint may react to ECN by varying the ECN. The fragmenting endpoint may react to ECN by varying the
Window_Size between MinWindowSize and MaxWindowSize, varying the Window_Size between MinWindowSize and MaxWindowSize, varying the
Fragment_Size between MinFragmentSize and MaxFragmentSize, and/or Fragment_Size between MinFragmentSize and MaxFragmentSize, and/or
by increasing or reducing the inter-frame gap. With this by increasing or reducing the inter-frame gap. With this
specification, if UseECN is set and a fragmenting endpoint detects specification, if UseECN is set and a fragmenting endpoint detects
a congestion, it resets the Window_Size to 1 till the end of the a congestion, it may apply a congestion control method until the
datagram, whereas if UseECN is reset, the endpoint does not react end of the datagram, whereas if UseECN is reset, the endpoint does
to congestion. Future specifications may provide additional not react to congestion. Future specifications may provide
parameters and capabilities. 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 settings that can be observed from the perspective of both the
fragmenting endpoint and the reassembling endpoint with regards to fragmenting endpoint and the reassembling endpoint with regards to
the other endpoint. It may then tune the optimum size of the other endpoint. It may then tune the optimum size of
Fragment_Size and of Window_Size, OptFragmentSize, and OptWindowSize, Fragment_Size and of Window_Size, OptFragmentSize, and OptWindowSize,
respectively, at the fragmenting endpoint towards a particular respectively, at the fragmenting endpoint towards a particular
reassembling endpoint, applicable to the next datagrams. The values reassembling endpoint, applicable to the next datagrams. It will
should be bounded by the expected number of hops and reduced beyond preferably tune the inter-frame gap to increase the spacing between
that when the number of datagrams that can traverse an intermediate fragments of the same datagram and reduce the reduce the buffer bloat
point may exceed its capacity and cause a congestion loss. The in intermediate node that holds one or more fragments of that
inter-frame gap is another tool that can be used to increase the
spacing between fragments of the same datagram and reduce the ratio
of time when a particular intermediate node holds a fragment of that
datagram. datagram.
8. Security Considerations 8. Security Considerations
This document specifies an instantiation of a 6FF technique and This document specifies an instantiation of a 6FF technique and
inherits from the generic description in [FRAG-FWD]. The inherits from the generic description in [FRAG-FWD]. The
considerations in the Security Section of [FRAG-FWD] equally apply to considerations in the Security Section of [FRAG-FWD] equally apply to
this document. this document.
In addition to the threats detailed therein, an attacker that is on- In addition to the threats detailed therein, an attacker that is on-
skipping to change at page 30, line 40 skipping to change at page 30, line 45
Retransmission 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 fragmenting endpoint decides how many
fragments are (re)sent before an acknowledgment is required, and how
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
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
 End of changes. 36 change blocks. 
131 lines changed or deleted 130 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/