Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
Extracted elements (31)
m=8 is the recommended default because it allows small-to-medium source blocks (up to 255 encoding symbols) while keeping GF elements byte-aligned, enabling efficient read/write memory operations during encoding and decoding. m=4 suits very small blocks; m=16 suits very large blocks but at high computational and memory cost.
Reed-Solomon codes over GF(2^^m) are Maximum Distance Separable (MDS): a receiver can recover all k source symbols from any set of exactly k encoding symbols, providing optimal erasure protection. They are also systematic, so source symbols are part of the encoding symbols, greatly simplifying decoding.
The E parameter has two modes controlled by the S flag: S=0 (E is the maximum symbol length per session; actual per-block E is determined from the size of the first received repair symbol) and S=1 (E is strictly fixed for all blocks). This accommodates variable-length ADU flows while maintaining a constant per-block encoding symbol size required by RS codes.
The Source Block Length (k) field is fixed at 16 bits in both Source and Repair Payload IDs regardless of m, providing a single common format for all m values. While 16 bits exceeds what is needed for m <= 8, it is necessary when 8 < m <= 16.
The specification is designed for compatibility with Luigi Rizzo's widely-deployed Reed-Solomon codec, which is already used by many applications for packet-based erasure recovery. The goal was to specify a simple RS scheme compatible with that codec within the FECFRAME context.
For TRILL (RFC 6325), IS-IS is constrained to operate only over TRILL links and not over external IP or Ethernet links, ensuring that TRILL IS-IS traffic is isolated from general IS-IS routing domains.
The core Reed-Solomon code specification (based on Vandermonde matrices) is inherited from Section 8 of RFC 5510. Sections 4-7 of RFC 5510, which define RFC 5052-specific formats and procedures for object delivery, are not used and are replaced by the FECFRAME-specific formats defined in this document.
When m=16, the theoretical maximum of 65535 encoding symbols enables very large source blocks, but at significantly higher processing cost; pre-calculated tables may require prohibitive memory on embedded platforms. Lightweight alternatives such as LDPC FEC (RFC 5170) may be preferred when processing load is a concern and large source blocks are needed.
A FEC repair packet MUST contain a Repair FEC Payload ID prepended to the repair symbol(s), and there MUST be a single repair symbol per FEC repair packet.
A FEC source packet MUST contain an Explicit Source FEC Payload ID appended to the end of the packet, comprising the Source Block Number, Encoding Symbol ID, and Source Block Length fields.
If confidentiality is a concern, it is RECOMMENDED that one of the solutions mentioned in RFC 6363 be used, with special considerations given to whether encryption is applied before or after FEC protection and to the threat model.
In situations where the use case does not specify an m value, the default m=8 MUST be used. Any compliant implementation MUST support at least the default m=8 value.
It is RECOMMENDED that security measures be taken to guarantee FFCI integrity, protecting against attacks that modify the FEC Encoding ID, E, S flag, or m parameters. How to achieve this depends on the FFCI communication mechanism and is not specified in this document.
The FEC Encoding ID for this Fully-Specified FEC Scheme MUST be 8, as assigned by IANA. When SDP is used to communicate the FFCI, this value MUST be carried in the 'encoding-id' parameter of the 'fec-repair-flow' attribute specified in RFC 6364.
The SBN MUST start at 0 for the first source block and MUST be incremented by 1 for each new block. ESI values MUST start at 0 and be managed sequentially, with 0 <= ESI <= k-1 identifying source symbols and k <= ESI <= n-1 identifying repair symbols.
The use case SHOULD define which m parameter value or values need to be supported, since several values are possible and agreement on a common m value is necessary for interoperability.
There MUST be exactly one source symbol per ADUI (and therefore per ADU), exactly one repair symbol per FEC Repair Packet, and exactly one source block per ADU block.
To counter content corruption, it is RECOMMENDED that one of the integrity/authentication solutions mentioned in RFC 6363 be used on both the FEC Source and Repair Packets.
The ADU Information (ADUI) for ADU i consists of a 1-byte Flow ID (F[i]), a 2-byte Length field (L[i]) in network byte order, the ADU payload, and zero padding (Pad[i]) to align to exactly E bytes. Each ADUI is exactly one source symbol; the F[i], L[i], and Pad[i] fields are never transmitted over the network.
The Explicit Source FEC Payload ID consists of a (32-m)-bit Source Block Number, an m-bit Encoding Symbol ID (ESI), and a 16-bit Source Block Length (k). The total payload ID is always 6 bytes regardless of m.
The FEC Scheme-Specific Information (FSSI) comprises: E (Encoding Symbol Length, non-negative integer < 2^^16), S (Strict flag, 1-bit: 1 means E is fixed for all blocks, 0 means E is the maximum), and m (finite field element length in bits, 2 <= m <= 16). All three are required by both encoder and decoder.
The maximum ADU block size max_B is computed as min(max_k, max_rt), where max_k = floor((2^^m - 1) * CR) constrains the block size to allow room for repair symbols, and max_rt = floor(l / d) constrains it based on real-time latency l and per-ADU duration d.
The Repair FEC Payload ID has the same structure as the Source FEC Payload ID — (32-m)-bit SBN, m-bit ESI, 16-bit k — but the ESI identifies repair symbols (k <= ESI <= n-1). It is prepended to the repair symbol in the FEC repair packet.
This document registers FEC Encoding ID value 8 ('Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary Packet Flows') in the 'FEC Framework (FECFRAME) FEC Encoding IDs' subregistry of the 'Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs' IANA registry.
Modifying FFCI parameters enables Denial of Service attacks: changing the FEC Encoding ID causes the receiver to use a different scheme; setting E too small creates incoherency for received symbols; changing m causes sender and receiver to interpret Payload ID fields differently and may impose excessive decoding load.
Modifying the SBN, ESI, or k fields in the Explicit Source FEC Payload ID or Repair FEC Payload ID can corrupt the source block identified by the SBN. Security measures are RECOMMENDED to protect the integrity of FEC Source and Repair Packets.
The baseline secure FECFRAME operation requires IPsec/ESP as mandatory-to-implement (but not mandatory-to-use), suitable when the only insecure domain is the one over which FECFRAME operates. The RS FEC Scheme does not change this recommendation from RFC 6363.
Each ADUI prepends 3 bytes to the ADU before FEC encoding: F[i] (1 byte Flow ID) and L[i] (2 bytes ADU length, big-endian). Zero padding Pad[i] follows the ADU to reach size E. These 3 header bytes and padding are present during encoding but are never sent on the wire.
For m=8 (default), the Repair FEC Payload ID is 6 bytes: 24-bit SBN | 8-bit ESI | 16-bit k (Figure 8). For m=16, it is 6 bytes: 16-bit SBN | 16-bit ESI | 16-bit k (Figure 9), matching the Source FEC Payload ID layout.
For m=8 (default), the Source FEC Payload ID is 6 bytes: 24-bit SBN | 8-bit ESI | 16-bit k (Figure 5). For m=16, it is also 6 bytes: 16-bit SBN | 16-bit ESI | 16-bit k (Figure 6). The format is parameterized by m.
The FSSI opaque octet-string encoding is 3 octets: a 16-bit Encoding Symbol Length (E) field, followed by a 1-bit Strict (S) flag and a 7-bit m parameter (Figure 3).