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