draft-ietf-fecframe-raptor-00.txt   draft-ietf-fecframe-raptor-01.txt 
FEC Framework M. Watson FEC Framework M. Watson
Internet-Draft Digital Fountain Internet-Draft Qualcomm, Inc.
Intended status: Standards Track October 22, 2008 Intended status: Standards Track July 8, 2009
Expires: April 25, 2009 Expires: January 9, 2010
Raptor FEC Schemes for FECFRAME Raptor FEC Schemes for FECFRAME
draft-ietf-fecframe-raptor-00 draft-ietf-fecframe-raptor-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2009. This Internet-Draft will expire on January 9, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes Fully-Specified Forward Error Correction This document describes Fully-Specified Forward Error Correction
(FEC) Schemes for the Raptor code and its application to reliable (FEC) Schemes for the Raptor code and its application to reliable
delivery of media streams in the context of FEC Framework. The delivery of media streams in the context of FEC Framework. The
Raptor code is a systematic code, where a number of repair symbols Raptor code is a systematic code, where a number of repair symbols
are generated from a set of source symbols and sent in one or more are generated from a set of source symbols and sent in one or more
repair flows in addition to the source symbols that are sent to the repair flows in addition to the source symbols that are sent to the
receiver(s) within a source flow. The Raptor code offers a close to receiver(s) within a source flow. The Raptor code offers a close to
skipping to change at page 2, line 4 skipping to change at page 2, line 13
delivery of media streams in the context of FEC Framework. The delivery of media streams in the context of FEC Framework. The
Raptor code is a systematic code, where a number of repair symbols Raptor code is a systematic code, where a number of repair symbols
are generated from a set of source symbols and sent in one or more are generated from a set of source symbols and sent in one or more
repair flows in addition to the source symbols that are sent to the repair flows in addition to the source symbols that are sent to the
receiver(s) within a source flow. The Raptor code offers a close to receiver(s) within a source flow. The Raptor code offers a close to
optimal protection against arbitrary packet losses at a low optimal protection against arbitrary packet losses at a low
computational complexity. Two FEC Schemes are defined, one for computational complexity. Two FEC Schemes are defined, one for
protection of arbitrary packet flows and another for protection of a protection of arbitrary packet flows and another for protection of a
single flow that already contains a sequence number. Repair data may single flow that already contains a sequence number. Repair data may
be sent over arbitrary datagram transport (e.g. UDP) or using RTP. be sent over arbitrary datagram transport (e.g. UDP) or using RTP.
An RTP Payload Type is defined for this latter case. An RTP Payload Type is defined for this latter case.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Document Outline . . . . . . . . . . . . . . . . . . . . . . . 5 2. Document Outline . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
4. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 4. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5
4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
5. General procedures for Raptor FEC Schemes . . . . . . . . . . 7 5. General procedures for Raptor FEC Schemes . . . . . . . . . . 6
6. Raptor FEC Scheme for arbitrary packet flows . . . . . . . . . 8 6. Raptor FEC Scheme for arbitrary packet flows . . . . . . . . . 8
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 8 6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 8
6.2.1. FEC Framework Configuration Information . . . . . . . 8 6.2.1. FEC Framework Configuration Information . . . . . . . 8
6.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 9 6.2.2. Source FEC Payload ID . . . . . . . . . . . . . . . . 9
6.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 9 6.2.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 9
6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Source symbol construction . . . . . . . . . . . . . . 10 6.3.1. Source symbol construction . . . . . . . . . . . . . . 10
6.3.2. Repair packet construction . . . . . . . . . . . . . . 10 6.3.2. Repair packet construction . . . . . . . . . . . . . . 10
6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 11 6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 7 skipping to change at page 4, line 4
8.2.3. Repair packet construction . . . . . . . . . . . . . . 16 8.2.3. Repair packet construction . . . . . . . . . . . . . . 16
8.2.4. Procedures for RTP source flows . . . . . . . . . . . 16 8.2.4. Procedures for RTP source flows . . . . . . . . . . . 16
8.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 16 8.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Session Description Protocol (SDP) Signaling . . . . . . . . . 16 10. Session Description Protocol (SDP) Signaling . . . . . . . . . 16
11. Congestion Control Considerations . . . . . . . . . . . . . . 17 11. Congestion Control Considerations . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 17 12.1. Registration of FEC Scheme IDs . . . . . . . . . . . . . . 17
13. Normative References . . . . . . . . . . . . . . . . . . . . . 17 13. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The FEC Framework [I-D.ietf-fecframe-framework] describes a framework The FEC Framework [I-D.ietf-fecframe-framework] describes a framework
for the application of Forward Error Correction to arbitrary packet for the application of Forward Error Correction to arbitrary packet
flows. Modelled after the FEC Building Block developed by the IETF flows. Modelled after the FEC Building Block developed by the IETF
Reliable Multicast Transport working group ([RFC5052]), the FEC Reliable Multicast Transport working group ([RFC5052]), the FEC
Framework defines the concept of FEC Schemes which provide specific Framework defines the concept of FEC Schemes which provide specific
Forward Error Correction schemes. This document describes two FEC Forward Error Correction schemes. This document describes two FEC
Schemes which make use of the Raptor FEC code as defined in Schemes which make use of the Raptor FEC code as defined in
[RFC5053]. [RFC5053].
The FEC protection mechanism is independent of the type of the source The FEC protection mechanism is independent of the type of the source
data, which can be an arbitrary sequence of packets, including for data, which can be an arbitrary sequence of packets, including for
example audio or video data. In general, the operation of the example audio or video data. In general, the operation of the
protection mechanism is as follows: protection mechanism is as follows:
o The sender determines a set of source packets to be protected o The sender determines a set of source packets (a source block) to
together based on the FEC Framework Configuration Information. be protected together based on the FEC Framework Configuration
Information.
o The sender arranges the source packets into a set of source o The sender arranges the source packets into a set of source
symbols, each of which is the same size. symbols, each of which is the same size.
o The sender applies the Raptor protection operation on the source o The sender applies the Raptor protection operation on the source
symbols to generate the required number of repair symbols. symbols to generate the required number of repair symbols.
o The sender packetizes the repair symbols and sends the repair o The sender packetizes the repair symbols and sends the repair
packet(s) along with the source packets to the receiver(s). packet(s) along with the source packets to the receiver(s).
skipping to change at page 5, line 26 skipping to change at page 5, line 27
Raptor code in the context of the FEC Framework. Raptor code in the context of the FEC Framework.
Section 6defines an FEC Scheme for the case of arbitrary source Section 6defines an FEC Scheme for the case of arbitrary source
flows and follows the format defined for FEC Schemes in flows and follows the format defined for FEC Schemes in
[I-D.ietf-fecframe-framework]. This scheme is equivalent to that [I-D.ietf-fecframe-framework]. This scheme is equivalent to that
defined in [3GPP MBMS Specification]. defined in [3GPP MBMS Specification].
Section 7 defines an FEC Scheme similar to that defined in Section 7 defines an FEC Scheme similar to that defined in
Section 6but with optimisations for the case where only limited Section 6but with optimisations for the case where only limited
source block sizes are required. This scheme is equivalent to source block sizes are required. This scheme is equivalent to
that defined in [DVB AL-FEC specification] for arbitrary packet that defined in [dvbts] for arbitrary packet flows.
flows.
Section 8 defines an FEC Scheme for the case of a single sequenced
flow and follows the format defined for FEC Schemes in
[I-D.ietf-fecframe-framework]. This scheme is equivalent to that Section 8 defines an FEC Scheme for the case of a single flow
defined in [DVB AL-FEC specification] for the case of a single which is already provided with a source packet sequence number.
sequenced flow. This scheme is equivalent to that defined in [dvbts] for the case
of a single sequenced flow.
3. Requirements Notation 3. Requirements Notation
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].
4. Definitions and Abbreviations 4. Definitions and Abbreviations
The definitions, notations and abbreviations commonly used in this The definitions, notations and abbreviations commonly used in this
skipping to change at page 7, line 10 skipping to change at page 7, line 5
o SS-FSSI: Sender-Side FEC-Scheme-Specific Information. o SS-FSSI: Sender-Side FEC-Scheme-Specific Information.
o RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. o RS-FSSI: Receiver-Side FEC-Scheme-Specific Information.
5. General procedures for Raptor FEC Schemes 5. General procedures for Raptor FEC Schemes
This section specifies general procedures which apply to all Raptor This section specifies general procedures which apply to all Raptor
FEC Schemes, specifically the construction of source symbols from a FEC Schemes, specifically the construction of source symbols from a
set of source transport payloads. As described in set of source transport payloads. As described in
[I-D.ietf-fecframe-framework] for each source transport payload in a [I-D.ietf-fecframe-framework] for each Application Data Unit in a
source block, the FEC Scheme is provided with: source block, the FEC Scheme is provided with:
o A description of the source transport flow with which the o A description of the source data flow with which the Application
transport payload is associated and an integer identifier Data Unit is associated and an integer identifier associated with
associated with that flow. that flow.
o The source transport payload itself. o The Application Data Unit itself.
o The length of the source transport payload. o The length of the Application Data Unit.
For each source transport payload, we define the Source Packet For each Application Data Unit, we define the Application Data Unit
Information (SPI) as follows: Information (ADUI) as follows:
Let Let
n be the number of source transport payloads in the source block. n be the number of Application Data Units in the source block.
T be the source symbol size in bytes. Note: this information is T be the source symbol size in bytes. Note: this information is
provided by the FEC Scheme as defined below. provided by the FEC Scheme as defined below.
i the index to the (i+1)-th source transport payload to be added i the index to the (i+1)-th Application Data Unit to be added to
to the source block, 0 <= i < n. the source block, 0 <= i < n.
R[i] denote the number of octets in the (i+1)-th source transport R[i] denote the number of octets in the (i+1)-th Application Data
payload. Unit.
l[i] be a length indication associated with the i-th UDP packet - l[i] be a length indication associated with the i-th Application
the nature of the length indication is defined by the FEC Scheme. Data Unit - the nature of the length indication is defined by the
FEC Scheme.
L[i] denote two octets representing the value of l[i] in network L[i] denote two octets representing the value of l[i] in network
byte order (high order octet first) of the i-th UDP packet. byte order (high order octet first) of the i-th Application Data
Unit.
f[i] denote the integer identifier associated with the source f[i] denote the integer identifier associated with the source data
transport payload from which the i-th source transport payload was flow from which the i-th Application Data Unit was taken.
taken.
F[i] denote a single octet representing the value of f[i]. F[i] denote a single octet representing the value of f[i].
s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note
s[i] is the length of SPI[i] in units of symbols of size T bytes. s[i] is the length of SPI[i] in units of symbols of size T bytes.
P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding
octets to align the start of each UDP packet with the start of a octets to align the start of each UDP packet with the start of a
symbol. symbol.
SPI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. ADUI[i] be the concatenation of F[i] ,L[i], R[i] and P[i].
Then, a source data block is constructed by concatenating SPI[i] for Then, a source data block is constructed by concatenating ADUI[i] for
i = 0, 1, 2, ... n-1. The source data block size, S, is then given i = 0, 1, 2, ... n-1. The source data block size, S, is then given
by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer
Encoding Symbol IDs consecutively starting from zero within the Encoding Symbol IDs consecutively starting from zero within the
source block. Each source transport payload is associated with the source block. Each Application Data Unit is associated with the
Encoding Symbol ID of the first symbol containing SPI for that Encoding Symbol ID of the first symbol containing SPI for that
packet. Thus, the Encoding Symbol ID value associated with the j-th packet. Thus, the Encoding Symbol ID value associated with the j-th
source packet, ESI[j], is given by ESI[j] = 0, for j=0 and ESI[j] = source packet, ESI[j], is given by ESI[j] = 0, for j=0 and ESI[j] =
sum{s[i], i=0,...,(j-1)}, for 0 < j < n. sum{s[i], i=0,...,(j-1)}, for 0 < j < n.
Source blocks are identified by integer Source Block Numbers. This Source blocks are identified by integer Source Block Numbers. This
specification does not specify how Source Block Numbers are allocated specification does not specify how Source Block Numbers are allocated
to source blocks. The Source FEC Packet Identification Information to source blocks. The Source FEC Packet Identification Information
consists of the identity of the source block and the Encoding Symbol consists of the identity of the source block and the Encoding Symbol
ID associated with the packet. ID associated with the packet.
skipping to change at page 8, line 45 skipping to change at page 8, line 41
This scheme is equivalent to that specified in [3GPP MBMS This scheme is equivalent to that specified in [3GPP MBMS
Specification]. Specification].
6.2. Formats and Codes 6.2. Formats and Codes
6.2.1. FEC Framework Configuration Information 6.2.1. FEC Framework Configuration Information
6.2.1.1. FEC Scheme ID 6.2.1.1. FEC Scheme ID
The value of the FEC Scheme ID for the fully-specified FEC scheme The value of the FEC Scheme ID for the fully-specified FEC scheme
defined in this section MUST be TBD as assigned by IANA. defined in this section is XXX, as assigned by IANA.
6.2.1.2. Scheme-Specific Elements 6.2.1.2. Scheme-Specific Elements
The scheme-specific elements of the FEC Framework Configuration The scheme-specific elements of the FEC Framework Configuration
information for this scheme are as follows: information for this scheme are as follows:
Maximum Source Block Length A non-negative integer less than 2^13, Maximum Source Block Length A non-negative integer less than 2^13,
in units of symbols in units of symbols
Encoding Symbol Size A non-negative integer less than 2^16, in units Encoding Symbol Size A non-negative integer less than 2^16, in units
skipping to change at page 12, line 5 skipping to change at page 12, line 5
symbols are then discarded after decoding. The source block size symbols are then discarded after decoding. The source block size
to be used for a stream is signalled in the Maximum Source Block to be used for a stream is signalled in the Maximum Source Block
Size field of the scheme-specific information. This allows for Size field of the scheme-specific information. This allows for
efficient parallel encoding of multiple streams. efficient parallel encoding of multiple streams.
A restricted set of possible source block sizes is specified. A restricted set of possible source block sizes is specified.
This allows explicit operation sequences for encoding the This allows explicit operation sequences for encoding the
restricted set of block sizes to be pre-calculated and embedded in restricted set of block sizes to be pre-calculated and embedded in
software or handware. software or handware.
This scheme is equivalent to that specified in [DVB AL-FEC This scheme is equivalent to that specified in [dvbts] for arbitrary
Specification] for arbitrary packet flows. packet flows.
7.2. Formats and Codes 7.2. Formats and Codes
7.2.1. FEC Framework Configuration Information 7.2.1. FEC Framework Configuration Information
7.2.1.1. FEC Scheme ID 7.2.1.1. FEC Scheme ID
The value of the FEC Scheme ID for the fully-specified FEC scheme The value of the FEC Scheme ID for the fully-specified FEC scheme
defined in this section MUST be TBD as assigned by IANA. defined in this section is XXX, as assigned by IANA.
7.2.1.2. FEC Scheme specific information 7.2.1.2. FEC Scheme specific information
See . (Section 6.2.1.2) See . (Section 6.2.1.2)
7.2.2. Source FEC Payload ID 7.2.2. Source FEC Payload ID
See . (Section 6.2.2) See . (Section 6.2.2)
7.2.3. Repair FEC Payload ID 7.2.3. Repair FEC Payload ID
skipping to change at page 13, line 36 skipping to change at page 13, line 36
8. Raptor FEC Scheme for a single sequenced flow 8. Raptor FEC Scheme for a single sequenced flow
8.1. Formats and codes 8.1. Formats and codes
8.1.1. FEC Framework Configuration Information 8.1.1. FEC Framework Configuration Information
8.1.1.1. FEC Scheme ID 8.1.1.1. FEC Scheme ID
The value of the FEC Scheme ID for the fully-specified FEC scheme The value of the FEC Scheme ID for the fully-specified FEC scheme
defined in this section MUST be TBD as assigned by IANA. defined in this section is XXX, as assigned by IANA.
8.1.1.2. Scheme-specific elements 8.1.1.2. Scheme-specific elements
See Section 6.2.1.2 See Section 6.2.1.2
8.1.2. Source FEC Payload ID 8.1.2. Source FEC Payload ID
The Source FEC Payload ID field is not used by this FEC Scheme. The Source FEC Payload ID field is not used by this FEC Scheme.
Source packets are not modified by this FEC Scheme. Source packets are not modified by this FEC Scheme.
skipping to change at page 15, line 19 skipping to change at page 15, line 19
received in any Repair FEC packet belonging to this Source Block. received in any Repair FEC packet belonging to this Source Block.
Source blocks are identified by the sequence number of the first Source blocks are identified by the sequence number of the first
source packet in the block. This information is signaled in all source packet in the block. This information is signaled in all
Repair FEC packets associated with the source block in the Initial Repair FEC packets associated with the source block in the Initial
Sequence Number field. Sequence Number field.
The length of the Source Packet Information (in bytes) for source The length of the Source Packet Information (in bytes) for source
packets within a source block is equal to length of the payload packets within a source block is equal to length of the payload
containing encoding symbols of the repair packets (i.e. not including containing encoding symbols of the repair packets (i.e. not including
the Repair FEC Payload ID) for that block, which MUST be the same for the Repair FEC Payload ID) for that block, which MUST be the same for
all repair packets. The Source Packet Information Length (SPIL) in all repair packets. The Application Data Unit Information Length
symbols is equal to this length divided by the Encoding Symbol Size (ADUIL) in symbols is equal to this length divided by the Encoding
(which is signaled in the FEC Framework Configuration Information). Symbol Size (which is signaled in the FEC Framework Configuration
The set of source packets which are included in the source block is Information). The set of source packets which are included in the
determined from the Initial Sequence Number (ISN) and Source Block source block is determined from the Initial Sequence Number (ISN) and
Length (SBL) as follows: Source Block Length (SBL) as follows:
Let, Let,
I be the Initial Sequence Number of the source block I be the Initial Sequence Number of the source block
LP be the Source Packet Information Length in symbols LP be the Source Packet Information Length in symbols
LB be the Source Block Length in symbols LB be the Source Block Length in symbols
Then, source packets with sequence numbers from I to I +LB/LP-1 Then, source packets with sequence numbers from I to I +LB/LP-1
skipping to change at page 16, line 19 skipping to change at page 16, line 19
8.2.3. Repair packet construction 8.2.3. Repair packet construction
See Section 7.3.2 See Section 7.3.2
8.2.4. Procedures for RTP source flows 8.2.4. Procedures for RTP source flows
In the specific case of RTP source packet flows, then the RTP In the specific case of RTP source packet flows, then the RTP
Sequence Number field SHALL be used as the sequence number in the Sequence Number field SHALL be used as the sequence number in the
procedures described above. The length indication included in the procedures described above. The length indication included in the
Source Packet Information SHALL be the RTP payload length plus the Application Data Unit Information SHALL be the RTP payload length
length of the CSRCs, if any, and the RTP padding bytes, if any. Note plus the length of the CSRCs, if any, and the RTP padding bytes, if
that this length is always equal to the UDP payload length of the any. Note that this length is always equal to the UDP payload length
packet, minus 12. of the packet minus 12.
8.3. FEC Code Specification 8.3. FEC Code Specification
See Section 7.4 See Section 7.4
9. Security Considerations 9. Security Considerations
For the general security considerations related to the use of FEC, For the general security considerations related to the use of FEC,
refer to [I-D.ietf-fecframe-framework]. refer to [I-D.ietf-fecframe-framework].
skipping to change at page 17, line 6 skipping to change at page 17, line 6
example uses the SDP elements for FEC Framework, which were example uses the SDP elements for FEC Framework, which were
introduced in [I-D.ietf-fecframe-sdp-elements], and the FEC grouping introduced in [I-D.ietf-fecframe-sdp-elements], and the FEC grouping
semantics [RFC4756]. semantics [RFC4756].
In this example, we have one source video stream (mid:S1) and one FEC In this example, 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 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 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. on different multicast groups. The repair window is set to 200 ms.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Interleaved Parity FEC Example s=Raptor FEC Example
t=0 0 t=0 0
a=group:FEC S1 R1 a=group:FEC S1 R1
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0; tag-len=4
a=mid:S1 a=mid:S1
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 224.1.2.1/127 c=IN IP4 233.252.0.2/127
a=fec-repair-flow: scheme-id=0; ss-fssi=5hu= a=fec-repair-flow: encoding-id=0; fssi=5hu=
a=repair-window: 200 a=repair-window: 200
a=mid:R1 a=mid:R1
11. Congestion Control Considerations 11. Congestion Control Considerations
For the general congestion control considerations related to the use For the general congestion control considerations related to the use
of FEC, refer to [I-D.ietf-fecframe-framework]. of FEC, refer to [I-D.ietf-fecframe-framework].
12. IANA Considerations 12. IANA Considerations
12.1. Registration of FEC Scheme IDs 12.1. Registration of FEC Scheme IDs
The value of FEC Scheme IDs is subject to IANA registration. For The value of FEC Scheme IDs is subject to IANA registration. For
general guidelines on IANA considerations as they apply to this general guidelines on IANA considerations as they apply to this
document, refer to [I-D.ietf-fecframe-framework]. document, refer to [I-D.ietf-fecframe-framework].
This document registers three values in the FEC Framework (FECFRAME)
FEC Encoding IDs registry as follows:
o XXX for the Raptor FEC Scheme for Arbitrary Packet Flows
(Section 6.
o XXX for the Optimised Raptor FEC Scheme for Arbitrary Packet Flows
(Section 7).
o XXX for the Raptor FEC Scheme for a single sequence flow
(Section 8).
13. Normative References 13. Normative References
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework", Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-02 (work in progress), draft-ietf-fecframe-framework-03 (work in progress),
July 2008. October 2008.
[RFC5052] "", 2005.
[RFC5053] "", 2005.
[I-D.ietf-fecframe-sdp-elements] [I-D.ietf-fecframe-sdp-elements]
Begen, A., "SDP Elements for FEC Framework", Begen, A., "SDP Elements for FEC Framework",
draft-ietf-fecframe-sdp-elements-01 (work in progress), draft-ietf-fecframe-sdp-elements-03 (work in progress),
July 2008. June 2009.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme for Object
Delivery", RFC 5053, October 2007.
[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.
[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.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006. Session Description Protocol", RFC 4756, November 2006.
[dvbts] "ETSI TS 102 034 - Digital Video Broadcasting (DVB);
Transport of MPEG-2 Based DVB Services over IP Based
Networks", March 2005.
Author's Address Author's Address
Mark Watson Mark Watson
Digital Fountain Qualcomm, Inc.
39141 Civic Center Drive 3165 Kifer Road
Suite 300 Santa Clara, CA 95051
Fremont, CA 94538
U.S.A. U.S.A.
Email: mark@digitalfountain.com Email: watson@qualcomm.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 41 change blocks. 
78 lines changed or deleted 102 lines changed or added

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