draft-ietf-fecframe-framework-00.txt   draft-ietf-fecframe-framework-01.txt 
FEC Framework Working Group M. Watson FEC Framework Working Group M. Watson
Internet-Draft Digital Fountain Internet-Draft Digital Fountain
Intended status: Standards Track February 21, 2007 Intended status: Standards Track November 16, 2007
Expires: August 25, 2007 Expires: May 19, 2008
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-00 draft-ietf-fecframe-framework-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2007. This Internet-Draft will expire on May 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes for a framework for using forward error This document describes for a framework for using forward error
correction (FEC) codes with applications in the Internet to provide correction (FEC) codes with applications in public and private IP
protection against packet loss. The framework supports applying networks to provide protection against packet loss. The framework
Forward Error Correction to arbitrary packet flows and is primarily supports applying Forward Error Correction to arbitrary packet flows
intended for streaming media. This framework can be used to define over unreliable transport and is primarily intended for real-time, or
Content Delivery Protocols that provide Forward Error Correction for streaming, media. This framework can be used to define Content
Delivery Protocols that provide Forward Error Correction for
streaming media delivery or other packet flows. Content Delivery streaming media delivery or other packet flows. Content Delivery
Protocols defined using this framework can support any FEC Scheme Protocols defined using this framework can support any FEC Scheme
(and associated FEC codes) which is compliant with various (and associated FEC codes) which is compliant with various
requirements defined in this document. Thus, Content Delivery requirements defined in this document. Thus, Content Delivery
Protocols can be defined which are not specific to a particular FEC Protocols can be defined which are not specific to a particular FEC
Scheme and FEC Schemes can be defined which are not specific to a Scheme and FEC Schemes can be defined which are not specific to a
particular Content Delivery Protocol. particular Content Delivery Protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 5 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 8
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 8 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9
5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 10 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 12
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 11 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 13
5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 12 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 15
6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 14 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 18
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Structure of the source block . . . . . . . . . . . . . . 14 6.2. Structure of the source block . . . . . . . . . . . . . . 18
6.3. Packet format for FEC Source packets . . . . . . . . . . . 14 6.3. Packet format for FEC Source packets . . . . . . . . . . . 18
6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 15 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 20
6.5. FEC Framework Configuration Information . . . . . . . . . 16 6.5. FEC Framework Configuration Information . . . . . . . . . 20
6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 17 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 22
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 18 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 25
8. Session Description Protocol elements . . . . . . . . . . . . 19 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 26
8.1. udp/fec/<proto> transport protocol identifier . . . . . . 19 8.1. Normative requirements . . . . . . . . . . . . . . . . . . 27
8.2. udp/fec transport protocol identifier . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8.3. fec-declaration attribute . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.4. fec-oti-extension attribute . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8.5. fec attribute . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.6. FEC media grouping semantics . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.7. SDP example . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 34
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative requirements . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
Many applications have a requirement to transport a continuous stream Many applications have a requirement to transport a continuous stream
of packetised data from a source (sender) to one or more destinations of packetised data from a source (sender) to one or more destinations
(receivers) over networks which do not provide guaranteed packet (receivers) over networks which do not provide guaranteed packet
delivery. Primary examples are media streaming applications such as delivery. Primary examples are real-time, or streaming, media
broadcast, multicast or on-demand audio, video or multi-media. applications such as broadcast, multicast or on-demand audio, video
or multimedia.
Forward Error Correction is a well-known technique for improving Forward Error Correction is a well-known technique for improving
reliability of packet transmission over networks which do not provide reliability of packet transmission over networks which do not provide
guaranteed packet delivery, especially in multicast and broadcast guaranteed packet delivery, especially in multicast and broadcast
applications. The FEC Building Block defined in [4] provides a applications. The FEC Building Block defined in [3] provides a
framework for definition of Content Delivery Protocols (CDPs) for framework for definition of Content Delivery Protocols (CDPs) for
object delivery (including, primarily, file delivery) which make use object delivery (including, primarily, file delivery) which make use
of separately defined FEC Schemes. Any CDP defined according to the of separately defined FEC Schemes. Any CDP defined according to the
requirements of the FEC Building Block can then easily be used with requirements of the FEC Building Block can then easily be used with
any FEC Scheme which is also defined according to the requirements of any FEC Scheme which is also defined according to the requirements of
the FEC Building Block. the FEC Building Block. (Note that the term "Forward Erasure
Correction" is sometimes used, '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 focus of this document is strictly
on erasures, however the term Forward Error Correction is more widely
used).
This document defines a framework for the definition of CDPs which This document defines a framework for the definition of CDPs which
provide for FEC protection of arbitrary packet flows over unreliable provide for FEC protection of arbitrary packet flows over unreliable
transports such as UDP. This document does not define a complete transports such as UDP. As such, this document complements the FEC
Content Delivery Protocol, but rather defines only those aspects that Building Block of [3], by providing for the case of arbitrary packet
are expected to be common to all such Content Delivery Protocols. 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, but rather defines only those
aspects that are expected to be common to all Content Delivery
Protocols based on this framework.
This framework does not define how the flows to be protected are This framework does not define how the flows to be protected are
determined, nor how the details of the protected flows and the FEC determined, nor how the details of the protected flows and the FEC
streams which protect them are communicated from sender to receiver. streams which protect them are communicated from sender to receiver.
It is expected that any complete Content Delivery Protocol It is expected that any complete Content Delivery Protocol
specification which makes use of this framework will address these specification which makes use of this framework will address these
signalling requirements. However, this document does specify the signalling requirements. However, this document does specify the
information which is required by the FEC Framework at the sender and information which is required by the FEC Framework at the sender and
receiver - for example details of the flows to be FEC protected, the receiver - for example details of the flows to be FEC protected, the
flow(s) that will carry the FEC protection data and an opaque flow(s) that will carry the FEC protection data and an opaque
container for FEC-Scheme-specific information. We also specify SDP container for FEC-Scheme-specific information.
[5] attributes which a Content Delivery Protocol MAY use to
communicate this information.
FEC Schemes designed for use with this framework must fulfil a number FEC Schemes designed for use with this framework must fulfil a number
of requirements defined in this document. Note that these of requirements defined in this document. Note that these
requirements are different from those defined in [4] for FEC Schemes requirements are different from those defined in [3] for FEC Schemes
for object delivery. However there is a great deal of commonality for object delivery. However there is a great deal of commonality
and FEC Schemes defined for object delivery may be easily adapted for and FEC Schemes defined for object delivery may be easily adapted for
use with the framework defined here. use with the framework defined here.
2. Definitions/Abbreviations 2. Definitions/Abbreviations
'FEC' Forward Erasure Correction. 'FEC' Forward Error Correction.
'AL-FEC' Application Layer Forward Erasure Correction 'AL-FEC' Application Layer Forward Error Correction
'FEC Framework' A protocol framework for definition of Content 'FEC Framework' A protocol framework for definition of Content
Delivery Protocols using FEC, such as the framework defined in Delivery Protocols using FEC, such as the framework defined in
this document. this document.
'Source data flow' The packet flow or flows to which FEC protection 'Source data flow' The packet flow or flows to which FEC protection
is to be applied. is to be applied.
'Repair data flow' The packet flow or flows carrying forward error 'Repair data flow' The packet flow or flows carrying forward error
correction data correction data
'Source protocol' A protocol used for the source data flow being 'Source protocol' A protocol used for the source data flow being
protected - e.g. RTP. protected - e.g. RTP.
'Transport protocol' The protocol used for transport of the source 'Transport protocol' The protocol used for transport of the source
data flow being protected - e.g. UDP, DCCP. data flow being protected - e.g. UDP, DCCP.
'Transport payload' Data used as the payload for the transport layer
(e.g. UDP or DCCP packet payload)
'Application protocol' Control protocols used to establish and 'Application protocol' Control protocols used to establish and
control the source data flow being protected - e.g. RTSP. control the source data flow being protected - e.g. RTSP.
'FEC Code' An algorithm for encoding data such that the encoded data 'FEC Code' An algorithm for encoding data such that the encoded data
flow is resiliant to data loss or corruption. flow is resiliant to data loss or corruption.
'FEC Scheme' A specification which defines the additional protocol 'FEC Scheme' A specification which defines the additional protocol
aspects required to use a particular FEC code with the FEC aspects required to use a particular FEC code with the FEC
framework, or (in the context of RMT), with the RMT FEC Building Framework, or (in the context of RMT), with the RMT FEC Building
Block. Block.
'Source Block' the group of source data packets which are to be FEC 'Source Block' the group of source data packets which are to be FEC
protected as a single block protected as a single block
'Protection amount' The relative increase in data sent due to the 'Protection amount' The relative increase in data sent due to the
use of FEC. use of FEC.
FEC Framework Configuration Information: Information which controls FEC Framework Configuration Information: Information which controls
the operation of the FEC Framework. the operation of the FEC Framework.
FEC Payload ID: Information which identifies the contents of a FEC Payload ID: Information which identifies the contents of a
packet with respect to the FEC Scheme. packet with respect to the FEC Scheme.
Source FEC Payload ID: An FEC Payload ID specifically for use with Source FEC Payload ID: An FEC Payload ID specifically for use with
source packets. source packets.
Repair FEC Payload ID: An FEC Payload ID specifically for use with Repair FEC Payload ID: An FEC Payload ID specifically for use with
repair packets. repair packets.
Content Delivery Protocol (CDP): See [4]. Content Delivery Protocol (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 to provide
Forward Error Correction capabilities.
3. Requirements notation 3. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
4. Architecture Overview 4. Architecture Overview
The FEC Framework is described in terms of an additional protocol The FEC Framework is described in terms of an additional protocol
skipping to change at page 8, line 20 skipping to change at page 9, line 20
of such protocols are RTP, RTCP, etc. As such, the data path of such protocols are RTP, RTCP, etc. As such, the data path
interface between the FEC Framework and both underlying and overlying interface between the FEC Framework and both underlying and overlying
layers can be thought of as being the same as the standard interface layers can be thought of as being the same as the standard interface
to the transport layer - i.e. the data exchanged consists of datagram to the transport layer - i.e. the data exchanged consists of datagram
payloads each associated with a single transport flow identified by payloads each associated with a single transport flow identified by
the standard 5-tuple { Source IP Address, Source Transport Port, the standard 5-tuple { Source IP Address, Source Transport Port,
Destination IP Address, Destination Transport Port, Transport Destination IP Address, Destination Transport Port, Transport
Protocol }. Protocol }.
The FEC Framework makes use of an FEC Scheme, in a similar sense to The FEC Framework makes use of an FEC Scheme, in a similar sense to
that defined in [4] and uses the terminology of that document. The that defined in [3] and uses the terminology of that document. The
FEC Scheme provides FEC encoding and decoding and describes the FEC Scheme provides FEC encoding and decoding and describes the
protocol fields and or procedures used to identify packet payload protocol fields and or procedures used to identify packet payload
data in the context of the FEC Scheme. The interface between the FEC data in the context of the FEC Scheme. The interface between the FEC
Framework and an FEC Scheme, which is described in this document, is Framework and an FEC Scheme, which is described in this document, is
a logical one, which exists for specification purposes only. At an a logical one, which exists for specification purposes only. At an
encoder, the FEC Framework passes groups of transport packet payloads encoder, the FEC Framework passes groups of transport packet payloads
to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC
repair packet payloads, encoded FEC Payload ID information for each repair packet payloads, encoded FEC Payload ID information for each
of the repair packets and, in some cases, encoded FEC Payload ID of the repair packets and, in some cases, encoded FEC Payload ID
information for each of the source packets. At a decoder, the FEC information for each of the source packets. At a decoder, the FEC
skipping to change at page 8, line 44 skipping to change at page 9, line 44
This document defines certain FEC Framework Configuration Information This document defines certain FEC Framework Configuration Information
which MUST be available to both sender and receiver(s). For example, which MUST be available to both sender and receiver(s). For example,
this information includes the specification of the transport flows this information includes the specification of the transport flows
which are to be FEC protected, specification of the transport flow(s) which are to be FEC protected, specification of the transport flow(s)
which will carry the FEC protection (repair) data and the which will carry the FEC protection (repair) data and the
relationship(s) between these 'source' and 'repair' flows (i.e. which relationship(s) between these 'source' and 'repair' flows (i.e. which
source flow(s) are protected by each repair flow. The FEC Framework source flow(s) are protected by each repair flow. The FEC Framework
Configuration Information also includes information fields which are Configuration Information also includes information fields which are
specific to the FEC Scheme. This information is analagous to the FEC specific to the FEC Scheme. This information is analagous to the FEC
Object Transmission Information defined in [4]. Object Transmission Information defined in [3].
The FEC Framework does not define how the FEC Framework Configuration The FEC Framework does not define how the FEC Framework Configuration
Information for the stream is communicated from sender to receiver. Information for the stream is communicated from sender to receiver.
This must be defined by any Content Delivery Protocol specification This must be defined by any Content Delivery Protocol specification
as described below. However, this specification does define new as described in the following sections.
Session Description Protocol (SDP) [5] elements which MAY be used by
Content Delivery Protocols for this purpose. In this architecture we assume that the interface to the transport
layer supports the concepts of payloads to be transported and
identification transport flows on which those payloads are
transported. Since this is an interface internal to the
architecture, we do not specify this interface explicitly, except to
say that transport 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) are also distinct on the
interface between the transport layer and the FEC Framework.
The architecture outlined above is illustrated in the Figure 1. The architecture outlined above is illustrated in the Figure 1.
+--------------------------------------------+
| |
| Application |
| |
+--------------------------------------------+
^
|
v
+ - - - - - - -- - - - - - - - - - - - - - - - - + + - - - - - - -- - - - - - - - - - - - - - - - - +
| | | |
+--------------------------------------------+ +--------------------------------------------+
| | | | | | | |
| Application | | Application Layer |
| | | | | | | |
+--------------------------------------------+ +--------------------------------------------+
| +---------------------------------+ | | | +---------------------------------+ | |
| | | | | |
| | Application Protocol (e.g. RTP) | | | | | Application/Transport Protocol | | |
| | |-Configuration/Coordination | (e.g. RTP) | |-Configuration/Coordination
| +---------------------------------+ | | | +---------------------------------+ | |
^ | ^ |
| | Transport flows | | | | Transport flows | |
v v v v
| +--------------------------------------------+ | +----------------+ | +--------------------------------------------+ | +----------------+
| | | | | | | |
| | FEC Framework (this document) |------| FEC Scheme | | | FEC Framework (this document) |------| FEC Scheme |
| | | | | | | |
| +--------------------------------------------+ | +----------------+ | +--------------------------------------------+ | +----------------+
^ ^
skipping to change at page 10, line 10 skipping to change at page 12, line 10
Content Delivery Protocol Content Delivery Protocol
+ - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework Architecture Figure 1: FEC Framework Architecture
5. Procedural overview 5. Procedural overview
5.1. General 5.1. General
The mechanism defined in this document does not place any The mechanism defined in this document does not place any
restrictions on the source data which can be protected together, restrictions on the source transport payloads which can be protected
except that the source data is carried over a supported transport together, except that the source transport payload is carried over a
protocol. The data may be from several different transport flows supported transport protocol (See Section 7). The data may be from
that are protected jointly. The FEC framework handles the packet multiple transport flows that are protected jointly. The FEC
flows as a sequence of 'source blocks' each consisting of a set of framework handles the packet flows as a sequence of 'source blocks'
source packets, possibly from multiple flows which are to be each consisting of a set of source transport payloads, possibly from
protected together. For example, each source block may be multiple flows which are to be protected together. For example, each
constructed from those source packets related to a particular segment source block may be constructed from those source transport payloads
in time of the flow. related to a particular segment in time of the flow.
At the sender, the FEC Framework passes the packet payloads for all At the sender, the FEC Framework passes the payloads for a given
packets of a given block to the FEC Scheme for FEC encoding. The FEC block to the FEC Scheme for FEC encoding. The FEC Scheme performs
Scheme performs the FEC encoding operation and returns the following the FEC encoding operation and returns the following information:
information:
o optionally, encoded FEC Payload IDs for each of the source packets o optionally, encoded FEC Payload IDs for each of the source
payloads
o one or more FEC repair packet payloads o one or more FEC repair packet payloads
o encoded FEC Payload IDs for each of the repair packets o encoded FEC Payload IDs for each of the repair packet payloads
The FEC Framework then appends the FEC Payload IDs, if provided, to The FEC framework then performs two operations: Firstly, it appends
each of the source packets and sends the resulting packets, known as the FEC payload IDs, if provided, to each of the source transport
FEC SOurce Packets, to the receiver. The FEC repair packets are then payloads, and sends the resulting packets, known as 'FEC source
constructed from the provided repair data and FEC Payload IDs and packets', to the receiver and secondly it places the provided 'FEC
sent to the receiver. FEC repair packets are sent to a different repair packet payloads' and corresponding 'FEC Repair Payload IDs'
transport port than the source packets, as specified by the FEC appropriately to construct 'FEC repair packets' and send them to the
Configuration Information. In the case of multicast, FEC repair receiver. Note that FEC repair packets MAY be sent to a different
packets MAY be sent to a different multicast group or groups from the multicast group or groups from the source packets.
source packets.
This document does not define how the sender determines which source This document does not define how the sender determines which source
packets are included in which source blocks. A specific Content transport payloads are included in which source blocks or the sending
Delivery Protocol MAY define this mapping or it MAY be left as order and timing of FEC source and FEC repair packets. A specific
implementation dependent at the sender. However, a CDP specification Content Delivery Protocol MAY define this mapping or it MAY be left
MUST define how a receiver determines the length of time it should as implementation dependent at the sender. However, a CDP
wait to receive FEC repair packets for any given source block. specification MUST define how a receiver determines the length of
time it should wait to receive FEC repair packets for any given
source block. The sequence of operations at the sender is described
in more detail in Section 5.2.
The receiver recovers original source packets directly from any FEC At the receiver, original source transport payloads are recovered by
Source packets received simply by removing the FEC Payload ID, if the FEC Framework directly from any FEC Source packets received
present. The receiver also passes the contents of the received FEC simply by removing the Source FEC Payload ID, if present. The
Source Packets, including their FEC Payload IDs to the FEC Scheme for receiver also passes the contents of the received FEC Source
decoding. transport payloads, plus their FEC Payload IDs to the FEC Scheme for
possible decoding.
If any FEC Source packets related to a given source block have been If any FEC source transport payloads related to a given source block
lost, then the FEC Scheme may perform FEC decoding to recover the have been lost, then the FEC Scheme may perform FEC decoding to
missing source packets (assuming sufficient FEC Source and FEC Repair recover the missing source transport payloads (assuming sufficient
packets related to that source block have been received). FEC Source and FEC Repair packets related to that source block have
been received).
Note that the receiver may need to buffer received source packets to 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 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 be performed before some or all of the received or recovered packets
are passed to the application. If such a buffer is not provided, 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 then the application must be able to deal with the severe re-ordering
of packets that will be required. However, such buffering is Content of packets that will be required. However, such buffering is Content
Delivery Protocol and/or implementation-specific and is not specified Delivery Protocol and/or implementation-specific and is not specified
here. here. The receiver operation is described in more detail in
Section 5.3
The FEC Source packets MUST contain information which identifies the The FEC Source packets MUST contain information which identifies the
source block and the position within the source block occupied by the source block and the position within the source block (in terms
packet. The identity of the source block and the position within the specific to the FEC Scheme) occupied by the packet. This information
source block of a source packet are together known as the 'Source FEC is known as the 'Source FEC Payload ID'. The FEC Scheme is
Payload ID'. The FEC Scheme is responsible for defining and responsible for defining and interpreting this information. This
interpreting this information. This information MAY be encoded into information MAY be encoded into a specific field within the FEC
a specific field within the FEC Source packet format defined in this Source packet format defined in this specification, called the
specification, called the encoded Source FEC Payload ID field. The Explicit Source FEC Payload ID field. The exact contents and format
exact contents and format of the encoded Source FEC Payload ID field of the Explicit Source FEC Payload ID field are defined by the FEC
are defined by the FEC Scheme. Alternatively, the FEC Scheme or CDP Scheme. Alternatively, the FEC Scheme MAY define how the Source FEC
MAY define how the Source FEC Payload ID is derived from other fields Payload ID is derived from other fields within the source packets.
within the source packets. This document defines the way that the This document defines the way that the Explicit Source FEC Payload ID
Source FEC Payload ID field is appended to source packets to form FEC field is appended to source packets to form FEC Source packets.
Source packets.
The FEC Repair packets MUST contain information which identifies the The FEC Repair packets MUST contain information which identifies the
source block and the relationship between the contained repair data source block and the relationship between the contained repair
and the original source block. This is known as the 'Repair FEC payloads and the original source block. This is known as the 'Repair
Payload ID'. This information MUST be encoded into a specific field, FEC Payload ID'. This information MUST be encoded into a specific
the Repair FEC Payload ID field, the contents and format of which are field, the Repair FEC Payload ID field, the contents and format of
defined by the FEC Scheme. which are defined by the FEC Scheme.
Any FEC Schemes to be used in conjunction with this specification The FEC Scheme MAY use different FEC Payload ID field formats for FEC
MUST be a systematic FEC Scheme. The FEC Scheme MAY use different Source packets and FEC Repair packets.
encoded FEC Payload ID field formats for FEC Source packets and FEC
Repair packets.
5.2. Sender Operation 5.2. Sender Operation
It is assumed that the sender has constructed or received original It is assumed that the sender has constructed or received original
data packets for the session. These may be RTP, RTCP, MIKEY or other data packets for the session. These may be RTP, RTCP, MIKEY or
UDP packets. The following operations describe a possible way to indeed any other type of packet. The following operations,
generate compliant FEC Source packet and FEC repair packet streams: illustrated in Figure 2 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. 1. Source transport payloads are provided by the application.
2. The source block is passed to the FEC Scheme for FEC encoding. 2. A source block is constructed as specified in Section 6.2.
3. The source block is passed to the FEC Scheme for FEC encoding.
The Source FEC Payload ID information of each Source packet is The Source FEC Payload ID information of each Source packet is
determined by the FEC Scheme and, if necessary, encoded into determined by the FEC Scheme. If required by the FEC Scheme the
encoded Source FEC Payload ID field. Source FEC Payload ID is encoded into the Explicit Source FEC
Payload ID field.
3. The FEC Source packet is constructed according to Section 6.3. 4. The FEC Scheme performs FEC Encoding, generating repair packet
The identity of the original flow is maintained by the source payloads from a source block and a Repair FEC Payload ID field for
packet through the use of the same transport ports and IP each repair payload.
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 transport layer procedures.
4. The FEC Scheme generates repair packet payloads from a source 5. The Explicit Source FEC Payload IDs (if used), Repair FEC
block and an encoded FEC Payload ID field for each repair paylaod. Payload IDs and repair packet payloads are provided back from the
The FEC Framework places these payloads and FEC Payload IDs into FEC Scheme to the FEC Framework.
FEC Repair packets, to be conveyed to the receiver(s). These
repair packets are sent using normal transport layer procedures to 6. The FEC Framework constructs FEC Source packets according to
a unique destination port(s) and/or multicast group(s) in the case Section 6.3 and FEC Repair packets according to Section 6.4
of multicast to separate them from any of the source packet flows.
The port(s) and multicast group(s) to be used for FEC Repair using the FEC Payload IDs and repair packet payloads provided by
packets are defined in the FEC Framework Configuration the FEC Scheme.
Information.
7. The FEC Source and FEC Repair packets are sent using normal
transport layer procedures. The port(s) and multicast group(s) to
be used for FEC Repair packets are defined in the FEC Framework
Configuration Information. The FEC Source packets are sent using
the same transport 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 eventual IP FEC Source
Packet will be the same whether or not the FEC Framework is
applied).
+-------------------------------------+
| |
| Application |
| |
+-------------------------------------+
|
| (1) Source transport payloads
|
v
+-------------------------------------+ +---------------------+
| FEC Framework | | |
| |------------------------------->| FEC Scheme |
| (2) Construct source blocks | (3) Source Block | |
| | | (4) FEC Encoding |
| (6) Construct FEC source packets |<-------------------------------| |
| and FEC repair packets | (5) Ex. Source FEC Payload Ids,| |
+-------------------------------------+ Repair FEC Payload Ids, +---------------------+
| Repair payloads
|
| (7) FEC Source packets and FEC repair packets
v
+-------------------------------------+
| |
| Transport Layer (e.g. UDP) |
| |
+-------------------------------------+
Figure 2: Sender operation
5.3. Receiver Operation 5.3. Receiver Operation
The following describes a possible receiver algorithm, when receiving The following describes a possible receiver algorithm, illustrated in
an FEC source or repair packet: Figure 3, when receiving an FEC source or repair packet:
1. If an FEC Source packet is received (as indicated by the 1. FEC Source Packets and FEC Repair packets are received and
transport flow on which was received), the source packet and passed to the FEC Framework. The type of packet (Source or
Source FEC Payload ID field are passed to the FEC Scheme. Repair) and the transport flow to which it belongs (in the case of
source packets ) is indicated by the transport flow information
which identifies the flow at the transport layer (for example
source and destination ports and addresses in the case of UDP).
2. If an FEC repair packet is received (as indicated by the 2. The FEC Framework extracts the Explicit Source FEC Payload ID
transport flow on which it was received), the contained repair field (if present) from FEC Source Packets and the Repair FEC
data and Repair FEC Payload ID field are passed to the FEC Scheme. Payload ID from FEC Repair Packets.
3. The FEC Scheme uses the received FEC Payload IDs to group 3. The Explicit Source FEC Payload IDs (if present), Repair FEC
source packets into source blocks. Payload IDs, FEC Source payloads and FEC Repair payloads are
passed to the FEC Scheme.
4. If at least one source packet is missing from a source block, 4. The FEC Scheme uses the received FEC Payload IDs (and derived
and at least one repair packet has been received for a source FEC Source Payload IDs in the case that the Explicit Source FEC
block then FEC decoding may be desirable. The FEC Scheme Payload ID field is not used) to group source and repair packets
determines if enough data for decoding of any or all of the into source blocks. If at least one source packet is missing from
missing source packets in the source block has been received and, a source block, and at least one repair packet has been received
if so, performs a decoding operation. for the same source block then FEC decoding may be performed in
order to recover missing source payloads. The FEC 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.
4. The FEC Scheme returns the source data to the FEC Framework in 5. The FEC Scheme returns the source transport payload to the FEC
the form of source blocks containing received and decoded source Framework in the form of source blocks containing received and
packets and indications of any source packets which were missing decoded source packets and indications of any source packets which
and could not be decoded. were missing and could not be decoded.
6. The FEC Framework passes the received and recovered source
packet payloads to the application.
+-------------------------------------+
| |
| Application |
| |
+-------------------------------------+
^
| (6) Source transport payloads
|
|
+-------------------------------------+ +---------------------+
| FEC Framework | | |
| |<-------------------------------| FEC Scheme |
| (2) Extract FEC Payload IDs and | (5) Source Transport Payloads | |
| pass Payloads and Payload IDs | | (4) FEC Decoding |
| to FEC Scheme |------------------------------->| |
| | (3) Ex. FEC Source Payload IDs,| |
+-------------------------------------+ FEC Repair Payload IDs, +---------------------+
^ FEC Source Payloads,
| FEC Repair Payloads
|
| (1) FEC Source packets and FEC repair packets
|
+--------------------------------------------+
| |
| Transport Layer (e.g. UDP) |
| |
+--------------------------------------------+
Figure 3: Receiver Operation
Note that the above procedure may result in a situation in which not Note that the above procedure may result in a situation in which not
all original source packets are recovered. all original source packets are recovered.
Source packets which are correctly received and those which are Source packets which are correctly received and those which are
reconstructed MAY be delivered to the application out of order and in reconstructed MAY be delivered to the application out of order and in
a different order from the order of arrival at the receiver. a different order from the order of arrival at the receiver.
Alternatively, buffering and packet re-ordering MAY be required to Alternatively, buffering and packet re-ordering MAY be required to
re-order received and reconstructed source packets into the order re-order received and reconstructed source packets into the order
they were placed into the source block, if that is necessary they were placed into the source block, if that is necessary
according to the application. according to the application.
6. Protocol Specification 6. Protocol Specification
6.1. General 6.1. General
This section specifies the protocol elements for the FEC Framework. This section specifies the protocol elements for the FEC Framework.
The protocol consists of three components which are described in the Three components of the protocol are defined in this document and are
following sections: described in the following sections:
1. Construction of a source block from source packets. The FEC 1. Construction of a source block from source payloads. The FEC
code will be applied to this source block to produce the repair code will be applied to this source block to produce the repair
data. payloads.
2. A format for packets containing source data. 2. A format for packets containing source data.
3. A format for packets containing repair data. 3. A format for packets containing repair data.
The operation of the FEC Framework is governed by certain FEC The operation of the FEC Framework is governed by certain FEC
Framework Configuation Information. This configuration information Framework Configuation Information. This configuration information
is also defined in this section. A complete protocol specification is also defined in this section. A complete protocol specification
that uses this framework MUST specify the means to determine and that uses this framework MUST specify the means to determine and
communicate this information between sender and receiver. Suitable communicate this information between sender and receiver.
Session Description Protocol elements for this purpose are defined in
Section 8.
6.2. Structure of the source block 6.2. Structure of the source block
The FEC Framework and FEC Scheme exchange source data in the form of The FEC Framework and FEC Scheme exchange source transport payload in
source blocks. A source block is generated from an ordered sequence the form of source blocks. A source block is generated by the FEC
of source packets. For each source packet, the following information Framework from an ordered sequence of source transport payloads. The
is included in the source block: allocation of transport payloads to blocks is dependent on the
application. Note that some source transport payloads may not be
included in any block. For each source transport payload included in
a source block, the following information is provided to the FEC
Scheme:
o The identity of the transport flow on which the packet was o A description of the source transport flow with which the
recieved transport payload is associated (See 6.5)
o The original source packet payload o The source transport payload itself
o The length of the original source packet payload o The length of the source transport payload
6.3. Packet format for FEC Source packets 6.3. Packet format for FEC Source packets
The packet format for FEC Source packets MUST be used to transport The packet format for FEC Source packets MUST be used to transport
the payload of an original source packet. As depicted in Figure 2, the payload of an original source packet. As depicted in Figure 4,
it consists of the original packet, optionally followed by the Source it consists of the original packet, optionally followed by the
FEC Payload ID field. The FEC Scheme determines whether the Source Explicit Source FEC Payload ID field. The FEC Scheme determines
FEC Payload ID field is required. This determination is specific to whether the Explicit Source FEC Payload ID field is required. This
each transport flow. determination is specific to each transport flow.
+------------------------------------+ +------------------------------------+
| IP header | | IP header |
+------------------------------------+ +------------------------------------+
| Transport header | | Transport header |
+------------------------------------+ +------------------------------------+
| Original transport Payload | | Original transport Payload |
+------------------------------------+ +------------------------------------+
| Source FEC Payload ID | | Explicit Source FEC Payload ID |
+------------------------------------+ +------------------------------------+
Figure 2: Structure of the FEC packet format for FEC Source packets Figure 4: Structure of the FEC packet format for FEC Source packets
The IP and transport header fields MUST be identical to those of the The FEC Source packets MUST be sent using the same transport flow as
original source packet. The Original transport Payload field MUST be would have been used for the original source packets if the FEC
identical to the transport payload of the original source packet. Framework were not present. The Original transport Payload field
The transport payload of the FEC Source packet MUST consist of the MUST be identical to the source transport payload. The transport
Original Transport Payload followed by the Source FEC Payload ID payload of the FEC Source packet MUST consist of the Original
Transport Payload followed by the Explicit Source FEC Payload ID
field, if required. field, if required.
The Source FEC Payload ID field contains information required to The Explicit Source FEC Payload ID field contains information
associate the source packet with a source block and for the operation required to associate the source packet with a source block and for
of the FEC algorithm and defined by the FEC Scheme. The format of the operation of the FEC algorithm and is defined by the FEC Scheme.
the Source FEC Payload ID field is defined by the FEC Scheme. Note The format of the Source FEC Payload ID field is defined by the FEC
that in the case that the FEC Scheme or CDP defines a means to derive Scheme. Note that in the case that the FEC Scheme or CDP defines a
the Source FEC Payload ID from other information in the packet (for means to derive the Source FEC Payload ID from other information in
example the a sequence number of some kind used by the application the packet (for example the a sequence number of some kind used by
protocol), then the Source FEC Payload ID field is not included in the application protocol), then the Source FEC Payload ID field is
the packet. In this case the original source packet and FEC Source not included in the packet. In this case the original source packet
Packet are identical. and FEC Source Packet are identical.
Note: The Source FEC Payload ID is placed at the end of the packet so Since the addition of the Explicit Source FEC Payload ID increases
that in the case that Robust Header Compression [3] or other header the packet length, then in applications where avoidance of IP packet
compression mechanisms are used and in the case that a ROHC profile fragmentation is a goal, Content Delivery Protocols SHOULD consider
is defined for the protocol carried within the transport payload (for the Explicit Source FEC Payload ID size when determining the size of
example RTP), then ROHC will still be applied for the FEC Source source transport payloads that will be delivered using the FEC
packets. Framework.
Note: The Explicit Source FEC Payload ID is placed at the end of the
packet so that in the case that Robust Header Compression [2] 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 packets. Applications that may be used with this
Framework should consider that FEC Schemes may add this Explicit
Source FEC Payload ID and thereby increase the packet size.
6.4. Packet Format for FEC Repair packets 6.4. Packet Format for FEC Repair packets
The packet format for FEC Repair packets is shown in Figure 3. The The packet format for FEC Repair packets is shown in Figure 5. The
transport payload consists of a Repair FEC Payload ID field followed transport payload consists of a Repair FEC Payload ID field followed
by repair data generated in the FEC encoding process. by repair data generated in the FEC encoding process.
+------------------------------------+ +------------------------------------+
| IP header | | IP header |
+------------------------------------+ +------------------------------------+
| Transport header | | Transport header |
+------------------------------------+ +------------------------------------+
| Repair FEC Payload ID | | Repair FEC Payload ID |
+------------------------------------+ +------------------------------------+
| Repair Symbols | | Repair Symbols |
+------------------------------------+ +------------------------------------+
Figure 3: Packet format for repair packets Figure 5: Packet format for repair packets
The Repair FEC Payload ID field contains information required for the The Repair FEC Payload ID field contains information required for the
operation of the FEC algorithm. This information is defined by the operation of the FEC algorithm at the receiver. This information is
FEC Scheme. The format of the Repair FEC Payload ID field is defined defined by the FEC Scheme. The format of the Repair FEC Payload ID
by the FEC Scheme. field is defined by the FEC Scheme.
6.5. FEC Framework Configuration Information 6.5. FEC Framework Configuration Information
The FEC Framework Configuration Information is information that the The FEC Framework Configuration Information is information that the
FEC Framework needs in order to apply FEC protection to the trasport FEC Framework needs in order to apply FEC protection to the transport
flows. A complete Content Delivery Protocol specification that uses flows. A complete Content Delivery Protocol specification that uses
the framework specified here MUST include details of how this the framework specified here MUST include details of how this
information is derived and communicated between sender and receiver. information is derived and communicated between sender and receiver.
The FEC Framework Configuration Information includes identification The FEC Framework Configuration Information includes identification
of a number of packet flows. For example, in the case of UDP, each of a set of source packet flows. For example, in the case of UDP,
packet flow is uniquely identified by a tuple { Source IP Address, each packet flow is uniquely identified by a tuple { Source IP
Destination IP Address, Source UDP port, Destination UDP port }. Address, Destination IP Address, Source UDP port, Destination UDP
port }. Note that in some applications some of these fields may be
wildcarded, so that the flow is identified by a subset of the fields
and in particular in many applications the limited tuple {
Destination IP Address, Destination UDP port } is sufficient.
A single instance of the FEC Framework provides FEC protection for A single instance of the FEC Framework provides FEC protection for
all packets of a specified set of source packet flows, by means of all packets of a specified set of source packet flows, by means of
one or more packet flows consisting of repair packets. The FEC one or more packet flows consisting of repair packets. The FEC
Framework Configuation Information includes, for each instance of the Framework Configuation Information includes, for each instance of the
FEC Framework: FEC Framework:
1. Identification of the packet flow(s) carrying FEC Repair 1. Identification of the packet flow(s) carrying FEC Repair
packets, known as the FEC repair flow(s). packets, known as the FEC repair flow(s).
2. For each source packet flow protected by the FEC repair 2. For each source packet flow protected by the FEC repair
flow(s): flow(s):
a. Identification of the packet flow carrying source packets. a. Defintion of the packet flow carrying source packets (for
example, by means of a tuple as describe above for UDP).
b. An integer identifier, between 0 and 255, for this flow. b. An integer identifier for this flow definition (i.e.
This identifier MUST be unique amongst all source packet flows tuple). This identifier MUST be unique amongst all source
which are protected by the same FEC repair flow. packet flows which are protected by the same FEC repair flow.
3. The FEC Encoding ID, identifying the FEC Scheme 3. The FEC Encoding ID, identifying the FEC Scheme
4. An opaque container for FEC-Scheme-specific information 4. The length of the Explicit Source FEC Payload Id, in bytes
5. An opaque container for FEC-Scheme-specific information
Multiple instances of the FEC Framework, with separate and Multiple instances of the FEC Framework, with separate and
independent FEC Framework Configuration Information, may be present independent FEC Framework Configuration Information, may be present
at a sender or receiver. A single instance of the FEC Framework at a sender or receiver. A single instance of the FEC Framework
protects all packets of all the source packet flows identified in (2) protects all packets of all the source packet flows identified in (2)
above i.e. all packets on those flows MUST be FEC Source packets as above i.e. all packets sent on those flows MUST be FEC Source packets
defined in Section 6.3. A single source packet flow MUST NOT be as defined in Section 6.3. A single source packet flow may be
protected by more than one FEC Framework instance. protected by multiple instances of the FEC Framework.
The integer flow identifier identified in 2(b) is a "shorthand" to
identify source flows between the FEC Framework and the FEC Scheme.
The reason for defining this as an integer, and including it in the
FEC Framework Configuration Information is so that the FEC Scheme at
the sender and receiver may use it to identify the source flow with
which a recovered packet is associated. The integer flow identifier
may therefore take the place of the complete flow description (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. Since repair packets may provide protection for
multiple source flows, this flow identifier would likely not be
carried directly in repair packets. However, the flow identifier
associated with a particular source packet may 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 A single FEC repair flow provides repair packets for a single
instance of the FEC Framework. Other packets MUST NOT be sent within instance of the FEC Framework. Other packets MUST NOT be sent within
this flow i.e. all packets in the FEC repair flow MUST be FEC repair 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 packets as defined in Section 6.4 and MUST relate to the same FEC
Framework instance. Framework instance.
6.6. FEC Scheme requirements 6.6. FEC Scheme requirements
In order to be used with this framework, an FEC Scheme MUST: In order to be used with this framework, an FEC Scheme MUST be
capable of processing data arranged into blocks of source transport
- use a systematic FEC code packet payloads (source blocks).
- be based on discrete source blocks
Editor's note: This section requires expansion to define more
explicitly the things an FEC Scheme must specify, along the lines
of the FEC Building Block.
7. Transport Protocols
The following transport protocols are supported:
o User Datagram Protocol (UDP) A specification for a new FEC scheme MUST include the following
things:
o Datagram Congestion Control Protocol (DCCP) 1. The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA as described in
Section 10.
Editor's note: This section will contain transport-specific 2. The type, semantics and encoding format of the Repair FEC Payload
considerations, if any. ID.
8. Session Description Protocol elements 3. The type, semantics and encoding format of the FEC Scheme-
specific FEC Framework Configuration Information.
This section defines Session Descrption Protocol elements which MAY 4. A full specification of the FEC code.
be used by Content Delivery Protocols that make use of this framework
to communicate the FEC Framework Configuration Information.
NOTE: It is for further discussion whether these SDP elements This specification MUST precisely define the valid FEC-Scheme-
should be defined here or in the context of a specific and Specific FEC Framework Configuration Information values, the
complete Content Delivery Protocol specification for streaming. valid FEC Payload ID values and the valid packet payload sizes
(where packet payload refers to the space - not necessarily
contiguous - within a packet dedicated to carrying encoding
symbol bytes).
This specification defines a class of new Transport Protocol Furthermore, given a source block as defined in Section 6.2,
identifiers for use in SDP media descriptions. For all existing valid values of the FEC-Scheme-Specific FEC Framework
identifiers <proto> this specification defines the identifier 'udp/ Configuration Information, a valid Repair FEC Payload ID value
fec/<proto>'. This identifier may be used as the Transport Protocol and a valid packet payload size, the specification MUST uniquely
identifier for a media description for source data to indicate that define the values of the encoding symbol bytes to be included in
the FEC Source packet format defined in Section 6.3 is used, with the the repair packet payload of a packet with the given Repair FEC
original transport payload field formated according to <proto>. Payload ID value.
Note that in the case of an FEC Scheme in which the Source FEC A common and simple way to specify the FEC code to the required
Payload ID field is not used, then the original Transport Protocol level of detail is to provide a precise specification of an
identifier MAY be used to support interoperability with receivers encoding algorithm which, given a source block, valid values of
which do not support FEC at all, whilst also providing FEC protection the FEC-Scheme-Specific FEC Framework Configuration Information,
for those receivers which support it. a valid Repair FEC Payload ID value and a valid packet payload
size as input produces the exact value of the encoding symbol
bytes as output.
A further Transport Protocol identifier, 'udp/fec', is defined to 5. A description of practical encoding and decoding algorithms.
indicate the the FEC Repair Packet format defined in Section 6.4.
This specification describes the use of SDP attributes defined in [6] This description need not be to the same level of detail as for
and the FEC grouping semantics defined in [7] to provide the FEC the encoding above, however it must be sufficient to demonstrate
Framework Configuration Information. The 'fec-declaration' attribute that encoding and decoding of the code is both possible and
may be used at either the session or media layer to declare a local practical.
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 FEC scheme specifications MAY additionally define the following:
and the Flow Identifiers require further discussion.
8.1. udp/fec/<proto> transport protocol identifier 1. Type, semantics and encoding format of an Explicit Source FEC
Payload ID.
tbc Whenever an FEC scheme specification defines an 'encoding format' for
an element, this must 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 be possible to derive the
length from examining the encoded bytes themselves. For example, the
initial bytes may include some kind of length indication.
8.2. udp/fec transport protocol identifier FEC scheme specifications SHOULD use the terminology defined in this
document and SHOULD follow the following format:
tbc 1. Introduction <describe the use-cases addressed by this FEC
scheme>
8.3. fec-declaration attribute 2. Formats and Codes
See [6]. 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>
8.4. fec-oti-extension attribute 2.2 Repair FEC Payload Id <Define the type and format of the
Repair FEC Payload ID>
See [6]. 2.3 FEC Framework Configuration Information <Define the type and
format of the FEC Scheme-specific FEC Framework configuration
information>
8.5. fec attribute 3. Procedures <describe any procedures which are specific to this
FEC scheme, in particular derivation and interpretation of the
fields in the FEC Payload ID and FEC Scheme-specific FEC Framework
configuration information.>
See [6]. 4. FEC code specification <provide a complete specification of the
FEC Code>
8.6. FEC media grouping semantics Specifications MAY include additional sections, for example,
examples.
This attribute is used to group source flows and the single repair Each FEC scheme MUST be specified independently of all other FEC
flow that protects them as described in [7] with the following schemes; for example, in a separate specification or a completely
additional requirements: independent section of larger specification (except, of course, a
specification of one FEC Scheme may include portions of another by
reference).
The media components grouped by an instance of the FEC grouping 7. Transport Protocols
attribute MUST include exactly one component with the udp/fec
protocol identifier.
The media components grouped by an instance of the FEC grouping The following transport protocols are supported:
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 o User Datagram Protocol (UDP)
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.
8.7. SDP example o Datagram Congestion Control Protocol (DCCP)
tbc Editor's note: This section will contain transport-specific
considerations, if any.
9. Congestion Control 8. Congestion Control
This section starts with a informative section on the motivation of This section starts with a informative section on the motivation of
the normative requirements for congestion control, which are spelled the normative requirements for congestion control, which are spelled
out in Section 9.1. out in Section 8.1.
Informative Note: The enforcement of Congestion Control (CC) Informative Note: The enforcement of Congestion Control (CC)
principles has gained a lot of momentum in the IETF over the principles has gained a lot of momentum in the IETF over the
recent years. While the need of CC over the open Internet is recent years. While the need of CC over the open Internet is
unquestioned, and the goal of TCP friendliness is generally agreed unquestioned, and the goal of TCP friendliness is generally agreed
for most (but not all) applications, the subject of congestion for most (but not all) applications, the subject of congestion
detection and measurement in heterogenous networks can hardly be detection and measurement in heterogenous networks can hardly be
considered as solved. Most congestion control algorithms detect considered as solved. Most congestion control algorithms detect
and measure congestion by taking (primarily or exclusively) the and measure congestion by taking (primarily or exclusively) the
packet loss rate into account. This appears to be inappropriate packet loss rate into account. This appears to be inappropriate
skipping to change at page 21, line 46 skipping to change at page 26, line 46
or multimedia transmission over heterogenous networks. In other or multimedia transmission over heterogenous networks. In other
cases, application reliability requirements may be so high that cases, application reliability requirements may be so high that
the required end-to-end reliability is difficult to achieve even the required end-to-end reliability is difficult to achieve even
over wired networks. Furthermore the end-to-end network over wired networks. Furthermore the end-to-end network
reliability may not be known in advance. reliability may not be known in advance.
This FEC framework is not proposed, nor intended, as a QoS This FEC framework is not proposed, nor intended, as a QoS
enhancement tool to combat losses resulting from highly congested enhancement tool to combat losses resulting from highly congested
networks. It should not be used for such purposes. networks. It should not be used for such purposes.
In order to prevent such mis-use, standardization could be left to In order to prevent such mis-use, one approach would be to leave
bodies most concerned with the problem described above. However, standardisation to bodies most concerned with the problem
the IETF defines base standards used by several bodies, including described above. However, the IETF defines base standards used by
DVB, 3GPP, 3GPP2, all of which appear to share the environment and several bodies, including DVB, 3GPP, 3GPP2, all of which appear to
the problem described. share the environment and the problem described.
Alternatively, a clear applicability statement could be used - for Another approach would be to write a clear applicability statement
example restricting use of the framework to networks with wireless - for example restricting use of the framework to networks with
links. However, there may be applications where the use of FEC wireless links. However, there may be applications where the use
may be justified to combat congestion-induced packet losses - of FEC may be justified to combat congestion-induced packet losses
particularly in lightly loaded networks, where congestion is the - particularly in lightly loaded networks, where congestion is the
result of relatively rare random peaks in instantaneous traffic result of relatively rare random peaks in instantaneous traffic
load - thereby intentionally violating congestion control load - thereby intentionally violating congestion control
principles. One possible example for such an application could be principles. One possible example for such an application could be
a no-matter-what, brute-force FEC protection of traffic generated a no-matter-what, brute-force FEC protection of traffic generated
as an emergency signal. as an emergency signal.
We propose a third approach, which is to require at a minimum that 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 the use of this framework with any given application, in any given
environment, does not cause congestion issues which the environment, does not cause congestion issues which the
application alone would not itself cause i.e. the use of this application alone would not itself cause i.e. the use of this
skipping to change at page 22, line 47 skipping to change at page 27, line 47
traffic from space-based senders, or senders in certain hardened traffic from space-based senders, or senders in certain hardened
military devices, which would warrant a higher FEC strength. military devices, which would warrant a higher FEC strength.
However, in this specification we give preference to the overall However, in this specification we give preference to the overall
stability and network friendliness of the average application, and stability and network friendliness of the average application, and
for those a factor of 2 appears to be appropriate. for those a factor of 2 appears to be appropriate.
A second constraint requires that the FEC protected packet stream A second constraint requires that the FEC protected packet stream
be in compliance with the congestion control in use for the be in compliance with the congestion control in use for the
application and network in question. application and network in question.
9.1. Normative requirements 8.1. Normative requirements
The bandwidth of FEC Repair packet flows MUST NOT exceed the The bandwidth of FEC Repair packet flows MUST NOT exceed the
bandwidth of the source packet flows being protected. In addition, bandwidth of the source packet flows being protected. In addition,
whenever the source packet flow bandwidth is adapted due to the whenever the source packet flow bandwidth is adapted due to the
operation of congestion control mechanisms, the FEC repair packet operation of congestion control mechanisms, the FEC repair packet
flow bandwidth MUST be similarly adapted. flow bandwidth MUST be similarly adapted.
10. Security Considerations 9. Security Considerations
The application of FEC protection to a stream does not provide any The application of FEC protection to a stream does not provide any
kind of security protection. kind of security protection.
If security services are required for the stream, then they MUST If security services are required for the stream, then they MUST
either be applied to the original source data before FEC protection either be applied to the original source transport payload before FEC
is applied, or to both the source and repair data, after FEC protection is applied, or to both the source and repair data, after
protection has been applied. FEC protection has been applied.
If integrity protection is applied to source packets before FEC If integrity protection is applied to source packets before FEC
protection is applied, and no further integrity protection is applied protection is applied, and no further integrity protection is applied
to repair packets, then a denial of service attack is possible if an 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 attacker is in a position to inject fake repair transport payloads.
by a receiver, such fake repair packets could cause incorrect FEC If received by a receiver, such fake repair transport payloads could
decoding resulting in incorrect source packets being passed up to the cause incorrect FEC decoding resulting in incorrect source transport
application protocol. Such incorrect packets would then be detected payloads being passed up to the application protocol. Such incorrect
by the source integrity protection and discarded, resulting in packets would then be detected by the source integrity protection and
partial or complete denial of service. Therefore, in such discarded, resulting in partial or complete denial of service.
environments, integrity protection MUST also be applied to the FEC Therefore, in such environments, integrity protection MUST also be
Repair packets, for example using IPsec. Receivers MUST also verify applied to the FEC repair transport payloads, for example using
the integrity of source packets before including the source data into IPsec. Receivers MUST also verify the integrity of source transport
the source block for FEC purposes. payloads before including the source transport payload into the
source block for FEC purposes.
It is possible that multiple streams with different confidentiality It is possible that multiple streams with different confidentiality
requirements (for example, the streams may be visible to different requirements (for example, the streams may be visible to different
sets of users) can be FEC protected by a single repair stream. This sets of users) can be FEC protected by a single repair stream. This
scenario is not recommended, since resources will be used to scenario is not recommended, since resources will be used to
distribute and decode data which cannot then be decrypted by at least distribute and decode data which cannot then be decrypted by at least
some receivers. However, in this scenario, confidentiality some receivers. However, in this scenario, confidentiality
protection MUST be applied before FEC encoding of the streams, protection MUST be applied before FEC encoding of the streams,
otherwise repair data may be used by a receiver to decode unencrypted otherwise repair transport payload may be used by a receiver to
versions of source streams which they do not have permissionions to decode unencrypted versions of source streams which they do not have
view. permissionions to view.
11. IANA Considerations 10. IANA Considerations
tbc tbd
12. Acknowledgments 11. Acknowledgments
This document is based in large part on [8] and so thanks are due to This document is based in large part on [4] and so thanks are due to
the additional authors of that document, Mike Luby, Magnus Westerlund the additional authors of that document, Mike Luby, Magnus Westerlund
and Stephan Wenger. That document was in turn based on the FEC and Stephan Wenger. That document was in turn based on the FEC
streaming protocol defined by 3GPP in [9] and thus thanks are also streaming protocol defined by 3GPP in [5] and thus thanks are also
due to the participants in 3GPP TSG SA working group 4. due to the participants in 3GPP TSG SA working group 4.
13. References 12. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
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, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed", Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
[4] Watson, M., "Forward Error Correction (FEC) Building Block", [3] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction
draft-ietf-rmt-fec-bb-revised-04 (work in progress), (FEC) Building Block", RFC 5052, August 2007.
September 2006.
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[6] Mehta, H., "SDP Descriptors for FLUTE",
draft-mehta-rmt-flute-sdp-05 (work in progress), January 2006.
[7] Li, A., "Forward Error Correction Grouping Semantics in Session
Description Protocol", RFC 4756, November 2006.
[8] Watson, M., "Forward Error Correction (FEC) Streaming [4] Watson, M., "Forward Error Correction (FEC) Streaming
Framework", draft-watson-tsvwg-fec-sf-00 (work in progress), Framework", draft-watson-tsvwg-fec-sf-00 (work in progress),
July 2005. July 2005.
[9] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols [5] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols
and codecs", 3GPP TS 26.346, April 2005. and codecs", 3GPP TS 26.346, April 2005.
Author's Address Author's Address
Mark Watson Mark Watson
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
U.S.A. U.S.A.
 End of changes. 117 change blocks. 
363 lines changed or deleted 493 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/