idnits 2.17.1 draft-ietf-fecframe-rtp-raptor-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 6, 2009) is 5523 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) == Unused Reference: 'RFC3550' is defined on line 453, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-03 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-02 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-raptor-00 Summary: 3 errors (**), 0 flaws (~~), 5 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 6, 2009 5 Expires: September 7, 2009 7 RTP Payload Format for Raptor FEC 8 draft-ietf-fecframe-rtp-raptor-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 7, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document specifies an RTP Payload Format for Forward Error 47 Correction repair data produced by the Raptor FEC Schemes. Raptor 48 FEC Schemes are specified for use with the IETF FEC Framework which 49 supports transport of repair data over both UDP and RTP. This 50 document specifies the Payload Format which is required for the use 51 of RTP to carry Raptor repair flows. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 57 3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 58 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 61 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Congestion Control Considerations . . . . . . . . . . . . . . 7 63 6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Registration of the application/raptorfec media type . . . 8 65 6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8 66 6.2. Registration of the video/raptorfec media type . . . . . . 9 67 6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9 68 6.3. Registration of the audio/raptorfec media type . . . . . . 10 69 6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 10 70 6.4. Registration of the text/raptorfec media type . . . . . . 12 71 6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 12 72 7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 14 73 8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 15 74 9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 16 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 The FEC Framework [I-D.ietf-fecframe-framework] defines a general 83 framework for the use of Forward Error Correction in association with 84 arbitrary packet flows, including flows over UDP and RTP. Forward 85 Error Corrections operates by generating redundant data packets 86 ("repair data") which can be sent independently from the original 87 flow. At a receiver the original flow can be reconstructed provided 88 a sufficient set of redundant data packets and possibly original data 89 packets are received. 91 The FEC Framework provides for independence between application 92 protocols and FEC codes. The use of a particular FEC code within the 93 framework is defined by means of an FEC Scheme which may then be used 94 with any application protocol compliant to the framework. 96 Repair data flows may be sent directly over a transport protocol such 97 as UDP, or they may be encapsulated within RTP. In the latter case, 98 an RTP Payload Format must be defined for each FEC Scheme. 100 This document defines the RTP Payload Format for the Raptor FEC 101 Schemes defined in [I-D.ietf-fecframe-raptor]. 103 2. Conventions, Definitions and Acronyms 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Media Format Background 111 The Raptor code is an efficient XOR-based block-based fountain code, 112 meaning that from any group of source packets (or 'source block') an 113 arbitrary number of repair packets may be generated. The Raptor code 114 has the property that the original group of source packets can be 115 recovered with very high probability from any set of packets (source 116 and repair) only slightly greater in number than the original number 117 of source packets. 119 [I-D.ietf-fecframe-raptor] defines three FEC Schemes for the use of 120 the Raptor code with arbitary packet flows: the first scheme is fully 121 applicable to arbitary packet flows. The second scheme is a slightly 122 optimised version of the first scheme which is applicable in 123 applications with relatively small block sizes. The third scheme is 124 a variant of the second scheme which is applicable to a single source 125 flow which already has some kind of identifiable sequence number. 126 The presence of a sequence number in the source flow allows for 127 backwards compatible operation (the source flows do not need to be 128 modified in order to apply FEC). In this case, in the language of 129 the FEC Framework, there is no explicit FEC Source Payload Id. 131 4. Payload Format 133 The RTP Payload contains a FEC Repair Payload as defined in 134 [I-D.ietf-fecframe-raptor]. 136 4.1. RTP Header Usage 138 The rules SHALL be followed for the RTP header used with FEC repair 139 packets: 141 o Marker bit: The marker bit shall be set 1 for the last protection 142 RTP packet sent for each source block, and otherwise set to 0 144 o Timestamp: The timestamp SHALL be set to a time corresponding to 145 the packet's transmission time. The timestamp value has no use in 146 the actual FEC protection process. It may be used for packet 147 arrival timing and jitter calculations. 149 4.2. Payload Header 151 There is no Payload Header in this Payload Format 153 4.3. Payload Data 155 The RTP Payload contains a FEC Repair Payload as defined in 156 [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor]. 158 5. Congestion Control Considerations 160 See [I-D.ietf-fecframe-framework]. 162 6. Media Types 164 6.1. Registration of the application/raptorfec media type 166 This RTP payload format is identified using the application/raptorfec 167 media type which is registered in accordance with [RFC4855] and using 168 the template of [RFC4288]. 170 6.1.1. Media Type Definition 172 Type name: application 174 Subtype name: raptorfec 176 Required parameters: 178 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 179 for the specific Raptor FEC Scheme that will be used as defined in 180 [I-D.ietf-fecframe-raptor]. 182 max-sbl: The value of this parameter is the FEC Object 183 Transmission Information element "Maximum Source Block Length" as 184 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 185 integer. 187 symbol-size: The value of this parameter is the FEC Object 188 Transmission Information element "Encoding Symbol Size" as 189 definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal 190 integer. 192 Optional parameters: none 194 Encoding considerations: This media type is framed and binary, see 195 section 4.8 in [RFC4288] 197 Security considerations: Please see security consideration in 198 [I-D.ietf-fecframe-framework] 200 Interoperability considerations: 202 Published specification: [I-D.ietf-fecframe-raptor] 204 Applications that use this media type: 206 Additional information: 208 Magic number(s): 209 File extension(s): 211 Macintosh file type code(s): 213 Person & email address to contact for further information: Mark 214 Watson, watson@qualcomm.com 216 Intended usage: COMMON 218 Restrictions on usage: This media type depends on RTP framing, and 219 hence is only defined for transfer via RTP [[RFC3550]]. Transport 220 within other framing protocols is not defined at this time. 222 Author: Mark Watson, Qualcomm Inc. 224 Change controller: IETF Audio/Video Transport working group delegated 225 from the IESG. 227 6.2. Registration of the video/raptorfec media type 229 This RTP payload format is identified using the video/raptorfec media 230 type which is registered in accordance with [RFC4855] and using the 231 template of [RFC4288]. 233 6.2.1. Media Type Definition 235 Type name: video 237 Subtype name: raptorfec 239 Required parameters: 241 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 242 for the specific Raptor FEC Scheme that will be used as defined in 243 [I-D.ietf-fecframe-raptor] 245 max-sbl: The value of this parameter is the FEC Object 246 Transmission Information element "Maximum Source Block Length" as 247 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 248 integer. 250 symbol-size: The value of this parameter is the FEC Object 251 Transmission Information element "Encoding Symbol Size" as 252 definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal 253 integer. 255 Optional parameters: none 256 Encoding considerations: This media type is framed and binary, see 257 section 4.8 in [RFC4288] 259 Security considerations: Please see security consideration in 260 [I-D.ietf-fecframe-framework] 262 Interoperability considerations: 264 Published specification: [I-D.ietf-fecframe-raptor] 266 Applications that use this media type: 268 Additional information: 270 Magic number(s): 272 File extension(s): 274 Macintosh file type code(s): 276 Person & email address to contact for further information: Mark 277 Watson, watson@qualcomm.com 279 Intended usage: COMMON 281 Restrictions on usage: This media type depends on RTP framing, and 282 hence is only defined for transfer via RTP [[RFC3550]]. Transport 283 within other framing protocols is not defined at this time. 285 Author: Mark Watson, Qualcomm Inc. 287 Change controller: IETF Audio/Video Transport working group delegated 288 from the IESG. 290 6.3. Registration of the audio/raptorfec media type 292 This RTP payload format is identified using the audio/raptorfec media 293 type which is registered in accordance with [RFC4855] and using the 294 template of [RFC4288]. 296 6.3.1. Media Type Definition 298 Type name: audio 300 Subtype name: raptorfec 302 Required parameters: 304 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 305 for the specific Raptor FEC Scheme that will be used as defined in 306 [I-D.ietf-fecframe-raptor] 308 max-sbl: The value of this parameter is the FEC Object 309 Transmission Information element "Maximum Source Block Length" as 310 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 311 integer. 313 symbol-size: The value of this parameter is the FEC Object 314 Transmission Information element "Encoding Symbol Size" as 315 definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal 316 integer. 318 Optional parameters: none 320 Encoding considerations: This media type is framed and binary, see 321 section 4.8 in [RFC4288] 323 Security considerations: Please see security consideration in 324 [I-D.ietf-fecframe-framework] 326 Interoperability considerations: 328 Published specification: [I-D.ietf-fecframe-raptor] 330 Applications that use this media type: 332 Additional information: 334 Magic number(s): 336 File extension(s): 338 Macintosh file type code(s): 340 Person & email address to contact for further information: Mark 341 Watson, watson@qualcomm.com 343 Intended usage: COMMON 345 Restrictions on usage: This media type depends on RTP framing, and 346 hence is only defined for transfer via RTP [[RFC3550]]. Transport 347 within other framing protocols is not defined at this time. 349 Author: Mark Watson, Qualcomm Inc. 351 Change controller: IETF Audio/Video Transport working group delegated 352 from the IESG. 354 6.4. Registration of the text/raptorfec media type 356 This RTP payload format is identified using the text/raptorfec media 357 type which is registered in accordance with [RFC4855] and using the 358 template of [RFC4288]. 360 6.4.1. Media Type Definition 362 Type name: text 364 Subtype name: raptorfec 366 Required parameters: 368 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 369 for the specific Raptor FEC Scheme that will be used as defined in 370 [I-D.ietf-fecframe-raptor] 372 max-sbl: The value of this parameter is the FEC Object 373 Transmission Information element "Maximum Source Block Length" as 374 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 375 integer. 377 symbol-size: The value of this parameter is the FEC Object 378 Transmission Information element "Encoding Symbol Size" as 379 definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal 380 integer. 382 Optional parameters: none 384 Encoding considerations: This media type is framed and binary, see 385 section 4.8 in [RFC4288] 387 Security considerations: Please see security consideration in 388 [I-D.ietf-fecframe-framework] 390 Interoperability considerations: 392 Published specification: [I-D.ietf-fecframe-raptor] 394 Applications that use this media type: 396 Additional information: 398 Magic number(s): 399 File extension(s): 401 Macintosh file type code(s): 403 Person & email address to contact for further information: Mark 404 Watson, watson@qualcomm.com 406 Intended usage: COMMON 408 Restrictions on usage: This media type depends on RTP framing, and 409 hence is only defined for transfer via RTP [[RFC3550]]. Transport 410 within other framing protocols is not defined at this time. 412 Author: Mark Watson, Qualcomm Inc. 414 Change controller: IETF Audio/Video Transport working group delegated 415 from the IESG. 417 7. Mapping to SDP 419 The mapping of the above defined payload format media type and its 420 parameters SHALL be done according to Section 3 of [RFC4855] 422 When the RTP Payload Formats defined in this document are used, the 423 Media Type Parameters defined above SHALL be used to specify the FEC 424 Object Transmission Information in preference to the SDP attributes 425 specified in [I-D.ietf-fecframe-sdp-elements] 427 8. Offer/Answer considerations 429 None. 431 9. Declarative SDP Considerations 433 None. 435 10. IANA Considerations 437 This memo requests that IANA registers application/raptorfec as 438 specified in Section 6.1.1, video/raptorfec as specified in 439 Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and 440 text/raptorfec as specified in Section 6.4.1. The media type is also 441 requested to be added to the IANA registry for "RTP Payload Format 442 MIME types" (http://www.iana.org/assignments/rtp-parameters). 444 11. Security Considerations 446 See [I-D.ietf-fecframe-framework] 448 12. References 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 454 Jacobson, "RTP: A Transport Protocol for Real-Time 455 Applications", STD 64, RFC 3550, July 2003. 457 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 458 Registration Procedures", BCP 13, RFC 4288, December 2005. 460 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 461 Formats", RFC 4855, February 2007. 463 [I-D.ietf-fecframe-framework] 464 Watson, M., "Forward Error Correction (FEC) Framework", 465 draft-ietf-fecframe-framework-03 (work in progress), 466 October 2008. 468 [I-D.ietf-fecframe-sdp-elements] 469 Begen, A., "SDP Elements for FEC Framework", 470 draft-ietf-fecframe-sdp-elements-02 (work in progress), 471 November 2008. 473 [I-D.ietf-fecframe-raptor] 474 Watson, M., "Raptor FEC Schemes for FECFRAME", 475 draft-ietf-fecframe-raptor-00 (work in progress), 476 October 2008. 478 Author's Address 480 Mark Watson 481 Qualcomm Inc. 482 3165 Kifer Rd. 483 Santa Clara, CA 95051 484 U.S.A. 486 Email: watson@qualcomm.com