idnits 2.17.1 draft-begen-fecframe-1d2d-parity-scheme-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 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 939. 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 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 (February 18, 2008) is 5906 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-01 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) ** Downref: Normative reference to an Informational draft: draft-begen-mmusic-fec-grouping-issues (ref. 'I-D.begen-mmusic-fec-grouping-issues') Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft R. Asati 4 Intended status: Standards Track Cisco Systems 5 Expires: August 21, 2008 February 18, 2008 7 1-D and 2-D Parity FEC Scheme for FEC Framework 8 draft-begen-fecframe-1d2d-parity-scheme-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 August 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document describes a Fully-Specified Forward Error Correction 42 (FEC) Scheme for the one-dimensional (1-D) and two-dimensional (2-D) 43 parity codes and its application to reliable delivery of media 44 streams in the context of FEC Framework. The 1-D and 2-D parity 45 codes are systematic codes, where a number of repair symbols are 46 generated from a set of source symbols and sent in one or more repair 47 flows in addition to the source symbols that are sent to the 48 receiver(s) within a source flow. The 1-D and 2-D parity codes offer 49 a good protection against random and bursty packet losses at a cost 50 of decent complexity. This document also specifies an RTP payload 51 format for the FEC that is generated by the 1-D and 2-D parity codes 52 from a source media encapsulated in RTP. The FEC defined in this 53 document is not backward compatible with RFC 5109. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Use Cases for 1-D Parity Codes . . . . . . . . . . . . . . 4 59 1.2. Use Cases for 2-D Parity Codes . . . . . . . . . . . . . . 4 60 1.3. Overhead Computation . . . . . . . . . . . . . . . . . . . 4 61 1.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 5 62 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 63 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 5 64 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Formats and Codes . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Source FEC Payload ID . . . . . . . . . . . . . . . . . . 6 69 4.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 7 70 4.3. FEC Framework Configuration Information . . . . . . . . . 10 71 4.3.1. Mandatory Elements . . . . . . . . . . . . . . . . . . 11 72 4.3.2. Scheme-Specific Elements . . . . . . . . . . . . . . . 11 73 4.3.3. Encoding Format . . . . . . . . . . . . . . . . . . . 12 74 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.1. Configuration Information Signaling Procedures . . . . . . 12 76 5.2. Content Delivery Protocol Requirements . . . . . . . . . . 13 77 5.3. Determination of Source Block Size and Repair Window . . . 13 78 6. 1-D and 2-D Parity FEC Code Specification . . . . . . . . . . 13 79 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 14 81 6.2.1. Generating the FEC Header . . . . . . . . . . . . . . 14 82 6.2.2. Generating the Repair Packet Payload . . . . . . . . . 15 83 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 15 84 6.3.1. Associating the Source and Repair Packets . . . . . . 16 85 6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 16 86 6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . . 17 87 6.3.4. Iterative Decoding Algorithm for the 2-D Parity 88 Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 89 7. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8. Congestion Control Considerations . . . . . . . . . . . . . . 18 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 93 10.1. Registration of FEC Encoding ID . . . . . . . . . . . . . 19 94 10.2. Registration of audio/2dparityfec . . . . . . . . . . . . 19 95 10.3. Registration of video/2dparityfec . . . . . . . . . . . . 19 96 10.4. Registration of text/2dparityfec . . . . . . . . . . . . . 19 97 10.5. Registration of application/2dparityfec . . . . . . . . . 19 98 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 101 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 103 Intellectual Property and Copyright Statements . . . . . . . . . . 22 105 1. Introduction 107 This document defines a new RTP payload format for the FEC that is 108 generated by the 1-D and 2-D parity codes from a source media 109 encapsulated in RTP [RFC3550]. The type of the protected source 110 media can be audio, video, text or application. The payload format 111 also allows for a wide range of FEC configurations to be used within 112 the FEC Framework. The configuration information for the FEC 113 Framework is described through out-of-band means. This configuration 114 information plus the information contained in the payload format let 115 the receiver(s) know the exact associations/relationships between the 116 source and repair packets. 118 The FEC supported by this format uses the simple exclusive OR (XOR) 119 operation. In a nutshell, the sender determines a set of source 120 packets to be protected together based on the FEC Framework 121 Configuration Information. The sender then applies the XOR operation 122 to generate the required number of repair packets and sends the 123 repair packet(s) along with the source packets to the receiver(s). 124 Per the FEC Framework requirements, the sender MUST transmit the 125 source and repair packets in different source and repair flows, 126 respectively. At the receiver side, if all of the source packets are 127 successfully received, there is no need for FEC recovery and the 128 repair packets should be discarded. However, if there are missing 129 source packets, the repair packets can be used to recover the missing 130 information. 132 Editor's note: Include brief introduction to the parity codes, show 133 a block diagram, column FEC/row FEC, the notion of L and D. 135 1.1. Use Cases for 1-D Parity Codes 137 Editor's note: This section should include the use cases for the 1-D 138 parity codes, the scenarios where the 1-D parity codes fail. 140 1.2. Use Cases for 2-D Parity Codes 142 Editor's note: This section should include the use cases for the 2-D 143 parity codes, the scenarios where they offer an advantage over the 144 1-D version and the scenarios where the 2-D parity codes fail. 146 1.3. Overhead Computation 148 Editor's note: This section should include formulations to be used 149 to compute the overhead for the 1-D and 2-D parity codes. 151 1.4. Backward Compatibility 153 Editor's note: This section should include the limitations of the 154 existing specs such as [SMPTE2022-1] and [RFC5109]. It should also 155 include the differences between these specs. 157 This FEC scheme specification follows the document structure defined 158 in [I-D.ietf-fecframe-framework]. 160 2. Requirements Notation 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 3. Definitions, Notations and Abbreviations 168 The definitions, notations and abbreviations commonly used in this 169 document are summarized in this section. 171 3.1. Definitions 173 This document uses the following definitions. For further 174 definitions that apply to FEC Framework in general, see 175 [I-D.ietf-fecframe-framework]. 177 Source Flow: The packet flow(s) carrying the source data and to 178 which FEC protection is to be applied. 180 Repair Flow: The packet flow(s) carrying the repair data. 182 Symbol: A unit of data. Its size, in bytes, is referred to as the 183 symbol size. 185 Source Symbol: The smallest unit of data used during the encoding 186 process. All source symbols within a source block have the same 187 size. 189 Repair Symbol: Repair symbols are generated from the source symbols 190 and they have the same size as the source symbols of that source 191 block. 193 Source Packet: Data packets that contain only source symbols. 195 Repair Packet: Data packets that contain only repair symbols. 197 Source Block: A block of source symbols that are considered together 198 in the encoding process. 200 FEC Framework Configuration Information: Information that controls 201 the operation of the FEC Framework. Each FEC Framework instance has 202 its own configuration information. 204 FEC Payload ID: Information that identifies the contents of a packet 205 with respect to the FEC scheme. 207 Source FEC Payload ID: An FEC Payload ID specifically used with 208 source packets. 210 Repair FEC Payload ID: An FEC Payload ID specifically used with 211 repair packets. 213 3.2. Notations 215 o L: Number of columns of the source block. 217 o D: Number of rows of the source block. 219 3.3. Abbreviations 221 o XOR: Bitwise exclusive OR operation. 0 XOR 0 = 0; 0 XOR 1 = 1; 1 222 XOR 0 = 1; 1 XOR 1 = 0. 224 o FSSI: FEC-Scheme-Specific Information. 226 o SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 228 o RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 230 o ToP: Type of the protection applied by the sender. 232 o ToF: Type of the FEC data carried in the repair packet. 234 4. Formats and Codes 236 This section defines the formats of the source and repair packets as 237 well as the configuration information for the FEC scheme. 239 4.1. Source FEC Payload ID 241 The source packets MUST contain the information that identifies the 242 source block and the position within the source block occupied by the 243 packet. This information is referred to as the Source FEC Payload 244 ID. In some cases, Source FEC Payload ID may be inferred from the 245 fields already existing in the packet. In other cases, however, the 246 required information is explicitly encoded into a specific field 247 called Explicit Source FEC Payload ID, which is appended to the end 248 of the source packets [I-D.ietf-fecframe-framework]. 250 Since the source packets that are carried within an RTP stream 251 already contain unique sequence numbers in their RTP headers 252 [RFC3550], the Source FEC Payload ID can be derived in a 253 straightforward manner. Thus, there is no need to use the Explicit 254 Source FEC Payload ID field. The primary advantage of this approach 255 is that the source packets are not modified in anyway. This provides 256 backward compatibility for the receivers that do not support FEC at 257 all. In multicast scenarios, this backward compatibility becomes 258 quite useful as it allows the non-FEC-capable receivers to receive 259 and interpret the source packets. 261 The derivation of the Source FEC Payload ID from the RTP sequence 262 number is discussed in Section 5. 264 Editor's note: This section should specify the additional 265 requirements that are relevant to grouping multiple source flows 266 together before applying FEC protection. 268 4.2. Repair FEC Payload ID 270 The repair packets MUST contain information that identifies the 271 source block they pertain to and the relationship between the 272 contained repair symbols and the original source block. This 273 information is referred to as the Repair FEC Payload ID. This 274 information MUST be encoded into a specific field between the 275 transport header and the repair symbols within a repair packet, as 276 shown in Figure 1 [I-D.ietf-fecframe-framework]. 278 +------------------------------+ 279 | IP Header | 280 +------------------------------+ 281 | Transport Header | 282 +------------------------------+ 283 | Repair FEC Payload ID | 284 +------------------------------+ 285 | Repair Symbols | 286 +------------------------------+ 288 Figure 1: Format of repair packets 290 Since the repair packets are carried within an RTP stream, the Repair 291 FEC Payload ID consists of an RTP header and an FEC header. This is 292 shown in Figure 2. 294 +------------------------------+ 295 | IP Header | 296 +------------------------------+ 297 | Transport Header | ,--+------------------------------+ 298 +------------------------------+-' | RTP Header | 299 | Repair FEC Payload ID | +------------------------------+ 300 +------------------------------+-. | FEC Header | 301 | Repair Symbols | `--+------------------------------+ 302 +------------------------------+ 304 Figure 2: Format of Repair FEC Payload ID 306 The RTP header is formatted according to [RFC3550] with some further 307 clarifications listed below: 309 o Marker: This field is not used for this payload type, and SHALL 310 be set to 0. 312 o Synchronization Source (SSRC): The SSRC value SHALL be the same 313 as the SSRC value of the protected source RTP stream. 315 o Sequence Number (SN): The sequence number has the standard 316 definition. It MUST be one higher than the sequence number in the 317 previously transmitted repair packet. 319 o Timestamp (TS): The timestamp MUST be set to the value of the 320 media RTP clock at the instant the repair packet is transmitted. 321 Thus, the TS value in FEC packets is always monotonically 322 increasing. 324 o Payload Type: The payload type for the repair packets is 325 determined through the payload format specified in the FEC 326 Framework Configuration Information. Note that this document 327 introduces a new payload format for the repair packets (See 328 Section 10 for details). According to [RFC3550], an RTP receiver 329 that cannot recognize a payload type must discard it. This 330 provides backward compatibility. The FEC mechanisms can then be 331 used in a multicast group with mixed FEC-capable and non-FEC- 332 capable receivers. If the non-FEC-capable receivers receive any 333 repair packet, they will not recognize the payload type, and 334 hence, discard the repair packets. 336 The FEC header is 12 octets. The format of the FEC header is shown 337 in Figure 3. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |E|I|P|X| CC |M| PT recovery | SN base | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | TS recovery | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Length recovery | Increment | NA | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 3: Format of the FEC header 351 The FEC header consists of the following fields: 353 o The E bit is the extension flag reserved to indicate any future 354 extension to this specification. It SHALL be set to 0, and SHOULD 355 be ignored by the receiver. 357 o The I bit MUST be set to 0 for the column-FEC packets, and MUST be 358 set to 1 for the row-FEC packets. This is the indicator bit that 359 shows the type of the FEC carried with this packet. 361 o The P recovery field, the X recovery field, the CC recovery field, 362 the M recovery field, and the PT recovery field are obtained by 363 applying protection to the corresponding P, X, CC, M, and PT 364 values from the RTP headers of the source packets associated with 365 this repair packet. 367 o The SN base field MUST be set to the lowest sequence number, 368 taking wrap around into account, of those source packets protected 369 by FEC. 371 o The TS recovery field is computed by applying protection to the 372 timestamps of the source packets associated with this repair 373 packet. This allows the timestamp to be completely recovered. 375 o The Length recovery field is used to determine the length of any 376 recovered packets. It is computed by applying protection to the 377 unsigned network-ordered 16-bit representation of the sums of the 378 lengths (in bytes) of the media payload, CSRC list, extension and 379 padding of each of the source packets associated with this repair 380 packet. In other words, the CSRC list, RTP extension, and padding 381 of the media payload packets, if present, are counted as part of 382 the payload. This allows the FEC procedure to be applied even 383 when the lengths of the protected source packets are not 384 identical. 386 o The Increment field is the period used to select the source 387 packets associated with this repair packet. It MUST be set to the 388 L parameter defined in Section 4.3.2 for the column-FEC packets, 389 and MUST be set to 1 for the row-FEC packets. 391 o The NA field indicates the number of source packets associated 392 with this repair packet. It MUST be set to the D parameter 393 defined in Section 4.3.2 for the column-FEC packets, and MUST be 394 set to the L parameter defined in Section 4.3.2 for the row-FEC 395 packets. 397 Editor's note: Since the L and D are specified in the FSSI, we may 398 easily skip the Increment and NA fields in the header. However, this 399 information may be needed by the Repair FEC Payload ID and is useful 400 for sanity checks. 402 Editor's note: Shall we consider D and L values larger than 255? If 403 we don't put the Increment and NA fields in the repair packets, 404 length of the D and L values will not be an issue any more. 406 It should be noted that a mask-based approach (similar to the one 407 specified in [RFC5109]) may not be very efficient to indicate which 408 source packets in the current source block are associated with a 409 given repair packet. In particular, for the applications that would 410 like to use large source block sizes, the size of the mask that is 411 required to describe the source-repair packet associations may be 412 prohibitively large. Instead, a systematic approach that specifies 413 the same relationships with fewer bits is generally more efficient. 415 4.3. FEC Framework Configuration Information 417 The FEC Framework defines a minimum set of information that MUST be 418 communicated between the sender and receiver(s) for a proper 419 operation of the FEC scheme. This information is called the FEC 420 Framework Configuration Information. This information specifies how 421 the sender applies protection to the source flow(s) and how the 422 repair flow(s) can be used to recover the lost data. In other words, 423 this information specifies the relationship(s) between the source and 424 repair flows. The FEC Framework requires every FEC Framework 425 instance to provide its own configuration information. 427 From the FEC scheme point of view, the FEC Framework Configuration 428 Information consists of mandatory and scheme-specific elements. We 429 describe these elements below. 431 4.3.1. Mandatory Elements 433 o FEC Encoding ID: The value of the FEC Encoding ID for the fully- 434 specified FEC scheme defined in this document MUST be TBD as 435 assigned by IANA. Refer to Section 10. 437 4.3.2. Scheme-Specific Elements 439 FEC-Scheme-Specific Information (FSSI) includes the information that 440 is specific to the FEC scheme used by the Content Delivery Protocol. 441 FSSI is used to communicate the information that cannot be adequately 442 represented otherwise and is essential for proper FEC encoding and 443 decoding operations. 445 The FSSI is carried in two opaque containers. The first container 446 contains the FSSI required only by the sender. This information is 447 referred to as the Sender-Side FEC-Scheme-Specific Information (SS- 448 FSSI). Rest of the FSSI is referred to as the Receiver-Side FEC- 449 Scheme-Specific Information (RS-FSSI) and carried in the second 450 container. 452 The following parameters are carried in the FEC Scheme-Specific 453 Information element: 455 o L: Number of columns of the source block. L is a positive 456 integer. L cannot be larger than 255. 458 o D: Number of rows of the source block. D is a positive integer. 459 D cannot be larger than 255. 461 o SA: Sending arrangement. This is TBD. 463 Editor's note: Shall we define the sending arrangements? Can we 464 generalize this? Or, should we fix it to a certain sending 465 arrangement? Or, should we use "repair-window" attribute to 466 figure out the sending arrangement? E.g., send the repair packets 467 (as smoothly as possible) such that repair window requirement is 468 not violated. 470 Editor's note: In a strict sense, sending arrangement does not 471 depend on the FEC scheme and probably should not be part of this 472 specification. It is a transmission problem, which is out of the 473 scope of this document. 475 o ToP: Type of the protection applied by the sender. There are 476 three possible values for ToP: 0 for 1-D column-FEC protection, 1 477 for 1-D row-FEC protection, and 2 for 2-D column and row-FEC 478 protection. The ToP value of 3 is reserved for possible uses in 479 the future. The ToP value MAY be set by the receiver or another 480 3rd party entity to control the FEC operations at the sender. 482 Editor's note: Shall we consider code types other than XOR? 484 o ToF: Type of the FEC data carried in the repair flow. 0 for 485 column FEC, and 1 for row FEC. While the type of the FEC data 486 within a repair packet is already indicated by the I bit in the 487 FEC header, ToF is used by the receivers to determine which repair 488 flow carries which FEC data before they start receiving the repair 489 packets. For example, the sender might be generating two repair 490 flows corresponding to column FEC and and row FEC, and the 491 receiver might be interested only in the column-FEC protection. 492 The receiver can identify the repair flow carrying the column-FEC 493 data by checking the ToF values for each repair flow described in 494 the FEC Framework Configuration Information. 496 All of the parameters listed above MUST be included in the FSSI. The 497 parameters L, D and ToP are carried within the SS-FSSI container. 498 The parameter ToF is carried within the RS-FSSI container. 500 4.3.3. Encoding Format 502 The SS-FSSI container contains the string resulting from the Base64 503 encoding of the following value: TBD 505 The RS-FSSI container contains the string resulting from the Base64 506 encoding of the following value: TBD 508 5. Procedures 510 This section describes the procedures that are specific to the 1-D 511 and 2-D parity FEC scheme. 513 5.1. Configuration Information Signaling Procedures 515 This specification makes use of the signaling protocol to signal the 516 FEC Framework Configuration Information between the sender and 517 receiver(s). This enables the sender and receiver(s) to be in sync 518 with respect to the information needed for the operation of FEC 519 Framework. 521 5.2. Content Delivery Protocol Requirements 523 Content Delivery Protocol (CDP) is a complete application-protocol 524 specification that provides FEC capabilities by making use of the FEC 525 Schemes through the use of FEC Framework defined in 526 [I-D.ietf-fecframe-framework]. 528 The 1-D/2-D parity encoder and decoder require the following from the 529 CDP: 531 o The size of the source block, namely the number of columns (L) and 532 the number of rows (D). 534 o Type of the protection to be applied to the source blocks (ToP). 536 This information is transmitted to the receiver side by the CDP 537 through the FEC Framework Configuration Information. The 1-D/2-D 538 parity encoder additionally requires: 540 o The data to be protected. 542 The 1-D/2-D parity encoder provides the following information to the 543 CDP: 545 o A column-FEC packet that is generated by applying FEC over each 546 column in the current source block, if column-FEC is enabled. 548 o A row-FEC packet that is generated by applying FEC over each row 549 in the current source block, if row-FEC is enabled. 551 The source packets as well as the repair packets are then transmitted 552 to the receiver(s) by the transport protocol chosen by the CDP. 554 5.3. Determination of Source Block Size and Repair Window 556 TBC. 558 Editor's note: This section should discuss the derivation of the 559 Source FEC Payload ID from the RTP sequence number. 561 6. 1-D and 2-D Parity FEC Code Specification 563 This section provides a complete specification of the 1-D and 2-D 564 parity FEC scheme. Basically, it specifies the steps involved in 565 generating the repair packets and reconstructing the missing source 566 packets from the repair packets. 568 6.1. Overview 570 TBC. 572 6.2. Repair Packet Construction 574 The Repair FEC Payload ID consists of an RTP header and an FEC 575 header. The RTP header of an repair packet is formed based on the 576 guidelines given in Section 4.2. 578 6.2.1. Generating the FEC Header 580 The FEC header includes 12 octets (96 bits). It is constructed by 581 applying the XOR operation on the bit strings that are generated from 582 the individual source packets protected by this particular repair 583 packet. The set of the source packets that are associated with a 584 given repair packet can be computed by the formula given in 585 Section 6.3.1. 587 The bit string is formed for each source packet by concatenating the 588 following fields together in the order specified: 590 o The first 64 bits of the RTP header (64 bits). 592 o Unsigned network-ordered 16-bit representation of the source 593 packet length in bytes minus 12 (for the fixed RTP header), i.e., 594 the sum of the lengths of all the following if present: the CSRC 595 list, extension header, RTP payload, and RTP padding (16 bits). 597 By applying parity operation on the bit strings, we generate the FEC 598 bit string. The FEC header is generated from the FEC bit string as 599 follows: 601 o The first (most significant) 2 bits in the FEC bit string are 602 skipped. 604 o The next bit in the FEC bit string is written into the P recovery 605 bit of the FEC header in the FEC packet. 607 o The next bit in the FEC bit string is written into the X recovery 608 bit of the FEC header. 610 o The next 4 bits of the FEC bit string are written into the CC 611 recovery field of the FEC header. 613 o The next bit is written into the M recovery bit of the FEC header. 615 o The next 7 bits of the FEC bit string are written into the PT 616 recovery field in the FEC header. 618 o The next 16 bits are skipped. 620 o The next 32 bits of the FEC bit string are written into the TS 621 recovery field in the FEC header. 623 o The next 16 bits are written into the length recovery field in the 624 packet header. 626 As described in Section 4.2, the SN base field of the FEC header MUST 627 be set to the lowest sequence number of the source packets protected 628 by this repair packet. For the column-FEC packets, this corresponds 629 to the lowest sequence number of the source packets that form the 630 column. For the row-FEC packets, the SN base field MUST be set to 631 the lowest sequence number of the source packets that form the row. 633 The Increment field MUST be set to the L parameter defined in 634 Section 4.3.2 for the column-FEC packets, and MUST be set to 1 for 635 the row-FEC packets. Finally, the NA field MUST be set to the D 636 parameter defined in Section 4.3.2 for the column-FEC packets, and 637 MUST be set to the L parameter defined in Section 4.3.2 for the row- 638 FEC packets. 640 6.2.2. Generating the Repair Packet Payload 642 The repair packet payload consists of the bits that are generated by 643 applying the XOR operation on the payloads of the source RTP packets. 644 If the payload lengths of the source packets are not equal, each 645 shorter packet MUST be padded to the length of the longest packet by 646 adding octet 0's at the end. 648 6.3. Source Packet Reconstruction 650 This section describes the recovery procedures that are required to 651 reconstruct the missing packets. The recovery process has two steps. 652 In the first step, the FEC decoder determines which source and repair 653 packets should be used in order to recover a missing packet. In the 654 second step, the decoder recovers the missing packet, which consists 655 of an RTP header and RTP payload. 657 In the following, we describe the RECOMMENDED algorithms for the 658 first and second step. Based on the implementation, different 659 algorithms MAY be adopted. However, note that the same algorithms 660 are used by the 1-D parity codes, regardless of whether the FEC is 661 applied over a column or a row. The 2-D parity codes, on the other 662 hand, usually require multiple iterations of the procedures described 663 here. This iterative decoding algorithm is further explained in 664 Section 6.3.4. 666 6.3.1. Associating the Source and Repair Packets 668 The first step is associating the source and repair packets. By 669 virtue of the I bit in the FEC header, each repair packet is 670 indicated whether it is a column or row-FEC packet. In addition, the 671 SN base field in the FEC header shows the lowest sequence number of 672 the source packets that form the particular column or row. Finally, 673 the information of how many source packets are included in each 674 column or row is available from the Increment and NA fields in the 675 FEC header and from the FEC Framework Configuration Information. 676 This set of information uniquely identifies all of the source packets 677 associated with a given repair packet. 679 Mathematically, for any received repair packet, p*, we can determine 680 the sequence numbers of the source packets that are protected by this 681 repair packet as follows: 683 p*_snb + i * Increment 685 where p*_snb denotes the value indicated in the SN base field of p*, 686 and 688 0 <= i < NA 690 We denote the set of the source packets associated with a repair 691 packet by the set T. Note that in a source block whose size is L 692 columns by D rows, set T includes D source packets plus one repair 693 packet for the FEC applied over a column, and L source packets plus 694 one repair packet for the FEC applied over a row. 696 6.3.2. Recovering the RTP Header 698 For a given set T, the procedure for the recovery of the RTP header 699 of the missing packet, whose sequence number is denoted by X, is as 700 follows: 702 1. For each of the source packets that are successfully received in 703 T, compute the 80-bit string by concatenating the first 64 bits 704 of their RTP header and the unsigned network-ordered 16-bit 705 representation of their length in bytes minus 12. 707 2. For the repair packet in T, compute the FEC bit string from the 708 first 80 bits of the FEC header. 710 3. Calculate the recovered bit string as the XOR of the bit strings 711 generated from all source packets in T and the FEC bit string 712 generated from the repair packet in T. 714 4. Create a new packet with the standard 12-byte RTP header and no 715 payload. 717 5. Set the version of the new packet to 2. Skip the first 2 bits 718 in the recovered bit string. 720 6. Set the Padding bit in the new packet to the next bit in the 721 recovered bit string. 723 7. Set the Extension bit in the new packet to the next bit in the 724 recovered bit string. 726 8. Set the CC field to the next 4 bits in the recovered bit string. 728 9. Set the Marker bit in the new packet to the next bit in the 729 recovered bit string. 731 10. Set the Payload type in the new packet to the next 7 bits in the 732 recovered bit string. 734 11. Set the SN field in the new packet to X. Skip the next 16 bits 735 in the recovered bit string. 737 12. Set the TS field in the new packet to the next 32 bits in the 738 recovered bit string. 740 13. Take the next 16 bits of the recovered bit string and set Y to 741 whatever unsigned integer this represents (assuming network- 742 order). Y represents the length of the new packet in bytes 743 minus 12 (for the fixed RTP header), i.e., the sum of the 744 lengths of all the following if present: the CSRC list, 745 extension header, RTP payload, and RTP padding. 747 14. Set the SSRC of the new packet to the SSRC of the media stream 748 it's protecting, i.e., the SSRC of the media stream to which the 749 FEC stream is associated. 751 This procedure recovers the header of an RTP packet up to (and 752 including) the SSRC field. 754 6.3.3. Recovering the RTP Payload 756 Following the recovery of the RTP header, the procedure for the 757 recovery of the RTP payload is as follows: 759 1. Append Y bytes to the new packet. 761 2. For each of the source packets that are successfully received in 762 T, compute the bit string from the Y octets of data starting with 763 the 13th octet of the packet. If any of the bit strings 764 generated from the source packets has a length shorter than Y, 765 pad them to that length. The padding of octet 0 MUST be added at 766 the end of the bit string. Note that the information of the 767 first 12 octets are protected by the FEC header. 769 3. For the repair packet in T, compute the FEC bit string from the 770 repair packet payload, i.e., the Y octets of data following the 771 FEC header. 773 4. Calculate the recovered bit string as the XOR of the bit strings 774 generated from all source packets in T and the FEC bit string 775 generated from the repair packet in T. 777 5. Append the recovered bit string (Y octets) to the new packet 778 generated in Section 6.3.2. 780 6.3.4. Iterative Decoding Algorithm for the 2-D Parity Codes 782 TBC. 784 7. SDP Examples 786 Editor's note: This section should provide SDP [RFC4566] examples 787 with different set of configurations. The SDP elements for FEC 788 Framework are introduced in [I-D.ietf-fecframe-sdp-elements]. 789 Current examples use [RFC4756] for grouping source and repair flows 790 together in SDP. However, the examples should be updated, in case 791 new grouping semantics will be introduced 792 [I-D.begen-mmusic-fec-grouping-issues] in MMUSIC WG. 794 8. Congestion Control Considerations 796 For the general congestion control considerations related to the use 797 of FEC, refer to [I-D.ietf-fecframe-framework]. 799 Editor's note: Additional congestion control considerations 800 regarding the use of 2-D parity codes should be added here. 802 9. Security Considerations 804 For the general security considerations related to the use of FEC, 805 refer to [I-D.ietf-fecframe-framework]. 807 10. IANA Considerations 809 10.1. Registration of FEC Encoding ID 811 The value of FEC Encoding ID is subject to IANA registration. For 812 general guidelines on IANA considerations as they apply to this 813 document, see [I-D.ietf-fecframe-framework]. 815 This document assigns the Fully-Specified FEC Encoding ID TBD under 816 the ietf:fecframe:fec:encoding name-space to TBD. 818 10.2. Registration of audio/2dparityfec 820 TBC. 822 10.3. Registration of video/2dparityfec 824 TBC. 826 10.4. Registration of text/2dparityfec 828 TBC. 830 10.5. Registration of application/2dparityfec 832 TBC. 834 11. Acknowledgments 836 A major part of this document is borrowed from [RFC5109]. Thus, the 837 authors would like to thank the editor of [RFC5109] and those who 838 contributed to [RFC5109]. 840 The authors would also like to thank the FEC Framework Design Team 841 for their inputs, suggestions and contributions. 843 12. References 844 12.1. Normative References 846 [I-D.ietf-fecframe-framework] 847 Watson, M., "Forward Error Correction (FEC) Framework", 848 draft-ietf-fecframe-framework-01 (work in progress), 849 November 2007. 851 [I-D.ietf-fecframe-sdp-elements] 852 Begen, A., "SDP Elements for FEC Framework", 853 draft-ietf-fecframe-sdp-elements-00 (work in progress), 854 February 2008. 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, March 1997. 859 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 860 Jacobson, "RTP: A Transport Protocol for Real-Time 861 Applications", STD 64, RFC 3550, July 2003. 863 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 864 Description Protocol", RFC 4566, July 2006. 866 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 867 Session Description Protocol", RFC 4756, November 2006. 869 [I-D.begen-mmusic-fec-grouping-issues] 870 Begen, A., "FEC Grouping Issues in Session Description 871 Protocol", draft-begen-mmusic-fec-grouping-issues-00 (work 872 in progress), February 2008. 874 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 875 Correction", RFC 5109, December 2007. 877 12.2. Informative References 879 [SMPTE2022-1] 880 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 881 Video/Audio Transport Over IP Networks", 2007. 883 Authors' Addresses 885 Ali Begen 886 Cisco Systems 887 170 West Tasman Drive 888 San Jose, CA 95134 889 USA 891 Email: abegen@cisco.com 893 Rajiv Asati 894 Cisco Systems 895 7025-6 Kit Creek Road PO Box 14987 896 RTP, NC 27709 897 USA 899 Email: rajiva@cisco.com 901 Full Copyright Statement 903 Copyright (C) The IETF Trust (2008). 905 This document is subject to the rights, licenses and restrictions 906 contained in BCP 78, and except as set forth therein, the authors 907 retain all their rights. 909 This document and the information contained herein are provided on an 910 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 911 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 912 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 913 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 914 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 915 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 917 Intellectual Property 919 The IETF takes no position regarding the validity or scope of any 920 Intellectual Property Rights or other rights that might be claimed to 921 pertain to the implementation or use of the technology described in 922 this document or the extent to which any license under such rights 923 might or might not be available; nor does it represent that it has 924 made any independent effort to identify any such rights. Information 925 on the procedures with respect to rights in RFC documents can be 926 found in BCP 78 and BCP 79. 928 Copies of IPR disclosures made to the IETF Secretariat and any 929 assurances of licenses to be made available, or the result of an 930 attempt made to obtain a general license or permission for the use of 931 such proprietary rights by implementers or users of this 932 specification can be obtained from the IETF on-line IPR repository at 933 http://www.ietf.org/ipr. 935 The IETF invites any interested party to bring to its attention any 936 copyrights, patents or patent applications, or other proprietary 937 rights that may cover technology that may be required to implement 938 this standard. Please address the information to the IETF at 939 ietf-ipr@ietf.org. 941 Acknowledgment 943 Funding for the RFC Editor function is provided by the IETF 944 Administrative Support Activity (IASA).