idnits 2.17.1 draft-watson-fecframe-rtp-raptor-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 485. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2008) is 5657 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: 'RFC3095' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC5052' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC2736' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 416, 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-02 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework Working Group M. Watson 3 Internet-Draft Digital Fountain 4 Intended status: Standards Track October 22, 2008 5 Expires: April 25, 2009 7 RTP Payload Format for Raptor FEC 8 draft-watson-fecframe-rtp-raptor-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 25, 2009. 35 Abstract 37 This document specifies an RTP Payload Format for Forward Error 38 Correction repair data produced by the Raptor FEC Schemes. Raptor 39 FEC Schemes are specified for use with the IETF FEC Framework which 40 supports transport of repair data over both UDP and RTP. This 41 document specifies the Payload Format which is required for the use 42 of RTP to carry Raptor repair flows. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 48 3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 49 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 50 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 51 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 52 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 53 5. Congestion Control Considerations . . . . . . . . . . . . . . 7 54 6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 6.1. Registration of the application/raptorfec media type . . . 8 56 6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8 57 6.2. Registration of the video/raptorfec media type . . . . . . 9 58 6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9 59 6.3. Registration of the audio/raptorfec media type . . . . . . 10 60 6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 10 61 6.4. Registration of the text/raptorfec media type . . . . . . 11 62 6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 11 63 7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 13 64 8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 14 65 9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 15 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 Intellectual Property and Copyright Statements . . . . . . . . . . 20 72 1. Introduction 74 The FEC Framework [I-D.ietf-fecframe-framework] defines a general 75 framework for the use of Forward Error Correction in association with 76 arbitrary packet flows, including flows over UDP and RTP. Forward 77 Error Corrections operates by generating redundant data packets 78 ("repair data") which can be sent independently from the original 79 flow. At a receiver the original flow can be reconstructed provided 80 a sufficient set of redundant data packets and possibly original data 81 packets are received. 83 The FEC Framework provides for independence between application 84 protocols and FEC codes. The use of a particular FEC code within the 85 framework is defined by means of an FEC Scheme which may then be used 86 with any application protocol compliant to the framework. 88 Repair data flows may be sent directly over a transport protocol such 89 as UDP, or they may be encapsulated within RTP. In the latter case, 90 an RTP Payload Format must be defined for each FEC Scheme. 92 This document defines the RTP Payload Format for the Raptor FEC 93 Schemes defined in [I-D.watson-fecframe-raptor]. 95 2. Conventions, Definitions and Acronyms 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Media Format Background 103 The Raptor code is an efficient XOR-based block-based fountain code, 104 meaning that from any group of source packets an arbitrary number of 105 repair packets may be generated. The Raptor code has the property 106 that the original group of source packets can be recovered with very 107 high probability from any set of packets (source and repair) only 108 slightly greater in number than the original number of source 109 packets. 111 [I-D.watson-fecframe-raptor] defines three FEC Schemes for the use of 112 the Raptor code with arbitary packet flows: the first scheme is fully 113 applicable to arbitary packet flows. The second scheme is a slightly 114 optimised version of the first scheme which is applicable in 115 applications with relatively small block sizes. The third scheme is 116 a variant of the second scheme which is applicable to a single source 117 flow which already has some kind of identifiable sequence number. 118 The presence of a sequence number in the source flow allows for 119 backwards compatible operation (the source flows do not need to be 120 modified in order to apply FEC). In this case in the language of the 121 FEC Framework, there is no explicit FEC Source Payload Id. 123 4. Payload Format 125 The RTP Payload contains a FEC Repair Payload as defined in 126 [I-D.watson-fecframe-raptor]. 128 4.1. RTP Header Usage 130 The rules SHALL be followed for the RTP header used with FEC repair 131 packets: 133 o Marker bit: The marker bit shall be set 1 for the last protection 134 RTP packet sent for each source block, and otherwise set to 0 136 o Timestamp: The timestamp SHALL be set to a time corresponding to 137 the packet's transmission time. The timestamp value has no use in 138 the actual FEC protection process. It may be used for packet 139 arrival timing and jitter calculations. 141 4.2. Payload Header 143 There is no Payload Header in this Payload Format 145 4.3. Payload Data 147 The RTP Payload contains a FEC Repair Payload as defined in 148 [I-D.ietf-fecframe-framework] and [I-D.watson-fecframe-raptor]. 150 5. Congestion Control Considerations 152 See [I-D.ietf-fecframe-framework]. 154 6. Media Types 156 6.1. Registration of the application/raptorfec media type 158 This RTP payload format is identified using the application/raptorfec 159 media type which is registered in accordance with [RFC4855] and using 160 the template of [RFC4288]. 162 6.1.1. Media Type Definition 164 Type name: application 166 Subtype name: raptorfec 168 Required parameters: 170 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 171 for the specific Raptor FEC Scheme that will be used as defined in 172 [I-D.watson-fecframe-raptor] 174 Optional parameters: none 176 Encoding considerations: This media type is framed and binary, see 177 section 4.8 in [RFC4288] 179 Security considerations: Please see security consideration in 180 [I-D.ietf-fecframe-framework] 182 Interoperability considerations: 184 Published specification: [I-D.watson-fecframe-raptor] 186 Applications that use this media type: 188 Additional information: 190 Magic number(s): 192 File extension(s): 194 Macintosh file type code(s): 196 Person & email address to contact for further information: Mark 197 Watson, mark@digitalfountain.com 199 Intended usage: COMMON 201 Restrictions on usage: This media type depends on RTP framing, and 202 hence is only defined for transfer via RTP [[RFC3550]]. Transport 203 within other framing protocols is not defined at this time. 205 Author: Mark Watson, Digital Fountain 207 Change controller: IETF Audio/Video Transport working group delegated 208 from the IESG. 210 6.2. Registration of the video/raptorfec media type 212 This RTP payload format is identified using the video/raptorfec media 213 type which is registered in accordance with [RFC4855] and using the 214 template of [RFC4288]. 216 6.2.1. Media Type Definition 218 Type name: video 220 Subtype name: raptorfec 222 Required parameters: 224 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 225 for the specific Raptor FEC Scheme that will be used as defined in 226 [I-D.watson-fecframe-raptor] 228 Optional parameters: none 230 Encoding considerations: This media type is framed and binary, see 231 section 4.8 in [RFC4288] 233 Security considerations: Please see security consideration in 234 [I-D.ietf-fecframe-framework] 236 Interoperability considerations: 238 Published specification: [I-D.watson-fecframe-raptor] 240 Applications that use this media type: 242 Additional information: 244 Magic number(s): 246 File extension(s): 248 Macintosh file type code(s): 249 Person & email address to contact for further information: Mark 250 Watson, mark@digitalfountain.com 252 Intended usage: COMMON 254 Restrictions on usage: This media type depends on RTP framing, and 255 hence is only defined for transfer via RTP [[RFC3550]]. Transport 256 within other framing protocols is not defined at this time. 258 Author: Mark Watson, Digital Fountain 260 Change controller: IETF Audio/Video Transport working group delegated 261 from the IESG. 263 6.3. Registration of the audio/raptorfec media type 265 This RTP payload format is identified using the audio/raptorfec media 266 type which is registered in accordance with [RFC4855] and using the 267 template of [RFC4288]. 269 6.3.1. Media Type Definition 271 Type name: audio 273 Subtype name: raptorfec 275 Required parameters: 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.watson-fecframe-raptor] 281 Optional parameters: none 283 Encoding considerations: This media type is framed and binary, see 284 section 4.8 in [RFC4288] 286 Security considerations: Please see security consideration in 287 [I-D.ietf-fecframe-framework] 289 Interoperability considerations: 291 Published specification: [I-D.watson-fecframe-raptor] 293 Applications that use this media type: 295 Additional information: 297 Magic number(s): 299 File extension(s): 301 Macintosh file type code(s): 303 Person & email address to contact for further information: Mark 304 Watson, mark@digitalfountain.com 306 Intended usage: COMMON 308 Restrictions on usage: This media type depends on RTP framing, and 309 hence is only defined for transfer via RTP [[RFC3550]]. Transport 310 within other framing protocols is not defined at this time. 312 Author: Mark Watson, Digital Fountain 314 Change controller: IETF Audio/Video Transport working group delegated 315 from the IESG. 317 6.4. Registration of the text/raptorfec media type 319 This RTP payload format is identified using the text/raptorfec media 320 type which is registered in accordance with [RFC4855] and using the 321 template of [RFC4288]. 323 6.4.1. Media Type Definition 325 Type name: text 327 Subtype name: raptorfec 329 Required parameters: 331 raptor-scheme-id: The value of this parameter is the FEC Scheme Id 332 for the specific Raptor FEC Scheme that will be used as defined in 333 [I-D.watson-fecframe-raptor] 335 Optional parameters: none 337 Encoding considerations: This media type is framed and binary, see 338 section 4.8 in [RFC4288] 340 Security considerations: Please see security consideration in 341 [I-D.ietf-fecframe-framework] 343 Interoperability considerations: 345 Published specification: [I-D.watson-fecframe-raptor] 347 Applications that use this media type: 349 Additional information: 351 Magic number(s): 353 File extension(s): 355 Macintosh file type code(s): 357 Person & email address to contact for further information: Mark 358 Watson, mark@digitalfountain.com 360 Intended usage: COMMON 362 Restrictions on usage: This media type depends on RTP framing, and 363 hence is only defined for transfer via RTP [[RFC3550]]. Transport 364 within other framing protocols is not defined at this time. 366 Author: Mark Watson, Digital Fountain 368 Change controller: IETF Audio/Video Transport working group delegated 369 from the IESG. 371 7. Mapping to SDP 373 The mapping of the above defined payload format media type and its 374 parameters SHALL be done according to Section 3 of [RFC4855] 376 8. Offer/Answer considerations 378 None. 380 9. Declarative SDP Considerations 382 None. 384 10. IANA Considerations 386 This memo requests that IANA registers application/raptorfec as 387 specified in Section 6.1.1, video/raptorfec as specified in 388 Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and 389 text/raptorfec as specified in Section 6.4.1. The media type is also 390 requested to be added to the IANA registry for "RTP Payload Format 391 MIME types" (http://www.iana.org/assignments/rtp-parameters). 393 11. Security Considerations 395 See [I-D.ietf-fecframe-framework] 397 12. References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 403 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 404 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 405 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 406 Compression (ROHC): Framework and four profiles: RTP, UDP, 407 ESP, and uncompressed", RFC 3095, July 2001. 409 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 410 Correction (FEC) Building Block", RFC 5052, August 2007. 412 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 413 Payload Format Specifications", BCP 36, RFC 2736, 414 December 1999. 416 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 417 Jacobson, "RTP: A Transport Protocol for Real-Time 418 Applications", STD 64, RFC 3550, July 2003. 420 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 421 Registration Procedures", BCP 13, RFC 4288, December 2005. 423 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 424 Formats", RFC 4855, February 2007. 426 [I-D.ietf-fecframe-framework] 427 Watson, M., "Forward Error Correction (FEC) Framework", 428 draft-ietf-fecframe-framework-02 (work in progress), 429 July 2008. 431 [I-D.watson-fecframe-raptor] 432 Watson, M., "Raptor FEC Schemes for FECFRAME", 433 draft-watson-fecframe-raptor-00 (work in progress), 434 July 2008. 436 Author's Address 438 Mark Watson 439 Digital Fountain 440 39141 Civic Center Drive 441 Suite 300 442 Fremont, CA 94538 443 U.S.A. 445 Email: mark@digitalfountain.com 447 Full Copyright Statement 449 Copyright (C) The IETF Trust (2008). 451 This document is subject to the rights, licenses and restrictions 452 contained in BCP 78, and except as set forth therein, the authors 453 retain all their rights. 455 This document and the information contained herein are provided on an 456 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 457 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 458 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 459 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 460 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 461 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 463 Intellectual Property 465 The IETF takes no position regarding the validity or scope of any 466 Intellectual Property Rights or other rights that might be claimed to 467 pertain to the implementation or use of the technology described in 468 this document or the extent to which any license under such rights 469 might or might not be available; nor does it represent that it has 470 made any independent effort to identify any such rights. Information 471 on the procedures with respect to rights in RFC documents can be 472 found in BCP 78 and BCP 79. 474 Copies of IPR disclosures made to the IETF Secretariat and any 475 assurances of licenses to be made available, or the result of an 476 attempt made to obtain a general license or permission for the use of 477 such proprietary rights by implementers or users of this 478 specification can be obtained from the IETF on-line IPR repository at 479 http://www.ietf.org/ipr. 481 The IETF invites any interested party to bring to its attention any 482 copyrights, patents or patent applications, or other proprietary 483 rights that may cover technology that may be required to implement 484 this standard. Please address the information to the IETF at 485 ietf-ipr@ietf.org.