```
```China

```
```
wangrui@agora.io

```
```

```
```
Agora Lab
```
```China

```
```
siliang@agora.io

```
```

```
```
Agora Lab
```
```China

```
```
hebifeng@agora.io

```
```

```
```
General
TSVWG
FEC
FECFRAME
Selective Linear Code
This document describes a fully-specified Forward Error Correction (FEC) scheme for Sliding Window Selective Linear Code (SLC) over the Galois Field GF (2^^8). It can be used to selectively protect arbitrary media streams along the lines defined by FECFRAME. It is necessary to protect the media streams selectively (e.g., the reference frames are not continuous under the SVC mode in real-time video streaming transmission). Compared with the traditional Sliding Window FEC Codes, the Sliding Window Selective FEC Code supports that the source symbols in the encoding window are discrete. Therefore, it can be ensured that only source symbols with correlation (whether continuous or not) are included in the encoding window.

```
```
Introduction
The use of Application-Level Forward Erasure Correction (AL-FEC) codes is a widely-used error control method used to improve the reliability of unicast, multicast, and broadcast transmissions.
The document describes a general framework to use FEC in Content Delivery Protocols (CDPs), and it is suitable for FEC schemes based on building blocks. Based on this framework, the describes two fully-specified FEC Schemes, Low-Density Parity Check (LDPC) Staircase and LDPC Triangle, and the describes one Fully-Specified FEC Scheme for the special case of Reed-Solomon (RS) over GF (2^^8).
The document describes a general framework used to protect arbitrary media streams along the lines defined by FECFRAME. The FEC scheme defined by the framework does not limit the type of input data, but only processes the data.
Similar to , only considers block FEC schemes, which requires that the input stream be divided into a series of blocks according to the block partitioning algorithm defined in . The , , and are FEC schemes based on this framework. The value for the block size affects the packet loss resistance and the encoding and decoding delay of the FEC scheme. At the same code rate, the FEC scheme with larger size blocks have higher robustness (e.g., in case of long packet erasure bursts), but it has higher decoding delay which is unacceptable for real-time video streaming application.
The framework described in provides support for FEC codes based on a sliding coding window. The FEC scheme in this framework is advantageous for real-time flows because of its high robustness and low additional delay.
In real-time video streaming transmission, Scalable Video Coding (SVC) is widely used. In normal real-time video coding, all frames in a GOP follow the rule of the frame by frame reference, that is, all frames except the last one are reference frames. In the encoding window, all frames participating in the encoding are beneficial to the decoding of the current frame. However, in the SVC mode, the coding dependency between frames changes, some frames will become non-reference frames. When non-reference frames are encoded, the recovered packets will not help the decoding of the current frame, and even have a negative effect on the FEC error correction ability in extreme cases.
This document introduces one fully specified FEC scheme for the situation that the sliding encoding window is discontinous in media streaming. The Sliding Window SLC FEC scheme described in this document belongs to the broad class of Sliding Window AL-FEC Codes (a.k.a., convolutional codes) . The encoding process is based on an encoding window, and the source symbols are encoded by sliding the encoding window. However, the encoding window does not slide directly over the set of the source symbols. Instead, we find the source symbols according to the rule defined by application (e.g., coding dependency between frames) and then slide over the set of these source symbols. Repair symbols are generated on-the-fly, by the computation of a linear combination of source symbols present in the current encoding window and passed to the transport layer.
When the loss of source symbol is detected at the receiver, the SLC decoder will recover the lost source symbol according to the linear combination of the source symbols and each received repair symbol (when the rank of the equations involved is solvable).
This fully-specified FEC scheme follows the structure required by ("FEC Scheme Requirements"), namely:
- Formats and Codes: This section defines the FEC Framework Configuration Information (FFCI) carrying signaling, including mandatory elements and Scheme-Specific elements. It also defines the Source FEC Payload ID and Repair FEC Payload ID formats, carrying the signaling information associated with each source or repair symbol, including ESI, indexes of source symbols participating in encoding, and coding coefficients.
- Procedures: This section describes procedures specific to this FEC scheme, including encoding window management, coding matrix generation, a linear combination of source symbol computation in Finite Field, and the mapping between ADU, ADUI, and Source Symbols.
- FEC Code Specification: This section provides a high-level description of the Sliding Window SLC encoder and decoder.

Terminology
The key words "MUST ", "MUST NOT ", "REQUIRED ", "SHALL ", "SHALL NOT ", "SHOULD ", "SHOULD NOT ", "RECOMMENDED ", "NOT RECOMMENDED ",
"MAY ", and "OPTIONAL " in this document are to be interpreted as
described in .
Definitions Notations and Abbreviations
Definitions
This document uses the following terms and definitions. Some of these terms and definitions are FEC scheme-specific and are in line with :
- Source symbol:
- unit of data used during the encoding process.
- Encoding symbol:
- unit of data generated by the encoding process.
- Repair symbol:
- an encoding symbol that is not a source symbol.
- Packet erasure channel:
- a communication path where packets are either dropped (e.g., by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical layer codes) or received. When a packet is received, it is assumed that this packet is not corrupted.
- Application Data Unit (ADU):
- unit of source data provided as payload to the transport layer. Depending on the use case, an ADU may use an RTP encapsulation.
- ADU Information (ADUI):
- unit of data constituted by the ADU and the associated Flow ID, Length and Padding fields.
- FEC Framework Configuration Information (FFCI):
- information that controls the operation of FECFRAME. Each FEC Framework instance has its own configuration information. And the FFCI enables the synchronization of the FECFRAME sender and receiver instances.
- FEC Source Packet:
- at a sender (respectively, at a receiver) a payload submitted to (respectively, received from) the transport protocol containing an ADU along with an Explicit Source FEC Payload ID.
- FEC Repair Packet:
- at a sender (respectively, at a receiver) a payload submitted to (respectively, received from) the transport protocol containing one repair symbol along with a Repair FEC Payload ID and possibly an RTP header.

Notations
This document uses the following notations and some of them are FEC scheme-specific:
- m:
- defines the length of the elements in the finite field, in bits. In this document, m is such that m=8.
- GF(q):
- denotes a finite field (also known as the Galois Field) with q elements. We assume that q = 2^^m in this document.
- a^^b:
- denotes a raised to the power b.
- E:
- denotes the size of an encoding symbol length in bytes.
- cw_size:
- denotes coding window size (in symbols).
- cw_size_max:
- denotes coding window maximum size (in symbols).
- gc:
- denotes the count of symbol groups participating in encoding (if there is a gap in the serial number, it is considered a new group) when a repair symbol is generated.
- gc_max:
- denotes the maximum count of symbol groups involved in encoding when generating maintenance symbols.
- cm:
- denotes coding matrix.
- cm_r:
- denotes row in the coding matrix.
- cm_c:
- denotes col in the coding matrix.
- ESI:
- denotes the first source symbol of the ADUI corresponding to this FEC Source Packet.
- Start_ESI:
- denotes the first ADUI's ESI of the first group.
- Residual_ESI_:
- denotes the residual value of the starting ESI of the current group relative to the previous group.
- Group_Size_:
- denotes the number of ADUIs contained in each group.

Abbreviations
This document uses the following abbreviations, and some of them are FEC scheme-specific:
- FEC:
- stands for Forward Error (or Erasure) Correction codes.
- ADU:
- stands for Application Data Unit.
- ADUI:
- stands for Application Data Unit Information.
- ESI:
- stands for Encoding Symbol ID.
- FFCI:
- stands for FEC Framework Configuration Information.
- FSSI:
- stands for FEC Scheme-Specific Information.

Formats and Codes
This section describes the format of FEC Framework Configuration Information (or FFCI) and FEC Payload IDs, which are carried in "big-endian" or "network order" format.
FEC Framework Configuration Information
The FFCI needs to be shared between FECFRAME sender and receiver instances to ensure the synchronization of information. It includes mandatory elements (e.g., FEC Encoding ID) and scheme-specific elements (e.g., Encoding Symbol size).
Mandatory
- FEC Encoding ID:
- the value assigned to this Fully-Specified FEC scheme
MUST be XXX, as assigned by IANA().

FEC Scheme-Specific Information
The FEC scheme-specific information (FSSI) of this scheme is as follows:
- Encoding Symbol size (E):
- a non-negative integer that indicates the size of each encoding symbol in bytes;
- The maximum coding window size (cw_size_max):
- a non-negative integer that indicates the maximum size of the coding window allowed (in symbols);
- The maximum number of gc (gc_max):
- a non-negative integer that indicates the maximum count of groups protected by each repair packet.

These elements are required both by the encoder and decoder.
When SDP is used to communicate the FFCI, this FEC Scheme-Specific Information MUST be carried in the ‘fssi’ parameter in textual representation specified in . For instance:
fssi=E:1500,cw_size_max:128,gc_max:4
If another mechanism requires the FSSI to be carried as an opaque octet string (for instance after a Base64 encoding), the encoding format consists of the following four octets:
- Encoding symbol length (E):
- 16-bit field;
- Maximum coding window size (cw_size_max):
- 8-bit field;
- Maximum size of gc (gc_max):
- 8-bit field.

The encoding format consists of the following 4 octets of :
FEC Payload IDs
Explicit Source FEC Payload ID
A FEC Source Packet MUST contain an Explicit Source FEC Payload ID that is appended to the end of the packet as illustrated in .
More precisely, the Explicit Source FEC Payload ID is composed of the following field:
- Encoding Symbol ID (ESI) (32-bit field):
- this unsigned integer identifies the first source symbol of the ADUI corresponding to this FEC Source Packet. The ESI is incremented for each new source symbol, and after reaching the maximum value (2^^32-1), wrapping to zero occurs.

Repair FEC Payload ID
A FEC repair packet MUST contain a Repair FEC Payload ID prepended to the repair symbol as illustrated in . There MUST be a single repair symbol per FEC repair packet.
More precisely, the SLC decoder scheme require the following information from the Repair FEC Payload ID:
- Start_ESI (32-bit field):
- this unsigned integer indicates the ESI of the first source symbol of the first group in the encoding window when this repair symbol was generated.
- gc (8-bit field):
- this unsigned integer indicates the number of symbol groups in the encoding window when this repair symbol is generated (if there is a gap in the serial number, it is considered a new group).
- cm_r (8-bit field):
- this unsigned integer is used as a parameter to generate the desired encoding matrix. This cm_r
MUST NOT be greater than cw_size_max.
- Residual_ESI_ (8-bit field):
- this unsigned integer represents the residual value of the starting ESI of the current group relative to the previous group.
- Group_Size_ (8-bit field):
- this unsigned integer is the number of the source symbols contained in each group.

The length of the Repair FEC Payload ID depends on the gc parameter.
Procedures
Restrictions
This specification has the following restrictions:
- 1.
- There
MUST be exactly one source symbol per ADUI, and therefore per ADI;
- 2.
- There
MUST be exactly one repair symbol per FEC Repair Packet.

ADU, ADUI, and Source Symbols Mappings
Before FEC coding, the mapping from ADU to AUDI needs to be established. When multiple source flows (e.g., media streams) are mapped onto the same FECFRAME instance, each flow is assigned its Flow ID value. The Flow ID needs to be included in the ADUI. Then, the recovered ADU can be allocated to the corresponding source flow by its Flow ID.
Because the length of each ADU may be inconsistent, to ensure that the decoder can extract ADU from ADUI, the original ADU length also needs to be added to ADUI.
For each incoming ADU, an ADUI MUST be created as follows. First of all, 3 bytes are prepended ():
- Flow ID (F) (8-bit field):
- this unsigned byte contains the integer identifier associated with the source ADU flow to which this ADU belongs.
- Length (L) (16-bit field):
- this unsigned integer contains the length of this ADU in network byte order (i.e., big endian). This length is for the ADU itself and does not include the F, or Pad fields.

Then, zero padding is added to the ADU if needed:
- Padding (Pad) (variable size field):
- this field is used for alignment purposes up to a size of exactly E bytes.

The data unit resulting from the ADU and the F, L, and Pad fields is called ADUI. An ADUI always contributes to an integral number of source symbols.
Note that all the initial 3 bytes are considered during FEC encoding, and a receiver that lost a certain FEC Source Packet will be able to recover the ADUI if FEC decoding succeeds. Thanks to the initial 3 bytes, this receiver can determine the flow of ADU and verify the recovered Source Packet.
Encoding Window Management
Whenever an ADU arrives, ADU-to-source symbols mapping will be performed. Then, the source symbols will be added to the array source_symbol_history. Whenever a repair symbol needs to be generated, the SLC FEC encoder will search backward in the source_symbol_history, and the source symbols that conforms the rules defined by the application will be put into the encoding window. When the encoding window cw_size is equal to its maximum value cw_size_max or the symbol group count gc is equal to its maximum value gc_max, the search is stopped and the FEC coding will be performed on the source symbols in the encoding window.
Taking as an example, the coding dependency between frames is used as the rule of source symbol selection, and frame I is the reference frame of frame P1, so I and P1 are placed in the encoding window when generating Repair2. However, P1 is not the reference frame of P2 under the SVC mode, so P1 is skipped, I and P2 are put into the encoding window to generate Repair3. The same process is performed to produce Rapair4 and Repair5.
Note that each time the encoding window slides, cm_r will update. The update rules are as follows:
- if (++cm_r>=cw_size_max) cm_r=0;

Coding Matrix Generation
Compared with the RLC FEC encoder, which depends on a pseudorandom number generator to compute the coding coefficients, the SLC FEC encoder uses a fixed coding matrix to reduce overhead. The elements of the coding matrix used during the encoding process are generated at the SLC FEC encoder each time a new repair symbol needs to be produced. The cm_r and cm_c parameters control these elements. The values of cm_c between 0 (the minimum value) and cw_size_max-1 (the maximum value). And the values of cm_r between 0 and 255-cw_size_max.
- G (cm_r, cm_c) = y_c / (x_r + y_c) = (cm_c + cw_size_max) / (cm_r + cm_c + cw_size_max)

where cm_r represents the row number in the matrix, cm_c represents the col number in the matrix, cw_size_max represents the maximum value of the encoding window, x_r = cm_r, y_c = cw_size_max+cm_c. The basic operations of the above equations are carried out in the GF (2^^8).
Linear Operation on encoding side and decoding side
Encoding Side
In , the elements of coding matrix G(cm_r, cm_c) are obtained. Then, a repair symbol is generated by the computation of a linear combination of source symbols.
A linear combination of the cw_size source symbols present in the encoding window, say src_0 to src_cw_size_1, is computed as follows. For each byte of position i in each source and the repair symbol, where i belongs to [0; E-1].
- repair[i] = G(cm_r, 0) * src_0[i] + G(cm_r, 1) * src_1[i] + … + G(cm_r, cw_size-1) * src_cw_size_1[i]

where * is the multiplication over GF (2^^8), + is the addition over GF (2^^8). In this document, the following irreducible polynomial is used for GF(2^^8).
- x^^8 + x^^4 + x^^3 + x^^2 + 1

Decoding Side
For decoding side, it is assumed that the repair symbol protects cw_size source symbols, among which j source symbols are lost, then,
- remove_src[i] = repair[i] - G(cm_r, 0) * src_0[i] - … - G(cm_r, k) * src_k[i] - G(cm_r, k + j + 1) * src_k_j_1[i] - … - G(cm_r, cw_size-1) * src_cw_size_1[i]

It is assumed that in the linear system maintained by the decoding side, there is a symbol sequence S = {lost_src_1, lost_src_2, … , lost_src_N} consisting of N lost source symbols, a symbol sequence R = {repair_1, repair_2, … , repair_N} consisting of N repair symbols
There is a matrix A whose row represents the position of the repair symbol in R and whose column represents the position of the lost source symbol in S. A[row][col] represents the matrix element of lost_src_row corresponding to repair_col (if it does not exist, then A[row][col] = 0).
- A[row][col] = G(cm_r,cm_c)

where cm_r can be extracted from the Repair FEC Payload ID, cm_c represents the position of the lost source symbol in the encoding window.
Therefore, there is a linear system of equation as follows:
- A * Transpose(lost_src_1, lost_src_2, … , lost_src_N) = Transpose(remove_src_1, remove_src_2, … , remove_src_N)

The inverse matrix of A can be obtained by Gauss elimination method, and finally S can be recovered:
- Transpose(lost_src_1, lost_src_2, … , lost_src_N) = A^^-1 * Transpose(remove_src_1, remove_src_2, … , remove_src_N)

FEC Code Specification
Encoding Side
1. Whenever a new repair symbol needs to be produced, the source symbols are put into the sliding encoding window according to the rule defined by application (e.g., coding dependency between frames).
2. The SLC FEC encoder gathers the cw_size source symbols currently in the sliding encoding window.
3. The elements of the coding matrix are determined according to the parameters cm_r and cm_c ().
4. The SLC FEC encoder computes the repair symbol by a linear combination of the cw_size source symbols present in the encoding window using the coding matrix ().
When encoding, the execution object is ADUI composed of Flow ID, Length, ADU, Padding.
Decoding Side
1. A linear system composed of source symbols, elements of the coding matrix, and repair symbols MUST to be maintained to recover the lost source packets.
2. When a repair symbol is received, it detects whether there is loss in the protected source symbols. If at least one of the corresponding source symbols has been lost, an equation composed of the repair symbol, the corresponding source symbols, and the elements of the coding matrix will be added to the linear system (the elements of the coding matrix are generated by the method provided in ).
3. When the linear system covering one or more lost source symbols is full, decoding is performed in order to recover lost source symbols ().
4. Each time an ADUI can be totally recovered, padding is removed (thanks to the Length field, L, of the ADUI), and the ADU will be assigned to the corresponding flow.
Note that the recovered source symbols can be directly passed to the application through the callback function, or passed to the application after receiving a certain number of source symbols, which depends on the operation decision of the application.
Security Considerations
The FEC Framework document provides a comprehensive analysis of security considerations applicable to FEC schemes. Therefore, the present section follows the security considerations section of and only discusses specific topics.
Attacks Against the Data Flow
Access to Confidential Content
The Sliding Window SLC FEC scheme specified in this document does not change the recommendations of . To summarize, if confidentiality is a concern, it is RECOMMENDED that one of the solutions mentioned in is used with special considerations to the way this solution is applied (e.g., is encryption applied before or after FEC protection, within the end system or in a middlebox), to the operational constrains (e.g., performing FEC decoding in a protected environment may be complicated or even impossible) and to the threat model.
Content Corruption
The Sliding Window SLC FEC scheme specified in this document does not change the recommendations of . To summarize, it is RECOMMENDED that one of the solutions mentioned in is used on both the FEC Source and Repair Packets.
Attacks Against the FEC Parameters
The Sliding Window SLC FEC scheme specified in this document defines parameters that can be the basis of attacks. More specifically, the following parameters of the FEC Framework Configuration Information may be modified by an attacker ():
- FEC Encoding ID:
- changing this parameter leads the receiver to consider a different FEC Scheme. It will lead to severe consequences that the format of the AUDI, the Explicit Source FEC Payload ID, and Repair FEC Payload ID of received packets will probably differ. The FEC decoder can't get the correct decoding information, resulting in decoding failure or decoding error.
- Encoding symbol length (E):
- setting this E parameter to a different value will enable an attacker to create a DoS since the repair symbols and certain source symbols will be larger or smaller than E, incoherency for the receiver.

Therefore, it is RECOMMENDED that security measures be taken to guarantee the FFCI integrity, as specified in . How to achieve this depends on how the FFCI is communicated from the sender to the receiver, which is not specified in this document.
Similarly, attacks are possible against the Explicit Source FEC Payload ID and Repair FEC Payload ID. More specifically, in the case of an FEC Source Packet, the following value can be modified by an attacker who targets receivers:
- Encoding Symbol ID (ESI):
- changing the ESI leads a receiver to consider a wrong ADU, resulting in severe consequences, including corrupted content passed to the receiving application.
And in the case of an FEC Repair Packet.
- Start_ESI:
- changing this value causes the FEC decoder to add the wrong source symbol in the linear system, and therefore any source symbol recovered by the linear system may be wrong.
- gc:
- changing this value causes the FEC decoder to add an incorrect number of source symbols in the linear system. Therefore any source symbol recovered by the linear system may be wrong.
- cm_r:
- changing this value leads a receiver to generate a wrong coding coefficient, and therefore any source symbol decoded using the repair symbol contained in this packet will be corrupted.
- Residual_ESI_:
- changing this value causes the FEC decoder to add the wrong source symbol in the linear system, and therefore any source symbol recovered by the linear system may be wrong.
- Group_Size_:
- changing this value causes the FEC decoder to add an incorrect number of source symbols in the linear system. Therefore any source symbol recovered by the linear system may be wrong.

Therefore, it is RECOMMENDED that security measures are taken to guarantee the FEC Source and Repair Packets as stated in .
When Several Source Flows Are to Be Protected Together
The Sliding Window SLC FEC scheme specified in this document does not change the recommendations of .
Baseline Secure FECFRAME Operation
The Sliding Window SLC FEC scheme specified in this document does not change the recommendations of concerning the use of the IPsec/Encapsulating Security Payload (ESP) security protocol as a mandatory-to-implement (but not mandatory-to-use) security scheme. This is well suited to situations where the only insecure domain is the one over which the FEC Framework operates.
Operations and Management Considerations
The FECFRAME document provides a comprehensive analysis of operations and management considerations applicable to FEC schemes. Therefore, the present section only discusses specific topics.
Operational Recommendations: gc_max
The Sliding Window SLC FEC scheme specified in this document defines the maximum number of groups participating in encoding, called gc_max, reflecting the maximum number of source symbols that the coding window can hold. Gc_max is directly proportional to the computational complexity of FEC encoding. If gc_max is too large, the time complexity of FEC encoding will be too high, and the CPU overhead will be too large. Generally, it is appropriate to associate gc_max with cw_size_max.
For example, in real-time video streaming transmission, the frame rate (FR) and bit rate (BR) is determined by transmitting the transmitted video. The possible number of packets per frame can be calculated according to FR and BR, and they can calculate the maximum number of symbols in the coding window.
- BR kbps / 8 / FR fps / MTU * gc_max <= cw_size_max

Where MTU denotes Maximum Transmission Unit.
IANA Considerations
This document registers one values in the “FEC Framework (FECFRAME) FEC Encoding IDs” sub-registry as follows:
- XXX
- refers to the Sliding Window Selective Linear Code (SLC) Forward Error Correction (FEC) Scheme for Arbitrary Packet Flows.

Acknowledgments
The authors would like to thank the FEC Framework Design Team for providing a great FEC Framework. The authors would also like to thank Shie Qian for reviewing the earlier draft versions of this document.
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Forward Error Correction (FEC) Building Block
This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated ’out-of-band’ are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452.
Forward Error Correction (FEC) Framework
This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol.
Session Description Protocol Elements for the Forward Error Correction (FEC) Framework
This document specifies the use of the Session Description Protocol(SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Forward Error Correction (FEC) Framework Extension to Sliding Window Codes
RFC 6363 describes a framework for using Forward Error Correction (FEC) codes to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency.
Informative References
Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes
This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well-known class of "Low Density Parity Check" codes, and are large block FEC codes in the sense of RFC 3453.
Reed-Solomon Forward Error Correction (FEC) Schemes
This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).
Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo.
Raptor Forward Error Correction (FEC) Schemes for FECFRAME
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.
Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME
This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum.
Simple Reed- Solomon Forward Error Correction (FEC) Scheme for FECFRAME
This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.
Taxonomy of Coding Techniques for Efficient Network Communications
This document summarizes recommended terminology for Network Coding
concepts and constructs. It provides a comprehensive set of terms in
order to avoid ambiguities in future IRTF and IETF documents on
Network Coding. This document is the product of the Coding for
Efficient Network Communications Research Group (NWCRG), and it is in
line with the terminology used by the RFCs produced by the Reliable
Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working
groups.
Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME
This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.

```
```