idnits 2.17.1 draft-ietf-fecframe-rtp-raptor-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2010) is 5164 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 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-06 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-04 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-raptor-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 2326 (Obsoleted by RFC 7826) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework Working Group M. Watson 3 Internet-Draft Qualcomm Inc. 4 Intended status: Standards Track March 5, 2010 5 Expires: September 6, 2010 7 RTP Payload Format for Raptor FEC 8 draft-ietf-fecframe-rtp-raptor-03 10 Abstract 12 This document specifies an RTP Payload Format for Forward Error 13 Correction repair data produced by the Raptor FEC Schemes. Raptor 14 FEC Schemes are specified for use with the IETF FEC Framework which 15 supports transport of repair data over both UDP and RTP. This 16 document specifies the Payload Format which is required for the use 17 of RTP to carry Raptor repair flows. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 6, 2010. 42 Copyright Notice 44 Copyright (c) 2010 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 BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 61 3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 62 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Congestion Control Considerations . . . . . . . . . . . . . . 7 67 6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Registration of the application/raptorfec media type . . . 8 69 6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8 70 6.2. Registration of the video/raptorfec media type . . . . . . 9 71 6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9 72 6.3. Registration of the audio/raptorfec media type . . . . . . 11 73 6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 11 74 6.4. Registration of the text/raptorfec media type . . . . . . 12 75 6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 13 76 7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 16 78 9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 17 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 1. Introduction 86 The FEC Framework [I-D.ietf-fecframe-framework] defines a general 87 framework for the use of Forward Error Correction in association with 88 arbitrary packet flows, including flows over UDP and RTP [RFC3550]. 89 Forward Error Corrections operates by generating redundant data 90 packets ("repair data") which can be sent independently from the 91 original flow. At a receiver the original flow can be reconstructed 92 provided a sufficient set of redundant data packets and possibly 93 original data packets are received. 95 The FEC Framework provides for independence between application 96 protocols and FEC codes. The use of a particular FEC code within the 97 framework is defined by means of an FEC Scheme which may then be used 98 with any application protocol compliant to the framework. 100 Repair data flows may be sent directly over a transport protocol such 101 as UDP, or they may be encapsulated within RTP. In the latter case, 102 an RTP Payload Format must be defined for each FEC Scheme. 104 This document defines the RTP Payload Format for the Raptor FEC 105 Schemes defined in [I-D.ietf-fecframe-raptor]. 107 2. Conventions, Definitions and Acronyms 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Media Format Background 115 The Raptor and RaptorQ codes are efficient block-based fountain 116 codes, meaning that from any group of source packets (or 'source 117 block') an arbitrary number of repair packets may be generated. The 118 Raptor and RaptorQ codes have the property that the original group of 119 source symbols can be recovered with very high probability from any 120 set of symbols (source and repair) only slightly greater in number 121 than the original number of source symbols. The RaptorQ code 122 additionally has the property that the probability that the original 123 group of source symbols can be recovered from a set of symbols 124 (source and repair) equal in number to the original number of source 125 symbols is in many cases also very high. 127 [I-D.ietf-fecframe-raptor] defines six FEC Schemes for the use of the 128 Raptor and RaptorQ codes with arbitary packet flows: the first two 129 schemes are fully applicable to arbitary packet flows (using Raptor 130 and RaptorQ respectively). The third and fourth schemes are slightly 131 optimised versions of the first two schemes which are applicable in 132 applications with relatively small block sizes. The fifth and sixth 133 schemes are variants of the third and fourth schemes which are 134 applicable to a single source flow which already has some kind of 135 identifiable sequence number. The presence of a sequence number in 136 the source flow allows for backwards compatible operation (the source 137 flows do not need to be modified in order to apply FEC). In this 138 case, in the language of the FEC Framework, there is no need for an 139 explicit FEC Source Payload Id and it is therefore not included in 140 the packets. 142 4. Payload Format 144 4.1. RTP Header Usage 146 The following rules SHALL be followed for the RTP header used with 147 FEC repair packets: 149 o Marker bit: The marker bit SHALL be set 1 for the last protection 150 RTP packet sent for each source block, and otherwise set to 0 152 o Timestamp: The timestamp SHALL be set to a time corresponding to 153 the packet's transmission time. The timestamp value has no use in 154 the actual FEC protection process. It may be used for packet 155 arrival timing and jitter calculations. The timestamp rate SHALL 156 be specified using the "rate" media type parameter defined below. 158 Other header fields SHALL be set according to the rules of [RFC3550]. 160 4.2. Payload Header 162 There is no Payload Header in this Payload Format 164 4.3. Payload Data 166 Procedures and data formats for the use of Raptor Forward Error 167 Correction in an FECFRAME context are fully defined in 168 [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-framework] and 169 are not duplicated here. The procedures of those documents SHALL be 170 followed in order to generate repair data streams to be carried by 171 the payload formats defined in this document. 173 The RTP Payload SHALL contain an FEC Repair Payload as defined in 174 [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor]. 176 5. Congestion Control Considerations 178 See [I-D.ietf-fecframe-framework]. 180 6. Media Types 182 6.1. Registration of the application/raptorfec media type 184 This RTP payload format is identified using the application/raptorfec 185 media type which is registered in accordance with [RFC4855] and using 186 the template of [RFC4288]. 188 6.1.1. Media Type Definition 190 Type name: application 192 Subtype name: raptorfec 194 Required parameters: 196 rate: The RTP timestamp (clock) rate. The rate SHALL be larger 197 than 1000 Hz to provide sufficient resolution to RTCP operations. 198 However, it is RECOMMENDED to select the rate that matches the 199 rate of the protected source RTP stream. 201 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 202 for the specific Raptor FEC Scheme that will be used as defined in 203 [I-D.ietf-fecframe-raptor]. 205 Kmax: The value of this parameter is the FEC Framework 206 Configuration Information element "Maximum Source Block Length" as 207 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 208 integer. 210 T: The value of this parameter is the FEC Framework Configuration 211 Information element "Encoding Symbol Size" as defined in 212 [I-D.ietf-fecframe-raptor] encoded as a decimal integer. 214 repair-window: The maximum time that spans the source packets and 215 the corresponding repair packets. The size of the repair window 216 is specified in microseconds. 218 Optional parameters: 220 P: The value of this parameter is the FEC Framework Configuration 221 Information element "Payload ID Format" as defined in 222 [I-D.ietf-fecframe-raptor]. If this parameter is missing that the 223 value "A" shall be assumed. 225 Encoding considerations: This media type is framed and binary, see 226 section 4.8 in [RFC4288] 227 Security considerations: Please see security consideration in 228 [I-D.ietf-fecframe-framework] 230 Interoperability considerations: 232 Published specification: [I-D.ietf-fecframe-raptor] 234 Applications that use this media type: 236 Additional information: 238 Magic number(s): 240 File extension(s): 242 Macintosh file type code(s): 244 Person & email address to contact for further information: Mark 245 Watson, watson@qualcomm.com 247 Intended usage: COMMON 249 Restrictions on usage: This media type depends on RTP framing, and 250 hence is only defined for transfer via RTP [[RFC3550]]. Transport 251 within other framing protocols is not defined at this time. 253 Author: Mark Watson, Qualcomm Inc. 255 Change controller: IETF Audio/Video Transport working group delegated 256 from the IESG. 258 6.2. Registration of the video/raptorfec media type 260 This RTP payload format is identified using the video/raptorfec media 261 type which is registered in accordance with [RFC4855] and using the 262 template of [RFC4288]. 264 6.2.1. Media Type Definition 266 Type name: video 268 Subtype name: raptorfec 270 Required parameters: 272 rate: The RTP timestamp (clock) rate. The rate SHALL be larger 273 than 1000 Hz to provide sufficient resolution to RTCP operations. 274 However, it is RECOMMENDED to select the rate that matches the 275 rate of the protected source RTP stream. 277 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 278 for the specific Raptor FEC Scheme that will be used as defined in 279 [I-D.ietf-fecframe-raptor]. 281 Kmax: The value of this parameter is the FEC Framework 282 Configuration Information element "Maximum Source Block Length" as 283 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 284 integer. 286 T: The value of this parameter is the FEC Framework Configuration 287 Information element "Encoding Symbol Size" as defined in 288 [I-D.ietf-fecframe-raptor] encoded as a decimal integer. 290 repair-window: The maximum time that spans the source packets and 291 the corresponding repair packets. The size of the repair window 292 is specified in microseconds. 294 Optional parameters: 296 P: The value of this parameter is the FEC Framework Configuration 297 Information element "Payload ID Format" as defined in 298 [I-D.ietf-fecframe-raptor]. If this parameter is missing that the 299 value "A" shall be assumed. 301 Encoding considerations: This media type is framed and binary, see 302 section 4.8 in [RFC4288] 304 Security considerations: Please see security consideration in 305 [I-D.ietf-fecframe-framework] 307 Interoperability considerations: 309 Published specification: [I-D.ietf-fecframe-raptor] 311 Applications that use this media type: 313 Additional information: 315 Magic number(s): 317 File extension(s): 319 Macintosh file type code(s): 321 Person & email address to contact for further information: Mark 322 Watson, watson@qualcomm.com 323 Intended usage: COMMON 325 Restrictions on usage: This media type depends on RTP framing, and 326 hence is only defined for transfer via RTP [[RFC3550]]. Transport 327 within other framing protocols is not defined at this time. 329 Author: Mark Watson, Qualcomm Inc. 331 Change controller: IETF Audio/Video Transport working group delegated 332 from the IESG. 334 6.3. Registration of the audio/raptorfec media type 336 This RTP payload format is identified using the audio/raptorfec media 337 type which is registered in accordance with [RFC4855] and using the 338 template of [RFC4288]. 340 6.3.1. Media Type Definition 342 Type name: audio 344 Subtype name: raptorfec 346 Required parameters: 348 rate: The RTP timestamp (clock) rate. The rate SHALL be larger 349 than 1000 Hz to provide sufficient resolution to RTCP operations. 350 However, it is RECOMMENDED to select the rate that matches the 351 rate of the protected source RTP stream. 353 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 354 for the specific Raptor FEC Scheme that will be used as defined in 355 [I-D.ietf-fecframe-raptor]. 357 Kmax: The value of this parameter is the FEC Framework 358 Configuration Information element "Maximum Source Block Length" as 359 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 360 integer. 362 T: The value of this parameter is the FEC Framework Configuration 363 Information element "Encoding Symbol Size" as defined in 364 [I-D.ietf-fecframe-raptor] encoded as a decimal integer. 366 repair-window: The maximum time that spans the source packets and 367 the corresponding repair packets. The size of the repair window 368 is specified in microseconds. 370 Optional parameters: 372 P: The value of this parameter is the FEC Framework Configuration 373 Information element "Payload ID Format" as defined in 374 [I-D.ietf-fecframe-raptor]. If this parameter is missing that the 375 value "A" shall be assumed. 377 Encoding considerations: This media type is framed and binary, see 378 section 4.8 in [RFC4288] 380 Security considerations: Please see security consideration in 381 [I-D.ietf-fecframe-framework] 383 Interoperability considerations: 385 Published specification: [I-D.ietf-fecframe-raptor] 387 Applications that use this media type: 389 Additional information: 391 Magic number(s): 393 File extension(s): 395 Macintosh file type code(s): 397 Person & email address to contact for further information: Mark 398 Watson, watson@qualcomm.com 400 Intended usage: COMMON 402 Restrictions on usage: This media type depends on RTP framing, and 403 hence is only defined for transfer via RTP [[RFC3550]]. Transport 404 within other framing protocols is not defined at this time. 406 Author: Mark Watson, Qualcomm Inc. 408 Change controller: IETF Audio/Video Transport working group delegated 409 from the IESG. 411 6.4. Registration of the text/raptorfec media type 413 This RTP payload format is identified using the text/raptorfec media 414 type which is registered in accordance with [RFC4855] and using the 415 template of [RFC4288]. 417 6.4.1. Media Type Definition 419 Type name: text 421 Subtype name: raptorfec 423 Required parameters: 425 rate: The RTP timestamp (clock) rate. The rate SHALL be larger 426 than 1000 Hz to provide sufficient resolution to RTCP operations. 427 However, it is RECOMMENDED to select the rate that matches the 428 rate of the protected source RTP stream. 430 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 431 for the specific Raptor FEC Scheme that will be used as defined in 432 [I-D.ietf-fecframe-raptor]. 434 Kmax: The value of this parameter is the FEC Framework 435 Configuration Information element "Maximum Source Block Length" as 436 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 437 integer. 439 T: The value of this parameter is the FEC Framework Configuration 440 Information element "Encoding Symbol Size" as defined in 441 [I-D.ietf-fecframe-raptor] encoded as a decimal integer. 443 repair-window: The maximum time that spans the source packets and 444 the corresponding repair packets. The size of the repair window 445 is specified in microseconds. 447 Optional parameters: 449 P: The value of this parameter is the FEC Framework Configuration 450 Information element "Payload ID Format" as defined in 451 [I-D.ietf-fecframe-raptor]. If this parameter is missing that the 452 value "A" shall be assumed. 454 Encoding considerations: This media type is framed and binary, see 455 section 4.8 in [RFC4288] 457 Security considerations: Please see security consideration in 458 [I-D.ietf-fecframe-framework] 460 Interoperability considerations: 462 Published specification: [I-D.ietf-fecframe-raptor] 464 Applications that use this media type: 466 Additional information: 468 Magic number(s): 470 File extension(s): 472 Macintosh file type code(s): 474 Person & email address to contact for further information: Mark 475 Watson, watson@qualcomm.com 477 Intended usage: COMMON 479 Restrictions on usage: This media type depends on RTP framing, and 480 hence is only defined for transfer via RTP [[RFC3550]]. Transport 481 within other framing protocols is not defined at this time. 483 Author: Mark Watson, Qualcomm Inc. 485 Change controller: IETF Audio/Video Transport working group delegated 486 from the IESG. 488 7. Mapping to SDP 490 Applications that are using RTP transport commonly use Session 491 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 492 The information that is used to specify the media types in an RTP 493 session has specific mappings to the fields in an SDP description. 494 Note that if an application does not use SDP to describe the RTP 495 sessions, an appropriate mapping must be defined and used to specify 496 the media types and their parameters for the control/description 497 protocol employed by the application. 499 The mapping of the above defined payload format media type and its 500 parameters SHALL be done according to Section 3 of [RFC4855] 501 following the suggestion therein regarding the mapping of payload- 502 format-specific paraeters into the ""a=fmtp"" field. 504 When the RTP Payload Formats defined in this document are used, the 505 Media Type Parameters defined above SHALL be used to specify the FEC 506 Framework Configuration Information in preference to the SDP 507 attributes specified in [I-D.ietf-fecframe-sdp-elements] 509 8. Offer/Answer considerations 511 When offering Raptor FEC over RTP using SDP in an Offer/Answer model 512 [RFC3264], the following considerations apply: 514 o Each combination of the Kmax and T parameters produces different 515 FEC data and is not compatible with any other combination. A 516 sender application may desire to offer multiple offers with 517 different sets of Kmax and T values as long as the parameter 518 values are valid. The receiver SHOULD normally choose the offer 519 with the largest value of the product of Kmax and T that it 520 supports. 522 o The size of the repair-window is related to the maximum delay 523 between the transmission of a source packet and the associated 524 repair packet. This directly impacts the buffering requirement on 525 the receiver side and the receiver must consider this when 526 choosing an offer. 528 o When the P parameter is omitted, FEC Payload ID Format A MUST be 529 assumed. In an answer which selects an offer in which the P 530 parameter was omitted, the P parameter MUST either be omitted, or 531 included with value "A". 533 9. Declarative SDP Considerations 535 In declarative usage, like SDP in the Real-time Streaming Protocol 536 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 537 [RFC2947], the following considerations apply: 539 o The payload format configuration parameters are all declarative 540 and a participant MUST use the configuration that is provided for 541 the session. 543 o More than one configuration may be provided (if desired) by 544 declaring multiple RTP payload types. In that case, the receivers 545 should choose the repair flow that is best for them. 547 10. IANA Considerations 549 This memo requests that IANA registers application/raptorfec as 550 specified in Section 6.1.1, video/raptorfec as specified in 551 Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and 552 text/raptorfec as specified in Section 6.4.1. The media type is also 553 requested to be added to the IANA registry for "RTP Payload Format 554 MIME types" (http://www.iana.org/assignments/rtp-parameters). 556 11. Security Considerations 558 Security Considerations related to the use of the FEC Framework are 559 addressed in [I-D.ietf-fecframe-framework]. These consideration 560 apply in full to users of the RTP Payload Formats defined in this 561 document, since these are defined in terms of the FEC Framework. 563 No further security considerations related specifically to the Raptor 564 FEC Schemes defined in [I-D.ietf-fecframe-raptor] have been 565 identified. 567 Users of RTP should consider the Security Considerations of 568 [RFC3550]. 570 12. References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 576 Jacobson, "RTP: A Transport Protocol for Real-Time 577 Applications", STD 64, RFC 3550, July 2003. 579 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 580 Registration Procedures", BCP 13, RFC 4288, December 2005. 582 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 583 Formats", RFC 4855, February 2007. 585 [I-D.ietf-fecframe-framework] 586 Watson, M., "Forward Error Correction (FEC) Framework", 587 draft-ietf-fecframe-framework-06 (work in progress), 588 March 2010. 590 [I-D.ietf-fecframe-sdp-elements] 591 Begen, A., "SDP Elements for FEC Framework", 592 draft-ietf-fecframe-sdp-elements-04 (work in progress), 593 August 2009. 595 [I-D.ietf-fecframe-raptor] 596 Watson, M., "Raptor FEC Schemes for FECFRAME", 597 draft-ietf-fecframe-raptor-01 (work in progress), 598 July 2009. 600 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 601 Description Protocol", RFC 4566, July 2006. 603 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 604 with Session Description Protocol (SDP)", RFC 3264, 605 June 2002. 607 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 608 Streaming Protocol (RTSP)", RFC 2326, April 1998. 610 [RFC2947] Altman, J., "Telnet Encryption: DES3 64 bit Cipher 611 Feedback", RFC 2947, September 2000. 613 Author's Address 615 Mark Watson 616 Qualcomm Inc. 617 3165 Kifer Rd. 618 Santa Clara, CA 95051 619 U.S.A. 621 Email: watson@qualcomm.com