idnits 2.17.1 draft-ietf-rmt-fec-bb-revised-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1141. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1154. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (April 18, 2007) is 6180 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) == Missing Reference: '0' is mentioned on line 974, but not defined == Missing Reference: '255' is mentioned on line 990, but not defined == Missing Reference: '128' is mentioned on line 990, but not defined == Missing Reference: '127' is mentioned on line 974, but not defined ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3452 (ref. '3') (Obsoleted by RFC 5052, RFC 5445) -- Obsolete informational reference (is this intentional?): RFC 3926 (ref. '8') (Obsoleted by RFC 6726) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast M. Watson 3 Internet-Draft M. Luby 4 Obsoletes: 3452 (if approved) L. Vicisano 5 Intended status: Standards Track Digital Fountain 6 Expires: October 20, 2007 April 18, 2007 8 Forward Error Correction (FEC) Building Block 9 draft-ietf-rmt-fec-bb-revised-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 20, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes how to use Forward Error Correction (FEC) 43 codes to efficiently provide and/or augment reliability for bulk data 44 transfer over IP multicast. This document defines a framework for 45 the definition of the information that needs to be communicated in 46 order to use an FEC code for bulk data transfer, in addition to the 47 encoded data itself, and for definition of formats and codes for 48 communcation of that information. Both information communicated with 49 the encoded data itself and information that needs to be communicated 50 'out-of-band' are considered. The procedures for specifying new FEC 51 codes, defining the information communication requirements associated 52 with those codes and registering them with the Internet Assigned 53 Numbers Authority (IANA) are also described. The requirements on 54 Content Delivery Protocols which wish to use FEC codes defined within 55 this framework are also defined. The companion document titled, "The 56 Use of Forward Error Correction (FEC) in Reliable Multicast" 57 describes some applications of FEC codes for delivering content. 58 This document obsoletes RFC3452. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 5 64 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 65 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 67 6. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. FEC Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.2. FEC Object Transmission Information . . . . . . . . . . . 13 70 6.2.1. Transport of FEC Object Transmission Information . . . 14 71 6.2.2. Opacity of FEC Object Transmission Information . . . . 15 72 6.2.3. Mandatory FEC Object Transmission Information 73 elements . . . . . . . . . . . . . . . . . . . . . . . 15 74 6.2.4. Common FEC Object Transmission Information elements . 16 75 6.2.5. Scheme-specific FEC Object Transmission 76 Information element . . . . . . . . . . . . . . . . . 17 77 6.3. FEC Payload ID . . . . . . . . . . . . . . . . . . . . . . 17 78 7. FEC scheme specifications . . . . . . . . . . . . . . . . . . 19 79 8. CDP specifications . . . . . . . . . . . . . . . . . . . . . . 22 80 9. Common algorithms . . . . . . . . . . . . . . . . . . . . . . 23 81 9.1. Block partitioning algorithm . . . . . . . . . . . . . . . 23 82 9.1.1. First Step . . . . . . . . . . . . . . . . . . . . . . 23 83 9.1.2. Second step . . . . . . . . . . . . . . . . . . . . . 24 84 10. Requirements from other building blocks . . . . . . . . . . . 25 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 12.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 27 88 13. Changes from RFC3452 . . . . . . . . . . . . . . . . . . . . . 29 89 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 91 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 92 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 94 Intellectual Property and Copyright Statements . . . . . . . . . . 33 96 1. Introduction 98 This document describes how to use Forward Error Correction (FEC) 99 codes to provide support for reliable delivery of content within the 100 context of a Content Delivery Protocol (CDP). This document 101 describes a building block as defined in [10], specifically Section 102 4.2 of that document and follows the general guidelines provided in 103 [5]. 105 The purpose of this building block is to define a framework for 106 forward error correction such that: 108 1. CDPs can be designed to operate with a range of different FEC 109 codes/schemes, without needing to know details of the specific 110 FEC code/scheme that may be used 112 2. FEC schemes can be designed to operate with a range of different 113 CDPs, without needing to know details of the specific CDPs 115 Note that a 'CDP' in the context of this document may consist of 116 several distinct protocol mechanisms and may support any kind of 117 application requiring reliable transport - for example object 118 delivery and streaming applications. 120 This document also provides detailed guidelines on how to write an 121 RFC for an FEC scheme corresponding to a new FEC Encoding ID (for 122 both Fully-Specified and Under-Specified FEC Schemes - see 123 Section 4). 125 RFC3452 [3], which is obsoleted by this document, contained a 126 previous version, which was published in the "Experimental" category. 127 RFC3452 was published as an Experimental RFC in part due to the lack 128 at that time of specified congestion control strategies suitable for 129 use with Reliable Multicast protocols. 131 This Proposed Standard specification is thus based on RFC3452 [3] 132 updated according to accumulated experience and growing protocol 133 maturity since the publication of RFC3452 [3]. Said experience 134 applies both to this specification itself and to congestion control 135 strategies related to the use of this specification. 137 The differences between RFC3452 [3] and this document listed in 138 Section 13 140 2. Definitions/Abbreviations 142 Object: An ordered sequence of octets to be transferred by the 143 transport protocol. For example, a file or stream. 145 Symbol: A unit of data processed by the Forward Error Correction 146 code. A symbol is always considered as a unit i.e. it is either 147 completely received or completely lost. 149 Source symbol: A symbol containing information from the original 150 object. 152 Repair symbol: A symbol containing information generated by the FEC 153 code which can be used to recover lost source symbols. 155 Encoding symbol: A source symbol or a repair symbol. 157 Encoder: The FEC scheme specific functions required to transform a 158 object into FEC encoded data. i.e. the functions that produce 159 repair symbols using source symbols. 161 Decoder: The FEC scheme specific functions required to transform 162 received FEC encoded data into a copy of the original object 164 Receiver: A system supporting the receiving functions of a CDP and 165 FEC scheme according to this specification 167 Sender: A system supporting the sending functions of a CDP and FEC 168 scheme according to this specification 170 Source Block: A part of the object formed from a subset of the 171 object's source symbols 173 CDP: Content Delivery Protocol 175 FEC: Forward Error Correction 177 3. Requirements notation 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [1]. 183 4. Rationale 185 An FEC code, in the general sense, is a valuable basic component of 186 any CDP that is to provide reliable delivery of an object. Using FEC 187 codes is effective in the context of IP multicast and reliable 188 delivery because FEC encoding symbols can be useful to all receivers 189 for reconstructing an object even when the receivers have received 190 different encoding symbols. Furthermore, FEC codes can ameliorate or 191 even eliminate the need for feedback from receivers to senders to 192 request retransmission of lost packets. 194 Central to this document is the concept of an 'FEC Scheme', which we 195 distinguish from the concept of an 'FEC code' or 'FEC algorithm'. An 196 FEC scheme defines the ancillary information and procedures which, 197 combined with an FEC code or algorithm specification, fully define 198 how the FEC code can be used with CDPs. An FEC scheme may be 199 associated with a single standardised FEC code (A 'Fully-Specified' 200 FEC scheme) or may be applicable to many FEC codes (An 'Under- 201 Specified' FEC scheme). 203 This document describes a framework for the definition of FEC 204 schemes. Definition of actual FEC schemes is outside the scope of 205 this document. This document also defines requirements for reliable 206 CDPs that make use of FEC schemes. Any such CDP which is compliant 207 to the requirements specified in this document can make use of any 208 FEC scheme which is defined within the framework described here. 209 Note that FEC schemes may place restrictions on the types of CDP they 210 are intended to be used with. For example, some FEC schemes may be 211 specific to particular types of application, such as file delivery or 212 streaming. 214 The goal of the FEC building block is to describe functionality 215 directly related to FEC codes that is common to all reliable CDPs and 216 to all FEC schemes, and to leave out any additional functionality 217 that is specific to particular CDPs or particular FEC schemes. The 218 primary functionality described in this document that is common to 219 all such CDPs that use FEC codes is the definition and transport of 220 three kinds of information from sender to receiver(s): encoding 221 symbols themselves, ancillary information associated with encoding 222 symbols (or groups of such symbols, such as the group of symbols in a 223 single packet, or the group of symbols related to a single source 224 block) and ancillary information associated with the whole object 225 being transferred. It is important to note that this an information 226 is only required by the receiver if one or more of the encoding 227 symbols to which it relates are received. 229 This document for example does not describe how receivers may request 230 transmission of particular encoding symbols for an object. This is 231 because although there are CDPs where requests for transmission are 232 of use, there are also CDPs that do not require such requests. 234 The companion document [4] should be consulted for a full explanation 235 of the benefits of using FEC codes for reliable content delivery 236 using IP multicast. FEC codes are also useful in the context of 237 unicast, and thus the scope and applicability of this document is not 238 limited to IP multicast. 240 5. Applicability Statement 242 The FEC building block does not provide any support for congestion 243 control. Any complete multicast CDP MUST provide congestion control 244 that conforms to [6], in particular Section 3.2 of that document. 245 Thus, congestion control MUST be provided by another building block 246 when the FEC building block is used in a CDP. 248 A more complete description of the applicability of FEC codes can be 249 found in the companion document [4]. 251 6. Functionality 253 This section describes FEC information that is either to be sent in 254 packets also containing FEC encoding symbols or 'out-of-band'. The 255 FEC information is associated with transmission of encoding symbols 256 related to a particular object. There are three classes of packets 257 that may contain FEC information: data packets, session-control 258 packets and feedback packets. They generally contain different kinds 259 of FEC information. Note that some CDPs may not use session-control 260 or feedback packets. 262 Data packets may sometimes serve as session-control packets as well; 263 both data and session-control packets generally travel downstream 264 from the sender towards receivers and are sent to a multicast channel 265 or to a specific receiver using unicast. Session-control packets may 266 additionally travel upstream from receivers to senders. 268 As a general rule, feedback packets travel upstream from receivers to 269 the sender. Sometimes, however, they might be sent to a multicast 270 channel or to another receiver or to some intermediate node or 271 neighboring router that provides recovery services. 273 This document specifies both the FEC information that must be carried 274 in data packets and the FEC information that must be communicated 275 from sender to receiver(s) either out-of-band or in data packets. 276 Specification of protocol mechanisms for transporting this 277 information, for example field and packet formats, is out of scope of 278 this document. Instead, this document specifies at a higher level 279 the information that must be communicate and provides detailed 280 requirements for FEC Scheme and Content Delivery Protocol 281 specifications, which are where the detailed field and packet formats 282 should be defined. 284 FEC information is classified as follows: 286 1. FEC information associated with an object 288 This is information that is essential for the FEC decoder to 289 decode a specific object. An example of this information is the 290 identity of the FEC scheme that is being used to encode the 291 object, in the form of the FEC Encoding ID. The FEC Encoding ID 292 is described further below. This information may also include 293 FEC scheme-specific parameters for the FEC decoder. 295 2. FEC information associated with specific encoding symbols for an 296 object 297 This is information which is associated with one or more encoding 298 symbols and is thus needed by the decoder whenever one or more of 299 those encoding symbols have been received. Depending on the FEC 300 scheme, information may be associated with individual symbols 301 and/or with groups of symbols. One common such grouping is the 302 group of symbols included within a single packet. Many FEC 303 schemes also segment the object being encoded into multiple 304 'source blocks', each of which is processed independently for FEC 305 purposes. Information about each source block is another type of 306 information associated with a group of encoding symbols, this 307 time the group of symbols which are related to a given source 308 block. 310 Two 'containers' are provided for communicating the FEC information 311 described above, but there is not necessarily a one-to-one 312 correspondence between the class of FEC information and the mechanism 313 used. The two mechanisms are: 315 a. FEC Object Transmission Information 317 CDPs must provide a reliable mechanism for communicating certain 318 FEC information from sender to receiver(s). This information is 319 known as 'FEC Object Transmission Information' and its contents 320 depend on the particular FEC scheme. It includes all information 321 of the first class above and may include information of the 322 second class. The FEC Object Transmission Information can be 323 sent to a receiver within the data packet headers, within session 324 control packets, or by some other means. 326 b. FEC Payload ID 328 CDPs must provide a mechanism for communicating information which 329 identifies (for FEC purposes) the encoding symbols carried by a 330 packet. This information is known as the FEC Payload ID and its 331 contents depend on the FEC scheme. It includes only information 332 of the second class above. A data packet that carries encoding 333 symbols MUST include an FEC Payload ID. 335 6.1. FEC Schemes 337 Two types of FEC scheme are defined by this document: 'Fully- 338 Specified' FEC schemes and 'Under-Specified' FEC schemes. An FEC 339 scheme is a Fully-Specified FEC scheme if the encoding scheme is 340 formally and Fully-Specified, in a way that independent implementors 341 can implement both encoder and decoder from a specification that is 342 an IETF RFC. 344 It is possible that an FEC scheme may not be a Fully-Specified FEC 345 scheme, because either a specification is simply not available or a 346 party exists that owns the encoding scheme and is not willing to 347 disclose the algorithm or specification. We refer to such an FEC 348 encoding scheme as an Under-Specified FEC scheme. 350 FEC schemes are identified by an FEC Encoding ID, which is an integer 351 identifier assigned by IANA. The FEC Encoding ID allows receivers to 352 select the appropriate FEC decoder. The value of the FEC Encoding ID 353 MUST be the same for all transmission of encoding symbols related to 354 a particular object, but MAY vary across different transmissions of 355 encoding symbols about different objects, even if transmitted to the 356 same set of multicast channels and/or using a single upper-layer 357 session. 359 The FEC Instance ID is an integer value that identifies a specific 360 instance of an Under-Specified FEC scheme. This value is not used 361 for Fully-Specified FEC schemes. The FEC Instance ID is scoped by 362 the FEC Encoding ID, and FEC Instance ID values are subject to IANA 363 registration. 365 The FEC Encoding ID for Fully-Specified FEC Schemes and both the FEC 366 Encoding ID and FEC Instance ID for Under-Specified FEC Schemes are 367 essential for the decoder to decode an object and thus are part of 368 the FEC Object Transmission Information. 370 The following requirements apply to all FEC schemes, whether Fully- 371 Specified or Under-Specified: 373 o The type, semantics and an encoding format for the FEC Payload ID 374 and the FEC Object Transmission Information MUST be defined. 376 o A value for the FEC Encoding ID MUST be reserved and associated 377 with the types, semantics and encoding format of the FEC Payload 378 ID and the FEC Object Transmission Information. 380 The specification for an Under-Specified FEC Scheme MAY allocate a 381 sub-field within the Scheme-specific FEC Object Transmission 382 Information element which is for instance-specific information. Each 383 specific instance of the Under-Specified FEC Scheme may then use this 384 field in an instance-specific way. The FEC scheme should define the 385 scheme-specific FEC Object Transmission Information element in such a 386 way that receivers that do not support the received FEC Instance ID 387 can still parse and interpret the scheme-specific FEC Object 388 Transmission Information element with the exception of the instance- 389 specific field. 391 An already defined Under-Specified FEC Scheme (i.e. FEC Encoding ID 392 value) MUST be reused if the associated FEC Payload ID and FEC Object 393 Transmission Information have the required fields and encoding 394 formats for a new Under-Specified FEC scheme instance. 396 An instance of an Under-Specified FEC scheme is fully identified by 397 the tuple (FEC Encoding ID, FEC Instance ID). The tuple MUST 398 identify a single scheme instance that has at least one 399 implementation. The party that owns this tuple MUST be able to 400 provide information on how to obtain the Under-Specified FEC scheme 401 instance identified by the tuple, e.g., a pointer to a publicly 402 available reference-implementation or the name and contacts of a 403 company that sells it, either separately or embedded in another 404 product. 406 This specification reserves the range 0-127 for the values of FEC 407 Encoding IDs for Fully-Specified FEC schemes and the range 128-255 408 for the values of Under-Specified FEC schemes. 410 6.2. FEC Object Transmission Information 412 The FEC Object Transmission Information contains information which is 413 essential to the decoder in order to decode the encoded object. It 414 may also contain information which is required to decode certain 415 groups of encoding symbols, for example individual Source Blocks 416 within the object. This information is communicated reliably by the 417 CDP to the receiver(s) as described in Section 8. 419 The FEC Object Transmission Information may consist of several 420 elements and each element may be one of three types, as follows: 422 Mandatory: These elements are defined in this specification and are 423 each mandatory for at least one of the two types of FEC Scheme. 424 Each FEC scheme specifies how the values of the Mandatory FEC 425 Object Transmission Information elements are determined and each 426 CDP specifies how this information is encoded and reliably 427 communicated to the receiver(s). The Mandatory FEC Object 428 Transmission Information includes the identification of the FEC 429 Scheme, which is needed by the receiver to determine whether it 430 supports the FEC Scheme. 432 Common: These elements are defined in this specification and are 433 optional to be used by an FEC scheme. Each FEC scheme specifies 434 which of the Common FEC Object Transmission Information elements 435 it uses and how the values of these elements are determined. 437 Scheme-specific: An FEC scheme may specify a single Scheme-specific 438 FEC Object Transmission Information element. The FEC scheme 439 specifies the type, semantics and encoding format of the Scheme- 440 specific FEC Object Transmission Information element. The 441 resulting octet-string is known as the "encoded Scheme-specific 442 FEC Object Transmission Information". Each CDP specifies how the 443 encoded Scheme-specific FEC Object Transmission is communicated 444 reliably to the receiver(s) i.e. exactly where it shall be carried 445 within packets of the CDP. Note that although from the point of 446 view of this specification and of CDPs there is only a single 447 Scheme-specific FEC Object Transmission Information element, the 448 FEC scheme may specify this element to contain multiple distinct 449 pieces of information. 451 Each FEC scheme specifies an encoding format for the Common and 452 Scheme-specific FEC Object Transmission Information. Each CDP must 453 specify at least one of the following: 455 1. A means to reliably communicate the Common FEC Object 456 Transmission Information elements to the receiver(s) using the 457 encoding format defined by the FEC scheme. 459 2. An alternative, CDP specific, encoding format for each of the 460 Common FEC Object Transmission Information elements. 462 The Mandatory and Common FEC Object Transmission Information elements 463 are defined in the sections below. 465 6.2.1. Transport of FEC Object Transmission Information 467 It is the responsibility of the CDP to reliably transport the FEC 468 Object Transmission Information to the receiver(s). 470 It is important to note that the encoding format of the Mandatory FEC 471 Object Transmission Information elements (The FEC Encoding ID) is 472 defined by the CDP. This is so that the receiver can identify the 473 FEC Scheme to be used for interpreting the remaining FEC Object 474 Transmission Information elements. All CDPs must define encoding 475 formats for the Mandatory FEC Object Transmission Information 476 element. 478 Common FEC Object Transmission Information elements can be 479 transported in two different ways: (a) the FEC Scheme defines an 480 encoding format for the Common FEC Object Transmission Information 481 elements that it uses and the CDP transports this encoded data block, 482 or (b) the CDP defines an encoding format for each Common FEC Object 483 Transmission Information element and transports the information in 484 this format. 486 An FEC Scheme MUST define an encoding format for the Common FEC 487 Object Transmission Information elements that it uses. The resulting 488 octet string is known as the "encoded Common FEC Object Transmission 489 Information". A CDP MAY define individual encoding formats for each 490 of the Common FEC Object Transmission Information elements. The 491 choice of which way the Common FEC Object Transmission Information 492 elements shall be transported, (a) or (b), is made by the Content 493 Delivery Protocol and a particular method SHOULD be defined in the 494 Content Delivery Protocol specification. Note that a CDP may provide 495 support for one or both options. 497 In the case that the CDP uses the encoding format specified by the 498 FEC scheme then it may simply concatenate the encoded Common FEC 499 Object Transmission Information and the encoded Scheme-specific FEC 500 Object Transmission Information or it may carry each in a separate 501 field or wrapper within the CDP. In the former case, the 502 concatenated octet-string is known as the encoded FEC Object 503 Transmission Information. The FEC scheme must define the encoding 504 format for the Common FEC Object Transmission Information elements 505 that it uses in such a way that the length of each element is either 506 fixed or can be determined from the encoded data itself. 508 The encoding format of the Scheme-specific FEC Object Transmission 509 Information element is defined by the FEC scheme. CDPs specify only 510 how the resulting octet sequence is communicated. As with the 511 encoding format for the Common FEC Object Transmission Information 512 elements the length of the Scheme-specific FEC Object Transmission 513 Information must either be fixed or it must be possible to determine 514 the length from the encoded data itself. 516 6.2.2. Opacity of FEC Object Transmission Information 518 The Scheme-specific FEC Object Transmission Information element is 519 opaque to the CDP in the sense that inspecting the contents of this 520 element can only be done if FEC scheme-specific logic is included in 521 the CDP. 523 Any encoding formats defined by the FEC scheme for the Common FEC 524 Object Transmission Information elements are also opaque to the CDP 525 in the same sense. 527 Any encoding formats defined by the CDP for the Common FEC Object 528 Transmission Information elements are not opaque in this sense, 529 although it must be considered that different FEC Schemes may use 530 different combinations of the Common FEC Object Transmission 531 Information elements. 533 6.2.3. Mandatory FEC Object Transmission Information elements 535 The Mandatory FEC Object Transmission Information element is: 537 FEC Encoding ID: an integer between 0 and 255 inclusive identifying 538 a specific FEC scheme (Fully-Specified or Under-Specified.) 540 6.2.4. Common FEC Object Transmission Information elements 542 The Common FEC Object Transmission Information elements are described 543 below. Note that with the exception of the FEC Instance ID, this 544 specification does not provide complete definitions of these fields. 545 Instead only aspects of the abstract type are defined. The precise 546 type and semantics are defined for each FEC scheme in the FEC scheme 547 specification. 549 FEC Instance ID: an integer between 0 and 65535 inclusive 550 identifying an instance of an Under-specifed FEC scheme 552 Transfer-Length: a non-negative integer indicating the length of the 553 object in octets 555 Encoding-Symbol-Length: a non-negative integer indicating the length 556 of each encoding symbol in octets 558 Maximum-Source-Block-Length: a non-negative integer indicating the 559 maximum number of source symbols in a source block 561 Max-Number-of-Encoding-Symbols: a non-negative integer indicating 562 the maximum number of encoding symbols (i.e. source plus repair 563 symbols in the case of a systematic code) 565 The FEC Instance ID MUST be used by all Under-specified FEC schemes 566 and MUST NOT be used by Fully-specified FEC Schemes. 568 FEC Schemes define the precise type of those of the above elements 569 that they use and in particular may restrict the value range of each 570 element. FEC Schemes also define an encoding format for the subset 571 of the above elements that they use. CDPs may also provide an 572 encoding format for each element in which case this encoding format 573 MUST be capable of representing values up to (2^^16)-1 in the case of 574 the FEC Instance ID, (2^^48)-1 in the case of the Transfer-Length and 575 up to (2^^32)-1 for the other elements. CDPs may additionally or 576 alternatively provide a mechanism to transport the encoded Common FEC 577 Object Transmission information defined by the FEC scheme. For 578 example, FLUTE [8] specifies an XML-based encoding format for these 579 elements, but can also transport FEC scheme-specific encoding formats 580 within the EXT-FTI LCT header extension. 582 6.2.5. Scheme-specific FEC Object Transmission Information element 584 The Scheme-specific FEC Object Transmission Information element may 585 be used by an FEC Scheme to communicate information which is 586 essential to the decoder which cannot adequately be represented 587 within the Mandatory or Common FEC Object Transmission Information 588 elements. 590 From the point of view of a CDP, the Scheme-specific FEC Object 591 Transmission Information element is an opaque, variable length, octet 592 string. The FEC Scheme defines the structure of this octet string, 593 which may contain multiple distinct elements. 595 6.3. FEC Payload ID 597 The FEC Payload ID contains information which indicates to the FEC 598 decoder the relationships between the encoding symbols carried by a 599 particular packet and the FEC encoding transformation. For example 600 if the packet carries source symbols then the FEC Payload ID 601 indicates which source symbols of the object are carried by the 602 packet. If the packet carries repair symbols, then the FEC Payload 603 ID indicates how those repair symbols were constructed from the 604 object. 606 The FEC Payload ID may also contain information about larger groups 607 of encoding symbols of which those contained in the packet are part. 608 For example, the FEC Payload ID may contain information about the 609 source block the symbols are related to. 611 The FEC Payload ID for a given packet is essential to the decoder if 612 and only if the packet itself is received. Thus it must be possible 613 to obtain the FEC Payload ID from the received packet. Usually, the 614 FEC Payload ID is simply carried explicitly as a separate field 615 within each packet. In this case the size of the FEC Payload ID 616 field SHOULD be a small fraction of the packet size. Some FEC 617 schemes may specify means for deriving the relationship between the 618 carried encoding symbols and the object implicitly from other 619 information within the packet, such as protocol headers already 620 present. Such FEC schemes could obviously only be used with CDPs 621 which provided the appropriate information from which the FEC Payload 622 ID could be derived. 624 The encoding format of the FEC Payload ID, including its size, is 625 defined by the FEC Scheme. CDPs specify how the FEC Payload ID is 626 carried within data packets i.e. the position of the FEC Payload ID 627 within the CDP packet format and the how it is associated with 628 encoding symbols. 630 FEC schemes for systematic FEC codes, that is, those codes in which 631 the original source data is included within the encoded data, MAY 632 specify two FEC Payload ID formats, one for packets carrying only 633 source symbols and another for packets carrying at least one repair 634 symbol. CDPs must include an indication of which of the two FEC 635 Payload ID formats is included in each packet if they wish to support 636 such FEC Schemes. 638 7. FEC scheme specifications 640 A specification for a new FEC scheme MUST include the following 641 things: 643 1. The FEC Encoding ID value that uniquely identifies the FEC 644 scheme. This value MUST be registered with IANA as described in 645 Section 12. 647 2. The type, semantics and encoding format of one or two FEC Payload 648 IDs. Where two FEC Payload ID formats are specified, then the 649 FEC scheme MUST be a systematic FEC code and one FEC Payload ID 650 format MUST be designated for use with packets carrying only 651 source symbols and the other FEC Payload ID format MUST be 652 designated for use with packets carrying at least one repair 653 symbol. 655 3. The type and semantics of the FEC Object Transmission 656 Information. The FEC Scheme MAY define additional restrictions 657 on the type (including value range) of the Common FEC Object 658 Transmission Information elements. 660 4. An encoding format for the Common FEC Object Transmission 661 Information elements used by the FEC Scheme. 663 Fully-Specified FEC schemes MUST further specify: 665 1. A full specification of the FEC code. 667 This specification MUST precisely define the valid FEC Object 668 Transmission Information values, the valid FEC Payload ID values 669 and the valid packet payload sizes for any given object (where 670 packet payload refers to the space - not necessarily contiguous - 671 within a packet dedicated to carrying encoding symbol octets). 673 Furthermore, given an object, valid values for each of the FEC 674 Object Transmission Information elements used by the FEC Scheme, 675 a valid FEC Payload ID value and a valid packet payload size, the 676 specification MUST uniquely define the values of the encoding 677 symbol octets to be included in the packet payload of a packet 678 with the given FEC Payload ID value. 680 A common and simple way to specify the FEC code to the required 681 level of detail is to provide a precise specification of an 682 encoding algorithm which, given an object, valid values for each 683 of the FEC Object Transmission Information elements used by the 684 FEC Scheme for the object, a valid FEC Payload ID and packet 685 payload length as input produces the exact value of the encoding 686 symbol octets as output. 688 2. A description of practical encoding and decoding algorithms. 690 This description need not be to the same level of detail as for 691 (1) above, however it must be sufficient to demonstrate that 692 encoding and decoding of the code is both possible and practical. 694 FEC scheme specifications MAY additionally define the following: 696 1. Type, semantics and encoding format of a Scheme-specific FEC 697 Object Transmission Information element. 699 Note that if an FEC scheme does not define a Scheme-specific FEC 700 Object Transmission Information then such an element MUST NOT be 701 introduced in future versions of the FEC Scheme. This requirement is 702 included to ensure backwards-compatibility of CDPs designed to 703 support only FEC Schemes which do not use the Scheme-specific FEC 704 Object Transmission Information element. 706 Whenever an FEC scheme specification defines an 'encoding format' for 707 an element, this must be defined in terms of a sequence of octets 708 which can be embedded within a protocol. The length of the encoding 709 format MUST either be fixed or it must be possible to derive the 710 length from examining the encoded octets themselves. For example, 711 the initial octets may include some kind of length indication. 713 FEC schemes SHOULD make use of the Common FEC Object Transmission 714 Information elements in preference to including information in a 715 Scheme-specific FEC Object Transmission Information element. 717 FEC scheme specifications SHOULD use the terminology defined in this 718 document and SHOULD follow the following format: 720 1. Introduction 723 725 2. Formats and Codes 727 2.1 FEC Payload ID(s) 730 2.2 FEC Object Transmission Information 732 2.2.1 Mandatory 735 2.2.2 Common 739 2.2.3 Scheme-Specific 743 3. Procedures 748 4. FEC code specification (for Fully-Specified FEC schemes only) 749 751 Specifications MAY include additional sections, for example, 752 examples. 754 Each FEC scheme MUST be specified independently of all other FEC 755 schemes; for example, in a separate specification or a completely 756 independent section of larger specification. 758 8. CDP specifications 760 A specification for a CDP that uses this building block MUST include 761 the following things: 763 1. Definitions of an encoding formats for the Mandatory FEC Object 764 Transmission Information element. 766 2. A means to reliably communicate the Mandatory FEC Object 767 Transmission Information element from sender to receiver(s) using 768 the encoding format defined in (1). 770 3. Means to reliably communicate the Common FEC Object Transmission 771 Information element from sender to receiver(s) using either or 772 both of (a) the encoding format defined by the FEC Scheme or (b) 773 encoding formats defined by the CDP 775 4. A means to reliably communicate the Scheme-specific FEC Object 776 Transmission Information element from sender to receiver(s) using 777 the encoding format of the Scheme-specific FEC Object 778 Transmission Information element defined by the FEC scheme. 780 5. A means to communicate the FEC Payload ID in association with a 781 data packet. Note that the encoding format of the FEC Payload ID 782 is defined by the FEC Scheme. 784 If option (b) of (3) above is used, then the CDP MUST specify an 785 encoding format for the Common FEC Object Transmission Information 786 elements. 788 CDPs MAY additionally specify the following things: 790 1. A means to indicate whether the FEC Payload ID within a packet is 791 encoded according to the format for packets including only source 792 symbols or according to the format for packets including at least 793 one repair symbol. 795 9. Common algorithms 797 This section describes certain algorithms which are expected to be 798 commonly required by FEC schemes or by CDPs. FEC Schemes and CDPs 799 SHOULD use these algorithms in preference to scheme or protocol 800 specific algorithms where appropriate. 802 9.1. Block partitioning algorithm 804 This algorithm computes a partitioning of a object into source blocks 805 so that all source blocks are as close to being equal length as 806 possible. A first number of source blocks are of the same larger 807 length, and the remaining second number of source blocks of the same 808 smaller length. 810 This algorithm is described in two steps, the second of which may be 811 useful in itself as an independent algorithm in some cases. In the 812 first step, the number of source symbols (T) and the number of source 813 blocks (N) are derived from the Object transfer length (L), Maximum 814 Source Block Length (B) and Symbol Length (E). 816 In the second step, the partitioning of the object is derived from 817 the number of source symbols (T) and the number of source blocks (N). 818 The partitioning is defined in terms of a first number of source 819 blocks (I), a second number of source blocks (N-I), the length of 820 each of the first source blocks (A_large) and the length of each of 821 the second source blocks (A_small). 823 The following notation is used in the description below: 825 ceil[x] denotes x rounded up to the nearest integer. 827 floor[x] denotes x rounded down to the nearest integer. 829 9.1.1. First Step 831 Input: 833 B -- Maximum Source Block Length, i.e., the maximum number of source 834 symbols per source block 836 L -- Transfer Length in octets 838 E -- Encoding Symbol Length in octets 840 Output: 842 T -- the number of source symbols in the object. 844 N -- The number of source blocks into which the object shall be 845 partitioned. 847 Algorithm: 849 1. The number of source symbols in the transport object is computed 850 as T = ceil[L/E]. 852 2. The transport object shall be partitioned into N = ceil[T/B] 853 source blocks. 855 9.1.2. Second step 857 Input: 859 T -- the number of source symbols in the object. 861 N -- The number of source blocks into which the object is 862 partitioned. 864 Output: 866 I -- the number of larger source blocks. 868 A_large -- the length of each of the larger source blocks in 869 symbols. 871 A_small -- the length of each of the smaller source blocks in 872 symbols. 874 Algorithm: 876 1. A_large = ceil[T/N] 878 2. A_small = floor[T/N] 880 3. I = T - A_small * N 882 Each of the first I source blocks then consists of A_large source 883 symbols, each source symbol is E octets in length. Each of the 884 remaining N-I source blocks consist of A_small source symbols, each 885 source symbol is E octets in length except that the last source 886 symbol of the last source block is L-((L-1)/E) rounded down to the 887 nearest integer)*E octets in length. 889 10. Requirements from other building blocks 891 The FEC building block does not provide any support for congestion 892 control. Any complete CDP MUST provide congestion control that 893 conforms to [6], and thus this MUST be provided by another building 894 block when the FEC building block is used in a CDP. 896 There are no other specific requirements from other building blocks 897 for the use of this FEC building block. However, any CDP that uses 898 the FEC building block may use other building blocks for example to 899 provide support for sending higher level session information within 900 data packets containing FEC encoding symbols. 902 11. Security Considerations 904 Data delivery can be subject to denial-of-service attacks by 905 attackers which send corrupted packets that are accepted as 906 legitimate by receivers. This is particularly a concern for 907 multicast delivery because a corrupted packet may be injected into 908 the session close to the root of the multicast tree, in which case 909 the corrupted packet will arrive at many receivers. This is 910 particularly a concern for the FEC building block because the use of 911 even one corrupted packet containing encoding data may result in the 912 decoding of an object that is completely corrupted and unusable. It 913 is thus RECOMMENDED that source authentication and integrity checking 914 are applied to decoded objects before delivering objects to an 915 application. For example, a SHA-1 hash [7] of an object may be 916 appended before transmission, and the SHA-1 hash is computed and 917 checked after the object is decoded but before it is delivered to an 918 application. Source authentication SHOULD be provided, for example 919 by including a digital signature verifiable by the receiver computed 920 on top of the hash value. It is also RECOMMENDED that a packet 921 authentication protocol such as TESLA [9] be used to detect and 922 discard corrupted packets upon arrival. Furthermore, it is 923 RECOMMENDED that Reverse Path Forwarding checks be enabled in all 924 network routers and switches along the path from the sender to 925 receivers to limit the possibility of a bad agent successfully 926 injecting a corrupted packet into the multicast tree data path. 928 Another security concern is that some FEC information may be obtained 929 by receivers out-of-band in a session description, and if the session 930 description is forged or corrupted then the receivers will not use 931 the correct protocol for decoding content from received packets. To 932 avoid these problems, it is RECOMMENDED that measures be taken to 933 prevent receivers from accepting incorrect session descriptions, 934 e.g., by using source authentication to ensure that receivers only 935 accept legitimate session descriptions from authorized senders. 937 12. IANA Considerations 939 Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA 940 registration. They are registered in the registry named "Reliable 941 Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs" 942 located at time of publication at: 943 http://www.iana.org/assignments/rmt-fec-parameters 945 FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding 946 IDs scope independent ranges of FEC Instance IDs. Only FEC Encoding 947 IDs that correspond to Under-Specified FEC schemes scope a 948 corresponding set of FEC Instance IDs. 950 The FEC Encoding ID and FEC Instance IDs are non-negative integers. 951 In this document, the range of values for FEC Encoding IDs is 0 to 952 255. Values from 0 to 127 are reserved for Fully-Specified FEC 953 schemes and Values from 128 to 255 are reserved for Under-Specified 954 FEC schemes, as described in more detail in Section 6.1. 956 12.1. Explicit IANA Assignment Guidelines 958 This document defines a name-space for FEC Encoding IDs named: 959 ietf:rmt:fec:encoding 961 The values that can be assigned within the "ietf:rmt:fec:encoding" 962 name-space are numeric indexes in the range [0, 255], boundaries 963 included. Assignment requests are granted on a "IETF Consensus" 964 basis as defined in [2]. Section 7 defines explicit requirements 965 that documents defining new FEC Encoding IDs should meet. 967 This document also defines a name-space for FEC Instance IDs named: 968 ietf:rmt:fec:encoding:instance 970 The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space 971 associated with the "ietf:rmt:fec:encoding" name-space. Each value 972 of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a 973 separate "ietf:rmt:fec:encoding:instance" sub-name-space that it 974 scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do 975 not scope a "ietf:rmt:fec:encoding:instance" sub-name-space. 977 The values that can be assigned within each "ietf:rmt:fec:encoding: 978 instance" sub-name-space are non-negative integers less than 65536. 979 Assignment requests are granted on a "First Come First Served" basis 980 as defined in [2]. The same value of "ietf:rmt:fec:encoding: 981 instance" can be assigned within multiple distinct sub-name-spaces, 982 i.e., the same value of "ietf:rmt:fec:encoding:instance" can be used 983 for multiple values of "ietf:rmt:fec:encoding". 985 Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST 986 provide the following information: 988 o The value of "ietf:rmt:fec:encoding" that scopes the "ietf:rmt: 989 fec:encoding:instance" sub-name-space. This must be in the range 990 [128, 255]. 992 o Point of contact information 994 o A pointer to publicly accessible documentation describing the 995 Under-Specified FEC scheme, associated with the value of "ietf: 996 rmt:fec:encoding:instance" assigned, and a way to obtain it (e.g., 997 a pointer to a publicly available reference-implementation or the 998 name and contacts of a company that sells it, either separately or 999 embedded in a product). 1001 It is the responsibility of the requestor to keep all the above 1002 information up to date. 1004 13. Changes from RFC3452 1006 This section lists the changes between the Experimental version of 1007 this specification, [3], and this version: 1009 o The requirements for definition of a new FEC Scheme and the 1010 requirements for specification of new Content Delivery Protocols 1011 which use FEC Schemes are made more explicit to permit independent 1012 definition of FEC Schemes and Content Delivery Protocols. 1014 o The definitions of basic FEC Schemes have been removed with the 1015 intention of publishing these separately. 1017 o The FEC Object Transmission Information is more explicitly defined 1018 and in particular three classes of FEC OTI (Mandatory, Common and 1019 Scheme-specific) are introduced to permit re-usable definition of 1020 explicit fields in Content Delivery Protocols to carry these 1021 elements. 1023 o FEC Schemes are required to specify a complete encoding for the 1024 FEC Object Transmission which can be carried transparently by 1025 Content Delivery protocols (instead of defining explicit 1026 elements). 1028 o The possibility for FEC Schemes to define two FEC Payload ID 1029 formats for use with source and repair packets respectively in the 1030 case of systematic FEC codes is introduced. 1032 o The file blocking algorithm from FLUTE is included here as a 1033 common algorithm which is recommended to be re-used by FEC Schemes 1034 when appropriate. 1036 14. Acknowledgments 1038 This document is largely based on RFC3452 [3] and thus thanks are due 1039 to the additional authors of that document: J. Gemmell, L. Rizzo, M. 1040 Handley, J. Crowcroft. 1042 15. References 1044 15.1. Normative References 1046 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1047 Levels", BCP 14, RFC 2119, March 1997. 1049 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1050 Considerations Section in RFCs", BCP 26, RFC 2434, 1051 October 1998. 1053 15.2. Informative References 1055 [3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., 1056 and J. Crowcroft, "Forward Error Correction (FEC) Building 1057 Block", RFC 3452, December 2002. 1059 [4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., 1060 and J. Crowcroft, "The Use of Forward Error Correction (FEC) in 1061 Reliable Multicast", RFC 3453, December 2002. 1063 [5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable 1064 Multicast Transport (RMT) Building Blocks and Protocol 1065 Instantiation documents", RFC 3269, April 2002. 1067 [6] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1068 Criteria for Evaluating Reliable Multicast Transport and 1069 Application Protocols", RFC 2357, June 1998. 1071 [7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1072 April 1992. 1074 [8] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 1075 "FLUTE - File Delivery over Unidirectional Transport", 1076 RFC 3926, October 2004. 1078 [9] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, 1079 "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): 1080 Multicast Source Authentication Transform Introduction", 1081 RFC 4082, June 2005. 1083 [10] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., 1084 and M. Luby, "Reliable Multicast Transport Building Blocks for 1085 One-to-Many Bulk-Data Transfer", RFC 3048, January 2001. 1087 Authors' Addresses 1089 Mark Watson 1090 Digital Fountain 1091 39141 Civic Center Drive 1092 Suite 300 1093 Fremont, CA 94538 1094 U.S.A. 1096 Email: mark@digitalfountain.com 1098 Michael Luby 1099 Digital Fountain 1100 39141 Civic Center Drive 1101 Suite 300 1102 Fremont, CA 94538 1103 U.S.A. 1105 Email: luby@digitalfountain.com 1107 Lorenzo Vicisano 1108 Digital Fountain 1109 39141 Civic Center Drive 1110 Suite 300 1111 Fremont, CA 94538 1112 U.S.A. 1114 Email: lorenzo@digitalfountain.com 1116 Full Copyright Statement 1118 Copyright (C) The IETF Trust (2007). 1120 This document is subject to the rights, licenses and restrictions 1121 contained in BCP 78, and except as set forth therein, the authors 1122 retain all their rights. 1124 This document and the information contained herein are provided on an 1125 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1126 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1127 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1128 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1129 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1130 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1132 Intellectual Property 1134 The IETF takes no position regarding the validity or scope of any 1135 Intellectual Property Rights or other rights that might be claimed to 1136 pertain to the implementation or use of the technology described in 1137 this document or the extent to which any license under such rights 1138 might or might not be available; nor does it represent that it has 1139 made any independent effort to identify any such rights. Information 1140 on the procedures with respect to rights in RFC documents can be 1141 found in BCP 78 and BCP 79. 1143 Copies of IPR disclosures made to the IETF Secretariat and any 1144 assurances of licenses to be made available, or the result of an 1145 attempt made to obtain a general license or permission for the use of 1146 such proprietary rights by implementers or users of this 1147 specification can be obtained from the IETF on-line IPR repository at 1148 http://www.ietf.org/ipr. 1150 The IETF invites any interested party to bring to its attention any 1151 copyrights, patents or patent applications, or other proprietary 1152 rights that may cover technology that may be required to implement 1153 this standard. Please address the information to the IETF at 1154 ietf-ipr@ietf.org. 1156 Acknowledgment 1158 Funding for the RFC Editor function is provided by the IETF 1159 Administrative Support Activity (IASA).