idnits 2.17.1 draft-ietf-fecframe-framework-02.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 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1106. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1113. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1119. 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 (July 12, 2008) is 5766 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. 'I-D.watson-tsvwg-fec-sf' -- Possible downref: Non-RFC (?) normative reference: ref. 'MBMSTS' 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 July 12, 2008 5 Expires: January 13, 2009 7 Forward Error Correction (FEC) Framework 8 draft-ietf-fecframe-framework-02 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 January 13, 2009. 35 Abstract 37 This document describes for a framework for using forward error 38 correction (FEC) codes with applications in public and private IP 39 networks to provide protection against packet loss. The framework 40 supports applying Forward Error Correction to arbitrary packet flows 41 over unreliable transport and is primarily intended for real-time, or 42 streaming, media. This framework can be used to define Content 43 Delivery Protocols that provide Forward Error Correction for 44 streaming media delivery or other packet flows. Content Delivery 45 Protocols defined using this framework can support any FEC Scheme 46 (and associated FEC codes) which is compliant with various 47 requirements defined in this document. Thus, Content Delivery 48 Protocols can be defined which are not specific to a particular FEC 49 Scheme and FEC Schemes can be defined which are not specific to a 50 particular Content Delivery Protocol. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6 56 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 8 57 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 58 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 13 59 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14 61 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16 62 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 19 63 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 64 6.2. Structure of the source block . . . . . . . . . . . . . . 19 65 6.3. Packet format for FEC Source packets . . . . . . . . . . . 19 66 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 21 67 6.4.1. Packet Format for FEC Repair packets over RTP 68 (informative) . . . . . . . . . . . . . . . . . . . . 21 69 6.5. FEC Framework Configuration Information . . . . . . . . . 22 70 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 23 71 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 26 72 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 27 73 8.1. Normative requirements . . . . . . . . . . . . . . . . . . 28 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 79 Intellectual Property and Copyright Statements . . . . . . . . . . 35 81 1. Introduction 83 Many applications have a requirement to transport a continuous stream 84 of packetised data from a source (sender) to one or more destinations 85 (receivers) over networks which do not provide guaranteed packet 86 delivery. Primary examples are real-time, or streaming, media 87 applications such as broadcast, multicast or on-demand audio, video 88 or multimedia. 90 Forward Error Correction is a well-known technique for improving 91 reliability of packet transmission over networks which do not provide 92 guaranteed packet delivery, especially in multicast and broadcast 93 applications. The FEC Building Block defined in [RFC5052] provides a 94 framework for definition of Content Delivery Protocols (CDPs) for 95 object delivery (including, primarily, file delivery) which make use 96 of separately defined FEC Schemes. Any CDP defined according to the 97 requirements of the FEC Building Block can then easily be used with 98 any FEC Scheme which is also defined according to the requirements of 99 the FEC Building Block. (Note that the term "Forward Erasure 100 Correction" is sometimes used, 'erasures' being a type of error in 101 which data is lost and this loss can be detected, rather than being 102 received in corrupted form - the focus of this document is strictly 103 on erasures, however the term Forward Error Correction is more widely 104 used). 106 This document defines a framework for the definition of CDPs which 107 provide for FEC protection of arbitrary packet flows over unreliable 108 transports such as UDP. As such, this document complements the FEC 109 Building Block of [RFC5052], by providing for the case of arbitrary 110 packet flows over unreliable transport, the same kind of framework as 111 that document provides for object delivery. This document does not 112 define a complete Content Delivery Protocol, but rather defines only 113 those aspects that are expected to be common to all Content Delivery 114 Protocols based on this framework. 116 This framework does not define how the flows to be protected are 117 determined, nor how the details of the protected flows and the FEC 118 streams which protect them are communicated from sender to receiver. 119 It is expected that any complete Content Delivery Protocol 120 specification which makes use of this framework will address these 121 signalling requirements. However, this document does specify the 122 information which is required by the FEC Framework at the sender and 123 receiver - for example details of the flows to be FEC protected, the 124 flow(s) that will carry the FEC protection data and an opaque 125 container for FEC-Scheme-specific information. 127 FEC Schemes designed for use with this framework must fulfil a number 128 of requirements defined in this document. Note that these 129 requirements are different from those defined in [RFC5052] for FEC 130 Schemes for object delivery. However there is a great deal of 131 commonality and FEC Schemes defined for object delivery may be easily 132 adapted for use with the framework defined here. 134 2. Definitions/Abbreviations 136 'FEC' Forward Error Correction. 138 'AL-FEC' Application Layer Forward Error Correction 140 'FEC Framework' A protocol framework for definition of Content 141 Delivery Protocols using FEC, such as the framework defined in 142 this document. 144 'Source data flow' The packet flow or flows to which FEC protection 145 is to be applied. 147 'Repair data flow' The packet flow or flows carrying forward error 148 correction data 150 'Source protocol' A protocol used for the source data flow being 151 protected - e.g. RTP. 153 'Transport protocol' The protocol used for transport of the source 154 data flow being protected - e.g. UDP, DCCP. 156 'Transport payload' Data used as the payload for the transport layer 157 (e.g. UDP or DCCP packet payload) 159 'Application protocol' Control protocols used to establish and 160 control the source data flow being protected - e.g. RTSP. 162 'FEC Code' An algorithm for encoding data such that the encoded data 163 flow is resiliant to data loss or corruption. 165 'FEC Scheme' A specification which defines the additional protocol 166 aspects required to use a particular FEC code with the FEC 167 Framework, or (in the context of RMT), with the RMT FEC Building 168 Block. 170 'Source Block' the group of source data packets which are to be FEC 171 protected as a single block 173 'Protection amount' The relative increase in data sent due to the 174 use of FEC. 176 FEC Framework Configuration Information: Information which controls 177 the operation of the FEC Framework. 179 FEC Payload ID: Information which identifies the contents of a 180 packet with respect to the FEC Scheme. 182 Source FEC Payload ID: An FEC Payload ID specifically for use with 183 source packets. 185 Repair FEC Payload ID: An FEC Payload ID specifically for use with 186 repair packets. 188 Content Delivery Protocol (CDP): A complete application protocol 189 specification which, through the use of the framework defined in 190 this document, is able to make use of FEC Schemes to provide 191 Forward Error Correction capabilities. 193 3. Requirements notation 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 4. Architecture Overview 201 The FEC Framework is described in terms of an additional protocol 202 layer between the transport layer (e.g. UDP or DCCP) and Application 203 and Transport Protocols running over this transport layer. Examples 204 of such protocols are RTP, RTCP, etc. As such, the data path 205 interface between the FEC Framework and both underlying and overlying 206 layers can be thought of as being the same as the standard interface 207 to the transport layer - i.e. the data exchanged consists of datagram 208 payloads each associated with a single transport flow identified by 209 the standard 5-tuple { Source IP Address, Source Transport Port, 210 Destination IP Address, Destination Transport Port, Transport 211 Protocol }. 213 The FEC Framework makes use of an FEC Scheme, in a similar sense to 214 that defined in [RFC5052] and uses the terminology of that document. 215 The FEC Scheme provides FEC encoding and decoding and describes the 216 protocol fields and or procedures used to identify packet payload 217 data in the context of the FEC Scheme. The interface between the FEC 218 Framework and an FEC Scheme, which is described in this document, is 219 a logical one, which exists for specification purposes only. At an 220 encoder, the FEC Framework passes groups of transport packet payloads 221 to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC 222 repair packet payloads, encoded FEC Payload ID information for each 223 of the repair packets and, in some cases, encoded FEC Payload ID 224 information for each of the source packets. At a decoder, the FEC 225 Framework passes transport packet payloads (source and repair) to the 226 FEC Scheme and the FEC Scheme returns additional recovered source 227 packet payloads. 229 This document defines certain FEC Framework Configuration Information 230 which MUST be available to both sender and receiver(s). For example, 231 this information includes the specification of the transport flows 232 which are to be FEC protected, specification of the transport flow(s) 233 which will carry the FEC protection (repair) data and the 234 relationship(s) between these 'source' and 'repair' flows (i.e. which 235 source flow(s) are protected by each repair flow. The FEC Framework 236 Configuration Information also includes information fields which are 237 specific to the FEC Scheme. This information is analagous to the FEC 238 Object Transmission Information defined in [RFC5052]. 240 The FEC Framework does not define how the FEC Framework Configuration 241 Information for the stream is communicated from sender to receiver. 242 This must be defined by any Content Delivery Protocol specification 243 as described in the following sections. 245 In this architecture we assume that the interface to the transport 246 layer supports the concepts of payloads to be transported and 247 identification transport flows on which those payloads are 248 transported. Since this is an interface internal to the 249 architecture, we do not specify this interface explicitly, except to 250 say that transport flows which are distinct from the transport layer 251 point of view (for example, distinct UDP flows as identified by the 252 UDP source/destination ports/addresses) are also distinct on the 253 interface between the transport layer and the FEC Framework. 255 The architecture outlined above is illustrated in the Figure 1. 257 +--------------------------------------------+ 258 | | 259 | Application | 260 | | 261 +--------------------------------------------+ 262 ^ 263 | 264 v 265 + - - - - - - -- - - - - - - - - - - - - - - - - + 266 | | 267 +--------------------------------------------+ 268 | | | | 269 | Application Layer | 270 | | | | 271 +--------------------------------------------+ 272 | +---------------------------------+ | | 273 | | | 274 | | Application/Transport Protocol | | | 275 | (e.g. RTP) | |-Configuration/Coordination 276 | +---------------------------------+ | | 277 ^ | 278 | | Transport flows | | 279 v v 280 | +--------------------------------------------+ | +----------------+ 281 | | | | 282 | | FEC Framework (this document) |------| FEC Scheme | 283 | | | | 284 | +--------------------------------------------+ | +----------------+ 285 ^ 286 | | Transport flows | 287 v 288 | +--------------------------------------------+ | 289 | | 290 | | Transport Layer (e.g. UDP) | | 291 | | 292 +--------------------------------------------+ 293 | +--------------------------------------------+ | 294 | | 295 | | IP | | 296 | | 297 | +--------------------------------------------+ | 298 Content Delivery Protocol 299 + - - - - - - - - - - - - - - - - - - - - - - - + 301 Figure 1: FEC Framework Architecture 303 The contents of the transport payload for repair packets is fully 304 defined by the FEC Scheme. FEC Schemes MAY define a means for repair 305 data to be carried over RTP, in which case the repair packet payload 306 format starts with the RTP header. This specification provides 307 guidelines for the use of RTP for the repair flows in this manner, 308 however the explicit specification of this case is delegated to FEC 309 Schemes. 311 The use of RTP for repair packets is independent of the protocols 312 used for source packets: if RTP is used for source packets then 313 repair packets may or may not use RTP and vice versa (although it is 314 unlikely that there are useful scenarios where non-RTP source flows 315 are protected by RTP repair flows). FEC Schemes are expected to 316 recover entire transport payloads for recovered source packets in all 317 cases. For example if RTP is used for source flows, the FEC Scheme 318 is expected to recover the entire UDP payload, including the RTP 319 header. 321 Editor's note: An alternative possibility would be to define a 322 single RTP Payload Format (and associated MIME Type) for the 323 carriage of FEC repair data for any FEC Scheme. In this case, FEC 324 Scheme specifications need not mention RTP: the encapsulation of 325 repair payloads in RTP packets will be defined for all schemes by 326 a single RTP Payload Format specification. 328 5. Procedural overview 330 5.1. General 332 The mechanism defined in this document does not place any 333 restrictions on the source transport payloads which can be protected 334 together, except that the source transport payload is carried over a 335 supported transport protocol (See Section 7). The data may be from 336 multiple transport flows that are protected jointly. The FEC 337 framework handles the packet flows as a sequence of 'source blocks' 338 each consisting of a set of source transport payloads, possibly from 339 multiple flows which are to be protected together. For example, each 340 source block may be constructed from those source transport payloads 341 related to a particular segment in time of the flow. 343 At the sender, the FEC Framework passes the payloads for a given 344 block to the FEC Scheme for FEC encoding. The FEC Scheme performs 345 the FEC encoding operation and returns the following information: 347 o optionally, encoded FEC Payload IDs for each of the source 348 payloads 350 o one or more FEC repair packet payloads 352 o encoded FEC Payload IDs for each of the repair packet payloads 354 The FEC framework then performs two operations: Firstly, it appends 355 the FEC payload IDs, if provided, to each of the source transport 356 payloads, and sends the resulting packets, known as 'FEC source 357 packets', to the receiver and secondly it places the provided 'FEC 358 repair packet payloads' and corresponding 'FEC Repair Payload IDs' 359 appropriately to construct 'FEC repair packets' and send them to the 360 receiver. Note that FEC repair packets MAY be sent to a different 361 multicast group or groups from the source packets. 363 This document does not define how the sender determines which source 364 transport payloads are included in which source blocks or the sending 365 order and timing of FEC source and FEC repair packets. A specific 366 Content Delivery Protocol MAY define this mapping or it MAY be left 367 as implementation dependent at the sender. However, a CDP 368 specification MUST define how a receiver determines the length of 369 time it should wait to receive FEC repair packets for any given 370 source block. The sequence of operations at the sender is described 371 in more detail in Section 5.2. 373 At the receiver, original source transport payloads are recovered by 374 the FEC Framework directly from any FEC Source packets received 375 simply by removing the Source FEC Payload ID, if present. The 376 receiver also passes the contents of the received FEC Source 377 transport payloads, plus their FEC Payload IDs to the FEC Scheme for 378 possible decoding. 380 If any FEC source transport payloads related to a given source block 381 have been lost, then the FEC Scheme may perform FEC decoding to 382 recover the missing source transport payloads (assuming sufficient 383 FEC Source and FEC Repair packets related to that source block have 384 been received). 386 Note that the receiver may need to buffer received source packets to 387 allow time for the FEC Repair packets to arrive and FEC decoding to 388 be performed before some or all of the received or recovered packets 389 are passed to the application. If such a buffer is not provided, 390 then the application must be able to deal with the severe re-ordering 391 of packets that will be required. However, such buffering is Content 392 Delivery Protocol and/or implementation-specific and is not specified 393 here. The receiver operation is described in more detail in 394 Section 5.3 396 The FEC Source packets MUST contain information which identifies the 397 source block and the position within the source block (in terms 398 specific to the FEC Scheme) occupied by the packet. This information 399 is known as the 'Source FEC Payload ID'. The FEC Scheme is 400 responsible for defining and interpreting this information. This 401 information MAY be encoded into a specific field within the FEC 402 Source packet format defined in this specification, called the 403 Explicit Source FEC Payload ID field. The exact contents and format 404 of the Explicit Source FEC Payload ID field are defined by the FEC 405 Scheme. Alternatively, the FEC Scheme MAY define how the Source FEC 406 Payload ID is derived from other fields within the source packets. 407 This document defines the way that the Explicit Source FEC Payload ID 408 field is appended to source packets to form FEC Source packets. 410 The FEC Repair packets MUST contain information which identifies the 411 source block and the relationship between the contained repair 412 payloads and the original source block. This is known as the 'Repair 413 FEC Payload ID'. This information MUST be encoded into a specific 414 field, the Repair FEC Payload ID field, the contents and format of 415 which are defined by the FEC Scheme. 417 The FEC Scheme MAY use different FEC Payload ID field formats for FEC 418 Source packets and FEC Repair packets. 420 5.2. Sender Operation 422 It is assumed that the sender has constructed or received original 423 data packets for the session. These may be RTP, RTCP, MIKEY or 424 indeed any other type of packet. The following operations, 425 illustrated in Figure 2 describe a possible way to generate compliant 426 FEC Source packet and FEC repair packet streams: 428 1. Source transport payloads are provided by the application. 430 2. A source block is constructed as specified in Section 6.2. 432 3. The source block is passed to the FEC Scheme for FEC encoding. 433 The Source FEC Payload ID information of each Source packet is 434 determined by the FEC Scheme. If required by the FEC Scheme the 435 Source FEC Payload ID is encoded into the Explicit Source FEC 436 Payload ID field. 438 4. The FEC Scheme performs FEC Encoding, generating repair packet 439 payloads from a source block and a Repair FEC Payload ID field for 440 each repair payload. 442 5. The Explicit Source FEC Payload IDs (if used), Repair FEC 443 Payload IDs and repair packet payloads are provided back from the 444 FEC Scheme to the FEC Framework. 446 6. The FEC Framework constructs FEC Source packets according to 447 Section 6.3 and FEC Repair packets according to Section 6.4 449 using the FEC Payload IDs and repair packet payloads provided by 450 the FEC Scheme. 452 7. The FEC Source and FEC Repair packets are sent using normal 453 transport layer procedures. The port(s) and multicast group(s) to 454 be used for FEC Repair packets are defined in the FEC Framework 455 Configuration Information. The FEC Source packets are sent using 456 the same transport flow identification information as would have 457 been used for the original source packets if the FEC Framework 458 were not present (for example, in the UDP case, the UDP source and 459 destination addresses and ports on the eventual IP FEC Source 460 Packet will be the same whether or not the FEC Framework is 461 applied). 463 +-------------------------------------+ 464 | | 465 | Application | 466 | | 467 +-------------------------------------+ 468 | 469 | (1) Source transport payloads 470 | 471 v 472 +-------------------------------------+ +---------------------+ 473 | FEC Framework | | | 474 | |------------------------------->| FEC Scheme | 475 | (2) Construct source blocks | (3) Source Block | | 476 | | | (4) FEC Encoding | 477 | (6) Construct FEC source packets |<-------------------------------| | 478 | and FEC repair packets | (5) Ex. Source FEC Payload Ids,| | 479 +-------------------------------------+ Repair FEC Payload Ids, +---------------------+ 480 | Repair payloads 481 | 482 | (7) FEC Source packets and FEC repair packets 483 v 484 +-------------------------------------+ 485 | | 486 | Transport Layer (e.g. UDP) | 487 | | 488 +-------------------------------------+ 490 Figure 2: Sender operation 492 5.3. Receiver Operation 494 The following describes a possible receiver algorithm, illustrated in 495 Figure 3, when receiving an FEC source or repair packet: 497 1. FEC Source Packets and FEC Repair packets are received and 498 passed to the FEC Framework. The type of packet (Source or 499 Repair) and the transport flow to which it belongs (in the case of 500 source packets ) is indicated by the transport flow information 501 which identifies the flow at the transport layer (for example 502 source and destination ports and addresses in the case of UDP). 504 2. The FEC Framework extracts the Explicit Source FEC Payload ID 505 field (if present) from FEC Source Packets and the Repair FEC 506 Payload ID from FEC Repair Packets. 508 3. The Explicit Source FEC Payload IDs (if present), Repair FEC 509 Payload IDs, FEC Source payloads and FEC Repair payloads are 510 passed to the FEC Scheme. 512 4. The FEC Scheme uses the received FEC Payload IDs (and derived 513 FEC Source Payload IDs in the case that the Explicit Source FEC 514 Payload ID field is not used) to group source and repair packets 515 into source blocks. If at least one source packet is missing from 516 a source block, and at least one repair packet has been received 517 for the same source block then FEC decoding may be performed in 518 order to recover missing source payloads. The FEC Scheme 519 determines whether source packets have been lost and whether 520 enough data for decoding of any or all of the missing source 521 payloads in the source block has been received. 523 5. The FEC Scheme returns the source transport payload to the FEC 524 Framework in the form of source blocks containing received and 525 decoded source packets and indications of any source packets which 526 were missing and could not be decoded. 528 6. The FEC Framework passes the received and recovered source 529 packet payloads to the application. 531 +-------------------------------------+ 532 | | 533 | Application | 534 | | 535 +-------------------------------------+ 536 ^ 537 | (6) Source transport payloads 538 | 539 | 540 +-------------------------------------+ +---------------------+ 541 | FEC Framework | | | 542 | |<-------------------------------| FEC Scheme | 543 | (2) Extract FEC Payload IDs and | (5) Source Transport Payloads | | 544 | pass Payloads and Payload IDs | | (4) FEC Decoding | 545 | to FEC Scheme |------------------------------->| | 546 | | (3) Ex. FEC Source Payload IDs,| | 547 +-------------------------------------+ FEC Repair Payload IDs, +---------------------+ 548 ^ FEC Source Payloads, 549 | FEC Repair Payloads 550 | 551 | (1) FEC Source packets and FEC repair packets 552 | 553 +--------------------------------------------+ 554 | | 555 | Transport Layer (e.g. UDP) | 556 | | 557 +--------------------------------------------+ 559 Figure 3: Receiver Operation 561 Note that the above procedure may result in a situation in which not 562 all original source packets are recovered. 564 Source packets which are correctly received and those which are 565 reconstructed MAY be delivered to the application out of order and in 566 a different order from the order of arrival at the receiver. 567 Alternatively, buffering and packet re-ordering MAY be required to 568 re-order received and reconstructed source packets into the order 569 they were placed into the source block, if that is necessary 570 according to the application. 572 6. Protocol Specification 574 6.1. General 576 This section specifies the protocol elements for the FEC Framework. 577 Three components of the protocol are defined in this document and are 578 described in the following sections: 580 1. Construction of a source block from source payloads. The FEC 581 code will be applied to this source block to produce the repair 582 payloads. 584 2. A format for packets containing source data. 586 3. A format for packets containing repair data. 588 The operation of the FEC Framework is governed by certain FEC 589 Framework Configuation Information. This configuration information 590 is also defined in this section. A complete protocol specification 591 that uses this framework MUST specify the means to determine and 592 communicate this information between sender and receiver. 594 6.2. Structure of the source block 596 The FEC Framework and FEC Scheme exchange source transport payload in 597 the form of source blocks. A source block is generated by the FEC 598 Framework from an ordered sequence of source transport payloads. The 599 allocation of transport payloads to blocks is dependent on the 600 application. Note that some source transport payloads may not be 601 included in any block. For each source transport payload included in 602 a source block, the following information is provided to the FEC 603 Scheme: 605 o A description of the source transport flow with which the 606 transport payload is associated (See 6.5) 608 o The source transport payload itself 610 o The length of the source transport payload 612 6.3. Packet format for FEC Source packets 614 The packet format for FEC Source packets MUST be used to transport 615 the payload of an original source packet. As depicted in Figure 4, 616 it consists of the original packet, optionally followed by the 617 Explicit Source FEC Payload ID field. The FEC Scheme determines 618 whether the Explicit Source FEC Payload ID field is required. This 619 determination is specific to each transport flow. 621 +------------------------------------+ 622 | IP header | 623 +------------------------------------+ 624 | Transport header | 625 +------------------------------------+ 626 | Original transport Payload | 627 +------------------------------------+ 628 | Explicit Source FEC Payload ID | 629 +------------------------------------+ 631 Figure 4: Structure of the FEC packet format for FEC Source packets 633 The FEC Source packets MUST be sent using the same transport flow as 634 would have been used for the original source packets if the FEC 635 Framework were not present. The Original transport Payload field 636 MUST be identical to the source transport payload. The transport 637 payload of the FEC Source packet MUST consist of the Original 638 Transport Payload followed by the Explicit Source FEC Payload ID 639 field, if required. 641 The Explicit Source FEC Payload ID field contains information 642 required to associate the source packet with a source block and for 643 the operation of the FEC algorithm and is defined by the FEC Scheme. 644 The format of the Source FEC Payload ID field is defined by the FEC 645 Scheme. Note that in the case that the FEC Scheme or CDP defines a 646 means to derive the Source FEC Payload ID from other information in 647 the packet (for example the a sequence number of some kind used by 648 the application protocol), then the Source FEC Payload ID field is 649 not included in the packet. In this case the original source packet 650 and FEC Source Packet are identical. 652 Since the addition of the Explicit Source FEC Payload ID increases 653 the packet length, then in applications where avoidance of IP packet 654 fragmentation is a goal, Content Delivery Protocols SHOULD consider 655 the Explicit Source FEC Payload ID size when determining the size of 656 source transport payloads that will be delivered using the FEC 657 Framework. 659 Note: The Explicit Source FEC Payload ID is placed at the end of the 660 packet so that in the case that Robust Header Compression [RFC3095] 661 or other header compression mechanisms are used and in the case that 662 a ROHC profile is defined for the protocol carried within the 663 transport payload (for example RTP), then ROHC will still be applied 664 for the FEC Source packets. Applications that may be used with this 665 Framework should consider that FEC Schemes may add this Explicit 666 Source FEC Payload ID and thereby increase the packet size. 668 6.4. Packet Format for FEC Repair packets 670 The packet format for FEC Repair packets is shown in Figure 5. The 671 transport payload consists of a Repair FEC Payload ID field followed 672 by repair data generated in the FEC encoding process. 674 +------------------------------------+ 675 | IP header | 676 +------------------------------------+ 677 | Transport header | 678 +------------------------------------+ 679 | Repair FEC Payload ID | 680 +------------------------------------+ 681 | Repair Symbols | 682 +------------------------------------+ 684 Figure 5: Packet format for repair packets 686 The Repair FEC Payload ID field contains information required for the 687 operation of the FEC algorithm at the receiver. This information is 688 defined by the FEC Scheme. The format of the Repair FEC Payload ID 689 field is defined by the FEC Scheme. 691 6.4.1. Packet Format for FEC Repair packets over RTP (informative) 693 For FEC Schemes which specify the use of RTP for repair packets, the 694 packet format for repair packets includes an RTP header as shown in 695 Figure 6. 697 +------------------------------------+ 698 | IP header | 699 +------------------------------------+ 700 | Transport header (UDP) | 701 +------------------------------------+ 702 | RTP Header | 703 +------------------------------------+ 704 | Repair FEC Payload ID | 705 +------------------------------------+ 706 | Repair Symbols | 707 +------------------------------------+ 709 Figure 6: Packet format for repair packets 711 6.5. FEC Framework Configuration Information 713 The FEC Framework Configuration Information is information that the 714 FEC Framework needs in order to apply FEC protection to the transport 715 flows. A complete Content Delivery Protocol specification that uses 716 the framework specified here MUST include details of how this 717 information is derived and communicated between sender and receiver. 719 The FEC Framework Configuration Information includes identification 720 of a set of source packet flows. For example, in the case of UDP, 721 each packet flow is uniquely identified by a tuple { Source IP 722 Address, Destination IP Address, Source UDP port, Destination UDP 723 port }. Note that in some applications some of these fields may be 724 wildcarded, so that the flow is identified by a subset of the fields 725 and in particular in many applications the limited tuple { 726 Destination IP Address, Destination UDP port } is sufficient. 728 A single instance of the FEC Framework provides FEC protection for 729 all packets of a specified set of source packet flows, by means of 730 one or more packet flows consisting of repair packets. The FEC 731 Framework Configuation Information includes, for each instance of the 732 FEC Framework: 734 1. Identification of the packet flow(s) carrying FEC Repair 735 packets, known as the FEC repair flow(s). 737 2. For each source packet flow protected by the FEC repair 738 flow(s): 740 a. Defintion of the packet flow carrying source packets (for 741 example, by means of a tuple as describe above for UDP). 743 b. An integer identifier for this flow definition (i.e. 744 tuple). This identifier MUST be unique amongst all source 745 packet flows which are protected by the same FEC repair flow. 747 3. The FEC Encoding ID, identifying the FEC Scheme 749 4. The length of the Explicit Source FEC Payload Id, in bytes 751 5. An opaque container for FEC-Scheme-specific information 753 Multiple instances of the FEC Framework, with separate and 754 independent FEC Framework Configuration Information, may be present 755 at a sender or receiver. A single instance of the FEC Framework 756 protects all packets of all the source packet flows identified in (2) 757 above i.e. all packets sent on those flows MUST be FEC Source packets 758 as defined in Section 6.3. A single source packet flow may be 759 protected by multiple instances of the FEC Framework. 761 The integer flow identifier identified in 2(b) is a "shorthand" to 762 identify source flows between the FEC Framework and the FEC Scheme. 763 The reason for defining this as an integer, and including it in the 764 FEC Framework Configuration Information is so that the FEC Scheme at 765 the sender and receiver may use it to identify the source flow with 766 which a recovered packet is associated. The integer flow identifier 767 may therefore take the place of the complete flow description (e.g. 768 UDP 4-tuple). 770 Whether and how this flow identifier is used is defined by the FEC 771 Scheme. Since source packets are directly associated with a flow by 772 virtue of their packet headers, this identifier need not be carried 773 in source packets. Since repair packets may provide protection for 774 multiple source flows, this flow identifier would likely not be 775 carried directly in repair packets. However, the flow identifier 776 associated with a particular source packet may be recovered from the 777 repair packets as part of an FEC decoding operation. Integer flow 778 identifiers SHOULD be allocated starting from zero and increasing by 779 one for each flow. 781 A single FEC repair flow provides repair packets for a single 782 instance of the FEC Framework. Other packets MUST NOT be sent within 783 this flow i.e. all packets in the FEC repair flow MUST be FEC repair 784 packets as defined in Section 6.4 and MUST relate to the same FEC 785 Framework instance. 787 In the case that RTP is used for repair packets, the identification 788 of the repair packet flow MAY also include the RTP Payload Type to be 789 used for repair packets. 791 6.6. FEC Scheme requirements 793 In order to be used with this framework, an FEC Scheme MUST be 794 capable of processing data arranged into blocks of source transport 795 packet payloads (source blocks). 797 A specification for a new FEC scheme MUST include the following 798 things: 800 1. The FEC Encoding ID value that uniquely identifies the FEC 801 scheme. This value MUST be registered with IANA as described in 802 Section 10. 804 2. The type, semantics and encoding format of the Repair FEC Payload 805 ID. 807 3. The type, semantics and encoding format of the FEC Scheme- 808 specific FEC Framework Configuration Information. 810 4. A full specification of the FEC code. 812 This specification MUST precisely define the valid FEC-Scheme- 813 Specific FEC Framework Configuration Information values, the 814 valid FEC Payload ID values and the valid packet payload sizes 815 (where packet payload refers to the space - not necessarily 816 contiguous - within a packet dedicated to carrying encoding 817 symbol bytes). 819 Furthermore, given a source block as defined in Section 6.2, 820 valid values of the FEC-Scheme-Specific FEC Framework 821 Configuration Information, a valid Repair FEC Payload ID value 822 and a valid packet payload size, the specification MUST uniquely 823 define the values of the encoding symbol bytes to be included in 824 the repair packet payload of a packet with the given Repair FEC 825 Payload ID value. 827 A common and simple way to specify the FEC code to the required 828 level of detail is to provide a precise specification of an 829 encoding algorithm which, given a source block, valid values of 830 the FEC-Scheme-Specific FEC Framework Configuration Information, 831 a valid Repair FEC Payload ID value and a valid packet payload 832 size as input produces the exact value of the encoding symbol 833 bytes as output. 835 5. A description of practical encoding and decoding algorithms. 837 This description need not be to the same level of detail as for 838 the encoding above, however it must be sufficient to demonstrate 839 that encoding and decoding of the code is both possible and 840 practical. 842 FEC scheme specifications MAY additionally define the following: 844 1. Type, semantics and encoding format of an Explicit Source FEC 845 Payload ID. 847 Whenever an FEC scheme specification defines an 'encoding format' for 848 an element, this must be defined in terms of a sequence of bytes 849 which can be embedded within a protocol. The length of the encoding 850 format MUST either be fixed or it must be possible to derive the 851 length from examining the encoded bytes themselves. For example, the 852 initial bytes may include some kind of length indication. 854 FEC scheme specifications SHOULD use the terminology defined in this 855 document and SHOULD follow the following format: 857 1. Introduction 860 2. Formats and Codes 862 2.1 Source FEC Payload ID(s) 866 2.2 Repair FEC Payload Id 869 2.3 FEC Framework Configuration Information 873 3. Procedures 878 4. FEC code specification 881 Specifications MAY include additional sections, for example, 882 examples. 884 Each FEC scheme MUST be specified independently of all other FEC 885 schemes; for example, in a separate specification or a completely 886 independent section of larger specification (except, of course, a 887 specification of one FEC Scheme may include portions of another by 888 reference). 890 7. Transport Protocols 892 The following transport protocols are supported: 894 o User Datagram Protocol (UDP) 896 o Datagram Congestion Control Protocol (DCCP) 898 Editor's note: This section will contain transport-specific 899 considerations, if any. 901 8. Congestion Control 903 This section starts with a informative section on the motivation of 904 the normative requirements for congestion control, which are spelled 905 out in Section 8.1. 907 Informative Note: The enforcement of Congestion Control (CC) 908 principles has gained a lot of momentum in the IETF over the 909 recent years. While the need of CC over the open Internet is 910 unquestioned, and the goal of TCP friendliness is generally agreed 911 for most (but not all) applications, the subject of congestion 912 detection and measurement in heterogenous networks can hardly be 913 considered as solved. Most congestion control algorithms detect 914 and measure congestion by taking (primarily or exclusively) the 915 packet loss rate into account. This appears to be inappropriate 916 in environments where a large percentage of the packet losses are 917 the result link-layer errors and independent of the network load. 918 Note that such environments exist in the "open Internet", as well 919 as in "closed" IP based networks. An example for the former would 920 be the use of IP/UDP/RTP based streaming from an Internet- 921 connected streaming server to a device attached to the Internet 922 using cellular technology. 924 The authors of this draft are primarily interested in applications 925 where the application reliability requirements and end-to-end 926 reliability of the network differ, such that it warrants higher 927 layer protection of the packet stream - for example due to the 928 presence of unreliable links in the end-to-end path - and where 929 real-time, scalability or other constraints prohibit the use of 930 higher layer (transport or application) feedback. A typical 931 example for such applications is multicast and broadcast streaming 932 or multimedia transmission over heterogenous networks. In other 933 cases, application reliability requirements may be so high that 934 the required end-to-end reliability is difficult to achieve even 935 over wired networks. Furthermore the end-to-end network 936 reliability may not be known in advance. 938 This FEC framework is not proposed, nor intended, as a QoS 939 enhancement tool to combat losses resulting from highly congested 940 networks. It should not be used for such purposes. 942 In order to prevent such mis-use, one approach would be to leave 943 standardisation to bodies most concerned with the problem 944 described above. However, the IETF defines base standards used by 945 several bodies, including DVB, 3GPP, 3GPP2, all of which appear to 946 share the environment and the problem described. 948 Another approach would be to write a clear applicability statement 949 - for example restricting use of the framework to networks with 950 wireless links. However, there may be applications where the use 951 of FEC may be justified to combat congestion-induced packet losses 952 - particularly in lightly loaded networks, where congestion is the 953 result of relatively rare random peaks in instantaneous traffic 954 load - thereby intentionally violating congestion control 955 principles. One possible example for such an application could be 956 a no-matter-what, brute-force FEC protection of traffic generated 957 as an emergency signal. 959 We propose a third approach, which is to require at a minimum that 960 the use of this framework with any given application, in any given 961 environment, does not cause congestion issues which the 962 application alone would not itself cause i.e. the use of this 963 framework must not make things worse. 965 Taking above considerations into account, the normative text of 966 this section implements a small set of constraints for the FEC, 967 which are mandatory for all senders compliant with this FEC 968 framework. Further restrictions may be imposed for certain 969 Content Delivery Protocols. In this it follows the spirit of the 970 congestion control section of RTP and its Audio-Visual Profile 971 (RFC3550/STD64 and RFC3551/STD65). 973 One of the constraints effectively limits the bandwidth for the 974 FEC protected packet stream to be no more than roughly twice as 975 high as the original, non-FEC protected packet stream. This 976 disallows the (static or dynamic) use of excessively strong FEC to 977 combat high packet loss rates, which may otherwise be chosen by 978 naively implemented dynamic FEC-strength selection mechanisms. We 979 acknowledge that there may be a few exotic applications, e.g. IP 980 traffic from space-based senders, or senders in certain hardened 981 military devices, which would warrant a higher FEC strength. 982 However, in this specification we give preference to the overall 983 stability and network friendliness of the average application, and 984 for those a factor of 2 appears to be appropriate. 986 A second constraint requires that the FEC protected packet stream 987 be in compliance with the congestion control in use for the 988 application and network in question. 990 8.1. Normative requirements 992 The bandwidth of FEC Repair packet flows MUST NOT exceed the 993 bandwidth of the source packet flows being protected. In addition, 994 whenever the source packet flow bandwidth is adapted due to the 995 operation of congestion control mechanisms, the FEC repair packet 996 flow bandwidth MUST be similarly adapted. 998 9. Security Considerations 1000 The application of FEC protection to a stream does not provide any 1001 kind of security protection. 1003 If security services are required for the stream, then they MUST 1004 either be applied to the original source transport payload before FEC 1005 protection is applied, or to both the source and repair data, after 1006 FEC protection has been applied. 1008 If integrity protection is applied to source packets before FEC 1009 protection is applied, and no further integrity protection is applied 1010 to repair packets, then a denial of service attack is possible if an 1011 attacker is in a position to inject fake repair transport payloads. 1012 If received by a receiver, such fake repair transport payloads could 1013 cause incorrect FEC decoding resulting in incorrect source transport 1014 payloads being passed up to the application protocol. Such incorrect 1015 packets would then be detected by the source integrity protection and 1016 discarded, resulting in partial or complete denial of service. 1017 Therefore, in such environments, integrity protection MUST also be 1018 applied to the FEC repair transport payloads, for example using 1019 IPsec. Receivers MUST also verify the integrity of source transport 1020 payloads before including the source transport payload into the 1021 source block for FEC purposes. 1023 It is possible that multiple streams with different confidentiality 1024 requirements (for example, the streams may be visible to different 1025 sets of users) can be FEC protected by a single repair stream. This 1026 scenario is not recommended, since resources will be used to 1027 distribute and decode data which cannot then be decrypted by at least 1028 some receivers. However, in this scenario, confidentiality 1029 protection MUST be applied before FEC encoding of the streams, 1030 otherwise repair transport payload may be used by a receiver to 1031 decode unencrypted versions of source streams which they do not have 1032 permissionions to view. 1034 10. IANA Considerations 1036 tbd 1038 11. Acknowledgments 1040 This document is based in large part on [I-D.watson-tsvwg-fec-sf] and 1041 so thanks are due to the additional authors of that document, Mike 1042 Luby, Magnus Westerlund and Stephan Wenger. That document was in 1043 turn based on the FEC streaming protocol defined by 3GPP in [MBMSTS] 1044 and thus thanks are also due to the participants in 3GPP TSG SA 1045 working group 4. 1047 12. References 1049 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1050 Requirement Levels", BCP 14, RFC 2119, March 1997. 1052 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1053 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1054 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1055 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1056 Compression (ROHC): Framework and four profiles: RTP, UDP, 1057 ESP, and uncompressed", RFC 3095, July 2001. 1059 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1060 Correction (FEC) Building Block", RFC 5052, August 2007. 1062 [I-D.watson-tsvwg-fec-sf] 1063 Watson, M., "Forward Error Correction (FEC) Streaming 1064 Framework", draft-watson-tsvwg-fec-sf-00 (work in 1065 progress), July 2005. 1067 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1068 Protocols and codecs", 3GPP TS 26.346, April 2005. 1070 Author's Address 1072 Mark Watson 1073 Digital Fountain 1074 39141 Civic Center Drive 1075 Suite 300 1076 Fremont, CA 94538 1077 U.S.A. 1079 Email: mark@digitalfountain.com 1081 Full Copyright Statement 1083 Copyright (C) The IETF Trust (2008). 1085 This document is subject to the rights, licenses and restrictions 1086 contained in BCP 78, and except as set forth therein, the authors 1087 retain all their rights. 1089 This document and the information contained herein are provided on an 1090 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1091 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1092 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1093 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1094 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1095 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1097 Intellectual Property 1099 The IETF takes no position regarding the validity or scope of any 1100 Intellectual Property Rights or other rights that might be claimed to 1101 pertain to the implementation or use of the technology described in 1102 this document or the extent to which any license under such rights 1103 might or might not be available; nor does it represent that it has 1104 made any independent effort to identify any such rights. Information 1105 on the procedures with respect to rights in RFC documents can be 1106 found in BCP 78 and BCP 79. 1108 Copies of IPR disclosures made to the IETF Secretariat and any 1109 assurances of licenses to be made available, or the result of an 1110 attempt made to obtain a general license or permission for the use of 1111 such proprietary rights by implementers or users of this 1112 specification can be obtained from the IETF on-line IPR repository at 1113 http://www.ietf.org/ipr. 1115 The IETF invites any interested party to bring to its attention any 1116 copyrights, patents or patent applications, or other proprietary 1117 rights that may cover technology that may be required to implement 1118 this standard. Please address the information to the IETF at 1119 ietf-ipr@ietf.org.