idnits 2.17.1 draft-ietf-fecframe-raptor-11.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 (May 10, 2012) is 4368 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: November 11, 2012 Nomor Research 6 M. Luby 7 Qualcomm Incorporated 8 May 10, 2012 10 Raptor FEC Schemes for FECFRAME 11 draft-ietf-fecframe-raptor-11 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 November 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 89 6.3.1. Source symbol construction . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . 14 94 7.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 14 95 7.2.1. FEC Framework Configuration Information . . . . . . . 14 96 7.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 15 97 7.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 15 98 7.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 99 7.3.1. Source symbol construction . . . . . . . . . . . . . . 15 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 . . . . . . . . 16 103 8.1. Formats and codes . . . . . . . . . . . . . . . . . . . . 16 104 8.1.1. FEC Framework Configuration Information . . . . . . . 16 105 8.1.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 16 106 8.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 16 107 8.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 18 108 8.2.1. Source symbol construction . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . 20 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 115 10. Session Description Protocol (SDP) Signaling . . . . . . . . . 20 116 11. Congestion Control Considerations . . . . . . . . . . . . . . 21 117 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 118 12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 21 119 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 120 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 121 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 122 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 125 1. Introduction 127 The Forward Error Correction (FEC) Framework [RFC6363] describes a 128 general framework for the use of Forward Error Correction in 129 association with arbitrary packet flows. Modeled after the FEC 130 Building Block developed by the IETF Reliable Multicast Transport 131 working group [RFC5052], the FEC Framework defines the concept of FEC 132 Schemes which provide specific Forward Error Correction schemes. 133 This document describes six FEC Schemes which make use of the Raptor 134 and RaptorQ FEC codes as defined 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, for example 138 audio or video data. In general, the operation of the protection 139 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 Real-time Transport Protocol (RTP) transport is used for 156 repair packets, in different RTP 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 6 defines 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 6 but 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 The FEC-specific terminology used in this document is defined in 223 [RFC6363]. In this document, as in [RFC6363], the first letter of 224 each FEC-specific is capitalized along with the new terms defined 225 here: 227 Symbol: A unit of data. Its size, in octets, is referred to as the 228 symbol size. 230 FEC Framework Configuration Information: Information that controls 231 the operation of the FEC Framework. Each FEC Framework instance 232 has its own configuration information. 234 4.2. Abbreviations 236 This document uses abbreviations that apply to FEC Framework in 237 general as defined in [RFC6363]. In addition, this document uses the 238 following abbreviations 240 FSSI: FEC-Scheme-Specific Information. 242 SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 244 RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 246 ADU: Application Data Unit 248 ADUI: Application Data Unit Information. 250 SPI: Source Packet Information. 252 MSBL: Maximum Source Block Length 254 5. General procedures for Raptor FEC Schemes 256 This section specifies general procedures which apply to all Raptor 257 and RaptorQ FEC Schemes, specifically the construction of source 258 symbols from a set of source transport payloads. 260 For any field defined in this document, the octets are ordered in 261 network byte order. 263 As described in [RFC6363] for each Application Data Unit (ADU) in a 264 source block, the FEC Scheme is provided with: 266 o A description of the source data flow with which the ADU is 267 associated and an integer identifier associated with that flow. 269 o The ADU itself. 271 o The length of the ADU. 273 For each ADU, we define the Application Data Unit Information (ADUI) 274 as follows: 276 Let 278 o n be the number of ADUs in the source block. 280 o T be the source symbol size in octets. Note: this information is 281 provided by the FEC Scheme as defined below. 283 o i the index to the (i+1)-th ADU to be added to the source block, 0 284 <= i < n. 286 o f[i] denote the integer identifier associated with the source data 287 flow from which the i-th ADU was taken. 289 o F[i] denote a single octet representing the value of f[i]. 291 o l[i] be a length indication associated with the i-th ADU - the 292 nature of the length indication is defined by the FEC Scheme. 294 o L[i] denote two octets representing the value of l[i] in network 295 byte order (high order octet first) of the i-th ADU. 297 o R[i] denote the number of octets in the (i+1)-th ADU. 299 o s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note 300 s[i] is the length of SPI[i] in units of symbols of size T octets. 302 o P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding 303 octets to align the start of each UDP packet with the start of a 304 symbol. 306 o ADUI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. 308 Then, a source data block is constructed by concatenating ADUI[i] for 309 i = 0, 1, 2, ... n-1. The source data block size, S, is then given 310 by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer 311 Encoding Symbol IDs consecutively starting from zero within the 312 source block. Each ADU is associated with the Encoding Symbol ID of 313 the first symbol containing SPI for that packet. Thus, the Encoding 314 Symbol ID value associated with the j-th source packet, ESI[j], is 315 given by ESI[j] = 0, for j=0 and ESI[j] = sum{s[i], i=0,...,(j-1)}, 316 for 0 < j < n. 318 Source blocks are identified by integer Source Block Numbers. This 319 specification does not specify how Source Block Numbers are allocated 320 to source blocks. The Source FEC Packet Identification Information 321 consists of the identity of the source block and the Encoding Symbol 322 ID associated with the packet. 324 6. Raptor FEC Schemes for arbitrary packet flows 326 6.1. Introduction 328 This section specifies an FEC Scheme for the application of the 329 Raptor and RaptorQ codes to arbitrary packet flows. This scheme is 330 recommended in scenarios where maximal generality is required. 332 When used with the Raptor codes specified in [RFC5053], this scheme 333 is equivalent to that specified in [MBMSTS]. 335 6.2. Formats and Codes 337 6.2.1. FEC Framework Configuration Information 339 6.2.1.1. FEC Scheme ID 341 The value of the FEC Scheme ID for the fully-specified FEC scheme 342 defined in this section is XXX1 when [RFC5053] is used and XXX2 when 343 [RFC6330] is used, as assigned by IANA. 345 NOTE: To the RFC Editor: please change these XXX notations once 346 assigned, and remove this NOTE. 348 6.2.1.2. Scheme-Specific Elements 350 The scheme-specific elements of the FEC Framework Configuration 351 information for this scheme are as follows: 353 MSBL Value range: An non-negative integer less than 8192 for FEC 354 Scheme XXX1 and less than 56403 for FEC Scheme XXX2, in units of 355 symbols. The field type is unsigned integer. 357 Encoding Symbol Size Name: "T", Value range: A non-negative 358 integer less than 65536, in units of octets. The field type is 359 unsigned integer. 361 Payload ID Format Name: "P", Value range: "A" or "B". The P bit 362 shall be set to zero to indicate Payload ID Format A or to one to 363 indicate Payload ID Format B. 365 An encoding format for the MSBL and Encoding Symbol Size is defined 366 below. 368 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Symbol Size (T) | MSBL | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |P| Reserved | 374 +-+-+-+-+-+-+-+-+ 376 Figure 1: FEC Scheme Specific Information 378 The P bit shall be set to zero to indicate Payload ID Format A or to 379 one to indicate Payload ID Format B. The last octet of FEC Scheme 380 Specific Information SHOULD be omitted indicating that Payload ID 381 Format A is in use. The Payload ID Format identifier defines which 382 of the Source FEC Payload ID and Repair FEC Payload ID formats 383 defined below shall be used. Payload ID Format B SHALL NOT be used 384 for FEC Scheme XXX1. The two formats enable different use cases. 385 Format A is appropriate in case the stream has many typically smaller 386 source blocks and Format B is applicable if the stream has fewer 387 large source blocks each with many encoding symbols. 389 6.2.2. Source FEC Payload ID 391 This scheme makes use of an Explicit Source FEC Payload ID, which is 392 appended to the end of the source packets. Two formats are defined 393 for the Source FEC Payload ID, format A and format B. The format that 394 is used is signaled as part of the FEC Framework Configuration 395 Information. 397 The Source FEC Payload ID for format A is provided in Figure 2. 399 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 2: Source FEC Payload ID - Format A 407 Source Block Number (SBN), (16 bits): Identifier for the source 408 block that the source data within the packet relates. The field 409 type is unsigned integer. 411 Encoding Symbol ID (ESI), (16 bits): The starting symbol index of 412 the source packet in the source block. The field type is unsigned 413 integer. 415 The Source FEC Payload ID for format B is provided in Figure 3. 417 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | SBN | Encoding Symbol ID (ESI) | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 3: Source FEC Payload ID - Format B 425 Source Block Number (SBN), (8 bits): Identifier for the source block 426 that the source data within the packet relates. The field type is 427 unsigned integer. 429 Encoding Symbol ID (ESI), (24 bits): The starting symbol index of 430 the source packet in the source block. The field type is unsigned 431 integer. 433 6.2.3. Repair FEC Payload ID 435 Two formats for the Repair FEC Payload ID, Format A and Format B are 436 defined below. 438 The Repair FEC Payload ID for format A is provided in Figure 4. 440 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Source Block Length (SBL) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Figure 4: Repair FEC Payload ID - Format A 450 Source Block Number (SBN), (16 bits) Identifier for the source block 451 that the repair symbols within the packet relate. For format A, 452 it is of size 16 bits. The field type is unsigned integer. 454 Encoding Symbol ID (ESI), (16 bits) Identifier for the encoding 455 symbols within the packet. The field type is unsigned integer. 457 Source Block Length (SBL), (16 bits) The number of source symbols in 458 the source block. The field type is unsigned integer. 460 The Repair FEC Payload ID for format B is provided in Figure 5. 462 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | SBN | Encoding Symbol ID (ESI) | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Source Block Length (SBL) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 5: Repair FEC Payload ID - Format B 472 Source Block Number (SBN), (8 bits) Identifier for the source block 473 that the repair symbols within the packet relate. For format B, 474 it is of size 8 bits. The field type is unsigned integer. 476 Encoding Symbol ID (ESI), (24 bits) Identifier for the encoding 477 symbols within the packet. The field type is unsigned integer. 479 Source Block Length (SBL), (16 bits) The number of source symbols in 480 the source block. The field type is unsigned integer. 482 The interpretation of the Source Block Number, Encoding Symbol 483 Identifier and Source Block Length is defined by the FEC Code 484 Specification in [RFC5053] for FEC Scheme XXX1 and [RFC6330] for FEC 485 Scheme XXX2. 487 6.3. Procedures 489 6.3.1. Source symbol construction 491 FEC Scheme XXX1 and FEC Scheme XXX2 use the procedures defined in 492 Section 5 to construct a set of source symbols to which the FEC code 493 can be applied. The sender MUST allocate Source Block Numbers to 494 source blocks sequentially, wrapping around to zero after Source 495 Block Number 65535 (Format A) or 255 (Format B). 497 During the construction of the source block: 499 o the length indication, l[i], included in the Source Packet 500 Information for each packet shall be the transport payload length, 501 i.e. the length of the ADU. 503 o the value of s[i] in the construction of the Source Packet 504 Information for each packet shall be the smallest integer such 505 that s[i]*T >= (l[i]+3). 507 6.3.2. Repair packet construction 509 For FEC Scheme XXX1, the ESI value placed into a repair packet is 510 calculated as specified in Section 5.3.2 of [RFC5053]. 512 For FEC Scheme XXX2 [RFC6330], the ESI value placed into a repair 513 packet is calculated as specified in Section 4.4.2 of [RFC6330]. 515 In both cases K is identical to SBL. 517 6.4. FEC Code Specification 519 The FEC encoder defined in [RFC5053] SHALL be used FEC Scheme XXX1 520 and the FEC encoder defined in [RFC6330] SHALL be used for FEC Scheme 521 XXX2. For both FEC Scheme XXX1 and FEC Scheme XXX2, the source 522 symbols passed to the FEC encoder SHALL consist of the source symbols 523 constructed according to Section 6.3.1. Thus the value of the 524 parameter K used by the FEC encoder (equal to the Source Block 525 Length) may vary amongst the blocks of the stream but SHALL NOT 526 exceed the Maximum Source Block Length signaled in the FEC Scheme- 527 specific information. The symbol size, T, to be used for source 528 block construction and the repair symbol construction is equal to the 529 Encoding Symbol Size signaled in the FEC Scheme Specific Information. 531 7. Optimised Raptor FEC Scheme for arbitrary packet flows 532 7.1. Introduction 534 This section specifies a slightly modified version of the FEC Scheme 535 specified in Section 6 which is applicable to scenarios in which only 536 relatively small block sizes will be used. These modifications admit 537 substantial optimisations to both sender and receiver 538 implementations. 540 In outline, the modifications are: 542 o All source blocks within a stream are encoded using the same 543 source block size. Code shortening is used to encode blocks of 544 different sizes. This is achieved by padding every block to the 545 required size using zero symbols before encoding. The zero 546 symbols are then discarded after decoding. The source block size 547 to be used for a stream is signaled in the Maximum Source Block 548 Length (MSBL) field of the scheme-specific information. The 549 extended source block is constructed by adding zero or more 550 padding symbols such that the total number of symbols, MSBL, is 551 one of the values listed in Section 7.4. Each padding symbol 552 consists of T octets where the value of each octet is zero. MSBL 553 MUST be selected as the smallest value of the possible values in 554 Section 7.4 that is greater than or equal to K. 556 o The possible choices of the MSBL for a stream is restricted to a 557 small specified set. This allows explicit operation sequences for 558 encoding and decoding the restricted set of source block lengths 559 to be pre-calculated and embedded in software or hardware. 561 When used with the Raptor codes specified in [RFC5053], this scheme 562 is equivalent to that specified in [dvbts] for arbitrary packet 563 flows. 565 7.2. Formats and Codes 567 7.2.1. FEC Framework Configuration Information 569 7.2.1.1. FEC Scheme ID 571 The value of the FEC Scheme ID for the fully-specified FEC scheme 572 defined in this section is XXX3 when [RFC5053] is used and XXX4 when 573 [RFC6330] is used, as assigned by IANA. 575 NOTE: To the RFC Editor: please change these XXX notations once 576 assigned, and remove this NOTE. 578 7.2.1.2. FEC Scheme specific information 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.1.2, except that the MSBL value is as 583 defined in Section 7.4. 585 7.2.2. Source FEC Payload ID 587 The same as specified for FEC Scheme XXX1 for FEC Scheme XXX3, and 588 the same as specified for FEC Scheme XXX2 for FEC Scheme XXX4, as 589 specified in Section 6.2.2. 591 7.2.3. Repair FEC Payload ID 593 The same as specified for FEC Scheme XXX1 for FEC Scheme XXX3, and 594 the same as specified for FEC Scheme XXX2 for FEC Scheme XXX4, as 595 specified in Section 6.2.3. 597 7.3. Procedures 599 7.3.1. Source symbol construction 601 See Section 6.3.1. 603 7.3.2. Repair packet construction 605 The number of repair symbols contained within a repair packet is 606 computed from the packet length. The ESI value placed into a repair 607 packet is calculated as X + MSBL - SBL, where X would be the ESI 608 value of the repair packet if the ESI were calculated as specified in 609 Section 5.3.2 of [RFC5053] for FEC Scheme XXX3 and as specified in 610 Section 4.4.2 of [RFC6330] for FEC Scheme XXX4, where K=SBL. The 611 value of SBL SHALL be at most the value of MSBL. 613 7.4. FEC Code Specification 615 The FEC encoder defined in [RFC5053] SHALL be used for FEC Scheme 616 XXX3 and the FEC encoder defined in [RFC6330] SHALL be used for FEC 617 Scheme XXX4. The source symbols passed to the FEC encoder SHALL 618 consist of the source symbols constructed according to Section 6.3.1 619 extended with zero or more padding symbols. The extension SHALL be 620 such that the total number of symbols in the source block is equal to 621 the MSBL signaled in the FEC Scheme Specific Information. Thus the 622 value of the parameter K used by the FEC encoded is equal to the MSBL 623 for all blocks of the stream. Padding symbols shall consist entirely 624 of octets set to the value zero. The symbol size, T, to be used for 625 source block construction and the repair symbol construction is equal 626 to the Encoding Symbol Size signaled in the FEC Scheme Specific 627 Information. 629 For FEC Scheme XXX3, the parameter T SHALL be set such that the 630 number of source symbols in any source block is at most 8192. The 631 MSBL parameter, and hence the number of symbols used in the FEC 632 Encoding and Decoding operations, SHALL be set to one of the 633 following values: 635 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 636 1139, 1281 638 For FEC Scheme XXX4, the parameter T SHALL be set such that the 639 number of source symbols in any source block is less than 56403. The 640 MSBL parameter SHALL be set to one of the supported values for K' 641 defined in Section 5.6 of [RFC6330]. 643 8. Raptor FEC Scheme for a single sequenced flow 645 8.1. Formats and codes 647 8.1.1. FEC Framework Configuration Information 649 8.1.1.1. FEC Scheme ID 651 The value of the FEC Scheme ID for the fully-specified FEC scheme 652 defined in this section is XXX5 when [RFC5053] is used and XXX6 when 653 [RFC6330] is used, as assigned by IANA. 655 NOTE: To the RFC Editor: please change these XXX notations once 656 assigned, and remove this NOTE. 658 8.1.1.2. Scheme-specific elements 660 The same as specified for FEC Scheme XXX1 for FEC Scheme XXX5, and 661 the same as specified for FEC Scheme XXX2 for FEC Scheme XXX6, as 662 specified in Section 6.2.1.2. 664 8.1.2. Source FEC Payload ID 666 The Source FEC Payload ID field is not used by this FEC Scheme. 667 Source packets are not modified by this FEC Scheme. 669 8.1.3. Repair FEC Payload ID 671 Two formats for the Repair FEC Payload ID are defined, Format A and 672 Format B. 674 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Initial Sequence Number | Source Block Length | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Encoding Symbol ID | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Figure 6: Repair FEC Payload ID - Format A 684 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 685 the lowest 16 bits of the sequence number of the first packet to 686 be included in this sub-block. If the sequence numbers are 687 shorter than 16 bits then the received Sequence Number SHALL be 688 logically padded with zero bits to become 16 bits in length 689 respectively. The field type is unsigned integer. 691 Source Block Length (SBL) - 16 bits This field specifies the length 692 of the source block in symbols. The field type is unsigned 693 integer. 695 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 696 symbols are contained within this repair packet. The ESI provided 697 is the ESI of the first repair symbol in the packet. The field 698 type is unsigned integer. 700 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Initial Sequence Number | Source Block Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Encoding Symbol ID | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 7: Repair FEC Payload ID - Format B 710 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 711 the lowest 16 bits of the sequence number of the first packet to 712 be included in this sub-block. If the sequence numbers are 713 shorter than 16 bits then the received Sequence Number SHALL be 714 logically padded with zero bits to become 16 bits in length 715 respectively. The field type is unsigned integer. 717 Source Block Length (SBL) - 16 bits This field specifies the length 718 of the source block in symbols. The field type is unsigned 719 integer. 721 Encoding Symbol ID (ESI) - 24 bits This field indicates which repair 722 symbols are contained within this repair packet. The ESI provided 723 is the ESI of the first repair symbol in the packet. The field 724 type is unsigned integer. 726 8.2. Procedures 728 8.2.1. Source symbol construction 730 FEC Scheme XXX5 and FEC Scheme XXX6 use the procedures defined in 731 Section 5 to construct a set of source symbols to which the FEC code 732 can be applied. 734 During the construction of the source block: 736 o the length indication, l[i], included in the Source Packet 737 Information for each packet shall be dependent on the protocol 738 carried within the transport payload. Rules for RTP are specified 739 below. 741 o the value of s[i] in the construction of the Source Packet 742 Information for each packet shall be the smallest integer such 743 that s[i]*T >= (l[i]+3) 745 8.2.2. Derivation of Source FEC Packet Identification Information 747 The Source FEC Packet Identification Information for a source packet 748 is derived from the sequence number of the packet and information 749 received in any repair FEC packet belonging to this Source Block. 750 Source blocks are identified by the sequence number of the first 751 source packet in the block. This information is signaled in all 752 repair FEC packets associated with the source block in the Initial 753 Sequence Number field. 755 The length of the Source Packet Information (in octets) for source 756 packets within a source block is equal to length of the payload 757 containing encoding symbols of the repair packets (i.e. not including 758 the Repair FEC Payload ID) for that block, which MUST be the same for 759 all repair packets. The Application Data Unit Information Length 760 (ADUIL) in symbols is equal to this length divided by the Encoding 761 Symbol Size (which is signaled in the FEC Framework Configuration 762 Information). The set of source packets which are included in the 763 source block is determined from the Initial Sequence Number (ISN) and 764 Source Block Length (SBL) as follows: 766 Let, 767 o I be the Initial Sequence Number of the source block 769 o LP be the Source Packet Information Length in symbols 771 o LB be the Source Block Length in symbols 773 Then, source packets with sequence numbers from I to I +(LB/LP)-1 774 inclusive are included in the source block. The Source Block Length 775 LB MUST be chosen such that it is at least as large as the largest 776 Source Packet Information Length LP. 778 Note that if no FEC repair packets are received then no FEC decoding 779 is possible and it is unnecessary for the receiver to identify the 780 Source FEC Packet Identification Information for the source packets. 782 The Encoding Symbol ID for a packet is derived from the following 783 information: 785 o The sequence number, Ns, of the packet 787 o The Source Packet Information Length for the source block, LP 789 o The Initial Sequence Number of the source block, I 791 Then the Encoding Symbol ID for packet with sequence number Ns is 792 determined by the following formula: 794 ESI = ( Ns - I ) * LP 796 Note that all repair packet associated to a given Source Block MUST 797 contain the same Source Block Length and Initial Sequence Number. 799 Note also that the source packet flow processed by the FEC encoder 800 MUST have consecutive sequence numbers. In case the incoming source 801 packet flow has a gap in the sequence numbers then implementors 802 SHOULD insert an ADU in the source block that complies to the format 803 of the source packet flow, but is ignored at the application with 804 high probability. For additional guidelines refer to [RFC6363], 805 Section 10.2, paragraph 5. 807 8.2.3. Repair packet construction 809 See Section 7.3.2 811 8.2.4. Procedures for RTP source flows 813 In the specific case of RTP source packet flows, then the RTP 814 Sequence Number field SHALL be used as the sequence number in the 815 procedures described above. The length indication included in the 816 Application Data Unit Information SHALL be the RTP payload length 817 plus the length of the CSRCs, if any, the RTP Header Extension, if 818 present, and the RTP padding octets, if any. Note that this length 819 is always equal to the UDP payload length of the packet minus 12. 821 8.3. FEC Code Specification 823 The same as specified for FEC Scheme XXX3 for FEC Scheme XXX5, and 824 the same as specified for FEC Scheme XXX4 for FEC Scheme XXX6, as 825 specified in Section 7.4. 827 9. Security Considerations 829 For the general security considerations related to the use of FEC, 830 refer to [RFC6363]. Also consider relevant security considerations 831 in [RFC5053] and [RFC6330]. No security vulnerabilities specific to 832 this document have been identified. 834 10. Session Description Protocol (SDP) Signaling 836 This section provides an SDP [RFC4566] example. The syntax follows 837 the definition in [RFC6364] .Assume we have one source video stream 838 (mid:S1) and one FEC repair stream (mid:R1). We form one FEC group 839 with the "a=group:FEC-FR S1 R1" line. The source and repair streams 840 are sent to the same port on different multicast groups. The repair 841 window is set to 200 ms. 843 v=0 844 o=ali 1122334455 1122334466 IN IP4 fec.example.com 845 s=Raptor FEC Example 846 t=0 0 847 a=group:FEC-FR S1 R1 848 m=video 30000 RTP/AVP 100 849 c=IN IP4 233.252.0.1/127 850 a=rtpmap:100 MP2T/90000 851 a=fec-source-flow: id=0 852 a=mid:S1 853 m=application 30000 UDP/FEC 854 c=IN IP4 233.252.0.2/127 855 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A 856 a=repair-window:200ms 857 a=mid:R1 859 11. Congestion Control Considerations 861 For the general congestion control considerations related to the use 862 of FEC, refer to [RFC6363]. 864 12. IANA Considerations 866 12.1. Registration of FEC Scheme IDs 868 The value of FEC Scheme IDs is subject to IANA registration. For 869 general guidelines on IANA considerations as they apply to this 870 document, refer to [RFC6363]. 872 This document registers six values in the FEC Framework (FECFRAME) 873 FEC Encoding IDs registry (http://www.iana.org/assignments/ 874 rmt-fec-parameters/rmt-fec-parameters.xml#fecframe-fec-encoding-ids) 875 as provided in Table 1. Each value refers to a fully-specified FEC 876 scheme. 878 NOTE: To the RFC Editor: please change these XXX notations once 879 assigned, and remove this NOTE. 881 +----------+---------------------+----------------------------------+ 882 | FEC | FEC Scheme | Reference | 883 | Encoding | Description | | 884 | ID | | | 885 +----------+---------------------+----------------------------------+ 886 | XXX1 | Raptor FEC Scheme | Section 6 in this document using | 887 | | for Arbitrary | [RFC5053] | 888 | | Packet Flows | | 889 +----------+---------------------+----------------------------------+ 890 | XXX2 | RaptorQ FEC Scheme | Section 6 in this document using | 891 | | for Arbitrary | [RFC6330]. | 892 | | Packet Flows | | 893 +----------+---------------------+----------------------------------+ 894 | XXX3 | Raptor FEC Scheme | Section 7 in this document using | 895 | | Optimised for | Raptor [RFC5053]. | 896 | | Arbitrary Packet | | 897 | | Flows | | 898 +----------+---------------------+----------------------------------+ 899 | XXX4 | RaptorQ FEC Scheme | XXX4 for the Optimised RaptorQ | 900 | | Optimised for | FEC Scheme for Arbitrary Packet | 901 | | Arbitrary Packet | Flows (Section 7) using RaptorQ | 902 | | Flows | [RFC6330]. | 903 +----------+---------------------+----------------------------------+ 904 +----------+---------------------+----------------------------------+ 905 | XXX5 | Raptor FEC Scheme | XXX5 for the Raptor FEC Scheme | 906 | | for a single | for a single sequence flow | 907 | | sequence flow | (Section 8) using Raptor | 908 | | | [RFC5053]. | 909 +----------+---------------------+----------------------------------+ 910 | XXX6 | RaptorQ FEC Scheme | XXX6 for the RaptorQ FEC Scheme | 911 | | for a single | for a single sequence flow | 912 | | sequence flow | (Section 8) using RaptorQ | 913 | | | [RFC6330]. | 914 +----------+---------------------+----------------------------------+ 916 Table 1: FEC Framework (FECFRAME) FEC Encoding IDs 918 13. Acknowledgements 920 Thanks are due to Ali C. Begen and David Harrington for thorough 921 review of earlier draft versions of this document. 923 14. References 925 14.1. Normative References 927 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 928 Correction (FEC) Framework", RFC 6363, October 2011. 930 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 931 "Raptor Forward Error Correction Scheme for Object 932 Delivery", RFC 5053, October 2007. 934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 935 Requirement Levels", BCP 14, RFC 2119, March 1997. 937 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 938 and L. Minder, "RaptorQ Forward Error Correction Scheme 939 for Object Delivery", RFC 6330, August 2011. 941 14.2. Informative References 943 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 944 Correction (FEC) Building Block", RFC 5052, August 2007. 946 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 947 Description Protocol", RFC 4566, July 2006. 949 [RFC6364] Begen, A., "Session Description Protocol Elements for the 950 Forward Error Correction (FEC) Framework", RFC 6364, 951 October 2011. 953 [dvbts] "ETSI TS 102 034 - Digital Video Broadcasting (DVB); 954 Transport of MPEG-2 Based DVB Services over IP Based 955 Networks", March 2005. 957 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 958 Protocols and codecs", 3GPP TS 26.346, April 2005. 960 Authors' Addresses 962 Mark Watson 963 Netflix 964 100 Winchester Circle 965 Los Gatos, CA 95032 966 U.S.A. 968 Email: watsonm@netflix.com 970 Thomas Stockhammer 971 Nomor Research 972 Brecherspitzstrasse 8 973 Munich 81541 974 Germany 976 Email: stockhammer@nomor.de 978 Michael Luby 979 Qualcomm Incorporated 980 3165 Kifer Road 981 Santa Clara, CA 95051 982 U.S.A. 984 Email: luby@qualcomm.com