idnits 2.17.1 draft-roca-tsvwg-fecframev2-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6363]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC6363, but the abstract doesn't seem to directly say this. It does mention RFC6363 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 73 has weird spacing: '...eration with ...' -- The document date (July 4, 2016) is 2853 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) == Missing Reference: 'RFC6681' is mentioned on line 137, but not defined == Missing Reference: 'RFC6816' is mentioned on line 137, but not defined == Missing Reference: 'RFC6865' is mentioned on line 137, but not defined ** 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 (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG V. Roca 3 Internet-Draft INRIA 4 Obsoletes: 6363 (if approved) M. Watson 5 Intended status: Standards Track Netflix, Inc. 6 Expires: January 5, 2017 A. Begen 7 Networked Media 8 July 4, 2016 10 Forward Error Correction (FEC) Framework version 2 11 draft-roca-tsvwg-fecframev2-00 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) that 24 is compliant with various requirements defined in this document. 25 Thus, Content Delivery Protocols can be defined that are not specific 26 to a particular FEC scheme, and FEC schemes can be defined that are 27 not specific to a particular Content Delivery Protocol. The first 28 version of FECFRAME defined in [RFC6363] was restricted to block FEC 29 codes. The FECFRAME version 2 defined in this document adds the 30 possibility to use Convolutional FEC Codes in addition to Block FEC 31 Codes. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 5, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 69 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 8 70 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 12 71 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.2. Sender Operation with Block FEC Codes . . . . . . . . . . 14 73 4.3. Receiver Operation with Block FEC Codes . . . . . . . . 16 74 4.4. Sender Operation with Convolutional FEC Codes . . . . . . 19 75 4.5. Receiver Operation with Convolutional FEC Codes . . . . . 22 76 5. Protocol Specification . . . . . . . . . . . . . . . . . . . 23 77 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 5.2. Structure of the Source Block with Block FEC Codes . . . 24 79 5.3. Packet Format for FEC Source Packets . . . . . . . . . . 24 80 5.3.1. Generic Explicit Source FEC Payload ID . . . . . . . 25 81 5.4. Packet Format for FEC Repair Packets . . . . . . . . . . 26 82 5.4.1. Packet Format for FEC Repair Packets over RTP . . . . 27 83 5.5. FEC Framework Configuration Information . . . . . . . . . 27 84 5.6. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 29 85 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 31 86 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 32 87 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 32 88 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 32 89 8.2. Normative Requirements . . . . . . . . . . . . . . . . . 33 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 91 9.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 34 92 9.2. Attacks against the Data Flows . . . . . . . . . . . . . 36 93 9.2.1. Access to Confidential Content . . . . . . . . . . . 36 94 9.2.2. Content Corruption . . . . . . . . . . . . . . . . . 37 95 9.3. Attacks against the FEC Parameters . . . . . . . . . . . 38 96 9.4. When Several Source Flows Are to Be Protected Together . 38 97 9.5. Baseline Secure FEC Framework Operation . . . . . . . . . 39 99 10. Operations and Management Considerations . . . . . . . . . . 40 100 10.1. What Are the Key Aspects to Consider? . . . . . . . . . 40 101 10.2. Operational and Management Recommendations . . . . . . . 41 102 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 103 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 105 13.1. Normative References . . . . . . . . . . . . . . . . . . 44 106 13.2. Informative References . . . . . . . . . . . . . . . . . 45 107 Appendix A. Possible management within a FEC Scheme of the 108 Encoding Window with Convolutional FEC Codes (non 109 Normative) . . . . . . . . . . . . . . . . . . . . . 48 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 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 that do not provide guaranteed packet 117 delivery. Primary examples are real-time, or streaming, media 118 applications such as broadcast, multicast, or on-demand forms of 119 audio, video, or multimedia. 121 Forward Error Correction (FEC) is a well-known technique for 122 improving the reliability of packet transmission over networks that 123 do not provide guaranteed packet delivery, especially in multicast 124 and broadcast applications. The FEC Building Block, defined in 125 [RFC5052], provides a framework for the definition of Content 126 Delivery Protocols (CDPs) for object delivery (including, primarily, 127 file delivery) that make use of separately defined FEC schemes. Any 128 CDP defined according to the requirements of the FEC Building Block 129 can then easily be used with any FEC scheme that is also defined 130 according to the requirements of the FEC Building Block. However 131 [RFC5052] is restricted to block FEC codes, which means that the 132 input flow(s) MUST be segmented into a sequence of blocks: FEC 133 encoding (at a sender/coding node) must be performed on a per-block 134 basis, and decoding (at a receiver/decoding node) MUST be performed 135 independently on a per-block basis. This approach has a major impact 136 on coding and decoding delays when used with block FEC codes (e.g., 137 [RFC6681], [RFC6816] or [RFC6865]) since encoding requires that all 138 the source symbols be known at the encoder. In case of continuous 139 input flow(s), even if source symbols can be sent immediately, repair 140 symbols are naturally delayed by the block creation time, that 141 directly depends on the block size (i.e., the number of source 142 symbols in this block, k). This block creation time is also the 143 minimum decoding latency any receiver will experience in case of 144 erasures, since no repair symbol for the current block can be 145 received before. A good value for the block size is necessarily a 146 good balance between the minimum decoding latency at the receivers 147 (which must be in line with the most stringent real-time requirement 148 of the flow(s)) and the desired robustness against long erasure 149 bursts (which depends on the block size). 151 On the opposite, a convolutional code associated to a sliding 152 encoding window (of fixed size) or a sliding elastic encoding window 153 (of variable size) removes this minimum decoding delay, since repair 154 symbols can be generated and sent on-the-fly, at any time, from the 155 source symbols present in the current coding window. Using a sliding 156 encoding window mode is therefore highly beneficial to real-time 157 flows, one of the primary targets of FECFRAME. 158 [FECFRAMEv2-Motivations] discusses more in detail the motivations 159 behind this document. 161 Note that the term "Forward Erasure Correction" is sometimes used, 162 erasures being a type of error in which data is lost and this loss 163 can be detected, rather than being received in corrupted form. The 164 focus of this document is strictly on erasures, and the term "Forward 165 Error Correction" is more widely used. 167 This document defines a framework for the definition of CDPs that 168 provide for FEC protection for arbitrary packet flows over unreliable 169 transports such as UDP, using either block FEC codes as in [RFC6363] 170 (i.e., the original FECFRAME, also called FECFRAME version 1 in this 171 document), or convolutional FEC codes that is specific to FECFRAME 172 version 2 described in this document. As such, when used with block 173 FEC codes, this document complements the FEC Building Block of 174 [RFC5052], by providing for the case of arbitrary packet flows over 175 unreliable transport, the same kind of framework as that document 176 provides for object delivery. This document does not define a 177 complete CDP; rather, it defines only those aspects that are expected 178 to be common to all CDPs based on this framework. 180 This framework does not define how the flows to be protected are 181 determined, nor does it define how the details of the protected flows 182 and the FEC streams that protect them are communicated from sender to 183 receiver. It is expected that any complete CDP specification that 184 makes use of this framework will address these signaling 185 requirements. However, this document does specify the information 186 that is required by the FEC Framework at the sender and receiver, 187 e.g., details of the flows to be FEC protected, the flow(s) that will 188 carry the FEC protection data, and an opaque container for FEC- 189 Scheme-Specific Information. 191 FEC schemes designed for use with this framework must fulfill a 192 number of requirements defined in this document. These requirements 193 are different from those defined in [RFC5052] for FEC schemes for 194 object delivery. However, there is a great deal of commonality, and 195 FEC schemes defined for object delivery may be easily adapted for use 196 with the framework defined in this document. 198 Since RTP [RFC3550] is (often) used over UDP, this framework can be 199 applied to RTP flows as well. FEC repair packets may be sent 200 directly over UDP or RTP. The latter approach has the advantage that 201 RTP instrumentation, based on the RTP Control Protocol (RTCP), can be 202 used for the repair flow. Additionally, the post-repair RTCP 203 extended reports [RFC5725] may be used to obtain information about 204 the loss rate after FEC recovery. 206 The use of RTP for repair flows is defined for each FEC scheme by 207 defining an RTP payload format for that particular FEC scheme 208 (possibly in the same document). 210 Editor's notes: 212 o FECFRAME does not define any header/trailer (but FEC Schemes do) 213 and there is no "version" field that could be used to signal this 214 is FECFRAME version 2 and not version 1. The notion of "version" 215 remains therefore purely abstract and could be removed altogether 216 without affecting FECFRAME interoperability at all. An FEC Scheme 217 for a convolutional FEC code will be unsupported by a receiver 218 that only supports FECFRAME "version 1" FEC Schemes and this 219 repair flow will be ignored. This is exactly the same behavior 220 when a receiver wants to join a FECFRAME "version 1" session for 221 which the repair flow uses an unsupported "block" FEC Scheme. 222 "Version 2" of FECFRAME extends the applicability of FECFRAME to 223 new types of FEC codes in a fully backward compatible way. 224 However, supporting these new FEC codes does impact the FECFRAME 225 software: implementation is seriously impacted due to different 226 working modes, the notion of sliding encoding/decoding window 227 blocks being added to that of source block. Therefore, the notion 228 of "version" could be used to distinguish FECFRAME implementations 229 in addition/replacement to the associated RFC number, or could be 230 ignored if one prefers to keep a higher level view. The current 231 document uses the notion of version for the sake of clarity. 233 o Writing an I-D equivalent to [RFC5052] and focused on 234 convolutional FEC codes remains to be done. 236 2. Definitions and Abbreviations 238 Application Data Unit (ADU): The unit of source data provided as 239 payload to the transport layer. 241 ADU Flow: A sequence of ADUs associated with a transport-layer 242 flow identifier (such as the standard 5-tuple {source IP address, 243 source port, destination IP address, destination port, transport 244 protocol}). 246 AL-FEC: Application-layer Forward Error Correction. 248 Application Protocol: Control protocol used to establish and 249 control the source flow being protected, e.g., the Real-Time 250 Streaming Protocol (RTSP). 252 Content Delivery Protocol (CDP): A complete application protocol 253 specification that, through the use of the framework defined in 254 this document, is able to make use of FEC schemes to provide FEC 255 capabilities. 257 FEC Code: An algorithm for encoding data such that the encoded 258 data flow is resilient to data loss. Note that, in general, FEC 259 codes may also be used to make a data flow resilient to 260 corruption, but that is not considered in this document. 262 Block FEC Code: FEC Code that operate in a block manner, i.e., for 263 which the input flow MUST be segmented into a sequence of blocks, 264 FEC encoding and decoding being performed independently on a per- 265 block basis. 267 Convolutional FEC Code: FEC Code that can generate repair symbols 268 on-the-fly, at any time, from the source symbols present in the 269 current encoding window. 271 FEC Framework: A protocol framework for the definition of Content 272 Delivery Protocols using FEC, such as the framework defined in 273 this document. 275 FEC Framework Configuration Information: Information that controls 276 the operation of the FEC Framework. 278 FEC Payload ID: Information that identifies the contents of a 279 packet with respect to the FEC scheme. 281 FEC Repair Packet: At a sender (respectively, at a receiver), a 282 payload submitted to (respectively, received from) the transport 283 protocol containing one or more repair symbols along with a Repair 284 FEC Payload ID and possibly an RTP header. 286 FEC Scheme: A specification that defines the additional protocol 287 aspects required to use a particular FEC code with the FEC 288 Framework. 290 FEC Source Packet: At a sender (respectively, at a receiver), a 291 payload submitted to (respectively, received from) the transport 292 protocol containing an ADU along with an optional Explicit Source 293 FEC Payload ID. 295 Protection Amount: The relative increase in data sent due to the 296 use of FEC. 298 Repair Flow: The packet flow carrying FEC data. 300 Repair FEC Payload ID: A FEC Payload ID specifically for use with 301 repair packets. 303 Source Flow: The packet flow to which FEC protection is to be 304 applied. A source flow consists of ADUs. 306 Source FEC Payload ID: A FEC Payload ID specifically for use with 307 source packets. 309 Source Protocol: A protocol used for the source flow being 310 protected, e.g., RTP. 312 Transport Protocol: The protocol used for the transport of the 313 source and repair flows, e.g., UDP and the Datagram Congestion 314 Control Protocol (DCCP). 316 Encoding Window: Set of Source Symbols available at the sender/ 317 coding node that are used to generate a repair symbol, with a 318 Convolutional FEC Code. 320 Decoding Window: Set of received or decoded source and repair 321 symbols available at a receiver that are used to decode erased 322 source symbols, with a Convolutional FEC Code. 324 The following definitions are aligned with [RFC5052]. Unless 325 otherwise mentioned, they apply both to Block and Convolutional FEC 326 Codes: 328 Code Rate: The ratio between the number of source symbols and the 329 number of encoding symbols. By definition, the code rate is such 330 that 0 < code rate <= 1. A code rate close to 1 indicates that a 331 small number of repair symbols have been produced during the 332 encoding process. 334 Encoding Symbol: Unit of data generated by the encoding process. 335 With systematic codes, source symbols are part of the encoding 336 symbols. 338 Packet Erasure Channel: A communication path where packets are 339 either dropped (e.g., by a congested router, or because the number 340 of transmission errors exceeds the correction capabilities of the 341 physical-layer codes) or received. When a packet is received, it 342 is assumed that this packet is not corrupted. 344 Repair Symbol: Encoding symbol that is not a source symbol. 346 Source Block: Group of ADUs that are to be FEC protected as a 347 single block. This notion is restricted to Block FEC Codes. 349 Source Symbol: Unit of data used during the encoding process. 351 Systematic Code: FEC code in which the source symbols are part of 352 the encoding symbols. 354 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 355 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 356 document are to be interpreted as described in [RFC2119]. 358 3. Architecture Overview 360 The FEC Framework is described in terms of an additional layer 361 between the transport layer (e.g., UDP or DCCP) and protocols running 362 over this transport layer. As such, the data path interface between 363 the FEC Framework and both underlying and overlying layers can be 364 thought of as being the same as the standard interface to the 365 transport layer; i.e., the data exchanged consists of datagram 366 payloads each associated with a single ADU flow identified by the 367 standard 5-tuple {source IP address, source port, destination IP 368 address, destination port, transport protocol}. In the case that RTP 369 is used for the repair flows, the source and repair data can be 370 multiplexed using RTP onto a single UDP flow and needs to be 371 consequently demultiplexed at the receiver. There are various ways 372 in which this multiplexing can be done (for example, as described in 373 [RFC4588]). 375 It is important to understand that the main purpose of the FEC 376 Framework architecture is to allocate functional responsibilities to 377 separately documented components in such a way that specific 378 instances of the components can be combined in different ways to 379 describe different protocols. 381 The FEC Framework makes use of a FEC scheme, in a similar sense to 382 that defined in [RFC5052] in case of Block FEC Codes, and uses the 383 terminology of that document. The FEC scheme defines the FEC 384 encoding and decoding, and it defines the protocol fields and 385 procedures used to identify packet payload data in the context of the 386 FEC scheme. The interface between the FEC Framework and a FEC 387 scheme, which is described in this document, is a logical one that 388 exists for specification purposes only. At an encoder, the FEC 389 Framework passes ADUs to the FEC scheme for FEC encoding. The FEC 390 scheme returns repair symbols with their associated Repair FEC 391 Payload IDs and, in some cases, Source FEC Payload IDs, depending on 392 the FEC scheme. At a decoder, the FEC Framework passes transport 393 packet payloads (source and repair) to the FEC scheme, and the FEC 394 scheme returns additional recovered source packet payloads. 396 This document defines certain FEC Framework Configuration Information 397 that MUST be available to both sender and receiver(s). For example, 398 this information includes the specification of the ADU flows that are 399 to be FEC protected, specification of the ADU flow(s) that will carry 400 the FEC protection (repair) data, and the relationship(s) between 401 these source and repair flows (i.e., which source flow(s) are 402 protected by repair flow(s)). The FEC Framework Configuration 403 Information also includes information fields that are specific to the 404 FEC scheme. This information is analogous to the FEC Object 405 Transmission Information defined in [RFC5052]. 407 The FEC Framework does not define how the FEC Framework Configuration 408 Information for the stream is communicated from sender to receiver. 409 This has to be defined by any CDP specification, as described in the 410 following sections. 412 In this architecture, we assume that the interface to the transport 413 layer supports the concepts of data units (referred to here as 414 Application Data Units (ADUs)) to be transported and identification 415 of ADU flows on which those data units are transported. Since this 416 is an interface internal to the architecture, we do not specify this 417 interface explicitly. We do require that ADU flows that are distinct 418 from the transport layer point of view (for example, distinct UDP 419 flows as identified by the UDP source/destination addresses/ports) 420 are also distinct on the interface between the transport layer and 421 the FEC Framework. 423 As noted above, RTP flows are a specific example of ADU flows that 424 might be protected by the FEC Framework. From the FEC Framework 425 point of view, RTP source flows are ADU flows like any other, with 426 the RTP header included within the ADU. 428 Depending on the FEC scheme, RTP can also be used as a transport for 429 repair packet flows. In this case, a FEC scheme has to define an RTP 430 payload format for the repair data. 432 The architecture outlined above is illustrated in Figure 1. In this 433 architecture, two (optional) RTP instances are shown, for the source 434 and repair data, respectively. This is because the use of RTP for 435 the source data is separate from, and independent of, the use of RTP 436 for the repair data. The appearance of two RTP instances is more 437 natural when one considers that in many FEC codes, the repair payload 438 contains repair data calculated across the RTP headers of the source 439 packets. Thus, a repair packet carried over RTP starts with an RTP 440 header of its own, which is followed (after the Repair Payload ID) by 441 repair data containing bytes that protect the source RTP headers (as 442 well as repair data for the source RTP payloads). 444 +--------------------------------------------+ 445 | Application | 446 +--------------------------------------------+ 447 | 448 | 449 | 450 + - - - - - - - - - - - - - - - - - - - - - - - -+ 451 | +--------------------------------------------+ | 452 | Application Layer | 453 | +--------------------------------------------+ | 454 | | 455 | + -- -- -- -- -- -- -- -- -- -- --+ | | 456 | RTP (Optional) | | 457 | | | |- Configuration/ 458 +- -- -- -- -- -- -- -- -- -- -- -+ | Coordination 459 | | | | 460 | ADU flows | 461 | | v | 462 +--------------------------------------------+ +------------+ 463 | | FEC Framework (This document) |<--->| FEC Scheme | 464 +--------------------------------------------+ +------------+ 465 | | | | 466 Source | Repair | 467 | | | | 468 +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ 469 | | RTP Layer | | RTP Processing | | | 470 | (Optional) | +-- -- -- |- -- -+ | 471 | | +-- -- -- -- -- -- -- |--+ | | 472 | | RTP (De)multiplexing | | 473 | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | 474 | 475 | +--------------------------------------------+ | 476 | Transport Layer (e.g., UDP) | 477 | +--------------------------------------------+ | 478 | 479 | +--------------------------------------------+ | 480 | IP | 481 | +--------------------------------------------+ | 483 | Content Delivery Protocol | 484 + - - - - - - - - - - - - - - - - - - - - - - - + 486 Figure 1: FEC Framework Architecture 488 The content of the transport payload for repair packets is fully 489 defined by the FEC scheme. For a specific FEC scheme, a means MAY be 490 defined for repair data to be carried over RTP, in which case, the 491 repair packet payload format starts with the RTP header. This 492 corresponds to defining an RTP payload format for the specific FEC 493 scheme. 495 The use of RTP for repair packets is independent of the protocols 496 used for source packets: if RTP is used for source packets, repair 497 packets may or may not use RTP and vice versa (although it is 498 unlikely that there are useful scenarios where non-RTP source flows 499 are protected by RTP repair flows). FEC schemes are expected to 500 recover entire transport payloads for recovered source packets in all 501 cases. For example, if RTP is used for source flows, the FEC scheme 502 is expected to recover the entire UDP payload, including the RTP 503 header. 505 4. Procedural Overview 507 4.1. General 509 The mechanism defined in this document does not place any 510 restrictions on the ADUs that can be protected together, except that 511 the ADU be carried over a supported transport protocol (see 512 Section 7). The data can be from multiple source flows that are 513 protected jointly. For instance, with a Block FEC Code, the FEC 514 Framework handles the source flows as a sequence of source blocks 515 each consisting of a set of ADUs, possibly from multiple source flows 516 that are to be protected together. For example, each source block 517 can be constructed from those ADUs related to a particular segment in 518 time of the flow. 520 At the sender, with a Block FEC Code, the FEC Framework passes the 521 payloads for a given block to the FEC scheme for FEC encoding. With 522 a Convolutional FEC Code, the FEC Framework passes the payloads 523 currently present in the Encoding Window to the FEC scheme for FEC 524 encoding. Then the FEC scheme performs the FEC encoding operation 525 and returns the following information: 527 o Optionally, FEC Payload IDs for each of the source payloads 528 (encoded according to a FEC-Scheme-Specific format). 530 o One or more FEC repair packet payloads. 532 o FEC Payload IDs for each of the repair packet payloads (encoded 533 according to a FEC-Scheme-Specific format). 535 The FEC Framework then performs two operations. First, it appends 536 the Source FEC Payload IDs, if provided, to each of the ADUs, and 537 sends the resulting packets, known as "FEC source packets", to the 538 receiver. Second, it places the provided FEC repair packet payloads 539 and corresponding Repair FEC Payload IDs appropriately to construct 540 FEC repair packets and send them to the receiver. 542 This document does not define how the sender determines which ADUs 543 are included in which source blocks (in case of a Block FEC Code) or 544 in the Encoding Window (in case of a Convolutional FEC Code), or the 545 sending order and timing of FEC source and repair packets. A 546 specific CDP MAY define this mapping, or it MAY be left as 547 implementation dependent at the sender. However, a CDP specification 548 MUST define how a receiver determines a minimum length of time that 549 it needs to wait to receive FEC repair packets for any given source 550 block. FEC schemes MAY define limitations on this mapping (such as 551 maximum size of source blocks with a Block FEC Code), but they SHOULD 552 NOT attempt to define specific mappings. The sequence of operations 553 at the sender is described in more detail in Section 4.2. 555 At the receiver, original ADUs are recovered by the FEC Framework 556 directly from any FEC source packets received simply by removing the 557 Source FEC Payload ID, if present. The receiver also passes the 558 contents of the received ADUs, plus their FEC Payload IDs, to the FEC 559 scheme for possible decoding. 561 If any ADUs have been lost, then the FEC scheme can perform FEC 562 decoding to recover the missing ADUs (assuming sufficient FEC source 563 and repair packets related to that source block have been received). 565 Note that the receiver might need to buffer received source packets 566 to allow time for the FEC repair packets to arrive and FEC decoding 567 to be performed before some or all of the received or recovered 568 packets are passed to the application. If such a buffer is not 569 provided, then the application has to be able to deal with the severe 570 re-ordering of packets that can occur. However, such buffering is 571 CDP- and/or implementation-specific and is not specified here. The 572 receiver operation is described in more detail in Section 4.3. 574 With a Block FEC Code, the FEC source packets MUST contain 575 information that identifies the source block and the position within 576 the source block (in terms specific to the FEC scheme) occupied by 577 the ADU. Similarly, with a Convolutional FEC Code, the FEC source 578 packet MUST contain information to identify the position within the 579 source flow (in terms specific to the FEC scheme) occupied by the 580 ADU. In both cases this information is known as the Source FEC 581 Payload ID. The FEC scheme is responsible for defining and 582 interpreting this information. This information MAY be encoded into 583 a specific field within the FEC source packet format defined in this 584 specification, called the Explicit Source FEC Payload ID field. The 585 exact contents and format of the Explicit Source FEC Payload ID field 586 are defined by the FEC schemes. Alternatively, the FEC scheme MAY 587 define how the Source FEC Payload ID is derived from other fields 588 within the source packets. This document defines the way that the 589 Explicit Source FEC Payload ID field is appended to source packets to 590 form FEC source packets. 592 With a Block FEC Code, the FEC repair packets MUST contain 593 information that identifies the source block and the relationship 594 between the contained repair payloads and the original source block. 595 Similarly, with a Convolutional FEC Code, the FEC repair packets MUST 596 contain information that identifies the relationship between the 597 contained repair payloads and the original source symbols used during 598 encoding. In both cases this is known as the Repair FEC Payload ID. 599 This information MUST be encoded into a specific field, the Repair 600 FEC Payload ID field, the contents and format of which are defined by 601 the FEC schemes. 603 The FEC scheme MAY use different FEC Payload ID field formats for 604 source and repair packets. 606 4.2. Sender Operation with Block FEC Codes 608 It is assumed that the sender has constructed or received original 609 data packets for the session. These could be carrying any type of 610 data. The following operations, illustrated in Figure 2 for the case 611 of UDP repair flows and in Figure 3 for the case of RTP repair flows, 612 describe a possible way to generate compliant source and repair 613 flows: 615 1. ADUs are provided by the application. 617 2. A source block is constructed as specified in Section 5.2. 619 3. The source block is passed to the FEC scheme for FEC encoding. 620 The Source FEC Payload ID information of each source packet is 621 determined by the FEC scheme. If required by the FEC scheme, the 622 Source FEC Payload ID is encoded into the Explicit Source FEC 623 Payload ID field. 625 4. The FEC scheme performs FEC encoding, generating repair packet 626 payloads from a source block and a Repair FEC Payload ID field 627 for each repair payload. 629 5. The Explicit Source FEC Payload IDs (if used), Repair FEC Payload 630 IDs, and repair packet payloads are provided back from the FEC 631 scheme to the FEC Framework. 633 6. The FEC Framework constructs FEC source packets according to 634 Section 5.3, and FEC repair packets according to Section 5.4, 635 using the FEC Payload IDs and repair packet payloads provided by 636 the FEC scheme. 638 7. The FEC source and repair packets are sent using normal 639 transport-layer procedures. The port(s) and multicast group(s) 640 to be used for FEC repair packets are defined in the FEC 641 Framework Configuration Information. The FEC source packets are 642 sent using the same ADU flow identification information as would 643 have been used for the original source packets if the FEC 644 Framework were not present (for example, in the UDP case, the UDP 645 source and destination addresses and ports on the IP datagram 646 carrying the source packet will be the same whether or not the 647 FEC Framework is applied). 649 +----------------------+ 650 | Application | 651 +----------------------+ 652 | 653 |(1) ADUs 654 | 655 v 656 +----------------------+ +----------------+ 657 | FEC Framework | | | 658 | |-------------------------->| FEC Scheme | 659 |(2) Construct source |(3) Source Block | | 660 | blocks | |(4) FEC Encoding| 661 |(6) Construct FEC |<--------------------------| | 662 | source and repair | | | 663 | packets |(5) Explicit Source FEC | | 664 +----------------------+ Payload IDs +----------------+ 665 | Repair FEC Payload IDs 666 | Repair symbols 667 | 668 |(7) FEC source and repair packets 669 v 670 +----------------------+ 671 | Transport Layer | 672 | (e.g., UDP) | 673 +----------------------+ 675 Figure 2: Sender Operation with Block FEC Codes 677 +----------------------+ 678 | Application | 679 +----------------------+ 680 | 681 |(1) ADUs 682 | 683 v 684 +----------------------+ +----------------+ 685 | FEC Framework | | | 686 | |-------------------------->| FEC Scheme | 687 |(2) Construct source |(3) Source Block | | 688 | blocks | |(4) FEC Encoding| 689 |(6) Construct FEC |<--------------------------| | 690 | source packets and| | | 691 | repair payloads |(5) Explicit Source FEC | | 692 +----------------------+ Payload IDs +----------------+ 693 | | Repair FEC Payload IDs 694 | | Repair symbols 695 | | 696 |(7) Source |(7') Repair payloads 697 | packets | 698 | | 699 | + -- -- -- -- -+ 700 | | RTP | 701 | +-- -- -- -- --+ 702 v v 703 +----------------------+ 704 | Transport Layer | 705 | (e.g., UDP) | 706 +----------------------+ 708 Figure 3: Sender Operation with RTP Repair Flows with Block FEC Codes 710 4.3. Receiver Operation with Block FEC Codes 712 The following describes a possible receiver algorithm, illustrated in 713 Figures 4 and 5 for the case of UDP and RTP repair flows, 714 respectively, when receiving a FEC source or repair packet: 716 1. FEC source packets and FEC repair packets are received and passed 717 to the FEC Framework. The type of packet (source or repair) and 718 the source flow to which it belongs (in the case of source 719 packets) are indicated by the ADU flow information, which 720 identifies the flow at the transport layer. 722 In the special case that RTP is used for repair packets, and 723 source and repair packets are multiplexed onto the same UDP flow, 724 then RTP demultiplexing is required to demultiplex source and 725 repair flows. However, RTP processing is applied only to the 726 repair packets at this stage; source packets continue to be 727 handled as UDP payloads (i.e., including their RTP headers). 729 2. The FEC Framework extracts the Explicit Source FEC Payload ID 730 field (if present) from the source packets and the Repair FEC 731 Payload ID from the repair packets. 733 3. The Explicit Source FEC Payload IDs (if present), Repair FEC 734 Payload IDs, and FEC source and repair payloads are passed to the 735 FEC scheme. 737 4. The FEC scheme uses the received FEC Payload IDs (and derived FEC 738 Source Payload IDs in the case that the Explicit Source FEC 739 Payload ID field is not used) to group source and repair packets 740 into source blocks. If at least one source packet is missing 741 from a source block, and at least one repair packet has been 742 received for the same source block, then FEC decoding can be 743 performed in order to recover missing source payloads. The FEC 744 scheme determines whether source packets have been lost and 745 whether enough data for decoding of any or all of the missing 746 source payloads in the source block has been received. 748 5. The FEC scheme returns the ADUs to the FEC Framework in the form 749 of source blocks containing received and decoded ADUs and 750 indications of any ADUs that were missing and could not be 751 decoded. 753 6. The FEC Framework passes the received and recovered ADUs to the 754 application. 756 The description above defines functionality responsibilities but does 757 not imply a specific set of timing relationships. Source packets 758 that are correctly received and those that are reconstructed MAY be 759 delivered to the application out of order and in a different order 760 from the order of arrival at the receiver. Alternatively, buffering 761 and packet re-ordering MAY be applied to re-order received and 762 reconstructed source packets into the order they were placed into the 763 source block, if that is necessary according to the application. 765 +----------------------+ 766 | Application | 767 +----------------------+ 768 ^ 769 | 770 |(6) ADUs 771 | 772 +----------------------+ +----------------+ 773 | FEC Framework | | | 774 | |<--------------------------| FEC Scheme | 775 |(2)Extract FEC Payload|(5) ADUs | | 776 | IDs and pass IDs & | |(4) FEC Decoding| 777 | payloads to FEC |-------------------------->| | 778 | scheme |(3) Explicit Source FEC | | 779 +----------------------+ Payload IDs +----------------+ 780 ^ Repair FEC Payload IDs 781 | Source payloads 782 | Repair payloads 783 | 784 |(1) FEC source and repair packets 785 | 786 +----------------------+ 787 | Transport Layer | 788 | (e.g., UDP) | 789 +----------------------+ 791 Figure 4: Receiver Operation with Block FEC Codes or Convolutional 792 FEC Codes 794 +----------------------+ 795 | Application | 796 +----------------------+ 797 ^ 798 | 799 |(6) ADUs 800 | 801 +----------------------+ +----------------+ 802 | FEC Framework | | | 803 | |<--------------------------| FEC Scheme | 804 |(2)Extract FEC Payload|(5) ADUs | | 805 | IDs and pass IDs & | |(4) FEC Decoding| 806 | payloads to FEC |-------------------------->| | 807 | scheme |(3) Explicit Source FEC | | 808 +----------------------+ Payload IDs +----------------+ 809 ^ ^ Repair FEC Payload IDs 810 | | Source payloads 811 | | Repair payloads 812 | | 813 |Source |Repair payloads 814 |packets | 815 | | 816 +-- |- -- -- -- -- -- -+ 817 |RTP| | RTP Processing | 818 | | +-- -- -- --|-- -+ 819 | +-- -- -- -- -- |--+ | 820 | | RTP Demux | | 821 +-- -- -- -- -- -- -- -+ 822 ^ 823 |(1) FEC source and repair packets 824 | 825 +----------------------+ 826 | Transport Layer | 827 | (e.g., UDP) | 828 +----------------------+ 830 Figure 5: Receiver Operation with RTP Repair Flows with Block FEC 831 Codes or Convolutional FEC Codes 833 Note that the above procedure might result in a situation in which 834 not all ADUs are recovered. 836 4.4. Sender Operation with Convolutional FEC Codes 838 Let us now consider FECFRAME version 2 using a Convolutional FEC 839 Code. The following operations, illustrated in Figure 6 for the case 840 of UDP repair flows and in Figure 7 for the case of RTP repair flows, 841 describe a possible way to generate compliant source and repair 842 flows: 844 1. A new ADU is provided by the application. 846 2. The FEC Framework communicates this ADU to the FEC scheme. 848 3. The (sliding) encoding window is updated by the FEC scheme. The 849 ADU to source symbols mapping as well as the encoding window 850 management details are the responsibility of the FEC scheme. 851 However Appendix A provide some hints on the way it might be 852 performed. 854 4. The Source FEC Payload ID information of the source packet is 855 determined by the FEC scheme. If required by the FEC scheme, 856 the Source FEC Payload ID is encoded into the Explicit Source 857 FEC Payload ID field and returned to the FEC Framework. 859 5. The FEC Framework constructs the FEC source packet according to 860 Section 5.3, using the Explicit Source FEC Payload ID provided 861 by the FEC scheme if applicable. 863 6. The FEC source packet is sent using normal transport-layer 864 procedures. This packet is sent using the same ADU flow 865 identification information as would have been used for the 866 original source packet if the FEC Framework were not present 867 (for example, in the UDP case, the UDP source and destination 868 addresses and ports on the IP datagram carrying the source 869 packet will be the same whether or not the FEC Framework is 870 applied). 872 7. When the FEC Framework needs to send one or several FEC repair 873 packets (e.g., according to the target Code Rate), it asks the 874 FEC scheme to create one or several repair packet payloads from 875 the current sliding encoding window along with their Repair FEC 876 Payload ID. 878 8. The Repair FEC Payload IDs and repair packet payloads are 879 provided back from the FEC scheme to the FEC Framework. 881 9. The FEC Framework constructs FEC repair packets according to 882 Section 5.4, using the FEC Payload IDs and repair packet 883 payloads provided by the FEC scheme. 885 10. The FEC repair packets are sent using normal transport-layer 886 procedures. The port(s) and multicast group(s) to be used for 887 FEC repair packets are defined in the FEC Framework 888 Configuration Information. 890 +----------------------+ 891 | Application | 892 +----------------------+ 893 | 894 | (1) New Application Data Unit (ADU) 895 v 896 +---------------------+ +----------------+ 897 | FEC Framework ver.2 | | FEC Scheme | 898 | |-------------------------->| | 899 | | (2) New ADU |(3) Update of | 900 | | | encoding | 901 | |<--------------------------| window | 902 |(5) Construct FEC | (4) Explicit Source | | 903 | source packet | FEC Payload ID(s) |(7) FEC | 904 | |<--------------------------| encoding | 905 |(9) Construct FEC | (8) Repair FEC Payload ID | | 906 | repair packet(s) | + Repair symbol(s) | | 907 +---------------------+ +----------------+ 908 | 909 | (6) FEC source packet 910 | 911 | (10) FEC repair packets 912 v 913 +----------------------+ 914 | Transport Layer | 915 | (e.g., UDP) | 916 +----------------------+ 918 Figure 6: Sender Operation with Convolutional FEC Codes 920 +----------------------+ 921 | Application | 922 +----------------------+ 923 | 924 | (1) New Application Data Unit (ADU) 925 v 926 +---------------------+ +----------------+ 927 | FEC Framework ver.2 | | FEC Scheme | 928 | |-------------------------->| | 929 | | (2) New ADU |(3) Update of | 930 | | | encoding | 931 | |<--------------------------| window | 932 |(5) Construct FEC | (4) Explicit Source | | 933 | source packet | FEC Payload ID(s) |(7) FEC | 934 | |<--------------------------| encoding | 935 |(9) Construct FEC | (8) Repair FEC Payload ID | | 936 | repair packet(s) | + Repair symbol(s) | | 937 +---------------------+ +----------------+ 938 | | 939 |(6) Source |(10) Repair payloads 940 | packets | 941 | | 942 | + -- -- -- -- -+ 943 | | RTP | 944 | +-- -- -- -- --+ 945 v v 946 +----------------------+ 947 | Transport Layer | 948 | (e.g., UDP) | 949 +----------------------+ 951 Figure 7: Sender Operation with RTP Repair Flows with Convolutional 952 FEC Codes 954 4.5. Receiver Operation with Convolutional FEC Codes 956 The following describes a possible receiver algorithm in the case of 957 Convolutional FEC Code. Figures 4 and 5 for the case of UDP and RTP 958 repair flows, respectively, when receiving a FEC source or repair 959 packet also apply here. The only difference lies in step (4): 961 4. The FEC scheme uses the received FEC Payload IDs (and derived 962 FEC Source Payload IDs in the case that the Explicit Source FEC 963 Payload ID field is not used) to insert source and repair packets 964 into the decoding window in the right way. If at least one source 965 packet is missing and at least one repair packet has been received 966 and the rank of the associated linear system permits it (assuming 967 we are dealing with a linear convolutional FEC code), then FEC 968 decoding can be performed in order to recover missing source 969 payloads. The FEC scheme determines whether source packets have 970 been lost and whether enough data for decoding of any or all of 971 the missing source payloads in the decoding window has been 972 received. 974 Not shown in these Figures is the management of the decoding window 975 at a receiver. For instance this decoding window is composed of a 976 set of linear equations (assuming we are using a linear code) 977 associated to each FEC repair packet received, and whose variables 978 are the available (i.e., received or decoded) or unknown source 979 symbols associated to ADUs. The decoding window is under the control 980 of the FEC scheme and management details MUST be specified by the FEC 981 scheme. 983 5. Protocol Specification 985 5.1. General 987 This section specifies the protocol elements for the FEC Framework. 988 Three components of the protocol are defined in this document and are 989 described in the following sections: 991 1. With a Block FEC Code, construction of a source block from ADUs. 992 The FEC code will be applied to this source block to produce the 993 repair payloads. 995 2. A format for packets containing source data. 997 3. A format for packets containing repair data. 999 The operation of the FEC Framework is governed by certain FEC 1000 Framework Configuration Information, which is defined in this 1001 section. A complete protocol specification that uses this framework 1002 MUST specify the means to determine and communicate this information 1003 between sender and receiver. 1005 Note that the FEC Framework does not specify the management of the 1006 encoding window. This is left to the FEC scheme associated to a 1007 Convolutional FEC Code. This is motivated by the links that exist 1008 between the encoding window management features and the FEC scheme 1009 signaling features. For instance, an encoding window that is 1010 composed of a non sequential set of ADUs may require an appropriate 1011 signaling to inform a FEC Framework receiver of the identity of each 1012 ADU composing the encoding window. On the opposite, an encoding 1013 window always composed of a sequential set of ADUs simplifies 1014 signaling. For instance, providing the identity of the first ADU (or 1015 first source symbol of this ADU) and the number of ADUs (or source 1016 symbols) used to generate a FEC repair packet is sufficient to 1017 identify all the ADUs (or source symbols) present in the encoding 1018 window. Appendix A gives an example of coding window management (non 1019 normative text). 1021 Similarly the FEC Framework does not specify the management of the 1022 decoding window which is also left to the FEC scheme associated to a 1023 Convolutional FEC Code. 1025 Note that the FEC Framework does not specify the ADU to source symbol 1026 mapping, neither for Block FEC Codes nor for Convolutional FEC Codes. 1028 5.2. Structure of the Source Block with Block FEC Codes 1030 The FEC Framework and FEC scheme exchange ADUs in the form of source 1031 blocks. A source block is generated by the FEC Framework from an 1032 ordered sequence of ADUs. The allocation of ADUs to blocks is 1033 dependent on the application. Note that some ADUs may not be 1034 included in any block. Each source block provided to the FEC scheme 1035 consists of an ordered sequence of ADUs where the following 1036 information is provided for each ADU: 1038 o A description of the source flow with which the ADU is associated. 1040 o The ADU itself. 1042 o The length of the ADU. 1044 5.3. Packet Format for FEC Source Packets 1046 The packet format for FEC source packets MUST be used to transport 1047 the payload of an original source packet. As depicted in Figure 8, 1048 it consists of the original packet, optionally followed by the 1049 Explicit Source FEC Payload ID field. The FEC scheme determines 1050 whether the Explicit Source FEC Payload ID field is required. This 1051 determination is specific to each ADU flow. 1053 +------------------------------------+ 1054 | IP Header | 1055 +------------------------------------+ 1056 | Transport Header | 1057 +------------------------------------+ 1058 | Application Data Unit | 1059 +------------------------------------+ 1060 | Explicit Source FEC Payload ID | 1061 +------------------------------------+ 1063 Figure 8: Structure of the FEC Packet Format for FEC Source Packets 1065 The FEC source packets MUST be sent using the same ADU flow as would 1066 have been used for the original source packets if the FEC Framework 1067 were not present. The transport payload of the FEC source packet 1068 MUST consist of the ADU followed by the Explicit Source FEC Payload 1069 ID field, if required. 1071 The Explicit Source FEC Payload ID field contains information 1072 required to associate the source packet with a source block (in case 1073 of Block FEC Code) or to the source flow (in case of Convolutional 1074 FEC code) and for the operation of the FEC algorithm, and is defined 1075 by the FEC scheme. The format of the Source FEC Payload ID field is 1076 defined by the FEC scheme. In the case that the FEC scheme or CDP 1077 defines a means to derive the Source FEC Payload ID from other 1078 information in the packet (for example, a sequence number used by the 1079 application protocol), then the Source FEC Payload ID field is not 1080 included in the packet. In this case, the original source packet and 1081 FEC source packet are identical. 1083 In applications where avoidance of IP packet fragmentation is a goal, 1084 CDPs SHOULD consider the Explicit Source FEC Payload ID size when 1085 determining the size of ADUs that will be delivered using the FEC 1086 Framework. This is because the addition of the Explicit Source FEC 1087 Payload ID increases the packet length. 1089 The Explicit Source FEC Payload ID is placed at the end of the 1090 packet, so that in the case that Robust Header Compression (ROHC) 1091 [RFC3095] or other header compression mechanisms are used, and in the 1092 case that a ROHC profile is defined for the protocol carried within 1093 the transport payload (for example, RTP), then ROHC will still be 1094 applied for the FEC source packets. Applications that are used with 1095 this framework need to consider that FEC schemes can add this 1096 Explicit Source FEC Payload ID and thereby increase the packet size. 1098 In many applications, support for FEC is added to a pre-existing 1099 protocol, and in this case, use of the Explicit Source FEC Payload ID 1100 can break backward compatibility, since source packets are modified. 1102 5.3.1. Generic Explicit Source FEC Payload ID 1104 In order to apply FEC protection using multiple FEC schemes to a 1105 single source flow, all schemes have to use the same Explicit Source 1106 FEC Payload ID format. In order to enable this, it is RECOMMENDED 1107 that FEC schemes support the Generic Explicit Source FEC Payload ID 1108 format described below. 1110 The Generic Explicit Source FEC Payload ID has a length of two octets 1111 and consists of an unsigned packet sequence number in network-byte 1112 order. The allocation of sequence numbers to packets is independent 1113 of any FEC scheme and of the source block construction or encoding 1114 window management, except that the use of this sequence number places 1115 a constraint on source block construction or encoding window 1116 management. Source packets within a given source block or encoding 1117 window MUST have consecutive sequence numbers (where consecutive 1118 includes wrap-around from the maximum value that can be represented 1119 in two octets (65535) to 0). Sequence numbers SHOULD NOT be reused 1120 until all values in the sequence number space have been used. 1122 Editor's notes: 1124 o Are two bytes also suited to the case of convolutional codes? 1125 This limited field size create constraint on the maximum encoding/ 1126 decoding window sizes (measured in number of source symbols), 1127 especially with high bitrate flows. 1129 Note that if the original packets of the source flow are already 1130 carrying a packet sequence number that is at least two bytes long, 1131 there is no need to add the generic Explicit Source FEC Payload ID 1132 and modify the packets. 1134 5.4. Packet Format for FEC Repair Packets 1136 The packet format for FEC repair packets is shown in Figure 9. The 1137 transport payload consists of a Repair FEC Payload ID field followed 1138 by repair data generated in the FEC encoding process. 1140 +------------------------------------+ 1141 | IP Header | 1142 +------------------------------------+ 1143 | Transport Header | 1144 +------------------------------------+ 1145 | Repair FEC Payload ID | 1146 +------------------------------------+ 1147 | Repair Symbols | 1148 +------------------------------------+ 1150 Figure 9: Packet Format for FEC Repair Packets 1152 The Repair FEC Payload ID field contains information required for the 1153 operation of the FEC algorithm at the receiver. This information is 1154 defined by the FEC scheme. The format of the Repair FEC Payload ID 1155 field is defined by the FEC scheme. 1157 5.4.1. Packet Format for FEC Repair Packets over RTP 1159 For FEC schemes that specify the use of RTP for repair packets, the 1160 packet format for repair packets includes an RTP header as shown in 1161 Figure 10. 1163 +------------------------------------+ 1164 | IP Header | 1165 +------------------------------------+ 1166 | Transport Header (UDP) | 1167 +------------------------------------+ 1168 | RTP Header | 1169 +------------------------------------+ 1170 | Repair FEC Payload ID | 1171 +------------------------------------+ 1172 | Repair Symbols | 1173 +------------------------------------+ 1175 Figure 10: Packet Format for FEC Repair Packets over RTP 1177 5.5. FEC Framework Configuration Information 1179 The FEC Framework Configuration Information is information that the 1180 FEC Framework needs in order to apply FEC protection to the ADU 1181 flows. A complete CDP specification that uses the framework 1182 specified here MUST include details of how this information is 1183 derived and communicated between sender and receiver. 1185 The FEC Framework Configuration Information includes identification 1186 of the set of source flows. For example, in the case of UDP, each 1187 source flow is uniquely identified by a tuple {source IP address, 1188 source UDP port, destination IP address, destination UDP port}. In 1189 some applications, some of these fields can contain wildcards, so 1190 that the flow is identified by a subset of the fields. In 1191 particular, in many applications the limited tuple {destination IP 1192 address, destination UDP port} is sufficient. 1194 A single instance of the FEC Framework provides FEC protection for 1195 packets of the specified set of source flows, by means of one or more 1196 packet flows consisting of repair packets. The FEC Framework 1197 Configuration Information includes, for each instance of the FEC 1198 Framework: 1200 1. Identification of the repair flows. 1202 2. For each source flow protected by the repair flow(s): 1204 A. Definition of the source flow. 1206 B. An integer identifier for this flow definition (i.e., tuple). 1207 This identifier MUST be unique among all source flows that 1208 are protected by the same FEC repair flow. Integer 1209 identifiers can be allocated starting from zero and 1210 increasing by one for each flow. However, any random (but 1211 still unique) allocation is also possible. A source flow 1212 identifier need not be carried in source packets, since 1213 source packets are directly associated with a flow by virtue 1214 of their packet headers. 1216 3. The FEC Encoding ID, identifying the FEC scheme. 1218 4. The length of the Explicit Source FEC Payload ID (in octets). 1220 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, 1221 each consisting of a name and a value where the valid element 1222 names and value ranges are defined by the FEC scheme. 1224 Multiple instances of the FEC Framework, with separate and 1225 independent FEC Framework Configuration Information, can be present 1226 at a sender or receiver. A single instance of the FEC Framework 1227 protects packets of the source flows identified in (2) above; i.e., 1228 all packets sent on those flows MUST be FEC source packets as defined 1229 in Section 5.3. A single source flow can be protected by multiple 1230 instances of the FEC Framework. 1232 The integer flow identifier identified in (2B) above is a shorthand 1233 to identify source flows between the FEC Framework and the FEC 1234 scheme. The reason for defining this as an integer, and including it 1235 in the FEC Framework Configuration Information, is so that the FEC 1236 scheme at the sender and receiver can use it to identify the source 1237 flow with which a recovered packet is associated. The integer flow 1238 identifier can therefore take the place of the complete flow 1239 description (e.g., UDP 4-tuple). 1241 Whether and how this flow identifier is used is defined by the FEC 1242 scheme. Since repair packets can provide protection for multiple 1243 source flows, repair packets either would not carry the identifier at 1244 all or can carry multiple identifiers. However, in any case, the 1245 flow identifier associated with a particular source packet can be 1246 recovered from the repair packets as part of a FEC decoding 1247 operation. 1249 A single FEC repair flow provides repair packets for a single 1250 instance of the FEC Framework. Other packets MUST NOT be sent within 1251 this flow; i.e., all packets in the FEC repair flow MUST be FEC 1252 repair packets as defined in Section 5.4 and MUST relate to the same 1253 FEC Framework instance. 1255 In the case that RTP is used for repair packets, the identification 1256 of the repair packet flow can also include the RTP payload type to be 1257 used for repair packets. 1259 FSSI includes the information that is specific to the FEC scheme used 1260 by the CDP. FSSI is used to communicate the information that cannot 1261 be adequately represented otherwise and is essential for proper FEC 1262 encoding and decoding operations. The motivation behind separating 1263 the FSSI required only by the sender (which is carried in a Sender- 1264 Side FEC-Scheme-Specific Information (SS-FSSI) container) from the 1265 rest of the FSSI is to provide the receiver or the third-party 1266 entities a means of controlling the FEC operations at the sender. 1267 Any FSSI other than the one solely required by the sender MUST be 1268 communicated via the FSSI container. 1270 The variable-length SS-FSSI and FSSI containers transmit the 1271 information in textual representation and contain zero or more 1272 distinct elements, whose descriptions are provided by the fully 1273 specified FEC schemes. 1275 For the CDPs that choose the Session Description Protocol (SDP) 1276 [RFC4566] for their multimedia sessions, the ABNF [RFC5234] syntax 1277 for the SS-FSSI and FSSI containers is provided in Section 4.5 of 1278 [RFC6364]. 1280 5.6. FEC Scheme Requirements 1282 In order to be used with this framework, a FEC scheme MUST be capable 1283 of processing data either arranged into blocks of ADUs (source 1284 blocks) in case of a Block FEC Code, or arranged as a continuous flow 1285 of ADUs in case of a Convolutional FEC Code. 1287 A specification for a new FEC scheme MUST include the following: 1289 1. The FEC Encoding ID value that uniquely identifies the FEC 1290 scheme. This value MUST be registered with IANA, as described in 1291 Section 11. 1293 2. The type, semantics, and encoding format of the Repair FEC 1294 Payload ID. 1296 3. The name, type, semantics, and text value encoding rules for zero 1297 or more FEC-Scheme-Specific Information elements. 1299 4. A full specification of the FEC code. 1301 This specification MUST precisely define the valid FEC-Scheme- 1302 Specific Information values, the valid FEC Payload ID values, and 1303 the valid packet payload sizes (where packet payload refers to 1304 the space within a packet dedicated to carrying encoding 1305 symbols). 1307 Furthermore, given valid values of the FEC-Scheme-Specific 1308 Information, a valid Repair FEC Payload ID value, a valid packet 1309 payload size and in case of a Block FEC Code a source block as 1310 defined in Section 5.2, the specification MUST uniquely define 1311 the values of the encoding symbols to be included in the repair 1312 packet payload of a packet with the given Repair FEC Payload ID 1313 value. 1315 A common and simple way to specify the FEC code to the required 1316 level of detail is to provide a precise specification of an 1317 encoding algorithm that -- given valid values of the FEC-Scheme- 1318 Specific Information, a valid Repair FEC Payload ID value, a 1319 valid packet payload size, and in case of a Block FEC Code a 1320 source block as input -- produces the exact value of the encoding 1321 symbols as output. 1323 5. A description of practical encoding and decoding algorithms. 1325 This description need not be to the same level of detail as for 1326 the encoding above; however, it has to be sufficient to 1327 demonstrate that encoding and decoding of the code are both 1328 possible and practical. 1330 FEC scheme specifications MAY additionally define the following: 1332 Type, semantics, and encoding format of an Explicit Source FEC 1333 Payload ID. 1335 Whenever a FEC scheme specification defines an 'encoding format' for 1336 an element, this has to be defined in terms of a sequence of bytes 1337 that can be embedded within a protocol. The length of the encoding 1338 format either MUST be fixed or it MUST be possible to derive the 1339 length from examining the encoded bytes themselves. For example, the 1340 initial bytes can include some kind of length indication. 1342 FEC scheme specifications SHOULD use the terminology defined in this 1343 document and SHOULD follow the following format: 1345 1. Introduction 1348 2. Formats and Codes 1349 2.1. Source FEC Payload ID(s) 1354 2.2. Repair FEC Payload ID 1357 2.3. FEC Framework Configuration Information 1361 3. Procedures 1366 4. FEC Code Specification 1369 Specifications can include additional sections including examples. 1371 Each FEC scheme MUST be specified independently of all other FEC 1372 schemes, for example, in a separate specification or a completely 1373 independent section of a larger specification (except, of course, a 1374 specification of one FEC scheme can include portions of another by 1375 reference). Where an RTP payload format is defined for repair data 1376 for a specific FEC scheme, the RTP payload format and the FEC scheme 1377 can be specified within the same document. 1379 6. Feedback 1381 Many applications require some kind of feedback on transport 1382 performance, e.g., how much data arrived at the receiver, at what 1383 rate, and when? When FEC is added to such applications, feedback 1384 mechanisms may also need to be enhanced to report on the performance 1385 of the FEC, e.g., how much lost data was recovered by the FEC? 1387 When used to provide instrumentation for engineering purposes, it is 1388 important to remember that FEC is generally applied to relatively 1389 small sets of data (in the sense that each block or symbols of an 1390 encoding window is transmitted over a relatively small period of 1391 time). Thus, feedback information that is averaged over longer 1392 periods of time will likely not provide sufficient information for 1393 engineering purposes. More detailed feedback over shorter time 1394 scales might be preferred. For example, for applications using RTP 1395 transport, see [RFC5725]. 1397 Applications that use feedback for congestion control purposes MUST 1398 calculate such feedback on the basis of packets received before FEC 1399 recovery is applied. If this requirement conflicts with other uses 1400 of the feedback information, then the application MUST be enhanced to 1401 support information calculated both pre- and post-FEC recovery. This 1402 is to ensure that congestion control mechanisms operate correctly 1403 based on congestion indications received from the network, rather 1404 than on post-FEC recovery information that would give an inaccurate 1405 picture of congestion conditions. 1407 New applications that require such feedback SHOULD use RTP/RTCP 1408 [RFC3550]. 1410 7. Transport Protocols 1412 This framework is intended to be used to define CDPs that operate 1413 over transport protocols providing an unreliable datagram service, 1414 including in particular the User Datagram Protocol (UDP) and the 1415 Datagram Congestion Control Protocol (DCCP). 1417 8. Congestion Control 1419 This section starts with some informative background on the 1420 motivation of the normative requirements for congestion control, 1421 which are spelled out in Section 8.2. 1423 8.1. Motivation 1425 o The enforcement of congestion control principles has gained a lot 1426 of momentum in the IETF over recent years. While the need for 1427 congestion control over the open Internet is unquestioned, and the 1428 goal of TCP friendliness is generally agreed upon for most (but 1429 not all) applications, the problem of congestion detection and 1430 measurement in heterogeneous networks can hardly be considered 1431 solved. Most congestion control algorithms detect and measure 1432 congestion by taking (primarily or exclusively) the packet loss 1433 rate into account. This appears to be inappropriate in 1434 environments where a large percentage of the packet losses are the 1435 result of link-layer errors and independent of the network load. 1437 o The authors of this document are primarily interested in 1438 applications where the application reliability requirements and 1439 end-to-end reliability of the network differ, such that it 1440 warrants higher-layer protection of the packet stream, e.g., due 1441 to the presence of unreliable links in the end-to-end path and 1442 where real-time, scalability, or other constraints prohibit the 1443 use of higher-layer (transport or application) feedback. A 1444 typical example for such applications is multicast and broadcast 1445 streaming or multimedia transmission over heterogeneous networks. 1446 In other cases, application reliability requirements can be so 1447 high that the required end-to-end reliability will be difficult to 1448 achieve. Furthermore, the end-to-end network reliability is not 1449 necessarily known in advance. 1451 o This FEC Framework is not defined as, nor is it intended to be, a 1452 quality-of-service (QoS) enhancement tool to combat losses 1453 resulting from highly congested networks. It should not be used 1454 for such purposes. 1456 o In order to prevent such misuse, one approach is to leave 1457 standardization to bodies most concerned with the problem 1458 described above. However, the IETF defines base standards used by 1459 several bodies, including the Digital Video Broadcasting (DVB) 1460 Project, the Third Generation Partnership Project (3GPP), and 1461 3GPP2, all of which appear to share the environment and the 1462 problem described. 1464 o Another approach is to write a clear applicability statement. For 1465 example, one could restrict the use of this framework to networks 1466 with certain loss characteristics (e.g., wireless links). 1467 However, there can be applications where the use of FEC is 1468 justified to combat congestion-induced packet losses -- 1469 particularly in lightly loaded networks, where congestion is the 1470 result of relatively rare random peaks in instantaneous traffic 1471 load -- thereby intentionally violating congestion control 1472 principles. One possible example for such an application could be 1473 a no-matter-what, brute-force FEC protection of traffic generated 1474 as an emergency signal. 1476 o A third approach is to require, at a minimum, that the use of this 1477 framework with any given application, in any given environment, 1478 does not cause congestion issues that the application alone would 1479 not itself cause; i.e., the use of this framework must not make 1480 things worse. 1482 o Taking the above considerations into account, Section 8.2 1483 specifies a small set of constraints for FEC; these constraints 1484 are mandatory for all senders compliant with this FEC Framework. 1485 Further restrictions can be imposed by certain CDPs. 1487 8.2. Normative Requirements 1489 o The bandwidth of FEC repair data MUST NOT exceed the bandwidth of 1490 the original source data being protected (without the possible 1491 addition of an Explicit Source FEC Payload ID). This disallows 1492 the (static or dynamic) use of excessively strong FEC to combat 1493 high packet loss rates, which can otherwise be chosen by naively 1494 implemented dynamic FEC-strength selection mechanisms. We 1495 acknowledge that there are a few exotic applications, e.g., IP 1496 traffic from space-based senders, or senders in certain hardened 1497 military devices, that could warrant a higher FEC strength. 1498 However, in this specification, we give preference to the overall 1499 stability and network friendliness of average applications. 1501 o Whenever the source data rate is adapted due to the operation of 1502 congestion control mechanisms, the FEC repair data rate MUST be 1503 similarly adapted. 1505 9. Security Considerations 1507 First of all, it must be clear that the application of FEC protection 1508 to a stream does not provide any kind of security. On the contrary, 1509 the FEC Framework itself could be subject to attacks or could pose 1510 new security risks. The goals of this section are to state the 1511 problem, discuss the risks, and identify solutions when feasible. It 1512 also defines a mandatory-to-implement (but not mandatory-to-use) 1513 security scheme. 1515 9.1. Problem Statement 1517 A content delivery system is potentially subject to many attacks. 1518 Attacks can target the content, the CDP, or the network itself, with 1519 completely different consequences, particularly in terms of the 1520 number of impacted nodes. 1522 Attacks can have several goals: 1524 o They can try to give access to confidential content (e.g., in the 1525 case of non-free content). 1527 o They can try to corrupt the source flows (e.g., to prevent a 1528 receiver from using them), which is a form of denial-of-service 1529 (DoS) attack. 1531 o They can try to compromise the receiver's behavior (e.g., by 1532 making the decoding of an object computationally expensive), which 1533 is another form of DoS attack. 1535 o They can try to compromise the network's behavior (e.g., by 1536 causing congestion within the network), which potentially impacts 1537 a large number of nodes. 1539 These attacks can be launched either against the source and/or repair 1540 flows (e.g., by sending fake FEC source and/or repair packets) or 1541 against the FEC parameters that are sent either in-band (e.g., in the 1542 Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or 1543 out-of-band (e.g., in the FEC Framework Configuration Information). 1545 Several dimensions to the problem need to be considered. The first 1546 one is the way the FEC Framework is used. The FEC Framework can be 1547 used end-to-end, i.e., it can be included in the final end-device 1548 where the upper application runs, or the FEC Framework can be used in 1549 middleboxes, for instance, to globally protect several source flows 1550 exchanged between two or more distant sites. 1552 A second dimension is the threat model. When the FEC Framework 1553 operates in the end-device, this device (e.g., a personal computer) 1554 might be subject to attacks. Here, the attacker is either the end- 1555 user (who might want to access confidential content) or somebody 1556 else. In all cases, the attacker has access to the end-device but 1557 does not necessarily fully control this end-device (a secure domain 1558 can exist). Similarly, when the FEC Framework operates in a 1559 middlebox, this middlebox can be subject to attacks or the attacker 1560 can gain access to it. The threats can also concern the end-to-end 1561 transport (e.g., through the Internet). Here, examples of threats 1562 include the transmission of fake FEC source or repair packets; the 1563 replay of valid packets; the drop, delay, or misordering of packets; 1564 and, of course, traffic eavesdropping. 1566 The third dimension consists in the desired security services. Among 1567 them, the content integrity and sender authentication services are 1568 probably the most important features. We can also mention DoS 1569 mitigation, anti-replay protection, or content confidentiality. 1571 Finally, the fourth dimension consists in the security tools 1572 available. This is the case of the various Digital Rights Management 1573 (DRM) systems, defined outside of the context of the IETF, that can 1574 be proprietary solutions. Otherwise, the Secure Real-Time Transport 1575 Protocol (SRTP) [RFC3711] and IPsec/Encapsulating Security Payload 1576 (IPsec/ESP) [RFC4303] are two tools that can turn out to be useful in 1577 the context of the FEC Framework. Note that using SRTP requires that 1578 the application generate RTP source flows and, when applied below the 1579 FEC Framework, that both the FEC source and repair packets be regular 1580 RTP packets. Therefore, SRTP is not considered to be a universal 1581 solution applicable in all use cases. 1583 In the following sections, we further discuss security aspects 1584 related to the use of the FEC Framework. 1586 9.2. Attacks against the Data Flows 1588 9.2.1. Access to Confidential Content 1590 Access control to the source flow being transmitted is typically 1591 provided by means of encryption. This encryption can be done by the 1592 content provider itself, or within the application (for instance, by 1593 using SRTP [RFC3711]), or at the network layer on a per-packet basis 1594 when IPsec/ESP is used [RFC4303]. If confidentiality is a concern, 1595 it is RECOMMENDED that one of these solutions be used. Even if we 1596 mention these attacks here, they are neither related to nor 1597 facilitated by the use of FEC. 1599 Note that when encryption is applied, this encryption MUST be applied 1600 either on the source data before the FEC protection or, if done after 1601 the FEC protection, on both the FEC source packets and repair packets 1602 (and an encryption at least as cryptographically secure as the 1603 encryption applied on the FEC source packets MUST be used for the FEC 1604 repair packets). Otherwise, if encryption were to be performed only 1605 on the FEC source packets after FEC encoding, a non-authorized 1606 receiver could be able to recover the source data after decoding the 1607 FEC repair packets, provided that a sufficient number of such packets 1608 were available. 1610 The following considerations apply when choosing where to apply 1611 encryption (and more generally where to apply security services 1612 beyond encryption). Once decryption has taken place, the source data 1613 is in plaintext. The full path between the output of the deciphering 1614 module and the final destination (e.g., the TV display in the case of 1615 a video) MUST be secured, in order to prevent any unauthorized access 1616 to the source data. 1618 When the FEC Framework endpoint is the end-system (i.e., where the 1619 upper application runs) and if the threat model includes the 1620 possibility that an attacker has access to this end-system, then the 1621 end-system architecture is very important. More precisely, in order 1622 to prevent an attacker from getting hold of the plaintext, all 1623 processing, once deciphering has taken place, MUST occur in a 1624 protected environment. If encryption is applied after FEC protection 1625 at the sending side (i.e., below the FEC Framework), it means that 1626 FEC decoding MUST take place in the protected environment. With 1627 certain use cases, this MAY be complicated or even impossible. In 1628 such cases, applying encryption before FEC protection is preferred. 1630 When the FEC Framework endpoint is a middlebox, the recovered source 1631 flow, after FEC decoding, SHOULD NOT be sent in plaintext to the 1632 final destination(s) if the threat model includes the possibility 1633 that an attacker eavesdrops on the traffic. In that case, it is 1634 preferable to apply encryption before FEC protection. 1636 In some cases, encryption could be applied both before and after the 1637 FEC protection. The considerations described above still apply in 1638 such cases. 1640 9.2.2. Content Corruption 1642 Protection against corruptions (e.g., against forged FEC source/ 1643 repair packets) is achieved by means of a content integrity 1644 verification/source authentication scheme. This service is usually 1645 provided at the packet level. In this case, after removing all the 1646 forged packets, the source flow might sometimes be recovered. 1647 Several techniques can provide this content integrity/source 1648 authentication service: 1650 o At the application layer, SRTP [RFC3711] provides several 1651 solutions to check the integrity and authenticate the source of 1652 RTP and RTCP messages, among other services. For instance, when 1653 associated with the Timed Efficient Stream Loss-Tolerant 1654 Authentication (TESLA) [RFC4383], SRTP is an attractive solution 1655 that is robust to losses, provides a true authentication/integrity 1656 service, and does not create any prohibitive processing load or 1657 transmission overhead. Yet, with TESLA, checking a packet 1658 requires a small delay (a second or more) after its reception. 1659 Whether or not this extra delay, both in terms of startup delay at 1660 the client and end-to-end delay, is appropriate depends on the 1661 target use case. In some situations, this might degrade the user 1662 experience. In other situations, this will not be an issue. 1663 Other building blocks can be used within SRTP to provide content 1664 integrity/authentication services. 1666 o At the network layer, IPsec/ESP [RFC4303] offers (among other 1667 services) an integrity verification mechanism that can be used to 1668 provide authentication/content integrity services. 1670 It is up to the developer and the person in charge of deployment, who 1671 know the security requirements and features of the target application 1672 area, to define which solution is the most appropriate. Nonetheless, 1673 it is RECOMMENDED that at least one of these techniques be used. 1675 Note that when integrity protection is applied, it is RECOMMENDED 1676 that it take place on both FEC source and repair packets. The 1677 motivation is to keep corrupted packets from being considered during 1678 decoding, as such packets would often lead to a decoding failure or 1679 result in a corrupted decoded source flow. 1681 9.3. Attacks against the FEC Parameters 1683 Attacks on these FEC parameters can prevent the decoding of the 1684 associated object. For instance, modifying the finite field size of 1685 a Reed-Solomon FEC scheme (when applicable) will lead a receiver to 1686 consider a different FEC code. 1688 Therefore, it is RECOMMENDED that security measures be taken to 1689 guarantee the integrity of the FEC Framework Configuration 1690 Information. Since the FEC Framework does not define how the FEC 1691 Framework Configuration Information is communicated from sender to 1692 receiver, we cannot provide further recommendations on how to 1693 guarantee its integrity. However, any complete CDP specification 1694 MUST give recommendations on how to achieve it. When the FEC 1695 Framework Configuration Information is sent out-of-band, e.g., in a 1696 session description, it SHOULD be protected, for instance, by 1697 digitally signing it. 1699 Attacks are also possible against some FEC parameters included in the 1700 Explicit Source FEC Payload ID and Repair FEC Payload ID. For 1701 instance, with a Block FEC Code, modifying the Source Block Number of 1702 a FEC source or repair packet will lead a receiver to assign this 1703 packet to a wrong block. 1705 Therefore, it is RECOMMENDED that security measures be taken to 1706 guarantee the integrity of the Explicit Source FEC Payload ID and 1707 Repair FEC Payload ID. To that purpose, one of the packet-level 1708 source authentication/content integrity techniques described in 1709 Section 9.2.2 can be used. 1711 9.4. When Several Source Flows Are to Be Protected Together 1713 When several source flows, with different security requirements, need 1714 to be FEC protected jointly, within a single FEC Framework instance, 1715 then each flow MAY be processed appropriately, before the protection. 1716 For instance, source flows that require access control MAY be 1717 encrypted before they are FEC protected. 1719 There are also situations where the only insecure domain is the one 1720 over which the FEC Framework operates. In that case, this situation 1721 MAY be addressed at the network layer, using IPsec/ESP (see 1722 Section 9.5), even if only a subset of the source flows has strict 1723 security requirements. 1725 Since the use of the FEC Framework should not add any additional 1726 threat, it is RECOMMENDED that the FEC Framework aggregate flow be in 1727 line with the maximum security requirements of the individual source 1728 flows. For instance, if denial-of-service (DoS) protection is 1729 required, an integrity protection SHOULD be provided below the FEC 1730 Framework, using, for instance, IPsec/ESP. 1732 Generally speaking, whenever feasible, it is RECOMMENDED that FEC 1733 protecting flows with totally different security requirements be 1734 avoided. Otherwise, significant processing overhead would be added 1735 to protect source flows that do not need it. 1737 9.5. Baseline Secure FEC Framework Operation 1739 The FEC Framework has been defined in such a way to be independent 1740 from the application that generates source flows. Some applications 1741 might use purely unidirectional flows, while other applications might 1742 also use unicast feedback from the receivers. For instance, this is 1743 the case when considering RTP/RTCP-based source flows. 1745 This section describes a baseline mode of secure FEC Framework 1746 operation based on the application of the IPsec protocol, which is 1747 one possible solution to solve or mitigate the security threats 1748 introduced by the use of the FEC Framework. 1750 Two related documents are of interest. First, Section 5.1 of 1751 [RFC5775] defines a baseline secure Asynchronous Layered Coding (ALC) 1752 operation for sender-to-group transmissions, assuming the presence of 1753 a single sender and a source-specific multicast (SSM) or SSM-like 1754 operation. The proposed solution, based on IPsec/ESP, can be used to 1755 provide a baseline FEC Framework secure operation, for the downstream 1756 source flow. 1758 Second, Section 7.1 of [RFC5740] defines a baseline secure NACK- 1759 Oriented Reliable Multicast (NORM) operation, for sender-to-group 1760 transmissions as well as unicast feedback from receivers. Here, it 1761 is also assumed there is a single sender. The proposed solution is 1762 also based on IPsec/ESP. However, the difference with respect to 1763 [RFC5775] relies on the management of IPsec Security Associations 1764 (SAs) and corresponding Security Policy Database (SPD) entries, since 1765 NORM requires a second set of SAs and SPD entries to be defined to 1766 protect unicast feedback from receivers. 1768 Note that the IPsec/ESP requirement profiles outlined in [RFC5775] 1769 and [RFC5740] are commonly available on many potential hosts. They 1770 can form the basis of a secure mode of operation. Configuration and 1771 operation of IPsec typically require privileged user authorization. 1772 Automated key management implementations are typically configured 1773 with the privileges necessary to allow the needed system IPsec 1774 configuration. 1776 10. Operations and Management Considerations 1778 The question of operating and managing the FEC Framework and the 1779 associated FEC scheme(s) is of high practical importance. The goals 1780 of this section are to discuss aspects and recommendations related to 1781 specific deployments and solutions. 1783 In particular, this section discusses the questions of 1784 interoperability across vendors/use cases and whether defining 1785 mandatory-to-implement (but not mandatory-to-use) solutions is 1786 beneficial. 1788 10.1. What Are the Key Aspects to Consider? 1790 Several aspects need to be considered, since they will directly 1791 impact the way the FEC Framework and the associated FEC schemes can 1792 be operated and managed. 1794 This section lists them as follows: 1796 1. A Single Small Generic Component within a Larger (and Often 1797 Legacy) Solution: The FEC Framework is one component within a 1798 larger solution that includes one or several upper-layer 1799 applications (that generate one or several ADU flows) and an 1800 underlying protocol stack. A key design principle is that the 1801 FEC Framework should be able to work without making any 1802 assumption with respect to either the upper-layer application(s) 1803 or the underlying protocol stack, even if there are special cases 1804 where assumptions are made. 1806 2. One-to-One with Feedback vs. One-to-Many with Feedback vs. One- 1807 to-Many without Feedback Scenarios: The FEC Framework can be used 1808 in use cases that completely differ from one another. Some use 1809 cases are one-way (e.g., in broadcast networks), with either a 1810 one-to-one, one-to-many, or many-to-many transmission model, and 1811 the receiver(s) cannot send any feedback to the sender(s). Other 1812 use cases follow a bidirectional one-to-one, one-to-many, or 1813 many-to-many scenario, and the receiver(s) can send feedback to 1814 the sender(s). 1816 3. Non-FEC Framework Capable Receivers: With the one-to-many and 1817 many-to-many use cases, the receiver population might have 1818 different capabilities with respect to the FEC Framework itself 1819 and the supported FEC schemes. Some receivers might not be 1820 capable of decoding the repair packets belonging to a particular 1821 FEC scheme, while some other receivers might not support the FEC 1822 Framework at all. 1824 4. Internet vs. Non-Internet Networks: The FEC Framework can be 1825 useful in many use cases that use a transport network that is not 1826 the public Internet (e.g., with IPTV or Mobile TV). In such 1827 networks, the operational and management considerations can be 1828 achieved through an open or proprietary solution, which is 1829 specified outside of the IETF. 1831 5. Congestion Control Considerations: See Section 8 for a discussion 1832 on whether or not congestion control is needed, and its 1833 relationships with the FEC Framework. 1835 6. Within End-Systems vs. within Middleboxes: The FEC Framework can 1836 be used within end-systems, very close to the upper-layer 1837 application, or within dedicated middleboxes (for instance, when 1838 it is desired to protect one or several flows while they cross a 1839 lossy channel between two or more remote sites). 1841 7. Protecting a Single Flow vs. Several Flows Globally: The FEC 1842 Framework can be used to protect a single flow or several flows 1843 globally. 1845 10.2. Operational and Management Recommendations 1847 Overall, from the discussion in Section 10.1, it is clear that the 1848 CDPs and FEC schemes compatible with the FEC Framework differ widely 1849 in their capabilities, application, and deployment scenarios such 1850 that a common operation and management method or protocol that works 1851 well for all of them would be too complex to define. Thus, as a 1852 design choice, the FEC Framework does not dictate the use of any 1853 particular technology or protocol for transporting FEC data, managing 1854 the hosts, signaling the configuration information, or encoding the 1855 configuration information. This provides flexibility and is one of 1856 the main goals of the FEC Framework. However, this section gives 1857 some RECOMMENDED guidelines. 1859 1. A Single Small Generic Component within a Larger (and Often 1860 Legacy) Solution: It is anticipated that the FEC Framework will 1861 often be used to protect one or several RTP streams. Therefore, 1862 implementations SHOULD make feedback information accessible via 1863 RTCP to enable users to take advantage of the tools using (or 1864 used by) RTCP to operate and manage the FEC Framework instance 1865 along with the associated FEC schemes. 1867 2. One-to-One with Feedback vs. One-to-Many with Feedback vs. One- 1868 to-Many without Feedback Scenarios: With use cases that are one- 1869 way, the FEC Framework sender does not have any way to gather 1870 feedback from receivers. With use cases that are bidirectional, 1871 the FEC Framework sender can collect detailed feedback (e.g., in 1872 the case of a one-to-one scenario) or at least occasional 1873 feedback (e.g., in the case of a multicast, one-to-many 1874 scenario). All these applications have naturally different 1875 operational and management aspects. They also have different 1876 requirements or features, if any, for collecting feedback, 1877 processing it, and acting on it. The data structures for 1878 carrying the feedback also vary. 1880 Implementers SHOULD make feedback available using either an in- 1881 band or out-of-band asynchronous reporting mechanism. When an 1882 out-of-band solution is preferred, a standardized reporting 1883 mechanism, such as Syslog [RFC5424] or Simple Network Management 1884 Protocol (SNMP) notifications [RFC3411], is RECOMMENDED. When 1885 required, a mapping mechanism between the Syslog and SNMP 1886 reporting mechanisms could be used, as described in [RFC5675] and 1887 [RFC5676]. 1889 3. Non-FEC Framework Capable Receivers: Section 5.3 gives 1890 recommendations on how to provide backward compatibility in the 1891 presence of receivers that cannot support the FEC scheme being 1892 used or the FEC Framework itself: basically, the use of Explicit 1893 Source FEC Payload ID is banned. Additionally, a non-FEC 1894 Framework capable receiver MUST also have a means not to receive 1895 the repair packets that it will not be able to decode in the 1896 first place or a means to identify and discard them appropriately 1897 upon receiving them. This SHOULD be achieved by sending repair 1898 packets on a different transport-layer flow. In the case of RTP 1899 transport, and if both source and repair packets will be sent on 1900 the same transport-layer flow, this SHOULD be achieved by using 1901 an RTP framing for FEC repair packets with a different payload 1902 type. It is the responsibility of the sender to select the 1903 appropriate mechanism when needed. 1905 4. Within End-Systems vs. within Middleboxes: When the FEC Framework 1906 is used within middleboxes, it is RECOMMENDED that the paths 1907 between the hosts where the sending applications run and the 1908 middlebox that performs FEC encoding be as reliable as possible, 1909 i.e., not be prone to packet loss, packet reordering, or varying 1910 delays in delivering packets. 1912 Similarly, when the FEC Framework is used within middleboxes, it 1913 is RECOMMENDED that the paths be as reliable as possible between 1914 the middleboxes that perform FEC decoding and the end-systems 1915 where the receiving applications operate. 1917 5. Management of Communication Issues before Reaching the Sending 1918 FECFRAME Instance: Let us consider situations where the FEC 1919 Framework is used within middleboxes. At the sending side, the 1920 general reliability recommendation for the path between the 1921 sending applications and the middlebox is important, but it may 1922 not guarantee that a loss, reordering, or long delivery delay 1923 cannot happen, for whatever reason. If such a rare event 1924 happens, this event SHOULD NOT compromise the operation of the 1925 FECFRAME instances, at either the sending side or the receiving 1926 side. This is particularly important with FEC schemes that do 1927 not modify the ADU for backward-compatibility purposes (i.e., do 1928 not use any Explicit Source FEC Payload ID) and rely on, for 1929 instance, the RTP sequence number field to identify FEC source 1930 packets within their source block (Block FEC Code) or source flow 1931 (Convolutional FEC Code). In this case, packet loss or packet 1932 reordering leads to a gap in the RTP sequence number space seen 1933 by the FECFRAME instance. Similarly, varying delay in delivering 1934 packets over this path can lead to significant timing issues. 1935 With FEC schemes for a Block FEC Code that indicate in the Repair 1936 FEC Payload ID, for each source block, the base RTP sequence 1937 number and number of consecutive RTP packets that belong to this 1938 source block, a missing ADU or an ADU delivered out of order 1939 could cause the FECFRAME sender to switch to a new source block. 1940 However, some FEC schemes and/or receivers may not necessarily 1941 handle such varying source block sizes. In this case, one could 1942 consider duplicating the last ADU received before the loss, or 1943 inserting zeroed ADU(s), depending on the nature of the ADU flow. 1944 Implementers SHOULD consider the consequences of such alternative 1945 approaches, based on their use cases. 1947 6. Protecting a Single Flow vs. Several Flows Globally: In the 1948 general case, the various ADU flows that are globally protected 1949 can have different features, and in particular different real- 1950 time requirements (in the case of real-time flows). The process 1951 of globally protecting these flows SHOULD take into account the 1952 requirements of each individual flow. In particular, it would be 1953 counterproductive to add repair traffic to a real-time flow for 1954 which the FEC decoding delay at a receiver makes decoded ADUs for 1955 this flow useless because they do not satisfy the associated 1956 real-time constraints. From a practical point of view, this 1957 means that the source block creation process (Block FEC Code) or 1958 encoding window management process (Convolutional FEC Code) at 1959 the sending FEC Framework instance SHOULD consider the most 1960 stringent real-time requirements of the ADU flows being globally 1961 protected. 1963 7. ADU Flow Bundle Definition and Flow Delivery: By design, a repair 1964 flow might enable a receiver to recover the ADU flow(s) that it 1965 protects even if none of the associated FEC source packets are 1966 received. Therefore, when defining the bundle of ADU flows that 1967 are globally protected and when defining which receiver receives 1968 which flow, the sender SHOULD make sure that the ADU flow(s) and 1969 repair flow(s) of that bundle will only be received by receivers 1970 that are authorized to receive all the ADU flows of that bundle. 1971 See Section 9.4 for additional recommendations for situations 1972 where strict access control for ADU flows is needed. 1974 Additionally, when multiple ADU flows are globally protected, a 1975 receiver that wants to benefit from FECFRAME loss protection 1976 SHOULD receive all the ADU flows of the bundle. Otherwise, the 1977 missing FEC source packets would be considered lost, which might 1978 significantly reduce the efficiency of the FEC scheme. 1980 11. IANA Considerations 1982 FEC schemes for use with this framework are identified in protocols 1983 using FEC Encoding IDs. Values of FEC Encoding IDs are subject to 1984 IANA registration. For this purpose, this document reuses the 1985 registry called the "FEC Framework (FECFRAME) FEC Encoding IDs". 1987 The values that can be assigned within the "FEC Framework (FECFRAME) 1988 FEC Encoding IDs" registry are numeric indexes in the range (0, 255). 1989 Values of 0 and 255 are reserved. Assignment requests are granted on 1990 an IETF Review basis as defined in [RFC5226]. Section 5.6 defines 1991 explicit requirements that documents defining new FEC Encoding IDs 1992 should meet. 1994 12. Acknowledgments 1996 This document is based in part on [FEC-SF], and so thanks are due to 1997 the additional authors of that document: Mike Luby, Magnus 1998 Westerlund, and Stephan Wenger. That document was in turn based on 1999 the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and thus, 2000 thanks are also due to the participants in 3GPP SA Working Group 4. 2001 Further thanks are due to the members of the FECFRAME Working Group 2002 for their comments and reviews. 2004 13. References 2006 13.1. Normative References 2008 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2009 Requirement Levels", BCP 14, RFC 2119, 2010 DOI 10.17487/RFC2119, March 1997, 2011 . 2013 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2014 Architecture for Describing Simple Network Management 2015 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2016 DOI 10.17487/RFC3411, December 2002, 2017 . 2019 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 2020 Correction (FEC) Building Block", RFC 5052, 2021 DOI 10.17487/RFC5052, August 2007, 2022 . 2024 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2025 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2026 DOI 10.17487/RFC5226, May 2008, 2027 . 2029 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2030 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2032 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 2033 DOI 10.17487/RFC5424, March 2009, 2034 . 2036 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 2037 Correction (FEC) Framework", RFC 6363, 2038 DOI 10.17487/RFC6363, October 2011, 2039 . 2041 13.2. Informative References 2043 [FEC-SF] Watson, M., Luby, M., Westerlund, M., and S. Wenger, 2044 "Forward Error Correction (FEC) Streaming Framework", Work 2045 in Progress, July 2005. 2047 [FECFRAMEv2-Motivations] 2048 IRTF NetWork Coding Research Group (NWCRG), "FECFRAMEv2: 2049 Adding Sliding Encoding Window Capabilities to the FEC 2050 Framework: Problem Position", May 2016, 2051 . 2054 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 2055 Protocols and codecs", 3GPP TS 26.346, March 2009, 2056 . 2058 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 2059 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 2060 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 2061 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 2062 Compression (ROHC): Framework and four profiles: RTP, UDP, 2063 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 2064 July 2001, . 2066 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2067 Jacobson, "RTP: A Transport Protocol for Real-Time 2068 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2069 July 2003, . 2071 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2072 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2073 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2074 . 2076 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2077 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2078 . 2080 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 2081 Stream Loss-Tolerant Authentication (TESLA) in the Secure 2082 Real-time Transport Protocol (SRTP)", RFC 4383, 2083 DOI 10.17487/RFC4383, February 2006, 2084 . 2086 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2087 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2088 July 2006, . 2090 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 2091 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 2092 DOI 10.17487/RFC4588, July 2006, 2093 . 2095 [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network 2096 Management Protocol (SNMP) Notifications to SYSLOG 2097 Messages", RFC 5675, DOI 10.17487/RFC5675, October 2009, 2098 . 2100 [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, 2101 "Definitions of Managed Objects for Mapping SYSLOG 2102 Messages to Simple Network Management Protocol (SNMP) 2103 Notifications", RFC 5676, DOI 10.17487/RFC5676, October 2104 2009, . 2106 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 2107 Report Block Type for RTP Control Protocol (RTCP) Extended 2108 Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 2109 2010, . 2111 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2112 "NACK-Oriented Reliable Multicast (NORM) Transport 2113 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2114 . 2116 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 2117 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 2118 DOI 10.17487/RFC5775, April 2010, 2119 . 2121 [RFC6364] Begen, A., "Session Description Protocol Elements for FEC 2122 Framework", RFC 6364, October 2011. 2124 Appendix A. Possible management within a FEC Scheme of the Encoding 2125 Window with Convolutional FEC Codes (non Normative) 2127 The FEC Framework does not specify the management of the encoding 2128 window, which is left to the FEC scheme associated to a Convolutional 2129 FEC Code. This section is therefore non normative. On the opposite, 2130 the FEC scheme associated to a Convolution FEC Code: 2132 o MUST defined an encoding window that slides over the set of ADUs 2133 and its management. 2135 o MUST define the relationships between ADUs and the associated 2136 source symbols (as with Block FEC Codes). 2138 Source symbols are added to the sliding encoding window each time a 2139 new ADU arrives, where the following information is provided for this 2140 ADU by the FEC Framework: 2142 o A description of the source flow with which the ADU is associated. 2144 o The ADU itself. 2146 o The length of the ADU. 2148 Source symbols and the corresponding ADUs are removed from the 2149 sliding encoding window, for instance: 2151 o after a certain delay, for situations where the sliding encoding 2152 window is managed on a time basis. The motivation is that an old 2153 ADU of a real-time flow becomes useless after a certain delay. 2154 The ADU retention delay in the sliding encoding window is 2155 therefore initialized according to the real-time features of 2156 incoming flow(s). 2158 o once the sliding encoding window has reached its maximum size, 2159 since there is usually an upper limit to the sliding encoding 2160 window size. 2162 o when the sliding encoding window is of fixed size or has reached 2163 its maximum size, the oldest symbol is removed each time a new 2164 symbol is added. 2166 Limitations MAY exist that impact the encoding window management. 2167 For instance: 2169 o at the FEC Framework level: the source flows can have real-time 2170 constraints that limit the number of ADUs in the encoding window. 2172 o at the FEC scheme level: there may be theoretical or practical 2173 limitations (e.g., computational complexity) that limit the number 2174 of ADUs in the encoding window. 2176 The most stringent limitation defines the maximum encoding window 2177 size, either in terms of number of source symbols or number of ADUs, 2178 whichever applies. 2180 Authors' Addresses 2182 Vincent Roca 2183 INRIA 2184 655, av. de l'Europe 2185 Inovallee; Montbonnot 2186 ST ISMIER cedex 38334 2187 France 2189 EMail: vincent.roca@inria.fr 2191 Mark Watson 2192 Netflix, Inc. 2193 100 Winchester Circle 2194 Los Gatos, CA 95032 2195 USA 2197 EMail: watsonm@netflix.com 2199 Ali Begen 2200 Networked Media 2201 Konya 2202 Turkey 2204 EMail: ali.begen@networked.media