idnits 2.17.1 draft-ietf-rmt-bb-fec-basic-schemes-revised-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 717. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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. 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 (July 13, 2005) is 6860 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 345 == Unused Reference: '5' is defined on line 656, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 660, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 663, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 666, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3452 (ref. '2') (Obsoleted by RFC 5052, RFC 5445) ** Downref: Normative reference to an Informational RFC: RFC 3453 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 3269 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2357 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 2324 (ref. '7') ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3926 (ref. '9') (Obsoleted by RFC 6726) ** Downref: Normative reference to an Informational RFC: RFC 3048 (ref. '10') ** Obsolete normative reference: RFC 3695 (ref. '11') (Obsoleted by RFC 5445) == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-00 Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport M. Watson 3 Internet-Draft Digital Fountain 4 Expires: January 14, 2006 July 13, 2005 6 Basic Forward Error Correction (FEC) Schemes 7 draft-ietf-rmt-bb-fec-basic-schemes-revised-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document provides FEC Scheme specifications according to the RMT 41 FEC Building Block for the Compact No-Code FEC Scheme, the Small 42 Block, Large Block and Expandable FEC Scheme, the Small Block 43 Systematic FEC Scheme and the Compact FEC Scheme. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 49 3. Compact No-Code FEC Scheme . . . . . . . . . . . . . . . . . . 5 50 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.2 Formats and Codes . . . . . . . . . . . . . . . . . . . . 5 52 3.2.1 FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 5 53 3.2.2 FEC Object Transmission Information . . . . . . . . . 6 54 3.3 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.4 FEC code specification . . . . . . . . . . . . . . . . . . 8 56 3.4.1 Source Block Logistics . . . . . . . . . . . . . . . . 8 57 3.4.2 Sending and Receiving a Source Block . . . . . . . . . 9 58 4. Small Block, Large Block and Expandable FEC Scheme . . . . . . 11 59 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 60 4.2 Formats and Codes . . . . . . . . . . . . . . . . . . . . 11 61 4.2.1 FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 11 62 4.2.2 FEC Object Transmission Information . . . . . . . . . 11 63 4.3 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.4 FEC Code Specification . . . . . . . . . . . . . . . . . . 12 65 5. Small Block Systematic FEC Scheme . . . . . . . . . . . . . . 13 66 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 13 67 5.2 Formats and Codes . . . . . . . . . . . . . . . . . . . . 13 68 5.2.1 FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 13 69 5.2.2 FEC Object Transmission Information . . . . . . . . . 14 70 5.3 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 71 5.4 FEC Code Specification . . . . . . . . . . . . . . . . . . 15 72 6. Compact FEC Scheme . . . . . . . . . . . . . . . . . . . . . . 16 73 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.2 Formats and Codes . . . . . . . . . . . . . . . . . . . . 16 75 6.2.1 FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 16 76 6.2.2 FEC Object Transmission Information . . . . . . . . . 16 77 6.3 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16 78 6.4 FEC code specification . . . . . . . . . . . . . . . . . . 17 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 83 Intellectual Property and Copyright Statements . . . . . . . . 21 85 1. Introduction 87 The document specifies the following FEC Schemes according to the 88 specification requirements of the FEC Building Block [12]: 90 o Compact No-Code FEC Scheme 92 o Small Block, Large Block and Expandable FEC Scheme 94 o Small Block Systematic FEC Scheme 96 o Compact FEC Scheme 98 2. Requirements notation 100 This document inherits the context, language, declarations and 101 restrictions of the FEC building block [12]. This document also uses 102 the terminology of the companion document [3] which describes the use 103 of FEC codes within the context of reliable IP multicast transport 104 and provides an introduction to some commonly used FEC codes. 106 Building blocks are defined in RFC 3048 [10]. This document is a 107 product of the IETF RMT WG and follows the general guidelines 108 provided in RFC 3269 [4]. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [1]. 114 3. Compact No-Code FEC Scheme 116 3.1 Introduction 118 The Compact No-code FEC Scheme is a Fully-Specified FEC Scheme. The 119 scheme requires no FEC coding and is specified primarily to allow 120 simple interoperability testing between different implementations of 121 protocol instantiations that use the FEC building block. 123 3.2 Formats and Codes 125 3.2.1 FEC Payload ID(s) 127 The FEC Payload ID for the Compact No-Code FEC Scheme is composed of 128 a Source Block Number and an Encoding Symbol ID as shown in Figure 1. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Source Block Number | Encoding Symbol ID | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1: FEC Payload ID format for Compact No-Code FEC Scheme 138 The 16-bit Source Block Number is used to identify from which source 139 block of the object the encoding symbol in the payload of the packet 140 is generated. There are two possible modes: In the unique SBN mode 141 each source block within the object has a unique Source Block Number 142 associated with it, and in the non-unique SBN mode the same Source 143 Block Number may be used for more than one source block within the 144 object. Which mode is being used for an object is outside the scope 145 of this document and MUST be communicated, either explicitly or 146 implicitly, out-of-band to receivers. 148 If the unique SBN mode is used then successive Source Block Numbers 149 are associated with consecutive source blocks of the object starting 150 with Source Block Number 0 for the first source block of the object. 151 In this case, there are at most 2^^16 source blocks in the object. 153 If the non-unique SBN mode is used then the mapping from source 154 blocks to Source Block Numbers MUST be communicated out-of-band to 155 receivers, and how this is done is outside the scope of this 156 document. This mapping could be implicit, for example determined by 157 the transmission order of the source blocks. In non-unique SBN mode, 158 packets for two different source blocks mapped to the same Source 159 Block Number SHOULD NOT be sent within an interval of time that is 160 shorter than the transport time of a source block. The transport 161 time of a source block includes the amount of time the source block 162 is processed at the transport layer by the sender, the network 163 transit time for packets, and the amount of time the source block is 164 processed at the transport layer by a receiver. This allows the 165 receiver to clearly decide which packets belong to which source 166 block. 168 The 16-bit Encoding Symbol ID identifies which specific encoding 169 symbol generated from the source block is carried in the packet 170 payload. The exact details of the correspondence between Encoding 171 Symbol IDs and the encoding symbols in the packet payload are 172 specified in Section 3.4. 174 3.2.2 FEC Object Transmission Information 176 3.2.2.1 Mandatory 178 The mandatory FEC Object Transmission Information elements for the 179 Compact No-Code FEC Scheme are: 181 o FEC Encoding ID: zero (0) 183 3.2.2.2 Common 185 The common FEC Object Transmission Information elements and their 186 value ranges for the Compact No-code FEC Scheme are: 188 Transfer-Length: a non-negative integer less than 2^^48. 190 Encoding-Symbol-Length: a non-negative integer less than 2^^16. 192 Maximum-Source-Block-Length: a non-negative integer less than 2^^32. 194 Note that the semantics for the above elements are defined in [12] 195 and are not duplicated here. 197 Where an explicit encoding format defined by the FEC Scheme is 198 required for these elements, they SHALL be encoded according to 199 Figure 2. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Encoding Symbol Length | Max. Source Block Length (MSB)| 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Max. Source Block Length (LSB)| 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: Common FEC OTI enoding format for Compact No-Code FEC 210 Scheme 212 All Encoding Symbols of a transport object MUST have length equal to 213 the length specified in the Encoding Symbol Length element, with the 214 optional exception of the last source symbol of the last source block 215 (so that redundant padding is not mandatory in this last symbol). 216 This last source symbol MUST be logically padded out with zeroes when 217 another Encoding Symbol is computed based on this source symbol to 218 ensure the same interpretation of this Encoding Symbol value by the 219 sender and receiver. However, this padding does not actually need to 220 be sent with the data of the last source symbol. 222 Note: this FEC Scheme was first defined in [11] which did not 223 require that the Encoding Symbol Length should be the same for 224 every source block. However, no protocols have been defined which 225 support variation in the Encoding Symbol Length between source 226 blocks and thus introduction of a general requirement that the 227 Encoding Symbol Length be the same across source blocks (as 228 proposed here) should not cause backwards compatibility issues and 229 will aid interoperability. 231 3.2.2.3 Scheme-Specific 233 No Scheme-Specific FEC Object Transmission Information elements are 234 defined by this FEC Scheme. 236 3.3 Procedures 238 The algorithm defined in Section 9.1. of [12] MUST be used to 239 partition the file into source blocks. 241 Note: this FEC Scheme was first defined in [11] which did not 242 define an algorithm for partitioning the file. FLUTE [9] defined 243 an algorithm equivalent to that referenced above and recommended 244 its use with the Compact No-Code FEC Scheme. Since no other 245 algorithms have been defined the requirement above can be 246 introduced without backwards compatiblity issues. Specification 247 of a single mandatory partitioning algorithm should aid 248 interoperability. 250 3.4 FEC code specification 252 The Compact No-Code FEC scheme does not require FEC encoding or 253 decoding. Instead, each encoding symbol consists of consecutive 254 bytes of a source block of the object. 256 The following two subsections describe the details of how the Compact 257 No-Code FEC scheme operates for each source block of an object. 259 3.4.1 Source Block Logistics 261 Let X > 0 be the length of a source block in bytes. Let L > 0 be the 262 length of the encoding symbol contained in the payload of each 263 packet. The value of X and L are part of the FEC Object Transmission 264 Information, and how this information is communicated to a receiver 265 is outside the scope of this document. 267 For a given source block X bytes in length with Source Block Number 268 I, let N = X/L rounded up to the nearest integer. The encoding 269 symbol carried in the payload of a packet consists of a consecutive 270 portion of the source block. The source block is logically 271 partitioned into N encoding symbols, each L bytes in length, and the 272 corresponding Encoding Symbol IDs range from 0 through N-1 starting 273 at the beginning of the source block and proceeding to the end. 274 Thus, the encoding symbol with Encoding Symbol ID Y consists of bytes 275 L*Y through L*(Y+1)-1 of the source block, where the bytes of the 276 source block are numbered from 0 through X-1. If X/L is not integral 277 then the last encoding symbol with Encoding Symbol ID = N-1 consists 278 of bytes L*(N-1) through the last byte X-1 of the source block, and 279 the remaining L*N - X bytes of the encoding symbol can by padded out 280 with zeroes. 282 As an example, suppose that the source block length X = 20,400 and 283 encoding symbol length L = 1,000. The encoding symbol with Encoding 284 Symbol ID = 10 contains bytes 10,000 through 10,999 of the source 285 block, and the encoding symbol with Encoding Symbol ID = 20 contains 286 bytes 20,000 through the last byte 20,399 of the source block and the 287 remaining 600 bytes of the encoding symbol can be padded with zeroes. 289 There are no restrictions beyond the rules stated above on how a 290 sender generates encoding symbols to send from a source block. 291 However, it is recommended that an implementor of refer to the 292 companion document [2] for general advice. 294 In the next subsection a procedure is recommended for sending and 295 receiving source blocks. 297 3.4.2 Sending and Receiving a Source Block 299 The following carousel procedure is RECOMMENDED for a sender to 300 generate packets containing FEC Payload IDs and corresponding 301 encoding symbols for a source block with Source Block Number I. Set 302 the length in bytes of an encoding symbol to a fixed value L which is 303 reasonable for a packet payload (e.g., ensure that the total packet 304 size does not exceed the MTU) and that is smaller than the source 305 block length X, e.g., L = 1,000 for X >= 1,000. Initialize Y to a 306 value randomly chosen in the interval [0..N-1]. Repeat the following 307 for each packet of the source block to be sent. 309 o If Y <= N-1 then generate the encoding symbol Y. 311 o Within the FEC Payload ID, set the Source Block Length to X, set 312 the Source Block Number = I, set the Encoding Symbol ID = Y, place 313 the FEC Payload ID and the encoding symbol into the packet to 314 send. 316 o In preparation for the generation of the next packet: if Y < N-1 317 then increment Y by one else if Y = N-1 then reset Y to zero. 319 The following procedure is RECOMMENDED for a receiver to recover the 320 source block based on receiving packets for the source block from a 321 sender that is using the carousel procedure described above. The 322 receiver can determine from which source block a received packet was 323 generated by the Source Block Number carried in the FEC Payload ID. 324 Upon receipt of the first FEC Payload ID for a source block, the 325 receiver uses the source block length received out-of-band as part of 326 the FEC Object Transmission Information to determine the length X in 327 bytes of the source block, and allocates space for the X bytes that 328 the source block requires. The receiver also computes the length L 329 of the encoding symbol in the payload of the packet by substracting 330 the packet header length from the total length of the received packet 331 (and the receiver checks that this length is the same in each 332 subsequent received packet from the same source block). After 333 calculating N = X/L rounded up to the nearest integer, the receiver 334 allocates a boolean array RECEIVED[0..N-1] with all N entries 335 initialized to false to track received encoding symbols. The 336 receiver keeps receiving packets for the source block as long as 337 there is at least one entry in RECEIVED still set to false or until 338 the application decides to give up on this source block and move on 339 to other source blocks. For each received packet for the source 340 block (including the first packet) the steps to be taken to help 341 recover the source block are as follows. Let Y be the value of the 342 Encoding Symbol ID within FEC Payload ID of the packet. If Y <= N-1 343 then the receiver copies the encoding symbol into the appropriate 344 place within the space reserved for the source block and sets 345 RECEIVED[Y] = true. If all N entries of RECEIVED are true then the 346 receiver has recovered the entire source block. 348 4. Small Block, Large Block and Expandable FEC Scheme 350 4.1 Introduction 352 This section defines an Under-Specified FEC Scheme for Small Block 353 FEC codes, Large Block FEC codes and Expandable FEC codes as 354 described in [3]. 356 4.2 Formats and Codes 358 4.2.1 FEC Payload ID(s) 360 The FEC Payload ID is composed of a Source Block Number and an 361 Encoding Symbol ID structured as shown in Figure 3. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Source Block Number | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Encoding Symbol ID | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 3: FEC Payload ID format for Small Block, Large Block and 372 Expandable FEC Codes 374 The Source Block Number identifies from which source block of the 375 object the encoding symbol(s) in the payload are generated. These 376 blocks are numbered consecutively from 0 to N-1, where N is the 377 number of source blocks in the object. 379 The Encoding Symbol ID identifies which specific encoding symbol(s) 380 generated from the source block are carried in the packet payload. 381 The exact details of the correspondence between Encoding Symbol IDs 382 and the encoding symbol(s) in the packet payload are dependent on the 383 particular FEC Scheme instance used as identified by the FEC Encoding 384 ID and by the FEC Instance ID, and these details may be proprietary. 386 4.2.2 FEC Object Transmission Information 388 4.2.2.1 Mandatory 390 The mandatory FEC Object Transmission Information elements for the 391 Small Block, Large Block and Expandable FEC Scheme are: 393 o FEC Encoding ID: 128 394 o FEC Instance ID: defined by instances of this FEC Scheme 396 4.2.2.2 Common 398 The common FEC Object Transmission Information elements and their 399 encoding are the same as defined for the Compact No-Code FEC Scheme 400 in Section 3.2.2.2. 402 4.2.2.3 Scheme-Specific 404 No Scheme-Specific FEC Object Transmission Information elements are 405 defined by this FEC Scheme. 407 4.3 Procedures 409 The algorithm defined in Section 9.1. of [12] MUST be used to 410 partition the file into source blocks. 412 Note: this FEC Scheme was first defined in [11] which did not 413 define an algorithm for partitioning the file. FLUTE [9] defined 414 an algorithm equivalent to that referenced above and recommended 415 its use with the Small Block, Large Block and Expandable FEC 416 Scheme. Since no other algorithms have been defined the 417 requirement above can be introduced without backwards compatiblity 418 issues. Specification of a single mandatory partitioning 419 algorithm should aid interoperability. 421 4.4 FEC Code Specification 423 The FEC code specification and the correspondance of Encoding Symbols 424 IDs to encoding symbols are defined by specific instances of this 425 scheme and so are out of scope of this document. 427 5. Small Block Systematic FEC Scheme 429 5.1 Introduction 431 This section defines an Under-Specified FEC Scheme for Small Block 432 Systematic FEC codes as described in [3]. For Small Block Systematic 433 FEC codes, each source block is of length at most 65536 source 434 symbols. 436 Although these codes can generally be accommodated by the FEC 437 Encoding ID described in Section 4, a specific FEC Encoding ID is 438 defined for Small Block Systematic FEC codes to allow more 439 flexibility and to retain header compactness. The small source block 440 length and small expansion factor that often characterize systematic 441 codes may require the data source to frequently change the source 442 block length. To allow the dynamic variation of the source block 443 length and to communicate it to the receivers with low overhead, the 444 block length is included in the FEC Payload ID. 446 5.2 Formats and Codes 448 5.2.1 FEC Payload ID(s) 450 The FEC Payload ID is composed of the Source Block Number, Source 451 Block Length and the Encoding Symbol ID structured as shown in 452 Figure 4. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Source Block Number | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Source Block Length | Encoding Symbol ID | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 4: FEC Payload ID format for Small Block Systematic FEC scheme 464 The Source Block Number identifies from which source block of the 465 object the encoding symbol(s) in the payload are generated. These 466 blocks are numbered consecutively from 0 to N-1, where N is the 467 number of source blocks in the object. 469 The Source Block Length is the length in units of source symbols of 470 the source block identified by the Source Block Number. 472 The Encoding Symbol ID identifies which specific encoding symbol(s) 473 generated from the source block are carried in the packet payload. 474 Each encoding symbol is either an original source symbol or a 475 redundant symbol generated by the encoder. The exact details of the 476 correspondence between Encoding Symbol IDs and the encoding symbol(s) 477 in the packet payload are dependent on the particular FEC scheme 478 instance used as identified by the FEC Instance ID, and these details 479 may be proprietary. 481 5.2.2 FEC Object Transmission Information 483 5.2.2.1 Mandatory 485 The mandatory FEC Object Transmission Information elements for the 486 Small Block Systematic FEC Scheme are: 488 o FEC Encoding ID: 129 490 o FEC Instance ID: defined by instances of this FEC Scheme 492 5.2.2.2 Common 494 The common FEC Object Transmission Information elements and their 495 value ranges for the Small Block Systematic FEC Scheme are: 497 Transfer-Length: a non-negative integer less than 2^^48. 499 Encoding-Symbol-Length: a non-negative integer less than 2^^16. 501 Maximum-Source-Block-Length: a non-negative integer less than 2^^16. 503 Max-Number-of-Encoding-Symbols: a non-negative integer less than 504 2^^16 506 Note that the semantics for the above elements are defined in [12] 507 and are not duplicated here. 509 Where an explicit encoding format is required for these elements, 510 they SHALL be encoded according to Figure 5. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Encoding Symbol Length | Maximum Source Block Length | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Max. Num. of Encoding Symbols | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 5: FEC OTI format for Small Block Systematic FEC Scheme 522 All Encoding Symbols of a transport object MUST have length equal to 523 the length specified in the Encoding Symbol Length field, with the 524 optional exception of the last source symbol of the last source block 525 (so that redundant padding is not mandatory in this last symbol). 526 This last source symbol MUST be logically padded out with zeroes when 527 another Encoding Symbol is computed based on this source symbol to 528 ensure the same interpretation of this Encoding Symbol value by the 529 sender and receiver. However, this padding need not be actually sent 530 with the data of the last source symbol. 532 Note: this FEC Scheme was first defined in [2] which did not 533 require that the Encoding Symbol Length should be the same for 534 every source block. However, no protocols have been defined which 535 support variation in the Encoding Symbol Length between source 536 blocks and thus introduction of a general requirement that the 537 Encoding Symbol Length be the same across source blocks (as 538 proposed here) should not cause backwards compatibility issues and 539 will aid interoperability. 541 5.2.2.3 Scheme-Specific 543 No Scheme-Specific FEC Object Transmission Information elements are 544 defined by this FEC Scheme. 546 5.3 Procedures 548 The algorithm defined in Section 9.1. of [12] MAY be used to 549 partition the file into source blocks. 551 DISCUSSION NOTE: This FEC scheme was intended for systematic FEC 552 codes, but no correspondance between Encoding Symbol IDs and 553 source symbols was defined - this was left to instances of the 554 scheme (of which there are presently none). Specification as part 555 of the scheme of the correspondance between Encoding Symbols ID 556 values and source symbols would allow receivers that did not 557 support a given instance of this scheme to correctly receive at 558 least the source symbols. 560 5.4 FEC Code Specification 562 The FEC code specification and the correspondance of Encoding Symbols 563 IDs to encoding symbols are defined by specific instances of this 564 scheme and so are out of scope of this document. 566 6. Compact FEC Scheme 568 6.1 Introduction 570 The Compact FEC Scheme is an Under-Specified FEC scheme. This FEC 571 scheme is similar in spirit to the Compact No-Code FEC scheme, except 572 that a non-trivial FEC encoding (that is Under-Specified) may be used 573 to generate encoding symbol(s) placed in the payload of each packet 574 and a corresponding FEC decoder may be used to produce the source 575 block from received packets. 577 6.2 Formats and Codes 579 6.2.1 FEC Payload ID(s) 581 The FEC Payload ID format defined in Section 3.2.1 SHALL be used. 583 6.2.2 FEC Object Transmission Information 585 6.2.2.1 Mandatory 587 The mandatory FEC Object Transmission Information elements for the 588 Compact No-Code FEC Scheme are: 590 o FEC Encoding ID: 130 592 o FEC Instance ID: defined by instances of this FEC Scheme 594 6.2.2.2 Common 596 The common FEC Object Transmission Information elements and their 597 encoding are the same as defined for the Compact No-Code FEC Scheme 598 in Section 3.2.2.2. 600 6.2.2.3 Scheme-Specific 602 No Scheme-Specific FEC Object Transmission Information elements are 603 defined by this FEC Scheme. 605 6.3 Procedures 607 The algorithm defined in Section 9.1. of [12] MUST be used to 608 partition the file into source blocks. 610 Note: this FEC Scheme was first defined in [11] which did not 611 define an algorithm for partitioning the file. FLUTE [9] defined 612 an algorithm equivalent to that referenced above and recommended 613 its use with the Compact FEC Scheme. Since no other algorithms 614 have been defined the requirement above can be introduced without 615 backwards compatiblity issues. Specification of a single 616 mandatory partitioning algorithm should aid interoperability. 618 6.4 FEC code specification 620 The FEC code specification and the correspondance of Encoding Symbols 621 IDs to encoding symbols are defined by specific instances of this 622 scheme and so are out of scope of this document. 624 7. Acknowledgments 626 This document is based in part on [11] by Michael Luby and Lorenzo 627 Vicisano. 629 8. IANA Considerations 631 FEC Encoding IDs 0 and 130 were first defined and registered in the 632 ietf:rmt:fec:encoding namespace by [11]. This document updates and 633 obsoletes the definitions from that specification. 635 FEC Encoding IDs 128 and 129 were first defined and registered in the 636 ietf:rmt:fec:encoding namespace by [2]. This document updates and 637 obsoletes the definitions from that specification. 639 9. References 641 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 642 Levels", BCP 14, RFC 2119, March 1997. 644 [2] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., 645 and J. Crowcroft, "Forward Error Correction (FEC) Building 646 Block", RFC 3452, December 2002. 648 [3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., 649 and J. Crowcroft, "The Use of Forward Error Correction (FEC) in 650 Reliable Multicast", RFC 3453, December 2002. 652 [4] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable 653 Multicast Transport (RMT) Building Blocks and Protocol 654 Instantiation documents", RFC 3269, April 2002. 656 [5] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 657 Criteria for Evaluating Reliable Multicast Transport and 658 Application Protocols", RFC 2357, June 1998. 660 [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 661 April 1992. 663 [7] Masinter, L., "Hyper Text Coffee Pot Control Protocol 664 (HTCPCP/1.0)", RFC 2324, April 1998. 666 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 667 Considerations Section in RFCs", BCP 26, RFC 2434, 668 October 1998. 670 [9] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 671 "FLUTE - File Delivery over Unidirectional Transport", 672 RFC 3926, October 2004. 674 [10] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., 675 and M. Luby, "Reliable Multicast Transport Building Blocks for 676 One-to-Many Bulk-Data Transfer", RFC 3048, January 2001. 678 [11] Luby, M. and L. Vicisano, "Compact Forward Error Correction 679 (FEC) Schemes", RFC 3695, February 2004. 681 [12] Watson, M., "Forward Error Correction (FEC) Building Block", 682 draft-ietf-rmt-fec-bb-revised-00 (work in progress), May 2005. 684 Author's Address 686 Mark Watson 687 Digital Fountain 688 39141 Civic Center Drive 689 Suite 300 690 Fremont, CA 94538 691 U.S.A. 693 Email: mark@digitalfountain.com 695 Intellectual Property Statement 697 The IETF takes no position regarding the validity or scope of any 698 Intellectual Property Rights or other rights that might be claimed to 699 pertain to the implementation or use of the technology described in 700 this document or the extent to which any license under such rights 701 might or might not be available; nor does it represent that it has 702 made any independent effort to identify any such rights. Information 703 on the procedures with respect to rights in RFC documents can be 704 found in BCP 78 and BCP 79. 706 Copies of IPR disclosures made to the IETF Secretariat and any 707 assurances of licenses to be made available, or the result of an 708 attempt made to obtain a general license or permission for the use of 709 such proprietary rights by implementers or users of this 710 specification can be obtained from the IETF on-line IPR repository at 711 http://www.ietf.org/ipr. 713 The IETF invites any interested party to bring to its attention any 714 copyrights, patents or patent applications, or other proprietary 715 rights that may cover technology that may be required to implement 716 this standard. Please address the information to the IETF at 717 ietf-ipr@ietf.org. 719 Disclaimer of Validity 721 This document and the information contained herein are provided on an 722 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 723 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 724 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 725 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 726 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 727 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 729 Copyright Statement 731 Copyright (C) The Internet Society (2005). This document is subject 732 to the rights, licenses and restrictions contained in BCP 78, and 733 except as set forth therein, the authors retain all their rights. 735 Acknowledgment 737 Funding for the RFC Editor function is currently provided by the 738 Internet Society.