draft-ietf-fecframe-framework-05.txt   draft-ietf-fecframe-framework-06.txt 
FEC Framework Working Group M. Watson FEC Framework Working Group M. Watson
Internet-Draft Qualcomm, Inc. Internet-Draft Qualcomm, Inc.
Intended status: Standards Track July 9, 2009 Intended status: Standards Track March 5, 2010
Expires: January 10, 2010 Expires: September 6, 2010
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-05 draft-ietf-fecframe-framework-06
Abstract
This document describes a framework for using forward error
correction (FEC) codes with applications in public and private IP
networks to provide protection against packet loss. The framework
supports applying Forward Error Correction to arbitrary packet flows
over unreliable transport and is primarily intended for real-time, or
streaming, media. This framework can be used to define Content
Delivery Protocols that provide Forward Error Correction for
streaming media delivery or other packet flows. Content Delivery
Protocols defined using this framework can support any FEC Scheme
(and associated FEC codes) which is compliant with various
requirements defined in this document. Thus, Content Delivery
Protocols can be defined which are not specific to a particular FEC
Scheme and FEC Schemes can be defined which are not specific to a
particular Content Delivery Protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 January 10, 2010. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document describes for a framework for using forward error This document may contain material from IETF Documents or IETF
correction (FEC) codes with applications in public and private IP Contributions published or made publicly available before November
networks to provide protection against packet loss. The framework 10, 2008. The person(s) controlling the copyright in some of this
supports applying Forward Error Correction to arbitrary packet flows material may not have granted the IETF Trust the right to allow
over unreliable transport and is primarily intended for real-time, or modifications of such material outside the IETF Standards Process.
streaming, media. This framework can be used to define Content Without obtaining an adequate license from the person(s) controlling
Delivery Protocols that provide Forward Error Correction for the copyright in such materials, this document may not be modified
streaming media delivery or other packet flows. Content Delivery outside the IETF Standards Process, and derivative works of it may
Protocols defined using this framework can support any FEC Scheme not be created outside the IETF Standards Process, except to format
(and associated FEC codes) which is compliant with various it for publication as an RFC or to translate it into languages other
requirements defined in this document. Thus, Content Delivery than English.
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
particular Content Delivery Protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 7 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 9 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 9
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10
5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 14 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 14
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 16
5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18
6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 22 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 22
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Structure of the source block . . . . . . . . . . . . . . 22 6.2. Structure of the source block . . . . . . . . . . . . . . 22
6.3. Packet format for FEC Source packets . . . . . . . . . . . 22 6.3. Packet format for FEC Source packets . . . . . . . . . . . 22
6.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 24 6.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 24
6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 24 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 24
6.4.1. Packet Format for FEC Repair packets over RTP . . . . 24 6.4.1. Packet Format for FEC Repair packets over RTP . . . . 24
6.5. FEC Framework Configuration Information . . . . . . . . . 25 6.5. FEC Framework Configuration Information . . . . . . . . . 25
6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26
skipping to change at page 6, line 13 skipping to change at page 5, line 13
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 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 applied to RTP flows as well. FEC repair packets may be sent
directly over UDP or over RTP. The latter approach has the advantage directly over UDP or over RTP. The latter approach has the advantage
that RTP instrumentation, based on RTCP, can be used for the repair that RTP instrumentation, based on RTCP, can be used for the repair
flow. Additionally, the post-repair RTCP extended report flow. Additionally, the post-repair RTCP extended report [RFC5725]
[I-D.ietf-avt-post-repair-rtcp-xr] may be used to obtain information may be used to obtain information about the loss rate after FEC
about the loss rate after FEC recovery. recovery.
The use of RTP for repair flows is defined for each FEC Scheme by The use of RTP for repair flows is defined for each FEC Scheme by
defining an RTP Payload Format for that particular FEC Scheme defining an RTP Payload Format for that particular FEC Scheme
(possibly in the same document). (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.
'Source data flow' The packet flow or flows to which FEC protection 'Source data flow' The packet flow or flows to which FEC protection
is to be applied. is to be applied. A source data flow consists of ADUs.
'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. and repair data flows - e.g. UDP, DCCP.
'Application Data Unit' Data used as the payload for the transport 'Application Data Unit' The unit of source data provided as payload
layer (e.g. UDP or DCCP packet payload) to the transport layer
'ADU Flow' A sequence of ADUs associated with a transport layer flow
identifier (such as the standard 5-tuple { Source IP Address,
Source Transport Port, Destination IP Address, Destination
Transport Port, Transport Protocol } in the case of UDP)
'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 (Note: in general FEC Codes may
also be used to make a data flow resiliant to corruption, but that
is not considered here).
'FEC Scheme' A specification which defines the additional protocol 'FEC Scheme' A specification which defines the additional protocol
aspects required to use a particular FEC code with the FEC aspects required to use a particular FEC code with the FEC
Framework, or (in the context of RMT), with the RMT FEC Building Framework, or (in the context of RMT), with the RMT FEC Building
Block. Block.
'Source Block' the group of source data packets which are to be FEC 'Source Block' A group of ADUs which are to be FEC protected as a
protected as a single block single block
'Protection amount' The relative increase in data sent due to the 'Protection amount' The relative increase in data sent due to the
use of FEC. use of FEC.
FEC Framework Configuration Information: Information which controls 'FEC Framework Configuration Information' Information which controls
the operation of the FEC Framework. the operation of the FEC Framework.
FEC Payload ID: Information which identifies the contents of a 'FEC Source Packet' At a sender (resp. receiver) a payload submitted
to (resp. received from) the Transport protocol containing an ADU
along with an optional Source FEC Payload ID.
'FEC Repair Packet' At a sender (resp. receiver) a payload submitted
to (resp. received from) the Transport protocol containing one or
more repair symbols along with a Repair FEC Payload ID and
possibly an RTP header.
'FEC Payload ID' Information which identifies the contents of a
packet with respect to the FEC Scheme. packet with respect to the FEC Scheme.
Source FEC Payload ID: An FEC Payload ID specifically for use with 'Source FEC Payload ID' An FEC Payload ID specifically for use with
source packets. source packets.
Repair FEC Payload ID: An FEC Payload ID specifically for use with 'Repair FEC Payload ID' An FEC Payload ID specifically for use with
repair packets. repair packets.
Content Delivery Protocol (CDP): A complete application protocol 'Content Delivery Protocol (CDP)' A complete application protocol
specification which, through the use of the framework defined in specification which, through the use of the framework defined in
this document, is able to make use of FEC Schemes to provide this document, is able to make use of FEC Schemes to provide
Forward Error Correction capabilities. Forward Error Correction capabilities
The following definitions are aligned with [RFC5052]
'Source symbol' unit of data used during the encoding process.
Encoding symbol: unit of data generated by the encoding process.
With systematic codes, source symbols are part of the encoding
symbols.
'Encoding symbol' unit of data generated by the encoding process.
With systematic codes, source symbols are part of the encoding
symbols.
'Repair symbol' encoding symbol that is not a source symbol.
'Code rate' the k/n ratio, i.e., the ratio between the number of
source symbols and the number of encoding symbols. By definition,
the code rate is such that: 0 < code rate <= 1. A code rate close
to 1 indicates that a small number of repair symbols have been
produced during the encoding process.
'Systematic code' FEC code in which the source symbols are part of
the encoding symbols. The Reed-Solomon codes introduced in this
document are systematic.
'Source Block' s group of ADUs which are to be FEC protected as a
single block.
'Packet Erasure Channel' a communication path where packets are
either dropped (e.g., by a congested router, or because the number
of transmission errors exceeds the correction capabilities of the
physical layer codes) or received. When a packet is received, it
is assumed that this packet is not corrupted.
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 layer The FEC Framework is described in terms of an additional layer
between the transport layer (e.g. UDP or DCCP) and protocols running between the transport layer (e.g. UDP or DCCP) and protocols running
over this transport layer. Examples of such protocols are RTP, RTCP, over this transport layer. Examples of such protocols are RTP, RTCP,
etc. As such, the data path interface between the FEC Framework and etc. As such, the data path interface between the FEC Framework and
both underlying and overlying layers can be thought of as being the both underlying and overlying layers can be thought of as being the
same as the standard interface to the transport layer - i.e. the data same as the standard interface to the transport layer - i.e. the data
exchanged consists of datagram payloads each associated with a single exchanged consists of datagram payloads each associated with a single
transport flow identified (in the case of UDP) by the standard ADU flow identified (in the case of UDP) by the standard 5-tuple {
5-tuple { Source IP Address, Source Transport Port, Destination IP Source IP Address, Source Transport Port, Destination IP Address,
Address, Destination Transport Port, Transport Protocol }. In the Destination Transport Port, Transport Protocol }. In the case that
case that RTP is used for the repair flows, the source and repair RTP is used for the repair flows, the source and repair data may be
data may be multiplexed using RTP onto a single UDP flow and must multiplexed using RTP onto a single UDP flow and must consequently be
consequently be demultiplexed at the receiver. There are various demultiplexed at the receiver. There are various ways in which this
ways in which this multiplexing can be done, for example as described multiplexing can be done, for example as described in [RFC4588].
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 It is important to understand that the main purpose of the FEC
Framework architecture is to allocate fuctional responsibilities to Framework architecture is to allocate fuctional responsibilities to
separately documented components in such a way that specific separately documented components in such a way that specific
instances of the components can be combined in different ways to instances of the components can be combined in different ways to
describe different protocols. 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 defines the FEC encoding and decoding and defines the The FEC Scheme defines the FEC encoding and decoding and defines the
protocol fields and procedures used to identify packet payload data protocol fields and procedures used to identify packet payload 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 ADUs to the FEC Scheme for FEC
to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC encoding. The FEC Scheme returns repair symbols with their
repair packet payloads, encoded FEC Payload ID information for each associated Repair FEC Payload IDs, and in some case Source FEC
of the repair packets and, in some cases, encoded FEC Payload ID Payload IDs, depending on the FEC Scheme. 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.
This document defines certain FEC Framework Configuration Information This document defines certain FEC Framework Configuration Information
which MUST be available to both sender and receiver(s). For example, which MUST be available to both sender and receiver(s). For example,
this information includes the specification of the transport flows this information includes the specification of the ADU flows which
which are to be FEC protected, specification of the transport flow(s) are to be FEC protected, specification of the ADU flow(s) which will
which will carry the FEC protection (repair) data and the carry the FEC protection (repair) data and the relationship(s)
relationship(s) between these 'source' and 'repair' flows (i.e. which between these source and repair flows (i.e. which source flow(s) are
source flow(s) are protected by each repair flow. The FEC Framework protected by each repair flow. The FEC Framework Configuration
Configuration Information also includes information fields which are Information also includes information fields which are specific to
specific to the FEC Scheme. This information is analagous to the FEC the FEC Scheme. This information is analagous to the FEC Object
Object Transmission Information defined in [RFC5052]. 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 data units (referred to here as layer supports the concepts of data units (referred to here as
Application Data Units) to be transported and identification of Application Data Units) to be transported and identification of ADU
transport flows on which those data units are transported. Since flows on which those data units are transported. Since this is an
this is an interface internal to the architecture, we do not specify interface internal to the architecture, we do not specify this
this interface explicitly, except to say that transport flows which interface explicitly, except to say that ADU flows which are distinct
are distinct from the transport layer point of view (for example, from the transport layer point of view (for example, distinct UDP
distinct UDP flows as identified by the UDP source/destination ports/ flows as identified by the UDP source/destination ports/addresses)
addresses) are also distinct on the interface between the transport are also distinct on the interface between the transport layer and
layer and the FEC Framework. 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 ADU flows which
which might be protected by the FEC Framework. From the FEC might be protected by the FEC Framework. From the FEC Framework
Framework point of view, RTP source flows are sequences of UDP packet point of view, RTP source flows are ADU flows like any other, with
payloads like any other protocol over UDP. the RTP header included within the ADU.
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.
The architecture outlined above is illustrated in the Figure 1. In The architecture outlined above is illustrated in the Figure 1. In
this architecture, two RTP instances are shown, for the source and this architecture, two RTP instances are shown, for the source and
repair data respectively. This is because the use of RTP for the 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 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 the repair data. The appearance of two RTP instances is more natural
when you consider that in many FEC codes, the the repair payload when you consider that in many FEC codes, the repair payload contains
contains parity bytes calculated across the RTP headers of the source repair data calculated across the RTP headers of the source packets.
packets. Thus a repair packet carried over RTP starts with an RTP Thus a repair packet carried over RTP starts with an RTP header of
header of its own which is immediately followed by parity data its own which is followed (after the Repair Payload ID) by repair
containing bytes which protect the source RTP headers (as well as data containing bytes which protect the source RTP headers (as well
parity data for the source RTP payloads). as repair data for the source RTP payloads).
+--------------------------------------------+ +--------------------------------------------+
| Application | | Application |
+--------------------------------------------+ +--------------------------------------------+
| |
| |
| |
+ - - - - - - - - - - - - - - - - - - - - - - - -+ + - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ | | +--------------------------------------------+ |
| Application Layer | | Application Layer |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| | | |
| + -- -- -- -- -- -- -- -- -- -- --+ | | | + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP | | | RTP (optional) | |
| | | |-Configuration/Coordination | | | |-Configuration/Coordination
+- -- -- -- -- -- -- -- -- -- -- -+ | +- -- -- -- -- -- -- -- -- -- -- -+ |
| | | | | | | |
| Transport flows | | ADU flows |
| | v | | | v |
+--------------------------------------------+ +----------------+ +--------------------------------------------+ +----------------+
| | FEC Framework (this document) |<--->| FEC Scheme | | | FEC Framework (this document) |<--->| FEC Scheme |
+--------------------------------------------+ +----------------+ +--------------------------------------------+ +----------------+
| | | | | | | |
Source | Repair | Source | Repair |
| | | | | | | |
+-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
| | RTP | | RTP processing | |<--- Optional | | RTP | | RTP processing | |<--- Optional
| | +-- -- -- |- -- -+ | - dependent on | | +-- -- -- |- -- -+ | - dependent on
skipping to change at page 14, line 25 skipping to change at page 14, line 25
blocks' each consisting of a set of Application Data Units, possibly blocks' each consisting of a set of Application Data Units, possibly
from multiple Source Data Flows which are to be protected together. from multiple Source Data Flows which are to be protected together.
For example, each source block may be constructed from those For example, each source block may be constructed from those
Application Data Units related to a particular segment in time of the Application Data Units related to a particular segment in time of the
flow. 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, FEC Payload IDs for each of the source payloads
payloads (encoded according to an FEC-Scheme-specific format)
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 FEC Payload IDs for each of the repair packet payloads (encoded
according to an FEC-Scheme-specific format)
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 Application Data the FEC payload IDs, if provided, to each of the Application Data
Units, 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
Application Data Units are included in which source blocks or the Application Data Units are included in which source blocks or the
sending order and timing of FEC source and FEC repair packets. A sending order and timing of FEC source and FEC repair packets. A
specific Content Delivery Protocol MAY define this mapping or it MAY specific Content Delivery Protocol MAY define this mapping or it MAY
be left 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 a mimimum length
time it should wait to receive FEC repair packets for any given of time that it should wait to receive FEC repair packets for any
source block. The sequence of operations at the sender is described given source block. FEC Schemes MAY define limitations on this
in more detail in Section 5.2. mapping, such as maximum size of source blocks, but SHOULD NOT
attempt to define specific mappings. The sequence of operations at
the sender is described in more detail in Section 5.2.
At the receiver, original Application Data Units are recovered by the At the receiver, original Application Data Units are recovered by the
FEC Framework directly from any FEC Source Packets received simply by FEC Framework directly from any FEC Source Packets received simply by
removing the Source FEC Payload ID, if present. The receiver also removing the Source FEC Payload ID, if present. The receiver also
passes the contents of the received Application Data Units, plus passes the contents of the received Application Data Units, plus
their FEC Payload IDs to the FEC Scheme for possible decoding. their FEC Payload IDs to the FEC Scheme for possible decoding.
If any Application Data Units related to a given source block have If any Application Data Units related to a given source block have
been lost, then the FEC Scheme may perform FEC decoding to recover been lost, then the FEC Scheme may perform FEC decoding to recover
the missing Application Data Units (assuming sufficient FEC Source the missing Application Data Units (assuming sufficient FEC Source
skipping to change at page 16, line 36 skipping to change at page 16, line 41
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 using 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 the FEC Payload IDs and repair packet payloads provided by the FEC
Scheme. 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 ADU flow identification information as would have been
been used for the original source packets if the FEC Framework used for the original source packets if the FEC Framework were not
were not present (for example, in the UDP case, the UDP source and 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 IP datagram carrying the
Packet will be the same whether or not the FEC Framework is Source Packet will be the same whether or not the FEC Framework is
applied). applied).
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) Application Data Units | (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,+------------------+
| Repair transport payloads | Repair symbols
| |
| (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
skipping to change at page 18, line 18 skipping to change at page 18, line 18
| |
| (1) Application Data Units | (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 payloads |(5) Ex src FEC Payload Ids,| |
+----------------------+ Repair FEC Payload Ids,+------------------+ +----------------------+ Repair FEC Payload Ids,+------------------+
| | Repair RTP payloads | | Repair symbols
|(7) Source | |(7) Source |
| |(7') Repair RTP payloads | |(7') Repair RTP payloads
| + -- -- -- -- -+ | + -- -- -- -- -+
| | RTP | | | RTP |
| +-- -- -- -- --+ | +-- -- -- -- --+
v v v v
+----------------------+ +----------------------+
| Transport Layer | | Transport Layer |
| (e.g. UDP ) | | (e.g. UDP ) |
+----------------------+ +----------------------+
skipping to change at page 18, line 43 skipping to change at page 18, line 43
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 Source Data Flow to which it belongs (in the case Repair) and the Source Data Flow to which it belongs (in the case
of source packets) is indicated by the transport flow information of source packets) is indicated by the ADU flow information which
which identifies the flow at the transport layer (for example identifies the flow at the transport layer (for example source and
source and destination ports and addresses in the case of UDP). 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).
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
skipping to change at page 19, 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 Application Data Unit to the FEC 5. The FEC Scheme returns the Application Data Units to the FEC
Framework in the form of source blocks containing received and Framework in the form of source blocks containing received and
decoded Application Data Units and indications of any Application decoded Application Data Units and indications of any Application
Data Units which 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 6. The FEC Framework passes the received and recovered
Application Data Units to the application. Application Data Units to the application.
Note that the description above defines functionality
responsibilities but does not imply a specific set of timing
relationships. For example, ADUs may eb provided to the application
as soon as they are received or recovered (and hence potentially out-
of-order) or they may be buffered are delivered to the application
in-order.
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
| (6) Application Data Units | (6) Application Data Units
| |
+----------------------+ +------------------+ +----------------------+ +------------------+
| FEC Framework | | | | FEC Framework | | |
| |<---------------------------| FEC Scheme | | |<---------------------------| FEC Scheme |
|(2)Extract FEC Payload| (5) Application Data Units | | |(2)Extract FEC Payload| (5) Application Data Units | |
skipping to change at page 21, line 38 skipping to change at page 21, line 38
+-- -- -- -- -- -- -- -+ +-- -- -- -- -- -- -- -+
| (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 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 ADUs 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 applied to re- Alternatively, buffering and packet re-ordering MAY be applied to re-
order received and reconstructed source packets into the order they order received and reconstructed source packets into the order they
were placed into the source block, if that is necessary according to were placed into the source block, if that is necessary according to
the application. the application.
6. Protocol Specification 6. Protocol Specification
skipping to change at page 22, line 34 skipping to change at page 22, line 34
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 Application Data Units 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 Application Data Units. The Framework from an ordered sequence of Application Data Units. The
allocation of Application Data Units to blocks is dependent on the allocation of Application Data Units to blocks is dependent on the
application. Note that some Application Data Units may not be application. Note that some Application Data Units may not be
included in any block. For each sApplication Data Units included in included in any block. Each Source Block provided to the FEC scheme
a source block, the following information is provided to the FEC consists of an ordered sequence of Application Data Units where the
Scheme: following information is provided for each ADU:
o A description of the Source Data Flow with which the Application o A description of the Source Data Flow with which the Application
Data Unit is associated (See 6.5) Data Unit is associated (See 6.5)
o The Application Data Unit itself o The Application Data Unit itself
o The length of the Application Data Unit 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 ADU flow.
+------------------------------------+ +------------------------------------+
| IP header | | IP header |
+------------------------------------+ +------------------------------------+
| Transport header | | Transport header |
+------------------------------------+ +------------------------------------+
| Application Data Unit | | 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 ADU flow as would
would have been used for the original source packets if the FEC have been used for the original source packets if the FEC Framework
Framework were not present. The transport payload of the FEC Source were not present. The transport payload of the FEC Source packet
packet MUST consist of the Application Data Unit followed by the MUST consist of the Application Data Unit followed by the Explicit
Explicit Source FEC Payload ID field, if required. 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
skipping to change at page 24, line 5 skipping to change at page 23, line 50
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.
In many applications, support for Forward Error Correction is added
to a pre-existing protocol and in this case use of the Explicit
Source FEC Payload ID may break backwards compatibility, since source
packets are modified.
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.
The allocation of sequence numbers to packets is independent of any The allocation of sequence numbers to packets is independent of any
FEC Scheme and of the Source Block contruction, except that the use FEC Scheme and of the Source Block contruction, except that the use
of this sequence number places a constraint on source block of this sequence number places a constraint on source block
construction source packets within a gioven source block MUST have construction source packets within a given source block MUST have
consecutive sequence numbers (where consecutive includes wrap-around consecutive sequence numbers (where consecutive includes wrap-around
from 65535 to 0). Sequence numbers SHOULD NOT be reused until all from 65535 to 0). Sequence numbers SHOULD NOT be reused until all
values in the sequence nmber space have been used. values in the sequence number 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 25, line 22 skipping to change at page 25, line 22
| Repair FEC Payload ID | | Repair FEC Payload ID |
+------------------------------------+ +------------------------------------+
| Repair Symbols | | Repair Symbols |
+------------------------------------+ +------------------------------------+
Figure 8: 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 ADU
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 the set of Source Data Flows. For example, in the case of UDP, of the set of Source Data Flows. For example, in the case of UDP,
each Source Data 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 the specified set of Source Data Flows, by means of packets of the specified set of Source Data Flows, by means of one or
one or more packet flows consisting of repair packets. The FEC more packet flows consisting of repair packets. The FEC Framework
Framework Configuation Information includes, for each instance of the Configuation Information includes, for each instance of the FEC
FEC Framework: 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 Data Flow protected by the FEC repair flow(s): 2. For each Source Data Flow protected by the FEC repair flow(s):
a. Defintion of the Source Data Flow carrying source packets a. Defintion of the Source Data Flow carrying source packets
(for 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.
skipping to change at page 30, line 18 skipping to change at page 30, line 18
performance: how much data arrived at the receiver, at what rate, performance: how much data arrived at the receiver, at what rate,
when etc. When FEC is added to such applications, feedback when etc. When FEC is added to such applications, feedback
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 [RFC5725].
Applications which used feedback for congestion control purposes MUST Applications which used feedback for congestion control purposes MUST
calculate such feedback on the basis of packets received before FEC calculate such feedback on the basis of packets received before FEC
recovery is applied. If this requirement conflicts with other uses recovery is applied. If this requirement conflicts with other uses
of the feedback information then the application MUST be enhanced to of the feedback information then the application MUST be enhanced to
support both information calculated pre- and post- FEC recovery. support both information calculated pre- and post- FEC recovery.
This is to ensure that congestion control mechanisms operate This is to ensure that congestion control mechanisms operate
correctly based on congestion indications recieved from the network, correctly based on congestion indications received from the network,
rather than on post-FEC recovery information which would give an rather than on post-FEC recovery information which would give an
inaccuate picture of congestion conditions. inaccurate 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)
skipping to change at page 37, line 7 skipping to change at page 37, line 7
The values that can be assigned within the FEC Framework (FECFRAME) The values that can be assigned within the FEC Framework (FECFRAME)
FEC Encoding ID registry are numeric indexes in the range [0, 255], FEC Encoding ID registry are numeric indexes in the range [0, 255],
boundaries included. Assignment requests are granted on a "IETF boundaries included. Assignment requests are granted on a "IETF
Consensus" basis as defined in[RFC5226] . Section 6.6 defines Consensus" basis as defined in[RFC5226] . Section 6.6 defines
explicit requirements that documents defining new FEC Encoding IDs explicit requirements that documents defining new FEC Encoding IDs
should meet. 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 part on [I-D.watson-tsvwg-fec-sf] and so
so thanks are due to the additional authors of that document, Mike thanks are due to the additional authors of that document, Mike Luby,
Luby, Magnus Westerlund and Stephan Wenger. That document was in Magnus Westerlund and Stephan Wenger. That document was in turn
turn based on the FEC streaming protocol defined by 3GPP in [MBMSTS] based on the FEC streaming protocol defined by 3GPP in [MBMSTS] and
and thus thanks are also due to the participants in 3GPP TSG SA thus thanks are also due to the participants in 3GPP TSG SA working
working group 4. group 4. Further thanks are due to the members of the FECFRAME
working group for their comments and review.
13. References 13. References
13.1. Normative 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,
skipping to change at page 38, line 37 skipping to change at page 38, line 37
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. 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] [RFC5725] 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 RTP Control Protocol (RTCP) Extended
Report Block Type for RTCP XR", Reports (XRs)", RFC 5725, February 2010.
draft-ietf-avt-post-repair-rtcp-xr-05 (work in progress),
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);
 End of changes. 54 change blocks. 
149 lines changed or deleted 213 lines changed or added

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