idnits 2.17.1 draft-ietf-fecframe-1d2d-parity-scheme-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 24, 2009) is 5451 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 1031, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) ** 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 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 5 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 May 24, 2009 5 Expires: November 25, 2009 7 RTP Payload Format for Non-Interleaved and Interleaved Parity FEC 8 draft-ietf-fecframe-1d2d-parity-scheme-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 25, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document defines new RTP payload formats for the Forward Error 57 Correction (FEC) that is generated by the non-interleaved and 58 interleaved parity codes from a source media encapsulated in RTP. 59 These parity codes are systematic codes, where a number of repair 60 symbols are generated from a set of source symbols and sent in a 61 repair flow separate from the source flow that carries the source 62 symbols. The non-interleaved and interleaved parity codes offer a 63 good protection against random and bursty packet losses, 64 respectively, at a cost of decent complexity. The RTP payload 65 formats that are defined in this document address the scalability 66 issues experienced with the earlier specifications including RFC 67 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due 68 to these changes, the new payload formats are not backward compatible 69 with the earlier specifications. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. Use Cases for 1-D FEC Protection . . . . . . . . . . . . . 7 75 1.2. Use Cases for 2-D Parity FEC Protection . . . . . . . . . 9 76 1.3. Overhead Computation . . . . . . . . . . . . . . . . . . . 11 77 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11 78 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 11 79 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 80 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 12 81 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . . 12 83 4.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . . 12 84 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15 85 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 15 86 5.1.1. Registration of audio/non-interleaved-parityfec . . . 16 87 5.1.2. Registration of video/non-interleaved-parityfec . . . 17 88 5.1.3. Registration of text/non-interleaved-parityfec . . . . 18 89 5.1.4. Registration of 90 application/non-interleaved-parityfec . . . . . . . . 19 91 5.1.5. Registration of audio/interleaved-parityfec . . . . . 20 92 5.1.6. Registration of video/interleaved-parityfec . . . . . 21 93 5.1.7. Registration of text/interleaved-parityfec . . . . . . 23 94 5.1.8. Registration of application/interleaved-parityfec . . 24 95 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 25 96 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 26 97 5.2.2. Declarative Considerations . . . . . . . . . . . . . . 26 98 6. Protection and Recovery Procedures . . . . . . . . . . . . . . 27 99 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 27 101 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 29 102 6.3.1. Associating the Source and Repair Packets . . . . . . 29 103 6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 30 104 6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . . 31 105 6.3.4. Iterative Decoding Algorithm for the 2-D Parity 106 FEC Protection . . . . . . . . . . . . . . . . . . . . 32 107 7. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 7.1. Example SDP for 1-D Parity FEC Protection . . . . . . . . 34 109 7.2. Example SDP for 2-D Parity FEC Protection . . . . . . . . 35 110 8. Congestion Control Considerations . . . . . . . . . . . . . . 35 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 112 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 113 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 114 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 37 115 12.1. draft-ietf-fecframe-1d2d-parity-scheme-01 . . . . . . . . 37 116 12.2. draft-ietf-fecframe-1d2d-parity-scheme-00 . . . . . . . . 37 117 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 118 13.1. Normative References . . . . . . . . . . . . . . . . . . . 37 119 13.2. Informative References . . . . . . . . . . . . . . . . . . 38 120 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 122 1. Introduction 124 This document defines new RTP payload formats for the FEC that is 125 generated by the non-interleaved and interleaved parity codes from a 126 source media encapsulated in RTP [RFC3550]. The type of the source 127 media protected by these parity codes can be audio, video, text or 128 application. The FEC data are generated according to the media type 129 parameters that are communicated through out-of-band means. The 130 associations/relationships between the source and repair flows are 131 also communicated through out-of-band means. 133 Both the non-interleaved and interleaved parity codes use the 134 exclusive OR (XOR) operation to generate the repair symbols. In a 135 nutshell, the following steps take place: 137 1. The sender determines a set of source packets to be protected 138 together based on the media type parameters. 140 2. The sender applies the XOR operation on the source symbols to 141 generate the required number of repair symbols. 143 3. The sender packetizes the repair symbols and sends the repair 144 packet(s) along with the source packets to the receiver(s) (in 145 different flows). The repair packets MAY be sent proactively or 146 on-demand. 148 Note that the source and repair packets belong to different source 149 and repair flows, and the sender MUST provide a way for the receivers 150 to demultiplex them, even in the case they are sent in the same 151 transport flow (i.e., same source/destination address/port with UDP). 152 This is required to offer backward compatibility (See Section 4). At 153 the receiver side, if all of the source packets are successfully 154 received, there is no need for FEC recovery and the repair packets 155 are discarded. However, if there are missing source packets, the 156 repair packets can be used to recover the missing information. Block 157 diagrams for the systematic parity FEC encoder and decoder are 158 sketched in Figure 1 and Figure 2, respectively. 160 +------------+ 161 +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 162 +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 163 | Encoder | 164 | (Sender) | --> +==+ +==+ 165 +------------+ +==+ +==+ 167 Source Packet: +--+ Repair Packet: +==+ 168 +--+ +==+ 170 Figure 1: Block diagram for systematic parity FEC encoder 172 +------------+ 173 +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 174 +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 175 | Decoder | 176 +==+ +==+ --> | (Receiver) | 177 +==+ +==+ +------------+ 179 Source Packet: +--+ Repair Packet: +==+ Lost Packet: X 180 +--+ +==+ 182 Figure 2: Block diagram for systematic parity FEC decoder 184 In Figure 2, it is clear that the FEC packets have to be received by 185 the receiver within a certain time to be useful in the FEC recovery 186 process. In this document, we refer to the time that spans the 187 source packets and the corresponding repair packets as the repair 188 window. Assuming that there is no issue of delay variation, the FEC 189 decoder SHOULD NOT wait longer than the repair window since 190 additional waiting would not help the recovery process. The size of 191 the repair window depends on the source block size and the regime 192 adopted for sending the repair packets. 194 Suppose that we have a group of D x L source packets that have 195 sequence numbers starting from 1 running to D x L, and a repair 196 packet is generated by applying the XOR operation to every L 197 consecutive packets as sketched in Figure 3. This process is 198 referred to as 1-D non-interleaved FEC protection. As a result of 199 this process, D repair packets are generated, which we refer to as 200 non-interleaved (or row) FEC packets. 202 +--------------------------------------------------+ --- +===+ 203 | S_1 S_2 S3 ... S_L | + |XOR| = |R_1| 204 +--------------------------------------------------+ --- +===+ 205 +--------------------------------------------------+ --- +===+ 206 | S_L+1 S_L+2 S_L+3 ... S_2xL | + |XOR| = |R_2| 207 +--------------------------------------------------+ --- +===+ 208 . . . . . . 209 . . . . . . 210 . . . . . . 211 +--------------------------------------------------+ --- +===+ 212 | S_(D-1)xL+1 S_(D-1)xL+2 S_(D-1)xL+3 ... S_DxL | + |XOR| = |R_D| 213 +--------------------------------------------------+ --- +===+ 215 Figure 3: Generating non-interleaved (row) FEC packets 217 If we apply the XOR operation to the group of the source packets 218 whose sequence numbers are L apart from each other as sketched in 219 Figure 4, we generate L repair packets. This process is referred to 220 as 1-D interleaved FEC protection, and the resulting L repair packets 221 are referred to as interleaved (or column) FEC packets. 223 +-------------+ +-------------+ +-------------+ +-------+ 224 | S_1 | | S_2 | | S3 | ... | S_L | 225 | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | 226 | . | | . | | | | | 227 | . | | . | | | | | 228 | . | | . | | | | | 229 | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | 230 +-------------+ +-------------+ +-------------+ +-------+ 231 + + + + 232 ------------- ------------- ------------- ------- 233 | XOR | | XOR | | XOR | ... | XOR | 234 ------------- ------------- ------------- ------- 235 = = = = 236 +===+ +===+ +===+ +===+ 237 |C_1| |C_2| |C_3| ... |C_L| 238 +===+ +===+ +===+ +===+ 240 Figure 4: Generating interleaved (column) FEC packets 242 1.1. Use Cases for 1-D FEC Protection 244 We generate one non-interleaved repair packet out of L consecutive 245 source packets and one interleaved repair packet out of D non- 246 consecutive source packets. Regardless of whether the repair packet 247 is a non-interleaved or an interleaved one, it can provide a full 248 recovery of the missing information if there is only one packet 249 missing among the corresponding source packets. This implies that 250 1-D non-interleaved FEC protection performs better when the source 251 packets are randomly lost. However, if the packet losses occur in 252 bursts, 1-D interleaved FEC protection performs better provided that 253 L is chosen large enough, i.e., L-packet duration SHOULD NOT be 254 shorter than the observed burst duration. The sender SHOULD monitor 255 the occurrences of the loss events on the source packets and generate 256 non-interleaved and interleaved FEC packets when the losses occur 257 randomly and in bursts, respectively. 259 If the sender generates non-interleaved FEC packets and a burst loss 260 hits the source packets, the repair operation fails. This is 261 illustrated in Figure 5. 263 +---+ +---+ +===+ 264 | 1 | X X | 4 | |R_1| 265 +---+ +---+ +===+ 267 +---+ +---+ +---+ +---+ +===+ 268 | 5 | | 6 | | 7 | | 8 | |R_2| 269 +---+ +---+ +---+ +---+ +===+ 271 +---+ +---+ +---+ +---+ +===+ 272 | 9 | | 10| | 11| | 12| |R_3| 273 +---+ +---+ +---+ +---+ +===+ 275 Figure 5: Example scenario where 1-D non-interleaved FEC protection 276 fails error recovery 278 The sender may generate interleaved FEC packets to combat with the 279 bursty packet losses. However, two or more random packet losses may 280 hit the source and repair packets in the same column. In that case, 281 the repair operation fails. This is illustrated in Figure 6. Note 282 that it is possible that two burst losses may occur back-to-back, in 283 which case interleaved FEC packets may still fail to recover the lost 284 data. 286 +---+ +---+ +---+ 287 | 1 | X | 3 | | 4 | 288 +---+ +---+ +---+ 290 +---+ +---+ +---+ 291 | 5 | X | 7 | | 8 | 292 +---+ +---+ +---+ 294 +---+ +---+ +---+ +---+ 295 | 9 | | 10| | 11| | 12| 296 +---+ +---+ +---+ +---+ 298 +===+ +===+ +===+ +===+ 299 |C_1| |C_2| |C_3| |C_4| 300 +===+ +===+ +===+ +===+ 302 Figure 6: Example scenario where 1-D interleaved FEC protection fails 303 error recovery 305 1.2. Use Cases for 2-D Parity FEC Protection 307 In networks where the source packets are lost both randomly and in 308 bursts, the sender may generate both non-interleaved and interleaved 309 FEC packets. This type of FEC protection is known as 2-D parity FEC 310 protection. At the expense of generating more FEC packets, thus 311 increasing the FEC overhead, 2-D FEC provides a superior protection 312 against mixed loss patterns. However, 2-D parity FEC protection is 313 still not hitless and may fail to recover all of the lost source 314 packets if a particular loss pattern hits the source packets. An 315 example scenario is illustrated in Figure 7. 317 +---+ +---+ +===+ 318 | 1 | X X | 4 | |R_1| 319 +---+ +---+ +===+ 321 +---+ +---+ +---+ +---+ +===+ 322 | 5 | | 6 | | 7 | | 8 | |R_2| 323 +---+ +---+ +---+ +---+ +===+ 325 +---+ +---+ +===+ 326 | 9 | X X | 12| |R_3| 327 +---+ +---+ +===+ 329 +===+ +===+ +===+ +===+ 330 |C_1| |C_2| |C_3| |C_4| 331 +===+ +===+ +===+ +===+ 333 Figure 7: Example scenario #1 where 2-D parity FEC protection fails 334 error recovery 336 2-D parity FEC protection also fails when at least two rows are 337 missing a source and the FEC packet and the missing source packets 338 (in at least two rows) are aligned in the same column. An example 339 loss pattern is sketched in Figure 8. Similarly, 2-D parity FEC 340 protection cannot repair all missing source packets when at least two 341 columns are missing a source and the FEC packet and the missing 342 source packets (in at least two columns) are aligned in the same row. 344 +---+ +---+ +---+ 345 | 1 | | 2 | X | 4 | X 346 +---+ +---+ +---+ 348 +---+ +---+ +---+ +---+ +===+ 349 | 5 | | 6 | | 7 | | 8 | |R_2| 350 +---+ +---+ +---+ +---+ +===+ 352 +---+ +---+ +---+ 353 | 9 | | 10| X | 12| X 354 +---+ +---+ +---+ 356 +===+ +===+ +===+ +===+ 357 |C_1| |C_2| |C_3| |C_4| 358 +===+ +===+ +===+ +===+ 360 Figure 8: Example scenario #2 where 2-D parity FEC protection fails 361 error recovery 363 1.3. Overhead Computation 365 The overhead is defined as the ratio of the number of bytes belonging 366 to the repair packets to the number of bytes belonging to the 367 protected source packets. 369 Generally, repair packets are larger in size compared to the source 370 packets. Also, not all the source packets are necessarily equal in 371 size. However, if we assume that each repair packet carries an equal 372 number of bytes carried by a source packet, we can compute the 373 overhead for different FEC protection methods as follows: 375 o 1-D Non-interleaved FEC Protection: Overhead = 1/L 377 o 1-D Interleaved FEC Protection: Overhead = 1/D 379 o 2-D Parity FEC Protection: Overhead = 1/L + 1/D 381 where L and D are the number of columns and rows in the source block, 382 respectively. 384 2. Requirements Notation 386 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 387 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 388 document are to be interpreted as described in [RFC2119]. 390 3. Definitions, Notations and Abbreviations 392 The definitions and notations commonly used in this document are 393 summarized in this section. 395 3.1. Definitions 397 This document uses the following definitions: 399 Source Flow: The packet flow(s) carrying the source data and to 400 which FEC protection is to be applied. 402 Repair Flow: The packet flow(s) carrying the repair data. 404 Symbol: A unit of data. Its size, in bytes, is referred to as the 405 symbol size. 407 Source Symbol: The smallest unit of data used during the encoding 408 process. 410 Repair Symbol: Repair symbols are generated from the source symbols. 412 Source Packet: Data packets that contain only source symbols. 414 Repair Packet: Data packets that contain only repair symbols. 416 Source Block: A block of source symbols that are considered together 417 in the encoding process. 419 3.2. Notations 421 o L: Number of columns of the source block. 423 o D: Number of rows of the source block. 425 o ToP: Type of protection. 427 4. Packet Formats 429 This section defines the formats of the source and repair packets. 431 4.1. Source Packets 433 The source packets MUST contain the information that identifies the 434 source block and the position within the source block occupied by the 435 packet. Since the source packets that are carried within an RTP 436 stream already contain unique sequence numbers in their RTP headers 437 [RFC3550], we can identify the source packets in a straightforward 438 manner and there is no need to append additional field(s). The 439 primary advantage of not modifying the source packets in any way is 440 that it provides backward compatibility for the receivers that do not 441 support FEC at all. In multicast scenarios, this backward 442 compatibility becomes quite useful as it allows the non-FEC-capable 443 and FEC-capable receivers to receive and interpret the same source 444 packets sent in the same multicast session. 446 4.2. Repair Packets 448 The repair packets MUST contain information that identifies the 449 source block they pertain to and the relationship between the 450 contained repair symbols and the original source block. For this 451 purpose, we use the RTP header of the repair packets as well as 452 another header within the RTP payload, which we refer to as the FEC 453 header, as shown in Figure 9. 455 +------------------------------+ 456 | IP Header | 457 +------------------------------+ 458 | Transport Header | 459 +------------------------------+ 460 | RTP Header | __ 461 +------------------------------+ | 462 | FEC Header | \ 463 +------------------------------+ > RTP Payload 464 | Repair Symbols | / 465 +------------------------------+ __| 467 Figure 9: Format of repair packets 469 The RTP header is formatted according to [RFC3550] with some further 470 clarifications listed below: 472 o Marker (M) Bit: This bit is not used for this payload type, and 473 SHALL be set to 0. 475 o Payload Type: The (dynamic) payload type for the repair packets 476 is determined through out-of-band means. Note that this document 477 registers new payload formats for the repair packets (Refer to 478 Section 5 for details). According to [RFC3550], an RTP receiver 479 that cannot recognize a payload type must discard it. This 480 provides backward compatibility. The FEC mechanisms can then be 481 used in a multicast group with mixed FEC-capable and non-FEC- 482 capable receivers. If a non-FEC-capable receiver receives a 483 repair packet, it will not recognize the payload type, and hence, 484 will discard the repair packet. 486 o Sequence Number (SN): The sequence number has the standard 487 definition. It MUST be one higher than the sequence number in the 488 previously transmitted repair packet. The initial value of the 489 sequence number SHOULD be random (unpredictable) [RFC3550]. 491 o Timestamp (TS): The timestamp SHALL be set to a time 492 corresponding to the repair packet's transmission time. Note that 493 the timestamp value has no use in the actual FEC protection 494 process and is usually useful for jitter calculations. 496 o Synchronization Source (SSRC): The SSRC value SHALL be randomly 497 assigned as suggested by [RFC3550]. This allows the sender to 498 multiplex the source and repair flows on the same port, or 499 multiplex multiple repair flows on a single port. The repair 500 flows SHOULD use the RTCP CNAME field to associate themselves with 501 the source flow. 503 In some networks, the RTP Source, which produces the source 504 packets and the FEC Source, which generates the repair packets 505 from the source packets may not be the same host. In such 506 scenarios, using the same CNAME for the source and repair flows 507 means that the RTP Source and the FEC Source MUST share the same 508 CNAME (for this specific source-repair flow association). A 509 common CNAME may be produced based on an algorithm that is known 510 both to the RTP and FEC Source. This usage is compliant with 511 [RFC3550]. 513 Note that due to the randomness of the SSRC assignments, there is 514 a possibility of SSRC collision. In such cases, the collisions 515 MUST be resolved as described in [RFC3550]. 517 The FEC header is 12 octets (or 16 octets when the optional padding 518 is used). The format of the FEC header is shown in Figure 10. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 |E|I|P|X| CC |M| PT recovery | SN base | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | TS recovery | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Length recovery | Padding | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Padding (optional) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 10: Format of the FEC header 534 The FEC header consists of the following fields: 536 o The E bit is the extension flag reserved to indicate any future 537 extension to this specification. 539 o The I bit is used to indicate the length of padding in the FEC 540 header. The padding length SHOULD be selected based on the 541 platform architecture and the impact of header length on the 542 header processing performance. 544 o The P, X, CC, M and PT recovery fields are used to determine the 545 corresponding fields of the recovered packets. 547 o The SN base field is used to indicate the lowest sequence number, 548 taking wrap around into account, of those source packets protected 549 by this repair packet. 551 o The TS recovery field is used to determine the timestamp of the 552 recovered packets. 554 o The Length recovery field is used to determine the length of the 555 recovered packets. 557 o The Padding field is used to pad the FEC header to 12 bytes 558 (integer multiples of 32 bits). 560 o The second (optional) Padding field is used to pad the FEC header 561 to 16 bytes (integer multiples of 64 bits). 563 The details on setting the fields in the FEC header are provided in 564 Section 6.2. 566 It should be noted that a mask-based approach (similar to the ones 567 specified in [RFC2733] and [RFC5109]) may not be very efficient to 568 indicate which source packets in the current source block are 569 associated with a given repair packet. In particular, for the 570 applications that would like to use large source block sizes, the 571 size of the mask that is required to describe the source-repair 572 packet associations may be prohibitively large. Instead, a 573 systematized approach similar to the one proposed in [SMPTE2022-1] is 574 inherently more efficient. Yet, [SMPTE2022-1] carries the values of 575 D and L in 8-bit fields. While this approach can support larger 576 blocks compared to the mask-based approaches, 8-bit fields may still 577 be limiting when a high-bitrate source flow (e.g., a flow carrying 578 Ultra HD video) is to be protected or when network outages/lossy 579 periods span more than 255 packets. 581 5. Payload Format Parameters 583 This section provides the media subtype registration for the non- 584 interleaved and interleaved parity FEC. The parameters that are 585 required to configure the FEC encoding and decoding operations are 586 also defined in this section. 588 5.1. Media Type Registration 590 This registration is done using the template defined in [RFC4288] and 591 following the guidance provided in [RFC3555]. 593 Note to the RFC Editor: In the following sections, please replace 594 "XXXX" with the number of this document prior to publication as an 595 RFC. 597 5.1.1. Registration of audio/non-interleaved-parityfec 599 Type name: audio 601 Subtype name: non-interleaved-parityfec 603 Required parameters: 605 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 606 than 1000 Hz to provide sufficient resolution to RTCP operations. 607 However, it is RECOMMENDED to select the rate that matches the 608 rate of the protected source RTP stream. 610 o L: Number of columns of the source block. L is a positive 611 integer. 613 o D: Number of rows of the source block. D is a positive integer. 615 o ToP: Type of the protection applied by the sender: 0 for 1-D 616 interleaved FEC protection, 1 for 1-D non-interleaved FEC 617 protection, and 2 for 2-D parity FEC protection. The ToP value of 618 3 is reserved for future uses. 620 o repair-window: The time that spans the source packets and the 621 corresponding repair packets. The size of the repair window is 622 specified in microseconds. 624 Optional parameters: None. 626 Encoding considerations: This media type is framed (See Section 4.8 627 in the template document [RFC4288]) and contains binary data. 629 Security considerations: See Section 9 of [RFCXXXX]. 631 Interoperability considerations: None. 633 Published specification: [RFCXXXX]. 635 Applications that use this media type: Multimedia applications that 636 want to improve resiliency against packet loss by sending redundant 637 data in addition to the source media. 639 Additional information: None. 641 Person & email address to contact for further information: Ali Begen 642 and IETF Audio/Video Transport Working Group. 644 Intended usage: COMMON. 646 Restriction on usage: This media type depends on RTP framing, and 647 hence, is only defined for transport via RTP [RFC3550]. 649 Author: Ali Begen . 651 Change controller: IETF Audio/Video Transport Working Group 652 delegated from the IESG. 654 5.1.2. Registration of video/non-interleaved-parityfec 656 Type name: video 658 Subtype name: non-interleaved-parityfec 660 Required parameters: 662 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 663 than 1000 Hz to provide sufficient resolution to RTCP operations. 664 However, it is RECOMMENDED to select the rate that matches the 665 rate of the protected source RTP stream. 667 o L: Number of columns of the source block. L is a positive 668 integer. 670 o D: Number of rows of the source block. D is a positive integer. 672 o ToP: Type of the protection applied by the sender: 0 for 1-D 673 interleaved FEC protection, 1 for 1-D non-interleaved FEC 674 protection, and 2 for 2-D parity FEC protection. The ToP value of 675 3 is reserved for future uses. 677 o repair-window: The time that spans the source packets and the 678 corresponding repair packets. The size of the repair window is 679 specified in microseconds. 681 Optional parameters: None. 683 Encoding considerations: This media type is framed (See Section 4.8 684 in the template document [RFC4288]) and contains binary data. 686 Security considerations: See Section 9 of [RFCXXXX]. 688 Interoperability considerations: None. 690 Published specification: [RFCXXXX]. 692 Applications that use this media type: Multimedia applications that 693 want to improve resiliency against packet loss by sending redundant 694 data in addition to the source media. 696 Additional information: None. 698 Person & email address to contact for further information: Ali Begen 699 and IETF Audio/Video Transport Working Group. 701 Intended usage: COMMON. 703 Restriction on usage: This media type depends on RTP framing, and 704 hence, is only defined for transport via RTP [RFC3550]. 706 Author: Ali Begen . 708 Change controller: IETF Audio/Video Transport Working Group 709 delegated from the IESG. 711 5.1.3. Registration of text/non-interleaved-parityfec 713 Type name: text 715 Subtype name: non-interleaved-parityfec 717 Required parameters: 719 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 720 than 1000 Hz to provide sufficient resolution to RTCP operations. 721 However, it is RECOMMENDED to select the rate that matches the 722 rate of the protected source RTP stream. 724 o L: Number of columns of the source block. L is a positive 725 integer. 727 o D: Number of rows of the source block. D is a positive integer. 729 o ToP: Type of the protection applied by the sender: 0 for 1-D 730 interleaved FEC protection, 1 for 1-D non-interleaved FEC 731 protection, and 2 for 2-D parity FEC protection. The ToP value of 732 3 is reserved for future uses. 734 o repair-window: The time that spans the source packets and the 735 corresponding repair packets. The size of the repair window is 736 specified in microseconds. 738 Optional parameters: None. 740 Encoding considerations: This media type is framed (See Section 4.8 741 in the template document [RFC4288]) and contains binary data. 743 Security considerations: See Section 9 of [RFCXXXX]. 745 Interoperability considerations: None. 747 Published specification: [RFCXXXX]. 749 Applications that use this media type: Multimedia applications that 750 want to improve resiliency against packet loss by sending redundant 751 data in addition to the source media. 753 Additional information: None. 755 Person & email address to contact for further information: Ali Begen 756 and IETF Audio/Video Transport Working Group. 758 Intended usage: COMMON. 760 Restriction on usage: This media type depends on RTP framing, and 761 hence, is only defined for transport via RTP [RFC3550]. 763 Author: Ali Begen . 765 Change controller: IETF Audio/Video Transport Working Group 766 delegated from the IESG. 768 5.1.4. Registration of application/non-interleaved-parityfec 770 Type name: application 772 Subtype name: non-interleaved-parityfec 774 Required parameters: 776 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 777 than 1000 Hz to provide sufficient resolution to RTCP operations. 778 However, it is RECOMMENDED to select the rate that matches the 779 rate of the protected source RTP stream. 781 o L: Number of columns of the source block. L is a positive 782 integer. 784 o D: Number of rows of the source block. D is a positive integer. 786 o ToP: Type of the protection applied by the sender: 0 for 1-D 787 interleaved FEC protection, 1 for 1-D non-interleaved FEC 788 protection, and 2 for 2-D parity FEC protection. The ToP value of 789 3 is reserved for future uses. 791 o repair-window: The time that spans the source packets and the 792 corresponding repair packets. The size of the repair window is 793 specified in microseconds. 795 Optional parameters: None. 797 Encoding considerations: This media type is framed (See Section 4.8 798 in the template document [RFC4288]) and contains binary data. 800 Security considerations: See Section 9 of [RFCXXXX]. 802 Interoperability considerations: None. 804 Published specification: [RFCXXXX]. 806 Applications that use this media type: Multimedia applications that 807 want to improve resiliency against packet loss by sending redundant 808 data in addition to the source media. 810 Additional information: None. 812 Person & email address to contact for further information: Ali Begen 813 and IETF Audio/Video Transport Working Group. 815 Intended usage: COMMON. 817 Restriction on usage: This media type depends on RTP framing, and 818 hence, is only defined for transport via RTP [RFC3550]. 820 Author: Ali Begen . 822 Change controller: IETF Audio/Video Transport Working Group 823 delegated from the IESG. 825 5.1.5. Registration of audio/interleaved-parityfec 827 Type name: audio 829 Subtype name: interleaved-parityfec 831 Required parameters: 833 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 834 than 1000 Hz to provide sufficient resolution to RTCP operations. 835 However, it is RECOMMENDED to select the rate that matches the 836 rate of the protected source RTP stream. 838 o L: Number of columns of the source block. L is a positive 839 integer. 841 o D: Number of rows of the source block. D is a positive integer. 843 o ToP: Type of the protection applied by the sender: 0 for 1-D 844 interleaved FEC protection, 1 for 1-D non-interleaved FEC 845 protection, and 2 for 2-D parity FEC protection. The ToP value of 846 3 is reserved for future uses. 848 o repair-window: The time that spans the source packets and the 849 corresponding repair packets. The size of the repair window is 850 specified in microseconds. 852 Optional parameters: None. 854 Encoding considerations: This media type is framed (See Section 4.8 855 in the template document [RFC4288]) and contains binary data. 857 Security considerations: See Section 9 of [RFCXXXX]. 859 Interoperability considerations: None. 861 Published specification: [RFCXXXX]. 863 Applications that use this media type: Multimedia applications that 864 want to improve resiliency against packet loss by sending redundant 865 data in addition to the source media. 867 Additional information: None. 869 Person & email address to contact for further information: Ali Begen 870 and IETF Audio/Video Transport Working Group. 872 Intended usage: COMMON. 874 Restriction on usage: This media type depends on RTP framing, and 875 hence, is only defined for transport via RTP [RFC3550]. 877 Author: Ali Begen . 879 Change controller: IETF Audio/Video Transport Working Group 880 delegated from the IESG. 882 5.1.6. Registration of video/interleaved-parityfec 884 Type name: video 885 Subtype name: interleaved-parityfec 887 Required parameters: 889 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 890 than 1000 Hz to provide sufficient resolution to RTCP operations. 891 However, it is RECOMMENDED to select the rate that matches the 892 rate of the protected source RTP stream. 894 o L: Number of columns of the source block. L is a positive 895 integer. 897 o D: Number of rows of the source block. D is a positive integer. 899 o ToP: Type of the protection applied by the sender: 0 for 1-D 900 interleaved FEC protection, 1 for 1-D non-interleaved FEC 901 protection, and 2 for 2-D parity FEC protection. The ToP value of 902 3 is reserved for future uses. 904 o repair-window: The time that spans the source packets and the 905 corresponding repair packets. The size of the repair window is 906 specified in microseconds. 908 Optional parameters: None. 910 Encoding considerations: This media type is framed (See Section 4.8 911 in the template document [RFC4288]) and contains binary data. 913 Security considerations: See Section 9 of [RFCXXXX]. 915 Interoperability considerations: None. 917 Published specification: [RFCXXXX]. 919 Applications that use this media type: Multimedia applications that 920 want to improve resiliency against packet loss by sending redundant 921 data in addition to the source media. 923 Additional information: None. 925 Person & email address to contact for further information: Ali Begen 926 and IETF Audio/Video Transport Working Group. 928 Intended usage: COMMON. 930 Restriction on usage: This media type depends on RTP framing, and 931 hence, is only defined for transport via RTP [RFC3550]. 933 Author: Ali Begen . 935 Change controller: IETF Audio/Video Transport Working Group 936 delegated from the IESG. 938 5.1.7. Registration of text/interleaved-parityfec 940 Type name: text 942 Subtype name: interleaved-parityfec 944 Required parameters: 946 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 947 than 1000 Hz to provide sufficient resolution to RTCP operations. 948 However, it is RECOMMENDED to select the rate that matches the 949 rate of the protected source RTP stream. 951 o L: Number of columns of the source block. L is a positive 952 integer. 954 o D: Number of rows of the source block. D is a positive integer. 956 o ToP: Type of the protection applied by the sender: 0 for 1-D 957 interleaved FEC protection, 1 for 1-D non-interleaved FEC 958 protection, and 2 for 2-D parity FEC protection. The ToP value of 959 3 is reserved for future uses. 961 o repair-window: The time that spans the source packets and the 962 corresponding repair packets. The size of the repair window is 963 specified in microseconds. 965 Optional parameters: None. 967 Encoding considerations: This media type is framed (See Section 4.8 968 in the template document [RFC4288]) and contains binary data. 970 Security considerations: See Section 9 of [RFCXXXX]. 972 Interoperability considerations: None. 974 Published specification: [RFCXXXX]. 976 Applications that use this media type: Multimedia applications that 977 want to improve resiliency against packet loss by sending redundant 978 data in addition to the source media. 980 Additional information: None. 982 Person & email address to contact for further information: Ali Begen 983 and IETF Audio/Video Transport Working Group. 985 Intended usage: COMMON. 987 Restriction on usage: This media type depends on RTP framing, and 988 hence, is only defined for transport via RTP [RFC3550]. 990 Author: Ali Begen . 992 Change controller: IETF Audio/Video Transport Working Group 993 delegated from the IESG. 995 5.1.8. Registration of application/interleaved-parityfec 997 Type name: application 999 Subtype name: interleaved-parityfec 1001 Required parameters: 1003 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 1004 than 1000 Hz to provide sufficient resolution to RTCP operations. 1005 However, it is RECOMMENDED to select the rate that matches the 1006 rate of the protected source RTP stream. 1008 o L: Number of columns of the source block. L is a positive 1009 integer. 1011 o D: Number of rows of the source block. D is a positive integer. 1013 o ToP: Type of the protection applied by the sender: 0 for 1-D 1014 interleaved FEC protection, 1 for 1-D non-interleaved FEC 1015 protection, and 2 for 2-D parity FEC protection. The ToP value of 1016 3 is reserved for future uses. 1018 o repair-window: The time that spans the source packets and the 1019 corresponding repair packets. The size of the repair window is 1020 specified in microseconds. 1022 Optional parameters: None. 1024 Encoding considerations: This media type is framed (See Section 4.8 1025 in the template document [RFC4288]) and contains binary data. 1027 Security considerations: See Section 9 of [RFCXXXX]. 1029 Interoperability considerations: None. 1031 Published specification: [RFCXXXX]. 1033 Applications that use this media type: Multimedia applications that 1034 want to improve resiliency against packet loss by sending redundant 1035 data in addition to the source media. 1037 Additional information: None. 1039 Person & email address to contact for further information: Ali Begen 1040 and IETF Audio/Video Transport Working Group. 1042 Intended usage: COMMON. 1044 Restriction on usage: This media type depends on RTP framing, and 1045 hence, is only defined for transport via RTP [RFC3550]. 1047 Author: Ali Begen . 1049 Change controller: IETF Audio/Video Transport Working Group 1050 delegated from the IESG. 1052 5.2. Mapping to SDP Parameters 1054 Applications that are using RTP transport commonly use Session 1055 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 1056 The information that is used to specify the media types in an RTP 1057 session has specific mappings to the fields in an SDP description. 1058 In this section, we provide these mappings for the media subtypes 1059 registered by this document. Note that if an application does not 1060 use SDP to describe the RTP sessions, an appropriate mapping must be 1061 defined and used to specify the media types and their parameters for 1062 the control/description protocol employed by the application. 1064 The mapping of the media type specification for "non-interleaved- 1065 parityfec" and "interleaved-parityfec" and their parameters in SDP is 1066 as follows: 1068 o The media type (e.g., "application") goes into the "m=" line as 1069 the media name. 1071 o The media subtype goes into the "a=rtpmap" line as the encoding 1072 name. The RTP clock rate parameter ("rate") also goes into the 1073 "a=rtpmap" line as the clock rate. 1075 o The remaining required payload-format-specific parameters go into 1076 the "a=fmtp" line by copying them directly from the media type 1077 string as a semicolon-separated list of parameter=value pairs. 1079 SDP examples are provided in Section 7. 1081 5.2.1. Offer-Answer Model Considerations 1083 When offering 1-D interleaved parity FEC over RTP using SDP in an 1084 Offer/Answer model [RFC3264], the following considerations apply: 1086 o Each combination of the L and D parameters produces a different 1087 FEC data and is not compatible with any other combination. A 1088 sender application may desire to offer multiple offers with 1089 different sets of L and D values as long as the parameter values 1090 are valid. The receiver SHOULD normally choose the offer that has 1091 a sufficient amount of interleaving. If multiple such offers 1092 exist, the receiver may choose the offer that has the lowest 1093 overhead or the one that requires the smallest amount of 1094 buffering. The selection depends on the application requirements. 1096 o The value for the repair-window parameter depends on the L and D 1097 values and cannot be chosen arbitrarily. More specifically, L and 1098 D values determine the lower limit for the repair-window size. 1099 The upper limit of the repair-window size does not depend on the L 1100 and D values. 1102 o Although combinations with the same L and D values but with 1103 different repair-window sizes produce the same FEC data, such 1104 combinations are still considered different offers. The size of 1105 the repair-window is related to the maximum delay between the 1106 transmission of a source packet and the associated repair packet. 1107 This directly impacts the buffering requirement on the receiver 1108 side and the receiver must consider this when choosing an offer. 1110 o There are no optional format parameters defined for this payload. 1111 Any unknown option in the offer MUST be ignored and deleted from 1112 the answer. If FEC is not desired by the receiver, it can be 1113 deleted from the answer. 1115 5.2.2. Declarative Considerations 1117 In declarative usage, like SDP in the Real-time Streaming Protocol 1118 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 1119 [RFC2974], the following considerations apply: 1121 o The payload format configuration parameters are all declarative 1122 and a participant MUST use the configuration that is provided for 1123 the session. 1125 o More than one configuration may be provided (if desired) by 1126 declaring multiple RTP payload types. In that case, the receivers 1127 should choose the repair flow that is best for them. 1129 6. Protection and Recovery Procedures 1131 This section provides a complete specification of the 1-D and 2-D 1132 parity codes and their RTP payload formats. 1134 6.1. Overview 1136 The following sections specify the steps involved in generating the 1137 repair packets and reconstructing the missing source packets from the 1138 repair packets. 1140 6.2. Repair Packet Construction 1142 The RTP header of a repair packet is formed based on the guidelines 1143 given in Section 4.2. 1145 The FEC header includes 12 octets (or 16 octets when the optional 1146 padding is used). It is constructed by applying the XOR operation on 1147 the bit strings that are generated from the individual source packets 1148 protected by this particular repair packet. The set of the source 1149 packets that are associated with a given repair packet can be 1150 computed by the formula given in Section 6.3.1. 1152 The bit string is formed for each source packet by concatenating the 1153 following fields together in the order specified: 1155 o The first 64 bits of the RTP header (64 bits). 1157 o Unsigned network-ordered 16-bit representation of the source 1158 packet length in bytes minus 12 (for the fixed RTP header), i.e., 1159 the sum of the lengths of all the following if present: the CSRC 1160 list, extension header, RTP payload and RTP padding (16 bits). 1162 By applying the parity operation on the bit strings produced from the 1163 source packets, we generate the FEC bit string. The FEC header is 1164 generated from the FEC bit string as follows: 1166 o The first (most significant) 2 bits in the FEC bit string are 1167 skipped. The E bit in the FEC header is set to 0. The I bit in 1168 the FEC header is set to 0 if only 2-byte padding is used, or to 1 1169 if 6-byte padding is used. 1171 o The next bit in the FEC bit string is written into the P recovery 1172 bit in the FEC header. 1174 o The next bit in the FEC bit string is written into the X recovery 1175 bit in the FEC header. 1177 o The next 4 bits of the FEC bit string are written into the CC 1178 recovery field in the FEC header. 1180 o The next bit is written into the M recovery bit in the FEC header. 1182 o The next 7 bits of the FEC bit string are written into the PT 1183 recovery field in the FEC header. 1185 o The next 16 bits are skipped. 1187 o The next 32 bits of the FEC bit string are written into the TS 1188 recovery field in the FEC header. 1190 o The next 16 bits are written into the length recovery field in the 1191 FEC header. 1193 o The 2-byte padding field of the FEC header SHALL be set to 0. 1195 o If the I bit is set to 1, indicating that 6-byte padding is used, 1196 four more bytes SHALL be added to the FEC header and these bytes 1197 SHALL be set to 0. 1199 As described in Section 4.2, the SN base field of the FEC header MUST 1200 be set to the lowest sequence number of the source packets protected 1201 by this repair packet. For the interleaved FEC packets, this 1202 corresponds to the lowest sequence number of the source packets that 1203 form the column. For the non-interleaved FEC packets, the SN base 1204 field MUST be set to the lowest sequence number of the source packets 1205 that form the row. 1207 The repair packet payload consists of the bits that are generated by 1208 applying the XOR operation on the payloads of the source RTP packets. 1209 If the payload lengths of the source packets are not equal, each 1210 shorter packet MUST be padded to the length of the longest packet by 1211 adding octet 0's at the end. 1213 Due to this possible padding and mandatory FEC header, a repair 1214 packet has a larger size than the source packets it protects. This 1215 may cause problems if the resulting repair packet size exceeds the 1216 Maximum Transmission Unit (MTU) size of the path over which the 1217 repair flow is sent. 1219 6.3. Source Packet Reconstruction 1221 This section describes the recovery procedures that are required to 1222 reconstruct the missing source packets. The recovery process has two 1223 steps. In the first step, the FEC decoder determines which source 1224 and repair packets should be used in order to recover a missing 1225 packet. In the second step, the decoder recovers the missing packet, 1226 which consists of an RTP header and RTP payload. 1228 In the following, we describe the RECOMMENDED algorithms for the 1229 first and second steps. Based on the implementation, different 1230 algorithms MAY be adopted. However, the end result MUST be identical 1231 to the one produced by the algorithms described below. 1233 Note that the same algorithms are used by the 1-D parity codes, 1234 regardless of whether the FEC protection is applied over a column or 1235 a row. The 2-D parity codes, on the other hand, usually require 1236 multiple iterations of the procedures described here. This iterative 1237 decoding algorithm is further explained in Section 6.3.4. 1239 6.3.1. Associating the Source and Repair Packets 1241 The first step is associating the source and repair packets. By 1242 virtue of the payload type field in the RTP header, each repair 1243 packet is indicated whether it is an interleaved or non-interleaved 1244 FEC packet. In addition, the SN base field in the FEC header shows 1245 the lowest sequence number of the source packets that form the 1246 particular column or row. Finally, the information of how many 1247 source packets are included in each column or row is available from 1248 the media type parameters specified in the SDP description. This set 1249 of information uniquely identifies all of the source packets 1250 associated with a given repair packet. 1252 Mathematically, for any received repair packet, p*, we can determine 1253 the sequence numbers of the source packets that are protected by this 1254 repair packet as follows: 1256 p*_snb + i * X_1 (modulo 65536) 1258 where p*_snb denotes the value in the SN base field of p*'s FEC 1259 header, X_1 is set to L and 1 for the interleaved and non-interleaved 1260 FEC packets, respectively, and 1262 0 <= i < X_2 1264 where X_2 is set to D and L for the interleaved and non-interleaved 1265 FEC packets, respectively. 1267 We denote the set of the source packets associated with repair packet 1268 p* by set T(p*). Note that in a source block whose size is L columns 1269 by D rows, set T includes D source packets plus one repair packet for 1270 the FEC protection applied over a column, and L source packets plus 1271 one repair packet for the FEC protection applied over a row. Recall 1272 that 1-D interleaved and non-interleaved FEC protection can fully 1273 recover the missing information if there is only one source packet 1274 missing in set T. If there are more than one source packets missing 1275 in set T, 1-D FEC protection will not work. 1277 6.3.2. Recovering the RTP Header 1279 For a given set T, the procedure for the recovery of the RTP header 1280 of the missing packet, whose sequence number is denoted by SEQNUM, is 1281 as follows: 1283 1. For each of the source packets that are successfully received in 1284 T, compute the 80-bit string by concatenating the first 64 bits 1285 of their RTP header and the unsigned network-ordered 16-bit 1286 representation of their length in bytes minus 12. 1288 2. For the repair packet in T, compute the FEC bit string from the 1289 first 80 bits of the FEC header. 1291 3. Calculate the recovered bit string as the XOR of the bit strings 1292 generated from all source packets in T and the FEC bit string 1293 generated from the repair packet in T. 1295 4. Create a new packet with the standard 12-byte RTP header and no 1296 payload. 1298 5. Set the version of the new packet to 2. Skip the first 2 bits 1299 in the recovered bit string. 1301 6. Set the Padding bit in the new packet to the next bit in the 1302 recovered bit string. 1304 7. Set the Extension bit in the new packet to the next bit in the 1305 recovered bit string. 1307 8. Set the CC field to the next 4 bits in the recovered bit string. 1309 9. Set the Marker bit in the new packet to the next bit in the 1310 recovered bit string. 1312 10. Set the Payload type in the new packet to the next 7 bits in the 1313 recovered bit string. 1315 11. Set the SN field in the new packet to SEQNUM. Skip the next 16 1316 bits in the recovered bit string. 1318 12. Set the TS field in the new packet to the next 32 bits in the 1319 recovered bit string. 1321 13. Take the next 16 bits of the recovered bit string and set the 1322 new variable Y to whatever unsigned integer this represents 1323 (assuming network order). Convert Y to host order. Y 1324 represents the length of the new packet in bytes minus 12 (for 1325 the fixed RTP header), i.e., the sum of the lengths of all the 1326 following if present: the CSRC list, header extension, RTP 1327 payload and RTP padding. 1329 14. Set the SSRC of the new packet to the SSRC of the source RTP 1330 stream. 1332 This procedure recovers the header of an RTP packet up to (and 1333 including) the SSRC field. 1335 6.3.3. Recovering the RTP Payload 1337 Following the recovery of the RTP header, the procedure for the 1338 recovery of the RTP payload is as follows: 1340 1. Append Y bytes to the new packet. 1342 2. For each of the source packets that are successfully received in 1343 T, compute the bit string from the Y octets of data starting with 1344 the 13th octet of the packet. If any of the bit strings 1345 generated from the source packets has a length shorter than Y, 1346 pad them to that length. The padding of octet 0 MUST be added at 1347 the end of the bit string. Note that the information of the 1348 first 8 octets are protected by the FEC header. 1350 3. For the repair packet in T, compute the FEC bit string from the 1351 repair packet payload, i.e., the Y octets of data following the 1352 FEC header. Note that the FEC header may be 12 octets or 16 1353 octets depending on whether the optional padding is used or not. 1355 4. Calculate the recovered bit string as the XOR of the bit strings 1356 generated from all source packets in T and the FEC bit string 1357 generated from the repair packet in T. 1359 5. Append the recovered bit string (Y octets) to the new packet 1360 generated in Section 6.3.2. 1362 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC Protection 1364 In 2-D parity FEC protection, the sender generates both non- 1365 interleaved and interleaved FEC packets to combat with the mixed loss 1366 patterns (random and bursty). At the receiver side, these FEC 1367 packets are used iteratively to overcome the shortcomings of the 1-D 1368 non-interleaved/interleaved FEC protection and improve the chances of 1369 full error recovery. 1371 The iterative decoding algorithm runs as follows: 1373 1. Set num_recovered_until_this_iteration to zero 1375 2. Set num_recovered_so_far to zero 1377 3. Recover as many source packets as possible by using the non- 1378 interleaved FEC packets as outlined in Section 6.3.2 and 1379 Section 6.3.3, and increase the value of num_recovered_so_far by 1380 the number of recovered source packets. 1382 4. Recover as many source packets as possible by using the 1383 interleaved FEC packets as outlined in Section 6.3.2 and 1384 Section 6.3.3, and increase the value of num_recovered_so_far by 1385 the number of recovered source packets. 1387 5. If num_recovered_so_far > num_recovered_until_this_iteration 1388 ---num_recovered_until_this_iteration = num_recovered_so_far 1389 ---Go to step 3 1390 Else 1391 ---Terminate 1393 The algorithm terminates either when all missing source packets are 1394 fully recovered or when there are still remaining missing source 1395 packets but the FEC packets are not able to recover any more source 1396 packets. For the example scenarios when the 2-D parity FEC 1397 protection fails full recovery, refer to Section 1.2. Upon 1398 termination, variable num_recovered_so_far has a value equal to the 1399 total number of recovered source packets. 1401 Example: 1403 Suppose that the receiver experienced the loss pattern sketched in 1404 Figure 11. 1406 +---+ +---+ +===+ 1407 X X | 3 | | 4 | |R_1| 1408 +---+ +---+ +===+ 1410 +---+ +---+ +---+ +---+ +===+ 1411 | 5 | | 6 | | 7 | | 8 | |R_2| 1412 +---+ +---+ +---+ +---+ +===+ 1414 +---+ +---+ +===+ 1415 | 9 | X X | 12| |R_3| 1416 +---+ +---+ +===+ 1418 +===+ +===+ +===+ +===+ 1419 |C_1| |C_2| |C_3| |C_4| 1420 +===+ +===+ +===+ +===+ 1422 Figure 11: Example loss pattern for the iterative decoding algorithm 1424 The receiver executes the iterative decoding algorithm and recovers 1425 source packets #1 and #11 in the first iteration. The resulting 1426 pattern is sketched in Figure 12. 1428 +---+ +---+ +---+ +===+ 1429 | 1 | X | 3 | | 4 | |R_1| 1430 +---+ +---+ +---+ +===+ 1432 +---+ +---+ +---+ +---+ +===+ 1433 | 5 | | 6 | | 7 | | 8 | |R_2| 1434 +---+ +---+ +---+ +---+ +===+ 1436 +---+ +---+ +---+ +===+ 1437 | 9 | X | 11| | 12| |R_3| 1438 +---+ +---+ +---+ +===+ 1440 +===+ +===+ +===+ +===+ 1441 |C_1| |C_2| |C_3| |C_4| 1442 +===+ +===+ +===+ +===+ 1444 Figure 12: The resulting pattern after the first iteration 1446 Since the if condition holds true, the receiver runs a new iteration. 1447 In the second iteration, source packets #2 and #10 are recovered, 1448 resulting in a full recovery as sketched in Figure 13. 1450 +---+ +---+ +---+ +---+ +===+ 1451 | 1 | | 2 | | 3 | | 4 | |R_1| 1452 +---+ +---+ +---+ +---+ +===+ 1454 +---+ +---+ +---+ +---+ +===+ 1455 | 5 | | 6 | | 7 | | 8 | |R_2| 1456 +---+ +---+ +---+ +---+ +===+ 1458 +---+ +---+ +---+ +---+ +===+ 1459 | 9 | | 10| | 11| | 12| |R_3| 1460 +---+ +---+ +---+ +---+ +===+ 1462 +===+ +===+ +===+ +===+ 1463 |C_1| |C_2| |C_3| |C_4| 1464 +===+ +===+ +===+ +===+ 1466 Figure 13: The resulting pattern after the second iteration 1468 7. SDP Examples 1470 This section provides two SDP [RFC4566] examples. The examples use 1471 the FEC grouping semantics defined in [RFC4756]. 1473 7.1. Example SDP for 1-D Parity FEC Protection 1475 In this example, we have one source video stream (mid:S1) and one FEC 1476 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 1477 S1 R1" line. The source and repair streams are sent to the same port 1478 on different multicast groups. The repair window is set to 200 ms. 1480 v=0 1481 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1482 s=1-D Interleaved Parity FEC Example 1483 t=0 0 1484 a=group:FEC S1 R1 1485 m=video 30000 RTP/AVP 100 1486 c=IN IP4 233.252.0.1/127 1487 a=rtpmap:100 MP2T/90000 1488 a=mid:S1 1489 m=application 30000 RTP/AVP 110 1490 c=IN IP4 233.252.0.2/127 1491 a=rtpmap:110 interleaved-parityfec/90000 1492 a=fmtp:110 L:5; D:10; ToP:0; repair-window:200000 1493 a=mid:R1 1495 7.2. Example SDP for 2-D Parity FEC Protection 1497 In this example, we have one source video stream (mid:S1) and two FEC 1498 repair streams (mid:R1 and mid:R2). We form one FEC group with the 1499 "a=group:FEC S1 R1 R2" line. The source and repair streams are sent 1500 to the same port on different multicast groups. The repair window is 1501 set to 200 ms. 1503 v=0 1504 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1505 s=2-D Parity FEC Example 1506 t=0 0 1507 a=group:FEC S1 R1 R2 1508 m=video 30000 RTP/AVP 100 1509 c=IN IP4 233.252.0.1/127 1510 a=rtpmap:100 MP2T/90000 1511 a=mid:S1 1512 m=application 30000 RTP/AVP 110 1513 c=IN IP4 233.252.0.2/127 1514 a=rtpmap:110 interleaved-parityfec/90000 1515 a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000 1516 a=mid:R1 1517 m=application 30000 RTP/AVP 111 1518 c=IN IP4 233.252.0.3/127 1519 a=rtpmap:111 non-interleaved-parityfec/90000 1520 a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000 1521 a=mid:R2 1523 Note that the sender might be generating two repair flows carrying 1524 non-interleaved and interleaved FEC packets, however the receiver 1525 might be interested only in the interleaved FEC packets. The 1526 receiver can identify the repair flow carrying the desired repair 1527 data by checking the payload types associated with each repair flow 1528 described in the SDP description. 1530 8. Congestion Control Considerations 1532 FEC is an effective approach to provide applications resiliency 1533 against packet losses. However, in networks where the congestion is 1534 a major contributor to the packet loss, the potential impacts of 1535 using FEC SHOULD be considered carefully before injecting the repair 1536 flows into the network. In particular, in bandwidth-limited 1537 networks, FEC repair flows may consume most or all of the available 1538 bandwidth and consequently may congest the network. In such cases, 1539 the applications MUST NOT arbitrarily increase the amount of FEC 1540 protection since doing so may lead to a congestion collapse. If 1541 desired, stronger FEC protection MAY be applied only after the source 1542 rate has been reduced. 1544 In a network-friendly implementation, an application SHOULD NOT send/ 1545 receive FEC repair flows if it knows that sending/receiving those FEC 1546 repair flows would not help at all in recovering the missing packets. 1547 Such a practice helps reduce the amount of wasted bandwidth. It is 1548 RECOMMENDED that the amount of FEC protection is adjusted dynamically 1549 based on the packet loss rate observed by the applications. 1551 In multicast scenarios, it may be difficult to optimize the FEC 1552 protection per receiver. If there is a large variation among the 1553 levels of FEC protection needed by different receivers, it is 1554 RECOMMENDED that the sender offers multiple repair flows with 1555 different levels of FEC protection and the receivers join the 1556 corresponding multicast sessions to receive the repair flow(s) that 1557 is best for them. 1559 Editor's note: Additional congestion control considerations 1560 regarding the use of 2-D parity codes should be added here. 1562 9. Security Considerations 1564 RTP packets using the payload format defined in this specification 1565 are subject to the security considerations discussed in the RTP 1566 specification [RFC3550] and in any applicable RTP profile. The main 1567 security considerations for the RTP packet carrying the RTP payload 1568 format defined within this memo are confidentiality, integrity and 1569 source authenticity. Confidentiality is achieved by encrypting the 1570 RTP payload. Integrity of the RTP packets is achieved through a 1571 suitable cryptographic integrity protection mechanism. Such a 1572 cryptographic system may also allow the authentication of the source 1573 of the payload. A suitable security mechanism for this RTP payload 1574 format should provide confidentiality, integrity protection, and at 1575 least source authentication capable of determining if an RTP packet 1576 is from a member of the RTP session. 1578 Note that the appropriate mechanism to provide security to RTP and 1579 payloads following this memo may vary. It is dependent on the 1580 application, transport and signaling protocol employed. Therefore, a 1581 single mechanism is not sufficient, although if suitable, using the 1582 Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. 1583 Other mechanisms that may be used are IPsec [RFC4301] and Transport 1584 Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may 1585 exist. 1587 10. IANA Considerations 1589 New media subtypes are subject to IANA registration. For the 1590 registration of the payload formats and their parameters introduced 1591 in this document, refer to Section 5. 1593 11. Acknowledgments 1595 Some parts of this document are borrowed from [RFC5109]. Thus, the 1596 author would like to thank the editor of [RFC5109] and those who 1597 contributed to [RFC5109]. 1599 The author would also like to thank the FEC Framework Design Team for 1600 their inputs, suggestions and contributions. 1602 12. Change Log 1604 12.1. draft-ietf-fecframe-1d2d-parity-scheme-01 1606 The following are the major changes compared to version 00: 1608 o Some details were added regarding the use of CNAME field. 1610 o Offer-Answer and Declarative Considerations sections have been 1611 completed. 1613 o Security Considerations section has been completed. 1615 12.2. draft-ietf-fecframe-1d2d-parity-scheme-00 1617 This is the initial version, which is based on an earlier individual 1618 submission. The following are the major changes compared to that 1619 document: 1621 o The timestamp field definition has changed. 1623 13. References 1625 13.1. Normative References 1627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1628 Requirement Levels", BCP 14, RFC 2119, March 1997. 1630 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1631 Jacobson, "RTP: A Transport Protocol for Real-Time 1632 Applications", STD 64, RFC 3550, July 2003. 1634 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1635 Description Protocol", RFC 4566, July 2006. 1637 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1638 Registration Procedures", BCP 13, RFC 4288, December 2005. 1640 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1641 Payload Formats", RFC 3555, July 2003. 1643 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 1644 Session Description Protocol", RFC 4756, November 2006. 1646 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1647 with Session Description Protocol (SDP)", RFC 3264, 1648 June 2002. 1650 13.2. Informative References 1652 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1653 for Generic Forward Error Correction", RFC 2733, 1654 December 1999. 1656 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1657 Correction", RFC 5109, December 2007. 1659 [SMPTE2022-1] 1660 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 1661 Video/Audio Transport over IP Networks", 2007. 1663 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1664 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1666 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1667 Announcement Protocol", RFC 2974, October 2000. 1669 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1670 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1671 RFC 3711, March 2004. 1673 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1674 Internet Protocol", RFC 4301, December 2005. 1676 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1677 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1679 Author's Address 1681 Ali Begen 1682 Cisco Systems 1683 170 West Tasman Drive 1684 San Jose, CA 95134 1685 USA 1687 Email: abegen@cisco.com