draft-ietf-fecframe-framework-08.txt   draft-ietf-fecframe-framework-09.txt 
FEC Framework Working Group M. Watson FEC Framework Working Group M. Watson
Internet-Draft Qualcomm, Inc. Internet-Draft Qualcomm, Inc.
Intended status: Standards Track June 1, 2010 Intended status: Standards Track July 6, 2010
Expires: December 3, 2010 Expires: January 7, 2011
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-08 draft-ietf-fecframe-framework-09
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 Forward Error Correction to arbitrary packet flows
over unreliable transport and is primarily intended for real-time, or over unreliable transport and is primarily intended for real-time, or
streaming, media. This framework can be used to define Content streaming, media. This framework can be used to define Content
Delivery Protocols that provide Forward Error Correction for Delivery Protocols that provide Forward Error Correction for
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 December 3, 2010. This Internet-Draft will expire on January 7, 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 9 skipping to change at page 3, line 9
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/Abbreviations . . . . . . . . . . . . . . . . . . 6
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 9 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10 4. Procedural overview . . . . . . . . . . . . . . . . . . . . . 13
5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 14 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 16 4.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17
5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21
6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 22 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Structure of the source block . . . . . . . . . . . . . . 21
6.2. Structure of the source block . . . . . . . . . . . . . . 22 5.3. Packet format for FEC Source packets . . . . . . . . . . . 21
6.3. Packet format for FEC Source packets . . . . . . . . . . . 22 5.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 23
6.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 24 5.4. Packet Format for FEC Repair packets . . . . . . . . . . . 23
6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 24 5.4.1. Packet Format for FEC Repair packets over RTP . . . . 23
6.4.1. Packet Format for FEC Repair packets over RTP . . . . 24 5.5. FEC Framework Configuration Information . . . . . . . . . 24
6.5. FEC Framework Configuration Information . . . . . . . . . 25 5.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26
6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 27 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30
8. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 31 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative requirements . . . . . . . . . . . . . . . . . . 32
9.1. Normative requirements . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 12.1. Normative references . . . . . . . . . . . . . . . . . . . 36
13.1. Normative references . . . . . . . . . . . . . . . . . . . 38 12.2. Informative references . . . . . . . . . . . . . . . . . . 36
13.2. Informative references . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Many applications have a requirement to transport a continuous stream Many applications have a requirement to transport a continuous stream
of packetised data from a source (sender) to one or more destinations of 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 is a well-known technique for improving
reliability of packet transmission over networks which do not provide reliability of packet transmission over networks which do not provide
guaranteed packet delivery, especially in multicast and broadcast guaranteed packet delivery, especially in multicast and broadcast
applications. The FEC Building Block defined in [RFC5052] provides a applications. The FEC Building Block defined in [RFC5052] provides a
framework for definition of Content Delivery Protocols (CDPs) for framework for definition of Content Delivery Protocols (CDPs) for
skipping to change at page 6, line 7 skipping to change at page 6, line 7
flow. Additionally, the post-repair RTCP extended report [RFC5725] flow. Additionally, the post-repair RTCP extended report [RFC5725]
may be used to obtain information about the loss rate after FEC may be used to obtain information about the loss rate after FEC
recovery. recovery.
The use of RTP for repair flows is defined for each FEC Scheme by The use of RTP for repair flows is defined for each FEC Scheme by
defining an RTP Payload Format for that particular FEC Scheme defining an RTP Payload Format for that particular FEC Scheme
(possibly in the same document). (possibly in the same document).
2. Definitions/Abbreviations 2. Definitions/Abbreviations
'FEC' Forward Error Correction. '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 'AL-FEC' Application Layer Forward Error Correction
'FEC Framework' A protocol framework for definition of Content
Delivery Protocols using FEC, such as the framework defined in
this document.
'Source data flow' The packet flow or flows to which FEC protection
is to be applied. A source data flow consists of ADUs.
'Repair data flow' The packet flow or flows carrying forward error
correction data
'Source protocol' A protocol used for the source data flow being
protected - e.g. RTP.
'Transport protocol' The protocol used for transport of the source
and repair data flows - e.g. UDP, DCCP.
'Application Data Unit' The unit of source data provided as payload 'Application Data Unit' The unit of source data provided as payload
to the transport layer to the transport layer
'ADU Flow' A sequence of ADUs associated with a transport layer flow
identifier (such as the standard 5-tuple { Source IP Address,
Source Transport Port, Destination IP Address, Destination
Transport Port, Transport Protocol } in the case of UDP)
'Application protocol' Control protocol used to establish and 'Application protocol' Control protocol used to establish and
control the source data flow being protected - e.g. RTSP. control the source data flow being protected - e.g. RTSP.
'Content Delivery Protocol (CDP)' A complete application protocol
specification which, through the use of the framework defined in
this document, is able to make use of FEC Schemes to provide
Forward Error Correction capabilities
'FEC' Forward Error Correction.
'FEC Code' An algorithm for encoding data such that the encoded data 'FEC Code' An algorithm for encoding data such that the encoded data
flow is resiliant to data loss (Note: in general FEC Codes may flow is resilient to data loss (Note: in general FEC Codes may
also be used to make a data flow resiliant to corruption, but that also be used to make a data flow resilient to corruption, but that
is not considered here). is not considered here).
'FEC Framework' A protocol framework for definition of Content
Delivery Protocols using FEC, such as the framework defined in
this document.
'FEC Framework Configuration Information' Information which controls
the operation of the FEC Framework.
'FEC Payload ID' Information which identifies the contents of a
packet with respect to the FEC Scheme.
'FEC Repair Packet' At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the Transport
protocol containing one or more repair symbols along with a Repair
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, or, in the context of RMT, with the RMT FEC Building Framework, or, in the context of RMT, with the RMT FEC Building
Block. Block.
'FEC Source Packet' At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the Transport
protocol containing an ADU along with an optional Source FEC
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 of FEC. use of FEC.
'FEC Framework Configuration Information' Information which controls 'Repair data flow' The packet flow or flows carrying forward error
the operation of the FEC Framework. correction data
'FEC Source Packet' At a sender (resp. receiver) a payload submitted
to (resp. received from) the Transport protocol containing an ADU
along with an optional Source FEC Payload ID.
'FEC Repair Packet' At a sender (resp. receiver) a payload submitted 'Repair FEC Payload ID' An FEC Payload ID specifically for use with
to (resp. received from) the Transport protocol containing one or repair packets.
more repair symbols along with a Repair FEC Payload ID and
possibly an RTP header.
'FEC Payload ID' Information which identifies the contents of a 'Source data flow' The packet flow or flows to which FEC protection
packet with respect to the FEC Scheme. is to be applied. A source data 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.
'Repair FEC Payload ID' An FEC Payload ID specifically for use with 'Source protocol' A protocol used for the source data flow being
repair packets. protected - e.g. RTP.
'Content Delivery Protocol (CDP)' A complete application protocol 'Transport protocol' The protocol used for transport of the source
specification which, through the use of the framework defined in and repair data flows - e.g. UDP, DCCP.
this document, is able to make use of FEC Schemes to provide
Forward Error Correction capabilities
The following definitions are aligned with [RFC5052] The following definitions are aligned with [RFC5052]
'Source symbol' unit of data used during the encoding process. 'Code rate' the ratio between the number of source symbols and the
number of encoding symbols. By definition, the code rate is such
that: 0 < code rate <= 1. A code rate close to 1 indicates that a
small number of repair symbols have been produced during the
encoding process.
'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.
'Repair symbol' encoding symbol that is not a source symbol.
'Code rate' the k/n ratio, i.e., the ratio between the number of
source symbols and the number of encoding symbols. By definition,
the code rate is such that: 0 < code rate <= 1. A code rate close
to 1 indicates that a small number of repair symbols have been
produced during the encoding process.
'Systematic code' FEC code in which the source symbols are part of
the encoding symbols. The Reed-Solomon codes introduced in this
document are systematic.
'Source Block' group of ADUs which are to be FEC protected as a
single block.
'Packet Erasure Channel' a communication path where packets are 'Packet Erasure Channel' a communication path where packets are
either dropped (e.g., by a congested router, or because the number either dropped (e.g., by a congested router, or because the number
of transmission errors exceeds the correction capabilities of the of 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 assumed that this packet is not corrupted. is assumed that this packet is not corrupted.
3. Requirements notation 'Repair symbol' encoding symbol that is not a source symbol.
'Source Block' group of ADUs which are to be FEC protected as a
single block.
'Source symbol' unit of data used during the encoding process.
'Systematic code' FEC code in which the source symbols are part of
the encoding symbols. The Reed-Solomon codes introduced in this
document are systematic.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
4. Architecture Overview 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. Examples of such protocols are RTP, RTCP,
etc. As such, the data path interface between the FEC Framework and etc. As such, the data path interface between the FEC Framework and
both underlying and overlying layers can be thought of as being the both underlying and overlying layers can be thought of as being the
same as the standard interface to the transport layer - i.e. the data same as the standard interface to the transport layer - i.e. the data
exchanged consists of datagram payloads each associated with a single exchanged consists of datagram payloads each associated with a single
ADU flow identified (in the case of UDP) by the standard 5-tuple { ADU flow identified (in the case of UDP) by the standard 5-tuple {
Source IP Address, Source Transport Port, Destination IP Address, Source IP Address, Source Transport Port, Destination IP Address,
Destination Transport Port, Transport Protocol }. In the case that Destination Transport Port, Transport Protocol }. In the case that
RTP is used for the repair flows, the source and repair data may be RTP is used for the repair flows, the source and repair data may be
multiplexed using RTP onto a single UDP flow and must consequently be multiplexed using RTP onto a single UDP flow and must consequently be
demultiplexed at the receiver. There are various ways in which this demultiplexed at the receiver. There are various ways in which this
multiplexing can be done, for example as described in [RFC4588]. multiplexing can be done, for example as described in [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 fuctional 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
skipping to change at page 10, line 51 skipping to change at page 9, line 51
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. 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 analagous 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 must be defined by any Content Delivery Protocol specification
as described in the following sections. as described in the following sections.
In this architecture we assume that the interface to the transport In this architecture we assume that the interface to the transport
layer supports the concepts of data units (referred to here as layer supports the concepts of data units (referred to here as
Application Data Units) to be transported and identification of ADU Application Data Units) to be transported and identification of ADU
flows on which those data units are transported. Since this is an flows on which those data units are transported. Since this is an
interface internal to the architecture, we do not specify this interface internal to the architecture, we do not specify this
interface explicitly, except to say that ADU flows which are distinct interface explicitly. We do require that ADU flows which are
from the transport layer point of view (for example, distinct UDP distinct from the transport layer point of view (for example,
flows as identified by the UDP source/destination ports/addresses) distinct UDP flows as identified by the UDP source/destination ports/
are also distinct on the interface between the transport layer and addresses) are also distinct on the interface between the transport
the FEC Framework. 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 may also be used as a transport for
repair packet flows. In this case an FEC Scheme must define an RTP repair packet flows. In this case an FEC Scheme must define an RTP
Payload Format for the repair data. Payload Format for the repair data.
skipping to change at page 14, line 5 skipping to change at page 13, line 5
The use of RTP for repair packets is independent of the protocols The use of RTP for repair packets is independent of the protocols
used for source packets: if RTP is used for source packets then used for source packets: if RTP is used for source packets then
repair packets may or may not use RTP and vice versa (although it is repair packets may or may not use RTP and vice versa (although it is
unlikely that there are useful scenarios where non-RTP source flows unlikely that there are useful scenarios where non-RTP source flows
are protected by RTP repair flows). FEC Schemes are expected to are protected by RTP repair flows). FEC Schemes are expected to
recover entire transport payloads for recovered source packets in all recover entire transport payloads for recovered source packets in all
cases. For example if RTP is used for source flows, the FEC Scheme cases. For example if RTP is used for source flows, the FEC Scheme
is expected to recover the entire UDP payload, including the RTP is expected to recover the entire UDP payload, including the RTP
header. header.
5. Procedural overview 4. Procedural overview
5.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 Application Data Units which can be protected
together, except that the Application Data Unit is carried over a together, except that the Application Data Unit is carried over a
supported transport protocol (See Section 8). The data may be from supported transport protocol (See Section 7). The data may be from
multiple Source Data Flows that are protected jointly. The FEC multiple Source Data Flows that are protected jointly. The FEC
framework handles the Source Data Flows as a sequence of 'source framework handles the Source Data Flows as a sequence of 'source
blocks' each consisting of a set of Application Data Units, possibly blocks' each consisting of a set of Application Data Units, possibly
from multiple Source Data Flows which are to be protected together. from multiple Source Data Flows which are to be protected together.
For example, each source block may be constructed from those For example, each source block may be constructed from those
Application Data Units related to a particular segment in time of the Application Data Units related to a particular segment in time of the
flow. flow.
At the sender, the FEC Framework passes the payloads for a given At the sender, the FEC Framework passes the payloads for a given
block to the FEC Scheme for FEC encoding. The FEC Scheme performs block to the FEC Scheme for FEC encoding. The FEC Scheme performs
skipping to change at page 14, line 47 skipping to change at page 13, line 47
repair packet payloads' and corresponding 'FEC Repair Payload IDs' repair packet payloads' and corresponding 'FEC Repair Payload IDs'
appropriately to construct 'FEC repair packets' and send them to the appropriately to construct 'FEC repair packets' and send them to the
receiver. Note that FEC repair packets MAY be sent to a different receiver. Note that FEC repair packets MAY be sent to a different
multicast group or groups from the source packets. multicast group or groups from the source packets.
This document does not define how the sender determines which This document does not define how the sender determines which
Application Data Units are included in which source blocks or the Application Data Units are included in which source blocks or the
sending order and timing of FEC source and FEC repair packets. A sending order and timing of FEC source and FEC repair packets. A
specific Content Delivery Protocol MAY define this mapping or it MAY specific Content Delivery Protocol MAY define this mapping or it MAY
be left as implementation dependent at the sender. However, a CDP be left as implementation dependent at the sender. However, a CDP
specification MUST define how a receiver determines a mimimum length specification MUST define how a receiver determines a minimum length
of time that it should wait to receive FEC repair packets for any of time that it should wait to receive FEC repair packets for any
given source block. FEC Schemes MAY define limitations on this given source block. FEC Schemes MAY define limitations on this
mapping, such as maximum size of source blocks, but SHOULD NOT mapping, such as maximum size of source blocks, but SHOULD NOT
attempt to define specific mappings. The sequence of operations at attempt to define specific mappings. The sequence of operations at
the sender is described in more detail in Section 5.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 Application Data Units are recovered by the
FEC Framework directly from any FEC Source Packets received simply by FEC Framework directly from any FEC Source Packets received simply by
removing the Source FEC Payload ID, if present. The receiver also removing the Source FEC Payload ID, if present. The receiver also
passes the contents of the received Application Data Units, plus passes the contents of the received Application Data Units, plus
their FEC Payload IDs to the FEC Scheme for possible decoding. their FEC Payload IDs to the FEC Scheme for possible decoding.
If any Application Data Units related to a given source block have If any Application Data Units related to a given source block have
been lost, then the FEC Scheme may perform FEC decoding to recover been lost, then the FEC Scheme may perform FEC decoding to recover
the missing Application Data Units (assuming sufficient FEC Source the missing Application Data Units (assuming sufficient FEC Source
skipping to change at page 15, line 25 skipping to change at page 14, line 25
received). received).
Note that the receiver may need to buffer received source packets to Note that the receiver may need to buffer received source packets to
allow time for the FEC Repair packets to arrive and FEC decoding to allow time for the FEC Repair packets to arrive and FEC decoding to
be performed before some or all of the received or recovered packets be performed before some or all of the received or recovered packets
are passed to the application. If such a buffer is not provided, are passed to the application. If such a buffer is not provided,
then the application must be able to deal with the severe re-ordering then the application must be able to deal with the severe re-ordering
of packets that may occur. However, such buffering is Content of packets that may occur. However, such buffering is Content
Delivery Protocol and/or implementation-specific and is not specified Delivery Protocol and/or implementation-specific and is not specified
here. The receiver operation is described in more detail in here. The receiver operation is described in more detail in
Section 5.3 Section 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 Application Data Unit.
This information is known as the 'Source FEC Payload ID'. The FEC This information is known as the 'Source FEC Payload ID'. The FEC
Scheme is responsible for defining and interpreting this information. Scheme is responsible for defining and interpreting this information.
This information MAY be encoded into a specific field within the FEC This information MAY be encoded into a specific field within the FEC
Source packet format defined in this specification, called the Source packet format defined in this specification, called the
Explicit Source FEC Payload ID field. The exact contents and format Explicit Source FEC Payload ID field. The exact contents and format
of the Explicit Source FEC Payload ID field are defined by the FEC of the Explicit Source FEC Payload ID field are defined by the FEC
skipping to change at page 16, line 5 skipping to change at page 15, line 5
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 Scheme.
The FEC Scheme MAY use different FEC Payload ID field formats for FEC The FEC Scheme MAY use different FEC Payload ID field formats for FEC
Source packets and FEC Repair packets. Source packets and FEC Repair packets.
5.2. Sender Operation 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 may be RTP, RTCP, MIKEY or
indeed any other type of packet. The following operations, indeed any other type of packet. The following operations,
illustrated in Figure 2, for the case of UDP repair flows and illustrated in Figure 2, for the case of UDP repair flows and
Figure 3 for the case of RTP repair flows, describe a possible way to Figure 3 for the case of RTP repair flows, describe a possible way to
generate compliant FEC Source packet and FEC repair packet streams: generate compliant FEC Source packet and FEC repair packet streams:
1. Application Data Units are provided by the application. 1. Application Data Units are provided by the application.
2. A source block is constructed as specified in Section 6.2. 2. A source block is constructed as specified in Section 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 for
each repair payload. each repair payload.
5. The Explicit Source FEC Payload IDs (if used), Repair FEC 5. The Explicit Source FEC Payload IDs (if used), Repair FEC
Payload IDs and repair packet payloads are provided back from the Payload IDs and repair packet payloads are provided back from the
FEC Scheme to the FEC Framework. FEC Scheme to the FEC Framework.
6. The FEC Framework constructs FEC Source packets according to 6. The FEC Framework constructs FEC Source packets according to
Section 6.3 and FEC Repair packets according to Section 6.4 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 FEC
Scheme. Scheme.
7. The FEC Source and FEC Repair packets are sent using normal 7. The FEC Source and FEC Repair packets are sent using normal
transport layer procedures. The port(s) and multicast group(s) to transport layer procedures. The port(s) and multicast group(s) to
be used for FEC Repair packets are defined in the FEC Framework be used for FEC Repair packets are defined in the FEC Framework
Configuration Information. The FEC Source packets are sent using Configuration Information. The FEC Source packets are sent using
the same ADU flow identification information as would have been the same ADU flow identification information as would have been
used for the original source packets if the FEC Framework were not used for the original source packets if the FEC Framework were not
present (for example, in the UDP case, the UDP source and present (for example, in the UDP case, the UDP source and
skipping to change at page 18, line 34 skipping to change at page 17, line 34
| | RTP | | | RTP |
| +-- -- -- -- --+ | +-- -- -- -- --+
v v v v
+----------------------+ +----------------------+
| Transport Layer | | Transport Layer |
| (e.g. UDP ) | | (e.g. UDP ) |
+----------------------+ +----------------------+
Figure 3: Sender operation with RTP repair flows Figure 3: Sender operation with RTP repair flows
5.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 to the FEC Framework. The type of packet (Source or passed to the FEC Framework. The type of packet (Source or
Repair) and the Source Data Flow to which it belongs (in the case Repair) and the Source Data Flow to which it belongs (in the case
of source packets) is indicated by the ADU flow information which of source 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 (for example source and
skipping to change at page 19, line 34 skipping to change at page 18, line 34
5. The FEC Scheme returns the Application Data Units to the FEC 5. The FEC Scheme returns the Application Data Units to the FEC
Framework in the form of source blocks containing received and Framework in the form of source blocks containing received and
decoded Application Data Units and indications of any Application decoded Application Data Units and indications of any Application
Data Units which were missing and could not be decoded. Data Units which were missing and could not be decoded.
6. The FEC Framework passes the received and recovered 6. The FEC Framework passes the received and recovered
Application Data Units to the application. Application Data Units to the application.
Note that the description above defines functionality Note that the description above defines functionality
responsibilities but does not imply a specific set of timing responsibilities but does not imply a specific set of timing
relationships. For example, ADUs may eb provided to the application relationships. For example, ADUs may be provided to the application
as soon as they are received or recovered (and hence potentially out- as soon as they are received or recovered (and hence potentially out-
of-order) or they may be buffered are delivered to the application of-order) or they may be buffered and delivered to the application
in-order. in-order.
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
| (6) Application Data Units | (6) Application Data Units
| |
+----------------------+ +------------------+ +----------------------+ +------------------+
| FEC Framework | | | | FEC Framework | | |
skipping to change at page 22, line 5 skipping to change at page 21, line 5
all ADUs are recovered. all ADUs are recovered.
Source packets which are correctly received and those which are Source packets which are correctly received and those which are
reconstructed MAY be delivered to the application out of order and in reconstructed MAY be delivered to the application out of order and in
a different order from the order of arrival at the receiver. a different order from the order of arrival at the receiver.
Alternatively, buffering and packet re-ordering MAY be applied to re- Alternatively, buffering and packet re-ordering MAY be applied to re-
order received and reconstructed source packets into the order they order received and reconstructed source packets into the order they
were placed into the source block, if that is necessary according to were placed into the source block, if that is necessary according to
the application. the application.
6. Protocol Specification 5. Protocol Specification
6.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 Application Data Units.
The FEC code will be applied to this source block to produce the The FEC code will be 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 Configuation Information. This configuration information Framework Configuration Information. This configuration information
is also defined in this section. A complete protocol specification is also defined in this section. A complete protocol specification
that uses this framework MUST specify the means to determine and that uses this framework MUST specify the means to determine and
communicate this information between sender and receiver. communicate this information between sender and receiver.
6.2. Structure of the source block 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 Application Data Units in
the form of source blocks. A source block is generated by the FEC the form of source blocks. A source block is generated by the FEC
Framework from an ordered sequence of Application Data Units. The Framework from an ordered sequence of Application Data Units. The
allocation of Application Data Units to blocks is dependent on the allocation of Application Data Units to blocks is dependent on the
application. Note that some Application Data Units may not be application. Note that some Application Data Units may not be
included in any block. 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 Application Data Units where the consists of an ordered sequence of Application Data Units where the
following 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 Data Flow with which the Application
Data Unit is associated (See 6.5) Data Unit is associated (See 6.5)
o The Application Data Unit itself o The Application Data Unit itself
o The length of the Application Data Unit o The length of the Application Data Unit
6.3. Packet format for FEC Source packets 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 |
skipping to change at page 23, line 29 skipping to change at page 22, line 29
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 Application Data Unit followed by the Explicit
Source FEC Payload ID field, if required. Source FEC Payload ID field, if required.
The Explicit Source FEC Payload ID field contains information The Explicit Source FEC Payload ID field contains information
required to associate the source packet with a source block and for required to associate the source packet with a source block and for
the operation of the FEC algorithm and is defined by the FEC Scheme. the operation of the FEC algorithm and is defined by the FEC Scheme.
The format of the Source FEC Payload ID field is defined by the FEC The format of the Source FEC Payload ID field is defined by the FEC
Scheme. Note that in the case that the FEC Scheme or CDP defines a Scheme. Note that in the case that the FEC Scheme or CDP defines a
means to derive the Source FEC Payload ID from other information in means to derive the Source FEC Payload ID from other information in
the packet (for example the a sequence number of some kind used by the packet (for example a sequence number used by the application
the application protocol), then the Source FEC Payload ID field is protocol), then the Source FEC Payload ID field is not included in
not included in the packet. In this case the original source packet the packet. In this case the original source packet and FEC Source
and FEC Source Packet are identical. Packet are identical.
Since the addition of the Explicit Source FEC Payload ID increases In applications where avoidance of IP packet fragmentation is a goal,
the packet length, then in applications where avoidance of IP packet Content Delivery Protocols SHOULD consider the Explicit Source FEC
fragmentation is a goal, Content Delivery Protocols SHOULD consider Payload ID size when determining the size of Application Data Units
the Explicit Source FEC Payload ID size when determining the size of that will be delivered using the FEC Framework. This is because the
Application Data Units that will be delivered using the FEC addition of the Explicit Source FEC Payload ID increases the packet
Framework. length.
Note: The Explicit Source FEC Payload ID is placed at the end of the Note: The Explicit Source FEC Payload ID is placed at the end of the
packet so that in the case that Robust Header Compression [RFC3095] packet so that in the case that Robust Header Compression [RFC3095]
or other header compression mechanisms are used and in the case that or other header compression mechanisms are used and in the case that
a ROHC profile is defined for the protocol carried within the a ROHC profile is defined for the protocol carried within the
transport payload (for example RTP), then ROHC will still be applied transport payload (for example RTP), then ROHC will still be applied
for the FEC Source packets. Applications that may be used with this for the FEC Source packets. Applications that may be used with this
Framework should consider that FEC Schemes may add this Explicit Framework should consider that FEC Schemes may add this Explicit
Source FEC Payload ID and thereby increase the packet size. Source FEC Payload ID and thereby increase the packet size.
In many applications, support for Forward Error Correction is added In many applications, support for Forward Error Correction is added
to a pre-existing protocol and in this case use of the Explicit to a pre-existing protocol and in this case use of the Explicit
Source FEC Payload ID may break backwards compatibility, since source Source FEC Payload ID may break backwards compatibility, since source
packets are modified. packets are modified.
6.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 must use the same Explicit Source FEC
Payload Id format. In order to enable this, it is RECOMMENDED that Payload Id format. In order to enable this, it is RECOMMENDED that
FEC Schemes support the Generic Explicit Source FEC Payload Id format FEC Schemes support the Generic Explicit Source FEC Payload Id format
described below. described below.
The Generic Explicit Source FEC Payload Id has length 2 bytes and The Generic Explicit Source FEC Payload Id has length of 2 bytes and
consists of an unsigned packet sequence number in network byte order. consists of an unsigned packet sequence number in network byte order.
The allocation of sequence numbers to packets is independent of any The allocation of sequence numbers to packets is independent of any
FEC Scheme and of the Source Block contruction, except that the use FEC Scheme and of the Source Block construction, except that the use
of this sequence number places a constraint on source block of this sequence number places a constraint on source block
construction source packets within a 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 65535 to 0). Sequence numbers SHOULD NOT be reused until all from the maximum value which can be represented in 2 bytes - 65535 -
values in the sequence number space have been used. to 0). Sequence numbers SHOULD NOT be reused until all values in the
sequence number space have been used.
6.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 |
+------------------------------------+ +------------------------------------+
skipping to change at page 24, line 47 skipping to change at page 23, line 48
| 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.
6.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
6.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 Content Delivery Protocol specification that uses
the framework specified here MUST include details of how this the framework specified here MUST include details of how this
information is derived and communicated between sender and receiver. information is derived and communicated between sender and receiver.
The FEC Framework Configuration Information includes identification The FEC Framework Configuration Information includes identification
of the set of Source Data Flows. For example, in the case of UDP, of the set of Source Data Flows. For example, in the case of UDP,
each Source Data Flow is uniquely identified by a tuple { Source IP each Source Data Flow is uniquely identified by a tuple { Source IP
Address, Destination IP Address, Source UDP port, Destination UDP Address, Destination IP Address, Source UDP port, Destination UDP
port }. Note that in some applications some of these fields may be port }. Note that in some applications some of these fields may
wildcarded, so that the flow is identified by a subset of the fields contain wildcards, so that the flow is identified by a subset of the
and in particular in many applications the limited tuple { fields and in particular in many applications the limited tuple {
Destination IP Address, Destination UDP port } is sufficient. Destination IP Address, Destination UDP port } is sufficient.
A single instance of the FEC Framework provides FEC protection for A single instance of the FEC Framework provides FEC protection for
packets of the specified set of Source Data Flows, by means of one or packets of the specified set of Source Data Flows, by means of one or
more packet flows consisting of repair packets. The FEC Framework more packet flows consisting of repair packets. The FEC Framework
Configuation 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 packet flow(s) carrying FEC Repair
packets, known as the FEC repair flow(s). packets, known as the FEC repair flow(s).
2. For each Source Data Flow protected by the FEC repair flow(s): 2. For each Source Data Flow protected by the FEC repair flow(s):
a. Defintion of the Source Data Flow carrying source packets a. Definition of the Source Data Flow carrying source packets
(for example, by means of a tuple as describe above for UDP). (for example, by means of a tuple as described above for UDP).
b. An integer identifier for this flow definition (i.e. b. An integer identifier for this Source Data Flow. This
tuple). This identifier MUST be unique amongst all Source Data identifier MUST be unique amongst all Source Data Flows which
Flows which are protected by the same FEC repair flow. are protected by the same FEC repair flow.
3. The FEC Encoding ID, identifying the FEC Scheme 3. The FEC Encoding ID, identifying the FEC Scheme
4. The length of the Explicit Source FEC Payload Id, in bytes 4. The length of the Explicit Source FEC Payload Id, in bytes
5. Zero or more FEC-Scheme-specific information elements, each 5. Zero or more FEC-Scheme-specific information elements, each
consisting of a name and a value where the valid element names and consisting of a name and a value where the valid element names and
value ranges are defined by the FEC Scheme 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, may be present
at a sender or receiver. A single instance of the FEC Framework at a sender or receiver. A single instance of the FEC Framework
protects packets of the Source Data Flows identified in (2) above protects packets of the Source Data Flows identified in (2) above
i.e. all packets sent on those flows MUST be FEC Source packets as i.e. all packets sent on those flows MUST be FEC Source packets as
defined in Section 6.3. A single Source Data Flow may be protected defined in Section 5.3. A single Source Data Flow may be protected
by multiple instances of the FEC Framework. by multiple instances of the FEC Framework.
The integer flow identifier identified in 2(b) is a "shorthand" to The integer flow identifier identified in 2(b) is a "shorthand" to
identify source flows between the FEC Framework and the FEC Scheme. identify source flows between the FEC Framework and the FEC Scheme.
The reason for defining this as an integer, and including it in the The reason for defining this as an integer, and including it in the
FEC Framework Configuration Information is so that the FEC Scheme at FEC Framework Configuration Information is so that the FEC Scheme at
the sender and receiver may use it to identify the source flow with the sender and receiver may use it to identify the source flow with
which a recovered packet is associated. The integer flow identifier which a recovered packet is associated. The integer flow identifier
may therefore take the place of the complete flow description (e.g. may therefore take the place of the complete flow description (e.g.
UDP 4-tuple). UDP 4-tuple).
skipping to change at page 26, line 44 skipping to change at page 25, line 48
multiple source flows, repair packets would either not carry the multiple source flows, repair packets would either not carry the
identifier at all or may carry multiple identifiers. However, in any identifier at all or may carry multiple identifiers. However, in any
case, the flow identifier associated with a particular source packet case, the flow identifier associated with a particular source packet
may be recovered from the repair packets as part of an FEC decoding may be recovered from the repair packets as part of an FEC decoding
operation. Integer flow identifiers SHOULD be allocated starting operation. Integer flow identifiers SHOULD be allocated starting
from zero and increasing by one for each flow. from zero and increasing by one for each flow.
A single FEC repair flow provides repair packets for a single A single FEC repair flow provides repair packets for a single
instance of the FEC Framework. Other packets MUST NOT be sent within instance of the FEC Framework. Other packets MUST NOT be sent within
this flow i.e. all packets in the FEC repair flow MUST be FEC repair this flow i.e. all packets in the FEC repair flow MUST be FEC repair
packets as defined in Section 6.4 and MUST relate to the same FEC packets as defined in Section 5.4 and MUST relate to the same FEC
Framework instance. Framework instance.
In the case that RTP is used for repair packets, the identification In the case that RTP is used for repair packets, the identification
of the repair packet flow MAY also include the RTP Payload Type to be of the repair packet flow MAY also include the RTP Payload Type to be
used for repair packets. used for repair packets.
FEC Scheme-specific information elements MAY be encoded into a text FEC Scheme-specific information elements MAY be encoded into a text
string for transport within Content Delivery Protocols as according string for transport within Content Delivery Protocols as according
to the following ABNF [RFC5234]: to the following ABNF [RFC5234]:
scheme-specific-info = [ element *( ',' element ) ] scheme-specific-info = [ element *( ',' element ) ]
element = name ':' value element = name ':' value
name = token name = token
token = 1*<any CHAR except CTLs or separators> token = 1*<any CHAR except CTLs or separators>
value = *<any CHAR except CTLs or separators> value = *<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@" separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <"> | "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "=" | "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT | "{" | "}" | SP | HT
6.6. FEC Scheme requirements 5.6. FEC Scheme requirements
In order to be used with this framework, an FEC Scheme MUST be In order to be used with this framework, an FEC Scheme MUST be
capable of processing data arranged into blocks of Application Data capable of processing data arranged into blocks of Application Data
Units (source blocks). Units (source blocks).
A specification for a new FEC scheme MUST include the following A specification for a new FEC scheme MUST include the following
things: things:
1. The FEC Encoding ID value that uniquely identifies the FEC 1. The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA as described in scheme. This value MUST be registered with IANA as described in
Section 11. Section 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 FEC Framework Configuration
Information elements. Names must conform to the Information elements. Names must conform to the "name"
"name"__production and values encodings to the "value" __ production and values encodings to the "value" production defined
production defined in Section 6.5 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 FEC Framework Configuration Information values, the
valid FEC Payload ID values and the valid packet payload sizes valid FEC Payload ID values and the valid packet payload sizes
(where packet payload refers to the space within a packet (where packet payload refers to the space within a packet
dedicated to carrying encoding symbol bytes). dedicated to carrying encoding symbol bytes).
Furthermore, given a source block as defined in Section 6.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 FEC Framework
Configuration Information, a valid Repair FEC Payload ID value Configuration Information, a valid Repair FEC Payload ID value
and a valid packet payload size, the specification MUST uniquely and a valid packet payload size, the specification MUST uniquely
define the values of the encoding symbol bytes to be included in define the values of the encoding symbol bytes to be included in
the repair packet payload of a packet with the given Repair FEC the repair packet payload of a packet with the given Repair FEC
Payload ID value. Payload ID value.
A common and simple way to specify the FEC code to the required A common and simple way to specify the FEC code to the required
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
skipping to change at page 30, line 5 skipping to change at page 29, line 5
Each FEC scheme MUST be specified independently of all other FEC Each FEC scheme MUST be specified independently of all other FEC
schemes; for example, in a separate specification or a completely schemes; for example, in a separate specification or a completely
independent section of larger specification (except, of course, a independent section of larger specification (except, of course, a
specification of one FEC Scheme may include portions of another by specification of one FEC Scheme may include portions of another by
reference). reference).
Where an RTP Payload Format is defined for repair data for a specific Where an RTP Payload Format is defined for repair data for a specific
FEC Scheme, the RTP Payload Format and the FEC Scheme MAY be FEC Scheme, the RTP Payload Format and the FEC Scheme MAY be
specified within the same document. specified within the same document.
7. 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: how much data arrived at the receiver, at what rate,
when etc. When FEC is added to such applications, feedback when etc. When FEC is added to such applications, feedback
mechanisms may also need to be enhanced to report on the performance mechanisms may also need to be enhanced to report on the performance
of the FEC (for example how much lost data was recovered by the FEC). of the FEC (for example how much lost data was recovered by the FEC).
When used to provide instrumentation for engineering purposes, it is When used to provide instrumentation for engineering purposes, it is
important to remember that FEC is generally applied to relatively important to remember that FEC is generally applied to relatively
small blocks of data (in time) and so feedback information averaged small blocks of data (in the sense that each block is transmitted
over longer periods of time than the FEC block size will likely not over a relatively small period of time) and so feedback information
provide sufficient information for engineering purposes. For example averaged over longer periods of time than the FEC block transmission
see [RFC5725]. time will likely not provide sufficient information for engineering
purposes. For example 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].
8. Transport Protocols 7. Transport Protocols
The following transport protocols are supported:
o User Datagram Protocol (UDP)
o Datagram Congestion Control Protocol (DCCP) This framework is intended to be used to define Content Delivery
Protocols which operate over transport protocols which provide an
unreliable datagram service, including in particular the User
Datagram Protocol (UDP) and the Datagram Congestion Control Protocol
(DCCP).
9. Congestion Control 8. Congestion Control
This section starts with a informative section on the motivation of This section starts with a informative section on the motivation of
the normative requirements for congestion control, which are spelled the normative requirements for congestion control, which are spelled
out in Section 9.1. out in Section 8.1.
Informative Note: The enforcement of Congestion Control (CC) Informative Note: The enforcement of Congestion Control (CC)
principles has gained a lot of momentum in the IETF over the principles has gained a lot of momentum in the IETF over the
recent years. While the need of CC over the open Internet is recent years. While the need of CC over the open Internet is
unquestioned, and the goal of TCP friendliness is generally agreed unquestioned, and the goal of TCP friendliness is generally agreed
for most (but not all) applications, the subject of congestion for most (but not all) applications, the subject of congestion
detection and measurement in heterogenous networks can hardly be detection and measurement in heterogeneous networks can hardly be
considered as solved. Most congestion control algorithms detect considered as solved. Most congestion control algorithms detect
and measure congestion by taking (primarily or exclusively) the and measure congestion by taking (primarily or exclusively) the
packet loss rate into account. This appears to be inappropriate packet loss rate into account. This appears to be inappropriate
in environments where a large percentage of the packet losses are in environments where a large percentage of the packet losses are
the result link-layer errors and independent of the network load. the result of link-layer errors and independent of the network
Note that such environments exist in the "open Internet", as well load. Note that such environments exist in the "open Internet",
as in "closed" IP based networks. An example for the former would as well as in "closed" IP based networks. An example for the
be the use of IP/UDP/RTP based streaming from an Internet- former would be the use of IP/UDP/RTP based streaming from an
connected streaming server to a device attached to the Internet Internet-connected streaming server to a device attached to the
using cellular technology. Internet using cellular technology.
The authors of this draft are primarily interested in applications The authors of this draft are primarily interested in applications
where the application reliability requirements and end-to-end where the application reliability requirements and end-to-end
reliability of the network differ, such that it warrants higher reliability of the network differ, such that it warrants higher
layer protection of the packet stream - for example due to the layer protection of the packet stream - for example due to the
presence of unreliable links in the end-to-end path - and where presence of unreliable links in the end-to-end path - and where
real-time, scalability or other constraints prohibit the use of real-time, scalability or other constraints prohibit the use of
higher layer (transport or application) feedback. A typical 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 heterogenous networks. In other or multimedia transmission over heterogeneous networks. In other
cases, application reliability requirements may be so high that cases, application reliability requirements may be so high that
the required end-to-end reliability is difficult to achieve even the required end-to-end reliability is difficult to achieve even
over wired networks. Furthermore the end-to-end network over wired networks. Furthermore the end-to-end network
reliability may not be known in advance. reliability may not be known in advance.
This FEC framework is not proposed, nor intended, as a QoS This FEC framework is not proposed, nor intended, as a QoS
enhancement tool to combat losses resulting from highly congested enhancement tool to combat losses resulting from highly congested
networks. It should not be used for such purposes. networks. It should not be used for such purposes.
In order to prevent such mis-use, one approach would be to leave In order to prevent such mis-use, one approach would be to leave
skipping to change at page 33, line 22 skipping to change at page 32, line 22
principles. One possible example for such an application could be principles. One possible example for such an application could be
a no-matter-what, brute-force FEC protection of traffic generated a no-matter-what, brute-force FEC protection of traffic generated
as an emergency signal. as an emergency signal.
We propose a third approach, which is to require at a minimum that We propose a third approach, which is to require at a minimum that
the use of this framework with any given application, in any given the use of this framework with any given application, in any given
environment, does not cause congestion issues which the environment, does not cause congestion issues which the
application alone would not itself cause i.e. the use of this application alone would not itself cause i.e. the use of this
framework must not make things worse. framework must not make things worse.
Taking above considerations into account, the normative text of Taking above considerations into account, Section 8.1 specifies a
this section implements a small set of constraints for the FEC, small set of constraints for the FEC, which are mandatory for all
which are mandatory for all senders compliant with this FEC senders compliant with this FEC framework. Further restrictions
framework. Further restrictions may be imposed for certain may be imposed for certain Content Delivery Protocols. In this it
Content Delivery Protocols. In this it follows the spirit of the follows the spirit of the congestion control section of RTP and
congestion control section of RTP and its Audio-Visual Profile its Audio-Visual Profile (RFC3550/STD64 and RFC3551/STD65).
(RFC3550/STD64 and RFC3551/STD65).
One of the constraints effectively limits the bandwidth for the One of the constraints effectively limits the bandwidth for the
FEC protected packet stream to be no more than roughly twice as FEC protected packet stream to be no more than roughly twice as
high as the original, non-FEC protected packet stream. This high as the original, non-FEC protected packet stream. This
disallows the (static or dynamic) use of excessively strong FEC to disallows the (static or dynamic) use of excessively strong FEC to
combat high packet loss rates, which may otherwise be chosen by combat high packet loss rates, which may otherwise be chosen by
naively implemented dynamic FEC-strength selection mechanisms. We naively implemented dynamic FEC-strength selection mechanisms. We
acknowledge that there may be a few exotic applications, e.g. IP acknowledge that there may be 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 would warrant a higher FEC strength.
However, in this specification we give preference to the overall However, in this specification we give preference to the overall
stability and network friendliness of the average application, and stability and network friendliness of the average application, and
for those a factor of 2 appears to be appropriate. for those a factor of 2 appears to be appropriate.
A second constraint requires that the FEC protected packet stream A second constraint requires that the FEC protected packet stream
be in compliance with the congestion control in use for the be in compliance with the congestion control in use for the
application and network in question. application and network in question.
9.1. Normative requirements 8.1. Normative requirements
The bandwidth of FEC Repair packet flows MUST NOT exceed the The bandwidth of FEC Repair packet flows MUST NOT exceed the
bandwidth of the source packet flows being protected. In addition, bandwidth of the source packet flows being protected. In addition,
whenever the source packet flow bandwidth is adapted due to the whenever the source packet flow bandwidth is adapted due to the
operation of congestion control mechanisms, the FEC repair packet operation of congestion control mechanisms, the FEC repair packet
flow bandwidth MUST be similarly adapted. flow bandwidth MUST be similarly adapted.
10. Security Considerations 9. Security Considerations
The application of FEC protection to a stream does not provide any The application of FEC protection to a stream does not provide any
kind of security protection. kind of security protection.
If security services are required for the stream, then they MUST If security services are required for the stream, then they MUST
either be applied to the original source data before FEC protection either be applied to the original source 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 Application Data
Units being passed up to the application protocol. A similar attack Units being passed up to the application protocol. A similar attack
may be possible if an attacker is in a position to inject fack FEC may be possible if an attacker is in a position to inject fake FEC
Framework Configuration Information or fake FEC Payload IDs. Such Framework Configuration Information or fake FEC Payload IDs. Such
incorrect decoded Application Data Units would then be detected by incorrect decoded Application Data Units would then be detected by
the source integrity protection and discarded, resulting in partial the source integrity protection and discarded, resulting in partial
or complete denial of service. Therefore, in such environments, or complete denial of service. Therefore, in such environments,
integrity protection MUST also be applied to the FEC repair transport integrity protection MUST also be applied to the FEC repair transport
payloads, FEC Framework Configuration Information and FEC Payload payloads, FEC Framework Configuration Information and FEC Payload
IDs, for example using IPsec to integrity protect all packets. IDs, for example using IPsec to integrity protect all packets.
Receivers MUST also verify the integrity of source symbols before Receivers MUST also verify the integrity of source symbols before
including the source symbols into the source block for FEC purposes. including the source symbols into the source block for FEC purposes.
It is possible that multiple streams with different confidentiality It is possible that multiple streams with different confidentiality
requirements (for example, the streams may be visible to different requirements (for example, the streams may be visible to different
sets of users) can be FEC protected by a single repair stream. This sets of users) can be FEC protected by a single repair stream. This
scenario is not recommended, since resources will be used to scenario is not recommended, since resources will be used to
distribute and decode data which cannot then be decrypted by at least distribute and FEC decode encrypted data which cannot then be
some receivers. However, in this scenario, confidentiality decrypted by at least some receivers. However, in this scenario,
protection MUST be applied before FEC encoding of the streams, confidentiality protection MUST be applied before FEC encoding of the
otherwise repair transport payload may be used by a receiver to streams, otherwise repair transport payload may be used by a receiver
decode unencrypted versions of source streams which they do not have to decode unencrypted versions of source streams which they do not
permissionions to view. have permissions to view.
11. IANA Considerations 10. IANA Considerations
FEC Schemes for use with this framework may be identified in FEC Schemes for use with this framework may be identified in
protocols using FEC Encoding IDs. Values of FEC Encoding IDs are protocols using FEC Encoding IDs. Values of FEC Encoding IDs are
subject to IANA registration. They are in the registry named "FEC subject to IANA registration. They are in the registry named "FEC
Framework (FECFRAME) FEC Encoding IDs" located at time of publication Framework (FECFRAME) FEC Encoding IDs" located at time of publication
at <tbd>. 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 a "IETF
Consensus" basis as defined in[RFC5226] . Section 6.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.
12. 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.
13. References 12. References
13.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,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
skipping to change at page 38, line 33 skipping to change at page 36, line 33
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative references 12.2. Informative references
[I-D.watson-tsvwg-fec-sf] [I-D.watson-tsvwg-fec-sf]
Watson, M., "Forward Error Correction (FEC) Streaming Watson, M., "Forward Error Correction (FEC) Streaming
Framework", draft-watson-tsvwg-fec-sf-00 (work in Framework", draft-watson-tsvwg-fec-sf-00 (work in
progress), July 2005. progress), July 2005.
[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.
 End of changes. 81 change blocks. 
194 lines changed or deleted 193 lines changed or added

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