[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-watson-fecframe-raptor) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6681

FEC Framework                                                  M. Watson
Internet-Draft                                          Digital Fountain
Intended status:  Standards Track                       October 22, 2008
Expires:  April 25, 2009


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 25, 2009.

Abstract

   This document describes Fully-Specified Forward Error Correction
   (FEC) Schemes for the Raptor code and its application to reliable
   delivery of media streams in the context of FEC Framework.  The
   Raptor code is a systematic code, 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 code offers a close to
   optimal protection against arbitrary packet losses at a low
   computational complexity.  Two FEC Schemes are defined, one for
   protection of arbitrary packet flows and another 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.



Watson                   Expires April 25, 2009                 [Page 1]

Internet-Draft              Raptor FEC Scheme               October 2008


   An RTP Payload Type is defined for this latter case.


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



Watson                   Expires April 25, 2009                 [Page 2]

Internet-Draft              Raptor FEC Scheme               October 2008


     12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 17
   13. Normative References . . . . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19















































Watson                   Expires April 25, 2009                 [Page 3]

Internet-Draft              Raptor FEC Scheme               October 2008


1.  Introduction

   The FEC Framework [I-D.ietf-fecframe-framework] describes a framework
   for the application of Forward Error Correction to arbitrary packet
   flows.  Modelled after the FEC Building Block developed by the IETF
   Reliable Multicast Transport working group ([RFC5052]), the FEC
   Framework defines the concept of FEC Schemes which provide specific
   Forward Error Correction schemes.  This document describes two FEC
   Schemes which make use of the Raptor FEC code as defined in
   [RFC5053].

   The FEC protection mechanism is independent of the type of the source
   data, which can be an arbitrary sequence of packets, including for
   example audio or video data.  In general, the operation of the
   protection mechanism is as follows:

   o  The sender determines a set of source packets 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 protection operation on the source
      symbols to generate the required number of repair symbols.

   o  The sender packetizes the repair symbols and sends the repair
      packet(s) along with the source packets to the receiver(s).

   Per the FEC Framework requirements, the sender MUST transmit the
   source and repair packets in different source and repair flows,
   respectively.  At the receiver side, if all of the source packets are
   successfully received, there is no need for FEC recovery and the
   repair packets are discarded.  However, if there are missing source
   packets, the repair packets can be used to recover the missing
   information.

   The operation of the FEC mechanism requires that the receiver can
   identify the relationships between received source packets and repair
   packets and in particular which source packets are missing.  In many
   cases, data already exists in the source packets which can be used to
   refer to source packets and to identify which packets are missing.
   In this case we assume it is possible to derive a "sequence number"
   directly or indirectly from the source packets and this sequence
   number can be used within the FEC Scheme.  This case is referred to
   as a "single sequenced flow".  In this case the FEC Source Payload ID
   defined in [I-D.ietf-fecframe-framework] is empty and the source
   packets are not modified by the application of FEC, with obvious
   backwards compatibility advantages.



Watson                   Expires April 25, 2009                 [Page 4]

Internet-Draft              Raptor FEC Scheme               October 2008


   Otherwise, it is necessary to add data to the source packets for FEC
   purposes in the form of a non-empty FEC Source Payload ID.  This case
   if referred to as the "arbitrary packet flow" case.  Accordingly,
   this document defines two FEC Schemes, one for the case of a single
   sequenced flow and another for the case of arbitrary packet flows.


2.  Document Outline

   This document is organised as follows:

      Section 5 defines general procedures applicable to the use of the
      Raptor code in the context of the FEC Framework.

      Section 6defines an FEC Scheme for the case of arbitrary source
      flows and follows the format defined for FEC Schemes in
      [I-D.ietf-fecframe-framework].  This scheme is equivalent to that
      defined in [3GPP MBMS Specification].

      Section 7 defines an FEC Scheme similar to that defined in
      Section 6but with optimisations for the case where only limited
      source block sizes are required.  This scheme is equivalent to
      that defined in [DVB AL-FEC specification] for arbitrary packet
      flows.

      Section 8 defines an FEC Scheme for the case of a single sequenced
      flow and follows the format defined for FEC Schemes in

      [I-D.ietf-fecframe-framework].  This scheme is equivalent to that
      defined in [DVB AL-FEC specification] 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                   Expires April 25, 2009                 [Page 5]

Internet-Draft              Raptor FEC Scheme               October 2008


4.1.  Definitions

   This document uses the following definitions.  For further
   definitions that apply to FEC Framework in general, see
   [I-D.ietf-fecframe-framework].

   Source Flow:  The packet flow(s) carrying the source data and to
   which FEC protection is to be applied.

   Repair Flow:  The packet flow(s) carrying the repair data.

   Symbol:  A unit of data.  Its size, in bytes, is referred to as the
   symbol size.

   Source Symbol:  The smallest unit of data used during the encoding
   process.

   Repair Symbol:  Repair symbols are generated from the source symbols.

   Source Packet:  Data packets that contain only source symbols.

   Repair Packet:  Data packets that contain only repair symbols.

   Source Block:  A block of source symbols that are considered together
   in the encoding process.

   FEC Framework Configuration Information:  Information that controls
   the operation of the FEC Framework.  Each FEC Framework instance has
   its own configuration information.

   FEC Payload ID:  Information that identifies the contents of a packet
   with respect to the FEC scheme.

   Source FEC Payload ID:  An FEC Payload ID specifically used with
   source packets.

   Repair FEC Payload ID:  An FEC Payload ID specifically used with
   repair packets.

4.2.  Abbreviations

   o  FSSI:  FEC-Scheme-Specific Information.

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

   o  RS-FSSI:  Receiver-Side FEC-Scheme-Specific Information.





Watson                   Expires April 25, 2009                 [Page 6]

Internet-Draft              Raptor FEC Scheme               October 2008


5.  General procedures for Raptor FEC Schemes

   This section specifies general procedures which apply to all Raptor
   FEC Schemes, specifically the construction of source symbols from a
   set of source transport payloads.  As described in
   [I-D.ietf-fecframe-framework] for each source transport payload in a
   source block, the FEC Scheme is provided with:

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

   o  The source transport payload itself.

   o  The length of the source transport payload.

   For each source transport payload, we define the Source Packet
   Information (SPI) as follows:

   Let

      n be the number of source transport payloads in the source block.

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

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

      R[i] denote the number of octets in the (i+1)-th source transport
      payload.

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

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

      f[i] denote the integer identifier associated with the source
      transport payload from which the i-th source transport payload was
      taken.

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

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





Watson                   Expires April 25, 2009                 [Page 7]

Internet-Draft              Raptor FEC Scheme               October 2008


      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.

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

   Then, a source data block is constructed by concatenating SPI[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 source transport payload is associated with the
   Encoding Symbol ID of the first symbol containing SPI for that
   packet.  Thus, the Encoding Symbol ID value associated with the j-th
   source packet, ESI[j], is given by ESI[j] = 0, for j=0 and ESI[j] =
   sum{s[i], i=0,...,(j-1)}, for 0 < j < n.

   Source blocks are identified by integer Source Block Numbers.  This
   specification does not specify how Source Block Numbers are allocated
   to source blocks.  The Source FEC Packet Identification Information
   consists of the identity of the source block and the Encoding Symbol
   ID associated with the packet.


6.  Raptor FEC Scheme for arbitrary packet flows

6.1.  Introduction

   This section specifies an FEC Scheme for the application of the
   Raptor code to arbitary packet flows.  This scheme is recommended in
   scenarios where maximal generality is required.

   This scheme is equivalent to that specified in [3GPP MBMS
   Specification].

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 MUST be TBD 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:




Watson                   Expires April 25, 2009                 [Page 8]

Internet-Draft              Raptor FEC Scheme               October 2008


   Maximum Source Block Length  A non-negative integer less than 2^13,
      in units of symbols

   Encoding Symbol Size  A non-negative integer less than 2^16, in units
      of bytes

   An encoding format for this information in a 4 octet field is defined
   as follows:


                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Symbol Size (T)         |   Max. Source Block Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: FEC Scheme Specific Information

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.


                          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

   Source Block Number (SBN), (16 bits):  An integer identifier for the
   source block that the source data within the packet relates to.

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

6.2.3.  Repair FEC Payload ID

   The structure of the Repair FEC Payload ID is defined below:










Watson                   Expires April 25, 2009                 [Page 9]

Internet-Draft              Raptor FEC Scheme               October 2008


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

                           Repair FEC Payload ID

   Source Block Number (SBN), (16 bits)  An integer identifier for the
      source block that the repair symbols within the packet relate to.

   Encoding Symbol ID (ESI), (16 bits)  Integer identifier for the
      encoding symbols within the packet.

   Source Block Length (SBL), (16 bits)  The number of source symbols in
      the source block.

   The interpretation of the Source Block Number, Encoding Symbol
   Identifier and Source Block Length is defined by the FEC Code
   Specification.

6.3.  Procedures

6.3.1.  Source symbol construction

   This FEC Scheme uses the procedures defined in Section 5 to construct
   a set of source symbols to which the FEC code can be applied.  The
   sender MUST allocate Source Block Numbers to source blocks
   sequentially, wrapping around to zero after Source Block Number
   2^16-1.

   During the construction of the source block:

   o  the length indication, l[i], included in the Source Packet
      Information for each packet shall be the transport payload length.

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

6.3.2.  Repair packet construction

   The number of repair symbols contained within a repair packet is
   computed from the packet length.  The ESI value placed into a repair
   packet is given by the following formula:




Watson                   Expires April 25, 2009                [Page 10]

Internet-Draft              Raptor FEC Scheme               October 2008


   ESI_repair = I_repair + SBL,

   where I_repair is the index of the repair symbol in the sequence of
   repair symbols generated according to Section 6.4, where the first
   repair symbol has index 0, the second index 1 etc. and SBL is the
   Source Block Length.  The Source Block Length field of the Repair FEC
   Payload ID field SHALL be set to the number of symbols included in
   the Source Packet Information of packets associated with the source
   block.

6.4.  FEC Code Specification

   The Raptor FEC encoder defined in [RFC5053] SHALL be used.  The
   source symbols passed to the Raptor FEC encoder SHALL consist of the
   source symbols constructed according to Section 6.3.1.  Thus the
   value of the parameter K used by the FEC encoder (equal to the Source
   Block Length) may vary amongst the blocks of the stream but SHALL NOT
   exceed the Maximum Source Block Length signalled in the FEC Scheme-
   specific information.  The symbol size, T, to be used for source
   block construction and the repair symbol construction is equal to the
   Encoding Symbol Size signaled in the FEC Scheme Specific Information.


7.  Optimised Raptor FEC Scheme for arbitrary packet flows

7.1.  Introduction

   This section specifies a slightly modified version of the FEC Scheme
   specified in Section 6 which is applicable to scenarios in which only
   relatively small block sizes will be used.  These modifications admit
   substantial optimisations to both sender and receiver
   implementations.

   In outline, the modifications are:

      All source blocks within a stream are encoded using the same
      source block size.  Code shortening is used to encode blocks of
      different sizes.  This is achieved by padding every block to the
      required size using zero symbols before encoding.  The zero
      symbols are then discarded after decoding.  The source block size
      to be used for a stream is signalled in the Maximum Source Block
      Size field of the scheme-specific information.  This allows for
      efficient parallel encoding of multiple streams.

      A restricted set of possible source block sizes is specified.
      This allows explicit operation sequences for encoding the
      restricted set of block sizes to be pre-calculated and embedded in
      software or handware.



Watson                   Expires April 25, 2009                [Page 11]

Internet-Draft              Raptor FEC Scheme               October 2008


   This scheme is equivalent to that specified in [DVB AL-FEC
   Specification] 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 MUST be TBD as assigned by IANA.

7.2.1.2.  FEC Scheme specific information

   See . (Section 6.2.1.2)

7.2.2.  Source FEC Payload ID

   See . (Section 6.2.2)

7.2.3.  Repair FEC Payload ID

   SeeSection 6.2.3

7.3.  Procedures

7.3.1.  Source symbol construction

   See Section 6.3.1

7.3.2.  Repair packet construction

   The number of repair symbols contained within a repair packet is
   computed from the packet length.  The ESI value placed into a repair
   packet is given by the following formula:

   ESI_repair = I_repair + MSBL

   Where I_repair is the index of the repair symbol in the sequence of
   repair symbols generated according to Section 6.4, where the first
   repair symbol has index 0, the second index 1 etc. and MSBL is the
   Maximum Source Block Length signalled in the FEC Scheme Specific
   Information.  The Source Block Length field of the Repair FEC Payload
   ID field SHALL be set to the number of symbols included in the Source
   Packet Information of packets associated with the source block.






Watson                   Expires April 25, 2009                [Page 12]

Internet-Draft              Raptor FEC Scheme               October 2008


7.4.  FEC Code Specification

   The Raptor FEC encoder defined in [RFC5053] SHALL be used.  The
   source symbols passed to the Raptor FEC encoder SHALL consist of the
   source symbols constructed according to Section 6.3.1 extended with
   zero or more padding symbols such that the total number of symbols in
   the source block is equal to the Maximum Source Block Length signaled
   in the FEC Scheme Specific Information.  Thus the value of the
   parameter K used by the FEC encoded is equal to the Maximum Source
   Block Length for all blocks of the stream.  Padding symbols shall
   consist entirely of bytes set to the value zero.  The symbol size, T,
   to be used for source block construction and the repair symbol
   construction is equal to the Encoding Symbol Size signaled in the FEC
   Scheme Specific Information.  The parameter T shall be set such that
   the number of source symbols in any source block is at most KMAX =
   8192.  The Maximum Source Block Length parameter - and hence the
   number of symbols used in the FEC Encoding and Decoding operations -
   SHALL be set to one of the following values:

      101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031,
      1139, 1281


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 MUST be TBD as assigned by IANA.

8.1.1.2.  Scheme-specific elements

   See Section 6.2.1.2

8.1.2.  Source FEC Payload ID

   The Source FEC Payload ID field is not used by this FEC Scheme.
   Source packets are not modified by this FEC Scheme.

8.1.3.  Repair FEC Payload ID

   The Repair FEC Payload ID format for this FEC Scheme is shown below:





Watson                   Expires April 25, 2009                [Page 13]

Internet-Draft              Raptor FEC Scheme               October 2008


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

                      Figure 3: Repair FEC Payload ID

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

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

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

8.2.  Procedures

8.2.1.  Source symbol construction

   This FEC Scheme uses the procedures defined in Section 5 to construct
   a set of source symbols to which the FEC code can be applied.  The
   sender MUST allocate Source Block Numbers to source blocks
   sequentially, wrapping around to zero after Source Block Number
   2^16-1.

   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)







Watson                   Expires April 25, 2009                [Page 14]

Internet-Draft              Raptor FEC Scheme               October 2008


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 bytes) for source
   packets within a source block is equal to length of the payload
   containing encoding symbols of the repair packets (i.e. not including
   the Repair FEC Payload ID) for that block, which MUST be the same for
   all repair packets.  The Source Packet Information Length (SPIL) in
   symbols is equal to this length divided by the Encoding Symbol Size
   (which is signaled in the FEC Framework Configuration Information).
   The set of source packets which are included in the source block is
   determined from the Initial Sequence Number (ISN) and Source Block
   Length (SBL) as follows:

   Let,

      I be the Initial Sequence Number of the source block

      LP be the Source Packet Information Length in symbols

      LB be the Source Block Length in symbols

   Then, source packets with sequence numbers from I to I +LB/LP-1
   inclusive are included in the source block.

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

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

      The sequence number, Ns, of the packet

      The Source Packet Information Length for the source block, LP

      The Initial Sequence Number of the source block, I

   Then the Encoding Symbol ID for packet with sequence number Ns is
   determined by the following formula:




Watson                   Expires April 25, 2009                [Page 15]

Internet-Draft              Raptor FEC Scheme               October 2008


      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.

8.2.3.  Repair packet construction

   See Section 7.3.2

8.2.4.  Procedures for RTP source flows

   In the specific case of RTP source packet flows, then the RTP
   Sequence Number field SHALL be used as the sequence number in the
   procedures described above.  The length indication included in the
   Source Packet Information SHALL be the RTP payload length plus the
   length of the CSRCs, if any, and the RTP padding bytes, if any.  Note
   that this length is always equal to the UDP payload length of the
   packet, minus 12.

8.3.  FEC Code Specification

   See Section 7.4


9.  Security Considerations

   For the general security considerations related to the use of FEC,
   refer to [I-D.ietf-fecframe-framework].


10.  Session Description Protocol (SDP) Signaling

   This section provides an SDP [RFC4566] example.  The following
   example uses the SDP elements for FEC Framework, which were
   introduced in [I-D.ietf-fecframe-sdp-elements], and the FEC grouping
   semantics [RFC4756].

   In this example, we have one source video stream (mid:S1) and one FEC
   repair stream (mid:R1).  We form one FEC group with the "a=group:FEC
   S1 R1" line.  The source and repair streams are sent to the same port
   on different multicast groups.  The repair window is set to 200 ms.










Watson                   Expires April 25, 2009                [Page 16]

Internet-Draft              Raptor FEC Scheme               October 2008


        v=0
        o=ali 1122334455 1122334466 IN IP4 fec.rocks.com
        s=Interleaved Parity FEC Example
        t=0 0
        a=group:FEC S1 R1
        m=video 30000 RTP/AVP 100
        c=IN IP4 224.1.1.1/127
        a=rtpmap:100 MP2T/90000
        a=fec-source-flow: id=0
        a=mid:S1
        m=application 30000 udp/fec
        c=IN IP4 224.1.2.1/127
        a=fec-repair-flow: scheme-id=0; ss-fssi=5hu=
        a=repair-window: 200
        a=mid:R1


11.  Congestion Control Considerations

   For the general congestion control considerations related to the use
   of FEC, refer to [I-D.ietf-fecframe-framework].


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 [I-D.ietf-fecframe-framework].


13.  Normative References

   [I-D.ietf-fecframe-framework]
              Watson, M., "Forward Error Correction (FEC) Framework",
              draft-ietf-fecframe-framework-02 (work in progress),
              July 2008.

   [RFC5052]  "", 2005.

   [RFC5053]  "", 2005.

   [I-D.ietf-fecframe-sdp-elements]
              Begen, A., "SDP Elements for FEC Framework",
              draft-ietf-fecframe-sdp-elements-01 (work in progress),
              July 2008.




Watson                   Expires April 25, 2009                [Page 17]

Internet-Draft              Raptor FEC Scheme               October 2008


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

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

   [RFC4756]  Li, A., "Forward Error Correction Grouping Semantics in
              Session Description Protocol", RFC 4756, November 2006.


Author's Address

   Mark Watson
   Digital Fountain
   39141 Civic Center Drive
   Suite 300
   Fremont, CA  94538
   U.S.A.

   Email:  mark@digitalfountain.com































Watson                   Expires April 25, 2009                [Page 18]

Internet-Draft              Raptor FEC Scheme               October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Watson                   Expires April 25, 2009                [Page 19]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/