draft-ietf-fecframe-framework-10.txt   draft-ietf-fecframe-framework-11.txt 
FEC Framework Working Group M. Watson FEC Framework M. Watson
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Standards Track September 7, 2010 Intended status: Standards Track A. Begen
Expires: March 11, 2011 Expires: May 24, 2011 Cisco
November 20, 2010
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-10 draft-ietf-fecframe-framework-11
Abstract Abstract
This document describes a framework for using forward error This document describes 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 FEC to arbitrary packet flows over unreliable
over unreliable transport and is primarily intended for real-time, or transport and is primarily intended for real-time, or streaming,
streaming, media. This framework can be used to define Content media. This framework can be used to define Content Delivery
Delivery Protocols that provide Forward Error Correction for Protocols that provide FEC for streaming media delivery or other
streaming media delivery or other packet flows. Content Delivery packet flows. Content Delivery Protocols defined using this
Protocols defined using this framework can support any FEC Scheme framework can support any FEC scheme (and associated FEC codes) which
(and associated FEC codes) which is compliant with various is compliant with various requirements defined in this document.
requirements defined in this document. Thus, Content Delivery Thus, Content Delivery Protocols can be defined which are not
Protocols can be defined which are not specific to a particular FEC specific to a particular FEC scheme, and FEC schemes can be defined
Scheme and FEC Schemes can be defined which are not specific to a which are not specific to a particular Content Delivery Protocol.
particular Content Delivery Protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 11, 2011. This Internet-Draft will expire on May 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9
4. Procedural overview . . . . . . . . . . . . . . . . . . . . . 13 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 13
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15 4.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14
4.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 4.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Structure of the source block . . . . . . . . . . . . . . 21 5.2. Structure of the Source Block . . . . . . . . . . . . . . 21
5.3. Packet format for FEC Source packets . . . . . . . . . . . 21 5.3. Packet Format for FEC Source Packets . . . . . . . . . . . 21
5.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 23 5.3.1. Generic Explicit Source FEC Payload ID . . . . . . . . 23
5.4. Packet Format for FEC Repair packets . . . . . . . . . . . 23 5.4. Packet Format for FEC Repair Packets . . . . . . . . . . . 23
5.4.1. Packet Format for FEC Repair packets over RTP . . . . 23 5.4.1. Packet Format for FEC Repair Packets over RTP . . . . 23
5.5. FEC Framework Configuration Information . . . . . . . . . 24 5.5. FEC Framework Configuration Information . . . . . . . . . 24
5.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26 5.6. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 26
6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative requirements . . . . . . . . . . . . . . . . . . 32 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Normative Requirements . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative references . . . . . . . . . . . . . . . . . . . 36 12.1. Normative references . . . . . . . . . . . . . . . . . . . 36
12.2. Informative references . . . . . . . . . . . . . . . . . . 36 12.2. Informative references . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
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 packetized data from a source (sender) to one or more destinations of packetized 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.
Forward Error Correction is a well-known technique for improving Forward Error Correction (FEC) is a well-known technique for
reliability of packet transmission over networks which do not provide improving reliability of packet transmission over networks which do
guaranteed packet delivery, especially in multicast and broadcast not provide guaranteed packet delivery, especially in multicast and
applications. The FEC Building Block defined in [RFC5052] provides a broadcast applications. The FEC Building Block defined in [RFC5052]
framework for definition of Content Delivery Protocols (CDPs) for provides a framework for definition of Content Delivery Protocols
object delivery (including, primarily, file delivery) which make use (CDPs) for object delivery (including, primarily, file delivery)
of separately defined FEC Schemes. Any CDP defined according to the which make use of separately defined FEC schemes. Any CDP defined
requirements of the FEC Building Block can then easily be used with according to the requirements of the FEC Building Block can then
any FEC Scheme which is also defined according to the requirements of easily be used with any FEC scheme which is also defined according to
the FEC Building Block. (Note that the term "Forward Erasure the requirements of the FEC Building Block.
Correction" is sometimes used, 'erasures' being a type of error in
which data is lost and this loss can be detected, rather than being Note that the term "Forward Erasure Correction" is sometimes used,
received in corrupted form - the focus of this document is strictly erasures being a type of error in which data is lost and this loss
on erasures, however the term Forward Error Correction is more widely can be detected, rather than being received in corrupted form. The
used). focus of this document is strictly on erasures and, the term "Forward
Error Correction" is more widely used.
This document defines a framework for the definition of CDPs which This document defines a framework for the definition of CDPs which
provide for FEC protection of arbitrary packet flows over unreliable provide for FEC protection for arbitrary packet flows over unreliable
transports such as UDP. As such, this document complements the FEC transports such as UDP. As such, this document complements the FEC
Building Block of [RFC5052], by providing for the case of arbitrary Building Block of [RFC5052], by providing for the case of arbitrary
packet flows over unreliable transport, the same kind of framework as packet flows over unreliable transport, the same kind of framework as
that document provides for object delivery. This document does not that document provides for object delivery. This document does not
define a complete Content Delivery Protocol, but rather defines only define a complete CDP, but rather defines only those aspects that are
those aspects that are expected to be common to all Content Delivery expected to be common to all CDPs based on this framework.
Protocols based on this framework.
This framework does not define how the flows to be protected are This framework does not define how the flows to be protected are
determined, nor how the details of the protected flows and the FEC determined, nor how the details of the protected flows and the FEC
streams which protect them are communicated from sender to receiver. streams which protect them are communicated from sender to receiver.
It is expected that any complete Content Delivery Protocol It is expected that any complete CDP specification which makes use of
specification which makes use of this framework will address these this framework will address these signaling requirements. However,
signalling requirements. However, this document does specify the this document does specify the information which is required by the
information which is required by the FEC Framework at the sender and FEC Framework at the sender and receiver, e.g., details of the flows
receiver - for example details of the flows to be FEC protected, the to be FEC protected, the flow(s) that will carry the FEC protection
flow(s) that will carry the FEC protection data and an opaque data and an opaque container for FEC-Scheme-Specific Information.
container for FEC-Scheme-specific information.
FEC Schemes designed for use with this framework must fulfil a number FEC schemes designed for use with this framework must fulfill a
of requirements defined in this document. Note that these number of requirements defined in this document. These requirements
requirements are different from those defined in [RFC5052] for FEC are different from those defined in [RFC5052] for FEC schemes for
Schemes for object delivery. However there is a great deal of object delivery. However, there is a great deal of commonality and
commonality and FEC Schemes defined for object delivery may be easily FEC schemes defined for object delivery may be easily adapted for use
adapted for use with the framework defined here. with the framework defined in this document.
Since the RTP protocol layer is used over UDP, this framework can be Since the RTP protocol is (often) used over UDP, this framework can
applied to RTP flows as well. FEC repair packets may be sent be applied to RTP flows as well. FEC repair packets may be sent
directly over UDP or over RTP. The latter approach has the advantage directly over UDP or RTP. The latter approach has the advantage that
that RTP instrumentation, based on RTCP, can be used for the repair RTP instrumentation, based on RTP Control Protocol (RTCP), can be
flow. Additionally, the post-repair RTCP extended report [RFC5725] used for the repair flow. Additionally, the post-repair RTCP
may be used to obtain information about the loss rate after FEC extended reports [RFC5725] may be used to obtain information about
recovery. the loss rate after FEC 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 and Abbreviations
'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)
'AL-FEC' Application Layer Forward Error Correction Application Data Unit (ADU): The unit of source data provided as
payload to the transport layer.
'Application Data Unit' The unit of source data provided as payload ADU Flow: A sequence of ADUs associated with a transport-layer flow
to the transport layer identifier (such as the standard 5-tuple {Source IP address, source
port, destination IP address, destination port, transport protocol}).
'Application protocol' Control protocol used to establish and AL-FEC: Application-layer Forward Error Correction.
control the source data flow being protected - e.g. RTSP.
'Content Delivery Protocol (CDP)' A complete application protocol Application Protocol: Control protocol used to establish and control
specification which, through the use of the framework defined in the source flow being protected, e.g., RTSP.
this document, is able to make use of FEC Schemes to provide
Forward Error Correction capabilities
'FEC' Forward Error Correction. Content Delivery Protocol (CDP): A complete application protocol
specification which, through the use of the framework defined in this
document, is able to make use of FEC schemes to provide FEC
capabilities.
'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 resilient to data loss (Note: in general FEC Codes may flow is resilient to data loss. Note that in general FEC codes may
also be used to make a data flow resilient to corruption, but that also be used to make a data flow resilient to corruption, but that is
is not considered here). not considered in this document.
'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
this document. document.
'FEC Framework Configuration Information' Information which controls FEC Framework Configuration Information: Information which controls
the operation of the FEC Framework. the operation of the FEC Framework.
'FEC Payload ID' Information which identifies the contents of a FEC Payload ID: Information which identifies the contents of a packet
packet with respect to the FEC Scheme. with respect to the FEC scheme.
'FEC Repair Packet' At a sender (respectively, at a receiver) a FEC Repair Packet: At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the Transport payload submitted to (respectively, received from) the transport
protocol containing one or more repair symbols along with a Repair protocol containing one or more repair symbols along with a Repair
FEC Payload ID and possibly an RTP header. FEC Payload ID and possibly an RTP header.
'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.
Framework, or, in the context of RMT, with the RMT FEC Building
Block.
'FEC Source Packet' At a sender (respectively, at a receiver) a FEC Source Packet: At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the Transport payload submitted to (respectively, received from) the transport
protocol containing an ADU along with an optional Source FEC protocol containing an ADU along with an optional Explicit Source FEC
Payload ID. Payload ID.
'Protection amount' The relative increase in data sent due to the Protection Amount: The relative increase in data sent due to the use
use of FEC. of FEC.
'Repair data flow' The packet flow or flows carrying forward error Repair Flow: The packet flow carrying FEC data.
correction data
'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.
'Source data flow' The packet flow or flows to which FEC protection Source Flow: The packet flow to which FEC protection is to be
is to be applied. A source data flow consists of ADUs. applied. A source flow consists of ADUs.
'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.
'Source protocol' A protocol used for the source data flow being Source Protocol: A protocol used for the source flow being protected,
protected - e.g. RTP. e.g., RTP.
'Transport protocol' The protocol used for transport of the source Transport Protocol: The protocol used for transport of the source and
and repair data flows - e.g. UDP, DCCP. repair flows, e.g., UDP and DCCP.
The following definitions are aligned with [RFC5052] The following definitions are aligned with [RFC5052]:
'Code rate' the ratio between the number of source symbols and the Code Rate: The ratio between the number of source symbols and the
number of encoding symbols. By definition, the code rate is such 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 that 0 < code rate <= 1. A code rate close to 1 indicates that a
small number of repair symbols have been produced during the small number of repair symbols have been produced during the encoding
encoding process. process.
'Encoding symbol' unit of data generated by the encoding process. Encoding Symbol: Unit of data generated by the encoding process.
With systematic codes, source symbols are part of the encoding With systematic codes, source symbols are part of the encoding
symbols. symbols.
'Packet Erasure Channel' a communication path where packets are Packet Erasure Channel: A communication path where packets are either
either dropped (e.g., by a congested router, or because the number dropped (e.g., by a congested router, or because the number of
of transmission errors exceeds the correction capabilities of the transmission errors exceeds the correction capabilities of the
physical layer codes) or received. When a packet is received, it physical-layer codes) or received. When a packet is received, it is
is assumed that this packet is not corrupted. assumed that this packet is not corrupted.
'Repair symbol' encoding symbol that is not a source symbol. Repair Symbol: Encoding symbol that is not a source symbol.
'Source Block' group of ADUs which are to be FEC protected as a Source Block: Group of ADUs which are to be FEC protected as a single
single block. block.
'Source symbol' unit of data used during the encoding process. Source Symbol: Unit of data used during the encoding process.
'Systematic code' FEC code in which the source symbols are part of Systematic Code: FEC code in which the source symbols are part of the
the encoding symbols. The Reed-Solomon codes introduced in this encoding symbols.
document are systematic.
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].
3. Architecture Overview 3. 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. As such, the data path interface between
etc. As such, the data path interface between the FEC Framework and the FEC Framework and both underlying and overlying layers can be
both underlying and overlying layers can be thought of as being the thought of as being the same as the standard interface to the
same as the standard interface to the transport layer - i.e. the data transport layer, i.e., the data exchanged consists of datagram
exchanged consists of datagram payloads each associated with a single payloads each associated with a single ADU flow identified by the
ADU flow identified (in the case of UDP) by the standard 5-tuple { standard 5-tuple {Source IP address, source port, destination IP
Source IP Address, Source Transport Port, Destination IP Address, address, destination port, transport protocol}. In the case that RTP
Destination Transport Port, Transport Protocol }. In the case that is used for the repair flows, the source and repair data can be
RTP is used for the repair flows, the source and repair data may be multiplexed using RTP onto a single UDP flow and needs to be
multiplexed using RTP onto a single UDP flow and must consequently be consequently demultiplexed at the receiver. There are various ways
demultiplexed at the receiver. There are various ways in which this in which this multiplexing can be done, for example as described in
multiplexing can be done, for example as described in [RFC4588]. [RFC4588].
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 functional responsibilities to Framework architecture is to allocate functional 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 ADUs to the FEC Scheme for FEC encoder, the FEC Framework passes ADUs to the FEC scheme for FEC
encoding. The FEC Scheme returns repair symbols with their encoding. The FEC scheme returns repair symbols with their
associated Repair FEC Payload IDs, and in some case Source FEC associated Repair FEC Payload IDs, and in some cases Source FEC
Payload IDs, depending on the FEC Scheme. At a decoder, the FEC Payload IDs, depending on the FEC scheme. 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 ADU flows which this information includes the specification of the ADU flows which
are to be FEC protected, specification of the ADU flow(s) which will are to be FEC protected, specification of the ADU flow(s) which will
carry the FEC protection (repair) data and the relationship(s) carry the FEC protection (repair) data and the relationship(s)
between these source and repair flows (i.e. which source flow(s) are between these source and repair flows (i.e., which source flow(s) are
protected by each repair flow. The FEC Framework Configuration protected by each repair flow(s)). The FEC Framework Configuration
Information also includes information fields which are specific to Information also includes information fields which are specific to
the FEC Scheme. This information is analogous to the FEC Object the FEC scheme. This information is analogous to the FEC 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 has to be defined by any CDP specification as described in the
as described in the following sections. 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 ADU Application Data Units (ADUs)) to be transported and identification
flows on which those data units are transported. Since this is an of ADU flows on which those data units are transported. Since this
interface internal to the architecture, we do not specify this is an interface internal to the architecture, we do not specify this
interface explicitly. We do require that ADU flows which are interface explicitly. We do require that ADU flows which are
distinct from the transport layer point of view (for example, distinct from the transport layer point of view (for example,
distinct UDP flows as identified by the UDP source/destination ports/ distinct UDP flows as identified by the UDP source/destination
addresses) are also distinct on the interface between the transport addresses/ports) are also distinct on the interface between the
layer and the FEC Framework. transport layer and the FEC Framework.
As noted above, RTP flows are a specific example of ADU flows which As noted above, RTP flows are a specific example of ADU flows which
might be protected by the FEC Framework. From the FEC Framework might be protected by the FEC Framework. From the FEC Framework
point of view, RTP source flows are ADU flows like any other, with point of view, RTP source flows are ADU flows like any other, with
the RTP header included within the ADU. 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 can 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 has to 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 (optional) RTP instances are shown, for the
repair data respectively. This is because the use of RTP for the source and repair data respectively. This is because the use of RTP
source data is separate from and independent of the use of RTP for for the source data is separate from and independent of the use of
the repair data. The appearance of two RTP instances is more natural RTP for the repair data. The appearance of two RTP instances is more
when you consider that in many FEC codes, the repair payload contains natural when one considers that in many FEC codes, the repair payload
repair data calculated across the RTP headers of the source packets. contains repair data calculated across the RTP headers of the source
Thus a repair packet carried over RTP starts with an RTP header of packets. Thus, a repair packet carried over RTP starts with an RTP
its own which is followed (after the Repair Payload ID) by repair header of its own which is followed (after the Repair Payload ID) by
data containing bytes which protect the source RTP headers (as well repair data containing bytes which protect the source RTP headers (as
as repair data for the source RTP payloads). well as repair data for the source RTP payloads).
+--------------------------------------------+ +--------------------------------------------+
| Application | | Application |
+--------------------------------------------+ +--------------------------------------------+
| |
| |
| |
+ - - - - - - - - - - - - - - - - - - - - - - - -+ + - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ | | +--------------------------------------------+ |
| Application Layer | | Application Layer |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| | | |
| + -- -- -- -- -- -- -- -- -- -- --+ | | | + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP (optional) | | | RTP (Optional) | |
| | | |-Configuration/Coordination | | | |- Configuration/Coordination
+- -- -- -- -- -- -- -- -- -- -- -+ | +- -- -- -- -- -- -- -- -- -- -- -+ |
| | | | | | | |
| ADU 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 Layer | | RTP Processing | | |
| | +-- -- -- |- -- -+ | - dependent on | (Optional) | +-- -- -- |- -- -+ |
| | +-- -- -- -- -- -- -- |--+ | | FEC Scheme | | +-- -- -- -- -- -- -- |--+ | |
| | RTP (de)multiplexing | | | | RTP (De)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
| |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| Transport Layer (e.g. UDP) | | Transport Layer (e.g., UDP) |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| IP | | IP |
| +--------------------------------------------+ | | +--------------------------------------------+ |
Content Delivery Protocol
+ - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework Architecture | Content Delivery Protocol |
+ - - - - - - - - - - - - - - - - - - - - - - - +
The contents of the transport payload for repair packets is fully Figure 1: FEC Framework architecture
defined by the FEC Scheme. For a specific FEC Scheme, a means MAY be
The content of the transport payload for repair packets is fully
defined by the FEC scheme. For a specific FEC scheme, a means MAY be
defined for repair data to be carried over RTP, in which case the defined for repair data to be carried over RTP, in which case the
repair packet payload format starts with the RTP header. This repair packet payload format starts with the RTP header. This
corresponds to defining an RTP Payload Format for the specific FEC corresponds to defining an RTP payload format for the specific FEC
Scheme. Guidelines for writers of RTP Payload Formats are provided scheme.
in [RFC2736].
The use of RTP for repair packets is independent of the protocols The use of RTP for repair packets is independent of the protocols
used for source packets: if RTP is used for source packets then used for source packets: if RTP is used for source packets, repair
repair packets may or may not use RTP and vice versa (although it is packets may or may not use RTP and vice versa (although it is
unlikely that there are useful scenarios where non-RTP source flows unlikely that there are useful scenarios where non-RTP source flows
are protected by RTP repair flows). FEC Schemes are expected to are protected by RTP repair flows). FEC schemes are expected to
recover entire transport payloads for recovered source packets in all recover entire transport payloads for recovered source packets in all
cases. For example if RTP is used for source flows, the FEC Scheme cases. For example, if RTP is used for source flows, the FEC scheme
is expected to recover the entire UDP payload, including the RTP is expected to recover the entire UDP payload, including the RTP
header. header.
4. Procedural overview 4. Procedural Overview
4.1. General 4.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 Application Data Units which can be protected restrictions on the ADUs which can be protected together, except that
together, except that the Application Data Unit is carried over a the ADU is carried over a supported transport protocol (See
supported transport protocol (See Section 7). The data may be from Section 7). The data can be from multiple source flows that are
multiple Source Data Flows that are protected jointly. The FEC protected jointly. The FEC Framework handles the source flows as a
framework handles the Source Data Flows as a sequence of 'source sequence of source blocks each consisting of a set of ADUs, possibly
blocks' each consisting of a set of Application Data Units, possibly from multiple source flows which are to be protected together. For
from multiple Source Data Flows which are to be protected together. example, each source block can be constructed from those ADUs related
For example, each source block may be constructed from those 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, FEC Payload IDs for each of the source payloads o Optionally, FEC Payload IDs for each of the source payloads
(encoded according to an FEC-Scheme-specific format) (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 FEC Payload IDs for each of the repair packet payloads (encoded o FEC Payload IDs for each of the repair packet payloads (encoded
according to an FEC-Scheme-specific format) according to an FEC-Scheme-Specific format).
The FEC framework then performs two operations: Firstly, it appends The FEC Framework then performs two operations. First, it appends
the FEC payload IDs, if provided, to each of the Application Data the Source FEC Payload IDs, if provided, to each of the ADUs, and
Units, and sends the resulting packets, known as 'FEC source sends the resulting packets, known as FEC source packets, to the
packets', to the receiver and secondly it places the provided 'FEC receiver, and second it places the provided FEC repair packet
repair packet payloads' and corresponding 'FEC Repair Payload IDs' payloads and corresponding Repair FEC Payload IDs appropriately to
appropriately to construct 'FEC repair packets' and send them to the construct FEC repair packets and send them to the receiver.
receiver. Note that FEC repair packets MAY be sent to a different
multicast group or groups from the source packets.
This document does not define how the sender determines which This document does not define how the sender determines which ADUs
Application Data Units are included in which source blocks or the are included in which source blocks or the sending order and timing
sending order and timing of FEC source and FEC repair packets. A of FEC source and repair packets. A specific CDP MAY define this
specific Content Delivery Protocol MAY define this mapping or it MAY mapping or it MAY be left as implementation dependent at the sender.
be left as implementation dependent at the sender. However, a CDP However, a CDP specification MUST define how a receiver determines a
specification MUST define how a receiver determines a minimum length minimum length of time that it needs to wait to receive FEC repair
of time that it should wait to receive FEC repair packets for any packets for any given source block. FEC schemes MAY define
given source block. FEC Schemes MAY define limitations on this limitations on this mapping, such as maximum size of source blocks,
mapping, such as maximum size of source blocks, but SHOULD NOT but SHOULD NOT attempt to define specific mappings. The sequence of
attempt to define specific mappings. The sequence of operations at operations at the sender is described in more detail in Section 4.2.
the sender is described in more detail in Section 4.2.
At the receiver, original Application Data Units are recovered by the At the receiver, original ADUs are recovered by the FEC Framework
FEC Framework directly from any FEC Source Packets received simply by directly from any FEC source packets received simply by removing the
removing the Source FEC Payload ID, if present. The receiver also Source FEC Payload ID, if present. The receiver also passes the
passes the contents of the received Application Data Units, plus contents of the received ADUs, plus their FEC Payload IDs to the FEC
their FEC Payload IDs to the FEC Scheme for possible decoding. scheme for possible decoding.
If any Application Data Units related to a given source block have If any ADUs related to a given source block have been lost, then the
been lost, then the FEC Scheme may perform FEC decoding to recover FEC scheme can perform FEC decoding to recover the missing ADUs
the missing Application Data Units (assuming sufficient FEC Source (assuming sufficient FEC source and repair packets related to that
and FEC Repair packets related to that source block have been source block have been received).
received).
Note that the receiver may need to buffer received source packets to Note that the receiver might need to buffer received source packets
allow time for the FEC Repair packets to arrive and FEC decoding to to allow time for the FEC repair packets to arrive and FEC decoding
be performed before some or all of the received or recovered packets to be performed before some or all of the received or recovered
are passed to the application. If such a buffer is not provided, packets are passed to the application. If such a buffer is not
then the application must be able to deal with the severe re-ordering provided, then the application has to be able to deal with the severe
of packets that may occur. However, such buffering is Content re-ordering of packets that can occur. However, such buffering is
Delivery Protocol and/or implementation-specific and is not specified CDP and/or implementation-specific and is not specified here. The
here. The receiver operation is described in more detail in receiver operation is described in more detail in Section 4.3.
Section 4.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 Application Data Unit. specific to the FEC scheme) occupied by the ADU. This information is
This information is known as the 'Source FEC Payload ID'. The FEC known as the Source FEC Payload ID. The FEC scheme is responsible
Scheme is responsible for defining and interpreting this information. for defining and interpreting this information. This information MAY
This information MAY be encoded into a specific field within the FEC be encoded into a specific field within the FEC source packet format
Source packet format defined in this specification, called the defined in this specification, called the Explicit Source FEC Payload
Explicit Source FEC Payload ID field. The exact contents and format ID field. The exact contents and format of the Explicit Source FEC
of the Explicit Source FEC Payload ID field are defined by the FEC Payload ID field are defined by the FEC schemes. Alternatively, the
Scheme. Alternatively, the FEC Scheme MAY define how the Source FEC FEC scheme MAY define how the Source FEC Payload ID is derived from
Payload ID is derived from other fields within the source packets. other fields within the source packets. This document defines the
This document defines the way that the Explicit Source FEC Payload ID way that the Explicit Source FEC Payload ID field is appended to
field is appended to source packets to form FEC Source packets. 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
payloads and the original source block. This is known as the 'Repair payloads and the original source block. This is known as the Repair
FEC Payload ID'. This information MUST be encoded into a specific FEC Payload ID. This information MUST be encoded into a specific
field, the Repair FEC Payload ID field, the contents and format of field, the Repair FEC Payload ID field, the contents and format of
which are defined by the FEC Scheme. which are defined by the FEC schemes.
The FEC Scheme MAY use different FEC Payload ID field formats for FEC The FEC scheme MAY use different FEC Payload ID field formats for
Source packets and FEC Repair packets. source and repair packets.
4.2. Sender Operation 4.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 could be carrying any type of
indeed any other type of packet. The following operations, data. The following operations, illustrated in Figure 2, for the
illustrated in Figure 2, for the case of UDP repair flows and case of UDP repair flows and Figure 3 for the case of RTP repair
Figure 3 for the case of RTP repair flows, describe a possible way to flows, describe a possible way to generate compliant source and
generate compliant FEC Source packet and FEC repair packet streams: repair flows:
1. Application Data Units are provided by the application. 1. ADUs are provided by the application.
2. A source block is constructed as specified in Section 5.2. 2. A source block is constructed as specified in Section 5.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
each repair payload. for 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
Payload IDs and repair packet payloads are provided back from the IDs and repair packet payloads are provided back from the FEC
FEC Scheme to the FEC Framework. 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 5.3 and FEC Repair packets according to Section 5.4 using Section 5.3 and FEC repair packets according to Section 5.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
Scheme. FEC scheme.
7. The FEC Source and FEC Repair packets are sent using normal 7. The FEC source and 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)
be used for FEC Repair packets are defined in the FEC Framework to be used for FEC repair packets are defined in the FEC
Configuration Information. The FEC Source packets are sent using Framework Configuration Information. The FEC source packets are
the same ADU flow identification information as would have been sent using the same ADU flow identification information as would
used for the original source packets if the FEC Framework were not have been used for the original source packets if the FEC
present (for example, in the UDP case, the UDP source and Framework were not present (for example, in the UDP case, the UDP
destination addresses and ports on the IP datagram carrying the source and destination addresses and ports on the IP datagram
Source Packet will be the same whether or not the FEC Framework is carrying the source packet will be the same whether or not the
applied). FEC Framework is applied).
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) Application Data Units |(1) ADUs
| |
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 |<--------------------------| |
| packets and FEC | | | | source and repair | | |
| repair packets |(5) Ex src FEC Payload Ids,| | | packets |(5) Explicit Source FEC | |
+----------------------+ Repair FEC Payload Ids,+------------------+ +----------------------+ Payload IDs +------------------+
| Repair symbols | Repair FEC Payload IDs
| | Repair symbols
| (7) FEC Source packets and FEC repair packets |
v |(7) FEC source and repair packets
+----------------------+ v
| Transport Layer | +----------------------+
| (e.g. UDP ) | | Transport Layer |
+----------------------+ | (e.g., UDP) |
+----------------------+
Figure 2: Sender operation Figure 2: Sender operation
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) Application Data Units |(1) ADUs
v |
+----------------------+ +------------------+ v
| FEC Framework | | | +----------------------+ +------------------+
| |-------------------------->| FEC Scheme | | FEC Framework | | |
|(2) Construct source | (3) Source Block | | | |-------------------------->| FEC Scheme |
| blocks | | (4) FEC Encoding | |(2) Construct source |(3) Source Block | |
|(6) Construct FEC src |<--------------------------| | | blocks | | (4) FEC Encoding |
| packets and FEC | | | |(6) Construct FEC |<--------------------------| |
| repair payloads |(5) Ex src FEC Payload Ids,| | | source packets and| | |
+----------------------+ Repair FEC Payload Ids,+------------------+ | repair payloads |(5) Explicit Source FEC | |
| | Repair symbols +----------------------+ Payload IDs +------------------+
|(7) Source | | | Repair FEC Payload IDs
| |(7') Repair RTP payloads | | Repair symbols
| + -- -- -- -- -+ | |
| | RTP | |(7) Source |(7') Repair payloads
| +-- -- -- -- --+ | packets |
v v | |
+----------------------+ | + -- -- -- -- -+
| Transport Layer | | | RTP |
| (e.g. UDP ) | | +-- -- -- -- --+
+----------------------+ v v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 3: Sender operation with RTP repair flows Figure 3: Sender operation with RTP repair flows
4.3. Receiver Operation 4.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
passed to the FEC Framework. The type of packet (Source or to the FEC Framework. The type of packet (source or repair) and
Repair) and the Source Data Flow to which it belongs (in the case the source flow to which it belongs (in the case of source
of source packets) is indicated by the ADU flow information which packets) is indicated by the ADU flow information which
identifies the flow at the transport layer (for example source and identifies the flow at the transport layer.
destination ports and addresses in the case of UDP).
1a. In the special case that RTP is used for repair packets and
source and repair packets are multiplexed onto the same UDP flow,
then RTP demultiplexing is required to demultiplex source and
repair flows. However, RTP processing is applied only to the
repair packets at this stage: source packets continue to be
handled as UDP payloads (i.e. including their RTP headers).
2. The FEC Framework extracts the Explicit Source FEC Payload ID In the special case that RTP is used for repair packets, and
field (if present) from FEC Source Packets and the Repair FEC source and repair packets are multiplexed onto the same UDP flow,
Payload ID from FEC Repair Packets. then RTP demultiplexing is required to demultiplex source and
repair flows. However, RTP processing is applied only to the
repair packets at this stage; source packets continue to be
handled as UDP payloads (i.e., including their RTP headers).
3. The Explicit Source FEC Payload IDs (if present), Repair FEC 2. The FEC Framework extracts the Explicit Source FEC Payload ID
Payload IDs, FEC Source payloads and FEC Repair payloads are field (if present) from the source packets and the Repair FEC
passed to the FEC Scheme. Payload ID from the repair packets.
4. The FEC Scheme uses the received FEC Payload IDs (and derived 3. The Explicit Source FEC Payload IDs (if present), Repair FEC
FEC Source Payload IDs in the case that the Explicit Source FEC Payload IDs, FEC source and repair payloads are passed to the FEC
Payload ID field is not used) to group source and repair packets scheme.
into source blocks. If at least one source packet is missing from
a source block, and at least one repair packet has been received
for the same source block then FEC decoding may be performed in
order to recover missing source payloads. The FEC Scheme
determines whether source packets have been lost and whether
enough data for decoding of any or all of the missing source
payloads in the source block has been received.
5. The FEC Scheme returns the Application Data Units to the FEC 4. The FEC scheme uses the received FEC Payload IDs (and derived FEC
Framework in the form of source blocks containing received and Source Payload IDs in the case that the Explicit Source FEC
decoded Application Data Units and indications of any Application Payload ID field is not used) to group source and repair packets
Data Units which were missing and could not be decoded. into source blocks. If at least one source packet is missing
from a source block, and at least one repair packet has been
received for the same source block then FEC decoding can be
performed in order to recover missing source payloads. The FEC
scheme determines whether source packets have been lost and
whether enough data for decoding of any or all of the missing
source payloads in the source block has been received.
6. The FEC Framework passes the received and recovered 5. The FEC scheme returns the ADUs to the FEC Framework in the form
Application Data Units to the application. of source blocks containing received and decoded ADUs and
indications of any ADUs which were missing and could not be
decoded.
Note that the description above defines functionality 6. The FEC Framework passes the received and recovered ADUs to the
responsibilities but does not imply a specific set of timing application.
relationships. For example, ADUs may be provided to the application
as soon as they are received or recovered (and hence potentially out-
of-order) or they may be buffered and delivered to the application
in-order.
+----------------------+ The description above defines functionality responsibilities but does
| Application | not imply a specific set of timing relationships. Source packets
+----------------------+ which are correctly received and those which are reconstructed MAY be
^ delivered to the application out of order and in a different order
| (6) Application Data Units from the order of arrival at the receiver. Alternatively, buffering
| and packet re-ordering MAY be applied to re-order received and
+----------------------+ +------------------+ reconstructed source packets into the order they were placed into the
| FEC Framework | | | source block, if that is necessary according to the application.
| |<---------------------------| FEC Scheme |
|(2)Extract FEC Payload| (5) Application Data Units | |
| IDs and pass IDs & | | (4) FEC Decoding |
| Payloads to FEC |--------------------------->| |
| Scheme | (3) Ex src FEC Payload IDs,| |
+----------------------+ FEC Repair Payload IDs,+------------------+
^ FEC Source Payloads,
| FEC Repair Payloads
|
| (1) FEC Source packets and FEC repair packets
|
+----------------------+
| Transport Layer |
| (e.g. UDP ) |
+----------------------+
Figure 4: Receiver Operation +----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +------------------+
| FEC Framework | | |
| |<---------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | | (4) FEC Decoding |
| payloads to FEC |--------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +------------------+
^ Repair FEC Payload IDs
| Source payloads
| Repair payloads
|
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
+----------------------+ Figure 4: Receiver operation
| Application |
+----------------------+
^
| (6) Application Data Units
|
+----------------------+ +------------------+
| FEC Framework | | |
| |<---------------------------| FEC Scheme |
|(2)Extract FEC Payload| (5) Application Data Units | |
| IDs and pass IDs & | | (4) FEC Decoding |
| Payloads to FEC |--------------------------->| |
| Scheme | (3) Ex src FEC Payload IDs,| |
+----------------------+ FEC Repair Payload IDs,+------------------+
^ ^ FEC Source Payloads,
| | FEC Repair Payloads
|Source pkts |
| |(1a) FEC repair payloads
+-- |- -- -- -- -- -- -+
|RTP| | RTP processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP demux | |
+-- -- -- -- -- -- -- -+
| (1) FEC Source packets and FEC repair packets
+----------------------+
| Transport Layer |
| (e.g. UDP ) |
+----------------------+
Figure 5: Receiver Operation +----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +------------------+
| FEC Framework | | |
| |<---------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | | (4) FEC Decoding |
| payloads to FEC |--------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +------------------+
^ ^ Repair FEC Payload IDs
| | Source payloads
| | Repair payloads
| |
|Source |Repair payloads
|packets |
| |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux | |
+-- -- -- -- -- -- -- -+
^
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Note that the above procedure may result in a situation in which not Figure 5: Receiver operation with RTP repair flows
all ADUs are recovered.
Source packets which are correctly received and those which are Note that the above procedure might result in a situation in which
reconstructed MAY be delivered to the application out of order and in not all ADUs are recovered.
a different order from the order of arrival at the receiver.
Alternatively, buffering and packet re-ordering MAY be applied to re-
order received and reconstructed source packets into the order they
were placed into the source block, if that is necessary according to
the application.
5. Protocol Specification 5. Protocol Specification
5.1. General 5.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 Application Data Units. 1. Construction of a source block from ADUs. The FEC code will be
The FEC code will be applied to this source block to produce the applied to this source block to produce the repair 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 Configuration Information. This configuration information Framework Configuration Information, which is defined in this
is also defined in this section. A complete protocol specification section. A complete protocol specification that uses this framework
that uses this framework MUST specify the means to determine and MUST specify the means to determine and communicate this information
communicate this information between sender and receiver. between sender and receiver.
5.2. Structure of the source block 5.2. Structure of the Source Block
The FEC Framework and FEC Scheme exchange Application Data Units in The FEC Framework and FEC scheme exchange ADUs in the form of source
the form of source blocks. A source block is generated by the FEC blocks. A source block is generated by the FEC Framework from an
Framework from an ordered sequence of Application Data Units. The ordered sequence of ADUs. The allocation of ADUs to blocks is
allocation of Application Data Units to blocks is dependent on the dependent on the application. Note that some ADUs may not be
application. Note that some Application Data Units may not be included in any block. Each source block provided to the FEC scheme
included in any block. Each Source Block provided to the FEC scheme consists of an ordered sequence of ADUs where the following
consists of an ordered sequence of Application Data Units where the information is provided for each ADU:
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 flow with which the ADU is associated
Data Unit is associated (See 6.5) with.
o The Application Data Unit itself o The ADU itself.
o The length of the Application Data Unit o The length of the ADU.
5.3. Packet format for FEC Source packets 5.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 ADU 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 ADU flow as would The FEC source packets MUST be sent using the same ADU flow as would
have been used for the original source packets if the FEC Framework have been used for the original source packets if the FEC Framework
were not present. The transport payload of the FEC Source packet were not present. The transport payload of the FEC source packet
MUST consist of the Application Data Unit followed by the Explicit MUST consist of the ADU followed by the Explicit Source FEC Payload
Source FEC Payload ID field, if required. 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. In the case that the FEC scheme or CDP defines a means to
means to derive the Source FEC Payload ID from other information in derive the Source FEC Payload ID from other information in the packet
the packet (for example a sequence number used by the application (for example a sequence number used by the application protocol),
protocol), then the Source FEC Payload ID field is not included in then the Source FEC Payload ID field is not included in the packet.
the packet. In this case the original source packet and FEC Source In this case, the original source packet and FEC source packet are
Packet are identical. identical.
In applications where avoidance of IP packet fragmentation is a goal, In applications where avoidance of IP packet fragmentation is a goal,
Content Delivery Protocols SHOULD consider the Explicit Source FEC CDPs SHOULD consider the Explicit Source FEC Payload ID size when
Payload ID size when determining the size of Application Data Units determining the size of ADUs that will be delivered using the FEC
that will be delivered using the FEC Framework. This is because the Framework. This is because the addition of the Explicit Source FEC
addition of the Explicit Source FEC Payload ID increases the packet Payload ID increases the packet length.
length.
Note: The Explicit Source FEC Payload ID is placed at the end of the The Explicit Source FEC Payload ID is placed at the end of the packet
packet so that in the case that Robust Header Compression [RFC3095] so that in the case that Robust Header Compression (ROHC) [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 are used with this
Framework should consider that FEC Schemes may add this Explicit framework need to consider that FEC schemes can 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 In many applications, support for FEC is added to a pre-existing
to a pre-existing protocol and in this case use of the Explicit protocol and in this case use of the Explicit Source FEC Payload ID
Source FEC Payload ID may break backwards compatibility, since source can break backwards compatibility, since source packets are modified.
packets are modified.
5.3.1. Generic Explicit Source FEC Payload Id 5.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 have to use the same Explicit Source
Payload Id format. In order to enable this, it is RECOMMENDED that FEC Payload ID format. In order to enable this, it is RECOMMENDED
FEC Schemes support the Generic Explicit Source FEC Payload Id format that FEC schemes support the Generic Explicit Source FEC Payload ID
described below. format described below.
The Generic Explicit Source FEC Payload Id has length of 2 bytes and The Generic Explicit Source FEC Payload ID has a length of two octets
consists of an unsigned packet sequence number in network byte order. and consists of an unsigned packet sequence number in network-byte
The allocation of sequence numbers to packets is independent of any order. The allocation of sequence numbers to packets is independent
FEC Scheme and of the Source Block construction, except that the use of any FEC scheme and of the source block construction, except that
of this sequence number places a constraint on source block the use of this sequence number places a constraint on source block
construction. Source packets within a given 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 the maximum value which can be represented in 2 bytes - 65535 - from the maximum value which can be represented in two octets (65535)
to 0). Sequence numbers SHOULD NOT be reused until all values in the to 0). Sequence numbers SHOULD NOT be reused until all values in the
sequence number space have been used. sequence number space have been used.
5.4. Packet Format for FEC Repair packets 5.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 |
+------------------------------------+ +------------------------------------+
| Transport header | | Transport Header |
+------------------------------------+ +------------------------------------+
| Repair FEC Payload ID | | Repair FEC Payload ID |
+------------------------------------+ +------------------------------------+
| Repair Symbols | | Repair Symbols |
+------------------------------------+ +------------------------------------+
Figure 7: Packet format for repair packets Figure 7: Packet format for repair packets
The Repair FEC Payload ID field contains information required for the The Repair FEC Payload ID field contains information required for the
operation of the FEC algorithm at the receiver. This information is operation of the FEC algorithm at the receiver. This information is
defined by the FEC Scheme. The format of the Repair FEC Payload ID defined by the FEC scheme. The format of the Repair FEC Payload ID
field is defined by the FEC Scheme. field is defined by the FEC scheme.
5.4.1. Packet Format for FEC Repair packets over RTP 5.4.1. Packet Format for FEC Repair Packets over RTP
For FEC Schemes which specify the use of RTP for repair packets, the For FEC schemes which specify the use of RTP for repair packets, the
packet format for repair packets includes an RTP header as shown in packet format for repair packets includes an RTP header as shown in
Figure 8. Figure 8.
+------------------------------------+ +------------------------------------+
| IP header | | IP header |
+------------------------------------+ +------------------------------------+
| Transport header (UDP) | | Transport Header (UDP) |
+------------------------------------+ +------------------------------------+
| RTP Header | | RTP Header |
+------------------------------------+ +------------------------------------+
| Repair FEC Payload ID | | Repair FEC Payload ID |
+------------------------------------+ +------------------------------------+
| Repair Symbols | | Repair Symbols |
+------------------------------------+ +------------------------------------+
Figure 8: Packet format for repair packets Figure 8: Packet format for repair packets
5.5. FEC Framework Configuration Information 5.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 ADU FEC Framework needs in order to apply FEC protection to the ADU
flows. A complete Content Delivery Protocol specification that uses flows. A complete CDP specification that uses the framework
the framework specified here MUST include details of how this specified here MUST include details of how this information is
information is derived and communicated between sender and receiver. 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 flows. For example, in the case of UDP, each
each Source Data Flow is uniquely identified by a tuple { Source IP source flow is uniquely identified by a tuple {Source IP address,
Address, Destination IP Address, Source UDP port, Destination UDP source UDP port, destination IP address, destination UDP port}. In
port }. Note that in some applications some of these fields may some applications some of these fields can contain wildcards, so that
contain wildcards, so that the flow is identified by a subset of the the flow is identified by a subset of the fields. In particular, in
fields and in particular in many applications the limited tuple { many applications the limited tuple {Destination IP address,
Destination IP Address, Destination UDP port } is sufficient. 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
packets of the specified set of Source Data Flows, by means of one or packets of the specified set of source flows, by means of one or more
more packet flows consisting of repair packets. The FEC Framework packet flows consisting of repair packets. The FEC Framework
Configuration Information includes, for each instance of the FEC Configuration Information includes, for each instance of the FEC
Framework: Framework:
1. Identification of the packet flow(s) carrying FEC Repair 1. Identification of the repair flows.
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 flow protected by the repair flow(s):
a. Definition of the Source Data Flow carrying source packets A. Definition of the source flow.
(for example, by means of a tuple as described above for UDP).
b. An integer identifier for this Source Data Flow. This B. An integer identifier for this flow definition (i.e., tuple).
identifier MUST be unique amongst all Source Data Flows which This identifier MUST be unique amongst all source flows that
are protected by the same FEC repair flow. are protected by the same FEC repair flow. Integer
identifiers can be allocated starting from zero and
increasing by one for each flow. However, any random (but
still unique) allocation is also possible. A source flow
identifier need not be carried in source packets since source
packets are directly associated with a flow by virtue of
their packet headers.
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 octets).
5. Zero or more FEC-Scheme-specific information elements, each 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements,
consisting of a name and a value where the valid element names and each consisting of a name and a value where the valid element
value ranges are defined by the FEC Scheme names and value ranges are defined by the FEC scheme.
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, can 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 packets of the Source Data Flows identified in (2) above protects packets of the source flows identified in (2) above, i.e.,
i.e. all packets sent on those flows MUST be FEC Source packets as all packets sent on those flows MUST be FEC source packets as defined
defined in Section 5.3. A single Source Data Flow may be protected in Section 5.3. A single source flow can be protected by multiple
by multiple instances of the FEC Framework. instances of the FEC Framework.
The integer flow identifier identified in 2(b) is a "shorthand" to The integer flow identifier identified in (2b) above is a shorthand
identify source flows between the FEC Framework and the FEC Scheme. to identify source flows between the FEC Framework and the FEC
The reason for defining this as an integer, and including it in the scheme. The reason for defining this as an integer, and including it
FEC Framework Configuration Information is so that the FEC Scheme at in the FEC Framework Configuration Information is so that the FEC
the sender and receiver may use it to identify the source flow with scheme at the sender and receiver can use it to identify the source
which a recovered packet is associated. The integer flow identifier flow with which a recovered packet is associated. The integer flow
may therefore take the place of the complete flow description (e.g. identifier can therefore take the place of the complete flow
UDP 4-tuple). description (e.g., 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 repair packets can provide protection for multiple
virtue of their packet headers, this identifier need not be carried source flows, repair packets would either not carry the identifier at
in source packets. Since repair packets may provide protection for all or can carry multiple identifiers. However, in any case, the
multiple source flows, repair packets would either not carry the flow identifier associated with a particular source packet can be
identifier at all or may carry multiple identifiers. However, in any recovered from the repair packets as part of an FEC decoding
case, the flow identifier associated with a particular source packet operation.
may be recovered from the repair packets as part of an FEC decoding
operation. Integer flow identifiers SHOULD be allocated starting
from zero and increasing by one for each flow.
A single FEC repair flow provides repair packets for a single A single FEC repair flow provides repair packets for a single
instance of the FEC Framework. Other packets MUST NOT be sent within instance of the FEC Framework. Other packets MUST NOT be sent within
this flow i.e. all packets in the FEC repair flow MUST be FEC repair this flow, i.e., all packets in the FEC repair flow MUST be FEC
packets as defined in Section 5.4 and MUST relate to the same FEC repair packets as defined in Section 5.4 and MUST relate to the same
Framework instance. FEC 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 can also include the RTP payload type to be
used for repair packets. used for repair packets.
FEC Scheme-specific information elements MAY be encoded into a text FSSI includes the information that is specific to the FEC scheme used
string for transport within Content Delivery Protocols. See Section by the CDP. FSSI is used to communicate the information that cannot
4.5 of [I-D.ietf-fecframe-sdp-elements] for the ABNF [RFC5234] be adequately represented otherwise and is essential for proper FEC
syntax. encoding and decoding operations. The motivation behind separating
the FSSI required only by the sender (which is carried in Sender-Side
FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of
the FSSI is to provide the receiver or the third party entities a
means of controlling the FEC operations at the sender. Any FSSI
other than the one solely required by the sender MUST be communicated
via the FSSI container.
5.6. FEC Scheme requirements The variable-length SS-FSSI and FSSI containers transmit the
information in textual representation and contain zero or more
distinct elements, whose descriptions are provided by the fully-
specified FEC schemes.
In order to be used with this framework, an FEC Scheme MUST be For the CDPs that choose the Session Description Protocol (SDP)
capable of processing data arranged into blocks of Application Data [RFC4566] as their session description protocol, the ABNF [RFC5234]
Units (source blocks). syntax for the SS-FSSI and FSSI containers is provided in Section 4.5
of [I-D.ietf-fecframe-sdp-elements].
A specification for a new FEC scheme MUST include the following 5.6. FEC Scheme Requirements
things:
In order to be used with this framework, an FEC scheme MUST be
capable of processing data arranged into blocks of ADUs (source
blocks).
A specification for a new FEC scheme MUST include the following:
1. The FEC Encoding ID value that uniquely identifies the FEC 1. The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA as described in scheme. This value MUST be registered with IANA as described in
Section 10. Section 10.
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 name, type, semantics and text value encoding rules for zero 3. The name, type, semantics and text value encoding rules for zero
or more FEC Scheme-specific FEC Framework Configuration or more FEC-Scheme-Specific Information elements.
Information elements. Names must conform to the "name"
production and values encodings to the "value" production defined
in Section 5.5
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 Information values, the valid FEC Payload ID values and
valid FEC Payload ID values and the valid packet payload sizes the valid packet payload sizes (where packet payload refers to
(where packet payload refers to the space within a packet the space within a packet dedicated to carrying encoding
dedicated to carrying encoding symbol bytes). symbols).
Furthermore, given a source block as defined in Section 5.2, Furthermore, given a source block as defined in Section 5.2,
valid values of the FEC-Scheme-Specific FEC Framework valid values of the FEC-Scheme-Specific Information, a valid
Configuration Information, a valid Repair FEC Payload ID value Repair FEC Payload ID value and a valid packet payload size, the
and a valid packet payload size, the specification MUST uniquely specification MUST uniquely define the values of the encoding
define the values of the encoding symbol bytes to be included in symbols to be included in the repair packet payload of a packet
the repair packet payload of a packet with the given Repair FEC 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
level of detail is to provide a precise specification of an level of detail is to provide a precise specification of an
encoding algorithm which, given a source block, valid values of encoding algorithm which, given a source block, valid values of
the FEC-Scheme-Specific FEC Framework Configuration Information, the FEC-Scheme-Specific Information, a valid Repair FEC Payload
a valid Repair FEC Payload ID value and a valid packet payload ID value and a valid packet payload size as input produces the
size as input produces the exact value of the encoding symbol exact value of the encoding symbols as output.
bytes as output.
5. A description of practical encoding and decoding algorithms. 5. A description of practical encoding and decoding algorithms.
This description need not be to the same level of detail as for This description need not be to the same level of detail as for
the encoding above, however it must be sufficient to demonstrate the encoding above, however it has to be sufficient to
that encoding and decoding of the code is both possible and demonstrate that encoding and decoding of the code is both
practical. possible and practical.
FEC scheme specifications MAY additionally define the following: FEC scheme specifications MAY additionally define the following:
1. Type, semantics and encoding format of an Explicit Source FEC 1. Type, semantics and encoding format of an Explicit Source FEC
Payload ID. Payload ID.
Whenever an FEC scheme specification defines an 'encoding format' for Whenever an FEC scheme specification defines an 'encoding format' for
an element, this must be defined in terms of a sequence of bytes an element, this has to be defined in terms of a sequence of bytes
which can be embedded within a protocol. The length of the encoding which can be embedded within a protocol. The length of the encoding
format MUST either be fixed or it must be possible to derive the format MUST either be fixed or it MUST be possible to derive the
length from examining the encoded bytes themselves. For example, the length from examining the encoded bytes themselves. For example, the
initial bytes may include some kind of length indication. initial bytes can include some kind of length indication.
FEC scheme specifications SHOULD use the terminology defined in this FEC scheme specifications SHOULD use the terminology defined in this
document and SHOULD follow the following format: document and SHOULD follow the following format:
1. Introduction <describe the use-cases addressed by this FEC 1. Introduction <Describe the use-cases addressed by this FEC
scheme> scheme>
2. Formats and Codes 2. Formats and Codes
2.1 Source FEC Payload ID(s) <Either, define the type and format 2.1 Source FEC Payload ID(s) <Either, define the type and format
of the Explicit Source FEC Payload ID, or define how Source FEC of the Explicit Source FEC Payload ID, or define how Source FEC
Payload ID information is derived from source packets> Payload ID information is derived from source packets>
2.2 Repair FEC Payload Id <Define the type and format of the 2.2 Repair FEC Payload ID <Define the type and format of the
Repair FEC Payload ID> Repair FEC Payload ID>
2.3 FEC Framework Configuration Information <Define the names, 2.3 FEC Framework Configuration Information <Define the names,
types and text value encoding formats of the FEC Scheme- types and text value encoding formats of the FEC-Scheme-
specific FEC Framework configuration information elements> Specific Information elements>
3. Procedures <describe any procedures which are specific to this 3. Procedures <Describe any procedures which are specific to this
FEC scheme, in particular derivation and interpretation of the FEC scheme, in particular derivation and interpretation of the
fields in the FEC Payload ID and FEC Scheme-specific FEC Framework fields in the FEC Payload IDs and FEC-Scheme-Specific Information>
configuration information.>
4. FEC code specification <provide a complete specification of the 4. FEC Code Specification <Provide a complete specification of the
FEC Code> FEC Code>
Specifications MAY include additional sections, for example, Specifications can include additional sections including examples.
examples.
Each FEC scheme MUST be specified independently of all other FEC Each FEC scheme MUST be specified independently of all other FEC
schemes; for example, in a separate specification or a completely schemes; for example, in a separate specification or a completely
independent section of larger specification (except, of course, a independent section of larger specification (except, of course, a
specification of one FEC Scheme may include portions of another by specification of one FEC scheme can include portions of another by
reference). reference). Where an RTP Payload Format is defined for repair data
for a specific FEC scheme, the RTP Payload Format and the FEC scheme
Where an RTP Payload Format is defined for repair data for a specific can be specified within the same document.
FEC Scheme, the RTP Payload Format and the FEC Scheme MAY be
specified within the same document.
6. Feedback 6. Feedback
Many applications require some kind of feedback on transport Many applications require some kind of feedback on transport
performance: how much data arrived at the receiver, at what rate, performance. E.g., how much data arrived at the receiver, at what
when etc. When FEC is added to such applications, feedback rate and when? When FEC is added to such applications, feedback
mechanisms may also need to be enhanced to report on the performance mechanisms can 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. E.g., 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 the sense that each block is transmitted small blocks of data (in the sense that each block is transmitted
over a relatively small period of time) and so feedback information over a relatively small period of time). Thus, feedback information
averaged over longer periods of time than the FEC block transmission that is averaged over longer periods of time will likely not provide
time will likely not provide sufficient information for engineering sufficient information for engineering purposes. More detailed
purposes. For example see [RFC5725]. feedback over shorter time scales might be preferred. For example,
for applications using RTP transport, 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 received 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
inaccurate 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].
7. Transport Protocols 7. Transport Protocols
This framework is intended to be used to define Content Delivery This framework is intended to be used to define CDPs that operate
Protocols which operate over transport protocols which provide an over transport protocols providing an unreliable datagram service,
unreliable datagram service, including in particular the User including in particular the User Datagram Protocol (UDP) and the
Datagram Protocol (UDP) and the Datagram Congestion Control Protocol Datagram Congestion Control Protocol (DCCP).
(DCCP).
8. Congestion Control 8. Congestion Control
This section starts with a informative section on the motivation of This section starts with some informative background on the
the normative requirements for congestion control, which are spelled motivation of the normative requirements for congestion control,
out in Section 8.1. which are spelled out in Section 8.2.
Informative Note: The enforcement of Congestion Control (CC) 8.1. Motivation
principles has gained a lot of momentum in the IETF over the
recent years. While the need of CC over the open Internet is
unquestioned, and the goal of TCP friendliness is generally agreed
for most (but not all) applications, the subject of congestion
detection and measurement in heterogeneous networks can hardly be
considered as solved. Most congestion control algorithms detect
and measure congestion by taking (primarily or exclusively) the
packet loss rate into account. This appears to be inappropriate
in environments where a large percentage of the packet losses are
the result of link-layer errors and independent of the network
load. Note that such environments exist in the "open Internet",
as well as in "closed" IP based networks. An example for the
former would be the use of IP/UDP/RTP based streaming from an
Internet-connected streaming server to a device attached to the
Internet using cellular technology.
The authors of this draft are primarily interested in applications o The enforcement of congestion control principles has gained a lot
where the application reliability requirements and end-to-end of momentum in the IETF over the recent years. While the need for
reliability of the network differ, such that it warrants higher congestion control over the open Internet is unquestioned, and the
layer protection of the packet stream - for example due to the goal of TCP friendliness is generally agreed for most (but not
presence of unreliable links in the end-to-end path - and where all) applications, the subject of congestion detection and
real-time, scalability or other constraints prohibit the use of measurement in heterogeneous networks can hardly be considered as
higher layer (transport or application) feedback. A typical solved. Most congestion control algorithms detect and measure
congestion by taking (primarily or exclusively) the packet loss
rate into account. This appears to be inappropriate in
environments where a large percentage of the packet losses are the
result of link-layer errors and independent of the network load.
o The authors of this document are primarily interested in
applications where the application reliability requirements and
end-to-end reliability of the network differ, such that it
warrants higher-layer protection of the packet stream, e.g., due
to the presence of unreliable links in the end-to-end path and
where real-time, scalability or other constraints prohibit the use
of higher-layer (transport or application) feedback. A typical
example for such applications is multicast and broadcast streaming example for such applications is multicast and broadcast streaming
or multimedia transmission over heterogeneous networks. In other or multimedia transmission over heterogeneous networks. In other
cases, application reliability requirements may be so high that cases, application reliability requirements can be so high that
the required end-to-end reliability is difficult to achieve even the required end-to-end reliability will be difficult to achieve.
over wired networks. Furthermore the end-to-end network Furthermore, the end-to-end network reliability is not necessarily
reliability may not be known in advance. known in advance.
This FEC framework is not proposed, nor intended, as a QoS o This FEC Framework is not defined, nor intended, as a QoS
enhancement tool to combat losses resulting from highly congested enhancement tool to combat losses resulting from highly congested
networks. It should not be used for such purposes. networks. It should not be used for such purposes.
In order to prevent such mis-use, one approach would be to leave o In order to prevent such mis-use, one approach is to leave
standardisation to bodies most concerned with the problem standardization to bodies most concerned with the problem
described above. However, the IETF defines base standards used by described above. However, the IETF defines base standards used by
several bodies, including DVB, 3GPP, 3GPP2, all of which appear to several bodies, including DVB, 3GPP, 3GPP2, all of which appear to
share the environment and the problem described. share the environment and the problem described.
Another approach would be to write a clear applicability statement o Another approach is to write a clear applicability statement. For
- for example restricting use of the framework to networks with example, one could restrict the use of this framework to networks
wireless links. However, there may be applications where the use with certain loss characteristics (e.g., wireless links).
of FEC may be justified to combat congestion-induced packet losses However, there can be applications where the use of FEC is
- particularly in lightly loaded networks, where congestion is the justified to combat congestion-induced packet losses -
particularly in lightly loaded networks, where congestion is the
result of relatively rare random peaks in instantaneous traffic result of relatively rare random peaks in instantaneous traffic
load - thereby intentionally violating congestion control load - thereby intentionally violating congestion control
principles. One possible example for such an application could be principles. One possible example for such an application could be
a no-matter-what, brute-force FEC protection of traffic generated a no-matter-what, brute-force FEC protection of a traffic
as an emergency signal. generated as an emergency signal.
We propose a third approach, which is to require at a minimum that o A third approach is to require at a minimum that the use of this
the use of this framework with any given application, in any given framework with any given application, in any given environment,
environment, does not cause congestion issues which the does not cause congestion issues which the application alone would
application alone would not itself cause i.e. the use of this not itself cause, i.e., the use of this framework must not make
framework must not make things worse. things worse.
Taking above considerations into account, Section 8.1 specifies a o Taking above considerations into account, Section 8.2 specifies a
small set of constraints for the FEC, which are mandatory for all small set of constraints for the FEC, which are mandatory for all
senders compliant with this FEC framework. Further restrictions senders compliant with this FEC Framework. Further restrictions
may be imposed for certain Content Delivery Protocols. In this it can be imposed by certain CDPs.
follows the spirit of the congestion control section of RTP and
its Audio-Visual Profile (RFC3550/STD64 and RFC3551/STD65).
One of the constraints effectively limits the bandwidth for the 8.2. Normative Requirements
FEC protected packet stream to be no more than roughly twice as
high as the original, non-FEC protected packet stream. This o The bandwidth of FEC repair data MUST NOT exceed the bandwidth of
disallows the (static or dynamic) use of excessively strong FEC to the original source data being protected (without the possible
combat high packet loss rates, which may otherwise be chosen by addition of an Explicit Source FEC Payload ID). This disallows
naively implemented dynamic FEC-strength selection mechanisms. We the (static or dynamic) use of excessively strong FEC to combat
acknowledge that there may be a few exotic applications, e.g. IP high packet loss rates, which can otherwise be chosen by naively
implemented dynamic FEC-strength selection mechanisms. We
acknowledge that there are a few exotic applications, e.g., IP
traffic from space-based senders, or senders in certain hardened traffic from space-based senders, or senders in certain hardened
military devices, which would warrant a higher FEC strength. military devices, which could warrant a higher FEC strength.
However, in this specification we give preference to the overall However, in this specification we give preference to the overall
stability and network friendliness of the average application, and stability and network friendliness of average applications.
for those a factor of 2 appears to be appropriate.
A second constraint requires that the FEC protected packet stream
be in compliance with the congestion control in use for the
application and network in question.
8.1. Normative requirements
The bandwidth of FEC Repair packet flows MUST NOT exceed the o Whenever the source data rate is adapted due to the operation of
bandwidth of the source packet flows being protected. In addition, congestion control mechanisms, the FEC repair data rate MUST be
whenever the source packet flow bandwidth is adapted due to the similarly adapted.
operation of congestion control mechanisms, the FEC repair packet
flow bandwidth MUST be similarly adapted.
9. Security Considerations 9. Security Considerations
The application of FEC protection to a stream does not provide any The application of FEC protection to a stream does not provide any
kind of security protection. kind of security protection.
If security services are required for the stream, then they MUST If security services are required for the stream, then they MUST
either be applied to the original source data before FEC protection either be applied to the original source data before FEC protection
is applied, or to both the source and repair data, after FEC is applied, or to both the source and repair data, after FEC
protection has been applied. protection has been applied.
If integrity protection is applied to source packets before FEC If integrity protection is applied to source packets before FEC
protection is applied, and no further integrity protection is applied protection is applied, and no further integrity protection is applied
to repair packets, then a denial of service attack is possible if an to repair packets, then a denial-of-service attack is possible if an
attacker is in a position to inject fake repair transport payloads. attacker is in a position to inject fake repair transport payloads.
If received by a receiver, such fake repair transport payloads could If received by a receiver, such fake repair transport payloads could
cause incorrect FEC decoding resulting in incorrect Application Data cause incorrect FEC decoding resulting in incorrect ADUs being passed
Units being passed up to the application protocol. A similar attack up to the application protocol. A similar attack is possible if an
may be possible if an attacker is in a position to inject fake FEC attacker is in a position to inject fake FEC Framework Configuration
Framework Configuration Information or fake FEC Payload IDs. Such Information or fake FEC Payload IDs. Such incorrect decoded ADUs
incorrect decoded Application Data Units would then be detected by would then be detected by the source integrity protection and
the source integrity protection and discarded, resulting in partial discarded, resulting in partial or complete denial of service.
or complete denial of service. Therefore, in such environments, Therefore, in such environments, integrity protection MUST also be
integrity protection MUST also be applied to the FEC repair transport applied to the FEC repair transport payloads, FEC Framework
payloads, FEC Framework Configuration Information and FEC Payload Configuration Information and FEC Payload IDs, for example using
IDs, for example using IPsec to integrity protect all packets. IPSec to integrity protect all packets. Receivers MUST also verify
Receivers MUST also verify the integrity of source symbols before the integrity of source symbols before including the source symbols
including the source symbols into the source block for FEC purposes. into the source block.
It is possible that multiple streams with different confidentiality It is possible that multiple streams with different confidentiality
requirements (for example, the streams may be visible to different requirements (for example, the streams may be visible to different
sets of users) can be FEC protected by a single repair stream. This sets of users) can be FEC protected by a single repair stream. This
scenario is not recommended, since resources will be used to scenario is not recommended, since resources will be used to
distribute and FEC decode encrypted data which cannot then be distribute and FEC decode encrypted data which cannot then be
decrypted by at least some receivers. However, in this scenario, decrypted by at least some receivers. However, in this scenario,
confidentiality protection MUST be applied before FEC encoding of the confidentiality protection MUST be applied before FEC encoding of the
streams, otherwise repair transport payload may be used by a receiver streams, otherwise repair transport payload may be used by a receiver
to decode unencrypted versions of source streams which they do not to decode unencrypted versions of source streams which they do not
have permissions to view. have permissions to access.
10. IANA Considerations 10. IANA Considerations
FEC Schemes for use with this framework may be identified in FEC schemes for use with this framework are identified in protocols
protocols using FEC Encoding IDs. Values of FEC Encoding IDs are using FEC Encoding IDs. Values of FEC Encoding IDs are subject to
subject to IANA registration. They are in the registry named "FEC IANA registration. For this purposes, this document creates a new
Framework (FECFRAME) FEC Encoding IDs" located at time of publication registry called FEC Framework (FECFRAME) FEC Encoding IDs.
at <tbd>.
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 an IETF
Consensus" basis as defined in[RFC5226] . Section 5.6 defines Consensus basis as defined in [RFC5226]. Section 5.6 defines
explicit requirements that documents defining new FEC Encoding IDs explicit requirements that documents defining new FEC Encoding IDs
should meet. should meet.
11. Acknowledgments 11. Acknowledgments
This document is based in part on [I-D.watson-tsvwg-fec-sf] and so This document is based in part on [I-D.watson-tsvwg-fec-sf] and so
thanks are due to the additional authors of that document, Mike Luby, thanks are due to the additional authors of that document, Mike Luby,
Magnus Westerlund and Stephan Wenger. That document was in turn Magnus Westerlund and Stephan Wenger. That document was in turn
based on the FEC streaming protocol defined by 3GPP in [MBMSTS] and based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and
thus thanks are also due to the participants in 3GPP TSG SA working thus, thanks are also due to the participants in 3GPP TSG SA Working
group 4. Further thanks are due to the members of the FECFRAME Group 4. Further thanks are due to the members of the FECFRAME
working group for their comments and review. Working Group for their comments and review.
12. References 12. References
12.1. Normative references 12.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 36, line 44 skipping to change at page 36, line 44
[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.
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
Report Block Type for RTP Control Protocol (RTCP) Extended Report Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", RFC 5725, February 2010. Reports (XRs)", RFC 5725, February 2010.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[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
Payload Format Specifications", BCP 36, RFC 2736,
December 1999.
[I-D.ietf-fecframe-sdp-elements] [I-D.ietf-fecframe-sdp-elements]
Begen, A., "Session Description Protocol (SDP) Elements Begen, A., "Session Description Protocol Elements for FEC
for FEC Framework", draft-ietf-fecframe-sdp-elements-08 Framework", draft-ietf-fecframe-sdp-elements-11 (work in
(work in progress), August 2010. progress), October 2010.
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346, April 2005. Protocols and codecs", 3GPP TS 26.346, April 2005.
Author's Address Authors' Addresses
Mark Watson Mark Watson
Netflix, Inc. Netflix, Inc.
100 Winchester Circle 100 Winchester Circle
Los Gatos, CA, CA 95032 Los Gatos, CA 95032
U.S.A. USA
Email: watsonm@netflix.com Email: watsonm@netflix.com
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
Email: abegen@cisco.com
 End of changes. 207 change blocks. 
815 lines changed or deleted 797 lines changed or added

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