idnits 2.17.1 draft-ietf-fecframe-rtp-raptor-00.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 4, 2009) is 5531 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 410, 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 Summary: 3 errors (**), 0 flaws (~~), 3 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 4, 2009 5 Expires: September 5, 2009 7 RTP Payload Format for Raptor FEC 8 draft-ietf-fecframe-rtp-raptor-00 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 5, 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 . . . . . . 11 71 6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 11 72 7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 14 74 9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 15 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 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.watson-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 an arbitrary number of 113 repair packets may be generated. The Raptor code has the property 114 that the original group of source packets can be recovered with very 115 high probability from any set of packets (source and repair) only 116 slightly greater in number than the original number of source 117 packets. 119 [I-D.watson-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 the 129 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.watson-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.watson-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.watson-fecframe-raptor] 182 Optional parameters: none 184 Encoding considerations: This media type is framed and binary, see 185 section 4.8 in [RFC4288] 187 Security considerations: Please see security consideration in 188 [I-D.ietf-fecframe-framework] 190 Interoperability considerations: 192 Published specification: [I-D.watson-fecframe-raptor] 194 Applications that use this media type: 196 Additional information: 198 Magic number(s): 200 File extension(s): 202 Macintosh file type code(s): 204 Person & email address to contact for further information: Mark 205 Watson, mark@digitalfountain.com 207 Intended usage: COMMON 209 Restrictions on usage: This media type depends on RTP framing, and 210 hence is only defined for transfer via RTP [[RFC3550]]. Transport 211 within other framing protocols is not defined at this time. 213 Author: Mark Watson, Digital Fountain 215 Change controller: IETF Audio/Video Transport working group delegated 216 from the IESG. 218 6.2. Registration of the video/raptorfec media type 220 This RTP payload format is identified using the video/raptorfec media 221 type which is registered in accordance with [RFC4855] and using the 222 template of [RFC4288]. 224 6.2.1. Media Type Definition 226 Type name: video 228 Subtype name: raptorfec 230 Required parameters: 232 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 233 for the specific Raptor FEC Scheme that will be used as defined in 234 [I-D.watson-fecframe-raptor] 236 Optional parameters: none 238 Encoding considerations: This media type is framed and binary, see 239 section 4.8 in [RFC4288] 241 Security considerations: Please see security consideration in 242 [I-D.ietf-fecframe-framework] 244 Interoperability considerations: 246 Published specification: [I-D.watson-fecframe-raptor] 248 Applications that use this media type: 250 Additional information: 252 Magic number(s): 254 File extension(s): 256 Macintosh file type code(s): 257 Person & email address to contact for further information: Mark 258 Watson, mark@digitalfountain.com 260 Intended usage: COMMON 262 Restrictions on usage: This media type depends on RTP framing, and 263 hence is only defined for transfer via RTP [[RFC3550]]. Transport 264 within other framing protocols is not defined at this time. 266 Author: Mark Watson, Digital Fountain 268 Change controller: IETF Audio/Video Transport working group delegated 269 from the IESG. 271 6.3. Registration of the audio/raptorfec media type 273 This RTP payload format is identified using the audio/raptorfec media 274 type which is registered in accordance with [RFC4855] and using the 275 template of [RFC4288]. 277 6.3.1. Media Type Definition 279 Type name: audio 281 Subtype name: raptorfec 283 Required parameters: 285 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 286 for the specific Raptor FEC Scheme that will be used as defined in 287 [I-D.watson-fecframe-raptor] 289 Optional parameters: none 291 Encoding considerations: This media type is framed and binary, see 292 section 4.8 in [RFC4288] 294 Security considerations: Please see security consideration in 295 [I-D.ietf-fecframe-framework] 297 Interoperability considerations: 299 Published specification: [I-D.watson-fecframe-raptor] 301 Applications that use this media type: 303 Additional information: 305 Magic number(s): 307 File extension(s): 309 Macintosh file type code(s): 311 Person & email address to contact for further information: Mark 312 Watson, mark@digitalfountain.com 314 Intended usage: COMMON 316 Restrictions on usage: This media type depends on RTP framing, and 317 hence is only defined for transfer via RTP [[RFC3550]]. Transport 318 within other framing protocols is not defined at this time. 320 Author: Mark Watson, Digital Fountain 322 Change controller: IETF Audio/Video Transport working group delegated 323 from the IESG. 325 6.4. Registration of the text/raptorfec media type 327 This RTP payload format is identified using the text/raptorfec media 328 type which is registered in accordance with [RFC4855] and using the 329 template of [RFC4288]. 331 6.4.1. Media Type Definition 333 Type name: text 335 Subtype name: raptorfec 337 Required parameters: 339 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 340 for the specific Raptor FEC Scheme that will be used as defined in 341 [I-D.watson-fecframe-raptor] 343 Optional parameters: none 345 Encoding considerations: This media type is framed and binary, see 346 section 4.8 in [RFC4288] 348 Security considerations: Please see security consideration in 349 [I-D.ietf-fecframe-framework] 351 Interoperability considerations: 353 Published specification: [I-D.watson-fecframe-raptor] 355 Applications that use this media type: 357 Additional information: 359 Magic number(s): 361 File extension(s): 363 Macintosh file type code(s): 365 Person & email address to contact for further information: Mark 366 Watson, mark@digitalfountain.com 368 Intended usage: COMMON 370 Restrictions on usage: This media type depends on RTP framing, and 371 hence is only defined for transfer via RTP [[RFC3550]]. Transport 372 within other framing protocols is not defined at this time. 374 Author: Mark Watson, Digital Fountain 376 Change controller: IETF Audio/Video Transport working group delegated 377 from the IESG. 379 7. Mapping to SDP 381 The mapping of the above defined payload format media type and its 382 parameters SHALL be done according to Section 3 of [RFC4855] 384 8. Offer/Answer considerations 386 None. 388 9. Declarative SDP Considerations 390 None. 392 10. IANA Considerations 394 This memo requests that IANA registers application/raptorfec as 395 specified in Section 6.1.1, video/raptorfec as specified in 396 Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and 397 text/raptorfec as specified in Section 6.4.1. The media type is also 398 requested to be added to the IANA registry for "RTP Payload Format 399 MIME types" (http://www.iana.org/assignments/rtp-parameters). 401 11. Security Considerations 403 See [I-D.ietf-fecframe-framework] 405 12. References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 411 Jacobson, "RTP: A Transport Protocol for Real-Time 412 Applications", STD 64, RFC 3550, July 2003. 414 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 415 Registration Procedures", BCP 13, RFC 4288, December 2005. 417 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 418 Formats", RFC 4855, February 2007. 420 [I-D.ietf-fecframe-framework] 421 Watson, M., "Forward Error Correction (FEC) Framework", 422 draft-ietf-fecframe-framework-03 (work in progress), 423 October 2008. 425 [I-D.watson-fecframe-raptor] 426 Watson, M., "Raptor FEC Schemes for FECFRAME", 427 draft-watson-fecframe-raptor-00 (work in progress), 428 July 2008. 430 Author's Address 432 Mark Watson 433 Qualcomm Inc. 434 3165 Kifer Rd. 435 Santa Clara, CA 95051 436 U.S.A. 438 Email: watson@qualcomm.com