idnits 2.17.1 draft-ietf-fecframe-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1064. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1070. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 24 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 5977 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) -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 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 November 16, 2007 5 Expires: May 19, 2008 7 Forward Error Correction (FEC) Framework 8 draft-ietf-fecframe-framework-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 19, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes for a framework for using forward error 42 correction (FEC) codes with applications in public and private IP 43 networks to provide protection against packet loss. The framework 44 supports applying Forward Error Correction to arbitrary packet flows 45 over unreliable transport and is primarily intended for real-time, or 46 streaming, media. This framework can be used to define Content 47 Delivery Protocols that provide Forward Error Correction for 48 streaming media delivery or other packet flows. Content Delivery 49 Protocols defined using this framework can support any FEC Scheme 50 (and associated FEC codes) which is compliant with various 51 requirements defined in this document. Thus, Content Delivery 52 Protocols can be defined which are not specific to a particular FEC 53 Scheme and FEC Schemes can be defined which are not specific to a 54 particular Content Delivery Protocol. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6 60 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 8 61 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 62 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 12 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 13 65 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 15 66 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 18 67 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 6.2. Structure of the source block . . . . . . . . . . . . . . 18 69 6.3. Packet format for FEC Source packets . . . . . . . . . . . 18 70 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 20 71 6.5. FEC Framework Configuration Information . . . . . . . . . 20 72 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 22 73 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 25 74 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 26 75 8.1. Normative requirements . . . . . . . . . . . . . . . . . . 27 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 81 Intellectual Property and Copyright Statements . . . . . . . . . . 34 83 1. Introduction 85 Many applications have a requirement to transport a continuous stream 86 of packetised data from a source (sender) to one or more destinations 87 (receivers) over networks which do not provide guaranteed packet 88 delivery. Primary examples are real-time, or streaming, media 89 applications such as broadcast, multicast or on-demand audio, video 90 or multimedia. 92 Forward Error Correction is a well-known technique for improving 93 reliability of packet transmission over networks which do not provide 94 guaranteed packet delivery, especially in multicast and broadcast 95 applications. The FEC Building Block defined in [3] provides a 96 framework for definition of Content Delivery Protocols (CDPs) for 97 object delivery (including, primarily, file delivery) which make use 98 of separately defined FEC Schemes. Any CDP defined according to the 99 requirements of the FEC Building Block can then easily be used with 100 any FEC Scheme which is also defined according to the requirements of 101 the FEC Building Block. (Note that the term "Forward Erasure 102 Correction" is sometimes used, 'erasures' being a type of error in 103 which data is lost and this loss can be detected, rather than being 104 received in corrupted form - the focus of this document is strictly 105 on erasures, however the term Forward Error Correction is more widely 106 used). 108 This document defines a framework for the definition of CDPs which 109 provide for FEC protection of arbitrary packet flows over unreliable 110 transports such as UDP. As such, this document complements the FEC 111 Building Block of [3], by providing for the case of arbitrary packet 112 flows over unreliable transport, the same kind of framework as that 113 document provides for object delivery. This document does not define 114 a complete Content Delivery Protocol, but rather defines only those 115 aspects that are expected to be common to all Content Delivery 116 Protocols based on this framework. 118 This framework does not define how the flows to be protected are 119 determined, nor how the details of the protected flows and the FEC 120 streams which protect them are communicated from sender to receiver. 121 It is expected that any complete Content Delivery Protocol 122 specification which makes use of this framework will address these 123 signalling requirements. However, this document does specify the 124 information which is required by the FEC Framework at the sender and 125 receiver - for example details of the flows to be FEC protected, the 126 flow(s) that will carry the FEC protection data and an opaque 127 container for FEC-Scheme-specific information. 129 FEC Schemes designed for use with this framework must fulfil a number 130 of requirements defined in this document. Note that these 131 requirements are different from those defined in [3] for FEC Schemes 132 for object delivery. However there is a great deal of commonality 133 and FEC Schemes defined for object delivery may be easily adapted for 134 use with the framework defined here. 136 2. Definitions/Abbreviations 138 'FEC' Forward Error Correction. 140 'AL-FEC' Application Layer Forward Error Correction 142 'FEC Framework' A protocol framework for definition of Content 143 Delivery Protocols using FEC, such as the framework defined in 144 this document. 146 'Source data flow' The packet flow or flows to which FEC protection 147 is to be applied. 149 'Repair data flow' The packet flow or flows carrying forward error 150 correction data 152 'Source protocol' A protocol used for the source data flow being 153 protected - e.g. RTP. 155 'Transport protocol' The protocol used for transport of the source 156 data flow being protected - e.g. UDP, DCCP. 158 'Transport payload' Data used as the payload for the transport layer 159 (e.g. UDP or DCCP packet payload) 161 'Application protocol' Control protocols used to establish and 162 control the source data flow being protected - e.g. RTSP. 164 'FEC Code' An algorithm for encoding data such that the encoded data 165 flow is resiliant to data loss or corruption. 167 'FEC Scheme' A specification which defines the additional protocol 168 aspects required to use a particular FEC code with the FEC 169 Framework, or (in the context of RMT), with the RMT FEC Building 170 Block. 172 'Source Block' the group of source data packets which are to be FEC 173 protected as a single block 175 'Protection amount' The relative increase in data sent due to the 176 use of FEC. 178 FEC Framework Configuration Information: Information which controls 179 the operation of the FEC Framework. 181 FEC Payload ID: Information which identifies the contents of a 182 packet with respect to the FEC Scheme. 184 Source FEC Payload ID: An FEC Payload ID specifically for use with 185 source packets. 187 Repair FEC Payload ID: An FEC Payload ID specifically for use with 188 repair packets. 190 Content Delivery Protocol (CDP): A complete application protocol 191 specification which, through the use of the framework defined in 192 this document, is able to make use of FEC Schemes to provide 193 Forward Error Correction capabilities. 195 3. Requirements notation 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [1]. 201 4. Architecture Overview 203 The FEC Framework is described in terms of an additional protocol 204 layer between the transport layer (e.g. UDP or DCCP) and Application 205 and Transport Protocols running over this transport layer. Examples 206 of such protocols are RTP, RTCP, etc. As such, the data path 207 interface between the FEC Framework and both underlying and overlying 208 layers can be thought of as being the same as the standard interface 209 to the transport layer - i.e. the data exchanged consists of datagram 210 payloads each associated with a single transport flow identified by 211 the standard 5-tuple { Source IP Address, Source Transport Port, 212 Destination IP Address, Destination Transport Port, Transport 213 Protocol }. 215 The FEC Framework makes use of an FEC Scheme, in a similar sense to 216 that defined in [3] and uses the terminology of that document. The 217 FEC Scheme provides FEC encoding and decoding and describes the 218 protocol fields and or procedures used to identify packet payload 219 data in the context of the FEC Scheme. The interface between the FEC 220 Framework and an FEC Scheme, which is described in this document, is 221 a logical one, which exists for specification purposes only. At an 222 encoder, the FEC Framework passes groups of transport packet payloads 223 to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC 224 repair packet payloads, encoded FEC Payload ID information for each 225 of the repair packets and, in some cases, encoded FEC Payload ID 226 information for each of the source packets. At a decoder, the FEC 227 Framework passes transport packet payloads (source and repair) to the 228 FEC Scheme and the FEC Scheme returns additional recovered source 229 packet payloads. 231 This document defines certain FEC Framework Configuration Information 232 which MUST be available to both sender and receiver(s). For example, 233 this information includes the specification of the transport flows 234 which are to be FEC protected, specification of the transport flow(s) 235 which will carry the FEC protection (repair) data and the 236 relationship(s) between these 'source' and 'repair' flows (i.e. which 237 source flow(s) are protected by each repair flow. The FEC Framework 238 Configuration Information also includes information fields which are 239 specific to the FEC Scheme. This information is analagous to the FEC 240 Object Transmission Information defined in [3]. 242 The FEC Framework does not define how the FEC Framework Configuration 243 Information for the stream is communicated from sender to receiver. 244 This must be defined by any Content Delivery Protocol specification 245 as described in the following sections. 247 In this architecture we assume that the interface to the transport 248 layer supports the concepts of payloads to be transported and 249 identification transport flows on which those payloads are 250 transported. Since this is an interface internal to the 251 architecture, we do not specify this interface explicitly, except to 252 say that transport flows which are distinct from the transport layer 253 point of view (for example, distinct UDP flows as identified by the 254 UDP source/destination ports/addresses) are also distinct on the 255 interface between the transport layer and the FEC Framework. 257 The architecture outlined above is illustrated in the Figure 1. 259 +--------------------------------------------+ 260 | | 261 | Application | 262 | | 263 +--------------------------------------------+ 264 ^ 265 | 266 v 267 + - - - - - - -- - - - - - - - - - - - - - - - - + 268 | | 269 +--------------------------------------------+ 270 | | | | 271 | Application Layer | 272 | | | | 273 +--------------------------------------------+ 274 | +---------------------------------+ | | 275 | | | 276 | | Application/Transport Protocol | | | 277 | (e.g. RTP) | |-Configuration/Coordination 278 | +---------------------------------+ | | 279 ^ | 280 | | Transport flows | | 281 v v 282 | +--------------------------------------------+ | +----------------+ 283 | | | | 284 | | FEC Framework (this document) |------| FEC Scheme | 285 | | | | 286 | +--------------------------------------------+ | +----------------+ 287 ^ 288 | | Transport flows | 289 v 290 | +--------------------------------------------+ | 291 | | 292 | | Transport Layer (e.g. UDP) | | 293 | | 294 +--------------------------------------------+ 295 | +--------------------------------------------+ | 296 | | 297 | | IP | | 298 | | 299 | +--------------------------------------------+ | 300 Content Delivery Protocol 301 + - - - - - - - - - - - - - - - - - - - - - - - + 303 Figure 1: FEC Framework Architecture 305 5. Procedural overview 307 5.1. General 309 The mechanism defined in this document does not place any 310 restrictions on the source transport payloads which can be protected 311 together, except that the source transport payload is carried over a 312 supported transport protocol (See Section 7). The data may be from 313 multiple transport flows that are protected jointly. The FEC 314 framework handles the packet flows as a sequence of 'source blocks' 315 each consisting of a set of source transport payloads, possibly from 316 multiple flows which are to be protected together. For example, each 317 source block may be constructed from those source transport payloads 318 related to a particular segment in time of the flow. 320 At the sender, the FEC Framework passes the payloads for a given 321 block to the FEC Scheme for FEC encoding. The FEC Scheme performs 322 the FEC encoding operation and returns the following information: 324 o optionally, encoded FEC Payload IDs for each of the source 325 payloads 327 o one or more FEC repair packet payloads 329 o encoded FEC Payload IDs for each of the repair packet payloads 331 The FEC framework then performs two operations: Firstly, it appends 332 the FEC payload IDs, if provided, to each of the source transport 333 payloads, and sends the resulting packets, known as 'FEC source 334 packets', to the receiver and secondly it places the provided 'FEC 335 repair packet payloads' and corresponding 'FEC Repair Payload IDs' 336 appropriately to construct 'FEC repair packets' and send them to the 337 receiver. Note that FEC repair packets MAY be sent to a different 338 multicast group or groups from the source packets. 340 This document does not define how the sender determines which source 341 transport payloads are included in which source blocks or the sending 342 order and timing of FEC source and FEC repair packets. A specific 343 Content Delivery Protocol MAY define this mapping or it MAY be left 344 as implementation dependent at the sender. However, a CDP 345 specification MUST define how a receiver determines the length of 346 time it should wait to receive FEC repair packets for any given 347 source block. The sequence of operations at the sender is described 348 in more detail in Section 5.2. 350 At the receiver, original source transport payloads are recovered by 351 the FEC Framework directly from any FEC Source packets received 352 simply by removing the Source FEC Payload ID, if present. The 353 receiver also passes the contents of the received FEC Source 354 transport payloads, plus their FEC Payload IDs to the FEC Scheme for 355 possible decoding. 357 If any FEC source transport payloads related to a given source block 358 have been lost, then the FEC Scheme may perform FEC decoding to 359 recover the missing source transport payloads (assuming sufficient 360 FEC Source and FEC Repair packets related to that source block have 361 been received). 363 Note that the receiver may need to buffer received source packets to 364 allow time for the FEC Repair packets to arrive and FEC decoding to 365 be performed before some or all of the received or recovered packets 366 are passed to the application. If such a buffer is not provided, 367 then the application must be able to deal with the severe re-ordering 368 of packets that will be required. However, such buffering is Content 369 Delivery Protocol and/or implementation-specific and is not specified 370 here. The receiver operation is described in more detail in 371 Section 5.3 373 The FEC Source packets MUST contain information which identifies the 374 source block and the position within the source block (in terms 375 specific to the FEC Scheme) occupied by the packet. This information 376 is known as the 'Source FEC Payload ID'. The FEC Scheme is 377 responsible for defining and interpreting this information. This 378 information MAY be encoded into a specific field within the FEC 379 Source packet format defined in this specification, called the 380 Explicit Source FEC Payload ID field. The exact contents and format 381 of the Explicit Source FEC Payload ID field are defined by the FEC 382 Scheme. Alternatively, the FEC Scheme MAY define how the Source FEC 383 Payload ID is derived from other fields within the source packets. 384 This document defines the way that the Explicit Source FEC Payload ID 385 field is appended to source packets to form FEC Source packets. 387 The FEC Repair packets MUST contain information which identifies the 388 source block and the relationship between the contained repair 389 payloads and the original source block. This is known as the 'Repair 390 FEC Payload ID'. This information MUST be encoded into a specific 391 field, the Repair FEC Payload ID field, the contents and format of 392 which are defined by the FEC Scheme. 394 The FEC Scheme MAY use different FEC Payload ID field formats for FEC 395 Source packets and FEC Repair packets. 397 5.2. Sender Operation 399 It is assumed that the sender has constructed or received original 400 data packets for the session. These may be RTP, RTCP, MIKEY or 401 indeed any other type of packet. The following operations, 402 illustrated in Figure 2 describe a possible way to generate compliant 403 FEC Source packet and FEC repair packet streams: 405 1. Source transport payloads are provided by the application. 407 2. A source block is constructed as specified in Section 6.2. 409 3. The source block is passed to the FEC Scheme for FEC encoding. 410 The Source FEC Payload ID information of each Source packet is 411 determined by the FEC Scheme. If required by the FEC Scheme the 412 Source FEC Payload ID is encoded into the Explicit Source FEC 413 Payload ID field. 415 4. The FEC Scheme performs FEC Encoding, generating repair packet 416 payloads from a source block and a Repair FEC Payload ID field for 417 each repair payload. 419 5. The Explicit Source FEC Payload IDs (if used), Repair FEC 420 Payload IDs and repair packet payloads are provided back from the 421 FEC Scheme to the FEC Framework. 423 6. The FEC Framework constructs FEC Source packets according to 424 Section 6.3 and FEC Repair packets according to Section 6.4 426 using the FEC Payload IDs and repair packet payloads provided by 427 the FEC Scheme. 429 7. The FEC Source and FEC Repair packets are sent using normal 430 transport layer procedures. The port(s) and multicast group(s) to 431 be used for FEC Repair packets are defined in the FEC Framework 432 Configuration Information. The FEC Source packets are sent using 433 the same transport flow identification information as would have 434 been used for the original source packets if the FEC Framework 435 were not present (for example, in the UDP case, the UDP source and 436 destination addresses and ports on the eventual IP FEC Source 437 Packet will be the same whether or not the FEC Framework is 438 applied). 440 +-------------------------------------+ 441 | | 442 | Application | 443 | | 444 +-------------------------------------+ 445 | 446 | (1) Source transport payloads 447 | 448 v 449 +-------------------------------------+ +---------------------+ 450 | FEC Framework | | | 451 | |------------------------------->| FEC Scheme | 452 | (2) Construct source blocks | (3) Source Block | | 453 | | | (4) FEC Encoding | 454 | (6) Construct FEC source packets |<-------------------------------| | 455 | and FEC repair packets | (5) Ex. Source FEC Payload Ids,| | 456 +-------------------------------------+ Repair FEC Payload Ids, +---------------------+ 457 | Repair payloads 458 | 459 | (7) FEC Source packets and FEC repair packets 460 v 461 +-------------------------------------+ 462 | | 463 | Transport Layer (e.g. UDP) | 464 | | 465 +-------------------------------------+ 467 Figure 2: Sender operation 469 5.3. Receiver Operation 471 The following describes a possible receiver algorithm, illustrated in 472 Figure 3, when receiving an FEC source or repair packet: 474 1. FEC Source Packets and FEC Repair packets are received and 475 passed to the FEC Framework. The type of packet (Source or 476 Repair) and the transport flow to which it belongs (in the case of 477 source packets ) is indicated by the transport flow information 478 which identifies the flow at the transport layer (for example 479 source and destination ports and addresses in the case of UDP). 481 2. The FEC Framework extracts the Explicit Source FEC Payload ID 482 field (if present) from FEC Source Packets and the Repair FEC 483 Payload ID from FEC Repair Packets. 485 3. The Explicit Source FEC Payload IDs (if present), Repair FEC 486 Payload IDs, FEC Source payloads and FEC Repair payloads are 487 passed to the FEC Scheme. 489 4. The FEC Scheme uses the received FEC Payload IDs (and derived 490 FEC Source Payload IDs in the case that the Explicit Source FEC 491 Payload ID field is not used) to group source and repair packets 492 into source blocks. If at least one source packet is missing from 493 a source block, and at least one repair packet has been received 494 for the same source block then FEC decoding may be performed in 495 order to recover missing source payloads. The FEC Scheme 496 determines whether source packets have been lost and whether 497 enough data for decoding of any or all of the missing source 498 payloads in the source block has been received. 500 5. The FEC Scheme returns the source transport payload to the FEC 501 Framework in the form of source blocks containing received and 502 decoded source packets and indications of any source packets which 503 were missing and could not be decoded. 505 6. The FEC Framework passes the received and recovered source 506 packet payloads to the application. 508 +-------------------------------------+ 509 | | 510 | Application | 511 | | 512 +-------------------------------------+ 513 ^ 514 | (6) Source transport payloads 515 | 516 | 517 +-------------------------------------+ +---------------------+ 518 | FEC Framework | | | 519 | |<-------------------------------| FEC Scheme | 520 | (2) Extract FEC Payload IDs and | (5) Source Transport Payloads | | 521 | pass Payloads and Payload IDs | | (4) FEC Decoding | 522 | to FEC Scheme |------------------------------->| | 523 | | (3) Ex. FEC Source Payload IDs,| | 524 +-------------------------------------+ FEC Repair Payload IDs, +---------------------+ 525 ^ FEC Source Payloads, 526 | FEC Repair Payloads 527 | 528 | (1) FEC Source packets and FEC repair packets 529 | 530 +--------------------------------------------+ 531 | | 532 | Transport Layer (e.g. UDP) | 533 | | 534 +--------------------------------------------+ 536 Figure 3: Receiver Operation 538 Note that the above procedure may result in a situation in which not 539 all original source packets are recovered. 541 Source packets which are correctly received and those which are 542 reconstructed MAY be delivered to the application out of order and in 543 a different order from the order of arrival at the receiver. 544 Alternatively, buffering and packet re-ordering MAY be required to 545 re-order received and reconstructed source packets into the order 546 they were placed into the source block, if that is necessary 547 according to the application. 549 6. Protocol Specification 551 6.1. General 553 This section specifies the protocol elements for the FEC Framework. 554 Three components of the protocol are defined in this document and are 555 described in the following sections: 557 1. Construction of a source block from source payloads. The FEC 558 code will be applied to this source block to produce the repair 559 payloads. 561 2. A format for packets containing source data. 563 3. A format for packets containing repair data. 565 The operation of the FEC Framework is governed by certain FEC 566 Framework Configuation Information. This configuration information 567 is also defined in this section. A complete protocol specification 568 that uses this framework MUST specify the means to determine and 569 communicate this information between sender and receiver. 571 6.2. Structure of the source block 573 The FEC Framework and FEC Scheme exchange source transport payload in 574 the form of source blocks. A source block is generated by the FEC 575 Framework from an ordered sequence of source transport payloads. The 576 allocation of transport payloads to blocks is dependent on the 577 application. Note that some source transport payloads may not be 578 included in any block. For each source transport payload included in 579 a source block, the following information is provided to the FEC 580 Scheme: 582 o A description of the source transport flow with which the 583 transport payload is associated (See 6.5) 585 o The source transport payload itself 587 o The length of the source transport payload 589 6.3. Packet format for FEC Source packets 591 The packet format for FEC Source packets MUST be used to transport 592 the payload of an original source packet. As depicted in Figure 4, 593 it consists of the original packet, optionally followed by the 594 Explicit Source FEC Payload ID field. The FEC Scheme determines 595 whether the Explicit Source FEC Payload ID field is required. This 596 determination is specific to each transport flow. 598 +------------------------------------+ 599 | IP header | 600 +------------------------------------+ 601 | Transport header | 602 +------------------------------------+ 603 | Original transport Payload | 604 +------------------------------------+ 605 | Explicit Source FEC Payload ID | 606 +------------------------------------+ 608 Figure 4: Structure of the FEC packet format for FEC Source packets 610 The FEC Source packets MUST be sent using the same transport flow as 611 would have been used for the original source packets if the FEC 612 Framework were not present. The Original transport Payload field 613 MUST be identical to the source transport payload. The transport 614 payload of the FEC Source packet MUST consist of the Original 615 Transport Payload followed by the Explicit Source FEC Payload ID 616 field, if required. 618 The Explicit Source FEC Payload ID field contains information 619 required to associate the source packet with a source block and for 620 the operation of the FEC algorithm and is defined by the FEC Scheme. 621 The format of the Source FEC Payload ID field is defined by the FEC 622 Scheme. Note that in the case that the FEC Scheme or CDP defines a 623 means to derive the Source FEC Payload ID from other information in 624 the packet (for example the a sequence number of some kind used by 625 the application protocol), then the Source FEC Payload ID field is 626 not included in the packet. In this case the original source packet 627 and FEC Source Packet are identical. 629 Since the addition of the Explicit Source FEC Payload ID increases 630 the packet length, then in applications where avoidance of IP packet 631 fragmentation is a goal, Content Delivery Protocols SHOULD consider 632 the Explicit Source FEC Payload ID size when determining the size of 633 source transport payloads that will be delivered using the FEC 634 Framework. 636 Note: The Explicit Source FEC Payload ID is placed at the end of the 637 packet so that in the case that Robust Header Compression [2] or 638 other header compression mechanisms are used and in the case that a 639 ROHC profile is defined for the protocol carried within the transport 640 payload (for example RTP), then ROHC will still be applied for the 641 FEC Source packets. Applications that may be used with this 642 Framework should consider that FEC Schemes may add this Explicit 643 Source FEC Payload ID and thereby increase the packet size. 645 6.4. Packet Format for FEC Repair packets 647 The packet format for FEC Repair packets is shown in Figure 5. The 648 transport payload consists of a Repair FEC Payload ID field followed 649 by repair data generated in the FEC encoding process. 651 +------------------------------------+ 652 | IP header | 653 +------------------------------------+ 654 | Transport header | 655 +------------------------------------+ 656 | Repair FEC Payload ID | 657 +------------------------------------+ 658 | Repair Symbols | 659 +------------------------------------+ 661 Figure 5: Packet format for repair packets 663 The Repair FEC Payload ID field contains information required for the 664 operation of the FEC algorithm at the receiver. This information is 665 defined by the FEC Scheme. The format of the Repair FEC Payload ID 666 field is defined by the FEC Scheme. 668 6.5. FEC Framework Configuration Information 670 The FEC Framework Configuration Information is information that the 671 FEC Framework needs in order to apply FEC protection to the transport 672 flows. A complete Content Delivery Protocol specification that uses 673 the framework specified here MUST include details of how this 674 information is derived and communicated between sender and receiver. 676 The FEC Framework Configuration Information includes identification 677 of a set of source packet flows. For example, in the case of UDP, 678 each packet flow is uniquely identified by a tuple { Source IP 679 Address, Destination IP Address, Source UDP port, Destination UDP 680 port }. Note that in some applications some of these fields may be 681 wildcarded, so that the flow is identified by a subset of the fields 682 and in particular in many applications the limited tuple { 683 Destination IP Address, Destination UDP port } is sufficient. 685 A single instance of the FEC Framework provides FEC protection for 686 all packets of a specified set of source packet flows, by means of 687 one or more packet flows consisting of repair packets. The FEC 688 Framework Configuation Information includes, for each instance of the 689 FEC Framework: 691 1. Identification of the packet flow(s) carrying FEC Repair 692 packets, known as the FEC repair flow(s). 694 2. For each source packet flow protected by the FEC repair 695 flow(s): 697 a. Defintion of the packet flow carrying source packets (for 698 example, by means of a tuple as describe above for UDP). 700 b. An integer identifier for this flow definition (i.e. 701 tuple). This identifier MUST be unique amongst all source 702 packet flows which are protected by the same FEC repair flow. 704 3. The FEC Encoding ID, identifying the FEC Scheme 706 4. The length of the Explicit Source FEC Payload Id, in bytes 708 5. An opaque container for FEC-Scheme-specific information 710 Multiple instances of the FEC Framework, with separate and 711 independent FEC Framework Configuration Information, may be present 712 at a sender or receiver. A single instance of the FEC Framework 713 protects all packets of all the source packet flows identified in (2) 714 above i.e. all packets sent on those flows MUST be FEC Source packets 715 as defined in Section 6.3. A single source packet flow may be 716 protected by multiple instances of the FEC Framework. 718 The integer flow identifier identified in 2(b) is a "shorthand" to 719 identify source flows between the FEC Framework and the FEC Scheme. 720 The reason for defining this as an integer, and including it in the 721 FEC Framework Configuration Information is so that the FEC Scheme at 722 the sender and receiver may use it to identify the source flow with 723 which a recovered packet is associated. The integer flow identifier 724 may therefore take the place of the complete flow description (e.g. 725 UDP 4-tuple). 727 Whether and how this flow identifier is used is defined by the FEC 728 Scheme. Since source packets are directly associated with a flow by 729 virtue of their packet headers, this identifier need not be carried 730 in source packets. Since repair packets may provide protection for 731 multiple source flows, this flow identifier would likely not be 732 carried directly in repair packets. However, the flow identifier 733 associated with a particular source packet may be recovered from the 734 repair packets as part of an FEC decoding operation. Integer flow 735 identifiers SHOULD be allocated starting from zero and increasing by 736 one for each flow. 738 A single FEC repair flow provides repair packets for a single 739 instance of the FEC Framework. Other packets MUST NOT be sent within 740 this flow i.e. all packets in the FEC repair flow MUST be FEC repair 741 packets as defined in Section 6.4 and MUST relate to the same FEC 742 Framework instance. 744 6.6. FEC Scheme requirements 746 In order to be used with this framework, an FEC Scheme MUST be 747 capable of processing data arranged into blocks of source transport 748 packet payloads (source blocks). 750 A specification for a new FEC scheme MUST include the following 751 things: 753 1. The FEC Encoding ID value that uniquely identifies the FEC 754 scheme. This value MUST be registered with IANA as described in 755 Section 10. 757 2. The type, semantics and encoding format of the Repair FEC Payload 758 ID. 760 3. The type, semantics and encoding format of the FEC Scheme- 761 specific FEC Framework Configuration Information. 763 4. A full specification of the FEC code. 765 This specification MUST precisely define the valid FEC-Scheme- 766 Specific FEC Framework Configuration Information values, the 767 valid FEC Payload ID values and the valid packet payload sizes 768 (where packet payload refers to the space - not necessarily 769 contiguous - within a packet dedicated to carrying encoding 770 symbol bytes). 772 Furthermore, given a source block as defined in Section 6.2, 773 valid values of the FEC-Scheme-Specific FEC Framework 774 Configuration Information, a valid Repair FEC Payload ID value 775 and a valid packet payload size, the specification MUST uniquely 776 define the values of the encoding symbol bytes to be included in 777 the repair packet payload of a packet with the given Repair FEC 778 Payload ID value. 780 A common and simple way to specify the FEC code to the required 781 level of detail is to provide a precise specification of an 782 encoding algorithm which, given a source block, valid values of 783 the FEC-Scheme-Specific FEC Framework Configuration Information, 784 a valid Repair FEC Payload ID value and a valid packet payload 785 size as input produces the exact value of the encoding symbol 786 bytes as output. 788 5. A description of practical encoding and decoding algorithms. 790 This description need not be to the same level of detail as for 791 the encoding above, however it must be sufficient to demonstrate 792 that encoding and decoding of the code is both possible and 793 practical. 795 FEC scheme specifications MAY additionally define the following: 797 1. Type, semantics and encoding format of an Explicit Source FEC 798 Payload ID. 800 Whenever an FEC scheme specification defines an 'encoding format' for 801 an element, this must be defined in terms of a sequence of bytes 802 which can be embedded within a protocol. The length of the encoding 803 format MUST either be fixed or it must be possible to derive the 804 length from examining the encoded bytes themselves. For example, the 805 initial bytes may include some kind of length indication. 807 FEC scheme specifications SHOULD use the terminology defined in this 808 document and SHOULD follow the following format: 810 1. Introduction 813 2. Formats and Codes 815 2.1 Source FEC Payload ID(s) 819 2.2 Repair FEC Payload Id 822 2.3 FEC Framework Configuration Information 826 3. Procedures 831 4. FEC code specification 834 Specifications MAY include additional sections, for example, 835 examples. 837 Each FEC scheme MUST be specified independently of all other FEC 838 schemes; for example, in a separate specification or a completely 839 independent section of larger specification (except, of course, a 840 specification of one FEC Scheme may include portions of another by 841 reference). 843 7. Transport Protocols 845 The following transport protocols are supported: 847 o User Datagram Protocol (UDP) 849 o Datagram Congestion Control Protocol (DCCP) 851 Editor's note: This section will contain transport-specific 852 considerations, if any. 854 8. Congestion Control 856 This section starts with a informative section on the motivation of 857 the normative requirements for congestion control, which are spelled 858 out in Section 8.1. 860 Informative Note: The enforcement of Congestion Control (CC) 861 principles has gained a lot of momentum in the IETF over the 862 recent years. While the need of CC over the open Internet is 863 unquestioned, and the goal of TCP friendliness is generally agreed 864 for most (but not all) applications, the subject of congestion 865 detection and measurement in heterogenous networks can hardly be 866 considered as solved. Most congestion control algorithms detect 867 and measure congestion by taking (primarily or exclusively) the 868 packet loss rate into account. This appears to be inappropriate 869 in environments where a large percentage of the packet losses are 870 the result link-layer errors and independent of the network load. 871 Note that such environments exist in the "open Internet", as well 872 as in "closed" IP based networks. An example for the former would 873 be the use of IP/UDP/RTP based streaming from an Internet- 874 connected streaming server to a device attached to the Internet 875 using cellular technology. 877 The authors of this draft are primarily interested in applications 878 where the application reliability requirements and end-to-end 879 reliability of the network differ, such that it warrants higher 880 layer protection of the packet stream - for example due to the 881 presence of unreliable links in the end-to-end path - and where 882 real-time, scalability or other constraints prohibit the use of 883 higher layer (transport or application) feedback. A typical 884 example for such applications is multicast and broadcast streaming 885 or multimedia transmission over heterogenous networks. In other 886 cases, application reliability requirements may be so high that 887 the required end-to-end reliability is difficult to achieve even 888 over wired networks. Furthermore the end-to-end network 889 reliability may not be known in advance. 891 This FEC framework is not proposed, nor intended, as a QoS 892 enhancement tool to combat losses resulting from highly congested 893 networks. It should not be used for such purposes. 895 In order to prevent such mis-use, one approach would be to leave 896 standardisation to bodies most concerned with the problem 897 described above. However, the IETF defines base standards used by 898 several bodies, including DVB, 3GPP, 3GPP2, all of which appear to 899 share the environment and the problem described. 901 Another approach would be to write a clear applicability statement 902 - for example restricting use of the framework to networks with 903 wireless links. However, there may be applications where the use 904 of FEC may be justified to combat congestion-induced packet losses 905 - particularly in lightly loaded networks, where congestion is the 906 result of relatively rare random peaks in instantaneous traffic 907 load - thereby intentionally violating congestion control 908 principles. One possible example for such an application could be 909 a no-matter-what, brute-force FEC protection of traffic generated 910 as an emergency signal. 912 We propose a third approach, which is to require at a minimum that 913 the use of this framework with any given application, in any given 914 environment, does not cause congestion issues which the 915 application alone would not itself cause i.e. the use of this 916 framework must not make things worse. 918 Taking above considerations into account, the normative text of 919 this section implements a small set of constraints for the FEC, 920 which are mandatory for all senders compliant with this FEC 921 framework. Further restrictions may be imposed for certain 922 Content Delivery Protocols. In this it follows the spirit of the 923 congestion control section of RTP and its Audio-Visual Profile 924 (RFC3550/STD64 and RFC3551/STD65). 926 One of the constraints effectively limits the bandwidth for the 927 FEC protected packet stream to be no more than roughly twice as 928 high as the original, non-FEC protected packet stream. This 929 disallows the (static or dynamic) use of excessively strong FEC to 930 combat high packet loss rates, which may otherwise be chosen by 931 naively implemented dynamic FEC-strength selection mechanisms. We 932 acknowledge that there may be a few exotic applications, e.g. IP 933 traffic from space-based senders, or senders in certain hardened 934 military devices, which would warrant a higher FEC strength. 935 However, in this specification we give preference to the overall 936 stability and network friendliness of the average application, and 937 for those a factor of 2 appears to be appropriate. 939 A second constraint requires that the FEC protected packet stream 940 be in compliance with the congestion control in use for the 941 application and network in question. 943 8.1. Normative requirements 945 The bandwidth of FEC Repair packet flows MUST NOT exceed the 946 bandwidth of the source packet flows being protected. In addition, 947 whenever the source packet flow bandwidth is adapted due to the 948 operation of congestion control mechanisms, the FEC repair packet 949 flow bandwidth MUST be similarly adapted. 951 9. Security Considerations 953 The application of FEC protection to a stream does not provide any 954 kind of security protection. 956 If security services are required for the stream, then they MUST 957 either be applied to the original source transport payload before FEC 958 protection is applied, or to both the source and repair data, after 959 FEC protection has been applied. 961 If integrity protection is applied to source packets before FEC 962 protection is applied, and no further integrity protection is applied 963 to repair packets, then a denial of service attack is possible if an 964 attacker is in a position to inject fake repair transport payloads. 965 If received by a receiver, such fake repair transport payloads could 966 cause incorrect FEC decoding resulting in incorrect source transport 967 payloads being passed up to the application protocol. Such incorrect 968 packets would then be detected by the source integrity protection and 969 discarded, resulting in partial or complete denial of service. 970 Therefore, in such environments, integrity protection MUST also be 971 applied to the FEC repair transport payloads, for example using 972 IPsec. Receivers MUST also verify the integrity of source transport 973 payloads before including the source transport payload into the 974 source block for FEC purposes. 976 It is possible that multiple streams with different confidentiality 977 requirements (for example, the streams may be visible to different 978 sets of users) can be FEC protected by a single repair stream. This 979 scenario is not recommended, since resources will be used to 980 distribute and decode data which cannot then be decrypted by at least 981 some receivers. However, in this scenario, confidentiality 982 protection MUST be applied before FEC encoding of the streams, 983 otherwise repair transport payload may be used by a receiver to 984 decode unencrypted versions of source streams which they do not have 985 permissionions to view. 987 10. IANA Considerations 989 tbd 991 11. Acknowledgments 993 This document is based in large part on [4] and so thanks are due to 994 the additional authors of that document, Mike Luby, Magnus Westerlund 995 and Stephan Wenger. That document was in turn based on the FEC 996 streaming protocol defined by 3GPP in [5] and thus thanks are also 997 due to the participants in 3GPP TSG SA working group 4. 999 12. References 1001 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1002 Levels", BCP 14, RFC 2119, March 1997. 1004 [2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1005 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, 1006 Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 1007 Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): 1008 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 1009 RFC 3095, July 2001. 1011 [3] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction 1012 (FEC) Building Block", RFC 5052, August 2007. 1014 [4] Watson, M., "Forward Error Correction (FEC) Streaming 1015 Framework", draft-watson-tsvwg-fec-sf-00 (work in progress), 1016 July 2005. 1018 [5] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols 1019 and codecs", 3GPP TS 26.346, April 2005. 1021 Author's Address 1023 Mark Watson 1024 Digital Fountain 1025 39141 Civic Center Drive 1026 Suite 300 1027 Fremont, CA 94538 1028 U.S.A. 1030 Email: mark@digitalfountain.com 1032 Full Copyright Statement 1034 Copyright (C) The IETF Trust (2007). 1036 This document is subject to the rights, licenses and restrictions 1037 contained in BCP 78, and except as set forth therein, the authors 1038 retain all their rights. 1040 This document and the information contained herein are provided on an 1041 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1042 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1043 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1044 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1045 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1046 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1048 Intellectual Property 1050 The IETF takes no position regarding the validity or scope of any 1051 Intellectual Property Rights or other rights that might be claimed to 1052 pertain to the implementation or use of the technology described in 1053 this document or the extent to which any license under such rights 1054 might or might not be available; nor does it represent that it has 1055 made any independent effort to identify any such rights. Information 1056 on the procedures with respect to rights in RFC documents can be 1057 found in BCP 78 and BCP 79. 1059 Copies of IPR disclosures made to the IETF Secretariat and any 1060 assurances of licenses to be made available, or the result of an 1061 attempt made to obtain a general license or permission for the use of 1062 such proprietary rights by implementers or users of this 1063 specification can be obtained from the IETF on-line IPR repository at 1064 http://www.ietf.org/ipr. 1066 The IETF invites any interested party to bring to its attention any 1067 copyrights, patents or patent applications, or other proprietary 1068 rights that may cover technology that may be required to implement 1069 this standard. Please address the information to the IETF at 1070 ietf-ipr@ietf.org. 1072 Acknowledgment 1074 Funding for the RFC Editor function is provided by the IETF 1075 Administrative Support Activity (IASA).