FEC Framework Working Group                                                  M. Watson
Internet-Draft                                             Netflix, Inc.
Intended status: Standards Track                       September 7, 2010                                A. Begen
Expires: March 11, May 24, 2011                                              Cisco
                                                       November 20, 2010

                Forward Error Correction (FEC) Framework
                    draft-ietf-fecframe-framework-10
                    draft-ietf-fecframe-framework-11

Abstract

   This document describes a framework for using forward error
   correction Forward Error
   Correction (FEC) codes with applications in public and private IP
   networks to provide protection against packet loss.  The framework
   supports applying Forward Error Correction FEC to arbitrary packet flows over unreliable
   transport and is primarily intended for real-time, or streaming,
   media.  This framework can be used to define Content Delivery
   Protocols that provide Forward Error Correction FEC for streaming media delivery or other
   packet flows.  Content Delivery Protocols defined using this
   framework can support any FEC Scheme scheme (and associated FEC codes) which
   is compliant with various requirements defined in this document.
   Thus, Content Delivery Protocols can be defined which are not
   specific to a particular FEC
   Scheme scheme, and FEC Schemes schemes can be defined
   which are not specific to a particular Content Delivery Protocol.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 11, May 24, 2011.

Copyright Notice

   Copyright (c) 2010 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definitions/Abbreviations  . .  Definitions and Abbreviations  . . . . . . . . . . . . . . . .  6
   3.  Architecture Overview  . . . . . . . . . . . . . . . . . . . .  9
   4.  Procedural overview Overview  . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.2.  Sender Operation . . . . . . . . . . . . . . . . . . . . . 15 14
     4.3.  Receiver Operation . . . . . . . . . . . . . . . . . . . . 17
   5.  Protocol Specification . . . . . . . . . . . . . . . . . . . . 21
     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.2.  Structure of the source block Source Block  . . . . . . . . . . . . . . 21
     5.3.  Packet format Format for FEC Source packets Packets . . . . . . . . . . . 21
       5.3.1.  Generic Explicit Source FEC Payload Id ID . . . . . . . . 23
     5.4.  Packet Format for FEC Repair packets Packets . . . . . . . . . . . 23
       5.4.1.  Packet Format for FEC Repair packets Packets over RTP  . . . . 23
     5.5.  FEC Framework Configuration Information  . . . . . . . . . 24
     5.6.  FEC Scheme requirements Requirements  . . . . . . . . . . . . . . . . . 26
   6.  Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   7.  Transport Protocols  . . . . . . . . . . . . . . . . . . . . . 30
   8.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31
     8.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 31
     8.2.  Normative requirements Requirements . . . . . . . . . . . . . . . . . . 32
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 35
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     12.1. Normative references . . . . . . . . . . . . . . . . . . . 36
     12.2. Informative references . . . . . . . . . . . . . . . . . . 36
   Author's Address .
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38

1.  Introduction

   Many applications have a requirement to transport a continuous stream
   of packetized data from a source (sender) to one or more destinations
   (receivers) over networks which do not provide guaranteed packet
   delivery.  Primary examples are real-time, or streaming, media
   applications such as broadcast, multicast or on-demand audio, video
   or multimedia.

   Forward Error Correction (FEC) is a well-known technique for
   improving reliability of packet transmission over networks which do
   not provide guaranteed packet delivery, especially in multicast and
   broadcast applications.  The FEC Building Block defined in [RFC5052]
   provides a framework for definition of Content Delivery Protocols
   (CDPs) for object delivery (including, primarily, file delivery)
   which make use of separately defined FEC Schemes. schemes.  Any CDP defined
   according to the requirements of the FEC Building Block can then
   easily be used with any FEC Scheme scheme which is also defined according to
   the requirements of the FEC Building Block.  (Note

   Note that the term "Forward Erasure Correction" is sometimes used, 'erasures'
   erasures being a type of error in which data is lost and this loss
   can be detected, rather than being received in corrupted form - the form.  The
   focus of this document is strictly on erasures, however erasures and, the term Forward "Forward
   Error Correction Correction" is more widely
   used). used.

   This document defines a framework for the definition of CDPs which
   provide for FEC protection of for arbitrary packet flows over unreliable
   transports such as UDP.  As such, this document complements the FEC
   Building Block of [RFC5052], by providing for the case of arbitrary
   packet flows over unreliable transport, the same kind of framework as
   that document provides for object delivery.  This document does not
   define a complete Content Delivery Protocol, CDP, but rather defines only those aspects that are
   expected to be common to all Content Delivery
   Protocols CDPs based on this framework.

   This framework does not define how the flows to be protected are
   determined, nor how the details of the protected flows and the FEC
   streams which protect them are communicated from sender to receiver.
   It is expected that any complete Content Delivery Protocol CDP specification which makes use of
   this framework will address these
   signalling signaling requirements.  However,
   this document does specify the information which is required by the
   FEC Framework at the sender and
   receiver - for example receiver, e.g., details of the flows
   to be FEC protected, the flow(s) that will carry the FEC protection
   data and an opaque container for FEC-Scheme-specific information. FEC-Scheme-Specific Information.

   FEC Schemes schemes designed for use with this framework must fulfil fulfill a
   number of requirements defined in this document.  Note that these  These requirements
   are different from those defined in [RFC5052] for FEC
   Schemes schemes for
   object delivery.  However  However, there is a great deal of commonality and
   FEC Schemes schemes defined for object delivery may be easily adapted for use
   with the framework defined here. in this document.

   Since the RTP protocol layer is (often) used over UDP, this framework can
   be applied to RTP flows as well.  FEC repair packets may be sent
   directly over UDP or over RTP.  The latter approach has the advantage that
   RTP instrumentation, based on RTCP, RTP Control Protocol (RTCP), can be
   used for the repair flow.  Additionally, the post-repair RTCP
   extended report reports [RFC5725] may be used to obtain information about
   the loss rate after FEC recovery.

   The use of RTP for repair flows is defined for each FEC Scheme scheme by
   defining an RTP Payload Format payload format for that particular FEC Scheme scheme
   (possibly in the same document).

2.  Definitions/Abbreviations

   'ADU Flow'  Definitions and Abbreviations

   Application Data Unit (ADU): The unit of source data provided as
   payload to the transport layer.

   ADU Flow: A sequence of ADUs associated with a transport layer transport-layer flow
   identifier (such as the standard 5-tuple { Source {Source IP Address,
      Source Transport Port, Destination address, source
   port, destination IP Address, Destination
      Transport Port, Transport Protocol } in the case of UDP)

   'AL-FEC'  Application Layer address, destination port, transport protocol}).

   AL-FEC: Application-layer Forward Error Correction

   'Application Data Unit'  The unit of source data provided as payload
      to the transport layer

   'Application protocol' Correction.

   Application Protocol: Control protocol used to establish and control
   the source data flow being protected - e.g. protected, e.g., RTSP.

   'Content

   Content Delivery Protocol (CDP)' (CDP): A complete application protocol
   specification which, through the use of the framework defined in this
   document, is able to make use of FEC Schemes schemes to provide
      Forward Error Correction capabilities

   'FEC'  Forward Error Correction.

   'FEC Code' FEC
   capabilities.

   FEC Code: An algorithm for encoding data such that the encoded data
   flow is resilient to data loss (Note: loss.  Note that in general FEC Codes codes may
   also be used to make a data flow resilient to corruption, but that is
   not considered here).

   'FEC Framework' in this document.

   FEC Framework: A protocol framework for definition of Content
   Delivery Protocols using FEC, such as the framework defined in this
   document.

   'FEC

   FEC Framework Configuration Information' Information: Information which controls
   the operation of the FEC Framework.

   'FEC

   FEC Payload ID' ID: Information which identifies the contents of a packet
   with respect to the FEC Scheme.

   'FEC scheme.

   FEC Repair Packet' Packet: At a sender (respectively, at a receiver) a
   payload submitted to (respectively, received from) the Transport transport
   protocol containing one or more repair symbols along with a Repair
   FEC Payload ID and possibly an RTP header.

   'FEC Scheme'

   FEC Scheme: A specification which defines the additional protocol
   aspects required to use a particular FEC code with the FEC
      Framework, or, in the context of RMT, with the RMT Framework.

   FEC Building
      Block.

   'FEC Source Packet' Packet: At a sender (respectively, at a receiver) a
   payload submitted to (respectively, received from) the Transport transport
   protocol containing an ADU along with an optional Explicit Source FEC
   Payload ID.

   'Protection amount'

   Protection Amount: The relative increase in data sent due to the use
   of FEC.

   'Repair data flow'

   Repair Flow: The packet flow or flows carrying forward error
      correction data

   'Repair FEC data.

   Repair FEC Payload ID' ID: An FEC Payload ID specifically for use with
   repair packets.

   'Source data flow'

   Source Flow: The packet flow or flows to which FEC protection is to be
   applied.  A source data flow consists of ADUs.

   'Source

   Source FEC Payload ID' ID: An FEC Payload ID specifically for use with
   source packets.

   'Source protocol'

   Source Protocol: A protocol used for the source data flow being
      protected - e.g. protected,
   e.g., RTP.

   'Transport protocol'

   Transport Protocol: The protocol used for transport of the source and
   repair data flows - e.g.  UDP, flows, e.g., UDP and DCCP.

   The following definitions are aligned with [RFC5052]

   'Code rate'  the [RFC5052]:

   Code Rate: The ratio between the number of source symbols and the
   number of encoding symbols.  By definition, the code rate is such
      that:
   that 0 < code rate <= 1.  A code rate close to 1 indicates that a
   small number of repair symbols have been produced during the encoding
   process.

   'Encoding symbol'  unit

   Encoding Symbol: Unit of data generated by the encoding process.
   With systematic codes, source symbols are part of the encoding
   symbols.

   'Packet

   Packet Erasure Channel'  a Channel: A communication path where packets are either
   dropped (e.g., by a congested router, or because the number of
   transmission errors exceeds the correction capabilities of the
      physical layer
   physical-layer codes) or received.  When a packet is received, it is
   assumed that this packet is not corrupted.

   'Repair symbol'  encoding

   Repair Symbol: Encoding symbol that is not a source symbol.

   'Source Block'  group

   Source Block: Group of ADUs which are to be FEC protected as a single
   block.

   'Source symbol'  unit

   Source Symbol: Unit of data used during the encoding process.

   'Systematic code'

   Systematic Code: FEC code in which the source symbols are part of the
   encoding symbols.

   The Reed-Solomon codes introduced in this
      document are systematic.

   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.  Architecture Overview

   The FEC Framework is described in terms of an additional layer
   between the transport layer (e.g. (e.g., UDP or DCCP) and protocols running
   over this transport layer.  Examples of such protocols are RTP, RTCP,
   etc.  As such, the data path interface between
   the FEC Framework and both underlying and overlying layers can be
   thought of as being the same as the standard interface to the
   transport layer - i.e. layer, i.e., the data exchanged consists of datagram
   payloads each associated with a single ADU flow identified (in the case of UDP) by the
   standard 5-tuple {
   Source {Source IP Address, Source Transport Port, Destination address, source port, destination IP Address,
   Destination Transport Port, Transport Protocol }.
   address, destination port, transport protocol}.  In the case that RTP
   is used for the repair flows, the source and repair data may can be
   multiplexed using RTP onto a single UDP flow and must consequently needs to be
   consequently demultiplexed at the receiver.  There are various ways
   in which this multiplexing can be done, for example as described in
   [RFC4588].

   It is important to understand that the main purpose of the FEC
   Framework architecture is to allocate functional responsibilities to
   separately documented components in such a way that specific
   instances of the components can be combined in different ways to
   describe different protocols.

   The FEC Framework makes use of an FEC Scheme, scheme, in a similar sense to
   that defined in [RFC5052] and uses the terminology of that document.
   The FEC Scheme scheme defines the FEC encoding and decoding decoding, and defines the
   protocol fields and procedures used to identify packet payload data
   in the context of the FEC Scheme. scheme.  The interface between the FEC
   Framework and an FEC Scheme, scheme, which is described in this document, is
   a logical one, which exists for specification purposes only.  At an
   encoder, the FEC Framework passes ADUs to the FEC Scheme scheme for FEC
   encoding.  The FEC Scheme scheme returns repair symbols with their
   associated Repair FEC Payload IDs, and in some case cases Source FEC
   Payload IDs, depending on the FEC Scheme. scheme.  At a decoder, the FEC
   Framework passes transport packet payloads (source and repair) to the
   FEC Scheme scheme and the FEC Scheme scheme returns additional recovered source
   packet payloads.

   This document defines certain FEC Framework Configuration Information
   which MUST be available to both sender and receiver(s).  For example,
   this information includes the specification of the ADU flows which
   are to be FEC protected, specification of the ADU flow(s) which will
   carry the FEC protection (repair) data and the relationship(s)
   between these source and repair flows (i.e. (i.e., which source flow(s) are
   protected by each repair flow. flow(s)).  The FEC Framework Configuration
   Information also includes information fields which are specific to
   the FEC Scheme. scheme.  This information is analogous to the FEC Object
   Transmission Information defined in [RFC5052].

   The FEC Framework does not define how the FEC Framework Configuration
   Information for the stream is communicated from sender to receiver.
   This must has to be defined by any Content Delivery Protocol CDP specification as described in the
   following sections.

   In this architecture we assume that the interface to the transport
   layer supports the concepts of data units (referred to here as
   Application Data Units) Units (ADUs)) to be transported and identification
   of ADU flows on which those data units are transported.  Since this
   is an interface internal to the architecture, we do not specify this
   interface explicitly.  We do require that ADU flows which are
   distinct from the transport layer point of view (for example,
   distinct UDP flows as identified by the UDP source/destination ports/
   addresses)
   addresses/ports) are also distinct on the interface between the
   transport layer and the FEC Framework.

   As noted above, RTP flows are a specific example of ADU flows which
   might be protected by the FEC Framework.  From the FEC Framework
   point of view, RTP source flows are ADU flows like any other, with
   the RTP header included within the ADU.

   Depending on the FEC Scheme, scheme, RTP may can also be used as a transport for
   repair packet flows.  In this case an FEC Scheme must scheme has to define an RTP
   Payload Format
   payload format for the repair data.

   The architecture outlined above is illustrated in the Figure 1.  In
   this architecture, two (optional) RTP instances are shown, for the
   source and repair data respectively.  This is because the use of RTP
   for the source data is separate from and independent of the use of
   RTP for the repair data.  The appearance of two RTP instances is more
   natural when you consider one considers that in many FEC codes, the repair payload
   contains repair data calculated across the RTP headers of the source
   packets.
   Thus  Thus, a repair packet carried over RTP starts with an RTP
   header of its own which is followed (after the Repair Payload ID) by
   repair data containing bytes which protect the source RTP headers (as
   well as repair data for the source RTP payloads).

     +--------------------------------------------+
     |                 Application                |
     +--------------------------------------------+
                            |
                            |
                            |
   + - - - - - - - - - - - - - - - - - - - - - - - -+
   | +--------------------------------------------+ |
     |            Application Layer               |
   | +--------------------------------------------+ |
                            |                |
   | + -- -- -- -- -- -- -- -- -- -- --+     |      |
     |            RTP (optional) (Optional)       |     |
   | |                                 |     |-Configuration/Coordination     |- Configuration/Coordination
     +- -- -- -- -- -- -- -- -- -- -- -+     |
   |                    |                    |      |
                        | ADU flows          |
   |                    |                    v      |
     +--------------------------------------------+     +----------------+
   | |      FEC Framework (this (This document)         |<--->|   FEC Scheme   |
     +--------------------------------------------+     +----------------+
   |                |               |               |
             Source |        Repair |
   |                |               |               |
     +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
   | | RTP Layer    |     | RTP processing Processing |      | |      |<--- Optional
     | (Optional)   |     +-- -- -- |- -- -+      |       - dependent on
   | |        +-- -- -- -- -- -- -- |--+          | |       FEC Scheme
     |        |  RTP (de)multiplexing (De)multiplexing  |          |
   | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
                            |
   | +--------------------------------------------+ |
     |          Transport Layer (e.g. (e.g., UDP)       |
   | +--------------------------------------------+ |
                            |
   | +--------------------------------------------+ |
     |                     IP                     |
   | +--------------------------------------------+ |

   | Content Delivery Protocol                      |
   + - - - - - - - - - - - - - - -  - - - - - - - - +

                   Figure 1: FEC Framework Architecture architecture

   The contents content of the transport payload for repair packets is fully
   defined by the FEC Scheme. scheme.  For a specific FEC Scheme, scheme, a means MAY be
   defined for repair data to be carried over RTP, in which case the
   repair packet payload format starts with the RTP header.  This
   corresponds to defining an RTP Payload Format payload format for the specific FEC
   Scheme.  Guidelines for writers of RTP Payload Formats are provided
   in [RFC2736].
   scheme.

   The use of RTP for repair packets is independent of the protocols
   used for source packets: if RTP is used for source packets then packets, repair
   packets may or may not use RTP and vice versa (although it is
   unlikely that there are useful scenarios where non-RTP source flows
   are protected by RTP repair flows).  FEC Schemes schemes are expected to
   recover entire transport payloads for recovered source packets in all
   cases.  For example example, if RTP is used for source flows, the FEC Scheme scheme
   is expected to recover the entire UDP payload, including the RTP
   header.

4.  Procedural overview Overview

4.1.  General

   The mechanism defined in this document does not place any
   restrictions on the Application Data Units ADUs which can be protected together, except that
   the Application Data Unit ADU is carried over a supported transport protocol (See
   Section 7).  The data may can be from multiple Source Data Flows source flows that are
   protected jointly.  The FEC
   framework Framework handles the Source Data Flows source flows as a
   sequence of 'source
   blocks' source blocks each consisting of a set of Application Data Units, ADUs, possibly
   from multiple Source Data Flows source flows which are to be protected together.  For
   example, each source block may can be constructed from those
   Application Data Units ADUs related
   to a particular segment in time of the flow.

   At the sender, the FEC Framework passes the payloads for a given
   block to the FEC Scheme scheme for FEC encoding.  The FEC Scheme scheme performs
   the FEC encoding operation and returns the following information:

   o  optionally,  Optionally, FEC Payload IDs for each of the source payloads
      (encoded according to an FEC-Scheme-specific format) FEC-Scheme-Specific format).

   o  one  One or more FEC repair packet payloads payloads.

   o  FEC Payload IDs for each of the repair packet payloads (encoded
      according to an FEC-Scheme-specific format) FEC-Scheme-Specific format).

   The FEC framework Framework then performs two operations: Firstly, operations.  First, it appends
   the Source FEC payload Payload IDs, if provided, to each of the Application Data
   Units, ADUs, and
   sends the resulting packets, known as 'FEC FEC source
   packets', packets, to the receiver
   receiver, and secondly second it places the provided 'FEC FEC repair packet payloads'
   payloads and corresponding 'FEC Repair FEC Payload IDs' IDs appropriately to
   construct 'FEC FEC repair packets' packets and send them to the receiver.  Note that FEC repair packets MAY be sent to a different
   multicast group or groups from the source packets.

   This document does not define how the sender determines which
   Application Data Units ADUs
   are included in which source blocks or the sending order and timing
   of FEC source and FEC repair packets.  A specific Content Delivery Protocol CDP MAY define this
   mapping or it MAY be left as implementation dependent at the sender.
   However, a CDP specification MUST define how a receiver determines a
   minimum length of time that it should needs to wait to receive FEC repair
   packets for any given source block.  FEC Schemes schemes MAY define
   limitations on this mapping, such as maximum size of source blocks,
   but SHOULD NOT attempt to define specific mappings.  The sequence of
   operations at the sender is described in more detail in Section 4.2.

   At the receiver, original Application Data Units ADUs are recovered by the FEC Framework
   directly from any FEC Source Packets source packets received simply by removing the
   Source FEC Payload ID, if present.  The receiver also passes the
   contents of the received Application Data Units, ADUs, plus their FEC Payload IDs to the FEC Scheme
   scheme for possible decoding.

   If any Application Data Units ADUs related to a given source block have been lost, then the
   FEC Scheme may scheme can perform FEC decoding to recover the missing Application Data Units ADUs
   (assuming sufficient FEC Source source and FEC Repair repair packets related to that
   source block have been received).

   Note that the receiver may might need to buffer received source packets
   to allow time for the FEC Repair repair packets to arrive and FEC decoding
   to be performed before some or all of the received or recovered
   packets are passed to the application.  If such a buffer is not
   provided, then the application must has to be able to deal with the severe
   re-ordering of packets that may can occur.  However, such buffering is Content
   Delivery Protocol
   CDP and/or implementation-specific and is not specified here.  The
   receiver operation is described in more detail in Section 4.3 4.3.

   The FEC Source source packets MUST contain information which identifies the
   source block and the position within the source block (in terms
   specific to the FEC Scheme) scheme) occupied by the Application Data Unit. ADU.  This information is
   known as the 'Source Source FEC Payload ID'. ID.  The FEC
   Scheme scheme is responsible
   for defining and interpreting this information.  This information MAY
   be encoded into a specific field within the FEC
   Source source packet format
   defined in this specification, called the Explicit Source FEC Payload
   ID field.  The exact contents and format of the Explicit Source FEC
   Payload ID field are defined by the FEC
   Scheme. schemes.  Alternatively, the
   FEC Scheme scheme MAY define how the Source FEC Payload ID is derived from
   other fields within the source packets.  This document defines the
   way that the Explicit Source FEC Payload ID field is appended to
   source packets to form FEC Source source packets.

   The FEC Repair repair packets MUST contain information which identifies the
   source block and the relationship between the contained repair
   payloads and the original source block.  This is known as the 'Repair Repair
   FEC Payload ID'. ID.  This information MUST be encoded into a specific
   field, the Repair FEC Payload ID field, the contents and format of
   which are defined by the FEC Scheme. schemes.

   The FEC Scheme scheme MAY use different FEC Payload ID field formats for FEC
   Source packets
   source and FEC Repair repair packets.

4.2.  Sender Operation

   It is assumed that the sender has constructed or received original
   data packets for the session.  These may could be RTP, RTCP, MIKEY or
   indeed carrying any other type of packet.
   data.  The following operations, illustrated in Figure 2, for the
   case of UDP repair flows and Figure 3 for the case of RTP repair
   flows, describe a possible way to generate compliant FEC Source packet source and FEC
   repair packet streams: flows:

   1.  Application Data Units  ADUs are provided by the application.

   2.  A source block is constructed as specified in Section 5.2.

   3.  The source block is passed to the FEC Scheme scheme for FEC encoding.
       The Source FEC Payload ID information of each Source source packet is
       determined by the FEC Scheme. scheme.  If required by the FEC Scheme scheme the
       Source FEC Payload ID is encoded into the Explicit Source FEC
       Payload ID field.

   4.  The FEC Scheme scheme performs FEC Encoding, encoding, generating repair packet
       payloads from a source block and a Repair FEC Payload ID field
       for each repair payload.

   5.  The Explicit Source FEC Payload IDs (if used), Repair FEC Payload
       IDs and repair packet payloads are provided back from the FEC Scheme
       scheme to the FEC Framework.

   6.  The FEC Framework constructs FEC Source source packets according to
       Section 5.3 and FEC Repair repair packets according to Section 5.4 using
       the FEC Payload IDs and repair packet payloads provided by the
       FEC
      Scheme. scheme.

   7.  The FEC Source source and FEC Repair repair packets are sent using normal
      transport layer
       transport-layer procedures.  The port(s) and multicast group(s)
       to be used for FEC Repair repair packets are defined in the FEC
       Framework Configuration Information.  The FEC Source source packets are
       sent using the same ADU flow identification information as would
       have been used for the original source packets if the FEC
       Framework were not present (for example, in the UDP case, the UDP
       source and destination addresses and ports on the IP datagram
       carrying the
      Source Packet source packet will be the same whether or not the
       FEC Framework is applied).

   +----------------------+
   |     Application      |
   +----------------------+
              |
            | (1) Application Data Units
              |(1) ADUs
              |
              v
   +----------------------+                           +------------------+
   |    FEC Framework     |                           |                  |
   |                      |-------------------------->|    FEC Scheme    |
   |(2) Construct source  |   (3)  |(3) Source Block           |                  |
   |    blocks            |                           | (4) FEC Encoding |
   |(6) Construct FEC src     |<--------------------------|                  |
   |    packets    source and FEC repair |                           |                  |
   |    repair    packets           |(5) Ex src Explicit Source FEC Payload Ids,|    |                  |
   +----------------------+    Payload IDs            +------------------+
              |                Repair FEC Payload Ids,+------------------+ IDs
              |                Repair symbols
              |
            | (7)
              |(7) FEC Source packets source and FEC repair packets
              v
   +----------------------+
   |   Transport Layer    |
   |     (e.g. UDP )     (e.g., UDP)      |
   +----------------------+

                        Figure 2: Sender operation

   +----------------------+
   |     Application      |
   +----------------------+
              |
              |(1) ADUs
              | (1) Application Data Units
              v
   +----------------------+                           +------------------+
   |    FEC Framework     |                           |                  |
   |                      |-------------------------->|    FEC Scheme    |
   |(2) Construct source  |    (3)  |(3) Source Block           |                  |
   |    blocks            |                           | (4) FEC Encoding |
   |(6) Construct FEC src     |<--------------------------|                  |
   |    source packets and FEC   | and|                           |                  |
   |    repair payloads   |(5) Ex src Explicit Source FEC Payload Ids,|    |                  |
   +----------------------+    Payload IDs            +------------------+
       |             |         Repair FEC Payload Ids,+------------------+ IDs
       |             |         Repair symbols
     |(7) Source
       |             |
       |(7) Source   |(7') Repair RTP payloads
       |    packets  |
       |             |
       |      + -- -- -- -- -+
       |      |     RTP      |
       |      +-- -- -- -- --+
       v             v
   +----------------------+
   |   Transport Layer    |
   |     (e.g. UDP )     (e.g., UDP)      |
   +----------------------+

             Figure 3: Sender operation with RTP repair flows

4.3.  Receiver Operation

   The following describes a possible receiver algorithm, illustrated in
   Figure 4 and Figure 5 for the case of RTP repair flows, when
   receiving an FEC source or repair packet:

   1.  FEC Source Packets source packets and FEC Repair repair packets are received and passed
       to the FEC Framework.  The type of packet (Source (source or
      Repair) repair) and
       the Source Data Flow source flow to which it belongs (in the case of source
       packets) is indicated by the ADU flow information which
       identifies the flow at the transport layer (for example source and
      destination ports and addresses in the case of UDP).

      1a. layer.

       In the special case that RTP is used for repair packets packets, and
       source and repair packets are multiplexed onto the same UDP flow,
       then RTP demultiplexing is required to demultiplex source and
       repair flows.  However, RTP processing is applied only to the
       repair packets at this stage: stage; source packets continue to be
       handled as UDP payloads (i.e. (i.e., including their RTP headers).

   2.  The FEC Framework extracts the Explicit Source FEC Payload ID
       field (if present) from FEC Source Packets the source packets and the Repair FEC
       Payload ID from FEC Repair Packets. the repair packets.

   3.  The Explicit Source FEC Payload IDs (if present), Repair FEC
       Payload IDs, FEC Source payloads source and FEC Repair repair payloads are passed to the FEC Scheme.
       scheme.

   4.  The FEC Scheme scheme uses the received FEC Payload IDs (and derived FEC
       Source Payload IDs in the case that the Explicit Source FEC
       Payload ID field is not used) to group source and repair packets
       into source blocks.  If at least one source packet is missing
       from a source block, and at least one repair packet has been
       received for the same source block then FEC decoding may can be
       performed in order to recover missing source payloads.  The FEC Scheme
       scheme determines whether source packets have been lost and
       whether enough data for decoding of any or all of the missing
       source payloads in the source block has been received.

   5.  The FEC Scheme scheme returns the Application Data Units ADUs to the FEC Framework in the form
       of source blocks containing received and decoded Application Data Units ADUs and
       indications of any Application
      Data Units ADUs which were missing and could not be
       decoded.

   6.  The FEC Framework passes the received and recovered
      Application Data Units ADUs to the
       application.

   Note that the

   The description above defines functionality responsibilities but does
   not imply a specific set of timing relationships.  For example, ADUs may be provided to the application
   as soon as they  Source packets
   which are correctly received or recovered (and hence potentially out-
   of-order) or they may be buffered and those which are reconstructed MAY be
   delivered to the application
   in-order. out of order and in a different order
   from the order of arrival at the receiver.  Alternatively, buffering
   and packet re-ordering MAY be applied to re-order received and
   reconstructed source packets into the order they were placed into the
   source block, if that is necessary according to the application.

   +----------------------+
   |     Application      |
   +----------------------+
              ^
              | (6) Application Data Units
              |(6) ADUs
              |
   +----------------------+                            +------------------+
   |    FEC Framework     |                            |                  |
   |                      |<---------------------------|    FEC Scheme    |
   |(2)Extract FEC Payload| (5) Application Data Units Payload|(5) ADUs                    |                  |
   |   IDs and pass IDs & |                            | (4) FEC Decoding |
   |   Payloads   payloads to FEC    |--------------------------->|                  |
   |   Scheme             | (3) Ex src   scheme             |(3) Explicit Source FEC Payload IDs,|     |                  |
   +----------------------+     FEC Repair    Payload IDs,+------------------+ IDs             +------------------+
              ^                Repair FEC Payload IDs
              |                Source Payloads, payloads
              |                 FEC                Repair Payloads
           | payloads
              | (1)
              |(1) FEC Source packets source and FEC repair packets
              |
   +----------------------+
   |   Transport Layer    |
   |     (e.g. UDP )     (e.g., UDP)      |
   +----------------------+

                       Figure 4: Receiver Operation operation

   +----------------------+
   |     Application      |
   +----------------------+
              ^
              | (6) Application Data Units
              |(6) ADUs
              |
   +----------------------+                            +------------------+
   |    FEC Framework     |                            |                  |
   |                      |<---------------------------|    FEC Scheme    |
   |(2)Extract FEC Payload| (5) Application Data Units Payload|(5) ADUs                    |                  |
   |   IDs and pass IDs & |                            | (4) FEC Decoding |
   |   Payloads   payloads to FEC    |--------------------------->|                  |
   |   Scheme             | (3) Ex src   scheme             |(3) Explicit Source FEC Payload IDs,|     |                  |
   +----------------------+     FEC Repair    Payload IDs,+------------------+ IDs             +------------------+
       ^             ^         Repair FEC Payload IDs
       |             |         Source Payloads, payloads
       |             |          FEC         Repair Payloads
    |Source pkts payloads
       |             |             |(1a) FEC repair
       |Source       |Repair payloads
       |packets      |
       |             |
   +-- |- -- -- -- -- -- -+
   |RTP| | RTP processing Processing |
   |   | +-- -- -- --|-- -+
   | +-- -- -- -- -- |--+ |
   | | RTP demux Demux        | |
   +-- -- -- -- -- -- -- -+
           |  (1)
              ^
              |(1) FEC Source packets source and FEC repair packets
              |
   +----------------------+
   |   Transport Layer    |
   |     (e.g. UDP )     (e.g., UDP)      |
   +----------------------+

            Figure 5: Receiver Operation operation with RTP repair flows

   Note that the above procedure may might result in a situation in which
   not all ADUs are recovered.

   Source packets which are correctly received and those which are
   reconstructed MAY be delivered to the application out of order and in
   a different order from the order of arrival at the receiver.
   Alternatively, buffering and packet re-ordering MAY be applied to re-
   order received and reconstructed source packets into the order they
   were placed into the source block, if that is necessary according to
   the application.

5.  Protocol Specification

5.1.  General

   This section specifies the protocol elements for the FEC Framework.
   Three components of the protocol are defined in this document and are
   described in the following sections:

   1.  Construction of a source block from Application Data Units. ADUs.  The FEC code will be
       applied to this source block to produce the repair payloads.

   2.  A format for packets containing source data.

   3.  A format for packets containing repair data.

   The operation of the FEC Framework is governed by certain FEC
   Framework Configuration Information.  This configuration information Information, which is also defined in this
   section.  A complete protocol specification that uses this framework
   MUST specify the means to determine and communicate this information
   between sender and receiver.

5.2.  Structure of the source block Source Block

   The FEC Framework and FEC Scheme scheme exchange Application Data Units ADUs in the form of source
   blocks.  A source block is generated by the FEC Framework from an
   ordered sequence of Application Data Units. ADUs.  The allocation of Application Data Units ADUs to blocks is
   dependent on the application.  Note that some Application Data Units ADUs may not be
   included in any block.  Each Source Block source block provided to the FEC scheme
   consists of an ordered sequence of Application Data Units ADUs where the following
   information is provided for each ADU:

   o  A description of the Source Data Flow source flow with which the Application
      Data Unit ADU is associated (See 6.5)
      with.

   o  The Application Data Unit itself ADU itself.

   o  The length of the Application Data Unit ADU.

5.3.  Packet format Format for FEC Source packets Packets

   The packet format for FEC Source source packets MUST be used to transport
   the payload of an original source packet.  As depicted in Figure 6,
   it consists of the original packet, optionally followed by the
   Explicit Source FEC Payload ID field.  The FEC Scheme scheme determines
   whether the Explicit Source FEC Payload ID field is required.  This
   determination is specific to each ADU flow.

                   +------------------------------------+
                   |             IP header Header              |
                   +------------------------------------+
                   |          Transport header Header          |
                   +------------------------------------+
                   |        Application Data Unit       |
                   +------------------------------------+
                   |   Explicit Source FEC Payload ID   |
                   +------------------------------------+

    Figure 6: Structure of the FEC packet format for FEC Source source packets

   The FEC Source source packets MUST be sent using the same ADU flow as would
   have been used for the original source packets if the FEC Framework
   were not present.  The transport payload of the FEC Source source packet
   MUST consist of the Application Data Unit ADU followed by the Explicit Source FEC Payload
   ID field, if required.

   The Explicit Source FEC Payload ID field contains information
   required to associate the source packet with a source block and for
   the operation of the FEC algorithm algorithm, and is defined by the FEC Scheme. scheme.
   The format of the Source FEC Payload ID field is defined by the FEC
   Scheme.  Note that in
   scheme.  In the case that the FEC Scheme scheme or CDP defines a means to
   derive the Source FEC Payload ID from other information in the packet
   (for example a sequence number used by the application protocol),
   then the Source FEC Payload ID field is not included in the packet.
   In this case case, the original source packet and FEC Source
   Packet source packet are
   identical.

   In applications where avoidance of IP packet fragmentation is a goal,
   Content Delivery Protocols
   CDPs SHOULD consider the Explicit Source FEC Payload ID size when
   determining the size of Application Data Units ADUs that will be delivered using the FEC
   Framework.  This is because the addition of the Explicit Source FEC
   Payload ID increases the packet length.

   Note:

   The Explicit Source FEC Payload ID is placed at the end of the packet
   so that in the case that Robust Header Compression (ROHC) [RFC3095]
   or other header compression mechanisms are used and in the case that
   a ROHC profile is defined for the protocol carried within the
   transport payload (for example RTP), then ROHC will still be applied
   for the FEC Source source packets.  Applications that may be are used with this
   Framework should
   framework need to consider that FEC Schemes may schemes can add this Explicit
   Source FEC Payload ID and thereby increase the packet size.

   In many applications, support for Forward Error Correction FEC is added to a pre-existing
   protocol and in this case use of the Explicit Source FEC Payload ID may
   can break backwards compatibility, since source packets are modified.

5.3.1.  Generic Explicit Source FEC Payload Id ID

   In order to apply FEC protection using multiple FEC Schemes schemes to a
   single source flow flow, all schemes must have to use the same Explicit Source
   FEC Payload Id ID format.  In order to enable this, it is RECOMMENDED
   that FEC Schemes schemes support the Generic Explicit Source FEC Payload Id ID
   format described below.

   The Generic Explicit Source FEC Payload Id ID has a length of 2 bytes two octets
   and consists of an unsigned packet sequence number in network byte network-byte
   order.  The allocation of sequence numbers to packets is independent
   of any FEC Scheme scheme and of the Source Block source block construction, except that
   the use of this sequence number places a constraint on source block
   construction.  Source packets within a given source block MUST have
   consecutive sequence numbers (where consecutive includes wrap-around
   from the maximum value which can be represented in 2 bytes - 65535 - two octets (65535)
   to 0).  Sequence numbers SHOULD NOT be reused until all values in the
   sequence number space have been used.

5.4.  Packet Format for FEC Repair packets Packets

   The packet format for FEC Repair repair packets is shown in Figure 7.  The
   transport payload consists of a Repair FEC Payload ID field followed
   by repair data generated in the FEC encoding process.

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

                Figure 7: Packet format for repair packets

   The Repair FEC Payload ID field contains information required for the
   operation of the FEC algorithm at the receiver.  This information is
   defined by the FEC Scheme. scheme.  The format of the Repair FEC Payload ID
   field is defined by the FEC Scheme. scheme.

5.4.1.  Packet Format for FEC Repair packets Packets over RTP

   For FEC Schemes schemes which specify the use of RTP for repair packets, the
   packet format for repair packets includes an RTP header as shown in
   Figure 8.

                   +------------------------------------+
                   |             IP header              |
                   +------------------------------------+
                   |      Transport header Header (UDP)        |
                   +------------------------------------+
                   |             RTP Header             |
                   +------------------------------------+
                   |       Repair FEC Payload ID        |
                   +------------------------------------+
                   |          Repair Symbols            |
                   +------------------------------------+

                Figure 8: Packet format for repair packets

5.5.  FEC Framework Configuration Information

   The FEC Framework Configuration Information is information that the
   FEC Framework needs in order to apply FEC protection to the ADU
   flows.  A complete Content Delivery Protocol CDP specification that uses the framework
   specified here MUST include details of how this information is
   derived and communicated between sender and receiver.

   The FEC Framework Configuration Information includes identification
   of the set of Source Data Flows. source flows.  For example, in the case of UDP, each Source Data Flow
   source flow is uniquely identified by a tuple { Source IP
   Address, Destination {Source IP Address, Source address,
   source UDP port, Destination destination IP address, destination UDP
   port }.  Note that in port}.  In
   some applications some of these fields may can contain wildcards, so that
   the flow is identified by a subset of the
   fields and in particular fields.  In particular, in
   many applications the limited tuple {
   Destination {Destination IP Address, Destination address,
   destination UDP port } port} is sufficient.

   A single instance of the FEC Framework provides FEC protection for
   packets of the specified set of Source Data Flows, source flows, by means of one or more
   packet flows consisting of repair packets.  The FEC Framework
   Configuration Information includes, for each instance of the FEC
   Framework:

   1.  Identification of the packet flow(s) carrying FEC Repair
      packets, known as the FEC repair flow(s). flows.

   2.  For each Source Data Flow source flow protected by the FEC repair flow(s):

         a.

       A.  Definition of the Source Data Flow carrying source packets
         (for example, by means of a tuple as described above for UDP).

         b. flow.

       B.  An integer identifier for this Source Data Flow. flow definition (i.e., tuple).
           This identifier MUST be unique amongst all Source Data Flows which source flows that
           are protected by the same FEC repair flow.  Integer
           identifiers can be allocated starting from zero and
           increasing by one for each flow.  However, any random (but
           still unique) allocation is also possible.  A source flow
           identifier need not be carried in source packets since source
           packets are directly associated with a flow by virtue of
           their packet headers.

   3.  The FEC Encoding ID, identifying the FEC Scheme scheme.

   4.  The length of the Explicit Source FEC Payload Id, in bytes ID (in octets).

   5.  Zero or more FEC-Scheme-specific information FEC-Scheme-Specific Information (FSSI) elements,
       each consisting of a name and a value where the valid element
       names and value ranges are defined by the FEC Scheme scheme.

   Multiple instances of the FEC Framework, with separate and
   independent FEC Framework Configuration Information, may can be present
   at a sender or receiver.  A single instance of the FEC Framework
   protects packets of the Source Data Flows source flows identified in (2) above
   i.e. above, i.e.,
   all packets sent on those flows MUST be FEC Source source packets as defined
   in Section 5.3.  A single Source Data Flow may source flow can be protected by multiple
   instances of the FEC Framework.

   The integer flow identifier identified in 2(b) (2b) above is a "shorthand" shorthand
   to identify source flows between the FEC Framework and the FEC Scheme.
   scheme.  The reason for defining this as an integer, and including it
   in the FEC Framework Configuration Information is so that the FEC Scheme
   scheme at the sender and receiver may can use it to identify the source
   flow with which a recovered packet is associated.  The integer flow
   identifier
   may can therefore take the place of the complete flow
   description (e.g. (e.g., UDP 4-tuple).

   Whether and how this flow identifier is used is defined by the FEC
   Scheme.  Since source packets are directly associated with a flow by
   virtue of their packet headers, this identifier need not be carried
   in source packets.
   scheme.  Since repair packets may can provide protection for multiple
   source flows, repair packets would either not carry the identifier at
   all or may can carry multiple identifiers.  However, in any case, the
   flow identifier associated with a particular source packet
   may can be
   recovered from the repair packets as part of an FEC decoding
   operation.  Integer flow identifiers SHOULD be allocated starting
   from zero and increasing by one for each flow.

   A single FEC repair flow provides repair packets for a single
   instance of the FEC Framework.  Other packets MUST NOT be sent within
   this flow i.e. flow, i.e., all packets in the FEC repair flow MUST be FEC
   repair packets as defined in Section 5.4 and MUST relate to the same
   FEC Framework instance.

   In the case that RTP is used for repair packets, the identification
   of identification
   of the repair packet flow can also include the RTP payload type to be
   used for repair packets.

   FSSI includes the information that is specific to the FEC scheme used
   by the CDP.  FSSI is used to communicate the information that cannot
   be adequately represented otherwise and is essential for proper FEC
   encoding and decoding operations.  The motivation behind separating
   the FSSI required only by the sender (which is carried in Sender-Side
   FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of
   the FSSI is to provide the receiver or the third party entities a
   means of controlling the FEC operations at the sender.  Any FSSI
   other than the one solely required by the sender MUST be communicated
   via the FSSI container.

   The variable-length SS-FSSI and FSSI containers transmit the
   information in textual representation and contain zero or more
   distinct elements, whose descriptions are provided by the fully-
   specified FEC schemes.

   For the repair packet flow MAY also include CDPs that choose the RTP Payload Type to be
   used for repair packets.

   FEC Scheme-specific information elements MAY be encoded into a text
   string Session Description Protocol (SDP)
   [RFC4566] as their session description protocol, the ABNF [RFC5234]
   syntax for transport within Content Delivery Protocols.  See the SS-FSSI and FSSI containers is provided in Section 4.5
   of [I-D.ietf-fecframe-sdp-elements] for the ABNF [RFC5234]
   syntax. [I-D.ietf-fecframe-sdp-elements].

5.6.  FEC Scheme requirements Requirements

   In order to be used with this framework, an FEC Scheme scheme MUST be
   capable of processing data arranged into blocks of Application Data
   Units ADUs (source
   blocks).

   A specification for a new FEC scheme MUST include the following
   things: following:

   1.  The FEC Encoding ID value that uniquely identifies the FEC
       scheme.  This value MUST be registered with IANA as described in
       Section 10.

   2.  The type, semantics and encoding format of the Repair FEC Payload
       ID.

   3.  The name, type, semantics and text value encoding rules for zero
       or more FEC Scheme-specific FEC Framework Configuration FEC-Scheme-Specific Information elements.  Names must conform to the "name"
       production and values encodings to the "value" production defined
       in Section 5.5

   4.  A full specification of the FEC code.

       This specification MUST precisely define the valid FEC-Scheme-
       Specific FEC Framework Configuration Information values, the valid FEC Payload ID values and
       the valid packet payload sizes (where packet payload refers to
       the space within a packet dedicated to carrying encoding symbol bytes).
       symbols).

       Furthermore, given a source block as defined in Section 5.2,
       valid values of the FEC-Scheme-Specific FEC Framework
       Configuration Information, a valid
       Repair FEC Payload ID value and a valid packet payload size, the
       specification MUST uniquely define the values of the encoding symbol bytes
       symbols to be included in the repair packet payload of a packet
       with the given Repair FEC Payload ID value.

       A common and simple way to specify the FEC code to the required
       level of detail is to provide a precise specification of an
       encoding algorithm which, given a source block, valid values of
       the FEC-Scheme-Specific FEC Framework Configuration Information, a valid Repair FEC Payload
       ID value and a valid packet payload size as input produces the
       exact value of the encoding symbol
       bytes symbols as output.

   5.  A description of practical encoding and decoding algorithms.

       This description need not be to the same level of detail as for
       the encoding above, however it must has to be sufficient to
       demonstrate that encoding and decoding of the code is both
       possible and practical.

   FEC scheme specifications MAY additionally define the following:

   1.  Type, semantics and encoding format of an Explicit Source FEC
       Payload ID.

   Whenever an FEC scheme specification defines an 'encoding format' for
   an element, this must has to be defined in terms of a sequence of bytes
   which can be embedded within a protocol.  The length of the encoding
   format MUST either be fixed or it must MUST be possible to derive the
   length from examining the encoded bytes themselves.  For example, the
   initial bytes may can include some kind of length indication.

   FEC scheme specifications SHOULD use the terminology defined in this
   document and SHOULD follow the following format:

   1. Introduction  <describe  <Describe the use-cases addressed by this FEC
      scheme>

   2. Formats and Codes

      2.1 Source FEC Payload ID(s)  <Either, define the type and format
         of the Explicit Source FEC Payload ID, or define how Source FEC
         Payload ID information is derived from source packets>

      2.2 Repair FEC Payload Id ID  <Define the type and format of the
         Repair FEC Payload ID>

      2.3 FEC Framework Configuration Information  <Define the names,
         types and text value encoding formats of the FEC Scheme-
         specific FEC Framework configuration information FEC-Scheme-
         Specific Information elements>

   3. Procedures  <describe  <Describe any procedures which are specific to this
      FEC scheme, in particular derivation and interpretation of the
      fields in the FEC Payload ID IDs and FEC Scheme-specific FEC Framework
      configuration information.> FEC-Scheme-Specific Information>

   4. FEC code specification  <provide Code Specification  <Provide a complete specification of the
      FEC Code>

   Specifications MAY can include additional sections, for example, sections including examples.

   Each FEC scheme MUST be specified independently of all other FEC
   schemes; for example, in a separate specification or a completely
   independent section of larger specification (except, of course, a
   specification of one FEC Scheme may scheme can include portions of another by
   reference).  Where an RTP Payload Format is defined for repair data
   for a specific FEC Scheme, scheme, the RTP Payload Format and the FEC Scheme MAY scheme
   can be specified within the same document.

6.  Feedback

   Many applications require some kind of feedback on transport
   performance:
   performance.  E.g., how much data arrived at the receiver, at what rate,
   when etc.
   rate and when?  When FEC is added to such applications, feedback
   mechanisms may can also need to be enhanced to report on the performance
   of the FEC (for example FEC.  E.g., how much lost data was recovered by the FEC). FEC?

   When used to provide instrumentation for engineering purposes, it is
   important to remember that FEC is generally applied to relatively
   small blocks of data (in the sense that each block is transmitted
   over a relatively small period of time) and so time).  Thus, feedback information
   that is averaged over longer periods of time than the FEC block transmission
   time will likely not provide
   sufficient information for engineering purposes.  More detailed
   feedback over shorter time scales might be preferred.  For example example,
   for applications using RTP transport, see [RFC5725].

   Applications which used feedback for congestion control purposes MUST
   calculate such feedback on the basis of packets received before FEC
   recovery is applied.  If this requirement conflicts with other uses
   of the feedback information then the application MUST be enhanced to
   support both information calculated pre- and post- FEC recovery.
   This is to ensure that congestion control mechanisms operate
   correctly based on congestion indications received from the network,
   rather than on post-FEC recovery information which would give an
   inaccurate picture of congestion conditions.

   New applications which require such feedback SHOULD use RTP/RTCP
   [RFC3550].

7.  Transport Protocols

   This framework is intended to be used to define Content Delivery
   Protocols which CDPs that operate
   over transport protocols which provide providing an unreliable datagram service,
   including in particular the User Datagram Protocol (UDP) and the
   Datagram Congestion Control Protocol (DCCP).

8.  Congestion Control

   This section starts with a some informative section background on the
   motivation of the normative requirements for congestion control,
   which are spelled out in Section 8.2.

8.1.

      Informative Note:  Motivation

   o  The enforcement of Congestion Control (CC) congestion control principles has gained a lot
      of momentum in the IETF over the recent years.  While the need of CC for
      congestion control over the open Internet is unquestioned, and the
      goal of TCP friendliness is generally agreed for most (but not
      all) applications, the subject of congestion detection and
      measurement in heterogeneous networks can hardly be considered as
      solved.  Most congestion control algorithms detect and measure
      congestion by taking (primarily or exclusively) the packet loss
      rate into account.  This appears to be inappropriate in
      environments where a large percentage of the packet losses are the
      result of link-layer errors and independent of the network load.  Note that such environments exist in the "open Internet",
      as well as in "closed" IP based networks.  An example for the
      former would be the use of IP/UDP/RTP based streaming from an
      Internet-connected streaming server to a device attached to the
      Internet using cellular technology.

   o  The authors of this draft document are primarily interested in
      applications where the application reliability requirements and
      end-to-end reliability of the network differ, such that it
      warrants higher
      layer higher-layer protection of the packet stream - for example stream, e.g., due
      to the presence of unreliable links in the end-to-end path - and
      where real-time, scalability or other constraints prohibit the use
      of
      higher layer higher-layer (transport or application) feedback.  A typical
      example for such applications is multicast and broadcast streaming
      or multimedia transmission over heterogeneous networks.  In other
      cases, application reliability requirements may can be so high that
      the required end-to-end reliability is will be difficult to achieve even
      over wired networks.  Furthermore achieve.
      Furthermore, the end-to-end network reliability may is not be necessarily
      known in advance.

   o  This FEC framework Framework is not proposed, defined, nor intended, as a QoS
      enhancement tool to combat losses resulting from highly congested
      networks.  It should not be used for such purposes.

   o  In order to prevent such mis-use, one approach would be approach is to leave
      standardisation
      standardization to bodies most concerned with the problem
      described above.  However, the IETF defines base standards used by
      several bodies, including DVB, 3GPP, 3GPP2, all of which appear to
      share the environment and the problem described.

   o  Another approach would be is to write a clear applicability statement
      - for example restricting statement.  For
      example, one could restrict the use of the this framework to networks
      with certain loss characteristics (e.g., wireless links. links).
      However, there may can be applications where the use of FEC may be is
      justified to combat congestion-induced packet losses -
      particularly in lightly loaded networks, where congestion is the
      result of relatively rare random peaks in instantaneous traffic
      load - thereby intentionally violating congestion control
      principles.  One possible example for such an application could be
      a no-matter-what, brute-force FEC protection of a traffic
      generated as an emergency signal.

      We propose a

   o  A third approach, which approach is to require at a minimum that the use of this
      framework with any given application, in any given environment,
      does not cause congestion issues which the application alone would
      not itself cause i.e. cause, i.e., the use of this framework must not make
      things worse.

   o  Taking above considerations into account, Section 8.1 8.2 specifies a
      small set of constraints for the FEC, which are mandatory for all
      senders compliant with this FEC framework. Framework.  Further restrictions
      may
      can be imposed for by certain Content Delivery Protocols.  In this it
      follows the spirit of the congestion control section of RTP and
      its Audio-Visual Profile (RFC3550/STD64 and RFC3551/STD65).

      One CDPs.

8.2.  Normative Requirements

   o  The bandwidth of the constraints effectively limits FEC repair data MUST NOT exceed the bandwidth for of
      the
      FEC original source data being protected packet stream to be no more than roughly twice as
      high as (without the original, non-FEC protected packet stream. possible
      addition of an Explicit Source FEC Payload ID).  This disallows
      the (static or dynamic) use of excessively strong FEC to combat
      high packet loss rates, which may can otherwise be chosen by naively
      implemented dynamic FEC-strength selection mechanisms.  We
      acknowledge that there may be are a few exotic applications, e.g. e.g., IP
      traffic from space-based senders, or senders in certain hardened
      military devices, which would could warrant a higher FEC strength.
      However, in this specification we give preference to the overall
      stability and network friendliness of the average application, and
      for those a factor of 2 appears to be appropriate.

      A second constraint requires that the FEC protected packet stream
      be in compliance with the congestion control in use for the
      application and network in question.

8.1.  Normative requirements

   The bandwidth of FEC Repair packet flows MUST NOT exceed the
   bandwidth of the source packet flows being protected.  In addition,
   whenever applications.

   o  Whenever the source packet flow bandwidth data rate is adapted due to the operation of
      congestion control mechanisms, the FEC repair packet
   flow bandwidth data rate MUST be
      similarly adapted.

9.  Security Considerations

   The application of FEC protection to a stream does not provide any
   kind of security protection.

   If security services are required for the stream, then they MUST
   either be applied to the original source data before FEC protection
   is applied, or to both the source and repair data, after FEC
   protection has been applied.

   If integrity protection is applied to source packets before FEC
   protection is applied, and no further integrity protection is applied
   to repair packets, then a denial of service denial-of-service attack is possible if an
   attacker is in a position to inject fake repair transport payloads.
   If received by a receiver, such fake repair transport payloads could
   cause incorrect FEC decoding resulting in incorrect Application Data
   Units ADUs being passed
   up to the application protocol.  A similar attack
   may be is possible if an
   attacker is in a position to inject fake FEC Framework Configuration
   Information or fake FEC Payload IDs.  Such incorrect decoded Application Data Units ADUs
   would then be detected by the source integrity protection and
   discarded, resulting in partial or complete denial of service.
   Therefore, in such environments, integrity protection MUST also be
   applied to the FEC repair transport payloads, FEC Framework
   Configuration Information and FEC Payload IDs, for example using IPsec
   IPSec to integrity protect all packets.  Receivers MUST also verify
   the integrity of source symbols before including the source symbols
   into the source block for FEC purposes. block.

   It is possible that multiple streams with different confidentiality
   requirements (for example, the streams may be visible to different
   sets of users) can be FEC protected by a single repair stream.  This
   scenario is not recommended, since resources will be used to
   distribute and FEC decode encrypted data which cannot then be
   decrypted by at least some receivers.  However, in this scenario,
   confidentiality protection MUST be applied before FEC encoding of the
   streams, otherwise repair transport payload may be used by a receiver
   to decode unencrypted versions of source streams which they do not
   have permissions to view. access.

10.  IANA Considerations

   FEC Schemes schemes for use with this framework may be are identified in protocols
   using FEC Encoding IDs.  Values of FEC Encoding IDs are subject to
   IANA registration.  They are in the  For this purposes, this document creates a new
   registry named "FEC called FEC Framework (FECFRAME) FEC Encoding IDs" located at time of publication
   at <tbd>. IDs.

   The values that can be assigned within the FEC Framework (FECFRAME)
   FEC Encoding ID registry are numeric indexes in the range [0, 255],
   boundaries included.  Assignment requests are granted on a "IETF
   Consensus" an IETF
   Consensus basis as defined in[RFC5226] . in [RFC5226].  Section 5.6 defines
   explicit requirements that documents defining new FEC Encoding IDs
   should meet.

11.  Acknowledgments

   This document is based in part on [I-D.watson-tsvwg-fec-sf] and so
   thanks are due to the additional authors of that document, Mike Luby,
   Magnus Westerlund and Stephan Wenger.  That document was in turn
   based on the FEC streaming protocol Streaming Protocol defined by 3GPP in [MBMSTS] [MBMSTS], and
   thus
   thus, thanks are also due to the participants in 3GPP TSG SA working
   group Working
   Group 4.  Further thanks are due to the members of the FECFRAME
   working group
   Working Group for their comments and review.

12.  References

12.1.  Normative references

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

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, July 2001.

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

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

12.2.  Informative references

   [I-D.watson-tsvwg-fec-sf]
              Watson, M., "Forward Error Correction (FEC) Streaming
              Framework", draft-watson-tsvwg-fec-sf-00 (work in
              progress), July 2005.

   [RFC5725]  Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
              Report Block Type for RTP Control Protocol (RTCP) Extended
              Reports (XRs)", RFC 5725, February 2010.

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

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

   [RFC2736]  Handley, M. and C. Perkins, "Guidelines for Writers of RTP
              Payload Format Specifications", BCP 36, RFC 2736,
              December 1999.

   [I-D.ietf-fecframe-sdp-elements]
              Begen, A., "Session Description Protocol (SDP) Elements for FEC
              Framework", draft-ietf-fecframe-sdp-elements-08 draft-ietf-fecframe-sdp-elements-11 (work in
              progress), August October 2010.

   [MBMSTS]   3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
              Protocols and codecs", 3GPP TS 26.346, April 2005.

Author's Address

Authors' Addresses

   Mark Watson
   Netflix, Inc.
   100 Winchester Circle
   Los Gatos, CA, CA  95032
   U.S.A.
   USA

   Email: watsonm@netflix.com

   Ali Begen
   Cisco
   181 Bay Street
   Toronto, ON  M5J 2T3
   Canada

   Email: abegen@cisco.com