One document matched: draft-ietf-fecframe-framework-15.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3095 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3095.xml">
<!ENTITY rfc5052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5052.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY fecsf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.watson-tsvwg-fec-sf.xml">
<!ENTITY fecsdp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-fecframe-sdp-elements.xml">
<!ENTITY rfc5725 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5725.xml">
<!ENTITY rfc4588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4588.xml">
<!ENTITY rfc2736 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2736.xml">
<!ENTITY rfc4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc5740 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5740.xml">
<!ENTITY rfc4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY rfc4383 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4383.xml">
<!ENTITY rfc5775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5775.xml">
<!ENTITY rfc5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY rfc3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY rfc5675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5675.xml">
<!ENTITY rfc5676 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5676.xml">
]>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-ietf-fecframe-framework-15"
ipr="pre5378Trust200902">
<front>
<title abbrev="FEC Framework">Forward Error Correction (FEC)
Framework</title>
<author fullname="Mark Watson" initials="M." surname="Watson">
<organization>Netflix, Inc.</organization>
<address>
<postal>
<street>100 Winchester Circle</street>
<city>Los Gatos</city>
<region>CA</region>
<code>95032</code>
<country>USA</country>
</postal>
<email>watsonm@netflix.com</email>
</address>
</author>
<author fullname="Ali Begen" initials="A." surname="Begen">
<organization>Cisco</organization>
<address>
<postal>
<street>181 Bay Street</street>
<city>Toronto</city>
<region>ON</region>
<code>M5J 2T3</code>
<country>Canada</country>
</postal>
<email>abegen@cisco.com</email>
</address>
</author>
<author fullname="Vincent Roca" initials="V" surname="Roca">
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Inovallee; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/people/roca/</uri>
</address>
</author>
<date day="9" month="June" year="2011" />
<workgroup>FEC Framework</workgroup>
<abstract>
<t>This document describes a framework for using Forward Error
Correction (FEC) codes with applications in public and private IP
networks to provide protection against packet loss. The framework
supports applying FEC to arbitrary packet flows over unreliable
transport and is primarily intended for real-time, or streaming, media.
This framework can be used to define Content Delivery Protocols that
provide FEC for streaming media delivery or other packet flows. Content
Delivery Protocols defined using this framework can support any FEC
scheme (and associated FEC codes) which is compliant with various
requirements defined in this document. Thus, Content Delivery Protocols
can be defined which are not specific to a particular FEC scheme, and
FEC schemes can be defined which are not specific to a particular
Content Delivery Protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Many applications have a requirement to transport a continuous stream
of packetized data from a source (sender) to one or more destinations
(receivers) over networks which do not provide guaranteed packet
delivery. Primary examples are real-time, or streaming, media
applications such as broadcast, multicast or on-demand audio, video or
multimedia.</t>
<t>Forward Error Correction (FEC) is a well-known technique for
improving reliability of packet transmission over networks which do not
provide guaranteed packet delivery, especially in multicast and
broadcast applications. The FEC Building Block defined in <xref
target="RFC5052"></xref> provides a framework for definition of Content
Delivery Protocols (CDPs) for object delivery (including, primarily,
file delivery) which make use of separately defined FEC schemes. Any CDP
defined according to the requirements of the FEC Building Block can then
easily be used with any FEC scheme which is also defined according to
the requirements of the FEC Building Block.</t>
<t>Note that the term "Forward Erasure Correction" is sometimes used,
erasures being a type of error in which data is lost and this loss can
be detected, rather than being received in corrupted form. The focus of
this document is strictly on erasures and, the term "Forward Error
Correction" is more widely used.</t>
<t>This document defines a framework for the definition of CDPs which
provide for FEC protection for arbitrary packet flows over unreliable
transports such as UDP. As such, this document complements the FEC
Building Block of <xref target="RFC5052"></xref>, by providing for the
case of arbitrary packet flows over unreliable transport, the same kind
of framework as that document provides for object delivery. This
document does not define a complete CDP, but rather defines only those
aspects that are expected to be common to all CDPs based on this
framework.</t>
<t>This framework does not define how the flows to be protected are
determined, nor how the details of the protected flows and the FEC
streams which protect them are communicated from sender to receiver. It
is expected that any complete CDP specification which makes use of this
framework will address these signaling requirements. However, this
document does specify the information which is required by the FEC
Framework at the sender and receiver, e.g., details of the flows to be
FEC protected, the flow(s) that will carry the FEC protection data and
an opaque container for FEC-Scheme-Specific Information.</t>
<t>FEC schemes designed for use with this framework must fulfill a
number of requirements defined in this document. These requirements are
different from those defined in <xref target="RFC5052"></xref> for FEC
schemes for object delivery. However, there is a great deal of
commonality and FEC schemes defined for object delivery may be easily
adapted for use with the framework defined in this document.</t>
<t>Since the RTP protocol is (often) used over UDP, this framework can
be applied to RTP flows as well. FEC repair packets may be sent directly
over UDP or RTP. The latter approach has the advantage that RTP
instrumentation, based on RTP Control Protocol (RTCP), can be used for
the repair flow. Additionally, the post-repair RTCP extended reports
<xref target="RFC5725"></xref> may be used to obtain information about
the loss rate after FEC recovery.</t>
<t>The use of RTP for repair flows is defined for each FEC scheme by
defining an RTP payload format for that particular FEC scheme (possibly
in the same document).</t>
</section>
<section title="Definitions and Abbreviations">
<t>Application Data Unit (ADU): The unit of source data provided as
payload to the transport layer.</t>
<t>ADU Flow: A sequence of ADUs associated with a transport-layer flow
identifier (such as the standard 5-tuple {Source IP address, source
port, destination IP address, destination port, transport
protocol}).</t>
<t>AL-FEC: Application-layer Forward Error Correction.</t>
<t>Application Protocol: Control protocol used to establish and control
the source flow being protected, e.g., RTSP.</t>
<t>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.</t>
<t>FEC Code: An algorithm for encoding data such that the encoded data
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 is not
considered in this document.</t>
<t>FEC Framework: A protocol framework for definition of Content
Delivery Protocols using FEC, such as the framework defined in this
document.</t>
<t>FEC Framework Configuration Information: Information which controls
the operation of the FEC Framework.</t>
<t>FEC Payload ID: Information which identifies the contents of a packet
with respect to the FEC scheme.</t>
<t>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.</t>
<t>FEC Scheme: A specification which defines the additional protocol
aspects required to use a particular FEC code with the FEC
Framework.</t>
<t>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 Explicit Source FEC
Payload ID.</t>
<t>Protection Amount: The relative increase in data sent due to the use
of FEC.</t>
<t>Repair Flow: The packet flow carrying FEC data.</t>
<t>Repair FEC Payload ID: An FEC Payload ID specifically for use with
repair packets.</t>
<t>Source Flow: The packet flow to which FEC protection is to be
applied. A source flow consists of ADUs.</t>
<t>Source FEC Payload ID: An FEC Payload ID specifically for use with
source packets.</t>
<t>Source Protocol: A protocol used for the source flow being protected,
e.g., RTP.</t>
<t>Transport Protocol: The protocol used for transport of the source and
repair flows, e.g., UDP and DCCP.</t>
<t>The following definitions are aligned with <xref
target="RFC5052"></xref>:</t>
<t>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.</t>
<t>Encoding Symbol: Unit of data generated by the encoding process. With
systematic codes, source symbols are part of the encoding symbols.</t>
<t>Packet Erasure Channel: A communication path where packets are either
dropped (e.g., by a congested router, or because the number of
transmission errors exceeds the correction capabilities of the
physical-layer codes) or received. When a packet is received, it is
assumed that this packet is not corrupted.</t>
<t>Repair Symbol: Encoding symbol that is not a source symbol.</t>
<t>Source Block: Group of ADUs which are to be FEC protected as a single
block.</t>
<t>Source Symbol: Unit of data used during the encoding process.</t>
<t>Systematic Code: FEC code in which the source symbols are part of the
encoding symbols.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Architecture Overview">
<t>The FEC Framework is described in terms of an additional layer
between the transport layer (e.g., UDP or DCCP) and protocols running
over this transport layer. As such, the data path interface between the
FEC Framework and 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 exchanged consists of datagram payloads each associated
with a single ADU flow identified by the standard 5-tuple {Source IP
address, source port, destination IP address, destination port,
transport protocol}. In the case that RTP is used for the repair flows,
the source and repair data can be multiplexed using RTP onto a single
UDP flow and needs to be consequently demultiplexed at the receiver.
There are various ways in which this multiplexing can be done, for
example as described in <xref target="RFC4588"></xref>.</t>
<t>It is important to understand that the main purpose of the FEC
Framework architecture is to allocate functional responsibilities to
separately documented components in such a way that specific instances
of the components can be combined in different ways to describe
different protocols.</t>
<t>The FEC Framework makes use of an FEC scheme, in a similar sense to
that defined in <xref target="RFC5052"></xref> and uses the terminology
of that document. The FEC scheme defines the FEC encoding and decoding,
and defines the protocol fields and procedures used to identify packet
payload data in the context of the FEC scheme. The interface between the
FEC Framework and an FEC scheme, which is described in this document, is
a logical one, which exists for specification purposes only. At an
encoder, the FEC Framework passes ADUs to the FEC scheme for FEC
encoding. The FEC scheme returns repair symbols with their associated
Repair FEC Payload IDs, and in some cases Source FEC Payload IDs,
depending on the FEC scheme. At a decoder, the FEC Framework passes
transport packet payloads (source and repair) to the FEC scheme and the
FEC scheme returns additional recovered source packet payloads.</t>
<t>This document defines certain FEC Framework Configuration Information
which MUST be available to both sender and receiver(s). For example,
this information includes the specification of the ADU flows which are
to be FEC protected, specification of the ADU flow(s) which will carry
the FEC protection (repair) data and the relationship(s) between these
source and repair flows (i.e., which source flow(s) are protected by
each repair flow(s)). The FEC Framework Configuration Information also
includes information fields which are specific to the FEC scheme. This
information is analogous to the FEC Object Transmission Information
defined in <xref target="RFC5052"></xref>.</t>
<t>The FEC Framework does not define how the FEC Framework Configuration
Information for the stream is communicated from sender to receiver. This
has to be defined by any CDP specification as described in the following
sections.</t>
<t>In this architecture we assume that the interface to the transport
layer supports the concepts of data units (referred to here as
Application Data Units (ADUs)) to be transported and identification of
ADU flows on which those data units are transported. Since this is an
interface internal to the architecture, we do not specify this interface
explicitly. We do require that ADU flows which are distinct from the
transport layer point of view (for example, distinct UDP flows as
identified by the UDP source/destination addresses/ports) are also
distinct on the interface between the transport layer and the FEC
Framework.</t>
<t>As noted above, RTP flows are a specific example of ADU flows which
might be protected by the FEC Framework. From the FEC Framework point of
view, RTP source flows are ADU flows like any other, with the RTP header
included within the ADU.</t>
<t>Depending on the FEC scheme, RTP can also be used as a transport for
repair packet flows. In this case an FEC scheme has to define an RTP
payload format for the repair data.</t>
<t>The architecture outlined above is illustrated in the <xref
target="architecturefigure"></xref>. In this architecture, two
(optional) RTP instances are shown, for the source and repair data
respectively. This is because the use of RTP for the source data is
separate from and independent of the use of RTP for the repair data. The
appearance of two RTP instances is more natural when one considers that
in many FEC codes, the repair payload contains repair data calculated
across the RTP headers of the source packets. Thus, a repair packet
carried over RTP starts with an RTP header of its own which is followed
(after the Repair Payload ID) by repair data containing bytes which
protect the source RTP headers (as well as repair data for the source
RTP payloads).</t>
<figure align="center" anchor="architecturefigure"
title="FEC Framework architecture">
<artwork><![CDATA[
+--------------------------------------------+
| Application |
+--------------------------------------------+
|
|
|
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ |
| Application Layer |
| +--------------------------------------------+ |
| |
| + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP (Optional) | |
| | | |- Configuration/
+- -- -- -- -- -- -- -- -- -- -- -+ | Coordination
| | | |
| ADU flows |
| | v |
+--------------------------------------------+ +------------+
| | FEC Framework (This document) |<--->| FEC Scheme |
+--------------------------------------------+ +------------+
| | | |
Source | Repair |
| | | |
+-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
| | RTP Layer | | RTP Processing | | |
| (Optional) | +-- -- -- |- -- -+ |
| | +-- -- -- -- -- -- -- |--+ | |
| | RTP (De)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
|
| +--------------------------------------------+ |
| Transport Layer (e.g., UDP) |
| +--------------------------------------------+ |
|
| +--------------------------------------------+ |
| IP |
| +--------------------------------------------+ |
| Content Delivery Protocol |
+ - - - - - - - - - - - - - - - - - - - - - - - +]]></artwork>
</figure>
<t></t>
<t>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 repair
packet payload format starts with the RTP header. This corresponds to
defining an RTP payload format for the specific FEC scheme.</t>
<t>The use of RTP for repair packets is independent of the protocols
used for source packets: if RTP is used for source packets, 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 are protected
by RTP repair flows). FEC schemes are expected to recover entire
transport payloads for recovered source packets in all cases. For
example, if RTP is used for source flows, the FEC scheme is expected to
recover the entire UDP payload, including the RTP header.</t>
</section>
<section title="Procedural Overview">
<section title="General">
<t>The mechanism defined in this document does not place any
restrictions on the ADUs which can be protected together, except that
the ADU is carried over a supported transport protocol (See <xref
target="TransportProtocols"></xref>). The data can be from multiple
source flows that are protected jointly. The FEC Framework handles the
source flows as a sequence of source blocks each consisting of a set
of ADUs, possibly from multiple source flows which are to be protected
together. For example, each source block can be constructed from those
ADUs related to a particular segment in time of the flow.</t>
<t>At the sender, the FEC Framework passes the payloads for a given
block to the FEC scheme for FEC encoding. The FEC scheme performs the
FEC encoding operation and returns the following information: <list
style="symbols">
<t>Optionally, FEC Payload IDs for each of the source payloads
(encoded according to an FEC-Scheme-Specific format).</t>
<t>One or more FEC repair packet payloads.</t>
<t>FEC Payload IDs for each of the repair packet payloads (encoded
according to an FEC-Scheme-Specific format).</t>
</list></t>
<t>The FEC Framework then performs two operations. First, it appends
the Source FEC Payload IDs, if provided, to each of the ADUs, and
sends the resulting packets, known as FEC source packets, to the
receiver, and second it places the provided FEC repair packet payloads
and corresponding Repair FEC Payload IDs appropriately to construct
FEC repair packets and send them to the receiver.</t>
<t>This document does not define how the sender determines which ADUs
are included in which source blocks or the sending order and timing of
FEC source and repair packets. A specific CDP MAY define this mapping
or it MAY be left as implementation dependent at the sender. However,
a CDP specification MUST define how a receiver determines a minimum
length of time that it needs to wait to receive FEC repair packets for
any given source block. FEC schemes MAY define limitations on this
mapping, such as maximum size of source blocks, but SHOULD NOT attempt
to define specific mappings. The sequence of operations at the sender
is described in more detail in <xref
target="senderoperation"></xref>.</t>
<t>At the receiver, original ADUs are recovered by the FEC Framework
directly from any FEC source packets received simply by removing the
Source FEC Payload ID, if present. The receiver also passes the
contents of the received ADUs, plus their FEC Payload IDs to the FEC
scheme for possible decoding.</t>
<t>If any ADUs related to a given source block have been lost, then
the FEC scheme can perform FEC decoding to recover the missing ADUs
(assuming sufficient FEC source and repair packets related to that
source block have been received).</t>
<t>Note that the receiver might need to buffer received source packets
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
are passed to the application. If such a buffer is not provided, then
the application has to be able to deal with the severe re-ordering of
packets that can occur. However, such buffering is CDP and/or
implementation-specific and is not specified here. The receiver
operation is described in more detail in <xref
target="receiveroperation"></xref>.</t>
<t>The FEC source packets MUST contain information which identifies
the source block and the position within the source block (in terms
specific to the FEC scheme) occupied by the ADU. This information is
known as the Source FEC Payload ID. The FEC scheme is responsible for
defining and interpreting this information. This information MAY be
encoded into a specific field within the FEC source packet format
defined in this specification, called the Explicit Source FEC Payload
ID field. The exact contents and format of the Explicit Source FEC
Payload ID field are defined by the FEC schemes. Alternatively, the
FEC scheme MAY define how the Source FEC Payload ID is derived from
other fields within the source packets. This document defines the way
that the Explicit Source FEC Payload ID field is appended to source
packets to form FEC source packets.</t>
<t>The FEC repair packets MUST contain information which identifies
the source block and the relationship between the contained repair
payloads and the original source block. This is known as the Repair
FEC Payload ID. This information MUST be encoded into a specific
field, the Repair FEC Payload ID field, the contents and format of
which are defined by the FEC schemes.</t>
<t>The FEC scheme MAY use different FEC Payload ID field formats for
source and repair packets.</t>
</section>
<section anchor="senderoperation" title="Sender Operation">
<t>It is assumed that the sender has constructed or received original
data packets for the session. These could be carrying any type of
data. The following operations, illustrated in <xref
target="senderfigure"></xref>, for the case of UDP repair flows and
<xref target="senderfigurertp"></xref> for the case of RTP repair
flows, describe a possible way to generate compliant source and repair
flows: <list style="numbers">
<t>ADUs are provided by the application.</t>
<t>A source block is constructed as specified in <xref
target="sourceblock"></xref>.</t>
<t>The source block is passed to the FEC scheme for FEC encoding.
The Source FEC Payload ID information of each source packet is
determined by the FEC scheme. If required by the FEC scheme the
Source FEC Payload ID is encoded into the Explicit Source FEC
Payload ID field.</t>
<t>The FEC scheme performs FEC encoding, generating repair packet
payloads from a source block and a Repair FEC Payload ID field for
each repair payload.</t>
<t>The Explicit Source FEC Payload IDs (if used), Repair FEC
Payload IDs and repair packet payloads are provided back from the
FEC scheme to the FEC Framework.</t>
<t>The FEC Framework constructs FEC source packets according to
<xref target="sourcepackets"></xref> and FEC repair packets
according to <xref target="repairpackets"></xref> using the FEC
Payload IDs and repair packet payloads provided by the FEC
scheme.</t>
<t>The FEC source and repair packets are sent using normal
transport-layer procedures. The port(s) and multicast group(s) to
be used for FEC repair packets are defined in the FEC Framework
Configuration Information. The FEC source packets are sent using
the same ADU flow identification information as would have been
used for the original source packets if the FEC Framework were not
present (for example, in the UDP case, the UDP source and
destination addresses and ports on the IP datagram carrying the
source packet will be the same whether or not the FEC Framework is
applied).</t>
</list></t>
<figure align="center" anchor="senderfigure" title="Sender operation">
<artwork><![CDATA[
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source and repair | | |
| packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs
| Repair symbols
|
|(7) FEC source and repair packets
v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
]]></artwork>
</figure>
<t></t>
<figure align="center" anchor="senderfigurertp"
title="Sender operation with RTP repair flows">
<artwork><![CDATA[
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source packets and| | |
| repair payloads |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| | Repair FEC Payload IDs
| | Repair symbols
| |
|(7) Source |(7') Repair payloads
| packets |
| |
| + -- -- -- -- -+
| | RTP |
| +-- -- -- -- --+
v v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
]]></artwork>
</figure>
</section>
<section anchor="receiveroperation" title="Receiver Operation">
<t>The following describes a possible receiver algorithm, illustrated
in <xref target="receiverfigure"></xref> and <xref
target="receiverfigurertp"></xref> for the case of RTP repair flows,
when receiving an FEC source or repair packet: <list style="numbers">
<t>FEC source packets and FEC repair packets are received and
passed to the FEC Framework. The type of packet (source or repair)
and the source flow to which it belongs (in the case of source
packets) is indicated by the ADU flow information which identifies
the flow at the transport layer.<vspace blankLines="1" />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).</t>
<t>The FEC Framework extracts the Explicit Source FEC Payload ID
field (if present) from the source packets and the Repair FEC
Payload ID from the repair packets.</t>
<t>The Explicit Source FEC Payload IDs (if present), Repair FEC
Payload IDs, FEC source and repair payloads are passed to the FEC
scheme.</t>
<t>The FEC scheme uses the received FEC Payload IDs (and derived
FEC Source Payload IDs in the case that the Explicit Source FEC
Payload ID field is not used) to group source and repair packets
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.</t>
<t>The FEC scheme returns the ADUs to the FEC Framework in the
form of source blocks containing received and decoded ADUs and
indications of any ADUs which were missing and could not be
decoded.</t>
<t>The FEC Framework passes the received and recovered ADUs to the
application.</t>
</list></t>
<t>The description above defines functionality responsibilities but
does 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
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.</t>
<figure align="center" anchor="receiverfigure"
title="Receiver operation">
<preamble></preamble>
<artwork><![CDATA[
+----------------------+
| 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) |
+----------------------+
]]></artwork>
</figure>
<t></t>
<figure align="center" anchor="receiverfigurertp"
title="Receiver operation with RTP repair flows">
<preamble></preamble>
<artwork><![CDATA[
+----------------------+
| 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) |
+----------------------+
]]></artwork>
</figure>
<t></t>
<t>Note that the above procedure might result in a situation in which
not all ADUs are recovered.</t>
</section>
</section>
<section title="Protocol Specification">
<section title="General">
<t>This section specifies the protocol elements for the FEC Framework.
Three components of the protocol are defined in this document and are
described in the following sections: <list style="numbers">
<t>Construction of a source block from ADUs. The FEC code will be
applied to this source block to produce the repair payloads.</t>
<t>A format for packets containing source data.</t>
<t>A format for packets containing repair data.</t>
</list>The operation of the FEC Framework is governed by certain FEC
Framework Configuration Information, which is defined in this section.
A complete protocol specification that uses this framework MUST
specify the means to determine and communicate this information
between sender and receiver.</t>
</section>
<section anchor="sourceblock" title="Structure of the Source Block">
<t>The FEC Framework and FEC scheme exchange ADUs in the form of
source blocks. A source block is generated by the FEC Framework from
an ordered sequence of ADUs. The allocation of ADUs to blocks is
dependent on the application. Note that some ADUs may not be included
in any block. Each source block provided to the FEC scheme consists of
an ordered sequence of ADUs where the following information is
provided for each ADU: <list style="symbols">
<t>A description of the source flow with which the ADU is
associated with.</t>
<t>The ADU itself.</t>
<t>The length of the ADU.</t>
</list></t>
</section>
<section anchor="sourcepackets"
title="Packet Format for FEC Source Packets">
<t>The packet format for FEC source packets MUST be used to transport
the payload of an original source packet. As depicted in <xref
target="sourcepacketfigure"></xref>, it consists of the original
packet, optionally followed by the Explicit Source FEC Payload ID
field. The FEC scheme determines whether the Explicit Source FEC
Payload ID field is required. This determination is specific to each
ADU flow.</t>
<figure align="center" anchor="sourcepacketfigure"
title="Structure of the FEC packet format for FEC source packets">
<artwork><![CDATA[
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Application Data Unit |
+------------------------------------+
| Explicit Source FEC Payload ID |
+------------------------------------+
]]></artwork>
</figure>
<t></t>
<t>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 were not present. The transport payload of the FEC source
packet MUST consist of the ADU followed by the Explicit Source FEC
Payload ID field, if required.</t>
<t>The Explicit Source FEC Payload ID field contains information
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 format of the Source FEC Payload ID field is defined by the FEC
scheme. In the case that the FEC scheme or CDP defines a means to
derive the Source FEC Payload ID from other information in the packet
(for example a sequence number used by the application protocol), then
the Source FEC Payload ID field is not included in the packet. In this
case, the original source packet and FEC source packet are
identical.</t>
<t>In applications where avoidance of IP packet fragmentation is a
goal, CDPs SHOULD consider the Explicit Source FEC Payload ID size
when determining the size of ADUs that will be delivered using the FEC
Framework. This is because the addition of the Explicit Source FEC
Payload ID increases the packet length.</t>
<t>The Explicit Source FEC Payload ID is placed at the end of the
packet so that in the case that Robust Header Compression (ROHC) <xref
target="RFC3095"></xref> or other header compression mechanisms are
used and in the case that a ROHC profile is defined for the protocol
carried within the transport payload (for example RTP), then ROHC will
still be applied for the FEC source packets. Applications that are
used with this framework need to consider that FEC schemes can add
this Explicit Source FEC Payload ID and thereby increase the packet
size.</t>
<t>In many applications, support for FEC is added to a pre-existing
protocol and in this case use of the Explicit Source FEC Payload ID
can break backwards compatibility, since source packets are
modified.</t>
<section title="Generic Explicit Source FEC Payload ID">
<t>In order to apply FEC protection using multiple FEC schemes to a
single source flow, all schemes have to use the same Explicit Source
FEC Payload ID format. In order to enable this, it is RECOMMENDED
that FEC schemes support the Generic Explicit Source FEC Payload ID
format described below.</t>
<t>The Generic Explicit Source FEC Payload ID has a length of two
octets and consists of an unsigned packet sequence number in
network-byte order. The allocation of sequence numbers to packets is
independent of any FEC scheme and of the source block construction,
except that the use of this sequence number places a constraint on
source block construction. Source packets within a given source
block MUST have consecutive sequence numbers (where consecutive
includes wrap-around 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 sequence number space have been used.</t>
<t>Note that if the original packets of the source flow are already
carrying a packet sequence number that is at least two bytes long,
there is no need to add the generic Explicit Source FEC Payload ID
and modify the packets.</t>
</section>
</section>
<section anchor="repairpackets"
title="Packet Format for FEC Repair Packets">
<t>The packet format for FEC repair packets is shown in <xref
target="repairpacketfigure"></xref>. The transport payload consists of
a Repair FEC Payload ID field followed by repair data generated in the
FEC encoding process. <figure align="center"
anchor="repairpacketfigure"
title="Packet format for repair packets">
<artwork><![CDATA[
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
]]></artwork>
</figure></t>
<t>The Repair FEC Payload ID field contains information required for
the operation of the FEC algorithm at the receiver. This information
is defined by the FEC scheme. The format of the Repair FEC Payload ID
field is defined by the FEC scheme.</t>
<section title="Packet Format for FEC Repair Packets over RTP">
<t>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 <xref target="repairpacketfigureRTP"></xref>.</t>
<t><figure align="center" anchor="repairpacketfigureRTP"
title="Packet format for repair packets">
<artwork><![CDATA[
+------------------------------------+
| IP header |
+------------------------------------+
| Transport Header (UDP) |
+------------------------------------+
| RTP Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="config" title="FEC Framework Configuration Information">
<t>The FEC Framework Configuration Information is information that the
FEC Framework needs in order to apply FEC protection to the ADU flows.
A complete CDP specification that uses the framework specified here
MUST include details of how this information is derived and
communicated between sender and receiver.</t>
<t>The FEC Framework Configuration Information includes identification
of the set of source flows. For example, in the case of UDP, each
source flow is uniquely identified by a tuple {Source IP address,
source UDP port, destination IP address, destination UDP port}. In
some applications some of these fields can contain wildcards, so that
the flow is identified by a subset of the fields. In particular, in
many applications the limited tuple {Destination IP address,
destination UDP port} is sufficient.</t>
<t>A single instance of the FEC Framework provides FEC protection for
packets of the specified set of source flows, by means of one or more
packet flows consisting of repair packets. The FEC Framework
Configuration Information includes, for each instance of the FEC
Framework: <list style="numbers">
<t>Identification of the repair flows.</t>
<t>For each source flow protected by the repair flow(s): <list
style="letters">
<t>Definition of the source flow.</t>
<t>An integer identifier for this flow definition (i.e.,
tuple). This identifier MUST be unique amongst all source
flows that 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.</t>
</list></t>
<t>The FEC Encoding ID, identifying the FEC scheme.</t>
<t>The length of the Explicit Source FEC Payload ID (in
octets).</t>
<t>Zero or more FEC-Scheme-Specific Information (FSSI) elements,
each consisting of a name and a value where the valid element
names and value ranges are defined by the FEC scheme.</t>
</list></t>
<t>Multiple instances of the FEC Framework, with separate and
independent FEC Framework Configuration Information, can be present at
a sender or receiver. A single instance of the FEC Framework protects
packets of the source flows identified in (2) above, i.e., all packets
sent on those flows MUST be FEC source packets as defined in <xref
target="sourcepackets"></xref>. A single source flow can be protected
by multiple instances of the FEC Framework.</t>
<t>The integer flow identifier identified in (2b) above is a shorthand
to identify source flows between the FEC Framework and the FEC scheme.
The reason for defining this as an integer, and including it in the
FEC Framework Configuration Information is so that the FEC scheme at
the sender and receiver can use it to identify the source flow with
which a recovered packet is associated. The integer flow identifier
can therefore take the place of the complete flow description (e.g.,
UDP 4-tuple).</t>
<t>Whether and how this flow identifier is used is defined by the FEC
scheme. Since repair packets can provide protection for multiple
source flows, repair packets would either not carry the identifier at
all or can carry multiple identifiers. However, in any case, the flow
identifier associated with a particular source packet can be recovered
from the repair packets as part of an FEC decoding operation.</t>
<t>A single FEC repair flow provides repair packets for a single
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
packets as defined in <xref target="repairpackets"></xref> and MUST
relate to the same FEC Framework instance.</t>
<t>In the case that RTP is used for repair packets, the identification
of the repair packet flow can also include the RTP payload type to be
used for repair packets.</t>
<t>FSSI includes the information that is specific to the FEC scheme
used by the CDP. FSSI is used to communicate the information that
cannot be adequately represented otherwise and is essential for proper
FEC 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.</t>
<t>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.</t>
<t>For the CDPs that choose the Session Description Protocol (SDP)
<xref target="RFC4566"></xref> as their session description protocol,
the ABNF <xref target="RFC5234"></xref> syntax for the SS-FSSI and
FSSI containers is provided in Section 4.5 of <xref
target="I-D.ietf-fecframe-sdp-elements"></xref>.</t>
</section>
<section anchor="fecscheme" title="FEC Scheme Requirements">
<t>In order to be used with this framework, an FEC scheme MUST be
capable of processing data arranged into blocks of ADUs (source
blocks).</t>
<t>A specification for a new FEC scheme MUST include the following:
<list style="numbers">
<t>The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA as described in
<xref target="iana"></xref>.</t>
<t>The type, semantics and encoding format of the Repair FEC
Payload ID.</t>
<t>The name, type, semantics and text value encoding rules for
zero or more FEC-Scheme-Specific Information elements.</t>
<t>A full specification of the FEC code. <vspace
blankLines="1" />This specification MUST precisely define the
valid FEC-Scheme-Specific Information values, the valid FEC
Payload ID values and the valid packet payload sizes (where packet
payload refers to the space within a packet dedicated to carrying
encoding symbols). <vspace blankLines="1" />Furthermore, given a
source block as defined in <xref target="sourceblock"></xref>,
valid values of the FEC-Scheme-Specific Information, a valid
Repair FEC Payload ID value and a valid packet payload size, the
specification MUST uniquely define the values of the encoding
symbols to be included in the repair packet payload of a packet
with the given Repair FEC Payload ID value.<vspace
blankLines="1" />A common and simple way to specify the FEC code
to the required level of detail is to provide a precise
specification of an encoding algorithm which, given a source
block, valid values of the FEC-Scheme-Specific Information, a
valid Repair FEC Payload ID value and a valid packet payload size
as input produces the exact value of the encoding symbols as
output.</t>
<t>A description of practical encoding and decoding
algorithms.<vspace blankLines="1" />This description need not be
to the same level of detail as for the encoding above, however it
has to be sufficient to demonstrate that encoding and decoding of
the code is both possible and practical.</t>
</list></t>
<t>FEC scheme specifications MAY additionally define the following:
<list style="numbers">
<t>Type, semantics and encoding format of an Explicit Source FEC
Payload ID.</t>
</list></t>
<t>Whenever an FEC scheme specification defines an 'encoding format'
for 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
format MUST either be fixed or it MUST be possible to derive the
length from examining the encoded bytes themselves. For example, the
initial bytes can include some kind of length indication.</t>
<t>FEC scheme specifications SHOULD use the terminology defined in
this document and SHOULD follow the following format: <list
style="hanging">
<t hangText="1. Introduction"><Describe the use-cases addressed
by this FEC scheme><vspace blankLines="1" /></t>
<t hangText="2. Formats and Codes"><list style="hanging">
<t hangText="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 Payload ID information is derived from
source packets><vspace blankLines="1" /></t>
<t hangText="2.2 Repair FEC Payload ID"><Define the type
and format of the Repair FEC Payload ID></t>
<t
hangText="2.3 FEC Framework Configuration Information"><Define
the names, types and text value encoding formats of the
FEC-Scheme-Specific Information elements></t>
</list></t>
<t hangText="3. Procedures"><Describe any procedures which are
specific to this FEC scheme, in particular derivation and
interpretation of the fields in the FEC Payload IDs and
FEC-Scheme-Specific Information></t>
<t hangText="4. FEC Code Specification"><Provide a complete
specification of the FEC Code></t>
</list></t>
<t>Specifications can include additional sections including
examples.</t>
<t>Each FEC scheme MUST be specified independently of all other FEC
schemes; for example, in a separate specification or a completely
independent section of larger specification (except, of course, a
specification of one FEC scheme can include portions of another by
reference). Where an RTP Payload Format is defined for repair data for
a specific FEC scheme, the RTP Payload Format and the FEC scheme can
be specified within the same document.</t>
</section>
</section>
<section title="Feedback">
<t>Many applications require some kind of feedback on transport
performance. E.g., how much data arrived at the receiver, at what rate
and when? When FEC is added to such applications, feedback mechanisms
can also need to be enhanced to report on the performance of the FEC.
E.g., how much lost data was recovered by the FEC?</t>
<t>When used to provide instrumentation for engineering purposes, it is
important to remember that FEC is generally applied to relatively small
blocks of data (in the sense that each block is transmitted over a
relatively small period of time). Thus, feedback information that is
averaged over longer periods of time will likely not provide sufficient
information for engineering purposes. More detailed feedback over
shorter time scales might be preferred. For example, for applications
using RTP transport, see <xref target="RFC5725"></xref>.</t>
<t>Applications which used feedback for congestion control purposes MUST
calculate such feedback on the basis of packets received before FEC
recovery is applied. If this requirement conflicts with other uses of
the feedback information then the application MUST be enhanced to
support both information calculated pre- and post- FEC recovery. This is
to ensure that congestion control mechanisms operate correctly based on
congestion indications received from the network, rather than on
post-FEC recovery information which would give an inaccurate picture of
congestion conditions.</t>
<t>New applications which require such feedback SHOULD use RTP/RTCP
<xref target="RFC3550"></xref>.</t>
</section>
<section anchor="TransportProtocols" title="Transport Protocols">
<t>This framework is intended to be used to define CDPs that operate
over transport protocols providing an unreliable datagram service,
including in particular the User Datagram Protocol (UDP) and the
Datagram Congestion Control Protocol (DCCP).</t>
</section>
<section anchor="sec_congestion" title="Congestion Control">
<t>This section starts with some informative background on the
motivation of the normative requirements for congestion control, which
are spelled out in <xref target="normativecongestion"></xref>.</t>
<section title="Motivation">
<t><list style="symbols">
<t>The enforcement of congestion control principles has gained a
lot of momentum in the IETF over the recent years. While the need
for congestion control 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.</t>
<t>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
or multimedia transmission over heterogeneous networks. In other
cases, application reliability requirements can be so high that
the required end-to-end reliability will be difficult to achieve.
Furthermore, the end-to-end network reliability is not necessarily
known in advance.</t>
<t>This FEC Framework is not defined, nor intended, as a QoS
enhancement tool to combat losses resulting from highly congested
networks. It should not be used for such purposes.</t>
<t>In order to prevent such mis-use, one approach is to leave
standardization to bodies most concerned with the problem
described above. However, the IETF defines base standards used by
several bodies, including DVB, 3GPP, 3GPP2, all of which appear to
share the environment and the problem described.</t>
<t>Another approach is to write a clear applicability statement.
For example, one could restrict the use of this framework to
networks with certain loss characteristics (e.g., wireless links).
However, there can be applications where the use of FEC is
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
load - thereby intentionally violating congestion control
principles. One possible example for such an application could be
a no-matter-what, brute-force FEC protection of a traffic
generated as an emergency signal.</t>
<t>A third approach is to require at a minimum that the use of
this framework with any given application, in any given
environment, does not cause congestion issues which the
application alone would not itself cause, i.e., the use of this
framework must not make things worse.</t>
<t>Taking above considerations into account, <xref
target="normativecongestion"> </xref> specifies a small set of
constraints for the FEC, which are mandatory for all senders
compliant with this FEC Framework. Further restrictions can be
imposed by certain CDPs.</t>
</list></t>
</section>
<section anchor="normativecongestion" title="Normative Requirements">
<t><list style="symbols">
<t>The bandwidth of FEC repair data MUST NOT exceed the bandwidth
of the original source data being protected (without the possible
addition of an Explicit Source FEC Payload ID). This disallows the
(static or dynamic) use of excessively strong FEC to combat 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
military devices, which could warrant a higher FEC strength.
However, in this specification we give preference to the overall
stability and network friendliness of average applications.</t>
<t>Whenever the source data rate is adapted due to the operation
of congestion control mechanisms, the FEC repair data rate MUST be
similarly adapted.</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>First of all, it must be clear that the application of FEC protection
to a stream does not provide any kind of security. On the opposite, the
FEC Framework itself could be subject to attacks, or could pose new
security risks. The goals of this section are to state the problem,
discuss the risks and identify solutions when feasible. It also defines
a mandatory to implement (but not mandatory to use) security scheme.</t>
<section title="Problem Statement">
<t>A content delivery system is potentially subject to many attacks.
Attacks can target the content, or the CDP, or the network itself,
with completely different consequences, in particular in terms of the
number of impacted nodes.</t>
<t>Attacks can have several goals: <list style="symbols">
<t>They can try to give access to a confidential content (e.g., in
case of a non-free content).</t>
<t>They can try to corrupt the source flows (e.g., to prevent a
receiver from using them), which is a form of DoS attack.</t>
<t>They can try to compromise the receiver's behavior (e.g., by
making the decoding of an object computationally expensive), which
is another form of DoS attack.</t>
<t>They can try to compromise the network's behavior (e.g., by
causing congestion within the network), which potentially impacts
a large number of nodes.</t>
</list>These attacks can be launched either against the source
and/or repair flows (e.g., by sending fake FEC source and/or repair
packets) or against the FEC parameters that are sent either in-band
(e.g., in the Repair FEC Payload ID or in the Explicit Source FEC
Payload ID) or out-of-band (e.g., in the FEC Framework Configuration
Information).</t>
<t>Several dimensions to the problem need to be considered. The first
one is the way the FEC Framework is used. The FEC Framework can be
used end-to-end, i.e., it can be included in the final end-device
where the upper application runs; or the FEC Framework can be used in
middleboxes, for instance, to globally protect several source flows
exchanged between two or more distant sites.</t>
<t>A second dimension is the threat model. When the FEC Framework
operates in the end-device, this device (e.g., a personal computer)
might be subject to attacks. Here, the attacker is either the end-user
(who might want to access confidential content) or somebody else. In
all cases the attacker has access to the end-device, but not
necessarily to the full control of the end-device (a secure domain can
exist). Similarly, when the FEC Framework operates in a middlebox,
this middlebox can be subject to attacks or the attacker can gain
access to it. The threats can also concern the end-to-end transport
(e.g., through Internet). Here, examples of threats include the
transmission of fake FEC source or repair packets, the replay of valid
packets, the drop, delay or misordering of packets, and of course
traffic eavesdropping.</t>
<t>The third dimension consists in the desired security services.
Among them, the content integrity and sender authentication services
are probably the most important features. We can also mention DoS
mitigation, anti-replay protection or content confidentiality.</t>
<t>Finally, the fourth dimension consists in the security tools
available. This is the case of the various Digital Rights Management
(DRM) systems, defined out of the context of the IETF and that can be
proprietary solutions. Otherwise SRTP and IPsec/ESP are two tools that
can turn out to be useful in the context of the FEC Framework. Note
that using SRTP requires that the application generates RTP source
flows and, when applied below the FEC Framework, that both the FEC
source and repair packets to be regular RTP packets. Therefore SRTP is
not considered as a universal solution applicable in all use
cases.</t>
<t>In the following sections, we further discuss security aspects
related to the use of the FEC Framework.</t>
</section>
<section title="Attacks Against the Data Flows">
<t></t>
<section title="Access to Confidential Content">
<t>Access control to the source flow being transmitted is typically
provided by means of encryption. This encryption can be done by the
content provider itself, or within the application (for instance by
using the Secure Real-time Transport Protocol (SRTP) <xref
target="RFC3711"></xref>), or at the network layer, on a per-packet
basis when IPsec/ESP is used <xref target="RFC4303"></xref>. If
confidentiality is a concern, it is RECOMMENDED that one of these
solutions is used. Even if we mention these attacks here, they are
neither related to nor facilitated by the use of FEC.</t>
<t>Note that when encryption is applied, this encryption MUST either
be applied on the source data before the FEC protection, or if done
after the FEC protection, then both the FEC source packets and
repair packets MUST be encrypted (and an encryption at least as
cryptographically secure as the encryption applied on the FEC source
packets MUST be used for the FEC repair packets). Otherwise, if
encryption were to be performed only on the FEC source packets after
FEC encoding, a non-authorized receiver could be able to recover the
source data after decoding the FEC repair packets provided that a
sufficient number of such packets were available.</t>
<t>The following considerations apply when choosing where to apply
encryption (and more generally where to apply security services
beyond encryption). Once decryption has taken place, the source data
is in plaintext. The full path between the output of the deciphering
module and the final destination (e.g., the TV display in case of a
video) MUST be secured, in order to prevent any unauthorized access
to the source data.</t>
<t>When the FEC Framework endpoint is the end system (i.e., where
the upper application runs) and if the threat model includes the
possibility that an attacker has access to this end system, then the
end system architecture is very important. More precisely, in order
to prevent an attacker to get hold of the plaintext, all
processings, once deciphering has taken place, MUST occur in a
protected environment. If encryption is applied after FEC protection
at the sending side (i.e., below FEC Framework), it means that FEC
decoding MUST take place in the protected environment. With certain
use cases, this MAY be complicated or even impossible. In that case
applying encryption before FEC protection is preferred.</t>
<t>When the FEC Framework endpoint is a middlebox, the recovered
source flow, after FEC decoding, SHOULD NOT be sent in plaintext to
the final destination(s) if the threat model includes the
possibility that an attacker eavesdrops the traffic. In that case
also it is preferred to apply encryption before FEC protection.</t>
<t>In some cases, encryption could be applied both before and after
the FEC protection. The considerations described above still apply
in such cases.</t>
</section>
<section anchor="sec_content_corruption" title="Content Corruption">
<t>Protection against corruptions (e.g., against forged FEC
source/repair packets) is achieved by means of a content integrity
verification/source authentication scheme. This service is usually
provided at the packet level. In this case, after removing all the
forged packets, the source flow might sometimes be recovered.
Several techniques can provide this content integrity/source
authentication service: <list style="symbols">
<t>At the application layer, SRTP <xref target="RFC3711"></xref>
provides several solutions to check the integrity and
authenticate the source of RTP and RTCP messages, among other
services. For instance, associated to the Timed Efficient Stream
Loss-Tolerant Authentication (TESLA) <xref
target="RFC4383"></xref>, SRTP is an attractive solution that is
robust to losses, provides a true authentication/integrity
service, and does not create any prohibitive processing load or
transmission overhead. Yet, checking a packet requires a small
delay (a second or more) after its reception with TESLA. Whether
this extra delay, both in terms of startup delay at the client
and end-to-end delay, is appropriate or not depends on the
target use case. In some situations, this might degrade the user
experience. In other situations, this will not be an issue.
Other building blocks can be used within SRTP to provide content
integrity/authentication services.</t>
<t>At the network layer, IPsec/ESP <xref
target="RFC4303"></xref> offers (among other services) an
integrity verification mechanism that can be used to provide
authentication/content integrity services.</t>
</list></t>
<t>It is up to the developer and the person in charge of deployment,
who know the security requirements and features of the target
application area, to define which solution is the most appropriate.
Nonetheless it is RECOMMENDED that at least one of these techniques
is used.</t>
<t>Note that when integrity protection is applied, it is RECOMMENDED
that it takes place on both FEC source and repair packets. The
motivation is to avoid corrupted packets to be considered during
decoding, which would often lead to a decoding failure or result in
a corrupted decoded source flow.</t>
</section>
</section>
<section title="Attacks Against the FEC Parameters">
<t>Attacks on these FEC parameters can prevent the decoding of the
associated object. For instance, modifying the finite field size of a
Reed-Solomon FEC scheme (when applicable) will lead a receiver to
consider a different FEC code.</t>
<t>It is therefore RECOMMENDED that security measures are taken to
guarantee the FEC Framework Configuration Information integrity. Since
the FEC Framework does not define how the FEC Framework Configuration
Information is communicated from sender to receiver, we cannot provide
further recommendations on how to guarantee its integrity. However,
any complete CDP specification MUST give recommendations on how to
achieve it. When the FEC Framework Configuration Information is sent
out-of-band, e.g., in a session description, it SHOULD be protected,
for instance, by digitally signing it.</t>
<t>Attacks are also possible against some FEC parameters included in
the Explicit Source FEC Payload ID and Repair FEC Payload ID. For
instance, modifying the Source Block Number of an FEC source or repair
packet will lead a receiver to assign this packet to a wrong
block.</t>
<t>It is therefore RECOMMENDED that security measures are taken to
guarantee the Explicit Source FEC Payload ID and Repair FEC Payload ID
integrity. To that purpose, one of the packet-level source
authentication/content integrity techniques of <xref
target="sec_content_corruption"></xref> can be used.</t>
</section>
<section anchor="sec_pro_tog"
title="When Several Source Flows are to be Protected Together">
<t>When several source flows, with different security requirements,
need to be FEC protected jointly, within a single FEC Framework
instance, then each flow MAY be processed appropriately, before the
protection. For instance, source Flows that require access control MAY
be encrypted before they are FEC protected.</t>
<t>There are also situations where the only insecure domain is the one
over which the FEC Framework operates. In that case, this situation
MAY be addressed at the network layer, using IPsec/ESP (see <xref
target="sec_mandatory_solution"></xref>), even if only a subset of the
source flows have strict security requirements.</t>
<t>Since the use of FEC Framework should not add any additional
threat, it is RECOMMENDED that the FEC Framework aggregate flow be in
line with the maximum security requirements of the individual source
flows. For instance, if denial-of-service (DoS) protection is
required, an integrity protection SHOULD be provided below the FEC
Framework, using for instance IPsec/ESP.</t>
<t>Generally speaking, whenever feasible, it is RECOMMENDED to avoid
FEC protecting flows with totally different security requirements.
Otherwise, an important processing would be added to protect the
source flows that do not need it.</t>
</section>
<section anchor="sec_mandatory_solution"
title="Baseline Secure FEC Framework Operation">
<t>This section describes a baseline mode of secure FEC Framework
operation based on the application of the IPsec security protocol,
which is one possible solution to solve or mitigate the security
threats introduced by the use of the FEC Framework.</t>
<t>Two related documents are of interest. First, Section 5.1 of <xref
target="RFC5775"></xref> defines a baseline secure ALC operation for
sender-to-group transmissions, assuming the presence of a single
sender and a source-specific multicast (SSM) or SSM-like operation.
The proposed solution, based on IPsec/ESP, can be used to provide a
baseline FEC Framework secure operation, for the downstream source
flow.</t>
<t>Second, Section 7.1 of <xref target="RFC5740"></xref> defines a
baseline secure NORM operation, for sender-to-group transmissions as
well as unicast feedbacks from receivers. Here, it is also assumed
there is a single sender. The proposed solution is also based on
IPsec/ESP. However, the difference with respect to the first document
relies on the management of IPsec Security Associations (SA) and
corresponding Security Policy Database (SPD) entries, since NORM
requires a second set of SA and SPD to be defined to protect unicast
feedbacks from receivers.</t>
<t>The FEC Framework has been defined in such a way to be independent
from the application that generates source flows. Some applications
might use purely unidirectional flows, while other applications might
also use unicast feedbacks from the receivers. For instance, this is
the case when considering RTP/RTCP based source flows. Depending on
the specific situation, it is RECOMMENDED that the baseline secure FEC
Framework operation inherits from <xref target="RFC5775"></xref> in
case of purely unidirectional sender-to-group flows, or <xref
target="RFC5740"></xref> in case both sender-to-group and unicast
feedbacks flows are needed.</t>
<t>Note that the IPsec/ESP requirements profiles outlined in <xref
target="RFC5775"></xref> and <xref target="RFC5740"></xref> are
commonly available on many potential hosts. They can form the basis of
a secure mode of operation. One potential limitation, however, is the
need for privileged user authorization. However, automated key
management implementations are typically configured with the
privileges necessary to affect system IPsec configuration.</t>
</section>
</section>
<section title="Operations and Management Considerations">
<t>The question of operating and managing the FEC Framework and the
associated FEC scheme(s) is of high practical importance. The goals of
this section are to discuss the general requirements, aspects related to
a specific deployment and solutions whenever possible.</t>
<t>In particular, this section discusses the questions of
interoperability across vendors/use cases and whether defining mandatory
to implement (but not mandatory to use) solutions is beneficial.</t>
<section anchor="sec_ops1" title="What are the Key Aspects to Consider?">
<t>Several aspects need to be considered since they will directly
impact the way the FEC Framework and the associated FEC schemes can be
operated and managed.</t>
<t>This section lists them as follows:</t>
<t><list style="symbols">
<t>A Single Small Generic Component within a Larger (and Often
Legacy) Solution: The FEC Framework is one component within a
larger solution which includes both one or several upper-layer
applications (that generate one or several ADU flows) and an
underlying protocol stack. A key design principle is that the FEC
Framework should be able to work without making any assumption
with respect to either the upper-layer application(s) or the
underlying protocol stack, even if there are special cases where
assumptions are made.</t>
<t>One-to-One with Feedback vs. One-to-Many with Feedback vs.
One-to-Many without Feedback Scenarios: The FEC Framework can be
used in use cases that completely differ from one another. Some
use cases are one-way (e.g., in broadcast networks), with either a
one-to-one, one-to-many or many-to-many transmission model, and
the receiver(s) cannot send any feedback to the sender(s). Other
use cases follow a bidirectional one-to-one, one-to-many, or
many-to-many scenario, and the receiver(s) can send feedback to
the sender(s).</t>
<t>Non-FEC Framework Capable Receivers: With the one-to-many and
many-to-many use cases, the receiver population might have
different capabilities with respect to the FEC Framework itself
and the supported FEC schemes. Some receivers might not be capable
of decoding the repair packets belonging to a particular FEC
scheme, while some other receivers might not be supporting the FEC
Framework at all.</t>
<t>Internet vs. non-Internet Networks: The FEC Framework can be
useful in many use cases that use a transport network that is not
the public Internet (e.g., with IPTV or Mobile TV). In such
networks, the operational and management considerations can be
achieved through an open or proprietary solution, which is
specified outside of the IETF.</t>
<t>Congestion Control Considerations: See <xref
target="sec_congestion"></xref> for a discussion on whether
congestion control is needed or not, and its relationships with
the FEC Framework.</t>
<t>Within End-Systems vs. within Middleboxes: The FEC Framework
can be used within end-systems, very close to the upper-layer
application, or within dedicated middleboxes, for instance when it
is desired to protect one or several flows while they cross a
lossy channel between two or more remote sites.</t>
<t>Protecting a Single Flow vs. Several Flows Globally: The FEC
Framework can be used to protect a single flow, or several flows
globally.</t>
</list></t>
</section>
<section title="Operational and Management Recommendations">
<t>Overall, from the discussion of <xref target="sec_ops1"></xref>, it
is clear that the CDPs and FEC schemes compatible with the FEC
Framework widely differ in their capabilities, application and
deployment scenarios such that a common operation and management
method or protocol that works well for all of them would be too
complex to define. Thus, as a design choice, the FEC Framework does
not dictate the use of any particular technology or protocol for
transporting FEC data, managing the hosts, signaling the configuration
information or encoding the configuration information. This provides
flexibility and is one of the main goals of the FEC Framework.
However, this section gives some RECOMMENDED guidelines.</t>
<t><list style="symbols">
<t>A Single Small Generic Component within a Larger (and Often
Legacy) Solution: It is anticipated that the FEC Framework will
often be used to protect one or several RTP streams. Therefore,
implementations SHOULD make feedback information accessible via
RTCP to enable users to take advantage of the tools using (or used
by) RTCP to operate and manage the FEC Framework instance along
with the associated FEC schemes.</t>
<t>One-to-One with Feedback vs. One-to-Many with Feedback vs.
One-to-Many without Feedback Scenarios: With use cases that are
one-way, the FEC Framework sender does not have any way to gather
feedback from receivers. With use cases that are bidirectional,
the FEC Framework sender can collect detailed feedback (e.g., in
case of a one-to-one scenario) or at least occasional feedback
(e.g., in case of a multicast, one-to-many scenario). All these
applications have naturally different operational and management
aspects. If any, they also have different requirements or features
for collecting feedback, processing it and acting on it. The data
structures for carrying the feedback also vary.<vspace
blankLines="1" />Implementers SHOULD make feedback available using
either an in-band or out-of-band asynchronous reporting mechanism.
When an out-of-band solution is preferred, a standardized
reporting mechanism, such as Syslog <xref target="RFC5424"></xref>
or SNMP notifications <xref target="RFC3411"></xref>, is
RECOMMENDED. When required, a mapping mechanism between the Syslog
and SNMP reporting mechanisms could be used, as described in <xref
target="RFC5675"></xref> and <xref target="RFC5676"></xref>. </t>
<t>Non-FEC Framework Capable Receivers: <xref
target="sourcepackets"></xref> gives recommendations on how to
provide backward compatibility in presence of receivers that
cannot support the FEC scheme being used, or the FEC Framework
itself: basically the use of Explicit Source FEC Payload ID is
banned. Additionally, a non-FEC Framework capable receiver MUST
also have a means not to receive the repair packets that it will
not be able to decode in the first place or a means to identify
and discard them appropriately upon receiving them. This SHOULD be
achieved by sending repair packets on a different transport-layer
flow. In case of RTP transport and if both source and repair
packets will be sent on the same transport-layer flow, this SHOULD
be achieved by using an RTP framing for FEC repair packets with a
different payload type. It is the responsibility of the sender to
select the appropriate mechanism when needed.</t>
<t>Within End-Systems vs. within Middleboxes: When the FEC
Framework is used within middleboxes, it is RECOMMENDED that the
paths between the hosts where the sending applications run and the
middlebox that performs FEC encoding be as reliable as possible,
i.e., are not prone to packet loss, packet reordering, or varying
delays in delivering packets. <vspace blankLines="1" />Similarly,
it is RECOMMENDED that the paths between the middleboxes that
perform FEC decoding and the end-systems where the receiving
applications operate, in situations where this is a different
host, be as reliable as possible. <vspace blankLines="1" /></t>
<t>Management of Communication Issues Before Reaching the Sending
FECFRAME Instance:
Let us consider situations where the FEC Framework is used within
middleboxes.
At the sending side, the general reliability recommendation for
the path between the sending applications and the middlebox is
important but it may not guarantee that a loss, reordering or
important delivery delay cannot happen, for whatever reason. If
such a rare event happens, this event SHOULD NOT compromise the
operation of the FECFRAME instances, neither at the sending side nor
receiving side. This is particularly important with FEC schemes
that do not modify the ADU for backward compatibility purposes
(i.e., do not use any Explicit Source FEC Payload ID) and rely for
instance on the RTP sequence number field to identify FEC source
packets within their source block. In this case, packet loss or
packet reordering leads to a gap in the RTP sequence number space
seen by the FECFRAME instance. Similarly, varying delay in
delivering packets over this path can lead to significant timing
issues. With FEC schemes that indicate in the Repair FEC Payload
ID, for each source block, the base RTP sequence number and number
of consecutive RTP packets that belong to this source block, a
missing ADU or an ADU delivered out of order could cause the
FECFRAME sender to switch to a new source block. However, some FEC
schemes and/or receivers may not necessarily handle such varying
source block sizes. In this case, one could consider duplicating
the last ADU received before the loss, or inserting zero'ed
ADU(s), depending on the ADU flow nature. Implementers SHOULD
consider the consequences of such alternative approaches based on
their use cases.</t>
<t>Protecting a Single Flow vs. Several Flows Globally: In the
general case, the various ADU flows that are globally protected
can have different features, and in particular different real-time
requirements (in case of real-time flows). The process of globally
protecting these flows SHOULD take into account the requirements
of each individual flow. In particular, it would be
counter-productive to add repair traffic to a real-time flow for
which the FEC decoding delay at a receiver makes decoded ADUs for
this flow useless because they do not satisfy the associated
real-time constraints. From a practical point of view, this means
that the source block creation process at the sending FEC
Framework instance, SHOULD consider the most stringent real-time
requirements of the ADU flows being globally protected.</t>
<t>ADU Flow Bundle Definition and Flow Delivery: By design a
repair flow might enable a receiver to recover the ADU flow(s)
that it protects even if none of the associated FEC source packets
are received. Therefore, when defining the bundle of ADU flows
that are globally protected and when defining which receiver
receives which flow, the sender SHOULD make sure that the ADU
flow(s) and repair flow(s) of that bundle will only be received by
receivers that are authorized to receive all the ADU flows of that
bundle. See <xref target="sec_pro_tog"></xref> for additional
recommendations for situations where a strict access control to
ADU flows is needed. <vspace blankLines="1" />Additionally when
multiple ADU flows are globally protected, a receiver who wants to
benefit from FECFRAME loss protection SHOULD receive all the ADU
flows of the bundle. Otherwise, the missing FEC source packets
would be considered as lost which might significantly reduce the
efficiency of the FEC scheme.</t>
</list></t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>FEC schemes for use with this framework are identified in protocols
using FEC Encoding IDs. Values of FEC Encoding IDs are subject to IANA
registration. For this purposes, this document creates a new registry
called FEC Framework (FECFRAME) FEC Encoding IDs.</t>
<t>The values that can be assigned within the FEC Framework (FECFRAME)
FEC Encoding ID registry are numeric indexes in the range (0, 255).
Values of 0 and 255 are reserved. Assignment requests are granted on an
IETF Consensus basis as defined in <xref target="RFC5226"></xref>. <xref
target="fecscheme"></xref> defines explicit requirements that documents
defining new FEC Encoding IDs should meet.</t>
</section>
<section title="Acknowledgments">
<t>This document is based in part on <xref
target="I-D.watson-tsvwg-fec-sf"></xref> and so thanks are due to the
additional authors of that document, Mike Luby, Magnus Westerlund and
Stephan Wenger. That document was in turn based on the FEC Streaming
Protocol defined by 3GPP in <xref target="MBMSTS"></xref>, and thus,
thanks are also due to the participants in 3GPP SA Working Group 4.
Further thanks are due to the members of the FECFRAME Working Group for
their comments and reviews.</t>
</section>
</middle>
<back>
<references title="Normative references">
&rfc2119;
&rfc3095;
&rfc5052;
&rfc3550;
&rfc5226;
&rfc5234;
&rfc5424;
&rfc3411;
</references>
<references title="Informative references">
&fecsf;
&rfc5725;
&rfc4566;
&rfc4588;
&fecsdp;
&rfc3711;
&rfc5740;
&rfc5675;
&rfc5676;
&rfc4303;
&rfc4383;
&rfc5775;
<reference anchor="MBMSTS">
<front>
<title>Multimedia Broadcast/Multicast Service (MBMS); Protocols and
codecs</title>
<author>
<organization>3GPP</organization>
</author>
<date day="01" month="April" year="2005" />
</front>
<seriesInfo name="3GPP TS" value="26.346" />
<format target="http://www.3gpp.org/ftp/Specs/html-info/26346.htm"
type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 13:18:14 |