| TOC |
|
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 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 protection of arbitrary packet flows, two that are optimised for small source blocks and another two for 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.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright (c) 2010 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 BSD License.
1.
Introduction
2.
Document Outline
3.
Requirements Notation
4.
Definitions and Abbreviations
4.1.
Definitions
4.2.
Abbreviations
5.
General procedures for Raptor FEC Schemes
6.
Raptor FEC Schemes for arbitrary packet flows
6.1.
Introduction
6.2.
Formats and Codes
6.2.1.
FEC Framework Configuration Information
6.2.2.
Source FEC Payload ID
6.2.3.
Repair FEC Payload ID
6.3.
Procedures
6.3.1.
Source symbol construction
6.3.2.
Repair packet construction
6.4.
FEC Code Specification
7.
Optimised Raptor FEC Scheme for arbitrary packet flows
7.1.
Introduction
7.2.
Formats and Codes
7.2.1.
FEC Framework Configuration Information
7.2.2.
Source FEC Payload ID
7.2.3.
Repair FEC Payload ID
7.3.
Procedures
7.3.1.
Source symbol construction
7.3.2.
Repair packet construction
7.4.
FEC Code Specification
8.
Raptor FEC Scheme for a single sequenced flow
8.1.
Formats and codes
8.1.1.
FEC Framework Configuration Information
8.1.2.
Source FEC Payload ID
8.1.3.
Repair FEC Payload ID
8.2.
Procedures
8.2.1.
Source symbol construction
8.2.2.
Derivation of Source FEC Packet Identification Information
8.2.3.
Repair packet construction
8.2.4.
Procedures for RTP source flows
8.3.
FEC Code Specification
9.
Security Considerations
10.
Session Description Protocol (SDP) Signaling
11.
Congestion Control Considerations
12.
IANA Considerations
12.1.
Registration of FEC Scheme IDs
13.
Normative References
§
Author's Address
| TOC |
The FEC Framework [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.) describes a framework for the application of Forward Error Correction to arbitrary packet flows. Modelled after the FEC Building Block developed by the IETF Reliable Multicast Transport working group [RFC5052] (Watson, M., Luby, M., and L. Vicisano, “Forward Error Correction (FEC) Building Block,” August 2007.), the FEC Framework defines the concept of FEC Schemes which provide specific Forward Error Correction schemes. This document describes six FEC Schemes which make use of the Raptor and RaptorQ FEC codes as defined in [RFC5053] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” October 2007.) and [I‑D.ietf‑rmt‑bb‑fec‑raptorq] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” March 2010.).
The FEC protection mechanism is independent of the type of the source data, which can be an arbitrary sequence of packets, including for example audio or video data. In general, the operation of the protection mechanism is as follows:
Per the FEC Framework requirements, the sender MUST transmit the source and repair packets in different source and repair flows, or in the case RTP transport is used for Repair packets, in different RTP streams. 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 can identify the relationships between received source packets and repair packets and in particular which source packets are missing. In many cases, data already exists in the source packets which 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 [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.) 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 case if referred to as the "arbitrary packet flow" case. Accordingly, this document defines two FEC Schemes, one for the case of a single sequenced flow and another for the case of arbitrary packet flows.
| TOC |
This document is organised as follows:
Section 5 (General procedures for Raptor FEC Schemes) defines general procedures applicable to the use of the Raptor and RaptorQ codes in the context of the FEC Framework.
Section 6 (Raptor FEC Schemes for arbitrary packet flows)defines an FEC Scheme for the case of arbitrary source flows and follows the format defined for FEC Schemes in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.). When used with Raptor codes, this scheme is equivalent to that defined in [MBMSTS] (3GPP, “Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs,” April 2005.).
Section 7 (Optimised Raptor FEC Scheme for arbitrary packet flows) defines an FEC Scheme similar to that defined in Section 6 (Raptor FEC Schemes for arbitrary packet flows)but with optimisations for the case where only limited source block sizes are required. When used with Raptor codes, this scheme is equivalent to that defined in [dvbts] (, “ETSI TS 102 034 - Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks,” March 2005.) for arbitrary packet flows.
Section 8 (Raptor FEC Scheme for a single sequenced flow) defines an 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] (, “ETSI TS 102 034 - Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks,” March 2005.) for the case of a single sequenced flow.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
The definitions, notations and abbreviations commonly used in this document are summarized in this section.
| TOC |
This document uses the following definitions. For further definitions that apply to FEC Framework in general, see [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.).
Source Flow: The packet flow(s) or stream(s) carrying the source data and to which FEC protection is to be applied.
Repair Flow: The packet flow(s) or stream(s) carrying the repair data.
Symbol: A unit of data. Its size, in bytes, is referred to as the symbol size.
Source Symbol: The smallest unit of data used during the encoding process.
Repair Symbol: Repair symbols are generated from the source symbols.
Source Packet: Data packets that contain only source symbols.
Repair Packet: Data packets that contain only repair symbols.
Source Block: A block of source symbols that are considered together in the encoding process.
FEC Framework Configuration Information: Information that controls the operation of the FEC Framework. Each FEC Framework instance has its own configuration information.
FEC Payload ID: Information that identifies the contents of a packet with respect to the FEC scheme.
Source FEC Payload ID: An FEC Payload ID specifically used with source packets.
Repair FEC Payload ID: An FEC Payload ID specifically used with repair packets.
| TOC |
| TOC |
This section specifies general procedures which apply to all Raptor and RaptorQ FEC Schemes, specifically the construction of source symbols from a set of source transport payloads. As described in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.) for each Application Data Unit in a source block, the FEC Scheme is provided with:
For each Application Data Unit, we define the Application Data Unit Information (ADUI) as follows:
Let
n be the number of Application Data Units in the source block.
T be the source symbol size in bytes. Note: this information is provided by the FEC Scheme as defined below.
i the index to the (i+1)-th Application Data Unit to be added to the source block, 0 <= i < n.
R[i] denote the number of octets in the (i+1)-th Application Data Unit.
l[i] be a length indication associated with the i-th Application Data Unit – the nature of the length indication is defined by the FEC Scheme.
L[i] denote two octets representing the value of l[i] in network byte order (high order octet first) of the i-th Application Data Unit.
f[i] denote the integer identifier associated with the source data flow from which the i-th Application Data Unit was taken.
F[i] denote a single octet representing the value of f[i].
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 bytes.
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.
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 consecutively starting from zero within the source block. Each Application Data Unit is associated with the Encoding Symbol ID 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 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.
| TOC |
| TOC |
This section specifies an FEC Scheme for the application of the Raptor and RaptorQ codes to arbitary packet flows. This scheme is recommended in scenarios where maximal generality is required.
When used with Raptor codes, this scheme is equivalent to that specified in [MBMSTS] (3GPP, “Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs,” April 2005.).
| TOC |
| TOC |
| TOC |
The value of the FEC Scheme ID for the fully-specified FEC scheme defined in this section is XXX when [RFC5053] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” October 2007.) is used and YYY when [I‑D.ietf‑rmt‑bb‑fec‑raptorq] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” March 2010.) is used, as assigned by IANA.
| TOC |
The scheme-specific elements of the FEC Framework Configuration information for this scheme are as follows:
- Maximum Source Block Length
- Name: Kmax, Value range: A decimal non-negative integer less than 8192 (for Raptor) or 56405 (for RaptorQ), in units of symbols
- Encoding Symbol Size
- Name: T, Value range: A decimal non-negative integer less than 65536, in units of bytes
- Payload ID Format
- Name: P, Value range: "A" or "B"
An encoding format for The Maximum Source Block Length and Encoding Symbol Size 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) |Max. Source Block Length (Kmax)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+
| Figure 1: FEC Scheme Specific Information |
The Payload ID Format identifier 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 when[RFC5053] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” October 2007.) is used.
| TOC |
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 signalled as part of the FEC Framework Configuration Information
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): An integer identifier for the source block that the source data within the packet relates to.
Encoding Symbol ID (ESI), (16 bits): The starting symbol index of the source packet in the source block.
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): An integer identifier for the source block that the source data within the packet relates to.
Encoding Symbol ID (ESI), (24 bits): The starting symbol index of the source packet in the source block
| TOC |
Two formats for the Repair FEC Payload ID, Format A and Format B are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (SBL) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repair FEC Payload ID - Format A |
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repair FEC Payload ID - Format B |
- Source Block Number (SBN), (16 bits)
- An integer identifier for the source block that the repair symbols within the packet relate to.
- Encoding Symbol ID (ESI), (16 bits)
- Integer identifier for the encoding symbols within the packet.
- Source Block Length (SBL), (16 bits)
- The number of source symbols in the source block.
The interpretation of the Source Block Number, Encoding Symbol Identifier and Source Block Length is defined by the FEC Code Specification.
| TOC |
| TOC |
This FEC Scheme uses the procedures defined in Section 5 (General procedures for Raptor FEC Schemes) 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:
| TOC |
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 given by the following formula:
ESI_repair = I_repair + SBL,
where I_repair is the index of the repair symbol in the sequence of repair symbols generated according to Section 6.4 (FEC Code Specification), where the first repair symbol has index 0, the second index 1 etc. and SBL is the Source Block Length. The Source Block Length field of the Repair FEC Payload ID field SHALL be set to the number of symbols included in the Source Packet Information of packets associated with the source block.
| TOC |
The Raptor FEC encoder defined in [RFC5053] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” October 2007.) or [I‑D.ietf‑rmt‑bb‑fec‑raptorq] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” March 2010.) SHALL be used. The source symbols passed to the Raptor FEC encoder SHALL consist of the source symbols constructed according to Section 6.3.1 (Source symbol construction). 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 signalled 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.
| TOC |
| TOC |
This section specifies a slightly modified version of the FEC Scheme specified in Section 6 (Raptor FEC Schemes for arbitrary packet flows) which is applicable to scenarios in which only relatively small block sizes will be used. These modifications admit substantial optimisations to both sender and receiver implementations.
In outline, the modifications are:
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 signalled in the Maximum Source Block Size field of the scheme-specific information. This allows for efficient parallel encoding of multiple streams.
A restricted set of possible source block sizes is specified. This allows explicit operation sequences for encoding the restricted set of block sizes to be pre-calculated and embedded in software or handware.
This scheme is equivalent to that specified in [dvbts] (, “ETSI TS 102 034 - Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks,” March 2005.) for arbitrary packet flows.
| TOC |
| TOC |
| TOC |
The value of the FEC Scheme ID for the fully-specified FEC scheme defined in this section is XXX when [RFC5053] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” October 2007.) is used and YYY when [I‑D.ietf‑rmt‑bb‑fec‑raptorq] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” March 2010.) is used, as assigned by IANA.
| TOC |
See . (Scheme-Specific Elements)
| TOC |
| TOC |
SeeSection 6.2.3 (Repair FEC Payload ID)
| TOC |
| TOC |
See Section 6.3.1 (Source symbol construction)
| TOC |
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 given by the following formula:
ESI_repair = I_repair + MSBL
Where I_repair is the index of the repair symbol in the sequence of repair symbols generated according to Section 6.4 (FEC Code Specification), where the first repair symbol has index 0, the second index 1 etc. and MSBL is the Maximum Source Block Length signalled in the FEC Scheme Specific Information. The Source Block Length field of the Repair FEC Payload ID field SHALL be set to the number of symbols included in the Source Packet Information of packets associated with the source block.
| TOC |
The Raptor FEC encoder defined in [RFC5053] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” October 2007.) or [I‑D.ietf‑rmt‑bb‑fec‑raptorq] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” March 2010.) SHALL be used. The source symbols passed to the Raptor FEC encoder SHALL consist of the source symbols constructed according to Section 6.3.1 (Source symbol construction) extended with zero or more padding symbols such that the total number of symbols in the source block is equal to the Maximum Source Block Length signaled in the FEC Scheme Specific Information. Thus the value of the parameter K used by the FEC encoded is equal to the Maximum Source Block Length for all blocks of the stream. Padding symbols shall consist entirely of bytes set to the value zero. 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.
When [RFC5053] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” October 2007.) is used, the parameter T SHALL be set such that the number of source symbols in any source block is at most 8192. The Maximum Source Block Length 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
When [I‑D.ietf‑rmt‑bb‑fec‑raptorq] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” March 2010.) is used, the parameter T SHALL be set such that the number of source symbols in any source block is less than 56404. The Maximum Source Block Length parameter SHALL be set to one of the supported vaoues for K' defined in Section 5.6 of [I‑D.ietf‑rmt‑bb‑fec‑raptorq] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” March 2010.).
| TOC |
| TOC |
| TOC |
| TOC |
The value of the FEC Scheme ID for the fully-specified FEC scheme defined in this section is XXX when [RFC5053] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” October 2007.) is used and YYY when [I‑D.ietf‑rmt‑bb‑fec‑raptorq] (Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” March 2010.) is used, as assigned by IANA.
| TOC |
See Section 6.2.1.2 (Scheme-Specific Elements)
| TOC |
The Source FEC Payload ID field is not used by this FEC Scheme. Source packets are not modified by this FEC Scheme.
| TOC |
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 | Encoding Symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 4: 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.
- 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.
- Source Block Length (SBL) – 16 bits
- This field specifies the length of the source block in symbols.
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 5: 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 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.
- 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.
- Source Block Length (SBL) – 16 bits
- This field specifies the length of the source block in symbols.
| TOC |
| TOC |
This FEC Scheme uses the procedures defined in Section 5 (General procedures for Raptor FEC Schemes) 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 in the case Format A is used for FEC Payload IDs and 255 in the case Format B is used for FEC Payload IDs.
During the construction of the source block:
| TOC |
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 bytes) for source packets within a source block is equal to 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 which are included in the source block is determined from the Initial Sequence Number (ISN) and Source Block Length (SBL) as follows:
Let,
I be the Initial Sequence Number of the source block
LP be the Source Packet Information Length in symbols
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.
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:
The sequence number, Ns, of the packet
The Source Packet Information Length for the source block, LP
The Initial Sequence Number of the source block, I
Then the Encoding Symbol ID for packet with sequence number Ns is determined by the following formula:
ESI = ( Ns - I ) * LP
Note that all repair packet associated to a given Source Block MUST contain the same Source Block Length and Initial Sequence Number.
| TOC |
See Section 7.3.2 (Repair packet construction)
| TOC |
In the specific case of RTP source packet flows, then 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 CSRCs, if any, the RTP Header Extension, if present, and the RTP padding bytes, if any. Note that this length is always equal to the UDP payload length of the packet minus 12.
| TOC |
See Section 7.4 (FEC Code Specification)
| TOC |
For the general security considerations related to the use of FEC, refer to [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.). No security considerations specific to this document have been identified.
| TOC |
This section provides an SDP [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) example. The following example uses the SDP elements for FEC Framework, which were introduced in [I‑D.ietf‑fecframe‑sdp‑elements] (Begen, A., “SDP Elements for FEC Framework,” April 2010.), and the FEC grouping semantics [I‑D.ietf‑mmusic‑rfc4756bis] (Begen, A., “Forward Error Correction Grouping Semantics in Session Description Protocol,” April 2010.).
In this example, 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 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 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; tag-len=4
a=mid:S1
m=application 30000 udp/fec
c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=0; fssi=Kmax:8192,T:128,P:A
a=repair-window:200
a=mid:R1
| TOC |
For the general congestion control considerations related to the use of FEC, refer to [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.).
| TOC |
| TOC |
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 [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.).
This document registers three values in the FEC Framework (FECFRAME) FEC Encoding IDs registry as follows:
| TOC |
| [I-D.ietf-fecframe-framework] | Watson, M., “Forward Error Correction (FEC) Framework,” draft-ietf-fecframe-framework-07 (work in progress), March 2010 (TXT). |
| [I-D.ietf-fecframe-sdp-elements] | Begen, A., “SDP Elements for FEC Framework,” draft-ietf-fecframe-sdp-elements-06 (work in progress), April 2010 (TXT). |
| [RFC5052] | Watson, M., Luby, M., and L. Vicisano, “Forward Error Correction (FEC) Building Block,” RFC 5052, August 2007 (TXT). |
| [RFC5053] | Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” RFC 5053, October 2007 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC4566] | Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT). |
| [I-D.ietf-mmusic-rfc4756bis] | Begen, A., “Forward Error Correction Grouping Semantics in Session Description Protocol,” draft-ietf-mmusic-rfc4756bis-08 (work in progress), April 2010 (TXT). |
| [I-D.ietf-rmt-bb-fec-raptorq] | Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “RaptorQ Forward Error Correction Scheme for Object Delivery,” draft-ietf-rmt-bb-fec-raptorq-02 (work in progress), March 2010 (TXT). |
| [dvbts] | “ETSI TS 102 034 - Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks,” March 2005. |
| [MBMSTS] | 3GPP, “Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs,” 3GPP TS 26.346, April 2005. |
| TOC |
| Mark Watson | |
| Qualcomm, Inc. | |
| 3165 Kifer Road | |
| Santa Clara, CA 95051 | |
| U.S.A. | |
| Email: | watson@qualcomm.com |