idnits 2.17.1 draft-ietf-fecframe-raptor-08.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 (February 24, 2012) is 4444 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: August 27, 2012 Nomor Research 6 M. Luby 7 Qualcomm Incorporated 8 February 24, 2012 10 Raptor FEC Schemes for FECFRAME 11 draft-ietf-fecframe-raptor-08 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 August 27, 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 . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 121 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 122 14.2. Informative References . . . . . . . . . . . . . . . . . . 21 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 Raptor codes, this scheme is equivalent to that 326 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 XXX(RFC5053-ARBITRARY) when [RFC5053] is 336 used and XXX(RFC6330-ARBITRARY) when [RFC6330] is used, as assigned 337 by IANA. 339 6.2.1.2. Scheme-Specific Elements 341 The scheme-specific elements of the FEC Framework Configuration 342 information for this scheme are as follows: 344 MSBL Value range: A decimal non-negative integer less than 8192 345 (for Raptor) or 56403 (for RaptorQ), in units of symbols 347 Encoding Symbol Size Name: "T", Value range: A decimal non- 348 negative integer less than 65536, in units of octets 350 Payload ID Format Name: "P", Value range: "A" or "B" 352 An encoding format for The MSBL and Encoding Symbol Size is defined 353 below. 355 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Symbol Size (T) | MSBL | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |P| Reserved | 361 +-+-+-+-+-+-+-+-+ 363 Figure 1: FEC Scheme Specific Information 365 The P bit shall be set to zero to indicate Payload ID Format A or to 366 one to indicate Payload ID Format B. The last octet of FEC Scheme 367 Specific Information may be omitted indicating that Payload ID Format 368 A is in use. The Payload ID Format identifier defines which of the 369 Source FEC Payload ID and Repair FEC Payload ID formats defined below 370 shall be used. Payload ID Format B SHALL NOT be used when[RFC5053] 371 is used. The two formats enable different use cases. Format A is 372 appropriate in case the stream has many typically smaller source 373 blocks and Format B is applicable if the stream has fewer large 374 source blocks each with many encoding symbols. 376 6.2.2. Source FEC Payload ID 378 This scheme makes use of an Explicit Source FEC Payload ID, which is 379 appended to the end of the source packets. Two formats are defined 380 for the Source FEC Payload ID, format A and format B. The format that 381 is used is signaled as part of the FEC Framework Configuration 382 Information. 384 The Source FEC Payload ID for format A is provided in Figure 2. 386 . 388 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 2: Source FEC Payload ID - Format A 396 Source Block Number (SBN), (16 bits): An integer identifier for the 397 source block that the source data within the packet relates to. 399 Encoding Symbol ID (ESI), (16 bits): The starting symbol index of 400 the source packet in the source block. 402 The Source FEC Payload ID for format B is provided in Figure 3. 404 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | SBN | Encoding Symbol ID (ESI) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 3: Source FEC Payload ID - Format B 412 Source Block Number (SBN), (8 bits): An integer identifier for the 413 source block that the source data within the packet relates to. 415 Encoding Symbol ID (ESI), (24 bits): The starting symbol index of 416 the source packet in the source block. 418 6.2.3. Repair FEC Payload ID 420 Two formats for the Repair FEC Payload ID, Format A and Format B are 421 defined below. 423 The Repair FEC Payload ID for format A is provided in Figure 4. 425 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Source Block Length (SBL) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 4: Repair FEC Payload ID - Format A 435 Source Block Number (SBN), (16 bits) An integer identifier for the 436 source block that the repair symbols within the packet relate to. 437 For format A, it is of size 16 bits. 439 Encoding Symbol ID (ESI), (16 bits) Integer identifier for the 440 encoding symbols within the packet. 442 Source Block Length (SBL), (16 bits) The number of source symbols in 443 the source block. 445 The Repair FEC Payload ID for format B is provided in Figure 5. 447 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | SBN | Encoding Symbol ID (ESI) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Source Block Length (SBL) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 5: Repair FEC Payload ID - Format B 457 Source Block Number (SBN), (8 bits) An integer identifier for the 458 source block that the repair symbols within the packet relate to. 459 For format B, it is of size 8 bits. 461 Encoding Symbol ID (ESI), (24 bits) Integer identifier for the 462 encoding symbols within the packet. 464 Source Block Length (SBL), (16 bits) The number of source symbols in 465 the source block. 467 The interpretation of the Source Block Number, Encoding Symbol 468 Identifier and Source Block Length is defined by the FEC Code 469 Specification in [RFC5053] and [RFC6330]. 471 6.3. Procedures 473 6.3.1. Source symbol construction 475 This FEC Scheme uses the procedures defined in Section 5 to construct 476 a set of source symbols to which the FEC code can be applied. The 477 sender MUST allocate Source Block Numbers to source blocks 478 sequentially, wrapping around to zero after Source Block Number 65535 479 (Format A) or 255 (Format B). 481 During the construction of the source block: 483 o the length indication, l[i], included in the Source Packet 484 Information for each packet shall be the transport payload length, 485 i.e. the length of the ADU. 487 o the value of s[i] in the construction of the Source Packet 488 Information for each packet shall be the smallest integer such 489 that s[i]*T >= (l[i]+3). 491 6.3.2. Repair packet construction 493 When using Raptor [RFC5053], the ESI value placed into a repair 494 packet is calculated as specified in Section 5.3.2 of [RFC5053]. 496 When using Raptor! [RFC6330], the ESI value placed into a repair 497 packet is calculated as specified in Section 4.4.2 of [RFC6330]. 499 In both cases K is identical to SBL. 501 6.4. FEC Code Specification 503 The Raptor FEC encoder defined in [RFC5053] or [RFC6330] SHALL be 504 used. The source symbols passed to the Raptor FEC encoder SHALL 505 consist of the source symbols constructed according to Section 6.3.1. 506 Thus the value of the parameter K used by the FEC encoder (equal to 507 the Source Block Length) may vary amongst the blocks of the stream 508 but SHALL NOT exceed the Maximum Source Block Length signaled in the 509 FEC Scheme-specific information. The symbol size, T, to be used for 510 source block construction and the repair symbol construction is equal 511 to the Encoding Symbol Size signaled in the FEC Scheme Specific 512 Information. 514 7. Optimised Raptor FEC Scheme for arbitrary packet flows 516 7.1. Introduction 518 This section specifies a slightly modified version of the FEC Scheme 519 specified in Section 6 which is applicable to scenarios in which only 520 relatively small block sizes will be used. These modifications admit 521 substantial optimisations to both sender and receiver 522 implementations. 524 In outline, the modifications are: 526 o All source blocks within a stream are encoded using the same 527 source block size. Code shortening is used to encode blocks of 528 different sizes. This is achieved by padding every block to the 529 required size using zero symbols before encoding. The zero 530 symbols are then discarded after decoding. The source block size 531 to be used for a stream is signaled in the Maximum Source Block 532 Length (MSBL) field of the scheme-specific information. This 533 allows for efficient parallel encoding of multiple streams. Note 534 that the padding operation is equivalent to the padding operation 535 in [RFC6330] with K' the specified MSBL and K the actual source 536 block length K. 538 o The possible choices of the MSBL for a stream is restricted to a 539 small specified set. This allows explicit operation sequences for 540 encoding and decoding the restricted set of source block lengths 541 to be pre-calculated and embedded in software or hardware. 543 When the Raptor FEC encoder as defined in [RFC5053] is used, this 544 scheme is equivalent to that specified in [dvbts] for arbitrary 545 packet flows. 547 7.2. Formats and Codes 549 7.2.1. FEC Framework Configuration Information 551 7.2.1.1. FEC Scheme ID 553 The value of the FEC Scheme ID for the fully-specified FEC scheme 554 defined in this section is XXX(RFC5053-OPTIMISED) when [RFC5053] is 555 used and XXX(RFC6330-OPTIMISED) when [RFC6330] is used, as assigned 556 by IANA. 558 7.2.1.2. FEC Scheme specific information 560 See . (Section 6.2.1.2). The MSBL value is one of the values as 561 defined in section . (Section 7.4). 563 7.2.2. Source FEC Payload ID 565 See Section 6.2.2. 567 7.2.3. Repair FEC Payload ID 569 See Section 6.2.3. 571 7.3. Procedures 573 7.3.1. Source symbol construction 575 See Section 6.3.1. 577 7.3.2. Repair packet construction 579 The number of repair symbols contained within a repair packet is 580 computed from the packet length. The ESI value placed into a repair 581 packet is calculated as X + MSBL - SBL, where X would be the ESI 582 value of the repair packet if the ESI were calculated as specified in 583 Section 5.3.2 of [RFC5053] when Raptor as defined in[RFC5053] is used 584 and as specified in Section 4.4.2 of [RFC6330] when RaptorQ as 585 defined in [RFC6330] is used, where K=SBL. The value of SBL SHALL be 586 at most the value of MSBL. 588 7.4. FEC Code Specification 590 The Raptor FEC encoder defined in [RFC5053] or [RFC6330] SHALL be 591 used. The source symbols passed to the Raptor FEC encoder SHALL 592 consist of the source symbols constructed according to Section 6.3.1 593 extended with zero or more padding symbols such that the total number 594 of symbols in the source block is equal to the MSBL signaled in the 595 FEC Scheme Specific Information. Thus the value of the parameter K 596 used by the FEC encoded is equal to the MSBL for all blocks of the 597 stream. Padding symbols shall consist entirely of octets set to the 598 value zero. The symbol size, T, to be used for source block 599 construction and the repair symbol construction is equal to the 600 Encoding Symbol Size signaled in the FEC Scheme Specific Information. 602 When [RFC5053] is used, the parameter T SHALL be set such that the 603 number of source symbols in any source block is at most 8192. The 604 MSBL parameter - and hence the number of symbols used in the FEC 605 Encoding and Decoding operations - SHALL be set to one of the 606 following values: 608 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 609 1139, 1281 611 When [RFC6330] is used, the parameter T SHALL be set such that the 612 number of source symbols in any source block is less than 56403. The 613 MSBL parameter SHALL be set to one of the supported values for K' 614 defined in Section 5.6 of [RFC6330]. 616 8. Raptor FEC Scheme for a single sequenced flow 618 8.1. Formats and codes 620 8.1.1. FEC Framework Configuration Information 622 8.1.1.1. FEC Scheme ID 624 The value of the FEC Scheme ID for the fully-specified FEC scheme 625 defined in this section is XXX(RFC5053-SINGLE) when [RFC5053] is used 626 and XXX(RFC6330-SINGLE) when [RFC6330] is used, as assigned by IANA. 628 8.1.1.2. Scheme-specific elements 630 See Section 6.2.1.2 632 8.1.2. Source FEC Payload ID 634 The Source FEC Payload ID field is not used by this FEC Scheme. 635 Source packets are not modified by this FEC Scheme. 637 8.1.3. Repair FEC Payload ID 639 Two formats for the Repair FEC Payload ID are defined, Format A and 640 Format B. 642 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Initial Sequence Number | Source Block Length | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Encoding Symbol ID | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Figure 6: Repair FEC Payload ID - Format A 652 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 653 the lowest 16 bits of the sequence number of the first packet to 654 be included in this sub-block. If the sequence numbers are 655 shorter than 16 bits then the received Sequence Number SHALL be 656 logically padded with zero bits to become 16 bits in length 657 respectively. 659 Source Block Length (SBL) - 16 bits This field specifies the length 660 of the source block in symbols. 662 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 663 symbols are contained within this repair packet. The ESI provided 664 is the ESI of the first repair symbol in the packet. 666 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Initial Sequence Number | Source Block Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Encoding Symbol ID | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 7: Repair FEC Payload ID - Format B 676 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 677 the lowest 16 bits of the sequence number of the first packet to 678 be included in this sub-block. If the sequence numbers are 679 shorter than 16 bits then the received Sequence Number SHALL be 680 logically padded with zero bits to become 16 bits in length 681 respectively. 683 Source Block Length (SBL) - 16 bits This field specifies the length 684 of the source block in symbols. 686 Encoding Symbol ID (ESI) - 24 bits This field indicates which repair 687 symbols are contained within this repair packet. The ESI provided 688 is the ESI of the first repair symbol in the packet. 690 8.2. Procedures 692 8.2.1. Source symbol construction 694 This FEC Scheme uses the procedures defined in Section 5 to construct 695 a set of source symbols to which the FEC code can be applied. 697 During the construction of the source block: 699 o the length indication, l[i], included in the Source Packet 700 Information for each packet shall be dependent on the protocol 701 carried within the transport payload. Rules for RTP are specified 702 below. 704 o the value of s[i] in the construction of the Source Packet 705 Information for each packet shall be the smallest integer such 706 that s[i]*T >= (l[i]+3) 708 8.2.2. Derivation of Source FEC Packet Identification Information 710 The Source FEC Packet Identification Information for a source packet 711 is derived from the sequence number of the packet and information 712 received in any repair FEC packet belonging to this Source Block. 713 Source blocks are identified by the sequence number of the first 714 source packet in the block. This information is signaled in all 715 repair FEC packets associated with the source block in the Initial 716 Sequence Number field. 718 The length of the Source Packet Information (in octets) for source 719 packets within a source block is equal to length of the payload 720 containing encoding symbols of the repair packets (i.e. not including 721 the Repair FEC Payload ID) for that block, which MUST be the same for 722 all repair packets. The Application Data Unit Information Length 723 (ADUIL) in symbols is equal to this length divided by the Encoding 724 Symbol Size (which is signaled in the FEC Framework Configuration 725 Information). The set of source packets which are included in the 726 source block is determined from the Initial Sequence Number (ISN) and 727 Source Block Length (SBL) as follows: 729 Let, 731 o I be the Initial Sequence Number of the source block 733 o LP be the Source Packet Information Length in symbols 735 o LB be the Source Block Length in symbols 737 Then, source packets with sequence numbers from I to I +(LB/LP)-1 738 inclusive are included in the source block. The Source Block Length 739 LB MUST be chosen such that it is at least as large as the largest 740 Source Packet Information Length LP. 742 Note that if no FEC repair packets are received then no FEC decoding 743 is possible and it is unnecessary for the receiver to identify the 744 Source FEC Packet Identification Information for the source packets. 746 The Encoding Symbol ID for a packet is derived from the following 747 information: 749 o The sequence number, Ns, of the packet 751 o The Source Packet Information Length for the source block, LP 753 o The Initial Sequence Number of the source block, I 755 Then the Encoding Symbol ID for packet with sequence number Ns is 756 determined by the following formula: 758 ESI = ( Ns - I ) * LP 760 Note that all repair packet associated to a given Source Block MUST 761 contain the same Source Block Length and Initial Sequence Number. 763 Note also that the source packet flow processed by the FEC encoder 764 MUST have consecutive sequence numbers. In case the incoming source 765 packet flow has a gap in the sequence numbers then implementors 766 SHOULD insert an ADU in the source block that complies to the format 767 of the source packet flow, but is ignored at the application with 768 high probability. For additional guidelines refer to [RFC6363], 769 Section 10.2, paragraph 5. 771 8.2.3. Repair packet construction 773 See Section 7.3.2 775 8.2.4. Procedures for RTP source flows 777 In the specific case of RTP source packet flows, then the RTP 778 Sequence Number field SHALL be used as the sequence number in the 779 procedures described above. The length indication included in the 780 Application Data Unit Information SHALL be the RTP payload length 781 plus the length of the CSRCs, if any, the RTP Header Extension, if 782 present, and the RTP padding octets, if any. Note that this length 783 is always equal to the UDP payload length of the packet minus 12. 785 8.3. FEC Code Specification 787 See Section 7.4 789 9. Security Considerations 791 For the general security considerations related to the use of FEC, 792 refer to [RFC6363]. No security vulnerabilities specific to this 793 document have been identified. 795 10. Session Description Protocol (SDP) Signaling 797 This section provides an SDP [RFC4566] example. The syntax follows 798 the definition in [RFC6364] .Assume we have one source video stream 799 (mid:S1) and one FEC repair stream (mid:R1). We form one FEC group 800 with the "a=group:FEC-FR S1 R1" line. The source and repair streams 801 are sent to the same port on different multicast groups. The repair 802 window is set to 200 ms. 804 v=0 805 o=ali 1122334455 1122334466 IN IP4 fec.example.com 806 s=Raptor FEC Example 807 t=0 0 808 a=group:FEC-FR S1 R1 809 m=video 30000 RTP/AVP 100 810 c=IN IP4 233.252.0.1/127 811 a=rtpmap:100 MP2T/90000 812 a=fec-source-flow: id=0 813 a=mid:S1 814 m=application 30000 UDP/FEC 815 c=IN IP4 233.252.0.2/127 816 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A 817 a=repair-window:200ms 818 a=mid:R1 820 11. Congestion Control Considerations 822 For the general congestion control considerations related to the use 823 of FEC, refer to [RFC6363]. 825 12. IANA Considerations 827 12.1. Registration of FEC Scheme IDs 829 The value of FEC Scheme IDs is subject to IANA registration. For 830 general guidelines on IANA considerations as they apply to this 831 document, refer to [RFC6363]. 833 This document registers six values in the FEC Framework (FECFRAME) 834 FEC Encoding IDs registry as follows: 836 o 1 for the Raptor FEC Scheme for Arbitrary Packet Flows (Section 6 837 using Raptor [RFC5053]. 839 o 2 for the RaptorQ FEC Scheme for Arbitrary Packet Flows (Section 6 840 using RaptorQ [RFC6330]. 842 o 3 for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows 843 (Section 7) using Raptor [RFC5053]. 845 o 4 for the Optimised RaptorQ FEC Scheme for Arbitrary Packet Flows 846 (Section 7) using RaptorQ [RFC6330]. 848 o 5 for the Raptor FEC Scheme for a single sequence flow (Section 8) 849 using Raptor [RFC5053]. 851 o 6 for the RaptorQ FEC Scheme for a single sequence flow 852 (Section 8) using RaptorQ [RFC6330]. 854 13. Acknowledgements 856 Thanks are due to Ali C. Begen and David Harrington for thorough 857 review of earlier draft versions of this document. 859 14. References 861 14.1. Normative References 863 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 864 Correction (FEC) Framework", RFC 6363, October 2011. 866 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 867 "Raptor Forward Error Correction Scheme for Object 868 Delivery", RFC 5053, October 2007. 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, March 1997. 873 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 874 and L. Minder, "RaptorQ Forward Error Correction Scheme 875 for Object Delivery", RFC 6330, August 2011. 877 14.2. Informative References 879 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 880 Correction (FEC) Building Block", RFC 5052, August 2007. 882 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 883 Description Protocol", RFC 4566, July 2006. 885 [RFC6364] Begen, A., "Session Description Protocol Elements for the 886 Forward Error Correction (FEC) Framework", RFC 6364, 887 October 2011. 889 [dvbts] "ETSI TS 102 034 - Digital Video Broadcasting (DVB); 890 Transport of MPEG-2 Based DVB Services over IP Based 891 Networks", March 2005. 893 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 894 Protocols and codecs", 3GPP TS 26.346, April 2005. 896 Authors' Addresses 898 Mark Watson 899 Netflix 900 100 Winchester Circle 901 Los Gatos, CA 95032 902 U.S.A. 904 Email: watsonm@netflix.com 906 Thomas Stockhammer 907 Nomor Research 908 Brecherspitzstrasse 8 909 Munich 81541 910 Germany 912 Email: stockhammer@nomor.de 914 Michael Luby 915 Qualcomm Incorporated 916 3165 Kifer Road 917 Santa Clara, CA 95051 918 U.S.A. 920 Email: luby@qualcomm.com