Internet DRAFT - draft-ietf-fecframe-raptor

draft-ietf-fecframe-raptor






FEC Framework                                                  M. Watson
Internet-Draft                                                   Netflix
Intended status:  Standards Track                         T. Stockhammer
Expires:  November 11, 2012                               Nomor Research
                                                                 M. Luby
                                                   Qualcomm Incorporated
                                                            May 10, 2012


                    Raptor FEC Schemes for FECFRAME
                     draft-ietf-fecframe-raptor-11

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 November 11, 2012.

Copyright Notice




Watson, et al.          Expires November 11, 2012               [Page 1]

Internet-Draft              Raptor FEC Scheme                   May 2012


   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.          Expires November 11, 2012               [Page 2]

Internet-Draft              Raptor FEC Scheme                   May 2012


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 . . . . . . . . . . . . . . . . . . . . . . . . 13
       6.3.1.  Source symbol construction . . . . . . . . . . . . . . 13
       6.3.2.  Repair packet construction . . . . . . . . . . . . . . 13
     6.4.  FEC Code Specification . . . . . . . . . . . . . . . . . . 13
   7.  Optimised Raptor FEC Scheme for arbitrary packet flows . . . . 13
     7.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 14
     7.2.  Formats and Codes  . . . . . . . . . . . . . . . . . . . . 14
       7.2.1.  FEC Framework Configuration Information  . . . . . . . 14
       7.2.2.  Source FEC Payload ID  . . . . . . . . . . . . . . . . 15
       7.2.3.  Repair FEC Payload ID  . . . . . . . . . . . . . . . . 15
     7.3.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
       7.3.1.  Source symbol construction . . . . . . . . . . . . . . 15
       7.3.2.  Repair packet construction . . . . . . . . . . . . . . 15
     7.4.  FEC Code Specification . . . . . . . . . . . . . . . . . . 15
   8.  Raptor FEC Scheme for a single sequenced flow  . . . . . . . . 16
     8.1.  Formats and codes  . . . . . . . . . . . . . . . . . . . . 16
       8.1.1.  FEC Framework Configuration Information  . . . . . . . 16
       8.1.2.  Source FEC Payload ID  . . . . . . . . . . . . . . . . 16
       8.1.3.  Repair FEC Payload ID  . . . . . . . . . . . . . . . . 16
     8.2.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . 18
       8.2.1.  Source symbol construction . . . . . . . . . . . . . . 18
       8.2.2.  Derivation of Source FEC Packet Identification
               Information  . . . . . . . . . . . . . . . . . . . . . 18
       8.2.3.  Repair packet construction . . . . . . . . . . . . . . 19
       8.2.4.  Procedures for RTP source flows  . . . . . . . . . . . 19
     8.3.  FEC Code Specification . . . . . . . . . . . . . . . . . . 20
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   10. Session Description Protocol (SDP) Signaling . . . . . . . . . 20
   11. Congestion Control Considerations  . . . . . . . . . . . . . . 21
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 21
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22



Watson, et al.          Expires November 11, 2012               [Page 3]

Internet-Draft              Raptor FEC Scheme                   May 2012


     14.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     14.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
















































Watson, et al.          Expires November 11, 2012               [Page 4]

Internet-Draft              Raptor FEC Scheme                   May 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 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, 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 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



Watson, et al.          Expires November 11, 2012               [Page 5]

Internet-Draft              Raptor FEC Scheme                   May 2012


   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 case
   is 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 6 defines 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 "3GPP TS 26.346:  Multimedia Broadcast/Multicast
      Service (MBMS); Protocols and codecs" [MBMSTS].

   o  Section 7 defines an FEC Scheme similar to that defined in
      Section 6 but with optimisations for the case where only limited
      source block sizes are required.  When used with Raptor codes,
      this scheme is equivalent to that defined in "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 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



Watson, et al.          Expires November 11, 2012               [Page 6]

Internet-Draft              Raptor FEC Scheme                   May 2012


   document are summarized in this section.

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 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 FEC Framework in
   general as defined in [RFC6363].  In addition, this document uses the
   following abbreviations

   FSSI:  FEC-Scheme-Specific Information.

   SS-FSSI:  Sender-Side FEC-Scheme-Specific Information.

   RS-FSSI:  Receiver-Side 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 which 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:



Watson, et al.          Expires November 11, 2012               [Page 7]

Internet-Draft              Raptor FEC Scheme                   May 2012


   o  A description of the source data flow with which the ADU is
      associated and an integer identifier associated with that flow.

   o  The ADU itself.

   o  The length of the ADU.

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

   Let

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

   o  T be the source symbol size in octets.  Note:  this information is
      provided by the FEC Scheme as defined below.

   o  i the index to the (i+1)-th ADU to be added to the source block, 0
      <= i < n.

   o  f[i] denote the integer identifier associated with the source data
      flow from which the i-th ADU was taken.

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

   o  l[i] be a length indication associated with the i-th ADU - the
      nature of the length indication is defined by the FEC Scheme.

   o  L[i] denote two octets representing the value of l[i] in network
      byte order (high order octet first) of the i-th ADU.

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

   o  s[i] be the smallest integer such that s[i]*T >= (l[i]+3).  Note
      s[i] is the length of SPI[i] in units of symbols of size T octets.

   o  P[i] denote s[i]*T-(l[i]+3) zero octets.  Note:  P[i] are padding
      octets to align the start of each UDP packet with the start of a
      symbol.

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

   Then, a source data block is constructed by concatenating ADUI[i] for
   i = 0, 1, 2, ... n-1.  The source data block size, S, is then given
   by sum {s[i]*T, i=0, ..., n-1}.  Symbols are allocated integer
   Encoding Symbol IDs 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



Watson, et al.          Expires November 11, 2012               [Page 8]

Internet-Draft              Raptor FEC Scheme                   May 2012


   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.


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 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 XXX1 when [RFC5053] is used and XXX2 when
   [RFC6330] is used, as assigned by IANA.

   NOTE:  To the RFC Editor:  please change these XXX notations once
      assigned, and remove this NOTE.

6.2.1.2.  Scheme-Specific Elements

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

   MSBL  Value range:  An non-negative integer less than 8192 for FEC
      Scheme XXX1 and less than 56403 for FEC Scheme XXX2, in units of
      symbols.  The field type is unsigned integer.

   Encoding Symbol Size  Name:  "T", Value range:  A non-negative
      integer less than 65536, in units of octets.  The field type is
      unsigned integer.




Watson, et al.          Expires November 11, 2012               [Page 9]

Internet-Draft              Raptor FEC Scheme                   May 2012


   Payload ID Format  Name:  "P", Value range:  "A" or "B".  The P bit
      shall be set to zero to indicate Payload ID Format A or to one to
      indicate Payload ID Format B.

   An encoding format for the MSBL and Encoding Symbol Size is defined
   below.


                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Symbol Size (T)         |          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 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
   for FEC Scheme XXX1.  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.













Watson, et al.          Expires November 11, 2012              [Page 10]

Internet-Draft              Raptor FEC Scheme                   May 2012


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

                Figure 2: Source FEC Payload ID - Format A

   Source Block Number (SBN), (16 bits):  Identifier for the source
      block that the source data within the packet relates.  The field
      type is unsigned integer.

   Encoding Symbol ID (ESI), (16 bits):  The starting symbol index of
      the source packet in the source block.  The field type is unsigned
      integer.

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


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

                Figure 3: Source FEC Payload ID - Format B

   Source Block Number (SBN), (8 bits):  Identifier for the source block
      that the source data within the packet relates.  The field type is
      unsigned integer.

   Encoding Symbol ID (ESI), (24 bits):  The starting symbol index of
      the source packet in the source block.  The field type is unsigned
      integer.

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.










Watson, et al.          Expires November 11, 2012              [Page 11]

Internet-Draft              Raptor FEC Scheme                   May 2012


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

                Figure 4: Repair FEC Payload ID - Format A

   Source Block Number (SBN), (16 bits)  Identifier for the source block
      that the repair symbols within the packet relate.  For format A,
      it is of size 16 bits.  The field type is unsigned integer.

   Encoding Symbol ID (ESI), (16 bits)  Identifier for the encoding
      symbols within the packet.  The field type is unsigned integer.

   Source Block Length (SBL), (16 bits)  The number of source symbols in
      the source block.  The field type is unsigned integer.

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


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

                Figure 5: Repair FEC Payload ID - Format B

   Source Block Number (SBN), (8 bits)  Identifier for the source block
      that the repair symbols within the packet relate.  For format B,
      it is of size 8 bits.  The field type is unsigned integer.

   Encoding Symbol ID (ESI), (24 bits)  Identifier for the encoding
      symbols within the packet.  The field type is unsigned integer.

   Source Block Length (SBL), (16 bits)  The number of source symbols in
      the source block.  The field type is unsigned integer.

   The interpretation of the Source Block Number, Encoding Symbol
   Identifier and Source Block Length is defined by the FEC Code
   Specification in [RFC5053] for FEC Scheme XXX1 and [RFC6330] for FEC
   Scheme XXX2.




Watson, et al.          Expires November 11, 2012              [Page 12]

Internet-Draft              Raptor FEC Scheme                   May 2012


6.3.  Procedures

6.3.1.  Source symbol construction

   FEC Scheme XXX1 and FEC Scheme XXX2 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).

6.3.2.  Repair packet construction

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

   For FEC Scheme XXX2 [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 FEC Scheme XXX1
   and the FEC encoder defined in [RFC6330] SHALL be used for FEC Scheme
   XXX2.  For both FEC Scheme XXX1 and FEC Scheme XXX2, 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.  Optimised Raptor FEC Scheme for arbitrary packet flows





Watson, et al.          Expires November 11, 2012              [Page 13]

Internet-Draft              Raptor FEC Scheme                   May 2012


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
      Length (MSBL) field of the scheme-specific information.  The
      extended source block is constructed by adding zero or more
      padding symbols such that the total number of symbols, MSBL, is
      one of the values listed in Section 7.4.  Each padding symbol
      consists of T octets where the value of each octet is zero.  MSBL
      MUST be selected as the smallest value of the possible values in
      Section 7.4 that is greater than or equal to K.

   o  The possible choices of the MSBL for a stream is restricted to a
      small specified set.  This allows explicit operation sequences for
      encoding and decoding the restricted set of source block lengths
      to be pre-calculated and embedded in software or hardware.

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

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 XXX3 when [RFC5053] is used and XXX4 when
   [RFC6330] is used, as assigned by IANA.

   NOTE:  To the RFC Editor:  please change these XXX notations once
      assigned, and remove this NOTE.






Watson, et al.          Expires November 11, 2012              [Page 14]

Internet-Draft              Raptor FEC Scheme                   May 2012


7.2.1.2.  FEC Scheme specific information

   The same as specified for FEC Scheme XXX1 for FEC Scheme XXX3, and
   the same as specified for FEC Scheme XXX2 for FEC Scheme XXX4, 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 same as specified for FEC Scheme XXX1 for FEC Scheme XXX3, and
   the same as specified for FEC Scheme XXX2 for FEC Scheme XXX4, as
   specified in Section 6.2.2.

7.2.3.  Repair FEC Payload ID

   The same as specified for FEC Scheme XXX1 for FEC Scheme XXX3, and
   the same as specified for FEC Scheme XXX2 for FEC Scheme XXX4, as
   specified in Section 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] for FEC Scheme XXX3 and as specified in
   Section 4.4.2 of [RFC6330] for FEC Scheme XXX4, 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
   XXX3 and the FEC encoder defined in [RFC6330] SHALL be used for FEC
   Scheme XXX4.  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 encoded 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
   source block construction and the repair symbol construction is equal



Watson, et al.          Expires November 11, 2012              [Page 15]

Internet-Draft              Raptor FEC Scheme                   May 2012


   to the Encoding Symbol Size signaled in the FEC Scheme Specific
   Information.

   For FEC Scheme XXX3, 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 XXX4, 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].


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 XXX5 when [RFC5053] is used and XXX6 when
   [RFC6330] is used, as assigned by IANA.

   NOTE:  To the RFC Editor:  please change these XXX notations once
      assigned, and remove this NOTE.

8.1.1.2.  Scheme-specific elements

   The same as specified for FEC Scheme XXX1 for FEC Scheme XXX5, and
   the same as specified for FEC Scheme XXX2 for FEC Scheme XXX6, 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.



Watson, et al.          Expires November 11, 2012              [Page 16]

Internet-Draft              Raptor FEC Scheme                   May 2012


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

                Figure 6: Repair FEC Payload ID - Format A

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

   Source Block Length (SBL) - 16 bits  This field specifies the length
      of the source block in symbols.  The field type is unsigned
      integer.

   Encoding Symbol ID (ESI) - 16 bits  This field indicates which repair
      symbols are contained within this repair packet.  The ESI provided
      is the ESI of the first repair symbol in the packet.  The field
      type is unsigned integer.

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

                Figure 7: Repair FEC Payload ID - Format B

   Initial Sequence Number (Flow i ISN) - 16 bits  This field specifies
      the lowest 16 bits of the sequence number 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.          Expires November 11, 2012              [Page 17]

Internet-Draft              Raptor FEC Scheme                   May 2012


   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 XXX5 and FEC Scheme XXX6 use the procedures defined in
   Section 5 to construct a set of source symbols to which the FEC code
   can be applied.

   During the construction of the source block:

   o  the length indication, l[i], included in the Source Packet
      Information for each packet shall be dependent on the protocol
      carried within the transport payload.  Rules for RTP are specified
      below.

   o  the value of s[i] in the construction of the Source Packet
      Information for each packet shall be the smallest integer such
      that s[i]*T >= (l[i]+3)

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,





Watson, et al.          Expires November 11, 2012              [Page 18]

Internet-Draft              Raptor FEC Scheme                   May 2012


   o  I be the Initial Sequence Number of the source block

   o  LP be the Source Packet Information Length in symbols

   o  LB be the Source Block Length in symbols

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

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

   The Encoding Symbol ID for a packet is derived from the following
   information:

   o  The sequence number, Ns, of the packet

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

   o  The Initial Sequence Number of the source block, I

   Then the Encoding Symbol ID for 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



Watson, et al.          Expires November 11, 2012              [Page 19]

Internet-Draft              Raptor FEC Scheme                   May 2012


   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
   is always equal to the UDP payload length of the packet minus 12.

8.3.  FEC Code Specification

   The same as specified for FEC Scheme XXX3 for FEC Scheme XXX5, and
   the same as specified for FEC Scheme XXX4 for FEC Scheme XXX6, 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.


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






Watson, et al.          Expires November 11, 2012              [Page 20]

Internet-Draft              Raptor FEC Scheme                   May 2012


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/rmt-fec-parameters.xml#fecframe-fec-encoding-ids)
   as provided in Table 1.  Each value refers to a fully-specified FEC
   scheme.

   NOTE:  To the RFC Editor:  please change these XXX notations once
      assigned, and remove this NOTE.

   +----------+---------------------+----------------------------------+
   | FEC      | FEC Scheme          | Reference                        |
   | Encoding | Description         |                                  |
   | ID       |                     |                                  |
   +----------+---------------------+----------------------------------+
   | XXX1     | Raptor FEC Scheme   | Section 6 in this document using |
   |          | for Arbitrary       | [RFC5053]                        |
   |          | Packet Flows        |                                  |
   +----------+---------------------+----------------------------------+
   | XXX2     | RaptorQ FEC Scheme  | Section 6 in this document using |
   |          | for Arbitrary       | [RFC6330].                       |
   |          | Packet Flows        |                                  |
   +----------+---------------------+----------------------------------+
   | XXX3     | Raptor FEC Scheme   | Section 7 in this document using |
   |          | Optimised for       | Raptor [RFC5053].                |
   |          | Arbitrary Packet    |                                  |
   |          | Flows               |                                  |
   +----------+---------------------+----------------------------------+
   | XXX4     | RaptorQ FEC Scheme  | XXX4 for the Optimised RaptorQ   |
   |          | Optimised for       | FEC Scheme for Arbitrary Packet  |
   |          | Arbitrary Packet    | Flows (Section 7) using RaptorQ  |
   |          | Flows               | [RFC6330].                       |
   +----------+---------------------+----------------------------------+





Watson, et al.          Expires November 11, 2012              [Page 21]

Internet-Draft              Raptor FEC Scheme                   May 2012


   +----------+---------------------+----------------------------------+
   | XXX5     | Raptor FEC Scheme   | XXX5 for the Raptor FEC Scheme   |
   |          | for a single        | for a single sequence flow       |
   |          | sequence flow       | (Section 8) using Raptor         |
   |          |                     | [RFC5053].                       |
   +----------+---------------------+----------------------------------+
   | XXX6     | RaptorQ FEC Scheme  | XXX6 for the RaptorQ FEC Scheme  |
   |          | for a single        | for a single sequence flow       |
   |          | sequence flow       | (Section 8) using RaptorQ        |
   |          |                     | [RFC6330].                       |
   +----------+---------------------+----------------------------------+

            Table 1: FEC Framework (FECFRAME) FEC Encoding IDs


13.  Acknowledgements

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


14.  References

14.1.  Normative References

   [RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
              Correction (FEC) Framework", RFC 6363, October 2011.

   [RFC5053]  Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
              "Raptor Forward Error Correction Scheme for Object
              Delivery", RFC 5053, October 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6330]  Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
              and L. Minder, "RaptorQ Forward Error Correction Scheme
              for Object Delivery", RFC 6330, August 2011.

14.2.  Informative References

   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
              Correction (FEC) Building Block", RFC 5052, August 2007.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

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



Watson, et al.          Expires November 11, 2012              [Page 22]

Internet-Draft              Raptor FEC Scheme                   May 2012


              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


   Michael Luby
   Qualcomm Incorporated
   3165 Kifer Road
   Santa Clara, CA  95051
   U.S.A.

   Email:  luby@qualcomm.com













Watson, et al.          Expires November 11, 2012              [Page 23]