idnits 2.17.1 draft-ietf-fecframe-framework-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (July 8, 2009) is 5378 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 1204 -- Looks like a reference, but probably isn't: '255' on line 1204 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-avt-post-repair-rtcp-xr-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 Digital Fountain 4 Intended status: Standards Track July 8, 2009 5 Expires: January 9, 2010 7 Forward Error Correction (FEC) Framework 8 draft-ietf-fecframe-framework-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 9, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document describes for a framework for using forward error 57 correction (FEC) codes with applications in public and private IP 58 networks to provide protection against packet loss. The framework 59 supports applying Forward Error Correction to arbitrary packet flows 60 over unreliable transport and is primarily intended for real-time, or 61 streaming, media. This framework can be used to define Content 62 Delivery Protocols that provide Forward Error Correction for 63 streaming media delivery or other packet flows. Content Delivery 64 Protocols defined using this framework can support any FEC Scheme 65 (and associated FEC codes) which is compliant with various 66 requirements defined in this document. Thus, Content Delivery 67 Protocols can be defined which are not specific to a particular FEC 68 Scheme and FEC Schemes can be defined which are not specific to a 69 particular Content Delivery Protocol. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 7 75 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 9 76 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10 77 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 14 78 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15 80 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18 81 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 22 82 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 6.2. Structure of the source block . . . . . . . . . . . . . . 22 84 6.3. Packet format for FEC Source packets . . . . . . . . . . . 22 85 6.3.1. Generic Explicit Source FEC Payload Id . . . . . . . . 24 86 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 24 87 6.4.1. Packet Format for FEC Repair packets over RTP . . . . 24 88 6.5. FEC Framework Configuration Information . . . . . . . . . 25 89 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 26 90 7. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 91 8. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 31 92 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 32 93 9.1. Normative requirements . . . . . . . . . . . . . . . . . . 33 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 96 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 98 13.1. Normative references . . . . . . . . . . . . . . . . . . . 38 99 13.2. Informative references . . . . . . . . . . . . . . . . . . 38 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 102 1. Introduction 104 Many applications have a requirement to transport a continuous stream 105 of packetised data from a source (sender) to one or more destinations 106 (receivers) over networks which do not provide guaranteed packet 107 delivery. Primary examples are real-time, or streaming, media 108 applications such as broadcast, multicast or on-demand audio, video 109 or multimedia. 111 Forward Error Correction is a well-known technique for improving 112 reliability of packet transmission over networks which do not provide 113 guaranteed packet delivery, especially in multicast and broadcast 114 applications. The FEC Building Block defined in [RFC5052] provides a 115 framework for definition of Content Delivery Protocols (CDPs) for 116 object delivery (including, primarily, file delivery) which make use 117 of separately defined FEC Schemes. Any CDP defined according to the 118 requirements of the FEC Building Block can then easily be used with 119 any FEC Scheme which is also defined according to the requirements of 120 the FEC Building Block. (Note that the term "Forward Erasure 121 Correction" is sometimes used, 'erasures' being a type of error in 122 which data is lost and this loss can be detected, rather than being 123 received in corrupted form - the focus of this document is strictly 124 on erasures, however the term Forward Error Correction is more widely 125 used). 127 This document defines a framework for the definition of CDPs which 128 provide for FEC protection of arbitrary packet flows over unreliable 129 transports such as UDP. As such, this document complements the FEC 130 Building Block of [RFC5052], by providing for the case of arbitrary 131 packet flows over unreliable transport, the same kind of framework as 132 that document provides for object delivery. This document does not 133 define a complete Content Delivery Protocol, but rather defines only 134 those aspects that are expected to be common to all Content Delivery 135 Protocols based on this framework. 137 This framework does not define how the flows to be protected are 138 determined, nor how the details of the protected flows and the FEC 139 streams which protect them are communicated from sender to receiver. 140 It is expected that any complete Content Delivery Protocol 141 specification which makes use of this framework will address these 142 signalling requirements. However, this document does specify the 143 information which is required by the FEC Framework at the sender and 144 receiver - for example details of the flows to be FEC protected, the 145 flow(s) that will carry the FEC protection data and an opaque 146 container for FEC-Scheme-specific information. 148 FEC Schemes designed for use with this framework must fulfil a number 149 of requirements defined in this document. Note that these 150 requirements are different from those defined in [RFC5052] for FEC 151 Schemes for object delivery. However there is a great deal of 152 commonality and FEC Schemes defined for object delivery may be easily 153 adapted for use with the framework defined here. 155 Since the RTP protocol layer is used over UDP, this framework can be 156 applied to RTP flows as well. FEC repair packets may be sent 157 directly over UDP or over RTP. The latter approach has the advantage 158 that RTP instrumentation, based on RTCP, can be used for the repair 159 flow. Additionally, the post-repair RTCP extended report 160 [I-D.ietf-avt-post-repair-rtcp-xr] may be used to obtain information 161 about the loss rate after FEC recovery. 163 The use of RTP for repair flows is defined for each FEC Scheme by 164 defining an RTP Payload Format for that particular FEC Scheme 165 (possibly in the same document). 167 2. Definitions/Abbreviations 169 'FEC' Forward Error Correction. 171 'AL-FEC' Application Layer Forward Error Correction 173 'FEC Framework' A protocol framework for definition of Content 174 Delivery Protocols using FEC, such as the framework defined in 175 this document. 177 'Source data flow' The packet flow or flows to which FEC protection 178 is to be applied. 180 'Repair data flow' The packet flow or flows carrying forward error 181 correction data 183 'Source protocol' A protocol used for the source data flow being 184 protected - e.g. RTP. 186 'Transport protocol' The protocol used for transport of the source 187 data flow being protected - e.g. UDP, DCCP. 189 'Application Data Unit' Data used as the payload for the transport 190 layer (e.g. UDP or DCCP packet payload) 192 'Application protocol' Control protocols used to establish and 193 control the source data flow being protected - e.g. RTSP. 195 'FEC Code' An algorithm for encoding data such that the encoded data 196 flow is resiliant to data loss or corruption. 198 'FEC Scheme' A specification which defines the additional protocol 199 aspects required to use a particular FEC code with the FEC 200 Framework, or (in the context of RMT), with the RMT FEC Building 201 Block. 203 'Source Block' the group of source data packets which are to be FEC 204 protected as a single block 206 'Protection amount' The relative increase in data sent due to the 207 use of FEC. 209 FEC Framework Configuration Information: Information which controls 210 the operation of the FEC Framework. 212 FEC Payload ID: Information which identifies the contents of a 213 packet with respect to the FEC Scheme. 215 Source FEC Payload ID: An FEC Payload ID specifically for use with 216 source packets. 218 Repair FEC Payload ID: An FEC Payload ID specifically for use with 219 repair packets. 221 Content Delivery Protocol (CDP): A complete application protocol 222 specification which, through the use of the framework defined in 223 this document, is able to make use of FEC Schemes to provide 224 Forward Error Correction capabilities. 226 3. Requirements notation 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in [RFC2119]. 232 4. Architecture Overview 234 The FEC Framework is described in terms of an additional layer 235 between the transport layer (e.g. UDP or DCCP) and protocols running 236 over this transport layer. Examples of such protocols are RTP, RTCP, 237 etc. As such, the data path interface between the FEC Framework and 238 both underlying and overlying layers can be thought of as being the 239 same as the standard interface to the transport layer - i.e. the data 240 exchanged consists of datagram payloads each associated with a single 241 transport flow identified (in the case of UDP) by the standard 242 5-tuple { Source IP Address, Source Transport Port, Destination IP 243 Address, Destination Transport Port, Transport Protocol }. In the 244 case that RTP is used for the repair flows, the source and repair 245 data may be multiplexed using RTP onto a single UDP flow and must 246 consequently be demultiplexed at the receiver. There are various 247 ways in which this multiplexing can be done, for example as described 248 in [RFC4588]. In this case the interface to the FEC Framework, at 249 least for the repair flows, can be thought of as equivalent to that 250 between RTP and users of RTP. 252 It is important to understand that the main purpose of the FEC 253 Framework architecture is to allocate fuctional responsibilities to 254 separately documented components in such a way that specific 255 instances of the components can be combined in different ways to 256 describe different protocols. 258 The FEC Framework makes use of an FEC Scheme, in a similar sense to 259 that defined in [RFC5052] and uses the terminology of that document. 260 The FEC Scheme defines the FEC encoding and decoding and defines the 261 protocol fields and procedures used to identify packet payload data 262 in the context of the FEC Scheme. The interface between the FEC 263 Framework and an FEC Scheme, which is described in this document, is 264 a logical one, which exists for specification purposes only. At an 265 encoder, the FEC Framework passes groups of transport packet payloads 266 to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC 267 repair packet payloads, encoded FEC Payload ID information for each 268 of the repair packets and, in some cases, encoded FEC Payload ID 269 information for each of the source packets. At a decoder, the FEC 270 Framework passes transport packet payloads (source and repair) to the 271 FEC Scheme and the FEC Scheme returns additional recovered source 272 packet payloads. 274 This document defines certain FEC Framework Configuration Information 275 which MUST be available to both sender and receiver(s). For example, 276 this information includes the specification of the transport flows 277 which are to be FEC protected, specification of the transport flow(s) 278 which will carry the FEC protection (repair) data and the 279 relationship(s) between these 'source' and 'repair' flows (i.e. which 280 source flow(s) are protected by each repair flow. The FEC Framework 281 Configuration Information also includes information fields which are 282 specific to the FEC Scheme. This information is analagous to the FEC 283 Object Transmission Information defined in [RFC5052]. 285 The FEC Framework does not define how the FEC Framework Configuration 286 Information for the stream is communicated from sender to receiver. 287 This must be defined by any Content Delivery Protocol specification 288 as described in the following sections. 290 In this architecture we assume that the interface to the transport 291 layer supports the concepts of data units (referred to here as 292 Application Data Units) to be transported and identification of 293 transport flows on which those data units are transported. Since 294 this is an interface internal to the architecture, we do not specify 295 this interface explicitly, except to say that transport flows which 296 are distinct from the transport layer point of view (for example, 297 distinct UDP flows as identified by the UDP source/destination ports/ 298 addresses) are also distinct on the interface between the transport 299 layer and the FEC Framework. 301 As noted above, RTP flows are a specific example of transport flows 302 which might be protected by the FEC Framework. From the FEC 303 Framework point of view, RTP source flows are sequences of UDP packet 304 payloads like any other protocol over UDP. 306 Depending on the FEC Scheme, RTP may also be used as a transport for 307 repair packet flows. In this case an FEC Scheme must define an RTP 308 Payload Format for the repair data. 310 The architecture outlined above is illustrated in the Figure 1. In 311 this architecture, two RTP instances are shown, for the source and 312 repair data respectively. This is because the use of RTP for the 313 source data is separate from and independent of the use of RTP for 314 the repair data. The appearance of two RTP instances is more natural 315 when you consider that in many FEC codes, the the repair payload 316 contains parity bytes calculated across the RTP headers of the source 317 packets. Thus a repair packet carried over RTP starts with an RTP 318 header of its own which is immediately followed by parity data 319 containing bytes which protect the source RTP headers (as well as 320 parity data for the source RTP payloads). 322 +--------------------------------------------+ 323 | Application | 324 +--------------------------------------------+ 325 | 326 | 327 | 328 + - - - - - - - - - - - - - - - - - - - - - - - -+ 329 | +--------------------------------------------+ | 330 | Application Layer | 331 | +--------------------------------------------+ | 332 | | 333 | + -- -- -- -- -- -- -- -- -- -- --+ | | 334 | RTP | | 335 | | | |-Configuration/Coordination 336 +- -- -- -- -- -- -- -- -- -- -- -+ | 337 | | | | 338 | Transport flows | 339 | | v | 340 +--------------------------------------------+ +----------------+ 341 | | FEC Framework (this document) |<--->| FEC Scheme | 342 +--------------------------------------------+ +----------------+ 343 | | | | 344 Source | Repair | 345 | | | | 346 +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ 347 | | RTP | | RTP processing | |<--- Optional 348 | | +-- -- -- |- -- -+ | - dependent on 349 | | +-- -- -- -- -- -- -- |--+ | | FEC Scheme 350 | | RTP (de)multiplexing | | 351 | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | 352 | 353 | +--------------------------------------------+ | 354 | Transport Layer (e.g. UDP) | 355 | +--------------------------------------------+ | 356 | 357 | +--------------------------------------------+ | 358 | IP | 359 | +--------------------------------------------+ | 360 Content Delivery Protocol 361 + - - - - - - - - - - - - - - - - - - - - - - - + 363 Figure 1: FEC Framework Architecture 365 The contents of the transport payload for repair packets is fully 366 defined by the FEC Scheme. For a specific FEC Scheme, a means MAY be 367 defined for repair data to be carried over RTP, in which case the 368 repair packet payload format starts with the RTP header. This 369 corresponds to defining an RTP Payload Format for the specific FEC 370 Scheme. Guidelines for writers of RTP Payload Formats are provided 371 in [RFC2736]. 373 The use of RTP for repair packets is independent of the protocols 374 used for source packets: if RTP is used for source packets then 375 repair packets may or may not use RTP and vice versa (although it is 376 unlikely that there are useful scenarios where non-RTP source flows 377 are protected by RTP repair flows). FEC Schemes are expected to 378 recover entire transport payloads for recovered source packets in all 379 cases. For example if RTP is used for source flows, the FEC Scheme 380 is expected to recover the entire UDP payload, including the RTP 381 header. 383 5. Procedural overview 385 5.1. General 387 The mechanism defined in this document does not place any 388 restrictions on the Application Data Units which can be protected 389 together, except that the Application Data Unit is carried over a 390 supported transport protocol (See Section 8). The data may be from 391 multiple Source Data Flows that are protected jointly. The FEC 392 framework handles the Source Data Flows as a sequence of 'source 393 blocks' each consisting of a set of Application Data Units, possibly 394 from multiple Source Data Flows which are to be protected together. 395 For example, each source block may be constructed from those 396 Application Data Units related to a particular segment in time of the 397 flow. 399 At the sender, the FEC Framework passes the payloads for a given 400 block to the FEC Scheme for FEC encoding. The FEC Scheme performs 401 the FEC encoding operation and returns the following information: 403 o optionally, encoded FEC Payload IDs for each of the source 404 payloads 406 o one or more FEC repair packet payloads 408 o encoded FEC Payload IDs for each of the repair packet payloads 410 The FEC framework then performs two operations: Firstly, it appends 411 the FEC payload IDs, if provided, to each of the Application Data 412 Units, and sends the resulting packets, known as 'FEC source 413 packets', to the receiver and secondly it places the provided 'FEC 414 repair packet payloads' and corresponding 'FEC Repair Payload IDs' 415 appropriately to construct 'FEC repair packets' and send them to the 416 receiver. Note that FEC repair packets MAY be sent to a different 417 multicast group or groups from the source packets. 419 This document does not define how the sender determines which source 420 Application Data Units are included in which source blocks or the 421 sending order and timing of FEC source and FEC repair packets. A 422 specific Content Delivery Protocol MAY define this mapping or it MAY 423 be left as implementation dependent at the sender. However, a CDP 424 specification MUST define how a receiver determines the length of 425 time it should wait to receive FEC repair packets for any given 426 source block. The sequence of operations at the sender is described 427 in more detail in Section 5.2. 429 At the receiver, original Application Data Units are recovered by the 430 FEC Framework directly from any FEC Source Packets received simply by 431 removing the Source FEC Payload ID, if present. The receiver also 432 passes the contents of the received Application Data Units, plus 433 their FEC Payload IDs to the FEC Scheme for possible decoding. 435 If any Application Data Units related to a given source block have 436 been lost, then the FEC Scheme may perform FEC decoding to recover 437 the missing Application Data Units (assuming sufficient FEC Source 438 and FEC Repair packets related to that source block have been 439 received). 441 Note that the receiver may need to buffer received source packets to 442 allow time for the FEC Repair packets to arrive and FEC decoding to 443 be performed before some or all of the received or recovered packets 444 are passed to the application. If such a buffer is not provided, 445 then the application must be able to deal with the severe re-ordering 446 of packets that may occur. However, such buffering is Content 447 Delivery Protocol and/or implementation-specific and is not specified 448 here. The receiver operation is described in more detail in 449 Section 5.3 451 The FEC Source packets MUST contain information which identifies the 452 source block and the position within the source block (in terms 453 specific to the FEC Scheme) occupied by the Application Data Unit. 454 This information is known as the 'Source FEC Payload ID'. The FEC 455 Scheme is responsible for defining and interpreting this information. 456 This information MAY be encoded into a specific field within the FEC 457 Source packet format defined in this specification, called the 458 Explicit Source FEC Payload ID field. The exact contents and format 459 of the Explicit Source FEC Payload ID field are defined by the FEC 460 Scheme. Alternatively, the FEC Scheme MAY define how the Source FEC 461 Payload ID is derived from other fields within the source packets. 462 This document defines the way that the Explicit Source FEC Payload ID 463 field is appended to source packets to form FEC Source packets. 465 The FEC Repair packets MUST contain information which identifies the 466 source block and the relationship between the contained repair 467 payloads and the original source block. This is known as the 'Repair 468 FEC Payload ID'. This information MUST be encoded into a specific 469 field, the Repair FEC Payload ID field, the contents and format of 470 which are defined by the FEC Scheme. 472 The FEC Scheme MAY use different FEC Payload ID field formats for FEC 473 Source packets and FEC Repair packets. 475 5.2. Sender Operation 477 It is assumed that the sender has constructed or received original 478 data packets for the session. These may be RTP, RTCP, MIKEY or 479 indeed any other type of packet. The following operations, 480 illustrated in Figure 2, for the case of UDP repair flows and 481 Figure 3 for the case of RTP repair flows, describe a possible way to 482 generate compliant FEC Source packet and FEC repair packet streams: 484 1. Application Data Units are provided by the application. 486 2. A source block is constructed as specified in Section 6.2. 488 3. The source block is passed to the FEC Scheme for FEC encoding. 489 The Source FEC Payload ID information of each Source packet is 490 determined by the FEC Scheme. If required by the FEC Scheme the 491 Source FEC Payload ID is encoded into the Explicit Source FEC 492 Payload ID field. 494 4. The FEC Scheme performs FEC Encoding, generating repair packet 495 payloads from a source block and a Repair FEC Payload ID field for 496 each repair payload. 498 5. The Explicit Source FEC Payload IDs (if used), Repair FEC 499 Payload IDs and repair packet payloads are provided back from the 500 FEC Scheme to the FEC Framework. 502 6. The FEC Framework constructs FEC Source packets according to 503 Section 6.3 and FEC Repair packets according to Section 6.4 using 504 the FEC Payload IDs and repair packet payloads provided by the FEC 505 Scheme. 507 7. The FEC Source and FEC Repair packets are sent using normal 508 transport layer procedures. The port(s) and multicast group(s) to 509 be used for FEC Repair packets are defined in the FEC Framework 510 Configuration Information. The FEC Source packets are sent using 511 the same transport flow identification information as would have 512 been used for the original source packets if the FEC Framework 513 were not present (for example, in the UDP case, the UDP source and 514 destination addresses and ports on the eventual IP FEC Source 515 Packet will be the same whether or not the FEC Framework is 516 applied). 518 +----------------------+ 519 | Application | 520 +----------------------+ 521 | 522 | (1) Application Data Units 523 | 524 v 525 +----------------------+ +------------------+ 526 | FEC Framework | | | 527 | |-------------------------->| FEC Scheme | 528 |(2) Construct source | (3) Source Block | | 529 | blocks | | (4) FEC Encoding | 530 |(6) Construct FEC src |<--------------------------| | 531 | packets and FEC | | | 532 | repair packets |(5) Ex src FEC Payload Ids,| | 533 +----------------------+ Repair FEC Payload Ids,+------------------+ 534 | Repair transport payloads 535 | 536 | (7) FEC Source packets and FEC repair packets 537 v 538 +----------------------+ 539 | Transport Layer | 540 | (e.g. UDP ) | 541 +----------------------+ 543 Figure 2: Sender operation 545 +----------------------+ 546 | Application | 547 +----------------------+ 548 | 549 | (1) Application Data Units 550 v 551 +----------------------+ +------------------+ 552 | FEC Framework | | | 553 | |-------------------------->| FEC Scheme | 554 |(2) Construct source | (3) Source Block | | 555 | blocks | | (4) FEC Encoding | 556 |(6) Construct FEC src |<--------------------------| | 557 | packets and FEC | | | 558 | repair packets |(5) Ex src FEC Payload Ids,| | 559 +----------------------+ Repair FEC Payload Ids,+------------------+ 560 | | Repair RTP payloads 561 |(7) Source | 562 | |(7') Repair RTP payloads 563 | + -- -- -- -- -+ 564 | | RTP | 565 | +-- -- -- -- --+ 566 v v 567 +----------------------+ 568 | Transport Layer | 569 | (e.g. UDP ) | 570 +----------------------+ 572 Figure 3: Sender operation with RTP repair flows 574 5.3. Receiver Operation 576 The following describes a possible receiver algorithm, illustrated in 577 Figure 4 and Figure 5 for the case of RTP repair flows, when 578 receiving an FEC source or repair packet: 580 1. FEC Source Packets and FEC Repair packets are received and 581 passed to the FEC Framework. The type of packet (Source or 582 Repair) and the Source Data Flow to which it belongs (in the case 583 of source packets) is indicated by the transport flow information 584 which identifies the flow at the transport layer (for example 585 source and destination ports and addresses in the case of UDP). 587 1a. In the special case that RTP is used for repair packets and 588 source and repair packets are multiplexed onto the same UDP flow, 589 then RTP demultiplexing is required to demultiplex source and 590 repair flows. However, RTP processing is applied only to the 591 repair packets at this stage: source packets continue to be 592 handled as UDP payloads (i.e. including their RTP headers). 594 2. The FEC Framework extracts the Explicit Source FEC Payload ID 595 field (if present) from FEC Source Packets and the Repair FEC 596 Payload ID from FEC Repair Packets. 598 3. The Explicit Source FEC Payload IDs (if present), Repair FEC 599 Payload IDs, FEC Source payloads and FEC Repair payloads are 600 passed to the FEC Scheme. 602 4. The FEC Scheme uses the received FEC Payload IDs (and derived 603 FEC Source Payload IDs in the case that the Explicit Source FEC 604 Payload ID field is not used) to group source and repair packets 605 into source blocks. If at least one source packet is missing from 606 a source block, and at least one repair packet has been received 607 for the same source block then FEC decoding may be performed in 608 order to recover missing source payloads. The FEC Scheme 609 determines whether source packets have been lost and whether 610 enough data for decoding of any or all of the missing source 611 payloads in the source block has been received. 613 5. The FEC Scheme returns the Application Data Unit to the FEC 614 Framework in the form of source blocks containing received and 615 decoded Application Data Units and indications of any Application 616 Data Units which were missing and could not be decoded. 618 6. The FEC Framework passes the received and recovered 619 Application Data Units to the application. 621 +----------------------+ 622 | Application | 623 +----------------------+ 624 ^ 625 | (6) Application Data Units 626 | 627 +----------------------+ +------------------+ 628 | FEC Framework | | | 629 | |<---------------------------| FEC Scheme | 630 |(2)Extract FEC Payload| (5) Application Data Units | | 631 | IDs and pass IDs & | | (4) FEC Decoding | 632 | Payloads to FEC |--------------------------->| | 633 | Scheme | (3) Ex src FEC Payload IDs,| | 634 +----------------------+ FEC Repair Payload IDs,+------------------+ 635 ^ FEC Source Payloads, 636 | FEC Repair Payloads 637 | 638 | (1) FEC Source packets and FEC repair packets 639 | 640 +----------------------+ 641 | Transport Layer | 642 | (e.g. UDP ) | 643 +----------------------+ 645 Figure 4: Receiver Operation 647 +----------------------+ 648 | Application | 649 +----------------------+ 650 ^ 651 | (6) Application Data Units 652 | 653 +----------------------+ +------------------+ 654 | FEC Framework | | | 655 | |<---------------------------| FEC Scheme | 656 |(2)Extract FEC Payload| (5) Application Data Units | | 657 | IDs and pass IDs & | | (4) FEC Decoding | 658 | Payloads to FEC |--------------------------->| | 659 | Scheme | (3) Ex src FEC Payload IDs,| | 660 +----------------------+ FEC Repair Payload IDs,+------------------+ 661 ^ ^ FEC Source Payloads, 662 | | FEC Repair Payloads 663 |Source pkts | 664 | |(1a) FEC repair payloads 665 +-- |- -- -- -- -- -- -+ 666 |RTP| | RTP processing | 667 | | +-- -- -- --|-- -+ 668 | +-- -- -- -- -- |--+ | 669 | | RTP demux | | 670 +-- -- -- -- -- -- -- -+ 671 | (1) FEC Source packets and FEC repair packets 672 +----------------------+ 673 | Transport Layer | 674 | (e.g. UDP ) | 675 +----------------------+ 677 Figure 5: Receiver Operation 679 Note that the above procedure may result in a situation in which not 680 all original source packets are recovered. 682 Source packets which are correctly received and those which are 683 reconstructed MAY be delivered to the application out of order and in 684 a different order from the order of arrival at the receiver. 685 Alternatively, buffering and packet re-ordering MAY be applied to re- 686 order received and reconstructed source packets into the order they 687 were placed into the source block, if that is necessary according to 688 the application. 690 6. Protocol Specification 692 6.1. General 694 This section specifies the protocol elements for the FEC Framework. 695 Three components of the protocol are defined in this document and are 696 described in the following sections: 698 1. Construction of a source block from Application Data Units. 699 The FEC code will be applied to this source block to produce the 700 repair payloads. 702 2. A format for packets containing source data. 704 3. A format for packets containing repair data. 706 The operation of the FEC Framework is governed by certain FEC 707 Framework Configuation Information. This configuration information 708 is also defined in this section. A complete protocol specification 709 that uses this framework MUST specify the means to determine and 710 communicate this information between sender and receiver. 712 6.2. Structure of the source block 714 The FEC Framework and FEC Scheme exchange Application Data Units in 715 the form of source blocks. A source block is generated by the FEC 716 Framework from an ordered sequence of Application Data Units. The 717 allocation of Application Data Units to blocks is dependent on the 718 application. Note that some Application Data Units may not be 719 included in any block. For each sApplication Data Units included in 720 a source block, the following information is provided to the FEC 721 Scheme: 723 o A description of the Source Data Flow with which the Application 724 Data Unit is associated (See 6.5) 726 o The Application Data Unit itself 728 o The length of the Application Data Unit 730 6.3. Packet format for FEC Source packets 732 The packet format for FEC Source packets MUST be used to transport 733 the payload of an original source packet. As depicted in Figure 6, 734 it consists of the original packet, optionally followed by the 735 Explicit Source FEC Payload ID field. The FEC Scheme determines 736 whether the Explicit Source FEC Payload ID field is required. This 737 determination is specific to each transport flow. 739 +------------------------------------+ 740 | IP header | 741 +------------------------------------+ 742 | Transport header | 743 +------------------------------------+ 744 | Application Data Unit | 745 +------------------------------------+ 746 | Explicit Source FEC Payload ID | 747 +------------------------------------+ 749 Figure 6: Structure of the FEC packet format for FEC Source packets 751 The FEC Source packets MUST be sent using the same transport flow as 752 would have been used for the original source packets if the FEC 753 Framework were not present. The transport payload of the FEC Source 754 packet MUST consist of the Application Data Unit followed by the 755 Explicit Source FEC Payload ID field, if required. 757 The Explicit Source FEC Payload ID field contains information 758 required to associate the source packet with a source block and for 759 the operation of the FEC algorithm and is defined by the FEC Scheme. 760 The format of the Source FEC Payload ID field is defined by the FEC 761 Scheme. Note that in the case that the FEC Scheme or CDP defines a 762 means to derive the Source FEC Payload ID from other information in 763 the packet (for example the a sequence number of some kind used by 764 the application protocol), then the Source FEC Payload ID field is 765 not included in the packet. In this case the original source packet 766 and FEC Source Packet are identical. 768 Since the addition of the Explicit Source FEC Payload ID increases 769 the packet length, then in applications where avoidance of IP packet 770 fragmentation is a goal, Content Delivery Protocols SHOULD consider 771 the Explicit Source FEC Payload ID size when determining the size of 772 Application Data Units that will be delivered using the FEC 773 Framework. 775 Note: The Explicit Source FEC Payload ID is placed at the end of the 776 packet so that in the case that Robust Header Compression [RFC3095] 777 or other header compression mechanisms are used and in the case that 778 a ROHC profile is defined for the protocol carried within the 779 transport payload (for example RTP), then ROHC will still be applied 780 for the FEC Source packets. Applications that may be used with this 781 Framework should consider that FEC Schemes may add this Explicit 782 Source FEC Payload ID and thereby increase the packet size. 784 6.3.1. Generic Explicit Source FEC Payload Id 786 In order to apply FEC protection using multiple FEC Schemes to a 787 single source flow all schemes must use the same Explicit Source FEC 788 Payload Id format. In order to enable this, it is RECOMMENDED that 789 FEC Schemes support the Generic Explicit Source FEC Payload Id format 790 described below. 792 The Generic Explicit Source FEC Payload Id has length 2 bytes and 793 consists of an unsigned packet sequence number in network byte order. 794 The allocation of sequence numbers to packets is independent of any 795 FEC Scheme and of the Source Block contruction, except that the use 796 of this sequence number places a constraint on source block 797 construction source packets within a gioven source block MUST have 798 consecutive sequence numbers (where consecutive includes wrap-around 799 from 65535 to 0). Sequence numbers SHOULD NOT be reused until all 800 values in the sequence nmber space have been used. 802 6.4. Packet Format for FEC Repair packets 804 The packet format for FEC Repair packets is shown in Figure 7. The 805 transport payload consists of a Repair FEC Payload ID field followed 806 by repair data generated in the FEC encoding process. 808 +------------------------------------+ 809 | IP header | 810 +------------------------------------+ 811 | Transport header | 812 +------------------------------------+ 813 | Repair FEC Payload ID | 814 +------------------------------------+ 815 | Repair Symbols | 816 +------------------------------------+ 818 Figure 7: Packet format for repair packets 820 The Repair FEC Payload ID field contains information required for the 821 operation of the FEC algorithm at the receiver. This information is 822 defined by the FEC Scheme. The format of the Repair FEC Payload ID 823 field is defined by the FEC Scheme. 825 6.4.1. Packet Format for FEC Repair packets over RTP 827 For FEC Schemes which specify the use of RTP for repair packets, the 828 packet format for repair packets includes an RTP header as shown in 829 Figure 8. 831 +------------------------------------+ 832 | IP header | 833 +------------------------------------+ 834 | Transport header (UDP) | 835 +------------------------------------+ 836 | RTP Header | 837 +------------------------------------+ 838 | Repair FEC Payload ID | 839 +------------------------------------+ 840 | Repair Symbols | 841 +------------------------------------+ 843 Figure 8: Packet format for repair packets 845 6.5. FEC Framework Configuration Information 847 The FEC Framework Configuration Information is information that the 848 FEC Framework needs in order to apply FEC protection to the transport 849 flows. A complete Content Delivery Protocol specification that uses 850 the framework specified here MUST include details of how this 851 information is derived and communicated between sender and receiver. 853 The FEC Framework Configuration Information includes identification 854 of the set of Source Data Flows. For example, in the case of UDP, 855 each Source Data Flow is uniquely identified by a tuple { Source IP 856 Address, Destination IP Address, Source UDP port, Destination UDP 857 port }. Note that in some applications some of these fields may be 858 wildcarded, so that the flow is identified by a subset of the fields 859 and in particular in many applications the limited tuple { 860 Destination IP Address, Destination UDP port } is sufficient. 862 A single instance of the FEC Framework provides FEC protection for 863 all packets of the specified set of Source Data Flows, by means of 864 one or more packet flows consisting of repair packets. The FEC 865 Framework Configuation Information includes, for each instance of the 866 FEC Framework: 868 1. Identification of the packet flow(s) carrying FEC Repair 869 packets, known as the FEC repair flow(s). 871 2. For each Source Data Flow protected by the FEC repair flow(s): 873 a. Defintion of the Source Data Flow carrying source packets 874 (for example, by means of a tuple as describe above for UDP). 876 b. An integer identifier for this flow definition (i.e. 877 tuple). This identifier MUST be unique amongst all Source Data 878 Flows which are protected by the same FEC repair flow. 880 3. The FEC Encoding ID, identifying the FEC Scheme 882 4. The length of the Explicit Source FEC Payload Id, in bytes 884 5. An opaque container for FEC-Scheme-specific information 886 Multiple instances of the FEC Framework, with separate and 887 independent FEC Framework Configuration Information, may be present 888 at a sender or receiver. A single instance of the FEC Framework 889 protects packets of the Source Data Flows identified in (2) above 890 i.e. all packets sent on those flows MUST be FEC Source packets as 891 defined in Section 6.3. A single Source Data Flow may be protected 892 by multiple instances of the FEC Framework. 894 The integer flow identifier identified in 2(b) is a "shorthand" to 895 identify source flows between the FEC Framework and the FEC Scheme. 896 The reason for defining this as an integer, and including it in the 897 FEC Framework Configuration Information is so that the FEC Scheme at 898 the sender and receiver may use it to identify the source flow with 899 which a recovered packet is associated. The integer flow identifier 900 may therefore take the place of the complete flow description (e.g. 901 UDP 4-tuple). 903 Whether and how this flow identifier is used is defined by the FEC 904 Scheme. Since source packets are directly associated with a flow by 905 virtue of their packet headers, this identifier need not be carried 906 in source packets. Since repair packets may provide protection for 907 multiple source flows, repair packets would either not carry the 908 identifier at all or may carry multiple identifiers. However, in any 909 case, the flow identifier associated with a particular source packet 910 may be recovered from the repair packets as part of an FEC decoding 911 operation. Integer flow identifiers SHOULD be allocated starting 912 from zero and increasing by one for each flow. 914 A single FEC repair flow provides repair packets for a single 915 instance of the FEC Framework. Other packets MUST NOT be sent within 916 this flow i.e. all packets in the FEC repair flow MUST be FEC repair 917 packets as defined in Section 6.4 and MUST relate to the same FEC 918 Framework instance. 920 In the case that RTP is used for repair packets, the identification 921 of the repair packet flow MAY also include the RTP Payload Type to be 922 used for repair packets. 924 6.6. FEC Scheme requirements 926 In order to be used with this framework, an FEC Scheme MUST be 927 capable of processing data arranged into blocks of Application Data 928 Units (source blocks). 930 A specification for a new FEC scheme MUST include the following 931 things: 933 1. The FEC Encoding ID value that uniquely identifies the FEC 934 scheme. This value MUST be registered with IANA as described in 935 Section 11. 937 2. The type, semantics and encoding format of the Repair FEC Payload 938 ID. 940 3. The type, semantics and encoding format of the FEC Scheme- 941 specific FEC Framework Configuration Information. 943 4. A full specification of the FEC code. 945 This specification MUST precisely define the valid FEC-Scheme- 946 Specific FEC Framework Configuration Information values, the 947 valid FEC Payload ID values and the valid packet payload sizes 948 (where packet payload refers to the space within a packet 949 dedicated to carrying encoding symbol bytes). 951 Furthermore, given a source block as defined in Section 6.2, 952 valid values of the FEC-Scheme-Specific FEC Framework 953 Configuration Information, a valid Repair FEC Payload ID value 954 and a valid packet payload size, the specification MUST uniquely 955 define the values of the encoding symbol bytes to be included in 956 the repair packet payload of a packet with the given Repair FEC 957 Payload ID value. 959 A common and simple way to specify the FEC code to the required 960 level of detail is to provide a precise specification of an 961 encoding algorithm which, given a source block, valid values of 962 the FEC-Scheme-Specific FEC Framework Configuration Information, 963 a valid Repair FEC Payload ID value and a valid packet payload 964 size as input produces the exact value of the encoding symbol 965 bytes as output. 967 5. A description of practical encoding and decoding algorithms. 969 This description need not be to the same level of detail as for 970 the encoding above, however it must be sufficient to demonstrate 971 that encoding and decoding of the code is both possible and 972 practical. 974 FEC scheme specifications MAY additionally define the following: 976 1. Type, semantics and encoding format of an Explicit Source FEC 977 Payload ID. 979 Whenever an FEC scheme specification defines an 'encoding format' for 980 an element, this must be defined in terms of a sequence of bytes 981 which can be embedded within a protocol. The length of the encoding 982 format MUST either be fixed or it must be possible to derive the 983 length from examining the encoded bytes themselves. For example, the 984 initial bytes may include some kind of length indication. 986 FEC scheme specifications SHOULD use the terminology defined in this 987 document and SHOULD follow the following format: 989 1. Introduction 992 2. Formats and Codes 994 2.1 Source FEC Payload ID(s) 998 2.2 Repair FEC Payload Id 1001 2.3 FEC Framework Configuration Information 1005 3. Procedures 1010 4. FEC code specification 1013 Specifications MAY include additional sections, for example, 1014 examples. 1016 Each FEC scheme MUST be specified independently of all other FEC 1017 schemes; for example, in a separate specification or a completely 1018 independent section of larger specification (except, of course, a 1019 specification of one FEC Scheme may include portions of another by 1020 reference). 1022 Where an RTP Payload Format is defined for repair data for a specific 1023 FEC Scheme, the RTP Payload Format and the FEC Scheme MAY be 1024 specified within the same document. 1026 7. Feedback 1028 Many applications require some kind of feedback on transport 1029 performance: how much data arrived at the receiver, at what rate, 1030 when etc. When FEC is added to such applications, feedback 1031 mechanisms may also need to be enhanced to report on the performance 1032 of the FEC (for example how much lost data was recovered by the FEC). 1034 When used to provide instrumentation for engineering purposes, it is 1035 important to remember that FEC is generally applied to relatively 1036 small blocks of data (in time) and so feedback information averaged 1037 over longer periods of time than the FEC block size will likely not 1038 provide sufficient information for engineering purposes. For example 1039 see [I-D.ietf-avt-post-repair-rtcp-xr]. 1041 Applications which used feedback for congestion control purposes MUST 1042 calculate such feedback on the basis of packets received before FEC 1043 recovery is applied. If this requirement conflicts with other uses 1044 of the feedback information then the application MUST be enhanced to 1045 support both information calculated pre- and post- FEC recovery. 1046 This is to ensure that congestion control mechanisms operate 1047 correctly based on congestion indications recieved from the network, 1048 rather than on post-FEC recovery information which would give an 1049 inaccuate picture of congestion conditions. 1051 New applications which require such feedback SHOULD use RTP/RTCP 1052 [RFC3550]. 1054 8. Transport Protocols 1056 The following transport protocols are supported: 1058 o User Datagram Protocol (UDP) 1060 o Datagram Congestion Control Protocol (DCCP) 1062 9. Congestion Control 1064 This section starts with a informative section on the motivation of 1065 the normative requirements for congestion control, which are spelled 1066 out in Section 9.1. 1068 Informative Note: The enforcement of Congestion Control (CC) 1069 principles has gained a lot of momentum in the IETF over the 1070 recent years. While the need of CC over the open Internet is 1071 unquestioned, and the goal of TCP friendliness is generally agreed 1072 for most (but not all) applications, the subject of congestion 1073 detection and measurement in heterogenous networks can hardly be 1074 considered as solved. Most congestion control algorithms detect 1075 and measure congestion by taking (primarily or exclusively) the 1076 packet loss rate into account. This appears to be inappropriate 1077 in environments where a large percentage of the packet losses are 1078 the result link-layer errors and independent of the network load. 1079 Note that such environments exist in the "open Internet", as well 1080 as in "closed" IP based networks. An example for the former would 1081 be the use of IP/UDP/RTP based streaming from an Internet- 1082 connected streaming server to a device attached to the Internet 1083 using cellular technology. 1085 The authors of this draft are primarily interested in applications 1086 where the application reliability requirements and end-to-end 1087 reliability of the network differ, such that it warrants higher 1088 layer protection of the packet stream - for example due to the 1089 presence of unreliable links in the end-to-end path - and where 1090 real-time, scalability or other constraints prohibit the use of 1091 higher layer (transport or application) feedback. A typical 1092 example for such applications is multicast and broadcast streaming 1093 or multimedia transmission over heterogenous networks. In other 1094 cases, application reliability requirements may be so high that 1095 the required end-to-end reliability is difficult to achieve even 1096 over wired networks. Furthermore the end-to-end network 1097 reliability may not be known in advance. 1099 This FEC framework is not proposed, nor intended, as a QoS 1100 enhancement tool to combat losses resulting from highly congested 1101 networks. It should not be used for such purposes. 1103 In order to prevent such mis-use, one approach would be to leave 1104 standardisation to bodies most concerned with the problem 1105 described above. However, the IETF defines base standards used by 1106 several bodies, including DVB, 3GPP, 3GPP2, all of which appear to 1107 share the environment and the problem described. 1109 Another approach would be to write a clear applicability statement 1110 - for example restricting use of the framework to networks with 1111 wireless links. However, there may be applications where the use 1112 of FEC may be justified to combat congestion-induced packet losses 1113 - particularly in lightly loaded networks, where congestion is the 1114 result of relatively rare random peaks in instantaneous traffic 1115 load - thereby intentionally violating congestion control 1116 principles. One possible example for such an application could be 1117 a no-matter-what, brute-force FEC protection of traffic generated 1118 as an emergency signal. 1120 We propose a third approach, which is to require at a minimum that 1121 the use of this framework with any given application, in any given 1122 environment, does not cause congestion issues which the 1123 application alone would not itself cause i.e. the use of this 1124 framework must not make things worse. 1126 Taking above considerations into account, the normative text of 1127 this section implements a small set of constraints for the FEC, 1128 which are mandatory for all senders compliant with this FEC 1129 framework. Further restrictions may be imposed for certain 1130 Content Delivery Protocols. In this it follows the spirit of the 1131 congestion control section of RTP and its Audio-Visual Profile 1132 (RFC3550/STD64 and RFC3551/STD65). 1134 One of the constraints effectively limits the bandwidth for the 1135 FEC protected packet stream to be no more than roughly twice as 1136 high as the original, non-FEC protected packet stream. This 1137 disallows the (static or dynamic) use of excessively strong FEC to 1138 combat high packet loss rates, which may otherwise be chosen by 1139 naively implemented dynamic FEC-strength selection mechanisms. We 1140 acknowledge that there may be a few exotic applications, e.g. IP 1141 traffic from space-based senders, or senders in certain hardened 1142 military devices, which would warrant a higher FEC strength. 1143 However, in this specification we give preference to the overall 1144 stability and network friendliness of the average application, and 1145 for those a factor of 2 appears to be appropriate. 1147 A second constraint requires that the FEC protected packet stream 1148 be in compliance with the congestion control in use for the 1149 application and network in question. 1151 9.1. Normative requirements 1153 The bandwidth of FEC Repair packet flows MUST NOT exceed the 1154 bandwidth of the source packet flows being protected. In addition, 1155 whenever the source packet flow bandwidth is adapted due to the 1156 operation of congestion control mechanisms, the FEC repair packet 1157 flow bandwidth MUST be similarly adapted. 1159 10. Security Considerations 1161 The application of FEC protection to a stream does not provide any 1162 kind of security protection. 1164 If security services are required for the stream, then they MUST 1165 either be applied to the original source transport payload before FEC 1166 protection is applied, or to both the source and repair data, after 1167 FEC protection has been applied. 1169 If integrity protection is applied to source packets before FEC 1170 protection is applied, and no further integrity protection is applied 1171 to repair packets, then a denial of service attack is possible if an 1172 attacker is in a position to inject fake repair transport payloads. 1173 If received by a receiver, such fake repair transport payloads could 1174 cause incorrect FEC decoding resulting in incorrect source transport 1175 payloads being passed up to the application protocol. Such incorrect 1176 packets would then be detected by the source integrity protection and 1177 discarded, resulting in partial or complete denial of service. 1178 Therefore, in such environments, integrity protection MUST also be 1179 applied to the FEC repair transport payloads, for example using 1180 IPsec. Receivers MUST also verify the integrity of source transport 1181 payloads before including the source transport payload into the 1182 source block for FEC purposes. 1184 It is possible that multiple streams with different confidentiality 1185 requirements (for example, the streams may be visible to different 1186 sets of users) can be FEC protected by a single repair stream. This 1187 scenario is not recommended, since resources will be used to 1188 distribute and decode data which cannot then be decrypted by at least 1189 some receivers. However, in this scenario, confidentiality 1190 protection MUST be applied before FEC encoding of the streams, 1191 otherwise repair transport payload may be used by a receiver to 1192 decode unencrypted versions of source streams which they do not have 1193 permissionions to view. 1195 11. IANA Considerations 1197 FEC Schemes for use with this framework may be identified in 1198 protocols using FEC Encoding IDs. Values of FEC Encoding IDs are 1199 subject to IANA registration. They are in the registry named "FEC 1200 Framework (FECFRAME) FEC Encoding IDs" located at time of publication 1201 at . 1203 The values that can be assigned within the FEC Framework (FECFRAME) 1204 FEC Encoding ID registry are numeric indexes in the range [0, 255], 1205 boundaries included. Assignment requests are granted on a "IETF 1206 Consensus" basis as defined in[RFC5226] . Section 6.6 defines 1207 explicit requirements that documents defining new FEC Encoding IDs 1208 should meet. 1210 12. Acknowledgments 1212 This document is based in large part on [I-D.watson-tsvwg-fec-sf] and 1213 so thanks are due to the additional authors of that document, Mike 1214 Luby, Magnus Westerlund and Stephan Wenger. That document was in 1215 turn based on the FEC streaming protocol defined by 3GPP in [MBMSTS] 1216 and thus thanks are also due to the participants in 3GPP TSG SA 1217 working group 4. 1219 13. References 1221 13.1. Normative references 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, March 1997. 1226 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1227 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1228 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1229 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1230 Compression (ROHC): Framework and four profiles: RTP, UDP, 1231 ESP, and uncompressed", RFC 3095, July 2001. 1233 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1234 Correction (FEC) Building Block", RFC 5052, August 2007. 1236 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1237 Jacobson, "RTP: A Transport Protocol for Real-Time 1238 Applications", STD 64, RFC 3550, July 2003. 1240 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1241 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1242 May 2008. 1244 13.2. Informative references 1246 [I-D.watson-tsvwg-fec-sf] 1247 Watson, M., "Forward Error Correction (FEC) Streaming 1248 Framework", draft-watson-tsvwg-fec-sf-00 (work in 1249 progress), July 2005. 1251 [I-D.ietf-avt-post-repair-rtcp-xr] 1252 Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 1253 Report Block Type for RTCP XR", 1254 draft-ietf-avt-post-repair-rtcp-xr-05 (work in progress), 1255 June 2009. 1257 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1258 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1259 July 2006. 1261 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 1262 Payload Format Specifications", BCP 36, RFC 2736, 1263 December 1999. 1265 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1266 Protocols and codecs", 3GPP TS 26.346, April 2005. 1268 Author's Address 1270 Mark Watson 1271 Digital Fountain 1272 39141 Civic Center Drive 1273 Suite 300 1274 Fremont, CA 94538 1275 U.S.A. 1277 Email: mark@digitalfountain.com