idnits 2.17.1 draft-ietf-fecframe-framework-09.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2010) is 5042 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1278 -- Looks like a reference, but probably isn't: '255' on line 1278 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework Working Group M. Watson 3 Internet-Draft Qualcomm, Inc. 4 Intended status: Standards Track July 6, 2010 5 Expires: January 7, 2011 7 Forward Error Correction (FEC) Framework 8 draft-ietf-fecframe-framework-09 10 Abstract 12 This document describes a framework for using forward error 13 correction (FEC) codes with applications in public and private IP 14 networks to provide protection against packet loss. The framework 15 supports applying Forward Error Correction to arbitrary packet flows 16 over unreliable transport and is primarily intended for real-time, or 17 streaming, media. This framework can be used to define Content 18 Delivery Protocols that provide Forward Error Correction for 19 streaming media delivery or other packet flows. Content Delivery 20 Protocols defined using this framework can support any FEC Scheme 21 (and associated FEC codes) which is compliant with various 22 requirements defined in this document. Thus, Content Delivery 23 Protocols can be defined which are not specific to a particular FEC 24 Scheme and FEC Schemes can be defined which are not specific to a 25 particular Content Delivery Protocol. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 7, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6 75 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 76 4. Procedural overview . . . . . . . . . . . . . . . . . . . . . 13 77 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15 79 4.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 80 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21 81 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 5.2. Structure of the source block . . . . . . . . . . . . . . 21 83 5.3. Packet format for FEC Source packets . . . . . . . . . . . 21 84 5.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 23 85 5.4. Packet Format for FEC Repair packets . . . . . . . . . . . 23 86 5.4.1. Packet Format for FEC Repair packets over RTP . . . . 23 87 5.5. FEC Framework Configuration Information . . . . . . . . . 24 88 5.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26 89 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30 91 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31 92 8.1. Normative requirements . . . . . . . . . . . . . . . . . . 32 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 97 12.1. Normative references . . . . . . . . . . . . . . . . . . . 36 98 12.2. Informative references . . . . . . . . . . . . . . . . . . 36 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 101 1. Introduction 103 Many applications have a requirement to transport a continuous stream 104 of packetized data from a source (sender) to one or more destinations 105 (receivers) over networks which do not provide guaranteed packet 106 delivery. Primary examples are real-time, or streaming, media 107 applications such as broadcast, multicast or on-demand audio, video 108 or multimedia. 110 Forward Error Correction is a well-known technique for improving 111 reliability of packet transmission over networks which do not provide 112 guaranteed packet delivery, especially in multicast and broadcast 113 applications. The FEC Building Block defined in [RFC5052] provides a 114 framework for definition of Content Delivery Protocols (CDPs) for 115 object delivery (including, primarily, file delivery) which make use 116 of separately defined FEC Schemes. Any CDP defined according to the 117 requirements of the FEC Building Block can then easily be used with 118 any FEC Scheme which is also defined according to the requirements of 119 the FEC Building Block. (Note that the term "Forward Erasure 120 Correction" is sometimes used, 'erasures' being a type of error in 121 which data is lost and this loss can be detected, rather than being 122 received in corrupted form - the focus of this document is strictly 123 on erasures, however the term Forward Error Correction is more widely 124 used). 126 This document defines a framework for the definition of CDPs which 127 provide for FEC protection of arbitrary packet flows over unreliable 128 transports such as UDP. As such, this document complements the FEC 129 Building Block of [RFC5052], by providing for the case of arbitrary 130 packet flows over unreliable transport, the same kind of framework as 131 that document provides for object delivery. This document does not 132 define a complete Content Delivery Protocol, but rather defines only 133 those aspects that are expected to be common to all Content Delivery 134 Protocols based on this framework. 136 This framework does not define how the flows to be protected are 137 determined, nor how the details of the protected flows and the FEC 138 streams which protect them are communicated from sender to receiver. 139 It is expected that any complete Content Delivery Protocol 140 specification which makes use of this framework will address these 141 signalling requirements. However, this document does specify the 142 information which is required by the FEC Framework at the sender and 143 receiver - for example details of the flows to be FEC protected, the 144 flow(s) that will carry the FEC protection data and an opaque 145 container for FEC-Scheme-specific information. 147 FEC Schemes designed for use with this framework must fulfil a number 148 of requirements defined in this document. Note that these 149 requirements are different from those defined in [RFC5052] for FEC 150 Schemes for object delivery. However there is a great deal of 151 commonality and FEC Schemes defined for object delivery may be easily 152 adapted for use with the framework defined here. 154 Since the RTP protocol layer is used over UDP, this framework can be 155 applied to RTP flows as well. FEC repair packets may be sent 156 directly over UDP or over RTP. The latter approach has the advantage 157 that RTP instrumentation, based on RTCP, can be used for the repair 158 flow. Additionally, the post-repair RTCP extended report [RFC5725] 159 may be used to obtain information about the loss rate after FEC 160 recovery. 162 The use of RTP for repair flows is defined for each FEC Scheme by 163 defining an RTP Payload Format for that particular FEC Scheme 164 (possibly in the same document). 166 2. Definitions/Abbreviations 168 'ADU Flow' A sequence of ADUs associated with a transport layer flow 169 identifier (such as the standard 5-tuple { Source IP Address, 170 Source Transport Port, Destination IP Address, Destination 171 Transport Port, Transport Protocol } in the case of UDP) 173 'AL-FEC' Application Layer Forward Error Correction 175 'Application Data Unit' The unit of source data provided as payload 176 to the transport layer 178 'Application protocol' Control protocol used to establish and 179 control the source data flow being protected - e.g. RTSP. 181 'Content Delivery Protocol (CDP)' A complete application protocol 182 specification which, through the use of the framework defined in 183 this document, is able to make use of FEC Schemes to provide 184 Forward Error Correction capabilities 186 'FEC' Forward Error Correction. 188 'FEC Code' An algorithm for encoding data such that the encoded data 189 flow is resilient to data loss (Note: in general FEC Codes may 190 also be used to make a data flow resilient to corruption, but that 191 is not considered here). 193 'FEC Framework' A protocol framework for definition of Content 194 Delivery Protocols using FEC, such as the framework defined in 195 this document. 197 'FEC Framework Configuration Information' Information which controls 198 the operation of the FEC Framework. 200 'FEC Payload ID' Information which identifies the contents of a 201 packet with respect to the FEC Scheme. 203 'FEC Repair Packet' At a sender (respectively, at a receiver) a 204 payload submitted to (respectively, received from) the Transport 205 protocol containing one or more repair symbols along with a Repair 206 FEC Payload ID and possibly an RTP header. 208 'FEC Scheme' A specification which defines the additional protocol 209 aspects required to use a particular FEC code with the FEC 210 Framework, or, in the context of RMT, with the RMT FEC Building 211 Block. 213 'FEC Source Packet' At a sender (respectively, at a receiver) a 214 payload submitted to (respectively, received from) the Transport 215 protocol containing an ADU along with an optional Source FEC 216 Payload ID. 218 'Protection amount' The relative increase in data sent due to the 219 use of FEC. 221 'Repair data flow' The packet flow or flows carrying forward error 222 correction data 224 'Repair FEC Payload ID' An FEC Payload ID specifically for use with 225 repair packets. 227 'Source data flow' The packet flow or flows to which FEC protection 228 is to be applied. A source data flow consists of ADUs. 230 'Source FEC Payload ID' An FEC Payload ID specifically for use with 231 source packets. 233 'Source protocol' A protocol used for the source data flow being 234 protected - e.g. RTP. 236 'Transport protocol' The protocol used for transport of the source 237 and repair data flows - e.g. UDP, DCCP. 239 The following definitions are aligned with [RFC5052] 241 'Code rate' the ratio between the number of source symbols and the 242 number of encoding symbols. By definition, the code rate is such 243 that: 0 < code rate <= 1. A code rate close to 1 indicates that a 244 small number of repair symbols have been produced during the 245 encoding process. 247 'Encoding symbol' unit of data generated by the encoding process. 248 With systematic codes, source symbols are part of the encoding 249 symbols. 251 'Packet Erasure Channel' a communication path where packets are 252 either dropped (e.g., by a congested router, or because the number 253 of transmission errors exceeds the correction capabilities of the 254 physical layer codes) or received. When a packet is received, it 255 is assumed that this packet is not corrupted. 257 'Repair symbol' encoding symbol that is not a source symbol. 259 'Source Block' group of ADUs which are to be FEC protected as a 260 single block. 262 'Source symbol' unit of data used during the encoding process. 264 'Systematic code' FEC code in which the source symbols are part of 265 the encoding symbols. The Reed-Solomon codes introduced in this 266 document are systematic. 268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 270 document are to be interpreted as described in [RFC2119]. 272 3. Architecture Overview 274 The FEC Framework is described in terms of an additional layer 275 between the transport layer (e.g. UDP or DCCP) and protocols running 276 over this transport layer. Examples of such protocols are RTP, RTCP, 277 etc. As such, the data path interface between the FEC Framework and 278 both underlying and overlying layers can be thought of as being the 279 same as the standard interface to the transport layer - i.e. the data 280 exchanged consists of datagram payloads each associated with a single 281 ADU flow identified (in the case of UDP) by the standard 5-tuple { 282 Source IP Address, Source Transport Port, Destination IP Address, 283 Destination Transport Port, Transport Protocol }. In the case that 284 RTP is used for the repair flows, the source and repair data may be 285 multiplexed using RTP onto a single UDP flow and must consequently be 286 demultiplexed at the receiver. There are various ways in which this 287 multiplexing can be done, for example as described in [RFC4588]. 289 It is important to understand that the main purpose of the FEC 290 Framework architecture is to allocate functional responsibilities to 291 separately documented components in such a way that specific 292 instances of the components can be combined in different ways to 293 describe different protocols. 295 The FEC Framework makes use of an FEC Scheme, in a similar sense to 296 that defined in [RFC5052] and uses the terminology of that document. 297 The FEC Scheme defines the FEC encoding and decoding and defines the 298 protocol fields and procedures used to identify packet payload data 299 in the context of the FEC Scheme. The interface between the FEC 300 Framework and an FEC Scheme, which is described in this document, is 301 a logical one, which exists for specification purposes only. At an 302 encoder, the FEC Framework passes ADUs to the FEC Scheme for FEC 303 encoding. The FEC Scheme returns repair symbols with their 304 associated Repair FEC Payload IDs, and in some case Source FEC 305 Payload IDs, depending on the FEC Scheme. At a decoder, the FEC 306 Framework passes transport packet payloads (source and repair) to the 307 FEC Scheme and the FEC Scheme returns additional recovered source 308 packet payloads. 310 This document defines certain FEC Framework Configuration Information 311 which MUST be available to both sender and receiver(s). For example, 312 this information includes the specification of the ADU flows which 313 are to be FEC protected, specification of the ADU flow(s) which will 314 carry the FEC protection (repair) data and the relationship(s) 315 between these source and repair flows (i.e. which source flow(s) are 316 protected by each repair flow. The FEC Framework Configuration 317 Information also includes information fields which are specific to 318 the FEC Scheme. This information is analogous to the FEC Object 319 Transmission Information defined in [RFC5052]. 321 The FEC Framework does not define how the FEC Framework Configuration 322 Information for the stream is communicated from sender to receiver. 323 This must be defined by any Content Delivery Protocol specification 324 as described in the following sections. 326 In this architecture we assume that the interface to the transport 327 layer supports the concepts of data units (referred to here as 328 Application Data Units) to be transported and identification of ADU 329 flows on which those data units are transported. Since this is an 330 interface internal to the architecture, we do not specify this 331 interface explicitly. We do require that ADU flows which are 332 distinct from the transport layer point of view (for example, 333 distinct UDP flows as identified by the UDP source/destination ports/ 334 addresses) are also distinct on the interface between the transport 335 layer and the FEC Framework. 337 As noted above, RTP flows are a specific example of ADU flows which 338 might be protected by the FEC Framework. From the FEC Framework 339 point of view, RTP source flows are ADU flows like any other, with 340 the RTP header included within the ADU. 342 Depending on the FEC Scheme, RTP may also be used as a transport for 343 repair packet flows. In this case an FEC Scheme must define an RTP 344 Payload Format for the repair data. 346 The architecture outlined above is illustrated in the Figure 1. In 347 this architecture, two RTP instances are shown, for the source and 348 repair data respectively. This is because the use of RTP for the 349 source data is separate from and independent of the use of RTP for 350 the repair data. The appearance of two RTP instances is more natural 351 when you consider that in many FEC codes, the repair payload contains 352 repair data calculated across the RTP headers of the source packets. 353 Thus a repair packet carried over RTP starts with an RTP header of 354 its own which is followed (after the Repair Payload ID) by repair 355 data containing bytes which protect the source RTP headers (as well 356 as repair data for the source RTP payloads). 358 +--------------------------------------------+ 359 | Application | 360 +--------------------------------------------+ 361 | 362 | 363 | 364 + - - - - - - - - - - - - - - - - - - - - - - - -+ 365 | +--------------------------------------------+ | 366 | Application Layer | 367 | +--------------------------------------------+ | 368 | | 369 | + -- -- -- -- -- -- -- -- -- -- --+ | | 370 | RTP (optional) | | 371 | | | |-Configuration/Coordination 372 +- -- -- -- -- -- -- -- -- -- -- -+ | 373 | | | | 374 | ADU flows | 375 | | v | 376 +--------------------------------------------+ +----------------+ 377 | | FEC Framework (this document) |<--->| FEC Scheme | 378 +--------------------------------------------+ +----------------+ 379 | | | | 380 Source | Repair | 381 | | | | 382 +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ 383 | | RTP | | RTP processing | |<--- Optional 384 | | +-- -- -- |- -- -+ | - dependent on 385 | | +-- -- -- -- -- -- -- |--+ | | FEC Scheme 386 | | RTP (de)multiplexing | | 387 | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | 388 | 389 | +--------------------------------------------+ | 390 | Transport Layer (e.g. UDP) | 391 | +--------------------------------------------+ | 392 | 393 | +--------------------------------------------+ | 394 | IP | 395 | +--------------------------------------------+ | 396 Content Delivery Protocol 397 + - - - - - - - - - - - - - - - - - - - - - - - + 399 Figure 1: FEC Framework Architecture 401 The contents of the transport payload for repair packets is fully 402 defined by the FEC Scheme. For a specific FEC Scheme, a means MAY be 403 defined for repair data to be carried over RTP, in which case the 404 repair packet payload format starts with the RTP header. This 405 corresponds to defining an RTP Payload Format for the specific FEC 406 Scheme. Guidelines for writers of RTP Payload Formats are provided 407 in [RFC2736]. 409 The use of RTP for repair packets is independent of the protocols 410 used for source packets: if RTP is used for source packets then 411 repair packets may or may not use RTP and vice versa (although it is 412 unlikely that there are useful scenarios where non-RTP source flows 413 are protected by RTP repair flows). FEC Schemes are expected to 414 recover entire transport payloads for recovered source packets in all 415 cases. For example if RTP is used for source flows, the FEC Scheme 416 is expected to recover the entire UDP payload, including the RTP 417 header. 419 4. Procedural overview 421 4.1. General 423 The mechanism defined in this document does not place any 424 restrictions on the Application Data Units which can be protected 425 together, except that the Application Data Unit is carried over a 426 supported transport protocol (See Section 7). The data may be from 427 multiple Source Data Flows that are protected jointly. The FEC 428 framework handles the Source Data Flows as a sequence of 'source 429 blocks' each consisting of a set of Application Data Units, possibly 430 from multiple Source Data Flows which are to be protected together. 431 For example, each source block may be constructed from those 432 Application Data Units related to a particular segment in time of the 433 flow. 435 At the sender, the FEC Framework passes the payloads for a given 436 block to the FEC Scheme for FEC encoding. The FEC Scheme performs 437 the FEC encoding operation and returns the following information: 439 o optionally, FEC Payload IDs for each of the source payloads 440 (encoded according to an FEC-Scheme-specific format) 442 o one or more FEC repair packet payloads 444 o FEC Payload IDs for each of the repair packet payloads (encoded 445 according to an FEC-Scheme-specific format) 447 The FEC framework then performs two operations: Firstly, it appends 448 the FEC payload IDs, if provided, to each of the Application Data 449 Units, and sends the resulting packets, known as 'FEC source 450 packets', to the receiver and secondly it places the provided 'FEC 451 repair packet payloads' and corresponding 'FEC Repair Payload IDs' 452 appropriately to construct 'FEC repair packets' and send them to the 453 receiver. Note that FEC repair packets MAY be sent to a different 454 multicast group or groups from the source packets. 456 This document does not define how the sender determines which 457 Application Data Units are included in which source blocks or the 458 sending order and timing of FEC source and FEC repair packets. A 459 specific Content Delivery Protocol MAY define this mapping or it MAY 460 be left as implementation dependent at the sender. However, a CDP 461 specification MUST define how a receiver determines a minimum length 462 of time that it should wait to receive FEC repair packets for any 463 given source block. FEC Schemes MAY define limitations on this 464 mapping, such as maximum size of source blocks, but SHOULD NOT 465 attempt to define specific mappings. The sequence of operations at 466 the sender is described in more detail in Section 4.2. 468 At the receiver, original Application Data Units are recovered by the 469 FEC Framework directly from any FEC Source Packets received simply by 470 removing the Source FEC Payload ID, if present. The receiver also 471 passes the contents of the received Application Data Units, plus 472 their FEC Payload IDs to the FEC Scheme for possible decoding. 474 If any Application Data Units related to a given source block have 475 been lost, then the FEC Scheme may perform FEC decoding to recover 476 the missing Application Data Units (assuming sufficient FEC Source 477 and FEC Repair packets related to that source block have been 478 received). 480 Note that the receiver may need to buffer received source packets to 481 allow time for the FEC Repair packets to arrive and FEC decoding to 482 be performed before some or all of the received or recovered packets 483 are passed to the application. If such a buffer is not provided, 484 then the application must be able to deal with the severe re-ordering 485 of packets that may occur. However, such buffering is Content 486 Delivery Protocol and/or implementation-specific and is not specified 487 here. The receiver operation is described in more detail in 488 Section 4.3 490 The FEC Source packets MUST contain information which identifies the 491 source block and the position within the source block (in terms 492 specific to the FEC Scheme) occupied by the Application Data Unit. 493 This information is known as the 'Source FEC Payload ID'. The FEC 494 Scheme is responsible for defining and interpreting this information. 495 This information MAY be encoded into a specific field within the FEC 496 Source packet format defined in this specification, called the 497 Explicit Source FEC Payload ID field. The exact contents and format 498 of the Explicit Source FEC Payload ID field are defined by the FEC 499 Scheme. Alternatively, the FEC Scheme MAY define how the Source FEC 500 Payload ID is derived from other fields within the source packets. 501 This document defines the way that the Explicit Source FEC Payload ID 502 field is appended to source packets to form FEC Source packets. 504 The FEC Repair packets MUST contain information which identifies the 505 source block and the relationship between the contained repair 506 payloads and the original source block. This is known as the 'Repair 507 FEC Payload ID'. This information MUST be encoded into a specific 508 field, the Repair FEC Payload ID field, the contents and format of 509 which are defined by the FEC Scheme. 511 The FEC Scheme MAY use different FEC Payload ID field formats for FEC 512 Source packets and FEC Repair packets. 514 4.2. Sender Operation 516 It is assumed that the sender has constructed or received original 517 data packets for the session. These may be RTP, RTCP, MIKEY or 518 indeed any other type of packet. The following operations, 519 illustrated in Figure 2, for the case of UDP repair flows and 520 Figure 3 for the case of RTP repair flows, describe a possible way to 521 generate compliant FEC Source packet and FEC repair packet streams: 523 1. Application Data Units are provided by the application. 525 2. A source block is constructed as specified in Section 5.2. 527 3. The source block is passed to the FEC Scheme for FEC encoding. 528 The Source FEC Payload ID information of each Source packet is 529 determined by the FEC Scheme. If required by the FEC Scheme the 530 Source FEC Payload ID is encoded into the Explicit Source FEC 531 Payload ID field. 533 4. The FEC Scheme performs FEC Encoding, generating repair packet 534 payloads from a source block and a Repair FEC Payload ID field for 535 each repair payload. 537 5. The Explicit Source FEC Payload IDs (if used), Repair FEC 538 Payload IDs and repair packet payloads are provided back from the 539 FEC Scheme to the FEC Framework. 541 6. The FEC Framework constructs FEC Source packets according to 542 Section 5.3 and FEC Repair packets according to Section 5.4 using 543 the FEC Payload IDs and repair packet payloads provided by the FEC 544 Scheme. 546 7. The FEC Source and FEC Repair packets are sent using normal 547 transport layer procedures. The port(s) and multicast group(s) to 548 be used for FEC Repair packets are defined in the FEC Framework 549 Configuration Information. The FEC Source packets are sent using 550 the same ADU flow identification information as would have been 551 used for the original source packets if the FEC Framework were not 552 present (for example, in the UDP case, the UDP source and 553 destination addresses and ports on the IP datagram carrying the 554 Source Packet will be the same whether or not the FEC Framework is 555 applied). 557 +----------------------+ 558 | Application | 559 +----------------------+ 560 | 561 | (1) Application Data Units 562 | 563 v 564 +----------------------+ +------------------+ 565 | FEC Framework | | | 566 | |-------------------------->| FEC Scheme | 567 |(2) Construct source | (3) Source Block | | 568 | blocks | | (4) FEC Encoding | 569 |(6) Construct FEC src |<--------------------------| | 570 | packets and FEC | | | 571 | repair packets |(5) Ex src FEC Payload Ids,| | 572 +----------------------+ Repair FEC Payload Ids,+------------------+ 573 | Repair symbols 574 | 575 | (7) FEC Source packets and FEC repair packets 576 v 577 +----------------------+ 578 | Transport Layer | 579 | (e.g. UDP ) | 580 +----------------------+ 582 Figure 2: Sender operation 584 +----------------------+ 585 | Application | 586 +----------------------+ 587 | 588 | (1) Application Data Units 589 v 590 +----------------------+ +------------------+ 591 | FEC Framework | | | 592 | |-------------------------->| FEC Scheme | 593 |(2) Construct source | (3) Source Block | | 594 | blocks | | (4) FEC Encoding | 595 |(6) Construct FEC src |<--------------------------| | 596 | packets and FEC | | | 597 | repair payloads |(5) Ex src FEC Payload Ids,| | 598 +----------------------+ Repair FEC Payload Ids,+------------------+ 599 | | Repair symbols 600 |(7) Source | 601 | |(7') Repair RTP payloads 602 | + -- -- -- -- -+ 603 | | RTP | 604 | +-- -- -- -- --+ 605 v v 606 +----------------------+ 607 | Transport Layer | 608 | (e.g. UDP ) | 609 +----------------------+ 611 Figure 3: Sender operation with RTP repair flows 613 4.3. Receiver Operation 615 The following describes a possible receiver algorithm, illustrated in 616 Figure 4 and Figure 5 for the case of RTP repair flows, when 617 receiving an FEC source or repair packet: 619 1. FEC Source Packets and FEC Repair packets are received and 620 passed to the FEC Framework. The type of packet (Source or 621 Repair) and the Source Data Flow to which it belongs (in the case 622 of source packets) is indicated by the ADU flow information which 623 identifies the flow at the transport layer (for example source and 624 destination ports and addresses in the case of UDP). 626 1a. In the special case that RTP is used for repair packets and 627 source and repair packets are multiplexed onto the same UDP flow, 628 then RTP demultiplexing is required to demultiplex source and 629 repair flows. However, RTP processing is applied only to the 630 repair packets at this stage: source packets continue to be 631 handled as UDP payloads (i.e. including their RTP headers). 633 2. The FEC Framework extracts the Explicit Source FEC Payload ID 634 field (if present) from FEC Source Packets and the Repair FEC 635 Payload ID from FEC Repair Packets. 637 3. The Explicit Source FEC Payload IDs (if present), Repair FEC 638 Payload IDs, FEC Source payloads and FEC Repair payloads are 639 passed to the FEC Scheme. 641 4. The FEC Scheme uses the received FEC Payload IDs (and derived 642 FEC Source Payload IDs in the case that the Explicit Source FEC 643 Payload ID field is not used) to group source and repair packets 644 into source blocks. If at least one source packet is missing from 645 a source block, and at least one repair packet has been received 646 for the same source block then FEC decoding may be performed in 647 order to recover missing source payloads. The FEC Scheme 648 determines whether source packets have been lost and whether 649 enough data for decoding of any or all of the missing source 650 payloads in the source block has been received. 652 5. The FEC Scheme returns the Application Data Units to the FEC 653 Framework in the form of source blocks containing received and 654 decoded Application Data Units and indications of any Application 655 Data Units which were missing and could not be decoded. 657 6. The FEC Framework passes the received and recovered 658 Application Data Units to the application. 660 Note that the description above defines functionality 661 responsibilities but does not imply a specific set of timing 662 relationships. For example, ADUs may be provided to the application 663 as soon as they are received or recovered (and hence potentially out- 664 of-order) or they may be buffered and delivered to the application 665 in-order. 667 +----------------------+ 668 | Application | 669 +----------------------+ 670 ^ 671 | (6) Application Data Units 672 | 673 +----------------------+ +------------------+ 674 | FEC Framework | | | 675 | |<---------------------------| FEC Scheme | 676 |(2)Extract FEC Payload| (5) Application Data Units | | 677 | IDs and pass IDs & | | (4) FEC Decoding | 678 | Payloads to FEC |--------------------------->| | 679 | Scheme | (3) Ex src FEC Payload IDs,| | 680 +----------------------+ FEC Repair Payload IDs,+------------------+ 681 ^ FEC Source Payloads, 682 | FEC Repair Payloads 683 | 684 | (1) FEC Source packets and FEC repair packets 685 | 686 +----------------------+ 687 | Transport Layer | 688 | (e.g. UDP ) | 689 +----------------------+ 691 Figure 4: Receiver Operation 693 +----------------------+ 694 | Application | 695 +----------------------+ 696 ^ 697 | (6) Application Data Units 698 | 699 +----------------------+ +------------------+ 700 | FEC Framework | | | 701 | |<---------------------------| FEC Scheme | 702 |(2)Extract FEC Payload| (5) Application Data Units | | 703 | IDs and pass IDs & | | (4) FEC Decoding | 704 | Payloads to FEC |--------------------------->| | 705 | Scheme | (3) Ex src FEC Payload IDs,| | 706 +----------------------+ FEC Repair Payload IDs,+------------------+ 707 ^ ^ FEC Source Payloads, 708 | | FEC Repair Payloads 709 |Source pkts | 710 | |(1a) FEC repair payloads 711 +-- |- -- -- -- -- -- -+ 712 |RTP| | RTP processing | 713 | | +-- -- -- --|-- -+ 714 | +-- -- -- -- -- |--+ | 715 | | RTP demux | | 716 +-- -- -- -- -- -- -- -+ 717 | (1) FEC Source packets and FEC repair packets 718 +----------------------+ 719 | Transport Layer | 720 | (e.g. UDP ) | 721 +----------------------+ 723 Figure 5: Receiver Operation 725 Note that the above procedure may result in a situation in which not 726 all ADUs are recovered. 728 Source packets which are correctly received and those which are 729 reconstructed MAY be delivered to the application out of order and in 730 a different order from the order of arrival at the receiver. 731 Alternatively, buffering and packet re-ordering MAY be applied to re- 732 order received and reconstructed source packets into the order they 733 were placed into the source block, if that is necessary according to 734 the application. 736 5. Protocol Specification 738 5.1. General 740 This section specifies the protocol elements for the FEC Framework. 741 Three components of the protocol are defined in this document and are 742 described in the following sections: 744 1. Construction of a source block from Application Data Units. 745 The FEC code will be applied to this source block to produce the 746 repair payloads. 748 2. A format for packets containing source data. 750 3. A format for packets containing repair data. 752 The operation of the FEC Framework is governed by certain FEC 753 Framework Configuration Information. This configuration information 754 is also defined in this section. A complete protocol specification 755 that uses this framework MUST specify the means to determine and 756 communicate this information between sender and receiver. 758 5.2. Structure of the source block 760 The FEC Framework and FEC Scheme exchange Application Data Units in 761 the form of source blocks. A source block is generated by the FEC 762 Framework from an ordered sequence of Application Data Units. The 763 allocation of Application Data Units to blocks is dependent on the 764 application. Note that some Application Data Units may not be 765 included in any block. Each Source Block provided to the FEC scheme 766 consists of an ordered sequence of Application Data Units where the 767 following information is provided for each ADU: 769 o A description of the Source Data Flow with which the Application 770 Data Unit is associated (See 6.5) 772 o The Application Data Unit itself 774 o The length of the Application Data Unit 776 5.3. Packet format for FEC Source packets 778 The packet format for FEC Source packets MUST be used to transport 779 the payload of an original source packet. As depicted in Figure 6, 780 it consists of the original packet, optionally followed by the 781 Explicit Source FEC Payload ID field. The FEC Scheme determines 782 whether the Explicit Source FEC Payload ID field is required. This 783 determination is specific to each ADU flow. 785 +------------------------------------+ 786 | IP header | 787 +------------------------------------+ 788 | Transport header | 789 +------------------------------------+ 790 | Application Data Unit | 791 +------------------------------------+ 792 | Explicit Source FEC Payload ID | 793 +------------------------------------+ 795 Figure 6: Structure of the FEC packet format for FEC Source packets 797 The FEC Source packets MUST be sent using the same ADU flow as would 798 have been used for the original source packets if the FEC Framework 799 were not present. The transport payload of the FEC Source packet 800 MUST consist of the Application Data Unit followed by the Explicit 801 Source FEC Payload ID field, if required. 803 The Explicit Source FEC Payload ID field contains information 804 required to associate the source packet with a source block and for 805 the operation of the FEC algorithm and is defined by the FEC Scheme. 806 The format of the Source FEC Payload ID field is defined by the FEC 807 Scheme. Note that in the case that the FEC Scheme or CDP defines a 808 means to derive the Source FEC Payload ID from other information in 809 the packet (for example a sequence number used by the application 810 protocol), then the Source FEC Payload ID field is not included in 811 the packet. In this case the original source packet and FEC Source 812 Packet are identical. 814 In applications where avoidance of IP packet fragmentation is a goal, 815 Content Delivery Protocols SHOULD consider the Explicit Source FEC 816 Payload ID size when determining the size of Application Data Units 817 that will be delivered using the FEC Framework. This is because the 818 addition of the Explicit Source FEC Payload ID increases the packet 819 length. 821 Note: The Explicit Source FEC Payload ID is placed at the end of the 822 packet so that in the case that Robust Header Compression [RFC3095] 823 or other header compression mechanisms are used and in the case that 824 a ROHC profile is defined for the protocol carried within the 825 transport payload (for example RTP), then ROHC will still be applied 826 for the FEC Source packets. Applications that may be used with this 827 Framework should consider that FEC Schemes may add this Explicit 828 Source FEC Payload ID and thereby increase the packet size. 830 In many applications, support for Forward Error Correction is added 831 to a pre-existing protocol and in this case use of the Explicit 832 Source FEC Payload ID may break backwards compatibility, since source 833 packets are modified. 835 5.3.1. Generic Explicit Source FEC Payload Id 837 In order to apply FEC protection using multiple FEC Schemes to a 838 single source flow all schemes must use the same Explicit Source FEC 839 Payload Id format. In order to enable this, it is RECOMMENDED that 840 FEC Schemes support the Generic Explicit Source FEC Payload Id format 841 described below. 843 The Generic Explicit Source FEC Payload Id has length of 2 bytes and 844 consists of an unsigned packet sequence number in network byte order. 845 The allocation of sequence numbers to packets is independent of any 846 FEC Scheme and of the Source Block construction, except that the use 847 of this sequence number places a constraint on source block 848 construction. Source packets within a given source block MUST have 849 consecutive sequence numbers (where consecutive includes wrap-around 850 from the maximum value which can be represented in 2 bytes - 65535 - 851 to 0). Sequence numbers SHOULD NOT be reused until all values in the 852 sequence number space have been used. 854 5.4. Packet Format for FEC Repair packets 856 The packet format for FEC Repair packets is shown in Figure 7. The 857 transport payload consists of a Repair FEC Payload ID field followed 858 by repair data generated in the FEC encoding process. 860 +------------------------------------+ 861 | IP header | 862 +------------------------------------+ 863 | Transport header | 864 +------------------------------------+ 865 | Repair FEC Payload ID | 866 +------------------------------------+ 867 | Repair Symbols | 868 +------------------------------------+ 870 Figure 7: Packet format for repair packets 872 The Repair FEC Payload ID field contains information required for the 873 operation of the FEC algorithm at the receiver. This information is 874 defined by the FEC Scheme. The format of the Repair FEC Payload ID 875 field is defined by the FEC Scheme. 877 5.4.1. Packet Format for FEC Repair packets over RTP 879 For FEC Schemes which specify the use of RTP for repair packets, the 880 packet format for repair packets includes an RTP header as shown in 881 Figure 8. 883 +------------------------------------+ 884 | IP header | 885 +------------------------------------+ 886 | Transport header (UDP) | 887 +------------------------------------+ 888 | RTP Header | 889 +------------------------------------+ 890 | Repair FEC Payload ID | 891 +------------------------------------+ 892 | Repair Symbols | 893 +------------------------------------+ 895 Figure 8: Packet format for repair packets 897 5.5. FEC Framework Configuration Information 899 The FEC Framework Configuration Information is information that the 900 FEC Framework needs in order to apply FEC protection to the ADU 901 flows. A complete Content Delivery Protocol specification that uses 902 the framework specified here MUST include details of how this 903 information is derived and communicated between sender and receiver. 905 The FEC Framework Configuration Information includes identification 906 of the set of Source Data Flows. For example, in the case of UDP, 907 each Source Data Flow is uniquely identified by a tuple { Source IP 908 Address, Destination IP Address, Source UDP port, Destination UDP 909 port }. Note that in some applications some of these fields may 910 contain wildcards, so that the flow is identified by a subset of the 911 fields and in particular in many applications the limited tuple { 912 Destination IP Address, Destination UDP port } is sufficient. 914 A single instance of the FEC Framework provides FEC protection for 915 packets of the specified set of Source Data Flows, by means of one or 916 more packet flows consisting of repair packets. The FEC Framework 917 Configuration Information includes, for each instance of the FEC 918 Framework: 920 1. Identification of the packet flow(s) carrying FEC Repair 921 packets, known as the FEC repair flow(s). 923 2. For each Source Data Flow protected by the FEC repair flow(s): 925 a. Definition of the Source Data Flow carrying source packets 926 (for example, by means of a tuple as described above for UDP). 928 b. An integer identifier for this Source Data Flow. This 929 identifier MUST be unique amongst all Source Data Flows which 930 are protected by the same FEC repair flow. 932 3. The FEC Encoding ID, identifying the FEC Scheme 934 4. The length of the Explicit Source FEC Payload Id, in bytes 936 5. Zero or more FEC-Scheme-specific information elements, each 937 consisting of a name and a value where the valid element names and 938 value ranges are defined by the FEC Scheme 940 Multiple instances of the FEC Framework, with separate and 941 independent FEC Framework Configuration Information, may be present 942 at a sender or receiver. A single instance of the FEC Framework 943 protects packets of the Source Data Flows identified in (2) above 944 i.e. all packets sent on those flows MUST be FEC Source packets as 945 defined in Section 5.3. A single Source Data Flow may be protected 946 by multiple instances of the FEC Framework. 948 The integer flow identifier identified in 2(b) is a "shorthand" to 949 identify source flows between the FEC Framework and the FEC Scheme. 950 The reason for defining this as an integer, and including it in the 951 FEC Framework Configuration Information is so that the FEC Scheme at 952 the sender and receiver may use it to identify the source flow with 953 which a recovered packet is associated. The integer flow identifier 954 may therefore take the place of the complete flow description (e.g. 955 UDP 4-tuple). 957 Whether and how this flow identifier is used is defined by the FEC 958 Scheme. Since source packets are directly associated with a flow by 959 virtue of their packet headers, this identifier need not be carried 960 in source packets. Since repair packets may provide protection for 961 multiple source flows, repair packets would either not carry the 962 identifier at all or may carry multiple identifiers. However, in any 963 case, the flow identifier associated with a particular source packet 964 may be recovered from the repair packets as part of an FEC decoding 965 operation. Integer flow identifiers SHOULD be allocated starting 966 from zero and increasing by one for each flow. 968 A single FEC repair flow provides repair packets for a single 969 instance of the FEC Framework. Other packets MUST NOT be sent within 970 this flow i.e. all packets in the FEC repair flow MUST be FEC repair 971 packets as defined in Section 5.4 and MUST relate to the same FEC 972 Framework instance. 974 In the case that RTP is used for repair packets, the identification 975 of the repair packet flow MAY also include the RTP Payload Type to be 976 used for repair packets. 978 FEC Scheme-specific information elements MAY be encoded into a text 979 string for transport within Content Delivery Protocols as according 980 to the following ABNF [RFC5234]: 982 scheme-specific-info = [ element *( ',' element ) ] 983 element = name ':' value 984 name = token 985 token = 1* 986 value = * 987 separators = "(" | ")" | "<" | ">" | "@" 988 | "," | ";" | ":" | "\" | <"> 989 | "/" | "[" | "]" | "?" | "=" 990 | "{" | "}" | SP | HT 992 5.6. FEC Scheme requirements 994 In order to be used with this framework, an FEC Scheme MUST be 995 capable of processing data arranged into blocks of Application Data 996 Units (source blocks). 998 A specification for a new FEC scheme MUST include the following 999 things: 1001 1. The FEC Encoding ID value that uniquely identifies the FEC 1002 scheme. This value MUST be registered with IANA as described in 1003 Section 10. 1005 2. The type, semantics and encoding format of the Repair FEC Payload 1006 ID. 1008 3. The name, type, semantics and text value encoding rules for zero 1009 or more FEC Scheme-specific FEC Framework Configuration 1010 Information elements. Names must conform to the "name" 1011 production and values encodings to the "value" production defined 1012 in Section 5.5 1014 4. A full specification of the FEC code. 1016 This specification MUST precisely define the valid FEC-Scheme- 1017 Specific FEC Framework Configuration Information values, the 1018 valid FEC Payload ID values and the valid packet payload sizes 1019 (where packet payload refers to the space within a packet 1020 dedicated to carrying encoding symbol bytes). 1022 Furthermore, given a source block as defined in Section 5.2, 1023 valid values of the FEC-Scheme-Specific FEC Framework 1024 Configuration Information, a valid Repair FEC Payload ID value 1025 and a valid packet payload size, the specification MUST uniquely 1026 define the values of the encoding symbol bytes to be included in 1027 the repair packet payload of a packet with the given Repair FEC 1028 Payload ID value. 1030 A common and simple way to specify the FEC code to the required 1031 level of detail is to provide a precise specification of an 1032 encoding algorithm which, given a source block, valid values of 1033 the FEC-Scheme-Specific FEC Framework Configuration Information, 1034 a valid Repair FEC Payload ID value and a valid packet payload 1035 size as input produces the exact value of the encoding symbol 1036 bytes as output. 1038 5. A description of practical encoding and decoding algorithms. 1040 This description need not be to the same level of detail as for 1041 the encoding above, however it must be sufficient to demonstrate 1042 that encoding and decoding of the code is both possible and 1043 practical. 1045 FEC scheme specifications MAY additionally define the following: 1047 1. Type, semantics and encoding format of an Explicit Source FEC 1048 Payload ID. 1050 Whenever an FEC scheme specification defines an 'encoding format' for 1051 an element, this must be defined in terms of a sequence of bytes 1052 which can be embedded within a protocol. The length of the encoding 1053 format MUST either be fixed or it must be possible to derive the 1054 length from examining the encoded bytes themselves. For example, the 1055 initial bytes may include some kind of length indication. 1057 FEC scheme specifications SHOULD use the terminology defined in this 1058 document and SHOULD follow the following format: 1060 1. Introduction 1063 2. Formats and Codes 1065 2.1 Source FEC Payload ID(s) 1069 2.2 Repair FEC Payload Id 1072 2.3 FEC Framework Configuration Information 1076 3. Procedures 1081 4. FEC code specification 1084 Specifications MAY include additional sections, for example, 1085 examples. 1087 Each FEC scheme MUST be specified independently of all other FEC 1088 schemes; for example, in a separate specification or a completely 1089 independent section of larger specification (except, of course, a 1090 specification of one FEC Scheme may include portions of another by 1091 reference). 1093 Where an RTP Payload Format is defined for repair data for a specific 1094 FEC Scheme, the RTP Payload Format and the FEC Scheme MAY be 1095 specified within the same document. 1097 6. Feedback 1099 Many applications require some kind of feedback on transport 1100 performance: how much data arrived at the receiver, at what rate, 1101 when etc. When FEC is added to such applications, feedback 1102 mechanisms may also need to be enhanced to report on the performance 1103 of the FEC (for example how much lost data was recovered by the FEC). 1105 When used to provide instrumentation for engineering purposes, it is 1106 important to remember that FEC is generally applied to relatively 1107 small blocks of data (in the sense that each block is transmitted 1108 over a relatively small period of time) and so feedback information 1109 averaged over longer periods of time than the FEC block transmission 1110 time will likely not provide sufficient information for engineering 1111 purposes. For example see [RFC5725]. 1113 Applications which used feedback for congestion control purposes MUST 1114 calculate such feedback on the basis of packets received before FEC 1115 recovery is applied. If this requirement conflicts with other uses 1116 of the feedback information then the application MUST be enhanced to 1117 support both information calculated pre- and post- FEC recovery. 1118 This is to ensure that congestion control mechanisms operate 1119 correctly based on congestion indications received from the network, 1120 rather than on post-FEC recovery information which would give an 1121 inaccurate picture of congestion conditions. 1123 New applications which require such feedback SHOULD use RTP/RTCP 1124 [RFC3550]. 1126 7. Transport Protocols 1128 This framework is intended to be used to define Content Delivery 1129 Protocols which operate over transport protocols which provide an 1130 unreliable datagram service, including in particular the User 1131 Datagram Protocol (UDP) and the Datagram Congestion Control Protocol 1132 (DCCP). 1134 8. Congestion Control 1136 This section starts with a informative section on the motivation of 1137 the normative requirements for congestion control, which are spelled 1138 out in Section 8.1. 1140 Informative Note: The enforcement of Congestion Control (CC) 1141 principles has gained a lot of momentum in the IETF over the 1142 recent years. While the need of CC over the open Internet is 1143 unquestioned, and the goal of TCP friendliness is generally agreed 1144 for most (but not all) applications, the subject of congestion 1145 detection and measurement in heterogeneous networks can hardly be 1146 considered as solved. Most congestion control algorithms detect 1147 and measure congestion by taking (primarily or exclusively) the 1148 packet loss rate into account. This appears to be inappropriate 1149 in environments where a large percentage of the packet losses are 1150 the result of link-layer errors and independent of the network 1151 load. Note that such environments exist in the "open Internet", 1152 as well as in "closed" IP based networks. An example for the 1153 former would be the use of IP/UDP/RTP based streaming from an 1154 Internet-connected streaming server to a device attached to the 1155 Internet using cellular technology. 1157 The authors of this draft are primarily interested in applications 1158 where the application reliability requirements and end-to-end 1159 reliability of the network differ, such that it warrants higher 1160 layer protection of the packet stream - for example due to the 1161 presence of unreliable links in the end-to-end path - and where 1162 real-time, scalability or other constraints prohibit the use of 1163 higher layer (transport or application) feedback. A typical 1164 example for such applications is multicast and broadcast streaming 1165 or multimedia transmission over heterogeneous networks. In other 1166 cases, application reliability requirements may be so high that 1167 the required end-to-end reliability is difficult to achieve even 1168 over wired networks. Furthermore the end-to-end network 1169 reliability may not be known in advance. 1171 This FEC framework is not proposed, nor intended, as a QoS 1172 enhancement tool to combat losses resulting from highly congested 1173 networks. It should not be used for such purposes. 1175 In order to prevent such mis-use, one approach would be to leave 1176 standardisation to bodies most concerned with the problem 1177 described above. However, the IETF defines base standards used by 1178 several bodies, including DVB, 3GPP, 3GPP2, all of which appear to 1179 share the environment and the problem described. 1181 Another approach would be to write a clear applicability statement 1182 - for example restricting use of the framework to networks with 1183 wireless links. However, there may be applications where the use 1184 of FEC may be justified to combat congestion-induced packet losses 1185 - particularly in lightly loaded networks, where congestion is the 1186 result of relatively rare random peaks in instantaneous traffic 1187 load - thereby intentionally violating congestion control 1188 principles. One possible example for such an application could be 1189 a no-matter-what, brute-force FEC protection of traffic generated 1190 as an emergency signal. 1192 We propose a third approach, which is to require at a minimum that 1193 the use of this framework with any given application, in any given 1194 environment, does not cause congestion issues which the 1195 application alone would not itself cause i.e. the use of this 1196 framework must not make things worse. 1198 Taking above considerations into account, Section 8.1 specifies a 1199 small set of constraints for the FEC, which are mandatory for all 1200 senders compliant with this FEC framework. Further restrictions 1201 may be imposed for certain Content Delivery Protocols. In this it 1202 follows the spirit of the congestion control section of RTP and 1203 its Audio-Visual Profile (RFC3550/STD64 and RFC3551/STD65). 1205 One of the constraints effectively limits the bandwidth for the 1206 FEC protected packet stream to be no more than roughly twice as 1207 high as the original, non-FEC protected packet stream. This 1208 disallows the (static or dynamic) use of excessively strong FEC to 1209 combat high packet loss rates, which may otherwise be chosen by 1210 naively implemented dynamic FEC-strength selection mechanisms. We 1211 acknowledge that there may be a few exotic applications, e.g. IP 1212 traffic from space-based senders, or senders in certain hardened 1213 military devices, which would warrant a higher FEC strength. 1214 However, in this specification we give preference to the overall 1215 stability and network friendliness of the average application, and 1216 for those a factor of 2 appears to be appropriate. 1218 A second constraint requires that the FEC protected packet stream 1219 be in compliance with the congestion control in use for the 1220 application and network in question. 1222 8.1. Normative requirements 1224 The bandwidth of FEC Repair packet flows MUST NOT exceed the 1225 bandwidth of the source packet flows being protected. In addition, 1226 whenever the source packet flow bandwidth is adapted due to the 1227 operation of congestion control mechanisms, the FEC repair packet 1228 flow bandwidth MUST be similarly adapted. 1230 9. Security Considerations 1232 The application of FEC protection to a stream does not provide any 1233 kind of security protection. 1235 If security services are required for the stream, then they MUST 1236 either be applied to the original source data before FEC protection 1237 is applied, or to both the source and repair data, after FEC 1238 protection has been applied. 1240 If integrity protection is applied to source packets before FEC 1241 protection is applied, and no further integrity protection is applied 1242 to repair packets, then a denial of service attack is possible if an 1243 attacker is in a position to inject fake repair transport payloads. 1244 If received by a receiver, such fake repair transport payloads could 1245 cause incorrect FEC decoding resulting in incorrect Application Data 1246 Units being passed up to the application protocol. A similar attack 1247 may be possible if an attacker is in a position to inject fake FEC 1248 Framework Configuration Information or fake FEC Payload IDs. Such 1249 incorrect decoded Application Data Units would then be detected by 1250 the source integrity protection and discarded, resulting in partial 1251 or complete denial of service. Therefore, in such environments, 1252 integrity protection MUST also be applied to the FEC repair transport 1253 payloads, FEC Framework Configuration Information and FEC Payload 1254 IDs, for example using IPsec to integrity protect all packets. 1255 Receivers MUST also verify the integrity of source symbols before 1256 including the source symbols into the source block for FEC purposes. 1258 It is possible that multiple streams with different confidentiality 1259 requirements (for example, the streams may be visible to different 1260 sets of users) can be FEC protected by a single repair stream. This 1261 scenario is not recommended, since resources will be used to 1262 distribute and FEC decode encrypted data which cannot then be 1263 decrypted by at least some receivers. However, in this scenario, 1264 confidentiality protection MUST be applied before FEC encoding of the 1265 streams, otherwise repair transport payload may be used by a receiver 1266 to decode unencrypted versions of source streams which they do not 1267 have permissions to view. 1269 10. IANA Considerations 1271 FEC Schemes for use with this framework may be identified in 1272 protocols using FEC Encoding IDs. Values of FEC Encoding IDs are 1273 subject to IANA registration. They are in the registry named "FEC 1274 Framework (FECFRAME) FEC Encoding IDs" located at time of publication 1275 at . 1277 The values that can be assigned within the FEC Framework (FECFRAME) 1278 FEC Encoding ID registry are numeric indexes in the range [0, 255], 1279 boundaries included. Assignment requests are granted on a "IETF 1280 Consensus" basis as defined in[RFC5226] . Section 5.6 defines 1281 explicit requirements that documents defining new FEC Encoding IDs 1282 should meet. 1284 11. Acknowledgments 1286 This document is based in part on [I-D.watson-tsvwg-fec-sf] and so 1287 thanks are due to the additional authors of that document, Mike Luby, 1288 Magnus Westerlund and Stephan Wenger. That document was in turn 1289 based on the FEC streaming protocol defined by 3GPP in [MBMSTS] and 1290 thus thanks are also due to the participants in 3GPP TSG SA working 1291 group 4. Further thanks are due to the members of the FECFRAME 1292 working group for their comments and review. 1294 12. References 1296 12.1. Normative references 1298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1299 Requirement Levels", BCP 14, RFC 2119, March 1997. 1301 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1302 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1303 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1304 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1305 Compression (ROHC): Framework and four profiles: RTP, UDP, 1306 ESP, and uncompressed", RFC 3095, July 2001. 1308 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1309 Correction (FEC) Building Block", RFC 5052, August 2007. 1311 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1312 Jacobson, "RTP: A Transport Protocol for Real-Time 1313 Applications", STD 64, RFC 3550, July 2003. 1315 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1316 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1317 May 2008. 1319 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1320 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1322 12.2. Informative references 1324 [I-D.watson-tsvwg-fec-sf] 1325 Watson, M., "Forward Error Correction (FEC) Streaming 1326 Framework", draft-watson-tsvwg-fec-sf-00 (work in 1327 progress), July 2005. 1329 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 1330 Report Block Type for RTP Control Protocol (RTCP) Extended 1331 Reports (XRs)", RFC 5725, February 2010. 1333 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1334 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1335 July 2006. 1337 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 1338 Payload Format Specifications", BCP 36, RFC 2736, 1339 December 1999. 1341 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1342 Protocols and codecs", 3GPP TS 26.346, April 2005. 1344 Author's Address 1346 Mark Watson 1347 Qualcomm, Inc. 1348 3165 Kifer Road 1349 Santa Clara, CA 95051 1350 U.S.A. 1352 Email: watson@qualcomm.com