rfc-6681

Raptor Forward Error Correction (FEC) Schemes for FECFRAME

M. Watson, T. Stockhammer, M. Luby
date2012-08 streamIETF areatsv wgfecframe statusPROPOSED STANDARD pages22 canonicalhttps://www.rfc-editor.org/rfc/rfc6681 doi10.17487/RFC6681
This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g., UDP) or using RTP. [STANDARDS-TRACK]

Extracted elements (28)

design-rationale §7.1

The optimized scheme (Schemes 3 and 4) restricts MSBL to a small specified set of values so that explicit encode/decode operation sequences for those block lengths can be pre-calculated and embedded in software or hardware, enabling substantial implementation optimizations.

design-rationale §1

The single sequenced flow variant (Schemes 5 and 6) leaves source packets unmodified—using no Source FEC Payload ID—because sequence numbers already present in the source flow can derive all necessary FEC identification information, providing backwards compatibility advantages.

design-rationale §6.2.1.2

Two Source and Repair FEC Payload ID formats (A and B) are provided because format A is appropriate when the stream has many typically smaller source blocks (16-bit SBN, 16-bit ESI), while format B is applicable when the stream has fewer large source blocks each with many encoding symbols (8-bit SBN, 24-bit ESI).

interoperability-note §6.1

FEC Scheme 1 (Raptor for arbitrary packet flows) is equivalent to the scheme defined in 3GPP TS 26.346 (MBMS Protocols and codecs); Schemes 3 and 5 (optimized and single sequenced flow using Raptor) are equivalent to those defined in ETSI TS 102.034 (DVB over IP).

normative-requirement §8.2.2 MUST

All repair packets associated with a given source block MUST contain the same Source Block Length and Initial Sequence Number.

normative-requirement §7.4 REQUIRED

For FEC Scheme 3, MSBL SHALL be set to one of the following values: 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 1139, 1281; for Scheme 4, MSBL SHALL be one of the supported K' values from RFC 6330 Section 5.6.

normative-requirement §7.1 MUST

For optimized Schemes 3 and 4, MSBL MUST be selected as the smallest permissible value (from the defined set) that is greater than or equal to K; the value of SBL SHALL be at most MSBL.

normative-requirement §8.2.4 REQUIRED

For RTP source flows using Schemes 5 or 6, the RTP Sequence Number field SHALL be used as the sequence number, and the length indication SHALL be the RTP payload length plus CSRCs, Header Extension, and padding (always equal to UDP payload length minus 12).

rtp

normative-requirement §6.4 MUST NOT

For Schemes 1 and 2, the value of K used by the FEC encoder (equal to SBL) SHALL NOT exceed the Maximum Source Block Length signaled in the FEC-Scheme-Specific Information.

normative-requirement §6.2.1.2 MUST NOT

Payload ID format B SHALL NOT be used for FEC Scheme 1; the last octet of FEC-Scheme-Specific Information SHOULD be omitted when format A is in use.

normative-requirement §6.4 REQUIRED

The FEC encoder defined in RFC 5053 SHALL be used for Schemes 1, 3, and 5; the FEC encoder defined in RFC 6330 SHALL be used for Schemes 2, 4, and 6.

normative-requirement §6.3.1 MUST

The sender MUST allocate Source Block Numbers to source blocks sequentially, wrapping around to zero after SBN 65535 (format A) or 255 (format B).

normative-requirement §1 MUST

The sender MUST transmit source and repair packets in different source and repair flows, or in different RTP streams when RTP transport is used for repair packets.

normative-requirement §8.2.2 MUST

The Source Block Length LB MUST be chosen such that it is at least as large as the largest Source Packet Information Length LP within the source block.

normative-requirement §8.2.2 MUST

The source packet flow processed by the FEC encoder MUST have consecutive sequence numbers; if a gap exists, implementors SHOULD insert a compliant dummy ADU that the application ignores with high probability.

protocol-element §5

Each Application Data Unit (ADU) in a source block is formatted as Application Data Unit Information (ADUI[i]) consisting of a 1-octet flow identifier F[i], 2-octet length L[i], the ADU payload R[i], and zero-padding P[i] to align to symbol boundaries, then all ADUIs are concatenated to form the source data block.

protocol-element §8.1.2

For Schemes 5 and 6 (single sequenced flow), the Source FEC Payload ID field is not used and source packets are not modified by the FEC scheme; packet identification is derived from the existing sequence number and information in repair packets.

protocol-element §8.2.2

For the single sequenced flow scheme, the Encoding Symbol ID for a source packet is derived as ESI = (Ns - I) * LP, where Ns is the packet sequence number, I is the Initial Sequence Number of the source block, and LP is the Source Packet Information Length in symbols.

protocol-element §1

Six Fully-Specified FEC Schemes are defined: Schemes 1 and 2 for arbitrary packet flows using Raptor (RFC 5053) and RaptorQ (RFC 6330) respectively; Schemes 3 and 4 are optimized variants for small source blocks; Schemes 5 and 6 apply to a single flow already carrying a sequence number.

protocol-element §7.1

The optimized scheme (Schemes 3 and 4) encodes all source blocks using a fixed MSBL by zero-padding shorter blocks before encoding and discarding the padding symbols after decoding; this allows pre-calculated encode/decode operation sequences for the restricted set of block lengths.

registry §12.1

Six FEC Encoding IDs are registered in the IANA 'FEC Framework (FECFRAME) FEC Encoding IDs' registry: IDs 1–6 for Raptor and RaptorQ schemes covering arbitrary packet flows, optimized arbitrary packet flows, and single sequenced flows.

registry

security-consideration §9

No security vulnerabilities specific to this document have been identified. Implementors are referred to the general FEC security considerations in RFC 6363 and to the code-specific considerations in RFC 5053 and RFC 6330.

security

wire-format §6.2.1.2

FEC-Scheme-Specific Information (Figure 1) for Schemes 1–6: 16-bit Symbol Size (T), 16-bit MSBL, and an optional final octet containing a 1-bit Payload ID format indicator (P) and 7 reserved bits; the last octet MAY be omitted to default to format A.

wire-format §6.2.3

Repair FEC Payload ID Format A (Figure 4) is a 6-octet field: 16-bit Source Block Number (SBN), 16-bit Encoding Symbol ID (ESI), and 16-bit Source Block Length (SBL), all unsigned integers.

wire-format §6.2.3

Repair FEC Payload ID Format B (Figure 5) is a 6-octet field: 8-bit Source Block Number (SBN), 24-bit Encoding Symbol ID (ESI), and 16-bit Source Block Length (SBL), all unsigned integers.

wire-format §8.1.3

Single Sequenced Flow Repair FEC Payload ID Format A (Figure 6) is a 6-octet field: 16-bit Initial Sequence Number (ISN), 16-bit Source Block Length (SBL), and 16-bit Encoding Symbol ID (ESI); Format B (Figure 7) replaces the ESI with a 24-bit field, making the total 7 octets.

wire-format §6.2.2

Source FEC Payload ID Format A (Figure 2) is a 4-octet field appended to source packets: 16-bit Source Block Number (SBN) and 16-bit Encoding Symbol ID (ESI), both unsigned integers in network byte order.

wire-format §6.2.2

Source FEC Payload ID Format B (Figure 3) is a 4-octet field: 8-bit Source Block Number (SBN) and 24-bit Encoding Symbol ID (ESI), enabling fewer but larger source blocks each with many encoding symbols.