summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6681.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6681.txt')
-rw-r--r--doc/rfc/rfc6681.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc6681.txt b/doc/rfc/rfc6681.txt
new file mode 100644
index 0000000..b05e867
--- /dev/null
+++ b/doc/rfc/rfc6681.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 1]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 2]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Document Outline ................................................5
+ 3. Requirements Notation ...........................................5
+ 4. Definitions and Abbreviations ...................................5
+ 4.1. Definitions ................................................6
+ 4.2. Abbreviations ..............................................6
+ 5. General Procedures for Raptor FEC Schemes .......................6
+ 6. Raptor FEC Schemes for Arbitrary Packet Flows ...................8
+ 6.1. Introduction ...............................................8
+ 6.2. Formats and Codes ..........................................8
+ 6.2.1. FEC Framework Configuration Information .............8
+ 6.2.2. Source FEC Payload ID ...............................9
+ 6.2.3. Repair FEC Payload ID ..............................10
+ 6.3. Procedures ................................................11
+ 6.3.1. Source Symbol Construction .........................11
+ 6.3.2. Repair Packet Construction .........................12
+ 6.4. FEC Code Specification ....................................12
+ 7. Optimized Raptor FEC Scheme for Arbitrary Packet Flows .........12
+ 7.1. Introduction ..............................................12
+ 7.2. Formats and Codes .........................................13
+ 7.2.1. FEC Framework Configuration Information ............13
+ 7.2.2. Source FEC Payload ID ..............................13
+ 7.2.3. Repair FEC Payload ID ..............................13
+ 7.3. Procedures ................................................13
+ 7.3.1. Source Symbol Construction .........................13
+ 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 ................................................16
+ 8.2.1. Source Symbol Construction .........................16
+ 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 ....................................18
+ 9. Security Considerations ........................................18
+ 10. Session Description Protocol (SDP) Signaling ..................19
+ 11. Congestion Control Considerations .............................19
+ 12. IANA Considerations ...........................................19
+ 12.1. Registration of FEC Scheme IDs ...........................19
+ 13. Acknowledgements ..............................................20
+ 14. References ....................................................21
+
+
+
+Watson, et al. Standards Track [Page 3]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+1. 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
+
+
+
+Watson, et al. Standards Track [Page 4]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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.
+
+2. 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.
+
+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. Standards Track [Page 5]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+4.1. 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.
+
+4.2. 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
+
+5. 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.
+
+
+
+Watson, et al. Standards Track [Page 6]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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
+
+
+
+Watson, et al. Standards Track [Page 7]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ Information consists of the identity of the source block and the
+ encoding symbol ID associated with the packet.
+
+6. Raptor FEC Schemes for Arbitrary Packet Flows
+
+6.1. 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].
+
+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 1 when [RFC5053] is used and 2 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:
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 8]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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.
+
+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): 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.
+
+
+
+Watson, et al. Standards Track [Page 9]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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.
+
+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): 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.
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 10]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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.
+
+6.3. Procedures
+
+6.3.1. 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).
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 11]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+6.3.2. 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.
+
+6.4. 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.
+
+7. Optimized 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 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
+
+
+
+
+Watson, et al. Standards Track [Page 12]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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.
+
+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 3 when [RFC5053] is used and 4 when
+ [RFC6330] is used, as assigned by IANA.
+
+7.2.1.2. 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.
+
+7.2.2. 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.
+
+7.2.3. 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.
+
+7.3. Procedures
+
+7.3.1. Source Symbol Construction
+
+ See Section 6.3.1.
+
+
+
+
+
+Watson, et al. Standards Track [Page 13]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+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] 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.
+
+7.4. 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 14]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+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 5 when [RFC5053] is used and 6 when
+ [RFC6330] is used, as assigned by IANA.
+
+8.1.1.2. 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.
+
+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.
+
+ 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.
+
+
+
+Watson, et al. Standards Track [Page 15]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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.
+
+8.2. Procedures
+
+8.2.1. 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.
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 16]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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 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
+
+
+
+Watson, et al. Standards Track [Page 17]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ 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.
+
+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, 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.
+
+8.3. 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.
+
+
+9. 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.
+
+
+
+
+
+Watson, et al. Standards Track [Page 18]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+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.
+
+
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 19]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+ +----------+---------------------+----------------------------------+
+ | 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 20]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 21]
+
+RFC 6681 Raptor FEC Scheme August 2012
+
+
+Authors' Addresses
+
+ Mark Watson
+ Netflix
+ 100 Winchester Circle
+ Los Gatos, CA 95032
+ United States
+
+ EMail: watsonm@netflix.com
+
+
+ Thomas Stockhammer
+ Nomor Research
+ Brecherspitzstrasse 8
+ Munich 81541
+ Germany
+
+ EMail: stockhammer@nomor.de
+
+
+ Michael Luby
+ Qualcomm Research Berkeley
+ 2030 Addison Street
+ Berkeley, CA 94704
+ United States
+
+ EMail: luby@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Watson, et al. Standards Track [Page 22]
+