idnits 2.17.1 draft-ietf-fecframe-interleaved-fec-scheme-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1261. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5659 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) == Outdated reference: A later version (-04) exists of draft-ietf-fecframe-dvb-al-fec-00 -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3009 (Obsoleted by RFC 5109) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track October 27, 2008 5 Expires: April 30, 2009 7 RTP Payload Format for 1-D Interleaved Parity FEC 8 draft-ietf-fecframe-interleaved-fec-scheme-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 30, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document defines a new RTP payload format for the Forward Error 42 Correction (FEC) that is generated by the 1-D interleaved parity code 43 from a source media encapsulated in RTP. The 1-D interleaved parity 44 code is a systematic code, where a number of repair symbols are 45 generated from a set of source symbols and sent in a repair flow 46 separate from the source flow that carries the source symbols. The 47 1-D interleaved parity code offers a good protection against bursty 48 packet losses at a cost of decent complexity. The new payload format 49 defined in this document is used as a part of the DVB Application- 50 layer FEC Specification. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 56 1.2. Overhead Computation . . . . . . . . . . . . . . . . . . . 8 57 1.3. Relation to Existing Specifications . . . . . . . . . . . 8 58 1.3.1. RFC 2733 and RFC 3009 . . . . . . . . . . . . . . . . 8 59 1.3.2. SMPTE 2022-1 . . . . . . . . . . . . . . . . . . . . . 8 60 1.3.3. ETSI TS 102 034 . . . . . . . . . . . . . . . . . . . 9 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 9 62 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 10 63 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10 66 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . . 11 68 4.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14 70 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 14 71 5.1.1. Registration of audio/1d-interleaved-parityfec . . . . 14 72 5.1.2. Registration of video/1d-interleaved-parityfec . . . . 15 73 5.1.3. Registration of text/1d-interleaved-parityfec . . . . 17 74 5.1.4. Registration of 75 application/1d-interleaved-parityfec . . . . . . . . . 18 76 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 19 77 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 20 78 5.2.2. Declarative Considerations . . . . . . . . . . . . . . 20 79 6. Protection and Recovery Procedures . . . . . . . . . . . . . . 20 80 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 20 82 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 22 83 6.3.1. Associating the Source and Repair Packets . . . . . . 23 84 6.3.2. Recovering the RTP Header and Payload . . . . . . . . 23 85 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 25 86 8. Congestion Control Considerations . . . . . . . . . . . . . . 25 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 90 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 12.1. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 26 92 12.2. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 26 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 95 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 Intellectual Property and Copyright Statements . . . . . . . . . . 29 100 1. Introduction 102 This document extends the Forward Error Correction (FEC) header 103 defined in [RFC2733] and uses this new FEC header for the FEC that is 104 generated by the 1-D interleaved parity code from a source media 105 encapsulated in RTP [RFC3550]. The resulting new RTP payload format 106 is registered by this document. 108 The type of the source media protected by the 1-D interleaved parity 109 code can be audio, video, text or application. The FEC data are 110 generated according to the media type parameters that are 111 communicated through out-of-band means. The associations/ 112 relationships between the source and repair flows are also 113 communicated through out-of-band means. 115 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 116 to generate the repair symbols. In a nutshell, the following steps 117 take place: 119 1. The sender determines a set of source packets to be protected 120 together based on the media type parameters. 122 2. The sender applies the XOR operation on the source symbols to 123 generate the required number of repair symbols. 125 3. The sender packetizes the repair symbols and sends the repair 126 packet(s) along with the source packets to the receiver(s) (in 127 different flows). The repair packets MAY be sent proactively or 128 on-demand. 130 Note that the sender MUST transmit the source and repair packets in 131 different source and repair flows, respectively to offer backward 132 compatibility (See Section 4). At the receiver side, if all of the 133 source packets are successfully received, there is no need for FEC 134 recovery and the repair packets are discarded. However, if there are 135 missing source packets, the repair packets can be used to recover the 136 missing information. Block diagrams for the systematic parity FEC 137 encoder and decoder are sketched in Figure 1 and Figure 2, 138 respectively. 140 +------------+ 141 +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 142 +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 143 | Encoder | 144 | (Sender) | --> +==+ +==+ 145 +------------+ +==+ +==+ 147 Source Packet: +--+ Repair Packet: +==+ 148 +--+ +==+ 150 Figure 1: Block diagram for systematic parity FEC encoder 152 +------------+ 153 +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 154 +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 155 | Decoder | 156 +==+ +==+ --> | (Receiver) | 157 +==+ +==+ +------------+ 159 Source Packet: +--+ Repair Packet: +==+ Lost Packet: X 160 +--+ +==+ 162 Figure 2: Block diagram for systematic parity FEC decoder 164 Suppose that we have a group of D x L source packets that have 165 sequence numbers starting from 1 running to D x L. If we apply the 166 XOR operation to the group of the source packets whose sequence 167 numbers are L apart from each other as sketched in Figure 3, we 168 generate L repair packets. This process is referred to as 1-D 169 interleaved FEC protection, and the resulting L repair packets are 170 referred to as interleaved (or column) FEC packets. 172 +-------------+ +-------------+ +-------------+ +-------+ 173 | S_1 | | S_2 | | S3 | ... | S_L | 174 | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | 175 | . | | . | | | | | 176 | . | | . | | | | | 177 | . | | . | | | | | 178 | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | 179 +-------------+ +-------------+ +-------------+ +-------+ 180 + + + + 181 ------------- ------------- ------------- ------- 182 | XOR | | XOR | | XOR | ... | XOR | 183 ------------- ------------- ------------- ------- 184 = = = = 185 +===+ +===+ +===+ +===+ 186 |C_1| |C_2| |C_3| ... |C_L| 187 +===+ +===+ +===+ +===+ 189 Figure 3: Generating interleaved (column) FEC packets 191 In Figure 3, S_n and C_m denote the source packet with a sequence 192 number n and the interleaved (column) FEC packet with a sequence 193 number m, respectively. 195 1.1. Use Cases 197 We generate one interleaved FEC packet out of D non-consecutive 198 source packets. This repair packet can provide a full recovery of 199 the missing information if there is only one packet missing among the 200 corresponding source packets. This implies that 1-D interleaved FEC 201 protection performs well under bursty loss conditions provided that L 202 is chosen large enough, i.e., L-packet duration SHOULD NOT be shorter 203 than the duration of the burst that is intended to be repaired. 205 For example, consider the scenario depicted in Figure 4 where the 206 sender generates interleaved FEC packets and a bursty loss hits the 207 source packets. Since the number of columns is larger than the 208 number of packets lost due to the bursty loss, the repair operation 209 succeeds. 211 +---+ 212 | 1 | X X X 213 +---+ 215 +---+ +---+ +---+ +---+ 216 | 5 | | 6 | | 7 | | 8 | 217 +---+ +---+ +---+ +---+ 219 +---+ +---+ +---+ +---+ 220 | 9 | | 10| | 11| | 12| 221 +---+ +---+ +---+ +---+ 223 +===+ +===+ +===+ +===+ 224 |C_1| |C_2| |C_3| |C_4| 225 +===+ +===+ +===+ +===+ 227 Figure 4: Example scenario where 1-D interleaved FEC protection 228 succeeds error recovery 230 The sender may generate interleaved FEC packets to combat with the 231 bursty packet losses. However, two or more random packet losses may 232 hit the source and repair packets in the same column. In that case, 233 the repair operation fails. This is illustrated in Figure 5. Note 234 that it is possible that two or more bursty losses may occur in the 235 same source block, in which case interleaved FEC packets may still 236 fail to recover the lost data. 238 +---+ +---+ +---+ 239 | 1 | X | 3 | | 4 | 240 +---+ +---+ +---+ 242 +---+ +---+ +---+ 243 | 5 | X | 7 | | 8 | 244 +---+ +---+ +---+ 246 +---+ +---+ +---+ +---+ 247 | 9 | | 10| | 11| | 12| 248 +---+ +---+ +---+ +---+ 250 +===+ +===+ +===+ +===+ 251 |C_1| |C_2| |C_3| |C_4| 252 +===+ +===+ +===+ +===+ 254 Figure 5: Example scenario where 1-D interleaved FEC protection fails 255 error recovery 257 1.2. Overhead Computation 259 The overhead is defined as the ratio of the number of bytes belonging 260 to the repair packets to the number of bytes belonging to the 261 protected source packets. 263 Assuming that each repair packet carries an equal number of bytes 264 carried by a source packet, we can compute the overhead as follows: 266 Overhead = 1/D 268 where D is the number of rows in the source block. 270 1.3. Relation to Existing Specifications 272 This section discusses the relation of the current specification to 273 other existing specifications. 275 1.3.1. RFC 2733 and RFC 3009 277 The current specification extends the FEC header defined in [RFC2733] 278 and registers a new RTP payload format. This new payload format is 279 not backward compatible with the payload format that was registered 280 by [RFC3009]. 282 1.3.2. SMPTE 2022-1 284 In 2007, the Society of Motion Picture and Television Engineers 285 (SMPTE) - Technology Committee N26 on File Management and Networking 286 Technology - decided to revise the Pro-MPEG Code of Practice (CoP) #3 287 Release 2 specification, which (was initially produced by the Pro- 288 MPEG Forum in 2004) discussed the several aspects of the transmission 289 of MPEG-2 transport streams over IP networks. The new SMPTE 290 specification is referred to as [SMPTE2022-1]. 292 The Pro-MPEG CoP #3 r2 document was originally based on [RFC2733]. 293 SMPTE revised the document by extending the FEC header (by setting 294 the E bit) proposed in [RFC2733]. This extended header offers some 295 improvements. 297 For example, instead of utilizing the bitmap field used in [RFC2733], 298 [SMPTE2022-1] introduces separate fields to convey the number of rows 299 (D) and columns (L) of the source block as well as the type of the 300 repair packet (i.e., whether the repair packet is an interleaved FEC 301 packet computed over a column or a non-interleaved FEC packet 302 computed over a row). These fields plus the base sequence number 303 allow the receiver side to establish the associations between the 304 source and repair packets. Note that although the bitmap field is 305 not utilized, the FEC header of [SMPTE2022-1] inherently carries over 306 the bitmap field from [RFC2733]. 308 On the other hand, some parts of [SMPTE2022-1] are not in compliant 309 with RTP [RFC3550]. For example, [SMPTE2022-1] sets the SSRC field 310 to zero and does not use the timestamp field in the RTP headers of 311 the repair packets (Receivers ignore the timestamps of the repair 312 packets). Furthermore, [SMPTE2022-1] also sets the CC field in the 313 RTP header to zero and does not allow any Contributing Source (CSRC) 314 entry in the RTP header. 316 The current document adopts the extended FEC header of [SMPTE2022-1] 317 and registers a new RTP payload format. At the same time, this 318 document fixes the parts of [SMPTE2022-1] that are not in compliant 319 with RTP [RFC3550]. 321 1.3.3. ETSI TS 102 034 323 In 2007, the Digital Video Broadcasting (DVB) consortium published a 324 technical specification [ETSI-TS-102-034] through European 325 Telecommunications Standards Institute (ETSI). This specification 326 covers several areas related to the transmission of MPEG-2 transport 327 stream-based services over IP networks. 329 The Annex E of [ETSI-TS-102-034] defines an optional protocol for 330 Application-layer FEC (AL-FEC) protection of streaming media for 331 DVB-IP services carried over RTP [RFC3550] transport. AL-FEC 332 protocol uses two layers for protection: a base layer that is 333 produced by a packet-based interleaved parity code, and an 334 enhancement layer that is produced by a Raptor code. While the use 335 of the enhancement layer is optional, the use of the base layer is 336 mandatory wherever AL-FEC is used. The DVB AL-FEC protocol is also 337 described in [I-D.ietf-fecframe-dvb-al-fec]. 339 The interleaved parity code that is used in the base layer is a 340 subset of [SMPTE2022-1]. In particular, AL-FEC base layer uses only 341 the 1-D interleaved FEC protection from [SMPTE2022-1]. The new RTP 342 payload format that is defined and registered in this document (with 343 some exceptions listed in [I-D.ietf-fecframe-dvb-al-fec]) is used as 344 the AL-FEC base layer. 346 2. Requirements Notation 348 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 349 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 350 document are to be interpreted as described in [RFC2119]. 352 3. Definitions, Notations and Abbreviations 354 The definitions, notations and abbreviations commonly used in this 355 document are summarized in this section. 357 3.1. Definitions 359 This document uses the following definitions: 361 Source Flow: The packet flow(s) carrying the source data and to 362 which FEC protection is to be applied. 364 Repair Flow: The packet flow(s) carrying the repair data. 366 Symbol: A unit of data. Its size, in bytes, is referred to as the 367 symbol size. 369 Source Symbol: The smallest unit of data used during the encoding 370 process. 372 Repair Symbol: Repair symbols are generated from the source symbols. 374 Source Packet: Data packets that contain only source symbols. 376 Repair Packet: Data packets that contain only repair symbols. 378 Source Block: A block of source symbols that are considered together 379 in the encoding process. 381 3.2. Notations 383 o L: Number of columns of the source block. 385 o D: Number of rows of the source block. 387 3.3. Abbreviations 389 o XOR: Bitwise exclusive OR operation. 390 0 XOR 0 = 0 391 0 XOR 1 = 1 392 1 XOR 0 = 1 393 1 XOR 1 = 0 395 4. Packet Formats 397 This section defines the formats of the source and repair packets. 399 4.1. Source Packets 401 The source packets MUST contain the information that identifies the 402 source block and the position within the source block occupied by the 403 packet. Since the source packets that are carried within an RTP 404 stream already contain unique sequence numbers in their RTP headers 405 [RFC3550], we can identify the source packets in a straightforward 406 manner and there is no need to append additional field(s). The 407 primary advantage of not modifying the source packets in any way is 408 that it provides backward compatibility for the receivers that do not 409 support FEC at all. In multicast scenarios, this backward 410 compatibility becomes quite useful as it allows the non-FEC-capable 411 and FEC-capable receivers to receive and interpret the same source 412 packets sent in the same multicast session. 414 4.2. Repair Packets 416 The repair packets MUST contain information that identifies the 417 source block they pertain to and the relationship between the 418 contained repair symbols and the original source block. For this 419 purpose, we use the RTP header of the repair packets as well as 420 another header within the RTP payload, which we refer to as the FEC 421 header, as shown in Figure 7. 423 +------------------------------+ 424 | IP Header | 425 +------------------------------+ 426 | Transport Header | 427 +------------------------------+ 428 | RTP Header | __ 429 +------------------------------+ | 430 | FEC Header | \ 431 +------------------------------+ > RTP Payload 432 | Repair Symbols | / 433 +------------------------------+ __| 435 Figure 7: Format of repair packets 437 The RTP header is formatted according to [RFC3550] with some further 438 clarifications listed below: 440 o Version: The version field is set to 2. 442 o Padding (P) Bit: This bit is obtained by applying protection to 443 the corresponding P bits from the RTP headers of the source 444 packets protected by this repair packet. However, padding octets 445 are never present in a repair packet, independent of the value of 446 the P bit. 448 o Extension (X) Bit: This bit is obtained by applying protection to 449 the corresponding X bits from the RTP headers of the source 450 packets protected by this repair packet. However, an RTP header 451 extension is never present in a repair packet, independent of the 452 value of the X bit. 454 o CSRC Count (CC): This field is obtained by applying protection to 455 the corresponding CC values from the RTP headers of the source 456 packets protected by this repair packet. However, a CSRC list is 457 never present in a repair packet, independent of the value of the 458 CC field. 460 o Marker (M) Bit: This bit is obtained by applying protection to 461 the corresponding M bits from the RTP headers of the source 462 packets protected by this repair packet. 464 o Payload Type: The (dynamic) payload type for the repair packets 465 is determined through out-of-band means. Note that this document 466 registers a new payload format for the repair packets (Refer to 467 Section 5 for details). According to [RFC3550], an RTP receiver 468 that cannot recognize a payload type must discard it. This 469 provides backward compatibility. The FEC mechanisms can then be 470 used in a multicast group with mixed FEC-capable and non-FEC- 471 capable receivers. If a non-FEC-capable receiver receives a 472 repair packet, it will not recognize the payload type, and hence, 473 discards the repair packet. 475 o Sequence Number (SN): The sequence number has the standard 476 definition. It MUST be one higher than the sequence number in the 477 previously transmitted repair packet. The initial value of the 478 sequence number SHOULD be random (unpredictable) [RFC3550]. 480 o Timestamp (TS): The timestamp SHALL be set to a time 481 corresponding to the repair packet's transmission time. Note that 482 the timestamp value has no use in the actual FEC protection 483 process and is usually useful for jitter calculations. 485 o Synchronization Source (SSRC): The SSRC value SHALL be randomly 486 assigned as suggested by [RFC3550]. This allows the sender to 487 multiplex the source and repair flows on the same port, or 488 multiplex multiple repair flows on a single port. The repair 489 flows SHOULD use the RTCP CNAME field to associate themselves with 490 the source flow. Note that due to the randomness of the SSRC 491 assignments, there is a possibility of SSRC collision. In such 492 cases, the collisions MUST be resolved as described in [RFC3550]. 494 Note that the P bit, X bit, CC field and M bit of the source packets 495 are protected by the corresponding bits/fields in the RTP header of 496 the repair packet. On the other hand, the payload of a repair packet 497 protects the concatenation of (if present) the CSRC list, RTP 498 extension, payload and padding of the source RTP packets associated 499 with this repair packet. 501 The FEC header is 16 octets. The format of the FEC header is shown 502 in Figure 8. 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | SN base low | Length recovery | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |E| PT recovery | Mask | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | TS recovery | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |N|D|Type |Index| Offset | NA | SN base ext | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 8: Format of the FEC header 518 The FEC header consists of the following fields: 520 o The SN base low field is used to indicate the lowest sequence 521 number, taking wrap around into account, of those source packets 522 protected by this repair packet. 524 o The Length recovery field is used to determine the length of any 525 recovered packets. 527 o The E bit is the extension flag introduced in [RFC2733] and used 528 to extend the [RFC2733] FEC header. 530 o The PT recovery field is used to determine the payload type of the 531 recovered packets. 533 o The Mask field is not used. 535 o The TS recovery field is used to determine the timestamp of the 536 recovered packets. 538 o The N bit is the extension flag that is reserved for future uses. 540 o The D bit is not used. 542 o The Type field indicates the type of the error-correcting code 543 used. This document defines only one error-correcting code. 545 o The Index field is not used. 547 o The Offset and NA fields are used to indicate the number of 548 columns (L) and rows (D) of the source block, respectively. 550 o The SN base ext field is not used. 552 The details on setting the fields in the FEC header are provided in 553 Section 6.2. 555 It should be noted that a mask-based approach (similar to the one 556 specified in [RFC2733]) may not be very efficient to indicate which 557 source packets in the current source block are associated with a 558 given repair packet. In particular, for the applications that would 559 like to use large source block sizes, the size of the mask that is 560 required to describe the source-repair packet associations may be 561 prohibitively large. Instead, a systematic approach is inherently 562 more efficient. 564 5. Payload Format Parameters 566 This section provides the media subtype registration for the 1-D 567 interleaved parity FEC. The parameters that are required to 568 configure the FEC encoding and decoding operations are also defined 569 in this section. 571 5.1. Media Type Registration 573 This registration is done using the template defined in [RFC4288] and 574 following the guidance provided in [RFC3555]. 576 5.1.1. Registration of audio/1d-interleaved-parityfec 578 Type name: audio 580 Subtype name: 1d-interleaved-parityfec 582 Required parameters: 584 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 585 than 1000 Hz to provide sufficient resolution to RTCP operations. 586 However, it is RECOMMENDED to select the rate that matches the 587 rate of the protected source RTP stream. 589 o L: Number of columns of the source block. L is a positive 590 integer that is less than or equal to 255. 592 o D: Number of rows of the source block. D is a positive integer 593 that is less than or equal to 255. 595 o repair-window: The time that spans the source packets and the 596 corresponding repair packets. An FEC encoder processes a block of 597 source packets and generates a number of repair packets, which are 598 then transmitted within a certain duration. At the receiver, the 599 FEC decoder tries to decode all the packets received within the 600 repair window to recover the missing packets. Assuming that there 601 is no issue of delay variation, the FEC decoder SHOULD NOT wait 602 longer than the repair window since additional waiting would not 603 help the recovery process. The size of the repair window is 604 specified in microseconds. 606 Optional parameters: None. 608 Encoding considerations: This media type is framed (See Section 4.8 609 in the template document [RFC4288]) and contains binary data. 611 Security considerations: See Section 9 of this document. 613 Interoperability considerations: None. 615 Published specification: This document. 617 Applications that use this media type: Multimedia applications that 618 want to improve resiliency against packet loss by sending redundant 619 data in addition to the source media. 621 Additional information: None. 623 Person & email address to contact for further information: Ali Begen 624 and IETF Audio/Video Transport Working Group. 626 Intended usage: COMMON. 628 Restriction on usage: None. 630 Author: Ali Begen . 632 Change controller: IETF Audio/Video Transport Working Group 633 delegated from the IESG. 635 5.1.2. Registration of video/1d-interleaved-parityfec 637 Type name: video 639 Subtype name: 1d-interleaved-parityfec 640 Required parameters: 642 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 643 than 1000 Hz to provide sufficient resolution to RTCP operations. 644 However, it is RECOMMENDED to select the rate that matches the 645 rate of the protected source RTP stream. 647 o L: Number of columns of the source block. L is a positive 648 integer that is less than or equal to 255. 650 o D: Number of rows of the source block. D is a positive integer 651 that is less than or equal to 255. 653 o repair-window: The time that spans the source packets and the 654 corresponding repair packets. An FEC encoder processes a block of 655 source packets and generates a number of repair packets, which are 656 then transmitted within a certain duration. At the receiver, the 657 FEC decoder tries to decode all the packets received within the 658 repair window to recover the missing packets. Assuming that there 659 is no issue of delay variation, the FEC decoder SHOULD NOT wait 660 longer than the repair window since additional waiting would not 661 help the recovery process. The size of the repair window is 662 specified in microseconds. 664 Optional parameters: None. 666 Encoding considerations: This media type is framed (See Section 4.8 667 in the template document [RFC4288]) and contains binary data. 669 Security considerations: See Section 9 of this document. 671 Interoperability considerations: None. 673 Published specification: This document. 675 Applications that use this media type: Multimedia applications that 676 want to improve resiliency against packet loss by sending redundant 677 data in addition to the source media. 679 Additional information: None. 681 Person & email address to contact for further information: Ali Begen 682 and IETF Audio/Video Transport Working Group. 684 Intended usage: COMMON. 686 Restriction on usage: None. 688 Author: Ali Begen . 690 Change controller: IETF Audio/Video Transport Working Group 691 delegated from the IESG. 693 5.1.3. Registration of text/1d-interleaved-parityfec 695 Type name: text 697 Subtype name: 1d-interleaved-parityfec 699 Required parameters: 701 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 702 than 1000 Hz to provide sufficient resolution to RTCP operations. 703 However, it is RECOMMENDED to select the rate that matches the 704 rate of the protected source RTP stream. 706 o L: Number of columns of the source block. L is a positive 707 integer that is less than or equal to 255. 709 o D: Number of rows of the source block. D is a positive integer 710 that is less than or equal to 255. 712 o repair-window: The time that spans the source packets and the 713 corresponding repair packets. An FEC encoder processes a block of 714 source packets and generates a number of repair packets, which are 715 then transmitted within a certain duration. At the receiver, the 716 FEC decoder tries to decode all the packets received within the 717 repair window to recover the missing packets. Assuming that there 718 is no issue of delay variation, the FEC decoder SHOULD NOT wait 719 longer than the repair window since additional waiting would not 720 help the recovery process. The size of the repair window is 721 specified in microseconds. 723 Optional parameters: None. 725 Encoding considerations: This media type is framed (See Section 4.8 726 in the template document [RFC4288]) and contains binary data. 728 Security considerations: See Section 9 of this document. 730 Interoperability considerations: None. 732 Published specification: This document. 734 Applications that use this media type: Multimedia applications that 735 want to improve resiliency against packet loss by sending redundant 736 data in addition to the source media. 738 Additional information: None. 740 Person & email address to contact for further information: Ali Begen 741 and IETF Audio/Video Transport Working Group. 743 Intended usage: COMMON. 745 Restriction on usage: None. 747 Author: Ali Begen . 749 Change controller: IETF Audio/Video Transport Working Group 750 delegated from the IESG. 752 5.1.4. Registration of application/1d-interleaved-parityfec 754 Type name: application 756 Subtype name: 1d-interleaved-parityfec 758 Required parameters: 760 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 761 than 1000 Hz to provide sufficient resolution to RTCP operations. 762 However, it is RECOMMENDED to select the rate that matches the 763 rate of the protected source RTP stream. 765 o L: Number of columns of the source block. L is a positive 766 integer that is less than or equal to 255. 768 o D: Number of rows of the source block. D is a positive integer 769 that is less than or equal to 255. 771 o repair-window: The time that spans the source packets and the 772 corresponding repair packets. An FEC encoder processes a block of 773 source packets and generates a number of repair packets, which are 774 then transmitted within a certain duration. At the receiver, the 775 FEC decoder tries to decode all the packets received within the 776 repair window to recover the missing packets. Assuming that there 777 is no issue of delay variation, the FEC decoder SHOULD NOT wait 778 longer than the repair window since additional waiting would not 779 help the recovery process. The size of the repair window is 780 specified in microseconds. 782 Optional parameters: None. 784 Encoding considerations: This media type is framed (See Section 4.8 785 in the template document [RFC4288]) and contains binary data. 787 Security considerations: See Section 9 of this document. 789 Interoperability considerations: None. 791 Published specification: This document. 793 Applications that use this media type: Multimedia applications that 794 want to improve resiliency against packet loss by sending redundant 795 data in addition to the source media. 797 Additional information: None. 799 Person & email address to contact for further information: Ali Begen 800 and IETF Audio/Video Transport Working Group. 802 Intended usage: COMMON. 804 Restriction on usage: None. 806 Author: Ali Begen . 808 Change controller: IETF Audio/Video Transport Working Group 809 delegated from the IESG. 811 5.2. Mapping to SDP Parameters 813 Applications that are using RTP transport commonly use Session 814 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 815 The information that is used to specify the media types in an RTP 816 session has specific mappings to the fields in an SDP description. 817 In this section, we provide these mappings for the media subtype 818 registered by this document ("1d-interleaved-parityfec"). Note that 819 if an application does not use SDP to describe the RTP sessions, an 820 appropriate mapping must be defined and used to specify the media 821 types and their parameters for the control/description protocol 822 employed by the application. 824 The mapping of the media type specification for "1d-interleaved- 825 parityfec" and its parameters in SDP is as follows: 827 o The media type (e.g., "application") goes into the "m=" line as 828 the media name. 830 o The media subtype ("1d-interleaved-parityfec") goes into the 831 "a=rtpmap" line as the encoding name. The RTP clock rate 832 parameter ("rate") also goes into the "a=rtpmap" line as the clock 833 rate. 835 o The remaining required payload-format-specific parameters go into 836 the "a=fmtp" line by copying them directly from the media type 837 string as a semicolon-separated list of parameter=value pairs. 839 SDP examples are provided in Section 7. 841 5.2.1. Offer-Answer Model Considerations 843 TBC. 845 5.2.2. Declarative Considerations 847 TBC. 849 6. Protection and Recovery Procedures 851 This section provides a complete specification of the 1-D interleaved 852 parity code. 854 6.1. Overview 856 The following sections specify the steps involved in generating the 857 repair packets and reconstructing the missing source packets from the 858 repair packets. 860 6.2. Repair Packet Construction 862 The RTP header of a repair packet is formed based on the guidelines 863 given in Section 4.2. 865 The FEC header includes 16 octets. It is constructed by applying the 866 XOR operation on the bit strings that are generated from the 867 individual source packets protected by this particular repair packet. 868 The set of the source packets that are associated with a given repair 869 packet can be computed by the formula given in Section 6.3.1. 871 The bit string is formed for each source packet by concatenating the 872 following fields together in the order specified: 874 o Padding bit (1 bit) (This is the most significant bit of the bit 875 string) 877 o Extension bit (1 bit) 878 o CC field (4 bits) 880 o Marker bit (1 bit) 882 o PT field (7 bits) 884 o Timestamp (32 bits) 886 o Unsigned network-ordered 16-bit representation of the source 887 packet length in bytes minus 12 (for the fixed RTP header), i.e., 888 the sum of the lengths of all the following if present: the CSRC 889 list, header extension, RTP payload and RTP padding (16 bits) 891 o If CC is nonzero, the CSRC list (variable length) 893 o If X is 1, the header extension (variable length) 895 o Payload (variable length) 897 o Padding, if present (variable length) 899 Note that if the payload lengths of the source packets are not equal, 900 each shorter packet MUST be padded to the length of the longest 901 packet by adding octet 0's at the end. Due to this possible padding 902 and mandatory FEC header, a repair packet usually has a larger size 903 than the source packets it protects. This may cause problems if the 904 resulting repair packet size exceeds the Maximum Transmission Unit 905 (MTU) size of the path over which the repair flow is sent. 907 By applying the parity operation on the bit strings produced from the 908 source packets, we generate the FEC bit string. Some parts of the 909 RTP header and the FEC header of the repair packet are generated from 910 the FEC bit string as follows: 912 o The first (most significant) bit in the FEC bit string is written 913 into the Padding bit in the RTP header of the repair packet. 915 o The next bit in the FEC bit string is written into the Extension 916 bit in the RTP header of the repair packet. 918 o The next 4 bits of the FEC bit string are written into the CC 919 field in the RTP header of the repair packet. 921 o The next bit of the FEC bit string is written into the Marker bit 922 in the RTP header of the repair packet. 924 o The next 7 bits of the FEC bit string are written into the PT 925 recovery field in the FEC header. 927 o The next 32 bits of the FEC bit string are written into the TS 928 recovery field in the FEC header. 930 o The next 16 bits are written into the Length recovery field in the 931 FEC header. This allows the FEC procedure to be applied even when 932 the lengths of the protected source packets are not identical. 934 o The remaining bits are set to be the payload of the repair packet. 936 The remaining parts of the FEC header are set as follows: 938 o The SN base low field MUST be set to the lowest sequence number, 939 taking wrap around into account, of those source packets protected 940 by this repair packet. 942 o The E bit MUST be set to 1 to extend the [RFC2733] FEC header. 944 o The Mask field SHALL be set to 0 and ignored by the receiver. 946 o The N bit SHALL be set to 0 and ignored by the receiver. 948 o The D bit SHALL be set to 0 and ignored by the receiver. 950 o The Type field MUST be set to 0. 952 o The Index field SHALL be set to 0 and ignored by the receiver. 954 o The Offset field MUST be set to the number of columns of the 955 source block (L). 957 o The NA field MUST be set to the number of rows of the source block 958 (D). 960 o The SN base ext field SHALL be set to 0 and ignored by the 961 receiver. 963 6.3. Source Packet Reconstruction 965 This section describes the recovery procedures that are required to 966 reconstruct the missing packets. The recovery process has two steps. 967 In the first step, the FEC decoder determines which source and repair 968 packets should be used in order to recover a missing packet. In the 969 second step, the decoder recovers the missing packet, which consists 970 of an RTP header and RTP payload. 972 In the following, we describe the RECOMMENDED algorithms for the 973 first and second steps. Based on the implementation, different 974 algorithms MAY be adopted. However, the end result MUST be identical 975 to the one produced by the algorithms described below. 977 6.3.1. Associating the Source and Repair Packets 979 The first step is to associate the source and repair packets. The SN 980 base low field in the FEC header shows the lowest sequence number of 981 the source packets that form the particular column. In addition, the 982 information of how many source packets are available in each column 983 and row is available from the media type parameters specified in the 984 SDP description. This set of information uniquely identifies all of 985 the source packets associated with a given repair packet. 987 Mathematically, for any received repair packet, p*, we can determine 988 the sequence numbers of the source packets that are protected by this 989 repair packet as follows: 991 p*_snb + i * L 993 where p*_snb denotes the value in the SN base low field of p*'s FEC 994 header, L is the number of columns of the source block and 996 0 <= i < D 998 where D is the number of rows of the source block. 1000 We denote the set of the source packets associated with repair packet 1001 p* by set T(p*). Note that in a source block whose size is L columns 1002 by D rows, set T includes D source packets. Recall that 1-D 1003 interleaved FEC protection can fully recover the missing information 1004 if there is only one source packet is missing in set T. If the repair 1005 packet that protects the source packets in set T is missing, or the 1006 repair packet is available but two or more source packets are 1007 missing, then missing source packets in set T cannot be recovered by 1008 1-D interleaved FEC protection. 1010 6.3.2. Recovering the RTP Header and Payload 1012 For a given set T, the procedure for the recovery of the RTP header 1013 of the missing packet, whose sequence number is denoted by SEQNUM, is 1014 as follows: 1016 1. For each of the source packets that are successfully received in 1017 set T, compute the bit string as described in Section 6.2. 1019 2. For the repair packet associated with set T, compute the bit 1020 string in the same fashion except use the PT recovery field 1021 instead of the PT field and TS recovery field instead of the 1022 Timestamp field, and set the CSRC list, header extension and 1023 padding to null regardless of the values of the CC field, X bit 1024 and P bit. 1026 3. If any of the bit strings generated from the source packets are 1027 shorter than the bit string generated from the repair packet, 1028 pad them to be the same length as the bit string generated from 1029 the repair packet. For padding, the padding of octet 0 MUST be 1030 added at the end of the bit string. 1032 4. Calculate the recovered bit string as the XOR of the bit strings 1033 generated from all source packets in set T and the FEC bit 1034 string generated from the repair packet associated with set T. 1036 5. Create a new packet with the standard 12-byte RTP header and no 1037 payload. 1039 6. Set the version of the new packet to 2. 1041 7. Set the Padding bit in the new packet to the first bit in the 1042 recovered bit string. 1044 8. Set the Extension bit in the new packet to the next bit in the 1045 recovered bit string. 1047 9. Set the CC field to the next 4 bits in the recovered bit string. 1049 10. Set the Marker bit in the new packet to the next bit in the 1050 recovered bit string. 1052 11. Set the Payload type in the new packet to the next 7 bits in the 1053 recovered bit string. 1055 12. Set the SN field in the new packet to SEQNUM. 1057 13. Set the TS field in the new packet to the next 32 bits in the 1058 recovered bit string. 1060 14. Take the next 16 bits of the recovered bit string and set Y to 1061 whatever unsigned integer this represents (assuming network- 1062 order). Take Y bytes from the recovered bit string and append 1063 them to the new packet. Y represents the length of the new 1064 packet in bytes minus 12 (for the fixed RTP header), i.e., the 1065 sum of the lengths of all the following if present: the CSRC 1066 list, header extension, RTP payload and RTP padding. 1068 15. Set the SSRC of the new packet to the SSRC of the source RTP 1069 stream. 1071 This procedure completely recovers both the header and payload of an 1072 RTP packet. 1074 7. Session Description Protocol (SDP) Signaling 1076 This section provides an SDP [RFC4566] example. The following 1077 example uses the FEC grouping semantics [RFC4756]. 1079 In this example, we have one source video stream (mid:S1) and one FEC 1080 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 1081 S1 R1" line. The source and repair streams are sent to the same port 1082 on different multicast groups. The repair window is set to 200 ms. 1084 v=0 1085 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1086 s=Interleaved Parity FEC Example 1087 t=0 0 1088 a=group:FEC S1 R1 1089 m=video 30000 RTP/AVP 100 1090 c=IN IP4 224.1.1.1/127 1091 a=rtpmap:100 MP2T/90000 1092 a=mid:S1 1093 m=application 30000 RTP/AVP 110 1094 c=IN IP4 224.1.2.1/127 1095 a=rtpmap:110 1d-interleaved-parityfec/90000 1096 a=fmtp:110 L:5; D:10; repair-window: 200000 1097 a=mid:R1 1099 8. Congestion Control Considerations 1101 FEC is an effective approach to provide applications resiliency 1102 against packet losses. However, in networks where the congestion is 1103 a major contributor to the packet loss, the potential impacts of 1104 using FEC SHOULD be considered carefully before injecting the repair 1105 flows into the network. In particular, in bandwidth-limited 1106 networks, FEC repair flows may consume most or all of the available 1107 bandwidth and consequently may congest the network. In such cases, 1108 the applications MUST NOT arbitrarily increase the amount of FEC 1109 protection since doing so may lead to a congestion collapse. If 1110 desired, stronger FEC protection MAY be applied only after the source 1111 rate has been reduced. 1113 In a network-friendly implementation, an application SHOULD NOT send/ 1114 receive FEC repair flows if it knows that sending/receiving those FEC 1115 repair flows would not help at all in recovering the missing packets. 1116 Such a practice helps reduce the amount of wasted bandwidth. It is 1117 RECOMMENDED that the amount of FEC protection is adjusted dynamically 1118 based on the packet loss rate observed by the applications. 1120 In multicast scenarios, it may be difficult to optimize the FEC 1121 protection per receiver. If there is a large variation among the 1122 levels of FEC protection needed by different receivers, it is 1123 RECOMMENDED that the sender offers multiple repair flows with 1124 different levels of FEC protection and the receivers join the 1125 corresponding multicast sessions to receive the repair flow(s) that 1126 is best for them. 1128 9. Security Considerations 1130 TBC. 1132 10. IANA Considerations 1134 New media subtypes are subject to IANA registration. For the 1135 registration of the payload format and its parameters introduced in 1136 this document, refer to Section 5. 1138 11. Acknowledgments 1140 A major part of this document is borrowed from [RFC2733] and 1141 [SMPTE2022-1]. Thus, the author would like to thank the authors and 1142 editors of these earlier specifications. The author also thanks 1143 Colin Perkins for his constructive suggestions for this document. 1145 12. Change Log 1147 12.1. draft-ietf-fecframe-interleaved-fec-scheme-01 1149 The following are the major changes compared to version 00: 1151 o The timestamp field definition has changed. 1153 12.2. draft-ietf-fecframe-interleaved-fec-scheme-00 1155 This is the initial version, which is based on an earlier individual 1156 submission. The following are the major changes compared to that 1157 document: 1159 o Per the discussion in the WG, references to the FEC Framework have 1160 been removed and the document has been turned into a pure RTP 1161 payload format specification. 1163 o A new section is added for congestion control considerations. 1165 o Editorial changes to clarify a few points. 1167 13. References 1169 13.1. Normative References 1171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1172 Requirement Levels", BCP 14, RFC 2119, March 1997. 1174 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1175 Jacobson, "RTP: A Transport Protocol for Real-Time 1176 Applications", STD 64, RFC 3550, July 2003. 1178 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1179 Description Protocol", RFC 4566, July 2006. 1181 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 1182 Session Description Protocol", RFC 4756, November 2006. 1184 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1185 Registration Procedures", BCP 13, RFC 4288, December 2005. 1187 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1188 Payload Formats", RFC 3555, July 2003. 1190 13.2. Informative References 1192 [I-D.ietf-fecframe-dvb-al-fec] 1193 Begen, A. and T. Stockhammer, "DVB Application-Layer 1194 Hybrid FEC Protection", draft-ietf-fecframe-dvb-al-fec-00 1195 (work in progress), August 2008. 1197 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1198 for Generic Forward Error Correction", RFC 2733, 1199 December 1999. 1201 [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of 1202 parityfec MIME types", RFC 3009, November 2000. 1204 [ETSI-TS-102-034] 1205 DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1), 1206 "Transport of MPEG 2 Transport Stream (TS) Based DVB 1207 Services over IP Based Networks", March 2007. 1209 [SMPTE2022-1] 1210 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 1211 Video/Audio Transport over IP Networks", 2007. 1213 Author's Address 1215 Ali Begen 1216 Cisco Systems 1217 170 West Tasman Drive 1218 San Jose, CA 95134 1219 USA 1221 Email: abegen@cisco.com 1223 Full Copyright Statement 1225 Copyright (C) The IETF Trust (2008). 1227 This document is subject to the rights, licenses and restrictions 1228 contained in BCP 78, and except as set forth therein, the authors 1229 retain all their rights. 1231 This document and the information contained herein are provided on an 1232 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1233 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1234 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1235 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1236 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1237 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1239 Intellectual Property 1241 The IETF takes no position regarding the validity or scope of any 1242 Intellectual Property Rights or other rights that might be claimed to 1243 pertain to the implementation or use of the technology described in 1244 this document or the extent to which any license under such rights 1245 might or might not be available; nor does it represent that it has 1246 made any independent effort to identify any such rights. Information 1247 on the procedures with respect to rights in RFC documents can be 1248 found in BCP 78 and BCP 79. 1250 Copies of IPR disclosures made to the IETF Secretariat and any 1251 assurances of licenses to be made available, or the result of an 1252 attempt made to obtain a general license or permission for the use of 1253 such proprietary rights by implementers or users of this 1254 specification can be obtained from the IETF on-line IPR repository at 1255 http://www.ietf.org/ipr. 1257 The IETF invites any interested party to bring to its attention any 1258 copyrights, patents or patent applications, or other proprietary 1259 rights that may cover technology that may be required to implement 1260 this standard. Please address the information to the IETF at 1261 ietf-ipr@ietf.org. 1263 Acknowledgment 1265 Funding for the RFC Editor function is provided by the IETF 1266 Administrative Support Activity (IASA).