draft-ietf-fecframe-framework-03.txt   draft-ietf-fecframe-framework-04.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 October 24, 2008 Intended status: Standards Track July 8, 2009
Expires: April 27, 2009 Expires: January 9, 2010
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-03 draft-ietf-fecframe-framework-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 27, 2009. This Internet-Draft will expire on January 9, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 7
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 8 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 9
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10
5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 13 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 14
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18
6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 22
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Structure of the source block . . . . . . . . . . . . . . 21 6.2. Structure of the source block . . . . . . . . . . . . . . 22
6.3. Packet format for FEC Source packets . . . . . . . . . . . 21 6.3. Packet format for FEC Source packets . . . . . . . . . . . 22
6.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 23 6.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 24
6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 23 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 24
6.4.1. Packet Format for FEC Repair packets over RTP . . . . 23 6.4.1. Packet Format for FEC Repair packets over RTP . . . . 24
6.5. FEC Framework Configuration Information . . . . . . . . . 24 6.5. FEC Framework Configuration Information . . . . . . . . . 25
6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26
7. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30 8. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 31
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative requirements . . . . . . . . . . . . . . . . . . 32 9.1. Normative requirements . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
13.1. Normative references . . . . . . . . . . . . . . . . . . . 37 13.1. Normative references . . . . . . . . . . . . . . . . . . . 38
13.2. Informative references . . . . . . . . . . . . . . . . . . 37 13.2. Informative references . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39
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 27 skipping to change at page 7, line 27
'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 'Application Data Unit' Data used as the payload for the transport
(e.g. UDP or DCCP packet payload) 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
skipping to change at page 10, line 15 skipping to change at page 11, line 15
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 [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 data units (referred to here as
identification of transport flows on which those payloads are Application Data Units) to be transported and identification of
transported. Since this is an interface internal to the transport flows on which those data units are transported. Since
architecture, we do not specify this interface explicitly, except to this is an interface internal to the architecture, we do not specify
say that transport flows which are distinct from the transport layer this interface explicitly, except to say that transport flows which
point of view (for example, distinct UDP flows as identified by the are distinct from the transport layer point of view (for example,
UDP source/destination ports/addresses) are also distinct on the distinct UDP flows as identified by the UDP source/destination ports/
interface between the transport layer and the FEC Framework. addresses) are also distinct on the interface between the transport
layer and the FEC Framework.
As noted above, RTP flows are a specific example of transport flows As noted above, RTP flows are a specific example of transport flows
which might be protected by the FEC Framework. From the FEC which might be protected by the FEC Framework. From the FEC
Framework point of view, RTP source flows are sequences of UDP packet Framework point of view, RTP source flows are sequences of UDP packet
payloads like any other protocol over UDP. payloads like any other protocol over UDP.
Depending on the FEC Scheme, RTP may also be used as a transport for 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 repair packet flows. In this case an FEC Scheme must define an RTP
Payload Format for the repair data. Payload Format for the repair data.
skipping to change at page 13, line 10 skipping to change at page 14, line 10
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.
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 Application Data Units which can be protected
together, except that the source transport payload is carried over a together, except that the Application Data Unit is carried over a
supported transport protocol (See Section 8). 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 Source Data Flows that are protected jointly. The FEC
framework handles the packet flows as a sequence of 'source blocks' framework handles the Source Data Flows as a sequence of 'source
each consisting of a set of source transport payloads, possibly from blocks' each consisting of a set of Application Data Units, possibly
multiple flows which are to be protected together. For example, each from multiple Source Data Flows which are to be protected together.
source block may be constructed from those source transport payloads For example, each source block may be constructed from those
related to a particular segment in time of the flow. Application Data Units 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:
o optionally, encoded FEC Payload IDs for each of the source o optionally, encoded FEC Payload IDs for each of the source
payloads 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 packet payloads o encoded FEC Payload IDs for each of the repair packet payloads
The FEC framework then performs two operations: Firstly, it appends The FEC framework then performs two operations: Firstly, it appends
the FEC payload IDs, if provided, to each of the source transport the FEC payload IDs, if provided, to each of the Application Data
payloads, and sends the resulting packets, known as 'FEC source Units, and sends the resulting packets, known as 'FEC source
packets', to the receiver and secondly it places the provided 'FEC packets', to the receiver and secondly it places the provided 'FEC
repair packet payloads' and corresponding 'FEC Repair Payload IDs' repair packet payloads' and corresponding 'FEC Repair Payload IDs'
appropriately to construct 'FEC repair packets' and send them to the appropriately to construct 'FEC repair packets' and send them to the
receiver. Note that FEC repair packets MAY be sent to a different receiver. Note that FEC repair packets MAY be sent to a different
multicast group or groups from the source packets. multicast group or groups from the source packets.
This document does not define how the sender determines which source This document does not define how the sender determines which source
transport payloads are included in which source blocks or the sending Application Data Units are included in which source blocks or the
order and timing of FEC source and FEC repair packets. A specific sending order and timing of FEC source and FEC repair packets. A
Content Delivery Protocol MAY define this mapping or it MAY be left specific Content Delivery Protocol MAY define this mapping or it MAY
as implementation dependent at the sender. However, a CDP be left as implementation dependent at the sender. However, a CDP
specification MUST define how a receiver determines the length of specification MUST define how a receiver determines the length of
time it should wait to receive FEC repair packets for any given time it should wait to receive FEC repair packets for any given
source block. The sequence of operations at the sender is described source block. The sequence of operations at the sender is described
in more detail in Section 5.2. in more detail in Section 5.2.
At the receiver, original source transport payloads are recovered by At the receiver, original Application Data Units are recovered by the
the FEC Framework directly from any FEC Source packets received FEC Framework directly from any FEC Source Packets received simply by
simply by removing the Source FEC Payload ID, if present. The removing the Source FEC Payload ID, if present. The receiver also
receiver also passes the contents of the received FEC Source passes the contents of the received Application Data Units, plus
transport payloads, plus their FEC Payload IDs to the FEC Scheme for their FEC Payload IDs to the FEC Scheme for possible decoding.
possible decoding.
If any FEC source transport payloads related to a given source block If any Application Data Units related to a given source block have
have been lost, then the FEC Scheme may perform FEC decoding to been lost, then the FEC Scheme may perform FEC decoding to recover
recover the missing source transport payloads (assuming sufficient the missing Application Data Units (assuming sufficient FEC Source
FEC Source and FEC Repair packets related to that source block have and FEC Repair packets related to that source block have been
been received). 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 may occur. 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. The receiver operation is described in more detail in here. The receiver operation is described in more detail in
Section 5.3 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 (in terms source block and the position within the source block (in terms
specific to the FEC Scheme) occupied by the packet. This information specific to the FEC Scheme) occupied by the Application Data Unit.
is known as the 'Source FEC Payload ID'. The FEC Scheme is This information is known as the 'Source FEC Payload ID'. The FEC
responsible for defining and interpreting this information. This Scheme is responsible for defining and interpreting this information.
information MAY be encoded into a specific field within the FEC This information MAY be encoded into a specific field within the FEC
Source packet format defined in this specification, called the Source packet format defined in this specification, called the
Explicit Source FEC Payload ID field. The exact contents and format Explicit Source FEC Payload ID field. The exact contents and format
of the Explicit Source FEC Payload ID field are defined by the FEC of the Explicit Source FEC Payload ID field are defined by the FEC
Scheme. Alternatively, the FEC Scheme MAY define how the Source FEC Scheme. Alternatively, the FEC Scheme MAY define how the Source FEC
Payload ID is derived from other fields within the source packets. Payload ID is derived from other fields within the source packets.
This document defines the way that the Explicit Source FEC Payload ID This document defines the way that the Explicit Source FEC Payload ID
field is appended to source packets to form FEC Source packets. field is appended to source packets to form FEC 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 source block and the relationship between the contained repair
skipping to change at page 15, line 9 skipping to change at page 16, line 9
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, for the case of UDP repair flows and illustrated in Figure 2, for the case of UDP repair flows and
Figure 3 for the case of RTP repair flows, describe a possible way to Figure 3 for the case of RTP repair flows, describe a possible way to
generate compliant FEC Source packet and FEC repair packet streams: generate compliant FEC Source packet and FEC repair packet streams:
1. Source transport payloads are provided by the application. 1. Application Data Units 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.
4. The FEC Scheme performs FEC Encoding, generating repair packet 4. The FEC Scheme performs FEC Encoding, generating repair packet
payloads from a source block and a Repair FEC Payload ID field for payloads from a source block and a Repair FEC Payload ID field for
each repair payload. each repair payload.
5. The Explicit Source FEC Payload IDs (if used), Repair FEC 5. The Explicit Source FEC Payload IDs (if used), Repair FEC
Payload IDs and repair packet payloads are provided back from the Payload IDs and repair packet payloads are provided back from the
FEC Scheme to the FEC Framework. FEC Scheme to the FEC Framework.
6. The FEC Framework constructs FEC Source packets according to 6. The FEC Framework constructs FEC Source packets according to
Section 6.3 and FEC Repair packets according to Section 6.4 Section 6.3 and FEC Repair packets according to Section 6.4 using
the FEC Payload IDs and repair packet payloads provided by the FEC
using the FEC Payload IDs and repair packet payloads provided by Scheme.
the FEC Scheme.
7. The FEC Source and FEC Repair packets are sent using normal 7. The FEC Source and FEC Repair packets are sent using normal
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) Application Data Units
| |
v v
+----------------------+ +------------------+ +----------------------+ +------------------+
| FEC Framework | | | | FEC Framework | | |
| |-------------------------->| FEC Scheme | | |-------------------------->| FEC Scheme |
|(2) Construct source | (3) Source Block | | |(2) Construct source | (3) Source Block | |
| blocks | | (4) FEC Encoding | | blocks | | (4) FEC Encoding |
|(6) Construct FEC src |<--------------------------| | |(6) Construct FEC src |<--------------------------| |
| packets and FEC | | | | packets and FEC | | |
| repair packets |(5) Ex src FEC Payload Ids,| | | repair packets |(5) Ex src FEC Payload Ids,| |
skipping to change at page 17, line 8 skipping to change at page 18, line 8
+----------------------+ +----------------------+
| Transport Layer | | Transport Layer |
| (e.g. UDP ) | | (e.g. UDP ) |
+----------------------+ +----------------------+
Figure 2: Sender operation Figure 2: Sender operation
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) Source UDP payloads | (1) Application Data Units
v v
+----------------------+ +------------------+ +----------------------+ +------------------+
| FEC Framework | | | | FEC Framework | | |
| |-------------------------->| FEC Scheme | | |-------------------------->| FEC Scheme |
|(2) Construct source | (3) Source Block | | |(2) Construct source | (3) Source Block | |
| blocks | | (4) FEC Encoding | | blocks | | (4) FEC Encoding |
|(6) Construct FEC src |<--------------------------| | |(6) Construct FEC src |<--------------------------| |
| packets and FEC | | | | packets and FEC | | |
| repair packets |(5) Ex src FEC Payload Ids,| | | repair packets |(5) Ex src FEC Payload Ids,| |
+----------------------+ Repair FEC Payload Ids,+------------------+ +----------------------+ Repair FEC Payload Ids,+------------------+
skipping to change at page 17, line 41 skipping to change at page 18, line 41
Figure 3: Sender operation with RTP repair flows 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 4 and Figure 5 for the case of RTP repair flows, when Figure 4 and Figure 5 for the case of RTP repair flows, when
receiving an FEC source or repair packet: 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 Source Data Flow to which it belongs (in the case
source packets ) is indicated by the transport flow information of 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 1a. In the special case that RTP is used for repair packets and
source and repair packets are multiplexed onto the same UDP flow, source and repair packets are multiplexed onto the same UDP flow,
then RTP demultiplexing is required to demultiplex source and then RTP demultiplexing is required to demultiplex source and
repair flows. However, RTP processing is applied only to the repair flows. However, RTP processing is applied only to the
repair packets at this stage: source packets continue to be repair packets at this stage: source packets continue to be
handled as UDP payloads (i.e. including their RTP headers). handled as UDP payloads (i.e. including their RTP headers).
skipping to change at page 18, line 24 skipping to change at page 19, line 24
FEC Source Payload IDs in the case that the Explicit Source FEC FEC Source Payload IDs in the case that the Explicit Source FEC
Payload ID field is not used) to group source and repair packets Payload ID field is not used) to group source and repair packets
into source blocks. If at least one source packet is missing from into source blocks. If at least one source packet is missing from
a source block, and at least one repair packet has been received a source block, and at least one repair packet has been received
for the same source block then FEC decoding may be performed in for the same source block then FEC decoding may be performed in
order to recover missing source payloads. The FEC Scheme order to recover missing source payloads. The FEC Scheme
determines whether source packets have been lost and whether determines whether source packets have been lost and whether
enough data for decoding of any or all of the missing source enough data for decoding of any or all of the missing source
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 Application Data Unit 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 Application Data Units and indications of any Application
were missing and could not be decoded. Data Units which 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
packet payloads to the application. Application Data Units to the application.
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
| (6) Source transport payloads | (6) Application Data Units
| |
+----------------------+ +------------------+ +----------------------+ +------------------+
| FEC Framework | | | | FEC Framework | | |
| |<---------------------------| FEC Scheme | | |<---------------------------| FEC Scheme |
|(2)Extract FEC Payload| (5) Source Transport | | |(2)Extract FEC Payload| (5) Application Data Units | |
| IDs and pass IDs & | Payloads | (4) FEC Decoding | | IDs and pass IDs & | | (4) FEC Decoding |
| Payloads to FEC |--------------------------->| | | Payloads to FEC |--------------------------->| |
| Scheme | (3) Ex src FEC 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 |
skipping to change at page 20, line 4 skipping to change at page 21, line 4
| 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 4: Receiver Operation Figure 4: Receiver Operation
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
| (6) Source UDP payloads | (6) Application Data Units
| |
+----------------------+ +------------------+ +----------------------+ +------------------+
| FEC Framework | | | | FEC Framework | | |
| |<---------------------------| FEC Scheme | | |<---------------------------| FEC Scheme |
|(2)Extract FEC Payload| (5) Source Transport | | |(2)Extract FEC Payload| (5) Application Data Units | |
| IDs and pass IDs & | Payloads | (4) FEC Decoding | | IDs and pass IDs & | | (4) FEC Decoding |
| Payloads to FEC |--------------------------->| | | Payloads to FEC |--------------------------->| |
| Scheme | (3) Ex src FEC 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
|Source pkts | |Source pkts |
| |(1a) FEC repair payloads | |(1a) FEC repair payloads
+-- |- -- -- -- -- -- -+ +-- |- -- -- -- -- -- -+
|RTP| | RTP processing | |RTP| | RTP processing |
| | +-- -- -- --|-- -+ | | +-- -- -- --|-- -+
skipping to change at page 20, line 42 skipping to change at page 21, line 43
+----------------------+ +----------------------+
Figure 5: Receiver Operation 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 applied to re-
re-order received and reconstructed source packets into the order order received and reconstructed source packets into the order they
they were placed into the source block, if that is necessary were placed into the source block, if that is necessary according to
according to the application. 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.
Three components of the protocol are defined in this document and are Three components of the protocol are defined in this document and are
described in the following sections: described in the following sections:
1. Construction of a source block from source payloads. The FEC 1. Construction of a source block from Application Data Units.
code will be applied to this source block to produce the repair The FEC code will be applied to this source block to produce the
payloads. repair 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. communicate this information between sender and receiver.
6.2. Structure of the source block 6.2. Structure of the source block
The FEC Framework and FEC Scheme exchange source transport payload in The FEC Framework and FEC Scheme exchange Application Data Units in
the form of source blocks. A source block is generated by the FEC the form of source blocks. A source block is generated by the FEC
Framework from an ordered sequence of source transport payloads. The Framework from an ordered sequence of Application Data Units. The
allocation of transport payloads to blocks is dependent on the allocation of Application Data Units to blocks is dependent on the
application. Note that some source transport payloads may not be application. Note that some Application Data Units may not be
included in any block. For each source transport payload included in included in any block. For each sApplication Data Units included in
a source block, the following information is provided to the FEC a source block, the following information is provided to the FEC
Scheme: Scheme:
o A description of the source transport flow with which the o A description of the Source Data Flow with which the Application
transport payload is associated (See 6.5) Data Unit is associated (See 6.5)
o The source transport payload itself o The Application Data Unit itself
o The length of the source transport payload o The length of the Application Data Unit
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 6, 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 | | Application Data Unit |
+------------------------------------+ +------------------------------------+
| Explicit Source FEC Payload ID | | Explicit Source FEC Payload ID |
+------------------------------------+ +------------------------------------+
Figure 6: 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 transport payload of the FEC Source
MUST be identical to the source transport payload. The transport packet MUST consist of the Application Data Unit followed by the
payload of the FEC Source packet MUST consist of the Original Explicit Source FEC Payload ID field, if required.
Transport Payload followed by the Explicit Source FEC Payload ID
field, if required.
The Explicit Source FEC Payload ID field contains information The Explicit Source FEC Payload ID field contains information
required to associate the source packet with a source block and for required to associate the source packet with a source block and for
the operation of the FEC algorithm and is defined by the FEC Scheme. the operation of the FEC algorithm and is defined by the FEC Scheme.
The format of the Source FEC Payload ID field is defined by the FEC The format of the Source FEC Payload ID field is defined by the FEC
Scheme. Note that in the case that the FEC Scheme or CDP defines a Scheme. Note that in the case that the FEC Scheme or CDP defines a
means to derive the Source FEC Payload ID from other information in means to derive the Source FEC Payload ID from other information in
the packet (for example the a sequence number of some kind used by the packet (for example the a sequence number of some kind used by
the application protocol), then the Source FEC Payload ID field is the application protocol), then the Source FEC Payload ID field is
not included in the packet. In this case the original source packet not included in the packet. In this case the original source packet
and FEC Source Packet are identical. and FEC Source Packet are identical.
Since the addition of the Explicit Source FEC Payload ID increases Since the addition of the Explicit Source FEC Payload ID increases
the packet length, then in applications where avoidance of IP packet the packet length, then in applications where avoidance of IP packet
fragmentation is a goal, Content Delivery Protocols SHOULD consider fragmentation is a goal, Content Delivery Protocols SHOULD consider
the Explicit Source FEC Payload ID size when determining the size of the Explicit Source FEC Payload ID size when determining the size of
source transport payloads that will be delivered using the FEC Application Data Units that will be delivered using the FEC
Framework. Framework.
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.
skipping to change at page 23, line 15 skipping to change at page 24, line 15
6.3.1. Generic Explicit Source FEC Payload Id 6.3.1. Generic Explicit Source FEC Payload Id
In order to apply FEC protection using multiple FEC Schemes to a In order to apply FEC protection using multiple FEC Schemes to a
single source flow all schemes must use the same Explicit Source FEC single source flow all schemes must use the same Explicit Source FEC
Payload Id format. In order to enable this, it is RECOMMENDED that Payload Id format. In order to enable this, it is RECOMMENDED that
FEC Schemes support the Generic Explicit Source FEC Payload Id format FEC Schemes support the Generic Explicit Source FEC Payload Id format
described below. described below.
The Generic Explicit Source FEC Payload Id has length 2 bytes and The Generic Explicit Source FEC Payload Id has length 2 bytes and
consists of an unsigned packet sequence number in network byte order. consists of an unsigned packet sequence number in network byte order.
Source packets SHALL be allocated sequence numbers such that source The allocation of sequence numbers to packets is independent of any
packets which are protected in a single FEC block have consecutive FEC Scheme and of the Source Block contruction, except that the use
sequence numbers (where consecutive includes wrap-around from 65535 of this sequence number places a constraint on source block
to 0). Sequence numbers SHOULD NOT be reused until all values in the construction source packets within a gioven source block MUST have
sequence nmber space have been used. 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 7. 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 |
+------------------------------------+ +------------------------------------+
skipping to change at page 24, line 28 skipping to change at page 25, line 28
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
of a set of source packet flows. For example, in the case of UDP, of the set of Source Data Flows. For example, in the case of UDP,
each packet flow is uniquely identified by a tuple { Source IP each Source Data Flow is uniquely identified by a tuple { Source IP
Address, Destination IP Address, Source UDP port, Destination UDP Address, Destination IP Address, Source UDP port, Destination UDP
port }. Note that in some applications some of these fields may be 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 wildcarded, so that the flow is identified by a subset of the fields
and in particular in many applications the limited tuple { and in particular in many applications the limited tuple {
Destination IP Address, Destination UDP port } is sufficient. 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 the specified set of Source Data 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 Data Flow protected by the FEC repair flow(s):
flow(s):
a. Defintion of the packet flow carrying source packets (for a. Defintion of the Source Data Flow carrying source packets
example, by means of a tuple as describe above for UDP). (for example, by means of a tuple as describe above for UDP).
b. An integer identifier for this flow definition (i.e. b. An integer identifier for this flow definition (i.e.
tuple). This identifier MUST be unique amongst all source tuple). This identifier MUST be unique amongst all Source Data
packet flows which are protected by the same FEC repair flow. 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. The length of the Explicit Source FEC Payload Id, in bytes 4. The length of the Explicit Source FEC Payload Id, in bytes
5. An opaque container for FEC-Scheme-specific information 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 packets of the Source Data Flows identified in (2) above
above i.e. all packets sent on those flows MUST be FEC Source packets i.e. all packets sent on those flows MUST be FEC Source packets as
as defined in Section 6.3. A single source packet flow may be defined in Section 6.3. A single Source Data Flow may be protected
protected by multiple instances of the FEC Framework. by multiple instances of the FEC Framework.
The integer flow identifier identified in 2(b) is a "shorthand" to The integer flow identifier identified in 2(b) is a "shorthand" to
identify source flows between the FEC Framework and the FEC Scheme. identify source flows between the FEC Framework and the FEC Scheme.
The reason for defining this as an integer, and including it in the The reason for defining this as an integer, and including it in the
FEC Framework Configuration Information is so that the FEC Scheme at FEC Framework Configuration Information is so that the FEC Scheme at
the sender and receiver may use it to identify the source flow with the sender and receiver may use it to identify the source flow with
which a recovered packet is associated. The integer flow identifier which a recovered packet is associated. The integer flow identifier
may therefore take the place of the complete flow description (e.g. may therefore take the place of the complete flow description (e.g.
UDP 4-tuple). UDP 4-tuple).
Whether and how this flow identifier is used is defined by the FEC Whether and how this flow identifier is used is defined by the FEC
Scheme. Since source packets are directly associated with a flow by Scheme. Since source packets are directly associated with a flow by
virtue of their packet headers, this identifier need not be carried virtue of their packet headers, this identifier need not be carried
in source packets. Since repair packets may provide protection for in source packets. Since repair packets may provide protection for
multiple source flows, this flow identifier would likely not be multiple source flows, repair packets would either not carry the
carried directly in repair packets. However, the flow identifier identifier at all or may carry multiple identifiers. However, in any
associated with a particular source packet may be recovered from the case, the flow identifier associated with a particular source packet
repair packets as part of an FEC decoding operation. Integer flow may be recovered from the repair packets as part of an FEC decoding
identifiers SHOULD be allocated starting from zero and increasing by operation. Integer flow identifiers SHOULD be allocated starting
one for each flow. 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.
In the case that RTP is used for repair packets, the identification In the case that RTP is used for repair packets, the identification
of the repair packet flow MAY also include the RTP Payload Type to be of the repair packet flow MAY also include the RTP Payload Type to be
used for repair packets. used for repair packets.
6.6. FEC Scheme requirements 6.6. FEC Scheme requirements
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 Application Data
packet payloads (source blocks). Units (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 11. 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-
Specific FEC Framework Configuration Information values, the Specific FEC Framework Configuration Information values, the
valid FEC Payload ID values and the valid packet payload sizes valid FEC Payload ID values and the valid packet payload sizes
(where packet payload refers to the space - not necessarily (where packet payload refers to the space within a packet
contiguous - within a packet dedicated to carrying encoding dedicated to carrying encoding symbol bytes).
symbol bytes).
Furthermore, given a source block as defined in Section 6.2, Furthermore, given a source block as defined in Section 6.2,
valid values of the FEC-Scheme-Specific FEC Framework valid values of the FEC-Scheme-Specific FEC Framework
Configuration Information, a valid Repair FEC Payload ID value Configuration Information, a valid Repair FEC Payload ID value
and a valid packet payload size, the specification MUST uniquely and a valid packet payload size, the specification MUST uniquely
define the values of the encoding symbol bytes to be included in define the values of the encoding symbol bytes to be included in
the repair packet payload of a packet with the given Repair FEC the repair packet payload of a packet with the given Repair FEC
Payload ID value. Payload ID value.
A common and simple way to specify the FEC code to the required A common and simple way to specify the FEC code to the required
skipping to change at page 29, line 20 skipping to change at page 30, line 20
mechanisms may also need to be enhanced to report on the performance 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). of the FEC (for example how much lost data was recovered by the FEC).
When used to provide instrumentation for engineering purposes, it is When used to provide instrumentation for engineering purposes, it is
important to remember that FEC is generally applied to relatively important to remember that FEC is generally applied to relatively
small blocks of data (in time) and so feedback information averaged small blocks of data (in time) and so feedback information averaged
over longer periods of time than the FEC block size will likely not over longer periods of time than the FEC block size will likely not
provide sufficient information for engineering purposes. For example provide sufficient information for engineering purposes. For example
see [I-D.ietf-avt-post-repair-rtcp-xr]. see [I-D.ietf-avt-post-repair-rtcp-xr].
Applications which used feedback for congestion control purposes MUST
calculate such feedback on the basis of packets received before FEC
recovery is applied. If this requirement conflicts with other uses
of the feedback information then the application MUST be enhanced to
support both information calculated pre- and post- FEC recovery.
This is to ensure that congestion control mechanisms operate
correctly based on congestion indications recieved from the network,
rather than on post-FEC recovery information which would give an
inaccuate picture of congestion conditions.
New applications which require such feedback SHOULD use RTP/RTCP New applications which require such feedback SHOULD use RTP/RTCP
[RFC3550]. [RFC3550].
8. Transport Protocols 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
considerations, if any.
9. 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 9.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
skipping to change at page 35, line 7 skipping to change at page 36, line 7
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.
11. IANA Considerations 11. IANA Considerations
tbd FEC Schemes for use with this framework may be identified in
protocols using FEC Encoding IDs. Values of FEC Encoding IDs are
subject to IANA registration. They are in the registry named "FEC
Framework (FECFRAME) FEC Encoding IDs" located at time of publication
at <tbd>.
The values that can be assigned within the FEC Framework (FECFRAME)
FEC Encoding ID registry are numeric indexes in the range [0, 255],
boundaries included. Assignment requests are granted on a "IETF
Consensus" basis as defined in[RFC5226] . Section 6.6 defines
explicit requirements that documents defining new FEC Encoding IDs
should meet.
12. 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.
skipping to change at page 37, line 26 skipping to change at page 38, line 26
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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
13.2. Informative references 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] [I-D.ietf-avt-post-repair-rtcp-xr]
Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
Report Block Type for RTCP XR", Report Block Type for RTCP XR",
draft-ietf-avt-post-repair-rtcp-xr-03 (work in progress), draft-ietf-avt-post-repair-rtcp-xr-05 (work in progress),
October 2008. June 2009.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, Payload Format Specifications", BCP 36, RFC 2736,
December 1999. December 1999.
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
skipping to change at page 39, line 4 skipping to change at line 1277
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.
Email: mark@digitalfountain.com Email: mark@digitalfountain.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 55 change blocks. 
154 lines changed or deleted 193 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/