idnits 2.17.1 draft-ietf-rmt-bb-fec-03.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 11 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 80: '...ding Identifier" MUST be the same for ...' RFC 2119 keyword, line 82: '...ular object, but MAY vary across diffe...' RFC 2119 keyword, line 109: '...he information described in 2) MUST be...' RFC 2119 keyword, line 144: '... These documents MUST also specify a c...' RFC 2119 keyword, line 156: '... Information" MUST be defined for t...' (12 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 (19 July 2001) is 8310 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-00 ** 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-03.txt L.Vicisano/Cisco 4 J.Gemmell/Microsoft 5 L.Rizzo/ACIRI and Univ. Pisa 6 M.Handley/ACIRI 7 J. Crowcroft/UCL 8 19 July 2001 9 Expires: January 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 specifies the information that protocol packets must carry 50 to implement the various forms of FEC-based reliability. A session is 51 defined to be all the information associated with a transmission of data 52 about a particular object by a single sender. There are three classes 53 of packets that may contain FEC information within a session: data 54 packets, session-control packets and feedback packets. They generally 55 contain different kinds of FEC information. Note that some protocols do 56 not use feedback packets. 58 Data packets may sometime serve as session-control packets as well; both 59 data and session-control packets generally travel downstream (from the 60 sender towards receivers) and are addressed to a multicast IP address 61 (sometime they might be addressed to the unicast address of a specific 62 receiver). In the following, for simplicity we will refer to both data 63 and session control packets as downstream-traveling packets, or simply 64 downstream packets. 66 As a general rule, feedback packets travel upstream (from receivers to 67 the sender) and are addressed to the unicast address of the sender. 68 Sometimes, however, they might be addressed to a multicast IP address or 69 to the unicast address of a receiver or also the the unicast address of 70 some different node (an intermediate node that provides recovery 71 services or a neighboring router). 73 The FEC-related information that can be present in downstream packets 74 can be classified as follows: 76 1) FEC Encoding Identifier 78 Identifies the FEC encoding being used and has the purpose of 79 allowing receivers to select the appropriate FEC decoder. As a 80 general rule, the "FEC Encoding Identifier" MUST be the same for a 81 given session, i.e., for all transmission of data related to a 82 particular object, but MAY vary across different transmissions of 83 data about different objects in different sessions, even if 84 transmitted using the same set of multicast groups and/or using a 85 single upper-layer session. 87 2) FEC payload ID 89 Identifies the symbol(s) in the payload of the packet. The content 90 of this piece of information depends on the encoder being used 92 ^L 93 (e.g. in Block FEC codes this may be the combination of block 94 index and encoding symbol identifier; in ideal expandable FEC 95 codes this may be just a flat encoding symbol identifier). 97 3) FEC Object Transmission Information 99 This is information regarding the encoding of a specific object 100 needed by the FEC decoder (e.g. for Block FEC codes this may be 101 the combination of block length and object length). This might 102 also include general parameters of the FEC encoder. Note that, in 103 strict terms, the "FEC Encoding Identifier" belongs to this class 104 of information, however, for practical purposes, we will consider 105 it separately. 107 All the classes of information above, except 2), can either be 108 transmitted within the transport session (using protocol packet-header 109 fields) or out of band. The information described in 2) MUST be 110 transmitted in data-packet header fields, as it provides a description 111 of the data contained in the packet. In the following we will specify 112 the content of 1), 2) and 3) regardless of whether these pieces of 113 information are transmitted in protocol packets or out of band. This 114 document neither specifies out-of-band methods to transport the 115 information nor does it specify the way out-of-band information is 116 associated with packet payloads. This last task is devolved to an upper- 117 layer protocol. 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 122 Identifier, that defines the block that is being repaired, and the 123 number of Repair Symbols requested. Although this is the most common 124 case, variants are possible in which the receivers provide more specific 125 information about the Repair Symbols requested (e.g. an index range or a 126 list of symbols accepted). It is also possible to include multiple of 127 these request in a single feedback packet. 129 This document does not provide any detail about the format of FEC 130 information in feedback packets. 132 1.1. FEC Encoding Identifier 134 This is a numeric index that identifies a specific FEC scheme OR a class 135 of encoding schemes that share the same format of "FEC Payload ID" and 136 "FEC Object Transmission Information". 138 ^L 139 The FEC Encoding Identifier identifies a specific FEC scheme when the 140 encoding scheme is formally and fully specified, in a way that 141 independent implementors can implement both encoder and decoder from the 142 specification. Companion documents of this specification may specify 143 such FEC schemes and associate them with "FEC Encoding Identifier" 144 values. These documents MUST also specify a correspondent format for the 145 "FEC Payload ID" and "FEC Object Transmission Information". Currently 146 FEC Encoding Identifiers in the range 0-127 are reserved for this class 147 of encoding schemes (fully-specified schemes). 149 It is possible that a FEC scheme cannot be completely specified or that 150 such a specification is simply not available or also that a party exists 151 that owns the encoding scheme and it is not willing to disclose its 152 algorithm. We refer to these encoding schemes as "Under-Specified" 153 schemes. Under-specified schemes can still be identified as follows: 155 o A format of the fields "FEC Payload ID" and "FEC Object Transmission 156 Information" MUST be defined for the encoding scheme. 158 o A value of "FEC Encoding Identifier" MUST be reserved and associated 159 to the format definitions above. An already reserved "FEC Encoding 160 Identifier" MUST be reused if it is associated to the same format 161 of "FEC Payload ID" and "FEC Object Transmission Information" as the 162 ones needed for the new under-specified FEC scheme. 164 o A value of "FEC Encoding Name" must be reserved (see below). 166 An Under-specified FEC scheme is completely identified by the tuple (FEC 167 Encoding Identifier, FEC Encoding Name). The tuple MUST identify a 168 single scheme that has at least one implementation. The party that owns 169 this tuple MUST be able to provide information on how to obtain the 170 under-specified FEC scheme identified by the tuple (e.g. a pointer to a 171 publicly available reference-implementation or the name and contacts of 172 a company that sells it, either separately or embedded in another 173 product). 175 "FEC Encoding Names" are numeric identifiers scoped by a FEC Encoding 176 Identifier. 178 The FEC Encoding Name MUST be part of the "FEC Object Transmission 179 Information" and must be communicated to receivers together with the FEC 180 Encoding Identifier. 182 Different FEC schemes that share the same FEC Encoding Identifier -- but 183 have different FEC Encoding Names -- also share the same format of FEC 184 Payload ID and FEC Object Transmission Information. 186 ^L 187 This specification reserves the range 0-127 of FEC Encoding Identifiers 188 for fully-specified encoding schemes and the range 128-255 for under- 189 specified encoding schemes. 191 1.2. FEC Payload ID and FEC Object Transmission Information 193 A document that specifies an encoding scheme and reserves a value 194 of FEC Encoding Identifier MUST define a packet-field format for FEC 195 Payload ID and FEC Object Transmission Information according to the need 196 of the encoding scheme. This also applies to documents that reserves 197 values of FEC Encoding Identifiers for under-specified encoding schemes. 198 In this case the FEC Object Transmission Information must also include a 199 field to contain the "FEC Encoding Name". 201 A packet field definition of FEC Object Transmission Information MUST be 202 provided despite the fact that a protocol instantiation may decide to 203 communicate this information out of band. 205 All packet field definitions (FEC Payload ID and FEC Object Transmission 206 Information) MUST be fully specified at the level of bit-fields and they 207 must have a length that is a multiple of a 4-byte word (this is to 208 facilitate the alignment of packet fields in protocol instantiations). 210 Note that the specification of FEC Payload ID MUST allow an 211 implementation-independent identification of the packet payload even in 212 the case of Under-Specified encoding schemes. 214 2. Preassigned FEC Encoding Identifiers 216 This section specifies the FEC Encoding Identifier and the relative 217 packets field for a number of known schemes that follow under the class 218 of under-specified FEC schemes. Others may be specified in companion 219 documents. 221 2.1. Small Block, Large Block and Expandable FEC Codes 223 This section reserves a FEC Encoding Identifier for the families of 224 codes described in [1], and specifies the relative packet fields. 225 Under-specified FEC schemes that belong to this class MUST use this 226 identifier and packet field definitions. 228 The FEC Encoding Identifier for under specified codes assigned to Small 229 Block, Large Block, and Expandable FEC Codes is 128. 231 ^L 232 The FEC Payload ID is composed of an encoding symbol identifier and an 233 encoding block number structured as follows: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | encoding block number | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | encoding symbol ID | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 In addition, a one bit FEC Encoding Flag MAY be included, and this flag 244 indicates whether the encoding symbol(s) in the payload of the packet 245 are source symbol(s) or redundant symbol(s). 247 The FEC Object Transmission Information has the following structure: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | FEC Encoding Name | Object Length (MSB) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Object Length (LSB) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Source Block Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Note that this structure limits the range of possible FEC Encoding Names 260 to 0-:-65536, despite the fact that the FEC Object Transmission 261 Information can also be transmitted out of band. 263 The Object Length, composed of a Most Significant Bytes portion (MSB) 264 and a Least Significant Bytes portion (LSB), is expressed in bytes. 266 2.2. Small Block Systematic FEC Codes 268 The following definitions apply to systematic codes of small length 269 (total block length < 2^16). 271 The FEC Encoding Identifier for under specified codes assigned to Small 272 Block Systematic FEC Codes is 129. 274 Although these codes can generally be accommodated by the FEC Encoding 276 ^L 277 Identifier described in Section 2.1, a specific Encoding-ID is defined 278 for systematic codes to allow better flexibility and to retain header 279 compactness. The small source block length and small exapansion factor 280 that often characterize systematic codes may require that the data 281 source changes frequently the source block length. To allow the dynamic 282 variation of the source block length and to communicate it to the 283 receivers with low overhead, the block length is included in the FEC 284 Payload ID. 286 The FEC Payload ID is composed of the encoding block number, the 287 encoding symbol identifier and the block length: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | encoding block number | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Source block length | encoding symbol ID | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 The FEC Object Transmission Information, when used, has the following 298 structure: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | FEC Encoding Name | Number of redundant symbols | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 When variable block-length is used, the number of redundant symbols is 307 to be interpreted as a maximum value (upper bound). This field is 308 provided as an indication to allow receives to preallocate a decoder 309 suitable for all the object blocks. 311 Note that this structure limits the range of possible FEC Encoding Names 312 to 0-:-65536, despite the FEC Object Transmission Information can also 313 be transmitted out of band. 315 3. IANA Considerations 317 Values of FEC Encoding Identifiers and FEC Encoding Names are subject to 318 IANA registration. FEC Encoding Identifiers and FEC Encoding Names are 319 hierarchical: FEC Encoding Identifiers (at the top level) scope ranges 321 ^L 322 of FEC Encoding Names. Not all FEC Encoding Identifiers have a 323 corresponding FEC Encoding Name scope (see below). 325 A FEC Encoding Identifier is a numeric non-negative index. Value from 0 326 to 127 are reserved for FEC encoders that are fully specified, as 327 described in section 3.1. The assignment of a FEC Encoding Identifier in 328 this range can only be granted if the requestor can provide such a 329 specification published as an IETF RFC. Values greater than 127 can be 330 assigned to under-specified encoding schemes. Note: this specification 331 already assigns the values 128 and 129. 333 In any case values of FEC Encoding Identifiers can only be assigned if 334 the required FEC packet fields corresponding to it (see section 1.2) are 335 specified in a RFC. 337 Each FEC Encoding Identifier assigned to an under-specified encoding 338 scheme scopes an independent range of FEC Encoding Names (i.e. the same 339 value of FEC Encoding Name can be reused for different FEC Encoding 340 Identifiers). An FEC Encoding Name is a numeric non-negative index. The 341 document that reserves a FEC Encoding Identifier MAY also specify a 342 range for the subordinate FEC Encoding Names. 344 Under the scope of a FEC Encoding Identifier, FEC Encoding Names are 345 assigned on a First Come First Served base to requestors that are able 346 to provide point of contact information and a pointer to publicly 347 accessible documentation describing the FEC scheme and ways to obtain it 348 (e.g. a pointer to a publicly available reference-implementation or the 349 name and contacts of a company that sells it, either separately or 350 embedded in another product). The requestor is responsible for keeping 351 this information up to date. 353 4. Acknowledgments 355 Brian Adamson contributed to this document by shaping Section 2.2 and 356 providing general feedback. We also wish to thank Vincent Roca for his 357 comments. 359 5. References 361 [1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M., 362 Crowcroft, J., "The use of Forward Error Correction in Reliable 363 Multicast", Internet draft draft-ietf-rmt-info-fec-00.txt, November 364 2000. 366 ^L 367 6. Authors' Addresses 369 Michael Luby 370 luby@digitalfountain.com 371 Digital Fountain, Inc. 372 39141 Civic Center Drive 373 Suite 300 374 Fremont, CA 94538 376 Lorenzo Vicisano 377 lorenzo@cisco.com 378 cisco Systems, Inc. 379 170 West Tasman Dr., 380 San Jose, CA, USA, 95134 382 Jim Gemmell 383 jgemmell@microsoft.com 384 Microsoft Research 385 301 Howard St., #830 386 San Francisco, CA, USA, 94105 388 Luigi Rizzo 389 luigi@iet.unipi.it 390 ACIRI, 1947 Center St., Berkeley CA 94704 391 and 392 Dip. di Ing. dell'Informazione 393 Universita` di Pisa 394 via Diotisalvi 2, 56126 Pisa, Italy 396 Mark Handley 397 mjh@aciri.org 398 ACIRI 399 1947 Center St. 400 Berkeley CA, USA, 94704 402 Jon Crowcroft 403 J.Crowcroft@cs.ucl.ac.uk 404 Department of Computer Science 405 University College London 406 Gower Street, 407 London WC1E 6BT, UK 409 ^L 411 7. Full Copyright Statement 413 Copyright (C) The Internet Society (2000). All Rights Reserved. 415 This document and translations of it may be copied and furnished to 416 others, and derivative works that comment on or otherwise explain it or 417 assist in its implementation may be prepared, copied, published and 418 distributed, in whole or in part, without restriction of any kind, 419 provided that the above copyright notice and this paragraph are included 420 on all such copies and derivative works. However, this document itself 421 may not be modified in any way, such as by removing the copyright notice 422 or references to the Internet Society or other Internet organizations, 423 except as needed for the purpose of developing Internet standards in 424 which case the procedures for copyrights defined in the Internet 425 languages other than English. 427 The limited permissions granted above are perpetual and will not be 428 revoked by the Internet Society or its successors or assigns. 430 This document and the information contained herein is provided on an "AS 431 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 432 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 433 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 434 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 435 FITNESS FOR A PARTICULAR PURPOSE." 437 ^L