FEC Framework Working Group M. Watson Internet-Draft Qualcomm Inc. Intended status: Standards Track March 6, 2009 Expires: September 7, 2009 RTP Payload Format for Raptor FEC draft-ietf-fecframe-rtp-raptor-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Watson Expires September 7, 2009 [Page 1] Internet-Draft RTP Payload Fromat for Raptor March 2009 Abstract This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 5. Congestion Control Considerations . . . . . . . . . . . . . . 7 6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Registration of the application/raptorfec media type . . . 8 6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8 6.2. Registration of the video/raptorfec media type . . . . . . 9 6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9 6.3. Registration of the audio/raptorfec media type . . . . . . 10 6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 10 6.4. Registration of the text/raptorfec media type . . . . . . 12 6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 12 7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 15 9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Watson Expires September 7, 2009 [Page 2] Internet-Draft RTP Payload Fromat for Raptor March 2009 1. Introduction The FEC Framework [I-D.ietf-fecframe-framework] defines a general framework for the use of Forward Error Correction in association with arbitrary packet flows, including flows over UDP and RTP. Forward Error Corrections operates by generating redundant data packets ("repair data") which can be sent independently from the original flow. At a receiver the original flow can be reconstructed provided a sufficient set of redundant data packets and possibly original data packets are received. The FEC Framework provides for independence between application protocols and FEC codes. The use of a particular FEC code within the framework is defined by means of an FEC Scheme which may then be used with any application protocol compliant to the framework. Repair data flows may be sent directly over a transport protocol such as UDP, or they may be encapsulated within RTP. In the latter case, an RTP Payload Format must be defined for each FEC Scheme. This document defines the RTP Payload Format for the Raptor FEC Schemes defined in [I-D.ietf-fecframe-raptor]. Watson Expires September 7, 2009 [Page 3] Internet-Draft RTP Payload Fromat for Raptor March 2009 2. Conventions, Definitions and Acronyms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Watson Expires September 7, 2009 [Page 4] Internet-Draft RTP Payload Fromat for Raptor March 2009 3. Media Format Background The Raptor code is an efficient XOR-based block-based fountain code, meaning that from any group of source packets (or 'source block') an arbitrary number of repair packets may be generated. The Raptor code has the property that the original group of source packets can be recovered with very high probability from any set of packets (source and repair) only slightly greater in number than the original number of source packets. [I-D.ietf-fecframe-raptor] defines three FEC Schemes for the use of the Raptor code with arbitary packet flows: the first scheme is fully applicable to arbitary packet flows. The second scheme is a slightly optimised version of the first scheme which is applicable in applications with relatively small block sizes. The third scheme is a variant of the second scheme which is applicable to a single source flow which already has some kind of identifiable sequence number. The presence of a sequence number in the source flow allows for backwards compatible operation (the source flows do not need to be modified in order to apply FEC). In this case, in the language of the FEC Framework, there is no explicit FEC Source Payload Id. Watson Expires September 7, 2009 [Page 5] Internet-Draft RTP Payload Fromat for Raptor March 2009 4. Payload Format The RTP Payload contains a FEC Repair Payload as defined in [I-D.ietf-fecframe-raptor]. 4.1. RTP Header Usage The rules SHALL be followed for the RTP header used with FEC repair packets: o Marker bit: The marker bit shall be set 1 for the last protection RTP packet sent for each source block, and otherwise set to 0 o Timestamp: The timestamp SHALL be set to a time corresponding to the packet's transmission time. The timestamp value has no use in the actual FEC protection process. It may be used for packet arrival timing and jitter calculations. 4.2. Payload Header There is no Payload Header in this Payload Format 4.3. Payload Data The RTP Payload contains a FEC Repair Payload as defined in [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor]. Watson Expires September 7, 2009 [Page 6] Internet-Draft RTP Payload Fromat for Raptor March 2009 5. Congestion Control Considerations See [I-D.ietf-fecframe-framework]. Watson Expires September 7, 2009 [Page 7] Internet-Draft RTP Payload Fromat for Raptor March 2009 6. Media Types 6.1. Registration of the application/raptorfec media type This RTP payload format is identified using the application/raptorfec media type which is registered in accordance with [RFC4855] and using the template of [RFC4288]. 6.1.1. Media Type Definition Type name: application Subtype name: raptorfec Required parameters: raptor-scheme-id: The value of this parameter is the FEC Scheme Id for the specific Raptor FEC Scheme that will be used as defined in [I-D.ietf-fecframe-raptor]. max-sbl: The value of this parameter is the FEC Object Transmission Information element "Maximum Source Block Length" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. symbol-size: The value of this parameter is the FEC Object Transmission Information element "Encoding Symbol Size" as definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. Optional parameters: none Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: Published specification: [I-D.ietf-fecframe-raptor] Applications that use this media type: Additional information: Magic number(s): Watson Expires September 7, 2009 [Page 8] Internet-Draft RTP Payload Fromat for Raptor March 2009 File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Mark Watson, watson@qualcomm.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Qualcomm Inc. Change controller: IETF Audio/Video Transport working group delegated from the IESG. 6.2. Registration of the video/raptorfec media type This RTP payload format is identified using the video/raptorfec media type which is registered in accordance with [RFC4855] and using the template of [RFC4288]. 6.2.1. Media Type Definition Type name: video Subtype name: raptorfec Required parameters: raptor-scheme-id: The value of this parameter is the FEC Scheme Id for the specific Raptor FEC Scheme that will be used as defined in [I-D.ietf-fecframe-raptor] max-sbl: The value of this parameter is the FEC Object Transmission Information element "Maximum Source Block Length" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. symbol-size: The value of this parameter is the FEC Object Transmission Information element "Encoding Symbol Size" as definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. Optional parameters: none Watson Expires September 7, 2009 [Page 9] Internet-Draft RTP Payload Fromat for Raptor March 2009 Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: Published specification: [I-D.ietf-fecframe-raptor] Applications that use this media type: Additional information: Magic number(s): File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Mark Watson, watson@qualcomm.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Qualcomm Inc. Change controller: IETF Audio/Video Transport working group delegated from the IESG. 6.3. Registration of the audio/raptorfec media type This RTP payload format is identified using the audio/raptorfec media type which is registered in accordance with [RFC4855] and using the template of [RFC4288]. 6.3.1. Media Type Definition Type name: audio Subtype name: raptorfec Required parameters: Watson Expires September 7, 2009 [Page 10] Internet-Draft RTP Payload Fromat for Raptor March 2009 raptor-scheme-id: The value of this parameter is the FEC Scheme Id for the specific Raptor FEC Scheme that will be used as defined in [I-D.ietf-fecframe-raptor] max-sbl: The value of this parameter is the FEC Object Transmission Information element "Maximum Source Block Length" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. symbol-size: The value of this parameter is the FEC Object Transmission Information element "Encoding Symbol Size" as definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. Optional parameters: none Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: Published specification: [I-D.ietf-fecframe-raptor] Applications that use this media type: Additional information: Magic number(s): File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Mark Watson, watson@qualcomm.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Qualcomm Inc. Change controller: IETF Audio/Video Transport working group delegated Watson Expires September 7, 2009 [Page 11] Internet-Draft RTP Payload Fromat for Raptor March 2009 from the IESG. 6.4. Registration of the text/raptorfec media type This RTP payload format is identified using the text/raptorfec media type which is registered in accordance with [RFC4855] and using the template of [RFC4288]. 6.4.1. Media Type Definition Type name: text Subtype name: raptorfec Required parameters: raptor-scheme-id: The value of this parameter is the FEC Scheme Id for the specific Raptor FEC Scheme that will be used as defined in [I-D.ietf-fecframe-raptor] max-sbl: The value of this parameter is the FEC Object Transmission Information element "Maximum Source Block Length" as defined in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. symbol-size: The value of this parameter is the FEC Object Transmission Information element "Encoding Symbol Size" as definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal integer. Optional parameters: none Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: Published specification: [I-D.ietf-fecframe-raptor] Applications that use this media type: Additional information: Magic number(s): Watson Expires September 7, 2009 [Page 12] Internet-Draft RTP Payload Fromat for Raptor March 2009 File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Mark Watson, watson@qualcomm.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Qualcomm Inc. Change controller: IETF Audio/Video Transport working group delegated from the IESG. Watson Expires September 7, 2009 [Page 13] Internet-Draft RTP Payload Fromat for Raptor March 2009 7. Mapping to SDP The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of [RFC4855] When the RTP Payload Formats defined in this document are used, the Media Type Parameters defined above SHALL be used to specify the FEC Object Transmission Information in preference to the SDP attributes specified in [I-D.ietf-fecframe-sdp-elements] Watson Expires September 7, 2009 [Page 14] Internet-Draft RTP Payload Fromat for Raptor March 2009 8. Offer/Answer considerations None. Watson Expires September 7, 2009 [Page 15] Internet-Draft RTP Payload Fromat for Raptor March 2009 9. Declarative SDP Considerations None. Watson Expires September 7, 2009 [Page 16] Internet-Draft RTP Payload Fromat for Raptor March 2009 10. IANA Considerations This memo requests that IANA registers application/raptorfec as specified in Section 6.1.1, video/raptorfec as specified in Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and text/raptorfec as specified in Section 6.4.1. The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" (http://www.iana.org/assignments/rtp-parameters). Watson Expires September 7, 2009 [Page 17] Internet-Draft RTP Payload Fromat for Raptor March 2009 11. Security Considerations See [I-D.ietf-fecframe-framework] Watson Expires September 7, 2009 [Page 18] Internet-Draft RTP Payload Fromat for Raptor March 2009 12. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-03 (work in progress), October 2008. [I-D.ietf-fecframe-sdp-elements] Begen, A., "SDP Elements for FEC Framework", draft-ietf-fecframe-sdp-elements-02 (work in progress), November 2008. [I-D.ietf-fecframe-raptor] Watson, M., "Raptor FEC Schemes for FECFRAME", draft-ietf-fecframe-raptor-00 (work in progress), October 2008. Watson Expires September 7, 2009 [Page 19] Internet-Draft RTP Payload Fromat for Raptor March 2009 Author's Address Mark Watson Qualcomm Inc. 3165 Kifer Rd. Santa Clara, CA 95051 U.S.A. Email: watson@qualcomm.com Watson Expires September 7, 2009 [Page 20]