idnits 2.17.1 draft-ietf-fecframe-raptor-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (July 8, 2009) is 5404 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-03 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-03 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 July 8, 2009 5 Expires: January 9, 2010 7 Raptor FEC Schemes for FECFRAME 8 draft-ietf-fecframe-raptor-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 9, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes Fully-Specified Forward Error Correction 47 (FEC) Schemes for the Raptor code and its application to reliable 48 delivery of media streams in the context of FEC Framework. The 49 Raptor code is a systematic code, where a number of repair symbols 50 are generated from a set of source symbols and sent in one or more 51 repair flows in addition to the source symbols that are sent to the 52 receiver(s) within a source flow. The Raptor code offers a close to 53 optimal protection against arbitrary packet losses at a low 54 computational complexity. Two FEC Schemes are defined, one for 55 protection of arbitrary packet flows and another for protection of a 56 single flow that already contains a sequence number. Repair data may 57 be sent over arbitrary datagram transport (e.g. UDP) or using RTP. 58 An RTP Payload Type is defined for this latter case. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Document Outline . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 65 4. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 66 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 68 5. General procedures for Raptor FEC Schemes . . . . . . . . . . 6 69 6. Raptor FEC Scheme for arbitrary packet flows . . . . . . . . . 8 70 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 8 72 6.2.1. FEC Framework Configuration Information . . . . . . . 8 73 6.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 9 74 6.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 9 75 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.3.1. Source symbol construction . . . . . . . . . . . . . . 10 77 6.3.2. Repair packet construction . . . . . . . . . . . . . . 10 78 6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 11 79 7. Optimised Raptor FEC Scheme for arbitrary packet flows . . . . 11 80 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12 82 7.2.1. FEC Framework Configuration Information . . . . . . . 12 83 7.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 12 84 7.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 12 85 7.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.3.1. Source symbol construction . . . . . . . . . . . . . . 12 87 7.3.2. Repair packet construction . . . . . . . . . . . . . . 12 88 7.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 13 89 8. Raptor FEC Scheme for a single sequenced flow . . . . . . . . 13 90 8.1. Formats and codes . . . . . . . . . . . . . . . . . . . . 13 91 8.1.1. FEC Framework Configuration Information . . . . . . . 13 92 8.1.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 13 93 8.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 94 8.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14 95 8.2.1. Source symbol construction . . . . . . . . . . . . . . 14 96 8.2.2. Derivation of Source FEC Packet Identification 97 Information . . . . . . . . . . . . . . . . . . . . . 15 98 8.2.3. Repair packet construction . . . . . . . . . . . . . . 16 99 8.2.4. Procedures for RTP source flows . . . . . . . . . . . 16 100 8.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 16 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 102 10. Session Description Protocol (SDP) Signaling . . . . . . . . . 16 103 11. Congestion Control Considerations . . . . . . . . . . . . . . 17 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 105 12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 17 106 13. Normative References . . . . . . . . . . . . . . . . . . . . . 17 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 109 1. Introduction 111 The FEC Framework [I-D.ietf-fecframe-framework] describes a framework 112 for the application of Forward Error Correction to arbitrary packet 113 flows. Modelled after the FEC Building Block developed by the IETF 114 Reliable Multicast Transport working group ([RFC5052]), the FEC 115 Framework defines the concept of FEC Schemes which provide specific 116 Forward Error Correction schemes. This document describes two FEC 117 Schemes which make use of the Raptor FEC code as defined in 118 [RFC5053]. 120 The FEC protection mechanism is independent of the type of the source 121 data, which can be an arbitrary sequence of packets, including for 122 example audio or video data. In general, the operation of the 123 protection mechanism is as follows: 125 o The sender determines a set of source packets (a source block) to 126 be protected together based on the FEC Framework Configuration 127 Information. 129 o The sender arranges the source packets into a set of source 130 symbols, each of which is the same size. 132 o The sender applies the Raptor protection operation on the source 133 symbols to generate the required number of repair symbols. 135 o The sender packetizes the repair symbols and sends the repair 136 packet(s) along with the source packets to the receiver(s). 138 Per the FEC Framework requirements, the sender MUST transmit the 139 source and repair packets in different source and repair flows, 140 respectively. At the receiver side, if all of the source packets are 141 successfully received, there is no need for FEC recovery and the 142 repair packets are discarded. However, if there are missing source 143 packets, the repair packets can be used to recover the missing 144 information. 146 The operation of the FEC mechanism requires that the receiver can 147 identify the relationships between received source packets and repair 148 packets and in particular which source packets are missing. In many 149 cases, data already exists in the source packets which can be used to 150 refer to source packets and to identify which packets are missing. 151 In this case we assume it is possible to derive a "sequence number" 152 directly or indirectly from the source packets and this sequence 153 number can be used within the FEC Scheme. This case is referred to 154 as a "single sequenced flow". In this case the FEC Source Payload ID 155 defined in [I-D.ietf-fecframe-framework] is empty and the source 156 packets are not modified by the application of FEC, with obvious 157 backwards compatibility advantages. 159 Otherwise, it is necessary to add data to the source packets for FEC 160 purposes in the form of a non-empty FEC Source Payload ID. This case 161 if referred to as the "arbitrary packet flow" case. Accordingly, 162 this document defines two FEC Schemes, one for the case of a single 163 sequenced flow and another for the case of arbitrary packet flows. 165 2. Document Outline 167 This document is organised as follows: 169 Section 5 defines general procedures applicable to the use of the 170 Raptor code in the context of the FEC Framework. 172 Section 6defines an FEC Scheme for the case of arbitrary source 173 flows and follows the format defined for FEC Schemes in 174 [I-D.ietf-fecframe-framework]. This scheme is equivalent to that 175 defined in [3GPP MBMS Specification]. 177 Section 7 defines an FEC Scheme similar to that defined in 178 Section 6but with optimisations for the case where only limited 179 source block sizes are required. This scheme is equivalent to 180 that defined in [dvbts] for arbitrary packet flows. 182 Section 8 defines an FEC Scheme for the case of a single flow 183 which is already provided with a source packet sequence number. 184 This scheme is equivalent to that defined in [dvbts] for the case 185 of a single sequenced flow. 187 3. Requirements Notation 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 4. Definitions and Abbreviations 195 The definitions, notations and abbreviations commonly used in this 196 document are summarized in this section. 198 4.1. Definitions 200 This document uses the following definitions. For further 201 definitions that apply to FEC Framework in general, see 203 [I-D.ietf-fecframe-framework]. 205 Source Flow: The packet flow(s) carrying the source data and to 206 which FEC protection is to be applied. 208 Repair Flow: The packet flow(s) carrying the repair data. 210 Symbol: A unit of data. Its size, in bytes, is referred to as the 211 symbol size. 213 Source Symbol: The smallest unit of data used during the encoding 214 process. 216 Repair Symbol: Repair symbols are generated from the source symbols. 218 Source Packet: Data packets that contain only source symbols. 220 Repair Packet: Data packets that contain only repair symbols. 222 Source Block: A block of source symbols that are considered together 223 in the encoding process. 225 FEC Framework Configuration Information: Information that controls 226 the operation of the FEC Framework. Each FEC Framework instance has 227 its own configuration information. 229 FEC Payload ID: Information that identifies the contents of a packet 230 with respect to the FEC scheme. 232 Source FEC Payload ID: An FEC Payload ID specifically used with 233 source packets. 235 Repair FEC Payload ID: An FEC Payload ID specifically used with 236 repair packets. 238 4.2. Abbreviations 240 o FSSI: FEC-Scheme-Specific Information. 242 o SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 244 o RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 246 5. General procedures for Raptor FEC Schemes 248 This section specifies general procedures which apply to all Raptor 249 FEC Schemes, specifically the construction of source symbols from a 250 set of source transport payloads. As described in 251 [I-D.ietf-fecframe-framework] for each Application Data Unit in a 252 source block, the FEC Scheme is provided with: 254 o A description of the source data flow with which the Application 255 Data Unit is associated and an integer identifier associated with 256 that flow. 258 o The Application Data Unit itself. 260 o The length of the Application Data Unit. 262 For each Application Data Unit, we define the Application Data Unit 263 Information (ADUI) as follows: 265 Let 267 n be the number of Application Data Units in the source block. 269 T be the source symbol size in bytes. Note: this information is 270 provided by the FEC Scheme as defined below. 272 i the index to the (i+1)-th Application Data Unit to be added to 273 the source block, 0 <= i < n. 275 R[i] denote the number of octets in the (i+1)-th Application Data 276 Unit. 278 l[i] be a length indication associated with the i-th Application 279 Data Unit - the nature of the length indication is defined by the 280 FEC Scheme. 282 L[i] denote two octets representing the value of l[i] in network 283 byte order (high order octet first) of the i-th Application Data 284 Unit. 286 f[i] denote the integer identifier associated with the source data 287 flow from which the i-th Application Data Unit was taken. 289 F[i] denote a single octet representing the value of f[i]. 291 s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note 292 s[i] is the length of SPI[i] in units of symbols of size T bytes. 294 P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding 295 octets to align the start of each UDP packet with the start of a 296 symbol. 298 ADUI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. 300 Then, a source data block is constructed by concatenating ADUI[i] for 301 i = 0, 1, 2, ... n-1. The source data block size, S, is then given 302 by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer 303 Encoding Symbol IDs consecutively starting from zero within the 304 source block. Each Application Data Unit is associated with the 305 Encoding Symbol ID of the first symbol containing SPI for that 306 packet. Thus, the Encoding Symbol ID value associated with the j-th 307 source packet, ESI[j], is given by ESI[j] = 0, for j=0 and ESI[j] = 308 sum{s[i], i=0,...,(j-1)}, for 0 < j < n. 310 Source blocks are identified by integer Source Block Numbers. This 311 specification does not specify how Source Block Numbers are allocated 312 to source blocks. The Source FEC Packet Identification Information 313 consists of the identity of the source block and the Encoding Symbol 314 ID associated with the packet. 316 6. Raptor FEC Scheme for arbitrary packet flows 318 6.1. Introduction 320 This section specifies an FEC Scheme for the application of the 321 Raptor code to arbitary packet flows. This scheme is recommended in 322 scenarios where maximal generality is required. 324 This scheme is equivalent to that specified in [3GPP MBMS 325 Specification]. 327 6.2. Formats and Codes 329 6.2.1. FEC Framework Configuration Information 331 6.2.1.1. FEC Scheme ID 333 The value of the FEC Scheme ID for the fully-specified FEC scheme 334 defined in this section is XXX, as assigned by IANA. 336 6.2.1.2. Scheme-Specific Elements 338 The scheme-specific elements of the FEC Framework Configuration 339 information for this scheme are as follows: 341 Maximum Source Block Length A non-negative integer less than 2^13, 342 in units of symbols 344 Encoding Symbol Size A non-negative integer less than 2^16, in units 345 of bytes 347 An encoding format for this information in a 4 octet field is defined 348 as follows: 350 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Symbol Size (T) | Max. Source Block Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 1: FEC Scheme Specific Information 358 6.2.2. Source FEC Payload ID 360 This scheme makes use of an Explicit Source FEC Payload ID, which is 361 appended to the end of the source packets. 363 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 2: Source FEC Payload ID 371 Source Block Number (SBN), (16 bits): An integer identifier for the 372 source block that the source data within the packet relates to. 374 Encoding Symbol ID (ESI), (16 bits): The starting symbol index of 375 the source packet in the source block. 377 6.2.3. Repair FEC Payload ID 379 The structure of the Repair FEC Payload ID is defined below: 381 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Source Block Length (SBL) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Repair FEC Payload ID 391 Source Block Number (SBN), (16 bits) An integer identifier for the 392 source block that the repair symbols within the packet relate to. 394 Encoding Symbol ID (ESI), (16 bits) Integer identifier for the 395 encoding symbols within the packet. 397 Source Block Length (SBL), (16 bits) The number of source symbols in 398 the source block. 400 The interpretation of the Source Block Number, Encoding Symbol 401 Identifier and Source Block Length is defined by the FEC Code 402 Specification. 404 6.3. Procedures 406 6.3.1. Source symbol construction 408 This FEC Scheme uses the procedures defined in Section 5 to construct 409 a set of source symbols to which the FEC code can be applied. The 410 sender MUST allocate Source Block Numbers to source blocks 411 sequentially, wrapping around to zero after Source Block Number 412 2^16-1. 414 During the construction of the source block: 416 o the length indication, l[i], included in the Source Packet 417 Information for each packet shall be the transport payload length. 419 o the value of s[i] in the construction of the Source Packet 420 Information for each packet shall be the smallest integer such 421 that s[i]*T >= (l[i]+3). 423 6.3.2. Repair packet construction 425 The number of repair symbols contained within a repair packet is 426 computed from the packet length. The ESI value placed into a repair 427 packet is given by the following formula: 429 ESI_repair = I_repair + SBL, 431 where I_repair is the index of the repair symbol in the sequence of 432 repair symbols generated according to Section 6.4, where the first 433 repair symbol has index 0, the second index 1 etc. and SBL is the 434 Source Block Length. The Source Block Length field of the Repair FEC 435 Payload ID field SHALL be set to the number of symbols included in 436 the Source Packet Information of packets associated with the source 437 block. 439 6.4. FEC Code Specification 441 The Raptor FEC encoder defined in [RFC5053] SHALL be used. The 442 source symbols passed to the Raptor FEC encoder SHALL consist of the 443 source symbols constructed according to Section 6.3.1. Thus the 444 value of the parameter K used by the FEC encoder (equal to the Source 445 Block Length) may vary amongst the blocks of the stream but SHALL NOT 446 exceed the Maximum Source Block Length signalled in the FEC Scheme- 447 specific information. The symbol size, T, to be used for source 448 block construction and the repair symbol construction is equal to the 449 Encoding Symbol Size signaled in the FEC Scheme Specific Information. 451 7. Optimised Raptor FEC Scheme for arbitrary packet flows 453 7.1. Introduction 455 This section specifies a slightly modified version of the FEC Scheme 456 specified in Section 6 which is applicable to scenarios in which only 457 relatively small block sizes will be used. These modifications admit 458 substantial optimisations to both sender and receiver 459 implementations. 461 In outline, the modifications are: 463 All source blocks within a stream are encoded using the same 464 source block size. Code shortening is used to encode blocks of 465 different sizes. This is achieved by padding every block to the 466 required size using zero symbols before encoding. The zero 467 symbols are then discarded after decoding. The source block size 468 to be used for a stream is signalled in the Maximum Source Block 469 Size field of the scheme-specific information. This allows for 470 efficient parallel encoding of multiple streams. 472 A restricted set of possible source block sizes is specified. 473 This allows explicit operation sequences for encoding the 474 restricted set of block sizes to be pre-calculated and embedded in 475 software or handware. 477 This scheme is equivalent to that specified in [dvbts] for arbitrary 478 packet flows. 480 7.2. Formats and Codes 482 7.2.1. FEC Framework Configuration Information 484 7.2.1.1. FEC Scheme ID 486 The value of the FEC Scheme ID for the fully-specified FEC scheme 487 defined in this section is XXX, as assigned by IANA. 489 7.2.1.2. FEC Scheme specific information 491 See . (Section 6.2.1.2) 493 7.2.2. Source FEC Payload ID 495 See . (Section 6.2.2) 497 7.2.3. Repair FEC Payload ID 499 SeeSection 6.2.3 501 7.3. Procedures 503 7.3.1. Source symbol construction 505 See Section 6.3.1 507 7.3.2. Repair packet construction 509 The number of repair symbols contained within a repair packet is 510 computed from the packet length. The ESI value placed into a repair 511 packet is given by the following formula: 513 ESI_repair = I_repair + MSBL 515 Where I_repair is the index of the repair symbol in the sequence of 516 repair symbols generated according to Section 6.4, where the first 517 repair symbol has index 0, the second index 1 etc. and MSBL is the 518 Maximum Source Block Length signalled in the FEC Scheme Specific 519 Information. The Source Block Length field of the Repair FEC Payload 520 ID field SHALL be set to the number of symbols included in the Source 521 Packet Information of packets associated with the source block. 523 7.4. FEC Code Specification 525 The Raptor FEC encoder defined in [RFC5053] SHALL be used. The 526 source symbols passed to the Raptor FEC encoder SHALL consist of the 527 source symbols constructed according to Section 6.3.1 extended with 528 zero or more padding symbols such that the total number of symbols in 529 the source block is equal to the Maximum Source Block Length signaled 530 in the FEC Scheme Specific Information. Thus the value of the 531 parameter K used by the FEC encoded is equal to the Maximum Source 532 Block Length for all blocks of the stream. Padding symbols shall 533 consist entirely of bytes set to the value zero. The symbol size, T, 534 to be used for source block construction and the repair symbol 535 construction is equal to the Encoding Symbol Size signaled in the FEC 536 Scheme Specific Information. The parameter T shall be set such that 537 the number of source symbols in any source block is at most KMAX = 538 8192. The Maximum Source Block Length parameter - and hence the 539 number of symbols used in the FEC Encoding and Decoding operations - 540 SHALL be set to one of the following values: 542 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 543 1139, 1281 545 8. Raptor FEC Scheme for a single sequenced flow 547 8.1. Formats and codes 549 8.1.1. FEC Framework Configuration Information 551 8.1.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, as assigned by IANA. 556 8.1.1.2. Scheme-specific elements 558 See Section 6.2.1.2 560 8.1.2. Source FEC Payload ID 562 The Source FEC Payload ID field is not used by this FEC Scheme. 563 Source packets are not modified by this FEC Scheme. 565 8.1.3. Repair FEC Payload ID 567 The Repair FEC Payload ID format for this FEC Scheme is shown below: 569 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Initial Sequence Number | Encoding Symbol ID | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Source Block Length | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 3: Repair FEC Payload ID 579 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 580 the lowest 16 bits of the sequence number of the first packet to 581 be included in this sub-block. If the sequence numbers are 582 shorter than 16 bits then the received Sequence Number SHALL be 583 logically padded with zero bits to become 16 bits in length 584 respectively. 586 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 587 symbols are contained within this repair packet. The ESI provided 588 is the ESI of the first repair symbol in the packet. 590 Source Block Length (SBL) - 16 bits This field specifies the length 591 of the source block in symbols. 593 8.2. Procedures 595 8.2.1. Source symbol construction 597 This FEC Scheme uses the procedures defined in Section 5 to construct 598 a set of source symbols to which the FEC code can be applied. The 599 sender MUST allocate Source Block Numbers to source blocks 600 sequentially, wrapping around to zero after Source Block Number 601 2^16-1. 603 During the construction of the source block: 605 o the length indication, l[i], included in the Source Packet 606 Information for each packet shall be dependent on the protocol 607 carried within the transport payload. Rules for RTP are specified 608 below. 610 o the value of s[i] in the construction of the Source Packet 611 Information for each packet shall be the smallest integer such 612 that s[i]*T >= (l[i]+3) 614 8.2.2. Derivation of Source FEC Packet Identification Information 616 The Source FEC Packet Identification Information for a source packet 617 is derived from the sequence number of the packet and information 618 received in any Repair FEC packet belonging to this Source Block. 619 Source blocks are identified by the sequence number of the first 620 source packet in the block. This information is signaled in all 621 Repair FEC packets associated with the source block in the Initial 622 Sequence Number field. 624 The length of the Source Packet Information (in bytes) for source 625 packets within a source block is equal to length of the payload 626 containing encoding symbols of the repair packets (i.e. not including 627 the Repair FEC Payload ID) for that block, which MUST be the same for 628 all repair packets. The Application Data Unit Information Length 629 (ADUIL) in symbols is equal to this length divided by the Encoding 630 Symbol Size (which is signaled in the FEC Framework Configuration 631 Information). The set of source packets which are included in the 632 source block is determined from the Initial Sequence Number (ISN) and 633 Source Block Length (SBL) as follows: 635 Let, 637 I be the Initial Sequence Number of the source block 639 LP be the Source Packet Information Length in symbols 641 LB be the Source Block Length in symbols 643 Then, source packets with sequence numbers from I to I +LB/LP-1 644 inclusive are included in the source block. 646 Note that if no FEC Repair packets are received then no FEC decoding 647 is possible and it is unnecessary for the receiver to identify the 648 Source FEC Packet Identification Information for the source packets. 650 The Encoding Symbol ID for a packet is derived from the following 651 information: 653 The sequence number, Ns, of the packet 655 The Source Packet Information Length for the source block, LP 657 The Initial Sequence Number of the source block, I 659 Then the Encoding Symbol ID for packet with sequence number Ns is 660 determined by the following formula: 662 ESI = ( Ns - I ) * LP 664 Note that all repair packet associated to a given Source Block MUST 665 contain the same Source Block Length and Initial Sequence Number. 667 8.2.3. Repair packet construction 669 See Section 7.3.2 671 8.2.4. Procedures for RTP source flows 673 In the specific case of RTP source packet flows, then the RTP 674 Sequence Number field SHALL be used as the sequence number in the 675 procedures described above. The length indication included in the 676 Application Data Unit Information SHALL be the RTP payload length 677 plus the length of the CSRCs, if any, and the RTP padding bytes, if 678 any. Note that this length is always equal to the UDP payload length 679 of the packet minus 12. 681 8.3. FEC Code Specification 683 See Section 7.4 685 9. Security Considerations 687 For the general security considerations related to the use of FEC, 688 refer to [I-D.ietf-fecframe-framework]. 690 10. Session Description Protocol (SDP) Signaling 692 This section provides an SDP [RFC4566] example. The following 693 example uses the SDP elements for FEC Framework, which were 694 introduced in [I-D.ietf-fecframe-sdp-elements], and the FEC grouping 695 semantics [RFC4756]. 697 In this example, we have one source video stream (mid:S1) and one FEC 698 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 699 S1 R1" line. The source and repair streams are sent to the same port 700 on different multicast groups. The repair window is set to 200 ms. 702 v=0 703 o=ali 1122334455 1122334466 IN IP4 fec.example.com 704 s=Raptor FEC Example 705 t=0 0 706 a=group:FEC S1 R1 707 m=video 30000 RTP/AVP 100 708 c=IN IP4 233.252.0.1/127 709 a=rtpmap:100 MP2T/90000 710 a=fec-source-flow: id=0; tag-len=4 711 a=mid:S1 712 m=application 30000 udp/fec 713 c=IN IP4 233.252.0.2/127 714 a=fec-repair-flow: encoding-id=0; fssi=5hu= 715 a=repair-window: 200 716 a=mid:R1 718 11. Congestion Control Considerations 720 For the general congestion control considerations related to the use 721 of FEC, refer to [I-D.ietf-fecframe-framework]. 723 12. IANA Considerations 725 12.1. Registration of FEC Scheme IDs 727 The value of FEC Scheme IDs is subject to IANA registration. For 728 general guidelines on IANA considerations as they apply to this 729 document, refer to [I-D.ietf-fecframe-framework]. 731 This document registers three values in the FEC Framework (FECFRAME) 732 FEC Encoding IDs registry as follows: 734 o XXX for the Raptor FEC Scheme for Arbitrary Packet Flows 735 (Section 6. 737 o XXX for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows 738 (Section 7). 740 o XXX for the Raptor FEC Scheme for a single sequence flow 741 (Section 8). 743 13. Normative References 745 [I-D.ietf-fecframe-framework] 746 Watson, M., "Forward Error Correction (FEC) Framework", 747 draft-ietf-fecframe-framework-03 (work in progress), 748 October 2008. 750 [I-D.ietf-fecframe-sdp-elements] 751 Begen, A., "SDP Elements for FEC Framework", 752 draft-ietf-fecframe-sdp-elements-03 (work in progress), 753 June 2009. 755 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 756 Correction (FEC) Building Block", RFC 5052, August 2007. 758 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 759 "Raptor Forward Error Correction Scheme for Object 760 Delivery", RFC 5053, October 2007. 762 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 763 Requirement Levels", BCP 14, RFC 2119, March 1997. 765 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 766 Description Protocol", RFC 4566, July 2006. 768 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 769 Session Description Protocol", RFC 4756, November 2006. 771 [dvbts] "ETSI TS 102 034 - Digital Video Broadcasting (DVB); 772 Transport of MPEG-2 Based DVB Services over IP Based 773 Networks", March 2005. 775 Author's Address 777 Mark Watson 778 Qualcomm, Inc. 779 3165 Kifer Road 780 Santa Clara, CA 95051 781 U.S.A. 783 Email: watson@qualcomm.com