diff options
Diffstat (limited to 'doc/rfc/rfc6363.txt')
| -rw-r--r-- | doc/rfc/rfc6363.txt | 2355 |
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc6363.txt b/doc/rfc/rfc6363.txt new file mode 100644 index 0000000..5f18fb2 --- /dev/null +++ b/doc/rfc/rfc6363.txt @@ -0,0 +1,2355 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Watson +Request for Comments: 6363 Netflix, Inc. +Category: Standards Track A. Begen +ISSN: 2070-1721 Cisco + V. Roca + INRIA + October 2011 + + + Forward Error Correction (FEC) Framework + +Abstract + + This document describes a framework for using Forward Error + Correction (FEC) codes with applications in public and private IP + networks to provide protection against packet loss. The framework + supports applying 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) that + is compliant with various requirements defined in this document. + Thus, Content Delivery Protocols can be defined that are not specific + to a particular FEC scheme, and FEC schemes can be defined that are + not specific to a particular Content Delivery Protocol. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6363. + + + + + + + + + + + +Watson, et al. Standards Track [Page 1] + +RFC 6363 FEC Framework October 2011 + + +Copyright Notice + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Watson, et al. Standards Track [Page 2] + +RFC 6363 FEC Framework October 2011 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Definitions and Abbreviations ...................................5 + 3. Architecture Overview ...........................................7 + 4. Procedural Overview ............................................11 + 4.1. General ...................................................11 + 4.2. Sender Operation ..........................................13 + 4.3. Receiver Operation ........................................15 + 5. Protocol Specification .........................................19 + 5.1. General ...................................................19 + 5.2. Structure of the Source Block .............................19 + 5.3. Packet Format for FEC Source Packets ......................19 + 5.3.1. Generic Explicit Source FEC Payload ID .............21 + 5.4. Packet Format for FEC Repair Packets ......................21 + 5.4.1. Packet Format for FEC Repair Packets over RTP ......22 + 5.5. FEC Framework Configuration Information ...................22 + 5.6. FEC Scheme Requirements ...................................24 + 6. Feedback .......................................................26 + 7. Transport Protocols ............................................27 + 8. Congestion Control .............................................27 + 8.1. Motivation ................................................27 + 8.2. Normative Requirements ....................................29 + 9. Security Considerations ........................................29 + 9.1. Problem Statement .........................................29 + 9.2. Attacks against the Data Flows ............................31 + 9.2.1. Access to Confidential Content .....................31 + 9.2.2. Content Corruption .................................32 + 9.3. Attacks against the FEC Parameters ........................33 + 9.4. When Several Source Flows Are to Be Protected Together ....33 + 9.5. Baseline Secure FEC Framework Operation ...................34 + 10. Operations and Management Considerations ......................35 + 10.1. What Are the Key Aspects to Consider? ....................35 + 10.2. Operational and Management Recommendations ...............36 + 11. IANA Considerations ...........................................39 + 12. Acknowledgments ...............................................39 + 13. References ....................................................40 + 13.1. Normative References .....................................40 + 13.2. Informative References ...................................40 + +1. Introduction + + 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 that do not provide guaranteed packet + delivery. Primary examples are real-time, or streaming, media + applications such as broadcast, multicast, or on-demand forms of + audio, video, or multimedia. + + + +Watson, et al. Standards Track [Page 3] + +RFC 6363 FEC Framework October 2011 + + + Forward Error Correction (FEC) is a well-known technique for + improving the reliability of packet transmission over networks that + do not provide guaranteed packet delivery, especially in multicast + and broadcast applications. The FEC Building Block, defined in + [RFC5052], provides a framework for the definition of Content + Delivery Protocols (CDPs) for object delivery (including, primarily, + file delivery) that 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 that 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 that + 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; rather, it 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 does it define how the details of the protected flows + and the FEC streams that protect them are communicated from sender to + receiver. It is expected that any complete CDP specification that + makes use of this framework will address these signaling + requirements. However, this document does specify the information + that 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. + + + + + + + + +Watson, et al. Standards Track [Page 4] + +RFC 6363 FEC Framework October 2011 + + + Since RTP [RFC3550] 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 the 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). + +2. Definitions and Abbreviations + + 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., the Real-Time Streaming + Protocol (RTSP). + + Content Delivery Protocol (CDP): A complete application protocol + specification that, 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 the definition of Content + Delivery Protocols using FEC, such as the framework defined in + this document. + + FEC Framework Configuration Information: Information that controls + the operation of the FEC Framework. + + FEC Payload ID: Information that identifies the contents of a packet + with respect to the FEC scheme. + + + + +Watson, et al. Standards Track [Page 5] + +RFC 6363 FEC Framework October 2011 + + + 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 that 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: A 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: A 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 the transport of the source + and repair flows, e.g., UDP and the Datagram Congestion Control + Protocol (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. + + + + + +Watson, et al. Standards Track [Page 6] + +RFC 6363 FEC Framework October 2011 + + + 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 that 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]. + +3. Architecture Overview + + 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 a 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 it defines + the protocol fields and procedures used to identify packet payload + data in the context of the FEC scheme. The interface between the FEC + + + +Watson, et al. Standards Track [Page 7] + +RFC 6363 FEC Framework October 2011 + + + Framework and a FEC scheme, which is described in this document, is a + logical one that 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 + that MUST be available to both sender and receiver(s). For example, + this information includes the specification of the ADU flows that are + to be FEC protected, specification of the ADU flow(s) that 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 repair flow(s)). The FEC Framework Configuration + Information also includes information fields that 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 that 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 that + 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, a FEC scheme has to define an RTP + payload format for the repair data. + + + + + + +Watson, et al. Standards Track [Page 8] + +RFC 6363 FEC Framework October 2011 + + + The architecture outlined above is illustrated in 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 that protect the source RTP headers (as + well as repair data for the source RTP payloads). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Watson, et al. Standards Track [Page 9] + +RFC 6363 FEC Framework October 2011 + + + +--------------------------------------------+ + | 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 | + + - - - - - - - - - - - - - - - - - - - - - - - + + + Figure 1: FEC Framework Architecture + + + + + + + + +Watson, et al. Standards Track [Page 10] + +RFC 6363 FEC Framework October 2011 + + + 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. + +4. Procedural Overview + +4.1. General + + The mechanism defined in this document does not place any + restrictions on the ADUs that can be protected together, except that + the ADU be 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 that 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: + + o Optionally, FEC Payload IDs for each of the source payloads + (encoded according to a FEC-Scheme-Specific format). + + o One or more FEC repair packet payloads. + + o FEC Payload IDs for each of the repair packet payloads (encoded + according to a FEC-Scheme-Specific format). + + + + + + + + + +Watson, et al. Standards Track [Page 11] + +RFC 6363 FEC Framework October 2011 + + + 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. 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 they 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 that 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 + + + +Watson, et al. Standards Track [Page 12] + +RFC 6363 FEC Framework October 2011 + + + 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 that 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. + +4.2. Sender Operation + + 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 in Figure 3 for the case of RTP repair flows, + describe a possible way to generate compliant source and repair + flows: + + 1. ADUs are provided by the application. + + 2. A source block is constructed as specified in Section 5.2. + + 3. The source block is passed to the FEC scheme for FEC encoding. + 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. + + 4. 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. + + 5. 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. + + 6. The FEC Framework constructs FEC source packets according to + Section 5.3, and FEC repair packets according to Section 5.4, + using the FEC Payload IDs and repair packet payloads provided by + the FEC scheme. + + + + + +Watson, et al. Standards Track [Page 13] + +RFC 6363 FEC Framework October 2011 + + + 7. 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). + + +----------------------+ + | 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) | + +----------------------+ + + Figure 2: Sender Operation + + + + + + + + + + + + + +Watson, et al. Standards Track [Page 14] + +RFC 6363 FEC Framework October 2011 + + + +----------------------+ + | 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) | + +----------------------+ + + Figure 3: Sender Operation with RTP Repair Flows + +4.3. Receiver Operation + + The following describes a possible receiver algorithm, illustrated in + Figures 4 and 5 for the case of UDP and RTP repair flows, + respectively, when receiving a FEC source or repair packet: + + 1. 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) are indicated by the ADU flow information, which + identifies the flow at the transport layer. + + 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 + + + +Watson, et al. Standards Track [Page 15] + +RFC 6363 FEC Framework October 2011 + + + repair flows. However, RTP processing is applied only to the + repair packets at this stage; source packets continue to be + handled as UDP payloads (i.e., including their RTP headers). + + 2. The FEC Framework extracts the Explicit Source FEC Payload ID + field (if present) from the source packets and the Repair FEC + Payload ID from the repair packets. + + 3. The Explicit Source FEC Payload IDs (if present), Repair FEC + Payload IDs, and FEC source and repair payloads are passed to the + FEC scheme. + + 4. 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. + + 5. 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 that were missing and could not be + decoded. + + 6. The FEC Framework passes the received and recovered ADUs to the + application. + + The description above defines functionality responsibilities but does + not imply a specific set of timing relationships. Source packets + that are correctly received and those that 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. + + + + + + + + + + + + +Watson, et al. Standards Track [Page 16] + +RFC 6363 FEC Framework October 2011 + + + +----------------------+ + | Application | + +----------------------+ + ^ + | + |(6) ADUs + | + +----------------------+ +----------------+ + | FEC Framework | | | + | |<--------------------------| FEC Scheme | + |(2)Extract FEC Payload|(5) ADUs | | + | IDs and pass IDs & | |(4) FEC Decoding| + | payloads to FEC |-------------------------->| | + | scheme |(3) Explicit Source FEC | | + +----------------------+ Payload IDs +----------------+ + ^ Repair FEC Payload IDs + | Source payloads + | Repair payloads + | + |(1) FEC source and repair packets + | + +----------------------+ + | Transport Layer | + | (e.g., UDP) | + +----------------------+ + + Figure 4: Receiver Operation + + + + + + + + + + + + + + + + + + + + + + + + +Watson, et al. Standards Track [Page 17] + +RFC 6363 FEC Framework October 2011 + + + +----------------------+ + | 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) | + +----------------------+ + + Figure 5: Receiver Operation with RTP Repair Flows + + Note that the above procedure might result in a situation in which + not all ADUs are recovered. + + + + + + + + + + + +Watson, et al. Standards Track [Page 18] + +RFC 6363 FEC Framework October 2011 + + +5. Protocol Specification + +5.1. General + + 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: + + 1. Construction of a source block from ADUs. The FEC code will be + applied to this source block to produce the repair payloads. + + 2. A format for packets containing source data. + + 3. A format for packets containing repair data. + + 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. + +5.2. Structure of the Source Block + + 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: + + o A description of the source flow with which the ADU is associated. + + o The ADU itself. + + o The length of the ADU. + +5.3. Packet Format for FEC Source Packets + + 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. + + + + + + +Watson, et al. Standards Track [Page 19] + +RFC 6363 FEC Framework October 2011 + + + +------------------------------------+ + | IP Header | + +------------------------------------+ + | Transport Header | + +------------------------------------+ + | Application Data Unit | + +------------------------------------+ + | Explicit Source FEC Payload ID | + +------------------------------------+ + + Figure 6: Structure of the FEC Packet Format for FEC Source Packets + + The FEC source packets MUST be sent using the same ADU flow as would + 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 backward compatibility, since source packets are modified. + + + + +Watson, et al. Standards Track [Page 20] + +RFC 6363 FEC Framework October 2011 + + +5.3.1. Generic Explicit Source FEC Payload ID + + 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 that 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. + +5.4. Packet Format for FEC Repair Packets + + 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. + + +------------------------------------+ + | IP Header | + +------------------------------------+ + | Transport Header | + +------------------------------------+ + | Repair FEC Payload ID | + +------------------------------------+ + | Repair Symbols | + +------------------------------------+ + + Figure 7: Packet Format for FEC Repair Packets + + 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. + + + + + +Watson, et al. Standards Track [Page 21] + +RFC 6363 FEC Framework October 2011 + + +5.4.1. Packet Format for FEC Repair Packets over RTP + + For FEC schemes that 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 | + +------------------------------------+ + + Figure 8: Packet Format for FEC Repair Packets over RTP + +5.5. FEC Framework Configuration Information + + 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: + + + + + + + + + +Watson, et al. Standards Track [Page 22] + +RFC 6363 FEC Framework October 2011 + + + 1. Identification of the repair flows. + + 2. For each source flow protected by the repair flow(s): + + A. Definition of the source flow. + + B. An integer identifier for this flow definition (i.e., tuple). + This identifier MUST be unique among 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. + + 3. The FEC Encoding ID, identifying the FEC scheme. + + 4. The length of the Explicit Source FEC Payload ID (in octets). + + 5. 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. + + 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 either would 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 a FEC decoding + operation. + + + +Watson, et al. Standards Track [Page 23] + +RFC 6363 FEC Framework October 2011 + + + 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 a 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] for their multimedia sessions, the ABNF [RFC5234] syntax + for the SS-FSSI and FSSI containers is provided in Section 4.5 of + [RFC6364]. + +5.6. FEC Scheme Requirements + + In order to be used with this framework, a FEC scheme MUST be capable + of processing data arranged into blocks of ADUs (source blocks). + + A specification for a new FEC scheme MUST include the following: + + 1. The FEC Encoding ID value that uniquely identifies the FEC + scheme. This value MUST be registered with IANA, as described in + Section 11. + + 2. The type, semantics, and encoding format of the Repair FEC + Payload ID. + + 3. The name, type, semantics, and text value encoding rules for zero + or more FEC-Scheme-Specific Information elements. + + + + +Watson, et al. Standards Track [Page 24] + +RFC 6363 FEC Framework October 2011 + + + 4. A full specification of the FEC code. + + 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). + + Furthermore, given a source block as defined in Section 5.2, + 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. + + 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 that -- 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. + + 5. A description of practical encoding and decoding algorithms. + + 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 are both + possible and practical. + + FEC scheme specifications MAY additionally define the following: + + Type, semantics, and encoding format of an Explicit Source FEC + Payload ID. + + Whenever a FEC scheme specification defines an 'encoding format' for + an element, this has to be defined in terms of a sequence of bytes + that can be embedded within a protocol. The length of the encoding + format either MUST 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. + + + + + + + + + + + +Watson, et al. Standards Track [Page 25] + +RFC 6363 FEC Framework October 2011 + + + FEC scheme specifications SHOULD use the terminology defined in this + document and SHOULD follow the following format: + + 1. Introduction <Describe the use cases addressed by this FEC + scheme> + + 2. Formats and Codes + + 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> + + 2.2. Repair FEC Payload ID <Define the type and format of the + Repair FEC Payload ID> + + 2.3. FEC Framework Configuration Information <Define the names, + types, and text value encoding formats of the FEC-Scheme- + Specific Information elements> + + 3. Procedures <Describe any procedures that are specific to this + FEC scheme, in particular derivation and interpretation of the + fields in the FEC Payload IDs and FEC-Scheme-Specific + Information> + + 4. FEC Code Specification <Provide a complete specification of the + FEC Code> + + 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 a 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. + +6. Feedback + + 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 may also need to be enhanced to report on the performance + of the FEC, e.g., how much lost data was recovered by the FEC? + + + + + + +Watson, et al. Standards Track [Page 26] + +RFC 6363 FEC Framework October 2011 + + + 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 that use 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 information calculated both 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 that would give an inaccurate + picture of congestion conditions. + + New applications that require such feedback SHOULD use RTP/RTCP + [RFC3550]. + +7. Transport Protocols + + 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). + +8. Congestion Control + + 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. + +8.1. Motivation + + o The enforcement of congestion control principles has gained a lot + of momentum in the IETF over recent years. While the need for + congestion control over the open Internet is unquestioned, and the + goal of TCP friendliness is generally agreed upon for most (but + not all) applications, the problem of congestion detection and + measurement in heterogeneous networks can hardly be considered + 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. + + + +Watson, et al. Standards Track [Page 27] + +RFC 6363 FEC Framework October 2011 + + + o The authors of this document are primarily interested in + applications where the application reliability requirements and + end-to-end reliability of the network differ, such that it + warrants higher-layer protection of the packet stream, e.g., due + to the presence of unreliable links in the end-to-end path and + where real-time, scalability, or other constraints prohibit the + use of higher-layer (transport or application) feedback. A + typical example for such applications is multicast and broadcast + streaming 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. + + o This FEC Framework is not defined as, nor is it intended to be, a + quality-of-service (QoS) enhancement tool to combat losses + resulting from highly congested networks. It should not be used + for such purposes. + + o In order to prevent such misuse, 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 the Digital Video Broadcasting (DVB) + Project, the Third Generation Partnership Project (3GPP), and + 3GPP2, all of which appear to share the environment and the + problem described. + + o 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 traffic generated + as an emergency signal. + + o 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 that the application alone would + not itself cause; i.e., the use of this framework must not make + things worse. + + + + + + + +Watson, et al. Standards Track [Page 28] + +RFC 6363 FEC Framework October 2011 + + + o Taking the above considerations into account, Section 8.2 + specifies a small set of constraints for FEC; these constraints + are mandatory for all senders compliant with this FEC Framework. + Further restrictions can be imposed by certain CDPs. + +8.2. Normative Requirements + + o 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, that could warrant a higher FEC strength. + However, in this specification, we give preference to the overall + stability and network friendliness of average applications. + + o Whenever the source data rate is adapted due to the operation of + congestion control mechanisms, the FEC repair data rate MUST be + similarly adapted. + +9. Security Considerations + + 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 contrary, + 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. + +9.1. Problem Statement + + A content delivery system is potentially subject to many attacks. + Attacks can target the content, the CDP, or the network itself, with + completely different consequences, particularly in terms of the + number of impacted nodes. + + Attacks can have several goals: + + o They can try to give access to confidential content (e.g., in the + case of non-free content). + + o They can try to corrupt the source flows (e.g., to prevent a + receiver from using them), which is a form of denial-of-service + (DoS) attack. + + + +Watson, et al. Standards Track [Page 29] + +RFC 6363 FEC Framework October 2011 + + + o 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. + + o 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. + + 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 + does not necessarily fully control this 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 the 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 outside of the context of the IETF, that can + be proprietary solutions. Otherwise, the Secure Real-Time Transport + Protocol (SRTP) [RFC3711] and IPsec/Encapsulating Security Payload + (IPsec/ESP) [RFC4303] 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 generate RTP source flows and, when applied below the + + + +Watson, et al. Standards Track [Page 30] + +RFC 6363 FEC Framework October 2011 + + + FEC Framework, that both the FEC source and repair packets be regular + RTP packets. Therefore, SRTP is not considered to be 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. + +9.2. Attacks against the Data Flows + +9.2.1. Access to Confidential Content + + 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 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 be 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 be applied + either on the source data before the FEC protection or, if done after + the FEC protection, on both the FEC source packets and repair packets + (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 the 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 from getting hold of the plaintext, all + processing, once deciphering has taken place, MUST occur in a + protected environment. If encryption is applied after FEC protection + + + + + +Watson, et al. Standards Track [Page 31] + +RFC 6363 FEC Framework October 2011 + + + at the sending side (i.e., below the 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 + such cases, 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 on the traffic. In that case, it is + preferable 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. + +9.2.2. Content Corruption + + 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: + + o At the application layer, SRTP [RFC3711] provides several + solutions to check the integrity and authenticate the source of + RTP and RTCP messages, among other services. For instance, when + associated with the Timed Efficient Stream Loss-Tolerant + Authentication (TESLA) [RFC4383], 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, with TESLA, checking a packet + requires a small delay (a second or more) after its reception. + Whether or not this extra delay, both in terms of startup delay at + the client and end-to-end delay, is appropriate 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. + + o At the network layer, IPsec/ESP [RFC4303] offers (among other + services) an integrity verification mechanism that can be used to + provide authentication/content integrity services. + + + + + + + +Watson, et al. Standards Track [Page 32] + +RFC 6363 FEC Framework October 2011 + + + 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 be used. + + Note that when integrity protection is applied, it is RECOMMENDED + that it take place on both FEC source and repair packets. The + motivation is to keep corrupted packets from being considered during + decoding, as such packets would often lead to a decoding failure or + result in a corrupted decoded source flow. + +9.3. Attacks against the FEC Parameters + + 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. + + Therefore, it is RECOMMENDED that security measures be taken to + guarantee the integrity of the FEC Framework Configuration + Information. 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 a FEC source or repair + packet will lead a receiver to assign this packet to a wrong block. + + Therefore, it is RECOMMENDED that security measures be taken to + guarantee the integrity of the Explicit Source FEC Payload ID and + Repair FEC Payload ID. To that purpose, one of the packet-level + source authentication/content integrity techniques described in + Section 9.2.2 can be used. + +9.4. When Several Source Flows Are to Be Protected Together + + 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. + + + + +Watson, et al. Standards Track [Page 33] + +RFC 6363 FEC Framework October 2011 + + + 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 has strict + security requirements. + + Since the use of the 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 that FEC + protecting flows with totally different security requirements be + avoided. Otherwise, significant processing overhead would be added + to protect source flows that do not need it. + +9.5. Baseline Secure FEC Framework Operation + + 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 feedback from the receivers. For instance, this is + the case when considering RTP/RTCP-based source flows. + + This section describes a baseline mode of secure FEC Framework + operation based on the application of the IPsec 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 Asynchronous Layered Coding (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 NACK- + Oriented Reliable Multicast (NORM) operation, for sender-to-group + transmissions as well as unicast feedback 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 + [RFC5775] relies on the management of IPsec Security Associations + (SAs) and corresponding Security Policy Database (SPD) entries, since + NORM requires a second set of SAs and SPD entries to be defined to + protect unicast feedback from receivers. + + + +Watson, et al. Standards Track [Page 34] + +RFC 6363 FEC Framework October 2011 + + + Note that the IPsec/ESP requirement profiles outlined in [RFC5775] + and [RFC5740] are commonly available on many potential hosts. They + can form the basis of a secure mode of operation. Configuration and + operation of IPsec typically require privileged user authorization. + Automated key management implementations are typically configured + with the privileges necessary to allow the needed system IPsec + configuration. + +10. Operations and Management Considerations + + 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 aspects and recommendations related to + specific deployments and solutions. + + 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. + +10.1. What Are the Key Aspects to Consider? + + 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: + + 1. A Single Small Generic Component within a Larger (and Often + Legacy) Solution: The FEC Framework is one component within a + larger solution that includes 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. + + 2. 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). + + + + +Watson, et al. Standards Track [Page 35] + +RFC 6363 FEC Framework October 2011 + + + 3. 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 support the FEC + Framework at all. + + 4. 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. + + 5. Congestion Control Considerations: See Section 8 for a discussion + on whether or not congestion control is needed, and its + relationships with the FEC Framework. + + 6. 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). + + 7. Protecting a Single Flow vs. Several Flows Globally: The FEC + Framework can be used to protect a single flow or several flows + globally. + +10.2. Operational and Management Recommendations + + Overall, from the discussion in Section 10.1, it is clear that the + CDPs and FEC schemes compatible with the FEC Framework differ widely + 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. + + + + + + + + + +Watson, et al. Standards Track [Page 36] + +RFC 6363 FEC Framework October 2011 + + + 1. 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. + + 2. 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 + the case of a one-to-one scenario) or at least occasional + feedback (e.g., in the case of a multicast, one-to-many + scenario). All these applications have naturally different + operational and management aspects. They also have different + requirements or features, if any, for collecting feedback, + processing it, and acting on it. The data structures for + carrying the feedback also vary. + + 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 [RFC5424] or Simple Network Management + Protocol (SNMP) notifications [RFC3411], is RECOMMENDED. When + required, a mapping mechanism between the Syslog and SNMP + reporting mechanisms could be used, as described in [RFC5675] and + [RFC5676]. + + 3. Non-FEC Framework Capable Receivers: Section 5.3 gives + recommendations on how to provide backward compatibility in the + 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 the 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. + + + + + + +Watson, et al. Standards Track [Page 37] + +RFC 6363 FEC Framework October 2011 + + + 4. 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., not be prone to packet loss, packet reordering, or varying + delays in delivering packets. + + Similarly, when the FEC Framework is used within middleboxes, it + is RECOMMENDED that the paths be as reliable as possible between + the middleboxes that perform FEC decoding and the end-systems + where the receiving applications operate. + + 5. 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 long delivery delay + cannot happen, for whatever reason. If such a rare event + happens, this event SHOULD NOT compromise the operation of the + FECFRAME instances, at either the sending side or the 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 on, for + instance, 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 + zeroed ADU(s), depending on the nature of the ADU flow. + Implementers SHOULD consider the consequences of such alternative + approaches, based on their use cases. + + 6. 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 the 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 + counterproductive to add repair traffic to a real-time flow for + + + +Watson, et al. Standards Track [Page 38] + +RFC 6363 FEC Framework October 2011 + + + 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. + + 7. 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 Section 9.4 for additional recommendations for situations + where strict access control for ADU flows is needed. + + Additionally, when multiple ADU flows are globally protected, a + receiver that 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 lost, which might + significantly reduce the efficiency of the FEC scheme. + +11. IANA Considerations + + 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 purpose, this document creates a new + registry called the "FEC Framework (FECFRAME) FEC Encoding IDs". + + The values that can be assigned within the "FEC Framework (FECFRAME) + FEC Encoding IDs" registry are numeric indexes in the range (0, 255). + Values of 0 and 255 are reserved. Assignment requests are granted on + an IETF Review basis as defined in [RFC5226]. Section 5.6 defines + explicit requirements that documents defining new FEC Encoding IDs + should meet. + +12. Acknowledgments + + This document is based in part on [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. + + + + +Watson, et al. Standards Track [Page 39] + +RFC 6363 FEC Framework October 2011 + + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002. + + [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error + Correction (FEC) Building Block", RFC 5052, August 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + January 2008. + + [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. + +13.2. Informative References + + [FEC-SF] Watson, M., Luby, M., Westerlund, M., and S. Wenger, + "Forward Error Correction (FEC) Streaming Framework", Work + in Progress, July 2005. + + [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); + Protocols and codecs", 3GPP TS 26.346, March 2009, + <http://ftp.3gpp.org/specs/html-info/26346.htm>. + + [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., + Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, + K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., + Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header + Compression (ROHC): Framework and four profiles: RTP, UDP, + ESP, and uncompressed", RFC 3095, July 2001. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + + + + + +Watson, et al. Standards Track [Page 40] + +RFC 6363 FEC Framework October 2011 + + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, March 2004. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient + Stream Loss-Tolerant Authentication (TESLA) in the Secure + Real-time Transport Protocol (SRTP)", RFC 4383, + February 2006. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + July 2006. + + [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network + Management Protocol (SNMP) Notifications to SYSLOG + Messages", RFC 5675, October 2009. + + [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, + "Definitions of Managed Objects for Mapping SYSLOG + Messages to Simple Network Management Protocol (SNMP) + Notifications", RFC 5676, October 2009. + + [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE + Report Block Type for RTP Control Protocol (RTCP) Extended + Reports (XRs)", RFC 5725, February 2010. + + [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, + "NACK-Oriented Reliable Multicast (NORM) Transport + Protocol", RFC 5740, November 2009. + + [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous + Layered Coding (ALC) Protocol Instantiation", RFC 5775, + April 2010. + + [RFC6364] Begen, A., "Session Description Protocol Elements for FEC + Framework", RFC 6364, October 2011. + + + + + + + + + +Watson, et al. Standards Track [Page 41] + +RFC 6363 FEC Framework October 2011 + + +Authors' Addresses + + Mark Watson + Netflix, Inc. + 100 Winchester Circle + Los Gatos, CA 95032 + USA + + EMail: watsonm@netflix.com + + + Ali Begen + Cisco + 181 Bay Street + Toronto, ON M5J 2T3 + Canada + + EMail: abegen@cisco.com + + + Vincent Roca + INRIA + 655, av. de l'Europe + Inovallee; Montbonnot + ST ISMIER cedex 38334 + France + + EMail: vincent.roca@inria.fr + URI: http://planete.inrialpes.fr/people/roca/ + + + + + + + + + + + + + + + + + + + + + + +Watson, et al. Standards Track [Page 42] + |