idnits 2.17.1 draft-watson-fecframe-framework-00.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 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 941. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 15, 2006) is 6402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 861, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-04 == Outdated reference: A later version (-06) exists of draft-mehta-rmt-flute-sdp-05 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 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: Informational October 15, 2006 5 Expires: April 18, 2007 7 Forward Error Correction (FEC) Framework 8 draft-watson-fecframe-framework-00 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 April 18, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document provides an initial proposal for a framework for using 42 forward error correction (FEC) codes with applications in the 43 Internet to provide protection against packet loss. The framework 44 supports applying Forward Error Correction to arbitrary packet flows 45 and is primarily intended for streaming media. This framework can be 46 used to define Content Delivery Protocols that provide Forward Error 47 Correction for streaming media delivery or other packet flows. 48 Content Delivery Protocols defined using this framework can support 49 any FEC Scheme (and associated FEC codes) which is compliant with 50 various requirements defined in this document. Thus, Content 51 Delivery Protocols can be defined which are not specific to a 52 particular FEC Scheme and FEC Schemes can be defined which are not 53 specific to a particular Content Delivery Protocol. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 5 59 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 60 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 8 61 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 10 62 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 11 64 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 12 65 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 14 66 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6.2. Structure of the source block . . . . . . . . . . . . . . 14 68 6.3. Packet format for FEC Source packets . . . . . . . . . . . 14 69 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 15 70 6.5. FEC Framework Configuration Information . . . . . . . . . 16 71 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 17 72 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 18 73 8. Session Description Protocol elements . . . . . . . . . . . . 19 74 8.1. udp/fec/ transport protocol identifier . . . . . . 19 75 8.2. udp/fec transport protocol identifier . . . . . . . . . . 20 76 8.3. fec-declaration attribute . . . . . . . . . . . . . . . . 20 77 8.4. fec-oti-extension attribute . . . . . . . . . . . . . . . 20 78 8.5. fec attribute . . . . . . . . . . . . . . . . . . . . . . 20 79 8.6. FEC media grouping semantics . . . . . . . . . . . . . . . 20 80 8.7. SDP example . . . . . . . . . . . . . . . . . . . . . . . 20 81 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21 82 9.1. Normative requirements . . . . . . . . . . . . . . . . . . 22 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 85 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 88 Intellectual Property and Copyright Statements . . . . . . . . . . 29 90 1. Introduction 92 Many applications have a requirement to transport a continuous stream 93 of packetised data from a source (sender) to one or more destinations 94 (receivers) over networks which do not provide guaranteed packet 95 delivery. Primary examples are media streaming applications such as 96 broadcast, multicast or on-demand audio, video or multi-media. 98 Forward Error Correction is a well-known technique for improving 99 reliability of packet transmission over networks which do not provide 100 guaranteed packet delivery, especially in multicast and broadcast 101 applications. The FEC Building Block defined in [4] provides a 102 framework for definition of Content Delivery Protocols (CDPs) for 103 object delivery (including, primarily, file delivery) which make use 104 of separately defined FEC Schemes. Any CDP defined according to the 105 requirements of the FEC Building Block can then easily be used with 106 any FEC Scheme which is also defined according to the requirements of 107 the FEC Building Block. 109 This document defines a framework for the definition of CDPs which 110 provide for FEC protection of arbitrary packet flows over unreliable 111 transports such as UDP. This document does not define a complete 112 Content Delivery Protocol, but rather defines only those aspects that 113 are expected to be common to all such Content Delivery Protocols. 115 This framework does not define how the flows to be protected are 116 determined, nor how the details of the protected flows and the FEC 117 streams which protect them are communicated from sender to receiver. 118 It is expected that any complete Content Delivery Protocol 119 specification which makes use of this framework will address these 120 signalling requirements. However, this document does specify the 121 information which is required by the FEC Framework at the sender and 122 receiver - for example details of the flows to be FEC protected, the 123 flow(s) that will carry the FEC protection data and an opaque 124 container for FEC-Scheme-specific information. We also specify SDP 125 [5] attributes which a Content Delivery Protocol MAY use to 126 communicate this information. 128 FEC Schemes designed for use with this framework must fulfil a number 129 of requirements defined in this document. Note that these 130 requirements are different from those defined in [4] for FEC Schemes 131 for object delivery. However there is a great deal of commonality 132 and FEC Schemes defined for object delivery may be easily adapted for 133 use with the framework defined here. 135 2. Definitions/Abbreviations 137 'FEC' Forward Erasure Correction. 139 'AL-FEC' Application Layer Forward Erasure Correction 141 'FEC Framework' A protocol framework for definition of Content 142 Delivery Protocols using FEC, such as the framework defined in 143 this document. 145 'Source data flow' The packet flow or flows to which FEC protection 146 is to be applied. 148 'Repair data flow' The packet flow or flows carrying forward error 149 correction data 151 'Source protocol' A protocol used for the source data flow being 152 protected - e.g. RTP. 154 'Transport protocol' The protocol used for transport of the source 155 data flow being protected - e.g. UDP, DCCP. 157 'Application protocol' Control protocols used to establish and 158 control the source data flow being protected - e.g. RTSP. 160 'FEC Code' An algorithm for encoding data such that the encoded data 161 flow is resiliant to data loss or corruption. 163 'FEC Scheme' A specification which defines the additional protocol 164 aspects required to use a particular FEC code with the FEC 165 framework, or (in the context of RMT), with the RMT FEC Building 166 Block. 168 'Source Block' the group of source data packets which are to be FEC 169 protected as a single block 171 'Protection amount' The relative increase in data sent due to the 172 use of FEC. 174 FEC Framework Configuration Information: Information which controls 175 the operation of the FEC Framework. 177 FEC Payload ID: Information which identifies the contents of a 178 packet with respect to the FEC Scheme. 180 Source FEC Payload ID: An FEC Payload ID specifically for use with 181 source packets. 183 Repair FEC Payload ID: An FEC Payload ID specifically for use with 184 repair packets. 186 Content Delivery Protocol (CDP): See [4]. 188 3. Requirements notation 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [1]. 194 4. Architecture Overview 196 The FEC Framework is described in terms of an additional protocol 197 layer between the transport layer (e.g. UDP or DCCP) and Application 198 and Transport Protocols running over this transport layer. Examples 199 of such protocols are RTP, RTCP, etc. As such, the data path 200 interface between the FEC Framework and both underlying and overlying 201 layers can be thought of as being the same as the standard interface 202 to the transport layer - i.e. the data exchanged consists of datagram 203 payloads each associated with a single transport flow identified by 204 the standard 5-tuple { Source IP Address, Source Transport Port, 205 Destination IP Address, Destination Transport Port, Transport 206 Protocol }. 208 The FEC Framework makes use of an FEC Scheme, in a similar sense to 209 that defined in [4] and uses the terminology of that document. The 210 FEC Scheme provides FEC encoding and decoding and describes the 211 protocol fields and or procedures used to identify packet payload 212 data in the context of the FEC Scheme. The interface between the FEC 213 Framework and an FEC Scheme, which is described in this document, is 214 a logical one, which exists for specification purposes only. At an 215 encoder, the FEC Framework passes groups of transport packet payloads 216 to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC 217 repair packet payloads, encoded FEC Payload ID information for each 218 of the repair packets and, in some cases, encoded FEC Payload ID 219 information for each of the source packets. At a decoder, the FEC 220 Framework passes transport packet payloads (source and repair) to the 221 FEC Scheme and the FEC Scheme returns additional recovered source 222 packet payloads. 224 This document defines certain FEC Framework Configuration Information 225 which MUST be available to both sender and receiver(s). For example, 226 this information includes the specification of the transport flows 227 which are to be FEC protected, specification of the transport flow(s) 228 which will carry the FEC protection (repair) data and the 229 relationship(s) between these 'source' and 'repair' flows (i.e. which 230 source flow(s) are protected by each repair flow. The FEC Framework 231 Configuration Information also includes information fields which are 232 specific to the FEC Scheme. This information is analagous to the FEC 233 Object Transmission Information defined in [4]. 235 The FEC Framework does not define how the FEC Framework Configuration 236 Information for the stream is communicated from sender to receiver. 237 This must be defined by any Content Delivery Protocol specification 238 as described below. However, this specification does define new 239 Session Description Protocol (SDP) [5] elements which MAY be used by 240 Content Delivery Protocols for this purpose. 242 The architecture outlined above is illustrated in the Figure 1. 244 + - - - - - - -- - - - - - - - - - - - - - - - - + 245 | | 246 +--------------------------------------------+ 247 | | | | 248 | Application | 249 | | | | 250 +--------------------------------------------+ 251 | +---------------------------------+ | | 252 | | | 253 | | Application Protocol (e.g. RTP) | | | 254 | | |-Configuration/Coordination 255 | +---------------------------------+ | | 256 ^ | 257 | | Transport flows | | 258 v v 259 | +--------------------------------------------+ | +----------------+ 260 | | | | 261 | | FEC Framework (this document) |------| FEC Scheme | 262 | | | | 263 | +--------------------------------------------+ | +----------------+ 264 ^ 265 | | Transport flows | 266 v 267 | +--------------------------------------------+ | 268 | | 269 | | Transport Layer (e.g. UDP) | | 270 | | 271 +--------------------------------------------+ 272 | +--------------------------------------------+ | 273 | | 274 | | IP | | 275 | | 276 | +--------------------------------------------+ | 277 Content Delivery Protocol 278 + - - - - - - - - - - - - - - - - - - - - - - - + 280 Figure 1: FEC Framework Architecture 282 5. Procedural overview 284 5.1. General 286 The mechanism defined in this document does not place any 287 restrictions on the source data which can be protected together, 288 except that the source data is carried over a supported transport 289 protocol. The data may be from several different transport flows 290 that are protected jointly. The FEC framework handles the packet 291 flows as a sequence of 'source blocks' each consisting of a set of 292 source packets, possibly from multiple flows which are to be 293 protected together. For example, each source block may be 294 constructed from those source packets related to a particular segment 295 in time of the flow. 297 At the sender, the FEC Framework passes the packet payloads for all 298 packets of a given block to the FEC Scheme for FEC encoding. The FEC 299 Scheme performs the FEC encoding operation and returns the following 300 information: 302 o optionally, encoded FEC Payload IDs for each of the source packets 304 o one or more FEC repair packet payloads 306 o encoded FEC Payload IDs for each of the repair packets 308 The FEC Framework then appends the FEC Payload IDs, if provided, to 309 each of the source packets and sends the resulting packets, known as 310 FEC SOurce Packets, to the receiver. The FEC repair packets are then 311 constructed from the provided repair data and FEC Payload IDs and 312 sent to the receiver. FEC repair packets are sent to a different 313 transport port than the source packets, as specified by the FEC 314 Configuration Information. In the case of multicast, FEC repair 315 packets MAY be sent to a different multicast group or groups from the 316 source packets. 318 This document does not define how the sender determines which source 319 packets are included in which source blocks. A specific Content 320 Delivery Protocol MAY define this mapping or it MAY be left as 321 implementation dependent at the sender. However, a CDP specification 322 MUST define how a receiver determines the length of time it should 323 wait to receive FEC repair packets for any given source block. 325 The receiver recovers original source packets directly from any FEC 326 Source packets received simply by removing the FEC Payload ID, if 327 present. The receiver also passes the contents of the received FEC 328 Source Packets, including their FEC Payload IDs to the FEC Scheme for 329 decoding. 331 If any FEC Source packets related to a given source block have been 332 lost, then the FEC Scheme may perform FEC decoding to recover the 333 missing source packets (assuming sufficient FEC Source and FEC Repair 334 packets related to that source block have been received). 336 Note that the receiver may need to buffer received source packets to 337 allow time for the FEC Repair packets to arrive and FEC decoding to 338 be performed before some or all of the received or recovered packets 339 are passed to the application. If such a buffer is not provided, 340 then the application must be able to deal with the severe re-ordering 341 of packets that will be required. However, such buffering is Content 342 Delivery Protocol and/or implementation-specific and is not specified 343 here. 345 The FEC Source packets MUST contain information which identifies the 346 source block and the position within the source block occupied by the 347 packet. The identity of the source block and the position within the 348 source block of a source packet are together known as the 'Source FEC 349 Payload ID'. The FEC Scheme is responsible for defining and 350 interpreting this information. This information MAY be encoded into 351 a specific field within the FEC Source packet format defined in this 352 specification, called the encoded Source FEC Payload ID field. The 353 exact contents and format of the encoded Source FEC Payload ID field 354 are defined by the FEC Scheme. Alternatively, the FEC Scheme or CDP 355 MAY define how the Source FEC Payload ID is derived from other fields 356 within the source packets. This document defines the way that the 357 Source FEC Payload ID field is appended to source packets to form FEC 358 Source packets. 360 The FEC Repair packets MUST contain information which identifies the 361 source block and the relationship between the contained repair data 362 and the original source block. This is known as the 'Repair FEC 363 Payload ID'. This information MUST be encoded into a specific field, 364 the Repair FEC Payload ID field, the contents and format of which are 365 defined by the FEC Scheme. 367 Any FEC Schemes to be used in conjunction with this specification 368 MUST be a systematic FEC Scheme. The FEC Scheme MAY use different 369 encoded FEC Payload ID field formats for FEC Source packets and FEC 370 Repair packets. 372 5.2. Sender Operation 374 It is assumed that the sender has constructed or received original 375 data packets for the session. These may be RTP, RTCP, MIKEY or other 376 UDP packets. The following operations describe a possible way to 377 generate compliant FEC Source packet and FEC repair packet streams: 379 1. A source block is constructed as specified in Section 6.2. 381 2. The source block is passed to the FEC Scheme for FEC encoding. 382 The Source FEC Payload ID information of each Source packet is 383 determined by the FEC Scheme and, if necessary, encoded into 384 encoded Source FEC Payload ID field. 386 3. The FEC Source packet is constructed according to Section 6.3. 387 The identity of the original flow is maintained by the source 388 packet through the use of the same transport ports and IP 389 addresses which have been advertised by the Content Delivery 390 Protocol (for example using SDP), as carrying FEC Source packets 391 generated from an original stream of a particular protocol (e.g. 392 RTP, RTCP, SRTP, MIKEY etc.). The FEC Source packet generated is 393 sent according to normal transport layer procedures. 395 4. The FEC Scheme generates repair packet payloads from a source 396 block and an encoded FEC Payload ID field for each repair paylaod. 397 The FEC Framework places these payloads and FEC Payload IDs into 398 FEC Repair packets, to be conveyed to the receiver(s). These 399 repair packets are sent using normal transport layer procedures to 400 a unique destination port(s) and/or multicast group(s) in the case 401 of multicast to separate them from any of the source packet flows. 402 The port(s) and multicast group(s) to be used for FEC Repair 403 packets are defined in the FEC Framework Configuration 404 Information. 406 5.3. Receiver Operation 408 The following describes a possible receiver algorithm, when receiving 409 an FEC source or repair packet: 411 1. If an FEC Source packet is received (as indicated by the 412 transport flow on which was received), the source packet and 413 Source FEC Payload ID field are passed to the FEC Scheme. 415 2. If an FEC repair packet is received (as indicated by the 416 transport flow on which it was received), the contained repair 417 data and Repair FEC Payload ID field are passed to the FEC Scheme. 419 3. The FEC Scheme uses the received FEC Payload IDs to group 420 source packets into source blocks. 422 4. If at least one source packet is missing from a source block, 423 and at least one repair packet has been received for a source 424 block then FEC decoding may be desirable. The FEC Scheme 425 determines if enough data for decoding of any or all of the 426 missing source packets in the source block has been received and, 427 if so, performs a decoding operation. 429 4. The FEC Scheme returns the source data to the FEC Framework in 430 the form of source blocks containing received and decoded source 431 packets and indications of any source packets which were missing 432 and could not be decoded. 434 Note that the above procedure may result in a situation in which not 435 all original source packets are recovered. 437 Source packets which are correctly received and those which are 438 reconstructed MAY be delivered to the application out of order and in 439 a different order from the order of arrival at the receiver. 440 Alternatively, buffering and packet re-ordering MAY be required to 441 re-order received and reconstructed source packets into the order 442 they were placed into the source block, if that is necessary 443 according to the application. 445 6. Protocol Specification 447 6.1. General 449 This section specifies the protocol elements for the FEC Framework. 450 The protocol consists of three components which are described in the 451 following sections: 453 1. Construction of a source block from source packets. The FEC 454 code will be applied to this source block to produce the repair 455 data. 457 2. A format for packets containing source data. 459 3. A format for packets containing repair data. 461 The operation of the FEC Framework is governed by certain FEC 462 Framework Configuation Information. This configuration information 463 is also defined in this section. A complete protocol specification 464 that uses this framework MUST specify the means to determine and 465 communicate this information between sender and receiver. Suitable 466 Session Description Protocol elements for this purpose are defined in 467 Section 8. 469 6.2. Structure of the source block 471 The FEC Framework and FEC Scheme exchange source data in the form of 472 source blocks. A source block is generated from an ordered sequence 473 of source packets. For each source packet, the following information 474 is included in the source block: 476 o The identity of the transport flow on which the packet was 477 recieved 479 o The original source packet payload 481 o The length of the original source packet payload 483 6.3. Packet format for FEC Source packets 485 The packet format for FEC Source packets MUST be used to transport 486 the payload of an original source packet. As depicted in Figure 2, 487 it consists of the original packet, optionally followed by the Source 488 FEC Payload ID field. The FEC Scheme determines whether the Source 489 FEC Payload ID field is required. This determination is specific to 490 each transport flow. 492 +------------------------------------+ 493 | IP header | 494 +------------------------------------+ 495 | Transport header | 496 +------------------------------------+ 497 | Original transport Payload | 498 +------------------------------------+ 499 | Source FEC Payload ID | 500 +------------------------------------+ 502 Figure 2: Structure of the FEC packet format for FEC Source packets 504 The IP and transport header fields MUST be identical to those of the 505 original source packet. The Original transport Payload field MUST be 506 identical to the transport payload of the original source packet. 507 The transport payload of the FEC Source packet MUST consist of the 508 Original Transport Payload followed by the Source FEC Payload ID 509 field, if required. 511 The Source FEC Payload ID field contains information required to 512 associate the source packet with a source block and for the operation 513 of the FEC algorithm and defined by the FEC Scheme. The format of 514 the Source FEC Payload ID field is defined by the FEC Scheme. Note 515 that in the case that the FEC Scheme or CDP defines a means to derive 516 the Source FEC Payload ID from other information in the packet (for 517 example the a sequence number of some kind used by the application 518 protocol), then the Source FEC Payload ID field is not included in 519 the packet. In this case the original source packet and FEC Source 520 Packet are identical. 522 Note: The Source FEC Payload ID is placed at the end of the packet so 523 that in the case that Robust Header Compression [3] or other header 524 compression mechanisms are used and in the case that a ROHC profile 525 is defined for the protocol carried within the transport payload (for 526 example RTP), then ROHC will still be applied for the FEC Source 527 packets. 529 6.4. Packet Format for FEC Repair packets 531 The packet format for FEC Repair packets is shown in Figure 3. The 532 transport payload consists of a Repair FEC Payload ID field followed 533 by repair data generated in the FEC encoding process. 535 +------------------------------------+ 536 | IP header | 537 +------------------------------------+ 538 | Transport header | 539 +------------------------------------+ 540 | Repair FEC Payload ID | 541 +------------------------------------+ 542 | Repair Symbols | 543 +------------------------------------+ 545 Figure 3: Packet format for repair packets 547 The Repair FEC Payload ID field contains information required for the 548 operation of the FEC algorithm. This information is defined by the 549 FEC Scheme. The format of the Repair FEC Payload ID field is defined 550 by the FEC Scheme. 552 6.5. FEC Framework Configuration Information 554 The FEC Framework Configuration Information is information that the 555 FEC Framework needs in order to apply FEC protection to the trasport 556 flows. A complete Content Delivery Protocol specification that uses 557 the framework specified here MUST include details of how this 558 information is derived and communicated between sender and receiver. 560 The FEC Framework Configuration Information includes identification 561 of a number of packet flows. For example, in the case of UDP, each 562 packet flow is uniquely identified by a tuple { Source IP Address, 563 Destination IP Address, Source UDP port, Destination UDP port }. 565 A single instance of the FEC Framework provides FEC protection for 566 all packets of a specified set of source packet flows, by means of 567 one or more packet flows consisting of repair packets. The FEC 568 Framework Configuation Information includes, for each instance of the 569 FEC Framework: 571 1. Identification of the packet flow(s) carrying FEC Repair 572 packets, known as the FEC repair flow(s). 574 2. For each source packet flow protected by the FEC repair 575 flow(s): 577 a. Identification of the packet flow carrying source packets. 579 b. An integer identifier, between 0 and 255, for this flow. 580 This identifier MUST be unique amongst all source packet flows 581 which are protected by the same FEC repair flow. 583 3. The FEC Encoding ID, identifying the FEC Scheme 585 4. An opaque container for FEC-Scheme-specific information 587 Multiple instances of the FEC Framework, with separate and 588 independent FEC Framework Configuration Information, may be present 589 at a sender or receiver. A single instance of the FEC Framework 590 protects all packets of all the source packet flows identified in (2) 591 above i.e. all packets on those flows MUST be FEC Source packets as 592 defined in Section 6.3. A single source packet flow MUST NOT be 593 protected by more than one FEC Framework instance. 595 A single FEC repair flow provides repair packets for a single 596 instance of the FEC Framework. Other packets MUST NOT be sent within 597 this flow i.e. all packets in the FEC repair flow MUST be FEC repair 598 packets as defined in Section 6.4 and MUST relate to the same FEC 599 Framework instance. 601 6.6. FEC Scheme requirements 603 In order to be used with this framework, an FEC Scheme MUST: 605 - use a systematic FEC code 607 - be based on discrete source blocks 609 Editor's note: This section requires expansion to define more 610 explicitly the things an FEC Scheme must specify, along the lines 611 of the FEC Building Block. 613 7. Transport Protocols 615 The following transport protocols are supported: 617 o User Datagram Protocol (UDP) 619 o Datagram Congestion Control Protocol (DCCP) 621 Editor's note: This section will contain transport-specific 622 considerations, if any. 624 8. Session Description Protocol elements 626 This section defines Session Descrption Protocol elements which MAY 627 be used by Content Delivery Protocols that make use of this framework 628 to communicate the FEC Framework Configuration Information. 630 NOTE: It is for further discussion whether these SDP elements 631 should be defined here or in the context of a specific and 632 complete Content Delivery Protocol specification for streaming. 634 This specification defines a class of new Transport Protocol 635 identifiers for use in SDP media descriptions. For all existing 636 identifiers this specification defines the identifier 'udp/ 637 fec/'. This identifier may be used as the Transport Protocol 638 identifier for a media description for source data to indicate that 639 the FEC Source packet format defined in Section 6.3 is used, with the 640 original transport payload field formated according to . 642 Note that in the case of an FEC Scheme in which the Source FEC 643 Payload ID field is not used, then the original Transport Protocol 644 identifier MAY be used to support interoperability with receivers 645 which do not support FEC at all, whilst also providing FEC protection 646 for those receivers which support it. 648 A further Transport Protocol identifier, 'udp/fec', is defined to 649 indicate the the FEC Repair Packet format defined in Section 6.4. 651 This specification describes the use of SDP attributes defined in [6] 652 and the FEC grouping semantics defined in [7] to provide the FEC 653 Framework Configuration Information. The 'fec-declaration' attribute 654 may be used at either the session or media layer to declare a local 655 identifier for a set of FEC parameters. This local identifier can 656 then be referenced in the other attributes. This avoids duplication 657 of parameter declarations within the SDP. The 'fec' parameter is 658 used on the media level to associate a media description with a 659 previous FEC parameter declaration. Finally, the 'FEC' grouping 660 attribute semantics is used to associate together source and repair 661 flows and assign UDP flow identifiers to be used in the source block 662 construction. 664 Mechanisms for communicating the corresponance between source flows 665 and the Flow Identifiers require further discussion. 667 8.1. udp/fec/ transport protocol identifier 669 tbc 671 8.2. udp/fec transport protocol identifier 673 tbc 675 8.3. fec-declaration attribute 677 See [6]. 679 8.4. fec-oti-extension attribute 681 See [6]. 683 8.5. fec attribute 685 See [6]. 687 8.6. FEC media grouping semantics 689 This attribute is used to group source flows and the single repair 690 flow that protects them as described in [7] with the following 691 additional requirements: 693 The media components grouped by an instance of the FEC grouping 694 attribute MUST include exactly one component with the udp/fec 695 protocol identifier. 697 The media components grouped by an instance of the FEC grouping 698 attribute MUST include at least one and MAY include more than one 699 source media stream with protocol identifier udp/fec/, 700 where is a valid protocol identifier registered with IANA. 702 In the case of an FEC Scheme which defines an FEC Payload ID field 703 of zero length, then the media components grouped by an instance 704 of the FEC grouping attribite MAY include source media streams 705 with protocol identified udp/, where is a valid 706 protocol identifier registered with IANA. 708 8.7. SDP example 710 tbc 712 9. Congestion Control 714 This section starts with a informative section on the motivation of 715 the normative requirements for congestion control, which are spelled 716 out in Section 9.1. 718 Informative Note: The enforcement of Congestion Control (CC) 719 principles has gained a lot of momentum in the IETF over the 720 recent years. While the need of CC over the open Internet is 721 unquestioned, and the goal of TCP friendliness is generally agreed 722 for most (but not all) applications, the subject of congestion 723 detection and measurement in heterogenous networks can hardly be 724 considered as solved. Most congestion control algorithms detect 725 and measure congestion by taking (primarily or exclusively) the 726 packet loss rate into account. This appears to be inappropriate 727 in environments where a large percentage of the packet losses are 728 the result link-layer errors and independent of the network load. 729 Note that such environments exist in the "open Internet", as well 730 as in "closed" IP based networks. An example for the former would 731 be the use of IP/UDP/RTP based streaming from an Internet- 732 connected streaming server to a device attached to the Internet 733 using cellular technology. 735 The authors of this draft are primarily interested in applications 736 where the application reliability requirements and end-to-end 737 reliability of the network differ, such that it warrants higher 738 layer protection of the packet stream - for example due to the 739 presence of unreliable links in the end-to-end path - and where 740 real-time, scalability or other constraints prohibit the use of 741 higher layer (transport or application) feedback. A typical 742 example for such applications is multicast and broadcast streaming 743 or multimedia transmission over heterogenous networks. In other 744 cases, application reliability requirements may be so high that 745 the required end-to-end reliability is difficult to achieve even 746 over wired networks. Furthermore the end-to-end network 747 reliability may not be known in advance. 749 This FEC framework is not proposed, nor intended, as a QoS 750 enhancement tool to combat losses resulting from highly congested 751 networks. It should not be used for such purposes. 753 In order to prevent such mis-use, standardization could be left to 754 bodies most concerned with the problem described above. However, 755 the IETF defines base standards used by several bodies, including 756 DVB, 3GPP, 3GPP2, all of which appear to share the environment and 757 the problem described. 759 Alternatively, a clear applicability statement could be used - for 760 example restricting use of the framework to networks with wireless 761 links. However, there may be applications where the use of FEC 762 may be justified to combat congestion-induced packet losses - 763 particularly in lightly loaded networks, where congestion is the 764 result of relatively rare random peaks in instantaneous traffic 765 load - thereby intentionally violating congestion control 766 principles. One possible example for such an application could be 767 a no-matter-what, brute-force FEC protection of traffic generated 768 as an emergency signal. 770 We propose a third approach, which is to require at a minimum that 771 the use of this framework with any given application, in any given 772 environment, does not cause congestion issues which the 773 application alone would not itself cause i.e. the use of this 774 framework must not make things worse. 776 Taking above considerations into account, the normative text of 777 this section implements a small set of constraints for the FEC, 778 which are mandatory for all senders compliant with this FEC 779 framework. Further restrictions may be imposed for certain 780 Content Delivery Protocols. In this it follows the spirit of the 781 congestion control section of RTP and its Audio-Visual Profile 782 (RFC3550/STD64 and RFC3551/STD65). 784 One of the constraints effectively limits the bandwidth for the 785 FEC protected packet stream to be no more than roughly twice as 786 high as the original, non-FEC protected packet stream. This 787 disallows the (static or dynamic) use of excessively strong FEC to 788 combat high packet loss rates, which may otherwise be chosen by 789 naively implemented dynamic FEC-strength selection mechanisms. We 790 acknowledge that there may be a few exotic applications, e.g. IP 791 traffic from space-based senders, or senders in certain hardened 792 military devices, which would warrant a higher FEC strength. 793 However, in this specification we give preference to the overall 794 stability and network friendliness of the average application, and 795 for those a factor of 2 appears to be appropriate. 797 A second constraint requires that the FEC protected packet stream 798 be in compliance with the congestion control in use for the 799 application and network in question. 801 9.1. Normative requirements 803 The bandwidth of FEC Repair packet flows MUST NOT exceed the 804 bandwidth of the source packet flows being protected. In addition, 805 whenever the source packet flow bandwidth is adapted due to the 806 operation of congestion control mechanisms, the FEC repair packet 807 flow bandwidth MUST be similarly adapted. 809 10. Security Considerations 811 The application of FEC protection to a stream does not provide any 812 kind of security protection. 814 If security services are required for the stream, then they MUST 815 either be applied to the original source data before FEC protection 816 is applied, or to both the source and repair data, after FEC 817 protection has been applied. 819 If integrity protection is applied to source packets before FEC 820 protection is applied, and no further integrity protection is applied 821 to repair packets, then a denial of service attack is possible if an 822 attacker is in a position to inject fake repair packets. If received 823 by a receiver, such fake repair packets could cause incorrect FEC 824 decoding resulting in incorrect source packets being passed up to the 825 application protocol. Such incorrect packets would then be detected 826 by the source integrity protection and discarded, resulting in 827 partial or complete denial of service. Therefore, in such 828 environments, integrity protection MUST also be applied to the FEC 829 Repair packets, for example using IPsec. Receivers MUST also verify 830 the integrity of source packets before including the source data into 831 the source block for FEC purposes. 833 It is possible that multiple streams with different confidentiality 834 requirements (for example, the streams may be visible to different 835 sets of users) can be FEC protected by a single repair stream. This 836 scenario is not recommended, since resources will be used to 837 distribute and decode data which cannot then be decrypted by at least 838 some receivers. However, in this scenario, confidentiality 839 protection MUST be applied before FEC encoding of the streams, 840 otherwise repair data may be used by a receiver to decode unencrypted 841 versions of source streams which they do not have permissionions to 842 view. 844 11. IANA Considerations 846 tbc 848 12. Acknowledgments 850 This document is based in large part on [8] and so thanks are due to 851 the additional authors of that document, Mike Luby, Magnus Westerlund 852 and Stephan Wenger. That document was in turn based on the FEC 853 streaming protocol defined by 3GPP in [9] and thus thanks are also 854 due to the participants in 3GPP TSG SA working group 4. 856 13. References 858 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 859 Levels", BCP 14, RFC 2119, March 1997. 861 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 862 Specifications: ABNF", RFC 2234, November 1997. 864 [3] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 865 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, 866 Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 867 Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): 868 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 869 RFC 3095, July 2001. 871 [4] Watson, M., "Forward Error Correction (FEC) Building Block", 872 draft-ietf-rmt-fec-bb-revised-04 (work in progress), 873 September 2006. 875 [5] Handley, M., "SDP: Session Description Protocol", 876 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 878 [6] Mehta, H., "SDP Descriptors for FLUTE", 879 draft-mehta-rmt-flute-sdp-05 (work in progress), January 2006. 881 [7] Li, A., "FEC Grouping Semantics in SDP", 882 draft-li-mmusic-fec-grouping-01 (work in progress), 883 September 2005. 885 [8] Watson, M., "Forward Error Correction (FEC) Streaming 886 Framework", draft-watson-tsvwg-fec-sf-00 (work in progress), 887 July 2005. 889 [9] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols 890 and codecs", 3GPP TS 26.346, April 2005. 892 Author's Address 894 Mark Watson 895 Digital Fountain 896 39141 Civic Center Drive 897 Suite 300 898 Fremont, CA 94538 899 U.S.A. 901 Email: mark@digitalfountain.com 903 Full Copyright Statement 905 Copyright (C) The Internet Society (2006). 907 This document is subject to the rights, licenses and restrictions 908 contained in BCP 78, and except as set forth therein, the authors 909 retain all their rights. 911 This document and the information contained herein are provided on an 912 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 913 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 914 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 915 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 916 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 917 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 919 Intellectual Property 921 The IETF takes no position regarding the validity or scope of any 922 Intellectual Property Rights or other rights that might be claimed to 923 pertain to the implementation or use of the technology described in 924 this document or the extent to which any license under such rights 925 might or might not be available; nor does it represent that it has 926 made any independent effort to identify any such rights. Information 927 on the procedures with respect to rights in RFC documents can be 928 found in BCP 78 and BCP 79. 930 Copies of IPR disclosures made to the IETF Secretariat and any 931 assurances of licenses to be made available, or the result of an 932 attempt made to obtain a general license or permission for the use of 933 such proprietary rights by implementers or users of this 934 specification can be obtained from the IETF on-line IPR repository at 935 http://www.ietf.org/ipr. 937 The IETF invites any interested party to bring to its attention any 938 copyrights, patents or patent applications, or other proprietary 939 rights that may cover technology that may be required to implement 940 this standard. Please address the information to the IETF at 941 ietf-ipr@ietf.org. 943 Acknowledgment 945 Funding for the RFC Editor function is provided by the IETF 946 Administrative Support Activity (IASA).