idnits 2.17.1 draft-ietf-rmt-bb-fec-basic-schemes-revised-01.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 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 713. ** 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. 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 (October 18, 2005) is 6765 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 339 == Unused Reference: '6' is defined on line 662, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 666, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 669, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-01 -- Obsolete informational reference (is this intentional?): RFC 3452 (ref. '3') (Obsoleted by RFC 5052, RFC 5445) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '8') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3695 (ref. '10') (Obsoleted by RFC 5445) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 11 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: April 21, 2006 October 18, 2005 6 Basic Forward Error Correction (FEC) Schemes 7 draft-ietf-rmt-bb-fec-basic-schemes-revised-01 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 April 21, 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 . . . . . . . . . . . . . . . . . . 7 56 3.4.1. Source Block Logistics . . . . . . . . . . . . . . . . 8 57 3.4.2. Sending and Receiving a Source Block . . . . . . . . . 8 58 4. Small Block, Large Block and Expandable FEC Scheme . . . . . . 10 59 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 60 4.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 10 61 4.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 10 62 4.2.2. FEC Object Transmission Information . . . . . . . . . 10 63 4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 16 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 Intellectual Property and Copyright Statements . . . . . . . . . . 21 87 1. Introduction 89 The document specifies the following FEC Schemes according to the 90 specification requirements of the FEC Building Block [2]: 92 o Compact No-Code FEC Scheme 94 o Small Block, Large Block and Expandable FEC Scheme 96 o Small Block Systematic FEC Scheme 98 o Compact FEC Scheme 100 2. Requirements notation 102 This document inherits the context, language, declarations and 103 restrictions of the FEC building block [2]. This document also uses 104 the terminology of the companion document [4] which describes the use 105 of FEC codes within the context of reliable IP multicast transport 106 and provides an introduction to some commonly used FEC codes. 108 Building blocks are defined in RFC 3048 [9]. This document is a 109 product of the IETF RMT WG and follows the general guidelines 110 provided in RFC 3269 [5]. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [1]. 116 3. Compact No-Code FEC Scheme 118 3.1. Introduction 120 The Compact No-code FEC Scheme is a Fully-Specified FEC Scheme. The 121 scheme requires no FEC coding and is specified primarily to allow 122 simple interoperability testing between different implementations of 123 protocol instantiations that use the FEC building block. 125 3.2. Formats and Codes 127 3.2.1. FEC Payload ID(s) 129 The FEC Payload ID for the Compact No-Code FEC Scheme is composed of 130 a Source Block Number and an Encoding Symbol ID as shown in Figure 1. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Source Block Number | Encoding Symbol ID | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Figure 1: FEC Payload ID format for Compact No-Code FEC Scheme 140 The 16-bit Source Block Number is used to identify from which source 141 block of the object the encoding symbol in the payload of the packet 142 is generated. There are two possible modes: In the unique SBN mode 143 each source block within the object has a unique Source Block Number 144 associated with it, and in the non-unique SBN mode the same Source 145 Block Number may be used for more than one source block within the 146 object. Which mode is being used for an object is outside the scope 147 of this document and MUST be communicated, either explicitly or 148 implicitly, out-of-band to receivers. 150 If the unique SBN mode is used then successive Source Block Numbers 151 are associated with consecutive source blocks of the object starting 152 with Source Block Number 0 for the first source block of the object. 153 In this case, there are at most 2^^16 source blocks in the object. 155 If the non-unique SBN mode is used then the mapping from source 156 blocks to Source Block Numbers MUST be communicated out-of-band to 157 receivers, and how this is done is outside the scope of this 158 document. This mapping could be implicit, for example determined by 159 the transmission order of the source blocks. In non-unique SBN mode, 160 packets for two different source blocks mapped to the same Source 161 Block Number SHOULD NOT be sent within an interval of time that is 162 shorter than the transport time of a source block. The transport 163 time of a source block includes the amount of time the source block 164 is processed at the transport layer by the sender, the network 165 transit time for packets, and the amount of time the source block is 166 processed at the transport layer by a receiver. This allows the 167 receiver to clearly decide which packets belong to which source 168 block. 170 The 16-bit Encoding Symbol ID identifies which specific encoding 171 symbol generated from the source block is carried in the packet 172 payload. The exact details of the correspondence between Encoding 173 Symbol IDs and the encoding symbols in the packet payload are 174 specified in Section 3.4. 176 3.2.2. FEC Object Transmission Information 178 3.2.2.1. Mandatory 180 The mandatory FEC Object Transmission Information element for the 181 Compact No-Code FEC Scheme is: 183 o FEC Encoding ID: zero (0) 185 3.2.2.2. Common 187 The common FEC Object Transmission Information elements and their 188 value ranges for the Compact No-code FEC Scheme are: 190 Transfer-Length: a non-negative integer less than 2^^48. 192 Encoding-Symbol-Length: a non-negative integer less than 2^^16. 194 Maximum-Source-Block-Length: a non-negative integer less than 2^^32. 196 Note that the semantics for the above elements are defined in [2] and 197 are not duplicated here. 199 The encoded Common FEC Object Transmission information is defined in 200 Figure 2. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Transfer Length | 206 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | Reserved | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Encoding Symbol Length | Max. Source Block Length (MSB)| 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Max. Source Block Length (LSB)| 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 2: Encoded Common FEC OTI for Compact No-Code FEC Scheme 216 All Encoding Symbols of a transport object MUST have length equal to 217 the length specified in the Encoding Symbol Length element, with the 218 optional exception of the last source symbol of the last source block 219 (so that redundant padding is not mandatory in this last symbol). 220 This last source symbol MUST be logically padded out with zeroes when 221 another Encoding Symbol is computed based on this source symbol to 222 ensure the same interpretation of this Encoding Symbol value by the 223 sender and receiver. However, this padding does not actually need to 224 be sent with the data of the last source symbol. 226 Note: this FEC Scheme was first defined in [10] which did not 227 require that the Encoding Symbol Length should be the same for 228 every source block. This document introduces a general 229 requirement that the Encoding Symbol Length be the same across 230 source blocks. Since no protocols were defined which support 231 variation in the Encoding Symbol Length between source blocks this 232 can be done without introducing backwards compatibility issues. 234 3.2.2.3. Scheme-Specific 236 No Scheme-Specific FEC Object Transmission Information elements are 237 defined by this FEC Scheme. 239 3.3. Procedures 241 The algorithm defined in Section 9.1. of [2] MUST be used to 242 partition the file into source blocks. 244 3.4. FEC code specification 246 The Compact No-Code FEC scheme does not require FEC encoding or 247 decoding. Instead, each encoding symbol consists of consecutive 248 bytes of a source block of the object. 250 The following two subsections describe the details of how the Compact 251 No-Code FEC scheme operates for each source block of an object. 253 3.4.1. Source Block Logistics 255 Let X > 0 be the length of a source block in bytes. Let L > 0 be the 256 length of the encoding symbol contained in the payload of each 257 packet. The value of X and L are part of the FEC Object Transmission 258 Information, and how this information is communicated to a receiver 259 is outside the scope of this document. 261 For a given source block X bytes in length with Source Block Number 262 I, let N = X/L rounded up to the nearest integer. The encoding 263 symbol carried in the payload of a packet consists of a consecutive 264 portion of the source block. The source block is logically 265 partitioned into N encoding symbols, each L bytes in length, and the 266 corresponding Encoding Symbol IDs range from 0 through N-1 starting 267 at the beginning of the source block and proceeding to the end. 268 Thus, the encoding symbol with Encoding Symbol ID Y consists of bytes 269 L*Y through L*(Y+1)-1 of the source block, where the bytes of the 270 source block are numbered from 0 through X-1. If X/L is not integral 271 then the last encoding symbol with Encoding Symbol ID = N-1 consists 272 of bytes L*(N-1) through the last byte X-1 of the source block, and 273 the remaining L*N - X bytes of the encoding symbol can by padded out 274 with zeroes. 276 As an example, suppose that the source block length X = 20,400 and 277 encoding symbol length L = 1,000. The encoding symbol with Encoding 278 Symbol ID = 10 contains bytes 10,000 through 10,999 of the source 279 block, and the encoding symbol with Encoding Symbol ID = 20 contains 280 bytes 20,000 through the last byte 20,399 of the source block and the 281 remaining 600 bytes of the encoding symbol can be padded with zeroes. 283 There are no restrictions beyond the rules stated above on how a 284 sender generates encoding symbols to send from a source block. 285 However, it is recommended that an implementor of refer to the 286 companion document [3] for general advice. 288 In the next subsection a procedure is recommended for sending and 289 receiving source blocks. 291 3.4.2. Sending and Receiving a Source Block 293 The following carousel procedure is RECOMMENDED for a sender to 294 generate packets containing FEC Payload IDs and corresponding 295 encoding symbols for a source block with Source Block Number I. Set 296 the length in bytes of an encoding symbol to a fixed value L which is 297 reasonable for a packet payload (e.g., ensure that the total packet 298 size does not exceed the MTU) and that is smaller than the source 299 block length X, e.g., L = 1,000 for X >= 1,000. Initialize Y to a 300 value randomly chosen in the interval [0..N-1]. Repeat the following 301 for each packet of the source block to be sent. 303 o If Y <= N-1 then generate the encoding symbol Y. 305 o Within the FEC Payload ID, set the Source Block Length to X, set 306 the Source Block Number = I, set the Encoding Symbol ID = Y, place 307 the FEC Payload ID and the encoding symbol into the packet to 308 send. 310 o In preparation for the generation of the next packet: if Y < N-1 311 then increment Y by one else if Y = N-1 then reset Y to zero. 313 The following procedure is RECOMMENDED for a receiver to recover the 314 source block based on receiving packets for the source block from a 315 sender that is using the carousel procedure described above. The 316 receiver can determine from which source block a received packet was 317 generated by the Source Block Number carried in the FEC Payload ID. 318 Upon receipt of the first FEC Payload ID for a source block, the 319 receiver uses the source block length received out-of-band as part of 320 the FEC Object Transmission Information to determine the length X in 321 bytes of the source block, and allocates space for the X bytes that 322 the source block requires. The receiver also computes the length L 323 of the encoding symbol in the payload of the packet by substracting 324 the packet header length from the total length of the received packet 325 (and the receiver checks that this length is the same in each 326 subsequent received packet from the same source block). After 327 calculating N = X/L rounded up to the nearest integer, the receiver 328 allocates a boolean array RECEIVED[0..N-1] with all N entries 329 initialized to false to track received encoding symbols. The 330 receiver keeps receiving packets for the source block as long as 331 there is at least one entry in RECEIVED still set to false or until 332 the application decides to give up on this source block and move on 333 to other source blocks. For each received packet for the source 334 block (including the first packet) the steps to be taken to help 335 recover the source block are as follows. Let Y be the value of the 336 Encoding Symbol ID within FEC Payload ID of the packet. If Y <= N-1 337 then the receiver copies the encoding symbol into the appropriate 338 place within the space reserved for the source block and sets 339 RECEIVED[Y] = true. If all N entries of RECEIVED are true then the 340 receiver has recovered the entire source block. 342 4. Small Block, Large Block and Expandable FEC Scheme 344 4.1. Introduction 346 This section defines an Under-Specified FEC Scheme for Small Block 347 FEC codes, Large Block FEC codes and Expandable FEC codes as 348 described in [4]. 350 4.2. Formats and Codes 352 4.2.1. FEC Payload ID(s) 354 The FEC Payload ID is composed of a Source Block Number and an 355 Encoding Symbol ID structured as shown in Figure 3. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Source Block Number | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Encoding Symbol ID | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 3: FEC Payload ID format for Small Block, Large Block and 366 Expandable FEC Codes 368 The Source Block Number identifies from which source block of the 369 object the encoding symbol(s) in the payload are generated. These 370 blocks are numbered consecutively from 0 to N-1, where N is the 371 number of source blocks in the object. 373 The Encoding Symbol ID identifies which specific encoding symbol(s) 374 generated from the source block are carried in the packet payload. 375 The exact details of the correspondence between Encoding Symbol IDs 376 and the encoding symbol(s) in the packet payload are dependent on the 377 particular FEC Scheme instance used as identified by the FEC Encoding 378 ID and by the FEC Instance ID, and these details may be proprietary. 380 4.2.2. FEC Object Transmission Information 382 4.2.2.1. Mandatory 384 The mandatory FEC Object Transmission Information element for the 385 Small Block, Large Block and Expandable FEC Scheme are: 387 o FEC Encoding ID: 128 389 4.2.2.2. Common 391 The common FEC Object Transmission Information elements and their 392 value ranges for the Small Block, Large Block and Expandable FEC 393 Scheme are: 395 FEC Instance ID: a non-negative integer less than 2^^16. 397 Transfer-Length: a non-negative integer less than 2^^48. 399 Encoding-Symbol-Length: a non-negative integer less than 2^^16. 401 Maximum-Source-Block-Length: a non-negative integer less than 2^^32. 403 Note that the semantics for the above elements are defined in [2] and 404 are not duplicated here. 406 The encoded Common FEC Object Transmission information is defined in 407 Section 4.2.2.2. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Transfer Length | 413 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | FEC Instance ID | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Encoding Symbol Length | Max. Source Block Length (MSB)| 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Max. Source Block Length (LSB)| 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 4: Encoded Common FEC OTI for Small Block, Large Block and 422 Expandable FEC Scheme 424 4.2.2.3. Scheme-Specific 426 No Scheme-Specific FEC Object Transmission Information elements are 427 defined by this FEC Scheme. 429 4.3. Procedures 431 The algorithm defined in Section 9.1. of [2] MUST be used to 432 partition the file into source blocks. 434 4.4. FEC Code Specification 436 The FEC code specification and the correspondance of Encoding Symbols 437 IDs to encoding symbols are defined by specific instances of this 438 scheme and so are out of scope of this document. 440 5. Small Block Systematic FEC Scheme 442 5.1. Introduction 444 This section defines an Under-Specified FEC Scheme for Small Block 445 Systematic FEC codes as described in [4]. For Small Block Systematic 446 FEC codes, each source block is of length at most 65536 source 447 symbols. 449 Although these codes can generally be accommodated by the FEC 450 Encoding ID described in Section 4, a specific FEC Encoding ID is 451 defined for Small Block Systematic FEC codes to allow more 452 flexibility and to retain header compactness. The small source block 453 length and small expansion factor that often characterize systematic 454 codes may require the data source to frequently change the source 455 block length. To allow the dynamic variation of the source block 456 length and to communicate it to the receivers with low overhead, the 457 block length is included in the FEC Payload ID. 459 5.2. Formats and Codes 461 5.2.1. FEC Payload ID(s) 463 The FEC Payload ID is composed of the Source Block Number, Source 464 Block Length and the Encoding Symbol ID structured as shown in 465 Figure 5. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Source Block Number | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Source Block Length | Encoding Symbol ID | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 5: FEC Payload ID format for Small Block Systematic FEC scheme 477 The Source Block Number identifies from which source block of the 478 object the encoding symbol(s) in the payload are generated. These 479 blocks are numbered consecutively from 0 to N-1, where N is the 480 number of source blocks in the object. 482 The Source Block Length is the length in units of source symbols of 483 the source block identified by the Source Block Number. 485 The Encoding Symbol ID identifies which specific encoding symbol(s) 486 generated from the source block are carried in the packet payload. 487 Each encoding symbol is either an original source symbol or a 488 redundant symbol generated by the encoder. The exact details of the 489 correspondence between Encoding Symbol IDs and the encoding symbol(s) 490 in the packet payload are dependent on the particular FEC scheme 491 instance used as identified by the FEC Instance ID, and these details 492 may be proprietary. 494 5.2.2. FEC Object Transmission Information 496 5.2.2.1. Mandatory 498 The mandatory FEC Object Transmission Information element for the 499 Small Block Systematic FEC Scheme is: 501 o FEC Encoding ID: 129 503 5.2.2.2. Common 505 The common FEC Object Transmission Information elements and their 506 value ranges for the Small Block Systematic FEC Scheme are: 508 FEC Instance ID: a non-negative integer less than 2^^16. 510 Transfer-Length: a non-negative integer less than 2^^48. 512 Encoding-Symbol-Length: a non-negative integer less than 2^^16. 514 Maximum-Source-Block-Length: a non-negative integer less than 2^^16. 516 Max-Number-of-Encoding-Symbols: a non-negative integer less than 517 2^^16 519 Note that the semantics for the above elements are defined in [2] and 520 are not duplicated here. 522 The encoded Common FEC Object Transmission information is defined in 523 Figure 6. 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Transfer Length | 529 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | FEC Instance ID | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Encoding Symbol Length | Maximum Source Block Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Max. Num. of Encoding Symbols | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 6: FEC OTI format for Small Block Systematic FEC Scheme 539 All Encoding Symbols of a transport object MUST have length equal to 540 the length specified in the Encoding Symbol Length field, with the 541 optional exception of the last source symbol of the last source block 542 (so that redundant padding is not mandatory in this last symbol). 543 This last source symbol MUST be logically padded out with zeroes when 544 another Encoding Symbol is computed based on this source symbol to 545 ensure the same interpretation of this Encoding Symbol value by the 546 sender and receiver. However, this padding need not be actually sent 547 with the data of the last source symbol. 549 Note: this FEC Scheme was first defined in [3] which did not 550 require that the Encoding Symbol Length should be the same for 551 every source block. However, no protocols have been defined which 552 support variation in the Encoding Symbol Length between source 553 blocks and thus introduction of a general requirement that the 554 Encoding Symbol Length be the same across source blocks (as 555 proposed here) should not cause backwards compatibility issues and 556 will aid interoperability. 558 5.2.2.3. Scheme-Specific 560 No Scheme-Specific FEC Object Transmission Information elements are 561 defined by this FEC Scheme. 563 5.3. Procedures 565 The algorithm defined in Section 9.1. of [2] MAY be used to partition 566 the file into source blocks. 568 5.4. FEC Code Specification 570 The FEC code specification and the correspondance of Encoding Symbols 571 IDs to encoding symbols are defined by specific instances of this 572 scheme and so are out of scope of this document. 574 6. Compact FEC Scheme 576 6.1. Introduction 578 The Compact FEC Scheme is an Under-Specified FEC scheme. This FEC 579 scheme is similar in spirit to the Compact No-Code FEC scheme, except 580 that a non-trivial FEC encoding (that is Under-Specified) may be used 581 to generate encoding symbol(s) placed in the payload of each packet 582 and a corresponding FEC decoder may be used to produce the source 583 block from received packets. 585 6.2. Formats and Codes 587 6.2.1. FEC Payload ID(s) 589 The FEC Payload ID format defined in Section 3.2.1 SHALL be used. 591 6.2.2. FEC Object Transmission Information 593 6.2.2.1. Mandatory 595 The mandatory FEC Object Transmission Information element for the 596 Compact No-Code FEC Scheme is: 598 o FEC Encoding ID: 130 600 6.2.2.2. Common 602 The common FEC Object Transmission Information elements and their 603 encoding are the same as defined for the Small Block, Large Block and 604 Expandable FEC Scheme in Figure 4. 606 6.2.2.3. Scheme-Specific 608 No Scheme-Specific FEC Object Transmission Information elements are 609 defined by this FEC Scheme. 611 6.3. Procedures 613 The algorithm defined in Section 9.1. of [2] MUST be used to 614 partition the file into source blocks. 616 6.4. FEC code specification 618 The FEC code specification and the correspondance of Encoding Symbols 619 IDs to encoding symbols are defined by specific instances of this 620 scheme and so are out of scope of this document. 622 7. Acknowledgments 624 This document is based in part on [10] by Michael Luby and Lorenzo 625 Vicisano. 627 8. IANA Considerations 629 FEC Encoding IDs 0 and 130 were first defined and registered in the 630 ietf:rmt:fec:encoding namespace by [10]. This document updates and 631 obsoletes the definitions from that specification. 633 FEC Encoding IDs 128 and 129 were first defined and registered in the 634 ietf:rmt:fec:encoding namespace by [3]. This document updates and 635 obsoletes the definitions from that specification. 637 9. References 639 9.1. Normative References 641 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 642 Levels", BCP 14, RFC 2119, March 1997. 644 [2] Watson, M., "Forward Error Correction (FEC) Building Block", 645 draft-ietf-rmt-fec-bb-revised-01 (work in progress), 646 September 2005. 648 9.2. Informative References 650 [3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., 651 and J. Crowcroft, "Forward Error Correction (FEC) Building 652 Block", RFC 3452, December 2002. 654 [4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., 655 and J. Crowcroft, "The Use of Forward Error Correction (FEC) in 656 Reliable Multicast", RFC 3453, December 2002. 658 [5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable 659 Multicast Transport (RMT) Building Blocks and Protocol 660 Instantiation documents", RFC 3269, April 2002. 662 [6] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 663 Criteria for Evaluating Reliable Multicast Transport and 664 Application Protocols", RFC 2357, June 1998. 666 [7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 667 April 1992. 669 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 670 Considerations Section in RFCs", BCP 26, RFC 2434, 671 October 1998. 673 [9] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., 674 and M. Luby, "Reliable Multicast Transport Building Blocks for 675 One-to-Many Bulk-Data Transfer", RFC 3048, January 2001. 677 [10] Luby, M. and L. Vicisano, "Compact Forward Error Correction 678 (FEC) Schemes", RFC 3695, February 2004. 680 Author's Address 682 Mark Watson 683 Digital Fountain 684 39141 Civic Center Drive 685 Suite 300 686 Fremont, CA 94538 687 U.S.A. 689 Email: mark@digitalfountain.com 691 Intellectual Property Statement 693 The IETF takes no position regarding the validity or scope of any 694 Intellectual Property Rights or other rights that might be claimed to 695 pertain to the implementation or use of the technology described in 696 this document or the extent to which any license under such rights 697 might or might not be available; nor does it represent that it has 698 made any independent effort to identify any such rights. Information 699 on the procedures with respect to rights in RFC documents can be 700 found in BCP 78 and BCP 79. 702 Copies of IPR disclosures made to the IETF Secretariat and any 703 assurances of licenses to be made available, or the result of an 704 attempt made to obtain a general license or permission for the use of 705 such proprietary rights by implementers or users of this 706 specification can be obtained from the IETF on-line IPR repository at 707 http://www.ietf.org/ipr. 709 The IETF invites any interested party to bring to its attention any 710 copyrights, patents or patent applications, or other proprietary 711 rights that may cover technology that may be required to implement 712 this standard. Please address the information to the IETF at 713 ietf-ipr@ietf.org. 715 Disclaimer of Validity 717 This document and the information contained herein are provided on an 718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 719 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 720 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 721 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 722 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 725 Copyright Statement 727 Copyright (C) The Internet Society (2005). This document is subject 728 to the rights, licenses and restrictions contained in BCP 78, and 729 except as set forth therein, the authors retain all their rights. 731 Acknowledgment 733 Funding for the RFC Editor function is currently provided by the 734 Internet Society.