idnits 2.17.1 draft-ietf-rmt-bb-fec-05.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 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 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 26 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 79: '... ID MUST be the same for all tran...' RFC 2119 keyword, line 80: '...ular object, but MAY vary across diffe...' RFC 2119 keyword, line 115: '...this document. The FEC Payload ID MUST...' RFC 2119 keyword, line 149: '...These documents MUST also specify a fo...' RFC 2119 keyword, line 160: '...sion Information MUST be defined for t...' (7 more instances...) 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 (21 November 2001) is 8193 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) == Outdated reference: A later version (-03) exists of draft-ietf-rmt-info-fec-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rmt-info-fec (ref. '1') Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 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-05.txt L.Vicisano/Cisco 4 J.Gemmell/Microsoft 5 L.Rizzo/ACIRI and Univ. Pisa 6 M.Handley/ACIRI 7 J. Crowcroft/UCL 8 21 November 2001 9 Expires: May 2002 11 RMT BB Forward Error Correction Codes 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are valid for a maximum of six months and may be 21 updated, replaced, or obsoleted by other documents at any time. It is 22 inappropriate to use Internet-Drafts as reference material or to cite 23 them other than as a "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 This document is a product of the IETF RMT WG. Comments should be 32 addressed to the authors, or the WG's mailing list at rmt@isi.edu. 34 Abstract 36 This memo describes the abstract packet formats and IANA 37 registration procedures for use of Forward Error Correction 38 (FEC) codes within the context of reliable IP multicast 39 transport. This memo should be read in conjunction with and 40 uses the terminology of the companion memo [1], which 41 describes the use of Forward Error Correction (FEC) codes 42 within the context of reliable IP multicast transport and 44 ^L 45 provides an introduction to some commonly used FEC codes. 47 1. FEC Abstract Packet Fields and Out-of-Band Information 49 This section describes FEC information that is either to be sent out-of- 50 band or in packets. The FEC information is associated with transmission 51 of data about a particular object. There are three classes of packets 52 that may contain FEC information: data packets, session-control packets 53 and feedback packets. They generally contain different kinds of FEC 54 information. Note that some protocols may not use session-control or 55 feedback packets. 57 Data packets may sometimes serve as session-control packets as well; 58 both data and session-control packets generally travel downstream from 59 the sender towards receivers and are sent to a multicast channel or to a 60 specific receiver using unicast. 62 As a general rule, feedback packets travel upstream from receivers to 63 the sender. Sometimes, however, they might be sent to a multicast 64 channel or to another receiver or to some intermediate node or 65 neighboring router that provides recovery services. 67 This document specifies the FEC information that must be carried in data 68 packets and the other FEC information that must be communicated either 69 out-of-band or in data packets. This document does not specify out-of- 70 band methods nor does it specify the way out-of-band FEC information is 71 associated with FEC information carried in data packets. These methods 72 must be specified in a complete protocol instantiation that uses the FEC 73 building block. FEC information is classified as follows: 75 1) FEC Encoding ID 77 Identifies the FEC encoder being used and allows receivers to 78 select the appropriate FEC decoder. The value of the FEC Encoding 79 ID MUST be the same for all transmission of data related to a 80 particular object, but MAY vary across different transmissions of 81 data about different objects, even if transmitted to the same set 82 of multicast channels and/or using a single upper-layer session. 83 The FEC encoding ID is subject to IANA registration. 85 2) FEC Encoding Name 87 Provides a more specific identification of the FEC encoder being 88 used for an Under-Specified FEC scheme. This value is not used 89 for Fully-Specified FEC schemes. (See Section 1.1 for the 90 definition of Under-Specified and Fully-Specified FEC schemes.) 92 ^L 93 The FEC encoding name is scoped by the FEC encoding ID, and is 94 subject to IANA registration. 96 3) FEC payload ID 98 Identifies the encoding symbol(s) in the payload of the packet. 99 The fields in the FEC Payload ID depend on the encoder being used 100 (e.g. in Block and Expandable FEC codes this may be the 101 combination of block number and encoding symbol ID). 103 4) FEC Object Transmission Information 105 This is information regarding the encoding of a specific object 106 needed by the FEC decoder (e.g. for Block and Expandable FEC codes 107 this may be the combination of the source block lengths and the 108 object length). This might also include specific parameters of 109 the FEC encoder. 111 The FEC Encoding ID, FEC Encoding Name (for Under-Specified FEC schemes) 112 and the FEC Object Transmission Information can be sent to a receiver 113 within the data packet headers, within session control packets, or by 114 some other means. In any case, the means for communicating this to a 115 receiver is out of the scope of this document. The FEC Payload ID MUST 116 be included in the data packet header fields, as it provides a 117 description of the data contained in the packet. 119 Within the context of FEC repair schemes, feedback packets are 120 (optionally) used to request FEC retransmission. The FEC-related 121 information present in feedback packets usually contains an FEC Block ID 122 that defines the block that is being repaired, and the number of Repair 123 Symbols requested. Although this is the most common case, variants are 124 possible in which the receivers provide more specific information about 125 the Repair Symbols requested (e.g. an index range or a list of symbols 126 accepted). It is also possible to include multiple of these requests in 127 a single feedback packet. 129 This document does not provide any detail about feedback schemes used in 130 combination with FEC nor the format of FEC information in feedback 131 packets. If feedback packets are used in a complete protocol 132 instantiation, these details must be provided in the protocol 133 instantiation specification. 135 1.1. FEC Encoding ID and FEC Encoding Name 137 The FEC Encoding ID is a numeric index that identifies a specific FEC 139 ^L 140 scheme OR a class of encoding schemes that share the same FEC Payload ID 141 format. 143 An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is 144 formally and fully specified, in a way that independent implementors can 145 implement both encoder and decoder from a specification that is an IETF 146 RFC. The FEC Encoding ID uniquely identifies a Fully-Specified FEC 147 scheme. Companion documents of this specification may specify Fully- 148 Specified FEC schemes and associate them with FEC Encoding ID values. 149 These documents MUST also specify a format for the FEC Payload ID and 150 specify the information in the FEC Object Transmission Information. 152 It is possible that a FEC scheme cannot be a Fully-Specified FEC scheme, 153 because a specification is simply not available or that a party exists 154 that owns the encoding scheme and is not willing to disclose the 155 algorithm or specification. We refer to such an FEC encoding schemes as 156 an Under-Specified FEC scheme. The following holds for an Under- 157 Specified FEC scheme: 159 o The format of the FEC Payload ID and the specific information in the 160 FEC Object Transmission Information MUST be defined for the Under- 161 Specified FEC scheme. 163 o A value for the FEC Encoding ID MUST be reserved and associated with 164 the format of the FEC Payload ID and the specific information in the 165 FEC Object Transmission Information. An already reserved FEC 166 Encoding ID value MUST be reused if it is associated with the same 167 format of FEC Payload ID and the same information in the FEC Object 168 Transmission Information as the ones needed for the new Under- 169 Specified FEC scheme. 171 o A value for the FEC Encoding Name MUST be reserved. 173 An Under-specified FEC scheme is fully identified by the tuple (FEC 174 Encoding ID, FEC Encoding Name). The tuple MUST identify a single scheme 175 that has at least one implementation. The party that owns this tuple 176 MUST be able to provide information on how to obtain the Under-Specified 177 FEC scheme identified by the tuple, e.g. a pointer to a publicly 178 available reference-implementation or the name and contacts of a company 179 that sells it, either separately or embedded in another product. 181 Different Under-Specified FEC schemes that share the same FEC Encoding 182 ID -- but have different FEC Encoding Names -- also share the same 183 format of FEC Payload ID and specify the same information in the FEC 184 Object Transmission Information. 186 This specification reserves the range 0-127 for the values of FEC 188 ^L 189 Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for 190 the values of Under-Specified FEC schemes. 192 1.2. FEC Payload ID and FEC Object Transmission Information 194 A document that specifies an FEC scheme and reserves a value of FEC 195 Encoding ID MUST define a packet format for the FEC Payload ID and 196 specify the information in the FEC Object Transmission Information 197 according to the needs of the encoding scheme. This applies to documents 198 that reserve values of FEC Encoding IDs for both Fully-Specified and 199 Under-Specified FEC schemes. 201 The packet format definition for the FEC Payload ID MUST specify the 202 meaning and layout of the fields down to the level of specific bits. 203 The FEC Payload ID MUST have a length that is a multiple of a 4-byte 204 word. This requirement facilitates the alignment of packet fields in 205 protocol instantiations. 207 2. Preassigned FEC Encoding IDs 209 This section specifies the FEC Encoding ID and the associated FEC 210 Payload ID format and the specific information in the FEC Object 211 Transmission Information for a number of known Under-Specified FEC 212 schemes. Under-specified FEC schemes that use the same FEC Payload ID 213 format and specific information in the FEC Object Transmission 214 Information as for one of the FEC Encoding IDs specified in this section 215 MUST use the corresponding FEC Encoding ID. Other FEC Encoding IDs may 216 be specified for other Under-Specified FEC schemes in companion 217 documents. 219 2.1. Small Block, Large Block and Expandable FEC Codes 221 This subsection reserves the FEC Encoding ID value 128 for the Under- 222 Specified FEC schemes described in [1] that are called Small Block FEC 223 codes, Large Block FEC codes and Expandable FEC codes. 225 The FEC Payload ID is composed of a Source Block Number and an Encoding 226 Symbol ID structured as follows: 228 ^L 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Source Block Number | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Encoding Symbol ID | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 The Source Block Number idenfities from which source block of the object 238 the encoding symbol(s) in the payload are generated. These blocks are 239 numbered consecutively from 0 to N-1, where N is the number of source 240 blocks in the object. 242 The Encoding Symbol ID identifies which specific encoding symbol(s) 243 generated from the source block are carried in the packet payload. The 244 exact details of the correspondence between Encoding Symbol IDs and the 245 encoding symbol(s) in the packet payload are dependent on the particular 246 encoding algorithm used as identified by the Fec Encoding ID and by the 247 FEC Encoding Name, and these details may be proprietary. 249 The FEC Object Transmission Information has the following specific 250 information: 252 o The total length of the object in bytes. 254 o The number of source blocks that the object is partitioned into, and 255 the length of each source block in bytes. 257 How this out of band information is communicated is outside the scope of 258 this document. As an example the source block lengths may be derived by 259 a fixed algorithm from the object length. As another example, it may be 260 that all source blocks are the same length and this is what is passed 261 out of band to the receiver. As a third example, it could be that the 262 full sized source block length is provided and this is the length used 263 for all but the last source block, which is calculated based on the full 264 source block length and the object length. 266 2.2. Small Block Systematic FEC Codes 268 This subsection reserves the FEC Encoding ID value 129 for the Under- 269 Specified FEC schemes described in [1] that are called Small Block 270 Systematic FEC codes. For Small Block Systematic FEC codes, each source 271 block is of length at most 65536 source symbols. 273 ^L 274 Although these codes can generally be accommodated by the FEC Encoding 275 ID described in Section 2.1, a specific FEC Encoding ID is defined for 276 Small Block Systematic FEC codes to allow more flexibility and to retain 277 header compactness. The small source block length and small expansion 278 factor that often characterize systematic codes may require that the 279 data source changes frequently the source block length. To allow the 280 dynamic variation of the source block length and to communicate it to 281 the receivers with low overhead, the block length is included in the FEC 282 Payload ID. 284 The FEC Payload ID is composed of the Source Block Number, Source Block 285 Length and the Encoding Symbol ID: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Source Block Number | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Source Block Length | Encoding Symbol ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 The Source Block Number idenfities from which source block of the object 296 the encoding symbol(s) in the payload are generated. These blocks are 297 numbered consecutively from 0 to N-1, where N is the number of source 298 blocks in the object. 300 The Source Block Length is the length in units of source symbols of the 301 source block identified by the Source Block Number. 303 The Encoding Symbol ID identifies which specific encoding symbol(s) 304 generated from the source block are carried in the packet payload. Each 305 encoding symbol is either an original source symbol or a redundant 306 symbol generated by the encoder. The exact details of the 307 correspondence between Encoding Symbol IDs and the encoding symbol(s) in 308 the packet payload are dependent on the particular encoding algorithm 309 used as identified by the Fec Encoding ID and by the FEC Encoding Name, 310 and these details may be proprietary. 312 The FEC Object Transmission Information has the following specific 313 information: 315 o The total length of the object in bytes. 317 o The maximum number of encoding symbols that can be generated for any 318 source block. This field is provided for example to allow receivers 320 ^L 321 to preallocate buffer space that is suitable for decoding to recover 322 any source block. 324 o For each source block, the length in bytes of encoding symbols for 325 the source block. 327 How this out of band information is communicated is outside the scope of 328 this document. As an example the length in bytes of encoding symbols 329 for each source block may be the same for all source blocks. As another 330 example, the encoding symbol length may be the same for all source 331 blocks of a given object and this length is communicated for each 332 object. As a third example, it may be that there is a threshold value 333 I, and for all source blocks consisting of less than I source symbols, 334 the encoding symbol length is one fixed number of bytes, but for all 335 source blocks consisting of I or more source symbols, the encoding 336 symbol length is a different fixed number of bytes. 338 Note that each encoding symbol, i.e., each source symbol and redundant 339 symbol, must be the same length for a given source block, and this 340 implies that each source block length is a multiple of its encoding 341 symbol length. If the original source block length is not a multiple of 342 the encodin symbol length, it is up to the sending application to 343 appropriately pad the original source block to form the source block to 344 be encoded, and to communicate this padding to the receiving 345 application. The form of this padding, if used, and how it is 346 communicated to the receiving application, is out of the scope of this 347 document, and must be handled at the application level. 349 3. IANA Considerations 351 Values of FEC Encoding IDs and FEC Encoding Names are subject to IANA 352 registration. FEC Encoding IDs and FEC Encoding Names are hierarchical: 353 FEC Encoding IDs scope ranges of FEC Encoding Names. Only FEC Encoding 354 IDs that correspond to Under-Specified FEC schemes scope a corresponding 355 set of FEC Encoding Names. 357 The FEC Encoding ID is a numeric non-negative index. In this document, 358 the range of values for FEC Encoding IDs is 0 and 255. Values from 0 to 359 127 are reserved for Fully-Specified FEC schemes, as described in more 360 detail in Section 1.1. The assignment of a FEC Encoding ID in this range 361 can only be granted if the requestor can provide such a specification 362 published as an IETF RFC, as described in more detail in Section 1.1. 363 Values from 128 to 255 are reserved for Under-Specified FEC schemes, as 364 described in more detail in Section 1.1. This specification already 365 assigns the values 128 and 129, as described in Section 2. 367 ^L 368 Values of FEC Encoding IDs can only be assigned if the required format 369 for the FEC Payload ID and the specific information in the FEC Object 370 Transmission Information are specified in an IETF RFC. 372 Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an 373 independent range of FEC Encoding Names (i.e. the same value of FEC 374 Encoding Name can be reused for different FEC Encoding IDs). An FEC 375 Encoding Name is a numeric non-negative index. 377 Under the scope of a FEC Encoding ID, FEC Encoding Names are assigned on 378 a First Come First Served base to requestors that are able to provide 379 point of contact information and a pointer to publicly accessible 380 documentation describing the Under-Specified FEC scheme and ways to 381 obtain it (e.g. a pointer to a publicly available reference- 382 implementation or the name and contacts of a company that sells it, 383 either separately or embedded in another product). The requestor is 384 responsible for keeping this information up to date. 386 4. Acknowledgments 388 Brian Adamson contributed to this document by shaping Section 2.2 and 389 providing general feedback. We also wish to thank Vincent Roca for his 390 extensive comments and Justin Chapweske for his comments. 392 5. References 394 [1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M., 395 Crowcroft, J., "The use of Forward Error Correction in Reliable 396 Multicast", Internet draft draft-ietf-rmt-info-fec-01.txt, October 2001. 398 6. Authors' Addresses 400 Michael Luby 401 luby@digitalfountain.com 402 Digital Fountain, Inc. 403 39141 Civic Center Drive 404 Suite 300 405 Fremont, CA 94538 407 Lorenzo Vicisano 408 lorenzo@cisco.com 409 cisco Systems, Inc. 410 170 West Tasman Dr., 411 San Jose, CA, USA, 95134 413 ^L 414 Jim Gemmell 415 jgemmell@microsoft.com 416 Microsoft Research 417 301 Howard St., #830 418 San Francisco, CA, USA, 94105 420 Luigi Rizzo 421 luigi@iet.unipi.it 422 ACIRI, 1947 Center St., Berkeley CA 94704 423 and 424 Dip. di Ing. dell'Informazione 425 Universita` di Pisa 426 via Diotisalvi 2, 56126 Pisa, Italy 428 Mark Handley 429 mjh@aciri.org 430 ACIRI 431 1947 Center St. 432 Berkeley CA, USA, 94704 434 Jon Crowcroft 435 J.Crowcroft@cs.ucl.ac.uk 436 Department of Computer Science 437 University College London 438 Gower Street, 439 London WC1E 6BT, UK 441 ^L 443 7. Full Copyright Statement 445 Copyright (C) The Internet Society (2001). All Rights Reserved. 447 This document and translations of it may be copied and furnished to 448 others, and derivative works that comment on or otherwise explain it or 449 assist in its implementation may be prepared, copied, published and 450 distributed, in whole or in part, without restriction of any kind, 451 provided that the above copyright notice and this paragraph are included 452 on all such copies and derivative works. However, this document itself 453 may not be modified in any way, such as by removing the copyright notice 454 or references to the Internet Society or other Internet organizations, 455 except as needed for the purpose of developing Internet standards in 456 which case the procedures for copyrights defined in the Internet 457 languages other than English. 459 The limited permissions granted above are perpetual and will not be 460 revoked by the Internet Society or its successors or assigns. 462 This document and the information contained herein is provided on an "AS 463 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 464 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 465 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 466 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 467 FITNESS FOR A PARTICULAR PURPOSE." 469 ^L