idnits 2.17.1 draft-ietf-rmt-bb-fec-supp-compact-01.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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 (12 May 2003) is 7648 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) -- Looks like a reference, but probably isn't: 'Y' on line 405 == Unused Reference: '4' is defined on line 505, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 509, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 521, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3269 (ref. '3') ** Obsolete normative reference: RFC 3450 (ref. '4') (Obsoleted by RFC 5775) ** Obsolete normative reference: RFC 3451 (ref. '5') (Obsoleted by RFC 5651) ** Obsolete normative reference: RFC 3452 (ref. '6') (Obsoleted by RFC 5052, RFC 5445) ** Downref: Normative reference to an Informational RFC: RFC 3453 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 2357 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 3048 (ref. '9') Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 3 draft-ietf-rmt-bb-fec-supp-compact-01.txt Digital Fountain 4 L. Vicisano 5 Cisco 6 12 May 2003 7 Expires: November 2003 9 Compact Forward Error Correction (FEC) Schemes 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet-Drafts as reference material or to cite 22 them other than as a "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 This document is a product of the IETF RMT WG. Comments should be 31 addressed to the authors, or the WG's mailing list at rmt@lbl.gov. 33 Abstract 35 This document introduces some Forward Error Correction (FEC) schemes 36 that supplement the FEC schemes described in RFC 3452 [6]. The primary 37 benefits of these additional FEC schemes are that they are designed for 38 reliable bulk delivery of large objects using a more compact FEC Payload 39 ID, and they can be used to sequentially deliver blocks of an object of 40 indeterminate length. Thus, they more flexibly support different 42 ^L 43 delivery models with less packet header overhead. 45 This document also describes the Fully-Specified FEC scheme 46 corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme 47 requires no FEC coding and is introduced primarily to allow simple 48 interoperability testing between different implementations of protocol 49 instantiations that use the FEC building block. 51 ^L 52 Table of Contents 54 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Packet Header Fields. . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. FEC Payload ID for FEC Encoding IDs 0 and 130. . . . . . . . . 5 57 2.2. Compact No-Code FEC scheme . . . . . . . . . . . . . . . . . . 6 58 2.3. Compact FEC scheme . . . . . . . . . . . . . . . . . . . . . . 7 59 3. Compact No-Code FEC scheme. . . . . . . . . . . . . . . . . . . . 8 60 3.1. Source Block Logistics . . . . . . . . . . . . . . . . . . . . 9 61 3.2. Sending and Receiving a Source Block . . . . . . . . . . . . . 10 62 4. Usage Examples. . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.1. Reliable Bulk Data Delivery. . . . . . . . . . . . . . . . . . 11 64 4.2. Block-Stream Delivery. . . . . . . . . . . . . . . . . . . . . 12 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 67 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 14 69 9. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 15 71 ^L 72 1. Introduction 74 This document describes two new Forward Error Correction (FEC) schemes 75 corresponding to FEC Encoding IDs 0 and 130 which supplement the FEC 76 schemes corresponding to FEC Encoding IDs 128 and 129 described in the 77 FEC Building Block [6]. 79 The new FEC schemes are particularly applicable when an object is 80 partitioned into equal-length source blocks. In this case, the source 81 block length common to all source blocks can be communicated out-of- 82 band, thus saving the additional overhead of carrying the source block 83 length within the FEC Payload ID of each packet. The new FEC schemes 84 are similar to the FEC schemes with FEC Encoding ID 128 defined in RFC 85 3452 [6], except that the FEC Payload ID is half as long. This is the 86 reason that these new FEC schemes are called Compact FEC schemes. 88 The primary focus of FEC Encoding IDs 128 and 129 is to reliably deliver 89 bulk objects of known length. The FEC schemes described in this 90 document are designed to be used for both reliable delivery of bulk 91 objects of known length, and for the delivery of a stream of source 92 blocks for an object of indeterminate length. Within the block-stream 93 delivery model, reliability guarantees can range from acknowledged 94 reliable delivery of each block to unacknowledged enhanced-reliability 95 delivery of time-sensitive blocks, depending on the properties of the 96 protocol instantiation in which the FEC scheme is used. Acknowledged 97 reliable block-stream delivery is similar in spirit to the byte-stream 98 delivery that TCP offers, except that the unit of delivery is a block of 99 data instead of a byte of data. In the spirit of a building block (see 100 RFC 3048 [9]), the FEC schemes described in this document can be used to 101 provide reliability for other service models as well. 103 The two new FEC Encoding IDs 0 and 130 are described in Section 2, and 104 this supplements Section 5 of the FEC building block [6]. Section 3 of 105 this document describes the Fully-Specified FEC scheme corresponding to 106 the FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC 107 coding and is specified primarily to allow simple interoperability 108 testing between different implementations of protocol instantiations 109 that use the FEC building block. 111 This document inherits the context, language, declarations and 112 restrictions of the FEC building block [6]. This document also uses the 113 terminology of the companion document [7] which describes the use of FEC 114 codes within the context of reliable IP multicast transport and provides 115 an introduction to some commonly used FEC codes. 117 Building blocks are defined in RFC 3048 [9]. This document is a product 118 of the IETF RMT WG and follows the general guidelines provided in RFC 119 3269 [3]. 121 ^L 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [2]. 126 2. Packet Header Fields 128 This section specifies FEC Encoding IDs 0 and 130 and the associated FEC 129 Payload ID formats and the specific information in the corresponding FEC 130 Object Transmission Information. The FEC scheme associated with FEC 131 Encoding ID 0 is Fully-Specified whereas the FEC schemes associated with 132 FEC Encoding ID 130 are Under-Specified. 134 FEC Encoding IDs 0 and 130 have the same FEC Payload ID format, which is 135 described in the following subsection. The FEC Object Transmission 136 Information for FEC Encoding IDs 0 and 130 is different, and is 137 described in the subsequent two subsections. 139 2.1. FEC Payload ID for FEC Encoding IDs 0 and 130 141 The FEC Payload ID for FEC Encoding IDs 0 and 130 is composed of a 142 Source Block Number and an Encoding Symbol ID structured as follows: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Source Block Number | Encoding Symbol ID | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 The 16-bit Source Block Number is used to identify from which source 151 block of the object the encoding symbol in the payload of the packet is 152 generated. There are two possible modes: In the unique SBN mode each 153 source block within the object has a unique Source Block Number 154 associated with it, and in the non-unique SBN mode the same Source Block 155 Number may be used for more than one source block within the object. 156 Which mode is being used for an object is outside the scope of this 157 document and MUST be communicated, either explicitly or implicitly, out- 158 of-band to receivers. 160 If the unique SBN mode is used then successive Source Block Numbers are 161 associated with consecutive source blocks of the object starting with 162 Source Block Number 0 for the first source block of the object. In this 163 case, there are at most 2^16 source blocks in the object. 165 ^L 166 If the non-unique SBN mode is used then the mapping from source blocks 167 to Source Block Numbers MUST be communicated out-of-band to receivers, 168 and how this is done is outside the scope of this document. This 169 mapping could be implicit, for example determined by the transmission 170 order of the source blocks. In non-unique SBN mode, packets for two 171 different source blocks mapped to the same Source Block Number SHOULD 172 NOT be sent within an interval of time that is shorter than the 173 transport time of a source block. The transport time of a source block 174 includes the amount of time the source block is processed at the 175 transport layer by the sender, the network transit time for packets, and 176 the amount of time the source block is processed at the transport layer 177 by a receiver. This is so that the receiver can clearly decide which 178 packets belong to which source block. 180 The 16-bit Encoding Symbol ID identifies which specific encoding symbol 181 generated from the source block is carried in the packet payload. The 182 exact details of the correspondence between Encoding Symbol IDs and the 183 encoding symbols in the packet payload for FEC Encoding ID 0 are 184 specified in Section 3. The exact details of the correspondence between 185 Encoding Symbol IDs and the encoding symbol(s) in the packet payload for 186 FEC Encoding ID 130 are dependent on the particular encoding algorithm 187 used as identified by the FEC Encoding ID and by the FEC Instance ID. 189 2.2. Compact No-Code FEC scheme 191 This subsection reserves FEC Encoding ID 0 for the Compact No-Code FEC 192 scheme that is described in this subsection and in Section 3. This is a 193 Fully-Specified FEC scheme that is primarily intended to be used for 194 simple interoperability testing between different implementations of 195 protocol instantiations that use the FEC building block. The value of 196 this FEC scheme is that no FEC encoding or decoding is required to 197 implement it and therefore it is easy to test interoperability between 198 protocols that may use different proprietary FEC schemes in production 199 in their first implementations. 201 The FEC Payload ID format for FEC Encoding ID 0 is described in 202 Subsection 2.1. The FEC Object Transmission Information has the 203 following specific information: 205 o The FEC Encoding ID 0. 207 o For each source block of the object, the length in bytes of the 208 encoding symbol carried in the packet payload. This length MUST be 209 the same for all packets sent for the same source block, but MAY be 210 different for different source blocks in the same object. 212 ^L 214 o For each source block of the object, the length of the source block 215 in bytes. Typically, each source block for the object has the same 216 length and thus only one length common to all source blocks need be 217 communicated, but this is not a requirement. For convenience, the 218 source block length MAY be a multiple of the length of the encoding 219 symbol carried in one packet payload. 221 How this out-of-band information is communicated is outside the scope of 222 this document. 224 Other information, such as the object length and the number of source 225 blocks of the object for an object of known length may be needed by a 226 receiver to support some delivery models such as reliable bulk data 227 delivery. 229 2.3. Compact FEC scheme 231 This subsection reserves FEC Encoding ID 130 for the Compact FEC scheme 232 that is described in this subsection. This is an Under-Specified FEC 233 scheme. This FEC scheme is similar in spirit to the Compact No-Code FEC 234 scheme, except that a non-trivial FEC encoding (that is Under-Specified) 235 may be used to generate encoding symbol(s) placed in the payload of each 236 packet and a corresponding FEC decoder may be used to produce the source 237 block from received packets. 239 The FEC Payload ID format for FEC Encoding ID 0 is described in 240 Subsection 2.1. The FEC Object Transmission Information has the 241 following specific information: 243 o The FEC Encoding ID 130. 245 o The FEC Instance ID associated with the FEC Encoding ID 130 to be 246 used. 248 o For each source block of the object, the aggregate length of the 249 encoding symbol(s) carried in one packet payload. This length MUST 250 be the same for all packets sent for the same source block, but MAY 251 be different for different source blocks in the same object. 253 o For each source block of the object, the length of the source block 254 in bytes. Typically, each source block for the object has the same 255 length and thus only one length common to all source blocks need be 256 communicated, but this is not a requirement. For convenience, the 257 source block length MAY be a multiple of the aggregate length of the 259 ^L 260 encoding symbol(s) carried in one packet payload. 262 How this out-of-band information is communicated is outside the scope of 263 this document. 265 Other information, such as the object length and the number of source 266 blocks of the object for an object of known length may be needed by a 267 receiver to support some delivery models such as reliable bulk data 268 delivery. 270 3. Compact No-Code FEC scheme 272 In this section we describe a Fully-Specified FEC scheme corresponding 273 to FEC Encoding ID 0. The primary purpose for introducing this FEC 274 schemes is to allow simple interoperability testing between different 275 implementations of the same protocol instantiation that uses the FEC 276 building block. 278 The Compact No-Code FEC scheme does not require FEC encoding or 279 decoding. Instead, each encoding symbol consists of consecutive bytes 280 of a source block of the object. The FEC Payload ID consists of two 281 fields, the 16-bit Source Block Number and the 16-bit Encoding Symbol 282 ID, as described in Subsection 2.1. The relative lengths of these fields 283 were chosen for their similarity with the corresponding fields of the 284 FEC Payload ID associated with FEC Encoding ID 130, and because of this 285 testing interoperability of the FEC scheme associated with FEC Encoding 286 ID 0 provides a first basic step to testing interoperability of an FEC 287 scheme associated with FEC Encoding ID 130. 289 The mapping between source blocks of an object and Source Block Numbers 290 is as described in Subsection 2.1. The next two subsections describe the 291 details of how the Compact No-Code FEC scheme operates for each source 292 block of an object. These subsections are not meant to suggest a 293 particular implementation, but just to illustrate the general algorithm 294 through the description of a simple, non-optimized implementation. 296 3.1. Source Block Logistics 298 Let X > 0 be the length of a source block in bytes. The value of X is 299 part of the FEC Object Transmission Information, and how this 300 information is communicated to a receiver is outside the scope of this 302 ^L 303 document. 305 Let L > 0 be the length of the encoding symbol contained in the payload 306 of each packet. There are several possible ways the length of the 307 encoding symbol L can be communicated to the receiver, and how this is 308 done is outside the scope of this document. As an example, a sender 309 could fix the packet payload length to be L in order to place the 310 encoding symbol of length L into the packet, and then a receiver could 311 infer the value of L from the length of the received packet payload. It 312 is REQUIRED that L be the same for all packets sent for the same source 313 block but MAY be different for different source blocks within the same 314 object. 316 For a given source block X bytes in length with Source Block Number I, 317 let N = X/L rounded up to the nearest integer. The encoding symbol 318 carried in the payload of a packet consists of a consecutive portion of 319 the source block. The source block is logically partitioned into N 320 encoding symbols, each L bytes in length, and the corresponding Encoding 321 Symbol IDs range from 0 through N-1 starting at the beginning of the 322 source block and proceeding to the end. Thus, the encoding symbol with 323 Encoding Symbol ID Y consists of bytes L*Y through L*(Y+1)-1 of the 324 source block, where the bytes of the source block are numbered from 0 325 through X-1. If X/L is not integral then the last encoding symbol with 326 Encoding Symbol ID = N-1 consists of bytes L*(N-1) through the last byte 327 X-1 of the source block, and the remaining L*N - X bytes of the encoding 328 symbol can by padded out with zeroes. 330 As an example, suppose that the source block length X = 20,400 and 331 encoding symbol length L = 1,000. The encoding symbol with Encoding 332 Symbol ID = 10 contains bytes 10,000 through 10,999 of the source block, 333 and the encoding symbol with Encoding Symbol ID = 20 contains bytes 334 20,000 through the last byte 20,399 of the source block and the 335 remaining 600 bytes of the encoding symbol can be padded with zeroes. 337 There are no restrictions beyond the rules stated above on how a sender 338 generates encoding symbols to send from a source block. However, it is 339 recommended that an implementor of refer to the companion document [7] 340 for general advice. 342 In the next subsection a procedure is recommended for sending and 343 receiving source blocks. 345 3.2. Sending and Receiving a Source Block 347 The following carousel procedure is RECOMMENDED for a sender to generate 349 ^L 350 packets containing FEC Payload IDs and corresponding encoding symbols 351 for a source block with Source Block Number I. Set the length in bytes 352 of an encoding symbol to a fixed value L which is reasonable for a 353 packet payload (e.g., ensure that the total packet size does not exceed 354 the MTU) and that is smaller than the source block length X, e.g., L = 355 1,000 for X >= 1,000. Initialize Y to a value randomly chosen in the 356 interval [0..N-1]. Repeat the following for each packet of the source 357 block to be sent. 359 o If Y < N-1 then generate the encoding symbol consisting of the L 360 bytes of the source block numbered L*Y through L*(Y+1)-1. 362 o If Y = N-1 then generate the encoding symbol consisting of the last 363 X - L*(N-1) bytes of the source block numbered L*(N-1) through X-1 364 followed by L*N - X padding bytes of zeroes. 366 o Set the Source Block Length to X, set the Source Block Number = I, 367 set the Encoding Symbol ID = Y, place the FEC Payload ID and the 368 encoding symbol into the packet to send. 370 o In preparation for the generation of the next packet: if Y < N-1 371 then increment Y by one elseif Y = N-1 then reset Y to zero. 373 The following procedure is RECOMMENDED for a receiver to recover the 374 source block based on receiving packets for the source block from a 375 sender that is using the carousel procedure describe above. The 376 receiver can determine from which source block a received packet was 377 generated by the Source Block Number carried in the FEC Payload ID. 378 Upon receipt of the first FEC Payload ID for a source block, the 379 receiver uses the source block length received out-of-band as part of 380 the FEC Object Transmission Information to determine the length X in 381 bytes of the source block, and allocates space for the X bytes that the 382 source block requires. The receiver also computes the length L of the 383 encoding symbol(s) in the payload of the packet by subtracting the 384 packet header length from the total length of the received packet (and 385 the receiver checks that this length is the same in each subsequent 386 received packet from the same source block). After calculating N = X/L 387 rounded up to the nearest integer, the receiver allocates a boolean 388 array RECEIVED[0..N-1] with all N entries initialized to false to track 389 received encoding symbols. The receiver keeps receiving packets for the 390 source block as long as there is at least one entry in RECEIVED still 391 set to false or until the application decides to give up on this source 392 block and move on to other source blocks. For each received packet for 393 the source block (including the first packet) the steps to be taken to 394 help recover the source block are as follows. Let Y be the value of the 395 Encoding Symbol ID within FEC Payload ID of the packet. If Y < N-1 then 396 the receiver copies the L bytes of the encoding symbol into bytes 398 ^L 399 numbered L*Y through L*(Y+1)-1 of the space reserved for the source 400 block. If Y = N-1 then the receiver copies the first X - L*(N-1) bytes 401 of the encoding symbol into bytes numbered L*(N-1) through X-1 of the 402 space reserved for the source block. In either case, the receiver sets 403 RECEIVED[Y] = true. At each point in time, the receiver has 404 successfully recovered bytes L*Y through L*(Y+1)-1 of the source block 405 for all Y in the interval [0..N-1] for which RECEIVED[Y] is true. If 406 all all N entries of RECEIVED are true then the receiver has recovered 407 the entire source block. 409 4. Usage Examples 411 The following subsections outline some usage examples for FEC Encoding 412 IDs 0 and 130. 414 4.1. Reliable Bulk Data Delivery 416 One possible delivery model that can be supported using any FEC scheme 417 described in this document is reliable bulk data delivery. In this 418 model, one or more potentially large objects are to be reliably 419 delivered to potentially multiple receivers using multicast. For this 420 delivery model the unique SBN mode is often used. Using this mode the 421 maximum length of an object that can be delivered is at most the number 422 of possible source blocks times the maximum length of a source block. 423 If the aggregate length of encoding symbols carried in a packet payload 424 is L bytes then the maximum length of a source block is the number of 425 distinct Encoding Symbol IDs times L, or 2^16 * L for FEC Encoding IDs 0 426 and 130. If for example L = 1 KB then the length of a source block can 427 be up to around 65 MB. However, in practice the length of the source 428 block is usually shorter than the number of distinct Encoding Symbol IDs 429 times L, and thus generally the length of a source block is a fraction 430 of 65 MB. Since the number of distinct Source Block Numbers is 2^16, 431 for this example an object can be more than a terabyte. 433 The non-unique SBN mode of delivery can also be effectively used for 434 reliably delivering large object. In this case, the length of the 435 object delivered could be arbitrarily large, depending on the out-of- 436 band mapping between source blocks and Source Block Numbers. 438 ^L 439 4.2. Block-Stream Delivery 441 Another possible delivery model that can be supported using FEC Encoding 442 ID 0 or 130 is block-stream delivery of an object. In this model, the 443 source blocks of a potentially indeterminate length object are to be 444 reliably delivered in sequence to one or multiple receivers. Thus, the 445 object could be partitioned into source blocks on-the-fly at the sender 446 as the data arrives, and all packets generated for one source block are 447 sent before any packets are sent for the subsequent source block. In 448 this example, all source blocks could be of the same length and this 449 length could be communicated out-of-band to a receiver before the 450 receiver joins the session. For this delivery model it is not required 451 that the Source Block Numbers for all source blocks are unique. 452 However, a suggested usage is to use all 2^16 Source Block Numbers for 453 consecutive source blocks of the object, and thus the time between reuse 454 of a Source Block Number is the time it takes to send the packets for 455 2^16 source blocks. 457 This delivery model can be used to reliably deliver an object to one or 458 multiple receivers, using either an ACK or NACK based acknowledgement 459 based scheme for each source block. As another example the sender could 460 send a fixed number of packets for each source block without any 461 acknowledgements from receivers, for example in a live streaming without 462 feedback application. 464 5. Security Considerations 466 The security considerations for this document are the same as they are 467 for RFC 3452 [6]. 469 6. IANA Considerations 471 Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA 472 registration. For general guidelines on IANA considerations as they 473 apply to this document, see RFC 3452 [6]. This document assigns the 474 Fully-Specified FEC Encoding ID 0 under the ietf:rmt:fec:encoding name- 475 space to "Compact No-Code". The FEC Payload ID format and corresponding 476 FEC Object Transmission Information associated with FEC Encoding ID 0 is 477 described in Subsections 2.1 and 2.2, and the corresponding FEC scheme 478 is described in Section 3. 480 This document assigns the Under-Specified FEC Encoding ID 130 under the 481 ietf:rmt:fec:encoding name-space to "Compact FEC". This document also 482 establishes a new "FEC Instance ID" registry 484 ^L 485 ietf:rmt:fec:encoding:instance:130 487 ietf:rmt:fec:encoding = 130 (Compact FEC) 489 The FEC Payload ID format and corresponding FEC Object Transmission 490 Information associated with FEC Encoding ID 130 is described in 491 Subsections 2.1 and 2.3. 493 7. References 495 [1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 496 2026, October 1996. 498 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 499 Levels", RFC 2119, March 1997. 501 [3] Kermode, R., Vicisano, L., ``Author Guidelines for Reliable 502 Multicast Transport (RMT) Building Blocks and Protocol Instantiation 503 documents'', RFC 3269, April 2002. 505 [4] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft, 506 "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450 507 December 2002. 509 [5] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. 510 Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451 511 December 2002. 513 [6] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. 514 Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, 515 December 2002. 517 [7] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. 518 Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable 519 Multicast", RFC 3453, December 2002. 521 [8] Mankin, A., Romanow, A., Bradner, S., Paxson V., "IETF Criteria for 522 Evaluating Reliable Multicast Transport and Application Protocols", RFC 523 2357, June 1998. 525 [9] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., 526 Luby, M., "Reliable Multicast Transport Building Blocks for One-to-Many 527 Bulk-Data Transfer", RFC 3048, January 2001. 529 ^L 530 8. Authors' Addresses 532 Michael Luby 533 luby@digitalfountain.com 534 Digital Fountain, Inc. 535 39141 Civic Center Drive 536 Suite 300 537 Fremont, CA 94538 539 Lorenzo Vicisano 540 lorenzo@cisco.com 541 cisco Systems, Inc. 542 170 West Tasman Dr., 543 San Jose, CA, USA, 95134 545 ^L 547 9. Full Copyright Statement 549 Copyright (C) The Internet Society (2002). All Rights Reserved. 551 This document and translations of it may be copied and furnished to 552 others, and derivative works that comment on or otherwise explain it or 553 assist in its implementation may be prepared, copied, published and 554 distributed, in whole or in part, without restriction of any kind, 555 provided that the above copyright notice and this paragraph are included 556 on all such copies and derivative works. However, this document itself 557 may not be modified in any way, such as by removing the copyright notice 558 or references to the Internet Society or other Internet organizations, 559 except as needed for the purpose of developing Internet standards in 560 which case the procedures for copyrights defined in the Internet 561 languages other than English. 563 The limited permissions granted above are perpetual and will not be 564 revoked by the Internet Society or its successors or assigns. 566 This document and the information contained herein is provided on an "AS 567 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 568 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 569 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 570 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 571 FITNESS FOR A PARTICULAR PURPOSE." 573 ^L