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