RFC6681

Internet Engineering Task Force (IETF) M. Watson Request for Comments: 6681 Netflix Category: Standards Track T. Stockhammer ISSN: 2070-1721 Nomor Research

                                                             M. Luby
                                               Qualcomm Incorporated
                                                         August 2012

   Raptor Forward Error Correction (FEC) Schemes for FECFRAME

Abstract

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.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6681.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

       8.2.2. Derivation of Source FEC Packet

Introduction

The "Forward Error Correction (FEC) Framework" RFC6363 describes a general framework for the use of Forward Error Correction in association with arbitrary packet flows. Modeled after the FEC Building Block developed by the IETF Reliable Multicast Transport working group RFC5052, the FEC Framework defines the concept of FEC Schemes that provide specific Forward Error Correction Schemes. This document describes six FEC Schemes that make use of the Raptor and RaptorQ FEC codes as defined in RFC5053 and RFC6330.

The FEC protection mechanism is independent of the type of source data that can be an arbitrary sequence of packets, for example audio or video data. In general, the operation of the protection mechanism is as follows:

o The sender determines a set of source packets (a source block) to

  be protected together based on the FEC Framework Configuration
  Information.

o The sender arranges the source packets into a set of source

  symbols, each of which is the same size.

o The sender applies the Raptor/RaptorQ protection operation on the

  source symbols to generate the required number of repair symbols.

o The sender packetizes the repair symbols and sends the repair

  packet(s) and the source packets to the receiver(s).  Per the FEC
  Framework requirements, the sender MUST transmit the source and
  repair packets in different source and repair flows, or in the
  case Real-time Transport Protocol (RTP) transport is used for
  repair packets, in different RTP streams.

o At the receiver side, if all of the source packets are

  successfully received, there is no need for FEC recovery and the
  repair packets are discarded.  However, if there are missing
  source packets, the repair packets can be used to recover the
  missing information.

The operation of the FEC mechanism requires that the receiver is able to identify the relationships between received source packets and repair packets, in particular, which source packets are missing. In many cases, data already exists in the source packets that can be used to refer to source packets and to identify which packets are missing. In this case, we assume it is possible to derive a "sequence number" directly or indirectly from the source packets, and this sequence number can be used within the FEC Scheme. This case is referred to as a "single sequenced flow". In this case, the FEC

Source Payload ID defined in RFC6363 is empty and the source packets are not modified by the application of FEC, with obvious backwards compatibility advantages.

Otherwise, it is necessary to add data to the source packets for FEC purposes in the form of a non-empty FEC Source Payload ID. This is referred to as the "arbitrary packet flow" case. This document defines six FEC Schemes, two for the case of a single sequenced flow and four for the case of arbitrary packet flows.

Document Outline

This document is organized as follows:

o Section 5 defines general procedures applicable to the use of the

  Raptor and RaptorQ codes in the context of the FEC Framework.

o Section 6 defines a FEC Scheme for the case of arbitrary source

  flows and follows the format defined for FEC Schemes in RFC6363.
  When used with Raptor codes, this scheme is equivalent to that
  defined in 3GPP TS 26.346, "Multimedia Broadcast/Multicast Service
  (MBMS); Protocols and codecs" [MBMSTS].

o Section 7 defines a FEC Scheme similar to that defined in Section

  6 but with optimizations for the case where only limited source
  block sizes are required.  When used with Raptor codes, this
  scheme is equivalent to that defined in ETSI TS 102.034, "Digital
  Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services
  over IP Based Networks" [DVBTS] for arbitrary packet flows.

o Section 8 defines a FEC Scheme for the case of a single flow,

  which is already provided with a source packet sequence number.
  When used with Raptor codes, this scheme is equivalent to that
  defined in [DVBTS] for the case of a single sequenced flow.

Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Definitions and Abbreviations

The definitions, notations, and abbreviations commonly used in this document are summarized in this section.

Definitions

The FEC-specific terminology used in this document is defined in RFC6363. In this document, as in RFC6363, the first letter of each FEC-specific term is capitalized along with the new terms defined here:

Symbol: A unit of data. Its size, in octets, is referred to as the

  symbol size.

FEC Framework Configuration Information: Information that controls

  the operation of the FEC Framework.  Each FEC Framework instance
  has its own configuration information.

Abbreviations

This document uses abbreviations that apply to the FEC Framework in general as defined in RFC6363. In addition, this document uses the following abbreviations

FSSI: FEC-Scheme-Specific Information.

ADU: Application Data Unit

ADUI: Application Data Unit Information.

SPI: Source Packet Information.

MSBL: Maximum Source Block Length

General Procedures for Raptor FEC Schemes

This section specifies general procedures that apply to all Raptor and RaptorQ FEC Schemes, specifically the construction of source symbols from a set of source transport payloads.

For any field defined in this document, the octets are ordered in network byte order.

As described in RFC6363, for each Application Data Unit (ADU) in a source block, the FEC Scheme is provided with:

o A description of the source data flow with which the ADU is

  associated and an integer identifier associated with that flow.

o The ADU itself.

o The length of the ADU.

For each ADU, we define the Application Data Unit Information (ADUI) as follows:

Let

o n be the number of ADUs in the source block.

o T be the source symbol size in octets. Note: this information is

  provided by the FEC Scheme as defined below.

o i the index to the (i+1)-th ADU to be added to the source block,

  0 <= i < n.

o f[i] denote the integer identifier associated with the source data

  flow from which the i-th ADU was taken.

o F[i] denote a single octet representing the value of f[i].

o l[i] be a length indication associated with the i-th ADU -- the

  nature of the length indication is defined by the FEC Scheme.

o L[i] denote two octets representing the value of l[i] in network

  byte order (high order octet first) of the i-th ADU.

o R[i] denote the number of octets in the (i+1)-th ADU.

o s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note:

  s[i] is the length of SPI[i] in units of symbols of size T octets.

o P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding

  octets to align the start of each UDP packet with the start of a
  symbol.

o ADUI[i] be the concatenation of F[i], L[i], R[i], and P[i].

Then, a source data block is constructed by concatenating ADUI[i] for i = 0, 1, 2, ... n-1. The source data block size, S, is then given by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer encoding symbol IDs (ESI) consecutively starting from zero within the source block. Each ADU is associated with the ESI of the first symbol containing SPI for that packet. Thus, the encoding symbol ID value associated with the j-th source packet, ESI[j], is given by ESI[j] = 0, for j=0 and ESI[j] = sum{s[i], i=0,...,(j-1)}, for 0 < j < n.

Source blocks are identified by integer Source Block Numbers. This specification does not specify how Source Block Numbers are allocated to the source blocks. The Source FEC Packet Identification

Information consists of the identity of the source block and the encoding symbol ID associated with the packet.

Raptor FEC Schemes for Arbitrary Packet Flows

Introduction

This section specifies a FEC Scheme for the application of the Raptor and RaptorQ codes to arbitrary packet flows. This scheme is recommended in scenarios where maximal generality is required.

When used with the Raptor codes specified in RFC5053, this scheme is equivalent to that specified in [MBMSTS].

Formats and Codes

FEC Framework Configuration Information

FEC Scheme ID

The value of the FEC Scheme ID for the Fully-Specified FEC scheme defined in this section is 1 when RFC5053 is used and 2 when RFC6330 is used, as assigned by IANA.

Scheme-Specific Elements

The scheme-specific elements of the FEC Framework Configuration information for this scheme are as follows:

MSBL: The maximum source block length. A non-negative integer less

  than 8192 for FEC Scheme 1 and less than 56403 for FEC Scheme 2,
  in units of symbols.  The field type is unsigned integer.

T: The encoding symbol size. A non-negative integer less than 65536,

  in units of octets.  The field type is unsigned integer.

P: The payload ID format indicator. The P bit shall be set to zero

  to indicate payload ID format A or to one to indicate payload ID
  format B.  The field type is unsigned integer.

An encoding format for the encoding symbol size, MSBL and payload ID format indicator is defined below.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Symbol Size (T)         |          MSBL                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |P|  Reserved   |
  +-+-+-+-+-+-+-+-+

             Figure 1: FEC-Scheme-Specific Information

The P bit shall be set to zero to indicate Payload ID format A or to one to indicate Payload ID format B. The last octet of FEC-Scheme- Specific Information SHOULD be omitted, indicating that Payload ID format A is in use. The payload ID format indicator defines which of the Source FEC Payload ID and Repair FEC Payload ID formats defined below shall be used. Payload ID format B SHALL NOT be used for FEC Scheme 1. The two formats enable different use cases. Format A is appropriate in case the stream has many typically smaller source blocks, and format B is applicable if the stream has fewer large source blocks, each with many encoding symbols.

Source FEC Payload ID

This scheme makes use of an Explicit Source FEC Payload ID, which is appended to the end of the source packets. Two formats are defined for the Source FEC Payload ID, format A and format B. The format that is used is signaled as part of the FEC Framework Configuration Information.

The Source FEC Payload ID for format A is provided in Figure 2.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Source Block Number (SBN)   |   Encoding Symbol ID (ESI)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Source FEC Payload ID - Format A

Source Block Number (SBN), (16 bits): Identifier for the source block

  that the source data within the packet relates.  The field type is
  unsigned integer.

Encoding Symbol ID (ESI), (16 bits): The starting symbol index of the

  source packet in the source block.  The field type is unsigned
  integer.

The Source FEC Payload ID for format B is provided in Figure 3.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      SBN      |            Encoding Symbol ID (ESI)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: Source FEC Payload ID - Format B

Source Block Number (SBN), (8 bits): Identifier for the source block

  that the source data within the packet relates.  The field type is
  unsigned integer.

Encoding Symbol ID (ESI), (24 bits): The starting symbol index of the

  source packet in the source block.  The field type is unsigned
  integer.

Repair FEC Payload ID

Two formats for the Repair FEC Payload ID, format A and format B, are defined below.

The Repair FEC Payload ID for format A is provided in Figure 4.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Source Block Number (SBN)   |   Encoding Symbol ID (ESI)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Source Block Length (SBL)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 4: Repair FEC Payload ID - Format A

Source Block Number (SBN), (16 bits): Identifier for the source block

  that the repair symbols within the packet relate.  For format A,
  it is of size 16 bits.  The field type is unsigned integer.

Encoding Symbol ID (ESI), (16 bits): Identifier for the encoding

  symbols within the packet.  The field type is unsigned integer.

Source Block Length (SBL), (16 bits): The number of source symbols in

  the source block.  The field type is unsigned integer.

The Repair FEC Payload ID for format B is provided in Figure 5.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      SBN      |            Encoding Symbol ID (ESI)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Source Block Length (SBL)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 5: Repair FEC Payload ID - Format B

Source Block Number (SBN), (8 bits): Identifier for the source block

  that the repair symbols within the packet relate.  For format B,
  it is of size 8 bits.  The field type is unsigned integer.

Encoding Symbol ID (ESI), (24 bits): Identifier for the encoding

  symbols within the packet.  The field type is unsigned integer.

Source Block Length (SBL), (16 bits): The number of source symbols in

  the source block.  The field type is unsigned integer.

The interpretation of the Source Block Number, encoding symbol ID, and Source Block Length is defined by the FEC Code Specification in RFC5053 for FEC Scheme 1 and RFC6330 for FEC Scheme 2.

Procedures

Source Symbol Construction

FEC Scheme 1 and FEC Scheme 2 use the procedures defined in Section 5 to construct a set of source symbols to which the FEC Code can be applied. The sender MUST allocate Source Block Numbers to source blocks sequentially, wrapping around to zero after Source Block Number 65535 (format A) or 255 (format B).

During the construction of the source block:

o the length indication, l[i], included in the Source Packet

  Information for each packet shall be the transport payload length,
  i.e., the length of the ADU.

o the value of s[i] in the construction of the Source Packet

  Information for each packet shall be the smallest integer such
  that s[i]*T >= (l[i]+3).

Repair Packet Construction

For FEC Scheme 1 RFC5053, the ESI value placed into a repair packet is calculated as specified in Section 5.3.2 of RFC5053.

For FEC Scheme 2 RFC6330, the ESI value placed into a repair packet is calculated as specified in Section 4.4.2 of RFC6330.

In both cases, K is identical to SBL.

FEC Code Specification

The FEC encoder defined in RFC5053 SHALL be used for FEC Scheme 1 and the FEC encoder defined in RFC6330 SHALL be used for FEC Scheme 2. For both FEC Scheme 1 and FEC Scheme 2, the source symbols passed to the FEC encoder SHALL consist of the source symbols constructed according to Section 6.3.1. Thus, the value of the parameter K used by the FEC encoder (equal to the Source Block Length) may vary amongst the blocks of the stream but SHALL NOT exceed the Maximum Source Block Length signaled in the FEC-Scheme-Specific Information. The symbol size, T, to be used for source block construction and the repair symbol construction is equal to the encoding symbol size signaled in the FEC-Scheme-Specific Information.

Optimized Raptor FEC Scheme for Arbitrary Packet Flows

Introduction

This section specifies a slightly modified version of the FEC Scheme specified in Section 6 that is applicable to scenarios in which only relatively small block sizes will be used. These modifications admit substantial optimizations to both sender and receiver implementations.

In outline, the modifications are:

o All source blocks within a stream are encoded using the same

  source block size.  Code shortening is used to encode blocks of
  different sizes.  This is achieved by padding every block to the
  required size using zero symbols before encoding.  The zero
  symbols are then discarded after decoding.  The source block size
  to be used for a stream is signaled in the Maximum Source Block
  Length (MSBL) field of the scheme-specific information.  The
  extended source block is constructed by adding zero or more
  padding symbols such that the total number of symbols, MSBL, is
  one of the values listed in Section 7.4.  Each padding symbol
  consists of T octets where the value of each octet is zero.  MSBL

  MUST be selected as the smallest value of the possible values in
  Section 7.4 that is greater than or equal to K.

o The possible choices of the MSBL for a stream is restricted to a

  small specified set.  This allows explicit operation sequences for
  encoding and decoding the restricted set of source block lengths
  to be pre-calculated and embedded in software or hardware.

When used with the Raptor codes specified in RFC5053, this scheme is equivalent to that specified in [DVBTS] for arbitrary packet flows.

Formats and Codes

FEC Framework Configuration Information

FEC Scheme ID

The value of the FEC Scheme ID for the Fully-Specified FEC scheme defined in this section is 3 when RFC5053 is used and 4 when RFC6330 is used, as assigned by IANA.

FEC-Scheme-Specific Information

The elements for FEC Scheme 3 are the same as specified for FEC Scheme 1, and the elements specified for FEC Scheme 4 are the same as specified for FEC 2, as specified in Section 6.2.1.2, except that the MSBL value is as defined in Section 7.4.

Source FEC Payload ID

The elements for FEC Scheme 3 are the same as specified for FEC Scheme 1, and the elements specified for FEC Scheme 4 are the same as specified for FEC 2, as specified in Section 6.2.2.

Repair FEC Payload ID

The elements for FEC Scheme 3 are the same as specified for FEC Scheme 1, and the elements specified for FEC Scheme 4 are the same as specified for FEC 2, as specified in Section 6.2.3.

Procedures

Source Symbol Construction

See Section 6.3.1.

Repair Packet Construction

The number of repair symbols contained within a repair packet is computed from the packet length. The ESI value placed into a repair packet is calculated as X + MSBL - SBL, where X would be the ESI value of the repair packet if the ESI were calculated as specified in Section 5.3.2 of RFC5053 for FEC Scheme 3 and as specified in Section 4.4.2 of RFC6330 for FEC Scheme 4, where K=SBL. The value of SBL SHALL be, at most, the value of MSBL.

FEC Code Specification

The FEC encoder defined in RFC5053 SHALL be used for FEC Scheme 3 and the FEC encoder defined in RFC6330 SHALL be used for FEC Scheme 4. The source symbols passed to the FEC encoder SHALL consist of the source symbols constructed according to Section 6.3.1 extended with zero or more padding symbols. The extension SHALL be such that the total number of symbols in the source block is equal to the MSBL signaled in the FEC-Scheme-Specific Information. Thus, the value of the parameter K used by the FEC encoder is equal to the MSBL for all blocks of the stream. Padding symbols shall consist entirely of octets set to the value zero. The symbol size, T, to be used for the source block construction and the repair symbol construction, is equal to the encoding symbol size signaled in the FEC-Scheme-Specific Information.

For FEC Scheme 3, the parameter T SHALL be set such that the number of source symbols in any source block is, at most, 8192. The MSBL parameter, and hence the number of symbols used in the FEC Encoding and Decoding operations, 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 FEC Scheme 4, the parameter T SHALL be set such that the number of source symbols in any source block is less than 56403. The MSBL parameter SHALL be set to one of the supported values for K' defined in Section 5.6 of RFC6330.

Raptor FEC Scheme for a Single Sequenced Flow

Formats and Codes

FEC Framework Configuration Information

FEC Scheme ID

The value of the FEC Scheme ID for the Fully-Specified FEC scheme defined in this section is 5 when RFC5053 is used and 6 when RFC6330 is used, as assigned by IANA.

Scheme-Specific Elements

The elements for FEC Scheme 5 are the same as specified for FEC Scheme 1, and the elements specified for FEC Scheme 6 are the same as specified for FEC 2, as specified in Section 6.2.1.2.

Source FEC Payload ID

The Source FEC Payload ID field is not used by this FEC Scheme. Source packets are not modified by this FEC Scheme.

Repair FEC Payload ID

Two formats for the Repair FEC Payload ID are defined, format A and format B.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Initial Sequence Number    |      Source Block Length      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Encoding Symbol ID       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 6: Repair FEC Payload ID - Format A

Initial Sequence Number (Flow i ISN), (16 bits): This field specifies

  the lowest 16 bits of the sequence number of the first packet to
  be included in this sub-block.  If the sequence numbers are
  shorter than 16 bits, then the received Sequence Number SHALL be
  logically padded with zero bits to become 16 bits in length,
  respectively.  The field type is unsigned integer.

Source Block Length (SBL), (16 bits): This field specifies the length

  of the source block in symbols.  The field type is unsigned
  integer.

Encoding Symbol ID (ESI), (16 bits): This field indicates which

  repair symbols are contained within this repair packet.  The ESI
  provided is the ESI of the first repair symbol in the packet.  The
  field type is unsigned integer.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Initial Sequence Number    |      Source Block Length      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Encoding Symbol ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 7: Repair FEC Payload ID - Format B

Initial Sequence Number (Flow i ISN), (16 bits): This field specifies

  the lowest 16 bits of the sequence number in the first packet to
  be included in this sub-block.  If the sequence numbers are
  shorter than 16 bits, then the received Sequence Number SHALL be
  logically padded with zero bits to become 16 bits in length,
  respectively.  The field type is unsigned integer.

Source Block Length (SBL), (16 bits): This field specifies the length

  of the source block in symbols.  The field type is unsigned
  integer.

Encoding Symbol ID (ESI); (24 bits): This field indicates which

  repair symbols are contained within this repair packet.  The ESI
  provided is the ESI of the first repair symbol in the packet.  The
  field type is unsigned integer.

Procedures

Source Symbol Construction

FEC Scheme 5 and FEC Scheme 6 use the procedures defined in Section 5 to construct a set of source symbols to which the FEC code can be applied.

During the construction of the source block:

o the length indication, l[i], included in the Source Packet

  Information for each packet shall be dependent on the protocol
  carried within the transport payload.  Rules for RTP are specified
  below.

o the value of s[i] in the construction of the Source Packet

  Information for each packet shall be the smallest integer such
  that s[i]*T >= (l[i]+3)

Derivation of Source FEC Packet Identification Information

The Source FEC Packet Identification Information for a source packet is derived from the sequence number of the packet and information received in any repair FEC packet belonging to this source block. Source blocks are identified by the sequence number of the first source packet in the block. This information is signaled in all repair FEC packets associated with the source block in the Initial Sequence Number field.

The length of the Source Packet Information (in octets) for source packets within a source block is equal to the length of the payload containing encoding symbols of the repair packets (i.e., not including the Repair FEC Payload ID) for that block, which MUST be the same for all repair packets. The Application Data Unit Information Length (ADUIL) in symbols is equal to this length divided by the encoding symbol size (which is signaled in the FEC Framework Configuration Information). The set of source packets included in the source block is determined by the Initial Sequence Number (ISN) and Source Block Length (SBL) as follows:

Let,

o I be the Initial Sequence Number of the source block

o LP be the Source Packet Information Length in symbols

o LB be the Source Block Length in symbols

Then, source packets with sequence numbers from I to I +(LB/LP)-1 inclusive are included in the source block. The Source Block Length, LB, MUST be chosen such that it is at least as large as the largest Source Packet Information Length LP.

Note that if no FEC repair packets are received, then no FEC decoding is possible, and it is unnecessary for the receiver to identify the Source FEC Packet Identification Information for the source packets.

The encoding symbol ID for a packet is derived from the following information:

o The sequence number, Ns, of the packet

o The Source Packet Information Length for the source block, LP

o The Initial Sequence Number of the source block, I

Then, the encoding symbol ID for the packet with sequence number Ns is determined by the following formula:

  ESI = ( Ns - I ) * LP

Note that all repair packets associated to a given source block MUST contain the same Source Block Length and Initial Sequence Number.

Note also that the source packet flow processed by the FEC encoder MUST have consecutive sequence numbers. In case the incoming source packet flow has a gap in the sequence numbers, then implementors SHOULD insert an ADU in the source block that complies to the format of the source packet flow, but is ignored at the application with high probability. For additional guidelines, refer to RFC6363, Section 10.2, paragraph 5.

Repair Packet Construction

See Section 7.3.2

Procedures for RTP Source Flows

In the specific case of RTP source packet flows, the RTP Sequence Number field SHALL be used as the sequence number in the procedures described above. The length indication included in the Application Data Unit Information SHALL be the RTP payload length plus the length of the contributing sources (CSRCs), if any, the RTP Header Extension, if present, and the RTP padding octets, if any. Note that this length is always equal to the UDP payload length of the packet minus 12.

FEC Code Specification

The elements for FEC Scheme 5 are the same as specified for FEC Scheme 3, and the elements specified for FEC Scheme 6 are the same as specified for FEC 4, as specified in Section 7.4.

Security Considerations

For the general security considerations related to the use of FEC, refer to RFC6363. Also consider relevant security considerations in RFC5053 and RFC6330. No security vulnerabilities specific to this document have been identified.

10. Session Description Protocol (SDP) Signaling

This section provides an SDP RFC4566 example. The syntax follows the definition in RFC6364. Assume we have one source video stream (mid:S1) and one FEC repair stream (mid:R1). We form one FEC group with the "a=group:FEC-FR S1 R1" line. The source and repair streams are sent to the same port on different multicast groups. The repair window is set to 200 ms.

    v=0
    o=ali 1122334455 1122334466 IN IP4 fec.example.com
    s=Raptor FEC Example
    t=0 0
    a=group:FEC-FR S1 R1
    m=video 30000 RTP/AVP 100
    c=IN IP4 233.252.0.1/127
    a=rtpmap:100 MP2T/90000
    a=fec-source-flow: id=0
    a=mid:S1
    m=application 30000 UDP/FEC
    c=IN IP4 233.252.0.2/127
    a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A
    a=repair-window:200ms
    a=mid:R1

11. Congestion Control Considerations

For the general congestion control considerations related to the use of FEC, refer to RFC6363.

12. IANA Considerations

12.1. Registration of FEC Scheme IDs

The value of FEC Scheme IDs is subject to IANA registration. For general guidelines on IANA considerations as they apply to this document, refer to RFC6363.

This document registers six values in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry (http://www.iana.org/assignments/ rmt-fec-parameters/) as provided in Table 1. Each value refers to a Fully-Specified FEC scheme.

+----------+---------------------+----------------------------------+ | FEC | FEC Scheme | Reference | | Encoding | Description | | | ID | | | +----------+---------------------+----------------------------------+ | 1 | Raptor FEC Scheme | Section 6 in this document using | | | for Arbitrary | RFC5053 | | | Packet Flows | | +----------+---------------------+----------------------------------+ | 2 | RaptorQ FEC Scheme | Section 6 in this document using | | | for Arbitrary | RFC6330. | | | Packet Flows | | +----------+---------------------+----------------------------------+ | 3 | Raptor FEC Scheme | Section 7 in this document using | | | Optimized for | Raptor RFC5053. | | | Arbitrary Packet | | | | Flows | | +----------+---------------------+----------------------------------+ | 4 | RaptorQ FEC Scheme | Section 7 in this document | | | Optimized for | using RaptorQ RFC6330. | | | Arbitrary Packet | | | | Flows | | +----------+---------------------+----------------------------------+ | 5 | Raptor FEC Scheme | Section 8 in this document using | | | for a Single | Raptor RFC5053. | | | Sequence Flow | | +----------+---------------------+----------------------------------+ | 6 | RaptorQ FEC Scheme | Section 8 in this document using | | | for a Single | RaptorQ RFC6330. | | | Sequence Flow | | +----------+---------------------+----------------------------------+

        Table 1: FEC Framework (FECFRAME) FEC Encoding IDs

13. Acknowledgements

Thanks are due to Ali C. Begen and David Harrington for thorough review of earlier draft versions of this document.

14. References

14.1. Normative References

RFC6363 Watson, M., Begen, A., and V. Roca, "Forward Error

          Correction (FEC) Framework", RFC 6363, October 2011.

RFC5053 Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,

          "Raptor Forward Error Correction Scheme for Object
          Delivery", RFC 5053, October 2007.

RFC2119 Bradner, S., "Key words for use in RFCs to Indicate

          Requirement Levels", BCP 14, RFC 2119, March 1997.

RFC6330 Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,

          and L. Minder, "RaptorQ Forward Error Correction Scheme
          for Object Delivery", RFC 6330, August 2011.

14.2. Informative References

RFC5052 Watson, M., Luby, M., and L. Vicisano, "Forward Error

          Correction (FEC) Building Block", RFC 5052, August 2007.

RFC4566 Handley, M., Jacobson, V., and C. Perkins, "SDP: Session

          Description Protocol", RFC 4566, July 2006.

RFC6364 Begen, A., "Session Description Protocol Elements for the

          Forward Error Correction (FEC) Framework", RFC 6364,
          October 2011.

[DVBTS] ETSI, "Digital Video Broadcasting (DVB); Transport of

          MPEG-2 Based DVB Services over IP Based Networks", ETSI TS
          102 034, March 2009.

[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);

          Protocols and codecs", 3GPP TS 26.346, April 2005.

Authors' Addresses

Mark Watson Netflix 100 Winchester Circle Los Gatos, CA 95032 United States

EMail: [email protected]

Thomas Stockhammer Nomor Research Brecherspitzstrasse 8 Munich 81541 Germany

EMail: [email protected]

Michael Luby Qualcomm Research Berkeley 2030 Addison Street Berkeley, CA 94704 United States

EMail: [email protected]