SCHC Rule Format for Forward Error Correction (FEC) in Fragmentation
draft-pelov-schc-fragmentation-fec-rule-format-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Alexander Pelov , Javier Alejandro FERNANDEZ , Hoang Quy Nguyen | ||
| Last updated | 2024-09-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pelov-schc-fragmentation-fec-rule-format-00
Network Working Group A. Pelov
Internet-Draft J. A. Fernandez
Intended status: Informational IMT Atlantique
Expires: 13 March 2025 Q. Nguyen
Actility
9 September 2024
SCHC Rule Format for Forward Error Correction (FEC) in Fragmentation
draft-pelov-schc-fragmentation-fec-rule-format-00
Abstract
This document defines a new Rule Format for Forward Error Correction
(FEC) of SCHC Fragments. It is backwards compatible with RFC8724, as
an implementation which does not have the necessary FEC code
implementations can simply ignore the messages with this new RuleID
format.
Status of This Memo
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 13 March 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pelov, et al. Expires 13 March 2025 [Page 1]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SCHC FEC Fragment Profile for XOR over RFC9011 Uplink
Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
A SCHC fragmentation session, besides allowing for larger payload
transfer, protects against the loss of fragments through its various
Acknowledgment modes, except in No-Ack where lost fragments can never
be recovered. In Ack-Always or Ack-On-Error, downlink messages are
necessary to identify lost fragments.
As some communication technologies are highly asymmetrical (e.g.
LPWANs), it may be desirable to use FEC codes to limit trafic in one
direction (e.g. increase the numebr of uplinks to avoid downlinks).
Simply repeating messages may be sub-optimal, depending on the radio
conditions.
This draft introduces a new SCHC Rule type - the FEC RuleID. A SCHC
FEC Fragmentation Rule is bound to a SCHC Fragmentation Rule,
complementing it with the FEC functionality. The SCHC data sent with
the FEC RuleID do not have a meaning or sense on their own. Instead,
they provide the necessary sequence to recover lost fragments.
2. Format
The format of a SCHC FEC Fragment is the following:
Pelov, et al. Expires 13 March 2025 [Page 2]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
|- SCHC FEC Fragment Header -|
|-- T --|-M-|-- N --|
+-- ... -+- ... -+---+- ... -+--------...-----------+~~~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W | FCN | FEC Fragment Payload | padding (as needed)
+-- ... -+- ... -+---+- ... -+--------...-----------+~~~~~~~~~~~~~~~~~~~~
Figure 1: SCHC FEC Fragment Format
3. Operation
The FEC Fragmentation Rule is bound to a Fragmentation Rule. There
MUST be a RuleID allocated in the same space as the RuleID of the
Fragmentation Rule to which it is bound.
The size of DTag, W and FCN MUST be the same as the bound
Fragmentation Rule.)
The FEC Fragmentation operates over a FEC Window (FW), which are the
Tiles over which the FEC Fragment is calculated.
The FEC Window consists of FW tiles. The size of the FW can be fixed
(e.g. in the Profile) or variable (e.g. depending on the MTU).
The FEC Fragment allows to recover some (or all) of the Tiles in its
FEC Window.
The DTag, W and FCN values indicate which is the LAST tile of the FEC
Window to which a given FEC Fragment refers to.
A SCHC FEC Fragmentation Profile defines the algorithm to use for the
calculation of the FEC and relevant parametrs.
It is RECOMMENDED that a FEC Fragment fits in a single MTU.
A change in the MTU during a fragmentation session may lead to a
change in the FEC Window size. Change in the radio conditions may as
well influence the FEC Window size. The SCHC FEC Fragmentation
Profile MUST define the behavior in case of dynamic change of the MTU
and/or the FEC Window size. A RECOMMENDED behavior is to restart the
FEC calculation, starting with the first Tile after the FEC Window
size was changed. If the FEC Window size or the MTU change
dynamically all participating SCHC End-points MUST have a way of
knowing this.
For example, in LoRaWAN a MAC Command may indicate change of the
DataRate, which in turn changes the MTU, which in turn may change the
FEC Window Size. In this case, the L2 technology provides the
protocol machinery for this update.
Pelov, et al. Expires 13 March 2025 [Page 3]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
A sender MAY send a FEC Fragment at any moment. Typically, a FEC
Fragment is sent after each N_FW number of fragments. However, this
may depend on the radio conditions and the network operator.
Note that the SCHC FEC Fragmentation operates only with SCHC
Fragments. Other types of messages (ACK, All-0, All-1, Abort, etc.)
are not covered by this draft.
SCHC FEC Fragmentation fields (DTag, W, FCN) MAY be aligned with the
corresponding SCHC Fragmentation fields. It is possible, however, to
send FEC Fragments, which are not aligned with the bound SCHC
Fragmentation. For example, a FEC fragment can be sent before the
end of a SCHC fragmentation session, covering the final tiles that
are piggybacked in an All-1 message.
Fragment A Fragment B FEC Fragment
+------------------+ +------------------+ +-----------------+
| RuleID = 20/8 | | RuleID = 20/8 | | RuleID = 30/8 |
+------------------+ +------------------+ +-----------------+
| W | FCN | Frag. A| | W | FCN | Frag. B| | W | FCN | FEC |
| 0 | 62 | Tiles | | 0 | 50 | Tiles | | 0 | 39 | Tiles |
+------------------+ +------------------+ +-----------------+
\ \ / / / /
\ \ / / / /
\ \ / / / /
+-------+ +-------+ +------+
|Frag. A| XOR |Frag. B| => |FEC |
|Tiles | |Tiles | |Tiles |
+-------+ +-------+ +------+
^12 tiles^ ^12 tiles^ ^12 tiles^
W=0 W=0 W=0
FCN=62 FCN=50 FCN=50-12+1=39
^------FEC Window------^ > Last tile of
previous fragment.
Figure 2: FEC Fragment concept and calculation example with
sample values following RFC9011.If Fragment B is lost in the
transmission, the receiver end may recover it by performing a
bitwise XOR operation between Fragment A and FEC Fragment.
Pelov, et al. Expires 13 March 2025 [Page 4]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
+--------------------------+ +----------------------------+
| SCHC Fragmentation | | SCHC FEC Fragmentation |
|--------------------------| |----------------------------|
| - Splits data into Tiles | | - Operates over FEC Window |
| - Uses DTag, W, FCN | | - Uses DTag, W, FCN |
| - Data transmission | | - Calculates FEC over Tiles|
+--------------------------+ +----------------------------+
| |
v v
+--------------------------+ +----------------------------+
| SCHC Fragments | | SCHC FEC Fragments |
|--------------------------| |----------------------------|
| - Contains data | | - Contains FEC code |
| - Indexed by DTag, W, FCN| | - Helps recover lost Tiles |
+--------------------------+ +----------------------------+
| |
v v
+--------------------------+ +----------------------------+
| Transmission to Receiver| | FEC Recovery Mechanism |
|--------------------------| |----------------------------|
| - Regular SCHC Fragments | | - Uses FEC Fragments |
| - As per fragmentation | | - Complements SCHC Frags |
| rules | | - Enhances reliability |
+--------------------------+ +----------------------------+
Figure 3: Difference between SCHC Fragments and SCHC FEC Fragments
Pelov, et al. Expires 13 March 2025 [Page 5]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
+------------------+ +------------------+
| New SCHC | ---------> | Init SCHC FEC |
| Fragmentation | | Fragmentation |
| Session | | Information |
| Start | | for that Session |
| (Init DTag, W, | | (Init FEC.DTag, |
| FCN) | | FEC.W, FEC.FCN) |
+------------------+ +--------+---------+
|
+--------------------------------+
|
v
+-------------------+ No +------------------+
|SCHC Fragment | ---------> | Release SCHC FEC |
| Session Ongoing |<----+--+ | Ressources for |
+---+---------------+ | | | this session.End.|
| Yes | | +------------------+
v | |
+-------------------+ No | | +------------------+
| Send FEC Fragment?|---->+ +<--| Chose FEC.DTag, |
| | | FEC.W, FEC.FCN, |
| Use algorithm | | Calculate FEC, |
| to decide to send | | |
| FEC Fragment | Yes | Send FEC Fragment|
| or not. |----------> | |
+-------------------+ +------------------+
Figure 4: State Machine of FEC Fragment Sender. Note that the
FEC Fragments can be sent at any time. Often, this could be
after the emission of a SCHC Fragment (e.g. sending a new FEC
Fragment every 2 SCHC Fragments), but that could be extended to a
time-based FEC Fragment emission (e.g. every 4 hours), or some
other parameter. Typically, the FEC Fragment sent will be
relative to the last SCHC Fragment, but it could refer to any
other tile. Receivers are not required to keep a trace of the
SCHC FEC Fragments they receive.
Pelov, et al. Expires 13 March 2025 [Page 6]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
+------------------+ +------------------+
| Start | ---------> | Init SCHC FEC |
| New SCHC | | Fragmentation |
| Fragmentation | | Information |
| Session | | for that Session |
| (Init DTag, W, | | (Init FEC.DTag, |
| FCN) | | FEC.W, FEC.FCN) |
+------------------+ +--------+---------+
|
+--------------------------------+
|
v
+-------------------+ No +------------------+
| SCHC Fragment | ---------> | Release SCHC FEC |
| Session Ongoing |<----+--+ | Resources for |
+---+---------------+ | | | this session. End|
| | | +------------------+
v | |
v | |
+-------------------+ No | | +------------------+
| Receive FEC |---->+ | | Use DTag,W,FCN |
| Fragment | | | to determine FEC |
| | | | Window position. |
| | Yes | | If possible, |
| |----------> | recover missing |
| | | | fragment(s). |
+-------------------+ | +--------+---------+
+--+ |
^ v
| +------------------+
| | FEC integrated in|
| | Fragmentation ? |
| +------------------+
| |
+--------------------------------+
| | |
Yes v | No v
+-------------------+ | +------------------+
| Process | | | Send recovered |
| SCHC Fragment | | | SCHC Fragment |
| as per |---->+<-----| to Fragmentation |
| Fragmentation FSM | | process |
+-------------------+ +------------------+
Pelov, et al. Expires 13 March 2025 [Page 7]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
Figure 5: State Machine of FEC Fragment Receiver. FEC Fragments
can be received at any time. The reception of a FEC Fragment may
allow to recover missing SCHC Fragments. If the data of a SCHC
Fragment is recovered, depending on the implementation there are
several options. One is to generate a SCHC Fragment
corresponding to the lost SCHC Fragment and send it to the SCHC
Fragmentation process (e.g. through an API call or as if it was
received through the lower-layer). Alternatively, the SCHC
Fragmentation process may be the one implementing the FEC
mechanism, in which case the recovery of a piece of data may be
processed internally.
4. SCHC FEC Fragment Profile for XOR over RFC9011 Uplink Fragmentation
One simple method for constructing a FEC fragment between SCHC
fragments of the same size is to apply an Exclusive OR (XOR)
operation on every two SCHC fragments and send the resulting value as
the FEC fragment as an additional message. A receiver needs any 2 of
the three fragments to recover the initial two fragments.
This example provides a SCHC FEC Fragment Profile bound to RFC9011
Uplink Fragmentation. SCHC FEC Fragment Rule ID = 30, bound to SCHC
Fragment RuleID = 20.
* SCHC fragmentation reliability mode: ACK-on-Error.
* SCHC header size: 2 bytes (the FPort byte + 1 additional byte).
* RuleID: 8 bits stored in the LoRaWAN FPort (cf. Section 5.2).
* DTag: Size T = 0 bits, not used (cf. Section 5.6.1).
* Window index: 4 windows are used, encoded on M = 2 bits.
* FCN is 6 bits.
* Tile size: 10B
* The tiles per SCHC Fragment are denoted with Tiles per Fragment:
TF = MTU size / Tile size (10).
* FEC Window (FW) is TF*2 tiles.
* The FEC Fragment contains TF tiles.
The default alrogithm to determine when to send a SCHC FEC Fragment
is: * One SCHC FEC Fragment for every two SCHC Fragments. The FEC
Window covers the tiles of the two latest SCHC Fragments.
Pelov, et al. Expires 13 March 2025 [Page 8]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
The FEC is calculated as follows: * The FEC Window is divided in two
halves, Left and Right, or Fragment A Tiles and Fragment B Tiles. *
The FEC is a bitwise XOR operation between the two halves. * FEC =
Left XOR Right.
SCHC Packet: 250 Bytes MTU: 50 Bytes TF = MTU / Tile size = 50 / 10 =
5 tiles per fragment
+--------------------------------------------+
| SCHC Packet |
+--------------------------------------------+
Fragment# | 1 | 2 | 3 | 4 | 5 |
Byte# | 0-49 | 50-99 | 100-149| 150-199| 200-249|
Tile# | 24..20 | 19..15 | 14..10 | 9..5 | 4..0 |
Window# |--------------------- 0 --------------------|
Figure 6: Example of SCHC Packet of 250B fragmented in 5
fragments of 50B, one window and 5 tiles per fragment.
In this example, there will be two SCHC FEC Fragments generated after
SCHC Fragment 2 and SCHC Fragment 4.
SCHC FEC Fragment 1 will have the following format:
SCHC FEC Fragment 1
| Rule ID| W | FCN |
+--------+---+-------+-------------------------------+
| 30/8 | 0 | 15 | Tiles 24..20 XOR Tiles 19..15 |
+--------+---+-------+-------------------------------+
Figure 7: The first SCHC FEC Fragment
SCHC FEC Fragment 2
| Rule ID| W | FCN |
+--------+---+-------+-------------------------------+
| 30/8 | 0 | 5 | Tiles 14..10 XOR Tiles 9..5 |
+--------+---+-------+-------------------------------+
Figure 8: The second SCHC FEC Fragment
If we illustrate the example based on the SCHC Fragments, we have the
following:
Pelov, et al. Expires 13 March 2025 [Page 9]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
+--------------------------------------------------------------+
| SCHC Packet |
+--------------------------------------------------------------+
SCHC Fragments
Fragment# | 1 | 2 | - | 3 | 4 | - | 5 |
Byte# | 0-49 | 50-99 | - | 100-149| 150-199| - | 200-249|
Tile# | 24..20 | 19..15 | - | 14..10 | 9..5 | - | 4..0 |
Window# |--------------------------- 0 --------------------------------|
SCHC FEC Fragments (SCHC Fragments)
FEC FCN | - | - | 15 | - | - | 5 | - |
FEC Data | - | - | 1 XOR 2| - | - | 3 XOR 4| - |
Window# |--------------------------- 0 --------------------------------|
Figure 9: The contents of the SCHC Packet sent with Fragmentation
and FEC Fragments
Sender Receiver
|-----Frag (RuleID 20), W=0, FCN=24----->| Fragment 1
|-----Frag (RuleID 20), W=0, FCN=19----->| Fragment 2
|-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 1 tiles XOR Fragment 2 tiles
|-----Frag (RuleID 20), W=0, FCN=14----->| Fragment 3
|-----Frag (RuleID 20), W=0, FCN=9------>| Fragment 4
|-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 3 tiles XOR Fragment 4 tiles
|-----Frag (RuleID 20), W=0, FCN=4------>| Fragment 5
|-----Frag (RuleID 20), W=0, FCN=63+RCS->| Integrity check: success
|<----Frag (RuleID 20), ACK, W=0, C=1 ---| C=1
(End)
Figure 10: Sequence Diagram of the above example, with no losses
on the radio.
Sender Receiver
|-----Frag (RuleID 20), W=0, FCN=24----->| Fragment 1
|-----Frag (RuleID 20), W=0, FCN=19--xx | Fragment 2 lost
|-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 1 tiles XOR Fragment 2 tiles
| | Recover Fragment 2 from FEC (Fragment 1 XOR FEC)
|-----Frag (RuleID 20), W=0, FCN=14--xx | Fragment 3 lost
|-----Frag (RuleID 20), W=0, FCN=9------>| Fragment 4
| | Recover Fragment 3 from FEC (Fragment 4 XOR FEC)
|-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 3 tiles XOR Fragment 4 tiles
|-----Frag (RuleID 20), W=0, FCN=4------>| Fragment 5
|-----Frag (RuleID 20), W=0, FCN=63+RCS->| Integrity check: success
|<----Frag (RuleID 20), ACK, W=0, C=1 ---| C=1
(End)
Figure 11: Sequence Diagram of the above example, with sparce losses.
Pelov, et al. Expires 13 March 2025 [Page 10]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
Sender Receiver
|-----Frag (RuleID 20), W=0, FCN=24--xx | Fragment 1 lost
|-----Frag (RuleID 20), W=0, FCN=19--xx | Fragment 2 lost
|-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 1 tiles XOR Fragment 2 tiles
| | Cannot recover. Discard.
|-----Frag (RuleID 20), W=0, FCN=14--xx | Fragment 3 lost
|-----Frag (RuleID 20), W=0, FCN=9------>| Fragment 4
| | Recover Fragment 3 from FEC (Fragment 4 XOR FEC)
|-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 3 tiles XOR Fragment 4 tiles
|-----Frag (RuleID 20), W=0, FCN=4------>| Fragment 5
|-----Frag (RuleID 20), W=0, FCN=63+RCS->| Integrity check: failed
|<----Frag (RuleID 20), ACK, W=0, C=1 ---| C=0, Bitmap: 0000000000111111111111111
|-----Frag (RuleID 20), W=0, FCN=24--xx | Fragment 6
|-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 5 tiles XOR Fragment 6 tiles
| | Recover Fragment 6 from FEC (Fragment 5 XOR FEC)
|-----Frag (RuleID 20), W=0, FCN=19----->| Fragment 7
|<----Frag (RuleID 20), ACK, W=0, C=1 ---| C=1
(End)
Figure 12: Sequence Diagram of the above example, with frequent
losses.
5. References
The IETF documents referred to here are [RFC8724].
6. Security Considerations
No security considerations.
7. IANA Considerations
8. Normative References
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
Authors' Addresses
Alexander Pelov
IMT Atlantique
2bis rue de la Chataigneraie
35536 Cesson-Sévigné
France
Email: alexander.pelov@imt-atlantique.fr
Pelov, et al. Expires 13 March 2025 [Page 11]
Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
Javier A. Fernandez
IMT Atlantique
2bis rue de la Chataigneraie
35536 Cesson-Sévigné
France
Email: javier-alejandro.fernandez@imt-atlantique.fr
Hoang Quy Nguyen
Actility
65 Rue de la Victoire
Paris
Email: hoang.quynguyen@actility.com
Pelov, et al. Expires 13 March 2025 [Page 12]