idnits 2.17.1 draft-ietf-fecframe-raptor-06.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 (November 24, 2011) is 4530 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: May 27, 2012 Nomor Research 6 M. Luby 7 Qualcomm Incorporated 8 November 24, 2011 10 Raptor FEC Schemes for FECFRAME 11 draft-ietf-fecframe-raptor-06 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 May 27, 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 [RFC6363] describes a framework for the application 128 of Forward Error Correction to arbitrary packet flows. Modeled after 129 the FEC Building Block developed by the IETF Reliable Multicast 130 Transport working group [RFC5052], the FEC Framework defines the 131 concept of FEC Schemes which provide specific Forward Error 132 Correction schemes. This document describes six FEC Schemes which 133 make use of the Raptor and RaptorQ FEC codes as defined in [RFC5053] 134 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 [RFC6363] is empty and the source packets are not modified 173 by the application of FEC, with obvious backwards compatibility 174 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 [RFC6363]. 191 When used with Raptor codes, this scheme is equivalent to that 192 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 [RFC6363]. 221 Symbol: A unit of data. Its size, in octets, is referred to as the 222 symbol size. 224 FEC Framework Configuration Information: Information that controls 225 the operation of the FEC Framework. Each FEC Framework instance 226 has its own configuration information. 228 4.2. Abbreviations 230 This document uses the following abbreviations. For further 231 abbreviations that apply to FEC Framework in general, see [RFC6363]. 233 FSSI: FEC-Scheme-Specific Information. 235 SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 237 RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 239 ADUI: Application Data Unit Information. 241 5. General procedures for Raptor FEC Schemes 243 This section specifies general procedures which apply to all Raptor 244 and RaptorQ FEC Schemes, specifically the construction of source 245 symbols from a set of source transport payloads. As described in 246 [RFC6363] for each Application Data Unit (ADU) in a source block, the 247 FEC Scheme is provided with: 249 o A description of the source data flow with which the ADU is 250 associated and an integer identifier associated with that flow. 252 o The ADU itself. 254 o The length of the ADU. 256 For each ADU, we define the Application Data Unit Information (ADUI) 257 as follows: 259 Let 260 o n be the number of ADUs in the source block. 262 o T be the source symbol size in octets. Note: this information is 263 provided by the FEC Scheme as defined below. 265 o i the index to the (i+1)-th ADU to be added to the source block, 0 266 <= i < n. 268 o R[i] denote the number of octets in the (i+1)-th ADU. 270 o l[i] be a length indication associated with the i-th ADU - the 271 nature of the length indication is defined by the FEC Scheme. 273 o L[i] denote two octets representing the value of l[i] in network 274 byte order (high order octet first) of the i-th ADU. 276 o f[i] denote the integer identifier associated with the source data 277 flow from which the i-th ADU was taken. 279 o F[i] denote a single octet representing the value of f[i]. 281 o s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note 282 s[i] is the length of SPI[i] in units of symbols of size T octets. 284 o P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding 285 octets to align the start of each UDP packet with the start of a 286 symbol. 288 o ADUI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. 290 Then, a source data block is constructed by concatenating ADUI[i] for 291 i = 0, 1, 2, ... n-1. The source data block size, S, is then given 292 by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer 293 Encoding Symbol IDs consecutively starting from zero within the 294 source block. Each ADU is associated with the Encoding Symbol ID of 295 the first symbol containing SPI for that packet. Thus, the Encoding 296 Symbol ID value associated with the j-th source packet, ESI[j], is 297 given by ESI[j] = 0, for j=0 and ESI[j] = sum{s[i], i=0,...,(j-1)}, 298 for 0 < j < n. 300 Source blocks are identified by integer Source Block Numbers. This 301 specification does not specify how Source Block Numbers are allocated 302 to source blocks. The Source FEC Packet Identification Information 303 consists of the identity of the source block and the Encoding Symbol 304 ID associated with the packet. 306 6. Raptor FEC Schemes for arbitrary packet flows 308 6.1. Introduction 310 This section specifies an FEC Scheme for the application of the 311 Raptor and RaptorQ codes to arbitrary packet flows. This scheme is 312 recommended in scenarios where maximal generality is required. 314 When used with Raptor codes, this scheme is equivalent to that 315 specified in [MBMSTS]. 317 6.2. Formats and Codes 319 6.2.1. FEC Framework Configuration Information 321 6.2.1.1. FEC Scheme ID 323 The value of the FEC Scheme ID for the fully-specified FEC scheme 324 defined in this section is XXX when [RFC5053] is used and YYY when 325 [RFC6330] is used, as assigned by IANA. 327 6.2.1.2. Scheme-Specific Elements 329 The scheme-specific elements of the FEC Framework Configuration 330 information for this scheme are as follows: 332 Maximum Source Block Length Name: "Kmax", Value range: A decimal 333 non-negative integer less than 8192 (for Raptor) or 56403 (for 334 RaptorQ), in units of symbols 336 Encoding Symbol Size Name: "T", Value range: A decimal non- 337 negative integer less than 65536, in units of octets 339 Payload ID Format Name: "P", Value range: "A" or "B" 341 An encoding format for The Maximum Source Block Length and Encoding 342 Symbol Size is defined below. 344 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Symbol Size (T) |Max. Source Block Length (Kmax)| 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |P| Reserved | 350 +-+-+-+-+-+-+-+-+ 352 Figure 1: FEC Scheme Specific Information 354 The P bit shall be set to zero to indicate Format A or to one to 355 indicate Format B. The last octet of the above encoding may be 356 omitted, in which case Format A shall be assumed. 358 The Payload ID Format identifier defines which of the Source FEC 359 Payload ID and Repair FEC Payload ID formats defined below shall be 360 used. Payload ID Format B SHALL NOT be used when[RFC5053] is used. 362 6.2.2. Source FEC Payload ID 364 This scheme makes use of an Explicit Source FEC Payload ID, which is 365 appended to the end of the source packets. Two formats are defined 366 for the Source FEC Payload ID, format A and format B. The format that 367 is used is signaled as part of the FEC Framework Configuration 368 Information. 370 The Source FEC Payload ID for format A is provided in Figure 2. 372 . 374 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 2: Source FEC Payload ID - Format A 382 Source Block Number (SBN), (16 bits): An integer identifier for the 383 source block that the source data within the packet relates to. 385 Encoding Symbol ID (ESI), (16 bits): The starting symbol index of 386 the source packet in the source block. 388 The Source FEC Payload ID for format B is provided in Figure 3. 390 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | SBN | Encoding Symbol ID (ESI) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Figure 3: Source FEC Payload ID - Format B 398 Source Block Number (SBN), (8 bits): An integer identifier for the 399 source block that the source data within the packet relates to. 401 Encoding Symbol ID (ESI), (24 bits): The starting symbol index of 402 the source packet in the source block. 404 6.2.3. Repair FEC Payload ID 406 Two formats for the Repair FEC Payload ID, Format A and Format B are 407 defined below. 409 The Repair FEC Payload ID for format A is provided in Figure 4. 411 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Source Block Length (SBL) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 4: Repair FEC Payload ID - Format A 421 Source Block Number (SBN), (16 bits) An integer identifier for the 422 source block that the repair symbols within the packet relate to. 423 For format A, it is of size 16 bits. 425 Encoding Symbol ID (ESI), (16 bits) Integer identifier for the 426 encoding symbols within the packet. 428 Source Block Length (SBL), (16 bits) The number of source symbols in 429 the source block. 431 The Repair FEC Payload ID for format B is provided in Figure 5. 433 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | SBN | Encoding Symbol ID (ESI) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Source Block Length (SBL) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Figure 5: Repair FEC Payload ID - Format B 443 Source Block Number (SBN), (8 bits) An integer identifier for the 444 source block that the repair symbols within the packet relate to. 445 For format A, it is of size 16 bits. 447 Encoding Symbol ID (ESI), (24 bits) Integer identifier for the 448 encoding symbols within the packet. 450 Source Block Length (SBL), (16 bits) The number of source symbols in 451 the source block. 453 The interpretation of the Source Block Number, Encoding Symbol 454 Identifier and Source Block Length is defined by the FEC Code 455 Specification. 457 6.3. Procedures 459 6.3.1. Source symbol construction 461 This FEC Scheme uses the procedures defined in Section 5 to construct 462 a set of source symbols to which the FEC code can be applied. The 463 sender MUST allocate Source Block Numbers to source blocks 464 sequentially, wrapping around to zero after Source Block Number 65535 465 (Format A) or 255 (Format B). 467 During the construction of the source block: 469 o the length indication, l[i], included in the Source Packet 470 Information for each packet shall be the transport payload length. 472 o the value of s[i] in the construction of the Source Packet 473 Information for each packet shall be the smallest integer such 474 that s[i]*T >= (l[i]+3). 476 6.3.2. Repair packet construction 478 The ESI value placed into a repair packet is calculated as specified 479 in Section 5.3.2 of [RFC5053] when Raptor as defined in [RFC5053] is 480 used and as specified in Section 4.4.2 of [RFC6330] when RaptorQ as 481 defined in [RFC6330] is used, where K=SBL. 483 6.4. FEC Code Specification 485 The Raptor FEC encoder defined in [RFC5053] or [RFC6330] SHALL be 486 used. The source symbols passed to the Raptor FEC encoder SHALL 487 consist of the source symbols constructed according to Section 6.3.1. 488 Thus the value of the parameter K used by the FEC encoder (equal to 489 the Source Block Length) may vary amongst the blocks of the stream 490 but SHALL NOT exceed the Maximum Source Block Length signaled in the 491 FEC Scheme-specific information. The symbol size, T, to be used for 492 source block construction and the repair symbol construction is equal 493 to the Encoding Symbol Size signaled in the FEC Scheme Specific 494 Information. 496 7. Optimised Raptor FEC Scheme for arbitrary packet flows 498 7.1. Introduction 500 This section specifies a slightly modified version of the FEC Scheme 501 specified in Section 6 which is applicable to scenarios in which only 502 relatively small block sizes will be used. These modifications admit 503 substantial optimisations to both sender and receiver 504 implementations. 506 In outline, the modifications are: 508 o All source blocks within a stream are encoded using the same 509 source block size. Code shortening is used to encode blocks of 510 different sizes. This is achieved by padding every block to the 511 required size using zero symbols before encoding. The zero 512 symbols are then discarded after decoding. The source block size 513 to be used for a stream is signaled in the Maximum Source Block 514 Size field of the scheme-specific information. This allows for 515 efficient parallel encoding of multiple streams. Note that the 516 padding operation is equivalent to the padding operation in 517 [RFC6330] with K' the specified single source block size and K the 518 actual source block size K. 520 o The possible choices of the source block size for a stream is 521 restricted to a small specified set of sizes. This allows 522 explicit operation sequences for encoding and decoding the 523 restricted set of source block sizes to be pre-calculated and 524 embedded in software or hardware. 526 When the Raptor FEC encoder as defined in [RFC5053] is used, this 527 scheme is equivalent to that specified in [dvbts] for arbitrary 528 packet flows. 530 7.2. Formats and Codes 532 7.2.1. FEC Framework Configuration Information 534 7.2.1.1. FEC Scheme ID 536 The value of the FEC Scheme ID for the fully-specified FEC scheme 537 defined in this section is XXX when [RFC5053] is used and YYY when 538 [RFC6330] is used, as assigned by IANA. 540 7.2.1.2. FEC Scheme specific information 542 See . (Section 6.2.1.2) 544 7.2.2. Source FEC Payload ID 546 See . (Section 6.2.2) 548 7.2.3. Repair FEC Payload ID 550 SeeSection 6.2.3 552 7.3. Procedures 554 7.3.1. Source symbol construction 556 See Section 6.3.1 558 7.3.2. Repair packet construction 560 The number of repair symbols contained within a repair packet is 561 computed from the packet length. The ESI value placed into a repair 562 packet is calculated as X + MSBL - SBL, where X would be the ESI 563 value of the repair packet if the ESI were calculated as specified in 564 Section 5.3.2 of [RFC5053] when Raptor as defined in[RFC5053] is used 565 and as specified in Section 4.4.2 of [RFC6330] when RaptorQ as 566 defined in [RFC6330] is used, where K=SBL. The value of SBL SHALL be 567 at most the value of MSBL. 569 7.4. FEC Code Specification 571 The Raptor FEC encoder defined in [RFC5053] or [RFC6330] SHALL be 572 used. The source symbols passed to the Raptor FEC encoder SHALL 573 consist of the source symbols constructed according to Section 6.3.1 574 extended with zero or more padding symbols such that the total number 575 of symbols in the source block is equal to the Maximum Source Block 576 Length signaled in the FEC Scheme Specific Information. Thus the 577 value of the parameter K used by the FEC encoded is equal to the 578 Maximum Source Block Length for all blocks of the stream. Padding 579 symbols shall consist entirely of octets set to the value zero. The 580 symbol size, T, to be used for source block construction and the 581 repair symbol construction is equal to the Encoding Symbol Size 582 signaled in the FEC Scheme Specific Information. 584 When [RFC5053] is used, the parameter T SHALL be set such that the 585 number of source symbols in any source block is at most 8192. The 586 Maximum Source Block Length parameter - and hence the number of 587 symbols used in the FEC Encoding and Decoding operations - SHALL be 588 set to one of the following values: 590 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 591 1139, 1281 593 When [RFC6330] is used, the parameter T SHALL be set such that the 594 number of source symbols in any source block is less than 56403. The 595 Maximum Source Block Length parameter SHALL be set to one of the 596 supported values for K' defined in Section 5.6 of [RFC6330]. 598 8. Raptor FEC Scheme for a single sequenced flow 600 8.1. Formats and codes 602 8.1.1. FEC Framework Configuration Information 604 8.1.1.1. FEC Scheme ID 606 The value of the FEC Scheme ID for the fully-specified FEC scheme 607 defined in this section is XXX when [RFC5053] is used and YYY when 608 [RFC6330] is used, as assigned by IANA. 610 8.1.1.2. Scheme-specific elements 612 See Section 6.2.1.2 614 8.1.2. Source FEC Payload ID 616 The Source FEC Payload ID field is not used by this FEC Scheme. 617 Source packets are not modified by this FEC Scheme. 619 8.1.3. Repair FEC Payload ID 621 Two formats for the Repair FEC Payload ID are defined, Format A and 622 Format B. 624 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Initial Sequence Number | Encoding Symbol ID | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Source Block Length | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Figure 6: Repair FEC Payload ID - Format A 634 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 635 the lowest 16 bits of the sequence number of the first packet to 636 be included in this sub-block. If the sequence numbers are 637 shorter than 16 bits then the received Sequence Number SHALL be 638 logically padded with zero bits to become 16 bits in length 639 respectively. 641 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 642 symbols are contained within this repair packet. The ESI provided 643 is the ESI of the first repair symbol in the packet. 645 Source Block Length (SBL) - 16 bits This field specifies the length 646 of the source block in symbols. 648 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Initial Sequence Number | Source Block Length | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Encoding Symbol ID | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Figure 7: Repair FEC Payload ID - Format B 658 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 659 the lowest 16 bits of the sequence number of the first packet to 660 be included in this sub-block. If the sequence numbers are 661 shorter than 16 bits then the received Sequence Number SHALL be 662 logically padded with zero bits to become 16 bits in length 663 respectively. 665 Source Block Length (SBL) - 16 bits This field specifies the length 666 of the source block in symbols. 668 Encoding Symbol ID (ESI) - 24 bits This field indicates which repair 669 symbols are contained within this repair packet. The ESI provided 670 is the ESI of the first repair symbol in the packet. 672 8.2. Procedures 674 8.2.1. Source symbol construction 676 This FEC Scheme uses the procedures defined in Section 5 to construct 677 a set of source symbols to which the FEC code can be applied. The 678 sender MUST allocate Source Block Numbers to source blocks 679 sequentially, wrapping around to zero after Source Block Number 65535 680 in the case Format A is used for FEC Payload IDs and 255 in the case 681 Format B is used for FEC Payload IDs. 683 During the construction of the source block: 685 o the length indication, l[i], included in the Source Packet 686 Information for each packet shall be dependent on the protocol 687 carried within the transport payload. Rules for RTP are specified 688 below. 690 o the value of s[i] in the construction of the Source Packet 691 Information for each packet shall be the smallest integer such 692 that s[i]*T >= (l[i]+3) 694 8.2.2. Derivation of Source FEC Packet Identification Information 696 The Source FEC Packet Identification Information for a source packet 697 is derived from the sequence number of the packet and information 698 received in any repair FEC packet belonging to this Source Block. 699 Source blocks are identified by the sequence number of the first 700 source packet in the block. This information is signaled in all 701 repair FEC packets associated with the source block in the Initial 702 Sequence Number field. 704 The length of the Source Packet Information (in octets) for source 705 packets within a source block is equal to length of the payload 706 containing encoding symbols of the repair packets (i.e. not including 707 the Repair FEC Payload ID) for that block, which MUST be the same for 708 all repair packets. The Application Data Unit Information Length 709 (ADUIL) in symbols is equal to this length divided by the Encoding 710 Symbol Size (which is signaled in the FEC Framework Configuration 711 Information). The set of source packets which are included in the 712 source block is determined from the Initial Sequence Number (ISN) and 713 Source Block Length (SBL) as follows: 715 Let, 717 o I be the Initial Sequence Number of the source block 718 o LP be the Source Packet Information Length in symbols 720 o LB be the Source Block Length in symbols 722 Then, source packets with sequence numbers from I to I +LB/LP-1 723 inclusive are included in the source block. 725 Note that if no FEC repair packets are received then no FEC decoding 726 is possible and it is unnecessary for the receiver to identify the 727 Source FEC Packet Identification Information for the source packets. 729 The Encoding Symbol ID for a packet is derived from the following 730 information: 732 o The sequence number, Ns, of the packet 734 o The Source Packet Information Length for the source block, LP 736 o The Initial Sequence Number of the source block, I 738 Then the Encoding Symbol ID for packet with sequence number Ns is 739 determined by the following formula: 741 ESI = ( Ns - I ) * LP 743 Note that all repair packet associated to a given Source Block MUST 744 contain the same Source Block Length and Initial Sequence Number. 746 8.2.3. Repair packet construction 748 See Section 7.3.2 750 8.2.4. Procedures for RTP source flows 752 In the specific case of RTP source packet flows, then the RTP 753 Sequence Number field SHALL be used as the sequence number in the 754 procedures described above. The length indication included in the 755 Application Data Unit Information SHALL be the RTP payload length 756 plus the length of the CSRCs, if any, the RTP Header Extension, if 757 present, and the RTP padding octets, if any. Note that this length 758 is always equal to the UDP payload length of the packet minus 12. 760 8.3. FEC Code Specification 762 See Section 7.4 764 9. Security Considerations 766 For the general security considerations related to the use of FEC, 767 refer to [RFC6363]. No security considerations specific to this 768 document have been identified. 770 10. Session Description Protocol (SDP) Signaling 772 This section provides an SDP [RFC4566] example. The syntax follows 773 the definition in [RFC6364] .Assume we have one source video stream 774 (mid:S1) and one FEC repair stream (mid:R1). We form one FEC group 775 with the "a=group:FEC-FR S1 R1" line. The source and repair streams 776 are sent to the same port on different multicast groups. The repair 777 window is set to 200 ms. 779 v=0 780 o=ali 1122334455 1122334466 IN IP4 fec.example.com 781 s=Raptor FEC Example 782 t=0 0 783 a=group:FEC-FR S1 R1 784 m=video 30000 RTP/AVP 100 785 c=IN IP4 233.252.0.1/127 786 a=rtpmap:100 MP2T/90000 787 a=fec-source-flow: id=0 788 a=mid:S1 789 m=application 30000 UDP/FEC 790 c=IN IP4 233.252.0.2/127 791 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A 792 a=repair-window:200ms 793 a=mid:R1 795 11. Congestion Control Considerations 797 For the general congestion control considerations related to the use 798 of FEC, refer to [RFC6363]. 800 12. IANA Considerations 802 12.1. Registration of FEC Scheme IDs 804 The value of FEC Scheme IDs is subject to IANA registration. For 805 general guidelines on IANA considerations as they apply to this 806 document, refer to [RFC6363]. 808 This document registers three values in the FEC Framework (FECFRAME) 809 FEC Encoding IDs registry as follows: 811 o 1 for the Raptor FEC Scheme for Arbitrary Packet Flows (Section 6 812 using Raptor [RFC5053]. 814 o 2 for the Raptor FEC Scheme for Arbitrary Packet Flows (Section 6 815 using RaptorQ [RFC6330]. 817 o 3 for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows 818 (Section 7) using Raptor [RFC5053]. 820 o 4 for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows 821 (Section 7) using RaptorQ [RFC6330]. 823 o 5 for the Raptor FEC Scheme for a single sequence flow (Section 8) 824 using Raptor [RFC5053]. 826 o 6 for the Raptor FEC Scheme for a single sequence flow (Section 8) 827 using RaptorQ [RFC6330]. 829 13. Acknowledgements 831 Thanks are due to Ali C. Begen for thorough review of earlier draft 832 versions of this document. 834 14. References 836 14.1. Normative References 838 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 839 Correction (FEC) Framework", RFC 6363, October 2011. 841 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 842 "Raptor Forward Error Correction Scheme for Object 843 Delivery", RFC 5053, October 2007. 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", BCP 14, RFC 2119, March 1997. 848 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 849 and L. Minder, "RaptorQ Forward Error Correction Scheme 850 for Object Delivery", RFC 6330, August 2011. 852 14.2. Informative References 854 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 855 Correction (FEC) Building Block", RFC 5052, August 2007. 857 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 858 Description Protocol", RFC 4566, July 2006. 860 [RFC6364] Begen, A., "Session Description Protocol Elements for the 861 Forward Error Correction (FEC) Framework", RFC 6364, 862 October 2011. 864 [dvbts] "ETSI TS 102 034 - Digital Video Broadcasting (DVB); 865 Transport of MPEG-2 Based DVB Services over IP Based 866 Networks", March 2005. 868 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 869 Protocols and codecs", 3GPP TS 26.346, April 2005. 871 Authors' Addresses 873 Mark Watson 874 Netflix 875 100 Winchester Circle 876 Los Gatos, CA 95032 877 U.S.A. 879 Email: watsonm@netflix.com 881 Thomas Stockhammer 882 Nomor Research 883 Brecherspitzstrasse 8 884 Munich 81541 885 Germany 887 Email: stockhammer@nomor.de 889 Michael Luby 890 Qualcomm Incorporated 891 3165 Kifer Road 892 Santa Clara, CA 95051 893 U.S.A. 895 Email: luby@qualcomm.com