draft-ietf-fecframe-rtp-raptor-06.txt   draft-ietf-fecframe-rtp-raptor-07.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 27, 2012 Nomor Research Expires: August 27, 2012 Nomor Research
M. Luby M. Luby
Qualcomm Incorporated Qualcomm Incorporated
November 24, 2011 February 24, 2012
RTP Payload Format for Raptor FEC RTP Payload Format for Raptor FEC
draft-ietf-fecframe-rtp-raptor-06 draft-ietf-fecframe-rtp-raptor-07
Abstract Abstract
This document specifies an RTP Payload Format for Forward Error This document specifies an RTP Payload Format for Forward Error
Correction repair data produced by the Raptor FEC Schemes. Raptor Correction repair data produced by the Raptor FEC Schemes. Raptor
FEC Schemes are specified for use with the IETF FEC Framework which FEC Schemes are specified for use with the IETF FEC Framework 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.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 27, 2012. This Internet-Draft will expire on August 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 5, line 9 skipping to change at page 5, line 9
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 one can generate an arbitrary number of repair packets. block') one can generate an arbitrary number of repair packets. The
The Raptor and RaptorQ codes have the property that the original Raptor and RaptorQ codes have the property that the original group of
group of source symbols can be recovered with very high probability source symbols can be recovered with very high probability from any
from any set of symbols (source and repair) only slightly greater in set of symbols (source and repair) only slightly greater in number
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 arbitrary packet flows: the first two Raptor and RaptorQ codes with arbitrary packet flows: the first two
schemes are fully applicable to arbitrary packet flows (using Raptor schemes are fully applicable to arbitrary 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
skipping to change at page 8, line 48 skipping to change at page 8, line 48
[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 and the format is unsigned integer. is specified in microseconds and the format is unsigned integer.
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 the [I-D.ietf-fecframe-raptor]. The default value of this parameter
value "A" SHALL be used by the receiver. (when it does not appear explicitly) is 'A'.
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
[RFC6363] [RFC6363]
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
skipping to change at page 10, line 32 skipping to change at page 10, line 32
[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 and the format is unsigned integer. is specified in microseconds and the format is unsigned integer.
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 the [I-D.ietf-fecframe-raptor]. The default value of this parameter
value "A" SHALL be used by the receiver. (when it does not appear explicitly) is 'A'.
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
[RFC6363] [RFC6363]
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
skipping to change at page 12, line 15 skipping to change at page 12, line 15
[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 and the format is unsigned integer. is specified in microseconds and the format is unsigned integer.
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 the [I-D.ietf-fecframe-raptor]. The default value of this parameter
value "A" SHALL be used by the receiver. (when it does not appear explicitly) is 'A'.
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
[RFC6363] [RFC6363]
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
skipping to change at page 13, line 47 skipping to change at page 13, line 47
[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 and the format is unsigned integer. is specified in microseconds and the format is unsigned integer.
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 the [I-D.ietf-fecframe-raptor]. The default value of this parameter
value "A" SHALL be used by the receiver. (when it does not appear explicitly) is 'A'.
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
[RFC6363] [RFC6363]
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
skipping to change at page 18, line 51 skipping to change at page 18, line 51
o an RTP header as specified in Section 4.1, and o an RTP header as specified in Section 4.1, and
o payload data as defined in Section 4.3. o payload data as defined in Section 4.3.
Repair Packet Construction may make use of the Sender Operation for Repair Packet Construction may make use of the Sender Operation for
RTP repair flows as specified in see [RFC6363], section 4.2. RTP repair flows as specified in see [RFC6363], section 4.2.
10.3. Usage of RTCP 10.3. Usage of RTCP
RTCP SHALL be used according to [RFC3550]. The repair RTP session RTCP SHALL be used according to [RFC3550]. If the repair RTP session
SHOULD be sent in a separate RTP session and the two sessions MAY be is sent in a separate RTP session the two sessions MUST be associated
associated using RTCP CNAME. using RTCP CNAME.
10.4. Source Packet Reconstruction 10.4. Source Packet Reconstruction
Source Packet Reconstruction may make use of the Receiver Operation Source Packet Reconstruction may make use of the Receiver Operation
for the case of RTP repair flows as specified in [RFC6363], section for the case of RTP repair flows as specified in [RFC6363], section
4.3. Depending on the FEC scheme in use of the ones defined in 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. [I-D.ietf-fecframe-raptor], the appropriate source blocks are formed.
If enough data for decoding of any or all of the missing source If enough data for decoding of any or all of the missing source
payloads in the source block has been received, the respective FEC payloads in the source block has been received, the respective FEC
decoding procedures are applied. decoding procedures are applied.
 End of changes. 11 change blocks. 
21 lines changed or deleted 21 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/