idnits 2.17.1 draft-ietf-fecframe-raptor-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 798. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 22, 2008) is 5658 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-02 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework M. Watson 3 Internet-Draft Digital Fountain 4 Intended status: Standards Track October 22, 2008 5 Expires: April 25, 2009 7 Raptor FEC Schemes for FECFRAME 8 draft-ietf-fecframe-raptor-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 25, 2009. 35 Abstract 37 This document describes Fully-Specified Forward Error Correction 38 (FEC) Schemes for the Raptor code and its application to reliable 39 delivery of media streams in the context of FEC Framework. The 40 Raptor code is a systematic code, where a number of repair symbols 41 are generated from a set of source symbols and sent in one or more 42 repair flows in addition to the source symbols that are sent to the 43 receiver(s) within a source flow. The Raptor code offers a close to 44 optimal protection against arbitrary packet losses at a low 45 computational complexity. Two FEC Schemes are defined, one for 46 protection of arbitrary packet flows and another for protection of a 47 single flow that already contains a sequence number. Repair data may 48 be sent over arbitrary datagram transport (e.g. UDP) or using RTP. 50 An RTP Payload Type is defined for this latter case. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Document Outline . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 57 4. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 58 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 60 5. General procedures for Raptor FEC Schemes . . . . . . . . . . 7 61 6. Raptor FEC Scheme for arbitrary packet flows . . . . . . . . . 8 62 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 8 64 6.2.1. FEC Framework Configuration Information . . . . . . . 8 65 6.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 9 66 6.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 9 67 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.3.1. Source symbol construction . . . . . . . . . . . . . . 10 69 6.3.2. Repair packet construction . . . . . . . . . . . . . . 10 70 6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 11 71 7. Optimised Raptor FEC Scheme for arbitrary packet flows . . . . 11 72 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 73 7.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12 74 7.2.1. FEC Framework Configuration Information . . . . . . . 12 75 7.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 12 76 7.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 12 77 7.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.3.1. Source symbol construction . . . . . . . . . . . . . . 12 79 7.3.2. Repair packet construction . . . . . . . . . . . . . . 12 80 7.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 13 81 8. Raptor FEC Scheme for a single sequenced flow . . . . . . . . 13 82 8.1. Formats and codes . . . . . . . . . . . . . . . . . . . . 13 83 8.1.1. FEC Framework Configuration Information . . . . . . . 13 84 8.1.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 13 85 8.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 86 8.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14 87 8.2.1. Source symbol construction . . . . . . . . . . . . . . 14 88 8.2.2. Derivation of Source FEC Packet Identification 89 Information . . . . . . . . . . . . . . . . . . . . . 15 90 8.2.3. Repair packet construction . . . . . . . . . . . . . . 16 91 8.2.4. Procedures for RTP source flows . . . . . . . . . . . 16 92 8.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 16 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 94 10. Session Description Protocol (SDP) Signaling . . . . . . . . . 16 95 11. Congestion Control Considerations . . . . . . . . . . . . . . 17 96 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 97 12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 17 98 13. Normative References . . . . . . . . . . . . . . . . . . . . . 17 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 Intellectual Property and Copyright Statements . . . . . . . . . . 19 102 1. Introduction 104 The FEC Framework [I-D.ietf-fecframe-framework] describes a framework 105 for the application of Forward Error Correction to arbitrary packet 106 flows. Modelled after the FEC Building Block developed by the IETF 107 Reliable Multicast Transport working group ([RFC5052]), the FEC 108 Framework defines the concept of FEC Schemes which provide specific 109 Forward Error Correction schemes. This document describes two FEC 110 Schemes which make use of the Raptor FEC code as defined in 111 [RFC5053]. 113 The FEC protection mechanism is independent of the type of the source 114 data, which can be an arbitrary sequence of packets, including for 115 example audio or video data. In general, the operation of the 116 protection mechanism is as follows: 118 o The sender determines a set of source packets to be protected 119 together based on the FEC Framework Configuration Information. 121 o The sender arranges the source packets into a set of source 122 symbols, each of which is the same size. 124 o The sender applies the Raptor protection operation on the source 125 symbols to generate the required number of repair symbols. 127 o The sender packetizes the repair symbols and sends the repair 128 packet(s) along with the source packets to the receiver(s). 130 Per the FEC Framework requirements, the sender MUST transmit the 131 source and repair packets in different source and repair flows, 132 respectively. At the receiver side, if all of the source packets are 133 successfully received, there is no need for FEC recovery and the 134 repair packets are discarded. However, if there are missing source 135 packets, the repair packets can be used to recover the missing 136 information. 138 The operation of the FEC mechanism requires that the receiver can 139 identify the relationships between received source packets and repair 140 packets and in particular which source packets are missing. In many 141 cases, data already exists in the source packets which can be used to 142 refer to source packets and to identify which packets are missing. 143 In this case we assume it is possible to derive a "sequence number" 144 directly or indirectly from the source packets and this sequence 145 number can be used within the FEC Scheme. This case is referred to 146 as a "single sequenced flow". In this case the FEC Source Payload ID 147 defined in [I-D.ietf-fecframe-framework] is empty and the source 148 packets are not modified by the application of FEC, with obvious 149 backwards compatibility advantages. 151 Otherwise, it is necessary to add data to the source packets for FEC 152 purposes in the form of a non-empty FEC Source Payload ID. This case 153 if referred to as the "arbitrary packet flow" case. Accordingly, 154 this document defines two FEC Schemes, one for the case of a single 155 sequenced flow and another for the case of arbitrary packet flows. 157 2. Document Outline 159 This document is organised as follows: 161 Section 5 defines general procedures applicable to the use of the 162 Raptor code in the context of the FEC Framework. 164 Section 6defines an FEC Scheme for the case of arbitrary source 165 flows and follows the format defined for FEC Schemes in 166 [I-D.ietf-fecframe-framework]. This scheme is equivalent to that 167 defined in [3GPP MBMS Specification]. 169 Section 7 defines an FEC Scheme similar to that defined in 170 Section 6but with optimisations for the case where only limited 171 source block sizes are required. This scheme is equivalent to 172 that defined in [DVB AL-FEC specification] for arbitrary packet 173 flows. 175 Section 8 defines an FEC Scheme for the case of a single sequenced 176 flow and follows the format defined for FEC Schemes in 178 [I-D.ietf-fecframe-framework]. This scheme is equivalent to that 179 defined in [DVB AL-FEC specification] for the case of a single 180 sequenced flow. 182 3. Requirements Notation 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 4. Definitions and Abbreviations 190 The definitions, notations and abbreviations commonly used in this 191 document are summarized in this section. 193 4.1. Definitions 195 This document uses the following definitions. For further 196 definitions that apply to FEC Framework in general, see 197 [I-D.ietf-fecframe-framework]. 199 Source Flow: The packet flow(s) carrying the source data and to 200 which FEC protection is to be applied. 202 Repair Flow: The packet flow(s) carrying the repair data. 204 Symbol: A unit of data. Its size, in bytes, is referred to as the 205 symbol size. 207 Source Symbol: The smallest unit of data used during the encoding 208 process. 210 Repair Symbol: Repair symbols are generated from the source symbols. 212 Source Packet: Data packets that contain only source symbols. 214 Repair Packet: Data packets that contain only repair symbols. 216 Source Block: A block of source symbols that are considered together 217 in the encoding process. 219 FEC Framework Configuration Information: Information that controls 220 the operation of the FEC Framework. Each FEC Framework instance has 221 its own configuration information. 223 FEC Payload ID: Information that identifies the contents of a packet 224 with respect to the FEC scheme. 226 Source FEC Payload ID: An FEC Payload ID specifically used with 227 source packets. 229 Repair FEC Payload ID: An FEC Payload ID specifically used with 230 repair packets. 232 4.2. Abbreviations 234 o FSSI: FEC-Scheme-Specific Information. 236 o SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 238 o RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 240 5. General procedures for Raptor FEC Schemes 242 This section specifies general procedures which apply to all Raptor 243 FEC Schemes, specifically the construction of source symbols from a 244 set of source transport payloads. As described in 245 [I-D.ietf-fecframe-framework] for each source transport payload in a 246 source block, the FEC Scheme is provided with: 248 o A description of the source transport flow with which the 249 transport payload is associated and an integer identifier 250 associated with that flow. 252 o The source transport payload itself. 254 o The length of the source transport payload. 256 For each source transport payload, we define the Source Packet 257 Information (SPI) as follows: 259 Let 261 n be the number of source transport payloads in the source block. 263 T be the source symbol size in bytes. Note: this information is 264 provided by the FEC Scheme as defined below. 266 i the index to the (i+1)-th source transport payload to be added 267 to the source block, 0 <= i < n. 269 R[i] denote the number of octets in the (i+1)-th source transport 270 payload. 272 l[i] be a length indication associated with the i-th UDP packet - 273 the nature of the length indication is defined by the FEC Scheme. 275 L[i] denote two octets representing the value of l[i] in network 276 byte order (high order octet first) of the i-th UDP packet. 278 f[i] denote the integer identifier associated with the source 279 transport payload from which the i-th source transport payload was 280 taken. 282 F[i] denote a single octet representing the value of f[i]. 284 s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note 285 s[i] is the length of SPI[i] in units of symbols of size T bytes. 287 P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding 288 octets to align the start of each UDP packet with the start of a 289 symbol. 291 SPI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. 293 Then, a source data block is constructed by concatenating SPI[i] for 294 i = 0, 1, 2, ... n-1. The source data block size, S, is then given 295 by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer 296 Encoding Symbol IDs consecutively starting from zero within the 297 source block. Each source transport payload is associated with the 298 Encoding Symbol ID of the first symbol containing SPI for that 299 packet. Thus, the Encoding Symbol ID value associated with the j-th 300 source packet, ESI[j], is given by ESI[j] = 0, for j=0 and ESI[j] = 301 sum{s[i], i=0,...,(j-1)}, for 0 < j < n. 303 Source blocks are identified by integer Source Block Numbers. This 304 specification does not specify how Source Block Numbers are allocated 305 to source blocks. The Source FEC Packet Identification Information 306 consists of the identity of the source block and the Encoding Symbol 307 ID associated with the packet. 309 6. Raptor FEC Scheme for arbitrary packet flows 311 6.1. Introduction 313 This section specifies an FEC Scheme for the application of the 314 Raptor code to arbitary packet flows. This scheme is recommended in 315 scenarios where maximal generality is required. 317 This scheme is equivalent to that specified in [3GPP MBMS 318 Specification]. 320 6.2. Formats and Codes 322 6.2.1. FEC Framework Configuration Information 324 6.2.1.1. FEC Scheme ID 326 The value of the FEC Scheme ID for the fully-specified FEC scheme 327 defined in this section MUST be TBD as assigned by IANA. 329 6.2.1.2. Scheme-Specific Elements 331 The scheme-specific elements of the FEC Framework Configuration 332 information for this scheme are as follows: 334 Maximum Source Block Length A non-negative integer less than 2^13, 335 in units of symbols 337 Encoding Symbol Size A non-negative integer less than 2^16, in units 338 of bytes 340 An encoding format for this information in a 4 octet field is defined 341 as follows: 343 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Symbol Size (T) | Max. Source Block Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 1: FEC Scheme Specific Information 351 6.2.2. Source FEC Payload ID 353 This scheme makes use of an Explicit Source FEC Payload ID, which is 354 appended to the end of the source packets. 356 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 2: Source FEC Payload ID 364 Source Block Number (SBN), (16 bits): An integer identifier for the 365 source block that the source data within the packet relates to. 367 Encoding Symbol ID (ESI), (16 bits): The starting symbol index of 368 the source packet in the source block. 370 6.2.3. Repair FEC Payload ID 372 The structure of the Repair FEC Payload ID is defined below: 374 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Source Block Number (SBN) | Encoding Symbol ID (ESI) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Source Block Length (SBL) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Repair FEC Payload ID 384 Source Block Number (SBN), (16 bits) An integer identifier for the 385 source block that the repair symbols within the packet relate to. 387 Encoding Symbol ID (ESI), (16 bits) Integer identifier for the 388 encoding symbols within the packet. 390 Source Block Length (SBL), (16 bits) The number of source symbols in 391 the source block. 393 The interpretation of the Source Block Number, Encoding Symbol 394 Identifier and Source Block Length is defined by the FEC Code 395 Specification. 397 6.3. Procedures 399 6.3.1. Source symbol construction 401 This FEC Scheme uses the procedures defined in Section 5 to construct 402 a set of source symbols to which the FEC code can be applied. The 403 sender MUST allocate Source Block Numbers to source blocks 404 sequentially, wrapping around to zero after Source Block Number 405 2^16-1. 407 During the construction of the source block: 409 o the length indication, l[i], included in the Source Packet 410 Information for each packet shall be the transport payload length. 412 o the value of s[i] in the construction of the Source Packet 413 Information for each packet shall be the smallest integer such 414 that s[i]*T >= (l[i]+3). 416 6.3.2. Repair packet construction 418 The number of repair symbols contained within a repair packet is 419 computed from the packet length. The ESI value placed into a repair 420 packet is given by the following formula: 422 ESI_repair = I_repair + SBL, 424 where I_repair is the index of the repair symbol in the sequence of 425 repair symbols generated according to Section 6.4, where the first 426 repair symbol has index 0, the second index 1 etc. and SBL is the 427 Source Block Length. The Source Block Length field of the Repair FEC 428 Payload ID field SHALL be set to the number of symbols included in 429 the Source Packet Information of packets associated with the source 430 block. 432 6.4. FEC Code Specification 434 The Raptor FEC encoder defined in [RFC5053] SHALL be used. The 435 source symbols passed to the Raptor FEC encoder SHALL consist of the 436 source symbols constructed according to Section 6.3.1. Thus the 437 value of the parameter K used by the FEC encoder (equal to the Source 438 Block Length) may vary amongst the blocks of the stream but SHALL NOT 439 exceed the Maximum Source Block Length signalled in the FEC Scheme- 440 specific information. The symbol size, T, to be used for source 441 block construction and the repair symbol construction is equal to the 442 Encoding Symbol Size signaled in the FEC Scheme Specific Information. 444 7. Optimised Raptor FEC Scheme for arbitrary packet flows 446 7.1. Introduction 448 This section specifies a slightly modified version of the FEC Scheme 449 specified in Section 6 which is applicable to scenarios in which only 450 relatively small block sizes will be used. These modifications admit 451 substantial optimisations to both sender and receiver 452 implementations. 454 In outline, the modifications are: 456 All source blocks within a stream are encoded using the same 457 source block size. Code shortening is used to encode blocks of 458 different sizes. This is achieved by padding every block to the 459 required size using zero symbols before encoding. The zero 460 symbols are then discarded after decoding. The source block size 461 to be used for a stream is signalled in the Maximum Source Block 462 Size field of the scheme-specific information. This allows for 463 efficient parallel encoding of multiple streams. 465 A restricted set of possible source block sizes is specified. 466 This allows explicit operation sequences for encoding the 467 restricted set of block sizes to be pre-calculated and embedded in 468 software or handware. 470 This scheme is equivalent to that specified in [DVB AL-FEC 471 Specification] for arbitrary packet flows. 473 7.2. Formats and Codes 475 7.2.1. FEC Framework Configuration Information 477 7.2.1.1. FEC Scheme ID 479 The value of the FEC Scheme ID for the fully-specified FEC scheme 480 defined in this section MUST be TBD as assigned by IANA. 482 7.2.1.2. FEC Scheme specific information 484 See . (Section 6.2.1.2) 486 7.2.2. Source FEC Payload ID 488 See . (Section 6.2.2) 490 7.2.3. Repair FEC Payload ID 492 SeeSection 6.2.3 494 7.3. Procedures 496 7.3.1. Source symbol construction 498 See Section 6.3.1 500 7.3.2. Repair packet construction 502 The number of repair symbols contained within a repair packet is 503 computed from the packet length. The ESI value placed into a repair 504 packet is given by the following formula: 506 ESI_repair = I_repair + MSBL 508 Where I_repair is the index of the repair symbol in the sequence of 509 repair symbols generated according to Section 6.4, where the first 510 repair symbol has index 0, the second index 1 etc. and MSBL is the 511 Maximum Source Block Length signalled in the FEC Scheme Specific 512 Information. The Source Block Length field of the Repair FEC Payload 513 ID field SHALL be set to the number of symbols included in the Source 514 Packet Information of packets associated with the source block. 516 7.4. FEC Code Specification 518 The Raptor FEC encoder defined in [RFC5053] SHALL be used. The 519 source symbols passed to the Raptor FEC encoder SHALL consist of the 520 source symbols constructed according to Section 6.3.1 extended with 521 zero or more padding symbols such that the total number of symbols in 522 the source block is equal to the Maximum Source Block Length signaled 523 in the FEC Scheme Specific Information. Thus the value of the 524 parameter K used by the FEC encoded is equal to the Maximum Source 525 Block Length for all blocks of the stream. Padding symbols shall 526 consist entirely of bytes set to the value zero. The symbol size, T, 527 to be used for source block construction and the repair symbol 528 construction is equal to the Encoding Symbol Size signaled in the FEC 529 Scheme Specific Information. The parameter T shall be set such that 530 the number of source symbols in any source block is at most KMAX = 531 8192. The Maximum Source Block Length parameter - and hence the 532 number of symbols used in the FEC Encoding and Decoding operations - 533 SHALL be set to one of the following values: 535 101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 536 1139, 1281 538 8. Raptor FEC Scheme for a single sequenced flow 540 8.1. Formats and codes 542 8.1.1. FEC Framework Configuration Information 544 8.1.1.1. FEC Scheme ID 546 The value of the FEC Scheme ID for the fully-specified FEC scheme 547 defined in this section MUST be TBD as assigned by IANA. 549 8.1.1.2. Scheme-specific elements 551 See Section 6.2.1.2 553 8.1.2. Source FEC Payload ID 555 The Source FEC Payload ID field is not used by this FEC Scheme. 556 Source packets are not modified by this FEC Scheme. 558 8.1.3. Repair FEC Payload ID 560 The Repair FEC Payload ID format for this FEC Scheme is shown below: 562 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Initial Sequence Number | Encoding Symbol ID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Source Block Length | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Figure 3: Repair FEC Payload ID 572 Initial Sequence Number (Flow i ISN) - 16 bits This field specifies 573 the lowest 16 bits of the sequence number of the first packet to 574 be included in this sub-block. If the sequence numbers are 575 shorter than 16 bits then the received Sequence Number SHALL be 576 logically padded with zero bits to become 16 bits in length 577 respectively. 579 Encoding Symbol ID (ESI) - 16 bits This field indicates which repair 580 symbols are contained within this repair packet. The ESI provided 581 is the ESI of the first repair symbol in the packet. 583 Source Block Length (SBL) - 16 bits This field specifies the length 584 of the source block in symbols. 586 8.2. Procedures 588 8.2.1. Source symbol construction 590 This FEC Scheme uses the procedures defined in Section 5 to construct 591 a set of source symbols to which the FEC code can be applied. The 592 sender MUST allocate Source Block Numbers to source blocks 593 sequentially, wrapping around to zero after Source Block Number 594 2^16-1. 596 During the construction of the source block: 598 o the length indication, l[i], included in the Source Packet 599 Information for each packet shall be dependent on the protocol 600 carried within the transport payload. Rules for RTP are specified 601 below. 603 o the value of s[i] in the construction of the Source Packet 604 Information for each packet shall be the smallest integer such 605 that s[i]*T >= (l[i]+3) 607 8.2.2. Derivation of Source FEC Packet Identification Information 609 The Source FEC Packet Identification Information for a source packet 610 is derived from the sequence number of the packet and information 611 received in any Repair FEC packet belonging to this Source Block. 612 Source blocks are identified by the sequence number of the first 613 source packet in the block. This information is signaled in all 614 Repair FEC packets associated with the source block in the Initial 615 Sequence Number field. 617 The length of the Source Packet Information (in bytes) for source 618 packets within a source block is equal to length of the payload 619 containing encoding symbols of the repair packets (i.e. not including 620 the Repair FEC Payload ID) for that block, which MUST be the same for 621 all repair packets. The Source Packet Information Length (SPIL) in 622 symbols is equal to this length divided by the Encoding Symbol Size 623 (which is signaled in the FEC Framework Configuration Information). 624 The set of source packets which are included in the source block is 625 determined from the Initial Sequence Number (ISN) and Source Block 626 Length (SBL) as follows: 628 Let, 630 I be the Initial Sequence Number of the source block 632 LP be the Source Packet Information Length in symbols 634 LB be the Source Block Length in symbols 636 Then, source packets with sequence numbers from I to I +LB/LP-1 637 inclusive are included in the source block. 639 Note that if no FEC Repair packets are received then no FEC decoding 640 is possible and it is unnecessary for the receiver to identify the 641 Source FEC Packet Identification Information for the source packets. 643 The Encoding Symbol ID for a packet is derived from the following 644 information: 646 The sequence number, Ns, of the packet 648 The Source Packet Information Length for the source block, LP 650 The Initial Sequence Number of the source block, I 652 Then the Encoding Symbol ID for packet with sequence number Ns is 653 determined by the following formula: 655 ESI = ( Ns - I ) * LP 657 Note that all repair packet associated to a given Source Block MUST 658 contain the same Source Block Length and Initial Sequence Number. 660 8.2.3. Repair packet construction 662 See Section 7.3.2 664 8.2.4. Procedures for RTP source flows 666 In the specific case of RTP source packet flows, then the RTP 667 Sequence Number field SHALL be used as the sequence number in the 668 procedures described above. The length indication included in the 669 Source Packet Information SHALL be the RTP payload length plus the 670 length of the CSRCs, if any, and the RTP padding bytes, if any. Note 671 that this length is always equal to the UDP payload length of the 672 packet, minus 12. 674 8.3. FEC Code Specification 676 See Section 7.4 678 9. Security Considerations 680 For the general security considerations related to the use of FEC, 681 refer to [I-D.ietf-fecframe-framework]. 683 10. Session Description Protocol (SDP) Signaling 685 This section provides an SDP [RFC4566] example. The following 686 example uses the SDP elements for FEC Framework, which were 687 introduced in [I-D.ietf-fecframe-sdp-elements], and the FEC grouping 688 semantics [RFC4756]. 690 In this example, we have one source video stream (mid:S1) and one FEC 691 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 692 S1 R1" line. The source and repair streams are sent to the same port 693 on different multicast groups. The repair window is set to 200 ms. 695 v=0 696 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 697 s=Interleaved Parity FEC Example 698 t=0 0 699 a=group:FEC S1 R1 700 m=video 30000 RTP/AVP 100 701 c=IN IP4 224.1.1.1/127 702 a=rtpmap:100 MP2T/90000 703 a=fec-source-flow: id=0 704 a=mid:S1 705 m=application 30000 udp/fec 706 c=IN IP4 224.1.2.1/127 707 a=fec-repair-flow: scheme-id=0; ss-fssi=5hu= 708 a=repair-window: 200 709 a=mid:R1 711 11. Congestion Control Considerations 713 For the general congestion control considerations related to the use 714 of FEC, refer to [I-D.ietf-fecframe-framework]. 716 12. IANA Considerations 718 12.1. Registration of FEC Scheme IDs 720 The value of FEC Scheme IDs is subject to IANA registration. For 721 general guidelines on IANA considerations as they apply to this 722 document, refer to [I-D.ietf-fecframe-framework]. 724 13. Normative References 726 [I-D.ietf-fecframe-framework] 727 Watson, M., "Forward Error Correction (FEC) Framework", 728 draft-ietf-fecframe-framework-02 (work in progress), 729 July 2008. 731 [RFC5052] "", 2005. 733 [RFC5053] "", 2005. 735 [I-D.ietf-fecframe-sdp-elements] 736 Begen, A., "SDP Elements for FEC Framework", 737 draft-ietf-fecframe-sdp-elements-01 (work in progress), 738 July 2008. 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, March 1997. 743 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 744 Description Protocol", RFC 4566, July 2006. 746 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 747 Session Description Protocol", RFC 4756, November 2006. 749 Author's Address 751 Mark Watson 752 Digital Fountain 753 39141 Civic Center Drive 754 Suite 300 755 Fremont, CA 94538 756 U.S.A. 758 Email: mark@digitalfountain.com 760 Full Copyright Statement 762 Copyright (C) The IETF Trust (2008). 764 This document is subject to the rights, licenses and restrictions 765 contained in BCP 78, and except as set forth therein, the authors 766 retain all their rights. 768 This document and the information contained herein are provided on an 769 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 770 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 771 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 772 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 773 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 776 Intellectual Property 778 The IETF takes no position regarding the validity or scope of any 779 Intellectual Property Rights or other rights that might be claimed to 780 pertain to the implementation or use of the technology described in 781 this document or the extent to which any license under such rights 782 might or might not be available; nor does it represent that it has 783 made any independent effort to identify any such rights. Information 784 on the procedures with respect to rights in RFC documents can be 785 found in BCP 78 and BCP 79. 787 Copies of IPR disclosures made to the IETF Secretariat and any 788 assurances of licenses to be made available, or the result of an 789 attempt made to obtain a general license or permission for the use of 790 such proprietary rights by implementers or users of this 791 specification can be obtained from the IETF on-line IPR repository at 792 http://www.ietf.org/ipr. 794 The IETF invites any interested party to bring to its attention any 795 copyrights, patents or patent applications, or other proprietary 796 rights that may cover technology that may be required to implement 797 this standard. Please address the information to the IETF at 798 ietf-ipr@ietf.org.