Forward Error Correction (FEC) Framework
updated by
- rfc-8680 — Forward Error Correction (FEC) Framework Extension to Sliding Window Codes
Extracted elements (28)
FSSI is split into a Sender-Side FSSI (SS-FSSI) container and a general FSSI container. This separation allows receivers or third-party entities to control FEC encoding operations at the sender without receiving information that is only relevant to the sender.
The Explicit Source FEC Payload ID is placed at the end of the source packet so that header compression schemes such as ROHC can still be applied to the inner protocol headers (e.g., RTP). This placement avoids breaking header compression pipelines when FEC is added to pre-existing protocols.
The FEC Framework complements the FEC Building Block (RFC 5052) by addressing arbitrary packet flows over unreliable transport rather than object delivery. It separates the CDP definition from the FEC scheme definition so that CDPs and FEC schemes can be independently specified and combined.
The FEC Framework is explicitly not intended as a QoS tool to combat congestion-induced packet losses. The bandwidth cap (repair MUST NOT exceed source) and congestion-adaptive rate requirement exist to prevent naively implemented dynamic FEC from destabilizing the network.
Non-FEC-Framework-capable receivers MUST have a means to either not receive repair packets or to identify and discard them. This SHOULD be achieved by sending repair packets on a different transport-layer flow; when RTP is used and source and repair share a UDP flow, different RTP payload types SHOULD distinguish them. Use of the Explicit Source FEC Payload ID must be avoided for backward compatibility with such receivers.
The use of RTP for repair packets is independent of whether RTP is used for source packets. FEC schemes are expected to recover entire transport payloads for recovered source packets in all cases; for RTP source flows this includes recovering the complete UDP payload, including the RTP header.
A CDP specification MUST define how a receiver determines a minimum length of time it needs to wait to receive FEC repair packets for any given source block. FEC schemes MAY define limitations such as maximum source block sizes but SHOULD NOT define specific ADU-to-block mappings.
A complete CDP specification that uses the FEC Framework MUST specify the means to determine and communicate the FEC Framework Configuration Information between sender and receiver.
A FEC scheme specification MUST include: the FEC Encoding ID value registered with IANA; the type, semantics, and encoding format of the Repair FEC Payload ID; names/types/encodings for all FSSI elements; and a full specification of the FEC code that uniquely defines encoding symbol values given source block and valid parameters.
Any FSSI other than information solely required by the sender (SS-FSSI) MUST be communicated via the FSSI container in the FEC Framework Configuration Information, enabling receivers and third-party entities access to all parameters needed for proper FEC decoding operations.
Applications using feedback for congestion control MUST calculate such feedback on the basis of packets received before FEC recovery is applied. If this conflicts with other uses, the application MUST support both pre- and post-FEC recovery feedback calculations to ensure congestion control mechanisms operate on accurate network signals.
Each FEC scheme MUST be specified independently of all other FEC schemes, either in a separate specification or a completely independent section of a larger document. The encoding format of any protocol element MUST have fixed length or length derivable from the encoded bytes themselves.
FEC repair packets MUST contain a Repair FEC Payload ID field that identifies the source block and the relationship between the contained repair payloads and the original source block. The contents and format of this field are defined by the FEC scheme.
FEC source packets MUST be sent using the same ADU flow identification information (e.g., UDP 5-tuple) as would have been used for the original source packets had the FEC Framework not been present. A single FEC repair flow MUST contain only FEC repair packets relating to a single FEC Framework instance.
FEC source packets MUST contain information (the Source FEC Payload ID) that identifies the source block and the position of the ADU within the source block. This MAY be encoded into an Explicit Source FEC Payload ID field appended to the source packet, or MAY be derived from other packet fields as defined by the FEC scheme.
It is RECOMMENDED that FEC schemes support the Generic Explicit Source FEC Payload ID format (2-octet unsigned sequence number in network-byte order) to enable multiple FEC schemes to be applied to a single source flow using a common identifier format.
The bandwidth of FEC repair data MUST NOT exceed the bandwidth of the original source data being protected. Whenever the source data rate is adapted due to congestion control, the FEC repair data rate MUST be similarly adapted.
A Source Block is a group of ADUs that are to be FEC protected as a single block. The FEC Framework handles source flows as a sequence of source blocks, each consisting of an ordered set of ADUs, possibly from multiple source flows, along with each ADU's associated source flow description and length.
An Application Data Unit (ADU) is the unit of source data provided as payload to the transport layer. An ADU flow is a sequence of ADUs associated with a transport-layer flow identified by the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}.
FEC Framework Configuration Information governs operation of the FEC Framework and MUST be available to both sender and receiver. It includes identification of source and repair flows, an integer flow identifier unique per FEC repair flow instance, the FEC Encoding ID, the length of the Explicit Source FEC Payload ID, and zero or more FEC-Scheme-Specific Information (FSSI) elements.
The FEC Encoding ID is a value that uniquely identifies a FEC scheme for use with the FEC Framework. Each new FEC scheme MUST register its FEC Encoding ID value with IANA, as described in Section 11 of this document.
A baseline secure FEC Framework operation based on IPsec/ESP is defined as mandatory-to-implement (but not mandatory-to-use), drawing from the IPsec profiles in RFC 5775 (ALC) and RFC 5740 (NORM). For bidirectional scenarios involving unicast receiver feedback, a second set of IPsec Security Associations is required to protect the feedback path.
Applying FEC protection does not provide any security. The FEC Framework can itself be subject to attacks: forged or replayed FEC source/repair packets can corrupt decoding or cause DoS; tampered FEC Framework Configuration Information (sent out-of-band) can prevent decoding; and modified Repair FEC Payload IDs can assign packets to wrong source blocks.
It is RECOMMENDED that integrity protection (e.g., SRTP with TESLA, or IPsec/ESP) be applied to both FEC source and repair packets to prevent corrupted packets from entering decoding, which would otherwise cause decoding failure or produce a corrupted source flow. The FEC Framework Configuration Information SHOULD also be integrity-protected, for example by digital signature when sent out-of-band.
When encryption is applied for confidentiality, it MUST be applied either before FEC encoding on the source data, or after FEC encoding on both FEC source packets and repair packets with at least equivalent cryptographic strength. Encrypting only FEC source packets after encoding allows an attacker to recover plaintext from unencrypted repair packets.
An FEC Repair Packet consists of: IP Header, Transport Header, Repair FEC Payload ID field, and Repair Symbols. When RTP is used for repair packets, an RTP Header precedes the Repair FEC Payload ID, followed by the Repair Symbols.
An FEC Source Packet consists of: IP Header, Transport Header, Application Data Unit, and an optional Explicit Source FEC Payload ID field appended at the end. The Explicit Source FEC Payload ID is placed last so that ROHC header compression can still be applied to the inner protocol headers.
The Generic Explicit Source FEC Payload ID is exactly two octets in length and encodes an unsigned packet sequence number in network-byte order. Source packets within a given source block MUST have consecutive sequence numbers, with wrap-around from 65535 to 0.