idnits 2.17.1 draft-ietf-fecframe-framework-11.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 (November 20, 2010) is 4906 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) -- Looks like a reference, but probably isn't: '0' on line 1252 -- Looks like a reference, but probably isn't: '255' on line 1252 ** 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 (==), 5 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: May 24, 2011 Cisco 6 November 20, 2010 8 Forward Error Correction (FEC) Framework 9 draft-ietf-fecframe-framework-11 11 Abstract 13 This document describes a framework for using Forward Error 14 Correction (FEC) codes with applications in public and private IP 15 networks to provide protection against packet loss. The framework 16 supports applying FEC to arbitrary packet flows over unreliable 17 transport and is primarily intended for real-time, or streaming, 18 media. This framework can be used to define Content Delivery 19 Protocols that provide FEC for streaming media delivery or other 20 packet flows. Content Delivery Protocols defined using this 21 framework can support any FEC scheme (and associated FEC codes) which 22 is compliant with various requirements defined in this document. 23 Thus, Content Delivery Protocols can be defined which are not 24 specific to a particular FEC scheme, and FEC schemes can be defined 25 which are not specific to a particular Content Delivery Protocol. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 24, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 75 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 76 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 13 77 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14 79 4.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 80 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21 81 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 5.2. Structure of the Source Block . . . . . . . . . . . . . . 21 83 5.3. Packet Format for FEC Source Packets . . . . . . . . . . . 21 84 5.3.1. Generic Explicit Source FEC Payload ID . . . . . . . . 23 85 5.4. Packet Format for FEC Repair Packets . . . . . . . . . . . 23 86 5.4.1. Packet Format for FEC Repair Packets over RTP . . . . 23 87 5.5. FEC Framework Configuration Information . . . . . . . . . 24 88 5.6. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 26 89 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30 91 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31 92 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 31 93 8.2. Normative Requirements . . . . . . . . . . . . . . . . . . 32 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 12.1. Normative references . . . . . . . . . . . . . . . . . . . 36 99 12.2. Informative references . . . . . . . . . . . . . . . . . . 36 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 102 1. Introduction 104 Many applications have a requirement to transport a continuous stream 105 of packetized data from a source (sender) to one or more destinations 106 (receivers) over networks which do not provide guaranteed packet 107 delivery. Primary examples are real-time, or streaming, media 108 applications such as broadcast, multicast or on-demand audio, video 109 or multimedia. 111 Forward Error Correction (FEC) is a well-known technique for 112 improving reliability of packet transmission over networks which do 113 not provide guaranteed packet delivery, especially in multicast and 114 broadcast applications. The FEC Building Block defined in [RFC5052] 115 provides a framework for definition of Content Delivery Protocols 116 (CDPs) for object delivery (including, primarily, file delivery) 117 which make use of separately defined FEC schemes. Any CDP defined 118 according to the requirements of the FEC Building Block can then 119 easily be used with any FEC scheme which is also defined according to 120 the requirements of the FEC Building Block. 122 Note that the term "Forward Erasure Correction" is sometimes used, 123 erasures being a type of error in which data is lost and this loss 124 can be detected, rather than being received in corrupted form. The 125 focus of this document is strictly on erasures and, the term "Forward 126 Error Correction" is more widely used. 128 This document defines a framework for the definition of CDPs which 129 provide for FEC protection for arbitrary packet flows over unreliable 130 transports such as UDP. As such, this document complements the FEC 131 Building Block of [RFC5052], by providing for the case of arbitrary 132 packet flows over unreliable transport, the same kind of framework as 133 that document provides for object delivery. This document does not 134 define a complete CDP, but rather defines only those aspects that are 135 expected to be common to all CDPs based on this framework. 137 This framework does not define how the flows to be protected are 138 determined, nor how the details of the protected flows and the FEC 139 streams which protect them are communicated from sender to receiver. 140 It is expected that any complete CDP specification which makes use of 141 this framework will address these signaling requirements. However, 142 this document does specify the information which is required by the 143 FEC Framework at the sender and receiver, e.g., details of the flows 144 to be FEC protected, the flow(s) that will carry the FEC protection 145 data and an opaque container for FEC-Scheme-Specific Information. 147 FEC schemes designed for use with this framework must fulfill a 148 number of requirements defined in this document. These requirements 149 are different from those defined in [RFC5052] for FEC schemes for 150 object delivery. However, there is a great deal of commonality and 151 FEC schemes defined for object delivery may be easily adapted for use 152 with the framework defined in this document. 154 Since the RTP protocol is (often) used over UDP, this framework can 155 be applied to RTP flows as well. FEC repair packets may be sent 156 directly over UDP or RTP. The latter approach has the advantage that 157 RTP instrumentation, based on RTP Control Protocol (RTCP), can be 158 used for the repair flow. Additionally, the post-repair RTCP 159 extended reports [RFC5725] may be used to obtain information about 160 the loss rate after FEC recovery. 162 The use of RTP for repair flows is defined for each FEC scheme by 163 defining an RTP payload format for that particular FEC scheme 164 (possibly in the same document). 166 2. Definitions and Abbreviations 168 Application Data Unit (ADU): The unit of source data provided as 169 payload to the transport layer. 171 ADU Flow: A sequence of ADUs associated with a transport-layer flow 172 identifier (such as the standard 5-tuple {Source IP address, source 173 port, destination IP address, destination port, transport protocol}). 175 AL-FEC: Application-layer Forward Error Correction. 177 Application Protocol: Control protocol used to establish and control 178 the source flow being protected, e.g., RTSP. 180 Content Delivery Protocol (CDP): A complete application protocol 181 specification which, through the use of the framework defined in this 182 document, is able to make use of FEC schemes to provide FEC 183 capabilities. 185 FEC Code: An algorithm for encoding data such that the encoded data 186 flow is resilient to data loss. Note that in general FEC codes may 187 also be used to make a data flow resilient to corruption, but that is 188 not considered in this document. 190 FEC Framework: A protocol framework for definition of Content 191 Delivery Protocols using FEC, such as the framework defined in this 192 document. 194 FEC Framework Configuration Information: Information which controls 195 the operation of the FEC Framework. 197 FEC Payload ID: Information which identifies the contents of a packet 198 with respect to the FEC scheme. 200 FEC Repair Packet: At a sender (respectively, at a receiver) a 201 payload submitted to (respectively, received from) the transport 202 protocol containing one or more repair symbols along with a Repair 203 FEC Payload ID and possibly an RTP header. 205 FEC Scheme: A specification which defines the additional protocol 206 aspects required to use a particular FEC code with the FEC Framework. 208 FEC Source Packet: At a sender (respectively, at a receiver) a 209 payload submitted to (respectively, received from) the transport 210 protocol containing an ADU along with an optional Explicit Source FEC 211 Payload ID. 213 Protection Amount: The relative increase in data sent due to the use 214 of FEC. 216 Repair Flow: The packet flow carrying FEC data. 218 Repair FEC Payload ID: An FEC Payload ID specifically for use with 219 repair packets. 221 Source Flow: The packet flow to which FEC protection is to be 222 applied. A source flow consists of ADUs. 224 Source FEC Payload ID: An FEC Payload ID specifically for use with 225 source packets. 227 Source Protocol: A protocol used for the source flow being protected, 228 e.g., RTP. 230 Transport Protocol: The protocol used for transport of the source and 231 repair flows, e.g., UDP and DCCP. 233 The following definitions are aligned with [RFC5052]: 235 Code Rate: The ratio between the number of source symbols and the 236 number of encoding symbols. By definition, the code rate is such 237 that 0 < code rate <= 1. A code rate close to 1 indicates that a 238 small number of repair symbols have been produced during the encoding 239 process. 241 Encoding Symbol: Unit of data generated by the encoding process. 242 With systematic codes, source symbols are part of the encoding 243 symbols. 245 Packet Erasure Channel: A communication path where packets are either 246 dropped (e.g., by a congested router, or because the number of 247 transmission errors exceeds the correction capabilities of the 248 physical-layer codes) or received. When a packet is received, it is 249 assumed that this packet is not corrupted. 251 Repair Symbol: Encoding symbol that is not a source symbol. 253 Source Block: Group of ADUs which are to be FEC protected as a single 254 block. 256 Source Symbol: Unit of data used during the encoding process. 258 Systematic Code: FEC code in which the source symbols are part of the 259 encoding symbols. 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 263 document are to be interpreted as described in [RFC2119]. 265 3. Architecture Overview 267 The FEC Framework is described in terms of an additional layer 268 between the transport layer (e.g., UDP or DCCP) and protocols running 269 over this transport layer. As such, the data path interface between 270 the FEC Framework and both underlying and overlying layers can be 271 thought of as being the same as the standard interface to the 272 transport layer, i.e., the data exchanged consists of datagram 273 payloads each associated with a single ADU flow identified by the 274 standard 5-tuple {Source IP address, source port, destination IP 275 address, destination port, transport protocol}. In the case that RTP 276 is used for the repair flows, the source and repair data can be 277 multiplexed using RTP onto a single UDP flow and needs to be 278 consequently demultiplexed at the receiver. There are various ways 279 in which this multiplexing can be done, for example as described in 280 [RFC4588]. 282 It is important to understand that the main purpose of the FEC 283 Framework architecture is to allocate functional responsibilities to 284 separately documented components in such a way that specific 285 instances of the components can be combined in different ways to 286 describe different protocols. 288 The FEC Framework makes use of an FEC scheme, in a similar sense to 289 that defined in [RFC5052] and uses the terminology of that document. 290 The FEC scheme defines the FEC encoding and decoding, and defines the 291 protocol fields and procedures used to identify packet payload data 292 in the context of the FEC scheme. The interface between the FEC 293 Framework and an FEC scheme, which is described in this document, is 294 a logical one, which exists for specification purposes only. At an 295 encoder, the FEC Framework passes ADUs to the FEC scheme for FEC 296 encoding. The FEC scheme returns repair symbols with their 297 associated Repair FEC Payload IDs, and in some cases Source FEC 298 Payload IDs, depending on the FEC scheme. At a decoder, the FEC 299 Framework passes transport packet payloads (source and repair) to the 300 FEC scheme and the FEC scheme returns additional recovered source 301 packet payloads. 303 This document defines certain FEC Framework Configuration Information 304 which MUST be available to both sender and receiver(s). For example, 305 this information includes the specification of the ADU flows which 306 are to be FEC protected, specification of the ADU flow(s) which will 307 carry the FEC protection (repair) data and the relationship(s) 308 between these source and repair flows (i.e., which source flow(s) are 309 protected by each repair flow(s)). The FEC Framework Configuration 310 Information also includes information fields which are specific to 311 the FEC scheme. This information is analogous to the FEC Object 312 Transmission Information defined in [RFC5052]. 314 The FEC Framework does not define how the FEC Framework Configuration 315 Information for the stream is communicated from sender to receiver. 316 This has to be defined by any CDP specification as described in the 317 following sections. 319 In this architecture we assume that the interface to the transport 320 layer supports the concepts of data units (referred to here as 321 Application Data Units (ADUs)) to be transported and identification 322 of ADU flows on which those data units are transported. Since this 323 is an interface internal to the architecture, we do not specify this 324 interface explicitly. We do require that ADU flows which are 325 distinct from the transport layer point of view (for example, 326 distinct UDP flows as identified by the UDP source/destination 327 addresses/ports) are also distinct on the interface between the 328 transport layer and the FEC Framework. 330 As noted above, RTP flows are a specific example of ADU flows which 331 might be protected by the FEC Framework. From the FEC Framework 332 point of view, RTP source flows are ADU flows like any other, with 333 the RTP header included within the ADU. 335 Depending on the FEC scheme, RTP can also be used as a transport for 336 repair packet flows. In this case an FEC scheme has to define an RTP 337 payload format for the repair data. 339 The architecture outlined above is illustrated in the Figure 1. In 340 this architecture, two (optional) RTP instances are shown, for the 341 source and repair data respectively. This is because the use of RTP 342 for the source data is separate from and independent of the use of 343 RTP for the repair data. The appearance of two RTP instances is more 344 natural when one considers that in many FEC codes, the repair payload 345 contains repair data calculated across the RTP headers of the source 346 packets. Thus, a repair packet carried over RTP starts with an RTP 347 header of its own which is followed (after the Repair Payload ID) by 348 repair data containing bytes which protect the source RTP headers (as 349 well as repair data for the source RTP payloads). 351 +--------------------------------------------+ 352 | Application | 353 +--------------------------------------------+ 354 | 355 | 356 | 357 + - - - - - - - - - - - - - - - - - - - - - - - -+ 358 | +--------------------------------------------+ | 359 | Application Layer | 360 | +--------------------------------------------+ | 361 | | 362 | + -- -- -- -- -- -- -- -- -- -- --+ | | 363 | RTP (Optional) | | 364 | | | |- Configuration/Coordination 365 +- -- -- -- -- -- -- -- -- -- -- -+ | 366 | | | | 367 | ADU flows | 368 | | v | 369 +--------------------------------------------+ +----------------+ 370 | | FEC Framework (This document) |<--->| FEC Scheme | 371 +--------------------------------------------+ +----------------+ 372 | | | | 373 Source | Repair | 374 | | | | 375 +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ 376 | | RTP Layer | | RTP Processing | | | 377 | (Optional) | +-- -- -- |- -- -+ | 378 | | +-- -- -- -- -- -- -- |--+ | | 379 | | RTP (De)multiplexing | | 380 | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | 381 | 382 | +--------------------------------------------+ | 383 | Transport Layer (e.g., UDP) | 384 | +--------------------------------------------+ | 385 | 386 | +--------------------------------------------+ | 387 | IP | 388 | +--------------------------------------------+ | 390 | Content Delivery Protocol | 391 + - - - - - - - - - - - - - - - - - - - - - - - + 393 Figure 1: FEC Framework architecture 395 The content of the transport payload for repair packets is fully 396 defined by the FEC scheme. For a specific FEC scheme, a means MAY be 397 defined for repair data to be carried over RTP, in which case the 398 repair packet payload format starts with the RTP header. This 399 corresponds to defining an RTP payload format for the specific FEC 400 scheme. 402 The use of RTP for repair packets is independent of the protocols 403 used for source packets: if RTP is used for source packets, repair 404 packets may or may not use RTP and vice versa (although it is 405 unlikely that there are useful scenarios where non-RTP source flows 406 are protected by RTP repair flows). FEC schemes are expected to 407 recover entire transport payloads for recovered source packets in all 408 cases. For example, if RTP is used for source flows, the FEC scheme 409 is expected to recover the entire UDP payload, including the RTP 410 header. 412 4. Procedural Overview 414 4.1. General 416 The mechanism defined in this document does not place any 417 restrictions on the ADUs which can be protected together, except that 418 the ADU is carried over a supported transport protocol (See 419 Section 7). The data can be from multiple source flows that are 420 protected jointly. The FEC Framework handles the source flows as a 421 sequence of source blocks each consisting of a set of ADUs, possibly 422 from multiple source flows which are to be protected together. For 423 example, each source block can be constructed from those ADUs related 424 to a particular segment in time of the flow. 426 At the sender, the FEC Framework passes the payloads for a given 427 block to the FEC scheme for FEC encoding. The FEC scheme performs 428 the FEC encoding operation and returns the following information: 430 o Optionally, FEC Payload IDs for each of the source payloads 431 (encoded according to an FEC-Scheme-Specific format). 433 o One or more FEC repair packet payloads. 435 o FEC Payload IDs for each of the repair packet payloads (encoded 436 according to an FEC-Scheme-Specific format). 438 The FEC Framework then performs two operations. First, it appends 439 the Source FEC Payload IDs, if provided, to each of the ADUs, and 440 sends the resulting packets, known as FEC source packets, to the 441 receiver, and second it places the provided FEC repair packet 442 payloads and corresponding Repair FEC Payload IDs appropriately to 443 construct FEC repair packets and send them to the receiver. 445 This document does not define how the sender determines which ADUs 446 are included in which source blocks or the sending order and timing 447 of FEC source and repair packets. A specific CDP MAY define this 448 mapping or it MAY be left as implementation dependent at the sender. 449 However, a CDP specification MUST define how a receiver determines a 450 minimum length of time that it needs to wait to receive FEC repair 451 packets for any given source block. FEC schemes MAY define 452 limitations on this mapping, such as maximum size of source blocks, 453 but SHOULD NOT attempt to define specific mappings. The sequence of 454 operations at the sender is described in more detail in Section 4.2. 456 At the receiver, original ADUs are recovered by the FEC Framework 457 directly from any FEC source packets received simply by removing the 458 Source FEC Payload ID, if present. The receiver also passes the 459 contents of the received ADUs, plus their FEC Payload IDs to the FEC 460 scheme for possible decoding. 462 If any ADUs related to a given source block have been lost, then the 463 FEC scheme can perform FEC decoding to recover the missing ADUs 464 (assuming sufficient FEC source and repair packets related to that 465 source block have been received). 467 Note that the receiver might need to buffer received source packets 468 to allow time for the FEC repair packets to arrive and FEC decoding 469 to be performed before some or all of the received or recovered 470 packets are passed to the application. If such a buffer is not 471 provided, then the application has to be able to deal with the severe 472 re-ordering of packets that can occur. However, such buffering is 473 CDP and/or implementation-specific and is not specified here. The 474 receiver operation is described in more detail in Section 4.3. 476 The FEC source packets MUST contain information which identifies the 477 source block and the position within the source block (in terms 478 specific to the FEC scheme) occupied by the ADU. This information is 479 known as the Source FEC Payload ID. The FEC scheme is responsible 480 for defining and interpreting this information. This information MAY 481 be encoded into a specific field within the FEC source packet format 482 defined in this specification, called the Explicit Source FEC Payload 483 ID field. The exact contents and format of the Explicit Source FEC 484 Payload ID field are defined by the FEC schemes. Alternatively, the 485 FEC scheme MAY define how the Source FEC Payload ID is derived from 486 other fields within the source packets. This document defines the 487 way that the Explicit Source FEC Payload ID field is appended to 488 source packets to form FEC source packets. 490 The FEC repair packets MUST contain information which identifies the 491 source block and the relationship between the contained repair 492 payloads and the original source block. This is known as the Repair 493 FEC Payload ID. This information MUST be encoded into a specific 494 field, the Repair FEC Payload ID field, the contents and format of 495 which are defined by the FEC schemes. 497 The FEC scheme MAY use different FEC Payload ID field formats for 498 source and repair packets. 500 4.2. Sender Operation 502 It is assumed that the sender has constructed or received original 503 data packets for the session. These could be carrying any type of 504 data. The following operations, illustrated in Figure 2, for the 505 case of UDP repair flows and Figure 3 for the case of RTP repair 506 flows, describe a possible way to generate compliant source and 507 repair flows: 509 1. ADUs are provided by the application. 511 2. A source block is constructed as specified in Section 5.2. 513 3. The source block is passed to the FEC scheme for FEC encoding. 514 The Source FEC Payload ID information of each source packet is 515 determined by the FEC scheme. If required by the FEC scheme the 516 Source FEC Payload ID is encoded into the Explicit Source FEC 517 Payload ID field. 519 4. The FEC scheme performs FEC encoding, generating repair packet 520 payloads from a source block and a Repair FEC Payload ID field 521 for each repair payload. 523 5. The Explicit Source FEC Payload IDs (if used), Repair FEC Payload 524 IDs and repair packet payloads are provided back from the FEC 525 scheme to the FEC Framework. 527 6. The FEC Framework constructs FEC source packets according to 528 Section 5.3 and FEC repair packets according to Section 5.4 using 529 the FEC Payload IDs and repair packet payloads provided by the 530 FEC scheme. 532 7. The FEC source and repair packets are sent using normal 533 transport-layer procedures. The port(s) and multicast group(s) 534 to be used for FEC repair packets are defined in the FEC 535 Framework Configuration Information. The FEC source packets are 536 sent using the same ADU flow identification information as would 537 have been used for the original source packets if the FEC 538 Framework were not present (for example, in the UDP case, the UDP 539 source and destination addresses and ports on the IP datagram 540 carrying the source packet will be the same whether or not the 541 FEC Framework is applied). 543 +----------------------+ 544 | Application | 545 +----------------------+ 546 | 547 |(1) ADUs 548 | 549 v 550 +----------------------+ +------------------+ 551 | FEC Framework | | | 552 | |-------------------------->| FEC Scheme | 553 |(2) Construct source |(3) Source Block | | 554 | blocks | | (4) FEC Encoding | 555 |(6) Construct FEC |<--------------------------| | 556 | source and repair | | | 557 | packets |(5) Explicit Source FEC | | 558 +----------------------+ Payload IDs +------------------+ 559 | Repair FEC Payload IDs 560 | Repair symbols 561 | 562 |(7) FEC source and repair packets 563 v 564 +----------------------+ 565 | Transport Layer | 566 | (e.g., UDP) | 567 +----------------------+ 569 Figure 2: Sender operation 571 +----------------------+ 572 | Application | 573 +----------------------+ 574 | 575 |(1) ADUs 576 | 577 v 578 +----------------------+ +------------------+ 579 | FEC Framework | | | 580 | |-------------------------->| FEC Scheme | 581 |(2) Construct source |(3) Source Block | | 582 | blocks | | (4) FEC Encoding | 583 |(6) Construct FEC |<--------------------------| | 584 | source packets and| | | 585 | repair payloads |(5) Explicit Source FEC | | 586 +----------------------+ Payload IDs +------------------+ 587 | | Repair FEC Payload IDs 588 | | Repair symbols 589 | | 590 |(7) Source |(7') Repair payloads 591 | packets | 592 | | 593 | + -- -- -- -- -+ 594 | | RTP | 595 | +-- -- -- -- --+ 596 v v 597 +----------------------+ 598 | Transport Layer | 599 | (e.g., UDP) | 600 +----------------------+ 602 Figure 3: Sender operation with RTP repair flows 604 4.3. Receiver Operation 606 The following describes a possible receiver algorithm, illustrated in 607 Figure 4 and Figure 5 for the case of RTP repair flows, when 608 receiving an FEC source or repair packet: 610 1. FEC source packets and FEC repair packets are received and passed 611 to the FEC Framework. The type of packet (source or repair) and 612 the source flow to which it belongs (in the case of source 613 packets) is indicated by the ADU flow information which 614 identifies the flow at the transport layer. 616 In the special case that RTP is used for repair packets, and 617 source and repair packets are multiplexed onto the same UDP flow, 618 then RTP demultiplexing is required to demultiplex source and 619 repair flows. However, RTP processing is applied only to the 620 repair packets at this stage; source packets continue to be 621 handled as UDP payloads (i.e., including their RTP headers). 623 2. The FEC Framework extracts the Explicit Source FEC Payload ID 624 field (if present) from the source packets and the Repair FEC 625 Payload ID from the repair packets. 627 3. The Explicit Source FEC Payload IDs (if present), Repair FEC 628 Payload IDs, FEC source and repair payloads are passed to the FEC 629 scheme. 631 4. The FEC scheme uses the received FEC Payload IDs (and derived FEC 632 Source Payload IDs in the case that the Explicit Source FEC 633 Payload ID field is not used) to group source and repair packets 634 into source blocks. If at least one source packet is missing 635 from a source block, and at least one repair packet has been 636 received for the same source block then FEC decoding can be 637 performed in order to recover missing source payloads. The FEC 638 scheme determines whether source packets have been lost and 639 whether enough data for decoding of any or all of the missing 640 source payloads in the source block has been received. 642 5. The FEC scheme returns the ADUs to the FEC Framework in the form 643 of source blocks containing received and decoded ADUs and 644 indications of any ADUs which were missing and could not be 645 decoded. 647 6. The FEC Framework passes the received and recovered ADUs to the 648 application. 650 The description above defines functionality responsibilities but does 651 not imply a specific set of timing relationships. Source packets 652 which are correctly received and those which are reconstructed MAY be 653 delivered to the application out of order and in a different order 654 from the order of arrival at the receiver. Alternatively, buffering 655 and packet re-ordering MAY be applied to re-order received and 656 reconstructed source packets into the order they were placed into the 657 source block, if that is necessary according to the application. 659 +----------------------+ 660 | Application | 661 +----------------------+ 662 ^ 663 | 664 |(6) ADUs 665 | 666 +----------------------+ +------------------+ 667 | FEC Framework | | | 668 | |<---------------------------| FEC Scheme | 669 |(2)Extract FEC Payload|(5) ADUs | | 670 | IDs and pass IDs & | | (4) FEC Decoding | 671 | payloads to FEC |--------------------------->| | 672 | scheme |(3) Explicit Source FEC | | 673 +----------------------+ Payload IDs +------------------+ 674 ^ Repair FEC Payload IDs 675 | Source payloads 676 | Repair payloads 677 | 678 |(1) FEC source and repair packets 679 | 680 +----------------------+ 681 | Transport Layer | 682 | (e.g., UDP) | 683 +----------------------+ 685 Figure 4: Receiver operation 687 +----------------------+ 688 | Application | 689 +----------------------+ 690 ^ 691 | 692 |(6) ADUs 693 | 694 +----------------------+ +------------------+ 695 | FEC Framework | | | 696 | |<---------------------------| FEC Scheme | 697 |(2)Extract FEC Payload|(5) ADUs | | 698 | IDs and pass IDs & | | (4) FEC Decoding | 699 | payloads to FEC |--------------------------->| | 700 | scheme |(3) Explicit Source FEC | | 701 +----------------------+ Payload IDs +------------------+ 702 ^ ^ Repair FEC Payload IDs 703 | | Source payloads 704 | | Repair payloads 705 | | 706 |Source |Repair payloads 707 |packets | 708 | | 709 +-- |- -- -- -- -- -- -+ 710 |RTP| | RTP Processing | 711 | | +-- -- -- --|-- -+ 712 | +-- -- -- -- -- |--+ | 713 | | RTP Demux | | 714 +-- -- -- -- -- -- -- -+ 715 ^ 716 |(1) FEC source and repair packets 717 | 718 +----------------------+ 719 | Transport Layer | 720 | (e.g., UDP) | 721 +----------------------+ 723 Figure 5: Receiver operation with RTP repair flows 725 Note that the above procedure might result in a situation in which 726 not all ADUs are recovered. 728 5. Protocol Specification 730 5.1. General 732 This section specifies the protocol elements for the FEC Framework. 733 Three components of the protocol are defined in this document and are 734 described in the following sections: 736 1. Construction of a source block from ADUs. The FEC code will be 737 applied to this source block to produce the repair payloads. 739 2. A format for packets containing source data. 741 3. A format for packets containing repair data. 743 The operation of the FEC Framework is governed by certain FEC 744 Framework Configuration Information, which is defined in this 745 section. A complete protocol specification that uses this framework 746 MUST specify the means to determine and communicate this information 747 between sender and receiver. 749 5.2. Structure of the Source Block 751 The FEC Framework and FEC scheme exchange ADUs in the form of source 752 blocks. A source block is generated by the FEC Framework from an 753 ordered sequence of ADUs. The allocation of ADUs to blocks is 754 dependent on the application. Note that some ADUs may not be 755 included in any block. Each source block provided to the FEC scheme 756 consists of an ordered sequence of ADUs where the following 757 information is provided for each ADU: 759 o A description of the source flow with which the ADU is associated 760 with. 762 o The ADU itself. 764 o The length of the ADU. 766 5.3. Packet Format for FEC Source Packets 768 The packet format for FEC source packets MUST be used to transport 769 the payload of an original source packet. As depicted in Figure 6, 770 it consists of the original packet, optionally followed by the 771 Explicit Source FEC Payload ID field. The FEC scheme determines 772 whether the Explicit Source FEC Payload ID field is required. This 773 determination is specific to each ADU flow. 775 +------------------------------------+ 776 | IP Header | 777 +------------------------------------+ 778 | Transport Header | 779 +------------------------------------+ 780 | Application Data Unit | 781 +------------------------------------+ 782 | Explicit Source FEC Payload ID | 783 +------------------------------------+ 785 Figure 6: Structure of the FEC packet format for FEC source packets 787 The FEC source packets MUST be sent using the same ADU flow as would 788 have been used for the original source packets if the FEC Framework 789 were not present. The transport payload of the FEC source packet 790 MUST consist of the ADU followed by the Explicit Source FEC Payload 791 ID field, if required. 793 The Explicit Source FEC Payload ID field contains information 794 required to associate the source packet with a source block and for 795 the operation of the FEC algorithm, and is defined by the FEC scheme. 796 The format of the Source FEC Payload ID field is defined by the FEC 797 scheme. In the case that the FEC scheme or CDP defines a means to 798 derive the Source FEC Payload ID from other information in the packet 799 (for example a sequence number used by the application protocol), 800 then the Source FEC Payload ID field is not included in the packet. 801 In this case, the original source packet and FEC source packet are 802 identical. 804 In applications where avoidance of IP packet fragmentation is a goal, 805 CDPs SHOULD consider the Explicit Source FEC Payload ID size when 806 determining the size of ADUs that will be delivered using the FEC 807 Framework. This is because the addition of the Explicit Source FEC 808 Payload ID increases the packet length. 810 The Explicit Source FEC Payload ID is placed at the end of the packet 811 so that in the case that Robust Header Compression (ROHC) [RFC3095] 812 or other header compression mechanisms are used and in the case that 813 a ROHC profile is defined for the protocol carried within the 814 transport payload (for example RTP), then ROHC will still be applied 815 for the FEC source packets. Applications that are used with this 816 framework need to consider that FEC schemes can add this Explicit 817 Source FEC Payload ID and thereby increase the packet size. 819 In many applications, support for FEC is added to a pre-existing 820 protocol and in this case use of the Explicit Source FEC Payload ID 821 can break backwards compatibility, since source packets are modified. 823 5.3.1. Generic Explicit Source FEC Payload ID 825 In order to apply FEC protection using multiple FEC schemes to a 826 single source flow, all schemes have to use the same Explicit Source 827 FEC Payload ID format. In order to enable this, it is RECOMMENDED 828 that FEC schemes support the Generic Explicit Source FEC Payload ID 829 format described below. 831 The Generic Explicit Source FEC Payload ID has a length of two octets 832 and consists of an unsigned packet sequence number in network-byte 833 order. The allocation of sequence numbers to packets is independent 834 of any FEC scheme and of the source block construction, except that 835 the use of this sequence number places a constraint on source block 836 construction. Source packets within a given source block MUST have 837 consecutive sequence numbers (where consecutive includes wrap-around 838 from the maximum value which can be represented in two octets (65535) 839 to 0). Sequence numbers SHOULD NOT be reused until all values in the 840 sequence number space have been used. 842 5.4. Packet Format for FEC Repair Packets 844 The packet format for FEC repair packets is shown in Figure 7. The 845 transport payload consists of a Repair FEC Payload ID field followed 846 by repair data generated in the FEC encoding process. 848 +------------------------------------+ 849 | IP Header | 850 +------------------------------------+ 851 | Transport Header | 852 +------------------------------------+ 853 | Repair FEC Payload ID | 854 +------------------------------------+ 855 | Repair Symbols | 856 +------------------------------------+ 858 Figure 7: Packet format for repair packets 860 The Repair FEC Payload ID field contains information required for the 861 operation of the FEC algorithm at the receiver. This information is 862 defined by the FEC scheme. The format of the Repair FEC Payload ID 863 field is defined by the FEC scheme. 865 5.4.1. Packet Format for FEC Repair Packets over RTP 867 For FEC schemes which specify the use of RTP for repair packets, the 868 packet format for repair packets includes an RTP header as shown in 869 Figure 8. 871 +------------------------------------+ 872 | IP header | 873 +------------------------------------+ 874 | Transport Header (UDP) | 875 +------------------------------------+ 876 | RTP Header | 877 +------------------------------------+ 878 | Repair FEC Payload ID | 879 +------------------------------------+ 880 | Repair Symbols | 881 +------------------------------------+ 883 Figure 8: Packet format for repair packets 885 5.5. FEC Framework Configuration Information 887 The FEC Framework Configuration Information is information that the 888 FEC Framework needs in order to apply FEC protection to the ADU 889 flows. A complete CDP specification that uses the framework 890 specified here MUST include details of how this information is 891 derived and communicated between sender and receiver. 893 The FEC Framework Configuration Information includes identification 894 of the set of source flows. For example, in the case of UDP, each 895 source flow is uniquely identified by a tuple {Source IP address, 896 source UDP port, destination IP address, destination UDP port}. In 897 some applications some of these fields can contain wildcards, so that 898 the flow is identified by a subset of the fields. In particular, in 899 many applications the limited tuple {Destination IP address, 900 destination UDP port} is sufficient. 902 A single instance of the FEC Framework provides FEC protection for 903 packets of the specified set of source flows, by means of one or more 904 packet flows consisting of repair packets. The FEC Framework 905 Configuration Information includes, for each instance of the FEC 906 Framework: 908 1. Identification of the repair flows. 910 2. For each source flow protected by the repair flow(s): 912 A. Definition of the source flow. 914 B. An integer identifier for this flow definition (i.e., tuple). 915 This identifier MUST be unique amongst all source flows that 916 are protected by the same FEC repair flow. Integer 917 identifiers can be allocated starting from zero and 918 increasing by one for each flow. However, any random (but 919 still unique) allocation is also possible. A source flow 920 identifier need not be carried in source packets since source 921 packets are directly associated with a flow by virtue of 922 their packet headers. 924 3. The FEC Encoding ID, identifying the FEC scheme. 926 4. The length of the Explicit Source FEC Payload ID (in octets). 928 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, 929 each consisting of a name and a value where the valid element 930 names and value ranges are defined by the FEC scheme. 932 Multiple instances of the FEC Framework, with separate and 933 independent FEC Framework Configuration Information, can be present 934 at a sender or receiver. A single instance of the FEC Framework 935 protects packets of the source flows identified in (2) above, i.e., 936 all packets sent on those flows MUST be FEC source packets as defined 937 in Section 5.3. A single source flow can be protected by multiple 938 instances of the FEC Framework. 940 The integer flow identifier identified in (2b) above is a shorthand 941 to identify source flows between the FEC Framework and the FEC 942 scheme. The reason for defining this as an integer, and including it 943 in the FEC Framework Configuration Information is so that the FEC 944 scheme at the sender and receiver can use it to identify the source 945 flow with which a recovered packet is associated. The integer flow 946 identifier can therefore take the place of the complete flow 947 description (e.g., UDP 4-tuple). 949 Whether and how this flow identifier is used is defined by the FEC 950 scheme. Since repair packets can provide protection for multiple 951 source flows, repair packets would either not carry the identifier at 952 all or can carry multiple identifiers. However, in any case, the 953 flow identifier associated with a particular source packet can be 954 recovered from the repair packets as part of an FEC decoding 955 operation. 957 A single FEC repair flow provides repair packets for a single 958 instance of the FEC Framework. Other packets MUST NOT be sent within 959 this flow, i.e., all packets in the FEC repair flow MUST be FEC 960 repair packets as defined in Section 5.4 and MUST relate to the same 961 FEC Framework instance. 963 In the case that RTP is used for repair packets, the identification 964 of the repair packet flow can also include the RTP payload type to be 965 used for repair packets. 967 FSSI includes the information that is specific to the FEC scheme used 968 by the CDP. FSSI is used to communicate the information that cannot 969 be adequately represented otherwise and is essential for proper FEC 970 encoding and decoding operations. The motivation behind separating 971 the FSSI required only by the sender (which is carried in Sender-Side 972 FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of 973 the FSSI is to provide the receiver or the third party entities a 974 means of controlling the FEC operations at the sender. Any FSSI 975 other than the one solely required by the sender MUST be communicated 976 via the FSSI container. 978 The variable-length SS-FSSI and FSSI containers transmit the 979 information in textual representation and contain zero or more 980 distinct elements, whose descriptions are provided by the fully- 981 specified FEC schemes. 983 For the CDPs that choose the Session Description Protocol (SDP) 984 [RFC4566] as their session description protocol, the ABNF [RFC5234] 985 syntax for the SS-FSSI and FSSI containers is provided in Section 4.5 986 of [I-D.ietf-fecframe-sdp-elements]. 988 5.6. FEC Scheme Requirements 990 In order to be used with this framework, an FEC scheme MUST be 991 capable of processing data arranged into blocks of ADUs (source 992 blocks). 994 A specification for a new FEC scheme MUST include the following: 996 1. The FEC Encoding ID value that uniquely identifies the FEC 997 scheme. This value MUST be registered with IANA as described in 998 Section 10. 1000 2. The type, semantics and encoding format of the Repair FEC Payload 1001 ID. 1003 3. The name, type, semantics and text value encoding rules for zero 1004 or more FEC-Scheme-Specific Information elements. 1006 4. A full specification of the FEC code. 1008 This specification MUST precisely define the valid FEC-Scheme- 1009 Specific Information values, the valid FEC Payload ID values and 1010 the valid packet payload sizes (where packet payload refers to 1011 the space within a packet dedicated to carrying encoding 1012 symbols). 1014 Furthermore, given a source block as defined in Section 5.2, 1015 valid values of the FEC-Scheme-Specific Information, a valid 1016 Repair FEC Payload ID value and a valid packet payload size, the 1017 specification MUST uniquely define the values of the encoding 1018 symbols to be included in the repair packet payload of a packet 1019 with the given Repair FEC Payload ID value. 1021 A common and simple way to specify the FEC code to the required 1022 level of detail is to provide a precise specification of an 1023 encoding algorithm which, given a source block, valid values of 1024 the FEC-Scheme-Specific Information, a valid Repair FEC Payload 1025 ID value and a valid packet payload size as input produces the 1026 exact value of the encoding symbols as output. 1028 5. A description of practical encoding and decoding algorithms. 1030 This description need not be to the same level of detail as for 1031 the encoding above, however it has to be sufficient to 1032 demonstrate that encoding and decoding of the code is both 1033 possible and practical. 1035 FEC scheme specifications MAY additionally define the following: 1037 1. Type, semantics and encoding format of an Explicit Source FEC 1038 Payload ID. 1040 Whenever an FEC scheme specification defines an 'encoding format' for 1041 an element, this has to be defined in terms of a sequence of bytes 1042 which can be embedded within a protocol. The length of the encoding 1043 format MUST either be fixed or it MUST be possible to derive the 1044 length from examining the encoded bytes themselves. For example, the 1045 initial bytes can include some kind of length indication. 1047 FEC scheme specifications SHOULD use the terminology defined in this 1048 document and SHOULD follow the following format: 1050 1. Introduction 1053 2. Formats and Codes 1055 2.1 Source FEC Payload ID(s) 1059 2.2 Repair FEC Payload ID 1062 2.3 FEC Framework Configuration Information 1066 3. Procedures 1070 4. FEC Code Specification 1073 Specifications can include additional sections including examples. 1075 Each FEC scheme MUST be specified independently of all other FEC 1076 schemes; for example, in a separate specification or a completely 1077 independent section of larger specification (except, of course, a 1078 specification of one FEC scheme can include portions of another by 1079 reference). Where an RTP Payload Format is defined for repair data 1080 for a specific FEC scheme, the RTP Payload Format and the FEC scheme 1081 can be specified within the same document. 1083 6. Feedback 1085 Many applications require some kind of feedback on transport 1086 performance. E.g., how much data arrived at the receiver, at what 1087 rate and when? When FEC is added to such applications, feedback 1088 mechanisms can also need to be enhanced to report on the performance 1089 of the FEC. E.g., how much lost data was recovered by the FEC? 1091 When used to provide instrumentation for engineering purposes, it is 1092 important to remember that FEC is generally applied to relatively 1093 small blocks of data (in the sense that each block is transmitted 1094 over a relatively small period of time). Thus, feedback information 1095 that is averaged over longer periods of time will likely not provide 1096 sufficient information for engineering purposes. More detailed 1097 feedback over shorter time scales might be preferred. For example, 1098 for applications using RTP transport, see [RFC5725]. 1100 Applications which used feedback for congestion control purposes MUST 1101 calculate such feedback on the basis of packets received before FEC 1102 recovery is applied. If this requirement conflicts with other uses 1103 of the feedback information then the application MUST be enhanced to 1104 support both information calculated pre- and post- FEC recovery. 1105 This is to ensure that congestion control mechanisms operate 1106 correctly based on congestion indications received from the network, 1107 rather than on post-FEC recovery information which would give an 1108 inaccurate picture of congestion conditions. 1110 New applications which require such feedback SHOULD use RTP/RTCP 1111 [RFC3550]. 1113 7. Transport Protocols 1115 This framework is intended to be used to define CDPs that operate 1116 over transport protocols providing an unreliable datagram service, 1117 including in particular the User Datagram Protocol (UDP) and the 1118 Datagram Congestion Control Protocol (DCCP). 1120 8. Congestion Control 1122 This section starts with some informative background on the 1123 motivation of the normative requirements for congestion control, 1124 which are spelled out in Section 8.2. 1126 8.1. Motivation 1128 o The enforcement of congestion control principles has gained a lot 1129 of momentum in the IETF over the recent years. While the need for 1130 congestion control over the open Internet is unquestioned, and the 1131 goal of TCP friendliness is generally agreed for most (but not 1132 all) applications, the subject of congestion detection and 1133 measurement in heterogeneous networks can hardly be considered as 1134 solved. Most congestion control algorithms detect and measure 1135 congestion by taking (primarily or exclusively) the packet loss 1136 rate into account. This appears to be inappropriate in 1137 environments where a large percentage of the packet losses are the 1138 result of link-layer errors and independent of the network load. 1140 o The authors of this document are primarily interested in 1141 applications where the application reliability requirements and 1142 end-to-end reliability of the network differ, such that it 1143 warrants higher-layer protection of the packet stream, e.g., due 1144 to the presence of unreliable links in the end-to-end path and 1145 where real-time, scalability or other constraints prohibit the use 1146 of higher-layer (transport or application) feedback. A typical 1147 example for such applications is multicast and broadcast streaming 1148 or multimedia transmission over heterogeneous networks. In other 1149 cases, application reliability requirements can be so high that 1150 the required end-to-end reliability will be difficult to achieve. 1151 Furthermore, the end-to-end network reliability is not necessarily 1152 known in advance. 1154 o This FEC Framework is not defined, nor intended, as a QoS 1155 enhancement tool to combat losses resulting from highly congested 1156 networks. It should not be used for such purposes. 1158 o In order to prevent such mis-use, one approach is to leave 1159 standardization to bodies most concerned with the problem 1160 described above. However, the IETF defines base standards used by 1161 several bodies, including DVB, 3GPP, 3GPP2, all of which appear to 1162 share the environment and the problem described. 1164 o Another approach is to write a clear applicability statement. For 1165 example, one could restrict the use of this framework to networks 1166 with certain loss characteristics (e.g., wireless links). 1167 However, there can be applications where the use of FEC is 1168 justified to combat congestion-induced packet losses - 1169 particularly in lightly loaded networks, where congestion is the 1170 result of relatively rare random peaks in instantaneous traffic 1171 load - thereby intentionally violating congestion control 1172 principles. One possible example for such an application could be 1173 a no-matter-what, brute-force FEC protection of a traffic 1174 generated as an emergency signal. 1176 o A third approach is to require at a minimum that the use of this 1177 framework with any given application, in any given environment, 1178 does not cause congestion issues which the application alone would 1179 not itself cause, i.e., the use of this framework must not make 1180 things worse. 1182 o Taking above considerations into account, Section 8.2 specifies a 1183 small set of constraints for the FEC, which are mandatory for all 1184 senders compliant with this FEC Framework. Further restrictions 1185 can be imposed by certain CDPs. 1187 8.2. Normative Requirements 1189 o The bandwidth of FEC repair data MUST NOT exceed the bandwidth of 1190 the original source data being protected (without the possible 1191 addition of an Explicit Source FEC Payload ID). This disallows 1192 the (static or dynamic) use of excessively strong FEC to combat 1193 high packet loss rates, which can otherwise be chosen by naively 1194 implemented dynamic FEC-strength selection mechanisms. We 1195 acknowledge that there are a few exotic applications, e.g., IP 1196 traffic from space-based senders, or senders in certain hardened 1197 military devices, which could warrant a higher FEC strength. 1198 However, in this specification we give preference to the overall 1199 stability and network friendliness of average applications. 1201 o Whenever the source data rate is adapted due to the operation of 1202 congestion control mechanisms, the FEC repair data rate MUST be 1203 similarly adapted. 1205 9. Security Considerations 1207 The application of FEC protection to a stream does not provide any 1208 kind of security protection. 1210 If security services are required for the stream, then they MUST 1211 either be applied to the original source data before FEC protection 1212 is applied, or to both the source and repair data, after FEC 1213 protection has been applied. 1215 If integrity protection is applied to source packets before FEC 1216 protection is applied, and no further integrity protection is applied 1217 to repair packets, then a denial-of-service attack is possible if an 1218 attacker is in a position to inject fake repair transport payloads. 1219 If received by a receiver, such fake repair transport payloads could 1220 cause incorrect FEC decoding resulting in incorrect ADUs being passed 1221 up to the application protocol. A similar attack is possible if an 1222 attacker is in a position to inject fake FEC Framework Configuration 1223 Information or fake FEC Payload IDs. Such incorrect decoded ADUs 1224 would then be detected by the source integrity protection and 1225 discarded, resulting in partial or complete denial of service. 1226 Therefore, in such environments, integrity protection MUST also be 1227 applied to the FEC repair transport payloads, FEC Framework 1228 Configuration Information and FEC Payload IDs, for example using 1229 IPSec to integrity protect all packets. Receivers MUST also verify 1230 the integrity of source symbols before including the source symbols 1231 into the source block. 1233 It is possible that multiple streams with different confidentiality 1234 requirements (for example, the streams may be visible to different 1235 sets of users) can be FEC protected by a single repair stream. This 1236 scenario is not recommended, since resources will be used to 1237 distribute and FEC decode encrypted data which cannot then be 1238 decrypted by at least some receivers. However, in this scenario, 1239 confidentiality protection MUST be applied before FEC encoding of the 1240 streams, otherwise repair transport payload may be used by a receiver 1241 to decode unencrypted versions of source streams which they do not 1242 have permissions to access. 1244 10. IANA Considerations 1246 FEC schemes for use with this framework are identified in protocols 1247 using FEC Encoding IDs. Values of FEC Encoding IDs are subject to 1248 IANA registration. For this purposes, this document creates a new 1249 registry called FEC Framework (FECFRAME) FEC Encoding IDs. 1251 The values that can be assigned within the FEC Framework (FECFRAME) 1252 FEC Encoding ID registry are numeric indexes in the range [0, 255], 1253 boundaries included. Assignment requests are granted on an IETF 1254 Consensus basis as defined in [RFC5226]. Section 5.6 defines 1255 explicit requirements that documents defining new FEC Encoding IDs 1256 should meet. 1258 11. Acknowledgments 1260 This document is based in part on [I-D.watson-tsvwg-fec-sf] and so 1261 thanks are due to the additional authors of that document, Mike Luby, 1262 Magnus Westerlund and Stephan Wenger. That document was in turn 1263 based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and 1264 thus, thanks are also due to the participants in 3GPP TSG SA Working 1265 Group 4. Further thanks are due to the members of the FECFRAME 1266 Working Group for their comments and review. 1268 12. References 1270 12.1. Normative references 1272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1273 Requirement Levels", BCP 14, RFC 2119, March 1997. 1275 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1276 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1277 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1278 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1279 Compression (ROHC): Framework and four profiles: RTP, UDP, 1280 ESP, and uncompressed", RFC 3095, July 2001. 1282 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1283 Correction (FEC) Building Block", RFC 5052, August 2007. 1285 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1286 Jacobson, "RTP: A Transport Protocol for Real-Time 1287 Applications", STD 64, RFC 3550, July 2003. 1289 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1290 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1291 May 2008. 1293 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1294 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1296 12.2. Informative references 1298 [I-D.watson-tsvwg-fec-sf] 1299 Watson, M., "Forward Error Correction (FEC) Streaming 1300 Framework", draft-watson-tsvwg-fec-sf-00 (work in 1301 progress), July 2005. 1303 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 1304 Report Block Type for RTP Control Protocol (RTCP) Extended 1305 Reports (XRs)", RFC 5725, February 2010. 1307 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1308 Description Protocol", RFC 4566, July 2006. 1310 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1311 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1312 July 2006. 1314 [I-D.ietf-fecframe-sdp-elements] 1315 Begen, A., "Session Description Protocol Elements for FEC 1316 Framework", draft-ietf-fecframe-sdp-elements-11 (work in 1317 progress), October 2010. 1319 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1320 Protocols and codecs", 3GPP TS 26.346, April 2005. 1322 Authors' Addresses 1324 Mark Watson 1325 Netflix, Inc. 1326 100 Winchester Circle 1327 Los Gatos, CA 95032 1328 USA 1330 Email: watsonm@netflix.com 1332 Ali Begen 1333 Cisco 1334 181 Bay Street 1335 Toronto, ON M5J 2T3 1336 Canada 1338 Email: abegen@cisco.com