idnits 2.17.1 draft-ietf-fecframe-raptor-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2010) is 5165 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) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-06 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-04 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-rfc4756bis-06 == Outdated reference: A later version (-06) exists of draft-ietf-rmt-bb-fec-raptorq-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'MBMSTS' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework M. Watson 3 Internet-Draft Qualcomm, Inc. 4 Intended status: Standards Track March 5, 2010 5 Expires: September 6, 2010 7 Raptor FEC Schemes for FECFRAME 8 draft-ietf-fecframe-raptor-02 10 Abstract 12 This document describes Fully-Specified Forward Error Correction 13 (FEC) Schemes for the Raptor and RaptorQ codes and their application 14 to reliable delivery of media streams in the context of FEC 15 Framework. The Raptor and RaptorQ codes are systematic codes, where 16 a number of repair symbols are generated from a set of source symbols 17 and sent in one or more repair flows in addition to the source 18 symbols that are sent to the receiver(s) within a source flow. The 19 Raptor and RaptorQ codes offer close to optimal protection against 20 arbitrary packet losses at a low computational complexity. Six FEC 21 Schemes are defined, two for protection of arbitrary packet flows, 22 two that are optimised for small source blocks and another two for 23 protection of a single flow that already contains a sequence number. 24 Repair data may be sent over arbitrary datagram transport (e.g. UDP) 25 or using RTP. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 6, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Document Outline . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 70 4. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 71 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 73 5. General procedures for Raptor FEC Schemes . . . . . . . . . . 7 74 6. Raptor FEC Schemes for arbitrary packet flows . . . . . . . . 8 75 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 8 77 6.2.1. FEC Framework Configuration Information . . . . . . . 8 78 6.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 9 79 6.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 10 80 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.3.1. Source symbol construction . . . . . . . . . . . . . . 11 82 6.3.2. Repair packet construction . . . . . . . . . . . . . . 11 83 6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 12 84 7. Optimised Raptor FEC Scheme for arbitrary packet flows . . . . 12 85 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 13 87 7.2.1. FEC Framework Configuration Information . . . . . . . 13 88 7.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 13 89 7.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 90 7.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 13 91 7.3.1. Source symbol construction . . . . . . . . . . . . . . 13 92 7.3.2. Repair packet construction . . . . . . . . . . . . . . 13 93 7.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 14 94 8. Raptor FEC Scheme for a single sequenced flow . . . . . . . . 14 95 8.1. Formats and codes . . . . . . . . . . . . . . . . . . . . 14 96 8.1.1. FEC Framework Configuration Information . . . . . . . 14 97 8.1.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 15 98 8.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 15 99 8.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16 100 8.2.1. Source symbol construction . . . . . . . . . . . . . . 16 101 8.2.2. Derivation of Source FEC Packet Identification 102 Information . . . . . . . . . . . . . . . . . . . . . 16 103 8.2.3. Repair packet construction . . . . . . . . . . . . . . 17 104 8.2.4. Procedures for RTP source flows . . . . . . . . . . . 18 105 8.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 18 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 107 10. Session Description Protocol (SDP) Signaling . . . . . . . . . 18 108 11. Congestion Control Considerations . . . . . . . . . . . . . . 19 109 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 110 12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 19 111 13. Normative References . . . . . . . . . . . . . . . . . . . . . 20 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 114 1. Introduction 116 The FEC Framework [I-D.ietf-fecframe-framework] describes a framework 117 for the application of Forward Error Correction to arbitrary packet 118 flows. Modelled after the FEC Building Block developed by the IETF 119 Reliable Multicast Transport working group [RFC5052], the FEC 120 Framework defines the concept of FEC Schemes which provide specific 121 Forward Error Correction schemes. This document describes six FEC 122 Schemes which make use of the Raptor and RaptorQ FEC codes as defined 123 in [RFC5053] and [I-D.ietf-rmt-bb-fec-raptorq]. 125 The FEC protection mechanism is independent of the type of the source 126 data, which can be an arbitrary sequence of packets, including for 127 example audio or video data. In general, the operation of the 128 protection mechanism is as follows: 130 o The sender determines a set of source packets (a source block) to 131 be protected together based on the FEC Framework Configuration 132 Information. 134 o The sender arranges the source packets into a set of source 135 symbols, each of which is the same size. 137 o The sender applies the Raptor protection operation on the source 138 symbols to generate the required number of repair symbols. 140 o The sender packetizes the repair symbols and sends the repair 141 packet(s) along with the source packets to the receiver(s). 143 Per the FEC Framework requirements, the sender MUST transmit the 144 source and repair packets in different source and repair flows, or in 145 the case RTP transport is used for Repair packets, in different RTP 146 streams. At the receiver side, if all of the source packets are 147 successfully received, there is no need for FEC recovery and the 148 repair packets are discarded. However, if there are missing source 149 packets, the repair packets can be used to recover the missing 150 information. 152 The operation of the FEC mechanism requires that the receiver can 153 identify the relationships between received source packets and repair 154 packets and in particular which source packets are missing. In many 155 cases, data already exists in the source packets which can be used to 156 refer to source packets and to identify which packets are missing. 157 In this case we assume it is possible to derive a "sequence number" 158 directly or indirectly from the source packets and this sequence 159 number can be used within the FEC Scheme. This case is referred to 160 as a "single sequenced flow". In this case the FEC Source Payload ID 161 defined in [I-D.ietf-fecframe-framework] is empty and the source 162 packets are not modified by the application of FEC, with obvious 163 backwards compatibility advantages. 165 Otherwise, it is necessary to add data to the source packets for FEC 166 purposes in the form of a non-empty FEC Source Payload ID. This case 167 if referred to as the "arbitrary packet flow" case. Accordingly, 168 this document defines two FEC Schemes, one for the case of a single 169 sequenced flow and another for the case of arbitrary packet flows. 171 2. Document Outline 173 This document is organised as follows: 175 Section 5 defines general procedures applicable to the use of the 176 Raptor and RaptorQ codes in the context of the FEC Framework. 178 Section 6defines an FEC Scheme for the case of arbitrary source 179 flows and follows the format defined for FEC Schemes in 180 [I-D.ietf-fecframe-framework]. When used with Raptor codes, this 181 scheme is equivalent to that defined in [MBMSTS]. 183 Section 7 defines an FEC Scheme similar to that defined in 184 Section 6but with optimisations for the case where only limited 185 source block sizes are required. When used with Raptor codes, 186 this scheme is equivalent to that defined in [dvbts] for arbitrary 187 packet flows. 189 Section 8 defines an FEC Scheme for the case of a single flow 190 which is already provided with a source packet sequence number. 191 When used with Raptor codes, this scheme is equivalent to that 192 defined in [dvbts] for the case of a single sequenced flow. 194 3. Requirements Notation 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 4. Definitions and Abbreviations 202 The definitions, notations and abbreviations commonly used in this 203 document are summarized in this section. 205 4.1. Definitions 207 This document uses the following definitions. For further 208 definitions that apply to FEC Framework in general, see 209 [I-D.ietf-fecframe-framework]. 211 Source Flow: The packet flow(s) or stream(s) carrying the source 212 data and to which FEC protection is to be applied. 214 Repair Flow: The packet flow(s) or stream(s) carrying the repair 215 data. 217 Symbol: A unit of data. Its size, in bytes, is referred to as the 218 symbol size. 220 Source Symbol: The smallest unit of data used during the encoding 221 process. 223 Repair Symbol: Repair symbols are generated from the source symbols. 225 Source Packet: Data packets that contain only source symbols. 227 Repair Packet: Data packets that contain only repair symbols. 229 Source Block: A block of source symbols that are considered together 230 in the encoding process. 232 FEC Framework Configuration Information: Information that controls 233 the operation of the FEC Framework. Each FEC Framework instance has 234 its own configuration information. 236 FEC Payload ID: Information that identifies the contents of a packet 237 with respect to the FEC scheme. 239 Source FEC Payload ID: An FEC Payload ID specifically used with 240 source packets. 242 Repair FEC Payload ID: An FEC Payload ID specifically used with 243 repair packets. 245 4.2. Abbreviations 247 o FSSI: FEC-Scheme-Specific Information. 249 o SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 251 o RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 253 5. General procedures for Raptor FEC Schemes 255 This section specifies general procedures which apply to all Raptor 256 and RaptorQ FEC Schemes, specifically the construction of source 257 symbols from a set of source transport payloads. As described in 258 [I-D.ietf-fecframe-framework] for each Application Data Unit in a 259 source block, the FEC Scheme is provided with: 261 o A description of the source data flow with which the Application 262 Data Unit is associated and an integer identifier associated with 263 that flow. 265 o The Application Data Unit itself. 267 o The length of the Application Data Unit. 269 For each Application Data Unit, we define the Application Data Unit 270 Information (ADUI) as follows: 272 Let 274 n be the number of Application Data Units in the source block. 276 T be the source symbol size in bytes. Note: this information is 277 provided by the FEC Scheme as defined below. 279 i the index to the (i+1)-th Application Data Unit to be added to 280 the source block, 0 <= i < n. 282 R[i] denote the number of octets in the (i+1)-th Application Data 283 Unit. 285 l[i] be a length indication associated with the i-th Application 286 Data Unit - the nature of the length indication is defined by the 287 FEC Scheme. 289 L[i] denote two octets representing the value of l[i] in network 290 byte order (high order octet first) of the i-th Application Data 291 Unit. 293 f[i] denote the integer identifier associated with the source data 294 flow from which the i-th Application Data Unit was taken. 296 F[i] denote a single octet representing the value of f[i]. 298 s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note 299 s[i] is the length of SPI[i] in units of symbols of size T bytes. 301 P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding 302 octets to align the start of each UDP packet with the start of a 303 symbol. 305 ADUI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. 307 Then, a source data block is constructed by concatenating ADUI[i] for 308 i = 0, 1, 2, ... n-1. The source data block size, S, is then given 309 by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer 310 Encoding Symbol IDs consecutively starting from zero within the 311 source block. Each Application Data Unit is associated with the 312 Encoding Symbol ID of the first symbol containing SPI for that 313 packet. Thus, the Encoding Symbol ID value associated with the j-th 314 source packet, ESI[j], is given by ESI[j] = 0, for j=0 and ESI[j] = 315 sum{s[i], i=0,...,(j-1)}, for 0 < j < n. 317 Source blocks are identified by integer Source Block Numbers. This 318 specification does not specify how Source Block Numbers are allocated 319 to source blocks. The Source FEC Packet Identification Information 320 consists of the identity of the source block and the Encoding Symbol 321 ID associated with the packet. 323 6. Raptor FEC Schemes for arbitrary packet flows 325 6.1. Introduction 327 This section specifies an FEC Scheme for the application of the 328 Raptor and RaptorQ codes to arbitary packet flows. This scheme is 329 recommended in scenarios where maximal generality is required. 331 When used with Raptor codes, this scheme is equivalent to that 332 specified in [MBMSTS]. 334 6.2. Formats and Codes 336 6.2.1. FEC Framework Configuration Information 338 6.2.1.1. FEC Scheme ID 340 The value of the FEC Scheme ID for the fully-specified FEC scheme 341 defined in this section is XXX when [RFC5053] is used and YYY when 342 [I-D.ietf-rmt-bb-fec-raptorq] is used, as assigned by IANA. 344 6.2.1.2. Scheme-Specific Elements 346 The scheme-specific elements of the FEC Framework Configuration 347 information for this scheme are as follows: 349 Maximum Source Block Length Name: "Kmax", Value range: A decimal 350 non-negative integer less than 8192 (for Raptor) or 56405 (for 351 RaptorQ), in units of symbols 353 Encoding Symbol Size Name: "T", Value range: A decimal non- 354 negative integer less than 65536, in units of bytes 356 Payload ID Format Name: "P", Value range: "A" or "B" 358 An encoding format for The Maximum Source Block Length and Encoding 359 Symbol Size is defined below. 361 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Symbol Size (T) |Max. Source Block Length (Kmax)| 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |P| Reserved | 367 +-+-+-+-+-+-+-+-+ 369 Figure 1: FEC Scheme Specific Information 371 The P bit shall be set to zero to indicate Format A or to 1 to 372 indicate Format B. The last octet of the above encoding may be 373 omitted, in which case Format A shall be assumed. 375 The Payload ID Format identifier defines which of the Source FEC 376 Payload ID and Repair FEC Payload ID formats defined below shall be 377 used. Payload ID Format B SHALL NOT be used when[RFC5053] is used. 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 signalled as part of the FEC Framework Configuration 385 Information 386 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 2: Source FEC Payload ID - Format A 394 Source Block Number (SBN), (16 bits): An integer identifier for the 395 source block that the source data within the packet relates to. 397 Encoding Symbol ID (ESI), (16 bits): The starting symbol index of 398 the source packet in the source block. 400 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | SBN | Encoding Symbol ID (ESI) | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 3: Source FEC Payload ID - Format B 408 Source Block Number (SBN), (8 bits): An integer identifier for the 409 source block that the source data within the packet relates to. 411 Encoding Symbol ID (ESI), (24 bits): The starting symbol index of 412 the source packet in the source block 414 6.2.3. Repair FEC Payload ID 416 Two formats for the Repair FEC Payload ID, Format A and Format B are 417 defined below: 419 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Source Block Length (SBL) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Repair FEC Payload ID - Format A 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 | SBN | Encoding Symbol ID (ESI) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Source Block Length (SBL) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Repair FEC Payload ID - Format B 438 Source Block Number (SBN), (16 bits) An integer identifier for the 439 source block that the repair symbols within the packet relate to. 441 Encoding Symbol ID (ESI), (16 bits) Integer identifier for the 442 encoding symbols within the packet. 444 Source Block Length (SBL), (16 bits) The number of source symbols in 445 the source block. 447 The interpretation of the Source Block Number, Encoding Symbol 448 Identifier and Source Block Length is defined by the FEC Code 449 Specification. 451 6.3. Procedures 453 6.3.1. Source symbol construction 455 This FEC Scheme uses the procedures defined in Section 5 to construct 456 a set of source symbols to which the FEC code can be applied. The 457 sender MUST allocate Source Block Numbers to source blocks 458 sequentially, wrapping around to zero after Source Block Number 65535 459 (Format A) or 255 (Format B). 461 During the construction of the source block: 463 o the length indication, l[i], included in the Source Packet 464 Information for each packet shall be the transport payload length. 466 o the value of s[i] in the construction of the Source Packet 467 Information for each packet shall be the smallest integer such 468 that s[i]*T >= (l[i]+3). 470 6.3.2. Repair packet construction 472 The number of repair symbols contained within a repair packet is 473 computed from the packet length. The ESI value placed into a repair 474 packet is given by the following formula: 476 ESI_repair = I_repair + SBL, 478 where I_repair is the index of the repair symbol in the sequence of 479 repair symbols generated according to Section 6.4, where the first 480 repair symbol has index 0, the second index 1 etc. and SBL is the 481 Source Block Length. The Source Block Length field of the Repair FEC 482 Payload ID field SHALL be set to the number of symbols included in 483 the Source Packet Information of packets associated with the source 484 block. 486 6.4. FEC Code Specification 488 The Raptor FEC encoder defined in [RFC5053] or 489 [I-D.ietf-rmt-bb-fec-raptorq] SHALL be used. The source symbols 490 passed to the Raptor FEC encoder SHALL consist of the source symbols 491 constructed according to Section 6.3.1. Thus the value of the 492 parameter K used by the FEC encoder (equal to the Source Block 493 Length) may vary amongst the blocks of the stream but SHALL NOT 494 exceed the Maximum Source Block Length signalled in the FEC Scheme- 495 specific information. The symbol size, T, to be used for source 496 block construction and the repair symbol construction is equal to the 497 Encoding Symbol Size signaled in the FEC Scheme Specific Information. 499 7. Optimised Raptor FEC Scheme for arbitrary packet flows 501 7.1. Introduction 503 This section specifies a slightly modified version of the FEC Scheme 504 specified in Section 6 which is applicable to scenarios in which only 505 relatively small block sizes will be used. These modifications admit 506 substantial optimisations to both sender and receiver 507 implementations. 509 In outline, the modifications are: 511 All source blocks within a stream are encoded using the same 512 source block size. Code shortening is used to encode blocks of 513 different sizes. This is achieved by padding every block to the 514 required size using zero symbols before encoding. The zero 515 symbols are then discarded after decoding. The source block size 516 to be used for a stream is signalled in the Maximum Source Block 517 Size field of the scheme-specific information. This allows for 518 efficient parallel encoding of multiple streams. 520 A restricted set of possible source block sizes is specified. 521 This allows explicit operation sequences for encoding the 522 restricted set of block sizes to be pre-calculated and embedded in 523 software or handware. 525 This scheme is equivalent to that specified in [dvbts] for arbitrary 526 packet flows. 528 7.2. Formats and Codes 530 7.2.1. FEC Framework Configuration Information 532 7.2.1.1. FEC Scheme ID 534 The value of the FEC Scheme ID for the fully-specified FEC scheme 535 defined in this section is XXX when [RFC5053] is used and YYY when 536 [I-D.ietf-rmt-bb-fec-raptorq] is used, as assigned by IANA. 538 7.2.1.2. FEC Scheme specific information 540 See . (Section 6.2.1.2) 542 7.2.2. Source FEC Payload ID 544 See . (Section 6.2.2) 546 7.2.3. Repair FEC Payload ID 548 SeeSection 6.2.3 550 7.3. Procedures 552 7.3.1. Source symbol construction 554 See Section 6.3.1 556 7.3.2. Repair packet construction 558 The number of repair symbols contained within a repair packet is 559 computed from the packet length. The ESI value placed into a repair 560 packet is given by the following formula: 562 ESI_repair = I_repair + MSBL 564 Where I_repair is the index of the repair symbol in the sequence of 565 repair symbols generated according to Section 6.4, where the first 566 repair symbol has index 0, the second index 1 etc. and MSBL is the 567 Maximum Source Block Length signalled in the FEC Scheme Specific 568 Information. The Source Block Length field of the Repair FEC Payload 569 ID field SHALL be set to the number of symbols included in the Source 570 Packet Information of packets associated with the source block. 572 7.4. FEC Code Specification 574 The Raptor FEC encoder defined in [RFC5053] or 575 [I-D.ietf-rmt-bb-fec-raptorq] SHALL be used. The source symbols 576 passed to the Raptor FEC encoder SHALL consist of the source symbols 577 constructed according to Section 6.3.1 extended with zero or more 578 padding symbols such that the total number of symbols in the source 579 block is equal to the Maximum Source Block Length signaled in the FEC 580 Scheme Specific Information. Thus the value of the parameter K used 581 by the FEC encoded is equal to the Maximum Source Block Length for 582 all blocks of the stream. Padding symbols shall consist entirely of 583 bytes set to the value zero. The symbol size, T, to be used for 584 source block construction and the repair symbol construction is equal 585 to the Encoding Symbol Size signaled in the FEC Scheme Specific 586 Information. 588 When [RFC5053] is used, the parameter T SHALL be set such that the 589 number of source symbols in any source block is at most 8192. The 590 Maximum Source Block Length parameter - and hence the number of 591 symbols used in the FEC Encoding and Decoding operations - SHALL be 592 set to one of the following values: 594 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 595 1139, 1281 597 When [I-D.ietf-rmt-bb-fec-raptorq] is used, the parameter T SHALL be 598 set such that the number of source symbols in any source block is 599 less than 56404. The Maximum Source Block Length parameter SHALL be 600 set to one of the supported vaoues for K' defined in Section 5.6 of 601 [I-D.ietf-rmt-bb-fec-raptorq]. 603 8. Raptor FEC Scheme for a single sequenced flow 605 8.1. Formats and codes 607 8.1.1. FEC Framework Configuration Information 609 8.1.1.1. FEC Scheme ID 611 The value of the FEC Scheme ID for the fully-specified FEC scheme 612 defined in this section is XXX when [RFC5053] is used and YYY when 613 [I-D.ietf-rmt-bb-fec-raptorq] is used, as assigned by IANA. 615 8.1.1.2. Scheme-specific elements 617 See Section 6.2.1.2 619 8.1.2. Source FEC Payload ID 621 The Source FEC Payload ID field is not used by this FEC Scheme. 622 Source packets are not modified by this FEC Scheme. 624 8.1.3. Repair FEC Payload ID 626 Two formats for the Repair FEC Payload ID are defined, Format A and 627 Format B. 629 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Initial Sequence Number | Encoding Symbol ID | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Source Block Length | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Figure 4: Repair FEC Payload ID - Format A 639 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 640 the lowest 16 bits of the sequence number of the first packet to 641 be included in this sub-block. If the sequence numbers are 642 shorter than 16 bits then the received Sequence Number SHALL be 643 logically padded with zero bits to become 16 bits in length 644 respectively. 646 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 647 symbols are contained within this repair packet. The ESI provided 648 is the ESI of the first repair symbol in the packet. 650 Source Block Length (SBL) - 16 bits This field specifies the length 651 of the source block in symbols. 653 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Initial Sequence Number | Source Block Length | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Encoding Symbol ID | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Figure 5: Repair FEC Payload ID - Format B 663 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 664 the lowest 16 bits of the sequence number of the first packet to 665 be included in this sub-block. If the sequence numbers are 666 shorter than 16 bits then the received Sequence Number SHALL be 667 logically padded with zero bits to become 16 bits in length 668 respectively. 670 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 671 symbols are contained within this repair packet. The ESI provided 672 is the ESI of the first repair symbol in the packet. 674 Source Block Length (SBL) - 16 bits This field specifies the length 675 of the source block in symbols. 677 8.2. Procedures 679 8.2.1. Source symbol construction 681 This FEC Scheme uses the procedures defined in Section 5 to construct 682 a set of source symbols to which the FEC code can be applied. The 683 sender MUST allocate Source Block Numbers to source blocks 684 sequentially, wrapping around to zero after Source Block Number 65535 685 in the case Format A is used for FEC Payload IDs and 255 in the case 686 Format B is used for FEC Payload IDs. 688 During the construction of the source block: 690 o the length indication, l[i], included in the Source Packet 691 Information for each packet shall be dependent on the protocol 692 carried within the transport payload. Rules for RTP are specified 693 below. 695 o the value of s[i] in the construction of the Source Packet 696 Information for each packet shall be the smallest integer such 697 that s[i]*T >= (l[i]+3) 699 8.2.2. Derivation of Source FEC Packet Identification Information 701 The Source FEC Packet Identification Information for a source packet 702 is derived from the sequence number of the packet and information 703 received in any Repair FEC packet belonging to this Source Block. 704 Source blocks are identified by the sequence number of the first 705 source packet in the block. This information is signaled in all 706 Repair FEC packets associated with the source block in the Initial 707 Sequence Number field. 709 The length of the Source Packet Information (in bytes) for source 710 packets within a source block is equal to length of the payload 711 containing encoding symbols of the repair packets (i.e. not including 712 the Repair FEC Payload ID) for that block, which MUST be the same for 713 all repair packets. The Application Data Unit Information Length 714 (ADUIL) in symbols is equal to this length divided by the Encoding 715 Symbol Size (which is signaled in the FEC Framework Configuration 716 Information). The set of source packets which are included in the 717 source block is determined from the Initial Sequence Number (ISN) and 718 Source Block Length (SBL) as follows: 720 Let, 722 I be the Initial Sequence Number of the source block 724 LP be the Source Packet Information Length in symbols 726 LB be the Source Block Length in symbols 728 Then, source packets with sequence numbers from I to I +LB/LP-1 729 inclusive are included in the source block. 731 Note that if no FEC Repair packets are received then no FEC decoding 732 is possible and it is unnecessary for the receiver to identify the 733 Source FEC Packet Identification Information for the source packets. 735 The Encoding Symbol ID for a packet is derived from the following 736 information: 738 The sequence number, Ns, of the packet 740 The Source Packet Information Length for the source block, LP 742 The Initial Sequence Number of the source block, I 744 Then the Encoding Symbol ID for packet with sequence number Ns is 745 determined by the following formula: 747 ESI = ( Ns - I ) * LP 749 Note that all repair packet associated to a given Source Block MUST 750 contain the same Source Block Length and Initial Sequence Number. 752 8.2.3. Repair packet construction 754 See Section 7.3.2 756 8.2.4. Procedures for RTP source flows 758 In the specific case of RTP source packet flows, then the RTP 759 Sequence Number field SHALL be used as the sequence number in the 760 procedures described above. The length indication included in the 761 Application Data Unit Information SHALL be the RTP payload length 762 plus the length of the CSRCs, if any, the RTP Header Extension, if 763 present, and the RTP padding bytes, if any. Note that this length is 764 always equal to the UDP payload length of the packet minus 12. 766 8.3. FEC Code Specification 768 See Section 7.4 770 9. Security Considerations 772 For the general security considerations related to the use of FEC, 773 refer to [I-D.ietf-fecframe-framework]. No security considerations 774 specific to this document have been identified. 776 10. Session Description Protocol (SDP) Signaling 778 This section provides an SDP [RFC4566] example. The following 779 example uses the SDP elements for FEC Framework, which were 780 introduced in [I-D.ietf-fecframe-sdp-elements], and the FEC grouping 781 semantics [I-D.ietf-mmusic-rfc4756bis]. 783 In this example, we have one source video stream (mid:S1) and one FEC 784 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 785 S1 R1" line. The source and repair streams are sent to the same port 786 on different multicast groups. The repair window is set to 200 ms. 788 v=0 789 o=ali 1122334455 1122334466 IN IP4 fec.example.com 790 s=Raptor FEC Example 791 t=0 0 792 a=group:FEC S1 R1 793 m=video 30000 RTP/AVP 100 794 c=IN IP4 233.252.0.1/127 795 a=rtpmap:100 MP2T/90000 796 a=fec-source-flow: id=0; tag-len=4 797 a=mid:S1 798 m=application 30000 udp/fec 799 c=IN IP4 233.252.0.2/127 800 a=fec-repair-flow: encoding-id=0; fssi=Kmax:8192,T:128,P:A 801 a=repair-window:200 802 a=mid:R1 804 11. Congestion Control Considerations 806 For the general congestion control considerations related to the use 807 of FEC, refer to [I-D.ietf-fecframe-framework]. 809 12. IANA Considerations 811 12.1. Registration of FEC Scheme IDs 813 The value of FEC Scheme IDs is subject to IANA registration. For 814 general guidelines on IANA considerations as they apply to this 815 document, refer to [I-D.ietf-fecframe-framework]. 817 This document registers three values in the FEC Framework (FECFRAME) 818 FEC Encoding IDs registry as follows: 820 o XXX for the Raptor FEC Scheme for Arbitrary Packet Flows 821 (Section 6 using Raptor [RFC5053]. 823 o XXX for the Raptor FEC Scheme for Arbitrary Packet Flows 824 (Section 6 using RaptorQ [I-D.ietf-rmt-bb-fec-raptorq]. 826 o XXX for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows 827 (Section 7) using Raptor [RFC5053]. 829 o XXX for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows 830 (Section 7) using RaptorQ [I-D.ietf-rmt-bb-fec-raptorq]. 832 o XXX for the Raptor FEC Scheme for a single sequence flow 833 (Section 8) using Raptor [RFC5053]. 835 o XXX for the Raptor FEC Scheme for a single sequence flow 836 (Section 8) using RaptorQ [I-D.ietf-rmt-bb-fec-raptorq]. 838 13. Normative References 840 [I-D.ietf-fecframe-framework] 841 Watson, M., "Forward Error Correction (FEC) Framework", 842 draft-ietf-fecframe-framework-06 (work in progress), 843 March 2010. 845 [I-D.ietf-fecframe-sdp-elements] 846 Begen, A., "SDP Elements for FEC Framework", 847 draft-ietf-fecframe-sdp-elements-04 (work in progress), 848 August 2009. 850 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 851 Correction (FEC) Building Block", RFC 5052, August 2007. 853 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 854 "Raptor Forward Error Correction Scheme for Object 855 Delivery", RFC 5053, October 2007. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 861 Description Protocol", RFC 4566, July 2006. 863 [I-D.ietf-mmusic-rfc4756bis] 864 Begen, A., "Forward Error Correction Grouping Semantics in 865 Session Description Protocol", 866 draft-ietf-mmusic-rfc4756bis-06 (work in progress), 867 February 2010. 869 [I-D.ietf-rmt-bb-fec-raptorq] 870 Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 871 "RaptorQ Forward Error Correction Scheme for Object 872 Delivery", draft-ietf-rmt-bb-fec-raptorq-01 (work in 873 progress), February 2010. 875 [dvbts] "ETSI TS 102 034 - Digital Video Broadcasting (DVB); 876 Transport of MPEG-2 Based DVB Services over IP Based 877 Networks", March 2005. 879 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 880 Protocols and codecs", 3GPP TS 26.346, April 2005. 882 Author's Address 884 Mark Watson 885 Qualcomm, Inc. 886 3165 Kifer Road 887 Santa Clara, CA 95051 888 U.S.A. 890 Email: watson@qualcomm.com