idnits 2.17.1 draft-ietf-fecframe-framework-12.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 (January 18, 2011) is 4845 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: July 22, 2011 Cisco 6 V. Roca 7 INRIA 8 January 18, 2011 10 Forward Error Correction (FEC) Framework 11 draft-ietf-fecframe-framework-12 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 July 22, 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 . . . . 23 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 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 106 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 108 13.1. Normative references . . . . . . . . . . . . . . . . . . . 43 109 13.2. Informative references . . . . . . . . . . . . . . . . . . 43 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 112 1. Introduction 114 Many applications have a requirement to transport a continuous stream 115 of packetized data from a source (sender) to one or more destinations 116 (receivers) over networks which do not provide guaranteed packet 117 delivery. Primary examples are real-time, or streaming, media 118 applications such as broadcast, multicast or on-demand audio, video 119 or multimedia. 121 Forward Error Correction (FEC) is a well-known technique for 122 improving reliability of packet transmission over networks which do 123 not provide guaranteed packet delivery, especially in multicast and 124 broadcast applications. The FEC Building Block defined in [RFC5052] 125 provides a framework for definition of Content Delivery Protocols 126 (CDPs) for object delivery (including, primarily, file delivery) 127 which make use of separately defined FEC schemes. Any CDP defined 128 according to the requirements of the FEC Building Block can then 129 easily be used with any FEC scheme which is also defined according to 130 the requirements of the FEC Building Block. 132 Note that the term "Forward Erasure Correction" is sometimes used, 133 erasures being a type of error in which data is lost and this loss 134 can be detected, rather than being received in corrupted form. The 135 focus of this document is strictly on erasures and, the term "Forward 136 Error Correction" is more widely used. 138 This document defines a framework for the definition of CDPs which 139 provide for FEC protection for arbitrary packet flows over unreliable 140 transports such as UDP. As such, this document complements the FEC 141 Building Block of [RFC5052], by providing for the case of arbitrary 142 packet flows over unreliable transport, the same kind of framework as 143 that document provides for object delivery. This document does not 144 define a complete CDP, but rather defines only those aspects that are 145 expected to be common to all CDPs based on this framework. 147 This framework does not define how the flows to be protected are 148 determined, nor how the details of the protected flows and the FEC 149 streams which protect them are communicated from sender to receiver. 150 It is expected that any complete CDP specification which makes use of 151 this framework will address these signaling requirements. However, 152 this document does specify the information which is required by the 153 FEC Framework at the sender and receiver, e.g., details of the flows 154 to be FEC protected, the flow(s) that will carry the FEC protection 155 data and an opaque container for FEC-Scheme-Specific Information. 157 FEC schemes designed for use with this framework must fulfill a 158 number of requirements defined in this document. These requirements 159 are different from those defined in [RFC5052] for FEC schemes for 160 object delivery. However, there is a great deal of commonality and 161 FEC schemes defined for object delivery may be easily adapted for use 162 with the framework defined in this document. 164 Since the RTP protocol is (often) used over UDP, this framework can 165 be applied to RTP flows as well. FEC repair packets may be sent 166 directly over UDP or RTP. The latter approach has the advantage that 167 RTP instrumentation, based on RTP Control Protocol (RTCP), can be 168 used for the repair flow. Additionally, the post-repair RTCP 169 extended reports [RFC5725] may be used to obtain information about 170 the loss rate after FEC recovery. 172 The use of RTP for repair flows is defined for each FEC scheme by 173 defining an RTP payload format for that particular FEC scheme 174 (possibly in the same document). 176 2. Definitions and Abbreviations 178 Application Data Unit (ADU): The unit of source data provided as 179 payload to the transport layer. 181 ADU Flow: A sequence of ADUs associated with a transport-layer flow 182 identifier (such as the standard 5-tuple {Source IP address, source 183 port, destination IP address, destination port, transport protocol}). 185 AL-FEC: Application-layer Forward Error Correction. 187 Application Protocol: Control protocol used to establish and control 188 the source flow being protected, e.g., RTSP. 190 Content Delivery Protocol (CDP): A complete application protocol 191 specification which, through the use of the framework defined in this 192 document, is able to make use of FEC schemes to provide FEC 193 capabilities. 195 FEC Code: An algorithm for encoding data such that the encoded data 196 flow is resilient to data loss. Note that in general FEC codes may 197 also be used to make a data flow resilient to corruption, but that is 198 not considered in this document. 200 FEC Framework: A protocol framework for definition of Content 201 Delivery Protocols using FEC, such as the framework defined in this 202 document. 204 FEC Framework Configuration Information: Information which controls 205 the operation of the FEC Framework. 207 FEC Payload ID: Information which identifies the contents of a packet 208 with respect to the FEC scheme. 210 FEC Repair Packet: At a sender (respectively, at a receiver) a 211 payload submitted to (respectively, received from) the transport 212 protocol containing one or more repair symbols along with a Repair 213 FEC Payload ID and possibly an RTP header. 215 FEC Scheme: A specification which defines the additional protocol 216 aspects required to use a particular FEC code with the FEC Framework. 218 FEC Source Packet: At a sender (respectively, at a receiver) a 219 payload submitted to (respectively, received from) the transport 220 protocol containing an ADU along with an optional Explicit Source FEC 221 Payload ID. 223 Protection Amount: The relative increase in data sent due to the use 224 of FEC. 226 Repair Flow: The packet flow carrying FEC data. 228 Repair FEC Payload ID: An FEC Payload ID specifically for use with 229 repair packets. 231 Source Flow: The packet flow to which FEC protection is to be 232 applied. A source flow consists of ADUs. 234 Source FEC Payload ID: An FEC Payload ID specifically for use with 235 source packets. 237 Source Protocol: A protocol used for the source flow being protected, 238 e.g., RTP. 240 Transport Protocol: The protocol used for transport of the source and 241 repair flows, e.g., UDP and DCCP. 243 The following definitions are aligned with [RFC5052]: 245 Code Rate: The ratio between the number of source symbols and the 246 number of encoding symbols. By definition, the code rate is such 247 that 0 < code rate <= 1. A code rate close to 1 indicates that a 248 small number of repair symbols have been produced during the encoding 249 process. 251 Encoding Symbol: Unit of data generated by the encoding process. 252 With systematic codes, source symbols are part of the encoding 253 symbols. 255 Packet Erasure Channel: A communication path where packets are either 256 dropped (e.g., by a congested router, or because the number of 257 transmission errors exceeds the correction capabilities of the 258 physical-layer codes) or received. When a packet is received, it is 259 assumed that this packet is not corrupted. 261 Repair Symbol: Encoding symbol that is not a source symbol. 263 Source Block: Group of ADUs which are to be FEC protected as a single 264 block. 266 Source Symbol: Unit of data used during the encoding process. 268 Systematic Code: FEC code in which the source symbols are part of the 269 encoding symbols. 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 273 document are to be interpreted as described in [RFC2119]. 275 3. Architecture Overview 277 The FEC Framework is described in terms of an additional layer 278 between the transport layer (e.g., UDP or DCCP) and protocols running 279 over this transport layer. As such, the data path interface between 280 the FEC Framework and both underlying and overlying layers can be 281 thought of as being the same as the standard interface to the 282 transport layer, i.e., the data exchanged consists of datagram 283 payloads each associated with a single ADU flow identified by the 284 standard 5-tuple {Source IP address, source port, destination IP 285 address, destination port, transport protocol}. In the case that RTP 286 is used for the repair flows, the source and repair data can be 287 multiplexed using RTP onto a single UDP flow and needs to be 288 consequently demultiplexed at the receiver. There are various ways 289 in which this multiplexing can be done, for example as described in 290 [RFC4588]. 292 It is important to understand that the main purpose of the FEC 293 Framework architecture is to allocate functional responsibilities to 294 separately documented components in such a way that specific 295 instances of the components can be combined in different ways to 296 describe different protocols. 298 The FEC Framework makes use of an FEC scheme, in a similar sense to 299 that defined in [RFC5052] and uses the terminology of that document. 300 The FEC scheme defines the FEC encoding and decoding, and defines the 301 protocol fields and procedures used to identify packet payload data 302 in the context of the FEC scheme. The interface between the FEC 303 Framework and an FEC scheme, which is described in this document, is 304 a logical one, which exists for specification purposes only. At an 305 encoder, the FEC Framework passes ADUs to the FEC scheme for FEC 306 encoding. The FEC scheme returns repair symbols with their 307 associated Repair FEC Payload IDs, and in some cases Source FEC 308 Payload IDs, depending on the FEC scheme. At a decoder, the FEC 309 Framework passes transport packet payloads (source and repair) to the 310 FEC scheme and the FEC scheme returns additional recovered source 311 packet payloads. 313 This document defines certain FEC Framework Configuration Information 314 which MUST be available to both sender and receiver(s). For example, 315 this information includes the specification of the ADU flows which 316 are to be FEC protected, specification of the ADU flow(s) which will 317 carry the FEC protection (repair) data and the relationship(s) 318 between these source and repair flows (i.e., which source flow(s) are 319 protected by each repair flow(s)). The FEC Framework Configuration 320 Information also includes information fields which are specific to 321 the FEC scheme. This information is analogous to the FEC Object 322 Transmission Information defined in [RFC5052]. 324 The FEC Framework does not define how the FEC Framework Configuration 325 Information for the stream is communicated from sender to receiver. 326 This has to be defined by any CDP specification as described in the 327 following sections. 329 In this architecture we assume that the interface to the transport 330 layer supports the concepts of data units (referred to here as 331 Application Data Units (ADUs)) to be transported and identification 332 of ADU flows on which those data units are transported. Since this 333 is an interface internal to the architecture, we do not specify this 334 interface explicitly. We do require that ADU flows which are 335 distinct from the transport layer point of view (for example, 336 distinct UDP flows as identified by the UDP source/destination 337 addresses/ports) are also distinct on the interface between the 338 transport layer and the FEC Framework. 340 As noted above, RTP flows are a specific example of ADU flows which 341 might be protected by the FEC Framework. From the FEC Framework 342 point of view, RTP source flows are ADU flows like any other, with 343 the RTP header included within the ADU. 345 Depending on the FEC scheme, RTP can also be used as a transport for 346 repair packet flows. In this case an FEC scheme has to define an RTP 347 payload format for the repair data. 349 The architecture outlined above is illustrated in the Figure 1. In 350 this architecture, two (optional) RTP instances are shown, for the 351 source and repair data respectively. This is because the use of RTP 352 for the source data is separate from and independent of the use of 353 RTP for the repair data. The appearance of two RTP instances is more 354 natural when one considers that in many FEC codes, the repair payload 355 contains repair data calculated across the RTP headers of the source 356 packets. Thus, a repair packet carried over RTP starts with an RTP 357 header of its own which is followed (after the Repair Payload ID) by 358 repair data containing bytes which protect the source RTP headers (as 359 well as repair data for the source RTP payloads). 361 +--------------------------------------------+ 362 | Application | 363 +--------------------------------------------+ 364 | 365 | 366 | 367 + - - - - - - - - - - - - - - - - - - - - - - - -+ 368 | +--------------------------------------------+ | 369 | Application Layer | 370 | +--------------------------------------------+ | 371 | | 372 | + -- -- -- -- -- -- -- -- -- -- --+ | | 373 | RTP (Optional) | | 374 | | | |- Configuration/Coordination 375 +- -- -- -- -- -- -- -- -- -- -- -+ | 376 | | | | 377 | ADU flows | 378 | | v | 379 +--------------------------------------------+ +----------------+ 380 | | FEC Framework (This document) |<--->| FEC Scheme | 381 +--------------------------------------------+ +----------------+ 382 | | | | 383 Source | Repair | 384 | | | | 385 +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ 386 | | RTP Layer | | RTP Processing | | | 387 | (Optional) | +-- -- -- |- -- -+ | 388 | | +-- -- -- -- -- -- -- |--+ | | 389 | | RTP (De)multiplexing | | 390 | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | 391 | 392 | +--------------------------------------------+ | 393 | Transport Layer (e.g., UDP) | 394 | +--------------------------------------------+ | 395 | 396 | +--------------------------------------------+ | 397 | IP | 398 | +--------------------------------------------+ | 400 | Content Delivery Protocol | 401 + - - - - - - - - - - - - - - - - - - - - - - - + 403 Figure 1: FEC Framework architecture 405 The content of the transport payload for repair packets is fully 406 defined by the FEC scheme. For a specific FEC scheme, a means MAY be 407 defined for repair data to be carried over RTP, in which case the 408 repair packet payload format starts with the RTP header. This 409 corresponds to defining an RTP payload format for the specific FEC 410 scheme. 412 The use of RTP for repair packets is independent of the protocols 413 used for source packets: if RTP is used for source packets, repair 414 packets may or may not use RTP and vice versa (although it is 415 unlikely that there are useful scenarios where non-RTP source flows 416 are protected by RTP repair flows). FEC schemes are expected to 417 recover entire transport payloads for recovered source packets in all 418 cases. For example, if RTP is used for source flows, the FEC scheme 419 is expected to recover the entire UDP payload, including the RTP 420 header. 422 4. Procedural Overview 424 4.1. General 426 The mechanism defined in this document does not place any 427 restrictions on the ADUs which can be protected together, except that 428 the ADU is carried over a supported transport protocol (See 429 Section 7). The data can be from multiple source flows that are 430 protected jointly. The FEC Framework handles the source flows as a 431 sequence of source blocks each consisting of a set of ADUs, possibly 432 from multiple source flows which are to be protected together. For 433 example, each source block can be constructed from those ADUs related 434 to a particular segment in time of the flow. 436 At the sender, the FEC Framework passes the payloads for a given 437 block to the FEC scheme for FEC encoding. The FEC scheme performs 438 the FEC encoding operation and returns the following information: 440 o Optionally, FEC Payload IDs for each of the source payloads 441 (encoded according to an FEC-Scheme-Specific format). 443 o One or more FEC repair packet payloads. 445 o FEC Payload IDs for each of the repair packet payloads (encoded 446 according to an FEC-Scheme-Specific format). 448 The FEC Framework then performs two operations. First, it appends 449 the Source FEC Payload IDs, if provided, to each of the ADUs, and 450 sends the resulting packets, known as FEC source packets, to the 451 receiver, and second it places the provided FEC repair packet 452 payloads and corresponding Repair FEC Payload IDs appropriately to 453 construct FEC repair packets and send them to the receiver. 455 This document does not define how the sender determines which ADUs 456 are included in which source blocks or the sending order and timing 457 of FEC source and repair packets. A specific CDP MAY define this 458 mapping or it MAY be left as implementation dependent at the sender. 459 However, a CDP specification MUST define how a receiver determines a 460 minimum length of time that it needs to wait to receive FEC repair 461 packets for any given source block. FEC schemes MAY define 462 limitations on this mapping, such as maximum size of source blocks, 463 but SHOULD NOT attempt to define specific mappings. The sequence of 464 operations at the sender is described in more detail in Section 4.2. 466 At the receiver, original ADUs are recovered by the FEC Framework 467 directly from any FEC source packets received simply by removing the 468 Source FEC Payload ID, if present. The receiver also passes the 469 contents of the received ADUs, plus their FEC Payload IDs to the FEC 470 scheme for possible decoding. 472 If any ADUs related to a given source block have been lost, then the 473 FEC scheme can perform FEC decoding to recover the missing ADUs 474 (assuming sufficient FEC source and repair packets related to that 475 source block have been received). 477 Note that the receiver might need to buffer received source packets 478 to allow time for the FEC repair packets to arrive and FEC decoding 479 to be performed before some or all of the received or recovered 480 packets are passed to the application. If such a buffer is not 481 provided, then the application has to be able to deal with the severe 482 re-ordering of packets that can occur. However, such buffering is 483 CDP and/or implementation-specific and is not specified here. The 484 receiver operation is described in more detail in Section 4.3. 486 The FEC source packets MUST contain information which identifies the 487 source block and the position within the source block (in terms 488 specific to the FEC scheme) occupied by the ADU. This information is 489 known as the Source FEC Payload ID. The FEC scheme is responsible 490 for defining and interpreting this information. This information MAY 491 be encoded into a specific field within the FEC source packet format 492 defined in this specification, called the Explicit Source FEC Payload 493 ID field. The exact contents and format of the Explicit Source FEC 494 Payload ID field are defined by the FEC schemes. Alternatively, the 495 FEC scheme MAY define how the Source FEC Payload ID is derived from 496 other fields within the source packets. This document defines the 497 way that the Explicit Source FEC Payload ID field is appended to 498 source packets to form FEC source packets. 500 The FEC repair packets MUST contain information which identifies the 501 source block and the relationship between the contained repair 502 payloads and the original source block. This is known as the Repair 503 FEC Payload ID. This information MUST be encoded into a specific 504 field, the Repair FEC Payload ID field, the contents and format of 505 which are defined by the FEC schemes. 507 The FEC scheme MAY use different FEC Payload ID field formats for 508 source and repair packets. 510 4.2. Sender Operation 512 It is assumed that the sender has constructed or received original 513 data packets for the session. These could be carrying any type of 514 data. The following operations, illustrated in Figure 2, for the 515 case of UDP repair flows and Figure 3 for the case of RTP repair 516 flows, describe a possible way to generate compliant source and 517 repair flows: 519 1. ADUs are provided by the application. 521 2. A source block is constructed as specified in Section 5.2. 523 3. The source block is passed to the FEC scheme for FEC encoding. 524 The Source FEC Payload ID information of each source packet is 525 determined by the FEC scheme. If required by the FEC scheme the 526 Source FEC Payload ID is encoded into the Explicit Source FEC 527 Payload ID field. 529 4. The FEC scheme performs FEC encoding, generating repair packet 530 payloads from a source block and a Repair FEC Payload ID field 531 for each repair payload. 533 5. The Explicit Source FEC Payload IDs (if used), Repair FEC Payload 534 IDs and repair packet payloads are provided back from the FEC 535 scheme to the FEC Framework. 537 6. The FEC Framework constructs FEC source packets according to 538 Section 5.3 and FEC repair packets according to Section 5.4 using 539 the FEC Payload IDs and repair packet payloads provided by the 540 FEC scheme. 542 7. The FEC source and repair packets are sent using normal 543 transport-layer procedures. The port(s) and multicast group(s) 544 to be used for FEC repair packets are defined in the FEC 545 Framework Configuration Information. The FEC source packets are 546 sent using the same ADU flow identification information as would 547 have been used for the original source packets if the FEC 548 Framework were not present (for example, in the UDP case, the UDP 549 source and destination addresses and ports on the IP datagram 550 carrying the source packet will be the same whether or not the 551 FEC Framework is applied). 553 +----------------------+ 554 | Application | 555 +----------------------+ 556 | 557 |(1) ADUs 558 | 559 v 560 +----------------------+ +------------------+ 561 | FEC Framework | | | 562 | |-------------------------->| FEC Scheme | 563 |(2) Construct source |(3) Source Block | | 564 | blocks | | (4) FEC Encoding | 565 |(6) Construct FEC |<--------------------------| | 566 | source and repair | | | 567 | packets |(5) Explicit Source FEC | | 568 +----------------------+ Payload IDs +------------------+ 569 | Repair FEC Payload IDs 570 | Repair symbols 571 | 572 |(7) FEC source and repair packets 573 v 574 +----------------------+ 575 | Transport Layer | 576 | (e.g., UDP) | 577 +----------------------+ 579 Figure 2: Sender operation 581 +----------------------+ 582 | Application | 583 +----------------------+ 584 | 585 |(1) ADUs 586 | 587 v 588 +----------------------+ +------------------+ 589 | FEC Framework | | | 590 | |-------------------------->| FEC Scheme | 591 |(2) Construct source |(3) Source Block | | 592 | blocks | | (4) FEC Encoding | 593 |(6) Construct FEC |<--------------------------| | 594 | source packets and| | | 595 | repair payloads |(5) Explicit Source FEC | | 596 +----------------------+ Payload IDs +------------------+ 597 | | Repair FEC Payload IDs 598 | | Repair symbols 599 | | 600 |(7) Source |(7') Repair payloads 601 | packets | 602 | | 603 | + -- -- -- -- -+ 604 | | RTP | 605 | +-- -- -- -- --+ 606 v v 607 +----------------------+ 608 | Transport Layer | 609 | (e.g., UDP) | 610 +----------------------+ 612 Figure 3: Sender operation with RTP repair flows 614 4.3. Receiver Operation 616 The following describes a possible receiver algorithm, illustrated in 617 Figure 4 and Figure 5 for the case of RTP repair flows, when 618 receiving an FEC source or repair packet: 620 1. FEC source packets and FEC repair packets are received and passed 621 to the FEC Framework. The type of packet (source or repair) and 622 the source flow to which it belongs (in the case of source 623 packets) is indicated by the ADU flow information which 624 identifies the flow at the transport layer. 626 In the special case that RTP is used for repair packets, and 627 source and repair packets are multiplexed onto the same UDP flow, 628 then RTP demultiplexing is required to demultiplex source and 629 repair flows. However, RTP processing is applied only to the 630 repair packets at this stage; source packets continue to be 631 handled as UDP payloads (i.e., including their RTP headers). 633 2. The FEC Framework extracts the Explicit Source FEC Payload ID 634 field (if present) from the source packets and the Repair FEC 635 Payload ID from the repair packets. 637 3. The Explicit Source FEC Payload IDs (if present), Repair FEC 638 Payload IDs, FEC source and repair payloads are passed to the FEC 639 scheme. 641 4. The FEC scheme uses the received FEC Payload IDs (and derived FEC 642 Source Payload IDs in the case that the Explicit Source FEC 643 Payload ID field is not used) to group source and repair packets 644 into source blocks. If at least one source packet is missing 645 from a source block, and at least one repair packet has been 646 received for the same source block then FEC decoding can be 647 performed in order to recover missing source payloads. The FEC 648 scheme determines whether source packets have been lost and 649 whether enough data for decoding of any or all of the missing 650 source payloads in the source block has been received. 652 5. The FEC scheme returns the ADUs to the FEC Framework in the form 653 of source blocks containing received and decoded ADUs and 654 indications of any ADUs which were missing and could not be 655 decoded. 657 6. The FEC Framework passes the received and recovered ADUs to the 658 application. 660 The description above defines functionality responsibilities but does 661 not imply a specific set of timing relationships. Source packets 662 which are correctly received and those which are reconstructed MAY be 663 delivered to the application out of order and in a different order 664 from the order of arrival at the receiver. Alternatively, buffering 665 and packet re-ordering MAY be applied to re-order received and 666 reconstructed source packets into the order they were placed into the 667 source block, if that is necessary according to the application. 669 +----------------------+ 670 | Application | 671 +----------------------+ 672 ^ 673 | 674 |(6) ADUs 675 | 676 +----------------------+ +------------------+ 677 | FEC Framework | | | 678 | |<---------------------------| FEC Scheme | 679 |(2)Extract FEC Payload|(5) ADUs | | 680 | IDs and pass IDs & | | (4) FEC Decoding | 681 | payloads to FEC |--------------------------->| | 682 | scheme |(3) Explicit Source FEC | | 683 +----------------------+ Payload IDs +------------------+ 684 ^ Repair FEC Payload IDs 685 | Source payloads 686 | Repair payloads 687 | 688 |(1) FEC source and repair packets 689 | 690 +----------------------+ 691 | Transport Layer | 692 | (e.g., UDP) | 693 +----------------------+ 695 Figure 4: Receiver operation 697 +----------------------+ 698 | Application | 699 +----------------------+ 700 ^ 701 | 702 |(6) ADUs 703 | 704 +----------------------+ +------------------+ 705 | FEC Framework | | | 706 | |<---------------------------| FEC Scheme | 707 |(2)Extract FEC Payload|(5) ADUs | | 708 | IDs and pass IDs & | | (4) FEC Decoding | 709 | payloads to FEC |--------------------------->| | 710 | scheme |(3) Explicit Source FEC | | 711 +----------------------+ Payload IDs +------------------+ 712 ^ ^ Repair FEC Payload IDs 713 | | Source payloads 714 | | Repair payloads 715 | | 716 |Source |Repair payloads 717 |packets | 718 | | 719 +-- |- -- -- -- -- -- -+ 720 |RTP| | RTP Processing | 721 | | +-- -- -- --|-- -+ 722 | +-- -- -- -- -- |--+ | 723 | | RTP Demux | | 724 +-- -- -- -- -- -- -- -+ 725 ^ 726 |(1) FEC source and repair packets 727 | 728 +----------------------+ 729 | Transport Layer | 730 | (e.g., UDP) | 731 +----------------------+ 733 Figure 5: Receiver operation with RTP repair flows 735 Note that the above procedure might result in a situation in which 736 not all ADUs are recovered. 738 5. Protocol Specification 740 5.1. General 742 This section specifies the protocol elements for the FEC Framework. 743 Three components of the protocol are defined in this document and are 744 described in the following sections: 746 1. Construction of a source block from ADUs. The FEC code will be 747 applied to this source block to produce the repair payloads. 749 2. A format for packets containing source data. 751 3. A format for packets containing repair data. 753 The operation of the FEC Framework is governed by certain FEC 754 Framework Configuration Information, which is defined in this 755 section. A complete protocol specification that uses this framework 756 MUST specify the means to determine and communicate this information 757 between sender and receiver. 759 5.2. Structure of the Source Block 761 The FEC Framework and FEC scheme exchange ADUs in the form of source 762 blocks. A source block is generated by the FEC Framework from an 763 ordered sequence of ADUs. The allocation of ADUs to blocks is 764 dependent on the application. Note that some ADUs may not be 765 included in any block. Each source block provided to the FEC scheme 766 consists of an ordered sequence of ADUs where the following 767 information is provided for each ADU: 769 o A description of the source flow with which the ADU is associated 770 with. 772 o The ADU itself. 774 o The length of the ADU. 776 5.3. Packet Format for FEC Source Packets 778 The packet format for FEC source packets MUST be used to transport 779 the payload of an original source packet. As depicted in Figure 6, 780 it consists of the original packet, optionally followed by the 781 Explicit Source FEC Payload ID field. The FEC scheme determines 782 whether the Explicit Source FEC Payload ID field is required. This 783 determination is specific to each ADU flow. 785 +------------------------------------+ 786 | IP Header | 787 +------------------------------------+ 788 | Transport Header | 789 +------------------------------------+ 790 | Application Data Unit | 791 +------------------------------------+ 792 | Explicit Source FEC Payload ID | 793 +------------------------------------+ 795 Figure 6: Structure of the FEC packet format for FEC source packets 797 The FEC source packets MUST be sent using the same ADU flow as would 798 have been used for the original source packets if the FEC Framework 799 were not present. The transport payload of the FEC source packet 800 MUST consist of the ADU followed by the Explicit Source FEC Payload 801 ID field, if required. 803 The Explicit Source FEC Payload ID field contains information 804 required to associate the source packet with a source block and for 805 the operation of the FEC algorithm, and is defined by the FEC scheme. 806 The format of the Source FEC Payload ID field is defined by the FEC 807 scheme. In the case that the FEC scheme or CDP defines a means to 808 derive the Source FEC Payload ID from other information in the packet 809 (for example a sequence number used by the application protocol), 810 then the Source FEC Payload ID field is not included in the packet. 811 In this case, the original source packet and FEC source packet are 812 identical. 814 In applications where avoidance of IP packet fragmentation is a goal, 815 CDPs SHOULD consider the Explicit Source FEC Payload ID size when 816 determining the size of ADUs that will be delivered using the FEC 817 Framework. This is because the addition of the Explicit Source FEC 818 Payload ID increases the packet length. 820 The Explicit Source FEC Payload ID is placed at the end of the packet 821 so that in the case that Robust Header Compression (ROHC) [RFC3095] 822 or other header compression mechanisms are used and in the case that 823 a ROHC profile is defined for the protocol carried within the 824 transport payload (for example RTP), then ROHC will still be applied 825 for the FEC source packets. Applications that are used with this 826 framework need to consider that FEC schemes can add this Explicit 827 Source FEC Payload ID and thereby increase the packet size. 829 In many applications, support for FEC is added to a pre-existing 830 protocol and in this case use of the Explicit Source FEC Payload ID 831 can break backwards compatibility, since source packets are modified. 833 5.3.1. Generic Explicit Source FEC Payload ID 835 In order to apply FEC protection using multiple FEC schemes to a 836 single source flow, all schemes have to use the same Explicit Source 837 FEC Payload ID format. In order to enable this, it is RECOMMENDED 838 that FEC schemes support the Generic Explicit Source FEC Payload ID 839 format described below. 841 The Generic Explicit Source FEC Payload ID has a length of two octets 842 and consists of an unsigned packet sequence number in network-byte 843 order. The allocation of sequence numbers to packets is independent 844 of any FEC scheme and of the source block construction, except that 845 the use of this sequence number places a constraint on source block 846 construction. Source packets within a given source block MUST have 847 consecutive sequence numbers (where consecutive includes wrap-around 848 from the maximum value which can be represented in two octets (65535) 849 to 0). Sequence numbers SHOULD NOT be reused until all values in the 850 sequence number space have been used. 852 5.4. Packet Format for FEC Repair Packets 854 The packet format for FEC repair packets is shown in Figure 7. The 855 transport payload consists of a Repair FEC Payload ID field followed 856 by repair data generated in the FEC encoding process. 858 +------------------------------------+ 859 | IP Header | 860 +------------------------------------+ 861 | Transport Header | 862 +------------------------------------+ 863 | Repair FEC Payload ID | 864 +------------------------------------+ 865 | Repair Symbols | 866 +------------------------------------+ 868 Figure 7: Packet format for repair packets 870 The Repair FEC Payload ID field contains information required for the 871 operation of the FEC algorithm at the receiver. This information is 872 defined by the FEC scheme. The format of the Repair FEC Payload ID 873 field is defined by the FEC scheme. 875 5.4.1. Packet Format for FEC Repair Packets over RTP 877 For FEC schemes which specify the use of RTP for repair packets, the 878 packet format for repair packets includes an RTP header as shown in 879 Figure 8. 881 +------------------------------------+ 882 | IP header | 883 +------------------------------------+ 884 | Transport Header (UDP) | 885 +------------------------------------+ 886 | RTP Header | 887 +------------------------------------+ 888 | Repair FEC Payload ID | 889 +------------------------------------+ 890 | Repair Symbols | 891 +------------------------------------+ 893 Figure 8: Packet format for repair packets 895 5.5. FEC Framework Configuration Information 897 The FEC Framework Configuration Information is information that the 898 FEC Framework needs in order to apply FEC protection to the ADU 899 flows. A complete CDP specification that uses the framework 900 specified here MUST include details of how this information is 901 derived and communicated between sender and receiver. 903 The FEC Framework Configuration Information includes identification 904 of the set of source flows. For example, in the case of UDP, each 905 source flow is uniquely identified by a tuple {Source IP address, 906 source UDP port, destination IP address, destination UDP port}. In 907 some applications some of these fields can contain wildcards, so that 908 the flow is identified by a subset of the fields. In particular, in 909 many applications the limited tuple {Destination IP address, 910 destination UDP port} is sufficient. 912 A single instance of the FEC Framework provides FEC protection for 913 packets of the specified set of source flows, by means of one or more 914 packet flows consisting of repair packets. The FEC Framework 915 Configuration Information includes, for each instance of the FEC 916 Framework: 918 1. Identification of the repair flows. 920 2. For each source flow protected by the repair flow(s): 922 A. Definition of the source flow. 924 B. An integer identifier for this flow definition (i.e., tuple). 925 This identifier MUST be unique amongst all source flows that 926 are protected by the same FEC repair flow. Integer 927 identifiers can be allocated starting from zero and 928 increasing by one for each flow. However, any random (but 929 still unique) allocation is also possible. A source flow 930 identifier need not be carried in source packets since source 931 packets are directly associated with a flow by virtue of 932 their packet headers. 934 3. The FEC Encoding ID, identifying the FEC scheme. 936 4. The length of the Explicit Source FEC Payload ID (in octets). 938 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, 939 each consisting of a name and a value where the valid element 940 names and value ranges are defined by the FEC scheme. 942 Multiple instances of the FEC Framework, with separate and 943 independent FEC Framework Configuration Information, can be present 944 at a sender or receiver. A single instance of the FEC Framework 945 protects packets of the source flows identified in (2) above, i.e., 946 all packets sent on those flows MUST be FEC source packets as defined 947 in Section 5.3. A single source flow can be protected by multiple 948 instances of the FEC Framework. 950 The integer flow identifier identified in (2b) above is a shorthand 951 to identify source flows between the FEC Framework and the FEC 952 scheme. The reason for defining this as an integer, and including it 953 in the FEC Framework Configuration Information is so that the FEC 954 scheme at the sender and receiver can use it to identify the source 955 flow with which a recovered packet is associated. The integer flow 956 identifier can therefore take the place of the complete flow 957 description (e.g., UDP 4-tuple). 959 Whether and how this flow identifier is used is defined by the FEC 960 scheme. Since repair packets can provide protection for multiple 961 source flows, repair packets would either not carry the identifier at 962 all or can carry multiple identifiers. However, in any case, the 963 flow identifier associated with a particular source packet can be 964 recovered from the repair packets as part of an FEC decoding 965 operation. 967 A single FEC repair flow provides repair packets for a single 968 instance of the FEC Framework. Other packets MUST NOT be sent within 969 this flow, i.e., all packets in the FEC repair flow MUST be FEC 970 repair packets as defined in Section 5.4 and MUST relate to the same 971 FEC Framework instance. 973 In the case that RTP is used for repair packets, the identification 974 of the repair packet flow can also include the RTP payload type to be 975 used for repair packets. 977 FSSI includes the information that is specific to the FEC scheme used 978 by the CDP. FSSI is used to communicate the information that cannot 979 be adequately represented otherwise and is essential for proper FEC 980 encoding and decoding operations. The motivation behind separating 981 the FSSI required only by the sender (which is carried in Sender-Side 982 FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of 983 the FSSI is to provide the receiver or the third party entities a 984 means of controlling the FEC operations at the sender. Any FSSI 985 other than the one solely required by the sender MUST be communicated 986 via the FSSI container. 988 The variable-length SS-FSSI and FSSI containers transmit the 989 information in textual representation and contain zero or more 990 distinct elements, whose descriptions are provided by the fully- 991 specified FEC schemes. 993 For the CDPs that choose the Session Description Protocol (SDP) 994 [RFC4566] as their session description protocol, the ABNF [RFC5234] 995 syntax for the SS-FSSI and FSSI containers is provided in Section 4.5 996 of [I-D.ietf-fecframe-sdp-elements]. 998 5.6. FEC Scheme Requirements 1000 In order to be used with this framework, an FEC scheme MUST be 1001 capable of processing data arranged into blocks of ADUs (source 1002 blocks). 1004 A specification for a new FEC scheme MUST include the following: 1006 1. The FEC Encoding ID value that uniquely identifies the FEC 1007 scheme. This value MUST be registered with IANA as described in 1008 Section 11. 1010 2. The type, semantics and encoding format of the Repair FEC Payload 1011 ID. 1013 3. The name, type, semantics and text value encoding rules for zero 1014 or more FEC-Scheme-Specific Information elements. 1016 4. A full specification of the FEC code. 1018 This specification MUST precisely define the valid FEC-Scheme- 1019 Specific Information values, the valid FEC Payload ID values and 1020 the valid packet payload sizes (where packet payload refers to 1021 the space within a packet dedicated to carrying encoding 1022 symbols). 1024 Furthermore, given a source block as defined in Section 5.2, 1025 valid values of the FEC-Scheme-Specific Information, a valid 1026 Repair FEC Payload ID value and a valid packet payload size, the 1027 specification MUST uniquely define the values of the encoding 1028 symbols to be included in the repair packet payload of a packet 1029 with the given Repair FEC Payload ID value. 1031 A common and simple way to specify the FEC code to the required 1032 level of detail is to provide a precise specification of an 1033 encoding algorithm which, given a source block, valid values of 1034 the FEC-Scheme-Specific Information, a valid Repair FEC Payload 1035 ID value and a valid packet payload size as input produces the 1036 exact value of the encoding symbols as output. 1038 5. A description of practical encoding and decoding algorithms. 1040 This description need not be to the same level of detail as for 1041 the encoding above, however it has to be sufficient to 1042 demonstrate that encoding and decoding of the code is both 1043 possible and practical. 1045 FEC scheme specifications MAY additionally define the following: 1047 1. Type, semantics and encoding format of an Explicit Source FEC 1048 Payload ID. 1050 Whenever an FEC scheme specification defines an 'encoding format' for 1051 an element, this has to be defined in terms of a sequence of bytes 1052 which can be embedded within a protocol. The length of the encoding 1053 format MUST either be fixed or it MUST be possible to derive the 1054 length from examining the encoded bytes themselves. For example, the 1055 initial bytes can include some kind of length indication. 1057 FEC scheme specifications SHOULD use the terminology defined in this 1058 document and SHOULD follow the following format: 1060 1. Introduction 1063 2. Formats and Codes 1065 2.1 Source FEC Payload ID(s) 1069 2.2 Repair FEC Payload ID 1072 2.3 FEC Framework Configuration Information 1076 3. Procedures 1080 4. FEC Code Specification 1083 Specifications can include additional sections including examples. 1085 Each FEC scheme MUST be specified independently of all other FEC 1086 schemes; for example, in a separate specification or a completely 1087 independent section of larger specification (except, of course, a 1088 specification of one FEC scheme can include portions of another by 1089 reference). Where an RTP Payload Format is defined for repair data 1090 for a specific FEC scheme, the RTP Payload Format and the FEC scheme 1091 can be specified within the same document. 1093 6. Feedback 1095 Many applications require some kind of feedback on transport 1096 performance. E.g., how much data arrived at the receiver, at what 1097 rate and when? When FEC is added to such applications, feedback 1098 mechanisms can also need to be enhanced to report on the performance 1099 of the FEC. E.g., how much lost data was recovered by the FEC? 1101 When used to provide instrumentation for engineering purposes, it is 1102 important to remember that FEC is generally applied to relatively 1103 small blocks of data (in the sense that each block is transmitted 1104 over a relatively small period of time). Thus, feedback information 1105 that is averaged over longer periods of time will likely not provide 1106 sufficient information for engineering purposes. More detailed 1107 feedback over shorter time scales might be preferred. For example, 1108 for applications using RTP transport, see [RFC5725]. 1110 Applications which used feedback for congestion control purposes MUST 1111 calculate such feedback on the basis of packets received before FEC 1112 recovery is applied. If this requirement conflicts with other uses 1113 of the feedback information then the application MUST be enhanced to 1114 support both information calculated pre- and post- FEC recovery. 1115 This is to ensure that congestion control mechanisms operate 1116 correctly based on congestion indications received from the network, 1117 rather than on post-FEC recovery information which would give an 1118 inaccurate picture of congestion conditions. 1120 New applications which require such feedback SHOULD use RTP/RTCP 1121 [RFC3550]. 1123 7. Transport Protocols 1125 This framework is intended to be used to define CDPs that operate 1126 over transport protocols providing an unreliable datagram service, 1127 including in particular the User Datagram Protocol (UDP) and the 1128 Datagram Congestion Control Protocol (DCCP). 1130 8. Congestion Control 1132 This section starts with some informative background on the 1133 motivation of the normative requirements for congestion control, 1134 which are spelled out in Section 8.2. 1136 8.1. Motivation 1138 o The enforcement of congestion control principles has gained a lot 1139 of momentum in the IETF over the recent years. While the need for 1140 congestion control over the open Internet is unquestioned, and the 1141 goal of TCP friendliness is generally agreed for most (but not 1142 all) applications, the subject of congestion detection and 1143 measurement in heterogeneous networks can hardly be considered as 1144 solved. Most congestion control algorithms detect and measure 1145 congestion by taking (primarily or exclusively) the packet loss 1146 rate into account. This appears to be inappropriate in 1147 environments where a large percentage of the packet losses are the 1148 result of link-layer errors and independent of the network load. 1150 o The authors of this document are primarily interested in 1151 applications where the application reliability requirements and 1152 end-to-end reliability of the network differ, such that it 1153 warrants higher-layer protection of the packet stream, e.g., due 1154 to the presence of unreliable links in the end-to-end path and 1155 where real-time, scalability or other constraints prohibit the use 1156 of higher-layer (transport or application) feedback. A typical 1157 example for such applications is multicast and broadcast streaming 1158 or multimedia transmission over heterogeneous networks. In other 1159 cases, application reliability requirements can be so high that 1160 the required end-to-end reliability will be difficult to achieve. 1161 Furthermore, the end-to-end network reliability is not necessarily 1162 known in advance. 1164 o This FEC Framework is not defined, nor intended, as a QoS 1165 enhancement tool to combat losses resulting from highly congested 1166 networks. It should not be used for such purposes. 1168 o In order to prevent such mis-use, one approach is to leave 1169 standardization to bodies most concerned with the problem 1170 described above. However, the IETF defines base standards used by 1171 several bodies, including DVB, 3GPP, 3GPP2, all of which appear to 1172 share the environment and the problem described. 1174 o Another approach is to write a clear applicability statement. For 1175 example, one could restrict the use of this framework to networks 1176 with certain loss characteristics (e.g., wireless links). 1177 However, there can be applications where the use of FEC is 1178 justified to combat congestion-induced packet losses - 1179 particularly in lightly loaded networks, where congestion is the 1180 result of relatively rare random peaks in instantaneous traffic 1181 load - thereby intentionally violating congestion control 1182 principles. One possible example for such an application could be 1183 a no-matter-what, brute-force FEC protection of a traffic 1184 generated as an emergency signal. 1186 o A third approach is to require at a minimum that the use of this 1187 framework with any given application, in any given environment, 1188 does not cause congestion issues which the application alone would 1189 not itself cause, i.e., the use of this framework must not make 1190 things worse. 1192 o Taking above considerations into account, Section 8.2 specifies a 1193 small set of constraints for the FEC, which are mandatory for all 1194 senders compliant with this FEC Framework. Further restrictions 1195 can be imposed by certain CDPs. 1197 8.2. Normative Requirements 1199 o The bandwidth of FEC repair data MUST NOT exceed the bandwidth of 1200 the original source data being protected (without the possible 1201 addition of an Explicit Source FEC Payload ID). This disallows 1202 the (static or dynamic) use of excessively strong FEC to combat 1203 high packet loss rates, which can otherwise be chosen by naively 1204 implemented dynamic FEC-strength selection mechanisms. We 1205 acknowledge that there are a few exotic applications, e.g., IP 1206 traffic from space-based senders, or senders in certain hardened 1207 military devices, which could warrant a higher FEC strength. 1208 However, in this specification we give preference to the overall 1209 stability and network friendliness of average applications. 1211 o Whenever the source data rate is adapted due to the operation of 1212 congestion control mechanisms, the FEC repair data rate MUST be 1213 similarly adapted. 1215 9. Security Considerations 1217 First of all, it must be clear that the application of FEC protection 1218 to a stream does not provide any kind of security. On the opposite, 1219 the FEC Framework itself could be subject to attacks, or could pose 1220 new security risks. The goals of this section are to state the 1221 problem, discuss the risks and identify solutions when feasible. It 1222 also defines a mandatory to implement (but not mandatory to use) 1223 security scheme. 1225 9.1. Problem Statement 1227 A content delivery system is potentially subject to many attacks. 1228 Attacks can target the content, or the CDP, or the network itself, 1229 with completely different consequences, in particular in terms of the 1230 number of impacted nodes. 1232 Attacks can have several goals: 1234 o They can try to give access to a confidential content (e.g., in 1235 case of a non-free content). 1237 o They can try to corrupt the source flows (e.g., to prevent a 1238 receiver from using them), which is a form of DoS attack. 1240 o They can try to compromise the receiver's behavior (e.g., by 1241 making the decoding of an object computationally expensive), which 1242 is another form of DoS attack. 1244 o They can try to compromise the network's behavior (e.g., by 1245 causing congestion within the network), which potentially impacts 1246 a large number of nodes. 1248 These attacks can be launched either against the source and/or repair 1249 flows (e.g., by sending fake FEC source and/or repair packets) or 1250 against the FEC parameters that are sent either in-band (e.g., in the 1251 Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or 1252 out-of-band (e.g., in the FEC Framework Configuration Information). 1254 Several dimensions to the problem need to be considered. The first 1255 one is the way the FEC Framework is used. The FEC Framework can be 1256 used end-to-end, i.e., it can be included in the final end-device 1257 where the upper application runs; or the FEC Framework can be used in 1258 middleboxes, for instance, to globally protect several source flows 1259 exchanged between two or more distant sites. 1261 A second dimension is the threat model. When the FEC Framework 1262 operates in the end-device, this device (e.g., a personal computer) 1263 might be subject to attacks. Here, the attacker is either the end- 1264 user (who might want to access confidential content) or somebody 1265 else. In all cases the attacker has access to the end-device, but 1266 not necessarily to the full control of the end-device (a secure 1267 domain can exist). Similarly, when the FEC Framework operates in a 1268 middlebox, this middlebox can be subject to attacks or the attacker 1269 can gain access to it. The threats can also concern the end-to-end 1270 transport (e.g., through Internet). Here, examples of threats 1271 include the transmission of fake FEC source or repair packets, the 1272 replay of valid packets, the drop, delay or misordering of packets, 1273 and of course traffic eavesdropping. 1275 The third dimension consists in the desired security services. Among 1276 them, the content integrity and sender authentication services are 1277 probably the most important features. We can also mention DoS 1278 mitigation, anti-replay protection or content confidentiality. 1280 Finally, the fourth dimension consists in the security tools 1281 available. This is the case of the various Digital Rights Management 1282 (DRM) systems, defined out of the context of the IETF and that can be 1283 proprietary solutions. Otherwise SRTP and IPsec/ESP are two tools 1284 that can turn out to be useful in the context of the FEC Framework. 1285 Note that using SRTP requires that the application generates RTP 1286 source flows and, when applied below the FEC Framework, that both the 1287 FEC source and repair packets to be regular RTP packets. Therefore 1288 SRTP is not considered as a universal solution applicable in all use 1289 cases. 1291 In the following sections, we further discuss security aspects 1292 related to the use of the FEC Framework. 1294 9.2. Attacks Against the Data Flows 1296 9.2.1. Access to Confidential Content 1298 Access control to the source flow being transmitted is typically 1299 provided by means of encryption. This encryption can be done by the 1300 content provider itself, or within the application (for instance by 1301 using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), or 1302 at the network layer, on a per-packet basis when IPsec/ESP is used 1303 [RFC4303]. If confidentiality is a concern, it is RECOMMENDED that 1304 one of these solutions is used. Even if we mention these attacks 1305 here, they are neither related to nor facilitated by the use of FEC. 1307 Note that when encryption is applied, this encryption MUST either be 1308 applied on the source data before the FEC protection, or if done 1309 after the FEC protection, then both the FEC source packets and repair 1310 packets MUST be encrypted (and an encryption at least as 1311 cryptographically secure as the encryption applied on the FEC source 1312 packets MUST be used for the FEC repair packets). Otherwise, if 1313 encryption were to be performed only on the FEC source packets after 1314 FEC encoding, a non-authorized receiver could be able to recover the 1315 source data after decoding the FEC repair packets provided that a 1316 sufficient number of such packets were available. 1318 The following considerations apply when choosing where to apply 1319 encryption (and more generally where to apply security services 1320 beyond encryption). Once decryption has taken place, the source data 1321 is in plaintext. The full path between the output of the deciphering 1322 module and the final destination (e.g., the TV display in case of a 1323 video) MUST be secured, in order to prevent any unauthorized access 1324 to the source data. 1326 When the FEC Framework endpoint is the end system (i.e., where the 1327 upper application runs) and if the threat model includes the 1328 possibility that an attacker has access to this end system, then the 1329 end system architecture is very important. More precisely, in order 1330 to prevent an attacker to get hold of the plaintext, all processings, 1331 once deciphering has taken place, MUST occur in a protected 1332 environment. If encryption is applied after FEC protection at the 1333 sending side (i.e., below FEC Framework), it means that FEC decoding 1334 MUST take place in the protected environment. With certain use 1335 cases, this MAY be complicated or even impossible. In that case 1336 applying encryption before FEC protection is preferred. 1338 When the FEC Framework endpoint is a middlebox, the recovered source 1339 flow, after FEC decoding, SHOULD NOT be sent in plaintext to the 1340 final destination(s) if the threat model includes the possibility 1341 that an attacker eavesdrops the traffic. In that case also it is 1342 preferred to apply encryption before FEC protection. 1344 In some cases, encryption could be applied both before and after the 1345 FEC protection. The considerations described above still apply in 1346 such cases. 1348 9.2.2. Content Corruption 1350 Protection against corruptions (e.g., against forged FEC source/ 1351 repair packets) is achieved by means of a content integrity 1352 verification/source authentication scheme. This service is usually 1353 provided at the packet level. In this case, after removing all the 1354 forged packets, the source flow might sometimes be recovered. 1355 Several techniques can provide this content integrity/source 1356 authentication service: 1358 o At the application layer, SRTP [RFC3711] provides several 1359 solutions to check the integrity and authenticate the source of 1360 RTP and RTCP messages, among other services. For instance, 1361 associated to the Timed Efficient Stream Loss-Tolerant 1362 Authentication (TESLA) [RFC4383], SRTP is an attractive solution 1363 that is robust to losses, provides a true authentication/integrity 1364 service, and does not create any prohibitive processing load or 1365 transmission overhead. Yet, checking a packet requires a small 1366 delay (a second or more) after its reception with TESLA. Whether 1367 this extra delay, both in terms of startup delay at the client and 1368 end-to-end delay, is appropriate or not depends on the target use 1369 case. In some situations, this might degrade the user experience. 1370 In other situations, this will not be an issue. Other building 1371 blocks can be used within SRTP to provide content integrity/ 1372 authentication services. 1374 o At the network layer, IPsec/ESP [RFC4303] offers (among other 1375 services) an integrity verification mechanism that can be used to 1376 provide authentication/content integrity services. 1378 It is up to the developer and the person in charge of deployment, who 1379 know the security requirements and features of the target application 1380 area, to define which solution is the most appropriate. Nonetheless 1381 it is RECOMMENDED that at least one of these techniques is used. 1383 Note that when integrity protection is applied, it is RECOMMENDED 1384 that it takes place on both FEC source and repair packets. The 1385 motivation is to avoid corrupted packets to be considered during 1386 decoding, which would often lead to a decoding failure or result in a 1387 corrupted decoded source flow. 1389 9.3. Attacks Against the FEC Parameters 1391 Attacks on these FEC parameters can prevent the decoding of the 1392 associated object. For instance, modifying the finite field size of 1393 a Reed-Solomon FEC scheme (when applicable) will lead a receiver to 1394 consider a different FEC code. 1396 It is therefore RECOMMENDED that security measures are taken to 1397 guarantee the FEC Framework Configuration Information integrity. 1398 Since the FEC Framework does not define how the FEC Framework 1399 Configuration Information is communicated from sender to receiver, we 1400 cannot provide further recommendations on how to guarantee its 1401 integrity. However, any complete CDP specification MUST give 1402 recommendations on how to achieve it. When the FEC Framework 1403 Configuration Information is sent out-of-band, e.g., in a session 1404 description, it SHOULD be protected, for instance, by digitally 1405 signing it. 1407 Attacks are also possible against some FEC parameters included in the 1408 Explicit Source FEC Payload ID and Repair FEC Payload ID. For 1409 instance, modifying the Source Block Number of an FEC source or 1410 repair packet will lead a receiver to assign this packet to a wrong 1411 block. 1413 It is therefore RECOMMENDED that security measures are taken to 1414 guarantee the Explicit Source FEC Payload ID and Repair FEC Payload 1415 ID integrity. To that purpose, one of the packet-level source 1416 authentication/content integrity techniques of Section 9.2.2 can be 1417 used. 1419 9.4. When Several Source Flows are to be Protected Together 1421 When several source flows, with different security requirements, need 1422 to be FEC protected jointly, within a single FEC Framework instance, 1423 then each flow MAY be processed appropriately, before the protection. 1424 For instance, source Flows that require access control MAY be 1425 encrypted before they are FEC protected. 1427 There are also situations where the only insecure domain is the one 1428 over which the FEC Framework operates. In that case, this situation 1429 MAY be addressed at the network layer, using IPsec/ESP (see 1430 Section 9.5), even if only a subset of the source flows have strict 1431 security requirements. 1433 Since the use of FEC Framework should not add any additional threat, 1434 it is RECOMMENDED that the FEC Framework aggregate flow be in line 1435 with the maximum security requirements of the individual source 1436 flows. For instance, if denial-of-service (DoS) protection is 1437 required, an integrity protection SHOULD be provided below the FEC 1438 Framework, using for instance IPsec/ESP. 1440 Generally speaking, whenever feasible, it is RECOMMENDED to avoid FEC 1441 protecting flows with totally different security requirements. 1442 Otherwise, an important processing would be added to protect the 1443 source flows that do not need it. 1445 9.5. Baseline Secure FEC Framework Operation 1447 This section describes a baseline mode of secure FEC Framework 1448 operation based on the application of the IPsec security protocol, 1449 which is one possible solution to solve or mitigate the security 1450 threats introduced by the use of the FEC Framework. 1452 Two related documents are of interest. First, Section 5.1 of 1453 [RFC5775] defines a baseline secure ALC operation for sender-to-group 1454 transmissions, assuming the presence of a single sender and a source- 1455 specific multicast (SSM) or SSM-like operation. The proposed 1456 solution, based on IPsec/ESP, can be used to provide a baseline FEC 1457 Framework secure operation, for the downstream source flow. 1459 Second, Section 7.1 of [RFC5740] defines a baseline secure NORM 1460 operation, for sender-to-group transmissions as well as unicast 1461 feedbacks from receivers. Here, it is also assumed there is a single 1462 sender. The proposed solution is also based on IPsec/ESP. However, 1463 the difference with respect to the first document relies on the 1464 management of IPsec Security Associations (SA) and corresponding 1465 Security Policy Database (SPD) entries, since NORM requires a second 1466 set of SA and SPD to be defined to protect unicast feedbacks from 1467 receivers. 1469 The FEC Framework has been defined in such a way to be independent 1470 from the application that generates source flows. Some applications 1471 might use purely unidirectional flows, while other applications might 1472 also use unicast feedbacks from the receivers. For instance, this is 1473 the case when considering RTP/RTCP based source flows. Depending on 1474 the specific situation, it is RECOMMENDED that the baseline secure 1475 FEC Framework operation inherits from [RFC5775] in case of purely 1476 unidirectional sender-to-group flows, or [RFC5740] in case both 1477 sender-to-group and unicast feedbacks flows are needed. 1479 Note that the IPsec/ESP requirements profiles outlined in [RFC5775] 1480 and [RFC5740] are commonly available on many potential hosts. They 1481 can form the basis of a secure mode of operation. One potential 1482 limitation, however, is the need for privileged user authorization. 1483 However, automated key management implementations are typically 1484 configured with the privileges necessary to affect system IPsec 1485 configuration. 1487 10. Operations and Management Considerations 1489 The FEC Framework is concerned about the FEC encoding and decoding 1490 operations, and the configuration information that is essential to 1491 control the hosts running these operations. Defining tools for the 1492 operation and management of these hosts is not within the scope of 1493 this specification. 1495 Some applications using the CDPs compatible with the FEC Framework 1496 are one-way meaning that they do not have a way to gather any kind of 1497 feedback from receivers (e.g., broadcast), while some of them may 1498 collect detailed feedback (in case it is a one-to-one application) or 1499 occasional feedback (in case it is a multicast (one-to-many) 1500 application). All these applications have naturally different 1501 management aspects. If any, they also have different requirements or 1502 features for collecting feedback, processing it and acting on it. 1503 The data structures for carrying the feedback also vary. 1505 From an operational viewpoint, it is important to note that in one- 1506 to-many applications, there could be some receivers that are not 1507 capable of decoding the repair packets belonging to a particular FEC 1508 scheme, or some receivers could be non-FEC-capable at all. Such 1509 receivers can opt not to receive the repair packets that they will 1510 not be able to decode in the first place or discard them 1511 appropriately upon receiving them. However, if the source packets 1512 have been modified during FEC encoding according to the rules 1513 specified in Section 5.3, the receivers that are not FEC Framework 1514 compatible will not even be able to use the source packets. When 1515 using FEC Framework in such receiver populations, it is important to 1516 keep the source packets unmodified or offer the unmodified source 1517 packets through another distribution channel to non-compatible 1518 receivers. For details, see Section 5.3. 1520 It is not advisable for the FEC Framework to explicitly list what the 1521 hosts (sender or receiver or even a middle-box) could do upon 1522 observing something in particular or receiving a specific feedback. 1523 The CDPs and the FEC schemes compatible with the FEC Framework SHOULD 1524 make use of existing tools as much as possible and to the extent 1525 possible. For example, for repair flows using RTP transport, 1526 benefiting from all the features of RTCP mechanisms is strongly 1527 RECOMMENDED since RTCP has already solved many of these issues in an 1528 agnostic way of the data carried with RTP. 1530 Overall, the CDPs and FEC schemes compatible with the FEC Framework 1531 widely differ in their capabilities, application and deployment 1532 scenarios such that a common operation and management tool that works 1533 well for all of them does not exist. Thus, as a design choice, the 1534 FEC Framework does not dictate the use of any particular technology 1535 or protocol for transporting FEC data, managing the hosts, signaling 1536 the configuration information or encoding the configuration 1537 information. This provides flexibility and was one of the main goals 1538 of the FEC Framework. 1540 11. IANA Considerations 1542 FEC schemes for use with this framework are identified in protocols 1543 using FEC Encoding IDs. Values of FEC Encoding IDs are subject to 1544 IANA registration. For this purposes, this document creates a new 1545 registry called FEC Framework (FECFRAME) FEC Encoding IDs. 1547 The values that can be assigned within the FEC Framework (FECFRAME) 1548 FEC Encoding ID registry are numeric indexes in the range (0, 255). 1549 Values of 0 and 255 are reserved. Assignment requests are granted on 1550 an IETF Consensus basis as defined in [RFC5226]. Section 5.6 defines 1551 explicit requirements that documents defining new FEC Encoding IDs 1552 should meet. 1554 12. Acknowledgments 1556 This document is based in part on [I-D.watson-tsvwg-fec-sf] and so 1557 thanks are due to the additional authors of that document, Mike Luby, 1558 Magnus Westerlund and Stephan Wenger. That document was in turn 1559 based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and 1560 thus, thanks are also due to the participants in 3GPP SA Working 1561 Group 4. Further thanks are due to the members of the FECFRAME 1562 Working Group for their comments and reviews. 1564 13. References 1566 13.1. Normative references 1568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1569 Requirement Levels", BCP 14, RFC 2119, March 1997. 1571 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1572 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1573 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1574 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1575 Compression (ROHC): Framework and four profiles: RTP, UDP, 1576 ESP, and uncompressed", RFC 3095, July 2001. 1578 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1579 Correction (FEC) Building Block", RFC 5052, August 2007. 1581 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1582 Jacobson, "RTP: A Transport Protocol for Real-Time 1583 Applications", STD 64, RFC 3550, July 2003. 1585 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1586 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1587 May 2008. 1589 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1590 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1592 13.2. Informative references 1594 [I-D.watson-tsvwg-fec-sf] 1595 Watson, M., "Forward Error Correction (FEC) Streaming 1596 Framework", draft-watson-tsvwg-fec-sf-00 (work in 1597 progress), July 2005. 1599 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 1600 Report Block Type for RTP Control Protocol (RTCP) Extended 1601 Reports (XRs)", RFC 5725, February 2010. 1603 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1604 Description Protocol", RFC 4566, July 2006. 1606 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1607 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1608 July 2006. 1610 [I-D.ietf-fecframe-sdp-elements] 1611 Begen, A., "Session Description Protocol Elements for FEC 1612 Framework", draft-ietf-fecframe-sdp-elements-11 (work in 1613 progress), October 2010. 1615 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1616 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1617 RFC 3711, March 2004. 1619 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1620 "NACK-Oriented Reliable Multicast (NORM) Transport 1621 Protocol", RFC 5740, November 2009. 1623 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1624 RFC 4303, December 2005. 1626 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1627 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1628 Real-time Transport Protocol (SRTP)", RFC 4383, 1629 February 2006. 1631 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1632 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1633 April 2010. 1635 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1636 Protocols and codecs", 3GPP TS 26.346, April 2005. 1638 Authors' Addresses 1640 Mark Watson 1641 Netflix, Inc. 1642 100 Winchester Circle 1643 Los Gatos, CA 95032 1644 USA 1646 Email: watsonm@netflix.com 1648 Ali Begen 1649 Cisco 1650 181 Bay Street 1651 Toronto, ON M5J 2T3 1652 Canada 1654 Email: abegen@cisco.com 1656 Vincent Roca 1657 INRIA 1658 655, av. de l'Europe 1659 Inovallee; Montbonnot 1660 ST ISMIER cedex 38334 1661 France 1663 Email: vincent.roca@inria.fr 1664 URI: http://planete.inrialpes.fr/people/roca/