idnits 2.17.1 draft-ietf-rmt-bb-fec-basic-schemes-revised-05.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 838. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 851. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC3695, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 479 has weird spacing: '...rmation the ...' -- 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 14, 2008) is 5764 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) == Missing Reference: 'Y' is mentioned on line 366, but not defined -- Obsolete informational reference (is this intentional?): RFC 3452 (Obsoleted by RFC 5052, RFC 5445) -- Obsolete informational reference (is this intentional?): RFC 3695 (Obsoleted by RFC 5445) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 10 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 Obsoletes: rfc3695 July 14, 2008 5 (if approved) 6 Intended status: Standards Track 7 Expires: January 15, 2009 9 Basic Forward Error Correction (FEC) Schemes 10 draft-ietf-rmt-bb-fec-basic-schemes-revised-05 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 15, 2009. 37 Abstract 39 This document provides FEC Scheme specifications according to the RMT 40 FEC Building Block for the Compact No-Code FEC Scheme, the Small 41 Block, Large Block and Expandable FEC Scheme, the Small Block 42 Systematic FEC Scheme and the Compact FEC Scheme. This document 43 obsoletes RFC3695 and assumes responsibility for the FEC Schemes 44 defined in RFC3452. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 50 3. Compact No-Code FEC Scheme . . . . . . . . . . . . . . . . . . 6 51 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 52 3.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 6 53 3.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 6 54 3.2.2. FEC Object Transmission Information . . . . . . . . . 7 55 3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.4. FEC code specification . . . . . . . . . . . . . . . . . . 9 57 3.4.1. Source Block Logistics . . . . . . . . . . . . . . . . 9 58 3.4.2. Sending and Receiving a Source Block . . . . . . . . . 10 59 4. Small Block, Large Block and Expandable FEC Scheme . . . . . . 12 60 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 61 4.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12 62 4.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 12 63 4.2.2. FEC Object Transmission Information . . . . . . . . . 12 64 4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14 65 4.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 14 66 5. Small Block Systematic FEC Scheme . . . . . . . . . . . . . . 15 67 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15 68 5.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 15 69 5.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 15 70 5.2.2. FEC Object Transmission Information . . . . . . . . . 16 71 5.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17 72 5.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 17 73 6. Compact FEC Scheme . . . . . . . . . . . . . . . . . . . . . . 19 74 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 19 75 6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 19 76 6.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 19 77 6.2.2. FEC Object Transmission Information . . . . . . . . . 19 78 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 19 79 6.4. FEC code specification . . . . . . . . . . . . . . . . . . 19 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 10. Changes from schemes defined in RFC3452 and RFC3695 . . . . . 24 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 Intellectual Property and Copyright Statements . . . . . . . . . . 27 90 1. Introduction 92 The document specifies the following FEC Schemes according to the 93 specification requirements of the FEC Building Block [RFC5052]: 95 o Compact No-Code FEC Scheme 97 o Small Block, Large Block and Expandable FEC Scheme 99 o Small Block Systematic FEC Scheme 101 o Compact FEC Scheme 103 This document inherits the context, language, declarations and 104 restrictions of the FEC building block [RFC5052]. This document also 105 uses the terminology of the companion document [RFC3453] which 106 describes the use of FEC codes within the context of reliable IP 107 multicast transport and provides an introduction to some commonly 108 used FEC codes. 110 Building blocks are defined in [RFC3048]. This document is a product 111 of the IETF RMT WG and follows the general guidelines provided in 112 [RFC3269]. 114 [RFC3452] and [RFC3695] contained a previous versions of the FEC 115 Schemes defined in this specification. These RFCs were published in 116 the "Experimental" category. It was the stated intent of the RMT 117 working group to re-submit these specifications as an IETF Proposed 118 Standard in due course. This document obsoletes [RFC3695]. 119 [RFC3452] has already been obsoleted by [RFC5052] and this document 120 assumes responsibility for aspects of [RFC3452] that were not 121 included in [RFC5052]. 123 This Proposed Standard specification is thus based on and backwards 124 compatible with the FEC Schemes defined in [RFC3452] and [RFC3695] 125 updated according to accumulated experience and growing protocol 126 maturity since their original publication. Said experience applies 127 both to this specification itself and to congestion control 128 strategies related to the use of this specification. 130 The differences between the FEC Scheme specifications in [RFC3452] 131 and [RFC3695] and this document listed in Section 10. 133 2. Requirements notation 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Compact No-Code FEC Scheme 141 3.1. Introduction 143 The Compact No-code FEC Scheme is a Fully-Specified FEC Scheme. The 144 scheme requires no FEC coding and is specified primarily to allow 145 simple interoperability testing between different implementations of 146 protocol instantiations that use the FEC building block. 148 3.2. Formats and Codes 150 3.2.1. FEC Payload ID(s) 152 The FEC Payload ID for the Compact No-Code FEC Scheme is composed of 153 a Source Block Number and an Encoding Symbol ID as shown in Figure 1. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Source Block Number | Encoding Symbol ID | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: FEC Payload ID format for Compact No-Code FEC Scheme 163 The 16-bit Source Block Number is used to identify from which source 164 block of the object the encoding symbol in the payload of the packet 165 is generated. There are two possible modes: In the unique SBN mode 166 each source block within the object has a unique Source Block Number 167 associated with it, and in the non-unique SBN mode the same Source 168 Block Number may be used for more than one source block within the 169 object. Which mode is being used for an object is outside the scope 170 of this document and MUST be communicated, either explicitly or 171 implicitly, out-of-band to receivers. 173 If the unique SBN mode is used then successive Source Block Numbers 174 are associated with consecutive source blocks of the object starting 175 with Source Block Number 0 for the first source block of the object. 176 In this case, there are at most 2^^16 source blocks in the object. 178 If the non-unique SBN mode is used then the mapping from source 179 blocks to Source Block Numbers MUST be communicated out-of-band to 180 receivers, and how this is done is outside the scope of this 181 document. This mapping could be implicit, for example determined by 182 the transmission order of the source blocks. In non-unique SBN mode, 183 packets for two different source blocks mapped to the same Source 184 Block Number SHOULD NOT be sent within an interval of time that is 185 shorter than the transport time of a source block. The transport 186 time of a source block includes the amount of time the source block 187 is processed at the transport layer by the sender, the network 188 transit time for packets, and the amount of time the source block is 189 processed at the transport layer by a receiver. This allows the 190 receiver to clearly decide which packets belong to which source 191 block. 193 The 16-bit Encoding Symbol ID identifies which specific encoding 194 symbol generated from the source block is carried in the packet 195 payload. The exact details of the correspondence between Encoding 196 Symbol IDs and the encoding symbols in the packet payload are 197 specified in Section 3.4. 199 3.2.2. FEC Object Transmission Information 201 3.2.2.1. Mandatory 203 The mandatory FEC Object Transmission Information element for the 204 Compact No-Code FEC Scheme is: 206 o FEC Encoding ID: zero (0) 208 3.2.2.2. Common 210 The common FEC Object Transmission Information elements and their 211 value ranges for the Compact No-code FEC Scheme are: 213 Transfer-Length: a non-negative integer less than 2^^48. 215 Encoding-Symbol-Length: a non-negative integer less than 2^^16. 217 Maximum-Source-Block-Length: a non-negative integer less than 2^^32. 219 Note that the semantics for the above elements are defined in 220 [RFC5052] and are not duplicated here. 222 The encoded Common FEC Object Transmission information is defined in 223 Figure 2. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Transfer Length | 229 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | Reserved | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Encoding Symbol Length | Max. Source Block Length (MSB)| 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Max. Source Block Length (LSB)| 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: Encoded Common FEC OTI for Compact No-Code FEC Scheme 239 All Encoding Symbols of a transport object MUST have length equal to 240 the length specified in the Encoding Symbol Length element, with the 241 optional exception of the last source symbol of the last source block 242 (so that redundant padding is not mandatory in this last symbol). 243 This last source symbol MUST be logically padded out with zeroes when 244 another Encoding Symbol is computed based on this source symbol to 245 ensure the same interpretation of this Encoding Symbol value by the 246 sender and receiver. However, this padding does not actually need to 247 be sent with the data of the last source symbol. 249 The "Reserved" field in the Encoded FEC Object Transmission 250 Information MUST be set to zero by senders and its value MUST be 251 ignored by receivers. 253 Note: this FEC Scheme was first defined in [RFC3695] which did not 254 require that the Encoding Symbol Length should be the same for 255 every source block. This document introduces a general 256 requirement that the Encoding Symbol Length be the same across 257 source blocks. Since no protocols were defined which support 258 variation in the Encoding Symbol Length between source blocks this 259 can be done without introducing backwards compatibility issues. 261 3.2.2.3. Scheme-Specific 263 No Scheme-Specific FEC Object Transmission Information elements are 264 defined by this FEC Scheme. 266 3.3. Procedures 268 The algorithm defined in Section 9.1. of [RFC5052] MUST be used to 269 partition the file into source blocks. 271 3.4. FEC code specification 273 The Compact No-Code FEC scheme does not require FEC encoding or 274 decoding. Instead, each encoding symbol consists of consecutive 275 bytes of a source block of the object. 277 The following two subsections describe the details of how the Compact 278 No-Code FEC scheme operates for each source block of an object. 280 3.4.1. Source Block Logistics 282 Let X > 0 be the length of a source block in bytes. Let L > 0 be the 283 length of the encoding symbol contained in the payload of each 284 packet. The value of X and L are part of the FEC Object Transmission 285 Information, and how this information is communicated to a receiver 286 is outside the scope of this document. 288 For a given source block X bytes in length with Source Block Number 289 I, let N = X/L rounded up to the nearest integer. The encoding 290 symbol carried in the payload of a packet consists of a consecutive 291 portion of the source block. The source block is logically 292 partitioned into N encoding symbols, each L bytes in length, and the 293 corresponding Encoding Symbol IDs range from 0 through N-1 starting 294 at the beginning of the source block and proceeding to the end. 295 Thus, the encoding symbol with Encoding Symbol ID Y consists of bytes 296 L*Y through L*(Y+1)-1 of the source block, where the bytes of the 297 source block are numbered from 0 through X-1. If X/L is not integral 298 then the last encoding symbol with Encoding Symbol ID = N-1 consists 299 of bytes L*(N-1) through the last byte X-1 of the source block, and 300 the remaining L*N - X bytes of the encoding symbol can by padded out 301 with zeroes. 303 As an example, suppose that the source block length X = 20,400 and 304 encoding symbol length L = 1,000. The encoding symbol with Encoding 305 Symbol ID = 10 contains bytes 10,000 through 10,999 of the source 306 block, and the encoding symbol with Encoding Symbol ID = 20 contains 307 bytes 20,000 through the last byte 20,399 of the source block and the 308 remaining 600 bytes of the encoding symbol can be padded with zeroes. 310 There are no restrictions beyond the rules stated above on how a 311 sender generates encoding symbols to send from a source block. 312 However, it is recommended that an implementor of refer to the 313 companion document [RFC3452] for general advice. 315 In the next subsection a procedure is recommended for sending and 316 receiving source blocks. 318 3.4.2. Sending and Receiving a Source Block 320 The following carousel procedure is RECOMMENDED for a sender to 321 generate packets containing FEC Payload IDs and corresponding 322 encoding symbols for a source block with Source Block Number I. Set 323 the length in bytes of an encoding symbol to a fixed value L which is 324 reasonable for a packet payload (e.g., ensure that the total packet 325 size does not exceed the MTU) and that is smaller than the source 326 block length X, e.g., L = 1,000 for X >= 1,000. Initialize Y to a 327 value randomly chosen in the interval [0..N-1]. Repeat the following 328 for each packet of the source block to be sent. 330 o If Y <= N-1 then generate the encoding symbol Y. 332 o Within the FEC Payload ID, set the Source Block Length to X, set 333 the Source Block Number = I, set the Encoding Symbol ID = Y, place 334 the FEC Payload ID and the encoding symbol into the packet to 335 send. 337 o In preparation for the generation of the next packet: if Y < N-1 338 then increment Y by one else if Y = N-1 then reset Y to zero. 340 The following procedure is RECOMMENDED for a receiver to recover the 341 source block based on receiving packets for the source block from a 342 sender that is using the carousel procedure described above. The 343 receiver can determine from which source block a received packet was 344 generated by the Source Block Number carried in the FEC Payload ID. 345 Upon receipt of the first FEC Payload ID for a source block, the 346 receiver uses the source block length received out-of-band as part of 347 the FEC Object Transmission Information to determine the length X in 348 bytes of the source block, and allocates space for the X bytes that 349 the source block requires. The receiver also computes the length L 350 of the encoding symbol in the payload of the packet by substracting 351 the packet header length from the total length of the received packet 352 (and the receiver checks that this length is the same in each 353 subsequent received packet from the same source block). After 354 calculating N = X/L rounded up to the nearest integer, the receiver 355 allocates a boolean array RECEIVED[0..N-1] with all N entries 356 initialized to false to track received encoding symbols. The 357 receiver keeps receiving packets for the source block as long as 358 there is at least one entry in RECEIVED still set to false or until 359 the application decides to give up on this source block and move on 360 to other source blocks. For each received packet for the source 361 block (including the first packet) the steps to be taken to help 362 recover the source block are as follows. Let Y be the value of the 363 Encoding Symbol ID within FEC Payload ID of the packet. If Y <= N-1 364 then the receiver copies the encoding symbol into the appropriate 365 place within the space reserved for the source block and sets 366 RECEIVED[Y] = true. If all N entries of RECEIVED are true then the 367 receiver has recovered the entire source block. 369 4. Small Block, Large Block and Expandable FEC Scheme 371 4.1. Introduction 373 This section defines an Under-Specified FEC Scheme for Small Block 374 FEC codes, Large Block FEC codes and Expandable FEC codes as 375 described in [RFC3453]. 377 4.2. Formats and Codes 379 4.2.1. FEC Payload ID(s) 381 The FEC Payload ID is composed of a Source Block Number and an 382 Encoding Symbol ID structured as shown in Figure 3. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Source Block Number | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Encoding Symbol ID | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 3: FEC Payload ID format for Small Block, Large Block and 393 Expandable FEC Codes 395 The Source Block Number identifies from which source block of the 396 object the encoding symbol(s) in the payload are generated. These 397 blocks are numbered consecutively from 0 to N-1, where N is the 398 number of source blocks in the object. 400 The Encoding Symbol ID identifies which specific encoding symbol(s) 401 generated from the source block are carried in the packet payload. 402 The exact details of the correspondence between Encoding Symbol IDs 403 and the encoding symbol(s) in the packet payload are dependent on the 404 particular FEC Scheme instance used as identified by the FEC Encoding 405 ID and by the FEC Instance ID, and these details may be proprietary. 407 4.2.2. FEC Object Transmission Information 409 4.2.2.1. Mandatory 411 The mandatory FEC Object Transmission Information element for the 412 Small Block, Large Block and Expandable FEC Scheme are: 414 o FEC Encoding ID: 128 416 4.2.2.2. Common 418 The common FEC Object Transmission Information elements and their 419 value ranges for the Small Block, Large Block and Expandable FEC 420 Scheme are: 422 FEC Instance ID: a non-negative integer less than 2^^16. 424 Transfer-Length: a non-negative integer less than 2^^48. 426 Encoding-Symbol-Length: a non-negative integer less than 2^^16. 428 Maximum-Source-Block-Length: a non-negative integer less than 2^^32. 430 Note that the semantics for the above elements are defined in 431 [RFC5052] and are not duplicated here. 433 The encoded Common FEC Object Transmission information is defined in 434 Section 4.2.2.2. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Transfer Length | 440 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | FEC Instance ID | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Encoding Symbol Length | Max. Source Block Length (MSB)| 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Max. Source Block Length (LSB)| 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Figure 4: Encoded Common FEC OTI for Small Block, Large Block and 449 Expandable FEC Scheme 451 4.2.2.3. Scheme-Specific 453 The Scheme-specific FEC Object Transmission Information field for the 454 Small block, Large Block and Expandable FEC Scheme provides for the 455 possibility of Instance-specific FEC Object Transmission Information. 456 The format of the Scheme-Specific FEC Object Transmission information 457 for this FEC Scheme is defined in Figure 5 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Length | Instance-specific FEC OTI | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 | Instance-specific FEC OTI contd. | 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 5: Encoded Scheme-specific FEC OTI for Small Block, Large 469 Block and Expandable FEC Scheme 471 The Scheme-specific FEC Object Transmission Information field 472 contains the following sub-fields: 474 Length (1 octet) specifies the length of the Scheme-specific FEC OTI 475 in four-octet words (including this length field), except that the 476 value zero indicates that no Instance-specific FEC OTI information 477 follows. 479 Instance-specific FEC OTI Information the contents of this field 480 are FEC Scheme Instance-specific 482 Note that in the case of a Content Delivery protocol which supports 483 external signalling of the total FEC Object Transmission Information 484 length, then the Scheme-Specific FEC OTI field defined here is 485 optional. Otherwise, this field MUST be included. 487 4.3. Procedures 489 The algorithm defined in Section 9.1. of [RFC5052] MUST be used to 490 partition the file into source blocks. 492 4.4. FEC Code Specification 494 The FEC code specification and the correspondance of Encoding Symbols 495 IDs to encoding symbols are defined by specific instances of this 496 scheme and so are out of scope of this document. 498 5. Small Block Systematic FEC Scheme 500 5.1. Introduction 502 This section defines an Under-Specified FEC Scheme for Small Block 503 Systematic FEC codes as described in [RFC3453]. For Small Block 504 Systematic FEC codes, each source block is of length at most 65536 505 source symbols. 507 Although these codes can generally be accommodated by the FEC 508 Encoding ID described in Section 4, a specific FEC Encoding ID is 509 defined for Small Block Systematic FEC codes to allow more 510 flexibility and to retain header compactness. The small source block 511 length and small expansion factor that often characterize systematic 512 codes may require the data source to frequently change the source 513 block length. To allow the dynamic variation of the source block 514 length and to communicate it to the receivers with low overhead, the 515 block length is included in the FEC Payload ID. 517 5.2. Formats and Codes 519 5.2.1. FEC Payload ID(s) 521 The FEC Payload ID is composed of the Source Block Number, Source 522 Block Length and the Encoding Symbol ID structured as shown 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 | Source Block Number | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Source Block Length | Encoding Symbol ID | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 6: FEC Payload ID format for Small Block Systematic FEC scheme 535 The Source Block Number identifies from which source block of the 536 object the encoding symbol(s) in the payload are generated. These 537 blocks are numbered consecutively from 0 to N-1, where N is the 538 number of source blocks in the object. 540 The Source Block Length is the length in units of source symbols of 541 the source block identified by the Source Block Number. 543 The Encoding Symbol ID identifies which specific encoding symbol(s) 544 generated from the source block are carried in the packet payload. 545 Each encoding symbol is either an original source symbol or a 546 redundant symbol generated by the encoder. The exact details of the 547 correspondence between Encoding Symbol IDs and the encoding symbol(s) 548 in the packet payload are dependent on the particular FEC scheme 549 instance used as identified by the FEC Instance ID, and these details 550 may be proprietary. 552 5.2.2. FEC Object Transmission Information 554 5.2.2.1. Mandatory 556 The mandatory FEC Object Transmission Information element for the 557 Small Block Systematic FEC Scheme is: 559 o FEC Encoding ID: 129 561 5.2.2.2. Common 563 The common FEC Object Transmission Information elements and their 564 value ranges for the Small Block Systematic FEC Scheme are: 566 FEC Instance ID: a non-negative integer less than 2^^16. 568 Transfer-Length: a non-negative integer less than 2^^48. 570 Encoding-Symbol-Length: a non-negative integer less than 2^^16. 572 Maximum-Source-Block-Length: a non-negative integer less than 2^^16. 574 Max-Number-of-Encoding-Symbols: a non-negative integer less than 575 2^^16 577 Note that the semantics for the above elements are defined in 578 [RFC5052] and are not duplicated here. 580 The encoded Common FEC Object Transmission information is defined in 581 Figure 7. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Transfer Length | 587 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | | FEC Instance ID | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Encoding Symbol Length | Maximum Source Block Length | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Max. Num. of Encoding Symbols | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 7: FEC OTI format for Small Block Systematic FEC Scheme 597 All Encoding Symbols of a transport object MUST have length equal to 598 the length specified in the Encoding Symbol Length field, with the 599 optional exception of the last source symbol of the last source block 600 (so that redundant padding is not mandatory in this last symbol). 601 This last source symbol MUST be logically padded out with zeroes when 602 another Encoding Symbol is computed based on this source symbol to 603 ensure the same interpretation of this Encoding Symbol value by the 604 sender and receiver. However, this padding need not be actually sent 605 with the data of the last source symbol. 607 Note: this FEC Scheme was first defined in [RFC3452] which did not 608 require that the Encoding Symbol Length should be the same for 609 every source block. However, no protocols have been defined which 610 support variation in the Encoding Symbol Length between source 611 blocks and thus introduction of a general requirement that the 612 Encoding Symbol Length be the same across source blocks (as 613 defined here) should not cause backwards compatibility issues and 614 will aid interoperability. 616 5.2.2.3. Scheme-Specific 618 The Scheme-Specific FEC Object Transmission Information format 619 defined in Section 4.2.2.3 SHALL be used. 621 5.3. Procedures 623 The algorithm defined in Section 9.1. of [RFC5052] MAY be used to 624 partition the file into source blocks. Otherwise the FEC Scheme 625 instance MUST specify the algorithm that is used. 627 5.4. FEC Code Specification 629 The FEC code specification and the correspondance of Encoding Symbols 630 IDs to encoding symbols are defined by specific instances of this 631 scheme and so are out of scope of this document. 633 6. Compact FEC Scheme 635 6.1. Introduction 637 The Compact FEC Scheme is an Under-Specified FEC scheme. This FEC 638 scheme is similar in spirit to the Compact No-Code FEC scheme, except 639 that a non-trivial FEC encoding (that is Under-Specified) may be used 640 to generate encoding symbol(s) placed in the payload of each packet 641 and a corresponding FEC decoder may be used to produce the source 642 block from received packets. 644 6.2. Formats and Codes 646 6.2.1. FEC Payload ID(s) 648 The FEC Payload ID format defined in Section 3.2.1 SHALL be used. 650 6.2.2. FEC Object Transmission Information 652 6.2.2.1. Mandatory 654 The mandatory FEC Object Transmission Information element for the 655 Compact No-Code FEC Scheme is: 657 o FEC Encoding ID: 130 659 6.2.2.2. Common 661 The common FEC Object Transmission Information elements and their 662 encoding are the same as defined for the Small Block, Large Block and 663 Expandable FEC Scheme in Figure 4. 665 6.2.2.3. Scheme-Specific 667 The Scheme-Specific FEC Object Transmission Information format 668 defined in Section 4.2.2.3 SHALL be used. 670 6.3. Procedures 672 The algorithm defined in Section 9.1. of [RFC5052] MUST be used to 673 partition the file into source blocks. 675 6.4. FEC code specification 677 The FEC code specification and the correspondance of Encoding Symbols 678 IDs to encoding symbols are defined by specific instances of this 679 scheme and so are out of scope of this document. 681 7. Security Considerations 683 This specification does not introduce any further security 684 considerations beyond those described in [RFC5052]. 686 8. Acknowledgments 688 This document is substantially based on [RFC3695] by Michael Luby and 689 Lorenzo Vicisano and [RFC3452] by Michael Luby, Lorenzo Vicisano, Jim 690 Gemmell, Luigi Rizzo, Mark Handley and Jon Crowcroft. 692 9. IANA Considerations 694 FEC Encoding IDs 0 and 130 were first defined and registered in the 695 ietf:rmt:fec:encoding namespace by [RFC3695]. This document updates 696 and obsoletes the definitions from that specification. 698 FEC Encoding IDs 128 and 129 were first defined and registered in the 699 ietf:rmt:fec:encoding namespace by [RFC3452]. This document updates 700 and obsoletes the definitions from that specification. 702 Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA 703 registration. For general guidelines on IANA considerations as they 704 apply to this document, see [RFC5052]. 706 This document assigns the Fully-Specified FEC Encoding ID 0 under the 707 ietf:rmt:fec:encoding name-space (which was previously assigned by 708 [RFC3695] which is obsoleted by this document) to "Compact No-Code" 709 as specified in Section 3 above. 711 This document assigns the Under-Specified FEC Encoding ID 128 under 712 the ietf:rmt:fec:encoding name-space (which was previously assigned 713 by [RFC3452]) to "Small Block, Large Block and Expandable FEC Codes" 714 as specified in Section 4 above. 716 This document assigns the Under-Specified FEC Encoding ID 129 under 717 the ietf:rmt:fec:encoding name-space (which was previously assigned 718 by [RFC3452]) to "Small Block, Systematic FEC Codes" as specified in 719 Section 5 above. 721 This document assigns the Under-Specified FEC Encoding ID 130 under 722 the ietf:rmt:fec:encoding name-space (which was previously assigned 723 by [RFC3695] which is obsoleted by this document) to "Compact FEC" as 724 specified in Section 6 above. 726 As FEC Encoding IDs 128, 129 and 130 are Under-Specified, "FEC 727 Instance ID" sub-name-spaces must be established, in accordance to 728 [RFC5052]. Hence this document also assumes responsibility for the 729 "FEC Instance ID" registriesnamed 731 ietf:rmt:fec:encoding:instance:128, scoped by ietf:rmt:fec: 732 encoding = 128 734 ietf:rmt:fec:encoding:instance:129, scoped by ietf:rmt:fec: 735 encoding = 129 737 ietf:rmt:fec:encoding:instance:130, scoped by ietf:rmt:fec: 738 encoding = 130 740 The values that can be assigned within these namespaces are non- 741 negative numeric indices. Assignment requests are granted on a 742 "First Come First Served" basis. [RFC5052] specifies additional 743 criteria that MUST be met for the assignment within the generic ietf: 744 rmt:fec:encoding:instance name-space. These criteria also apply to 745 ietf:rmt:fec:encoding:instance:128, ietf:rmt:fec:encoding:instance: 746 129 and ietf:rmt:fec:encoding:instance:130. 748 10. Changes from schemes defined in RFC3452 and RFC3695 750 This section describes the changes between the Exprimental versions 751 of these FEC Scheme specifictions contained in RFC3452 [RFC3452] and 752 RFC3695 [RFC3695] and those defined in this specification: 754 o Scheme definitions have been updated to meet the requirements of 755 [RFC5052]. 757 o Complete encoding formats for the FEC Object Trasmission 758 Information for each scheme are defined here, instead of within 759 content delivery protocol specifications, since th exact format 760 depends on the FEC Scheme. 762 o The previous specifications for the Compact No-Code and Small 763 Block Systematic FEC Schemes sis not require that all encoding 764 symbols of the object should have the same length. This 765 requirement is introduced in this specification. Since no 766 protocols have been defined which support variation of the 767 encoding symbol length within an object this should not cause 768 backwards compatibility issues. 770 11. References 772 11.1. Normative References 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 778 Correction (FEC) Building Block", RFC 5052, August 2007. 780 11.2. Informative References 782 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 783 M., and J. Crowcroft, "Forward Error Correction (FEC) 784 Building Block", RFC 3452, December 2002. 786 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 787 M., and J. Crowcroft, "The Use of Forward Error Correction 788 (FEC) in Reliable Multicast", RFC 3453, December 2002. 790 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 791 Reliable Multicast Transport (RMT) Building Blocks and 792 Protocol Instantiation documents", RFC 3269, April 2002. 794 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 795 Floyd, S., and M. Luby, "Reliable Multicast Transport 796 Building Blocks for One-to-Many Bulk-Data Transfer", 797 RFC 3048, January 2001. 799 [RFC3695] Luby, M. and L. Vicisano, "Compact Forward Error 800 Correction (FEC) Schemes", RFC 3695, February 2004. 802 Author's Address 804 Mark Watson 805 Digital Fountain 806 39141 Civic Center Drive 807 Suite 300 808 Fremont, CA 94538 809 U.S.A. 811 Email: mark@digitalfountain.com 813 Full Copyright Statement 815 Copyright (C) The IETF Trust (2008). 817 This document is subject to the rights, licenses and restrictions 818 contained in BCP 78, and except as set forth therein, the authors 819 retain all their rights. 821 This document and the information contained herein are provided on an 822 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 823 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 824 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 825 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 826 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 829 Intellectual Property 831 The IETF takes no position regarding the validity or scope of any 832 Intellectual Property Rights or other rights that might be claimed to 833 pertain to the implementation or use of the technology described in 834 this document or the extent to which any license under such rights 835 might or might not be available; nor does it represent that it has 836 made any independent effort to identify any such rights. Information 837 on the procedures with respect to rights in RFC documents can be 838 found in BCP 78 and BCP 79. 840 Copies of IPR disclosures made to the IETF Secretariat and any 841 assurances of licenses to be made available, or the result of an 842 attempt made to obtain a general license or permission for the use of 843 such proprietary rights by implementers or users of this 844 specification can be obtained from the IETF on-line IPR repository at 845 http://www.ietf.org/ipr. 847 The IETF invites any interested party to bring to its attention any 848 copyrights, patents or patent applications, or other proprietary 849 rights that may cover technology that may be required to implement 850 this standard. Please address the information to the IETF at 851 ietf-ipr@ietf.org.