RTP Payload Format for Raptor FEC
draft-watson-fecframe-rtp-raptor-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 28, 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
2.  Conventions, Definitions and Acronyms
3.  Media Format Background
4.  Payload Format
    4.1.  RTP Header Usage
    4.2.  Payload Header
    4.3.  Payload Data
5.  Congestion Control Considerations
6.  Media Types
    6.1.  Registration of the application/raptorfec media type
        6.1.1.  Media Type Definition
    6.2.  Registration of the video/raptorfec media type
        6.2.1.  Media Type Definition
    6.3.  Registration of the audio/raptorfec media type
        6.3.1.  Media Type Definition
    6.4.  Registration of the text/raptorfec media type
        6.4.1.  Media Type Definition
7.  Mapping to SDP
8.  Offer/Answer considerations
9.  Declarative SDP Considerations
10.  IANA Considerations
11.  Security Considerations
12.  References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The FEC Framework [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.) 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.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Media Format Background

The Raptor code is an efficient XOR-based block-based fountain code, meaning that from any group of source packets 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.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.) 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.

4.  Payload Format

The RTP Payload contains a FEC Repair Payload as defined in [I‑D.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.).

4.1.  RTP Header Usage

The rules SHALL be followed for the RTP header used with FEC repair packets:

• 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
• 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] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.) and [I‑D.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.).

5.  Congestion Control Considerations

See [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.).

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] (Casner, S., “Media Type Registration of RTP Payload Formats,” February 2007.) and using the template of [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.).

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.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.)

Optional parameters: none

Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.)

Security considerations: Please see security consideration in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.)

Interoperability considerations:

Published specification: [I‑D.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.)

Applications that use this media type:

Additional information:

Magic number(s): <none defined>

File extension(s): <none defined>

Macintosh file type code(s): <none defined>

Person & email address to contact for further information: Mark Watson, mark@digitalfountain.com

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.)]. Transport within other framing protocols is not defined at this time.

Author: Mark Watson, Digital Fountain

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] (Casner, S., “Media Type Registration of RTP Payload Formats,” February 2007.) and using the template of [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.).

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.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.)

Optional parameters: none

Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.)

Security considerations: Please see security consideration in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.)

Interoperability considerations:

Published specification: [I‑D.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.)

Applications that use this media type:

Additional information:

Magic number(s): <none defined>

File extension(s): <none defined>

Macintosh file type code(s): <none defined>

Person & email address to contact for further information: Mark Watson, mark@digitalfountain.com

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.)]. Transport within other framing protocols is not defined at this time.

Author: Mark Watson, Digital Fountain

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] (Casner, S., “Media Type Registration of RTP Payload Formats,” February 2007.) and using the template of [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.).

6.3.1.  Media Type Definition

Type name: audio

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.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.)

Optional parameters: none

Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.)

Security considerations: Please see security consideration in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.)

Interoperability considerations:

Published specification: [I‑D.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.)

Applications that use this media type:

Additional information:

Magic number(s): <none defined>

File extension(s): <none defined>

Macintosh file type code(s): <none defined>

Person & email address to contact for further information: Mark Watson, mark@digitalfountain.com

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.)]. Transport within other framing protocols is not defined at this time.

Author: Mark Watson, Digital Fountain

Change controller: IETF Audio/Video Transport working group delegated 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] (Casner, S., “Media Type Registration of RTP Payload Formats,” February 2007.) and using the template of [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.).

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.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.)

Optional parameters: none

Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.)

Security considerations: Please see security consideration in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.)

Interoperability considerations:

Published specification: [I‑D.watson‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” July 2008.)

Applications that use this media type:

Additional information:

Magic number(s): <none defined>

File extension(s): <none defined>

Macintosh file type code(s): <none defined>

Person & email address to contact for further information: Mark Watson, mark@digitalfountain.com

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.)]. Transport within other framing protocols is not defined at this time.

Author: Mark Watson, Digital Fountain

Change controller: IETF Audio/Video Transport working group delegated from the IESG.

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] (Casner, S., “Media Type Registration of RTP Payload Formats,” February 2007.)

8.  Offer/Answer considerations

None.

9.  Declarative SDP Considerations

None.

10.  IANA Considerations

This memo requests that IANA registers application/raptorfec as specified in Section 6.1.1 (Media Type Definition), video/raptorfec as specified in Section 6.2.1 (Media Type Definition), audio/raptorfec as specified in Section 6.3.1 (Media Type Definition) and text/raptorfec as specified in Section 6.4.1 (Media Type Definition). 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).

11.  Security Considerations

See [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.)

12. References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.