| Internet-Draft | TODO - Abbreviation | March 2024 |
| Papadopoulos & Bruniaux | Expires 26 September 2024 | [Page] |
This document describes a Forward Error Correction (FEC) method that is applied over the SCHC framework to improve the network performance under certain range of loss/error rates.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-todo-yourname-protocol/.¶
Discussion of this document takes place on the WG Working Group mailing list (mailto:WG@example.com), which is archived at https://example.com/WG.¶
Source for this draft and an issue tracker can be found at https://github.com/USER/REPO.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 26 September 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In Low-Power Wide Area Network (LPWAN) technologies, the L2 MTU typically ranges from tens to hundreds of bytes.¶
The RFC 8724 standard defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides header compression and optional fragmentation mechanisms to enable LPWAN technologies, that do not come with internal fragmentation/reassembly functionalities, to comply with the IPv6 MTU requirement of 1280 bytes [RFC8200].¶
However, this standardized framework struggles in low link-quality scenarios. This document describes a Forward Error Correction (FEC) method that is applied over the SCHC framework to improve the network performance under certain range of loss/error rates.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
FEC is a method employed to control errors in packet transmission by embedding additional redundant information within transmitted fragments, thereby reducing the chances for the destination node to request retransmission of missing fragments. Employed in satellite communications and mobile networks, FEC mechanisms use encoding algorithms that allow the destination node to detect errors and often to recover missing components (i.e., to correct the errors).¶
FEC can be classified into intra-frame, where error correction codes add redundancy inside a packet to correct errors on individual packets, and inter-frame (or inter-fragment), where additional redundant frames are transmitted. LoRa technology employed the intra-frame FEC. Indeed, the intra-frame FEC of LoRa uses Coding Rates (CR) 4/5 to 4/8. In this document, a generic inter-frame FEC mechanism is presented in order to obtain higher Data Delivery Rate (DDR).¶
SCHC framework can be applied over lossy radio links such as LPWAN where some of the fragments of a SCHC packet can be lost, which may lead to the failure of the reception of the whole SCHC packet (notably in the case of No-ACK mode). Therefore, incorporating FEC into SCHC allows the destination node to increase the chances for the destination node to recover the missing SCHC fragments without the need for the sender to retransmit the missing SCHC fragments.¶
While FEC mechanisms increase network reliability in lossy networks, they also introduce additional costs. This is because sending additional fragments demands energy and bandwidth. Furthermore, the increase in traffic can ultimately lead to overflow in the transmission queues of relay nodes when such nodes exist. Consequently, the implementation of FEC schemes in networks with constrained resources warrants careful consideration.¶
XORFEC employs the Exclusive OR (XOR) operator (⊕) within its FEC mechanism to produce an extra fragment for a fragmented IPv6 SCHC packet. This supplementary fragment contains the redundant information. This additional fragment is sent after the original fragments of the SCHC packet and allows the destination node to detect a potential loss of an original fragment and to recover it, mitigating thus the scenario where the loss of one fragment leads to the entire packet being lost and/or to reduce the number of fragment retries required to avoid the entire packet being lost.¶
XOR is a logical operator employed in encoding mechanisms, blending information from multiple fragments during encoding and subsequently decoding the encoded fragments upon reception. XOR is a binary operator, and when applied to fragments that consist of series of bits, is applied bitwise. The key property of XOR utilized in XORFEC for fragment recovery is that applying XOR to the result of an initial XOR operation and one of its input values (i.e., of the first XOR) yields the other input value, see an eample below:¶
B = A ⊕ (A ⊕ B)
A = B ⊕ (A ⊕ B)¶
Indeed, if a SCHC packet is fragmented into two fragments A and B, the additional fragment C generated by the source node will be:¶
C = A ⊕ B¶
In this case, if the destination node receives the A and C fragments but does not receive the B fragment, it can recover B fragment by applying the XOR operator to the successfully received fragments.¶
Note that this function can be generalised to SCHC packets that consists of more than two fragments. Indeed, with k original fragments (F1, F2, F3, ..., Fk), the additional fragment F_additional will be:¶
F_additional = F1 ⊕ F2 ⊕ F3 ⊕ ... ⊕ Fk¶
In a scenario where the destination node receives successfully all fragments except Fi, then it can recover the latter by applying the XOR operator to the successfully received fragments, as it is shown below:¶
Fi = (F1 ⊕ ... ⊕ Fi−1 ⊕ Fi+1 ⊕ ... ⊕ Fm) ⊕ F_additional¶
The main limitation of the XORFEC algorithm is that the loss tolerance is one missing fragment. Indeed, in the previous example of k fragments, the recovery of Fi is only possible if no more than one fragment is lost.¶
In No-ACK mode, a SCHC Packet is first fragmented into k original fragments and the additional fragment (i.e., F_additional) is generated by applying the XOR operator to these k fragments.¶
In Figure 1, the example (i.e., Figure 29) from [RFC8724] of No-ACK mode of a SCHC Packet that needs 5 SCHC Fragments (and where FCN is 1 bit wide) is adapted when XORFEC is applied to all 5 SCHC Fragments.¶
Sender Receiver |-----FCN=0----->| 1st Fragment (received) |-----FCN=0----->| 2nd Fragment (received) |-----FCN=0--X-->| 3rd Fragment (not received) |-----FCN=0----->| 4th Fragment (received) |-----FCN=0----->| 5th Fragment (received) |---FCN=1 + RCS->| The XOR Fragment with Integrity check: success (End)
Thus, even if with No-ACK mode there is no feedback from the receiver, by employing XORFEC, the receiver may successfully reassemble the original SCHC Packet. As a result, both the network reliability and the spectrum/bandwidth utlization efficiency are increased for a certain range of loss/error rates.¶
In ACK-on-Error mode, the XOR is applied per Window. In case, when there is one Tile per Fragment, then one additional fragment is introduced per Window.¶
In Figure 2, the example (i.e., Figure 31) from [RFC8724] of ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles is adapted when XORFEC is applied on ACK-on-Error mode is illustrated. A SCHC Packet is fragmented in 11 Tiles, with one Tile per SCHC Fragment, N=3, WINDOW_SIZE=7, and two lost SCHC Fragments.¶
Sender Receiver |-----W=0, FCN=6----->| 1st Tile/Fragment (received) |-----W=0, FCN=5----->| 2nd Tile/Fragment (received) |-----W=0, FCN=4----->| 3rd Tile/Fragment (received) |-----W=0, FCN=3----->| 4th Tile/Fragment (received) |-----W=0, FCN=2--X-->| 5th Tile/Fragment (not received) |-----W=0, FCN=1----->| 6th Tile/Fragment (received) |-----W=0, FCN=0----->| The additional (XOR) Fragment (no ACK) |-----W=1, FCN=6----->| 7th Tile/Fragment (received) |-----W=1, FCN=5----->| 8th Tile/Fragment (received) |-----W=1, FCN=4--X-->| 9th Tile/Fragment (not received) |-----W=1, FCN=3----->| 10th Tile/Fragment (received) |-----W=1, FCN=2----->| 11th Tile/Fragment (received) |- W=1, FCN=7 + RCS ->| The XOR Fragment with Integrity check: success |<-- ACK, W=1, C=1 ---| C=1 (End)
As it can be calculated, in the original example, there were in total 16 transmissions with two fragment losses, i.e., 11 original transmissions from the Sender, two retransmissions from the Sender, and three acknowledgments from the Receiver. In this XORFEC based approach, there are in total 14 transmissions, i.e., 11 original fragment transmissions from the Sender, two additional XOR transmissions from the Sender, and the ACK at the end from the Receiver. As a result, thanks to the XORFEC, the communication was reduced by two transmissions. Indeed, the ACK transmissions with the Bitmap of the missing fragments was not transmitted, and consequently the retransmissions of the missing fragments.¶
Similar to ACK-on-Error mode, in ACK-Always, the XOR is applied per Window. In case, when there is one Tile per Fragment, then one additional fragment is introduced per Window.¶
In Figure 3, the example (i.e., Figure 34) from [RFC8724] when XORFEC is applied on ACK-Always is illustrated. A SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7 and two lost SCHC Fragments.¶
Sender Receiver |-----W=0, FCN=6----->| 1st Tile/Fragment (received) |-----W=0, FCN=5----->| 2nd Tile/Fragment (received) |-----W=0, FCN=4----->| 3rd Tile/Fragment (received) |-----W=0, FCN=3----->| 4th Tile/Fragment (received) |-----W=0, FCN=2--X-->| 5th Tile/Fragment (not received) |-----W=0, FCN=1----->| 6th Tile/Fragment (received) |-----W=0, FCN=0----->| The additional (XOR) Fragment - 6543210 |<-- ACK, W=0, C=0 ---| Bitmap: 1111111 |-----W=1, FCN=6----->| 7th Tile/Fragment (received) |-----W=1, FCN=5----->| 8th Tile/Fragment (received) |-----W=1, FCN=4--X-->| 9th Tile/Fragment (not received) |-----W=1, FCN=3----->| 10th Tile/Fragment (received) |-----W=1, FCN=2----->| 11th Tile/Fragment (received) |- W=1, FCN=7 + RCS ->| The XOR Fragment with Integrity check: success |<-- ACK, W=1, C=1 ---| C=1 (End)
TODO Security¶
This document has no IANA actions.¶
Thanks to Carles Gomez for useful design considerations, reviews and comments.¶