| FEC Framework | M. Watson |
| Internet-Draft | Netflix, Inc. |
| Intended status: Standards Track | A. Begen |
| Expires: December 11, 2011 | Cisco |
| V. Roca | |
| INRIA | |
| June 09, 2011 |
Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-15
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 11, 2011.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
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.
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 [RFC5052] 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.
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.
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 [RFC5052], 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.
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.
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 [RFC5052] 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.
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 [RFC5725] may be used to obtain information about the loss rate after FEC recovery.
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).
Application Data Unit (ADU): The unit of source data provided as payload to the transport layer.
ADU Flow: A sequence of ADUs associated with a transport-layer flow identifier (such as the standard 5-tuple {Source IP address, source port, destination IP address, destination port, transport protocol}).
AL-FEC: Application-layer Forward Error Correction.
Application Protocol: Control protocol used to establish and control the source 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 FEC capabilities.
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.
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 aspects required to use a particular FEC code with the FEC Framework.
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.
Protection Amount: The relative increase in data sent due to the use of FEC.
Repair Flow: The packet flow carrying FEC data.
Repair FEC Payload ID: An FEC Payload ID specifically for use with repair packets.
Source Flow: The packet flow to which FEC protection is to be applied. A source flow consists of ADUs.
Source FEC Payload ID: An FEC Payload ID specifically for use with source packets.
Source Protocol: A protocol used for the source flow being protected, e.g., RTP.
Transport Protocol: The protocol used for transport of the source and repair flows, e.g., UDP and DCCP.
The following definitions are aligned with [RFC5052]:
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. With systematic codes, source symbols are part of the encoding symbols.
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.
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 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 [RFC2119].
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 [RFC4588].
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.
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. 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.
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 [RFC5052].
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.
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.
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.
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.
The architecture outlined above is illustrated in the Figure 1. 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).
+--------------------------------------------+
| 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 |
+ - - - - - - - - - - - - - - - - - - - - - - - +
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.
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.
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 Section 7). 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.
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:
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.
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 Section 4.2.
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.
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).
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 Section 4.3.
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.
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.
The FEC scheme MAY use different FEC Payload ID field formats for source and repair packets.
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 Figure 2, for the case of UDP repair flows and Figure 3 for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows:
+----------------------+
| 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) |
+----------------------+
+----------------------+
| 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) |
+----------------------+
The following describes a possible receiver algorithm, illustrated in Figure 4 and Figure 5 for the case of RTP repair flows, when receiving an FEC source or repair packet:
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.
+----------------------+
| 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) |
+----------------------+
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ ^ Repair FEC Payload IDs
| | Source payloads
| | Repair payloads
| |
|Source |Repair payloads
|packets |
| |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux | |
+-- -- -- -- -- -- -- -+
^
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Note that the above procedure might result in a situation in which not all ADUs are recovered.
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:
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.
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:
The packet format for FEC source packets MUST be used to transport the payload of an original source packet. As depicted in Figure 6, 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.
+------------------------------------+ | IP Header | +------------------------------------+ | Transport Header | +------------------------------------+ | Application Data Unit | +------------------------------------+ | Explicit Source FEC Payload ID | +------------------------------------+
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.
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.
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.
The Explicit Source FEC Payload ID is placed at the end of the packet so that in the case that Robust Header Compression (ROHC) [RFC3095] 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.
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.
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.
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.
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.
+------------------------------------+ | IP Header | +------------------------------------+ | Transport Header | +------------------------------------+ | Repair FEC Payload ID | +------------------------------------+ | Repair Symbols | +------------------------------------+
The packet format for FEC repair packets is shown in Figure 7. The transport payload consists of a Repair FEC Payload ID field followed by repair data generated in the FEC encoding process.
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.
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 Figure 8.
+------------------------------------+ | IP header | +------------------------------------+ | Transport Header (UDP) | +------------------------------------+ | RTP Header | +------------------------------------+ | Repair FEC Payload ID | +------------------------------------+ | Repair Symbols | +------------------------------------+
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.
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.
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:
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 Section 5.3. A single source flow can be protected by multiple instances of the FEC Framework.
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).
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.
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 Section 5.4 and MUST relate to the same FEC Framework instance.
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.
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.
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.
For the CDPs that choose the Session Description Protocol (SDP) [RFC4566] as their session description protocol, the ABNF [RFC5234] syntax for the SS-FSSI and FSSI containers is provided in Section 4.5 of [I-D.ietf-fecframe-sdp-elements].
In order to be used with this framework, an FEC scheme MUST be capable of processing data arranged into blocks of ADUs (source blocks).
A specification for a new FEC scheme MUST include the following:
FEC scheme specifications MAY additionally define the following:
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.
FEC scheme specifications SHOULD use the terminology defined in this document and SHOULD follow the following format:
Specifications can include additional sections including examples.
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.
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?
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 [RFC5725].
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.
New applications which require such feedback SHOULD use RTP/RTCP [RFC3550].
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).
This section starts with some informative background on the motivation of the normative requirements for congestion control, which are spelled out in Section 8.2.
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.
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.
Attacks can have several goals:
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).
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.
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.
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.
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.
In the following sections, we further discuss security aspects related to the use of the FEC Framework.
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) [RFC3711]), or at the network layer, on a per-packet basis when IPsec/ESP is used [RFC4303]. 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.
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.
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.
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.
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.
In some cases, encryption could be applied both before and after the FEC protection. The considerations described above still apply in such cases.
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:
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.
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.
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.
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.
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.
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 Section 9.2.2 can be used.
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.
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 Section 9.5), even if only a subset of the source flows have strict security requirements.
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.
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.
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.
Two related documents are of interest. First, Section 5.1 of [RFC5775] 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.
Second, Section 7.1 of [RFC5740] 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.
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 [RFC5775] in case of purely unidirectional sender-to-group flows, or [RFC5740] in case both sender-to-group and unicast feedbacks flows are needed.
Note that the IPsec/ESP requirements profiles outlined in [RFC5775] and [RFC5740] 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.
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.
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.
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.
This section lists them as follows:
Overall, from the discussion of Section 10.1, 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.
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.
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 [RFC5226]. Section 5.6 defines explicit requirements that documents defining new FEC Encoding IDs should meet.
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, Magnus Westerlund and Stephan Wenger. That document was in turn based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], 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.