idnits 2.17.1 draft-ietf-rmt-bb-fec-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (8 February 2002) is 8107 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) ** Obsolete normative reference: RFC 2401 (ref. '3') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '4') (Obsoleted by RFC 4303, RFC 4305) -- Duplicate reference: RFC2406, mentioned in '5', was also mentioned in '4'. ** Obsolete normative reference: RFC 2406 (ref. '5') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-03) exists of draft-ietf-rmt-info-fec-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rmt-info-fec (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 2357 (ref. '7') ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 3048 (ref. '11') Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force RMT WG 2 INTERNET-DRAFT M.Luby/Digital Fountain 3 draft-ietf-rmt-bb-fec-06.txt L.Vicisano/Cisco 4 J.Gemmell/Microsoft 5 L.Rizzo/ACIRI and Univ. Pisa 6 M.Handley/ACIRI 7 J. Crowcroft/UCL 8 8 February 2002 9 Expires: August 2002 11 Forward Error Correction building block 13 Status of this Document 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are valid for a maximum of six months and may be 22 updated, replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet-Drafts as reference material or to cite 24 them other than as a "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 This document is a product of the IETF RMT WG. Comments should be 33 addressed to the authors, or the WG's mailing list at rmt@lbl.gov. 35 Abstract 37 This document describes the abstract packet formats and IANA 38 registration procedures for use of Forward Error Correction 39 (FEC) codes within the context of reliable IP multicast 40 transport. This document should be read in conjunction with 41 and uses the terminology of the companion document [6], which 42 describes the use of Forward Error Correction (FEC) codes 43 within the context of reliable IP multicast transport and 44 provides an introduction to some commonly used FEC codes. 46 Table of Contents 48 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 49 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Functionality . . . . . . . . . . . . . . . . . . . . . 5 51 3.1. FEC Encoding ID and FEC Encoding Name. . . . . . . . 6 52 3.2. FEC Payload ID and FEC Object Transmission 53 Information . . . . . . . . . . . . . . . . . . . . . . . 7 54 4. Applicability Statement . . . . . . . . . . . . . . . . 8 55 5. Packet Header Fields. . . . . . . . . . . . . . . . . . 9 56 5.1. Small Block, Large Block and Expandable FEC 57 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 5.2. Small Block Systematic FEC Codes . . . . . . . . . . 10 59 6. Requirements from other building blocks . . . . . . . . 12 60 7. Security Considerations . . . . . . . . . . . . . . . . 12 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . 13 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 14 63 10. References . . . . . . . . . . . . . . . . . . . . . . 14 64 11. Authors' Addresses . . . . . . . . . . . . . . . . . . 15 65 12. Full Copyright Statement . . . . . . . . . . . . . . . 17 67 1. Introduction 69 This document describes how to use Forward Error Correction (FEC) codes 70 to provide support for reliable delivery of content using IP multicast. 71 This document should be read in conjunction with and uses the 72 terminology of the companion document [6], which describes the use of 73 FEC codes within the context of reliable IP multicast transport and 74 provides an introduction to some commonly used FEC codes. 76 This document describes a building block as defined in RFC3048 [11]. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC2119 [2]. 81 2. Rationale 83 FEC codes are a valuable basic component of any transport protocol that 84 is to provide reliable delivery of content. Using FEC codes is valuable 85 in the context of IP multicast and reliable delivery because FEC 86 encoding symbols can be useful to all receivers for reconstructing 87 content even when the receivers have received different encoding 88 symbols. Furthermore, FEC codes can ameliorate or even eliminate the 89 need for feedback from receivers to senders to request retransmission of 90 lost packets. 92 The goal of the FEC building block is to describe functionality directly 93 related to FEC codes that is common to all reliable content delivery IP 94 multicast protocols, and to leave out any additional functionality that 95 is specific to particular protocols. The primary functionality 96 described in this document that is common to all such protocols that use 97 FEC codes are FEC encoding symbols for an object that is included in 98 packets that flow from a sender to receivers. This document for example 99 does not describe how receivers may request transmission of particular 100 encoding symbols for an object. This is because although there are 101 protocols where requests for transmission are of use, there are also 102 protocols that do not require such requests. 104 The companion document [6] should be consulted for a full explanation of 105 the benefits of using FEC codes for reliable content delivery using IP 106 multicast. FEC codes are also useful in the context of unicast, and 107 thus the scope and applicability of this document is not limited to IP 108 multicast. 110 3. Functionality 112 This section describes FEC information that is either to be sent out-of- 113 band or in packets. The FEC information is associated with transmission 114 of data about a particular object. There are three classes of packets 115 that may contain FEC information: data packets, session-control packets 116 and feedback packets. They generally contain different kinds of FEC 117 information. Note that some protocols may not use session-control or 118 feedback packets. 120 Data packets may sometimes serve as session-control packets as well; 121 both data and session-control packets generally travel downstream from 122 the sender towards receivers and are sent to a multicast channel or to a 123 specific receiver using unicast. 125 As a general rule, feedback packets travel upstream from receivers to 126 the sender. Sometimes, however, they might be sent to a multicast 127 channel or to another receiver or to some intermediate node or 128 neighboring router that provides recovery services. 130 This document specifies the FEC information that must be carried in data 131 packets and the other FEC information that must be communicated either 132 out-of-band or in data packets. This document does not specify out-of- 133 band methods nor does it specify the way out-of-band FEC information is 134 associated with FEC information carried in data packets. These methods 135 must be specified in a complete protocol instantiation that uses the FEC 136 building block. FEC information is classified as follows: 138 1) FEC Encoding ID 140 Identifies the FEC encoder being used and allows receivers to 141 select the appropriate FEC decoder. The value of the FEC Encoding 142 ID MUST be the same for all transmission of data related to a 143 particular object, but MAY vary across different transmissions of 144 data about different objects, even if transmitted to the same set 145 of multicast channels and/or using a single upper-layer session. 146 The FEC encoding ID is subject to IANA registration. 148 2) FEC Encoding Name 150 Provides a more specific identification of the FEC encoder being 151 used for an Under-Specified FEC scheme. This value is not used 152 for Fully-Specified FEC schemes. (See Section 3.1 for the 153 definition of Under-Specified and Fully-Specified FEC schemes.) 154 The FEC encoding name is scoped by the FEC encoding ID, and is 155 subject to IANA registration. 157 3) FEC payload ID 159 Identifies the encoding symbol(s) in the payload of the packet. 160 The fields in the FEC Payload ID depend on the encoder being used 161 (e.g. in Block and Expandable FEC codes this may be the 162 combination of block number and encoding symbol ID). 164 4) FEC Object Transmission Information 166 This is information regarding the encoding of a specific object 167 needed by the FEC decoder (e.g. for Block and Expandable FEC codes 168 this may be the combination of the source block lengths and the 169 object length). This might also include specific parameters of 170 the FEC encoder. 172 The FEC Encoding ID, FEC Encoding Name (for Under-Specified FEC schemes) 173 and the FEC Object Transmission Information can be sent to a receiver 174 within the data packet headers, within session control packets, or by 175 some other means. In any case, the means for communicating this to a 176 receiver is outside the scope of this document. The FEC Payload ID MUST 177 be included in the data packet header fields, as it provides a 178 description of the data contained in the packet. 180 3.1. FEC Encoding ID and FEC Encoding Name 182 The FEC Encoding ID is a numeric index that identifies a specific FEC 183 scheme OR a class of encoding schemes that share the same FEC Payload ID 184 format. 186 An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is 187 formally and fully specified, in a way that independent implementors can 188 implement both encoder and decoder from a specification that is an IETF 189 RFC. The FEC Encoding ID uniquely identifies a Fully-Specified FEC 190 scheme. Companion documents of this specification may specify Fully- 191 Specified FEC schemes and associate them with FEC Encoding ID values. 192 These documents MUST also specify a format for the FEC Payload ID and 193 specify the information in the FEC Object Transmission Information. 195 It is possible that a FEC scheme cannot be a Fully-Specified FEC scheme, 196 because a specification is simply not available or that a party exists 197 that owns the encoding scheme and is not willing to disclose the 198 algorithm or specification. We refer to such an FEC encoding schemes as 199 an Under-Specified FEC scheme. The following holds for an Under- 200 Specified FEC scheme: 202 o The format of the FEC Payload ID and the specific information in the 203 FEC Object Transmission Information MUST be defined for the Under- 204 Specified FEC scheme. 206 o A value for the FEC Encoding ID MUST be reserved and associated with 207 the format of the FEC Payload ID and the specific information in the 208 FEC Object Transmission Information. An already reserved FEC 209 Encoding ID value MUST be reused if it is associated with the same 210 format of FEC Payload ID and the same information in the FEC Object 211 Transmission Information as the ones needed for the new Under- 212 Specified FEC scheme. 214 o A value for the FEC Encoding Name MUST be reserved. 216 An Under-specified FEC scheme is fully identified by the tuple (FEC 217 Encoding ID, FEC Encoding Name). The tuple MUST identify a single scheme 218 that has at least one implementation. The party that owns this tuple 219 MUST be able to provide information on how to obtain the Under-Specified 220 FEC scheme identified by the tuple, e.g. a pointer to a publicly 221 available reference-implementation or the name and contacts of a company 222 that sells it, either separately or embedded in another product. 224 Different Under-Specified FEC schemes that share the same FEC Encoding 225 ID -- but have different FEC Encoding Names -- also share the same 226 format of FEC Payload ID and specify the same information in the FEC 227 Object Transmission Information. 229 This specification reserves the range 0-127 for the values of FEC 230 Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for 231 the values of Under-Specified FEC schemes. 233 3.2. FEC Payload ID and FEC Object Transmission Information 235 A document that specifies an FEC scheme and reserves a value of FEC 236 Encoding ID MUST define a packet format for the FEC Payload ID and 237 specify the information in the FEC Object Transmission Information 238 according to the needs of the encoding scheme. This applies to documents 239 that reserve values of FEC Encoding IDs for both Fully-Specified and 240 Under-Specified FEC schemes. 242 The packet format definition for the FEC Payload ID MUST specify the 243 meaning and layout of the fields down to the level of specific bits. 244 The FEC Payload ID MUST have a length that is a multiple of a 4-byte 245 word. This requirement facilitates the alignment of packet fields in 246 protocol instantiations. This building block describes the abstract 247 packet formats for carrying FEC encoding symbols that are sent from a 248 sender to a receiver. 250 4. Applicability Statement 252 The FEC building block applies to creating and sending encoding symbols 253 for objects that are to be reliably transported using IP multicast or 254 unicast. The FEC building block does not provide higher level session 255 support. Thus, for example, many objects may be transmitted within the 256 same session, in which case a higher level building block may carry a 257 unique Transport Object ID (TOI) for each object in the session to allow 258 the receiver to demultiplex packets within the session based on the TOI 259 within each packet. As another example, a receiver may subscribe to 260 more than one session at a time. In this case a higher level building 261 block may carry a unique Transport Session ID (TSI) for each session to 262 allow the receiver to demultiplex packets based on the TSI within each 263 packet. 265 Other building blocks may supply direct support for carrying out-of-band 266 information directly relevant to the FEC building block to receivers. 267 For example, the length of the object is part of the FEC Object 268 Transmission Information that may in some cases be communicated out-of- 269 band to receivers, and one mechanism for providing this to receivers is 270 within the context of another building block that provides this 271 information. 273 Some protocols may use FEC codes as a mechanism for repairing the loss 274 of packets. Within the context of FEC repair schemes, feedback packets 275 are (optionally) used to request FEC retransmission. The FEC-related 276 information present in feedback packets usually contains an FEC Block ID 277 that defines the block that is being repaired, and the number of Repair 278 Symbols requested. Although this is the most common case, variants are 279 possible in which the receivers provide more specific information about 280 the Repair Symbols requested (e.g. an index range or a list of symbols 281 accepted). It is also possible to include multiple of these requests in 282 a single feedback packet. This document does not provide any detail 283 about feedback schemes used in combination with FEC nor the format of 284 FEC information in feedback packets. If feedback packets are used in a 285 complete protocol instantiation, these details must be provided in the 286 protocol instantiation specification. 288 The FEC building block does not provide any support for congestion 289 control. Any complete protocol MUST provide congestion control that 290 conforms to RFC2357 [7], and thus this MUST be provided by another 291 building block when the FEC building block is used in a protocol. 293 A more complete description of the applicability of FEC codes can be 294 found in the companion document [6]. 296 5. Packet Header Fields 298 This section specifies the FEC Encoding ID and the associated FEC 299 Payload ID format and the specific information in the FEC Object 300 Transmission Information for a number of known Under-Specified FEC 301 schemes. Under-specified FEC schemes that use the same FEC Payload ID 302 format and specific information in the FEC Object Transmission 303 Information as for one of the FEC Encoding IDs specified in this section 304 MUST use the corresponding FEC Encoding ID. Other FEC Encoding IDs may 305 be specified for other Under-Specified FEC schemes in companion 306 documents. 308 5.1. Small Block, Large Block and Expandable FEC Codes 310 This subsection reserves the FEC Encoding ID value 128 for the Under- 311 Specified FEC schemes described in [6] that are called Small Block FEC 312 codes, Large Block FEC codes and Expandable FEC codes. 314 The FEC Payload ID is composed of a Source Block Number and an Encoding 315 Symbol ID structured as follows: 317 0 1 2 3 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Source Block Number | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Encoding Symbol ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 The Source Block Number identifies from which source block of the object 326 the encoding symbol(s) in the payload are generated. These blocks are 327 numbered consecutively from 0 to N-1, where N is the number of source 328 blocks in the object. 330 The Encoding Symbol ID identifies which specific encoding symbol(s) 331 generated from the source block are carried in the packet payload. The 332 exact details of the correspondence between Encoding Symbol IDs and the 333 encoding symbol(s) in the packet payload are dependent on the particular 334 encoding algorithm used as identified by the Fec Encoding ID and by the 335 FEC Encoding Name, and these details may be proprietary. 337 The FEC Object Transmission Information has the following specific 338 information: 340 o The FEC Encoding ID 128. 342 o The FEC Encoding Name associated with the FEC Encoding ID 128 to be 343 used. 345 o The total length of the object in bytes. 347 o The number of source blocks that the object is partitioned into, and 348 the length of each source block in bytes. 350 How this out-of-band information is communicated is outside the scope of 351 this document. As an example the source block lengths may be derived by 352 a fixed algorithm from the object length. As another example, it may be 353 that all source blocks are the same length and this is what is passed 354 out-of-band to the receiver. As a third example, it could be that the 355 full sized source block length is provided and this is the length used 356 for all but the last source block, which is calculated based on the full 357 source block length and the object length. 359 5.2. Small Block Systematic FEC Codes 361 This subsection reserves the FEC Encoding ID value 129 for the Under- 362 Specified FEC schemes described in [6] that are called Small Block 363 Systematic FEC codes. For Small Block Systematic FEC codes, each source 364 block is of length at most 65536 source symbols. 366 Although these codes can generally be accommodated by the FEC Encoding 367 ID described in Section 5.1, a specific FEC Encoding ID is defined for 368 Small Block Systematic FEC codes to allow more flexibility and to retain 369 header compactness. The small source block length and small expansion 370 factor that often characterize systematic codes may require the data 371 source to frequently change the source block length. To allow the 372 dynamic variation of the source block length and to communicate it to 373 the receivers with low overhead, the block length is included in the FEC 374 Payload ID. 376 The FEC Payload ID is composed of the Source Block Number, Source Block 377 Length and the Encoding Symbol ID: 379 0 1 2 3 380 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Source Block Number | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Source Block Length | Encoding Symbol ID | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 The Source Block Number idenfities from which source block of the object 388 the encoding symbol(s) in the payload are generated. These blocks are 389 numbered consecutively from 0 to N-1, where N is the number of source 390 blocks in the object. 392 The Source Block Length is the length in units of source symbols of the 393 source block identified by the Source Block Number. 395 The Encoding Symbol ID identifies which specific encoding symbol(s) 396 generated from the source block are carried in the packet payload. Each 397 encoding symbol is either an original source symbol or a redundant 398 symbol generated by the encoder. The exact details of the 399 correspondence between Encoding Symbol IDs and the encoding symbol(s) in 400 the packet payload are dependent on the particular encoding algorithm 401 used as identified by the Fec Encoding ID and by the FEC Encoding Name, 402 and these details may be proprietary. 404 The FEC Object Transmission Information has the following specific 405 information: 407 o The FEC Encoding ID 129. 409 o The FEC Encoding Name associated with the FEC Encoding ID 129 to be 410 used. 412 o The total length of the object in bytes. 414 o The maximum number of encoding symbols that can be generated for any 415 source block. This field is provided for example to allow receivers 416 to preallocate buffer space that is suitable for decoding to recover 417 any source block. 419 o For each source block, the length in bytes of encoding symbols for 420 the source block. 422 How this out-of-band information is communicated is outside the scope of 423 this document. As an example the length in bytes of encoding symbols 424 for each source block may be the same for all source blocks. As another 425 example, the encoding symbol length may be the same for all source 426 blocks of a given object and this length is communicated for each 427 object. As a third example, it may be that there is a threshold value 428 I, and for all source blocks consisting of less than I source symbols, 429 the encoding symbol length is one fixed number of bytes, but for all 430 source blocks consisting of I or more source symbols, the encoding 431 symbol length is a different fixed number of bytes. 433 Note that each encoding symbol, i.e., each source symbol and redundant 434 symbol, must be the same length for a given source block, and this 435 implies that each source block length is a multiple of its encoding 436 symbol length. If the original source block length is not a multiple of 437 the encoding symbol length, it is up to the sending application to 438 appropriately pad the original source block to form the source block to 439 be encoded, and to communicate this padding to the receiving 440 application. The form of this padding, if used, and how it is 441 communicated to the receiving application, is outside the scope of this 442 document, and must be handled at the application level. 444 6. Requirements from other building blocks 446 The FEC building block does not provide any support for congestion 447 control. Any complete protocol MUST provide congestion control that 448 conforms to RFC2357 [7], and thus this MUST be provided by another 449 building block when the FEC building block is used in a protocol. 451 There are no other specific requirements from other building blocks for 452 the use of this FEC building block. However, any protocol that uses the 453 FEC building block will inevitably use other building blocks for example 454 to provide support for sending higher level session information within 455 data packets containing FEC encoding symbols. 457 7. Security Considerations 459 Data delivery can be subject to denial-of-service attacks by attackers 460 which send corrupted packets that are accepted as legitimate by 461 receivers. This is especially a concern for multicast delivery because 462 a corrupted packet may be injected into the session close to the root of 463 the multicast tree, in which case the corrupted packet will arrive to 464 many receivers. This is especially a concern for the FEC BB because the 465 use of even one corrupted packet containing encoding data may result in 466 the decoding of content that is completely corrupted and unusable. It 467 is thus RECOMMENDED that the decoded content be checked for integrity 468 before delivering the content to an application. For example, an MD5 469 hash [10] of the content may be appended before transmission, and the 470 MD5 hash is computed and checked after the content is decoded but before 471 it is delivered to an application. Moreover, in order to obtain strong 472 cryptographic integrity protection a digital signature verifiable by the 473 receiver SHOULD be computed on top of such a hash value. It is also 474 RECOMMENDED that a packet authentication protocol such as TESLA [9] be 475 used to detect and discard corrupted packets upon arrival. Furthermore, 476 it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all 477 network routers and switches along the path from the sender to receivers 478 to limit the possibility of a bad agent successfully injecting a 479 corrupted packet into the multicast tree data path. 481 Another security concern is that some FEC information may be obtained by 482 receivers out-of-band in a session description, and if the session 483 description is forged or corrupted then the receivers will not use the 484 correct protocol for decoding content from received packets. Thus, it 485 is RECOMMENDED that the receiver authenticate the session description, 486 for example by using either the ESP (with enabled authentication 487 service) [5] or AH [4] protocols of IPSEC [3] to ensure the authenticity 488 of the session description. 490 8. IANA Considerations 492 Values of FEC Encoding IDs and FEC Encoding Names are subject to IANA 493 registration. FEC Encoding IDs and FEC Encoding Names are hierarchical: 494 FEC Encoding IDs scope ranges of FEC Encoding Names. Only FEC Encoding 495 IDs that correspond to Under-Specified FEC schemes scope a corresponding 496 set of FEC Encoding Names. 498 The FEC Encoding ID is a numeric non-negative index. In this document, 499 the range of values for FEC Encoding IDs is 0 and 255. Values from 0 to 500 127 are reserved for Fully-Specified FEC schemes and Values from 128 to 501 255 are reserved for Under-Specified FEC schemes, as described in more 502 detail in Section 3.1. This specification already assigns the values 128 503 and 129, as described in Section 5. The assignment of additional FEC 504 Encoding IDs is on a Specification Required basis as defined in RFC2434 505 [8], and in particular a specification published as an IETF RFC is 506 required providing the information described in more detail in Section 507 3.1. 509 Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an 510 independent range of FEC Encoding Names (i.e. the same value of FEC 511 Encoding Name can be reused for different FEC Encoding IDs). An FEC 512 Encoding Name is a numeric non-negative index. 514 Under the scope of a FEC Encoding ID, FEC Encoding Names are assigned on 515 a First Come First Served basis as defined in RFC2434 [8] to requestors 516 that are able to provide point of contact information and a pointer to 517 publicly accessible documentation describing the Under-Specified FEC 518 scheme and ways to obtain it (e.g. a pointer to a publicly available 519 reference-implementation or the name and contacts of a company that 520 sells it, either separately or embedded in another product). The 521 requestor is responsible for keeping this information up to date. 523 9. Acknowledgments 525 Brian Adamson contributed to this document by shaping Section 5.2 and 526 providing general feedback. We also wish to thank Vincent Roca, Justin 527 Chapweske and Roger Kermode for their extensive comments. 529 10. References 531 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 532 RFC2026, October 1996. 534 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 535 Levels", RFC2119, March 1997. 537 [3] Kent, S., Atkinson, R., "Security Architecture for the Internet 538 Protocol", RFC2401, November 1998. 540 [4] Kent, S., Atkinson, R., "IP Authentication Header", RFC2406, 541 November 1998. 543 [5] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", 544 RFC2406, November 1998. 546 [6] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M., 547 Crowcroft, J., "The use of Forward Error Correction in Reliable 548 Multicast", Internet draft draft-ietf-rmt-info-fec-02.txt, January 2002. 550 [7] Mankin, A., Romanow, A., Bradner, S., Paxson V., "IETF Criteria for 551 Evaluating Reliable Multicast Transport and Application Protocols", 552 RFC2357, June 1998. 554 [8] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 555 Considerations Section in RFCs", RFC2434, October 1998. 557 [9] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and 558 Secure Source Authentication for Multicast", Network and Distributed 559 System Security Symposium, NDSS 2001, pp. 35-46, February 2001. 561 [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April 562 1992. 564 [11] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., 565 Luby, M., "Reliable Multicast Transport Building Blocks for One-to-Many 566 Bulk-Data Transfer", RFC3048, January 2001. 568 11. Authors' Addresses 570 Michael Luby 571 luby@digitalfountain.com 572 Digital Fountain, Inc. 573 39141 Civic Center Drive 574 Suite 300 575 Fremont, CA 94538 577 Lorenzo Vicisano 578 lorenzo@cisco.com 579 cisco Systems, Inc. 580 170 West Tasman Dr., 581 San Jose, CA, USA, 95134 583 Jim Gemmell 584 jgemmell@microsoft.com 585 Microsoft Research 586 301 Howard St., #830 587 San Francisco, CA, USA, 94105 589 Luigi Rizzo 590 luigi@iet.unipi.it 591 ACIRI, 1947 Center St., Berkeley CA 94704 592 and 593 Dip. di Ing. dell'Informazione 594 Universita` di Pisa 595 via Diotisalvi 2, 56126 Pisa, Italy 597 Mark Handley 598 mjh@aciri.org 599 ACIRI 600 1947 Center St. 601 Berkeley CA, USA, 94704 602 Jon Crowcroft 603 J.Crowcroft@cs.ucl.ac.uk 604 Department of Computer Science 605 University College London 606 Gower Street, 607 London WC1E 6BT, UK 609 12. Full Copyright Statement 611 Copyright (C) The Internet Society (2001). All Rights Reserved. 613 This document and translations of it may be copied and furnished to 614 others, and derivative works that comment on or otherwise explain it or 615 assist in its implementation may be prepared, copied, published and 616 distributed, in whole or in part, without restriction of any kind, 617 provided that the above copyright notice and this paragraph are included 618 on all such copies and derivative works. However, this document itself 619 may not be modified in any way, such as by removing the copyright notice 620 or references to the Internet Society or other Internet organizations, 621 except as needed for the purpose of developing Internet standards in 622 which case the procedures for copyrights defined in the Internet 623 languages other than English. 625 The limited permissions granted above are perpetual and will not be 626 revoked by the Internet Society or its successors or assigns. 628 This document and the information contained herein is provided on an "AS 629 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 630 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 631 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 632 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 633 FITNESS FOR A PARTICULAR PURPOSE."