RTP Payload Format for Raptor FEC
draft-ietf-fecframe-rtp-raptor-03

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.

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 9, 2010.

Copyright Notice

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

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

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 [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.). 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, M., “Raptor FEC Schemes for FECFRAME,” March 2010.).

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 and RaptorQ codes are efficient block-based fountain codes, meaning that from any group of source packets (or 'source block') an arbitrary number of repair packets may be generated. The Raptor and RaptorQ codes have the property that the original group of source symbols can be recovered with very high probability from any set of symbols (source and repair) only slightly greater in number than the original number of source symbols. The RaptorQ code additionally has the property that the probability that the original group of source symbols can be recovered from a set of symbols (source and repair) equal in number to the original number of source symbols is in many cases also very high.

[I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) defines six FEC Schemes for the use of the Raptor and RaptorQ codes with arbitary packet flows: the first two schemes are fully applicable to arbitary packet flows (using Raptor and RaptorQ respectively). The third and fourth schemes are slightly optimised versions of the first two schemes which are applicable in applications with relatively small block sizes. The fifth and sixth schemes are variants of the third and fourth schemes which are 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 need for an explicit FEC Source Payload Id and it is therefore not included in the packets.

4.  Payload Format

4.1.  RTP Header Usage

The following 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. The timestamp rate SHALL be specified using the "rate" media type parameter defined below.

Other header fields SHALL be set according to the rules of [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.).

4.2.  Payload Header

There is no Payload Header in this Payload Format

4.3.  Payload Data

Procedures and data formats for the use of Raptor Forward Error Correction in an FECFRAME context are fully defined in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.) and [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.) and are not duplicated here. The procedures of those documents SHALL be followed in order to generate repair data streams to be carried by the payload formats defined in this document.

The RTP Payload SHALL contain an FEC Repair Payload as defined in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.) and [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.).

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:

rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.

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] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.).

Kmax: The value of this parameter is the FEC Framework Configuration Information element "Maximum Source Block Length" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) encoded as a decimal integer.

T: The value of this parameter is the FEC Framework Configuration Information element "Encoding Symbol Size" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) encoded as a decimal integer.

repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds.

Optional parameters:

P: The value of this parameter is the FEC Framework Configuration Information element "Payload ID Format" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.). If this parameter is missing that the value "A" shall be assumed.

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

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, 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] (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, 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] (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:

rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.

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] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.).

Kmax: The value of this parameter is the FEC Framework Configuration Information element "Maximum Source Block Length" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) encoded as a decimal integer.

T: The value of this parameter is the FEC Framework Configuration Information element "Encoding Symbol Size" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) encoded as a decimal integer.

repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds.

Optional parameters:

P: The value of this parameter is the FEC Framework Configuration Information element "Payload ID Format" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.). If this parameter is missing that the value "A" shall be assumed.

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

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, 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] (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, 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] (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:

rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.

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] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.).

Kmax: The value of this parameter is the FEC Framework Configuration Information element "Maximum Source Block Length" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) encoded as a decimal integer.

T: The value of this parameter is the FEC Framework Configuration Information element "Encoding Symbol Size" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) encoded as a decimal integer.

repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds.

Optional parameters:

P: The value of this parameter is the FEC Framework Configuration Information element "Payload ID Format" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.). If this parameter is missing that the value "A" shall be assumed.

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

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, 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] (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, Qualcomm Inc.

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:

rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.

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] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.).

Kmax: The value of this parameter is the FEC Framework Configuration Information element "Maximum Source Block Length" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) encoded as a decimal integer.

T: The value of this parameter is the FEC Framework Configuration Information element "Encoding Symbol Size" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) encoded as a decimal integer.

repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds.

Optional parameters:

P: The value of this parameter is the FEC Framework Configuration Information element "Payload ID Format" as defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.). If this parameter is missing that the value "A" shall be assumed.

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

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, 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] (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, Qualcomm Inc.

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

7.  Mapping to SDP

Applications that are using RTP transport commonly use Session Description Protocol (SDP) [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) to describe their RTP sessions. The information that is used to specify the media types in an RTP session has specific mappings to the fields in an SDP description. Note that if an application does not use SDP to describe the RTP sessions, an appropriate mapping must be defined and used to specify the media types and their parameters for the control/description protocol employed by the application.

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.) following the suggestion therein regarding the mapping of payload-format-specific paraeters into the "a=fmtp" field.

When the RTP Payload Formats defined in this document are used, the Media Type Parameters defined above SHALL be used to specify the FEC Framework Configuration Information in preference to the SDP attributes specified in [I‑D.ietf‑fecframe‑sdp‑elements] (Begen, A., “SDP Elements for FEC Framework,” April 2010.)

8.  Offer/Answer considerations

When offering Raptor FEC over RTP using SDP in an Offer/Answer model [RFC3264] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.), the following considerations apply:

• Each combination of the Kmax and T parameters produces different FEC data and is not compatible with any other combination. A sender application may desire to offer multiple offers with different sets of Kmax and T values as long as the parameter values are valid. The receiver SHOULD normally choose the offer with the largest value of the product of Kmax and T that it supports.
• The size of the repair-window is related to the maximum delay between the transmission of a source packet and the associated repair packet. This directly impacts the buffering requirement on the receiver side and the receiver must consider this when choosing an offer.
• When the P parameter is omitted, FEC Payload ID Format A MUST be assumed. In an answer which selects an offer in which the P parameter was omitted, the P parameter MUST either be omitted, or included with value "A".

9.  Declarative SDP Considerations

In declarative usage, like SDP in the Real-time Streaming Protocol (RTSP) [RFC2326] (Schulzrinne, H., Rao, A., and R. Lanphier, “Real Time Streaming Protocol (RTSP),” April 1998.) or the Session Announcement Protocol (SAP) [RFC2947] (Altman, J., “Telnet Encryption: DES3 64 bit Cipher Feedback,” September 2000.), the following considerations apply:

• The payload format configuration parameters are all declarative and a participant MUST use the configuration that is provided for the session.
• More than one configuration may be provided (if desired) by declaring multiple RTP payload types. In that case, the receivers should choose the repair flow that is best for them.

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

Security Considerations related to the use of the FEC Framework are addressed in [I‑D.ietf‑fecframe‑framework] (Watson, M., “Forward Error Correction (FEC) Framework,” March 2010.). These consideration apply in full to users of the RTP Payload Formats defined in this document, since these are defined in terms of the FEC Framework.

No further security considerations related specifically to the Raptor FEC Schemes defined in [I‑D.ietf‑fecframe‑raptor] (Watson, M., “Raptor FEC Schemes for FECFRAME,” March 2010.) have been identified.

Users of RTP should consider the Security Considerations of [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.).

12. References

Author's Address