idnits 2.17.1 draft-galanos-fecframe-rtp-reedsolomon-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (March 14, 2011) is 4792 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) -- Looks like a reference, but probably isn't: '0' on line 349 -- Looks like a reference, but probably isn't: '1' on line 351 -- Looks like a reference, but probably isn't: '3' on line 355 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-14 -- No information found for draft-ietf-avt-reedsolomon - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework S. Galanos 3 Internet-Draft RADVISION 4 Intended status: Standards Track O. Peck 5 Expires: September 15, 2011 Kaminario 6 V. Roca (Ed.) 7 INRIA 8 March 14, 2011 10 RTP Payload Format for Reed Solomon FEC 11 draft-galanos-fecframe-rtp-reedsolomon-03 13 Abstract 15 This document defines an RTP payload format for the Reed-Solomon 16 Forward Error Correction (FEC) codes for the erasure channel. The 17 format defined by this document enables the protection of source 18 media encapsulated in RTP with one or more repair flows and is based 19 on the FEC framework and the SDP Elements for FEC Framework. The 20 Reed-Solomon codes used in this document belong to the class of 21 Maximum Distance Separable (MDS) codes which means they offer optimal 22 protection, and they are effective in front of random or bursty 23 packet losses. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 15, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 61 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 5 62 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Reed Solomon Codes . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Source Block Creation . . . . . . . . . . . . . . . . . . . . 8 67 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. FEC Source Packets . . . . . . . . . . . . . . . . . . . . 10 69 6.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . . 10 70 6.2.1. RTP header format . . . . . . . . . . . . . . . . . . 10 71 6.2.2. Repair FEC Payload ID encoding format . . . . . . . . 11 72 6.2.3. Repair Symbol Format . . . . . . . . . . . . . . . . . 12 73 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 74 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 13 75 7.1.1. Registration of audio/reed-solomon-fec . . . . . . . . 13 76 7.1.2. Registration of video/reed-solomon-fec . . . . . . . . 14 77 7.1.3. Registration of text/reed-solomon-fec . . . . . . . . 15 78 7.1.4. Registration of application/reed-solomon-fec . . . . . 17 79 7.2. Mapping of SDP Parameters . . . . . . . . . . . . . . . . 18 80 8. Protection and Recovery Procedures . . . . . . . . . . . . . . 18 81 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 8.2. FEC Repair Packet Construction . . . . . . . . . . . . . . 19 83 8.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 19 84 8.3.1. Associating the Source and Repair Packets . . . . . . 19 85 8.3.2. Recovering the source packet . . . . . . . . . . . . . 20 86 9. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 10. Implementation Considerations . . . . . . . . . . . . . . . . 21 88 11. Offer/Answer considerations . . . . . . . . . . . . . . . . . 22 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 12.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 22 91 12.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 22 92 12.2.1. Access to Confidential Contents . . . . . . . . . . . 22 93 12.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 23 94 12.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 24 95 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 96 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25 99 15.2. Informative References . . . . . . . . . . . . . . . . . . 25 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 102 1. Introduction 104 This document defines new RTP payload formats for the Forward Error 105 Correction (FEC) that is generated by the Reed-Solomon code. 107 By nature, interactive Real-time applications are extremely sensitive 108 to delay and require very low latency. As a result, retransmission 109 of lost packets and using other closed-loop schemes are not valid 110 options while the use of Forward Error Correction (FEC) is an 111 effective approach. 113 A primary requirement from FEC for real time applications is the 114 ability to correctly recover from both random and bursty packet 115 losses. The Reed-Solomon FEC codes used in this document belong to 116 the class of Maximum Distance Separable (MDS) codes that are optimal 117 in terms of erasure recovery capability for both situations. 119 The format defined by this document enables the protection of media 120 source flow with one or more repair flows without adding additional 121 information to the source packets. Such behavior reduces the delay 122 presented by any FEC scheme and maintains backwards compatibility 123 with non FEC-enabled receivers. 125 Number of previous drafts were composed to draw different FEC schemes 126 suitable for different applications. The scheme defined in this 127 draft is designed to compensate a burst of packet loss over RTP 128 networks with minimum delay, which is needed in interactive IP-based 129 applications such as video conferencing. 131 The method described in this document is generic to all media types 132 and provides the sender with the flexibility of deciding if FEC 133 protection is required and if so, how many protecting packets and how 134 many source packets to use in a block according to network 135 conditions. Furthermore it allows applying unequal error protection 136 that provides different level of protection to different packets. 137 For example, it can be combined with Scalable Video Coding to protect 138 only the base layer packets of the video flow. At the receiver, both 139 the FEC and original media are received. If no media packets are 140 lost, the FEC packets can be ignored. In the event of a loss, the 141 FEC packets can be combined with other received media to recover all 142 or part of the missing media packets. 144 The Reed-Solomon codes used in this document have been specified in 145 [RFC5510] and are compatible with Luigi Rizzo codec (see [Rizzo97]). 146 This document is compliant with the Forward Error Correction (FEC) 147 Framework (described in [I-D.ietf-fecframe-framework]) and SDP 148 Elements for FEC Framework (described in 149 [I-D.ietf-fecframe-sdp-elements] [RFC4566]). This draft completes 151 [I-D.roca-fecframe-rs] by defining Reed-Solomon usage for RTP 152 transport ([RFC3550]) and specifies the appropriate media types (see 153 [RFC4288] [RFC4855] [RFC4856]). 155 2. Requirements Notation 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. Definitions, Notations and Abbreviations 163 This document uses the following definitions and notations. For 164 further definitions that apply to FEC Framework in general, see 165 [I-D.ietf-fecframe-framework]. 167 3.1. Definitions 169 This document uses the following terms and definitions. Some of them 170 are FEC scheme specific and are in line with [RFC5052]: 172 Source symbol: unit of data used during the encoding process. 174 Encoding symbol: unit of data generated by the encoding process. 175 With systematic codes, source symbols are part of the encoding 176 symbols. 178 Repair symbol: encoding symbol that is not a source symbol. 180 Code rate: the k/n ratio, i.e., the ratio between the number of 181 source symbols and the number of encoding symbols. By definition, 182 the code rate is such that: 0 < code rate <= 1. A code rate 183 close to 1 indicates that a small number of repair symbols have 184 been produced during the encoding process. 186 Systematic code: FEC code in which the source symbols are part of 187 the encoding symbols. The Reed-Solomon codes introduced in this 188 document are systematic. 190 Source block: a block of k source symbols that are considered 191 together for the encoding. 193 Packet Erasure Channel: a communication path where packets are 194 either dropped (e.g., by a congested router, or because the number 195 of transmission errors exceeds the correction capabilities of the 196 physical layer codes) or received. When a packet is received, it 197 is assumed that this packet is not corrupted. 199 Some of them are FECFRAME framework specific and are in line with 200 [I-D.ietf-fecframe-framework]: 202 Application Data Unit (ADU): a unit of data coming from (sender) or 203 given to (receiver) the media delivery application. In this 204 document, an ADU MUST use an RTP encapsulation. 206 (Source) ADU Flow: a flow of ADUs from a media delivery application 207 and to which FEC protection is applied. In this document, there 208 MUST be a single ADU flow per FECFRAME framework instance. 210 ADU Block: a set of ADUs that are considered together by the 211 FECFRAME instance for the purpose of the FEC scheme. 213 FEC Framework Configuration Information: the FEC scheme specific 214 information that enables the synchronization of the FECFRAME 215 sender and receiver instances. 217 FEC Source Packet: an RTP data packet submitted to (sender) or 218 received from (receiver) the transport protocol. In this 219 document, FEC Source Packets and ADU MUST be the same (e.g., for 220 backward compatibility purposes). 222 FEC Repair Packet: an RTP repair packet submitted to (sender) or 223 received from (receiver) the transport protocol. It contains a 224 repair symbol along with its Explicit Repair FEC Payload ID. 226 3.2. Notations 228 This document uses the following notations: Some of them are FEC 229 scheme specific: 231 k denotes the number of source symbols in a source block. 233 max_k denotes the maximum number of source symbols for any source 234 block. 236 n_r denotes the number of repair symbols generated for a source 237 block. 239 n denotes the number of encoding symbols generated for a source 240 block. Therefore: n = k + n_r. 242 max_n denotes the maximum number of encoding symbols generated for 243 any source block. 245 E denotes the encoding symbol length in bytes. 247 S denotes the encoding symbol length in units of m-bit elements. 248 When m = 8, then S and E are equal. 250 GF(q) denotes a finite field (also known as Galois Field) with q 251 elements. We assume that q = 2^^m in this document. 253 m defines the length of the elements in the finite field, in 254 bits. In this document, m belongs to {2..16}. 256 q defines the number of elements in the finite field. We have: 257 q = 2^^m in this specification. 259 CR denotes the "code rate", i.e., the k/n ratio. 261 a^^b denotes a raised to the power b. 263 3.3. Abbreviations 265 This document uses the following abbreviations: 267 ADU stands for Application Data Unit. 269 ESI stands for Encoding Symbol ID. 271 FEC stands for Forward Error Correction code. 273 FFCI stands for FEC Framework Configuration Information. 275 RS stands for Reed-Solomon. 277 MDS stands for Maximum Distance Separable code. 279 4. Reed Solomon Codes 281 Reed Solomon codes take a group of k source symbols and generates n - 282 k repair symbols. A receiver needs to receive any k of the n source 283 or repair symbols in order to recover the remaining n-k symbols. As 284 explained in [RFC5510], the Reed-Solomon algorithm operates over 285 m-bit elements, where m is the finite field exponent, GF(2^m), taken 286 from the various encoding symbols. Symbols are composed of S "m-bit 287 elements" each. In the usual case of GF(2^8), elements are bytes and 288 the symbol size S is equal to the symbol size in bytes. 290 The detailed operation and theory behind Reed Solomon codes is out of 291 the scope of this document. For more information on Reed Solomon 292 codes, the reader is referred to [Rizzo97] and [RFC5510]. 294 5. Source Block Creation 296 This draft specifies how to protect an RTP source flow using one or 297 more FEC repair flows. In order to authorize backward compatibility, 298 the source flow is not modified at all by the FEC Scheme (i.e., FEC 299 source packets are identical to the RTP packets received from the 300 application). 302 A source block for the Reed-Solomon code contains k source symbols 303 and encoding generates n_r = n - k repair symbols. In this scheme, 304 each Application Data Unit (ADU) is composed of an RTP packet 305 received from the application and corresponds to a single source 306 symbol. Therefore a source block (also called ADU block) contains 307 exactly k RTP packets. In this scheme, each FEC repair packet 308 contains a single repair symbol generated during Reed-Solomon 309 encoding. Therefore, for this block, the n_r FEC repair packets are 310 transmitted along with the k unmodified FEC source packets. Note 311 that the k and n_r values may vary from one block to another since 312 they depend on the source ADU flow and source block creation 313 algorithm (see below). 315 The following steps MUST be followed in order to create a source 316 block: 318 1. Determine the largest ADU size in bytes of the source block 319 (i.e., the largest RTP packet size, considering both the RTP 320 header and the payload). The encoding symbol length in bytes for 321 this block, E, is given by: E = 2 + largest ADU size. 323 2. For each ADU of this source block, of index i, create a byte 324 array of size E as follows: 326 A. The first two bytes, L[i] (Length), contain the length of 327 this ADU, as an unsigned 16-bit integer stored in network 328 byte order (i.e., big endian). This length is for the ADU 329 itself and does not include the L[i] or Pad[i] fields. 331 B. Append the entire RTP packet (including its RTP header). 333 C. Then zero padding is added after ADU i (if needed) in field 334 Pad[i] for alignment purposes, up to a size of exactly E 335 bytes. Of course, the largest packet of this block does not 336 contain any padding. 338 3. Append all the byte arrays one after the other so that the RTP 339 packets are in increasing RTP sequence number, taking wraparound 340 of the RTP sequence number into account. 342 Figure Figure 1 illustrates how a source block is created from 4 RTP 343 packets, ADU 0 to ADU 3, with different sizes, and FEC repair packets 344 are created. 346 Encoding Symbol Length (E) 347 < --------------------------------------------------------- > 348 +----+-----------------------+------------------------------+ 349 |L[0]| ADU 0 | Pad[0] | 350 +----+----------+------------+------------------------------+ 351 |L[1]| ADU 1 | Pad[1] | 352 +----+----------+-------------------------------------------+ 353 |L[2]| ADU 2 | 354 +----+------+-----------------------------------------------+ 355 |L[3]|ADU 3 | Pad[3] | 356 +----+------+-----------------------------------------------+ 357 \__________________________ _______________________________/ 358 \/ 359 simple FEC encoding 361 +-----------------------------------------------------------+ 362 | Repair 4 | 363 +-----------------------------------------------------------+ 364 . . 365 . . 366 +-----------------------------------------------------------+ 367 | Repair 7 | 368 +-----------------------------------------------------------+ 370 Figure 1: Source block creation, for code rate 1/2 (equal number of 371 source and repair symbols, 4 in this example). 373 Note that neither the initial 2 bytes nor the optional padding are 374 sent over the network (remember that the source packets are sent 375 unmodified, without any extra padding). However, they are considered 376 during FEC encoding. It means that a receiver who lost a certain FEC 377 source packet (e.g., the UDP datagram containing this FEC source 378 packet) will be able to recover the ADUI if FEC decoding succeeds. 379 Thanks to the initial 2 bytes, this receiver will get rid of the 380 padding (if any). 382 6. Packet Formats 384 This section defines the formats of the source and repair packets. 386 6.1. FEC Source Packets 388 The FEC Framework requires that FEC source packets contain 389 information identifying the source block and the position within the 390 source block occupied by the packet. However, in order to maintain 391 backwards compatibility, the scheme defined by this document enables 392 the receiver to get this information without appending additional 393 information to the source packet. Specifically this information is 394 obtained using the combination of sequence number found in the RTP 395 header and information provided in the repair FEC Payload ID of each 396 FEC repair packet. This solution enables both non-FEC-capable and 397 FEC-capable receivers to receive and interpret the same source 398 packets sent in a multicast session. 400 6.2. FEC Repair Packets 402 The FEC repair packets contain information that enables the receiver 403 to reconstruct the source block. This is done by using the RTP 404 header of the FEC repair packets as well as the repair FEC Payload ID 405 dedicated header (see [I-D.ietf-fecframe-framework], section 6.4.1) 406 that is placed within the RTP payload. There MUST be a single repair 407 symbol per FEC repair packet. Figure Figure 2 shows such a FEC 408 repair packet. 410 +------------------------------+ 411 | IP Header | 412 +------------------------------+ 413 | Transport Header | 414 +------------------------------+ 415 | RTP Header | 416 +------------------------------+ \ 417 | Repair FEC Payload ID | | 418 +------------------------------+ > RTP Payload 419 | Repair Symbol | | 420 +------------------------------+ / 422 Figure 2: Format of FEC repair packets 424 6.2.1. RTP header format 426 The RTP header is formatted according to [RFC3550] with some further 427 clarifications listed below: 429 o Marker (M) Bit: This bit is not used for this payload type, and 430 is set to 0. 432 o Payload Type: The (dynamic) payload type for the repair packets 433 is determined through out-of-band means. Note that this document 434 registers new payload formats for the repair packets (Refer to 435 Section 5 for details). According to [RFC3550], an RTP receiver 436 that cannot recognize a payload type must discard it. This 437 provides for backward compatibility. The FEC mechanisms can then 438 be used in a multicast group with mixed FEC-capable and non-FEC- 439 capable receivers. If a non-FEC-capable receiver receives a 440 repair packet, it will not recognize the payload type, and hence, 441 will discard the repair packet. In case more than one repair flow 442 is used, different Payload Types will be used to distinguish 443 between the different flows. 445 o Sequence Number (SN): The sequence number maintains the standard 446 definition. It is one higher than the sequence number in the 447 previously transmitted repair packet. The initial value of the 448 sequence number is random (unpredictable) [RFC3550]. 450 o Timestamp (TS): The timestamp is set to a time corresponding to 451 the repair packet's transmission time. Note that the timestamp 452 value has no use in the actual FEC protection process and is 453 usually useful for jitter calculations. FEC packets that are the 454 result of the same FEC encoding operation will use the same value 455 as their Timestamp. 457 o Synchronization Source (SSRC): The SSRC value is randomly 458 assigned as suggested by [RFC3550]. 460 6.2.2. Repair FEC Payload ID encoding format 462 A FEC repair packet MUST contain a Repair FEC Payload ID that is 463 prepended to the repair symbol(s) as illustrated in Figure 2. More 464 precisely the Repair FEC Payload ID encoding format includes 465 information that enables the receiver to reconstruct the source block 466 and to identify the FEC repair packets associated with each source 467 block, in their correct order. 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Enc. Symbol ID (ESI) | SN_base | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Source Block Length (k) | n_r | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Figure 3: FEC Header Format 479 The format of the Repair FEC Payload ID is shown in figure Figure 3. 480 It includes the following fields: 482 Encoding Symbol ID, ESI (8-bit field): this field identifies the 483 repair symbol contained in this FEC repair packet. This value is 484 such that k <= ESI <= n - 1 for repair symbols. 486 SN_base (16-bit field): the lowest RTP sequence number (taking 487 wraparound into account) of the FEC source packets in the 488 associated source block. This SN_base also identifies the source 489 block. In order to avoid any risk of confusion, two consecutive 490 source blocks MUST use different SN_base values, which is easily 491 verified by the sender (this situation might happen with Reed- 492 Solomon over GF(2^16)). 494 Source block length, k (16-bit field): the number of consecutive FEC 495 Source Packets considered. 497 n_r (8-bit field): the number of FEC repair packets used to protect 498 this source block. 500 Though the n_r field is not absolutely required (the maximum number 501 of repair symbols can be deduced from the finite field parameter, m), 502 it MAY be useful for the receiver to determine if all the repair 503 packets have been sent (e.g., if n_r FEC repair packets have already 504 been received for this source block). However, since the 505 transmission of FEC repair packets is not necessarily reliable nor 506 guaranteed to preserved packet transmission order, so great care must 507 be taken in figuring out if more FEC repair packets are expected or 508 not. The n_r field MAY also be useful to receivers that need to 509 anticipate the memory block that is required to store all the FEC 510 repair packets. 512 6.2.3. Repair Symbol Format 514 The repair symbol follows directly the repair FEC Payload ID in the 515 FEC repair packet (see figure Figure 2). Note that the first two 516 bytes of a repair symbol contain the result of the Reed-Solomon 517 encoding over the packet sizes in the source block. Therefore, the 518 size of an FEC repair packet (FEC Payload ID and FEC repair symbol) 519 is larger than the longest source packet (2 bytes longer). This 520 should be taken under consideration when deciding on the Maximum 521 Transmission Unit (MTU) size used for the source packets. 523 7. Payload Format Parameters 525 According to the FEC framework, when RTP is used as a transport for 526 repair packet flows, the scheme must define an RTP Payload Format for 527 the repair symbol. This section provides the media subtype 528 registration for the Reed-Solomon FEC. The parameters that are 529 required to configure the FEC encoding and decoding operations are 530 also defined in this section. 532 7.1. Media Type Registration 534 This registration is done using the template defined in [RFC4288] and 535 following the guidance provided in [RFC4855][RFC4856]. 537 7.1.1. Registration of audio/reed-solomon-fec 539 Type name: audio 541 Subtype name: reed-solomon-fec 543 Required parameters: 545 o max_n: The upper limit for the sum of source and repair packets 546 that belong to the same FEC block. max_n is a positive integer. 547 The application can change both k and n-k. max_n is the upper 548 limit for n. The value of max_n must be equal to or lower than 549 the codec limitation (2^m). 551 o repair-window: The time that spans the source packets and the 552 corresponding repair packets. The size of the repair window is 553 specified in microseconds. 555 o The repair-window impacts the maximum number of source packets in 556 a FEC block at the sender side, and defines the time which the 557 receiver should wait for the repair packets. The repair-window 558 value may be negotiated between the sender and receiver. The 559 details of such negotiation are out-of-scope for this document. 561 o element-size: a non-negative integer indicating the length of 562 each encoding elements in bits. This value equals to the "m" 563 parameter in the GF (represented by 2^m). 565 Optional parameters: None. 567 Encoding considerations: This media type is framed and binary, see 568 section 4.8 in [RFC4288] 570 Security considerations: Please see security consideration in 571 [I-D.ietf-fecframe-framework] 573 Interoperability considerations: None. 575 Published specification: TBD 576 Applications that use this media type: Multimedia applications that 577 want to improve resiliency against packet loss by sending redundant 578 data in addition to the source media. 580 Additional information: None. 582 Magic number(s): none defined 584 File extension(s): none defined 586 Macintosh file type code(s): none defined 588 Person & email address to contact for further information: Sarit 589 Galanos, sarit@radvision.com 591 Intended usage: COMMON 593 Restrictions on usage: This media type depends on RTP framing, and 594 hence is only defined for transfer via RTP [RFC3550]. Transport 595 within other framing protocols is not defined at this time. 597 7.1.2. Registration of video/reed-solomon-fec 599 Type name: video 601 Subtype name: reed-solomon-fec 603 Required parameters: 605 o max_n: The upper limit for the sum of source and repair packets 606 that belong to the same FEC block. max_n is a positive integer. 607 The application can change both k and n-k. max_n is the upper 608 limit for n. The value of max_n must be equal to or lower than 609 the codec limitation (2^m). 611 o repair-window: The time that spans the source packets and the 612 corresponding repair packets. The size of the repair window is 613 specified in microseconds. 615 o The repair-window impacts the maximum number of source packets in 616 a FEC block at the sender side and defines the time which the 617 receiver should wait for the repair packets. The repair-window 618 value may be negotiated between the sender and receiver. the 619 details of such negotiation are out-of-scope for this document. 621 o element-size: a non-negative integer indicating the length of 622 each encoding elements in bits. This value equals to the "m" 623 parameter in the GF (represented by 2^m). 625 Optional parameters: None. 627 Encoding considerations: This media type is framed and binary, see 628 section 4.8 in [RFC4288] 630 Security considerations: Please see security consideration in 631 [I-D.ietf-fecframe-framework] 633 Interoperability considerations: None. 635 Published specification: TBD 637 Applications that use this media type: Multimedia applications that 638 want to improve resiliency against packet loss by sending redundant 639 data in addition to the source media. 641 Additional information: None. 643 Magic number(s): none defined 645 File extension(s): none defined 647 Macintosh file type code(s): none defined 649 Person & email address to contact for further information: Sarit 650 Galanos, sarit@radvision.com 652 Intended usage: COMMON 654 Restrictions on usage: This media type depends on RTP framing, and 655 hence is only defined for transfer via RTP [RFC3550]. Transport 656 within other framing protocols is not defined at this time. 658 7.1.3. Registration of text/reed-solomon-fec 660 Type name: text 662 Subtype name: reed-solomon-fec 664 Required parameters: 666 o max_n: The upper limit for the sum of source and repair packets 667 that belong to the same FEC block. max_n is a positive integer. 668 The application can change both k and n-k. max_n is the upper 669 limit for n. The value of max_n must be equal to or lower than 670 the codec limitation (2^m). 672 o repair-window: The time that spans the source packets and the 673 corresponding repair packets. The size of the repair window is 674 specified in microseconds. 676 o The repair-window impacts the maximum number of source packets in 677 a FEC block at the sender side, and defines the time which the 678 receiver should wait for the repair packets. The repair-window 679 value may be negotiated between the sender and receiver. the 680 details of such negotiation are out-of-scope for this document. 682 o element-size: a non-negative integer indicating the length of 683 each encoding elements in bits. This value equals to the "m" 684 parameter in the GF (represented by 2^m). 686 Optional parameters: None. 688 Encoding considerations: This media type is framed and binary, see 689 section 4.8 in [RFC4288] 691 Security considerations: Please see security consideration in 692 [I-D.ietf-fecframe-framework] 694 Interoperability considerations: None. 696 Published specification: TBD 698 Applications that use this media type: Multimedia applications that 699 want to improve resiliency against packet loss by sending redundant 700 data in addition to the source media. 702 Additional information: None. 704 Magic number(s): none defined 706 File extension(s): none defined 708 Macintosh file type code(s): none defined 710 Person & email address to contact for further information: Sarit 711 Galanos, sarit@radvision.com 713 Intended usage: COMMON 715 Restrictions on usage: This media type depends on RTP framing, and 716 hence is only defined for transfer via RTP [RFC3550]. Transport 717 within other framing protocols is not defined at this time. 719 7.1.4. Registration of application/reed-solomon-fec 721 Type name: application 723 Subtype name: reed-solomon-fec 725 Required parameters: 727 o max_n: The upper limit for the sum of source and repair packets 728 that belong to the same FEC block. max_n is a positive integer. 729 The application can change both k and n-k. max_n is the upper 730 limit for n. The value of max_n must be equal to or lower than 731 the codec limitation (2^m). 733 o repair-window: The time that spans the source packets and the 734 corresponding repair packets. The size of the repair window is 735 specified in microseconds. 737 o The repair-window impacts the maximum number of source packets in 738 a FEC block at the sender side, and defines the time which the 739 receiver should wait for the repair packets. The repair-window 740 value may be negotiated between the sender and receiver. the 741 details of such negotiation are out-of-scope for this document. 743 o element-size: a non-negative integer indicating the length of 744 each encoding elements in bits. This value equals to the "m" 745 parameter in the GF (represented by 2^m). 747 Optional parameters: None. 749 Encoding considerations: This media type is framed and binary, see 750 section 4.8 in [RFC4288] 752 Security considerations: Please see security consideration in 753 [I-D.ietf-fecframe-framework] 755 Interoperability considerations: None. 757 Published specification: TBD 759 Applications that use this media type: Multimedia applications that 760 want to improve resiliency against packet loss by sending redundant 761 data in addition to the source media. 763 Additional information: None. 765 Magic number(s): none defined 766 File extension(s): none defined 768 Macintosh file type code(s): none defined 770 Person & email address to contact for further information: Sarit 771 Galanos, sarit@radvision.com 773 Intended usage: COMMON 775 Restrictions on usage: This media type depends on RTP framing, and 776 hence is only defined for transfer via RTP [RFC3550]. Transport 777 within other framing protocols is not defined at this time. 779 7.2. Mapping of SDP Parameters 781 For a proper operation details of the FEC scheme have to be 782 communicated between the sender and the receiver. Specifically, the 783 receiver has to know the relationship between the source and the 784 repair flows, how the sender applied protection to the source flow 785 and how the repair flows can be used to recover the lost data. One 786 way to provide this information is to use the Session Description 787 Protocol (SDP) [RFC4566]. 789 The mapping of the media type specification for "reed-solomon-fec" 790 and their parameters in SDP is as follows: 792 o The media type (e.g., "application") goes into the "m=" line as 793 the media name. 795 o The media subtype ("reed-solomon-fec") goes into the "a=rtpmap" 796 line as the encoding name. 798 o The remaining required payload-format-specific parameters 799 ("max_n", "repair-window") go into the "a=fmtp" line by copying 800 them directly from the media type string as a semicolon-separated 801 list of parameter=value pairs. 803 See section 9 for SDP examples. 805 8. Protection and Recovery Procedures 807 This section provides a complete specification of the protection and 808 recovery procedures. 810 8.1. Overview 812 The FEC repair packets allow end-systems to recover from media packet 813 losses (also called erasures). The following sections specify the 814 steps involved in generating the FEC repair packets and 815 reconstructing the missing source packets from the FEC repair 816 packets. 818 8.2. FEC Repair Packet Construction 820 The source block is created and encoding is performed based on the 821 guidelines given in Section 5. The RTP header of a FEC repair packet 822 is formed based on the guidelines given in Section 6.2.1. The repair 823 FEC Payload ID is formed based on the guidelines given in 824 Section 6.2.2. The n_r FEC repair packets can then be sent along 825 with the k original unmodified source packets. 827 8.3. Source Packet Reconstruction 829 Recovery requires two distinct operations. The first operation 830 determines which packets (source and repair) must be considered in 831 order to recover the missing packets of a given block. Once this is 832 done, the second step is the reconstruction of the missing data. 834 8.3.1. Associating the Source and Repair Packets 836 Association of the FEC source packets and FEC repair packets is done 837 using a combination of the source packet sequence number and the 838 information found in the RTP header and the repair FEC Payload ID of 839 the FEC repair packets. The first step is to accumulate some of the 840 n_r = n - k repair packets that were generated. For that the 841 application follows the steps listed below: 843 o For each received packet, retrieve the payload type parameter from 844 the RTP header to identify the packet as a FEC repair packet of 845 the Reed-Solomon scheme or a source packet. In case multiple 846 repair flows are used, different payload types will be used to 847 distinguish between the different repair flows. 849 o If a FEC repair packet is received, retrieve the sequence number 850 (SN) from the RTP header and the ESI, SN_base, k and n_r 851 parameters from the repair FEC Payload ID. 853 * With these parameters, identify the collection of source 854 packets that are included in this source block. For example, 855 if SN_base = 991 and k = 10, the receiver deduces that this 856 source block is composed of the 10 source packets with RTP 857 sequence numbers 991 to 1000 (inclusive). 859 * With these parameters, identify the collection of FEC repair 860 packets generated for this source block. For example, if 861 SN_base = 991, ESI = 12, k = 10, n_r = 4, the receiver deduces 862 that 4 FEC repair packets with RTP sequence numbers 1001, 1002, 863 1003 and 1004 have been generated for this source block. 865 8.3.2. Recovering the source packet 867 In order to recover the lost source packets, the application has to 868 rebuild the source block according to the guidelines given in 869 Section 5 and append the repair symbol to it in the correct order. 870 Zero padding will replace the lost packets in the constructed source 871 block. The size of each source block data packet in bytes will be 872 equal to the size of the repair symbol found in the repair packets. 873 The repair symbol size is the size of the RTP payload in the repair 874 packet without the repair FEC Payload ID (see Figure 2). The 875 application will then append the repair symbol taken from each repair 876 packet. This new block is provided to the Reed-Solomon code. 878 Reconstruction of lost packets (source or repair packets) is possible 879 only if at least any k packets were received (source or repair). 881 The Reed-Solomon code will reconstruct the lost data into the 882 provided source block overriding the zero padded blocks. The 883 application can then recover the lost packets as follows: 885 o The first two bytes specify the RTP packet size. 887 o According to the RTP packet size the application can retrieve the 888 RTP packet (RTP header and payload). 890 o Any extra padding bytes (if any) are ignored. 892 9. SDP Examples 894 The following example demonstrates source flow with flow ID of 0 that 895 is protected by a single repair flow R1. 897 v=0 898 o=sarit 1122334455 1122334466 IN IP4 fec.example.com 899 s= Reed Solomon FEC Example 900 t=0 0 901 a=group:FEC S1 R1 902 m=video 30000 RTP/AVP 100 903 c=IN IP4 233.252.0.1/127 904 a=rtpmap:100 MP2T/90000 905 a=fec-source-flow: id=0 906 a=mid:S1 907 m=application 30000 RTP/AVP 110 908 c=IN IP4 233.252.0.2/127 909 a=rtpmap:110 reed-solomon-fec /90000 910 a=fmtp:110 max_n:16; repair-window:200000; symbol-size:8 911 a=mid:R1 913 Figure 4 915 10. Implementation Considerations 917 Using Reed-Solomon FEC protection over RTP may be useful for 918 efficiently overcoming network packet losses in interactive 919 communications where latency constraints apply. Protection may be 920 applied for small encoding blocks, and therefore latency caused by 921 waiting for the FEC repair packets is minimized. 923 This document allows the application to set the FEC recovery 924 capabilities dynamically according to the experienced and measured 925 loss rate, for optimizing bandwidth utilization while recovering from 926 network errors. 928 When FEC protection is used due to network congestion conditions, it 929 is important that the application will reduce the bandwidth used for 930 FEC protection from the bandwidth used by the source flow, in order 931 not to overload the already congested network with the additional FEC 932 repair packets. 934 In order to minimize bandwidth overhead for repair packets, algorithm 935 for applying FEC on source packets should be designed carefully. 936 Using source packets with similar lengths (when possible) can 937 minimize the bandwidth overhead of the FEC repair packets. 939 In order to maximize the FEC recovery capabilities, when a ratio of 940 k/n is chosen, the larger the encoding blocks size (n) is, the 941 stronger the FEC protection is. Of course, on the other hand the 942 larger the source block size is, the larger the latency is (caused by 943 waiting for the FEC repair packet). The application should choose 944 carefully the FEC block size in order to maximize the FEC recovery 945 capabilities while keeping an acceptable latency at the receiver 946 waiting for the FEC repair packets. 948 11. Offer/Answer considerations 950 None. 952 12. Security Considerations 954 12.1. Problem Statement 956 A content delivery system is potentially subject to many attacks. 957 Some of them target the network (e.g., to compromise the routing 958 infrastructure, by compromising the congestion control component), 959 others target the Content Delivery Protocol (CDP) (e.g., to 960 compromise its normal behavior), and finally some attacks target the 961 content itself. Since this document focuses on various FEC schemes, 962 this section only discusses the additional threats that their use 963 within the FECFRAME framework can create to an arbitrary CDP. 965 More specifically, these attacks may have several goals: 967 o those that are meant to give access to a confidential content 968 (e.g., in case of a non-free content), 970 o those that try to corrupt the ADU Flows being transmitted (e.g., 971 to prevent a receiver from using it), 973 o and those that try to compromise the receiver's behavior (e.g., by 974 making the decoding of an object computationally expensive). 976 These attacks can be launched either against the data flow itself 977 (e.g., by sending forged FEC Source/Repair Packets) or against the 978 FEC parameters that are sent either in-band (e.g., in the Repair FEC 979 Payload ID) or out-of-band (e.g., in a session description). 981 12.2. Attacks Against the Data Flow 983 First of all, let us consider the attacks against the data flow. 985 12.2.1. Access to Confidential Contents 987 Access control to the ADU Flow being transmitted is typically 988 provided by means of encryption. This encryption can be done within 989 the content provider itself, by the application (for instance by 990 using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), or 991 at the Network Layer, on a packet per packet basis when IPsec/ESP is 992 used [RFC4303]. If confidentiality is a concern, it is RECOMMENDED 993 that one of these solutions be used. Even if we mention these 994 attacks here, they are not related nor facilitated by the use of FEC. 996 12.2.2. Content Corruption 998 Protection against corruptions (e.g., after sending forged FEC 999 Source/Repair Packets) is achieved by means of a content integrity 1000 verification/sender authentication scheme. This service is usually 1001 provided at the packet level. In this case, after removing all 1002 forged packets, the ADU Flow may be sometimes recovered. Several 1003 techniques can provide this source authentication/content integrity 1004 service: 1006 o at the application level, the Secure Real-time Transport Protocol 1007 (SRTP) [RFC3711] provides several solutions to authenticate the 1008 source and check the integrity of RTP and RTCP messages, among 1009 other services. For instance, associated to the Timed Efficient 1010 Stream Loss-Tolerant Authentication (TESLA) [RFC4383], SRTP is an 1011 attractive solution that is robust to losses, provides a true 1012 authentication/integrity service, and does not create any 1013 prohibitive processing load or transmission overhead. Yet, 1014 checking a packet requires a small delay (a second or more) after 1015 its reception with TESLA. Other building blocks can be used 1016 within SRTP to provide authentication/content integrity services. 1018 o at the Network Layer, IPsec/ESP offers (among other services) an 1019 integrity verification mechanism that can be used to provide 1020 authentication/content integrity services. 1022 Techniques relying on public key cryptography (e.g., digital 1023 signatures) require that public keys be securely associated to the 1024 entities. This can be achieved by a Public Key Infrastructure (PKI), 1025 or by a PGP Web of Trust, or by pre-distributing the public keys of 1026 each group member. 1028 Techniques relying on symmetric key cryptography require that a 1029 secret key be shared by all group members. This can be achieved by 1030 means of a group key management protocol, or simply by pre- 1031 distributing the secret key (but this manual solution has many 1032 limitations). 1034 It is up to the developer and deployer, who know the security 1035 requirements and features of the target application area, to define 1036 which solution is the most appropriate. Nonetheless it is 1037 RECOMMENDED that at least one of these techniques be used. 1039 12.3. Attacks Against the FEC Parameters 1041 Let us now consider attacks against the FEC parameters included in 1042 the FFCI that are usually sent out-of-band (e.g., in a session 1043 description). Attacks on these FEC parameters can prevent the 1044 decoding of the associated object. For instance modifying the m 1045 field (when applicable) will lead a receiver to consider a different 1046 code. Modifying the E parameter will lead a receiver to consider bad 1047 Repair Symbols for a received FEC Repair Packet. 1049 It is therefore RECOMMENDED that security measures be taken to 1050 guarantee the FFCI integrity. When the FFCI is sent out-of-band in a 1051 session description, this latter SHOULD be protected, for instance by 1052 digitally signing it. 1054 Attacks are also possible against some FEC parameters included in the 1055 Explicit Repair FEC Payload ID. For instance modifying the SN_base 1056 of a FEC Repair Packet will lead a receiver to assign this packet to 1057 a wrong block. 1059 It is therefore RECOMMENDED that security measures be taken to 1060 guarantee the Explicit Repair FEC Payload ID integrity. To that 1061 purpose, one of the packet-level source authentication/content 1062 integrity techniques of Section 12.2.2 can be used. 1064 13. IANA Considerations 1066 New media subtypes are subject to IANA registration. For the 1067 registration of the payload formats and their parameters introduced 1068 in this document, refer to Section 7.1. 1070 14. Acknowledgments 1072 Some parts of this document are borrowed from the following 1073 documents: [RFC5109], [I-D.ietf-fecframe-1d2d-parity-scheme], 1074 [I-D.roca-fecframe-rs], [I-D.ietf-avt-reedsolomon]. The author would 1075 like to thank the editors of these documents. The authors would also 1076 like to thank the members of the FP7 3DPresence project consortium 1077 for their contribution to this draft writing. 1079 15. References 1080 15.1. Normative References 1082 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1083 Requirement Levels", BCP 14, RFC 2119, March 1997. 1085 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1086 Jacobson, "RTP: A Transport Protocol for Real-Time 1087 Applications", STD 64, RFC 3550, July 2003. 1089 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1090 Description Protocol", RFC 4566, July 2006. 1092 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1093 Registration Procedures", BCP 13, RFC 4288, December 2005. 1095 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1096 Formats", RFC 4855, February 2007. 1098 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 1099 the RTP Profile for Audio and Video Conferences", 1100 RFC 4856, February 2007. 1102 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 1103 "Reed-Solomon Forward Error Correction (FEC) Schemes", 1104 RFC 5510, April 2009. 1106 [I-D.ietf-fecframe-framework] 1107 Watson, M., Begen, A., and V. Roca, "Forward Error 1108 Correction (FEC) Framework", 1109 draft-ietf-fecframe-framework-14 (work in progress), 1110 March 2011. 1112 15.2. Informative References 1114 [I-D.ietf-fecframe-1d2d-parity-scheme] 1115 Begen, A., "RTP Payload Format for Non-Interleaved and 1116 Interleaved Parity FEC", 1117 draft-ietf-fecframe-1d2d-parity-scheme-01 (work in 1118 progress), May 2009. 1120 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1121 Correction", RFC 5109, December 2007. 1123 [I-D.ietf-avt-reedsolomon] 1124 Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1125 for Reed Solomon Codes", May 1999. 1127 [Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer 1128 Communication Protocols", ACM SIGCOMM Computer 1129 Communication Review Vol.27, No.2, pp.24-36, April 1997. 1131 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1132 RFC 4303, December 2005. 1134 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1135 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1136 RFC 3711, March 2004. 1138 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1139 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1140 Real- time Transport Protocol (SRTP)", RFC 4383, 1141 February 2006. 1143 [I-D.ietf-fecframe-sdp-elements] 1144 Begen, A., "Session Description Protocol Elements for FEC 1145 Framework", draft-ietf-fecframe-sdp-elements-11 (work in 1146 progress), October 2010. 1148 [I-D.roca-fecframe-rs] 1149 Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 1150 Matsuzono, "Reed-Solomon Forward Error Correction (FEC) 1151 Schemes for FECFRAME", draft-roca-fecframe-rs-03 (work in 1152 progress), July 2010. 1154 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1155 Correction (FEC) Building Block", RFC 5052, August 2007. 1157 Authors' Addresses 1159 Sarit Galanos 1160 RADVISION 1161 24 Raul Wallenberg St. 1162 Tel Aviv 69719 1163 Israel 1165 Email: sarit@radvision.com 1167 Orly Peck 1168 Kaminario 1169 Israel 1171 Email: orly.peck@kaminario.com 1172 Vincent Roca 1173 INRIA 1174 655, av. de l'Europe 1175 Inovallee; Montbonnot 1176 ST ISMIER cedex 38334 1177 France 1179 Email: vincent.roca@inria.fr