GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6681

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6681.txt · Last modified: 2012/08/14 16:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki