idnits 2.17.1 draft-ietf-fecframe-raptor-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 18, 2011) is 4597 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) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework M. Watson 3 Internet-Draft Netflix 4 Intended status: Standards Track T. Stockhammer 5 Expires: March 21, 2012 Nomor Research 6 M. Luby 7 Qualcomm Incorporated 8 September 18, 2011 10 Raptor FEC Schemes for FECFRAME 11 draft-ietf-fecframe-raptor-05 13 Abstract 15 This document describes Fully-Specified Forward Error Correction 16 (FEC) Schemes for the Raptor and RaptorQ codes and their application 17 to reliable delivery of media streams in the context of FEC 18 Framework. The Raptor and RaptorQ codes are systematic codes, where 19 a number of repair symbols are generated from a set of source symbols 20 and sent in one or more repair flows in addition to the source 21 symbols that are sent to the receiver(s) within a source flow. The 22 Raptor and RaptorQ codes offer close to optimal protection against 23 arbitrary packet losses at a low computational complexity. Six FEC 24 Schemes are defined, two for protection of arbitrary packet flows, 25 two that are optimised for small source blocks and another two for 26 protection of a single flow that already contains a sequence number. 27 Repair data may be sent over arbitrary datagram transport (e.g. UDP) 28 or using RTP. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 21, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Document Outline . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 78 4. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 79 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 81 5. General procedures for Raptor FEC Schemes . . . . . . . . . . 7 82 6. Raptor FEC Schemes for arbitrary packet flows . . . . . . . . 9 83 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 84 6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 9 85 6.2.1. FEC Framework Configuration Information . . . . . . . 9 86 6.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 10 87 6.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 11 88 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 12 89 6.3.1. Source symbol construction . . . . . . . . . . . . . . 12 90 6.3.2. Repair packet construction . . . . . . . . . . . . . . 12 91 6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 13 92 7. Optimised Raptor FEC Scheme for arbitrary packet flows . . . . 13 93 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 13 94 7.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 14 95 7.2.1. FEC Framework Configuration Information . . . . . . . 14 96 7.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 14 97 7.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 14 98 7.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14 99 7.3.1. Source symbol construction . . . . . . . . . . . . . . 14 100 7.3.2. Repair packet construction . . . . . . . . . . . . . . 14 101 7.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 14 102 8. Raptor FEC Scheme for a single sequenced flow . . . . . . . . 15 103 8.1. Formats and codes . . . . . . . . . . . . . . . . . . . . 15 104 8.1.1. FEC Framework Configuration Information . . . . . . . 15 105 8.1.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 15 106 8.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 15 107 8.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17 108 8.2.1. Source symbol construction . . . . . . . . . . . . . . 17 109 8.2.2. Derivation of Source FEC Packet Identification 110 Information . . . . . . . . . . . . . . . . . . . . . 17 111 8.2.3. Repair packet construction . . . . . . . . . . . . . . 18 112 8.2.4. Procedures for RTP source flows . . . . . . . . . . . 18 113 8.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 18 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 115 10. Session Description Protocol (SDP) Signaling . . . . . . . . . 19 116 11. Congestion Control Considerations . . . . . . . . . . . . . . 19 117 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 118 12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 19 119 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 120 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 121 14.1. Normative References . . . . . . . . . . . . . . . . . . . 20 122 14.2. Informative References . . . . . . . . . . . . . . . . . . 21 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 125 1. Introduction 127 The FEC Framework [I-D.ietf-fecframe-framework] describes a framework 128 for the application of Forward Error Correction to arbitrary packet 129 flows. Modeled after the FEC Building Block developed by the IETF 130 Reliable Multicast Transport working group [RFC5052], the FEC 131 Framework defines the concept of FEC Schemes which provide specific 132 Forward Error Correction schemes. This document describes six FEC 133 Schemes which make use of the Raptor and RaptorQ FEC codes as defined 134 in [RFC5053] and [RFC6330]. 136 The FEC protection mechanism is independent of the type of the source 137 data, which can be an arbitrary sequence of packets, including for 138 example audio or video data. In general, the operation of the 139 protection mechanism is as follows: 141 o The sender determines a set of source packets (a source block) to 142 be protected together based on the FEC Framework Configuration 143 Information. 145 o The sender arranges the source packets into a set of source 146 symbols, each of which is the same size. 148 o The sender applies the Raptor/RaptorQ protection operation on the 149 source symbols to generate the required number of repair symbols. 151 o The sender packetizes the repair symbols and sends the repair 152 packet(s) along with the source packets to the receiver(s). 154 Per the FEC Framework requirements, the sender MUST transmit the 155 source and repair packets in different source and repair flows, or in 156 the case RTP transport is used for repair packets, in different RTP 157 streams. At the receiver side, if all of the source packets are 158 successfully received, there is no need for FEC recovery and the 159 repair packets are discarded. However, if there are missing source 160 packets, the repair packets can be used to recover the missing 161 information. 163 The operation of the FEC mechanism requires that the receiver can 164 identify the relationships between received source packets and repair 165 packets and in particular which source packets are missing. In many 166 cases, data already exists in the source packets which can be used to 167 refer to source packets and to identify which packets are missing. 168 In this case we assume it is possible to derive a "sequence number" 169 directly or indirectly from the source packets and this sequence 170 number can be used within the FEC Scheme. This case is referred to 171 as a "single sequenced flow". In this case the FEC Source Payload ID 172 defined in [I-D.ietf-fecframe-framework] is empty and the source 173 packets are not modified by the application of FEC, with obvious 174 backwards compatibility advantages. 176 Otherwise, it is necessary to add data to the source packets for FEC 177 purposes in the form of a non-empty FEC Source Payload ID. This case 178 if referred to as the "arbitrary packet flow" case. Accordingly, 179 this document defines six FEC Schemes, two for the case of a single 180 sequenced flow and four for the case of arbitrary packet flows. 182 2. Document Outline 184 This document is organised as follows: 186 o Section 5 defines general procedures applicable to the use of the 187 Raptor and RaptorQ codes in the context of the FEC Framework. 189 o Section 6defines an FEC Scheme for the case of arbitrary source 190 flows and follows the format defined for FEC Schemes in 191 [I-D.ietf-fecframe-framework]. When used with Raptor codes, this 192 scheme is equivalent to that defined in [MBMSTS]. 194 o Section 7 defines an FEC Scheme similar to that defined in 195 Section 6but with optimisations for the case where only limited 196 source block sizes are required. When used with Raptor codes, 197 this scheme is equivalent to that defined in [dvbts] for arbitrary 198 packet flows. 200 o Section 8 defines an FEC Scheme for the case of a single flow 201 which is already provided with a source packet sequence number. 202 When used with Raptor codes, this scheme is equivalent to that 203 defined in [dvbts] for the case of a single sequenced flow. 205 3. Requirements Notation 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119]. 211 4. Definitions and Abbreviations 213 The definitions, notations and abbreviations commonly used in this 214 document are summarized in this section. 216 4.1. Definitions 218 This document uses the following definitions. For further 219 definitions that apply to FEC Framework in general, see 220 [I-D.ietf-fecframe-framework]. 222 Symbol: A unit of data. Its size, in octets, is referred to as the 223 symbol size. 225 FEC Framework Configuration Information: Information that controls 226 the operation of the FEC Framework. Each FEC Framework instance 227 has its own configuration information. 229 4.2. Abbreviations 231 This document uses the following abbreviations. For further 232 abbreviations that apply to FEC Framework in general, see 233 [I-D.ietf-fecframe-framework]. 235 FSSI: FEC-Scheme-Specific Information. 237 SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 239 RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 241 ADUI: Application Data Unit Information. 243 5. General procedures for Raptor FEC Schemes 245 This section specifies general procedures which apply to all Raptor 246 and RaptorQ FEC Schemes, specifically the construction of source 247 symbols from a set of source transport payloads. As described in 248 [I-D.ietf-fecframe-framework] for each Application Data Unit (ADU) in 249 a source block, the FEC Scheme is provided with: 251 o A description of the source data flow with which the ADU is 252 associated and an integer identifier associated with that flow. 254 o The ADU itself. 256 o The length of the ADU. 258 For each ADU, we define the Application Data Unit Information (ADUI) 259 as follows: 261 Let 262 o n be the number of ADUs in the source block. 264 o T be the source symbol size in octets. Note: this information is 265 provided by the FEC Scheme as defined below. 267 o i the index to the (i+1)-th ADU to be added to the source block, 0 268 <= i < n. 270 o R[i] denote the number of octets in the (i+1)-th ADU. 272 o l[i] be a length indication associated with the i-th ADU - the 273 nature of the length indication is defined by the FEC Scheme. 275 o L[i] denote two octets representing the value of l[i] in network 276 byte order (high order octet first) of the i-th ADU. 278 o f[i] denote the integer identifier associated with the source data 279 flow from which the i-th ADU was taken. 281 o F[i] denote a single octet representing the value of f[i]. 283 o s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note 284 s[i] is the length of SPI[i] in units of symbols of size T octets. 286 o P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding 287 octets to align the start of each UDP packet with the start of a 288 symbol. 290 o ADUI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. 292 Then, a source data block is constructed by concatenating ADUI[i] for 293 i = 0, 1, 2, ... n-1. The source data block size, S, is then given 294 by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer 295 Encoding Symbol IDs consecutively starting from zero within the 296 source block. Each ADU is associated with the Encoding Symbol ID of 297 the first symbol containing SPI for that packet. Thus, the Encoding 298 Symbol ID value associated with the j-th source packet, ESI[j], is 299 given by ESI[j] = 0, for j=0 and ESI[j] = sum{s[i], i=0,...,(j-1)}, 300 for 0 < j < n. 302 Source blocks are identified by integer Source Block Numbers. This 303 specification does not specify how Source Block Numbers are allocated 304 to source blocks. The Source FEC Packet Identification Information 305 consists of the identity of the source block and the Encoding Symbol 306 ID associated with the packet. 308 6. Raptor FEC Schemes for arbitrary packet flows 310 6.1. Introduction 312 This section specifies an FEC Scheme for the application of the 313 Raptor and RaptorQ codes to arbitrary packet flows. This scheme is 314 recommended in scenarios where maximal generality is required. 316 When used with Raptor codes, this scheme is equivalent to that 317 specified in [MBMSTS]. 319 6.2. Formats and Codes 321 6.2.1. FEC Framework Configuration Information 323 6.2.1.1. FEC Scheme ID 325 The value of the FEC Scheme ID for the fully-specified FEC scheme 326 defined in this section is XXX when [RFC5053] is used and YYY when 327 [RFC6330] is used, as assigned by IANA. 329 6.2.1.2. Scheme-Specific Elements 331 The scheme-specific elements of the FEC Framework Configuration 332 information for this scheme are as follows: 334 Maximum Source Block Length Name: "Kmax", Value range: A decimal 335 non-negative integer less than 8192 (for Raptor) or 56403 (for 336 RaptorQ), in units of symbols 338 Encoding Symbol Size Name: "T", Value range: A decimal non- 339 negative integer less than 65536, in units of octets 341 Payload ID Format Name: "P", Value range: "A" or "B" 343 An encoding format for The Maximum Source Block Length and Encoding 344 Symbol Size is defined below. 346 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Symbol Size (T) |Max. Source Block Length (Kmax)| 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |P| Reserved | 352 +-+-+-+-+-+-+-+-+ 354 Figure 1: FEC Scheme Specific Information 356 The P bit shall be set to zero to indicate Format A or to one to 357 indicate Format B. The last octet of the above encoding may be 358 omitted, in which case Format A shall be assumed. 360 The Payload ID Format identifier defines which of the Source FEC 361 Payload ID and Repair FEC Payload ID formats defined below shall be 362 used. Payload ID Format B SHALL NOT be used when[RFC5053] is used. 364 6.2.2. Source FEC Payload ID 366 This scheme makes use of an Explicit Source FEC Payload ID, which is 367 appended to the end of the source packets. Two formats are defined 368 for the Source FEC Payload ID, format A and format B. The format that 369 is used is signaled as part of the FEC Framework Configuration 370 Information. 372 The Source FEC Payload ID for format A is provided in Figure 2. 374 . 376 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 2: Source FEC Payload ID - Format A 384 Source Block Number (SBN), (16 bits): An integer identifier for the 385 source block that the source data within the packet relates to. 387 Encoding Symbol ID (ESI), (16 bits): The starting symbol index of 388 the source packet in the source block. 390 The Source FEC Payload ID for format B is provided in Figure 3. 392 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | SBN | Encoding Symbol ID (ESI) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 3: Source FEC Payload ID - Format B 400 Source Block Number (SBN), (8 bits): An integer identifier for the 401 source block that the source data within the packet relates to. 403 Encoding Symbol ID (ESI), (24 bits): The starting symbol index of 404 the source packet in the source block. 406 6.2.3. Repair FEC Payload ID 408 Two formats for the Repair FEC Payload ID, Format A and Format B are 409 defined below. 411 The Repair FEC Payload ID for format A is provided in Figure 4. 413 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Source Block Length (SBL) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 4: Repair FEC Payload ID - Format A 423 Source Block Number (SBN), (16 bits) An integer identifier for the 424 source block that the repair symbols within the packet relate to. 425 For format A, it is of size 16 bits. 427 Encoding Symbol ID (ESI), (16 bits) Integer identifier for the 428 encoding symbols within the packet. 430 Source Block Length (SBL), (16 bits) The number of source symbols in 431 the source block. 433 The Repair FEC Payload ID for format B is provided in Figure 5. 435 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | SBN | Encoding Symbol ID (ESI) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Source Block Length (SBL) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 5: Repair FEC Payload ID - Format B 445 Source Block Number (SBN), (8 bits) An integer identifier for the 446 source block that the repair symbols within the packet relate to. 447 For format A, it is of size 16 bits. 449 Encoding Symbol ID (ESI), (24 bits) Integer identifier for the 450 encoding symbols within the packet. 452 Source Block Length (SBL), (16 bits) The number of source symbols in 453 the source block. 455 The interpretation of the Source Block Number, Encoding Symbol 456 Identifier and Source Block Length is defined by the FEC Code 457 Specification. 459 6.3. Procedures 461 6.3.1. Source symbol construction 463 This FEC Scheme uses the procedures defined in Section 5 to construct 464 a set of source symbols to which the FEC code can be applied. The 465 sender MUST allocate Source Block Numbers to source blocks 466 sequentially, wrapping around to zero after Source Block Number 65535 467 (Format A) or 255 (Format B). 469 During the construction of the source block: 471 o the length indication, l[i], included in the Source Packet 472 Information for each packet shall be the transport payload length. 474 o the value of s[i] in the construction of the Source Packet 475 Information for each packet shall be the smallest integer such 476 that s[i]*T >= (l[i]+3). 478 6.3.2. Repair packet construction 480 The ESI value placed into a repair packet is calculated as specified 481 in Section 5.3.2 of [RFC5053] when Raptor as defined in [RFC5053] is 482 used and as specified in Section 4.4.2 of [RFC6330] when RaptorQ as 483 defined in [RFC6330] is used, where K=SBL. 485 6.4. FEC Code Specification 487 The Raptor FEC encoder defined in [RFC5053] or [RFC6330] SHALL be 488 used. The source symbols passed to the Raptor FEC encoder SHALL 489 consist of the source symbols constructed according to Section 6.3.1. 490 Thus the value of the parameter K used by the FEC encoder (equal to 491 the Source Block Length) may vary amongst the blocks of the stream 492 but SHALL NOT exceed the Maximum Source Block Length signaled in the 493 FEC Scheme-specific information. The symbol size, T, to be used for 494 source block construction and the repair symbol construction is equal 495 to the Encoding Symbol Size signaled in the FEC Scheme Specific 496 Information. 498 7. Optimised Raptor FEC Scheme for arbitrary packet flows 500 7.1. Introduction 502 This section specifies a slightly modified version of the FEC Scheme 503 specified in Section 6 which is applicable to scenarios in which only 504 relatively small block sizes will be used. These modifications admit 505 substantial optimisations to both sender and receiver 506 implementations. 508 In outline, the modifications are: 510 o All source blocks within a stream are encoded using the same 511 source block size. Code shortening is used to encode blocks of 512 different sizes. This is achieved by padding every block to the 513 required size using zero symbols before encoding. The zero 514 symbols are then discarded after decoding. The source block size 515 to be used for a stream is signaled in the Maximum Source Block 516 Size field of the scheme-specific information. This allows for 517 efficient parallel encoding of multiple streams. Note that the 518 padding operation is equivalent to the padding operation in 519 [RFC6330] with K' the specified single source block size and K the 520 actual source block size K. 522 o The possible choices of the source block size for a stream is 523 restricted to a small specified set of sizes. This allows 524 explicit operation sequences for encoding and decoding the 525 restricted set of source block sizes to be pre-calculated and 526 embedded in software or hardware. 528 When the Raptor FEC encoder as defined in [RFC5053] is used, this 529 scheme is equivalent to that specified in [dvbts] for arbitrary 530 packet flows. 532 7.2. Formats and Codes 534 7.2.1. FEC Framework Configuration Information 536 7.2.1.1. FEC Scheme ID 538 The value of the FEC Scheme ID for the fully-specified FEC scheme 539 defined in this section is XXX when [RFC5053] is used and YYY when 540 [RFC6330] is used, as assigned by IANA. 542 7.2.1.2. FEC Scheme specific information 544 See . (Section 6.2.1.2) 546 7.2.2. Source FEC Payload ID 548 See . (Section 6.2.2) 550 7.2.3. Repair FEC Payload ID 552 SeeSection 6.2.3 554 7.3. Procedures 556 7.3.1. Source symbol construction 558 See Section 6.3.1 560 7.3.2. Repair packet construction 562 The number of repair symbols contained within a repair packet is 563 computed from the packet length. The ESI value placed into a repair 564 packet is calculated as X + MSBL - SBL, where X would be the ESI 565 value of the repair packet if the ESI were calculated as specified in 566 Section 5.3.2 of [RFC5053] when Raptor as defined in[RFC5053] is used 567 and as specified in Section 4.4.2 of [RFC6330] when RaptorQ as 568 defined in [RFC6330] is used, where K=SBL. The value of SBL SHALL be 569 at most the value of MSBL. 571 7.4. FEC Code Specification 573 The Raptor FEC encoder defined in [RFC5053] or [RFC6330] SHALL be 574 used. The source symbols passed to the Raptor FEC encoder SHALL 575 consist of the source symbols constructed according to Section 6.3.1 576 extended with zero or more padding symbols such that the total number 577 of symbols in the source block is equal to the Maximum Source Block 578 Length signaled in the FEC Scheme Specific Information. Thus the 579 value of the parameter K used by the FEC encoded is equal to the 580 Maximum Source Block Length for all blocks of the stream. Padding 581 symbols shall consist entirely of octets set to the value zero. The 582 symbol size, T, to be used for source block construction and the 583 repair symbol construction is equal to the Encoding Symbol Size 584 signaled in the FEC Scheme Specific Information. 586 When [RFC5053] is used, the parameter T SHALL be set such that the 587 number of source symbols in any source block is at most 8192. The 588 Maximum Source Block Length parameter - and hence the number of 589 symbols used in the FEC Encoding and Decoding operations - SHALL be 590 set to one of the following values: 592 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 593 1139, 1281 595 When [RFC6330] is used, the parameter T SHALL be set such that the 596 number of source symbols in any source block is less than 56403. The 597 Maximum Source Block Length parameter SHALL be set to one of the 598 supported values for K' defined in Section 5.6 of [RFC6330]. 600 8. Raptor FEC Scheme for a single sequenced flow 602 8.1. Formats and codes 604 8.1.1. FEC Framework Configuration Information 606 8.1.1.1. FEC Scheme ID 608 The value of the FEC Scheme ID for the fully-specified FEC scheme 609 defined in this section is XXX when [RFC5053] is used and YYY when 610 [RFC6330] is used, as assigned by IANA. 612 8.1.1.2. Scheme-specific elements 614 See Section 6.2.1.2 616 8.1.2. Source FEC Payload ID 618 The Source FEC Payload ID field is not used by this FEC Scheme. 619 Source packets are not modified by this FEC Scheme. 621 8.1.3. Repair FEC Payload ID 623 Two formats for the Repair FEC Payload ID are defined, Format A and 624 Format B. 626 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Initial Sequence Number | Encoding Symbol ID | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Source Block Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 6: Repair FEC Payload ID - Format A 636 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 637 the lowest 16 bits of the sequence number of the first packet to 638 be included in this sub-block. If the sequence numbers are 639 shorter than 16 bits then the received Sequence Number SHALL be 640 logically padded with zero bits to become 16 bits in length 641 respectively. 643 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 644 symbols are contained within this repair packet. The ESI provided 645 is the ESI of the first repair symbol in the packet. 647 Source Block Length (SBL) - 16 bits This field specifies the length 648 of the source block in symbols. 650 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Initial Sequence Number | Source Block Length | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Encoding Symbol ID | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Figure 7: Repair FEC Payload ID - Format B 660 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 661 the lowest 16 bits of the sequence number of the first packet to 662 be included in this sub-block. If the sequence numbers are 663 shorter than 16 bits then the received Sequence Number SHALL be 664 logically padded with zero bits to become 16 bits in length 665 respectively. 667 Source Block Length (SBL) - 16 bits This field specifies the length 668 of the source block in symbols. 670 Encoding Symbol ID (ESI) - 24 bits This field indicates which repair 671 symbols are contained within this repair packet. The ESI provided 672 is the ESI of the first repair symbol in the packet. 674 8.2. Procedures 676 8.2.1. Source symbol construction 678 This FEC Scheme uses the procedures defined in Section 5 to construct 679 a set of source symbols to which the FEC code can be applied. The 680 sender MUST allocate Source Block Numbers to source blocks 681 sequentially, wrapping around to zero after Source Block Number 65535 682 in the case Format A is used for FEC Payload IDs and 255 in the case 683 Format B is used for FEC Payload IDs. 685 During the construction of the source block: 687 o the length indication, l[i], included in the Source Packet 688 Information for each packet shall be dependent on the protocol 689 carried within the transport payload. Rules for RTP are specified 690 below. 692 o the value of s[i] in the construction of the Source Packet 693 Information for each packet shall be the smallest integer such 694 that s[i]*T >= (l[i]+3) 696 8.2.2. Derivation of Source FEC Packet Identification Information 698 The Source FEC Packet Identification Information for a source packet 699 is derived from the sequence number of the packet and information 700 received in any repair FEC packet belonging to this Source Block. 701 Source blocks are identified by the sequence number of the first 702 source packet in the block. This information is signaled in all 703 repair FEC packets associated with the source block in the Initial 704 Sequence Number field. 706 The length of the Source Packet Information (in octets) for source 707 packets within a source block is equal to length of the payload 708 containing encoding symbols of the repair packets (i.e. not including 709 the Repair FEC Payload ID) for that block, which MUST be the same for 710 all repair packets. The Application Data Unit Information Length 711 (ADUIL) in symbols is equal to this length divided by the Encoding 712 Symbol Size (which is signaled in the FEC Framework Configuration 713 Information). The set of source packets which are included in the 714 source block is determined from the Initial Sequence Number (ISN) and 715 Source Block Length (SBL) as follows: 717 Let, 719 o I be the Initial Sequence Number of the source block 720 o LP be the Source Packet Information Length in symbols 722 o LB be the Source Block Length in symbols 724 Then, source packets with sequence numbers from I to I +LB/LP-1 725 inclusive are included in the source block. 727 Note that if no FEC repair packets are received then no FEC decoding 728 is possible and it is unnecessary for the receiver to identify the 729 Source FEC Packet Identification Information for the source packets. 731 The Encoding Symbol ID for a packet is derived from the following 732 information: 734 o The sequence number, Ns, of the packet 736 o The Source Packet Information Length for the source block, LP 738 o The Initial Sequence Number of the source block, I 740 Then the Encoding Symbol ID for packet with sequence number Ns is 741 determined by the following formula: 743 ESI = ( Ns - I ) * LP 745 Note that all repair packet associated to a given Source Block MUST 746 contain the same Source Block Length and Initial Sequence Number. 748 8.2.3. Repair packet construction 750 See Section 7.3.2 752 8.2.4. Procedures for RTP source flows 754 In the specific case of RTP source packet flows, then the RTP 755 Sequence Number field SHALL be used as the sequence number in the 756 procedures described above. The length indication included in the 757 Application Data Unit Information SHALL be the RTP payload length 758 plus the length of the CSRCs, if any, the RTP Header Extension, if 759 present, and the RTP padding octets, if any. Note that this length 760 is always equal to the UDP payload length of the packet minus 12. 762 8.3. FEC Code Specification 764 See Section 7.4 766 9. Security Considerations 768 For the general security considerations related to the use of FEC, 769 refer to [I-D.ietf-fecframe-framework]. No security considerations 770 specific to this document have been identified. 772 10. Session Description Protocol (SDP) Signaling 774 This section provides an SDP [RFC4566] example. The syntax follows 775 the definition in [I-D.ietf-fecframe-sdp-elements] .Assume we have 776 one source video stream (mid:S1) and one FEC repair stream (mid:R1). 777 We form one FEC group with the "a=group:FEC-FR S1 R1" line. The 778 source and repair streams are sent to the same port on different 779 multicast groups. The repair window is set to 200 ms. 781 v=0 782 o=ali 1122334455 1122334466 IN IP4 fec.example.com 783 s=Raptor FEC Example 784 t=0 0 785 a=group:FEC-FR S1 R1 786 m=video 30000 RTP/AVP 100 787 c=IN IP4 233.252.0.1/127 788 a=rtpmap:100 MP2T/90000 789 a=fec-source-flow: id=0 790 a=mid:S1 791 m=application 30000 UDP/FEC 792 c=IN IP4 233.252.0.2/127 793 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A 794 a=repair-window:200ms 795 a=mid:R1 797 11. Congestion Control Considerations 799 For the general congestion control considerations related to the use 800 of FEC, refer to [I-D.ietf-fecframe-framework]. 802 12. IANA Considerations 804 12.1. Registration of FEC Scheme IDs 806 The value of FEC Scheme IDs is subject to IANA registration. For 807 general guidelines on IANA considerations as they apply to this 808 document, refer to [I-D.ietf-fecframe-framework]. 810 This document registers three values in the FEC Framework (FECFRAME) 811 FEC Encoding IDs registry as follows: 813 o 1 for the Raptor FEC Scheme for Arbitrary Packet Flows (Section 6 814 using Raptor [RFC5053]. 816 o 2 for the Raptor FEC Scheme for Arbitrary Packet Flows (Section 6 817 using RaptorQ [RFC6330]. 819 o 3 for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows 820 (Section 7) using Raptor [RFC5053]. 822 o 4 for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows 823 (Section 7) using RaptorQ [RFC6330]. 825 o 5 for the Raptor FEC Scheme for a single sequence flow (Section 8) 826 using Raptor [RFC5053]. 828 o 6 for the Raptor FEC Scheme for a single sequence flow (Section 8) 829 using RaptorQ [RFC6330]. 831 13. Acknowledgements 833 Thanks are due to Ali C. Begen for thorough review of earlier draft 834 versions of this document. 836 14. References 838 14.1. Normative References 840 [I-D.ietf-fecframe-framework] 841 Watson, M., Begen, A., and V. Roca, "Forward Error 842 Correction (FEC) Framework", 843 draft-ietf-fecframe-framework-15 (work in progress), 844 June 2011. 846 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 847 "Raptor Forward Error Correction Scheme for Object 848 Delivery", RFC 5053, October 2007. 850 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 851 Requirement Levels", BCP 14, RFC 2119, March 1997. 853 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 854 and L. Minder, "RaptorQ Forward Error Correction Scheme 855 for Object Delivery", RFC 6330, August 2011. 857 14.2. Informative References 859 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 860 Correction (FEC) Building Block", RFC 5052, August 2007. 862 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 863 Description Protocol", RFC 4566, July 2006. 865 [I-D.ietf-fecframe-sdp-elements] 866 Begen, A., "Session Description Protocol Elements for FEC 867 Framework", October 2010. 869 [dvbts] "ETSI TS 102 034 - Digital Video Broadcasting (DVB); 870 Transport of MPEG-2 Based DVB Services over IP Based 871 Networks", March 2005. 873 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 874 Protocols and codecs", 3GPP TS 26.346, April 2005. 876 Authors' Addresses 878 Mark Watson 879 Netflix 880 100 Winchester Circle 881 Los Gatos, CA 95032 882 U.S.A. 884 Email: watsonm@netflix.com 886 Thomas Stockhammer 887 Nomor Research 888 Brecherspitzstrasse 8 889 Munich 81541 890 Germany 892 Email: stockhammer@nomor.de 894 Michael Luby 895 Qualcomm Incorporated 896 3165 Kifer Road 897 Santa Clara, CA 95051 898 U.S.A. 900 Email: luby@qualcomm.com