idnits 2.17.1 draft-roca-tsvwg-fecframev2-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2017) is 2615 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) == Unused Reference: 'FECFRAMEv2-Motivations' is defined on line 656, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG V. Roca 3 Internet-Draft INRIA 4 Intended status: Standards Track A. Begen 5 Expires: August 28, 2017 Networked Media 6 February 24, 2017 8 Forward Error Correction (FEC) Framework Extension to Convolutional 9 Codes 10 draft-roca-tsvwg-fecframev2-03 12 Abstract 14 RFC 6363 describes a framework for using Forward Error Correction 15 (FEC) codes with applications in public and private IP networks to 16 provide protection against packet loss. The framework supports 17 applying FEC to arbitrary packet flows over unreliable transport and 18 is primarily intended for real-time, or streaming, media. However 19 FECFRAME as per RFC 6363 is restricted to block FEC codes. The 20 present document extends FECFRAME to support convolutional FEC Codes, 21 based on a sliding encoding window, in addition to Block FEC Codes. 22 This is done in a backward compatible way. During multicast/ 23 broadcast real-time content delivery, these codes significantly 24 improve robustness in harsh environments, with less repair traffic 25 and lower FEC-related added latency. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 28, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 63 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 64 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Sender Operation with Convolutional FEC Codes . . . . . . 7 67 4.3. Receiver Operation with Convolutional FEC Codes . . . . . 10 68 5. Protocol Specification . . . . . . . . . . . . . . . . . . . 12 69 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.2. FEC Framework Configuration Information . . . . . . . . . 13 71 5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 13 72 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 14 74 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 14 75 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 11. Operations and Management Considerations . . . . . . . . . . 15 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 14.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Appendix A. About Sliding Encoding Window Management (non 84 Normative) . . . . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 Many applications need to transport a continuous stream of packetized 90 data from a source (sender) to one or more destinations (receivers) 91 over networks that do not provide guaranteed packet delivery. In 92 particular packets may be lost, which is strictly the focus of this 93 document: we assume that transmitted packets are either received 94 without any corruption or totally lost (e.g., because of a congested 95 router, of a poor signal-to-noise ratio in a wireless network, or 96 because the number of bit errors exceeds the correction capabilities 97 of a low-layer error correcting code). 99 For these use-cases, Forward Error Correction (FEC) applied within 100 the transport or application layer, is an efficient technique to 101 improve packet transmission robustness in presence of packet losses 102 (or "erasures"), without going through packet retransmissions that 103 create a delay often incompatible with real-time constraints. The 104 FEC Building Block defined in [RFC5052] provides a framework for the 105 definition of Content Delivery Protocols (CDPs) that make use of 106 separately defined FEC schemes. Any CDP defined according to the 107 requirements of the FEC Building Block can then easily be used with 108 any FEC scheme that is also defined according to the requirements of 109 the FEC Building Block. 111 Then FECFRAME [RFC6363] provides a framework to define Content 112 Delivery Protocols (CDPs) that provide FEC protection for arbitrary 113 packet flows over unreliable transports such as UDP. It is primarily 114 intended for real-time or streaming media applications, using 115 broadcast, multicast, or on-demand delivery. 117 However [RFC6363] only considers block FEC schemes defined in 118 accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], 119 [RFC6816] or [RFC6865]). These codes require the input flow(s) to be 120 segmented into a sequence of blocks. Then FEC encoding (at a sender 121 or an encoding middlebox) and decoding (at a receiver or a decoding 122 middlebox) are both performed on a per-block basis. This approach 123 has major impacts on FEC encoding and decoding delays. The data 124 packets of continuous media flow(s) can be sent immediately, without 125 delay. But the block creation time, that depends on the number k of 126 source symbols in this block, impacts the FEC encoding delay since 127 encoding requires that all source symbols be known. This block 128 creation time also impacts the decoding delay a receiver will 129 experience in case of erasures, since no repair symbol for the 130 current block can be received before. Therefore a good value for the 131 block size is necessarily a balance between the maximum decoding 132 latency at the receivers (which decreases with the block size and 133 must be in line with the most stringent real-time requirement of the 134 protected flow(s)), and the desired robustness against long loss 135 bursts (which increases with the block size). 137 This document extends [RFC6363] in order to also support 138 convolutional FEC codes based on a sliding encoding window. This 139 encoding window, either of fixed or variable size, slides over the 140 set of source symbols. FEC encoding is launched whenever needed, 141 from the set of source symbols present in the sliding encoding window 142 at that time. This approach significantly reduces FEC-related 143 latency, since repair symbols can be generated and sent on-the-fly, 144 at any time, and can be regularly received by receivers to quickly 145 recover packet losses. Using convolutional FEC codes is therefore 146 highly beneficial to real-time flows, one of the primary targets of 147 FECFRAME. 149 [RLC-ID] provides an example of such FEC Scheme for FECFRAME, built 150 from the well-known Random Linear Codes (RLC) convolutional FEC 151 codes. 153 This document is fully backward compatible with [RFC6363] that it 154 extends but does not replace. Indeed: 156 o this extension does not prevent nor compromize in any way the 157 support of block FEC codes. Both types of codes can nicely co- 158 exist, just like different FEC schemes can co-exist; 160 o any receiver, e.g., a legacy receiver that only supports block FEC 161 schemes, can easily identify the FEC scheme used in a FECFRAME 162 session thanks to the associated SDP file and its FEC Encoding ID 163 information (i.e., the "encoding-id=" parameter of a "fec-repair- 164 flow" attribute, [RFC6364]). This mechanism is not specific to 165 this extension but is the basic approach for a FECFRAME receiver 166 to determine whether or not it supports the FEC scheme used in a 167 given FECFRAME session; 169 This document leverages on [RFC6363] and re-uses its structure. It 170 proposes new sections specific to convolutional FEC codes whenever 171 required. 173 2. Definitions and Abbreviations 175 The following list of definitions and abbreviations is copied from 176 [RFC6363], adding only the Block/Convolutional FEC Code and Encoding/ 177 Decoding Window definitions: 179 Application Data Unit (ADU): The unit of source data provided as 180 payload to the transport layer. 182 ADU Flow: A sequence of ADUs associated with a transport-layer flow 183 identifier (such as the standard 5-tuple {source IP address, 184 source port, destination IP address, destination port, transport 185 protocol}). 187 AL-FEC: Application-layer Forward Error Correction. 189 Application Protocol: Control protocol used to establish and control 190 the source flow being protected, e.g., the Real-Time Streaming 191 Protocol (RTSP). 193 Content Delivery Protocol (CDP): A complete application protocol 194 specification that, through the use of the framework defined in 195 this document, is able to make use of FEC schemes to provide FEC 196 capabilities. 198 FEC Code: An algorithm for encoding data such that the encoded data 199 flow is resilient to data loss. Note that, in general, FEC codes 200 may also be used to make a data flow resilient to corruption, but 201 that is not considered in this document. 203 Block FEC Code: FEC Code that operate in a block manner, i.e., for 204 which the input flow MUST be segmented into a sequence of blocks, 205 FEC encoding and decoding being performed independently on a per- 206 block basis. 208 Convolutional FEC Code: FEC Code that can generate repair symbols 209 on-the-fly, at any time, from the set of source symbols present 210 in the sliding encoding window at that time. 212 FEC Framework: A protocol framework for the definition of Content 213 Delivery Protocols using FEC, such as the framework defined in 214 this document. 216 FEC Framework Configuration Information: Information that controls 217 the operation of the FEC Framework. 219 FEC Payload ID: Information that identifies the contents of a packet 220 with respect to the FEC scheme. 222 FEC Repair Packet: At a sender (respectively, at a receiver), a 223 payload submitted to (respectively, received from) the transport 224 protocol containing one or more repair symbols along with a 225 Repair FEC Payload ID and possibly an RTP header. 227 FEC Scheme: A specification that defines the additional protocol 228 aspects required to use a particular FEC code with the FEC 229 Framework. 231 FEC Source Packet: At a sender (respectively, at a receiver), a 232 payload submitted to (respectively, received from) the transport 233 protocol containing an ADU along with an optional Explicit Source 234 FEC Payload ID. 236 Protection Amount: The relative increase in data sent due to the use 237 of FEC. 239 Repair Flow: The packet flow carrying FEC data. 241 Repair FEC Payload ID: A FEC Payload ID specifically for use with 242 repair packets. 244 Source Flow: The packet flow to which FEC protection is to be 245 applied. A source flow consists of ADUs. 247 Source FEC Payload ID: A FEC Payload ID specifically for use with 248 source packets. 250 Source Protocol: A protocol used for the source flow being 251 protected, e.g., RTP. 253 Transport Protocol: The protocol used for the transport of the 254 source and repair flows, e.g., UDP and the Datagram Congestion 255 Control Protocol (DCCP). 257 Encoding Window: Set of Source Symbols available at the sender/ 258 coding node that are used to generate a repair symbol, with a 259 Convolutional FEC Code. 261 Decoding Window: Set of received or decoded source and repair 262 symbols available at a receiver that are used to decode erased 263 source symbols, with a Convolutional FEC Code. 265 Code Rate: The ratio between the number of source symbols and the 266 number of encoding symbols. By definition, the code rate is such 267 that 0 < code rate <= 1. A code rate close to 1 indicates that a 268 small number of repair symbols have been produced during the 269 encoding process. 271 Encoding Symbol: Unit of data generated by the encoding process. 272 With systematic codes, source symbols are part of the encoding 273 symbols. 275 Packet Erasure Channel: A communication path where packets are 276 either lost (e.g., by a congested router, or because the number 277 of transmission errors exceeds the correction capabilities of the 278 physical-layer codes) or received. When a packet is received, it 279 is assumed that this packet is not corrupted. 281 Repair Symbol: Encoding symbol that is not a source symbol. 283 Source Block: Group of ADUs that are to be FEC protected as a single 284 block. This notion is restricted to Block FEC Codes. 286 Source Symbol: Unit of data used during the encoding process. 288 Systematic Code: FEC code in which the source symbols are part of 289 the encoding symbols. 291 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 292 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 293 document are to be interpreted as described in [RFC2119]. 295 3. Architecture Overview 297 The architecture of [RFC6363], Section 3, equally applies to this 298 FECFRAME extension and is not repeated here. 300 4. Procedural Overview 302 4.1. General 304 The general considerations of [RFC6363], Section 4.1, that are 305 specific to block FEC codes are not repeated here. 307 With a Convolutional FEC Code, the FEC source packet MUST contain 308 information to identify the position occupied by the ADU within the 309 source flow, in terms specific to the FEC scheme. This information 310 is known as the Source FEC Payload ID, and the FEC scheme is 311 responsible for defining and interpreting it. 313 With a Convolutional FEC Code, the FEC repair packets MUST contain 314 information that identifies the relationship between the contained 315 repair payloads and the original source symbols used during encoding. 316 This information is known as the Repair FEC Payload ID, and the FEC 317 scheme is responsible for defining and interpreting it. 319 To the Sender Operation ([RFC6363], Section 4.2.) and Receiver 320 Operation ([RFC6363], Section 4.3), both specific to block FEC codes 321 and therefore omitted below, the following two sections detail 322 similar operations for convolutional FEC codes. 324 4.2. Sender Operation with Convolutional FEC Codes 326 With a convolutional FEC scheme, the following operations, 327 illustrated in Figure 1 for the case of UDP repair flows, and in 328 Figure 2 for the case of RTP repair flows, describe a possible way to 329 generate compliant source and repair flows: 331 1. A new ADU is provided by the application. 333 2. The FEC Framework communicates this ADU to the FEC scheme. 335 3. The sliding encoding window is updated by the FEC scheme. The 336 ADU to source symbols mapping as well as the encoding window 337 management details are both the responsibility of the FEC 338 scheme. However Appendix A provide some hints on the way it 339 might be performed. 341 4. The Source FEC Payload ID information of the source packet is 342 determined by the FEC scheme. If required by the FEC scheme, 343 the Source FEC Payload ID is encoded into the Explicit Source 344 FEC Payload ID field and returned to the FEC Framework. 346 5. The FEC Framework constructs the FEC source packet according to 347 [RFC6363] Figure 6, using the Explicit Source FEC Payload ID 348 provided by the FEC scheme if applicable. 350 6. The FEC source packet is sent using normal transport-layer 351 procedures. This packet is sent using the same ADU flow 352 identification information as would have been used for the 353 original source packet if the FEC Framework were not present 354 (for example, in the UDP case, the UDP source and destination 355 addresses and ports on the IP datagram carrying the source 356 packet will be the same whether or not the FEC Framework is 357 applied). 359 7. When the FEC Framework needs to send one or several FEC repair 360 packets (e.g., according to the target Code Rate), it asks the 361 FEC scheme to create one or several repair packet payloads from 362 the current sliding encoding window along with their Repair FEC 363 Payload ID. 365 8. The Repair FEC Payload IDs and repair packet payloads are 366 provided back by the FEC scheme to the FEC Framework. 368 9. The FEC Framework constructs FEC repair packets according to 369 [RFC6363] Figure 7, using the FEC Payload IDs and repair packet 370 payloads provided by the FEC scheme. 372 10. The FEC repair packets are sent using normal transport-layer 373 procedures. The port(s) and multicast group(s) to be used for 374 FEC repair packets are defined in the FEC Framework 375 Configuration Information. 377 +----------------------+ 378 | Application | 379 +----------------------+ 380 | 381 | (1) New Application Data Unit (ADU) 382 v 383 +---------------------+ +----------------+ 384 | FEC Framework | | FEC Scheme | 385 | |-------------------------->| | 386 | | (2) New ADU |(3) Update of | 387 | | | encoding | 388 | |<--------------------------| window | 389 |(5) Construct FEC | (4) Explicit Source | | 390 | source packet | FEC Payload ID(s) |(7) FEC | 391 | |<--------------------------| encoding | 392 |(9) Construct FEC | (8) Repair FEC Payload ID | | 393 | repair packet(s) | + Repair symbol(s) +----------------+ 394 +---------------------+ 395 | 396 | (6) FEC source packet 397 | (10) FEC repair packets 398 v 399 +----------------------+ 400 | Transport Layer | 401 | (e.g., UDP) | 402 +----------------------+ 404 Figure 1: Sender Operation with Convolutional FEC Codes 406 +----------------------+ 407 | Application | 408 +----------------------+ 409 | 410 | (1) New Application Data Unit (ADU) 411 v 412 +---------------------+ +----------------+ 413 | FEC Framework | | FEC Scheme | 414 | |-------------------------->| | 415 | | (2) New ADU |(3) Update of | 416 | | | encoding | 417 | |<--------------------------| window | 418 |(5) Construct FEC | (4) Explicit Source | | 419 | source packet | FEC Payload ID(s) |(7) FEC | 420 | |<--------------------------| encoding | 421 |(9) Construct FEC | (8) Repair FEC Payload ID | | 422 | repair packet(s) | + Repair symbol(s) +----------------+ 423 +---------------------+ 424 | | 425 |(6) Source |(10) Repair payloads 426 | packets | 427 | + -- -- -- -- -+ 428 | | RTP | 429 | +-- -- -- -- --+ 430 v v 431 +----------------------+ 432 | Transport Layer | 433 | (e.g., UDP) | 434 +----------------------+ 436 Figure 2: Sender Operation with RTP Repair Flows 438 4.3. Receiver Operation with Convolutional FEC Codes 440 With a convolutional FEC scheme, the following operations, 441 illustrated in Figure 3 for the case of UDP repair flows, and in 442 Figure 4 for the case of RTP repair flows. The only differences with 443 respect to block FEC codes lie in steps (4) and (5). Therefore this 444 section does not repeat the other steps of [RFC6363], Section 4.3, 445 "Receiver Operation". The new steps (4) and (5) are: 447 4. The FEC scheme uses the received FEC Payload IDs (and derived FEC 448 Source Payload IDs when the Explicit Source FEC Payload ID field 449 is not used) to insert source and repair packets into the 450 decoding window in the right way. If at least one source packet 451 is missing and at least one repair packet has been received and 452 the rank of the associated linear system permits it, then FEC 453 decoding can be performed in order to recover missing source 454 payloads. The FEC scheme determines whether source packets have 455 been lost and whether enough repair packets have been received to 456 decode any or all of the missing source payloads. 458 5. The FEC scheme returns the received and decoded ADUs to the FEC 459 Framework, along with indications of any ADUs that were missing 460 and could not be decoded. 462 +----------------------+ 463 | Application | 464 +----------------------+ 465 ^ 466 |(6) ADUs 467 | 468 +----------------------+ +----------------+ 469 | FEC Framework | | FEC Scheme | 470 | |<--------------------------| | 471 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding 472 | IDs and pass IDs & |-------------------------->| | 473 | payloads to FEC |(3) Explicit Source FEC +----------------+ 474 | scheme | Payload IDs 475 +----------------------+ Repair FEC Payload IDs 476 ^ Source payloads 477 | Repair payloads 478 |(1) FEC source 479 | and repair packets 480 +----------------------+ 481 | Transport Layer | 482 | (e.g., UDP) | 483 +----------------------+ 485 Figure 3: Receiver Operation with Convolutional FEC Codes 487 +----------------------+ 488 | Application | 489 +----------------------+ 490 ^ 491 |(6) ADUs 492 | 493 +----------------------+ +----------------+ 494 | FEC Framework | | FEC Scheme | 495 | |<--------------------------| | 496 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding| 497 | IDs and pass IDs & |-------------------------->| | 498 | payloads to FEC |(3) Explicit Source FEC +----------------+ 499 | scheme | Payload IDs 500 +----------------------+ Repair FEC Payload IDs 501 ^ ^ Source payloads 502 | | Repair payloads 503 |Source pkts |Repair payloads 504 | | 505 +-- |- -- -- -- -- -- -+ 506 |RTP| | RTP Processing | 507 | | +-- -- -- --|-- -+ 508 | +-- -- -- -- -- |--+ | 509 | | RTP Demux | | 510 +-- -- -- -- -- -- -- -+ 511 ^ 512 |(1) FEC source and repair packets 513 | 514 +----------------------+ 515 | Transport Layer | 516 | (e.g., UDP) | 517 +----------------------+ 519 Figure 4: Receiver Operation with RTP Repair Flows 521 5. Protocol Specification 523 5.1. General 525 This section discusses the protocol elements for the FEC Framework 526 specific to convolutional FEC schemes. The global formats of source 527 data packets (i.e., [RFC6363], Figure 6) and repair data packets 528 (i.e., [RFC6363], Figures 7 and 8) remain the same with convolutional 529 FEC codes. They are not repeated here. 531 5.2. FEC Framework Configuration Information 533 The FEC Framework Configuration Information considerations of 534 [RFC6363], Section 5.5, equally applies to this FECFRAME extension 535 and is not repeated here. 537 5.3. FEC Scheme Requirements 539 The FEC scheme requirements of [RFC6363], Section 5.6, mostly apply 540 to this FECFRAME extension and are not repeated here. An exception 541 though is the "full specification of the FEC code", item (4), that is 542 specific to block FEC codes. The following item (4) applies instead: 544 4. A full specification of the convolutional FEC code 546 This specification MUST precisely define the valid FEC-Scheme- 547 Specific Information values, the valid FEC Payload ID values, and 548 the valid packet payload sizes (where packet payload refers to 549 the space within a packet dedicated to carrying encoding 550 symbols). 552 Furthermore, given valid values of the FEC-Scheme-Specific 553 Information, a valid Repair FEC Payload ID value, a valid packet 554 payload size, and a valid encoding window (i.e., a set of source 555 symbols), the specification MUST uniquely define the values of 556 the encoding symbols to be included in the repair packet payload 557 with the given Repair FEC Payload ID value. 559 Additionally, the FEC scheme associated to a Convolutional FEC Code: 561 o MUST define the relationships between ADUs and the associated 562 source symbols (mapping); 564 o MUST define the management of the encoding window that slides over 565 the set of ADUs. Appendix A provides a non normative example; 567 o MUST define the management of the decoding window, consisting of a 568 system of linear equations (in case of a linear FEC code); 570 6. Feedback 572 The discussion of [RFC6363], Section 6, equally applies to this 573 FECFRAME extension and is not repeated here. 575 7. Transport Protocols 577 The discussion of [RFC6363], Section 7, equally applies to this 578 FECFRAME extension and is not repeated here. 580 8. Congestion Control 582 The discussion of [RFC6363], Section 8, equally applies to this 583 FECFRAME extension and is not repeated here. 585 9. Implementation Status 587 Editor's notes: RFC Editor, please remove this section motivated by 588 RFC 7942 before publishing the RFC. Thanks! 590 An implementation of FECFRAME extended to convolutional codes exists: 592 o Organisation: Inria 594 o Description: This is an implementation of FECFRAME extended to 595 convolutional codes and supporting the RLC FEC Scheme [RLC-ID]. 596 It is based on: (1) a proprietary implementation of FECFRAME, made 597 by Inria and Expway for which interoperability tests have been 598 conducted; and (2) a proprietary implementation of RLC 599 Convolutional FEC Codes. 601 o Maturity: the basic FECFRAME maturity is "production", the 602 FECFRAME extension maturity is "under progress". 604 o Coverage: the software implements a subset of [RFC6363], as 605 specialized by the 3GPP eMBMS standard [MBMSTS]. This software 606 also covers the additional features of FECFRAME extended to 607 convolutional codes, in particular the RLC FEC Scheme. 609 o Lincensing: proprietary. 611 o Implementation experience: maximum. 613 o Information update date: March 2017. 615 o Contact: vincent.roca@inria.fr 617 10. Security Considerations 619 This FECFRAME extension does not add any new security consideration. 620 All the considerations of [RFC6363], Section 9, apply to this 621 document as well. 623 11. Operations and Management Considerations 625 This FECFRAME extension does not add any new Operations and 626 Management Consideration. All the considerations of [RFC6363], 627 Section 10, apply to this document as well. 629 12. IANA Considerations 631 A FEC scheme for use with this FEC Framework is identified via its 632 FEC Encoding ID. It is subject to IANA registration in the "FEC 633 Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of 634 [RFC6363], Section 11, apply and are not repeated here. 636 13. Acknowledgments 638 TBD 640 14. References 642 14.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, 646 DOI 10.17487/RFC2119, March 1997, 647 . 649 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 650 Correction (FEC) Framework", RFC 6363, 651 DOI 10.17487/RFC6363, October 2011, 652 . 654 14.2. Informative References 656 [FECFRAMEv2-Motivations] 657 Roca, V., "FECFRAMEv2: Adding Sliding Encoding Window 658 Capabilities to the FEC Framework: Problem Position", Work 659 in Progress, November 2016, . 662 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 663 Protocols and codecs", 3GPP TS 26.346, March 2009, 664 . 666 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 667 Correction (FEC) Building Block", RFC 5052, 668 DOI 10.17487/RFC5052, August 2007, 669 . 671 [RFC6364] Begen, A., "Session Description Protocol Elements for the 672 Forward Error Correction (FEC) Framework", RFC 6364, 673 DOI 10.17487/RFC6364, October 2011, 674 . 676 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 677 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 678 DOI 10.17487/RFC6681, August 2012, 679 . 681 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 682 Parity Check (LDPC) Staircase Forward Error Correction 683 (FEC) Scheme for FECFRAME", RFC 6816, 684 DOI 10.17487/RFC6816, December 2012, 685 . 687 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 688 Matsuzono, "Simple Reed-Solomon Forward Error Correction 689 (FEC) Scheme for FECFRAME", RFC 6865, 690 DOI 10.17487/RFC6865, February 2013, 691 . 693 [RLC-ID] Roca, V., "Random Linear Codes (RLC) Forward Error 694 Correction (FEC) Scheme for FECFRAME", Work in Progress, 695 February 2017, . 698 Appendix A. About Sliding Encoding Window Management (non Normative) 700 The FEC Framework does not specify the management of the sliding 701 encoding window which is the responsibility of the FEC Scheme. This 702 annex provides a few hints with respect to the management of this 703 encoding window. 705 Source symbols are added to the sliding encoding window each time a 706 new ADU arrives, where the following information is provided for this 707 ADU by the FEC Framework: a description of the source flow with which 708 the ADU is associated, the ADU itself, and the length of the ADU. 709 This information is sufficient for the FEC scheme to map the ADU with 710 the corresponding source symbols. 712 Source symbols and the corresponding ADUs are removed from the 713 sliding encoding window, for instance: 715 o after a certain delay, when an "old" ADU of a real-time flow 716 times-out. The source symbol retention delay in the sliding 717 encoding window should therefore be initialized according to the 718 real-time features of incoming flow(s). 720 o once the sliding encoding window has reached its maximum size 721 (there is usually an upper limit to the sliding encoding window 722 size). In that case the oldest symbol is removed each time a new 723 source symbol is added. 725 Several aspects exist that can impact the sliding encoding window 726 management: 728 o at the source flows level: real-time constraints can limit the 729 total time source symbols can remain in the encoding window; 731 o at the FEC code level: there may be theoretical or practical 732 limitations (e.g., because of computational complexity aspect) 733 that limit the number of source symbols in the encoding window. 735 o at the FEC scheme level: signaling and window management are 736 intrinsically related. For instance, an encoding window composed 737 of a non sequential set of source symbols requires an appropriate 738 signaling to inform a receiver of the composition of the encoding 739 window. On the opposite, an encoding window always composed of a 740 sequential set of source symbols simplifies signaling: providing 741 the identity of the first source symbol plus their number is 742 sufficient. 744 Authors' Addresses 746 Vincent Roca 747 INRIA 748 Grenoble 749 France 751 EMail: vincent.roca@inria.fr 753 Ali Begen 754 Networked Media 755 Konya 756 Turkey 758 EMail: ali.begen@networked.media