Forward Error Correction (FEC) Building Block
obsoletes
- rfc-3452 — Forward Error Correction (FEC) Building Block
Extracted elements (25)
The FEC building block separates the concept of an 'FEC Scheme' from an 'FEC code' or algorithm. An FEC scheme defines ancillary information and procedures that, combined with an FEC code specification, fully define how the FEC code can be used with CDPs. This separation allows CDPs to operate with a range of FEC codes without knowing the details of each specific code.
This document was elevated from Experimental (RFC 3452) to Proposed Standard status because congestion control strategies suitable for use with Reliable Multicast protocols became available. The update also introduced explicit FEC OTI classes (Mandatory, Common, Scheme-specific) to allow reusable CDP field definitions and independent definition of FEC schemes and CDPs.
Two types of FEC schemes are defined: Fully-Specified (where the encoding scheme is formally specified in an IETF RFC enabling independent implementation) and Under-Specified (where the specification is unavailable or proprietary). This distinction allows standardization of the framework without requiring all FEC algorithms to be publicly specified.
FEC schemes for systematic FEC codes MAY specify two FEC Payload ID formats: one for packets carrying only source symbols and another for packets carrying at least one repair symbol. CDPs must include an indication of which format is used in each packet if they wish to support such FEC schemes.
A CDP specification MUST include: encoding formats for Mandatory FEC OTI elements; means to reliably communicate Mandatory, Common, and Scheme-specific FEC OTI from sender to receiver(s); and a means to communicate the FEC Payload ID in association with a data packet.
A data packet that carries encoding symbols MUST include an FEC Payload ID. The FEC Payload ID identifies (for FEC purposes) the encoding symbols carried by the packet and is essential to the decoder whenever the packet is received.
A specification for a new FEC scheme MUST include: the FEC Encoding ID registered with IANA; the type, semantics, and encoding format of one or two FEC Payload IDs; the type and semantics of the FEC OTI; and an encoding format for Common FEC OTI elements used. Fully-Specified schemes MUST additionally provide a full FEC code specification and description of practical encoding/decoding algorithms.
An already defined Under-Specified FEC Scheme (i.e., FEC Encoding ID value) MUST be reused if the associated FEC Payload ID and FEC Object Transmission Information have the required fields and encoding formats for a new Under-Specified FEC scheme instance.
An FEC Scheme MUST define an encoding format for the Common FEC OTI elements it uses. The encoding format length MUST either be fixed or derivable from examining the encoded octets themselves. If no Scheme-specific FEC OTI element is defined, such an element MUST NOT be introduced in future versions of the FEC scheme.
An instance of an Under-Specified FEC scheme is fully identified by the tuple (FEC Encoding ID, FEC Instance ID). This tuple MUST identify a single scheme instance with at least one implementation, and the owning party MUST be able to provide information on how to obtain the scheme instance.
Any complete multicast CDP MUST provide congestion control that conforms to RFC 2357, specifically Section 3.2. Congestion control MUST be provided by another building block when the FEC building block is used in a CDP, as the FEC building block itself provides no congestion control support.
For all FEC schemes (Fully-Specified or Under-Specified), the type, semantics, and an encoding format for the FEC Payload ID and FEC Object Transmission Information MUST be defined, and a value for the FEC Encoding ID MUST be reserved and associated with these definitions.
The FEC Instance ID MUST be used by all Under-Specified FEC schemes and MUST NOT be used by Fully-Specified FEC schemes. CDPs providing an encoding format for Common FEC OTI elements MUST support values up to (2^^16)-1 for FEC Instance ID, (2^^48)-1 for Transfer-Length, and (2^^32)-1 for other elements.
The value of the FEC Encoding ID MUST be the same for all transmissions of encoding symbols related to a particular object, but MAY vary across different transmissions of encoding symbols about different objects, even if transmitted to the same multicast channels.
Common FEC OTI elements include: FEC Instance ID (0-65535), Transfer-Length (object length in octets, up to 2^^48-1), Encoding-Symbol-Length (symbol length in octets), Maximum-Source-Block-Length (maximum source symbols per source block), and Max-Number-of-Encoding-Symbols. CDP encoding formats MUST support specified maximum value ranges for each.
FEC Object Transmission Information (OTI) contains information essential to the decoder for decoding the encoded object. It consists of three element types: Mandatory (defined in this specification, required per FEC scheme type), Common (defined in this specification, optional per FEC scheme), and Scheme-specific (defined by the FEC scheme, opaque to the CDP).
FEC schemes are identified by an FEC Encoding ID, an integer identifier assigned by IANA. The FEC Encoding ID allows receivers to select the appropriate FEC decoder. Values 0-127 are reserved for Fully-Specified FEC schemes; values 128-255 are reserved for Under-Specified FEC schemes.
The Block Partitioning Algorithm partitions an object into source blocks as equal in length as possible. Given object transfer length (L), Maximum Source Block Length (B), and Symbol Length (E), it computes T = ceil[L/E] source symbols and N = ceil[T/B] source blocks, then distributes symbols into I larger blocks of A_large = ceil[T/N] symbols and N-I smaller blocks of A_small = floor[T/N] symbols.
The FEC Instance ID is an integer value that identifies a specific instance of an Under-Specified FEC scheme. It is scoped by the FEC Encoding ID, is not used for Fully-Specified FEC schemes, and its values are subject to IANA registration. The FEC Instance ID ranges from 0 to 65535.
The FEC Payload ID contains information indicating to the FEC decoder the relationships between encoding symbols in a packet and the FEC encoding transformation. It is defined by the FEC scheme and carried within data packets as specified by the CDP. Its size SHOULD be a small fraction of the packet size.
The Mandatory FEC OTI element is the FEC Encoding ID: an integer between 0 and 255 inclusive identifying a specific FEC scheme (Fully-Specified or Under-Specified). Its encoding format is defined by the CDP.
IANA maintains the 'Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs' registry. FEC Encoding IDs (0-255) are assigned on an IETF Consensus basis; FEC Instance IDs (0-65535) scoped to Under-Specified FEC scheme Encoding IDs (128-255) are assigned on a First Come First Served basis. Requestors for FEC Instance IDs must provide contact information and a pointer to publicly accessible documentation.
Data delivery is subject to denial-of-service attacks via corrupted packets accepted as legitimate. For multicast, a corrupted packet injected near the multicast tree root reaches many receivers; even one corrupted FEC encoding packet may cause an entirely corrupted decoded object. It is RECOMMENDED that source authentication and integrity checking (e.g., SHA-1 hash with digital signature) be applied to decoded objects before delivery to an application.
FEC Object Transmission Information obtained out-of-band via session descriptions is a security concern: a forged or corrupted session description causes receivers to use incorrect protocol parameters for decoding. It is RECOMMENDED that source authentication be used to ensure receivers only accept legitimate session descriptions from authorized senders.
It is RECOMMENDED that a packet authentication protocol such as TESLA (RFC 4082) be used to detect and discard corrupted packets upon arrival. Furthermore, Reverse Path Forwarding checks are RECOMMENDED in all routers/switches along the sender-to-receiver path to limit bad agents from injecting corrupted packets into the multicast data path.