draft-ietf-fecframe-framework-02.txt   draft-ietf-fecframe-framework-03.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 July 12, 2008 Intended status: Standards Track October 24, 2008
Expires: January 13, 2009 Expires: April 27, 2009
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-02 draft-ietf-fecframe-framework-03
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 January 13, 2009. This Internet-Draft will expire on April 27, 2009.
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 public and private IP correction (FEC) codes with applications in public and private IP
networks to provide protection against packet loss. The framework networks to provide protection against packet loss. The framework
supports applying Forward Error Correction to arbitrary packet flows supports applying Forward Error Correction to arbitrary packet flows
over unreliable transport and is primarily intended for real-time, or over unreliable transport and is primarily intended for real-time, or
streaming, media. This framework can be used to define Content streaming, media. This framework can be used to define Content
Delivery Protocols that provide Forward Error Correction for Delivery Protocols that provide Forward Error Correction for
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 8 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 8
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9
5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 13 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 13
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14
5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17
6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 19 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Structure of the source block . . . . . . . . . . . . . . 19 6.2. Structure of the source block . . . . . . . . . . . . . . 21
6.3. Packet format for FEC Source packets . . . . . . . . . . . 19 6.3. Packet format for FEC Source packets . . . . . . . . . . . 21
6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 21 6.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 23
6.4.1. Packet Format for FEC Repair packets over RTP 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 23
(informative) . . . . . . . . . . . . . . . . . . . . 21 6.4.1. Packet Format for FEC Repair packets over RTP . . . . 23
6.5. FEC Framework Configuration Information . . . . . . . . . 22 6.5. FEC Framework Configuration Information . . . . . . . . . 24
6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 23 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 26 7. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 27 8. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative requirements . . . . . . . . . . . . . . . . . . 28 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9.1. Normative requirements . . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 35 13.1. Normative references . . . . . . . . . . . . . . . . . . . 37
13.2. Informative references . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
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 real-time, or streaming, media delivery. Primary examples are real-time, or streaming, media
applications such as broadcast, multicast or on-demand audio, video applications such as broadcast, multicast or on-demand audio, video
or multimedia. or multimedia.
skipping to change at page 6, line 5 skipping to change at page 5, line 9
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. container for FEC-Scheme-specific 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 [RFC5052] for FEC requirements are different from those defined in [RFC5052] for FEC
Schemes for object delivery. However there is a great deal of Schemes for object delivery. However there is a great deal of
commonality and FEC Schemes defined for object delivery may be easily commonality and FEC Schemes defined for object delivery may be easily
adapted for use with the framework defined here. adapted for use with the framework defined here.
Since the RTP protocol layer is used over UDP, this framework can be
applied to RTP flows as well. FEC repair packets may be sent
directly over UDP or over RTP. The latter approach has the advantage
that RTP instrumentation, based on RTCP, can be used for the repair
flow. Additionally, the post-repair RTCP extended report
[I-D.ietf-avt-post-repair-rtcp-xr] may be used to obtain information
about the loss rate after FEC recovery.
The use of RTP for repair flows is defined for each FEC Scheme by
defining an RTP Payload Format for that particular FEC Scheme
(possibly in the same document).
2. Definitions/Abbreviations 2. Definitions/Abbreviations
'FEC' Forward Error Correction. 'FEC' Forward Error Correction.
'AL-FEC' Application Layer Forward Error 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.
skipping to change at page 9, line 7 skipping to change at page 9, line 7
Forward Error Correction capabilities. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
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 layer
layer between the transport layer (e.g. UDP or DCCP) and Application between the transport layer (e.g. UDP or DCCP) and protocols running
and Transport Protocols running over this transport layer. Examples over this transport layer. Examples of such protocols are RTP, RTCP,
of such protocols are RTP, RTCP, etc. As such, the data path etc. As such, the data path interface between the FEC Framework and
interface between the FEC Framework and both underlying and overlying both underlying and overlying layers can be thought of as being the
layers can be thought of as being the same as the standard interface same as the standard interface to the transport layer - i.e. the data
to the transport layer - i.e. the data exchanged consists of datagram exchanged consists of datagram payloads each associated with a single
payloads each associated with a single transport flow identified by transport flow identified (in the case of UDP) by the standard
the standard 5-tuple { Source IP Address, Source Transport Port, 5-tuple { Source IP Address, Source Transport Port, Destination IP
Destination IP Address, Destination Transport Port, Transport Address, Destination Transport Port, Transport Protocol }. In the
Protocol }. case that RTP is used for the repair flows, the source and repair
data may be multiplexed using RTP onto a single UDP flow and must
consequently be demultiplexed at the receiver. There are various
ways in which this multiplexing can be done, for example as described
in [RFC4588]. In this case the interface to the FEC Framework, at
least for the repair flows, can be thought of as equivalent to that
between RTP and users of RTP.
It is important to understand that the main purpose of the FEC
Framework architecture is to allocate fuctional responsibilities to
separately documented components in such a way that specific
instances of the components can be combined in different ways to
describe different protocols.
The FEC Framework makes use of an FEC Scheme, in a similar sense to The FEC Framework makes use of an FEC Scheme, in a similar sense to
that defined in [RFC5052] and uses the terminology of that document. that defined in [RFC5052] and uses the terminology of that document.
The FEC Scheme provides FEC encoding and decoding and describes the The FEC Scheme defines the FEC encoding and decoding and defines the
protocol fields and or procedures used to identify packet payload protocol fields and procedures used to identify packet payload data
data in the context of the FEC Scheme. The interface between the FEC 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
Framework passes transport packet payloads (source and repair) to the Framework passes transport packet payloads (source and repair) to the
FEC Scheme and the FEC Scheme returns additional recovered source FEC Scheme and the FEC Scheme returns additional recovered source
packet payloads. packet payloads.
skipping to change at page 10, line 4 skipping to change at page 10, line 16
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 [RFC5052]. Object Transmission Information defined in [RFC5052].
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 in the following sections. as described in the following sections.
In this architecture we assume that the interface to the transport In this architecture we assume that the interface to the transport
layer supports the concepts of payloads to be transported and layer supports the concepts of payloads to be transported and
identification transport flows on which those payloads are identification of transport flows on which those payloads are
transported. Since this is an interface internal to the transported. Since this is an interface internal to the
architecture, we do not specify this interface explicitly, except to architecture, we do not specify this interface explicitly, except to
say that transport flows which are distinct from the transport layer say that transport flows which are distinct from the transport layer
point of view (for example, distinct UDP flows as identified by the point of view (for example, distinct UDP flows as identified by the
UDP source/destination ports/addresses) are also distinct on the UDP source/destination ports/addresses) are also distinct on the
interface between the transport layer and the FEC Framework. interface between the transport layer and the FEC Framework.
The architecture outlined above is illustrated in the Figure 1. As noted above, RTP flows are a specific example of transport flows
which might be protected by the FEC Framework. From the FEC
Framework point of view, RTP source flows are sequences of UDP packet
payloads like any other protocol over UDP.
Depending on the FEC Scheme, RTP may also be used as a transport for
repair packet flows. In this case an FEC Scheme must define an RTP
Payload Format for the repair data.
The architecture outlined above is illustrated in the Figure 1. In
this architecture, two RTP instances are shown, for the source and
repair data respectively. This is because the use of RTP for the
source data is separate from and independent of the use of RTP for
the repair data. The appearance of two RTP instances is more natural
when you consider that in many FEC codes, the the repair payload
contains parity bytes calculated across the RTP headers of the source
packets. Thus a repair packet carried over RTP starts with an RTP
header of its own which is immediately followed by parity data
containing bytes which protect the source RTP headers (as well as
parity data for the source RTP payloads).
+--------------------------------------------+ +--------------------------------------------+
| |
| Application | | Application |
| |
+--------------------------------------------+ +--------------------------------------------+
^
| |
v |
|
+ - - - - - - -- - - - - - - - - - - - - - - - - + + - - - - - - -- - - - - - - - - - - - - - - - - +
| | | +--------------------------------------------+ |
+--------------------------------------------+
| | | |
| Application Layer | | Application Layer |
| +--------------------------------------------+ |
| |
| + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP | |
| | | |-Configuration/Coordination
+- -- -- -- -- -- -- -- -- -- -- -+ |
| | | | | | | |
+--------------------------------------------+ | Transport flows |
| +---------------------------------+ | | | | v |
| | | +--------------------------------------------+ +----------------+
| | Application/Transport Protocol | | | | | FEC Framework (this document) |<--->| FEC Scheme |
| (e.g. RTP) | |-Configuration/Coordination +--------------------------------------------+ +----------------+
| +---------------------------------+ | |
^ |
| | Transport flows | |
v v
| +--------------------------------------------+ | +----------------+
| | | | | | | |
| | FEC Framework (this document) |------| FEC Scheme | Source | Repair |
| | | | | | | |
| +--------------------------------------------+ | +----------------+ +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
^ | | RTP | | RTP processing | |<--- Optional
| | Transport flows | | | +-- -- -- |- -- -+ | - dependent on
v | | +-- -- -- -- -- -- -- |--+ | | FEC Scheme
| | RTP (de)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
|
| +--------------------------------------------+ | | +--------------------------------------------+ |
| | | Transport Layer (e.g. UDP) |
| | Transport Layer (e.g. UDP) | |
| |
+--------------------------------------------+
| +--------------------------------------------+ | | +--------------------------------------------+ |
| | |
| | IP | | | +--------------------------------------------+ |
| | | IP |
| +--------------------------------------------+ | | +--------------------------------------------+ |
Content Delivery Protocol Content Delivery Protocol
+ - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework Architecture Figure 1: FEC Framework Architecture
The contents of the transport payload for repair packets is fully The contents of the transport payload for repair packets is fully
defined by the FEC Scheme. FEC Schemes MAY define a means for repair defined by the FEC Scheme. For a specific FEC Scheme, a means MAY be
data to be carried over RTP, in which case the repair packet payload defined for repair data to be carried over RTP, in which case the
format starts with the RTP header. This specification provides repair packet payload format starts with the RTP header. This
guidelines for the use of RTP for the repair flows in this manner, corresponds to defining an RTP Payload Format for the specific FEC
however the explicit specification of this case is delegated to FEC Scheme. Guidelines for writers of RTP Payload Formats are provided
Schemes. in [RFC2736].
The use of RTP for repair packets is independent of the protocols The use of RTP for repair packets is independent of the protocols
used for source packets: if RTP is used for source packets then used for source packets: if RTP is used for source packets then
repair packets may or may not use RTP and vice versa (although it is repair packets may or may not use RTP and vice versa (although it is
unlikely that there are useful scenarios where non-RTP source flows unlikely that there are useful scenarios where non-RTP source flows
are protected by RTP repair flows). FEC Schemes are expected to are protected by RTP repair flows). FEC Schemes are expected to
recover entire transport payloads for recovered source packets in all recover entire transport payloads for recovered source packets in all
cases. For example if RTP is used for source flows, the FEC Scheme cases. For example if RTP is used for source flows, the FEC Scheme
is expected to recover the entire UDP payload, including the RTP is expected to recover the entire UDP payload, including the RTP
header. header.
Editor's note: An alternative possibility would be to define a
single RTP Payload Format (and associated MIME Type) for the
carriage of FEC repair data for any FEC Scheme. In this case, FEC
Scheme specifications need not mention RTP: the encapsulation of
repair payloads in RTP packets will be defined for all schemes by
a single RTP Payload Format specification.
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 transport payloads which can be protected restrictions on the source transport payloads which can be protected
together, except that the source transport payload is carried over a together, except that the source transport payload is carried over a
supported transport protocol (See Section 7). The data may be from supported transport protocol (See Section 8). The data may be from
multiple transport flows that are protected jointly. The FEC multiple transport flows that are protected jointly. The FEC
framework handles the packet flows as a sequence of 'source blocks' framework handles the packet flows as a sequence of 'source blocks'
each consisting of a set of source transport payloads, possibly from each consisting of a set of source transport payloads, possibly from
multiple flows which are to be protected together. For example, each multiple flows which are to be protected together. For example, each
source block may be constructed from those source transport payloads source block may be constructed from those source transport payloads
related to a particular segment in time of the flow. related to a particular segment in time of the flow.
At the sender, the FEC Framework passes the payloads for a given At the sender, the FEC Framework passes the payloads for a given
block to the FEC Scheme for FEC encoding. The FEC Scheme performs block to the FEC Scheme for FEC encoding. The FEC Scheme performs
the FEC encoding operation and returns the following information: the FEC encoding operation and returns the following information:
skipping to change at page 15, line 5 skipping to change at page 15, line 5
which are defined by the FEC Scheme. which are defined by the FEC Scheme.
The FEC Scheme MAY use different FEC Payload ID field formats for FEC The FEC Scheme MAY use different FEC Payload ID field formats for FEC
Source packets and FEC Repair packets. 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 data packets for the session. These may be RTP, RTCP, MIKEY or
indeed any other type of packet. The following operations, indeed any other type of packet. The following operations,
illustrated in Figure 2 describe a possible way to generate compliant illustrated in Figure 2, for the case of UDP repair flows and
FEC Source packet and FEC repair packet streams: Figure 3 for the case of RTP repair flows, describe a possible way to
generate compliant FEC Source packet and FEC repair packet streams:
1. Source transport payloads are provided by the application. 1. Source transport payloads are provided by the application.
2. A source block is constructed as specified in Section 6.2. 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. 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. If required by the FEC Scheme the determined by the FEC Scheme. If required by the FEC Scheme the
Source FEC Payload ID is encoded into the Explicit Source FEC Source FEC Payload ID is encoded into the Explicit Source FEC
Payload ID field. Payload ID field.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
transport layer procedures. The port(s) and multicast group(s) to transport layer procedures. The port(s) and multicast group(s) to
be used for FEC Repair packets are defined in the FEC Framework be used for FEC Repair packets are defined in the FEC Framework
Configuration Information. The FEC Source packets are sent using Configuration Information. The FEC Source packets are sent using
the same transport flow identification information as would have the same transport flow identification information as would have
been used for the original source packets if the FEC Framework been used for the original source packets if the FEC Framework
were not present (for example, in the UDP case, the UDP source and were not present (for example, in the UDP case, the UDP source and
destination addresses and ports on the eventual IP FEC Source destination addresses and ports on the eventual IP FEC Source
Packet will be the same whether or not the FEC Framework is Packet will be the same whether or not the FEC Framework is
applied). applied).
+-------------------------------------+ +----------------------+
| |
| Application | | Application |
| | +----------------------+
+-------------------------------------+
| |
| (1) Source transport payloads | (1) Source transport payloads
| |
v v
+-------------------------------------+ +---------------------+ +----------------------+ +------------------+
| FEC Framework | | | | FEC Framework | | |
| |------------------------------->| FEC Scheme | | |-------------------------->| FEC Scheme |
| (2) Construct source blocks | (3) Source Block | | |(2) Construct source | (3) Source Block | |
| | | (4) FEC Encoding | | blocks | | (4) FEC Encoding |
| (6) Construct FEC source packets |<-------------------------------| | |(6) Construct FEC src |<--------------------------| |
| and FEC repair packets | (5) Ex. Source FEC Payload Ids,| | | packets and FEC | | |
+-------------------------------------+ Repair FEC Payload Ids, +---------------------+ | repair packets |(5) Ex src FEC Payload Ids,| |
| Repair payloads +----------------------+ Repair FEC Payload Ids,+------------------+
| Repair transport payloads
| |
| (7) FEC Source packets and FEC repair packets | (7) FEC Source packets and FEC repair packets
v v
+-------------------------------------+ +----------------------+
| | | Transport Layer |
| Transport Layer (e.g. UDP) | | (e.g. UDP ) |
| | +----------------------+
+-------------------------------------+
Figure 2: Sender operation Figure 2: Sender operation
+----------------------+
| Application |
+----------------------+
|
| (1) Source UDP payloads
v
+----------------------+ +------------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source | (3) Source Block | |
| blocks | | (4) FEC Encoding |
|(6) Construct FEC src |<--------------------------| |
| packets and FEC | | |
| repair packets |(5) Ex src FEC Payload Ids,| |
+----------------------+ Repair FEC Payload Ids,+------------------+
| | Repair RTP payloads
|(7) Source |
| |(7') Repair RTP payloads
| + -- -- -- -- -+
| | RTP |
| +-- -- -- -- --+
v v
+----------------------+
| Transport Layer |
| (e.g. UDP ) |
+----------------------+
Figure 3: Sender operation with RTP repair flows
5.3. Receiver Operation 5.3. Receiver Operation
The following describes a possible receiver algorithm, illustrated in The following describes a possible receiver algorithm, illustrated in
Figure 3, when receiving an FEC source or repair packet: Figure 4 and Figure 5 for the case of RTP repair flows, when
receiving an FEC source or repair packet:
1. FEC Source Packets and FEC Repair packets are received and 1. FEC Source Packets and FEC Repair packets are received and
passed to the FEC Framework. The type of packet (Source or passed to the FEC Framework. The type of packet (Source or
Repair) and the transport flow to which it belongs (in the case of Repair) and the transport flow to which it belongs (in the case of
source packets ) is indicated by the transport flow information source packets ) is indicated by the transport flow information
which identifies the flow at the transport layer (for example which identifies the flow at the transport layer (for example
source and destination ports and addresses in the case of UDP). source and destination ports and addresses in the case of UDP).
1a. In the special case that RTP is used for repair packets and
source and repair packets are multiplexed onto the same UDP flow,
then RTP demultiplexing is required to demultiplex source and
repair flows. However, RTP processing is applied only to the
repair packets at this stage: source packets continue to be
handled as UDP payloads (i.e. including their RTP headers).
2. The FEC Framework extracts the Explicit Source FEC Payload ID 2. The FEC Framework extracts the Explicit Source FEC Payload ID
field (if present) from FEC Source Packets and the Repair FEC field (if present) from FEC Source Packets and the Repair FEC
Payload ID from FEC Repair Packets. Payload ID from FEC Repair Packets.
3. The Explicit Source FEC Payload IDs (if present), Repair FEC 3. The Explicit Source FEC Payload IDs (if present), Repair FEC
Payload IDs, FEC Source payloads and FEC Repair payloads are Payload IDs, FEC Source payloads and FEC Repair payloads are
passed to the FEC Scheme. passed to the FEC Scheme.
4. The FEC Scheme uses the received FEC Payload IDs (and derived 4. The FEC Scheme uses the received FEC Payload IDs (and derived
FEC Source Payload IDs in the case that the Explicit Source FEC FEC Source Payload IDs in the case that the Explicit Source FEC
skipping to change at page 18, line 5 skipping to change at page 19, line 5
payloads in the source block has been received. payloads in the source block has been received.
5. The FEC Scheme returns the source transport payload to the FEC 5. The FEC Scheme returns the source transport payload to the FEC
Framework in the form of source blocks containing received and Framework in the form of source blocks containing received and
decoded source packets and indications of any source packets which decoded source packets and indications of any source packets which
were missing and could not be decoded. were missing and could not be decoded.
6. The FEC Framework passes the received and recovered source 6. The FEC Framework passes the received and recovered source
packet payloads to the application. packet payloads to the application.
+-------------------------------------+ +----------------------+
| |
| Application | | Application |
| | +----------------------+
+-------------------------------------+
^ ^
| (6) Source transport payloads | (6) Source transport payloads
| |
| +----------------------+ +------------------+
+-------------------------------------+ +---------------------+
| FEC Framework | | | | FEC Framework | | |
| |<-------------------------------| FEC Scheme | | |<---------------------------| FEC Scheme |
| (2) Extract FEC Payload IDs and | (5) Source Transport Payloads | | |(2)Extract FEC Payload| (5) Source Transport | |
| pass Payloads and Payload IDs | | (4) FEC Decoding | | IDs and pass IDs & | Payloads | (4) FEC Decoding |
| to FEC Scheme |------------------------------->| | | Payloads to FEC |--------------------------->| |
| | (3) Ex. FEC Source Payload IDs,| | | Scheme | (3) Ex src FEC Payload IDs,| |
+-------------------------------------+ FEC Repair Payload IDs, +---------------------+ +----------------------+ FEC Repair Payload IDs,+------------------+
^ FEC Source Payloads, ^ FEC Source Payloads,
| FEC Repair Payloads | FEC Repair Payloads
| |
| (1) FEC Source packets and FEC repair packets | (1) FEC Source packets and FEC repair packets
| |
+--------------------------------------------+ +----------------------+
| | | Transport Layer |
| Transport Layer (e.g. UDP) | | (e.g. UDP ) |
| | +----------------------+
+--------------------------------------------+
Figure 3: Receiver Operation Figure 4: Receiver Operation
+----------------------+
| Application |
+----------------------+
^
| (6) Source UDP payloads
|
+----------------------+ +------------------+
| FEC Framework | | |
| |<---------------------------| FEC Scheme |
|(2)Extract FEC Payload| (5) Source Transport | |
| IDs and pass IDs & | Payloads | (4) FEC Decoding |
| Payloads to FEC |--------------------------->| |
| Scheme | (3) Ex src FEC Payload IDs,| |
+----------------------+ FEC Repair Payload IDs,+------------------+
^ ^ FEC Source Payloads,
| | FEC Repair Payloads
|Source pkts |
| |(1a) FEC repair payloads
+-- |- -- -- -- -- -- -+
|RTP| | RTP processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP demux | |
+-- -- -- -- -- -- -- -+
| (1) FEC Source packets and FEC repair packets
+----------------------+
| Transport Layer |
| (e.g. UDP ) |
+----------------------+
Figure 5: 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
skipping to change at page 19, line 48 skipping to change at page 21, line 48
o A description of the source transport flow with which the o A description of the source transport flow with which the
transport payload is associated (See 6.5) transport payload is associated (See 6.5)
o The source transport payload itself o The source transport payload itself
o The length of the source transport 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 4, the payload of an original source packet. As depicted in Figure 6,
it consists of the original packet, optionally followed by the it consists of the original packet, optionally followed by the
Explicit Source FEC Payload ID field. The FEC Scheme determines Explicit Source FEC Payload ID field. The FEC Scheme determines
whether the Explicit Source FEC Payload ID field is required. This whether the Explicit Source FEC Payload ID field is required. This
determination is specific to each transport flow. determination is specific to each transport flow.
+------------------------------------+ +------------------------------------+
| IP header | | IP header |
+------------------------------------+ +------------------------------------+
| Transport header | | Transport header |
+------------------------------------+ +------------------------------------+
| Original transport Payload | | Original transport Payload |
+------------------------------------+ +------------------------------------+
| Explicit Source FEC Payload ID | | Explicit Source FEC Payload ID |
+------------------------------------+ +------------------------------------+
Figure 4: Structure of the FEC packet format for FEC Source packets Figure 6: Structure of the FEC packet format for FEC Source packets
The FEC Source packets MUST be sent using the same transport flow as The FEC Source packets MUST be sent using the same transport flow as
would have been used for the original source packets if the FEC would have been used for the original source packets if the FEC
Framework were not present. The Original transport Payload field Framework were not present. The Original transport Payload field
MUST be identical to the source transport payload. The transport MUST be identical to the source transport payload. The transport
payload of the FEC Source packet MUST consist of the Original payload of the FEC Source packet MUST consist of the Original
Transport Payload followed by the Explicit Source FEC Payload ID Transport Payload followed by the Explicit Source FEC Payload ID
field, if required. field, if required.
The Explicit Source FEC Payload ID field contains information The Explicit Source FEC Payload ID field contains information
skipping to change at page 21, line 5 skipping to change at page 23, line 5
Note: The Explicit Source FEC Payload ID is placed at the end of the Note: The Explicit Source FEC Payload ID is placed at the end of the
packet so that in the case that Robust Header Compression [RFC3095] packet so that in the case that Robust Header Compression [RFC3095]
or other header compression mechanisms are used and in the case that or other header compression mechanisms are used and in the case that
a ROHC profile is defined for the protocol carried within the a ROHC profile is defined for the protocol carried within the
transport payload (for example RTP), then ROHC will still be applied transport payload (for example RTP), then ROHC will still be applied
for the FEC Source packets. Applications that may be used with this for the FEC Source packets. Applications that may be used with this
Framework should consider that FEC Schemes may add this Explicit Framework should consider that FEC Schemes may add this Explicit
Source FEC Payload ID and thereby increase the packet size. Source FEC Payload ID and thereby increase the packet size.
6.3.1. Generic Explicit Source FEC Payload Id
In order to apply FEC protection using multiple FEC Schemes to a
single source flow all schemes must use the same Explicit Source FEC
Payload Id format. In order to enable this, it is RECOMMENDED that
FEC Schemes support the Generic Explicit Source FEC Payload Id format
described below.
The Generic Explicit Source FEC Payload Id has length 2 bytes and
consists of an unsigned packet sequence number in network byte order.
Source packets SHALL be allocated sequence numbers such that source
packets which are protected in a single FEC block have consecutive
sequence numbers (where consecutive includes wrap-around from 65535
to 0). Sequence numbers SHOULD NOT be reused until all values in the
sequence nmber space have been used.
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 5. The The packet format for FEC Repair packets is shown in Figure 7. 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 5: Packet format for repair packets Figure 7: 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 at the receiver. This information is operation of the FEC algorithm at the receiver. This information is
defined by the FEC Scheme. The format of the Repair FEC Payload ID defined by the FEC Scheme. The format of the Repair FEC Payload ID
field is defined by the FEC Scheme. field is defined by the FEC Scheme.
6.4.1. Packet Format for FEC Repair packets over RTP (informative) 6.4.1. Packet Format for FEC Repair packets over RTP
For FEC Schemes which specify the use of RTP for repair packets, the For FEC Schemes which specify the use of RTP for repair packets, the
packet format for repair packets includes an RTP header as shown in packet format for repair packets includes an RTP header as shown in
Figure 6. Figure 8.
+------------------------------------+ +------------------------------------+
| IP header | | IP header |
+------------------------------------+ +------------------------------------+
| Transport header (UDP) | | Transport header (UDP) |
+------------------------------------+ +------------------------------------+
| RTP Header | | RTP Header |
+------------------------------------+ +------------------------------------+
| Repair FEC Payload ID | | Repair FEC Payload ID |
+------------------------------------+ +------------------------------------+
| Repair Symbols | | Repair Symbols |
+------------------------------------+ +------------------------------------+
Figure 6: Packet format for repair packets Figure 8: Packet format for repair packets
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 transport 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
skipping to change at page 23, line 47 skipping to change at page 26, line 16
In order to be used with this framework, an FEC Scheme MUST be In order to be used with this framework, an FEC Scheme MUST be
capable of processing data arranged into blocks of source transport capable of processing data arranged into blocks of source transport
packet payloads (source blocks). packet payloads (source blocks).
A specification for a new FEC scheme MUST include the following A specification for a new FEC scheme MUST include the following
things: things:
1. The FEC Encoding ID value that uniquely identifies the FEC 1. The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA as described in scheme. This value MUST be registered with IANA as described in
Section 10. Section 11.
2. The type, semantics and encoding format of the Repair FEC Payload 2. The type, semantics and encoding format of the Repair FEC Payload
ID. ID.
3. The type, semantics and encoding format of the FEC Scheme- 3. The type, semantics and encoding format of the FEC Scheme-
specific FEC Framework Configuration Information. specific FEC Framework Configuration Information.
4. A full specification of the FEC code. 4. A full specification of the FEC code.
This specification MUST precisely define the valid FEC-Scheme- This specification MUST precisely define the valid FEC-Scheme-
skipping to change at page 26, line 5 skipping to change at page 28, line 9
Specifications MAY include additional sections, for example, Specifications MAY include additional sections, for example,
examples. examples.
Each FEC scheme MUST be specified independently of all other FEC Each FEC scheme MUST be specified independently of all other FEC
schemes; for example, in a separate specification or a completely schemes; for example, in a separate specification or a completely
independent section of larger specification (except, of course, a independent section of larger specification (except, of course, a
specification of one FEC Scheme may include portions of another by specification of one FEC Scheme may include portions of another by
reference). reference).
7. Transport Protocols Where an RTP Payload Format is defined for repair data for a specific
FEC Scheme, the RTP Payload Format and the FEC Scheme MAY be
specified within the same document.
7. Feedback
Many applications require some kind of feedback on transport
performance: how much data arrived at the receiver, at what rate,
when etc. When FEC is added to such applications, feedback
mechanisms may also need to be enhanced to report on the performance
of the FEC (for example how much lost data was recovered by the FEC).
When used to provide instrumentation for engineering purposes, it is
important to remember that FEC is generally applied to relatively
small blocks of data (in time) and so feedback information averaged
over longer periods of time than the FEC block size will likely not
provide sufficient information for engineering purposes. For example
see [I-D.ietf-avt-post-repair-rtcp-xr].
New applications which require such feedback SHOULD use RTP/RTCP
[RFC3550].
8. Transport Protocols
The following transport protocols are supported: The following transport protocols are supported:
o User Datagram Protocol (UDP) o User Datagram Protocol (UDP)
o Datagram Congestion Control Protocol (DCCP) o Datagram Congestion Control Protocol (DCCP)
Editor's note: This section will contain transport-specific Editor's note: This section will contain transport-specific
considerations, if any. considerations, if any.
8. Congestion Control 9. 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 8.1. out in Section 9.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 28, line 47 skipping to change at page 32, 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.
8.1. Normative requirements 9.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.
9. Security Considerations 10. 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 transport payload before FEC either be applied to the original source transport payload before FEC
protection is applied, or to both the source and repair data, after protection is applied, or to both the source and repair data, after
FEC 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
skipping to change at page 31, line 5 skipping to change at page 35, line 5
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 transport payload may be used by a receiver to otherwise repair transport payload may be used by a receiver to
decode unencrypted versions of source streams which they do not have decode unencrypted versions of source streams which they do not have
permissionions to view. permissionions to view.
10. IANA Considerations 11. IANA Considerations
tbd tbd
11. Acknowledgments 12. Acknowledgments
This document is based in large part on [I-D.watson-tsvwg-fec-sf] and This document is based in large part on [I-D.watson-tsvwg-fec-sf] and
so thanks are due to the additional authors of that document, Mike so thanks are due to the additional authors of that document, Mike
Luby, Magnus Westerlund and Stephan Wenger. That document was in Luby, Magnus Westerlund and Stephan Wenger. That document was in
turn based on the FEC streaming protocol defined by 3GPP in [MBMSTS] turn based on the FEC streaming protocol defined by 3GPP in [MBMSTS]
and thus thanks are also due to the participants in 3GPP TSG SA and thus thanks are also due to the participants in 3GPP TSG SA
working group 4. working group 4.
12. References 13. References
13.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
13.2. Informative references
[I-D.watson-tsvwg-fec-sf] [I-D.watson-tsvwg-fec-sf]
Watson, M., "Forward Error Correction (FEC) Streaming Watson, M., "Forward Error Correction (FEC) Streaming
Framework", draft-watson-tsvwg-fec-sf-00 (work in Framework", draft-watson-tsvwg-fec-sf-00 (work in
progress), July 2005. progress), July 2005.
[I-D.ietf-avt-post-repair-rtcp-xr]
Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
Report Block Type for RTCP XR",
draft-ietf-avt-post-repair-rtcp-xr-03 (work in progress),
October 2008.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736,
December 1999.
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346, April 2005. Protocols 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
 End of changes. 57 change blocks. 
136 lines changed or deleted 294 lines changed or added

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