Basic Forward Error Correction (FEC) Schemes
obsoletes
Extracted elements (26)
A dedicated FEC Encoding ID (129) was defined specifically for Small Block Systematic FEC codes rather than reusing the generic Under-Specified ID (128). Systematic codes frequently have small source blocks requiring dynamic block length changes; embedding Source Block Length directly in each Payload ID communicates this per-packet with minimal overhead, avoiding repeated out-of-band signaling.
Complete encoding formats for FEC Object Transmission Information are defined within the FEC Scheme specifications themselves rather than within content delivery protocol specifications. This change from RFC 3452 / RFC 3695 practice reflects that the exact OTI format depends on the FEC Scheme, not on the overlying protocol.
The Compact No-Code FEC Scheme exists primarily to enable interoperability testing between different implementations of protocols using the FEC building block, without requiring either party to implement an actual FEC codec. Assigning it FEC Encoding ID 0 (the lowest Fully-Specified value) reflects its baseline role.
This document introduces a new requirement that the Encoding Symbol Length be uniform across all source blocks of a transport object, which was not required by RFC 3452 or RFC 3695. Because no protocols were defined that supported per-source-block variation in Encoding Symbol Length, this tightening is stated to introduce no backwards compatibility issues.
This Proposed Standard is backwards compatible with the Experimental FEC Schemes defined in RFC 3452 and RFC 3695. All integer fields are encoded in network byte order. This document obsoletes RFC 3695 and assumes responsibility for the FEC Scheme portions of RFC 3452 not already absorbed by RFC 5052.
All Encoding Symbols of a transport object MUST have length equal to the Encoding Symbol Length element, with the optional exception of the last source symbol of the last source block. This uniformity requirement was not present in RFC 3695 or RFC 3452.
For the Small Block Systematic FEC Scheme, the RFC 5052 Section 9.1 partitioning algorithm MAY be used; if it is not used, the FEC Scheme instance MUST specify the partitioning algorithm. This allows systematic FEC instances with non-standard block structures to define their own partitioning.
In non-unique SBN mode for the Compact No-Code FEC Scheme, the mapping from source blocks to Source Block Numbers MUST be communicated out-of-band to receivers; how this is done is outside the scope of this document. The mapping may be implicit, for example determined by the transmission order of source blocks.
In non-unique SBN mode, packets for two different source blocks mapped to the same Source Block Number SHOULD NOT be sent within an interval shorter than the transport time of a source block (sender processing + network transit + receiver processing). This ensures receivers can unambiguously assign packets to source blocks.
The Compact FEC Scheme SHALL use the FEC Payload ID format defined for the Compact No-Code FEC Scheme in Section 3.2.1, and the Scheme-Specific FEC OTI format from Section 4.2.2.3 SHALL be used.
The file-partitioning algorithm defined in Section 9.1 of RFC 5052 MUST be used to partition an object into source blocks for the Compact No-Code FEC Scheme (Section 3.3), the Small Block/Large Block/Expandable FEC Scheme (Section 4.3), and the Compact FEC Scheme (Section 6.3).
The last source symbol of the last source block MUST be logically padded with zeroes when another Encoding Symbol is computed based on it, ensuring consistent interpretation by sender and receiver. The padded bytes need not actually be transmitted with the last source symbol's data.
The Reserved field in the Compact No-Code Encoded Common FEC OTI MUST be set to zero by senders, and its value MUST be ignored by receivers.
When a Content Delivery Protocol does not support external signaling of the total FEC OTI length, the Scheme-Specific FEC OTI field MUST be included for schemes using the Section 4.2.2.3 format (IDs 128, 129, 130). If Length is zero, three zero-valued padding bytes SHALL follow the Length field to maintain 4-octet alignment.
The Compact FEC Scheme (FEC Encoding ID 130) is an Under-Specified FEC Scheme similar in structure to the Compact No-Code Scheme but permitting a non-trivial Under-Specified FEC encoding. It reuses the Compact No-Code FEC Payload ID format (Section 3.2.1) and the Common OTI format from Section 4.
The Compact No-Code FEC Scheme (FEC Encoding ID 0) is a Fully-Specified FEC Scheme requiring no FEC encoding or decoding. Each encoding symbol consists of consecutive bytes of a source block, and the scheme is specified primarily to enable interoperability testing between implementations using the FEC building block.
The Small Block, Large Block, and Expandable FEC Scheme (FEC Encoding ID 128) is an Under-Specified FEC Scheme supporting three categories of FEC codes as described in RFC 3453. The specific FEC code is identified by the FEC Instance ID and its correspondence between Encoding Symbol IDs and encoding symbols may be proprietary.
The Small Block Systematic FEC Scheme (FEC Encoding ID 129) is an Under-Specified FEC Scheme for systematic codes where each source block is at most 65535 source symbols. A dedicated FEC Encoding ID is used rather than ID 128 to enable inclusion of Source Block Length in the Payload ID for low-overhead dynamic block length variation.
FEC Encoding ID 0 (Compact No-Code, Fully-Specified) and FEC Encoding ID 130 (Compact FEC, Under-Specified) are assigned in the ietf:rmt:fec:encoding namespace by this document, updating and obsoleting the prior assignments from RFC 3695.
FEC Encoding ID 128 (Small Block, Large Block, and Expandable FEC Codes) and FEC Encoding ID 129 (Small Block Systematic FEC Codes) are assigned as Under-Specified in the ietf:rmt:fec:encoding namespace, updating RFC 3452. Three corresponding FEC Instance ID sub-namespaces (ietf:rmt:fec:encoding:instance:128, :129, :130) are established with First Come First Served assignment policy.
This specification introduces no security considerations beyond those described in the FEC building block specification RFC 5052. Implementors should refer to RFC 5052 for all applicable security guidance.
The encoded Common FEC OTI for the Compact No-Code FEC Scheme is 10 bytes: Transfer Length (48 bits), Reserved (16 bits), Encoding Symbol Length (16 bits), and Maximum Source Block Length (32 bits), all unsigned integers in network byte order.
The encoded Common FEC OTI for the Small Block Systematic FEC Scheme is 14 bytes: Transfer Length (48 bits), FEC Instance ID (16 bits), Encoding Symbol Length (16 bits), Maximum Source Block Length (16 bits, max 65535), and Maximum Number of Encoding Symbols (16 bits), all as unsigned integers.
The FEC Payload ID for the Compact No-Code FEC Scheme is 32 bits: a 16-bit unsigned Source Block Number (SBN) followed by a 16-bit unsigned Encoding Symbol ID (ESID). SBN identifies which source block the encoding symbol originates from; ESID identifies the specific encoding symbol within that block.
The FEC Payload ID for the Small Block Systematic FEC Scheme is 96 bits: a 32-bit Source Block Number, a 16-bit Source Block Length (in source symbols), and a 16-bit Encoding Symbol ID. Embedding Source Block Length in each packet enables receivers to track dynamically varying block sizes without out-of-band signaling.
The Scheme-Specific FEC OTI field for the Small Block, Large Block, and Expandable FEC Scheme begins with a 1-octet Length field specifying the total field length in 4-octet words. A Length of zero indicates no Instance-specific OTI, in which case three zero-valued padding bytes SHALL follow to maintain 4-octet alignment.