doc: Add RFC documents

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]
+