FEC Framework M. Watson
Internet-Draft Netflix
Intended status: Standards Track T. Stockhammer
Expires: May 27, 2012 Nomor Research
M. Luby
Qualcomm Incorporated
November 24, 2011
Raptor FEC Schemes for FECFRAME
draft-ietf-fecframe-raptor-07
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 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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 27, 2012.
Copyright Notice
Watson, et al. Expires May 27, 2012 [Page 1]
Internet-Draft Raptor FEC Scheme November 2011
Copyright (c) 2011 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.
Watson, et al. Expires May 27, 2012 [Page 2]
Internet-Draft Raptor FEC Scheme November 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Document Outline . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6
4. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6
4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
5. General procedures for Raptor FEC Schemes . . . . . . . . . . 7
6. Raptor FEC Schemes for arbitrary packet flows . . . . . . . . 9
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 9
6.2.1. FEC Framework Configuration Information . . . . . . . 9
6.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 10
6.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 11
6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3.1. Source symbol construction . . . . . . . . . . . . . . 12
6.3.2. Repair packet construction . . . . . . . . . . . . . . 12
6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 13
7. Optimised Raptor FEC Scheme for arbitrary packet flows . . . . 13
7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 14
7.2.1. FEC Framework Configuration Information . . . . . . . 14
7.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 14
7.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 14
7.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3.1. Source symbol construction . . . . . . . . . . . . . . 14
7.3.2. Repair packet construction . . . . . . . . . . . . . . 14
7.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 14
8. Raptor FEC Scheme for a single sequenced flow . . . . . . . . 15
8.1. Formats and codes . . . . . . . . . . . . . . . . . . . . 15
8.1.1. FEC Framework Configuration Information . . . . . . . 15
8.1.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 15
8.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 15
8.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.1. Source symbol construction . . . . . . . . . . . . . . 17
8.2.2. Derivation of Source FEC Packet Identification
Information . . . . . . . . . . . . . . . . . . . . . 17
8.2.3. Repair packet construction . . . . . . . . . . . . . . 18
8.2.4. Procedures for RTP source flows . . . . . . . . . . . 18
8.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Session Description Protocol (SDP) Signaling . . . . . . . . . 19
11. Congestion Control Considerations . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 20
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Watson, et al. Expires May 27, 2012 [Page 3]
Internet-Draft Raptor FEC Scheme November 2011
14.1. Normative References . . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Watson, et al. Expires May 27, 2012 [Page 4]
Internet-Draft Raptor FEC Scheme November 2011
1. Introduction
The FEC Framework [RFC6363] describes a framework for the application
of Forward Error Correction to 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 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]
and [RFC6330].
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:
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) along with 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 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 [RFC6363] is empty and the source packets are not modified
Watson, et al. Expires May 27, 2012 [Page 5]
Internet-Draft Raptor FEC Scheme November 2011
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 six FEC Schemes, two for the case of a single
sequenced flow and four for the case of arbitrary packet flows.
2. Document Outline
This document is organised 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 6defines an 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 [MBMSTS].
o Section 7 defines an FEC Scheme similar to that defined in
Section 6but 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] for arbitrary
packet flows.
o Section 8 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] for the case of a single sequenced flow.
3. 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].
4. Definitions and Abbreviations
The definitions, notations and abbreviations commonly used in this
document are summarized in this section.
Watson, et al. Expires May 27, 2012 [Page 6]
Internet-Draft Raptor FEC Scheme November 2011
4.1. Definitions
This document uses the following definitions. For further
definitions that apply to FEC Framework in general, see [RFC6363].
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.
4.2. Abbreviations
This document uses the following abbreviations. For further
abbreviations that apply to FEC Framework in general, see [RFC6363].
FSSI: FEC-Scheme-Specific Information.
SS-FSSI: Sender-Side FEC-Scheme-Specific Information.
RS-FSSI: Receiver-Side FEC-Scheme-Specific Information.
ADUI: Application Data Unit Information.
5. General procedures for Raptor FEC Schemes
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
[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
Watson, et al. Expires May 27, 2012 [Page 7]
Internet-Draft Raptor FEC Scheme November 2011
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 R[i] denote the number of octets in the (i+1)-th ADU.
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 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 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 consecutively starting from zero within the
source block. Each ADU 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.
Watson, et al. Expires May 27, 2012 [Page 8]
Internet-Draft Raptor FEC Scheme November 2011
6. Raptor FEC Schemes for arbitrary packet flows
6.1. Introduction
This section specifies an 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 Raptor codes, this scheme is equivalent to that
specified in [MBMSTS].
6.2. Formats and Codes
6.2.1. FEC Framework Configuration Information
6.2.1.1. FEC Scheme ID
The value of the FEC Scheme ID for the fully-specified FEC scheme
defined in this section is XXX when [RFC5053] is used and YYY when
[RFC6330] is used, as assigned by IANA.
6.2.1.2. Scheme-Specific Elements
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 56403 (for
RaptorQ), in units of symbols
Encoding Symbol Size Name: "T", Value range: A decimal non-
negative integer less than 65536, in units of octets
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.
Watson, et al. Expires May 27, 2012 [Page 9]
Internet-Draft Raptor FEC Scheme November 2011
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 P bit shall be set to zero to indicate Format A or to one to
indicate Format B. The last octet of the above encoding may be
omitted, in which case Format A shall be assumed.
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] is used.
6.2.2. 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): 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.
The Source FEC Payload ID for format B is provided in Figure 3.
Watson, et al. Expires May 27, 2012 [Page 10]
Internet-Draft Raptor FEC Scheme November 2011
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.
6.2.3. 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) An integer identifier for the
source block that the repair symbols within the packet relate to.
For format A, it is of size 16 bits.
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 Repair FEC Payload ID for format B is provided in Figure 5.
Watson, et al. Expires May 27, 2012 [Page 11]
Internet-Draft Raptor FEC Scheme November 2011
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) An integer identifier for the
source block that the repair symbols within the packet relate to.
For format A, it is of size 16 bits.
Encoding Symbol ID (ESI), (24 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.
6.3. Procedures
6.3.1. Source symbol construction
This FEC Scheme uses 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.
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).
6.3.2. Repair packet construction
The ESI value placed into a repair packet is calculated as specified
in Section 5.3.2 of [RFC5053] when Raptor as defined in [RFC5053] is
used and as specified in Section 4.4.2 of [RFC6330] when RaptorQ as
Watson, et al. Expires May 27, 2012 [Page 12]
Internet-Draft Raptor FEC Scheme November 2011
defined in [RFC6330] is used, where K=SBL.
6.4. FEC Code Specification
The Raptor FEC encoder defined in [RFC5053] or [RFC6330] 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.
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.
7. Optimised Raptor FEC Scheme for arbitrary packet flows
7.1. Introduction
This section specifies a slightly modified version of the FEC Scheme
specified in Section 6 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:
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
Size field of the scheme-specific information. This allows for
efficient parallel encoding of multiple streams. Note that the
padding operation is equivalent to the padding operation in
[RFC6330] with K' the specified single source block size and K the
actual source block size K.
o The possible choices of the source block size for a stream is
restricted to a small specified set of sizes. This allows
explicit operation sequences for encoding and decoding the
restricted set of source block sizes to be pre-calculated and
embedded in software or hardware.
When the Raptor FEC encoder as defined in [RFC5053] is used, this
scheme is equivalent to that specified in [dvbts] for arbitrary
Watson, et al. Expires May 27, 2012 [Page 13]
Internet-Draft Raptor FEC Scheme November 2011
packet flows.
7.2. Formats and Codes
7.2.1. FEC Framework Configuration Information
7.2.1.1. FEC Scheme ID
The value of the FEC Scheme ID for the fully-specified FEC scheme
defined in this section is XXX when [RFC5053] is used and YYY when
[RFC6330] is used, as assigned by IANA.
7.2.1.2. FEC Scheme specific information
See . (Section 6.2.1.2)
7.2.2. Source FEC Payload ID
See . (Section 6.2.2)
7.2.3. Repair FEC Payload ID
SeeSection 6.2.3
7.3. Procedures
7.3.1. Source symbol construction
See Section 6.3.1
7.3.2. 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] when Raptor as defined in[RFC5053] is used
and as specified in Section 4.4.2 of [RFC6330] when RaptorQ as
defined in [RFC6330] is used, where K=SBL. The value of SBL SHALL be
at most the value of MSBL.
7.4. FEC Code Specification
The Raptor FEC encoder defined in [RFC5053] or [RFC6330] 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
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
Watson, et al. Expires May 27, 2012 [Page 14]
Internet-Draft Raptor FEC Scheme November 2011
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 octets 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] 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 [RFC6330] is used, the parameter T SHALL be set such that the
number of source symbols in any source block is less than 56403. The
Maximum Source Block Length parameter SHALL be set to one of the
supported values for K' defined in Section 5.6 of [RFC6330].
8. Raptor FEC Scheme for a single sequenced flow
8.1. Formats and codes
8.1.1. FEC Framework Configuration Information
8.1.1.1. FEC Scheme ID
The value of the FEC Scheme ID for the fully-specified FEC scheme
defined in this section is XXX when [RFC5053] is used and YYY when
[RFC6330] is used, as assigned by IANA.
8.1.1.2. Scheme-specific elements
See Section 6.2.1.2
8.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.
8.1.3. Repair FEC Payload ID
Two formats for the Repair FEC Payload ID are defined, Format A and
Format B.
Watson, et al. Expires May 27, 2012 [Page 15]
Internet-Draft Raptor FEC Scheme November 2011
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 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.
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 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 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.
Source Block Length (SBL) - 16 bits This field specifies the length
of the source block in symbols.
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.
Watson, et al. Expires May 27, 2012 [Page 16]
Internet-Draft Raptor FEC Scheme November 2011
8.2. Procedures
8.2.1. Source symbol construction
This FEC Scheme uses 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
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:
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)
8.2.2. 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 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,
o I be the Initial Sequence Number of the source block
Watson, et al. Expires May 27, 2012 [Page 17]
Internet-Draft Raptor FEC Scheme November 2011
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.
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 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.
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.
8.2.3. Repair packet construction
See Section 7.3.2
8.2.4. Procedures for RTP source flows
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 octets, if any. Note that this length
Watson, et al. Expires May 27, 2012 [Page 18]
Internet-Draft Raptor FEC Scheme November 2011
is always equal to the UDP payload length of the packet minus 12.
8.3. FEC Code Specification
See Section 7.4
9. Security Considerations
For the general security considerations related to the use of FEC,
refer to [RFC6363]. No security considerations 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].
Watson, et al. Expires May 27, 2012 [Page 19]
Internet-Draft Raptor FEC Scheme November 2011
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 three values in the FEC Framework (FECFRAME)
FEC Encoding IDs registry as follows:
o 1 for the Raptor FEC Scheme for Arbitrary Packet Flows (Section 6
using Raptor [RFC5053].
o 2 for the Raptor FEC Scheme for Arbitrary Packet Flows (Section 6
using RaptorQ [RFC6330].
o 3 for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows
(Section 7) using Raptor [RFC5053].
o 4 for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows
(Section 7) using RaptorQ [RFC6330].
o 5 for the Raptor FEC Scheme for a single sequence flow (Section 8)
using Raptor [RFC5053].
o 6 for the Raptor FEC Scheme for a single sequence flow (Section 8)
using RaptorQ [RFC6330].
13. Acknowledgements
Thanks are due to Ali C. Begen 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
Watson, et al. Expires May 27, 2012 [Page 20]
Internet-Draft Raptor FEC Scheme November 2011
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 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.
Authors' Addresses
Mark Watson
Netflix
100 Winchester Circle
Los Gatos, CA 95032
U.S.A.
Email: watsonm@netflix.com
Thomas Stockhammer
Nomor Research
Brecherspitzstrasse 8
Munich 81541
Germany
Email: stockhammer@nomor.de
Watson, et al. Expires May 27, 2012 [Page 21]
Internet-Draft Raptor FEC Scheme November 2011
Michael Luby
Qualcomm Incorporated
3165 Kifer Road
Santa Clara, CA 95051
U.S.A.
Email: luby@qualcomm.com
Watson, et al. Expires May 27, 2012 [Page 22]