idnits 2.17.1 draft-ietf-fecframe-raptor-10.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 (March 1, 2012) is 4437 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: September 2, 2012 Nomor Research 6 M. Luby 7 Qualcomm Incorporated 8 March 1, 2012 10 Raptor FEC Schemes for FECFRAME 11 draft-ietf-fecframe-raptor-10 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 September 2, 2012. 47 Copyright Notice 48 Copyright (c) 2012 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 . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . 15 101 7.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . 16 106 8.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . 18 111 8.2.3. Repair packet construction . . . . . . . . . . . . . . 19 112 8.2.4. Procedures for RTP source flows . . . . . . . . . . . 19 113 8.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 19 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 115 10. Session Description Protocol (SDP) Signaling . . . . . . . . . 19 116 11. Congestion Control Considerations . . . . . . . . . . . . . . 20 117 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 118 12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 20 119 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 120 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 121 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 122 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 125 1. Introduction 127 The FEC Framework [RFC6363] describes a general framework for the use 128 of Forward Error Correction in association with 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) and the source packets to the receiver(s). Per the FEC 153 Framework requirements, the sender MUST transmit the source and 154 repair packets in different source and repair flows, or in the 155 case RTP transport is used for repair packets, in different RTP 156 streams. 158 o At the receiver side, if all of the source packets are 159 successfully received, there is no need for FEC recovery and the 160 repair packets are discarded. However, if there are missing 161 source packets, the repair packets can be used to recover the 162 missing information. 164 The operation of the FEC mechanism requires that the receiver can 165 identify the relationships between received source packets and repair 166 packets and in particular which source packets are missing. In many 167 cases, data already exists in the source packets which can be used to 168 refer to source packets and to identify which packets are missing. 169 In this case we assume it is possible to derive a "sequence number" 170 directly or indirectly from the source packets and this sequence 171 number can be used within the FEC Scheme. This case is referred to 172 as a "single sequenced flow". In this case the FEC Source Payload ID 173 defined in [RFC6363] is empty and the source packets are not modified 174 by the application of FEC, with obvious backwards compatibility 175 advantages. 177 Otherwise, it is necessary to add data to the source packets for FEC 178 purposes in the form of a non-empty FEC Source Payload ID. This case 179 is referred to as the "arbitrary packet flow" case. Accordingly, 180 this document defines six FEC Schemes, two for the case of a single 181 sequenced flow and four for the case of arbitrary packet flows. 183 2. Document Outline 185 This document is organised as follows: 187 o Section 5 defines general procedures applicable to the use of the 188 Raptor and RaptorQ codes in the context of the FEC Framework. 190 o Section 6defines an FEC Scheme for the case of arbitrary source 191 flows and follows the format defined for FEC Schemes in [RFC6363]. 192 When used with Raptor codes, this scheme is equivalent to that 193 defined in "3GPP TS 26.346: Multimedia Broadcast/Multicast 194 Service (MBMS); Protocols and codecs" [MBMSTS]. 196 o Section 7 defines an FEC Scheme similar to that defined in 197 Section 6but with optimisations for the case where only limited 198 source block sizes are required. When used with Raptor codes, 199 this scheme is equivalent to that defined in "ETSI TS 102.034: 200 Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB 201 Services over IP Based" Networks[dvbts] for arbitrary packet 202 flows. 204 o Section 8 defines an FEC Scheme for the case of a single flow 205 which is already provided with a source packet sequence number. 206 When used with Raptor codes, this scheme is equivalent to that 207 defined in [dvbts] for the case of a single sequenced flow. 209 3. Requirements Notation 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 4. Definitions and Abbreviations 217 The definitions, notations and abbreviations commonly used in this 218 document are summarized in this section. 220 4.1. Definitions 222 This document uses definitions that apply to FEC Framework in general 223 as defined in [RFC6363]. In addition, this document uses the 224 following definitions: 226 Symbol: A unit of data. Its size, in octets, is referred to as the 227 symbol size. 229 FEC Framework Configuration Information: Information that controls 230 the operation of the FEC Framework. Each FEC Framework instance 231 has its own configuration information. 233 4.2. Abbreviations 235 This document uses abbreviations that apply to FEC Framework in 236 general as defined in [RFC6363]. In addition, this document uses the 237 following abbreviations 239 FSSI: FEC-Scheme-Specific Information. 241 SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 243 RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 245 ADUI: Application Data Unit Information. 247 SPI: Source Packet Information. 249 MSBL Maximum Source Block Length 251 5. General procedures for Raptor FEC Schemes 253 This section specifies general procedures which apply to all Raptor 254 and RaptorQ FEC Schemes, specifically the construction of source 255 symbols from a set of source transport payloads. As described in 256 [RFC6363] for each Application Data Unit (ADU) in a source block, the 257 FEC Scheme is provided with: 259 o A description of the source data flow with which the ADU is 260 associated and an integer identifier associated with that flow. 262 o The ADU itself. 264 o The length of the ADU. 266 For each ADU, we define the Application Data Unit Information (ADUI) 267 as follows: 269 Let 271 o n be the number of ADUs in the source block. 273 o T be the source symbol size in octets. Note: this information is 274 provided by the FEC Scheme as defined below. 276 o i the index to the (i+1)-th ADU to be added to the source block, 0 277 <= i < n. 279 o f[i] denote the integer identifier associated with the source data 280 flow from which the i-th ADU was taken. 282 o F[i] denote a single octet representing the value of f[i]. 284 o l[i] be a length indication associated with the i-th ADU - the 285 nature of the length indication is defined by the FEC Scheme. 287 o L[i] denote two octets representing the value of l[i] in network 288 byte order (high order octet first) of the i-th ADU. 290 o R[i] denote the number of octets in the (i+1)-th ADU. 292 o s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note 293 s[i] is the length of SPI[i] in units of symbols of size T octets. 295 o P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding 296 octets to align the start of each UDP packet with the start of a 297 symbol. 299 o ADUI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. 301 Then, a source data block is constructed by concatenating ADUI[i] for 302 i = 0, 1, 2, ... n-1. The source data block size, S, is then given 303 by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer 304 Encoding Symbol IDs consecutively starting from zero within the 305 source block. Each ADU is associated with the Encoding Symbol ID of 306 the first symbol containing SPI for that packet. Thus, the Encoding 307 Symbol ID value associated with the j-th source packet, ESI[j], is 308 given by ESI[j] = 0, for j=0 and ESI[j] = sum{s[i], i=0,...,(j-1)}, 309 for 0 < j < n. 311 Source blocks are identified by integer Source Block Numbers. This 312 specification does not specify how Source Block Numbers are allocated 313 to source blocks. The Source FEC Packet Identification Information 314 consists of the identity of the source block and the Encoding Symbol 315 ID associated with the packet. 317 6. Raptor FEC Schemes for arbitrary packet flows 319 6.1. Introduction 321 This section specifies an FEC Scheme for the application of the 322 Raptor and RaptorQ codes to arbitrary packet flows. This scheme is 323 recommended in scenarios where maximal generality is required. 325 When used with the Raptor codes specified in [RFC5053], this scheme 326 is equivalent to that specified in [MBMSTS]. 328 6.2. Formats and Codes 330 6.2.1. FEC Framework Configuration Information 332 6.2.1.1. FEC Scheme ID 334 The value of the FEC Scheme ID for the fully-specified FEC scheme 335 defined in this section is XXX1 when [RFC5053] is used and XXX2 when 336 [RFC6330] is used, as assigned by IANA. 338 NOTE: To the RFC Editor: please change these XXX notations once 339 assigned, and remove this NOTE. 341 6.2.1.2. Scheme-Specific Elements 343 The scheme-specific elements of the FEC Framework Configuration 344 information for this scheme are as follows: 346 MSBL Value range: A decimal non-negative integer less than 8192 for 347 FEC Scheme XXX1 and less than 56403 for FEC Scheme XXX2, in units 348 of symbols 350 Encoding Symbol Size Name: "T", Value range: A decimal non- 351 negative integer less than 65536, in units of octets 353 Payload ID Format Name: "P", Value range: "A" or "B" 355 An encoding format for The MSBL and Encoding Symbol Size is defined 356 below. 358 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Symbol Size (T) | MSBL | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |P| Reserved | 364 +-+-+-+-+-+-+-+-+ 366 Figure 1: FEC Scheme Specific Information 368 The P bit shall be set to zero to indicate Payload ID Format A or to 369 one to indicate Payload ID Format B. The last octet of FEC Scheme 370 Specific Information may be omitted indicating that Payload ID Format 371 A is in use. The Payload ID Format identifier defines which of the 372 Source FEC Payload ID and Repair FEC Payload ID formats defined below 373 shall be used. Payload ID Format B SHALL NOT be used for FEC Scheme 374 XXX1. The two formats enable different use cases. Format A is 375 appropriate in case the stream has many typically smaller source 376 blocks and Format B is applicable if the stream has fewer large 377 source blocks each with many encoding symbols. 379 6.2.2. Source FEC Payload ID 381 This scheme makes use of an Explicit Source FEC Payload ID, which is 382 appended to the end of the source packets. Two formats are defined 383 for the Source FEC Payload ID, format A and format B. The format that 384 is used is signaled as part of the FEC Framework Configuration 385 Information. 387 The Source FEC Payload ID for format A is provided in Figure 2. 389 . 391 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 2: Source FEC Payload ID - Format A 399 Source Block Number (SBN), (16 bits): An integer identifier for the 400 source block that the source data within the packet relates to. 402 Encoding Symbol ID (ESI), (16 bits): The starting symbol index of 403 the source packet in the source block. 405 The Source FEC Payload ID for format B is provided in Figure 3. 407 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | SBN | Encoding Symbol ID (ESI) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 3: Source FEC Payload ID - Format B 415 Source Block Number (SBN), (8 bits): An integer identifier for the 416 source block that the source data within the packet relates to. 418 Encoding Symbol ID (ESI), (24 bits): The starting symbol index of 419 the source packet in the source block. 421 6.2.3. Repair FEC Payload ID 423 Two formats for the Repair FEC Payload ID, Format A and Format B are 424 defined below. 426 The Repair FEC Payload ID for format A is provided in Figure 4. 428 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Source Block Length (SBL) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 4: Repair FEC Payload ID - Format A 438 Source Block Number (SBN), (16 bits) An integer identifier for the 439 source block that the repair symbols within the packet relate to. 440 For format A, it is of size 16 bits. 442 Encoding Symbol ID (ESI), (16 bits) Integer identifier for the 443 encoding symbols within the packet. 445 Source Block Length (SBL), (16 bits) The number of source symbols in 446 the source block. 448 The Repair FEC Payload ID for format B is provided in Figure 5. 450 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | SBN | Encoding Symbol ID (ESI) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Source Block Length (SBL) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 5: Repair FEC Payload ID - Format B 460 Source Block Number (SBN), (8 bits) An integer identifier for the 461 source block that the repair symbols within the packet relate to. 462 For format B, it is of size 8 bits. 464 Encoding Symbol ID (ESI), (24 bits) Integer identifier for the 465 encoding symbols within the packet. 467 Source Block Length (SBL), (16 bits) The number of source symbols in 468 the source block. 470 The interpretation of the Source Block Number, Encoding Symbol 471 Identifier and Source Block Length is defined by the FEC Code 472 Specification in [RFC5053] for FEC Scheme XXX1 and [RFC6330] for FEC 473 Scheme XXX2. 475 6.3. Procedures 477 6.3.1. Source symbol construction 479 FEC Scheme XXX1 and FEC Scheme XXX2 use the procedures defined in 480 Section 5 to construct a set of source symbols to which the FEC code 481 can be applied. The sender MUST allocate Source Block Numbers to 482 source blocks sequentially, wrapping around to zero after Source 483 Block Number 65535 (Format A) or 255 (Format B). 485 During the construction of the source block: 487 o the length indication, l[i], included in the Source Packet 488 Information for each packet shall be the transport payload length, 489 i.e. the length of the ADU. 491 o the value of s[i] in the construction of the Source Packet 492 Information for each packet shall be the smallest integer such 493 that s[i]*T >= (l[i]+3). 495 6.3.2. Repair packet construction 497 For FEC Scheme XXX1, the ESI value placed into a repair packet is 498 calculated as specified in Section 5.3.2 of [RFC5053]. 500 For FEC Scheme XXX2 [RFC6330], the ESI value placed into a repair 501 packet is calculated as specified in Section 4.4.2 of [RFC6330]. 503 In both cases K is identical to SBL. 505 6.4. FEC Code Specification 507 The FEC encoder defined in [RFC5053] SHALL be used FEC Scheme XXX1 508 and the FEC encoder defined in [RFC6330] SHALL be used for FEC Scheme 509 XXX2. For both FEC Scheme XXX1 and FEC Scheme XXX2, the source 510 symbols passed to the FEC encoder SHALL consist of the source symbols 511 constructed according to Section 6.3.1. Thus the value of the 512 parameter K used by the FEC encoder (equal to the Source Block 513 Length) may vary amongst the blocks of the stream but SHALL NOT 514 exceed the Maximum Source Block Length signaled in the FEC Scheme- 515 specific information. The symbol size, T, to be used for source 516 block construction and the repair symbol construction is equal to the 517 Encoding Symbol Size signaled in the FEC Scheme Specific Information. 519 7. Optimised Raptor FEC Scheme for arbitrary packet flows 521 7.1. Introduction 523 This section specifies a slightly modified version of the FEC Scheme 524 specified in Section 6 which is applicable to scenarios in which only 525 relatively small block sizes will be used. These modifications admit 526 substantial optimisations to both sender and receiver 527 implementations. 529 In outline, the modifications are: 531 o All source blocks within a stream are encoded using the same 532 source block size. Code shortening is used to encode blocks of 533 different sizes. This is achieved by padding every block to the 534 required size using zero symbols before encoding. The zero 535 symbols are then discarded after decoding. The source block size 536 to be used for a stream is signaled in the Maximum Source Block 537 Length (MSBL) field of the scheme-specific information. This 538 allows for efficient parallel encoding of multiple streams. Note 539 that the padding operation is equivalent to the padding operation 540 in [RFC6330] with K' the specified MSBL and K the actual source 541 block length K. 543 o The possible choices of the MSBL for a stream is restricted to a 544 small specified set. This allows explicit operation sequences for 545 encoding and decoding the restricted set of source block lengths 546 to be pre-calculated and embedded in software or hardware. 548 When used with the Raptor codes specified in [RFC5053], this scheme 549 is equivalent to that specified in [dvbts] for arbitrary packet 550 flows. 552 7.2. Formats and Codes 554 7.2.1. FEC Framework Configuration Information 556 7.2.1.1. FEC Scheme ID 558 The value of the FEC Scheme ID for the fully-specified FEC scheme 559 defined in this section is XXX3 when [RFC5053] is used and XXX4 when 560 [RFC6330] is used, as assigned by IANA. 562 NOTE: To the RFC Editor: please change these XXX notations once 563 assigned, and remove this NOTE. 565 7.2.1.2. FEC Scheme specific information 567 The same as specified for FEC Scheme XXX1 for FEC Scheme XXX3, and 568 the same as specified for FEC Scheme XXX2 for FEC Scheme XXX4, as 569 specified in Section 6.2.2, except that the MSBL value is as defined 570 in Section 7.4. 572 7.2.2. Source FEC Payload ID 574 The same as specified for FEC Scheme XXX1 for FEC Scheme XXX3, and 575 the same as specified for FEC Scheme XXX2 for FEC Scheme XXX4, as 576 specified in Section 6.2.2. 578 7.2.3. Repair FEC Payload ID 580 The same as specified for FEC Scheme XXX1 for FEC Scheme XXX3, and 581 the same as specified for FEC Scheme XXX2 for FEC Scheme XXX4, as 582 specified in Section 6.2.3. 584 7.3. Procedures 586 7.3.1. Source symbol construction 588 See Section 6.3.1. 590 7.3.2. Repair packet construction 592 The number of repair symbols contained within a repair packet is 593 computed from the packet length. The ESI value placed into a repair 594 packet is calculated as X + MSBL - SBL, where X would be the ESI 595 value of the repair packet if the ESI were calculated as specified in 596 Section 5.3.2 of [RFC5053] for FEC Scheme XXX3 and as specified in 597 Section 4.4.2 of [RFC6330] for FEC Scheme XXX4, where K=SBL. The 598 value of SBL SHALL be at most the value of MSBL. 600 7.4. FEC Code Specification 602 The FEC encoder defined in [RFC5053] SHALL be used for FEC Scheme 603 XXX3 and the FEC encoder defined in [RFC6330] SHALL be used for FEC 604 Scheme XXX4. The source symbols passed to the FEC encoder SHALL 605 consist of the source symbols constructed according to Section 6.3.1 606 extended with zero or more padding symbols such that the total number 607 of symbols in the source block is equal to the MSBL signaled in the 608 FEC Scheme Specific Information. Thus the value of the parameter K 609 used by the FEC encoded is equal to the MSBL for all blocks of the 610 stream. Padding symbols shall consist entirely of octets set to the 611 value zero. The symbol size, T, to be used for source block 612 construction and the repair symbol construction is equal to the 613 Encoding Symbol Size signaled in the FEC Scheme Specific Information. 615 For FEC Scheme XXX3, the parameter T SHALL be set such that the 616 number of source symbols in any source block is at most 8192. The 617 MSBL parameter - and hence the number of symbols used in the FEC 618 Encoding and Decoding operations - SHALL be set to one of the 619 following values: 621 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 622 1139, 1281 624 For FEC Scheme XXX4, the parameter T SHALL be set such that the 625 number of source symbols in any source block is less than 56403. The 626 MSBL parameter SHALL be set to one of the supported values for K' 627 defined in Section 5.6 of [RFC6330]. 629 8. Raptor FEC Scheme for a single sequenced flow 631 8.1. Formats and codes 633 8.1.1. FEC Framework Configuration Information 634 8.1.1.1. FEC Scheme ID 636 The value of the FEC Scheme ID for the fully-specified FEC scheme 637 defined in this section is XXX5 when [RFC5053] is used and XXX6 when 638 [RFC6330] is used, as assigned by IANA. 640 NOTE: To the RFC Editor: please change these XXX notations once 641 assigned, and remove this NOTE. 643 8.1.1.2. Scheme-specific elements 645 The same as specified for FEC Scheme XXX1 for FEC Scheme XXX5, and 646 the same as specified for FEC Scheme XXX2 for FEC Scheme XXX6, as 647 specified in Section 6.2.1.2. 649 8.1.2. Source FEC Payload ID 651 The Source FEC Payload ID field is not used by this FEC Scheme. 652 Source packets are not modified by this FEC Scheme. 654 8.1.3. Repair FEC Payload ID 656 Two formats for the Repair FEC Payload ID are defined, Format A and 657 Format B. 659 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Initial Sequence Number | Source Block Length | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Encoding Symbol ID | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 6: Repair FEC Payload ID - Format A 669 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 670 the lowest 16 bits of the sequence number of the first packet to 671 be included in this sub-block. If the sequence numbers are 672 shorter than 16 bits then the received Sequence Number SHALL be 673 logically padded with zero bits to become 16 bits in length 674 respectively. 676 Source Block Length (SBL) - 16 bits This field specifies the length 677 of the source block in symbols. 679 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 680 symbols are contained within this repair packet. The ESI provided 681 is the ESI of the first repair symbol in the packet. 683 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Initial Sequence Number | Source Block Length | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Encoding Symbol ID | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 Figure 7: Repair FEC Payload ID - Format B 693 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 694 the lowest 16 bits of the sequence number of the first packet to 695 be included in this sub-block. If the sequence numbers are 696 shorter than 16 bits then the received Sequence Number SHALL be 697 logically padded with zero bits to become 16 bits in length 698 respectively. 700 Source Block Length (SBL) - 16 bits This field specifies the length 701 of the source block in symbols. 703 Encoding Symbol ID (ESI) - 24 bits This field indicates which repair 704 symbols are contained within this repair packet. The ESI provided 705 is the ESI of the first repair symbol in the packet. 707 8.2. Procedures 709 8.2.1. Source symbol construction 711 FEC Scheme XXX5 and FEC Scheme XXX6 use the procedures defined in 712 Section 5 to construct a set of source symbols to which the FEC code 713 can be applied. 715 During the construction of the source block: 717 o the length indication, l[i], included in the Source Packet 718 Information for each packet shall be dependent on the protocol 719 carried within the transport payload. Rules for RTP are specified 720 below. 722 o the value of s[i] in the construction of the Source Packet 723 Information for each packet shall be the smallest integer such 724 that s[i]*T >= (l[i]+3) 726 8.2.2. Derivation of Source FEC Packet Identification Information 728 The Source FEC Packet Identification Information for a source packet 729 is derived from the sequence number of the packet and information 730 received in any repair FEC packet belonging to this Source Block. 731 Source blocks are identified by the sequence number of the first 732 source packet in the block. This information is signaled in all 733 repair FEC packets associated with the source block in the Initial 734 Sequence Number field. 736 The length of the Source Packet Information (in octets) for source 737 packets within a source block is equal to length of the payload 738 containing encoding symbols of the repair packets (i.e. not including 739 the Repair FEC Payload ID) for that block, which MUST be the same for 740 all repair packets. The Application Data Unit Information Length 741 (ADUIL) in symbols is equal to this length divided by the Encoding 742 Symbol Size (which is signaled in the FEC Framework Configuration 743 Information). The set of source packets which are included in the 744 source block is determined from the Initial Sequence Number (ISN) and 745 Source Block Length (SBL) as follows: 747 Let, 749 o I be the Initial Sequence Number of the source block 751 o LP be the Source Packet Information Length in symbols 753 o LB be the Source Block Length in symbols 755 Then, source packets with sequence numbers from I to I +(LB/LP)-1 756 inclusive are included in the source block. The Source Block Length 757 LB MUST be chosen such that it is at least as large as the largest 758 Source Packet Information Length LP. 760 Note that if no FEC repair packets are received then no FEC decoding 761 is possible and it is unnecessary for the receiver to identify the 762 Source FEC Packet Identification Information for the source packets. 764 The Encoding Symbol ID for a packet is derived from the following 765 information: 767 o The sequence number, Ns, of the packet 769 o The Source Packet Information Length for the source block, LP 771 o The Initial Sequence Number of the source block, I 773 Then the Encoding Symbol ID for packet with sequence number Ns is 774 determined by the following formula: 776 ESI = ( Ns - I ) * LP 778 Note that all repair packet associated to a given Source Block MUST 779 contain the same Source Block Length and Initial Sequence Number. 781 Note also that the source packet flow processed by the FEC encoder 782 MUST have consecutive sequence numbers. In case the incoming source 783 packet flow has a gap in the sequence numbers then implementors 784 SHOULD insert an ADU in the source block that complies to the format 785 of the source packet flow, but is ignored at the application with 786 high probability. For additional guidelines refer to [RFC6363], 787 Section 10.2, paragraph 5. 789 8.2.3. Repair packet construction 791 See Section 7.3.2 793 8.2.4. Procedures for RTP source flows 795 In the specific case of RTP source packet flows, then the RTP 796 Sequence Number field SHALL be used as the sequence number in the 797 procedures described above. The length indication included in the 798 Application Data Unit Information SHALL be the RTP payload length 799 plus the length of the CSRCs, if any, the RTP Header Extension, if 800 present, and the RTP padding octets, if any. Note that this length 801 is always equal to the UDP payload length of the packet minus 12. 803 8.3. FEC Code Specification 805 The same as specified for FEC Scheme XXX3 for FEC Scheme XXX5, and 806 the same as specified for FEC Scheme XXX4 for FEC Scheme XXX6, as 807 specified in Section 7.4. 809 9. Security Considerations 811 For the general security considerations related to the use of FEC, 812 refer to [RFC6363]. No security vulnerabilities specific to this 813 document have been identified. 815 10. Session Description Protocol (SDP) Signaling 817 This section provides an SDP [RFC4566] example. The syntax follows 818 the definition in [RFC6364] .Assume we have one source video stream 819 (mid:S1) and one FEC repair stream (mid:R1). We form one FEC group 820 with the "a=group:FEC-FR S1 R1" line. The source and repair streams 821 are sent to the same port on different multicast groups. The repair 822 window is set to 200 ms. 824 v=0 825 o=ali 1122334455 1122334466 IN IP4 fec.example.com 826 s=Raptor FEC Example 827 t=0 0 828 a=group:FEC-FR S1 R1 829 m=video 30000 RTP/AVP 100 830 c=IN IP4 233.252.0.1/127 831 a=rtpmap:100 MP2T/90000 832 a=fec-source-flow: id=0 833 a=mid:S1 834 m=application 30000 UDP/FEC 835 c=IN IP4 233.252.0.2/127 836 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A 837 a=repair-window:200ms 838 a=mid:R1 840 11. Congestion Control Considerations 842 For the general congestion control considerations related to the use 843 of FEC, refer to [RFC6363]. 845 12. IANA Considerations 847 12.1. Registration of FEC Scheme IDs 849 The value of FEC Scheme IDs is subject to IANA registration. For 850 general guidelines on IANA considerations as they apply to this 851 document, refer to [RFC6363]. 853 This document registers six values in the FEC Framework (FECFRAME) 854 FEC Encoding IDs registry (http://www.iana.org/assignments/ 855 rmt-fec-parameters/rmt-fec-parameters.xml#fecframe-fec-encoding-ids) 856 as provided in Table 1. Each value refers to a fully-specified FEC 857 scheme. 859 NOTE: To the RFC Editor: please change these XXX notations once 860 assigned, and remove this NOTE. 862 +----------+---------------------+----------------------------------+ 863 | FEC | FEC Scheme | Reference | 864 | Encoding | Description | | 865 | ID | | | 866 +----------+---------------------+----------------------------------+ 867 | XXX1 | Raptor FEC Scheme | Section 6 in this document using | 868 | | for Arbitrary | [RFC5053] | 869 | | Packet Flows | | 870 +----------+---------------------+----------------------------------+ 871 | XXX2 | RaptorQ FEC Scheme | Section 6 in this document using | 872 | | for Arbitrary | [RFC6330]. | 873 | | Packet Flows | | 874 +----------+---------------------+----------------------------------+ 875 | XXX3 | Raptor FEC Scheme | Section 7 in this document using | 876 | | Optimised for | Raptor [RFC5053]. | 877 | | Arbitrary Packet | | 878 | | Flows | | 879 +----------+---------------------+----------------------------------+ 880 | XXX4 | RaptorQ FEC Scheme | XXX4 for the Optimised RaptorQ | 881 | | Optimised for | FEC Scheme for Arbitrary Packet | 882 | | Arbitrary Packet | Flows (Section 7) using RaptorQ | 883 | | Flows | [RFC6330]. | 884 +----------+---------------------+----------------------------------+ 885 | XXX5 | Raptor FEC Scheme | XXX5 for the Raptor FEC Scheme | 886 | | for a single | for a single sequence flow | 887 | | sequence flow | (Section 8) using Raptor | 888 | | | [RFC5053]. | 889 +----------+---------------------+----------------------------------+ 890 | XXX6 | RaptorQ FEC Scheme | XXX6 for the RaptorQ FEC Scheme | 891 | | for a single | for a single sequence flow | 892 | | sequence flow | (Section 8) using RaptorQ | 893 | | | [RFC6330]. | 894 +----------+---------------------+----------------------------------+ 896 Table 1: FEC Framework (FECFRAME) FEC Encoding IDs 898 13. Acknowledgements 900 Thanks are due to Ali C. Begen and David Harrington for thorough 901 review of earlier draft versions of this document. 903 14. References 904 14.1. Normative References 906 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 907 Correction (FEC) Framework", RFC 6363, October 2011. 909 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 910 "Raptor Forward Error Correction Scheme for Object 911 Delivery", RFC 5053, October 2007. 913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 914 Requirement Levels", BCP 14, RFC 2119, March 1997. 916 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 917 and L. Minder, "RaptorQ Forward Error Correction Scheme 918 for Object Delivery", RFC 6330, August 2011. 920 14.2. Informative References 922 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 923 Correction (FEC) Building Block", RFC 5052, August 2007. 925 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 926 Description Protocol", RFC 4566, July 2006. 928 [RFC6364] Begen, A., "Session Description Protocol Elements for the 929 Forward Error Correction (FEC) Framework", RFC 6364, 930 October 2011. 932 [dvbts] "ETSI TS 102 034 - Digital Video Broadcasting (DVB); 933 Transport of MPEG-2 Based DVB Services over IP Based 934 Networks", March 2005. 936 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 937 Protocols and codecs", 3GPP TS 26.346, April 2005. 939 Authors' Addresses 941 Mark Watson 942 Netflix 943 100 Winchester Circle 944 Los Gatos, CA 95032 945 U.S.A. 947 Email: watsonm@netflix.com 948 Thomas Stockhammer 949 Nomor Research 950 Brecherspitzstrasse 8 951 Munich 81541 952 Germany 954 Email: stockhammer@nomor.de 956 Michael Luby 957 Qualcomm Incorporated 958 3165 Kifer Road 959 Santa Clara, CA 95051 960 U.S.A. 962 Email: luby@qualcomm.com