idnits 2.17.1 draft-ietf-fecframe-framework-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 38 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2011) is 4812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework M. Watson 3 Internet-Draft Netflix, Inc. 4 Intended status: Standards Track A. Begen 5 Expires: August 19, 2011 Cisco 6 V. Roca 7 INRIA 8 February 15, 2011 10 Forward Error Correction (FEC) Framework 11 draft-ietf-fecframe-framework-13 13 Abstract 15 This document describes a framework for using Forward Error 16 Correction (FEC) codes with applications in public and private IP 17 networks to provide protection against packet loss. The framework 18 supports applying FEC to arbitrary packet flows over unreliable 19 transport and is primarily intended for real-time, or streaming, 20 media. This framework can be used to define Content Delivery 21 Protocols that provide FEC for streaming media delivery or other 22 packet flows. Content Delivery Protocols defined using this 23 framework can support any FEC scheme (and associated FEC codes) which 24 is compliant with various requirements defined in this document. 25 Thus, Content Delivery Protocols can be defined which are not 26 specific to a particular FEC scheme, and FEC schemes can be defined 27 which are not specific to a particular Content Delivery Protocol. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 19, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 77 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 78 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 13 79 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14 81 4.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 82 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21 83 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 5.2. Structure of the Source Block . . . . . . . . . . . . . . 21 85 5.3. Packet Format for FEC Source Packets . . . . . . . . . . . 21 86 5.3.1. Generic Explicit Source FEC Payload ID . . . . . . . . 23 87 5.4. Packet Format for FEC Repair Packets . . . . . . . . . . . 23 88 5.4.1. Packet Format for FEC Repair Packets over RTP . . . . 24 89 5.5. FEC Framework Configuration Information . . . . . . . . . 24 90 5.6. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 26 91 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 92 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30 93 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31 94 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 31 95 8.2. Normative Requirements . . . . . . . . . . . . . . . . . . 32 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 97 9.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 33 98 9.2. Attacks Against the Data Flows . . . . . . . . . . . . . . 34 99 9.2.1. Access to Confidential Content . . . . . . . . . . . . 34 100 9.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 35 101 9.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 36 102 9.4. When Several Source Flows are to be Protected Together . . 37 103 9.5. Baseline Secure FEC Framework Operation . . . . . . . . . 37 104 10. Operations and Management Considerations . . . . . . . . . . . 39 105 10.1. What are the Key Aspects to Consider? . . . . . . . . . . 39 106 10.2. Operational and Management Recommendations . . . . . . . . 40 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 108 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 110 13.1. Normative references . . . . . . . . . . . . . . . . . . . 45 111 13.2. Informative references . . . . . . . . . . . . . . . . . . 45 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 114 1. Introduction 116 Many applications have a requirement to transport a continuous stream 117 of packetized data from a source (sender) to one or more destinations 118 (receivers) over networks which do not provide guaranteed packet 119 delivery. Primary examples are real-time, or streaming, media 120 applications such as broadcast, multicast or on-demand audio, video 121 or multimedia. 123 Forward Error Correction (FEC) is a well-known technique for 124 improving reliability of packet transmission over networks which do 125 not provide guaranteed packet delivery, especially in multicast and 126 broadcast applications. The FEC Building Block defined in [RFC5052] 127 provides a framework for definition of Content Delivery Protocols 128 (CDPs) for object delivery (including, primarily, file delivery) 129 which make use of separately defined FEC schemes. Any CDP defined 130 according to the requirements of the FEC Building Block can then 131 easily be used with any FEC scheme which is also defined according to 132 the requirements of the FEC Building Block. 134 Note that the term "Forward Erasure Correction" is sometimes used, 135 erasures being a type of error in which data is lost and this loss 136 can be detected, rather than being received in corrupted form. The 137 focus of this document is strictly on erasures and, the term "Forward 138 Error Correction" is more widely used. 140 This document defines a framework for the definition of CDPs which 141 provide for FEC protection for arbitrary packet flows over unreliable 142 transports such as UDP. As such, this document complements the FEC 143 Building Block of [RFC5052], by providing for the case of arbitrary 144 packet flows over unreliable transport, the same kind of framework as 145 that document provides for object delivery. This document does not 146 define a complete CDP, but rather defines only those aspects that are 147 expected to be common to all CDPs based on this framework. 149 This framework does not define how the flows to be protected are 150 determined, nor how the details of the protected flows and the FEC 151 streams which protect them are communicated from sender to receiver. 152 It is expected that any complete CDP specification which makes use of 153 this framework will address these signaling requirements. However, 154 this document does specify the information which is required by the 155 FEC Framework at the sender and receiver, e.g., details of the flows 156 to be FEC protected, the flow(s) that will carry the FEC protection 157 data and an opaque container for FEC-Scheme-Specific Information. 159 FEC schemes designed for use with this framework must fulfill a 160 number of requirements defined in this document. These requirements 161 are different from those defined in [RFC5052] for FEC schemes for 162 object delivery. However, there is a great deal of commonality and 163 FEC schemes defined for object delivery may be easily adapted for use 164 with the framework defined in this document. 166 Since the RTP protocol is (often) used over UDP, this framework can 167 be applied to RTP flows as well. FEC repair packets may be sent 168 directly over UDP or RTP. The latter approach has the advantage that 169 RTP instrumentation, based on RTP Control Protocol (RTCP), can be 170 used for the repair flow. Additionally, the post-repair RTCP 171 extended reports [RFC5725] may be used to obtain information about 172 the loss rate after FEC recovery. 174 The use of RTP for repair flows is defined for each FEC scheme by 175 defining an RTP payload format for that particular FEC scheme 176 (possibly in the same document). 178 2. Definitions and Abbreviations 180 Application Data Unit (ADU): The unit of source data provided as 181 payload to the transport layer. 183 ADU Flow: A sequence of ADUs associated with a transport-layer flow 184 identifier (such as the standard 5-tuple {Source IP address, source 185 port, destination IP address, destination port, transport protocol}). 187 AL-FEC: Application-layer Forward Error Correction. 189 Application Protocol: Control protocol used to establish and control 190 the source flow being protected, e.g., RTSP. 192 Content Delivery Protocol (CDP): A complete application protocol 193 specification which, through the use of the framework defined in this 194 document, is able to make use of FEC schemes to provide FEC 195 capabilities. 197 FEC Code: An algorithm for encoding data such that the encoded data 198 flow is resilient to data loss. Note that in general FEC codes may 199 also be used to make a data flow resilient to corruption, but that is 200 not considered in this document. 202 FEC Framework: A protocol framework for definition of Content 203 Delivery Protocols using FEC, such as the framework defined in this 204 document. 206 FEC Framework Configuration Information: Information which controls 207 the operation of the FEC Framework. 209 FEC Payload ID: Information which identifies the contents of a packet 210 with respect to the FEC scheme. 212 FEC Repair Packet: At a sender (respectively, at a receiver) a 213 payload submitted to (respectively, received from) the transport 214 protocol containing one or more repair symbols along with a Repair 215 FEC Payload ID and possibly an RTP header. 217 FEC Scheme: A specification which defines the additional protocol 218 aspects required to use a particular FEC code with the FEC Framework. 220 FEC Source Packet: At a sender (respectively, at a receiver) a 221 payload submitted to (respectively, received from) the transport 222 protocol containing an ADU along with an optional Explicit Source FEC 223 Payload ID. 225 Protection Amount: The relative increase in data sent due to the use 226 of FEC. 228 Repair Flow: The packet flow carrying FEC data. 230 Repair FEC Payload ID: An FEC Payload ID specifically for use with 231 repair packets. 233 Source Flow: The packet flow to which FEC protection is to be 234 applied. A source flow consists of ADUs. 236 Source FEC Payload ID: An FEC Payload ID specifically for use with 237 source packets. 239 Source Protocol: A protocol used for the source flow being protected, 240 e.g., RTP. 242 Transport Protocol: The protocol used for transport of the source and 243 repair flows, e.g., UDP and DCCP. 245 The following definitions are aligned with [RFC5052]: 247 Code Rate: The ratio between the number of source symbols and the 248 number of encoding symbols. By definition, the code rate is such 249 that 0 < code rate <= 1. A code rate close to 1 indicates that a 250 small number of repair symbols have been produced during the encoding 251 process. 253 Encoding Symbol: Unit of data generated by the encoding process. 254 With systematic codes, source symbols are part of the encoding 255 symbols. 257 Packet Erasure Channel: A communication path where packets are either 258 dropped (e.g., by a congested router, or because the number of 259 transmission errors exceeds the correction capabilities of the 260 physical-layer codes) or received. When a packet is received, it is 261 assumed that this packet is not corrupted. 263 Repair Symbol: Encoding symbol that is not a source symbol. 265 Source Block: Group of ADUs which are to be FEC protected as a single 266 block. 268 Source Symbol: Unit of data used during the encoding process. 270 Systematic Code: FEC code in which the source symbols are part of the 271 encoding symbols. 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 275 document are to be interpreted as described in [RFC2119]. 277 3. Architecture Overview 279 The FEC Framework is described in terms of an additional layer 280 between the transport layer (e.g., UDP or DCCP) and protocols running 281 over this transport layer. As such, the data path interface between 282 the FEC Framework and both underlying and overlying layers can be 283 thought of as being the same as the standard interface to the 284 transport layer, i.e., the data exchanged consists of datagram 285 payloads each associated with a single ADU flow identified by the 286 standard 5-tuple {Source IP address, source port, destination IP 287 address, destination port, transport protocol}. In the case that RTP 288 is used for the repair flows, the source and repair data can be 289 multiplexed using RTP onto a single UDP flow and needs to be 290 consequently demultiplexed at the receiver. There are various ways 291 in which this multiplexing can be done, for example as described in 292 [RFC4588]. 294 It is important to understand that the main purpose of the FEC 295 Framework architecture is to allocate functional responsibilities to 296 separately documented components in such a way that specific 297 instances of the components can be combined in different ways to 298 describe different protocols. 300 The FEC Framework makes use of an FEC scheme, in a similar sense to 301 that defined in [RFC5052] and uses the terminology of that document. 302 The FEC scheme defines the FEC encoding and decoding, and defines the 303 protocol fields and procedures used to identify packet payload data 304 in the context of the FEC scheme. The interface between the FEC 305 Framework and an FEC scheme, which is described in this document, is 306 a logical one, which exists for specification purposes only. At an 307 encoder, the FEC Framework passes ADUs to the FEC scheme for FEC 308 encoding. The FEC scheme returns repair symbols with their 309 associated Repair FEC Payload IDs, and in some cases Source FEC 310 Payload IDs, depending on the FEC scheme. At a decoder, the FEC 311 Framework passes transport packet payloads (source and repair) to the 312 FEC scheme and the FEC scheme returns additional recovered source 313 packet payloads. 315 This document defines certain FEC Framework Configuration Information 316 which MUST be available to both sender and receiver(s). For example, 317 this information includes the specification of the ADU flows which 318 are to be FEC protected, specification of the ADU flow(s) which will 319 carry the FEC protection (repair) data and the relationship(s) 320 between these source and repair flows (i.e., which source flow(s) are 321 protected by each repair flow(s)). The FEC Framework Configuration 322 Information also includes information fields which are specific to 323 the FEC scheme. This information is analogous to the FEC Object 324 Transmission Information defined in [RFC5052]. 326 The FEC Framework does not define how the FEC Framework Configuration 327 Information for the stream is communicated from sender to receiver. 328 This has to be defined by any CDP specification as described in the 329 following sections. 331 In this architecture we assume that the interface to the transport 332 layer supports the concepts of data units (referred to here as 333 Application Data Units (ADUs)) to be transported and identification 334 of ADU flows on which those data units are transported. Since this 335 is an interface internal to the architecture, we do not specify this 336 interface explicitly. We do require that ADU flows which are 337 distinct from the transport layer point of view (for example, 338 distinct UDP flows as identified by the UDP source/destination 339 addresses/ports) are also distinct on the interface between the 340 transport layer and the FEC Framework. 342 As noted above, RTP flows are a specific example of ADU flows which 343 might be protected by the FEC Framework. From the FEC Framework 344 point of view, RTP source flows are ADU flows like any other, with 345 the RTP header included within the ADU. 347 Depending on the FEC scheme, RTP can also be used as a transport for 348 repair packet flows. In this case an FEC scheme has to define an RTP 349 payload format for the repair data. 351 The architecture outlined above is illustrated in the Figure 1. In 352 this architecture, two (optional) RTP instances are shown, for the 353 source and repair data respectively. This is because the use of RTP 354 for the source data is separate from and independent of the use of 355 RTP for the repair data. The appearance of two RTP instances is more 356 natural when one considers that in many FEC codes, the repair payload 357 contains repair data calculated across the RTP headers of the source 358 packets. Thus, a repair packet carried over RTP starts with an RTP 359 header of its own which is followed (after the Repair Payload ID) by 360 repair data containing bytes which protect the source RTP headers (as 361 well as repair data for the source RTP payloads). 363 +--------------------------------------------+ 364 | Application | 365 +--------------------------------------------+ 366 | 367 | 368 | 369 + - - - - - - - - - - - - - - - - - - - - - - - -+ 370 | +--------------------------------------------+ | 371 | Application Layer | 372 | +--------------------------------------------+ | 373 | | 374 | + -- -- -- -- -- -- -- -- -- -- --+ | | 375 | RTP (Optional) | | 376 | | | |- Configuration/Coordination 377 +- -- -- -- -- -- -- -- -- -- -- -+ | 378 | | | | 379 | ADU flows | 380 | | v | 381 +--------------------------------------------+ +----------------+ 382 | | FEC Framework (This document) |<--->| FEC Scheme | 383 +--------------------------------------------+ +----------------+ 384 | | | | 385 Source | Repair | 386 | | | | 387 +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ 388 | | RTP Layer | | RTP Processing | | | 389 | (Optional) | +-- -- -- |- -- -+ | 390 | | +-- -- -- -- -- -- -- |--+ | | 391 | | RTP (De)multiplexing | | 392 | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | 393 | 394 | +--------------------------------------------+ | 395 | Transport Layer (e.g., UDP) | 396 | +--------------------------------------------+ | 397 | 398 | +--------------------------------------------+ | 399 | IP | 400 | +--------------------------------------------+ | 402 | Content Delivery Protocol | 403 + - - - - - - - - - - - - - - - - - - - - - - - + 405 Figure 1: FEC Framework architecture 407 The content of the transport payload for repair packets is fully 408 defined by the FEC scheme. For a specific FEC scheme, a means MAY be 409 defined for repair data to be carried over RTP, in which case the 410 repair packet payload format starts with the RTP header. This 411 corresponds to defining an RTP payload format for the specific FEC 412 scheme. 414 The use of RTP for repair packets is independent of the protocols 415 used for source packets: if RTP is used for source packets, repair 416 packets may or may not use RTP and vice versa (although it is 417 unlikely that there are useful scenarios where non-RTP source flows 418 are protected by RTP repair flows). FEC schemes are expected to 419 recover entire transport payloads for recovered source packets in all 420 cases. For example, if RTP is used for source flows, the FEC scheme 421 is expected to recover the entire UDP payload, including the RTP 422 header. 424 4. Procedural Overview 426 4.1. General 428 The mechanism defined in this document does not place any 429 restrictions on the ADUs which can be protected together, except that 430 the ADU is carried over a supported transport protocol (See 431 Section 7). The data can be from multiple source flows that are 432 protected jointly. The FEC Framework handles the source flows as a 433 sequence of source blocks each consisting of a set of ADUs, possibly 434 from multiple source flows which are to be protected together. For 435 example, each source block can be constructed from those ADUs related 436 to a particular segment in time of the flow. 438 At the sender, the FEC Framework passes the payloads for a given 439 block to the FEC scheme for FEC encoding. The FEC scheme performs 440 the FEC encoding operation and returns the following information: 442 o Optionally, FEC Payload IDs for each of the source payloads 443 (encoded according to an FEC-Scheme-Specific format). 445 o One or more FEC repair packet payloads. 447 o FEC Payload IDs for each of the repair packet payloads (encoded 448 according to an FEC-Scheme-Specific format). 450 The FEC Framework then performs two operations. First, it appends 451 the Source FEC Payload IDs, if provided, to each of the ADUs, and 452 sends the resulting packets, known as FEC source packets, to the 453 receiver, and second it places the provided FEC repair packet 454 payloads and corresponding Repair FEC Payload IDs appropriately to 455 construct FEC repair packets and send them to the receiver. 457 This document does not define how the sender determines which ADUs 458 are included in which source blocks or the sending order and timing 459 of FEC source and repair packets. A specific CDP MAY define this 460 mapping or it MAY be left as implementation dependent at the sender. 461 However, a CDP specification MUST define how a receiver determines a 462 minimum length of time that it needs to wait to receive FEC repair 463 packets for any given source block. FEC schemes MAY define 464 limitations on this mapping, such as maximum size of source blocks, 465 but SHOULD NOT attempt to define specific mappings. The sequence of 466 operations at the sender is described in more detail in Section 4.2. 468 At the receiver, original ADUs are recovered by the FEC Framework 469 directly from any FEC source packets received simply by removing the 470 Source FEC Payload ID, if present. The receiver also passes the 471 contents of the received ADUs, plus their FEC Payload IDs to the FEC 472 scheme for possible decoding. 474 If any ADUs related to a given source block have been lost, then the 475 FEC scheme can perform FEC decoding to recover the missing ADUs 476 (assuming sufficient FEC source and repair packets related to that 477 source block have been received). 479 Note that the receiver might need to buffer received source packets 480 to allow time for the FEC repair packets to arrive and FEC decoding 481 to be performed before some or all of the received or recovered 482 packets are passed to the application. If such a buffer is not 483 provided, then the application has to be able to deal with the severe 484 re-ordering of packets that can occur. However, such buffering is 485 CDP and/or implementation-specific and is not specified here. The 486 receiver operation is described in more detail in Section 4.3. 488 The FEC source packets MUST contain information which identifies the 489 source block and the position within the source block (in terms 490 specific to the FEC scheme) occupied by the ADU. This information is 491 known as the Source FEC Payload ID. The FEC scheme is responsible 492 for defining and interpreting this information. This information MAY 493 be encoded into a specific field within the FEC source packet format 494 defined in this specification, called the Explicit Source FEC Payload 495 ID field. The exact contents and format of the Explicit Source FEC 496 Payload ID field are defined by the FEC schemes. Alternatively, the 497 FEC scheme MAY define how the Source FEC Payload ID is derived from 498 other fields within the source packets. This document defines the 499 way that the Explicit Source FEC Payload ID field is appended to 500 source packets to form FEC source packets. 502 The FEC repair packets MUST contain information which identifies the 503 source block and the relationship between the contained repair 504 payloads and the original source block. This is known as the Repair 505 FEC Payload ID. This information MUST be encoded into a specific 506 field, the Repair FEC Payload ID field, the contents and format of 507 which are defined by the FEC schemes. 509 The FEC scheme MAY use different FEC Payload ID field formats for 510 source and repair packets. 512 4.2. Sender Operation 514 It is assumed that the sender has constructed or received original 515 data packets for the session. These could be carrying any type of 516 data. The following operations, illustrated in Figure 2, for the 517 case of UDP repair flows and Figure 3 for the case of RTP repair 518 flows, describe a possible way to generate compliant source and 519 repair flows: 521 1. ADUs are provided by the application. 523 2. A source block is constructed as specified in Section 5.2. 525 3. The source block is passed to the FEC scheme for FEC encoding. 526 The Source FEC Payload ID information of each source packet is 527 determined by the FEC scheme. If required by the FEC scheme the 528 Source FEC Payload ID is encoded into the Explicit Source FEC 529 Payload ID field. 531 4. The FEC scheme performs FEC encoding, generating repair packet 532 payloads from a source block and a Repair FEC Payload ID field 533 for each repair payload. 535 5. The Explicit Source FEC Payload IDs (if used), Repair FEC Payload 536 IDs and repair packet payloads are provided back from the FEC 537 scheme to the FEC Framework. 539 6. The FEC Framework constructs FEC source packets according to 540 Section 5.3 and FEC repair packets according to Section 5.4 using 541 the FEC Payload IDs and repair packet payloads provided by the 542 FEC scheme. 544 7. The FEC source and repair packets are sent using normal 545 transport-layer procedures. The port(s) and multicast group(s) 546 to be used for FEC repair packets are defined in the FEC 547 Framework Configuration Information. The FEC source packets are 548 sent using the same ADU flow identification information as would 549 have been used for the original source packets if the FEC 550 Framework were not present (for example, in the UDP case, the UDP 551 source and destination addresses and ports on the IP datagram 552 carrying the source packet will be the same whether or not the 553 FEC Framework is applied). 555 +----------------------+ 556 | Application | 557 +----------------------+ 558 | 559 |(1) ADUs 560 | 561 v 562 +----------------------+ +------------------+ 563 | FEC Framework | | | 564 | |-------------------------->| FEC Scheme | 565 |(2) Construct source |(3) Source Block | | 566 | blocks | | (4) FEC Encoding | 567 |(6) Construct FEC |<--------------------------| | 568 | source and repair | | | 569 | packets |(5) Explicit Source FEC | | 570 +----------------------+ Payload IDs +------------------+ 571 | Repair FEC Payload IDs 572 | Repair symbols 573 | 574 |(7) FEC source and repair packets 575 v 576 +----------------------+ 577 | Transport Layer | 578 | (e.g., UDP) | 579 +----------------------+ 581 Figure 2: Sender operation 583 +----------------------+ 584 | Application | 585 +----------------------+ 586 | 587 |(1) ADUs 588 | 589 v 590 +----------------------+ +------------------+ 591 | FEC Framework | | | 592 | |-------------------------->| FEC Scheme | 593 |(2) Construct source |(3) Source Block | | 594 | blocks | | (4) FEC Encoding | 595 |(6) Construct FEC |<--------------------------| | 596 | source packets and| | | 597 | repair payloads |(5) Explicit Source FEC | | 598 +----------------------+ Payload IDs +------------------+ 599 | | Repair FEC Payload IDs 600 | | Repair symbols 601 | | 602 |(7) Source |(7') Repair payloads 603 | packets | 604 | | 605 | + -- -- -- -- -+ 606 | | RTP | 607 | +-- -- -- -- --+ 608 v v 609 +----------------------+ 610 | Transport Layer | 611 | (e.g., UDP) | 612 +----------------------+ 614 Figure 3: Sender operation with RTP repair flows 616 4.3. Receiver Operation 618 The following describes a possible receiver algorithm, illustrated in 619 Figure 4 and Figure 5 for the case of RTP repair flows, when 620 receiving an FEC source or repair packet: 622 1. FEC source packets and FEC repair packets are received and passed 623 to the FEC Framework. The type of packet (source or repair) and 624 the source flow to which it belongs (in the case of source 625 packets) is indicated by the ADU flow information which 626 identifies the flow at the transport layer. 628 In the special case that RTP is used for repair packets, and 629 source and repair packets are multiplexed onto the same UDP flow, 630 then RTP demultiplexing is required to demultiplex source and 631 repair flows. However, RTP processing is applied only to the 632 repair packets at this stage; source packets continue to be 633 handled as UDP payloads (i.e., including their RTP headers). 635 2. The FEC Framework extracts the Explicit Source FEC Payload ID 636 field (if present) from the source packets and the Repair FEC 637 Payload ID from the repair packets. 639 3. The Explicit Source FEC Payload IDs (if present), Repair FEC 640 Payload IDs, FEC source and repair payloads are passed to the FEC 641 scheme. 643 4. The FEC scheme uses the received FEC Payload IDs (and derived FEC 644 Source Payload IDs in the case that the Explicit Source FEC 645 Payload ID field is not used) to group source and repair packets 646 into source blocks. If at least one source packet is missing 647 from a source block, and at least one repair packet has been 648 received for the same source block then FEC decoding can be 649 performed in order to recover missing source payloads. The FEC 650 scheme determines whether source packets have been lost and 651 whether enough data for decoding of any or all of the missing 652 source payloads in the source block has been received. 654 5. The FEC scheme returns the ADUs to the FEC Framework in the form 655 of source blocks containing received and decoded ADUs and 656 indications of any ADUs which were missing and could not be 657 decoded. 659 6. The FEC Framework passes the received and recovered ADUs to the 660 application. 662 The description above defines functionality responsibilities but does 663 not imply a specific set of timing relationships. Source packets 664 which are correctly received and those which are reconstructed MAY be 665 delivered to the application out of order and in a different order 666 from the order of arrival at the receiver. Alternatively, buffering 667 and packet re-ordering MAY be applied to re-order received and 668 reconstructed source packets into the order they were placed into the 669 source block, if that is necessary according to the application. 671 +----------------------+ 672 | Application | 673 +----------------------+ 674 ^ 675 | 676 |(6) ADUs 677 | 678 +----------------------+ +------------------+ 679 | FEC Framework | | | 680 | |<---------------------------| FEC Scheme | 681 |(2)Extract FEC Payload|(5) ADUs | | 682 | IDs and pass IDs & | | (4) FEC Decoding | 683 | payloads to FEC |--------------------------->| | 684 | scheme |(3) Explicit Source FEC | | 685 +----------------------+ Payload IDs +------------------+ 686 ^ Repair FEC Payload IDs 687 | Source payloads 688 | Repair payloads 689 | 690 |(1) FEC source and repair packets 691 | 692 +----------------------+ 693 | Transport Layer | 694 | (e.g., UDP) | 695 +----------------------+ 697 Figure 4: Receiver operation 699 +----------------------+ 700 | Application | 701 +----------------------+ 702 ^ 703 | 704 |(6) ADUs 705 | 706 +----------------------+ +------------------+ 707 | FEC Framework | | | 708 | |<---------------------------| FEC Scheme | 709 |(2)Extract FEC Payload|(5) ADUs | | 710 | IDs and pass IDs & | | (4) FEC Decoding | 711 | payloads to FEC |--------------------------->| | 712 | scheme |(3) Explicit Source FEC | | 713 +----------------------+ Payload IDs +------------------+ 714 ^ ^ Repair FEC Payload IDs 715 | | Source payloads 716 | | Repair payloads 717 | | 718 |Source |Repair payloads 719 |packets | 720 | | 721 +-- |- -- -- -- -- -- -+ 722 |RTP| | RTP Processing | 723 | | +-- -- -- --|-- -+ 724 | +-- -- -- -- -- |--+ | 725 | | RTP Demux | | 726 +-- -- -- -- -- -- -- -+ 727 ^ 728 |(1) FEC source and repair packets 729 | 730 +----------------------+ 731 | Transport Layer | 732 | (e.g., UDP) | 733 +----------------------+ 735 Figure 5: Receiver operation with RTP repair flows 737 Note that the above procedure might result in a situation in which 738 not all ADUs are recovered. 740 5. Protocol Specification 742 5.1. General 744 This section specifies the protocol elements for the FEC Framework. 745 Three components of the protocol are defined in this document and are 746 described in the following sections: 748 1. Construction of a source block from ADUs. The FEC code will be 749 applied to this source block to produce the repair payloads. 751 2. A format for packets containing source data. 753 3. A format for packets containing repair data. 755 The operation of the FEC Framework is governed by certain FEC 756 Framework Configuration Information, which is defined in this 757 section. A complete protocol specification that uses this framework 758 MUST specify the means to determine and communicate this information 759 between sender and receiver. 761 5.2. Structure of the Source Block 763 The FEC Framework and FEC scheme exchange ADUs in the form of source 764 blocks. A source block is generated by the FEC Framework from an 765 ordered sequence of ADUs. The allocation of ADUs to blocks is 766 dependent on the application. Note that some ADUs may not be 767 included in any block. Each source block provided to the FEC scheme 768 consists of an ordered sequence of ADUs where the following 769 information is provided for each ADU: 771 o A description of the source flow with which the ADU is associated 772 with. 774 o The ADU itself. 776 o The length of the ADU. 778 5.3. Packet Format for FEC Source Packets 780 The packet format for FEC source packets MUST be used to transport 781 the payload of an original source packet. As depicted in Figure 6, 782 it consists of the original packet, optionally followed by the 783 Explicit Source FEC Payload ID field. The FEC scheme determines 784 whether the Explicit Source FEC Payload ID field is required. This 785 determination is specific to each ADU flow. 787 +------------------------------------+ 788 | IP Header | 789 +------------------------------------+ 790 | Transport Header | 791 +------------------------------------+ 792 | Application Data Unit | 793 +------------------------------------+ 794 | Explicit Source FEC Payload ID | 795 +------------------------------------+ 797 Figure 6: Structure of the FEC packet format for FEC source packets 799 The FEC source packets MUST be sent using the same ADU flow as would 800 have been used for the original source packets if the FEC Framework 801 were not present. The transport payload of the FEC source packet 802 MUST consist of the ADU followed by the Explicit Source FEC Payload 803 ID field, if required. 805 The Explicit Source FEC Payload ID field contains information 806 required to associate the source packet with a source block and for 807 the operation of the FEC algorithm, and is defined by the FEC scheme. 808 The format of the Source FEC Payload ID field is defined by the FEC 809 scheme. In the case that the FEC scheme or CDP defines a means to 810 derive the Source FEC Payload ID from other information in the packet 811 (for example a sequence number used by the application protocol), 812 then the Source FEC Payload ID field is not included in the packet. 813 In this case, the original source packet and FEC source packet are 814 identical. 816 In applications where avoidance of IP packet fragmentation is a goal, 817 CDPs SHOULD consider the Explicit Source FEC Payload ID size when 818 determining the size of ADUs that will be delivered using the FEC 819 Framework. This is because the addition of the Explicit Source FEC 820 Payload ID increases the packet length. 822 The Explicit Source FEC Payload ID is placed at the end of the packet 823 so that in the case that Robust Header Compression (ROHC) [RFC3095] 824 or other header compression mechanisms are used and in the case that 825 a ROHC profile is defined for the protocol carried within the 826 transport payload (for example RTP), then ROHC will still be applied 827 for the FEC source packets. Applications that are used with this 828 framework need to consider that FEC schemes can add this Explicit 829 Source FEC Payload ID and thereby increase the packet size. 831 In many applications, support for FEC is added to a pre-existing 832 protocol and in this case use of the Explicit Source FEC Payload ID 833 can break backwards compatibility, since source packets are modified. 835 5.3.1. Generic Explicit Source FEC Payload ID 837 In order to apply FEC protection using multiple FEC schemes to a 838 single source flow, all schemes have to use the same Explicit Source 839 FEC Payload ID format. In order to enable this, it is RECOMMENDED 840 that FEC schemes support the Generic Explicit Source FEC Payload ID 841 format described below. 843 The Generic Explicit Source FEC Payload ID has a length of two octets 844 and consists of an unsigned packet sequence number in network-byte 845 order. The allocation of sequence numbers to packets is independent 846 of any FEC scheme and of the source block construction, except that 847 the use of this sequence number places a constraint on source block 848 construction. Source packets within a given source block MUST have 849 consecutive sequence numbers (where consecutive includes wrap-around 850 from the maximum value which can be represented in two octets (65535) 851 to 0). Sequence numbers SHOULD NOT be reused until all values in the 852 sequence number space have been used. 854 Note that if the original packets of the source flow are already 855 carrying a packet sequence number that is at least two bytes long, 856 there is no need to add the generic Explicit Source FEC Payload ID 857 and modify the packets. 859 5.4. Packet Format for FEC Repair Packets 861 The packet format for FEC repair packets is shown in Figure 7. The 862 transport payload consists of a Repair FEC Payload ID field followed 863 by repair data generated in the FEC encoding process. 865 +------------------------------------+ 866 | IP Header | 867 +------------------------------------+ 868 | Transport Header | 869 +------------------------------------+ 870 | Repair FEC Payload ID | 871 +------------------------------------+ 872 | Repair Symbols | 873 +------------------------------------+ 875 Figure 7: Packet format for repair packets 877 The Repair FEC Payload ID field contains information required for the 878 operation of the FEC algorithm at the receiver. This information is 879 defined by the FEC scheme. The format of the Repair FEC Payload ID 880 field is defined by the FEC scheme. 882 5.4.1. Packet Format for FEC Repair Packets over RTP 884 For FEC schemes which specify the use of RTP for repair packets, the 885 packet format for repair packets includes an RTP header as shown in 886 Figure 8. 888 +------------------------------------+ 889 | IP header | 890 +------------------------------------+ 891 | Transport Header (UDP) | 892 +------------------------------------+ 893 | RTP Header | 894 +------------------------------------+ 895 | Repair FEC Payload ID | 896 +------------------------------------+ 897 | Repair Symbols | 898 +------------------------------------+ 900 Figure 8: Packet format for repair packets 902 5.5. FEC Framework Configuration Information 904 The FEC Framework Configuration Information is information that the 905 FEC Framework needs in order to apply FEC protection to the ADU 906 flows. A complete CDP specification that uses the framework 907 specified here MUST include details of how this information is 908 derived and communicated between sender and receiver. 910 The FEC Framework Configuration Information includes identification 911 of the set of source flows. For example, in the case of UDP, each 912 source flow is uniquely identified by a tuple {Source IP address, 913 source UDP port, destination IP address, destination UDP port}. In 914 some applications some of these fields can contain wildcards, so that 915 the flow is identified by a subset of the fields. In particular, in 916 many applications the limited tuple {Destination IP address, 917 destination UDP port} is sufficient. 919 A single instance of the FEC Framework provides FEC protection for 920 packets of the specified set of source flows, by means of one or more 921 packet flows consisting of repair packets. The FEC Framework 922 Configuration Information includes, for each instance of the FEC 923 Framework: 925 1. Identification of the repair flows. 927 2. For each source flow protected by the repair flow(s): 929 A. Definition of the source flow. 931 B. An integer identifier for this flow definition (i.e., tuple). 932 This identifier MUST be unique amongst all source flows that 933 are protected by the same FEC repair flow. Integer 934 identifiers can be allocated starting from zero and 935 increasing by one for each flow. However, any random (but 936 still unique) allocation is also possible. A source flow 937 identifier need not be carried in source packets since source 938 packets are directly associated with a flow by virtue of 939 their packet headers. 941 3. The FEC Encoding ID, identifying the FEC scheme. 943 4. The length of the Explicit Source FEC Payload ID (in octets). 945 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, 946 each consisting of a name and a value where the valid element 947 names and value ranges are defined by the FEC scheme. 949 Multiple instances of the FEC Framework, with separate and 950 independent FEC Framework Configuration Information, can be present 951 at a sender or receiver. A single instance of the FEC Framework 952 protects packets of the source flows identified in (2) above, i.e., 953 all packets sent on those flows MUST be FEC source packets as defined 954 in Section 5.3. A single source flow can be protected by multiple 955 instances of the FEC Framework. 957 The integer flow identifier identified in (2b) above is a shorthand 958 to identify source flows between the FEC Framework and the FEC 959 scheme. The reason for defining this as an integer, and including it 960 in the FEC Framework Configuration Information is so that the FEC 961 scheme at the sender and receiver can use it to identify the source 962 flow with which a recovered packet is associated. The integer flow 963 identifier can therefore take the place of the complete flow 964 description (e.g., UDP 4-tuple). 966 Whether and how this flow identifier is used is defined by the FEC 967 scheme. Since repair packets can provide protection for multiple 968 source flows, repair packets would either not carry the identifier at 969 all or can carry multiple identifiers. However, in any case, the 970 flow identifier associated with a particular source packet can be 971 recovered from the repair packets as part of an FEC decoding 972 operation. 974 A single FEC repair flow provides repair packets for a single 975 instance of the FEC Framework. Other packets MUST NOT be sent within 976 this flow, i.e., all packets in the FEC repair flow MUST be FEC 977 repair packets as defined in Section 5.4 and MUST relate to the same 978 FEC Framework instance. 980 In the case that RTP is used for repair packets, the identification 981 of the repair packet flow can also include the RTP payload type to be 982 used for repair packets. 984 FSSI includes the information that is specific to the FEC scheme used 985 by the CDP. FSSI is used to communicate the information that cannot 986 be adequately represented otherwise and is essential for proper FEC 987 encoding and decoding operations. The motivation behind separating 988 the FSSI required only by the sender (which is carried in Sender-Side 989 FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of 990 the FSSI is to provide the receiver or the third party entities a 991 means of controlling the FEC operations at the sender. Any FSSI 992 other than the one solely required by the sender MUST be communicated 993 via the FSSI container. 995 The variable-length SS-FSSI and FSSI containers transmit the 996 information in textual representation and contain zero or more 997 distinct elements, whose descriptions are provided by the fully- 998 specified FEC schemes. 1000 For the CDPs that choose the Session Description Protocol (SDP) 1001 [RFC4566] as their session description protocol, the ABNF [RFC5234] 1002 syntax for the SS-FSSI and FSSI containers is provided in Section 4.5 1003 of [I-D.ietf-fecframe-sdp-elements]. 1005 5.6. FEC Scheme Requirements 1007 In order to be used with this framework, an FEC scheme MUST be 1008 capable of processing data arranged into blocks of ADUs (source 1009 blocks). 1011 A specification for a new FEC scheme MUST include the following: 1013 1. The FEC Encoding ID value that uniquely identifies the FEC 1014 scheme. This value MUST be registered with IANA as described in 1015 Section 11. 1017 2. The type, semantics and encoding format of the Repair FEC Payload 1018 ID. 1020 3. The name, type, semantics and text value encoding rules for zero 1021 or more FEC-Scheme-Specific Information elements. 1023 4. A full specification of the FEC code. 1025 This specification MUST precisely define the valid FEC-Scheme- 1026 Specific Information values, the valid FEC Payload ID values and 1027 the valid packet payload sizes (where packet payload refers to 1028 the space within a packet dedicated to carrying encoding 1029 symbols). 1031 Furthermore, given a source block as defined in Section 5.2, 1032 valid values of the FEC-Scheme-Specific Information, a valid 1033 Repair FEC Payload ID value and a valid packet payload size, the 1034 specification MUST uniquely define the values of the encoding 1035 symbols to be included in the repair packet payload of a packet 1036 with the given Repair FEC Payload ID value. 1038 A common and simple way to specify the FEC code to the required 1039 level of detail is to provide a precise specification of an 1040 encoding algorithm which, given a source block, valid values of 1041 the FEC-Scheme-Specific Information, a valid Repair FEC Payload 1042 ID value and a valid packet payload size as input produces the 1043 exact value of the encoding symbols as output. 1045 5. A description of practical encoding and decoding algorithms. 1047 This description need not be to the same level of detail as for 1048 the encoding above, however it has to be sufficient to 1049 demonstrate that encoding and decoding of the code is both 1050 possible and practical. 1052 FEC scheme specifications MAY additionally define the following: 1054 1. Type, semantics and encoding format of an Explicit Source FEC 1055 Payload ID. 1057 Whenever an FEC scheme specification defines an 'encoding format' for 1058 an element, this has to be defined in terms of a sequence of bytes 1059 which can be embedded within a protocol. The length of the encoding 1060 format MUST either be fixed or it MUST be possible to derive the 1061 length from examining the encoded bytes themselves. For example, the 1062 initial bytes can include some kind of length indication. 1064 FEC scheme specifications SHOULD use the terminology defined in this 1065 document and SHOULD follow the following format: 1067 1. Introduction 1070 2. Formats and Codes 1072 2.1 Source FEC Payload ID(s) 1076 2.2 Repair FEC Payload ID 1079 2.3 FEC Framework Configuration Information 1083 3. Procedures 1087 4. FEC Code Specification 1090 Specifications can include additional sections including examples. 1092 Each FEC scheme MUST be specified independently of all other FEC 1093 schemes; for example, in a separate specification or a completely 1094 independent section of larger specification (except, of course, a 1095 specification of one FEC scheme can include portions of another by 1096 reference). Where an RTP Payload Format is defined for repair data 1097 for a specific FEC scheme, the RTP Payload Format and the FEC scheme 1098 can be specified within the same document. 1100 6. Feedback 1102 Many applications require some kind of feedback on transport 1103 performance. E.g., how much data arrived at the receiver, at what 1104 rate and when? When FEC is added to such applications, feedback 1105 mechanisms can also need to be enhanced to report on the performance 1106 of the FEC. E.g., how much lost data was recovered by the FEC? 1108 When used to provide instrumentation for engineering purposes, it is 1109 important to remember that FEC is generally applied to relatively 1110 small blocks of data (in the sense that each block is transmitted 1111 over a relatively small period of time). Thus, feedback information 1112 that is averaged over longer periods of time will likely not provide 1113 sufficient information for engineering purposes. More detailed 1114 feedback over shorter time scales might be preferred. For example, 1115 for applications using RTP transport, see [RFC5725]. 1117 Applications which used feedback for congestion control purposes MUST 1118 calculate such feedback on the basis of packets received before FEC 1119 recovery is applied. If this requirement conflicts with other uses 1120 of the feedback information then the application MUST be enhanced to 1121 support both information calculated pre- and post- FEC recovery. 1122 This is to ensure that congestion control mechanisms operate 1123 correctly based on congestion indications received from the network, 1124 rather than on post-FEC recovery information which would give an 1125 inaccurate picture of congestion conditions. 1127 New applications which require such feedback SHOULD use RTP/RTCP 1128 [RFC3550]. 1130 7. Transport Protocols 1132 This framework is intended to be used to define CDPs that operate 1133 over transport protocols providing an unreliable datagram service, 1134 including in particular the User Datagram Protocol (UDP) and the 1135 Datagram Congestion Control Protocol (DCCP). 1137 8. Congestion Control 1139 This section starts with some informative background on the 1140 motivation of the normative requirements for congestion control, 1141 which are spelled out in Section 8.2. 1143 8.1. Motivation 1145 o The enforcement of congestion control principles has gained a lot 1146 of momentum in the IETF over the recent years. While the need for 1147 congestion control over the open Internet is unquestioned, and the 1148 goal of TCP friendliness is generally agreed for most (but not 1149 all) applications, the subject of congestion detection and 1150 measurement in heterogeneous networks can hardly be considered as 1151 solved. Most congestion control algorithms detect and measure 1152 congestion by taking (primarily or exclusively) the packet loss 1153 rate into account. This appears to be inappropriate in 1154 environments where a large percentage of the packet losses are the 1155 result of link-layer errors and independent of the network load. 1157 o The authors of this document are primarily interested in 1158 applications where the application reliability requirements and 1159 end-to-end reliability of the network differ, such that it 1160 warrants higher-layer protection of the packet stream, e.g., due 1161 to the presence of unreliable links in the end-to-end path and 1162 where real-time, scalability or other constraints prohibit the use 1163 of higher-layer (transport or application) feedback. A typical 1164 example for such applications is multicast and broadcast streaming 1165 or multimedia transmission over heterogeneous networks. In other 1166 cases, application reliability requirements can be so high that 1167 the required end-to-end reliability will be difficult to achieve. 1168 Furthermore, the end-to-end network reliability is not necessarily 1169 known in advance. 1171 o This FEC Framework is not defined, nor intended, as a QoS 1172 enhancement tool to combat losses resulting from highly congested 1173 networks. It should not be used for such purposes. 1175 o In order to prevent such mis-use, one approach is to leave 1176 standardization to bodies most concerned with the problem 1177 described above. However, the IETF defines base standards used by 1178 several bodies, including DVB, 3GPP, 3GPP2, all of which appear to 1179 share the environment and the problem described. 1181 o Another approach is to write a clear applicability statement. For 1182 example, one could restrict the use of this framework to networks 1183 with certain loss characteristics (e.g., wireless links). 1184 However, there can be applications where the use of FEC is 1185 justified to combat congestion-induced packet losses - 1186 particularly in lightly loaded networks, where congestion is the 1187 result of relatively rare random peaks in instantaneous traffic 1188 load - thereby intentionally violating congestion control 1189 principles. One possible example for such an application could be 1190 a no-matter-what, brute-force FEC protection of a traffic 1191 generated as an emergency signal. 1193 o A third approach is to require at a minimum that the use of this 1194 framework with any given application, in any given environment, 1195 does not cause congestion issues which the application alone would 1196 not itself cause, i.e., the use of this framework must not make 1197 things worse. 1199 o Taking above considerations into account, Section 8.2 specifies a 1200 small set of constraints for the FEC, which are mandatory for all 1201 senders compliant with this FEC Framework. Further restrictions 1202 can be imposed by certain CDPs. 1204 8.2. Normative Requirements 1206 o The bandwidth of FEC repair data MUST NOT exceed the bandwidth of 1207 the original source data being protected (without the possible 1208 addition of an Explicit Source FEC Payload ID). This disallows 1209 the (static or dynamic) use of excessively strong FEC to combat 1210 high packet loss rates, which can otherwise be chosen by naively 1211 implemented dynamic FEC-strength selection mechanisms. We 1212 acknowledge that there are a few exotic applications, e.g., IP 1213 traffic from space-based senders, or senders in certain hardened 1214 military devices, which could warrant a higher FEC strength. 1215 However, in this specification we give preference to the overall 1216 stability and network friendliness of average applications. 1218 o Whenever the source data rate is adapted due to the operation of 1219 congestion control mechanisms, the FEC repair data rate MUST be 1220 similarly adapted. 1222 9. Security Considerations 1224 First of all, it must be clear that the application of FEC protection 1225 to a stream does not provide any kind of security. On the opposite, 1226 the FEC Framework itself could be subject to attacks, or could pose 1227 new security risks. The goals of this section are to state the 1228 problem, discuss the risks and identify solutions when feasible. It 1229 also defines a mandatory to implement (but not mandatory to use) 1230 security scheme. 1232 9.1. Problem Statement 1234 A content delivery system is potentially subject to many attacks. 1235 Attacks can target the content, or the CDP, or the network itself, 1236 with completely different consequences, in particular in terms of the 1237 number of impacted nodes. 1239 Attacks can have several goals: 1241 o They can try to give access to a confidential content (e.g., in 1242 case of a non-free content). 1244 o They can try to corrupt the source flows (e.g., to prevent a 1245 receiver from using them), which is a form of DoS attack. 1247 o They can try to compromise the receiver's behavior (e.g., by 1248 making the decoding of an object computationally expensive), which 1249 is another form of DoS attack. 1251 o They can try to compromise the network's behavior (e.g., by 1252 causing congestion within the network), which potentially impacts 1253 a large number of nodes. 1255 These attacks can be launched either against the source and/or repair 1256 flows (e.g., by sending fake FEC source and/or repair packets) or 1257 against the FEC parameters that are sent either in-band (e.g., in the 1258 Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or 1259 out-of-band (e.g., in the FEC Framework Configuration Information). 1261 Several dimensions to the problem need to be considered. The first 1262 one is the way the FEC Framework is used. The FEC Framework can be 1263 used end-to-end, i.e., it can be included in the final end-device 1264 where the upper application runs; or the FEC Framework can be used in 1265 middleboxes, for instance, to globally protect several source flows 1266 exchanged between two or more distant sites. 1268 A second dimension is the threat model. When the FEC Framework 1269 operates in the end-device, this device (e.g., a personal computer) 1270 might be subject to attacks. Here, the attacker is either the end- 1271 user (who might want to access confidential content) or somebody 1272 else. In all cases the attacker has access to the end-device, but 1273 not necessarily to the full control of the end-device (a secure 1274 domain can exist). Similarly, when the FEC Framework operates in a 1275 middlebox, this middlebox can be subject to attacks or the attacker 1276 can gain access to it. The threats can also concern the end-to-end 1277 transport (e.g., through Internet). Here, examples of threats 1278 include the transmission of fake FEC source or repair packets, the 1279 replay of valid packets, the drop, delay or misordering of packets, 1280 and of course traffic eavesdropping. 1282 The third dimension consists in the desired security services. Among 1283 them, the content integrity and sender authentication services are 1284 probably the most important features. We can also mention DoS 1285 mitigation, anti-replay protection or content confidentiality. 1287 Finally, the fourth dimension consists in the security tools 1288 available. This is the case of the various Digital Rights Management 1289 (DRM) systems, defined out of the context of the IETF and that can be 1290 proprietary solutions. Otherwise SRTP and IPsec/ESP are two tools 1291 that can turn out to be useful in the context of the FEC Framework. 1292 Note that using SRTP requires that the application generates RTP 1293 source flows and, when applied below the FEC Framework, that both the 1294 FEC source and repair packets to be regular RTP packets. Therefore 1295 SRTP is not considered as a universal solution applicable in all use 1296 cases. 1298 In the following sections, we further discuss security aspects 1299 related to the use of the FEC Framework. 1301 9.2. Attacks Against the Data Flows 1303 9.2.1. Access to Confidential Content 1305 Access control to the source flow being transmitted is typically 1306 provided by means of encryption. This encryption can be done by the 1307 content provider itself, or within the application (for instance by 1308 using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), or 1309 at the network layer, on a per-packet basis when IPsec/ESP is used 1310 [RFC4303]. If confidentiality is a concern, it is RECOMMENDED that 1311 one of these solutions is used. Even if we mention these attacks 1312 here, they are neither related to nor facilitated by the use of FEC. 1314 Note that when encryption is applied, this encryption MUST either be 1315 applied on the source data before the FEC protection, or if done 1316 after the FEC protection, then both the FEC source packets and repair 1317 packets MUST be encrypted (and an encryption at least as 1318 cryptographically secure as the encryption applied on the FEC source 1319 packets MUST be used for the FEC repair packets). Otherwise, if 1320 encryption were to be performed only on the FEC source packets after 1321 FEC encoding, a non-authorized receiver could be able to recover the 1322 source data after decoding the FEC repair packets provided that a 1323 sufficient number of such packets were available. 1325 The following considerations apply when choosing where to apply 1326 encryption (and more generally where to apply security services 1327 beyond encryption). Once decryption has taken place, the source data 1328 is in plaintext. The full path between the output of the deciphering 1329 module and the final destination (e.g., the TV display in case of a 1330 video) MUST be secured, in order to prevent any unauthorized access 1331 to the source data. 1333 When the FEC Framework endpoint is the end system (i.e., where the 1334 upper application runs) and if the threat model includes the 1335 possibility that an attacker has access to this end system, then the 1336 end system architecture is very important. More precisely, in order 1337 to prevent an attacker to get hold of the plaintext, all processings, 1338 once deciphering has taken place, MUST occur in a protected 1339 environment. If encryption is applied after FEC protection at the 1340 sending side (i.e., below FEC Framework), it means that FEC decoding 1341 MUST take place in the protected environment. With certain use 1342 cases, this MAY be complicated or even impossible. In that case 1343 applying encryption before FEC protection is preferred. 1345 When the FEC Framework endpoint is a middlebox, the recovered source 1346 flow, after FEC decoding, SHOULD NOT be sent in plaintext to the 1347 final destination(s) if the threat model includes the possibility 1348 that an attacker eavesdrops the traffic. In that case also it is 1349 preferred to apply encryption before FEC protection. 1351 In some cases, encryption could be applied both before and after the 1352 FEC protection. The considerations described above still apply in 1353 such cases. 1355 9.2.2. Content Corruption 1357 Protection against corruptions (e.g., against forged FEC source/ 1358 repair packets) is achieved by means of a content integrity 1359 verification/source authentication scheme. This service is usually 1360 provided at the packet level. In this case, after removing all the 1361 forged packets, the source flow might sometimes be recovered. 1362 Several techniques can provide this content integrity/source 1363 authentication service: 1365 o At the application layer, SRTP [RFC3711] provides several 1366 solutions to check the integrity and authenticate the source of 1367 RTP and RTCP messages, among other services. For instance, 1368 associated to the Timed Efficient Stream Loss-Tolerant 1369 Authentication (TESLA) [RFC4383], SRTP is an attractive solution 1370 that is robust to losses, provides a true authentication/integrity 1371 service, and does not create any prohibitive processing load or 1372 transmission overhead. Yet, checking a packet requires a small 1373 delay (a second or more) after its reception with TESLA. Whether 1374 this extra delay, both in terms of startup delay at the client and 1375 end-to-end delay, is appropriate or not depends on the target use 1376 case. In some situations, this might degrade the user experience. 1377 In other situations, this will not be an issue. Other building 1378 blocks can be used within SRTP to provide content integrity/ 1379 authentication services. 1381 o At the network layer, IPsec/ESP [RFC4303] offers (among other 1382 services) an integrity verification mechanism that can be used to 1383 provide authentication/content integrity services. 1385 It is up to the developer and the person in charge of deployment, who 1386 know the security requirements and features of the target application 1387 area, to define which solution is the most appropriate. Nonetheless 1388 it is RECOMMENDED that at least one of these techniques is used. 1390 Note that when integrity protection is applied, it is RECOMMENDED 1391 that it takes place on both FEC source and repair packets. The 1392 motivation is to avoid corrupted packets to be considered during 1393 decoding, which would often lead to a decoding failure or result in a 1394 corrupted decoded source flow. 1396 9.3. Attacks Against the FEC Parameters 1398 Attacks on these FEC parameters can prevent the decoding of the 1399 associated object. For instance, modifying the finite field size of 1400 a Reed-Solomon FEC scheme (when applicable) will lead a receiver to 1401 consider a different FEC code. 1403 It is therefore RECOMMENDED that security measures are taken to 1404 guarantee the FEC Framework Configuration Information integrity. 1405 Since the FEC Framework does not define how the FEC Framework 1406 Configuration Information is communicated from sender to receiver, we 1407 cannot provide further recommendations on how to guarantee its 1408 integrity. However, any complete CDP specification MUST give 1409 recommendations on how to achieve it. When the FEC Framework 1410 Configuration Information is sent out-of-band, e.g., in a session 1411 description, it SHOULD be protected, for instance, by digitally 1412 signing it. 1414 Attacks are also possible against some FEC parameters included in the 1415 Explicit Source FEC Payload ID and Repair FEC Payload ID. For 1416 instance, modifying the Source Block Number of an FEC source or 1417 repair packet will lead a receiver to assign this packet to a wrong 1418 block. 1420 It is therefore RECOMMENDED that security measures are taken to 1421 guarantee the Explicit Source FEC Payload ID and Repair FEC Payload 1422 ID integrity. To that purpose, one of the packet-level source 1423 authentication/content integrity techniques of Section 9.2.2 can be 1424 used. 1426 9.4. When Several Source Flows are to be Protected Together 1428 When several source flows, with different security requirements, need 1429 to be FEC protected jointly, within a single FEC Framework instance, 1430 then each flow MAY be processed appropriately, before the protection. 1431 For instance, source Flows that require access control MAY be 1432 encrypted before they are FEC protected. 1434 There are also situations where the only insecure domain is the one 1435 over which the FEC Framework operates. In that case, this situation 1436 MAY be addressed at the network layer, using IPsec/ESP (see 1437 Section 9.5), even if only a subset of the source flows have strict 1438 security requirements. 1440 Since the use of FEC Framework should not add any additional threat, 1441 it is RECOMMENDED that the FEC Framework aggregate flow be in line 1442 with the maximum security requirements of the individual source 1443 flows. For instance, if denial-of-service (DoS) protection is 1444 required, an integrity protection SHOULD be provided below the FEC 1445 Framework, using for instance IPsec/ESP. 1447 Generally speaking, whenever feasible, it is RECOMMENDED to avoid FEC 1448 protecting flows with totally different security requirements. 1449 Otherwise, an important processing would be added to protect the 1450 source flows that do not need it. 1452 9.5. Baseline Secure FEC Framework Operation 1454 This section describes a baseline mode of secure FEC Framework 1455 operation based on the application of the IPsec security protocol, 1456 which is one possible solution to solve or mitigate the security 1457 threats introduced by the use of the FEC Framework. 1459 Two related documents are of interest. First, Section 5.1 of 1460 [RFC5775] defines a baseline secure ALC operation for sender-to-group 1461 transmissions, assuming the presence of a single sender and a source- 1462 specific multicast (SSM) or SSM-like operation. The proposed 1463 solution, based on IPsec/ESP, can be used to provide a baseline FEC 1464 Framework secure operation, for the downstream source flow. 1466 Second, Section 7.1 of [RFC5740] defines a baseline secure NORM 1467 operation, for sender-to-group transmissions as well as unicast 1468 feedbacks from receivers. Here, it is also assumed there is a single 1469 sender. The proposed solution is also based on IPsec/ESP. However, 1470 the difference with respect to the first document relies on the 1471 management of IPsec Security Associations (SA) and corresponding 1472 Security Policy Database (SPD) entries, since NORM requires a second 1473 set of SA and SPD to be defined to protect unicast feedbacks from 1474 receivers. 1476 The FEC Framework has been defined in such a way to be independent 1477 from the application that generates source flows. Some applications 1478 might use purely unidirectional flows, while other applications might 1479 also use unicast feedbacks from the receivers. For instance, this is 1480 the case when considering RTP/RTCP based source flows. Depending on 1481 the specific situation, it is RECOMMENDED that the baseline secure 1482 FEC Framework operation inherits from [RFC5775] in case of purely 1483 unidirectional sender-to-group flows, or [RFC5740] in case both 1484 sender-to-group and unicast feedbacks flows are needed. 1486 Note that the IPsec/ESP requirements profiles outlined in [RFC5775] 1487 and [RFC5740] are commonly available on many potential hosts. They 1488 can form the basis of a secure mode of operation. One potential 1489 limitation, however, is the need for privileged user authorization. 1490 However, automated key management implementations are typically 1491 configured with the privileges necessary to affect system IPsec 1492 configuration. 1494 10. Operations and Management Considerations 1496 The question of operating and managing the FEC Framework and the 1497 associated FEC scheme(s) is of high practical importance. The goals 1498 of this section are to discuss the general requirements, aspects 1499 related to a specific deployment and solutions whenever possible. 1501 In particular, this section discusses the questions of 1502 interoperability across vendors/use cases and whether defining 1503 mandatory to implement (but not mandatory to use) solutions is 1504 beneficial. 1506 10.1. What are the Key Aspects to Consider? 1508 Several aspects need to be considered since they will directly impact 1509 the way the FEC Framework and the associated FEC schemes can be 1510 operated and managed. 1512 This section lists them as follows: 1514 o A Single Small Generic Component within a Larger (and Often 1515 Legacy) Solution: The FEC Framework is one component within a 1516 larger solution which includes both one or several upper-layer 1517 applications (that generate one or several ADU flows) and an 1518 underlying protocol stack. A key design principle is that the FEC 1519 Framework should be able to work without making any assumption 1520 with respect to either the upper-layer application(s) or the 1521 underlying protocol stack, even if there are special cases where 1522 assumptions are made. 1524 o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- 1525 Many without Feedback Scenarios: The FEC Framework can be used in 1526 use cases that completely differ from one another. Some use cases 1527 are one-way (e.g., in broadcast networks), with either a one-to- 1528 one, one-to-many or many-to-many transmission model, and the 1529 receiver(s) cannot send any feedback to the sender(s). Other use 1530 cases follow a bidirectional one-to-one, one-to-many, or many-to- 1531 many scenario, and the receiver(s) can send feedback to the 1532 sender(s). 1534 o Non-FEC Framework Capable Receivers: With the one-to-many and 1535 many-to-many use cases, the receiver population might have 1536 different capabilities with respect to the FEC Framework itself 1537 and the supported FEC schemes. Some receivers might not be 1538 capable of decoding the repair packets belonging to a particular 1539 FEC scheme, while some other receivers might not be supporting the 1540 FEC Framework at all. 1542 o Internet vs. non-Internet Networks: The FEC Framework can be 1543 useful in many use cases that use a transport network that is not 1544 the public Internet (e.g., with IPTV or Mobile TV). In such 1545 networks, the operational and management considerations can be 1546 achieved through an open or proprietary solution, which is 1547 specified outside of the IETF. 1549 o Congestion Control Considerations: See Section 8 for a discussion 1550 on whether congestion control is needed or not, and its 1551 relationships with the FEC Framework. 1553 o Within End-Systems vs. within Middleboxes: The FEC Framework can 1554 be used within end-systems, very close to the upper-layer 1555 application, or within dedicated middleboxes, for instance when it 1556 is desired to protect one or several flows while they cross a 1557 lossy channel between two or more remote sites. 1559 o Protecting a Single Flow vs. Several Flows Globally: The FEC 1560 Framework can be used to protect a single flow, or several flows 1561 globally. 1563 10.2. Operational and Management Recommendations 1565 Overall, from the discussion of Section 10.1, it is clear that the 1566 CDPs and FEC schemes compatible with the FEC Framework widely differ 1567 in their capabilities, application and deployment scenarios such that 1568 a common operation and management method or protocol that works well 1569 for all of them would be too complex to define. Thus, as a design 1570 choice, the FEC Framework does not dictate the use of any particular 1571 technology or protocol for transporting FEC data, managing the hosts, 1572 signaling the configuration information or encoding the configuration 1573 information. This provides flexibility and is one of the main goals 1574 of the FEC Framework. However, this section gives some 1575 recommendations. 1577 o A Single Small Generic Component within a Larger (and Often 1578 Legacy) Solution: It is anticipated that the FEC Framework will 1579 often be used to protect one or several RTP streams. Therefore, 1580 there are use cases that may take advantage of RTCP to collect 1581 feedback information, and one can take advantage of the tools 1582 using (or used by) RTCP to operate and manage the FEC Framework 1583 instance along with the associated FEC schemes. 1585 o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- 1586 Many without Feedback Scenarios: With use cases that are one-way, 1587 the FEC Framework sender does not have any way to gather feedback 1588 from receivers. With use cases that are bidirectional, the FEC 1589 Framework sender can collect detailed feedback (e.g., in case of a 1590 one-to-one scenario) or at least occasional feedback (e.g., in 1591 case of a multicast, one-to-many scenario). All these 1592 applications have naturally different operational and management 1593 aspects. If any, they also have different requirements or 1594 features for collecting feedback, processing it and acting on it. 1595 The data structures for carrying the feedback also vary. 1597 o Non-FEC Framework Capable Receivers: Section 5.3 gives 1598 recommendations on how to provide backward compatibility in 1599 presence of receivers that cannot support the FEC scheme being 1600 used, or the FEC Framework itself: basically the use of Explicit 1601 Source FEC Payload ID is banned. Additionally, a non-FEC 1602 Framework capable receiver MUST also have a means not to receive 1603 the repair packets that it will not be able to decode in the first 1604 place or a means to identify and discard them appropriately upon 1605 receiving them. This can be achieved by sending repair packets on 1606 a different transport-layer flow. In case of an RTP source flow, 1607 this can also be achieved by using an RTP framing for FEC repair 1608 packets with a different payload type. Both source and repair 1609 packets can then be sent on the same transport-layer flow. It is 1610 the responsibility of the sender to select the appropriate 1611 mechanism when needed. 1613 o Within End-Systems vs. within Middleboxes: When the FEC Framework 1614 is used within middleboxes, it is RECOMMENDED that the paths 1615 between the hosts where the sending applications run and the 1616 middlebox that performs FEC encoding be as reliable as possible, 1617 since these paths are not protected against erasures by default. 1618 Similarly, it is RECOMMENDED that the paths between the 1619 middleboxes that perform FEC decoding and the end-systems where 1620 the receiving applications operate, in situations where this is a 1621 different host, be as reliable as possible since these paths are 1622 not protected against losses by default. 1624 The recommendation for the sending side is particularly important 1625 with FEC schemes that do not modify the ADU for backward 1626 compatibility purposes (i.e. do not use any Explicit Source FEC 1627 Payload ID) and rely for instance on the RTP sequence number field 1628 to identify FEC source packets within their source block. In this 1629 case, a lost or excessively delayed packet on this path directly 1630 leads to a gap in the RTP sequence number space seen by the 1631 FECFRAME instance. With FEC schemes that indicate in the Repair 1632 FEC Payload ID, for each source block, the base RTP sequence 1633 number and number of consecutive RTP packets that belong to this 1634 source block, a missing ADU could cause the FECFRAME sender to 1635 switch to a new source block. However, some FEC schemes and/or 1636 receivers may not necessarily handle such varying source block 1637 sizes. Thus, all the ADUs SHOULD be fed into the FEC encoder in 1638 their proper sequence and within a desired certain delay. For 1639 cases when this cannot be guaranteed, the sender and receiver 1640 implementations need to concider a potential solution and its 1641 consequences. 1643 o Protecting a Single Flow vs. Several Flows Globally: In the 1644 general case, the various ADU flows that are globally protected 1645 can have different features, and in particular different real-time 1646 requirements (in case of real-time flows). The process of 1647 globally protecting these flows SHOULD take into account the 1648 requirements of each individual flow. In particular, it would be 1649 counter-productive to add repair traffic to a real-time flow for 1650 which the FEC decoding delay at a receiver makes decoded ADUs for 1651 this flow useless because they do not satisfy the associated real- 1652 time constraints. From a practical point of view, this means that 1653 the source block creation process at the sending FEC Framework 1654 instance, SHOULD consider the most stringent real-time 1655 requirements of the ADU flows being globally protected. 1657 o ADU Flow Bundle Definition and Flow Delivery: By design a repair 1658 flow might enable a receiver to recover the ADU flow(s) that it 1659 protects even if none of the associated FEC source packets are 1660 received. Therefore, when defining the bundle of ADU flows that 1661 are globally protected and when defining which receiver receives 1662 which flow, the repair flow(s) SHOULD only be received by 1663 receivers that are authorized to receive all the associated ADU 1664 flows. See Section 9.4 for additional recommendations for 1665 situations where a strict access control to ADU flows is needed. 1667 Additionally when multiple ADU flows are globally protected, a 1668 receiver who wants to benefit from FECFRAME loss protection SHOULD 1669 receive all the ADU flows of the bundle. Otherwise, the missing 1670 FEC source packets would be considered as lost which might 1671 significantly reduce the efficiency of the FEC scheme. 1673 11. IANA Considerations 1675 FEC schemes for use with this framework are identified in protocols 1676 using FEC Encoding IDs. Values of FEC Encoding IDs are subject to 1677 IANA registration. For this purposes, this document creates a new 1678 registry called FEC Framework (FECFRAME) FEC Encoding IDs. 1680 The values that can be assigned within the FEC Framework (FECFRAME) 1681 FEC Encoding ID registry are numeric indexes in the range (0, 255). 1682 Values of 0 and 255 are reserved. Assignment requests are granted on 1683 an IETF Consensus basis as defined in [RFC5226]. Section 5.6 defines 1684 explicit requirements that documents defining new FEC Encoding IDs 1685 should meet. 1687 12. Acknowledgments 1689 This document is based in part on [I-D.watson-tsvwg-fec-sf] and so 1690 thanks are due to the additional authors of that document, Mike Luby, 1691 Magnus Westerlund and Stephan Wenger. That document was in turn 1692 based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and 1693 thus, thanks are also due to the participants in 3GPP SA Working 1694 Group 4. Further thanks are due to the members of the FECFRAME 1695 Working Group for their comments and reviews. 1697 13. References 1699 13.1. Normative references 1701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1702 Requirement Levels", BCP 14, RFC 2119, March 1997. 1704 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1705 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1706 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1707 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1708 Compression (ROHC): Framework and four profiles: RTP, UDP, 1709 ESP, and uncompressed", RFC 3095, July 2001. 1711 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1712 Correction (FEC) Building Block", RFC 5052, August 2007. 1714 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1715 Jacobson, "RTP: A Transport Protocol for Real-Time 1716 Applications", STD 64, RFC 3550, July 2003. 1718 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1719 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1720 May 2008. 1722 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1723 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1725 13.2. Informative references 1727 [I-D.watson-tsvwg-fec-sf] 1728 Watson, M., "Forward Error Correction (FEC) Streaming 1729 Framework", draft-watson-tsvwg-fec-sf-00 (work in 1730 progress), July 2005. 1732 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 1733 Report Block Type for RTP Control Protocol (RTCP) Extended 1734 Reports (XRs)", RFC 5725, February 2010. 1736 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1737 Description Protocol", RFC 4566, July 2006. 1739 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1740 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1741 July 2006. 1743 [I-D.ietf-fecframe-sdp-elements] 1744 Begen, A., "Session Description Protocol Elements for FEC 1745 Framework", draft-ietf-fecframe-sdp-elements-11 (work in 1746 progress), October 2010. 1748 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1749 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1750 RFC 3711, March 2004. 1752 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1753 "NACK-Oriented Reliable Multicast (NORM) Transport 1754 Protocol", RFC 5740, November 2009. 1756 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1757 RFC 4303, December 2005. 1759 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1760 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1761 Real-time Transport Protocol (SRTP)", RFC 4383, 1762 February 2006. 1764 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1765 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1766 April 2010. 1768 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1769 Protocols and codecs", 3GPP TS 26.346, April 2005. 1771 Authors' Addresses 1773 Mark Watson 1774 Netflix, Inc. 1775 100 Winchester Circle 1776 Los Gatos, CA 95032 1777 USA 1779 Email: watsonm@netflix.com 1781 Ali Begen 1782 Cisco 1783 181 Bay Street 1784 Toronto, ON M5J 2T3 1785 Canada 1787 Email: abegen@cisco.com 1789 Vincent Roca 1790 INRIA 1791 655, av. de l'Europe 1792 Inovallee; Montbonnot 1793 ST ISMIER cedex 38334 1794 France 1796 Email: vincent.roca@inria.fr 1797 URI: http://planete.inrialpes.fr/people/roca/