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