The RFRAG header is used to transport a fragment and optionally request an RFRAG-ACK that confirms the reception of one or more fragments. An RFRAG-ACK is carried as a standalone fragment header (i.e., with no 6LoWPAN payload) in a message that is propagated back to the fragmenting endpoint. To achieve this, each hop that performed an MPLS-like operation on fragments reverses that operation for the RFRAG-ACK by sending a frame from the next hop to the previous hop as known by its link-layer address in the VRB. The Datagram_Tag in the RFRAG-ACK is unique to the reassembling endpoint and is enough information for an intermediate hop to locate the VRB that contains the Datagram_Tag used by the previous hop and the Layer 2 information associated with it (interface and link-layer address).
The fragmenting endpoint (i.e., the node that fragments the packets at the 6LoWPAN level) also controls the number of acknowledgments by setting the Ack-Request flag in the RFRAG packets.
The fragmenting endpoint may set the Ack-Request flag on any fragment to perform congestion control by limiting the number of outstanding fragments, which are the fragments that have been sent but for which reception or loss was not positively confirmed by the reassembling endpoint. The maximum number of outstanding fragments is controlled by the Window-Size. It is configurable and may vary in case of ECN notification. When the endpoint that reassembles the packets at the 6LoWPAN level receives a fragment with the Ack-Request flag set, it 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. This flag MUST
be set on the last fragment if the fragmenting endpoint wishes to perform an automatic repeat request (ARQ) process for the datagram, and it MAY
be set in any intermediate fragment for the purpose of congestion control.
This ARQ process MUST
be protected by a Retransmission Timeout (RTO) timer, and the fragment that carries the "X" flag MAY
be retried upon a timeout for a configurable number of times (see Section 7.1
) with an exponential backoff. Upon exhaustion of the retries, the fragmenting endpoint may either abort the transmission of the datagram or resend the first fragment with an "X" flag set in order to establish a new path for the datagram and obtain the list of fragments that were received over the old path in the acknowledgment bitmap. When the fragmenting endpoint knows that an underlying link-layer mechanism protects the fragments, it may refrain from using the RFRAG Acknowledgment mechanism and never set the Ack-Request bit.
The reassembling endpoint MAY
issue unsolicited acknowledgments. An unsolicited acknowledgment signals to the fragmenting endpoint that it can resume sending in case it has reached its maximum number of outstanding fragments. Another use is to inform the fragmenting endpoint that the reassembling endpoint aborted the processing of an individual datagram.
The RFRAG Acknowledgment carries an ECN indication for congestion control (see Appendix C
). The reassembling endpoint of a fragment with the "E" (ECN) flag set MUST
echo that information at most once by setting the "E" (ECN) flag in the next RFRAG-ACK.
In order to protect the datagram, the fragmenting endpoint transfers a controlled number of fragments and flags to the last fragment of a window with an RFRAG Acknowledgment Request. The reassembling endpoint MUST
acknowledge a fragment with the acknowledgment request bit set. If any fragment immediately preceding an acknowledgment request is still missing, the reassembling endpoint MAY
intentionally delay its acknowledgment to allow in-transit fragments to arrive. Because it might defeat the round-trip time computation, delaying the acknowledgment should be configurable and not enabled by default.
When enough fragments are received to cover the whole datagram, the reassembling endpoint reconstructs the packet, passes it to the upper layer, sends an RFRAG-ACK on the reverse path with a FULL bitmap, and arms a short timer, e.g., on the order of an average round-trip time in the network. The FULL bitmap is used as opposed to a bitmap that acknowledges only the received fragments to let the intermediate nodes know that the datagram is fully received. As the timer runs, the reassembling endpoint absorbs the fragments that were still in flight for that datagram without creating a new state, acknowledging the ones that bear an Ack-Request with an FRAG Acknowledgment and the FULL bitmap. The reassembling endpoint aborts the communication if fragments with a matching source and Datagram-Tag continue to be received after the timer expires.
Note that acknowledgments might consume precious resources, so the use of unsolicited acknowledgments SHOULD
be configurable and not enabled by default.
An observation is that streamlining the forwarding of fragments generally reduces the latency over the LLN mesh, providing room for retries within existing upper-layer reliability mechanisms. The fragmenting endpoint protects the transmission over the LLN mesh with a retry timer that is configured for a use case and may be adapted dynamically, e.g., according to the method detailed in [RFC 6298
]. It is expected that the upper-layer retry mechanism obeys the recommendations in [RFC 8085
], in which case a single round of fragment recovery should fit within the upper-layer recovery timers.
be sent in a round-robin fashion: the sender MUST
send all the fragments for a first time before it retries any lost fragment; lost fragments MUST
be retried in sequence, oldest first. This mechanism enables the receiver to acknowledge fragments that were delayed in the network before they are retried.
When a single radio frequency is used by contiguous hops, the fragmenting endpoint SHOULD
insert a delay between the frames (e.g., carrying fragments) that are sent to the same next hop. The delay SHOULD
cover multiple transmissions so as to let a frame progress a few hops and avoid hidden terminal issues. This precaution is not required on channel hopping technologies such as Time-Slotted Channel Hopping (TSCH) [RFC 6554
], where nodes that communicate at Layer 2 are scheduled to send and receive, respectively, and different hops operate on different channels.
This specification inherits from [RFC 8930
] and proposes a Virtual Reassembly Buffer technique to forward fragments with no intermediate reconstruction of the entire datagram.
The IPv6 header MUST
be placed in the first fragment in full to enable the routing decision. The first fragment is routed and creates an LSP from the fragmenting endpoint to the reassembling endpoint. The next fragments are label switched along that LSP. As a consequence, the next fragments can only follow the path that was set up by the first fragment; they cannot follow an alternate route. The Datagram_Tag is used to carry the label, which is swapped in each hop.
If the first fragment is too large for the path MTU, it will repeatedly fail and never establish an LSP. In that case, the fragmenting endpoint MAY
retry the same datagram with a smaller Fragment_Size, in which case it MUST
abort the original attempt and use a new Datagram_Tag for the new attempt.
In route-over mode, the source and destination link-layer addresses in a frame change at each hop. The label that is formed and placed in the Datagram_Tag by the sender is associated with the source link-layer address and only valid (and temporarily unique) for that source link-layer address.
Upon receiving the first fragment (i.e., with a Sequence of 0), an intermediate router creates a VRB and the associated LSP state indexed by the incoming interface, the previous-hop link-layer address, and the Datagram_Tag and forwards the fragment along the IPv6 route that matches the destination IPv6 address in the IPv6 header until it reaches the reassembling endpoint, as prescribed by [RFC 8930
]. The LSP state enables matching the next incoming fragments of a datagram to the abstract forwarding information of the next interface, source and next-hop link-layer addresses, and the swapped Datagram_Tag.
In addition, the router also forms a reverse LSP state indexed by the interface to the next hop, the link-layer address the router uses as source for that datagram, and the swapped Datagram_Tag. This reverse LSP state enables matching the tuple (interface, destination link-layer address, Datagram_Tag) found in an RFRAG-ACK to the abstract forwarding information (previous interface, previous link-layer address, Datagram_Tag) used to forward the RFRAG-ACK back to the fragmenting endpoint.
Upon receiving the next fragment (i.e., with a non-zero Sequence), an intermediate router looks up an LSP indexed by the tuple (incoming interface, previous-hop link-layer address, Datagram_Tag) found in the fragment. If it is found, the router forwards the fragment using the associated VRB as prescribed by [RFC 8930
If the VRB for the tuple is not found, the router builds an RFRAG-ACK to abort the transmission of the packet. The resulting message has the following information:
The source and destination link-layer addresses are swapped from those found in the fragment, and the same interface is used
The Datagram_Tag is set to the Datagram_Tag found in the fragment
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 to the previous router. The RFRAG-ACK should normally be forwarded all the way to the source using the reverse LSP state in the VRBs in the intermediate routers as described in the next section.
] indicates that the reassembling endpoint stores "the actual packet data from the fragments received so far, in a form that makes it possible to detect when the whole packet has been received and can be processed or forwarded". How this is computed is implementation specific, but it relies on receiving all the bytes up to the Datagram_Size indicated in the first fragment. An implementation may receive overlapping fragments as the result of retries after an MTU change.
Upon receipt of an RFRAG-ACK, the router looks up a reverse LSP indexed by the interface and destination link-layer address of the received frame and the received Datagram_Tag in the RFRAG-ACK. If it is found, the router forwards the fragment using the associated VRB as prescribed by [RFC 8930
], but it uses the reverse LSP so that the RFRAG-ACK flows back to the fragmenting endpoint.
If the reverse LSP is not found, the router MUST
silently drop the RFRAG-ACK message.
Either way, if the RFRAG-ACK indicates that the fragment was entirely received (FULL bitmap), it arms a short timer, and upon timeout, the VRB and all the associated states are destroyed. Until the timer elapses, fragments of that datagram may still be received, e.g., if the RFRAG-ACK was lost on the path back, and the source retried the last fragment. In that case, the router generates an RFRAG-ACK with a FULL bitmap back to the fragmenting endpoint if an acknowledgment was requested; else, it silently drops the fragment.
This specification does not provide a method to discover the number of hops or the minimal value of MTU along those hops. In a typical case, the MTU is constant and is the same across the network. But should the minimal MTU along the path decrease, it is possible to retry a long fragment (say a Sequence of 5) with several shorter fragments with a Sequence that was not used before (e.g., 13 and 14). Fragment 5 is marked as abandoned and will not be retried anymore. Note that when this mechanism is in place, it is hard to predict the total number of fragments that will be needed or the final shape of the bitmap that would cover the whole packet. This is why the FULL bitmap is used when the reassembling endpoint gets the whole datagram regardless of which fragments were actually used to do so. Intermediate nodes will know unambiguously that the process is complete. Note that Path MTU Discovery is out of scope for this document.
A reset is signaled on the forward path with a pseudo fragment that has the Fragment_Offset set to 0. The sender of a reset SHOULD
also set the Sequence and Fragment_Size field to 0.
When the fragmenting endpoint or a router on the path decides that a packet should be dropped and the fragmentation process aborted, it generates a reset pseudo fragment and forwards it down the fragment path.
Each router along the path forwards the pseudo fragment in turn based on the VRB state. If an acknowledgment is not requested, the VRB and all associated states are destroyed.
Upon reception of the pseudo fragment, the reassembling endpoint cleans up all resources for the packet associated with the Datagram_Tag. If an acknowledgment is requested, the reassembling endpoint responds with a NULL bitmap.
On the other hand, the reassembling endpoint might need to abort the processing of a fragmented packet for internal reasons, for instance, if it is out of reassembly buffers, already uses all 256 possible values of the Datagram_Tag, or keeps receiving fragments beyond a reasonable time while it considers that this packet is already fully reassembled and was passed to the upper layer. In that case, the reassembling endpoint SHOULD
indicate so to the fragmenting endpoint with a NULL bitmap in an RFRAG-ACK.
The RFRAG-ACK is forwarded all the way back to the source of the packet and cleans up all resources on the path. Upon an acknowledgment with a NULL bitmap, the fragmenting endpoint MUST
abort the transmission of the fragmented datagram with one exception: in the particular case of the first fragment, it MAY
decide to retry via an alternate next hop instead.
The text above can be read with the assumption of a serial path between a source and a destination. The IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) architecture (see [6TiSCH
]) defines the concept of a Track that can be a complex path between a source and a destination with Packet ARQ, Replication, Elimination, and Overhearing (PAREO) along the Track. This specification can be used along any subset of the complex Track where the first fragment is flooded. The last RFRAG Acknowledgment is flooded on that same subset in the reverse direction. Intermediate RFRAG Acknowledgments can be flooded on any sub-subset of that reverse subset that reaches back to the source.