idnits 2.17.1 draft-ietf-fecframe-interleaved-fec-scheme-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2010) is 5211 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) == Missing Reference: 'RFCXXXX' is mentioned on line 842, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-rfc4756bis-05 ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3009 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft Cisco 4 Intended status: Standards Track January 12, 2010 5 Expires: July 16, 2010 7 RTP Payload Format for 1-D Interleaved Parity FEC 8 draft-ietf-fecframe-interleaved-fec-scheme-09 10 Abstract 12 This document defines a new RTP payload format for the Forward Error 13 Correction (FEC) that is generated by the 1-D interleaved parity code 14 from a source media encapsulated in RTP. The 1-D interleaved parity 15 code is a systematic code, where a number of repair symbols are 16 generated from a set of source symbols and sent in a repair flow 17 separate from the source flow that carries the source symbols. The 18 1-D interleaved parity code offers a good protection against bursty 19 packet losses at a cost of reasonable complexity. The new payload 20 format defined in this document should only be used (with some 21 exceptions) as a part of the DVB-IPTV Application-layer FEC 22 specification. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on July 16, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1.2. Overhead Computation . . . . . . . . . . . . . . . . . . 8 66 1.3. Relation to Existing Specifications . . . . . . . . . . . 8 67 1.3.1. RFC 2733 and RFC 3009 . . . . . . . . . . . . . . . . 8 68 1.3.2. SMPTE 2022-1 . . . . . . . . . . . . . . . . . . . . . 8 69 1.3.3. ETSI TS 102 034 . . . . . . . . . . . . . . . . . . . 9 70 1.4. Scope of the Payload Format . . . . . . . . . . . . . . . 10 71 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 10 72 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 10 73 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 11 77 4.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . 11 78 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15 79 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 15 80 5.1.1. Registration of audio/1d-interleaved-parityfec . . . . 15 81 5.1.2. Registration of video/1d-interleaved-parityfec . . . . 16 82 5.1.3. Registration of text/1d-interleaved-parityfec . . . . 18 83 5.1.4. Registration of 84 application/1d-interleaved-parityfec . . . . . . . . . 19 85 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 20 86 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 21 87 5.2.2. Declarative Considerations . . . . . . . . . . . . . . 21 88 6. Protection and Recovery Procedures . . . . . . . . . . . . . . 22 89 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 90 6.2. Repair Packet Construction . . . . . . . . . . . . . . . 22 91 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 24 92 6.3.1. Associating the Source and Repair Packets . . . . . . 24 93 6.3.2. Recovering the RTP Header and Payload . . . . . . . . 25 94 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 27 95 8. Congestion Control Considerations . . . . . . . . . . . . . . 27 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 99 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 12.1. draft-ietf-fecframe-interleaved-fec-scheme-09 . . . . . . 29 101 12.2. draft-ietf-fecframe-interleaved-fec-scheme-08 . . . . . . 29 102 12.3. draft-ietf-fecframe-interleaved-fec-scheme-07 . . . . . . 29 103 12.4. draft-ietf-fecframe-interleaved-fec-scheme-06 . . . . . . 29 104 12.5. draft-ietf-fecframe-interleaved-fec-scheme-05 . . . . . . 30 105 12.6. draft-ietf-fecframe-interleaved-fec-scheme-04 . . . . . . 30 106 12.7. draft-ietf-fecframe-interleaved-fec-scheme-03 . . . . . . 30 107 12.8. draft-ietf-fecframe-interleaved-fec-scheme-02 . . . . . . 30 108 12.9. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 30 109 12.10. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 30 110 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 112 13.2. Informative References . . . . . . . . . . . . . . . . . 31 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 115 1. Introduction 117 This document extends the Forward Error Correction (FEC) header 118 defined in [RFC2733] and uses this new FEC header for the FEC that is 119 generated by the 1-D interleaved parity code from a source media 120 encapsulated in RTP [RFC3550]. The resulting new RTP payload format 121 is registered by this document. 123 The type of the source media protected by the 1-D interleaved parity 124 code can be audio, video, text or application. The FEC data are 125 generated according to the media type parameters that are 126 communicated through out-of-band means. The associations/ 127 relationships between the source and repair flows are also 128 communicated through out-of-band means. 130 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 131 to generate the repair symbols. In a nutshell, the following steps 132 take place: 134 1. The sender determines a set of source packets to be protected 135 together based on the media type parameters. 137 2. The sender applies the XOR operation on the source symbols to 138 generate the required number of repair symbols. 140 3. The sender packetizes the repair symbols and sends the repair 141 packet(s) along with the source packets to the receiver(s) (in 142 different flows). The repair packets MAY be sent proactively or 143 on-demand. 145 Note that the source and repair packets belong to different source 146 and repair flows, and the sender needs to provide a way for the 147 receivers to demultiplex them, even in the case they are sent in the 148 same transport flow (i.e., same source/destination address/port with 149 UDP). This is required to offer backward compatibility (See 150 Section 4). At the receiver side, if all of the source packets are 151 successfully received, there is no need for FEC recovery and the 152 repair packets are discarded. However, if there are missing source 153 packets, the repair packets can be used to recover the missing 154 information. Block diagrams for the systematic parity FEC encoder 155 and decoder are sketched in Figure 1 and Figure 2, respectively. 157 +------------+ 158 +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 159 +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 160 | Encoder | 161 | (Sender) | --> +==+ +==+ 162 +------------+ +==+ +==+ 164 Source Packet: +--+ Repair Packet: +==+ 165 +--+ +==+ 167 Figure 1: Block diagram for systematic parity FEC encoder 169 +------------+ 170 +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 171 +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 172 | Decoder | 173 +==+ +==+ --> | (Receiver) | 174 +==+ +==+ +------------+ 176 Source Packet: +--+ Repair Packet: +==+ Lost Packet: X 177 +--+ +==+ 179 Figure 2: Block diagram for systematic parity FEC decoder 181 Suppose that we have a group of D x L source packets that have 182 sequence numbers starting from 1 running to D x L. If we apply the 183 XOR operation to the group of the source packets whose sequence 184 numbers are L apart from each other as sketched in Figure 3, we 185 generate L repair packets. This process is referred to as 1-D 186 interleaved FEC protection, and the resulting L repair packets are 187 referred to as interleaved (or column) FEC packets. 189 +-------------+ +-------------+ +-------------+ +-------+ 190 | S_1 | | S_2 | | S3 | ... | S_L | 191 | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | 192 | . | | . | | | | | 193 | . | | . | | | | | 194 | . | | . | | | | | 195 | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | 196 +-------------+ +-------------+ +-------------+ +-------+ 197 + + + + 198 ------------- ------------- ------------- ------- 199 | XOR | | XOR | | XOR | ... | XOR | 200 ------------- ------------- ------------- ------- 201 = = = = 202 +===+ +===+ +===+ +===+ 203 |C_1| |C_2| |C_3| ... |C_L| 204 +===+ +===+ +===+ +===+ 206 Figure 3: Generating interleaved (column) FEC packets 208 In Figure 3, S_n and C_m denote the source packet with a sequence 209 number n and the interleaved (column) FEC packet with a sequence 210 number m, respectively. 212 1.1. Use Cases 214 We generate one interleaved FEC packet out of D non-consecutive 215 source packets. This repair packet can provide a full recovery of 216 the missing information if there is only one packet missing among the 217 corresponding source packets. This implies that 1-D interleaved FEC 218 protection performs well under bursty loss conditions provided that L 219 is chosen large enough, i.e., L-packet duration should not be shorter 220 than the duration of the burst that is intended to be repaired. 222 For example, consider the scenario depicted in Figure 4 where the 223 sender generates interleaved FEC packets and a bursty loss hits the 224 source packets. Since the number of columns is larger than the 225 number of packets lost due to the bursty loss, the repair operation 226 succeeds. 228 +---+ 229 | 1 | X X X 230 +---+ 232 +---+ +---+ +---+ +---+ 233 | 5 | | 6 | | 7 | | 8 | 234 +---+ +---+ +---+ +---+ 236 +---+ +---+ +---+ +---+ 237 | 9 | | 10| | 11| | 12| 238 +---+ +---+ +---+ +---+ 240 +===+ +===+ +===+ +===+ 241 |C_1| |C_2| |C_3| |C_4| 242 +===+ +===+ +===+ +===+ 244 Figure 4: Example scenario where 1-D interleaved FEC protection 245 succeeds error recovery 247 The sender may generate interleaved FEC packets to combat with the 248 bursty packet losses. However, two or more random packet losses may 249 hit the source and repair packets in the same column. In that case, 250 the repair operation fails. This is illustrated in Figure 5. Note 251 that it is possible that two or more bursty losses may occur in the 252 same source block, in which case interleaved FEC packets may still 253 fail to recover the lost data. 255 +---+ +---+ +---+ 256 | 1 | X | 3 | | 4 | 257 +---+ +---+ +---+ 259 +---+ +---+ +---+ 260 | 5 | X | 7 | | 8 | 261 +---+ +---+ +---+ 263 +---+ +---+ +---+ +---+ 264 | 9 | | 10| | 11| | 12| 265 +---+ +---+ +---+ +---+ 267 +===+ +===+ +===+ +===+ 268 |C_1| |C_2| |C_3| |C_4| 269 +===+ +===+ +===+ +===+ 271 Figure 5: Example scenario where 1-D interleaved FEC protection fails 272 error recovery 274 1.2. Overhead Computation 276 The overhead is defined as the ratio of the number of bytes belonging 277 to the repair packets to the number of bytes belonging to the 278 protected source packets. 280 Assuming that each repair packet carries an equal number of bytes 281 carried by a source packet, we can compute the overhead as follows: 283 Overhead = 1/D 285 where D is the number of rows in the source block. 287 1.3. Relation to Existing Specifications 289 This section discusses the relation of the current specification to 290 other existing specifications. 292 1.3.1. RFC 2733 and RFC 3009 294 The current specification extends the FEC header defined in [RFC2733] 295 and registers a new RTP payload format. This new payload format is 296 not backward compatible with the payload format that was registered 297 by [RFC3009]. 299 1.3.2. SMPTE 2022-1 301 In 2007, the Society of Motion Picture and Television Engineers 302 (SMPTE) - Technology Committee N26 on File Management and Networking 303 Technology - decided to revise the Pro-MPEG Code of Practice (CoP) #3 304 Release 2 specification, which (was initially produced by the Pro- 305 MPEG Forum in 2004) discussed the several aspects of the transmission 306 of MPEG-2 transport streams over IP networks. The new SMPTE 307 specification is referred to as [SMPTE2022-1]. 309 The Pro-MPEG CoP #3 r2 document was originally based on [RFC2733]. 310 SMPTE revised the document by extending the FEC header (by setting 311 the E bit) proposed in [RFC2733]. This extended header offers some 312 improvements. 314 For example, instead of utilizing the bitmap field used in [RFC2733], 315 [SMPTE2022-1] introduces separate fields to convey the number of rows 316 (D) and columns (L) of the source block as well as the type of the 317 repair packet (i.e., whether the repair packet is an interleaved FEC 318 packet computed over a column or a non-interleaved FEC packet 319 computed over a row). These fields plus the base sequence number 320 allow the receiver side to establish the associations between the 321 source and repair packets. Note that although the bitmap field is 322 not utilized, the FEC header of [SMPTE2022-1] inherently carries over 323 the bitmap field from [RFC2733]. 325 On the other hand, some parts of [SMPTE2022-1] are not in compliant 326 with RTP [RFC3550]. For example, [SMPTE2022-1] sets the SSRC field 327 to zero and does not use the timestamp field in the RTP headers of 328 the repair packets (Receivers ignore the timestamps of the repair 329 packets). Furthermore, [SMPTE2022-1] also sets the CC field in the 330 RTP header to zero and does not allow any Contributing Source (CSRC) 331 entry in the RTP header. 333 The current document adopts the extended FEC header of [SMPTE2022-1] 334 and registers a new RTP payload format. At the same time, this 335 document fixes the parts of [SMPTE2022-1] that are not compliant with 336 RTP [RFC3550], except the one discussed below. 338 The baseline header format first proposed in [RFC2733] does not have 339 fields to protect the P and X bits and the CC fields of the source 340 packets associated with a repair packet. Rather, the P bit, X bit 341 and CC field in the RTP header of the repair packet are used to 342 protect those bits and fields. This, however, may sometimes result 343 in failures when doing the RTP header validity checks as specified in 344 [RFC3550]. While this behavior has been fixed in [RFC5109] that 345 obsoleted [RFC2733], the RTP payload format defined in this document 346 still allows for this behavior for legacy purposes. Implementations 347 following this specification must be aware of this potential issue 348 when RTP header validity checks are applied. 350 1.3.3. ETSI TS 102 034 352 In 2009, the Digital Video Broadcasting (DVB) consortium published a 353 technical specification [ETSI-TS-102-034] through European 354 Telecommunications Standards Institute (ETSI). This specification 355 covers several areas related to the transmission of MPEG-2 transport 356 stream-based services over IP networks. 358 The Annex E of [ETSI-TS-102-034] defines an optional protocol for 359 Application-layer FEC (AL-FEC) protection of streaming media for 360 DVB-IP services carried over RTP [RFC3550] transport. The DVB-IPTV 361 AL-FEC protocol uses two layers for protection: a base layer that is 362 produced by a packet-based interleaved parity code, and an 363 enhancement layer that is produced by a Raptor code 364 [I-D.ietf-fecframe-dvb-al-fec]. While the use of the enhancement 365 layer is optional, the use of the base layer is mandatory wherever 366 AL-FEC is used. The DVB-IPTV AL-FEC protocol is also described in 367 [I-D.ietf-fecframe-dvb-al-fec]. 369 The interleaved parity code that is used in the base layer is a 370 subset of [SMPTE2022-1]. In particular, AL-FEC base layer uses only 371 the 1-D interleaved FEC protection from [SMPTE2022-1]. The new RTP 372 payload format that is defined and registered in this document (with 373 some exceptions listed in [I-D.ietf-fecframe-dvb-al-fec]) is used as 374 the AL-FEC base layer. 376 1.4. Scope of the Payload Format 378 The payload format specified in this document must only be used in 379 legacy applications where the limitations explained in Section 1.3.2 380 are known not to impact any system components or other RTP elements. 381 Whenever possible a payload format that is fully compliant with 382 [RFC3550], such as [RFC5109] or other newer payload formats, must be 383 used. 385 2. Requirements Notation 387 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 388 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 389 document are to be interpreted as described in [RFC2119]. 391 3. Definitions, Notations and Abbreviations 393 The definitions and notations commonly used in this document are 394 summarized in this section. 396 3.1. Definitions 398 This document uses the following definitions: 400 Source Flow: The packet flow(s) carrying the source data and to 401 which FEC protection is to be applied. 403 Repair Flow: The packet flow(s) carrying the repair data. 405 Symbol: A unit of data. Its size, in bytes, is referred to as the 406 symbol size. 408 Source Symbol: The smallest unit of data used during the encoding 409 process. 411 Repair Symbol: Repair symbols are generated from the source symbols. 413 Source Packet: Data packets that contain only source symbols. 415 Repair Packet: Data packets that contain only repair symbols. 417 Source Block: A block of source symbols that are considered together 418 in the encoding process. 420 3.2. Notations 422 o L: Number of columns of the source block. 424 o D: Number of rows of the source block. 426 4. Packet Formats 428 This section defines the formats of the source and repair packets. 430 4.1. Source Packets 432 The source packets need to contain information that identifies the 433 source block and the position within the source block occupied by the 434 packet. Since the source packets that are carried within an RTP 435 stream already contain unique sequence numbers in their RTP headers 436 [RFC3550], we can identify the source packets in a straightforward 437 manner and there is no need to append additional field(s). The 438 primary advantage of not modifying the source packets in any way is 439 that it provides backward compatibility for the receivers that do not 440 support FEC at all. In multicast scenarios, this backward 441 compatibility becomes quite useful as it allows the non-FEC-capable 442 and FEC-capable receivers to receive and interpret the same source 443 packets sent in the same multicast session. 445 4.2. Repair Packets 447 The repair packets MUST contain information that identifies the 448 source block they pertain to and the relationship between the 449 contained repair symbols and the original source block. For this 450 purpose, we use the RTP header of the repair packets as well as 451 another header within the RTP payload, which we refer to as the FEC 452 header, as shown in Figure 6. 454 +------------------------------+ 455 | IP Header | 456 +------------------------------+ 457 | Transport Header | 458 +------------------------------+ 459 | RTP Header | __ 460 +------------------------------+ | 461 | FEC Header | \ 462 +------------------------------+ > RTP Payload 463 | Repair Symbols | / 464 +------------------------------+ __| 466 Figure 6: Format of repair packets 468 The RTP header is formatted according to [RFC3550] with some further 469 clarifications listed below: 471 o Version: The version field is set to 2. 473 o Padding (P) Bit: This bit is equal to the XOR sum of the 474 corresponding P bits from the RTP headers of the source packets 475 protected by this repair packet. However, padding octets are 476 never present in a repair packet, independent of the value of the 477 P bit. 479 o Extension (X) Bit: This bit is equal to the XOR sum of the 480 corresponding X bits from the RTP headers of the source packets 481 protected by this repair packet. However, an RTP header extension 482 is never present in a repair packet, independent of the value of 483 the X bit. 485 o CSRC Count (CC): This field is equal to the XOR sum of the 486 corresponding CC values from the RTP headers of the source packets 487 protected by this repair packet. However, a CSRC list is never 488 present in a repair packet, independent of the value of the CC 489 field. 491 o Marker (M) Bit: This bit is equal to the XOR sum of the 492 corresponding M bits from the RTP headers of the source packets 493 protected by this repair packet. 495 o Payload Type: The (dynamic) payload type for the repair packets 496 is determined through out-of-band means. Note that this document 497 registers a new payload format for the repair packets (Refer to 498 Section 5 for details). According to [RFC3550], an RTP receiver 499 that cannot recognize a payload type must discard it. This action 500 provides backward compatibility. The FEC mechanisms can then be 501 used in a multicast group with mixed FEC-capable and non-FEC- 502 capable receivers. If a non-FEC-capable receiver receives a 503 repair packet, it will not recognize the payload type, and hence, 504 discards the repair packet. 506 o Sequence Number (SN): The sequence number has the standard 507 definition. It MUST be one higher than the sequence number in the 508 previously transmitted repair packet. The initial value of the 509 sequence number SHOULD be random (unpredictable) [RFC3550]. 511 o Timestamp (TS): The timestamp SHALL be set to a time 512 corresponding to the repair packet's transmission time. Note that 513 the timestamp value has no use in the actual FEC protection 514 process and is usually useful for jitter calculations. 516 o Synchronization Source (SSRC): The SSRC value SHALL be randomly 517 assigned as suggested by [RFC3550]. This allows the sender to 518 multiplex the source and repair flows on the same port, or 519 multiplex multiple repair flows on a single port. The repair 520 flows SHOULD use the RTCP CNAME field to associate themselves with 521 the source flow. 523 In some networks, the RTP Source, which produces the source 524 packets and the FEC Source, which generates the repair packets 525 from the source packets may not be the same host. In such 526 scenarios, using the same CNAME for the source and repair flows 527 means that the RTP Source and the FEC Source MUST share the same 528 CNAME (for this specific source-repair flow association). A 529 common CNAME may be produced based on an algorithm that is known 530 both to the RTP and FEC Source. This usage is compliant with 531 [RFC3550]. 533 Note that due to the randomness of the SSRC assignments, there is 534 a possibility of SSRC collision. In such cases, the collisions 535 MUST be resolved as described in [RFC3550]. 537 Note that the P bit, X bit, CC field and M bit of the source packets 538 are protected by the corresponding bits/fields in the RTP header of 539 the repair packet. On the other hand, the payload of a repair packet 540 protects the concatenation of (if present) the CSRC list, RTP 541 extension, payload and padding of the source RTP packets associated 542 with this repair packet. 544 The FEC header is 16 octets. The format of the FEC header is shown 545 in Figure 7. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | SN base low | Length recovery | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 |E| PT recovery | Mask | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | TS recovery | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 |N|D|Type |Index| Offset | NA | SN base ext | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 7: Format of the FEC header 561 The FEC header consists of the following fields: 563 o The SN base low field is used to indicate the lowest sequence 564 number, taking wrap around into account, of those source packets 565 protected by this repair packet. 567 o The Length recovery field is used to determine the length of any 568 recovered packets. 570 o The E bit is the extension flag introduced in [RFC2733] and used 571 to extend the [RFC2733] FEC header. 573 o The PT recovery field is used to determine the payload type of the 574 recovered packets. 576 o The Mask field is not used. 578 o The TS recovery field is used to determine the timestamp of the 579 recovered packets. 581 o The N bit is the extension flag that is reserved for future uses. 583 o The D bit is not used. 585 o The Type field indicates the type of the error-correcting code 586 used. This document defines only one error-correcting code. 588 o The Index field is not used. 590 o The Offset and NA fields are used to indicate the number of 591 columns (L) and rows (D) of the source block, respectively. 593 o The SN base ext field is not used. 595 The details on setting the fields in the FEC header are provided in 596 Section 6.2. 598 It should be noted that a mask-based approach (similar to the one 599 specified in [RFC2733]) may not be very efficient to indicate which 600 source packets in the current source block are associated with a 601 given repair packet. In particular, for the applications that would 602 like to use large source block sizes, the size of the mask that is 603 required to describe the source-repair packet associations may be 604 prohibitively large. Instead, a systematized approach is inherently 605 more efficient. 607 5. Payload Format Parameters 609 This section provides the media subtype registration for the 1-D 610 interleaved parity FEC. The parameters that are required to 611 configure the FEC encoding and decoding operations are also defined 612 in this section. 614 5.1. Media Type Registration 616 This registration is done using the template defined in [RFC4288] and 617 following the guidance provided in [RFC3555]. 619 Note to the RFC Editor: In the following sections, please replace 620 "XXXX" with the number of this document prior to publication as an 621 RFC. 623 5.1.1. Registration of audio/1d-interleaved-parityfec 625 Type name: audio 627 Subtype name: 1d-interleaved-parityfec 629 Required parameters: 631 o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate 632 SHALL be larger than 1000 to provide sufficient resolution to RTCP 633 operations. However, it is RECOMMENDED to select the rate that 634 matches the rate of the protected source RTP stream. 636 o L: Number of columns of the source block. L is a positive 637 integer that is less than or equal to 255. 639 o D: Number of rows of the source block. D is a positive integer 640 that is less than or equal to 255. 642 o repair-window: The time that spans the source packets and the 643 corresponding repair packets. An FEC encoder processes a block of 644 source packets and generates a number of repair packets, which are 645 then transmitted within a certain duration. At the receiver, the 646 FEC decoder tries to decode all the packets received within the 647 repair window to recover the missing packets. Assuming that there 648 is no issue of delay variation, the FEC decoder SHOULD NOT wait 649 longer than the repair window since additional waiting would not 650 help the recovery process. The size of the repair window is 651 specified in microseconds. 653 Optional parameters: None. 655 Encoding considerations: This media type is framed (See Section 4.8 656 in the template document [RFC4288]) and contains binary data. 658 Security considerations: See Section 9 of [RFCXXXX]. 660 Interoperability considerations: None. 662 Published specification: [RFCXXXX]. 664 Applications that use this media type: Multimedia applications that 665 want to improve resiliency against packet loss by sending redundant 666 data in addition to the source media. 668 Additional information: None. 670 Person & email address to contact for further information: Ali Begen 671 and IETF Audio/Video Transport Working Group. 673 Intended usage: COMMON. 675 Restriction on usage: This media type depends on RTP framing, and 676 hence, is only defined for transport via RTP [RFC3550]. 678 Author: Ali Begen . 680 Change controller: IETF Audio/Video Transport Working Group 681 delegated from the IESG. 683 5.1.2. Registration of video/1d-interleaved-parityfec 685 Type name: video 687 Subtype name: 1d-interleaved-parityfec 689 Required parameters: 691 o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate 692 SHALL be larger than 1000 to provide sufficient resolution to RTCP 693 operations. However, it is RECOMMENDED to select the rate that 694 matches the rate of the protected source RTP stream. 696 o L: Number of columns of the source block. L is a positive 697 integer that is less than or equal to 255. 699 o D: Number of rows of the source block. D is a positive integer 700 that is less than or equal to 255. 702 o repair-window: The time that spans the source packets and the 703 corresponding repair packets. An FEC encoder processes a block of 704 source packets and generates a number of repair packets, which are 705 then transmitted within a certain duration. At the receiver, the 706 FEC decoder tries to decode all the packets received within the 707 repair window to recover the missing packets. Assuming that there 708 is no issue of delay variation, the FEC decoder SHOULD NOT wait 709 longer than the repair window since additional waiting would not 710 help the recovery process. The size of the repair window is 711 specified in microseconds. 713 Optional parameters: None. 715 Encoding considerations: This media type is framed (See Section 4.8 716 in the template document [RFC4288]) and contains binary data. 718 Security considerations: See Section 9 of [RFCXXXX]. 720 Interoperability considerations: None. 722 Published specification: [RFCXXXX]. 724 Applications that use this media type: Multimedia applications that 725 want to improve resiliency against packet loss by sending redundant 726 data in addition to the source media. 728 Additional information: None. 730 Person & email address to contact for further information: Ali Begen 731 and IETF Audio/Video Transport Working Group. 733 Intended usage: COMMON. 735 Restriction on usage: This media type depends on RTP framing, and 736 hence, is only defined for transport via RTP [RFC3550]. 738 Author: Ali Begen . 740 Change controller: IETF Audio/Video Transport Working Group 741 delegated from the IESG. 743 5.1.3. Registration of text/1d-interleaved-parityfec 745 Type name: text 747 Subtype name: 1d-interleaved-parityfec 749 Required parameters: 751 o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate 752 SHALL be larger than 1000 to provide sufficient resolution to RTCP 753 operations. However, it is RECOMMENDED to select the rate that 754 matches the rate of the protected source RTP stream. 756 o L: Number of columns of the source block. L is a positive 757 integer that is less than or equal to 255. 759 o D: Number of rows of the source block. D is a positive integer 760 that is less than or equal to 255. 762 o repair-window: The time that spans the source packets and the 763 corresponding repair packets. An FEC encoder processes a block of 764 source packets and generates a number of repair packets, which are 765 then transmitted within a certain duration. At the receiver, the 766 FEC decoder tries to decode all the packets received within the 767 repair window to recover the missing packets. Assuming that there 768 is no issue of delay variation, the FEC decoder SHOULD NOT wait 769 longer than the repair window since additional waiting would not 770 help the recovery process. The size of the repair window is 771 specified in microseconds. 773 Optional parameters: None. 775 Encoding considerations: This media type is framed (See Section 4.8 776 in the template document [RFC4288]) and contains binary data. 778 Security considerations: See Section 9 of [RFCXXXX]. 780 Interoperability considerations: None. 782 Published specification: [RFCXXXX]. 784 Applications that use this media type: Multimedia applications that 785 want to improve resiliency against packet loss by sending redundant 786 data in addition to the source media. 788 Additional information: None. 790 Person & email address to contact for further information: Ali Begen 791 and IETF Audio/Video Transport Working Group. 793 Intended usage: COMMON. 795 Restriction on usage: This media type depends on RTP framing, and 796 hence, is only defined for transport via RTP [RFC3550]. 798 Author: Ali Begen . 800 Change controller: IETF Audio/Video Transport Working Group 801 delegated from the IESG. 803 5.1.4. Registration of application/1d-interleaved-parityfec 805 Type name: application 807 Subtype name: 1d-interleaved-parityfec 809 Required parameters: 811 o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate 812 SHALL be larger than 1000 to provide sufficient resolution to RTCP 813 operations. However, it is RECOMMENDED to select the rate that 814 matches the rate of the protected source RTP stream. 816 o L: Number of columns of the source block. L is a positive 817 integer that is less than or equal to 255. 819 o D: Number of rows of the source block. D is a positive integer 820 that is less than or equal to 255. 822 o repair-window: The time that spans the source packets and the 823 corresponding repair packets. An FEC encoder processes a block of 824 source packets and generates a number of repair packets, which are 825 then transmitted within a certain duration. At the receiver, the 826 FEC decoder tries to decode all the packets received within the 827 repair window to recover the missing packets. Assuming that there 828 is no issue of delay variation, the FEC decoder SHOULD NOT wait 829 longer than the repair window since additional waiting would not 830 help the recovery process. The size of the repair window is 831 specified in microseconds. 833 Optional parameters: None. 835 Encoding considerations: This media type is framed (See Section 4.8 836 in the template document [RFC4288]) and contains binary data. 838 Security considerations: See Section 9 of [RFCXXXX]. 840 Interoperability considerations: None. 842 Published specification: [RFCXXXX]. 844 Applications that use this media type: Multimedia applications that 845 want to improve resiliency against packet loss by sending redundant 846 data in addition to the source media. 848 Additional information: None. 850 Person & email address to contact for further information: Ali Begen 851 and IETF Audio/Video Transport Working Group. 853 Intended usage: COMMON. 855 Restriction on usage: This media type depends on RTP framing, and 856 hence, is only defined for transport via RTP [RFC3550]. 858 Author: Ali Begen . 860 Change controller: IETF Audio/Video Transport Working Group 861 delegated from the IESG. 863 5.2. Mapping to SDP Parameters 865 Applications that are using RTP transport commonly use Session 866 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 867 The information that is used to specify the media types in an RTP 868 session has specific mappings to the fields in an SDP description. 869 In this section, we provide these mappings for the media subtype 870 registered by this document ("1d-interleaved-parityfec"). Note that 871 if an application does not use SDP to describe the RTP sessions, an 872 appropriate mapping must be defined and used to specify the media 873 types and their parameters for the control/description protocol 874 employed by the application. 876 The mapping of the media type specification for "1d-interleaved- 877 parityfec" and its parameters in SDP is as follows: 879 o The media type (e.g., "application") goes into the "m=" line as 880 the media name. 882 o The media subtype ("1d-interleaved-parityfec") goes into the 883 "a=rtpmap" line as the encoding name. The RTP clock rate 884 parameter ("rate") also goes into the "a=rtpmap" line as the clock 885 rate. 887 o The remaining required payload-format-specific parameters go into 888 the "a=fmtp" line by copying them directly from the media type 889 string as a semicolon-separated list of parameter=value pairs. 891 SDP examples are provided in Section 7. 893 5.2.1. Offer-Answer Model Considerations 895 When offering 1-D interleaved parity FEC over RTP using SDP in an 896 Offer/Answer model [RFC3264], the following considerations apply: 898 o Each combination of the L and D parameters produces a different 899 FEC data and is not compatible with any other combination. A 900 sender application may desire to offer multiple offers with 901 different sets of L and D values as long as the parameter values 902 are valid. The receiver SHOULD normally choose the offer that has 903 a sufficient amount of interleaving. If multiple such offers 904 exist, the receiver may choose the offer that has the lowest 905 overhead or the one that requires the smallest amount of 906 buffering. The selection depends on the application requirements. 908 o The value for the repair-window parameter depends on the L and D 909 values and cannot be chosen arbitrarily. More specifically, L and 910 D values determine the lower limit for the repair-window size. 911 The upper limit of the repair-window size does not depend on the L 912 and D values. 914 o Although combinations with the same L and D values but with 915 different repair-window sizes produce the same FEC data, such 916 combinations are still considered different offers. The size of 917 the repair-window is related to the maximum delay between the 918 transmission of a source packet and the associated repair packet. 919 This directly impacts the buffering requirement on the receiver 920 side and the receiver must consider this when choosing an offer. 922 o There are no optional format parameters defined for this payload. 923 Any unknown option in the offer MUST be ignored and deleted from 924 the answer. If FEC is not desired by the receiver, it can be 925 deleted from the answer. 927 5.2.2. Declarative Considerations 929 In declarative usage, like SDP in the Real-time Streaming Protocol 930 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 931 [RFC2974], the following considerations apply: 933 o The payload format configuration parameters are all declarative 934 and a participant MUST use the configuration that is provided for 935 the session. 937 o More than one configuration may be provided (if desired) by 938 declaring multiple RTP payload types. In that case, the receivers 939 should choose the repair flow that is best for them. 941 6. Protection and Recovery Procedures 943 This section provides a complete specification of the 1-D interleaved 944 parity code and its RTP payload format. 946 6.1. Overview 948 The following sections specify the steps involved in generating the 949 repair packets and reconstructing the missing source packets from the 950 repair packets. 952 6.2. Repair Packet Construction 954 The RTP header of a repair packet is formed based on the guidelines 955 given in Section 4.2. 957 The FEC header includes 16 octets. It is constructed by applying the 958 XOR operation on the bit strings that are generated from the 959 individual source packets protected by this particular repair packet. 960 The set of the source packets that are associated with a given repair 961 packet can be computed by the formula given in Section 6.3.1. 963 The bit string is formed for each source packet by concatenating the 964 following fields together in the order specified: 966 o Padding bit (1 bit) (This is the most significant bit of the bit 967 string) 969 o Extension bit (1 bit) 971 o CC field (4 bits) 973 o Marker bit (1 bit) 975 o PT field (7 bits) 977 o Timestamp (32 bits) 978 o Unsigned network-ordered 16-bit representation of the source 979 packet length in bytes minus 12 (for the fixed RTP header), i.e., 980 the sum of the lengths of all the following if present: the CSRC 981 list, header extension, RTP payload and RTP padding (16 bits) 983 o If CC is nonzero, the CSRC list (variable length) 985 o If X is 1, the header extension (variable length) 987 o Payload (variable length) 989 o Padding, if present (variable length) 991 Note that if the lengths of the source packets are not equal, each 992 shorter packet MUST be padded to the length of the longest packet by 993 adding octet 0's at the end. Due to this possible padding and 994 mandatory FEC header, a repair packet has a larger size than the 995 source packets it protects. This may cause problems if the resulting 996 repair packet size exceeds the Maximum Transmission Unit (MTU) size 997 of the path over which the repair flow is sent. 999 By applying the parity operation on the bit strings produced from the 1000 source packets, we generate the FEC bit string. Some parts of the 1001 RTP header and the FEC header of the repair packet are generated from 1002 the FEC bit string as follows: 1004 o The first (most significant) bit in the FEC bit string is written 1005 into the Padding bit in the RTP header of the repair packet. 1007 o The next bit in the FEC bit string is written into the Extension 1008 bit in the RTP header of the repair packet. 1010 o The next 4 bits of the FEC bit string are written into the CC 1011 field in the RTP header of the repair packet. 1013 o The next bit of the FEC bit string is written into the Marker bit 1014 in the RTP header of the repair packet. 1016 o The next 7 bits of the FEC bit string are written into the PT 1017 recovery field in the FEC header. 1019 o The next 32 bits of the FEC bit string are written into the TS 1020 recovery field in the FEC header. 1022 o The next 16 bits are written into the Length recovery field in the 1023 FEC header. This allows the FEC procedure to be applied even when 1024 the lengths of the protected source packets are not identical. 1026 o The remaining bits are set to be the payload of the repair packet. 1028 The remaining parts of the FEC header are set as follows: 1030 o The SN base low field MUST be set to the lowest sequence number, 1031 taking wrap around into account, of those source packets protected 1032 by this repair packet. 1034 o The E bit MUST be set to 1 to extend the [RFC2733] FEC header. 1036 o The Mask field SHALL be set to 0 and ignored by the receiver. 1038 o The N bit SHALL be set to 0 and ignored by the receiver. 1040 o The D bit SHALL be set to 0 and ignored by the receiver. 1042 o The Type field MUST be set to 0. 1044 o The Index field SHALL be set to 0 and ignored by the receiver. 1046 o The Offset field MUST be set to the number of columns of the 1047 source block (L). 1049 o The NA field MUST be set to the number of rows of the source block 1050 (D). 1052 o The SN base ext field SHALL be set to 0 and ignored by the 1053 receiver. 1055 6.3. Source Packet Reconstruction 1057 This section describes the recovery procedures that are required to 1058 reconstruct the missing source packets. The recovery process has two 1059 steps. In the first step, the FEC decoder determines which source 1060 and repair packets should be used in order to recover a missing 1061 packet. In the second step, the decoder recovers the missing packet, 1062 which consists of an RTP header and RTP payload. 1064 In the following, we describe the RECOMMENDED algorithms for the 1065 first and second steps. Based on the implementation, different 1066 algorithms MAY be adopted. However, the end result MUST be identical 1067 to the one produced by the algorithms described below. 1069 6.3.1. Associating the Source and Repair Packets 1071 The first step is to associate the source and repair packets. The SN 1072 base low field in the FEC header shows the lowest sequence number of 1073 the source packets that form the particular column. In addition, the 1074 information of how many source packets are available in each column 1075 and row is available from the media type parameters specified in the 1076 SDP description. This set of information uniquely identifies all of 1077 the source packets associated with a given repair packet. 1079 Mathematically, for any received repair packet, p*, we can determine 1080 the sequence numbers of the source packets that are protected by this 1081 repair packet as follows: 1083 p*_snb + i * L (modulo 65536) 1085 where p*_snb denotes the value in the SN base low field of p*'s FEC 1086 header, L is the number of columns of the source block and 1088 0 <= i < D 1090 where D is the number of rows of the source block. 1092 We denote the set of the source packets associated with repair packet 1093 p* by set T(p*). Note that in a source block whose size is L columns 1094 by D rows, set T includes D source packets. Recall that 1-D 1095 interleaved FEC protection can fully recover the missing information 1096 if there is only one source packet missing in set T. If the repair 1097 packet that protects the source packets in set T is missing, or the 1098 repair packet is available but two or more source packets are 1099 missing, then missing source packets in set T cannot be recovered by 1100 1-D interleaved FEC protection. 1102 6.3.2. Recovering the RTP Header and Payload 1104 For a given set T, the procedure for the recovery of the RTP header 1105 of the missing packet, whose sequence number is denoted by SEQNUM, is 1106 as follows: 1108 1. For each of the source packets that are successfully received in 1109 set T, compute the bit string as described in Section 6.2. 1111 2. For the repair packet associated with set T, compute the bit 1112 string in the same fashion except use the PT recovery field 1113 instead of the PT field and TS recovery field instead of the 1114 Timestamp field, and set the CSRC list, header extension and 1115 padding to null regardless of the values of the CC field, X bit 1116 and P bit. 1118 3. If any of the bit strings generated from the source packets are 1119 shorter than the bit string generated from the repair packet, 1120 pad them to be the same length as the bit string generated from 1121 the repair packet. For padding, the padding of octet 0 MUST be 1122 added at the end of the bit string. 1124 4. Calculate the recovered bit string as the XOR of the bit strings 1125 generated from all source packets in set T and the FEC bit 1126 string generated from the repair packet associated with set T. 1128 5. Create a new packet with the standard 12-byte RTP header and no 1129 payload. 1131 6. Set the version of the new packet to 2. 1133 7. Set the Padding bit in the new packet to the first bit in the 1134 recovered bit string. 1136 8. Set the Extension bit in the new packet to the next bit in the 1137 recovered bit string. 1139 9. Set the CC field to the next 4 bits in the recovered bit string. 1141 10. Set the Marker bit in the new packet to the next bit in the 1142 recovered bit string. 1144 11. Set the Payload type in the new packet to the next 7 bits in the 1145 recovered bit string. 1147 12. Set the SN field in the new packet to SEQNUM. 1149 13. Set the TS field in the new packet to the next 32 bits in the 1150 recovered bit string. 1152 14. Take the next 16 bits of the recovered bit string and set the 1153 new variable Y to whatever unsigned integer this represents 1154 (assuming network order). Convert Y to host order and then take 1155 Y bytes from the recovered bit string and append them to the new 1156 packet. Y represents the length of the new packet in bytes 1157 minus 12 (for the fixed RTP header), i.e., the sum of the 1158 lengths of all the following if present: the CSRC list, header 1159 extension, RTP payload and RTP padding. 1161 15. Set the SSRC of the new packet to the SSRC of the source RTP 1162 stream. 1164 This procedure completely recovers both the header and payload of an 1165 RTP packet. 1167 7. Session Description Protocol (SDP) Signaling 1169 This section provides an SDP [RFC4566] example. The following 1170 example uses the FEC grouping semantics [I-D.ietf-mmusic-rfc4756bis]. 1172 In this example, we have one source video stream (mid:S1) and one FEC 1173 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 1174 S1 R1" line. The source and repair streams are sent to the same port 1175 on different multicast groups. The repair window is set to 200 ms. 1177 v=0 1178 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1179 s=Interleaved Parity FEC Example 1180 t=0 0 1181 a=group:FEC S1 R1 1182 m=video 30000 RTP/AVP 100 1183 c=IN IP4 233.252.0.1/127 1184 a=rtpmap:100 MP2T/90000 1185 a=mid:S1 1186 m=application 30000 RTP/AVP 110 1187 c=IN IP4 233.252.0.2/127 1188 a=rtpmap:110 1d-interleaved-parityfec/90000 1189 a=fmtp:110 L:5; D:10; repair-window:200000 1190 a=mid:R1 1192 8. Congestion Control Considerations 1194 FEC is an effective approach to provide applications resiliency 1195 against packet losses. However, in networks where the congestion is 1196 a major contributor to the packet loss, the potential impacts of 1197 using FEC SHOULD be considered carefully before injecting the repair 1198 flows into the network. In particular, in bandwidth-limited 1199 networks, FEC repair flows may consume most or all of the available 1200 bandwidth and may consequently congest the network. In such cases, 1201 the applications MUST NOT arbitrarily increase the amount of FEC 1202 protection since doing so may lead to a congestion collapse. If 1203 desired, stronger FEC protection MAY be applied only after the source 1204 rate has been reduced. 1206 In a network-friendly implementation, an application SHOULD NOT send/ 1207 receive FEC repair flows if it knows that sending/receiving those FEC 1208 repair flows would not help at all in recovering the missing packets. 1209 Such a practice helps reduce the amount of wasted bandwidth. It is 1210 RECOMMENDED that the amount of FEC protection is adjusted dynamically 1211 based on the packet loss rate observed by the applications. 1213 In multicast scenarios, it may be difficult to optimize the FEC 1214 protection per receiver. If there is a large variation among the 1215 levels of FEC protection needed by different receivers, it is 1216 RECOMMENDED that the sender offers multiple repair flows with 1217 different levels of FEC protection and the receivers join the 1218 corresponding multicast sessions to receive the repair flow(s) that 1219 is best for them. 1221 9. Security Considerations 1223 RTP packets using the payload format defined in this specification 1224 are subject to the security considerations discussed in the RTP 1225 specification [RFC3550] and in any applicable RTP profile. 1227 The main security considerations for the RTP packet carrying the RTP 1228 payload format defined within this memo are confidentiality, 1229 integrity and source authenticity. Confidentiality is achieved by 1230 encrypting the RTP payload. Altering the FEC packets can have a big 1231 impact on the reconstruction operation. An attack by changing some 1232 bits in the FEC packets can have a significant effect on the 1233 calculation and the recovery of the source packets. For example, 1234 changing the length recovery field can result in the recovery of a 1235 packet that is too long. Depending on the application, it may be 1236 helpful to perform a sanity check on the received source and FEC 1237 packets before performing the recovery operation and to determine the 1238 validity of the recovered packets before using them. 1240 Integrity of the RTP packets is achieved through a suitable 1241 cryptographic integrity protection mechanism. Such a cryptographic 1242 system may also allow the authentication of the source of the 1243 payload. A suitable security mechanism for this RTP payload format 1244 should provide source authentication capable of determining if an RTP 1245 packet is from a member of the RTP session. 1247 Note that the appropriate mechanism to provide security to RTP and 1248 payloads following this memo may vary. It is dependent on the 1249 application, transport and signaling protocol employed. Therefore, a 1250 single mechanism is not sufficient, although if suitable, using the 1251 Secure Real-time Transport Protocol (SRTP) [RFC3711] is RECOMMENDED. 1252 Other mechanisms that may be used are IPsec [RFC4301] and Transport 1253 Layer Security (TLS) [RFC5246]; other alternatives may exist. 1255 If FEC protection is applied on already encrypted source packets, 1256 there is no need for additional encryption. However, if the source 1257 packets are encrypted after FEC protection is applied, the FEC 1258 packets should be cryptographically as secure as the source packets. 1259 Failure to provide an equal level of confidentiality, integrity and 1260 authentication to the FEC packets can compromise the source packets' 1261 confidentiality, integrity or authentication since the FEC packets 1262 are generated by applying XOR operation across the source packets. 1264 10. IANA Considerations 1266 New media subtypes are subject to IANA registration. For the 1267 registration of the payload format and its parameters introduced in 1268 this document, refer to Section 5. 1270 11. Acknowledgments 1272 A major part of this document is borrowed from [RFC2733], [RFC5109] 1273 and [SMPTE2022-1]. Thus, the author would like to thank the authors 1274 and editors of these earlier specifications. The author also thanks 1275 Colin Perkins for his constructive suggestions for this document. 1277 12. Change Log 1279 12.1. draft-ietf-fecframe-interleaved-fec-scheme-09 1281 The following are the major changes compared to version 08: 1283 o The last sentence in the abstract has been changed per IESG 1284 comment. 1286 12.2. draft-ietf-fecframe-interleaved-fec-scheme-08 1288 The following are the major changes compared to version 07: 1290 o Comments from the gen-art, media-type and IESG reviews have been 1291 addressed. 1293 12.3. draft-ietf-fecframe-interleaved-fec-scheme-07 1295 The following are the major changes compared to version 06: 1297 o The definition of "rate" in the media type registration has been 1298 clarified. 1300 12.4. draft-ietf-fecframe-interleaved-fec-scheme-06 1302 The following are the major changes compared to version 05: 1304 o Comments from IETF LC have been addressed. 1306 12.5. draft-ietf-fecframe-interleaved-fec-scheme-05 1308 The following are the major changes compared to version 04: 1310 o Comments from Vincent Roca have been addressed. 1312 12.6. draft-ietf-fecframe-interleaved-fec-scheme-04 1314 The following are the major changes compared to version 03: 1316 o Further comments from AVT WG have been addressed. 1318 12.7. draft-ietf-fecframe-interleaved-fec-scheme-03 1320 The following are the major changes compared to version 02: 1322 o Comments from WGLC have been addressed. 1324 12.8. draft-ietf-fecframe-interleaved-fec-scheme-02 1326 The following are the major changes compared to version 01: 1328 o Some details were added regarding the use of CNAME field. 1330 o Offer-Answer and Declarative Considerations sections have been 1331 completed. 1333 o Security Considerations section has been completed. 1335 12.9. draft-ietf-fecframe-interleaved-fec-scheme-01 1337 The following are the major changes compared to version 00: 1339 o The timestamp field definition has changed. 1341 12.10. draft-ietf-fecframe-interleaved-fec-scheme-00 1343 This is the initial version, which is based on an earlier individual 1344 submission. The following are the major changes compared to that 1345 document: 1347 o Per the discussion in the WG, references to the FEC Framework have 1348 been removed and the document has been turned into a pure RTP 1349 payload format specification. 1351 o A new section is added for congestion control considerations. 1353 o Editorial changes to clarify a few points. 1355 13. References 1357 13.1. Normative References 1359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1360 Requirement Levels", BCP 14, RFC 2119, March 1997. 1362 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1363 Jacobson, "RTP: A Transport Protocol for Real-Time 1364 Applications", STD 64, RFC 3550, July 2003. 1366 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1367 Description Protocol", RFC 4566, July 2006. 1369 [I-D.ietf-mmusic-rfc4756bis] 1370 Begen, A., "Forward Error Correction Grouping Semantics in 1371 Session Description Protocol", 1372 draft-ietf-mmusic-rfc4756bis-05 (work in progress), 1373 October 2009. 1375 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1376 Registration Procedures", BCP 13, RFC 4288, December 2005. 1378 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1379 Payload Formats", RFC 3555, July 2003. 1381 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1382 with Session Description Protocol (SDP)", RFC 3264, 1383 June 2002. 1385 13.2. Informative References 1387 [I-D.ietf-fecframe-dvb-al-fec] 1388 Begen, A. and T. Stockhammer, "Guidelines for Implementing 1389 DVB-IPTV Application-Layer Hybrid FEC Protection", 1390 draft-ietf-fecframe-dvb-al-fec-04 (work in progress), 1391 December 2009. 1393 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1394 for Generic Forward Error Correction", RFC 2733, 1395 December 1999. 1397 [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of 1398 parityfec MIME types", RFC 3009, November 2000. 1400 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1401 Correction", RFC 5109, December 2007. 1403 [ETSI-TS-102-034] 1404 ETSI TS 102 034 V1.4.1, "Transport of MPEG 2 TS Based DVB 1405 Services over IP Based Networks", August 2009. 1407 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1408 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1410 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1411 Announcement Protocol", RFC 2974, October 2000. 1413 [SMPTE2022-1] 1414 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 1415 Video/Audio Transport over IP Networks", 2007. 1417 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1418 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1419 RFC 3711, March 2004. 1421 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1422 Internet Protocol", RFC 4301, December 2005. 1424 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1425 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1427 Author's Address 1429 Ali Begen 1430 Cisco 1431 170 West Tasman Drive 1432 San Jose, CA 95134 1433 USA 1435 Email: abegen@cisco.com