idnits 2.17.1 draft-ietf-rmt-bb-fec-04.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 77: '... ID MUST be the same for all tran...' RFC 2119 keyword, line 78: '...ular object, but MAY vary across diffe...' RFC 2119 keyword, line 111: '...his document. The FEC Payload ID MUST...' RFC 2119 keyword, line 143: '...These documents MUST also specify a fo...' RFC 2119 keyword, line 154: '...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 (18 October 2001) is 8224 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: 9 errors (**), 0 flaws (~~), 3 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-04.txt L.Vicisano/Cisco 4 J.Gemmell/Microsoft 5 L.Rizzo/ACIRI and Univ. Pisa 6 M.Handley/ACIRI 7 J. Crowcroft/UCL 8 18 October 2001 9 Expires: April 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 43 provides an introduction to some commonly used FEC codes. 45 1. FEC Abstract Packet Fields and Out-of-Band Information 47 This section describes FEC information that is either to be sent out-of- 48 band or in packets. The FEC information is associated with transmission 49 of data about a particular object. There are three classes of packets 50 that may contain FEC information: data packets, session-control packets 51 and feedback packets. They generally contain different kinds of FEC 52 information. Note that some protocols may not use session-control or 53 feedback packets. 55 Data packets may sometimes serve as session-control packets as well; 56 both data and session-control packets generally travel downstream from 57 the sender towards receivers and are sent to a multicast channel or to a 58 specific receiver using unicast. 60 As a general rule, feedback packets travel upstream from receivers to 61 the sender. Sometimes, however, they might be sent to a multicast 62 channel or to another receiver or to some intermediate node or 63 neighboring router that provides recovery services. 65 This document specifies the FEC information that must be carried in data 66 packets and the other FEC information that must be communicated either 67 out-of-band or in data packets. This document does not specify out-of- 68 band methods nor does it specify the way out-of-band FEC information is 69 associated with FEC information carried in data packets. These methods 70 must be specified in a complete protocol instantiation that uses the FEC 71 building block. FEC information is classified as follows: 73 1) FEC Encoding ID 75 Identifies the FEC encoder being used and allows receivers to 76 select the appropriate FEC decoder. The value of the FEC Encoding 77 ID MUST be the same for all transmission of data related to a 78 particular object, but MAY vary across different transmissions of 79 data about different objects, even if transmitted to the same set 80 of multicast channels and/or using a single upper-layer session. 81 The FEC encoding ID is subject to IANA registration. 83 2) FEC Encoding Name 85 Provides a more specific identification of the FEC encoder being 86 used for an Under-Specified FEC scheme. This value is not used 87 for Fully-Specified FEC schemes. (See Section 1.1 for the 88 definition of Under-Specified and Fully-Specified FEC schemes.) 89 The FEC encoding name is scoped by the FEC encoding ID, and is 90 subject to IANA registration. 92 3) FEC payload ID 94 Identifies the encoding symbol(s) in the payload of the packet. 95 The fields in the FEC Payload ID depend on the encoder being used 96 (e.g. in Block and Expandable FEC codes this may be the 97 combination of block number and encoding symbol ID). 99 4) FEC Object Transmission Information 101 This is information regarding the encoding of a specific object 102 needed by the FEC decoder (e.g. for Block and Expandable FEC codes 103 this may be the combination of the source block lengths and the 104 object length). This might also include specific parameters of 105 the FEC encoder. 107 The FEC Encoding ID, FEC Encoding Name (for Under-Specified FEC schemes) 108 and the FEC Object Transmission Information can be sent to a receiver 109 within the data packet headers, within session control packets, or by 110 some other means. In any case, the means for communicating this to a 111 receiver is out of the scope of this document. The FEC Payload ID MUST 112 be included in the data packet header fields, as it provides a 113 description of the data contained in the packet. 115 Within the context of FEC repair schemes, feedback packets are 116 (optionally) used to request FEC retransmission. The FEC-related 117 information present in feedback packets usually contains an FEC Block ID 118 that defines the block that is being repaired, and the number of Repair 119 Symbols requested. Although this is the most common case, variants are 120 possible in which the receivers provide more specific information about 121 the Repair Symbols requested (e.g. an index range or a list of symbols 122 accepted). It is also possible to include multiple of these requests in 123 a single feedback packet. 125 This document does not provide any detail about feedback schemes used in 126 combination with FEC nor the format of FEC information in feedback 127 packets. If feedback packets are used in a complete protocol 128 instantiation, these details must be provided in the protocol 129 instantiation specification. 131 1.1. FEC Encoding ID and FEC Encoding Name 133 The FEC Encoding ID is a numeric index that identifies a specific FEC 134 scheme OR a class of encoding schemes that share the same FEC Payload ID 135 format. 137 An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is 138 formally and fully specified, in a way that independent implementors can 139 implement both encoder and decoder from a specification that is an IETF 140 RFC. The FEC Encoding ID uniquely identifies a Fully-Specified FEC 141 scheme. Companion documents of this specification may specify Fully- 142 Specified FEC schemes and associate them with FEC Encoding ID values. 143 These documents MUST also specify a format for the FEC Payload ID and 144 specify the information in the FEC Object Transmission Information. 146 It is possible that a FEC scheme cannot be a Fully-Specified FEC scheme, 147 because a specification is simply not available or that a party exists 148 that owns the encoding scheme and is not willing to disclose the 149 algorithm or specification. We refer to such an FEC encoding schemes as 150 an Under-Specified FEC scheme. The following holds for an Under- 151 Specified FEC scheme: 153 o The format of the FEC Payload ID and the specific information in the 154 FEC Object Transmission Information MUST be defined for the Under- 155 Specified FEC scheme. 157 o A value for the FEC Encoding ID MUST be reserved and associated with 158 the format of the FEC Payload ID and the specific information in the 159 FEC Object Transmission Information. An already reserved FEC 160 Encoding ID value MUST be reused if it is associated with the same 161 format of FEC Payload ID and the same information in the FEC Object 162 Transmission Information as the ones needed for the new Under- 163 Specified FEC scheme. 165 o A value for the FEC Encoding Name MUST be reserved. 167 An Under-specified FEC scheme is fully identified by the tuple (FEC 168 Encoding ID, FEC Encoding Name). The tuple MUST identify a single scheme 169 that has at least one implementation. The party that owns this tuple 170 MUST be able to provide information on how to obtain the Under-Specified 171 FEC scheme identified by the tuple, e.g. a pointer to a publicly 172 available reference-implementation or the name and contacts of a company 173 that sells it, either separately or embedded in another product. 175 Different Under-Specified FEC schemes that share the same FEC Encoding 176 ID -- but have different FEC Encoding Names -- also share the same 177 format of FEC Payload ID and specify the same information in the FEC 178 Object Transmission Information. 180 This specification reserves the range 0-127 for the values of FEC 181 Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for 182 the values of Under-Specified FEC schemes. 184 1.2. FEC Payload ID and FEC Object Transmission Information 186 A document that specifies an FEC scheme and reserves a value of FEC 187 Encoding ID MUST define a packet format for the FEC Payload ID and 188 specify the information in the FEC Object Transmission Information 189 according to the needs of the encoding scheme. This applies to documents 190 that reserve values of FEC Encoding IDs for both Fully-Specified and 191 Under-Specified FEC schemes. 193 The packet format definition for the FEC Payload ID MUST specify the 194 meaning and layout of the fields down to the level of specific bits. 195 The FEC Payload ID MUST have a length that is a multiple of a 4-byte 196 word. This requirement facilitates the alignment of packet fields in 197 protocol instantiations. 199 2. Preassigned FEC Encoding IDs 201 This section specifies the FEC Encoding ID and the associated FEC 202 Payload ID format and the specific information in the FEC Object 203 Transmission Information for a number of known Under-Specified FEC 204 schemes. Under-specified FEC schemes that use the same FEC Payload ID 205 format and specific information in the FEC Object Transmission 206 Information as for one of the FEC Encoding IDs specified in this section 207 MUST use the corresponding FEC Encoding ID. Other FEC Encoding IDs may 208 be specified for other Under-Specified FEC schemes in companion 209 documents. 211 2.1. Small Block, Large Block and Expandable FEC Codes 213 This subsection reserves the FEC Encoding ID value 128 for the Under- 214 Specified FEC schemes described in [1] that are called Small Block FEC 215 codes, Large Block FEC codes and Expandable FEC codes. 217 The FEC Payload ID is composed of a Source Block Number and an Encoding 218 Symbol ID structured as follows: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Source Block Number | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Encoding Symbol ID | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 The Source Block Number idenfities from which source block of the object 229 the encoding symbol(s) in the payload are generated. These blocks are 230 numbered consecutively from 0 to N-1, where N is the number of source 231 blocks in the object. 233 The Encoding Symbol ID identifies which specific encoding symbol(s) 234 generated from the source block are carried in the packet payload. The 235 exact details of the correspondence between Encoding Symbol IDs and the 236 encoding symbol(s) in the packet payload are dependent on the particular 237 encoding algorithm used as identified by the Fec Encoding ID and by the 238 FEC Encoding Name, and these details may be proprietary. 240 The FEC Object Transmission Information has the following specific 241 information: 243 o The total length of the object in bytes. 245 o The number of source blocks that the object is partitioned into, and 246 the length of each source block in bytes. 248 2.2. Small Block Systematic FEC Codes 250 This subsection reserves the FEC Encoding ID value 129 for the Under- 251 Specified FEC schemes described in [1] that are called Small Block 252 Systematic FEC codes. For Small Block Systematic FEC codes, each source 253 block is of length at most 65536 bytes. 255 Although these codes can generally be accommodated by the FEC Encoding 256 ID described in Section 2.1, a specific FEC Encoding ID is defined for 257 Small Block Systematic FEC codes to allow more flexibility and to retain 258 header compactness. The small source block length and small exapansion 259 factor that often characterize systematic codes may require that the 260 data source changes frequently the source block length. To allow the 261 dynamic variation of the source block length and to communicate it to 262 the receivers with low overhead, the block length is included in the FEC 263 Payload ID. 265 The FEC Payload ID is composed of the Source Block Number, Source Block 266 Length and the Encoding Symbol ID: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Source Block Number | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Source Block Length | Encoding Symbol ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 The Source Block Number idenfities from which source block of the object 277 the encoding symbol(s) in the payload are generated. These blocks are 278 numbered consecutively from 0 to N-1, where N is the number of source 279 blocks in the object. 281 The Source Block Length is the length in units of source symbols of the 282 source block identified by the Source Block Number. 284 The Encoding Symbol ID identifies which specific encoding symbol(s) 285 generated from the source block are carried in the packet payload. The 286 exact details of the correspondence between Encoding Symbol IDs and the 287 encoding symbol(s) in the packet payload are dependent on the particular 288 encoding algorithm used as identified by the Fec Encoding ID and by the 289 FEC Encoding Name, and these details may be proprietary. 291 The FEC Object Transmission Information has the following specific 292 information: 294 o The total length of the object in bytes. 296 o The maximum length in bytes of the encoding symbols that can be 297 generated for any source block. This field is provided to allow 298 receivers to preallocate buffer space that is suitable for decoding 299 to recover any source block. 301 o The length in bytes of a source symbol. 303 3. IANA Considerations 305 Values of FEC Encoding IDs and FEC Encoding Names are subject to IANA 306 registration. FEC Encoding IDs and FEC Encoding Names are hierarchical: 307 FEC Encoding IDs scope ranges of FEC Encoding Names. Only FEC Encoding 308 IDs that correspond to Under-Specified FEC schemes scope a corresponding 309 set of FEC Encoding Names. 311 The FEC Encoding ID is a numeric non-negative index. In this document, 312 the range of values for FEC Encoding IDs is 0 and 255. Values from 0 to 313 127 are reserved for Fully-Specified FEC schemes, as described in more 314 detail in Section 1.1. The assignment of a FEC Encoding ID in this range 315 can only be granted if the requestor can provide such a specification 316 published as an IETF RFC, as described in more detail in Section 1.1. 317 Values from 128 to 255 are reserved for Under-Specified FEC schemes, as 318 described in more detail in Section 1.1. This specification already 319 assigns the values 128 and 129, as described in Section 2. 321 Values of FEC Encoding IDs can only be assigned if the required format 322 for the FEC Payload ID and the specific information in the FEC Object 323 Transmission Information are specified in an IETF RFC. 325 Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an 326 independent range of FEC Encoding Names (i.e. the same value of FEC 327 Encoding Name can be reused for different FEC Encoding IDs). An FEC 328 Encoding Name is a numeric non-negative index. 330 Under the scope of a FEC Encoding ID, FEC Encoding Names are assigned on 331 a First Come First Served base to requestors that are able to provide 332 point of contact information and a pointer to publicly accessible 333 documentation describing the Under-Specified FEC scheme and ways to 334 obtain it (e.g. a pointer to a publicly available reference- 335 implementation or the name and contacts of a company that sells it, 336 either separately or embedded in another product). The requestor is 337 responsible for keeping this information up to date. 339 4. Acknowledgments 341 Brian Adamson contributed to this document by shaping Section 2.2 and 342 providing general feedback. We also wish to thank Vincent Roca and 343 Justin Chapweske for their comments. 345 5. References 347 [1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M., 348 Crowcroft, J., "The use of Forward Error Correction in Reliable 349 Multicast", Internet draft draft-ietf-rmt-info-fec-01.txt, October 2001. 351 6. Authors' Addresses 353 Michael Luby 354 luby@digitalfountain.com 355 Digital Fountain, Inc. 356 39141 Civic Center Drive 357 Suite 300 358 Fremont, CA 94538 360 Lorenzo Vicisano 361 lorenzo@cisco.com 362 cisco Systems, Inc. 363 170 West Tasman Dr., 364 San Jose, CA, USA, 95134 366 Jim Gemmell 367 jgemmell@microsoft.com 368 Microsoft Research 369 301 Howard St., #830 370 San Francisco, CA, USA, 94105 372 Luigi Rizzo 373 luigi@iet.unipi.it 374 ACIRI, 1947 Center St., Berkeley CA 94704 375 and 376 Dip. di Ing. dell'Informazione 377 Universita` di Pisa 378 via Diotisalvi 2, 56126 Pisa, Italy 380 Mark Handley 381 mjh@aciri.org 382 ACIRI 383 1947 Center St. 384 Berkeley CA, USA, 94704 386 Jon Crowcroft 387 J.Crowcroft@cs.ucl.ac.uk 388 Department of Computer Science 389 University College London 390 Gower Street, 391 London WC1E 6BT, UK 393 7. Full Copyright Statement 395 Copyright (C) The Internet Society (2001). All Rights Reserved. 397 This document and translations of it may be copied and furnished to 398 others, and derivative works that comment on or otherwise explain it or 399 assist in its implementation may be prepared, copied, published and 400 distributed, in whole or in part, without restriction of any kind, 401 provided that the above copyright notice and this paragraph are included 402 on all such copies and derivative works. However, this document itself 403 may not be modified in any way, such as by removing the copyright notice 404 or references to the Internet Society or other Internet organizations, 405 except as needed for the purpose of developing Internet standards in 406 which case the procedures for copyrights defined in the Internet 407 languages other than English. 409 The limited permissions granted above are perpetual and will not be 410 revoked by the Internet Society or its successors or assigns. 412 This document and the information contained herein is provided on an "AS 413 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 414 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 415 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 416 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 417 FITNESS FOR A PARTICULAR PURPOSE."