draft-ietf-fecframe-rtp-raptor-04.txt   draft-ietf-fecframe-rtp-raptor-05.txt 
FEC Framework Working Group M. Watson FEC Framework Working Group M. Watson
Internet-Draft Netflix Internet-Draft Netflix
Intended status: Standards Track T. Stockhammer Intended status: Standards Track T. Stockhammer
Expires: May 29, 2011 Nomor Research Expires: April 12, 2012 Nomor Research
November 25, 2010 October 10, 2011
RTP Payload Format for Raptor FEC RTP Payload Format for Raptor FEC
draft-ietf-fecframe-rtp-raptor-04 draft-ietf-fecframe-rtp-raptor-05
Abstract Abstract
This document specifies an RTP payload format for Forward Error This document specifies an RTP Payload Format for Forward Error
Correction /(FEC) repair data produced by the Raptor FEC schemes. Correction repair data produced by the Raptor FEC Schemes. Raptor
Raptor FEC schemes are specified for use with the IETF FEC Framework FEC Schemes are specified for use with the IETF FEC Framework which
which supports transport of repair data over both UDP and RTP. This supports transport of repair data over both UDP and RTP. This
document specifies the payload format which is required for the use document specifies the Payload Format which is required for the use
of RTP to carry Raptor repair flows. of RTP to carry Raptor repair flows.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 29, 2011. This Internet-Draft will expire on April 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4
3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 3. Media Format Background . . . . . . . . . . . . . . . . . . . 5
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
5. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Congestion Control Considerations . . . . . . . . . . . . . . 7
5.1. Registration of the application/raptorfec media type . . . 7 6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Media Type Definition . . . . . . . . . . . . . . . . 7 6.1. Registration of the application/raptorfec media type . . . 8
5.2. Registration of the video/raptorfec media type . . . . . . 8 6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8
5.2.1. Media Type Definition . . . . . . . . . . . . . . . . 8 6.2. Registration of the video/raptorfec media type . . . . . . 9
5.3. Registration of the audio/raptorfec media type . . . . . . 10 6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9
5.3.1. Media Type Definition . . . . . . . . . . . . . . . . 10 6.3. Registration of the audio/raptorfec media type . . . . . . 11
5.4. Registration of the text/raptorfec media type . . . . . . 12 6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 11
5.4.1. Media Type Definition . . . . . . . . . . . . . . . . 12 6.4. Registration of the text/raptorfec media type . . . . . . 13
6. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . . 14 6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 13
7. Offer/Answer considerations . . . . . . . . . . . . . . . . . 15 7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Declarative SDP Considerations . . . . . . . . . . . . . . . . 16 8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 16
9. FEC Generation and Recovery Procedures . . . . . . . . . . . . 17 9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 17
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.2. Repair Packet Construction . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Session Description Protocol (SDP) Example . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11. Congestion Control Considerations . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The FEC Framework [I-D.ietf-fecframe-framework] defines a general The FEC Framework [I-D.ietf-fecframe-framework] defines a general
framework for the use of Forward Error Correction (FEC) in framework for the use of Forward Error Correction in association with
association with arbitrary packet flows, including flows over UDP and arbitrary packet flows, including flows over UDP and RTP [RFC3550].
RTP [RFC3550]. FECs operates by generating repair data packets Forward Error Correction operates by generating redundant data
("repair data") which are sent separately from the source flow. At a packets ("repair data") which can be sent independently from the
receiver the source flow can be reconstructed provided a sufficient original flow. At a receiver the original flow can be reconstructed
set of source and repair data packets are received. provided a sufficient set of redundant data packets and possibly
original data packets are received.
The FEC Framework provides for independence between application The FEC Framework provides for independence between application
protocols and FEC codes. The use of a particular FEC code within the 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 framework is defined by means of a FEC Scheme which MAY then be used
with any application protocol compliant to the framework. with any application protocol compliant to the framework.
Repair data flows may be sent directly over a transport protocol such 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, as UDP, or they MAY be encapsulated within specialized transports for
an RTP payload format must be defined for each FEC scheme. multimedia, such as RTP.
This document defines the RTP payload format for the Raptor FEC This document defines the RTP Payload Format for the Raptor FEC
schemes defined in [I-D.ietf-fecframe-raptor]. Schemes defined in [I-D.ietf-fecframe-raptor].
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Media Format Background 3. Media Format Background
The Raptor and RaptorQ codes are efficient block-based fountain The Raptor and RaptorQ codes are efficient block-based fountain
codes, meaning that from any group of source packets (or 'source codes, meaning that from any group of source packets (or 'source
block') an arbitrary number of repair packets may be generated. The block') an arbitrary number of repair packets MAY be generated. The
Raptor and RaptorQ codes have the property that the original group of Raptor and RaptorQ codes have the property that the original group of
source symbols can be recovered with very high probability from any source symbols can be recovered with very high probability from any
set of symbols (source and repair) only slightly greater in number set of symbols (source and repair) only slightly greater in number
than the original number of source symbols. The RaptorQ code than the original number of source symbols. The RaptorQ code
additionally has the property that the probability that the original additionally has the property that the probability that the original
group of source symbols can be recovered from a set of symbols group of source symbols can be recovered from a set of symbols
(source and repair) equal in number to the original number of source (source and repair) equal in number to the original number of source
symbols is in many cases also very high. symbols is in many cases also very high.
[I-D.ietf-fecframe-raptor] defines six FEC schemes for the use of the [I-D.ietf-fecframe-raptor] defines six FEC Schemes for the use of the
Raptor and RaptorQ codes with arbitary packet flows: the first two Raptor and RaptorQ codes with arbitary packet flows: the first two
schemes are fully applicable to arbitary packet flows (using Raptor schemes are fully applicable to arbitary packet flows (using Raptor
and RaptorQ respectively). The third and fourth schemes are slightly and RaptorQ respectively). The third and fourth schemes are slightly
optimised versions of the first two schemes which are applicable in optimised versions of the first two schemes which are applicable in
applications with relatively small block sizes. The fifth and sixth applications with relatively small block sizes. The fifth and sixth
schemes are variants of the third and fourth schemes which are schemes are variants of the third and fourth schemes which are
applicable to a single source flow which already has some kind of applicable to a single source flow which already has some kind of
identifiable sequence number. The presence of a sequence number in identifiable sequence number. The presence of a sequence number in
the source flow allows for backwards compatible operation (the source the source flow allows for backwards-compatible operation (the source
flows do not need to be modified in order to apply FEC). In this 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 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 explicit FEC Source Payload Id and it is therefore not included in
the packets. the packets.
This document specifcies the payload format for RTP repair flows and This document specifcies the payload format for RTP repair flows and
can be used with any of the FEC schemes defined in can be used with any of the FEC Schemes defined in
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
4. Payload Format 4. Payload Format
4.1. RTP Header Usage 4.1. RTP Header Usage
The following rules SHALL be followed for the RTP header used with The following rules SHALL be followed for the RTP header used with
FEC repair packets: FEC repair packets:
o Marker bit: The marker bit SHALL be set 1 for the last protection 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 RTP packet sent for each source block, and otherwise set to 0.
o Timestamp: The timestamp SHALL be set to a time corresponding to 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 packet's transmission time. The timestamp value has no use in
the actual FEC protection process. It may be used for packet the actual FEC protection process. It MAY be used for packet
arrival timing and jitter calculations. The timestamp rate SHALL arrival timing and jitter calculations. The timestamp rate SHALL
be specified using the "rate" media type parameter defined below. be specified using the "rate" media type parameter defined below.
Other header fields SHALL be set according to the rules of [RFC3550]. Other header fields SHALL be set according to the rules of [RFC3550].
4.2. Payload Header 4.2. Payload Header
There is no Payload Header in this payload format. There is no Payload Header in this Payload Format.
4.3. Payload Data 4.3. Payload Data
Procedures and data formats for the use of Raptor FEC in an FECFRAME Procedures and data formats for the use of Raptor Forward Error
context are fully defined in [I-D.ietf-fecframe-raptor] and are not Correction in a FECFRAME context are fully defined in
duplicated here. The procedures of those documents SHALL be followed [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor] and are
in order to generate repair data streams to be carried by the payload not duplicated here. The procedures of those documents SHALL be
formats defined in this document. 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 The RTP Payload SHALL contain a FEC Repair Payload as defined in
[I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor].
5. Media Types 5. Congestion Control Considerations
5.1. Registration of the application/raptorfec media type See [I-D.ietf-fecframe-framework].
6. Media Types
6.1. Registration of the application/raptorfec media type
This RTP payload format is identified using the application/raptorfec This RTP payload format is identified using the application/raptorfec
media type which is registered in accordance with [RFC4855] and using media type which is registered in accordance with [RFC4855] and using
the template of [RFC4288]. the template of [RFC4288].
5.1.1. Media Type Definition 6.1.1. Media Type Definition
Type name: application Type name: application
Subtype name: raptorfec Subtype name: raptorfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate o rate: The RTP timestamp (clock) rate. The operator SHALL select a
SHALL be larger than 1000 to provide sufficient resolution to RTCP rate larger than 1000 Hz to provide sufficient resolution to RTCP
operations. However, it is RECOMMENDED to select the rate that operations and the operator SHOULD select the rate that matches
matches the rate of the protected source RTP stream. the rate of the protected source RTP stream.
o raptor-scheme-id: The value of this parameter is the FEC scheme Id o 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 for the specific Raptor FEC Scheme that will be used as defined in
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o Kmax: The value of this parameter is the FEC Framework o Kmax: The value of this parameter is the FEC Framework
Configuration Information element "Maximum Source Block Length" as Configuration Information element "Maximum Source Block Length" as
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal defined in [I-D.ietf-fecframe-raptor] encoded as a decimal
integer. For specific requirements for this value refer to integer. For specific requirements for this value refer to
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o T: The value of this parameter is the FEC Framework Configuration o T: The value of this parameter is the FEC Framework Configuration
Information element "Encoding Symbol Size" as defined in Information element "Encoding Symbol Size" as defined in
skipping to change at page 7, line 50 skipping to change at page 8, line 50
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o repair-window: The maximum time that spans the source packets and o repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window the corresponding repair packets. The size of the repair window
is specified in microseconds. is specified in microseconds.
Optional parameters: Optional parameters:
o P: The value of this parameter is the FEC Framework Configuration o P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in Information element "Payload ID Format" as defined in
[I-D.ietf-fecframe-raptor]. If this parameter is missing then the [I-D.ietf-fecframe-raptor]. If this parameter is missing the
value "A" shall be assumed. value "A" SHALL be assumed.
Encoding considerations: This media type is framed and binary, see Encoding considerations: This media type is framed and binary, see
section 4.8 in [RFC4288] section 4.8 in [RFC4288]
Security considerations: Please see security consideration in Security considerations: Please see security consideration in
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Interoperability considerations: None Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
Applications that use this media type: Applications that use this media type:
Additional information: Additional information:
Magic number(s): <none defined> Magic number(s): <none defined>
File extension(s): <none defined> File extension(s): <none defined>
skipping to change at page 8, line 39 skipping to change at page 9, line 39
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [[RFC3550]]. Transport hence is only defined for transfer via RTP [[RFC3550]]. Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Mark Watson, Netflix Author: Mark Watson, Netflix
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF Audio/Video Transport working group delegated
from the IESG. from the IESG.
5.2. Registration of the video/raptorfec media type 6.2. Registration of the video/raptorfec media type
This RTP payload format is identified using the video/raptorfec media This RTP payload format is identified using the video/raptorfec media
type which is registered in accordance with [RFC4855] and using the type which is registered in accordance with [RFC4855] and using the
template of [RFC4288]. template of [RFC4288].
5.2.1. Media Type Definition 6.2.1. Media Type Definition
Type name: video Type name: video
Subtype name: raptorfec Subtype name: raptorfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate o rate: The RTP timestamp (clock) rate. The operator SHALL select a
SHALL be larger than 1000 to provide sufficient resolution to RTCP rate larger than 1000 Hz to provide sufficient resolution to RTCP
operations. However, it is RECOMMENDED to select the rate that operations and the operator SHOULD select the rate that matches
matches the rate of the protected source RTP stream. the rate of the protected source RTP stream.
o raptor-scheme-id: The value of this parameter is the FEC scheme Id o 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 for the specific Raptor FEC Scheme that will be used as defined in
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o Kmax: The value of this parameter is the FEC Framework o Kmax: The value of this parameter is the FEC Framework
Configuration Information element "Maximum Source Block Length" as Configuration Information element "Maximum Source Block Length" as
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal defined in [I-D.ietf-fecframe-raptor] encoded as a decimal
integer. For specific requirements for this value refer to integer. For specific requirements for this value refer to
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o T: The value of this parameter is the FEC Framework Configuration o T: The value of this parameter is the FEC Framework Configuration
Information element "Encoding Symbol Size" as defined in Information element "Encoding Symbol Size" as defined in
skipping to change at page 9, line 34 skipping to change at page 10, line 34
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o repair-window: The maximum time that spans the source packets and o repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window the corresponding repair packets. The size of the repair window
is specified in microseconds. is specified in microseconds.
Optional parameters: Optional parameters:
o P: The value of this parameter is the FEC Framework Configuration o P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in Information element "Payload ID Format" as defined in
[I-D.ietf-fecframe-raptor]. If this parameter is missing then the [I-D.ietf-fecframe-raptor]. If this parameter is missing the
value "A" shall be assumed. value "A" SHALL be assumed.
Encoding considerations: This media type is framed and binary, see Encoding considerations: This media type is framed and binary, see
section 4.8 in [RFC4288] section 4.8 in [RFC4288]
Security considerations: Please see security consideration in Security considerations: Please see security consideration in
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Interoperability considerations: None Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
Applications that use this media type: Applications that use this media type:
Additional information: Additional information:
Magic number(s): <none defined> Magic number(s): <none defined>
File extension(s): <none defined> File extension(s): <none defined>
skipping to change at page 10, line 22 skipping to change at page 11, line 22
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [[RFC3550]]. Transport hence is only defined for transfer via RTP [[RFC3550]]. Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Mark Watson, Netflix. Author: Mark Watson, Netflix.
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF Audio/Video Transport working group delegated
from the IESG. from the IESG.
5.3. Registration of the audio/raptorfec media type 6.3. Registration of the audio/raptorfec media type
This RTP payload format is identified using the audio/raptorfec media This RTP payload format is identified using the audio/raptorfec media
type which is registered in accordance with [RFC4855] and using the type which is registered in accordance with [RFC4855] and using the
template of [RFC4288]. template of [RFC4288].
5.3.1. Media Type Definition 6.3.1. Media Type Definition
Type name: audio Type name: audio
Subtype name: raptorfec Subtype name: raptorfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate o rate: The RTP timestamp (clock) rate. The operator SHALL select a
SHALL be larger than 1000 to provide sufficient resolution to RTCP rate larger than 1000 Hz to provide sufficient resolution to RTCP
operations. However, it is RECOMMENDED to select the rate that operations and the operator SHOULD select the rate that matches
matches the rate of the protected source RTP stream. the rate of the protected source RTP stream.
o raptor-scheme-id: The value of this parameter is the FEC scheme Id o 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 for the specific Raptor FEC Scheme that will be used as defined in
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o Kmax: The value of this parameter is the FEC Framework o Kmax: The value of this parameter is the FEC Framework
Configuration Information element "Maximum Source Block Length" as Configuration Information element "Maximum Source Block Length" as
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal defined in [I-D.ietf-fecframe-raptor] encoded as a decimal
integer. For specific requirements for this value refer to integer. For specific requirements for this value refer to
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o T: The value of this parameter is the FEC Framework Configuration o T: The value of this parameter is the FEC Framework Configuration
Information element "Encoding Symbol Size" as defined in Information element "Encoding Symbol Size" as defined in
skipping to change at page 11, line 19 skipping to change at page 12, line 19
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o repair-window: The maximum time that spans the source packets and o repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window the corresponding repair packets. The size of the repair window
is specified in microseconds. is specified in microseconds.
Optional parameters: Optional parameters:
o P: The value of this parameter is the FEC Framework Configuration o P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in Information element "Payload ID Format" as defined in
[I-D.ietf-fecframe-raptor]. If this parameter is missing then the [I-D.ietf-fecframe-raptor]. If this parameter is missing the
value "A" shall be assumed. value "A" SHALL be assumed.
Encoding considerations: This media type is framed and binary, see Encoding considerations: This media type is framed and binary, see
section 4.8 in [RFC4288] section 4.8 in [RFC4288]
Security considerations: Please see security consideration in Security considerations: Please see security consideration in
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Interoperability considerations: None Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
Applications that use this media type: Applications that use this media type:
Additional information: Additional information:
Magic number(s): <none defined> Magic number(s): <none defined>
File extension(s): <none defined> File extension(s): <none defined>
skipping to change at page 12, line 8 skipping to change at page 13, line 8
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [[RFC3550]]. Transport hence is only defined for transfer via RTP [[RFC3550]]. Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Mark Watson, Netflix. Author: Mark Watson, Netflix.
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF Audio/Video Transport working group delegated
from the IESG. from the IESG.
5.4. Registration of the text/raptorfec media type 6.4. Registration of the text/raptorfec media type
This RTP payload format is identified using the text/raptorfec media This RTP payload format is identified using the text/raptorfec media
type which is registered in accordance with [RFC4855] and using the type which is registered in accordance with [RFC4855] and using the
template of [RFC4288]. template of [RFC4288].
5.4.1. Media Type Definition 6.4.1. Media Type Definition
Type name: text Type name: text
Subtype name: raptorfec Subtype name: raptorfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate in Hz. The (integer) rate o rate: The RTP timestamp (clock) rate. The operator SHALL select a
SHALL be larger than 1000 to provide sufficient resolution to RTCP rate larger than 1000 Hz to provide sufficient resolution to RTCP
operations. However, it is RECOMMENDED to select the rate that operations and the operator SHOULD select the rate that matches
matches the rate of the protected source RTP stream. the rate of the protected source RTP stream.
o raptor-scheme-id: The value of this parameter is the FEC scheme Id o 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 for the specific Raptor FEC Scheme that will be used as defined in
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o Kmax: The value of this parameter is the FEC Framework o Kmax: The value of this parameter is the FEC Framework
Configuration Information element "Maximum Source Block Length" as Configuration Information element "Maximum Source Block Length" as
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal defined in [I-D.ietf-fecframe-raptor] encoded as a decimal
integer. For specific requirements for this value refer to integer. For specific requirements for this value refer to
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o T: The value of this parameter is the FEC Framework Configuration o T: The value of this parameter is the FEC Framework Configuration
Information element "Encoding Symbol Size" as defined in Information element "Encoding Symbol Size" as defined in
skipping to change at page 12, line 51 skipping to change at page 13, line 51
[I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-raptor].
o repair-window: The maximum time that spans the source packets and o repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window the corresponding repair packets. The size of the repair window
is specified in microseconds. is specified in microseconds.
Optional parameters: Optional parameters:
o P: The value of this parameter is the FEC Framework Configuration o P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in Information element "Payload ID Format" as defined in
[I-D.ietf-fecframe-raptor]. If this parameter is missing then the [I-D.ietf-fecframe-raptor]. If this parameter is missing the
value "A" shall be assumed. value "A" SHALL be assumed.
Encoding considerations: This media type is framed and binary, see Encoding considerations: This media type is framed and binary, see
section 4.8 in [RFC4288] section 4.8 in [RFC4288]
Security considerations: Please see security consideration in Security considerations: Please see security consideration in
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Interoperability considerations: None Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
Applications that use this media type: Applications that use this media type:
Additional information: Additional information:
Magic number(s): <none defined> Magic number(s): <none defined>
File extension(s): <none defined> File extension(s): <none defined>
skipping to change at page 14, line 5 skipping to change at page 15, line 5
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [[RFC3550]]. Transport hence is only defined for transfer via RTP [[RFC3550]]. Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Mark Watson, Netflix. Author: Mark Watson, Netflix.
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF Audio/Video Transport working group delegated
from the IESG. from the IESG.
6. Mapping to SDP Parameters 7. Mapping to SDP
Applications that are using RTP transport commonly use Session Applications that are using RTP transport commonly use Session
Description Protocol (SDP) [RFC4566] to describe their RTP sessions. Description Protocol (SDP) [RFC4566] to describe their RTP sessions.
The information that is used to specify the media types in an RTP The information that is used to specify the media types in an RTP
session has specific mappings to the fields in an SDP description. session has specific mappings to the fields in an SDP description.
Note that if an application does not use SDP to describe the RTP Note that if an application does not use SDP to describe the RTP
sessions, an appropriate mapping must be defined and used to specify sessions, an appropriate mapping must be defined and used to specify
the media types and their parameters for the control/description the media types and their parameters for the control/description
protocol employed by the application. protocol employed by the application.
The mapping of the media type specification for "raptorfec" and its The mapping of the above defined payload format media type and its
parameters in SDP is as follows: parameters SHALL be done according to Section 3 of [RFC4855]
following the suggestion therein regarding the mapping of payload-
o The media type (e.g., "application") goes into the "m=" line as format-specific parameters into the ""a=fmtp"" field.
the media name.
o The media subtype ("raptorfec") goes into the 'a=rtpmap' line as
the encoding name. The RTP clock rate parameter ("rate") also
goes into the 'a=rtpmap' line as the clock rate.
o The remaining required payload-format-specific parameters go into
the 'a=fmtp' line by copying them directly from the media type
string as a semicolon-separated list of parameter=value pairs.
An SDP Example is provided in Section 10. 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]
7. Offer/Answer considerations 8. Offer/Answer considerations
When offering Raptor FEC over RTP using SDP in an Offer/Answer model When offering Raptor FEC over RTP using SDP in an Offer/Answer model
[RFC3264], the following considerations apply: [RFC3264], the following considerations apply:
o Each combination of the Kmax and T parameters produces different o Each combination of the Kmax and T parameters produces different
FEC data and is not compatible with any other combination. A FEC data and is not compatible with any other combination. A
sender application may desire to offer multiple offers with sender application MAY desire to offer multiple offers with
different sets of Kmax and T values as long as the parameter different sets of Kmax and T values as long as the parameter
values are valid. The receiver SHOULD normally choose the offer values are valid. The receiver SHOULD normally choose the offer
with the largest value of the product of Kmax and T that it with the largest value of the product of Kmax and T that it
supports. supports.
o The size of the repair-window is related to the maximum delay o The size of the repair-window is related to the maximum delay
between the transmission of a source packet and the associated between the transmission of a source packet and the associated
repair packet. This directly impacts the buffering requirement on repair packet. This directly impacts the buffering requirement on
the receiver side and the receiver must consider this when the receiver side and the receiver must consider this when
choosing an offer. choosing an offer.
o When the P parameter is omitted, FEC Payload ID Format A MUST be o 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 assumed. In an answer which selects an offer in which the P
parameter was omitted, the P parameter MUST either be omitted, or parameter was omitted, the P parameter MUST either be omitted, or
included with value "A". included with value "A".
8. Declarative SDP Considerations 9. Declarative SDP Considerations
In declarative usage, like SDP in the Real-time Streaming Protocol In declarative usage, like SDP in the Real-time Streaming Protocol
(RTSP) [RFC2326] or the Session Announcement Protocol (SAP) (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
[RFC2947], the following considerations apply: [RFC2974], the following considerations apply:
o The payload format configuration parameters are all declarative o The payload format configuration parameters are all declarative
and a participant MUST use the configuration that is provided for and a participant MUST use the configuration that is provided for
the session. the session.
o More than one configuration may be provided (if desired) by o More than one configuration MAY be provided (if desired) by
declaring multiple RTP payload types. In that case, the receivers declaring multiple RTP payload types. In that case, the receivers
should choose the repair flow that is best for them. should choose the repair flow that is best for them.
9. FEC Generation and Recovery Procedures 10. IANA Considerations
9.1. Overview
This document only specifies the repair packet construction when the
repair packets are delivered with RTP. Source packet construction is
covered in [I-D.ietf-fecframe-raptor]. This section provides an
overview on how to generate repair packets and on how to reconstruct
missing source packets from a set of available source and repair
packets. Detailed algorithms for the generation of Raptor and
RaptorQ symbols are provided in [RFC5053] and
[I-D.ietf-rmt-bb-fec-raptorq], respectively.
9.2. Repair Packet Construction
The construction of the repair packet is fully specified in
Section 4. A repair packet is constructed by the concatenation of
o an RTP header as specified in Section 4.1, and
o payload data as defined in Section 4.
Repair Packet Construction may make use of the Sender Operation for
RTP repair flows as specified in see [I-D.ietf-fecframe-framework],
section 4.2.
9.3. Source Packet Reconstruction
Source Packet Reconstruction may make use of the Receiver Operation
for the case of RTP repair flows as specified in see
[I-D.ietf-fecframe-framework], section 4.3. Depending on the FEC
scheme in use of the ones defined in [I-D.ietf-fecframe-raptor], the
appropriate source blocks are formed. If enough data for decoding of
any or all of the missing source payloads in the source block has
been received, the respective FEC decoding procedures are applied.
In case the FEC scheme uses Raptor codes as defined in [RFC5053],
then the Example FEC decoder as specifed in [RFC5053], section 5.5,
may be used.
In case the FEC scheme uses RaptorQ codes as defined in
[I-D.ietf-rmt-bb-fec-raptorq], then the Example FEC decoder as
specifed in [I-D.ietf-rmt-bb-fec-raptorq], section 5.4, may be used.
10. Session Description Protocol (SDP) Example
This section provides an SDP [RFC4566] example. Assume we have one
source video stream (mid:S1) and one FEC repair stream (mid:R1). We
form one FEC group with the "a=group:FEC S1 R1" line. The source and
repair streams are sent to the same port on different multicast
groups. The repair window is set to 200 ms. An Explicit Source FEC
Payload ID is used for the source flow.
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor RTP FEC Example
t=0 0
a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0; tag-len=4
a=mid:S1
m=application 30000 RTP/AVT
c=IN IP4 233.252.0.2/127
a=rtpmap:110 raptorfec/90000
a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128; P=A; repair-window=200000
a=mid:R1
11. Congestion Control Considerations
FEC is an effective approach to provide applications resiliency
against packet losses. However, in networks where the congestion is
a major contributor to the packet loss, the potential impacts of
using FEC SHOULD be considered carefully before injecting the repair
flows into the network. In particular, in bandwidth-limited
networks, FEC repair flows may consume most or all of the available
bandwidth and consequently may congest the network. In such cases,
the applications MUST NOT arbitrarily increase the amount of FEC
protection since doing so may lead to a congestion collapse. If
desired, stronger FEC protection MAY be applied only after the source
rate has been reduced. In a network-friendly implementation, an
application SHOULD NOT send/ receive FEC repair flows if it knows
that sending/receiving those FEC repair flows would not help at all
in recovering the missing packets. Such a practice helps reduce the
amount of wasted bandwidth. It is RECOMMENDED that the amount of FEC
protection is adjusted dynamically based on the packet loss rate
observed by the applications. In multicast scenarios, it may be
difficult to optimize the FEC protection per receiver. If there is a
large variation among the levels of FEC protection needed by
different receivers, it is RECOMMENDED that the sender offers
multiple repair flows with different levels of FEC protection and the
receivers join the corresponding multicast sessions to receive the
repair flow(s) that is best for them.
For more background and normative requirements, see This memo requests that IANA registers application/raptorfec as
[I-D.ietf-fecframe-framework], section 8. 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).
12. Security Considerations 11. Security Considerations
Security Considerations related to the use of the FEC Framework are Security Considerations related to the use of the FEC Framework are
addressed in [I-D.ietf-fecframe-framework], section 9. These addressed in [I-D.ietf-fecframe-framework]. These consideration
consideration apply in full to users of the RTP payload formats apply in full to users of the RTP Payload Formats defined in this
defined in this document, since these are defined in terms of the FEC document, since these are defined in terms of the FEC Framework.
Framework.
No further security considerations related specifically to the Raptor No further security considerations related specifically to the Raptor
FEC schemes defined in [I-D.ietf-fecframe-raptor] have been FEC Schemes defined in [I-D.ietf-fecframe-raptor] have been
identified. identified.
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550] and in any applicable RTP profile. The main specification [RFC3550] and in any applicable RTP profile. The main
security considerations for the RTP packet carrying the RTP payload security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity and format defined within this memo are confidentiality, integrity and
source authenticity. Confidentiality is achieved by encrypting the source authenticity. Confidentiality is achieved by encrypting the
RTP payload. Integrity of the RTP packets is achieved through a RTP payload. Integrity of the RTP packets is achieved through a
suitable cryptographic integrity protection mechanism. Such a suitable cryptographic integrity protection mechanism. Such a
cryptographic system may also allow the authentication of the source cryptographic system MAY also allow the authentication of the source
of the payload. A suitable security mechanism for this RTP payload of the payload. A suitable security mechanism for this RTP payload
format should provide confidentiality, integrity protection, and at format should provide confidentiality, integrity protection, and at
least source authentication capable of determining if an RTP packet least source authentication capable of determining if an RTP packet
is from a member of the RTP session. Note that the appropriate is from a member of the RTP session. Note that the appropriate
mechanism to provide security to RTP and payloads following this memo mechanism to provide security to RTP and payloads following this memo
may vary. It is dependent on the application, transport and MAY vary. It is dependent on the application, transport and
signaling protocol employed. Therefore, a single mechanism is not signaling protocol employed. Therefore, a single mechanism is not
sufficient, although if suitable, using the Secure Real-time sufficient, although if suitable, using the Secure Real-time
Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms Transport Protocol (SRTP) [RFC3711] is RECOMMENDED. Other mechanisms
that may be used are IPsec [RFC4301] and Transport Layer Security that MAY be used are IPsec [RFC4301] and Transport Layer Security
(TLS) [RFC5246] (RTP over TCP); other alternatives may exist. (TLS) [RFC5246] (RTP over TCP); other alternatives MAY exist.
13. IANA Considerations
New media subtypes are subject to IANA registration. For the
registration of the payload format and its parameters introduced in
this document, refer to Section 5.
14. Acknowledgements
Thanks are due to Ali C. Begen and Colin Perkins for thorough review
of earlier draft versions of this document.
15. References 12. References
15.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework", Watson, M., Begen, A., and V. Roca, "Forward Error
draft-ietf-fecframe-framework-10 (work in progress), Correction (FEC) Framework",
September 2010. draft-ietf-fecframe-framework-15 (work in progress),
June 2011.
[I-D.ietf-fecframe-sdp-elements]
Begen, A., "Session Description Protocol Elements for FEC
Framework", draft-ietf-fecframe-sdp-elements-11 (work in
progress), October 2010.
[I-D.ietf-fecframe-raptor] [I-D.ietf-fecframe-raptor]
Watson, M., "Raptor FEC Schemes for FECFRAME", Watson, M., Stockhammer, T., and M. Luby, "Raptor FEC
draft-ietf-fecframe-raptor-02 (work in progress), Schemes for FECFRAME", draft-ietf-fecframe-raptor-05 (work
March 2010. in progress), September 2011.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme for Object
Delivery", RFC 5053, October 2007.
[I-D.ietf-rmt-bb-fec-raptorq]
Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
and L. Minder, "RaptorQ Forward Error Correction Scheme
for Object Delivery", draft-ietf-rmt-bb-fec-raptorq-04
(work in progress), August 2010.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
15.2. Informative References
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2947] Altman, J., "Telnet Encryption: DES3 64 bit Cipher
Feedback", RFC 2947, September 2000.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
12.2. Informative References
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
Authors' Addresses Authors' Addresses
Mark Watson Mark Watson
Netflix Netflix
100 Winchester Circle 100 Winchester Circle
Los Gatos, CA 95032 Los Gatos, CA 95032
U.S.A. U.S.A.
Email: watsonm@netflix.com Email: watsonm@netflix.com
 End of changes. 69 change blocks. 
272 lines changed or deleted 161 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/