[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-fecframe-1d2d-parity-scheme

FEC Framework                                                   A. Begen
Internet-Draft                                                  R. Asati
Intended status:  Standards Track                          Cisco Systems
Expires:  August 21, 2008                              February 18, 2008


            1-D and 2-D Parity FEC Scheme for FEC Framework
               draft-begen-fecframe-1d2d-parity-scheme-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 August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes a Fully-Specified Forward Error Correction
   (FEC) Scheme for the one-dimensional (1-D) and two-dimensional (2-D)
   parity codes and its application to reliable delivery of media
   streams in the context of FEC Framework.  The 1-D and 2-D parity
   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 1-D and 2-D parity codes offer



Begen & Asati            Expires August 21, 2008                [Page 1]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   a good protection against random and bursty packet losses at a cost
   of decent complexity.  This document also specifies an RTP payload
   format for the FEC that is generated by the 1-D and 2-D parity codes
   from a source media encapsulated in RTP.  The FEC defined in this
   document is not backward compatible with RFC 5109.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Use Cases for 1-D Parity Codes . . . . . . . . . . . . . .  4
     1.2.  Use Cases for 2-D Parity Codes . . . . . . . . . . . . . .  4
     1.3.  Overhead Computation . . . . . . . . . . . . . . . . . . .  4
     1.4.  Backward Compatibility . . . . . . . . . . . . . . . . . .  5
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
   3.  Definitions, Notations and Abbreviations . . . . . . . . . . .  5
     3.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Notations  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Formats and Codes  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Source FEC Payload ID  . . . . . . . . . . . . . . . . . .  6
     4.2.  Repair FEC Payload ID  . . . . . . . . . . . . . . . . . .  7
     4.3.  FEC Framework Configuration Information  . . . . . . . . . 10
       4.3.1.  Mandatory Elements . . . . . . . . . . . . . . . . . . 11
       4.3.2.  Scheme-Specific Elements . . . . . . . . . . . . . . . 11
       4.3.3.  Encoding Format  . . . . . . . . . . . . . . . . . . . 12
   5.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  Configuration Information Signaling Procedures . . . . . . 12
     5.2.  Content Delivery Protocol Requirements . . . . . . . . . . 13
     5.3.  Determination of Source Block Size and Repair Window . . . 13
   6.  1-D and 2-D Parity FEC Code Specification  . . . . . . . . . . 13
     6.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  Repair Packet Construction . . . . . . . . . . . . . . . . 14
       6.2.1.  Generating the FEC Header  . . . . . . . . . . . . . . 14
       6.2.2.  Generating the Repair Packet Payload . . . . . . . . . 15
     6.3.  Source Packet Reconstruction . . . . . . . . . . . . . . . 15
       6.3.1.  Associating the Source and Repair Packets  . . . . . . 16
       6.3.2.  Recovering the RTP Header  . . . . . . . . . . . . . . 16
       6.3.3.  Recovering the RTP Payload . . . . . . . . . . . . . . 17
       6.3.4.  Iterative Decoding Algorithm for the 2-D Parity
               Codes  . . . . . . . . . . . . . . . . . . . . . . . . 18
   7.  SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  Congestion Control Considerations  . . . . . . . . . . . . . . 18
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     10.1. Registration of FEC Encoding ID  . . . . . . . . . . . . . 19
     10.2. Registration of audio/2dparityfec  . . . . . . . . . . . . 19
     10.3. Registration of video/2dparityfec  . . . . . . . . . . . . 19



Begen & Asati            Expires August 21, 2008                [Page 2]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


     10.4. Registration of text/2dparityfec . . . . . . . . . . . . . 19
     10.5. Registration of application/2dparityfec  . . . . . . . . . 19
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     12.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22











































Begen & Asati            Expires August 21, 2008                [Page 3]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


1.  Introduction

   This document defines a new RTP payload format for the FEC that is
   generated by the 1-D and 2-D parity codes from a source media
   encapsulated in RTP [RFC3550].  The type of the protected source
   media can be audio, video, text or application.  The payload format
   also allows for a wide range of FEC configurations to be used within
   the FEC Framework.  The configuration information for the FEC
   Framework is described through out-of-band means.  This configuration
   information plus the information contained in the payload format let
   the receiver(s) know the exact associations/relationships between the
   source and repair packets.

   The FEC supported by this format uses the simple exclusive OR (XOR)
   operation.  In a nutshell, the sender determines a set of source
   packets to be protected together based on the FEC Framework
   Configuration Information.  The sender then applies the XOR operation
   to generate the required number of repair packets 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 should be discarded.  However, if there are missing
   source packets, the repair packets can be used to recover the missing
   information.

   Editor's note:  Include brief introduction to the parity codes, show
   a block diagram, column FEC/row FEC, the notion of L and D.

1.1.  Use Cases for 1-D Parity Codes

   Editor's note:  This section should include the use cases for the 1-D
   parity codes, the scenarios where the 1-D parity codes fail.

1.2.  Use Cases for 2-D Parity Codes

   Editor's note:  This section should include the use cases for the 2-D
   parity codes, the scenarios where they offer an advantage over the
   1-D version and the scenarios where the 2-D parity codes fail.

1.3.  Overhead Computation

   Editor's note:  This section should include formulations to be used
   to compute the overhead for the 1-D and 2-D parity codes.






Begen & Asati            Expires August 21, 2008                [Page 4]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


1.4.  Backward Compatibility

   Editor's note:  This section should include the limitations of the
   existing specs such as [SMPTE2022-1] and [RFC5109].  It should also
   include the differences between these specs.

   This FEC scheme specification follows the document structure defined
   in [I-D.ietf-fecframe-framework].


2.  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].


3.  Definitions, Notations and Abbreviations

   The definitions, notations and abbreviations commonly used in this
   document are summarized in this section.

3.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.  All source symbols within a source block have the same
   size.

   Repair Symbol:  Repair symbols are generated from the source symbols
   and they have the same size as the source symbols of that source
   block.

   Source Packet:  Data packets that contain only source symbols.

   Repair Packet:  Data packets that contain only repair symbols.




Begen & Asati            Expires August 21, 2008                [Page 5]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   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.

3.2.  Notations

   o  L:  Number of columns of the source block.

   o  D:  Number of rows of the source block.

3.3.  Abbreviations

   o  XOR:  Bitwise exclusive OR operation. 0 XOR 0 = 0; 0 XOR 1 = 1; 1
      XOR 0 = 1; 1 XOR 1 = 0.

   o  FSSI:  FEC-Scheme-Specific Information.

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

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

   o  ToP:  Type of the protection applied by the sender.

   o  ToF:  Type of the FEC data carried in the repair packet.


4.  Formats and Codes

   This section defines the formats of the source and repair packets as
   well as the configuration information for the FEC scheme.

4.1.  Source FEC Payload ID

   The source packets MUST contain the information that identifies the
   source block and the position within the source block occupied by the
   packet.  This information is referred to as the Source FEC Payload



Begen & Asati            Expires August 21, 2008                [Page 6]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   ID.  In some cases, Source FEC Payload ID may be inferred from the
   fields already existing in the packet.  In other cases, however, the
   required information is explicitly encoded into a specific field
   called Explicit Source FEC Payload ID, which is appended to the end
   of the source packets [I-D.ietf-fecframe-framework].

   Since the source packets that are carried within an RTP stream
   already contain unique sequence numbers in their RTP headers
   [RFC3550], the Source FEC Payload ID can be derived in a
   straightforward manner.  Thus, there is no need to use the Explicit
   Source FEC Payload ID field.  The primary advantage of this approach
   is that the source packets are not modified in anyway.  This provides
   backward compatibility for the receivers that do not support FEC at
   all.  In multicast scenarios, this backward compatibility becomes
   quite useful as it allows the non-FEC-capable receivers to receive
   and interpret the source packets.

   The derivation of the Source FEC Payload ID from the RTP sequence
   number is discussed in Section 5.

   Editor's note:  This section should specify the additional
   requirements that are relevant to grouping multiple source flows
   together before applying FEC protection.

4.2.  Repair FEC Payload ID

   The repair packets MUST contain information that identifies the
   source block they pertain to and the relationship between the
   contained repair symbols and the original source block.  This
   information is referred to as the Repair FEC Payload ID.  This
   information MUST be encoded into a specific field between the
   transport header and the repair symbols within a repair packet, as
   shown in Figure 1 [I-D.ietf-fecframe-framework].


















Begen & Asati            Expires August 21, 2008                [Page 7]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


                      +------------------------------+
                      |          IP Header           |
                      +------------------------------+
                      |       Transport Header       |
                      +------------------------------+
                      |    Repair FEC Payload ID     |
                      +------------------------------+
                      |        Repair Symbols        |
                      +------------------------------+

                    Figure 1: Format of repair packets

   Since the repair packets are carried within an RTP stream, the Repair
   FEC Payload ID consists of an RTP header and an FEC header.  This is
   shown in Figure 2.

   +------------------------------+
   |          IP Header           |
   +------------------------------+
   |       Transport Header       |  ,--+------------------------------+
   +------------------------------+-'   |         RTP Header           |
   |    Repair FEC Payload ID     |     +------------------------------+
   +------------------------------+-.   |         FEC Header           |
   |        Repair Symbols        |  `--+------------------------------+
   +------------------------------+

                 Figure 2: Format of Repair FEC Payload ID

   The RTP header is formatted according to [RFC3550] with some further
   clarifications listed below:

   o  Marker:  This field is not used for this payload type, and SHALL
      be set to 0.

   o  Synchronization Source (SSRC):  The SSRC value SHALL be the same
      as the SSRC value of the protected source RTP stream.

   o  Sequence Number (SN):  The sequence number has the standard
      definition.  It MUST be one higher than the sequence number in the
      previously transmitted repair packet.

   o  Timestamp (TS):  The timestamp MUST be set to the value of the
      media RTP clock at the instant the repair packet is transmitted.
      Thus, the TS value in FEC packets is always monotonically
      increasing.

   o  Payload Type:  The payload type for the repair packets is
      determined through the payload format specified in the FEC



Begen & Asati            Expires August 21, 2008                [Page 8]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


      Framework Configuration Information.  Note that this document
      introduces a new payload format for the repair packets (See
      Section 10 for details).  According to [RFC3550], an RTP receiver
      that cannot recognize a payload type must discard it.  This
      provides backward compatibility.  The FEC mechanisms can then be
      used in a multicast group with mixed FEC-capable and non-FEC-
      capable receivers.  If the non-FEC-capable receivers receive any
      repair packet, they will not recognize the payload type, and
      hence, discard the repair packets.

   The FEC header is 12 octets.  The format of the FEC header is shown
   in Figure 3.

      0                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|I|P|X|  CC   |M| PT recovery |            SN base            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          TS recovery                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Length recovery        |   Increment   |       NA      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 3: Format of the FEC header

   The FEC header consists of the following fields:

   o  The E bit is the extension flag reserved to indicate any future
      extension to this specification.  It SHALL be set to 0, and SHOULD
      be ignored by the receiver.

   o  The I bit MUST be set to 0 for the column-FEC packets, and MUST be
      set to 1 for the row-FEC packets.  This is the indicator bit that
      shows the type of the FEC carried with this packet.

   o  The P recovery field, the X recovery field, the CC recovery field,
      the M recovery field, and the PT recovery field are obtained by
      applying protection to the corresponding P, X, CC, M, and PT
      values from the RTP headers of the source packets associated with
      this repair packet.

   o  The SN base field MUST be set to the lowest sequence number,
      taking wrap around into account, of those source packets protected
      by FEC.

   o  The TS recovery field is computed by applying protection to the
      timestamps of the source packets associated with this repair
      packet.  This allows the timestamp to be completely recovered.



Begen & Asati            Expires August 21, 2008                [Page 9]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   o  The Length recovery field is used to determine the length of any
      recovered packets.  It is computed by applying protection to the
      unsigned network-ordered 16-bit representation of the sums of the
      lengths (in bytes) of the media payload, CSRC list, extension and
      padding of each of the source packets associated with this repair
      packet.  In other words, the CSRC list, RTP extension, and padding
      of the media payload packets, if present, are counted as part of
      the payload.  This allows the FEC procedure to be applied even
      when the lengths of the protected source packets are not
      identical.

   o  The Increment field is the period used to select the source
      packets associated with this repair packet.  It MUST be set to the
      L parameter defined in Section 4.3.2 for the column-FEC packets,
      and MUST be set to 1 for the row-FEC packets.

   o  The NA field indicates the number of source packets associated
      with this repair packet.  It MUST be set to the D parameter
      defined in Section 4.3.2 for the column-FEC packets, and MUST be
      set to the L parameter defined in Section 4.3.2 for the row-FEC
      packets.

   Editor's note:  Since the L and D are specified in the FSSI, we may
   easily skip the Increment and NA fields in the header.  However, this
   information may be needed by the Repair FEC Payload ID and is useful
   for sanity checks.

   Editor's note:  Shall we consider D and L values larger than 255?  If
   we don't put the Increment and NA fields in the repair packets,
   length of the D and L values will not be an issue any more.

   It should be noted that a mask-based approach (similar to the one
   specified in [RFC5109]) may not be very efficient to indicate which
   source packets in the current source block are associated with a
   given repair packet.  In particular, for the applications that would
   like to use large source block sizes, the size of the mask that is
   required to describe the source-repair packet associations may be
   prohibitively large.  Instead, a systematic approach that specifies
   the same relationships with fewer bits is generally more efficient.

4.3.  FEC Framework Configuration Information

   The FEC Framework defines a minimum set of information that MUST be
   communicated between the sender and receiver(s) for a proper
   operation of the FEC scheme.  This information is called the FEC
   Framework Configuration Information.  This information specifies how
   the sender applies protection to the source flow(s) and how the
   repair flow(s) can be used to recover the lost data.  In other words,



Begen & Asati            Expires August 21, 2008               [Page 10]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   this information specifies the relationship(s) between the source and
   repair flows.  The FEC Framework requires every FEC Framework
   instance to provide its own configuration information.

   From the FEC scheme point of view, the FEC Framework Configuration
   Information consists of mandatory and scheme-specific elements.  We
   describe these elements below.

4.3.1.  Mandatory Elements

   o  FEC Encoding ID:  The value of the FEC Encoding ID for the fully-
      specified FEC scheme defined in this document MUST be TBD as
      assigned by IANA.  Refer to Section 10.

4.3.2.  Scheme-Specific Elements

   FEC-Scheme-Specific Information (FSSI) includes the information that
   is specific to the FEC scheme used by the Content Delivery Protocol.
   FSSI is used to communicate the information that cannot be adequately
   represented otherwise and is essential for proper FEC encoding and
   decoding operations.

   The FSSI is carried in two opaque containers.  The first container
   contains the FSSI required only by the sender.  This information is
   referred to as the Sender-Side FEC-Scheme-Specific Information (SS-
   FSSI).  Rest of the FSSI is referred to as the Receiver-Side FEC-
   Scheme-Specific Information (RS-FSSI) and carried in the second
   container.

   The following parameters are carried in the FEC Scheme-Specific
   Information element:

   o  L:  Number of columns of the source block.  L is a positive
      integer.  L cannot be larger than 255.

   o  D:  Number of rows of the source block.  D is a positive integer.
      D cannot be larger than 255.

   o  SA:  Sending arrangement.  This is TBD.

      Editor's note:  Shall we define the sending arrangements?  Can we
      generalize this?  Or, should we fix it to a certain sending
      arrangement?  Or, should we use "repair-window" attribute to
      figure out the sending arrangement?  E.g., send the repair packets
      (as smoothly as possible) such that repair window requirement is
      not violated.

      Editor's note:  In a strict sense, sending arrangement does not



Begen & Asati            Expires August 21, 2008               [Page 11]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


      depend on the FEC scheme and probably should not be part of this
      specification.  It is a transmission problem, which is out of the
      scope of this document.

   o  ToP:  Type of the protection applied by the sender.  There are
      three possible values for ToP:  0 for 1-D column-FEC protection, 1
      for 1-D row-FEC protection, and 2 for 2-D column and row-FEC
      protection.  The ToP value of 3 is reserved for possible uses in
      the future.  The ToP value MAY be set by the receiver or another
      3rd party entity to control the FEC operations at the sender.

      Editor's note:  Shall we consider code types other than XOR?

   o  ToF:  Type of the FEC data carried in the repair flow. 0 for
      column FEC, and 1 for row FEC.  While the type of the FEC data
      within a repair packet is already indicated by the I bit in the
      FEC header, ToF is used by the receivers to determine which repair
      flow carries which FEC data before they start receiving the repair
      packets.  For example, the sender might be generating two repair
      flows corresponding to column FEC and and row FEC, and the
      receiver might be interested only in the column-FEC protection.
      The receiver can identify the repair flow carrying the column-FEC
      data by checking the ToF values for each repair flow described in
      the FEC Framework Configuration Information.

   All of the parameters listed above MUST be included in the FSSI.  The
   parameters L, D and ToP are carried within the SS-FSSI container.
   The parameter ToF is carried within the RS-FSSI container.

4.3.3.  Encoding Format

   The SS-FSSI container contains the string resulting from the Base64
   encoding of the following value:  TBD

   The RS-FSSI container contains the string resulting from the Base64
   encoding of the following value:  TBD


5.  Procedures

   This section describes the procedures that are specific to the 1-D
   and 2-D parity FEC scheme.

5.1.  Configuration Information Signaling Procedures

   This specification makes use of the signaling protocol to signal the
   FEC Framework Configuration Information between the sender and
   receiver(s).  This enables the sender and receiver(s) to be in sync



Begen & Asati            Expires August 21, 2008               [Page 12]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   with respect to the information needed for the operation of FEC
   Framework.

5.2.  Content Delivery Protocol Requirements

   Content Delivery Protocol (CDP) is a complete application-protocol
   specification that provides FEC capabilities by making use of the FEC
   Schemes through the use of FEC Framework defined in
   [I-D.ietf-fecframe-framework].

   The 1-D/2-D parity encoder and decoder require the following from the
   CDP:

   o  The size of the source block, namely the number of columns (L) and
      the number of rows (D).

   o  Type of the protection to be applied to the source blocks (ToP).

   This information is transmitted to the receiver side by the CDP
   through the FEC Framework Configuration Information.  The 1-D/2-D
   parity encoder additionally requires:

   o  The data to be protected.

   The 1-D/2-D parity encoder provides the following information to the
   CDP:

   o  A column-FEC packet that is generated by applying FEC over each
      column in the current source block, if column-FEC is enabled.

   o  A row-FEC packet that is generated by applying FEC over each row
      in the current source block, if row-FEC is enabled.

   The source packets as well as the repair packets are then transmitted
   to the receiver(s) by the transport protocol chosen by the CDP.

5.3.  Determination of Source Block Size and Repair Window

   TBC.

   Editor's note:  This section should discuss the derivation of the
   Source FEC Payload ID from the RTP sequence number.


6.  1-D and 2-D Parity FEC Code Specification

   This section provides a complete specification of the 1-D and 2-D
   parity FEC scheme.  Basically, it specifies the steps involved in



Begen & Asati            Expires August 21, 2008               [Page 13]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   generating the repair packets and reconstructing the missing source
   packets from the repair packets.

6.1.  Overview

   TBC.

6.2.  Repair Packet Construction

   The Repair FEC Payload ID consists of an RTP header and an FEC
   header.  The RTP header of an repair packet is formed based on the
   guidelines given in Section 4.2.

6.2.1.  Generating the FEC Header

   The FEC header includes 12 octets (96 bits).  It is constructed by
   applying the XOR operation on the bit strings that are generated from
   the individual source packets protected by this particular repair
   packet.  The set of the source packets that are associated with a
   given repair packet can be computed by the formula given in
   Section 6.3.1.

   The bit string is formed for each source packet by concatenating the
   following fields together in the order specified:

   o  The first 64 bits of the RTP header (64 bits).

   o  Unsigned network-ordered 16-bit representation of the source
      packet length in bytes minus 12 (for the fixed RTP header), i.e.,
      the sum of the lengths of all the following if present:  the CSRC
      list, extension header, RTP payload, and RTP padding (16 bits).

   By applying parity operation on the bit strings, we generate the FEC
   bit string.  The FEC header is generated from the FEC bit string as
   follows:

   o  The first (most significant) 2 bits in the FEC bit string are
      skipped.

   o  The next bit in the FEC bit string is written into the P recovery
      bit of the FEC header in the FEC packet.

   o  The next bit in the FEC bit string is written into the X recovery
      bit of the FEC header.

   o  The next 4 bits of the FEC bit string are written into the CC
      recovery field of the FEC header.




Begen & Asati            Expires August 21, 2008               [Page 14]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   o  The next bit is written into the M recovery bit of the FEC header.

   o  The next 7 bits of the FEC bit string are written into the PT
      recovery field in the FEC header.

   o  The next 16 bits are skipped.

   o  The next 32 bits of the FEC bit string are written into the TS
      recovery field in the FEC header.

   o  The next 16 bits are written into the length recovery field in the
      packet header.

   As described in Section 4.2, the SN base field of the FEC header MUST
   be set to the lowest sequence number of the source packets protected
   by this repair packet.  For the column-FEC packets, this corresponds
   to the lowest sequence number of the source packets that form the
   column.  For the row-FEC packets, the SN base field MUST be set to
   the lowest sequence number of the source packets that form the row.

   The Increment field MUST be set to the L parameter defined in
   Section 4.3.2 for the column-FEC packets, and MUST be set to 1 for
   the row-FEC packets.  Finally, the NA field MUST be set to the D
   parameter defined in Section 4.3.2 for the column-FEC packets, and
   MUST be set to the L parameter defined in Section 4.3.2 for the row-
   FEC packets.

6.2.2.  Generating the Repair Packet Payload

   The repair packet payload consists of the bits that are generated by
   applying the XOR operation on the payloads of the source RTP packets.
   If the payload lengths of the source packets are not equal, each
   shorter packet MUST be padded to the length of the longest packet by
   adding octet 0's at the end.

6.3.  Source Packet Reconstruction

   This section describes the recovery procedures that are required to
   reconstruct the missing packets.  The recovery process has two steps.
   In the first step, the FEC decoder determines which source and repair
   packets should be used in order to recover a missing packet.  In the
   second step, the decoder recovers the missing packet, which consists
   of an RTP header and RTP payload.

   In the following, we describe the RECOMMENDED algorithms for the
   first and second step.  Based on the implementation, different
   algorithms MAY be adopted.  However, note that the same algorithms
   are used by the 1-D parity codes, regardless of whether the FEC is



Begen & Asati            Expires August 21, 2008               [Page 15]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   applied over a column or a row.  The 2-D parity codes, on the other
   hand, usually require multiple iterations of the procedures described
   here.  This iterative decoding algorithm is further explained in
   Section 6.3.4.

6.3.1.  Associating the Source and Repair Packets

   The first step is associating the source and repair packets.  By
   virtue of the I bit in the FEC header, each repair packet is
   indicated whether it is a column or row-FEC packet.  In addition, the
   SN base field in the FEC header shows the lowest sequence number of
   the source packets that form the particular column or row.  Finally,
   the information of how many source packets are included in each
   column or row is available from the Increment and NA fields in the
   FEC header and from the FEC Framework Configuration Information.
   This set of information uniquely identifies all of the source packets
   associated with a given repair packet.

   Mathematically, for any received repair packet, p*, we can determine
   the sequence numbers of the source packets that are protected by this
   repair packet as follows:

                           p*_snb + i * Increment

   where p*_snb denotes the value indicated in the SN base field of p*,
   and

                                0 <= i < NA

   We denote the set of the source packets associated with a repair
   packet by the set T. Note that in a source block whose size is L
   columns by D rows, set T includes D source packets plus one repair
   packet for the FEC applied over a column, and L source packets plus
   one repair packet for the FEC applied over a row.

6.3.2.  Recovering the RTP Header

   For a given set T, the procedure for the recovery of the RTP header
   of the missing packet, whose sequence number is denoted by X, is as
   follows:

   1.   For each of the source packets that are successfully received in
        T, compute the 80-bit string by concatenating the first 64 bits
        of their RTP header and the unsigned network-ordered 16-bit
        representation of their length in bytes minus 12.

   2.   For the repair packet in T, compute the FEC bit string from the
        first 80 bits of the FEC header.



Begen & Asati            Expires August 21, 2008               [Page 16]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   3.   Calculate the recovered bit string as the XOR of the bit strings
        generated from all source packets in T and the FEC bit string
        generated from the repair packet in T.

   4.   Create a new packet with the standard 12-byte RTP header and no
        payload.

   5.   Set the version of the new packet to 2.  Skip the first 2 bits
        in the recovered bit string.

   6.   Set the Padding bit in the new packet to the next bit in the
        recovered bit string.

   7.   Set the Extension bit in the new packet to the next bit in the
        recovered bit string.

   8.   Set the CC field to the next 4 bits in the recovered bit string.

   9.   Set the Marker bit in the new packet to the next bit in the
        recovered bit string.

   10.  Set the Payload type in the new packet to the next 7 bits in the
        recovered bit string.

   11.  Set the SN field in the new packet to X. Skip the next 16 bits
        in the recovered bit string.

   12.  Set the TS field in the new packet to the next 32 bits in the
        recovered bit string.

   13.  Take the next 16 bits of the recovered bit string and set Y to
        whatever unsigned integer this represents (assuming network-
        order).  Y represents the length of the new packet in bytes
        minus 12 (for the fixed RTP header), i.e., the sum of the
        lengths of all the following if present:  the CSRC list,
        extension header, RTP payload, and RTP padding.

   14.  Set the SSRC of the new packet to the SSRC of the media stream
        it's protecting, i.e., the SSRC of the media stream to which the
        FEC stream is associated.

   This procedure recovers the header of an RTP packet up to (and
   including) the SSRC field.

6.3.3.  Recovering the RTP Payload

   Following the recovery of the RTP header, the procedure for the
   recovery of the RTP payload is as follows:



Begen & Asati            Expires August 21, 2008               [Page 17]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


   1.  Append Y bytes to the new packet.

   2.  For each of the source packets that are successfully received in
       T, compute the bit string from the Y octets of data starting with
       the 13th octet of the packet.  If any of the bit strings
       generated from the source packets has a length shorter than Y,
       pad them to that length.  The padding of octet 0 MUST be added at
       the end of the bit string.  Note that the information of the
       first 12 octets are protected by the FEC header.

   3.  For the repair packet in T, compute the FEC bit string from the
       repair packet payload, i.e., the Y octets of data following the
       FEC header.

   4.  Calculate the recovered bit string as the XOR of the bit strings
       generated from all source packets in T and the FEC bit string
       generated from the repair packet in T.

   5.  Append the recovered bit string (Y octets) to the new packet
       generated in Section 6.3.2.

6.3.4.  Iterative Decoding Algorithm for the 2-D Parity Codes

   TBC.


7.  SDP Examples

   Editor's note:  This section should provide SDP [RFC4566] examples
   with different set of configurations.  The SDP elements for FEC
   Framework are introduced in [I-D.ietf-fecframe-sdp-elements].
   Current examples use [RFC4756] for grouping source and repair flows
   together in SDP.  However, the examples should be updated, in case
   new grouping semantics will be introduced
   [I-D.begen-mmusic-fec-grouping-issues] in MMUSIC WG.


8.  Congestion Control Considerations

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

   Editor's note:  Additional congestion control considerations
   regarding the use of 2-D parity codes should be added here.







Begen & Asati            Expires August 21, 2008               [Page 18]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


9.  Security Considerations

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


10.  IANA Considerations

10.1.  Registration of FEC Encoding ID

   The value of FEC Encoding ID is subject to IANA registration.  For
   general guidelines on IANA considerations as they apply to this
   document, see [I-D.ietf-fecframe-framework].

   This document assigns the Fully-Specified FEC Encoding ID TBD under
   the ietf:fecframe:fec:encoding name-space to TBD.

10.2.  Registration of audio/2dparityfec

   TBC.

10.3.  Registration of video/2dparityfec

   TBC.

10.4.  Registration of text/2dparityfec

   TBC.

10.5.  Registration of application/2dparityfec

   TBC.


11.  Acknowledgments

   A major part of this document is borrowed from [RFC5109].  Thus, the
   authors would like to thank the editor of [RFC5109] and those who
   contributed to [RFC5109].

   The authors would also like to thank the FEC Framework Design Team
   for their inputs, suggestions and contributions.


12.  References






Begen & Asati            Expires August 21, 2008               [Page 19]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


12.1.  Normative References

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

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

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

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [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.

   [I-D.begen-mmusic-fec-grouping-issues]
              Begen, A., "FEC Grouping Issues in Session Description
              Protocol", draft-begen-mmusic-fec-grouping-issues-00 (work
              in progress), February 2008.

   [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

12.2.  Informative References

   [SMPTE2022-1]
              SMPTE 2022-1-2007, "Forward Error Correction for Real-Time
              Video/Audio Transport Over IP Networks", 2007.













Begen & Asati            Expires August 21, 2008               [Page 20]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 2008


Authors' Addresses

   Ali Begen
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  abegen@cisco.com


   Rajiv Asati
   Cisco Systems
   7025-6 Kit Creek Road PO Box 14987
   RTP, NC  27709
   USA

   Email:  rajiva@cisco.com

































Begen & Asati            Expires August 21, 2008               [Page 21]


Internet-Draft        1-D and 2-D Parity FEC Scheme        February 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Begen & Asati            Expires August 21, 2008               [Page 22]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/