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

Versions: 00

Transport Area Working Group                                   M. Watson
Internet-Draft                                                   M. Luby
Expires: January 8, 2006                                Digital Fountain
                                                           M. Westerlund
                                                                Ericsson
                                                               S. Wenger
                                                                   Nokia
                                                            July 7, 2005


           Forward Error Correction (FEC) Streaming Framework
                      draft-watson-tsvwg-fec-sf-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 January 8, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines a framework for applying Forward Error
   Correction to UDP flows, primarily intended for streaming media.
   This framework can be used to define Content Delivery Protocols, in
   the context of the RMT FEC Building Block, that provide Forward Error



Watson, et al.           Expires January 8, 2006                [Page 1]

Internet-Draft           FEC Streaming Framework               July 2005


   Correction for streaming media delivery.  Content Delivery Protocols
   defined using this framework can support FEC Schemes (and associated
   FEC codes) compliant with the FEC Building Block.  Thus, Content
   Delivery Protocols can be defined which are not specific to a
   particular FEC Scheme.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definitions/Abbreviations  . . . . . . . . . . . . . . . . . .  5
   3.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  6
   4.  Architecture Overview  . . . . . . . . . . . . . . . . . . . .  7
   5.  Procedural overview  . . . . . . . . . . . . . . . . . . . . .  9
     5.1   General  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2   Sender Operation . . . . . . . . . . . . . . . . . . . . . 11
     5.3   Receiver Operation . . . . . . . . . . . . . . . . . . . . 12
   6.  Protocol Specification . . . . . . . . . . . . . . . . . . . . 13
     6.1   General  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.2   Structure of the source block  . . . . . . . . . . . . . . 13
     6.3   Packet format for FEC Source packets . . . . . . . . . . . 14
     6.4   Packet Format for FEC Repair packets . . . . . . . . . . . 15
     6.5   FEC Streaming Configuration Information  . . . . . . . . . 16
     6.6   FEC Scheme requirements  . . . . . . . . . . . . . . . . . 17
   7.  Session Description Protocol elements  . . . . . . . . . . . . 19
     7.1   udp/fec/<proto> transport protocol identifier  . . . . . . 19
     7.2   udp/fec transport protocol identifier  . . . . . . . . . . 20
     7.3   fec-declaration attribute  . . . . . . . . . . . . . . . . 20
     7.4   fec-oti-extension attribute  . . . . . . . . . . . . . . . 20
     7.5   fec attribute  . . . . . . . . . . . . . . . . . . . . . . 20
     7.6   FEC media grouping semantics . . . . . . . . . . . . . . . 20
     7.7   SDP example  . . . . . . . . . . . . . . . . . . . . . . . 20
   8.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
     8.1   Normative requirements . . . . . . . . . . . . . . . . . . 22
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 25
   11.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 26
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 26
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
       Intellectual Property and Copyright Statements . . . . . . . . 28












Watson, et al.           Expires January 8, 2006                [Page 2]

Internet-Draft           FEC Streaming Framework               July 2005


1.  Introduction

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

   Forward Error Correction 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 [4] provides a
   framework for definition of Content Delivery Protocols (CDPs) which
   make use of separately defined FEC Schemes.  Any CDP defined
   according to the requirements of this building block can then easily
   be used with any FEC Scheme which is also defined according to the
   requirements of the FEC building block (Note that it is also possible
   that CDPs define additional requirements on the FEC Scheme.  Such
   CDPs can clearly only be used with FEC Schemes compliant with those
   requirements.)

   This document defines a framework for the definition of CDPs, in the
   sense of the FEC Building Block, which provide for FEC protection of
   streamed data flows over UDP.  This document does not define a
   complete Content Delivery Protocol, but rather defines only those
   aspects that are expected to be common to all Content Delivery
   Protocols that support streaming data over UDP.

   The framework defined in this document is not specific to a single
   streaming application protocol.  The framework provides FEC
   protection for application protocol flows over UDP and for combined
   protection of multiple such flows.  For example, multiple RTP flows
   may be protected together with the associated RTCP flows and
   potentially also other related flows such as MIKEY packets.  For many
   FEC Schemes in many loss conditions, the improvement in reliability
   achievable through the use of FEC with a given FEC overhead increases
   as the amount of data protected as a single block increases.  Thus
   there is considerable advantage in the ability to protect multiple
   streams together, particularly in cases where the receiver requires
   all the streams in order to offer a useful service to the user.

   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
   specification which makes use of this framework will address these
   signalling requirements.  However, this document does specify the
   information which is required by the FEC Streaming Framework at



Watson, et al.           Expires January 8, 2006                [Page 3]

Internet-Draft           FEC Streaming Framework               July 2005


   sender and receiver - for example details of the flows to be FEC
   protected and the flow(s) that will carry the FEC protection data.
   We also specify SDP [5] attributes which a Content Delivery Protocol
   MAY use to communicate this information.















































Watson, et al.           Expires January 8, 2006                [Page 4]

Internet-Draft           FEC Streaming Framework               July 2005


2.  Definitions/Abbreviations

   Source Block: A logical block of data constructed from some subset of
      the source packets of the application protocol flows to which the
      FEC protection is to be applied.

   FEC: Forward Error Correction.  See [4].

   Symbol: A unit of data processed by the Forward Error Correction
      code.  A symbol is always considered as a unit i.e. it is either
      completely received or completely lost.

   Source symbol: A symbol of a source block.

   Repair symbol: A symbol containing information generated by the FEC
      code from a source block which can be used to recover lost source
      symbols from that source block.

   Encoding symbol: A source symbol or a repair symbol.

   Source Packet Information (SPI): Information related to or from a
      source packet which is included in the source block.

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

   FEC Payload ID: See [4].

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

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

   FEC Object Transmission Information: See [4].

   FEC Encoding ID: See [4].

   Content Delivery Protocol (CDP): See [4].












Watson, et al.           Expires January 8, 2006                [Page 5]

Internet-Draft           FEC Streaming Framework               July 2005


3.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].














































Watson, et al.           Expires January 8, 2006                [Page 6]

Internet-Draft           FEC Streaming Framework               July 2005


4.  Architecture Overview

   The FEC Streaming Framework (FEC-SF) is defined as an additional
   protocol layer between UDP and Application and Transport Protocols
   running over UDP.  Examples of such protocols are RTP, RTCP, etc.  As
   such, the data path interface between the FEC-SF and both underlying
   and overlying layers can be thought of as being the same as the
   standard interface to UDP - i.e. the data exchanged consists of UDP
   datagram payloads each associated with a single UDP flow identified
   by the standard 5-tuple { Source IP Address, Source UDP Port,
   Destination IP Address, Destination UDP Port, Protocol }, where the
   Protocol field value in this case is UDP.

   The FEC-SF makes use of an FEC Scheme, in the sense of [4] and uses
   the terminology of that document.  The FEC Scheme provides FEC
   encoding and decoding and describes the protocol fields used to
   identify packet payload data in the context of the FEC Scheme; i.e.
   it is the FEC Scheme specification, which MUST be defined according
   to [4], which defines the format and interpretation of the FEC
   Payload ID fields which are included in packets to identify the FEC
   source or repair symbol data which are carried by those packets.
   Alternatively, an FEC Scheme may define some other mechanism to
   identify the symbol data contained in a packet, in which case the FEC
   Payload ID fields described in the FEC Building Block and this
   specification may have zero length.

   The FEC Streaming Framework does not define how the FEC Object
   Transmission Information for the stream is communicated from sender
   to receiver.  This must be defined by any Content Delivery Protocol
   specification according to the requirements of the FEC Building
   Block.  However, this specification does define new Session
   Description Protocol (SDP) [5] elements which MAY be used by Content
   Delivery Protocols for this purpose.

   This document defines certain FEC Streaming Configuration Information
   which MUST be available to both sender and receiver(s).  For example,
   this information includes the specification of the UDP flows which
   are to be FEC protected, specification of the UDP flow(s) which will
   carry the FEC protection (repair) data and the relationship(s)
   between these 'source' and 'repair' flows.  The FEC Streaming
   Framework assumes that the Content Delivery Protocol includes
   appropriate signalling to communicate this FEC Streaming
   Configuration Information from sender to receiver(s).  In many cases,
   Content Delivery Protocols may use SDP to communicate information
   about the UDP streams.  This document defines suitable extensions to
   SDP which MAY be used to communicate the FEC Streaming Configuration
   Information from sender to receiver(s).




Watson, et al.           Expires January 8, 2006                [Page 7]

Internet-Draft           FEC Streaming Framework               July 2005


   The architecture outlined above is illustrated in the Figure 1.

   + - - - - - - -- - - - - - - - - - - - - - - - - +
   |                                                |
     +--------------------------------------------+
   | |                                            | |
     |               Application                  |
   | |                                            | |
     +--------------------------------------------+
   | +---------------------------------+     |      |
     |    Application/                 |     |
   | | Transport Protocol (e.g. RTP)   |     |      |
     |                                 |     |-Configuration/Coordination
   | +---------------------------------+     |      |
                        ^                    |
   |                    |  UDP flows         |      |
                        v                    v
   | +--------------------------------------------+ |    +----------------+
     |                                            |      |                |
   | |  FEC Streaming Framework (this document)   |------|   FEC Scheme   |
     |                                            |      |                |
   | +--------------------------------------------+ |    +----------------+
                        ^
   |                    |  UDP flows                |
                        v
   | +--------------------------------------------+ |
     |                                            |
   | |                   UDP                      | |
     |                                            |
     +--------------------------------------------+
   | +--------------------------------------------+ |
     |                                            |
   | |                  IP                        | |
     |                                            |
   | +--------------------------------------------+ |
    Content Delivery Protocol
   + - - - - - - - - - - - - - - -  - - - - - - - - +


              Figure 1: FEC Streaming Framework Architecture











Watson, et al.           Expires January 8, 2006                [Page 8]

Internet-Draft           FEC Streaming Framework               July 2005


5.  Procedural overview

5.1  General

   The mechanism defined in this document consists of three components:

      (i) construction of a 'source block' from source media packets
      belonging to one or several UDP packet flows.  The UDP flows MAY
      include, for example, RTP, RTCP and SRTP packets and also other
      protocols related to the stream such as MIKEY packets.

      (ii) extension of source packets to indicate the source block and
      the position within the source block occupied by the data from an
      related to the source packet.

      (iii) definition of repair packets, sent over UDP, which can be
      used by the FEC decoder to reconstruct missing portions of the
      source block.

   The mechanism does not place any restrictions on the source data
   which can be protected together, except that the source data is
   carried over UDP.  The data may be from several different UDP flows
   that are protected jointly.  In general, multiple source blocks will
   be constructed for a stream each constructed from different sets of
   source packets.  For example, each source block may be constructed
   from those source packets related to a particular segment of the
   stream in time.

   A receiver supporting this streaming framework MUST support the
   packet format for FEC Source packets and MAY also support the packet
   format for FEC Repair packets.

   This document does not define how the sender determines which source
   packets are included in which source blocks.  A specific Content
   Delivery Protocol 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 the length of time it should
   wait to receive FEC repair packets for any given source block.

   At the sender, the mechanism processes original UDP packets to
   create:

      (i) a stored copy of the original packets in the form of one or
      more 'source block(s)'.  The source block is a logical block of
      data to which the the FEC code will subsequently be applied.  It
      is constructed by concatenating 'Source Packet Information' (SPI)
      for each source packet.  The SPI for a packet contains a short
      identifier for the flow the packet belongs to, the length of the



Watson, et al.           Expires January 8, 2006                [Page 9]

Internet-Draft           FEC Streaming Framework               July 2005


      packet, the UDP payload and possible padding bytes.

      (ii) FEC Source packets for transmission to the receiver.

   The FEC Streaming Framework uses the FEC encoder specified by the FEC
   Scheme in use to generate the desired quantity of repair symbols from
   a source block.  These repair symbols are then sent using the FEC
   repair packet format to the receiver.  The FEC Repair packets are
   sent to a UDP destination port different from any of the original UDP
   packets' destination port(s) as indicated by the FEC Streaming
   Configuation Information.

   The receiver recovers original source packets directly from any FEC
   Source packets received.  The receiver also uses the received FEC
   Source Packets to construct a stored copy of the original packets in
   the same source block format as constructed at the sender.

   If any FEC Source packets related to a given source block have been
   lost, then this copy of the source block at the receiver will be
   incomplete.  If sufficient FEC source and FEC Repair packets related
   to that source block have been received, the FEC Framework may use
   the FEC decoding algorithm defined by the FEC Scheme to recover a
   (hopefully, but not necessarily, complete) copy of the source block.
   The SPI for the missing source packets can then be extracted from the
   completed parts of the source block and used to reconstruct the
   source packets to be passed to the application.

   Note that the receiver may need to buffer received source packets to
   allow time for the FEC 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 be able to deal with the severe re-ordering
   of packets that will be required.  However, such buffering is Content
   Delivery Protocol and/or implementation-specific and is not specified
   here.

   The FEC Source packets MUST contain information which identifies the
   source block and the position within the source block occupied by the
   SPI derived from the packet.  The identity of the source block and
   the position within the source block occupied by the SPI for a source
   packet are together known as the 'Source FEC Payload ID'.  This
   information MAY be encoded into a specific field within the FEC
   Source packet format defined in this specification, called the Source
   FEC Payload ID field.  The exact contents and format of the Source
   FEC Payload ID field are defined by the FEC Scheme.  Alternatively,
   the FEC Scheme or CDP MAY define how the Source FEC Payload ID is
   derived from other fields within the source packets.  This document
   defines the way that the Source FEC Payload ID field is appended to



Watson, et al.           Expires January 8, 2006               [Page 10]

Internet-Draft           FEC Streaming Framework               July 2005


   source packets to form FEC Source packets.

   The FEC Repair packets MUST contain information which identifies the
   source block and the relationship between the contained repair data
   and the original source block.  This is known as the 'Repair FEC
   Payload 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.

   Any FEC Schemes to be used in conjunction with this specification
   MUST be a systematic FEC Scheme and MUST be based on source blocks.
   The FEC Scheme MAY use different FEC Payload ID field formats for FEC
   Source packets and FEC Repair packets.

5.2  Sender Operation

   It is assumed that the sender has constructed or received original
   data packets for the session.  These may be RTP, RTCP, MIKEY or other
   UDP packets.  The following operations describe a possible way to
   generate compliant FEC Source packet and FEC repair packet streams:

      1.  A source block is constructed as specified in Section 6.2, by
      concatenating the SPI for each original source packet.  In doing
      so, the Source FEC Payload ID information of the FEC Source packet
      can be determined and included in the Source FEC Payload ID field,
      if defined.  In the SPI the identity of the packet's UDP flow is
      marked using a short 'UDP flow ID', defined in this specification.
      The association of UDP flow specifications to UDP flow IDs is
      defined by the FEC Streaming Configuation Information.

      2.  The FEC Source packet is constructed according to Section 6.3.
      The identity of the original flow is maintained by the source
      packet through the use of the same UDP ports and IP addresses
      which have been advertised by the Content Delivery Protocol (for
      example using SDP), as carrying FEC Source packets generated from
      an original stream of a particular protocol (e.g.  RTP, RTCP,
      SRTP, MIKEY etc.).  The FEC Source packet generated is sent
      according to normal UDP procedures.

      3.  The FEC encoder generates repair symbols from a source block
      and the FEC Streaming Framework places these symbols into FEC
      Repair packets, to be conveyed to the receiver(s).  These repair
      packets are sent using normal UDP procedures to a unique
      destination port to separate them from any of the source packet
      flows.  The ports to be used for FEC Repair packets are defined in
      the FEC Streaming Configuration Information.





Watson, et al.           Expires January 8, 2006               [Page 11]

Internet-Draft           FEC Streaming Framework               July 2005


5.3  Receiver Operation

   The following describes a possible receiver algorithm, when receiving
   an FEC source or repair packet:

      1.  If an FEC Source packet is received (as indicated by the UDP
      flow on which was received):

         a.  The original source packet is reconstructed by removing the
         Source FEC Payload ID.  The resulting packet MAY be buffered to
         allow time for the FEC repair.

         b.  The SPI for the resulting packet is placed into the source
         block according to the Source FEC Payload ID and the source
         block format described in Section 6.2.  The IP addresses and
         UDP ports the packet was received on/sent from are used to
         determine the UDP flow ID within the SPI.

      2.  If an FEC repair packet is received (as indicated by the UDP
      flow on which it was received), the contained repair symbols are
      associated with a source block according to the Repair FEC Payload
      ID.

      3.  If at least one source packet is missing and at least one
      repair packet has been received for a source block then FEC
      decoding may be desirable.  The FEC decoder determines if the
      source block constructed in step 1 plus the associated repair
      symbols received in step 2 contain enough symbols for decoding of
      any or all of the missing source symbols in the source block and,
      if so, performs a decoding operation.

      4.  Any SPI that was reconstructed during the decoding operation
      is then used to reconstruct the missing source packets and these
      are buffered as normal received source packets (see step 1a
      above).

   Note that the above procedure may result in a situation in which not
   all original source packets 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 required 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.





Watson, et al.           Expires January 8, 2006               [Page 12]

Internet-Draft           FEC Streaming Framework               July 2005


6.  Protocol Specification

6.1  General

   This section specifies the protocol elements for the FEC Streaming
   Framework.  The protocol consists of three components which are
   described in the following sections:

      1.  Construction of a source block from source packets.  The FEC
      code will be applied to this source block to produce the repair
      data.

      2.  A format for packets containing source data.

      3.  A format for packets containing repair data.

   The operation of the FEC Streaming Framework is governed by certain
   FEC Streaming Configuation Information.  This configuration
   information 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.  Suitable Session Description Protocol elements for this
   purpose are defined in Section 7.

6.2  Structure of the source block

   This clause defines the layout of the source block.  The source block
   consists of concatenation of SPI for at least one original source UDP
   packet.

   Let

      n be the number of UDP packets in the source block. n MAY be
      determined dynamically during the source block construction
      process.

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

      R[i]      denote the octets of the UDP payload of the i-th UDP packet
      to be added to the source block, 0 <= i < n.

      l[i]      be the length of R[i] in octets

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





Watson, et al.           Expires January 8, 2006               [Page 13]

Internet-Draft           FEC Streaming Framework               July 2005


      f[i]      denote an integer 'UDP flow ID' identifying the UDP flow from
      which the i-th packet was taken

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

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

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

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

   Then, the source block is constructed by concatenating SPI[i] for i =
   0, 2, ... n-1.  The source block size, S, is then given by sum
   {s[i]*T, i=0, ..., n-1}.

   Source blocks are identified by integer Source Block Numbers and
   symbols within a source block by integer Encoding Symbol IDs.  This
   specification does not specify how Source Block Numbers are allocated
   to source blocks.  Symbols are numbered consecutively starting from
   zero within the source block.  Each source packet is associated with
   the Encoding Symbol ID of the first symbol containing SPI for that
   packet.  Thus, the Encoding Symbol ID value associated with the j-th
   source packet, ESI[j], is given by

      ESI[j] = 0, for j=0

      ESI[j] = sum{s[i], i=0,...,(j-1)}, for 0 < j < n

   A UDP flow is uniquely defined by an IP source and destination
   address and UDP source and destination port values.  The assignment
   of UDP flow ID values to UDP flows is part of the FEC Streaming
   Configuration Information.

6.3  Packet format for FEC Source packets

   The packet format for FEC Source packets MUST be used to transport
   the payload of an original source UDP packet.  As depicted in
   Figure 2, it consists of the original UDP packet, followed by the
   Source FEC Payload ID field.









Watson, et al.           Expires January 8, 2006               [Page 14]

Internet-Draft           FEC Streaming Framework               July 2005


   +------------------------------------+
   |             IP header              |
   +------------------------------------+
   |            UDP header              |
   +------------------------------------+
   |       Original UDP Payload         |
   +------------------------------------+
   |       Source FEC Payload ID        |
   +------------------------------------+

    Figure 2: Structure of the FEC packet format for FEC Source packets

   The IP and UDP header fields MUST be identical to those of the
   original source packet.  The Original UDP Payload field MUST be
   identical to the UDP payload of the original source packet.  The UDP
   payload of the FEC Source packet MUST consist of the Original UDP
   Payload followed by the Source FEC Payload ID field.

   The Source FEC Payload ID field contains information required for the
   operation of the FEC algorithm and defined by the FEC Scheme.  The
   format of the Source FEC Payload ID field is defined by the FEC
   Scheme.  Note that in the case that the FEC Scheme or CDP defines a
   means to derive the Source FEC Payload ID from other information in
   the packet (for example the RTP Sequence number), then the Source FEC
   Payload ID field described here may have zero length.

   Note: The Source FEC Payload ID is placed at the end of the packet so
   that in the case that Robust Header Compression [3] or other header
   compression mechanisms are used and in the case that a ROHC profile
   is defined for the protocol carried within the UDP payload (for
   example RTP), then ROHC will still be applied for the FEC Source
   packets.

6.4  Packet Format for FEC Repair packets

   The packet format for FEC Repair packets is shown in Figure 3.  The
   UDP payload consists of a Repair FEC Payload ID field and one or more
   repair symbols generated by the FEC encoding process.













Watson, et al.           Expires January 8, 2006               [Page 15]

Internet-Draft           FEC Streaming Framework               July 2005


   +------------------------------------+
   |             IP header              |
   +------------------------------------+
   |            UDP header              |
   +------------------------------------+
   |       Repair FEC Payload ID        |
   +------------------------------------+
   |          Repair Symbols            |
   +------------------------------------+

                Figure 3: Packet format for repair packets

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

   Any number of whole repair symbols may be contained within an FEC
   Repair packet, subject to packet size restrictions or other
   restrictions defined by the FEC Scheme.  The number of repair symbols
   within a packet can be determined from the symbol length and the
   packet length.  Partial repair symbols MUST NOT be included in FEC
   repair packets.

6.5  FEC Streaming Configuration Information

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

   The FEC Streaming Configuration Information includes identification
   of a number of UDP packet flows.  Each UDP packet flow is uniquely
   identified by a tuple { Source IP Address, Destination IP Address,
   Source UDP port, Destination UDP port }.

   A single instance of the FEC-SF provides FEC protection for all
   packets of a specified set of source UDP packet flows, by means of
   one or more UDP packet flows containing repair packets.  The FEC
   Streaming Configuation Information includes, for each instance of the
   FEC-SF:

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





Watson, et al.           Expires January 8, 2006               [Page 16]

Internet-Draft           FEC Streaming Framework               July 2005


      2.  For each source UDP packet flow protected by the FEC repair
      flow(s):

         a.  Identification of the UDP packet flow carrying source
         packets.

         b.  An integer identifier, between 0 and 255, for this flow.
         This identifier MUST be unique amongst all source UDP packet
         flows which are protected by the same FEC repair flow.

      3.  The FEC Encoding ID, FEC Instance ID (if applicable) and,
      optionally, the symbol size.

   Item (3) above is included in the FEC Object Transmission
   Information.

   Multiple instances of the FEC-SF, with separate and independent FEC
   Streaming Configuration Information, may be present at a sender or
   receiver.  A single instance of the FEC-SF protects all packets of
   all the source UDP packet flows identified in (2) above i.e. all
   packets on those flows MUST be FEC Source packets as defined in
   Section 6.3.  A single source UDP packet flow MUST NOT be protected
   by more than one FEC-SF instance.

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

   The FEC-SF requires to be informed of the symbol size to be used for
   each source block.  This information MAY be included in the FEC
   Streaming Configuration Information or it MAY be communicated by
   other means, for example within the FEC Repair Payload ID field.  A
   complete Content Delivery Protocol specification MUST specify how
   this information is communicated between sender and receiver.

6.6  FEC Scheme requirements

   In order to be used with this framework, an FEC Scheme MUST:

      - adhere to the requirements of [4]

      - be systematic

      - be based on discrete source blocks





Watson, et al.           Expires January 8, 2006               [Page 17]

Internet-Draft           FEC Streaming Framework               July 2005


      - specify how the Source Block Number and Encoding Symbol ID
      associated with a source packet are derived or communicated from
      sender to receiver (for example, within the Source FEC Payload ID
      field)

      - specify how the symbol length is derived or communicated from
      sender to receiver (for example, as part of the FEC Object
      Transmission Information).











































Watson, et al.           Expires January 8, 2006               [Page 18]

Internet-Draft           FEC Streaming Framework               July 2005


7.  Session Description Protocol elements

   This section defines Session Descrption Protocol elements which MAY
   be used by Content Delivery Protocols that make use of this framework
   to communicate the FEC Streaming Configuration Information.

      NOTE: It is for further discussion whether these SDP elements
      should be defined here or in the context of a specific and
      complete Content Delivery Protocol specification for streaming.

   This specification defines a class of new Transport Protocol
   identifiers for use in SDP media descriptions.  For all existing
   identifiers <proto> this specification defines the identifier 'udp/
   fec/<proto>'.  This identifier may be used as the Transport Protocol
   identifier for a media description for source data to indicate that
   the FEC Source packet format defined in Section 6.3 is used, with the
   original UDP payload field formated according to <proto>.

   Note that in the case of an FEC Scheme in which the Source FEC
   Payload ID has zero length, then the original Transport Protocol
   identifier MAY be used to support interoperability with devices which
   do not support the FEC Source packet format at all, whilst also
   providing FEC protection for those devices which support it.

   A further Transport Protocol identifier, 'udp/fec', is defined to
   indicate the the FEC Repair Packet format defined in Section 6.4.

   This specification describes the use of SDP attributes defined in [6]
   and the FEC grouping semantics defined in [7] to provide the FEC
   Streaming Configuration Information.  The 'fec-declaration' attribute
   may be used at either the session or media layer to declare a local
   identifier for a set of FEC parameters.  This local identifier can
   then be referenced in the other attributes.  This avoids duplication
   of parameter declarations within the SDP.  The 'fec' parameter is
   used on the media level to associate a media description with a
   previous FEC parameter declaration.  Finally, the 'FEC' grouping
   attribute semantics is used to associate together source and repair
   flows and assign UDP flow identifiers to be used in the source block
   construction.

   Mechanisms for communicating the corresponance between source flows
   and the UDP Flow Identifiers that are included within the source
   block require further discussion.

7.1  udp/fec/<proto> transport protocol identifier

   tbc




Watson, et al.           Expires January 8, 2006               [Page 19]

Internet-Draft           FEC Streaming Framework               July 2005


7.2  udp/fec transport protocol identifier

   tbc

7.3  fec-declaration attribute

   See [6].

7.4  fec-oti-extension attribute

   See [6].

7.5  fec attribute

   See [6].

7.6  FEC media grouping semantics

   This attribute is used to group source flows and the single repair
   flow that protects them as described in [7] with the following
   additional requirements:

      The media components grouped by an instance of the FEC grouping
      attribute MUST include exactly one component with the udp/fec
      protocol identifier.

      The media components grouped by an instance of the FEC grouping
      attribute MUST include at least one and MAY include more than one
      source media stream with protocol identifier udp/fec/<proto>,
      where <proto> is a valid protocol identifier registered with IANA.

      In the case of an FEC Scheme which defines an FEC Payload ID field
      of zero length, then the media components grouped by an instance
      of the FEC grouping attribite MAY include source media streams
      with protocol identified udp/<proto>, where <proto> is a valid
      protocol identifier registered with IANA.


7.7  SDP example

   tbc










Watson, et al.           Expires January 8, 2006               [Page 20]

Internet-Draft           FEC Streaming Framework               July 2005


8.  Congestion Control

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

      Informative Note: The enforcement of Congestion Control (CC)
      principles has gained a lot of momentum in the IETF over the
      recent years.  While the need of CC 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 heterogenous 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 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.

      The authors of this draft 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 protection of the packet stream - for example due to the
      presence of unreliable links in the end-to-end path - and where
      real-time or other constraints prohibit the use of higher layer
      (transport or application) feedback.  A typical example for such
      applications is multicast and broadcast streaming to wireless
      devices or multimedia transmission over heterogenous, but partly
      wireless networks.  In other cases, application reliability
      requirements may be so high that the required end-to-end
      reliability is difficult to achieve even over wired networks.
      Furthermore the end-to-end network reliability may not be known in
      advance.

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

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




Watson, et al.           Expires January 8, 2006               [Page 21]

Internet-Draft           FEC Streaming Framework               July 2005


      Alternatively, a clear applicability statement could be used - for
      example restricting use of the framework to networks with wireless
      links.  However, there may be applications where the use of FEC
      may be 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 traffic generated
      as an emergency signal.

      We propose a third approach, which 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. the use of this
      framework must not make things worse.

      Taking above considerations into account, the normative text of
      this section implements a small set of constraints for the FEC,
      which are mandatory for all senders compliant with this FEC
      framework.  Further restrictions may be imposed for 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 of the constraints effectively limits the bandwidth for the
      FEC protected packet stream to be no more than roughly twice as
      high as the original, non-FEC protected packet stream.  This
      disallows the (static or dynamic) use of excessively strong FEC to
      combat high packet loss rates, which may otherwise be chosen by
      naively implemented dynamic FEC-strength selection mechanisms.  We
      acknowledge that there may be a few exotic applications, e.g.  IP
      traffic from space-based senders, or senders in certain hardened
      military devices, which would 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 the source packet flow bandwidth is adapted due to the



Watson, et al.           Expires January 8, 2006               [Page 22]

Internet-Draft           FEC Streaming Framework               July 2005


   operation of congestion control mechanisms, the FEC repair packet
   flow bandwidth MUST be similarly adapted.

















































Watson, et al.           Expires January 8, 2006               [Page 23]

Internet-Draft           FEC Streaming Framework               July 2005


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 attack is possible if an
   attacker is in a position to inject fake repair packets.  If received
   by a receiver, such fake repair packets could cause incorrect FEC
   decoding resulting in incorrect source packets being passed up to the
   application protocol.  Such incorrect packets 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 packets, for example using IPsec.  Receivers MUST also verify
   the integrity of source packets before including the source data into
   the source block for FEC purposes.

   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 decode 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 data may be used by a receiver to decode unencrypted
   versions of source streams which they do not have permissionions to
   view.

















Watson, et al.           Expires January 8, 2006               [Page 24]

Internet-Draft           FEC Streaming Framework               July 2005


10.  IANA Considerations

   tbc
















































Watson, et al.           Expires January 8, 2006               [Page 25]

Internet-Draft           FEC Streaming Framework               July 2005


11.  Acknowledgments

   This framework is based in large part on the FEC streaming protocol
   defined by 3GPP in [8] and thus thanks are due to the participants in
   3GPP TSG SA working group 4.

12.  References

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

   [2]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

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

   [4]  Watson, M., "Forward Error Correction (FEC) Building Block",
        draft-ietf-rmt-fec-bb-revised-00 (work in progress), May 2005.

   [5]  Handley, M., "SDP: Session Description Protocol",
        draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005.

   [6]  Mehta, H., "SDP Descriptors for FLUTE",
        draft-mehta-rmt-flute-sdp-03 (work in progress), July 2005.

   [7]  Li, A., "FEC Grouping Semantics in SDP",
        draft-li-mmusic-fec-grouping-00 (work in progress), June 2005.

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


Authors' Addresses

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

   Email: mark@digitalfountain.com




Watson, et al.           Expires January 8, 2006               [Page 26]

Internet-Draft           FEC Streaming Framework               July 2005


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

   Email: luby@digitalfountain.com


   Magnus Westerlund
   Ericsson
   Ericsson Research
   SE-164 80 Stockholm
   SWEDEN

   Email: magnus.westerlund@ericsson.com


   Stephan Wenger
   Nokia

   Email: Stephan.Wenger@nokia.com




























Watson, et al.           Expires January 8, 2006               [Page 27]

Internet-Draft           FEC Streaming Framework               July 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Watson, et al.           Expires January 8, 2006               [Page 28]


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