idnits 2.17.1 draft-begen-fecframe-interleaved-fec-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 1087. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1111. 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 (July 7, 2008) is 5772 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) -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3009 (Obsoleted by RFC 5109) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track July 7, 2008 5 Expires: January 8, 2009 7 1-D Interleaved Parity FEC Scheme for FEC Framework 8 draft-begen-fecframe-interleaved-fec-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 January 8, 2009. 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) interleaved parity code 43 and its application to reliable delivery of media streams in the 44 context of FEC Framework. The 1-D interleaved parity code is a 45 systematic code, where a number of repair symbols are generated from 46 a set of source symbols and sent in one or more repair flows in 47 addition to the source symbols that are sent to the receiver(s) 48 within a source flow. The 1-D interleaved parity code offers a good 49 protection against bursty packet losses at a cost of decent 50 complexity. This document extends the FEC header defined in RFC 2733 51 and registers a new RTP payload format for the FEC that is generated 52 by the 1-D interleaved parity code from a source media encapsulated 53 in RTP. This new payload format is compatible with and used as a 54 part of the DVB Application-layer FEC Specification. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.2. Overhead Computation . . . . . . . . . . . . . . . . . . . 8 61 1.3. Relation to Existing Specifications . . . . . . . . . . . 8 62 1.3.1. RFC 2733 and RFC 3009 . . . . . . . . . . . . . . . . 8 63 1.3.2. SMPTE 2022-1 . . . . . . . . . . . . . . . . . . . . . 8 64 1.3.3. ETSI TS 102 034 . . . . . . . . . . . . . . . . . . . 9 65 1.4. Document Outline . . . . . . . . . . . . . . . . . . . . . 9 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 10 67 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 10 68 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 11 71 4. Formats and Codes . . . . . . . . . . . . . . . . . . . . . . 11 72 4.1. Source FEC Payload ID . . . . . . . . . . . . . . . . . . 11 73 4.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 12 74 4.3. FEC Framework Configuration Information . . . . . . . . . 15 75 4.3.1. Mandatory Elements . . . . . . . . . . . . . . . . . . 16 76 4.3.2. Scheme-Specific Elements . . . . . . . . . . . . . . . 16 77 4.3.3. Encoding Format . . . . . . . . . . . . . . . . . . . 16 78 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 5.1. Configuration Information Signaling Procedures . . . . . . 17 80 5.2. Content Delivery Protocol Requirements . . . . . . . . . . 17 81 5.3. Determination of Source Block Size and Repair Window . . . 17 82 6. 1-D Interleaved Parity FEC Code Specification . . . . . . . . 17 83 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 18 85 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 20 86 6.3.1. Associating the Source and Repair Packets . . . . . . 20 87 6.3.2. Recovering the RTP Header and Payload . . . . . . . . 21 88 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 22 89 8. Congestion Control Considerations . . . . . . . . . . . . . . 23 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 10.1. Registration of FEC Encoding ID . . . . . . . . . . . . . 23 93 10.2. Registration of audio/1d-interleaved-parityfec . . . . . . 24 94 10.3. Registration of video/1d-interleaved-parityfec . . . . . . 24 95 10.4. Registration of text/1d-interleaved-parityfec . . . . . . 24 96 10.5. Registration of application/1d-interleaved-parityfec . . . 24 97 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 100 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 Intellectual Property and Copyright Statements . . . . . . . . . . 26 104 1. Introduction 106 This document extends the FEC header defined in [RFC2733] and 107 registers a new RTP payload format for the FEC that is generated by 108 the 1-D interleaved parity code from a source media encapsulated in 109 RTP [RFC3550]. The type of the protected source media can be audio, 110 video, text or application. The FEC data is generated by an instance 111 of the FEC Framework, which is configured by the FEC Framework 112 Configuration Information. This configuration information, which is 113 communicated through out-of-band means, plus the information 114 contained in the payload format let the receiver(s) know the exact 115 associations/relationships between the source and repair packets. 117 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 118 to generate the repair symbols. In a nutshell, the following steps 119 take place: 121 o The sender determines a set of source packets to be protected 122 together based on the FEC Framework Configuration Information. 124 o The sender applies the XOR operation on the source symbols to 125 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. Block diagrams for the systematic parity FEC encoder 137 and decoder are sketched in Figure 1 and Figure 2, respectively. 139 +------------+ 140 +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 141 +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 142 | Encoder | 143 | (Sender) | --> +==+ +==+ 144 +------------+ +==+ +==+ 146 Source Packet: +--+ Repair Packet: +==+ 147 +--+ +==+ 149 Figure 1: Block diagram for systematic parity FEC encoder 151 +------------+ 152 +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 153 +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 154 | Decoder | 155 +==+ +==+ --> | (Receiver) | 156 +==+ +==+ +------------+ 158 Source Packet: +--+ Repair Packet: +==+ Lost Packet: X 159 +--+ +==+ 161 Figure 2: Block diagram for systematic parity FEC decoder 163 Suppose that we have a group of D x L source packets that have 164 sequence numbers starting from 1 running to D x L. If we apply the 165 XOR operation to the group of the source packets whose sequence 166 numbers are L apart from each other as sketched in Figure 3, we 167 generate L repair packets. This process is referred to as 1-D 168 interleaved FEC protection, and the resulting L repair packets are 169 referred to as interleaved (or column) FEC packets. 171 +-------------+ +-------------+ +-------------+ +-------+ 172 | S_1 | | S_2 | | S3 | ... | S_L | 173 | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | 174 | . | | . | | | | | 175 | . | | . | | | | | 176 | . | | . | | | | | 177 | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | 178 +-------------+ +-------------+ +-------------+ +-------+ 179 + + + + 180 ------------- ------------- ------------- ------- 181 | XOR | | XOR | | XOR | ... | XOR | 182 ------------- ------------- ------------- ------- 183 = = = = 184 +===+ +===+ +===+ +===+ 185 |C_1| |C_2| |C_3| ... |C_L| 186 +===+ +===+ +===+ +===+ 188 Figure 3: Generating interleaved (column) FEC packets 190 In Figure 3, S_n and C_m denote the source packet with a sequence 191 number n and the interleaved (column) FEC packet with a sequence 192 number m, respectively. 194 1.1. Use Cases 196 We generate one interleaved repair packet out of D non-consecutive 197 source packets. This repair packet can provide a full recovery of 198 the missing information if there is only one packet missing among the 199 corresponding source packets. This implies that 1-D interleaved FEC 200 protection performs well under bursty loss conditions provided that L 201 is chosen large enough, i.e., L-packet duration SHOULD NOT be shorter 202 than the duration of the burst that is intended to be repaired. 204 For example, consider the scenario depicted in Figure 4 where the 205 sender generates interleaved FEC packets and a bursty loss hits the 206 source packets. Since the number of columns is larger than the 207 number of packets lost due to the bursty loss, the repair operation 208 succeeds. 210 +---+ 211 | 1 | X X X 212 +---+ 214 +---+ +---+ +---+ +---+ 215 | 5 | | 6 | | 7 | | 8 | 216 +---+ +---+ +---+ +---+ 218 +---+ +---+ +---+ +---+ 219 | 9 | | 10| | 11| | 12| 220 +---+ +---+ +---+ +---+ 222 +===+ +===+ +===+ +===+ 223 |C_1| |C_2| |C_3| |C_4| 224 +===+ +===+ +===+ +===+ 226 Figure 4: Example scenario where 1-D interleaved FEC protection 227 succeeds error recovery 229 The sender may generate interleaved FEC packets to combat with the 230 bursty packet losses. However, two or more random packet losses may 231 hit the source and repair packets in the same column. In that case, 232 the repair operation fails. This is illustrated in Figure 5. Note 233 that it is possible that two or more bursty losses may occur in the 234 same source block, in which case interleaved FEC packets may still 235 fail to recover the lost data. 237 +---+ +---+ +---+ 238 | 1 | X | 3 | | 4 | 239 +---+ +---+ +---+ 241 +---+ +---+ +---+ 242 | 5 | X | 7 | | 8 | 243 +---+ +---+ +---+ 245 +---+ +---+ +---+ +---+ 246 | 9 | | 10| | 11| | 12| 247 +---+ +---+ +---+ +---+ 249 +===+ +===+ +===+ +===+ 250 |C_1| |C_2| |C_3| |C_4| 251 +===+ +===+ +===+ +===+ 253 Figure 5: Example scenario where 1-D interleaved FEC protection fails 254 error recovery 256 1.2. Overhead Computation 258 The overhead is defined as the ratio of the number of bytes belonging 259 to the repair packets to the number of bytes belonging to the 260 protected source packets. 262 Assuming that each repair packet carries an equal number of bytes 263 carried by a source packet, we can compute the overhead as follows: 265 Overhead = 1/D 267 where D is the number of rows in the source block. 269 1.3. Relation to Existing Specifications 271 This section discusses the relation of the current specification to 272 other existing specifications. 274 1.3.1. RFC 2733 and RFC 3009 276 The current specification extends the FEC header defined in [RFC2733] 277 and registers a new RTP payload format. This new payload format is 278 not backward compatible with the payload format that was registered 279 by [RFC3009]. 281 1.3.2. SMPTE 2022-1 283 In 2007, the Society of Motion Picture and Television Engineers 284 (SMPTE) - Technology Committee N26 on File Management and Networking 285 Technology - decided to revise the Pro-MPEG Code of Practice (CoP) #3 286 Release 2 specification, which (was initially produced by the Pro- 287 MPEG Forum in 2004) discussed the several aspects of the transmission 288 of MPEG-2 transport streams over IP networks. The new SMPTE 289 specification is referred to as [SMPTE2022-1]. 291 The Pro-MPEG CoP #3 r2 document was originally based on [RFC2733]. 292 SMPTE revised the document by extending the FEC header (by setting 293 the E bit) proposed in [RFC2733]. This extended header offers some 294 improvements. 296 For example, instead of utilizing the bitmap field used in [RFC2733], 297 [SMPTE2022-1] introduces separate fields to convey the number of rows 298 (D) and columns (L) of the source block as well as the type of the 299 repair packet (i.e., whether the repair packet is an interleaved FEC 300 packet computed over a column or a non-interleaved FEC packet 301 computed over a row). These fields plus the base sequence number 302 allow the receiver side to establish the associations between the 303 source and repair packets. Note that although the bitmap field is 304 not utilized, the FEC header of [SMPTE2022-1] inherently carries over 305 the bitmap field from [RFC2733]. 307 On the other hand, some parts of [SMPTE2022-1] are not in compliant 308 with RTP [RFC3550]. For example, [SMPTE2022-1] sets the SSRC field 309 to zero and does not use the timestamp field in the RTP headers of 310 the repair packets (Receivers ignore the timestamps of the repair 311 packets). Furthermore, [SMPTE2022-1] also sets the CC field in the 312 RTP header to zero and does not allow any Contributing Source (CSRC) 313 entry in the RTP header. 315 The current document adopts the extended FEC header of [SMPTE2022-1] 316 and registers a new RTP payload format. At the same time, this 317 document fixes the parts of [SMPTE2022-1] that are not in compliant 318 with RTP [RFC3550]. 320 1.3.3. ETSI TS 102 034 322 In 2007, the Digital Video Broadcasting (DVB) consortium published a 323 technical specification [DVB-AL-FEC] through European 324 Telecommunications Standards Institute (ETSI). This specification 325 covers several areas related to the transmission of MPEG-2 transport 326 stream-based services over IP networks. 328 The Annex E of [DVB-AL-FEC] defines an optional protocol for 329 Application-layer FEC (AL-FEC) protection of streaming media for 330 DVB-IP services carried over RTP [RFC3550] transport. AL-FEC 331 protocol uses two layers for protection: a base layer that is 332 produced by a packet-based interleaved parity code, and an 333 enhancement layer that is produced by a Raptor code. While the use 334 of the enhancement layer is optional, the use of the base layer is 335 mandatory wherever AL-FEC is used. 337 The interleaved parity code that is used in the base layer is a 338 subset of [SMPTE2022-1]. In particular, AL-FEC base layer uses the 339 1-D interleaved FEC protection only from [SMPTE2022-1]. The new RTP 340 payload format that is defined and registered in this document is 341 compatible with the AL-FEC base layer. 343 1.4. Document Outline 345 This FEC scheme specification follows the document structure defined 346 in [I-D.ietf-fecframe-framework]. 348 2. Requirements Notation 350 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 351 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 352 document are to be interpreted as described in [RFC2119]. 354 3. Definitions, Notations and Abbreviations 356 The definitions, notations and abbreviations commonly used in this 357 document are summarized in this section. 359 3.1. Definitions 361 This document uses the following definitions. For further 362 definitions that apply to FEC Framework in general, see 363 [I-D.ietf-fecframe-framework]. 365 Source Flow: The packet flow(s) carrying the source data and to 366 which FEC protection is to be applied. 368 Repair Flow: The packet flow(s) carrying the repair data. 370 Symbol: A unit of data. Its size, in bytes, is referred to as the 371 symbol size. 373 Source Symbol: The smallest unit of data used during the encoding 374 process. 376 Repair Symbol: Repair symbols are generated from the source symbols. 378 Source Packet: Data packets that contain only source symbols. 380 Repair Packet: Data packets that contain only repair symbols. 382 Source Block: A block of source symbols that are considered together 383 in the encoding process. 385 FEC Framework Configuration Information: Information that controls 386 the operation of the FEC Framework. Each FEC Framework instance has 387 its own configuration information. 389 FEC Payload ID: Information that identifies the contents of a packet 390 with respect to the FEC scheme. 392 Source FEC Payload ID: An FEC Payload ID specifically used with 393 source packets. 395 Repair FEC Payload ID: An FEC Payload ID specifically used with 396 repair packets. 398 3.2. Notations 400 o L: Number of columns of the source block. 402 o D: Number of rows of the source block. 404 3.3. Abbreviations 406 o XOR: Bitwise exclusive OR operation. 407 0 XOR 0 = 0 408 0 XOR 1 = 1 409 1 XOR 0 = 1 410 1 XOR 1 = 0 412 o FSSI: FEC-Scheme-Specific Information. 414 o SS-FSSI: Sender-Side FEC-Scheme-Specific Information. 416 o RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. 418 4. Formats and Codes 420 This section defines the formats of the source and repair packets as 421 well as the configuration information for the FEC scheme. 423 4.1. Source FEC Payload ID 425 The source packets MUST contain the information that identifies the 426 source block and the position within the source block occupied by the 427 packet. This information is referred to as the Source FEC Payload 428 ID. In some cases, Source FEC Payload ID may be inferred from the 429 fields already existing in the packet. In other cases, however, the 430 required information is explicitly encoded into a specific field 431 called Explicit Source FEC Payload ID, which is appended to the end 432 of the source packets [I-D.ietf-fecframe-framework]. 434 Since the source packets that are carried within an RTP stream 435 already contain unique sequence numbers in their RTP headers 436 [RFC3550], the Source FEC Payload ID can be derived in a 437 straightforward manner. Thus, there is no need to use the Explicit 438 Source FEC Payload ID field. The primary advantage of this approach 439 is that the source packets are not modified in anyway. This provides 440 backward compatibility for the receivers that do not support FEC at 441 all. In multicast scenarios, this backward compatibility becomes 442 quite useful as it allows the non-FEC-capable receivers to receive 443 and interpret the source packets. 445 The derivation of the Source FEC Payload ID from the RTP sequence 446 number is discussed in Section 5. 448 Editor's note: This section should specify the additional 449 requirements (if any) that are relevant to grouping multiple source 450 flows together before applying FEC protection. 452 4.2. Repair FEC Payload ID 454 The repair packets MUST contain information that identifies the 455 source block they pertain to and the relationship between the 456 contained repair symbols and the original source block. This 457 information is referred to as the Repair FEC Payload ID. This 458 information MUST be encoded into a specific field between the 459 transport header and the repair symbols within a repair packet, as 460 shown in Figure 7 [I-D.ietf-fecframe-framework]. 462 +------------------------------+ 463 | IP Header | 464 +------------------------------+ 465 | Transport Header | 466 +------------------------------+ 467 | Repair FEC Payload ID | 468 +------------------------------+ 469 | Repair Symbols | 470 +------------------------------+ 472 Figure 7: Format of repair packets 474 Since the repair packets are carried within an RTP stream, the Repair 475 FEC Payload ID consists of an RTP header and an FEC header. This is 476 shown in Figure 8. 478 +------------------------------+ 479 | IP Header | 480 +------------------------------+ 481 | Transport Header | ,--+------------------------------+ 482 +------------------------------+-' | RTP Header | 483 | Repair FEC Payload ID | +------------------------------+ 484 +------------------------------+-. | FEC Header | 485 | Repair Symbols | `--+------------------------------+ 486 +------------------------------+ 488 Figure 8: Format of Repair FEC Payload ID 490 The RTP header is formatted according to [RFC3550] with some further 491 clarifications listed below: 493 o Version: The version field is set to 2. 495 o Padding (P) Bit: This bit is obtained by applying protection to 496 the corresponding P bits from the RTP headers of the source 497 packets protected by this repair packet. 499 o Extension (X) Bit: This bit is obtained by applying protection to 500 the corresponding X bits from the RTP headers of the source 501 packets protected by this repair packet. However, an RTP header 502 extension is never present in a repair packet, independent of the 503 value of the X bit. 505 o CSRC Count (CC): This field is obtained by applying protection to 506 the corresponding CC values from the RTP headers of the source 507 packets protected by this repair packet. However, a CSRC list is 508 never present in a repair packet, independent of the value of the 509 CC field. 511 o Marker (M) Bit: This bit is obtained by applying protection to 512 the corresponding M bits from the RTP headers of the source 513 packets protected by this repair packet.. 515 o Payload Type: The payload type for the repair packets is 516 determined through the payload format specified in the FEC 517 Framework Configuration Information. Note that this document 518 registers a new payload format for the repair packets (Refer to 519 Section 10 for details). According to [RFC3550], an RTP receiver 520 that cannot recognize a payload type must discard it. This 521 provides backward compatibility. The FEC mechanisms can then be 522 used in a multicast group with mixed FEC-capable and non-FEC- 523 capable receivers. If a non-FEC-capable receiver receives a 524 repair packet, it will not recognize the payload type, and hence, 525 discards the repair packet. 527 o Sequence Number (SN): The sequence number has the standard 528 definition. It MUST be one higher than the sequence number in the 529 previously transmitted repair packet. 531 o Timestamp (TS): The timestamp MUST be set to the timestamp of the 532 source packet whose sequence number is the lowest among the source 533 packets protected by this repair packet. 535 o Synchronization Source (SSRC): The SSRC value SHALL be randomly 536 assigned as suggested by [RFC3550]. This allows the sender to 537 multiplex the source and repair flows on the same port, or 538 multiplex multiple repair flows on a single port. The repair 539 flows SHOULD use the RTCP CNAME field to associate themselves with 540 the source flow. Note that due to the randomness of the SSRC 541 assignments, there is a possibility of SSRC collision. In such 542 cases, the collisions MUST be resolved as described in [RFC3550]. 544 Note that the P bit, X bit, CC field and M bit of the source packets 545 are protected by the corresponding bits/fields in the RTP header of 546 the repair packet. On the other hand, the payload of a repair packet 547 protects the concatenation of the CSRC list, RTP extension, payload 548 and padding of the source RTP packets associated with this repair 549 packet. 551 The FEC header is 16 octets. The format of the FEC header is shown 552 in Figure 9. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | SN base low | Length recovery | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |E| PT recovery | Mask | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | TS recovery | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 |N|D|Type |Index| Offset | NA | SN base ext | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 9: Format of the FEC header 568 The FEC header consists of the following fields: 570 o The SN base low field is used to indicate the lowest sequence 571 number, taking wrap around into account, of those source packets 572 protected by this repair packet. 574 o The Length recovery field is used to determine the length of any 575 recovered packets. 577 o The E bit is the extension flag introduced in [RFC2733] and used 578 to extend the [RFC2733] FEC header. 580 o The PT recovery field is used to determine the payload type of the 581 recovered packets. 583 o The Mask field is not used. 585 o The TS recovery field is used to determine the timestamp of the 586 recovered packets. 588 o The N bit is the extension flag that is reserved for future uses. 590 o The D bit is not used. 592 o The Type field indicates the type of the error-correcting code 593 used. This document defines only one error-correcting code. 595 o The Index field is not used. 597 o The Offset and NA fields are used to indicate the number of 598 columns (L) and rows (D) of the source block, respectively. 600 o The SN base ext field is not used. 602 The details on setting the fields in the FEC header are provided in 603 Section 6.2. 605 It should be noted that a mask-based approach (similar to the one 606 specified in [RFC2733]) may not be very efficient to indicate which 607 source packets in the current source block are associated with a 608 given repair packet. In particular, for the applications that would 609 like to use large source block sizes, the size of the mask that is 610 required to describe the source-repair packet associations may be 611 prohibitively large. Instead, a systematic approach is inherently 612 more efficient. 614 4.3. FEC Framework Configuration Information 616 The FEC Framework defines a minimum set of information that MUST be 617 communicated between the sender and receiver(s) for a proper 618 operation of the FEC scheme. This information is called the FEC 619 Framework Configuration Information. This information specifies how 620 the sender applies protection to the source flow(s) and how the 621 repair flow(s) can be used to recover the lost data. In other words, 622 this information specifies the relationship(s) between the source and 623 repair flows. The FEC Framework requires every FEC Framework 624 instance to provide its own configuration information. 626 From the FEC scheme point of view, the FEC Framework Configuration 627 Information consists of mandatory and scheme-specific elements. We 628 describe these elements below. 630 4.3.1. Mandatory Elements 632 o FEC Encoding ID: The value of the FEC Encoding ID for the fully- 633 specified FEC scheme defined in this document MUST be TBD as 634 assigned by IANA. Refer to Section 10. 636 4.3.2. Scheme-Specific Elements 638 FEC-Scheme-Specific Information (FSSI) includes the information that 639 is specific to the FEC scheme used by the Content Delivery Protocol. 640 FSSI is used to communicate the information that cannot be adequately 641 represented otherwise and is essential for proper FEC encoding and 642 decoding operations. 644 The FSSI is carried in two opaque containers. The first container 645 contains the FSSI required only by the sender. This information is 646 referred to as the Sender-Side FEC-Scheme-Specific Information (SS- 647 FSSI). Rest of the FSSI is referred to as the Receiver-Side FEC- 648 Scheme-Specific Information (RS-FSSI) and carried in the second 649 container. 651 The following parameters are carried in the FEC Scheme-Specific 652 Information element: 654 o L: Number of columns of the source block. L is a positive 655 integer. 657 o D: Number of rows of the source block. D is a positive integer. 659 All of the parameters listed above MUST be included in the FSSI. The 660 parameters L and D are carried within the SS-FSSI container. 662 4.3.3. Encoding Format 664 TBC. 666 5. Procedures 668 This section describes the procedures that are specific to the 1-D 669 interleaved parity FEC scheme. 671 5.1. Configuration Information Signaling Procedures 673 This specification makes use of the signaling protocol to signal the 674 FEC Framework Configuration Information between the sender and 675 receiver(s). This enables the sender and receiver(s) to be in sync 676 with respect to the information needed for the operation of FEC 677 Framework. 679 5.2. Content Delivery Protocol Requirements 681 Content Delivery Protocol (CDP) is a complete application-protocol 682 specification that provides FEC capabilities by making use of the FEC 683 Schemes through the use of FEC Framework defined in 684 [I-D.ietf-fecframe-framework]. 686 The parity FEC encoder and decoder require the following from the 687 CDP: 689 o The size of the source block, namely the number of columns (L) and 690 the number of rows (D). 692 This information is transmitted to the receiver side by the CDP 693 through the FEC Framework Configuration Information. The parity 694 encoder additionally requires: 696 o The data to be protected. 698 The parity encoder provides the following information to the CDP: 700 o An interleaved (column) FEC packet that is generated by applying 701 protection over each column in the current source block. 703 The source packets as well as the repair packets are then transmitted 704 to the receiver(s) by the transport protocol chosen by the CDP. 706 5.3. Determination of Source Block Size and Repair Window 708 TBC. 710 Editor's note: This section should discuss the derivation of the 711 Source FEC Payload ID from the RTP sequence number. 713 6. 1-D Interleaved Parity FEC Code Specification 715 This section provides a complete specification of the 1-D interleaved 716 parity FEC scheme. 718 6.1. Overview 720 The following sections specify the steps involved in generating the 721 repair packets and reconstructing the missing source packets from the 722 repair packets. 724 6.2. Repair Packet Construction 726 The Repair FEC Payload ID consists of an RTP header and an FEC 727 header. The RTP header of an repair packet is formed based on the 728 guidelines given in Section 4.2. 730 The FEC header includes 16 octets. It is constructed by applying the 731 XOR operation on the bit strings that are generated from the 732 individual source packets protected by this particular repair packet. 733 The set of the source packets that are associated with a given repair 734 packet can be computed by the formula given in Section 6.3.1. 736 The bit string is formed for each source packet by concatenating the 737 following fields together in the order specified: 739 o Padding bit (1 bit) (This is the most significant bit of the bit 740 string) 742 o Extension bit (1 bit) 744 o CC field (4 bits) 746 o Marker bit (1 bit) 748 o PT field (7 bits) 750 o Timestamp (32 bits) 752 o Unsigned network-ordered 16-bit representation of the source 753 packet length in bytes minus 12 (for the fixed RTP header), i.e., 754 the sum of the lengths of all the following if present: the CSRC 755 list, header extension, RTP payload, and RTP padding (16 bits) 757 o If CC is nonzero, the CSRC list (variable length) 759 o If X is 1, the header extension (variable length) 761 o Payload (variable length) 762 o Padding, if present (variable length) 764 Note that if the payload lengths of the source packets are not equal, 765 each shorter packet MUST be padded to the length of the longest 766 packet by adding octet 0's at the end. Due to this possible padding 767 and mandatory FEC header, a repair packet usually has a larger size 768 than the source packets it protects. This may cause problems if the 769 resulting repair packet size exceeds the Maximum Transmission Unit 770 (MTU) size of the path over which the repair flow is sent. 772 By applying the parity operation on the bit strings produced from the 773 source packets, we generate the FEC bit string. Some parts of the 774 RTP header and the FEC header of the repair packet are generated from 775 the FEC bit string as follows: 777 o The first (most significant) bit in the FEC bit string is written 778 into the Padding bit in the RTP header of the repair packet. 780 o The next bit in the FEC bit string is written into the Extension 781 bit in the RTP header of the repair packet. 783 o The next 4 bits of the FEC bit string are written into the CC 784 field in the RTP header of the repair packet. 786 o The next bit of the FEC bit string is written into the Marker bit 787 in the RTP header of the repair packet. 789 o The next 7 bits of the FEC bit string are written into the PT 790 recovery field in the FEC header. 792 o The next 32 bits of the FEC bit string are written into the TS 793 recovery field in the FEC header. 795 o The next 16 bits are written into the Length recovery field in the 796 FEC header. This allows the FEC procedure to be applied even when 797 the lengths of the protected source packets are not identical. 799 o The remaining bits are set to be the payload of the repair packet. 801 The remaining parts of the FEC header are set as follows: 803 o The SN base low field MUST be set to the lowest sequence number, 804 taking wrap around into account, of those source packets protected 805 by this repair packet. 807 o The E bit MUST be set to 1 to extend the [RFC2733] FEC header. 809 o The Mask field SHALL be set to 0 and ignored by the receiver. 811 o The N bit SHALL be set to 0 and ignored by the receiver. 813 o The D bit SHALL be set to 0 and ignored by the receiver. 815 o The Type field MUST be set to 0. 817 o The Index field SHALL be set to 0 and ignored by the receiver. 819 o The Offset field MUST be set to the number of columns of the 820 source block (L). 822 o The NA field MUST be set to the number of rows of the source block 823 (D). 825 o The SN base ext field SHALL be set to 0 and ignored by the 826 receiver. 828 6.3. Source Packet Reconstruction 830 This section describes the recovery procedures that are required to 831 reconstruct the missing packets. The recovery process has two steps. 832 In the first step, the FEC decoder determines which source and repair 833 packets should be used in order to recover a missing packet. In the 834 second step, the decoder recovers the missing packet, which consists 835 of an RTP header and RTP payload. 837 In the following, we describe the RECOMMENDED algorithms for the 838 first and second steps. Based on the implementation, different 839 algorithms MAY be adopted. However, the end result MUST be identical 840 to the one produced by the following algorithms. 842 6.3.1. Associating the Source and Repair Packets 844 The first step is associating the source and repair packets. The SN 845 base low field in the FEC header shows the lowest sequence number of 846 the source packets that form the particular column. In addition, the 847 information of how many source packets are available in each column 848 and row is available from the FEC Framework Configuration 849 Information. This set of information uniquely identifies all of the 850 source packets associated with a given repair packet. 852 Mathematically, for any received repair packet, p*, we can determine 853 the sequence numbers of the source packets that are protected by this 854 repair packet as follows: 856 p*_snb + i * L 858 where p*_snb denotes the value in the SN base low field of p*'s FEC 859 header, L is the number of columns of the source block (conveyed in 860 the Offset field) and 862 0 <= i < D 864 where D is the number of rows of the source block (conveyed in the NA 865 field). 867 We denote the set of the source packets associated with repair packet 868 p* by set T(p*). Note that in a source block whose size is L columns 869 by D rows, set T includes D source packets. Recall that 1-D 870 interleaved FEC protection can fully recover the missing information 871 if there is only source packet is missing in set T. If the repair 872 packet that protects the source packets in set T is missing, or the 873 repair packet is available but two or more source packets are 874 missing, then missing source packets in set T cannot be recovered by 875 1-D interleaved FEC protection. 877 6.3.2. Recovering the RTP Header and Payload 879 For a given set T, the procedure for the recovery of the RTP header 880 of the missing packet, whose sequence number is denoted by SEQNUM, is 881 as follows: 883 1. For each of the source packets that are successfully received in 884 set T, compute the bit string as described in Section 6.2. 886 2. For the repair packet associated with set T, compute the bit 887 string in the same fashion except use the PT recovery field 888 instead of the PT field and TS recovery field instead of the 889 Timestamp field, and set the CSRC list, header extension, and 890 padding to null regardless of the values of the X bit and CC 891 field. 893 3. If any of the bit strings generated from the source packets are 894 shorter than the bit string generated from the repair packet, 895 pad them to be the same length as the bit string generated from 896 the repair packet. For padding, the padding of octet 0 MUST be 897 added at the end of the bit string. 899 4. Calculate the recovered bit string as the XOR of the bit strings 900 generated from all source packets in set T and the FEC bit 901 string generated from the repair packet associated with set T. 903 5. Create a new packet with the standard 12-byte RTP header and no 904 payload. 906 6. Set the version of the new packet to 2. 908 7. Set the Padding bit in the new packet to the first bit in the 909 recovered bit string. 911 8. Set the Extension bit in the new packet to the next bit in the 912 recovered bit string. 914 9. Set the CC field to the next 4 bits in the recovered bit string. 916 10. Set the Marker bit in the new packet to the next bit in the 917 recovered bit string. 919 11. Set the Payload type in the new packet to the next 7 bits in the 920 recovered bit string. 922 12. Set the SN field in the new packet to SEQNUM. 924 13. Set the TS field in the new packet to the next 32 bits in the 925 recovered bit string. 927 14. Take the next 16 bits of the recovered bit string and set Y to 928 whatever unsigned integer this represents (assuming network- 929 order). Take Y bytes from the recovered bit string and append 930 them to the new packet. Y represents the length of the new 931 packet in bytes minus 12 (for the fixed RTP header), i.e., the 932 sum of the lengths of all the following if present: the CSRC 933 list, header extension, RTP payload and RTP padding. 935 15. Set the SSRC of the new packet to the SSRC of the source RTP 936 stream. 938 This procedure completely recovers both the header and payload of an 939 RTP packet. 941 7. Session Description Protocol (SDP) Signaling 943 This section provides an SDP [RFC4566] example. The following 944 example uses the SDP elements for FEC Framework, which were 945 introduced in [I-D.ietf-fecframe-sdp-elements], and the FEC grouping 946 semantics [RFC4756]. 948 Editor's note: No FEC Encoding ID has been registered with IANA for 949 the FEC scheme proposed in this document. In the example below, an 950 FEC Encoding ID of zero will be used. 952 In this example, we have one source video stream (mid:S1) and one FEC 953 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 954 S1 R1" line. The source and repair streams are sent to the same port 955 on different multicast groups. The repair window is set to 200 ms. 957 v=0 958 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 959 s=Interleaved Parity FEC Example 960 t=0 0 961 a=group:FEC S1 R1 962 m=video 30000 RTP/AVP 100 963 c=IN IP4 224.1.1.1/127 964 a=rtpmap:100 MP2T/90000 965 a=fec-source-flow: id=0 966 a=mid:S1 967 m=application 30000 RTP/AVP 110 968 c=IN IP4 224.1.2.1/127 969 a=rtpmap:110 1d-interleaved-parityfec/90000 970 a=fec-repair-flow: encoding-id=0; ss-fssi=L:5 D:10 971 a=repair-window: 200 972 a=mid:R1 974 8. Congestion Control Considerations 976 For the general congestion control considerations related to the use 977 of FEC, refer to [I-D.ietf-fecframe-framework]. 979 9. Security Considerations 981 For the general security considerations related to the use of FEC, 982 refer to [I-D.ietf-fecframe-framework]. 984 10. IANA Considerations 986 10.1. Registration of FEC Encoding ID 988 The value of FEC Encoding ID is subject to IANA registration. For 989 general guidelines on IANA considerations as they apply to this 990 document, refer to [I-D.ietf-fecframe-framework]. 992 This document assigns the Fully-Specified FEC Encoding ID TBD under 993 the ietf:fecframe:fec:encoding name-space to "1-D Interleaved Parity 994 FEC Code." 996 10.2. Registration of audio/1d-interleaved-parityfec 998 TBC. 1000 10.3. Registration of video/1d-interleaved-parityfec 1002 TBC. 1004 10.4. Registration of text/1d-interleaved-parityfec 1006 TBC. 1008 10.5. Registration of application/1d-interleaved-parityfec 1010 TBC. 1012 11. Acknowledgments 1014 A major part of this document is borrowed from [RFC2733] and 1015 [SMPTE2022-1]. Thus, the author would like to thank the authors and 1016 editors of these earlier specifications. 1018 12. References 1020 12.1. Normative References 1022 [I-D.ietf-fecframe-framework] 1023 Watson, M., "Forward Error Correction (FEC) Framework", 1024 draft-ietf-fecframe-framework-01 (work in progress), 1025 November 2007. 1027 [I-D.ietf-fecframe-sdp-elements] 1028 Begen, A., "SDP Elements for FEC Framework", 1029 draft-ietf-fecframe-sdp-elements-00 (work in progress), 1030 February 2008. 1032 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1033 Requirement Levels", BCP 14, RFC 2119, March 1997. 1035 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1036 Jacobson, "RTP: A Transport Protocol for Real-Time 1037 Applications", STD 64, RFC 3550, July 2003. 1039 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1040 Description Protocol", RFC 4566, July 2006. 1042 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 1043 Session Description Protocol", RFC 4756, November 2006. 1045 12.2. Informative References 1047 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1048 for Generic Forward Error Correction", RFC 2733, 1049 December 1999. 1051 [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of 1052 parityfec MIME types", RFC 3009, November 2000. 1054 [DVB-AL-FEC] 1055 DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1), 1056 "Transport of MPEG 2 Transport Stream (TS) Based DVB 1057 Services over IP Based Networks", March 2007. 1059 [SMPTE2022-1] 1060 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 1061 Video/Audio Transport over IP Networks", 2007. 1063 Author's Address 1065 Ali Begen 1066 Cisco Systems 1067 170 West Tasman Drive 1068 San Jose, CA 95134 1069 USA 1071 Email: abegen@cisco.com 1073 Full Copyright Statement 1075 Copyright (C) The IETF Trust (2008). 1077 This document is subject to the rights, licenses and restrictions 1078 contained in BCP 78, and except as set forth therein, the authors 1079 retain all their rights. 1081 This document and the information contained herein are provided on an 1082 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1083 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1084 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1085 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1086 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1087 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1089 Intellectual Property 1091 The IETF takes no position regarding the validity or scope of any 1092 Intellectual Property Rights or other rights that might be claimed to 1093 pertain to the implementation or use of the technology described in 1094 this document or the extent to which any license under such rights 1095 might or might not be available; nor does it represent that it has 1096 made any independent effort to identify any such rights. Information 1097 on the procedures with respect to rights in RFC documents can be 1098 found in BCP 78 and BCP 79. 1100 Copies of IPR disclosures made to the IETF Secretariat and any 1101 assurances of licenses to be made available, or the result of an 1102 attempt made to obtain a general license or permission for the use of 1103 such proprietary rights by implementers or users of this 1104 specification can be obtained from the IETF on-line IPR repository at 1105 http://www.ietf.org/ipr. 1107 The IETF invites any interested party to bring to its attention any 1108 copyrights, patents or patent applications, or other proprietary 1109 rights that may cover technology that may be required to implement 1110 this standard. Please address the information to the IETF at 1111 ietf-ipr@ietf.org. 1113 Acknowledgment 1115 Funding for the RFC Editor function is provided by the IETF 1116 Administrative Support Activity (IASA).