One document matched: draft-ietf-fecframe-raptor-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY __reference.I-D.ietf-fecframe-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-fecframe-framework.xml">
<!ENTITY __reference.I-D.ietf-fecframe-sdp-elements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-fecframe-sdp-elements.xml">
<!ENTITY __reference.I-D.ietf-mmusic-rfc4756bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-rfc4756bis.xml">
<!ENTITY __reference.I-D.ietf-rmt-bb-fec-raptorq SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmt-bb-fec-raptorq.xml">
<!ENTITY __reference.RFC.2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY __reference.RFC.4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY __reference.RFC.5052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5052.xml">
<!ENTITY __reference.RFC.5053 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5053.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-ietf-fecframe-raptor-02" ipr="trust200902">
<front>
<title abbrev="Raptor FEC Scheme">Raptor FEC Schemes for FECFRAME</title>
<author fullname="Mark Watson" initials="M." surname="Watson">
<organization>Qualcomm, Inc.</organization>
<address>
<postal>
<street>3165 Kifer Road</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>U.S.A.</country>
</postal>
<email>watson@qualcomm.com</email>
</address>
</author>
<date day="5" month="March" year="2010" />
<area>Transport</area>
<workgroup>FEC Framework</workgroup>
<abstract>
<t>This document describes Fully-Specified Forward Error Correction
(FEC) Schemes for the Raptor and RaptorQ codes and their application to
reliable delivery of media streams in the context of FEC Framework. The
Raptor and RaptorQ codes are systematic codes, where a number of repair
symbols 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
receiver(s) within a source flow. The Raptor and RaptorQ codes offer
close to optimal protection against arbitrary packet losses at a low
computational complexity. Six FEC Schemes are defined, two for
protection of arbitrary packet flows, two that are optimised for small
source blocks and another two for protection of a single flow that
already contains a sequence number. Repair data may be sent over
arbitrary datagram transport (e.g. UDP) or using RTP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The FEC Framework <xref target="I-D.ietf-fecframe-framework"> </xref>
describes a framework for the application of Forward Error Correction to
arbitrary packet flows. Modelled after the FEC Building Block developed
by the IETF Reliable Multicast Transport working group <xref
target="RFC5052"></xref>, the FEC Framework defines the concept of FEC
Schemes which provide specific Forward Error Correction schemes. This
document describes six FEC Schemes which make use of the Raptor and
RaptorQ FEC codes as defined in <xref target="RFC5053"></xref> and <xref
target="I-D.ietf-rmt-bb-fec-raptorq"></xref>.</t>
<t>The FEC protection mechanism is independent of the type of the source
data, which can be an arbitrary sequence of packets, including for
example audio or video data. In general, the operation of the protection
mechanism is as follows:</t>
<t><list style="symbols">
<t>The sender determines a set of source packets (a source block) to
be protected together based on the FEC Framework Configuration
Information.</t>
<t>The sender arranges the source packets into a set of source
symbols, each of which is the same size.</t>
<t>The sender applies the Raptor protection operation on the source
symbols to generate the required number of repair symbols.</t>
<t>The sender packetizes the repair symbols and sends the repair
packet(s) along with the source packets to the receiver(s).</t>
</list></t>
<t>Per the FEC Framework requirements, the sender MUST transmit the
source and repair packets in different source and repair flows, or in
the case RTP transport is used for Repair packets, in different RTP
streams. At the receiver side, if all of the source packets are
successfully received, there is no need for FEC recovery and the repair
packets are discarded. However, if there are missing source packets, the
repair packets can be used to recover the missing information.</t>
<t>The operation of the FEC mechanism requires that the receiver can
identify the relationships between received source packets and repair
packets and in particular which source packets are missing. In many
cases, data already exists in the source packets which can be used to
refer to source packets and to identify which packets are missing. In
this case we assume it is possible to derive a "sequence number"
directly or indirectly from the source packets and this sequence number
can be used within the FEC Scheme. This case is referred to as a "single
sequenced flow". In this case the FEC Source Payload ID defined in <xref
target="I-D.ietf-fecframe-framework"></xref> is empty and the source
packets are not modified by the application of FEC, with obvious
backwards compatibility advantages.</t>
<t>Otherwise, it is necessary to add data to the source packets for FEC
purposes in the form of a non-empty FEC Source Payload ID. This case if
referred to as the "arbitrary packet flow" case. Accordingly, this
document defines two FEC Schemes, one for the case of a single sequenced
flow and another for the case of arbitrary packet flows.</t>
</section>
<section title="Document Outline">
<t>This document is organised as follows: <list>
<t><xref target="GeneralProcedures"> </xref> defines general
procedures applicable to the use of the Raptor and RaptorQ codes in
the context of the FEC Framework.</t>
<t><xref target="ArbitraryFlowScheme"></xref>defines an FEC Scheme
for the case of arbitrary source flows and follows the format
defined for FEC Schemes in <xref
target="I-D.ietf-fecframe-framework"></xref>. When used with Raptor
codes, this scheme is equivalent to that defined in <xref
target="MBMSTS"></xref>.</t>
<t><xref target="OptimisedArbitraryFlowScheme"></xref> defines an
FEC Scheme similar to that defined in <xref
target="ArbitraryFlowScheme"> </xref>but with optimisations for the
case where only limited source block sizes are required. When used
with Raptor codes, this scheme is equivalent to that defined in
<xref target="dvbts"></xref> for arbitrary packet flows.</t>
<t><xref target="SingleFlowScheme"></xref> defines an FEC Scheme for
the case of a single flow which is already provided with a source
packet sequence number. When used with Raptor codes, this scheme is
equivalent to that defined in <xref target="dvbts"></xref> for the
case of a single sequenced flow.</t>
</list></t>
</section>
<section title="Requirements Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Definitions and Abbreviations">
<t>The definitions, notations and abbreviations commonly used in this
document are summarized in this section.</t>
<section title="Definitions">
<t>This document uses the following definitions. For further
definitions that apply to FEC Framework in general, see <xref
target="I-D.ietf-fecframe-framework"></xref>.</t>
<t>Source Flow: The packet flow(s) or stream(s) carrying the source
data and to which FEC protection is to be applied.</t>
<t>Repair Flow: The packet flow(s) or stream(s) carrying the repair
data.</t>
<t>Symbol: A unit of data. Its size, in bytes, is referred to as the
symbol size.</t>
<t>Source Symbol: The smallest unit of data used during the encoding
process.</t>
<t>Repair Symbol: Repair symbols are generated from the source
symbols.</t>
<t>Source Packet: Data packets that contain only source symbols.</t>
<t>Repair Packet: Data packets that contain only repair symbols.</t>
<t>Source Block: A block of source symbols that are considered
together in the encoding process.</t>
<t>FEC Framework Configuration Information: Information that controls
the operation of the FEC Framework. Each FEC Framework instance has
its own configuration information.</t>
<t>FEC Payload ID: Information that identifies the contents of a
packet with respect to the FEC scheme.</t>
<t>Source FEC Payload ID: An FEC Payload ID specifically used with
source packets.</t>
<t>Repair FEC Payload ID: An FEC Payload ID specifically used with
repair packets.</t>
</section>
<section title="Abbreviations">
<t><list style="symbols">
<t>FSSI: FEC-Scheme-Specific Information.</t>
<t>SS-FSSI: Sender-Side FEC-Scheme-Specific Information.</t>
<t>RS-FSSI: Receiver-Side FEC-Scheme-Specific Information.</t>
</list></t>
</section>
</section>
<section anchor="GeneralProcedures"
title="General procedures for Raptor FEC Schemes">
<t>This section specifies general procedures which apply to all Raptor
and RaptorQ FEC Schemes, specifically the construction of source symbols
from a set of source transport payloads. As described in <xref
target="I-D.ietf-fecframe-framework"> </xref> for each Application Data
Unit in a source block, the FEC Scheme is provided with:</t>
<t><list style="symbols">
<t>A description of the source data flow with which the Application
Data Unit is associated and an integer identifier associated with
that flow.</t>
<t>The Application Data Unit itself.</t>
<t>The length of the Application Data Unit.</t>
</list>For each Application Data Unit, we define the Application Data
Unit Information (ADUI) as follows:</t>
<t>Let</t>
<t><list>
<t>n be the number of Application Data Units in the source
block.</t>
<t>T be the source symbol size in bytes. Note: this information is
provided by the FEC Scheme as defined below.</t>
<t>i the index to the (i+1)-th Application Data Unit to be added to
the source block, 0 <= i < n.</t>
<t>R[i] denote the number of octets in the (i+1)-th Application Data
Unit.</t>
<t>l[i] be a length indication associated with the i-th Application
Data Unit – the nature of the length indication is defined by
the FEC Scheme.</t>
<t>L[i] denote two octets representing the value of l[i] in network
byte order (high order octet first) of the i-th Application Data
Unit.</t>
<t>f[i] denote the integer identifier associated with the source
data flow from which the i-th Application Data Unit was taken.</t>
<t>F[i] denote a single octet representing the value of f[i].</t>
<t>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.</t>
<t>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
symbol.</t>
<t>ADUI[i] be the concatenation of F[i] ,L[i], R[i] and P[i].</t>
</list></t>
<t>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 by
sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer Encoding
Symbol IDs consecutively starting from zero within the source block.
Each Application Data Unit is associated with the Encoding Symbol ID of
the first symbol containing SPI for that 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] = sum{s[i], i=0,...,(j-1)}, for 0 <
j < n.</t>
<t>Source blocks are identified by integer Source Block Numbers. This
specification does not specify how Source Block Numbers are allocated to
source blocks. The Source FEC Packet Identification Information consists
of the identity of the source block and the Encoding Symbol ID
associated with the packet.</t>
<t></t>
</section>
<section anchor="ArbitraryFlowScheme"
title="Raptor FEC Schemes for arbitrary packet flows">
<section title="Introduction">
<t>This section specifies an FEC Scheme for the application of the
Raptor and RaptorQ codes to arbitary packet flows. This scheme is
recommended in scenarios where maximal generality is required.</t>
<t>When used with Raptor codes, this scheme is equivalent to that
specified in <xref target="MBMSTS"></xref>.</t>
</section>
<section title="Formats and Codes">
<section title="FEC Framework Configuration Information">
<section title="FEC Scheme ID">
<t>The value of the FEC Scheme ID for the fully-specified FEC
scheme defined in this section is XXX when <xref
target="RFC5053"></xref> is used and YYY when <xref
target="I-D.ietf-rmt-bb-fec-raptorq"></xref> is used, as assigned
by IANA.</t>
</section>
<section anchor="ArbitraryFSSISection"
title="Scheme-Specific Elements">
<t>The scheme-specific elements of the FEC Framework Configuration
information for this scheme are as follows:</t>
<t><list style="hanging">
<t hangText="Maximum Source Block Length">Name: <spanx
style="verb">Kmax</spanx>, Value range: A decimal non-negative
integer less than 8192 (for Raptor) or 56405 (for RaptorQ), in
units of symbols</t>
<t hangText="Encoding Symbol Size">Name: <spanx style="verb">T</spanx>,
Value range: A decimal non-negative integer less than 65536,
in units of bytes</t>
<t hangText="Payload ID Format">Name: <spanx style="verb">P</spanx>,
Value range: "A" or "B"</t>
</list></t>
<t>An encoding format for The Maximum Source Block Length and
Encoding Symbol Size is defined below.</t>
<t><figure anchor="ArbitraryFSSI"
title="FEC Scheme Specific Information">
<preamble></preamble>
<artwork align="center"><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Symbol Size (T) |Max. Source Block Length (Kmax)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>The P bit shall be set to zero to indicate Format A or
to 1 to indicate Format B. The last octet of the above encoding
may be omitted, in which case Format A shall be assumed.</t>
<t>The Payload ID Format identifier defines which of the Source
FEC Payload ID and Repair FEC Payload ID formats defined below
shall be used. Payload ID Format B SHALL NOT be used when<xref
target="RFC5053"></xref> is used.</t>
</section>
</section>
<section anchor="SourceFECPayloadID" title="Source FEC Payload ID">
<t>This scheme makes use of an Explicit Source FEC Payload ID, which
is appended to the end of the source packets. Two formats are
defined for the Source FEC Payload ID, format A and format B. The
format that is used is signalled as part of the FEC Framework
Configuration Information</t>
<t><figure anchor="SourceFECPayloadIDFigureA"
title="Source FEC Payload ID - Format A">
<preamble></preamble>
<artwork align="center"><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>Source Block Number (SBN), (16 bits): An integer identifier for
the source block that the source data within the packet relates
to.</t>
<t>Encoding Symbol ID (ESI), (16 bits): The starting symbol index of
the source packet in the source block.</t>
<t><figure anchor="SourceFECPayloadIDFigureB"
title="Source FEC Payload ID - Format B">
<preamble></preamble>
<artwork align="center"><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBN | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>Source Block Number (SBN), (8 bits): An integer identifier for
the source block that the source data within the packet relates
to.</t>
<t>Encoding Symbol ID (ESI), (24 bits): The starting symbol index of
the source packet in the source block</t>
</section>
<section anchor="RepairFECPayloadID" title="Repair FEC Payload ID">
<t>Two formats for the Repair FEC Payload ID, Format A and Format B
are defined below:</t>
<t><figure title="Repair FEC Payload ID - Format A">
<preamble></preamble>
<artwork align="center"><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (SBL) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t><figure title="Repair FEC Payload ID - Format B">
<preamble></preamble>
<artwork align="center"><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBN | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (SBL) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t><list style="hanging">
<t hangText="Source Block Number (SBN), (16 bits)">An integer
identifier for the source block that the repair symbols within
the packet relate to.</t>
<t hangText="Encoding Symbol ID (ESI), (16 bits)">Integer
identifier for the encoding symbols within the packet.</t>
<t hangText="Source Block Length (SBL), (16 bits)">The number of
source symbols in the source block.</t>
</list></t>
<t>The interpretation of the Source Block Number, Encoding Symbol
Identifier and Source Block Length is defined by the FEC Code
Specification.</t>
</section>
</section>
<section title="Procedures">
<section anchor="SourceSymbolSection"
title="Source symbol construction">
<t>This FEC Scheme uses the procedures defined in <xref
target="GeneralProcedures"></xref> to construct a set of source
symbols to which the FEC code can be applied. The sender MUST
allocate Source Block Numbers to source blocks sequentially,
wrapping around to zero after Source Block Number 65535 (Format A)
or 255 (Format B).</t>
<t>During the construction of the source block:</t>
<t><list style="symbols">
<t>the length indication, l[i], included in the Source Packet
Information for each packet shall be the transport payload
length.</t>
<t>the value of s[i] in the construction of the Source Packet
Information for each packet shall be the smallest integer such
that s[i]*T >= (l[i]+3).</t>
</list></t>
</section>
<section title="Repair packet construction">
<t>The number of repair symbols contained within a repair packet is
computed from the packet length. The ESI value placed into a repair
packet is given by the following formula:</t>
<t>ESI_repair = I_repair + SBL,</t>
<t>where I_repair is the index of the repair symbol in the sequence
of repair symbols generated according to <xref
target="FECSpecificationSection"></xref>, where the first repair
symbol has index 0, the second index 1 etc. and SBL is the Source
Block Length. The Source Block Length field of the Repair FEC
Payload ID field SHALL be set to the number of symbols included in
the Source Packet Information of packets associated with the source
block.</t>
</section>
</section>
<section anchor="FECSpecificationSection" title="FEC Code Specification">
<t>The Raptor FEC encoder defined in <xref target="RFC5053"></xref> or
<xref target="I-D.ietf-rmt-bb-fec-raptorq"></xref> SHALL be used. The
source symbols passed to the Raptor FEC encoder SHALL consist of the
source symbols constructed according to <xref
target="SourceSymbolSection"></xref>. Thus the value of the parameter
K used by the FEC encoder (equal to the Source Block Length) may vary
amongst the blocks of the stream but SHALL NOT exceed the Maximum
Source Block Length signalled in the FEC Scheme-specific information.
The symbol size, T, to be used for source block construction and the
repair symbol construction is equal to the Encoding Symbol Size
signaled in the FEC Scheme Specific Information.</t>
</section>
</section>
<section anchor="OptimisedArbitraryFlowScheme"
title="Optimised Raptor FEC Scheme for arbitrary packet flows">
<section title="Introduction">
<t>This section specifies a slightly modified version of the FEC
Scheme specified in <xref target="ArbitraryFlowScheme"></xref> which
is applicable to scenarios in which only relatively small block sizes
will be used. These modifications admit substantial optimisations to
both sender and receiver implementations.</t>
<t>In outline, the modifications are:</t>
<t><list style="empty">
<t>All source blocks within a stream are encoded using the same
source block size. Code shortening is used to encode blocks of
different sizes. This is achieved by padding every block to the
required size using zero symbols before encoding. The zero symbols
are then discarded after decoding. The source block size to be
used for a stream is signalled in the Maximum Source Block Size
field of the scheme-specific information. This allows for
efficient parallel encoding of multiple streams.</t>
<t>A restricted set of possible source block sizes is specified.
This allows explicit operation sequences for encoding the
restricted set of block sizes to be pre-calculated and embedded in
software or handware.</t>
</list> This scheme is equivalent to that specified in <xref
target="dvbts"></xref> for arbitrary packet flows.</t>
</section>
<section title="Formats and Codes">
<section title="FEC Framework Configuration Information">
<section title="FEC Scheme ID">
<t>The value of the FEC Scheme ID for the fully-specified FEC
scheme defined in this section is XXX when <xref
target="RFC5053"></xref> is used and YYY when <xref
target="I-D.ietf-rmt-bb-fec-raptorq"></xref> is used, as assigned
by IANA.</t>
</section>
<section title="FEC Scheme specific information">
<t>See <xref target="ArbitraryFSSISection">.</xref></t>
</section>
</section>
<section title="Source FEC Payload ID">
<t>See <xref target="SourceFECPayloadID">.</xref></t>
</section>
<section title="Repair FEC Payload ID">
<t>See<xref target="RepairFECPayloadID"> </xref></t>
</section>
</section>
<section title="Procedures">
<section title="Source symbol construction">
<t>See <xref target="SourceSymbolSection"></xref></t>
</section>
<section anchor="OptimisedRepairPacketSection"
title="Repair packet construction">
<t>The number of repair symbols contained within a repair packet is
computed from the packet length. The ESI value placed into a repair
packet is given by the following formula:</t>
<t>ESI_repair = I_repair + MSBL</t>
<t>Where I_repair is the index of the repair symbol in the sequence
of repair symbols generated according to <xref
target="FECSpecificationSection"></xref>, where the first repair
symbol has index 0, the second index 1 etc. and MSBL is the Maximum
Source Block Length signalled in the FEC Scheme Specific
Information. The Source Block Length field of the Repair FEC Payload
ID field SHALL be set to the number of symbols included in the
Source Packet Information of packets associated with the source
block.</t>
</section>
</section>
<section anchor="OptimisedFECSpecificationSection"
title="FEC Code Specification">
<t>The Raptor FEC encoder defined in <xref target="RFC5053"></xref> or
<xref target="I-D.ietf-rmt-bb-fec-raptorq"></xref> SHALL be used. The
source symbols passed to the Raptor FEC encoder SHALL consist of the
source symbols constructed according to <xref
target="SourceSymbolSection"></xref> extended with zero or more
padding symbols such that the total number of symbols in the source
block is equal to the Maximum Source Block Length signaled in the FEC
Scheme Specific Information. Thus the value of the parameter K used by
the FEC encoded is equal to the Maximum Source Block Length for all
blocks of the stream. Padding symbols shall consist entirely of bytes
set to the value zero. The symbol size, T, to be used for source block
construction and the repair symbol construction is equal to the
Encoding Symbol Size signaled in the FEC Scheme Specific
Information.</t>
<t>When <xref target="RFC5053"></xref> is used, the parameter T SHALL
be set such that the number of source symbols in any source block is
at most 8192. The Maximum Source Block Length parameter – and
hence the number of symbols used in the FEC Encoding and Decoding
operations - SHALL be set to one of the following values:</t>
<t><list>
<t>101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842,
1031, 1139, 1281</t>
</list>When <xref target="I-D.ietf-rmt-bb-fec-raptorq"></xref> is
used, the parameter T SHALL be set such that the number of source
symbols in any source block is less than 56404. The Maximum Source
Block Length parameter SHALL be set to one of the supported vaoues for
K' defined in Section 5.6 of <xref
target="I-D.ietf-rmt-bb-fec-raptorq"></xref>.</t>
</section>
</section>
<section anchor="SingleFlowScheme"
title="Raptor FEC Scheme for a single sequenced flow">
<section title="Formats and codes">
<section title="FEC Framework Configuration Information">
<section title="FEC Scheme ID">
<t>The value of the FEC Scheme ID for the fully-specified FEC
scheme defined in this section is XXX when <xref
target="RFC5053"></xref> is used and YYY when <xref
target="I-D.ietf-rmt-bb-fec-raptorq"></xref> is used, as assigned
by IANA.</t>
</section>
<section title="Scheme-specific elements">
<t>See <xref target="ArbitraryFSSISection"></xref></t>
</section>
</section>
<section title="Source FEC Payload ID">
<t>The Source FEC Payload ID field is not used by this FEC Scheme.
Source packets are not modified by this FEC Scheme.</t>
</section>
<section title="Repair FEC Payload ID">
<t>Two formats for the Repair FEC Payload ID are defined, Format A
and Format B.</t>
<t><figure anchor="RepairFECPayloadID2A"
title="Repair FEC Payload ID - Format A">
<preamble></preamble>
<artwork align="center"><![CDATA[ 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure><list style="hanging">
<t
hangText="Initial Sequence Number (Flow i ISN) – 16 bits">This
field specifies the lowest 16 bits of the sequence number of the
first packet to be included in this sub-block. If the sequence
numbers are shorter than 16 bits then the received Sequence
Number SHALL be logically padded with zero bits to become 16
bits in length respectively.</t>
<t hangText="Encoding Symbol ID (ESI) – 16 bits">This
field indicates which repair symbols are contained within this
repair packet. The ESI provided is the ESI of the first repair
symbol in the packet.</t>
<t hangText="Source Block Length (SBL) – 16 bits">This
field specifies the length of the source block in symbols.</t>
</list><figure anchor="RepairFECPayloadID2B"
title="Repair FEC Payload ID - Format B">
<preamble></preamble>
<artwork align="center"><![CDATA[ 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure><list style="hanging">
<t
hangText="Initial Sequence Number (Flow i ISN) – 16 bits">This
field specifies the lowest 16 bits of the sequence number of the
first packet to be included in this sub-block. If the sequence
numbers are shorter than 16 bits then the received Sequence
Number SHALL be logically padded with zero bits to become 16
bits in length respectively.</t>
<t hangText="Encoding Symbol ID (ESI) – 16 bits">This
field indicates which repair symbols are contained within this
repair packet. The ESI provided is the ESI of the first repair
symbol in the packet.</t>
<t hangText="Source Block Length (SBL) – 16 bits">This
field specifies the length of the source block in symbols.</t>
</list></t>
</section>
</section>
<section title="Procedures">
<section title="Source symbol construction">
<t>This FEC Scheme uses the procedures defined in <xref
target="GeneralProcedures"></xref> to construct a set of source
symbols to which the FEC code can be applied. The sender MUST
allocate Source Block Numbers to source blocks sequentially,
wrapping around to zero after Source Block Number 65535 in the case
Format A is used for FEC Payload IDs and 255 in the case Format B is
used for FEC Payload IDs.</t>
<t>During the construction of the source block:</t>
<t><list style="symbols">
<t>the length indication, l[i], included in the Source Packet
Information for each packet shall be dependent on the protocol
carried within the transport payload. Rules for RTP are
specified below.</t>
<t>the value of s[i] in the construction of the Source Packet
Information for each packet shall be the smallest integer such
that s[i]*T >= (l[i]+3)</t>
</list></t>
</section>
<section title="Derivation of Source FEC Packet Identification Information">
<t>The Source FEC Packet Identification Information for a source
packet is derived from the sequence number of the packet and
information received in any Repair FEC packet belonging to this
Source Block. Source blocks are identified by the sequence number of
the first source packet in the block. This information is signaled
in all Repair FEC packets associated with the source block in the
Initial Sequence Number field.</t>
<t>The length of the Source Packet Information (in bytes) for source
packets within a source block is equal to length of the payload
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 all repair packets. The Application Data Unit
Information Length (ADUIL) in symbols is equal to this length
divided by the Encoding Symbol Size (which is signaled in the FEC
Framework Configuration Information). The set of source packets
which are included in the source block is determined from the
Initial Sequence Number (ISN) and Source Block Length (SBL) as
follows:</t>
<t>Let,</t>
<t><list style="empty">
<t>I be the Initial Sequence Number of the source block</t>
<t>LP be the Source Packet Information Length in symbols</t>
<t>LB be the Source Block Length in symbols</t>
</list>Then, source packets with sequence numbers from I to I
+LB/LP-1 inclusive are included in the source block.</t>
<t>Note that if no FEC Repair packets are received then no FEC
decoding is possible and it is unnecessary for the receiver to
identify the Source FEC Packet Identification Information for the
source packets.</t>
<t>The Encoding Symbol ID for a packet is derived from the following
information:</t>
<t><list>
<t>The sequence number, Ns, of the packet</t>
<t>The Source Packet Information Length for the source block,
LP</t>
<t>The Initial Sequence Number of the source block, I</t>
</list>Then the Encoding Symbol ID for packet with sequence number
Ns is determined by the following formula:</t>
<t><list>
<t>ESI = ( Ns - I ) * LP</t>
</list>Note that all repair packet associated to a given Source
Block MUST contain the same Source Block Length and Initial Sequence
Number.</t>
</section>
<section title="Repair packet construction">
<t>See <xref target="OptimisedRepairPacketSection"></xref></t>
</section>
<section title="Procedures for RTP source flows">
<t>In the specific case of RTP source packet flows, then the RTP
Sequence Number field SHALL be used as the sequence number in the
procedures described above. The length indication included in the
Application Data Unit Information SHALL be the RTP payload length
plus the length of the CSRCs, if any, the RTP Header Extension, if
present, and the RTP padding bytes, if any. Note that this length is
always equal to the UDP payload length of the packet minus 12.</t>
</section>
</section>
<section title="FEC Code Specification">
<t>See <xref target="OptimisedFECSpecificationSection"></xref></t>
</section>
</section>
<section anchor="SecuritySection" title="Security Considerations">
<t>For the general security considerations related to the use of FEC,
refer to <xref target="I-D.ietf-fecframe-framework"></xref>. No security
considerations specific to this document have been identified.</t>
</section>
<section title="Session Description Protocol (SDP) Signaling">
<t>This section provides an SDP <xref target="RFC4566"></xref> example.
The following example uses the SDP elements for FEC Framework, which
were introduced in <xref
target="I-D.ietf-fecframe-sdp-elements"></xref>, and the FEC grouping
semantics <xref target="I-D.ietf-mmusic-rfc4756bis"></xref>.</t>
<t>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 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.</t>
<t><figure>
<preamble></preamble>
<artwork><![CDATA[ v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor FEC Example
t=0 0
a=group:FEC 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 udp/fec
c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=0; fssi=Kmax:8192,T:128,P:A
a=repair-window:200
a=mid:R1
]]></artwork>
</figure></t>
</section>
<section title="Congestion Control Considerations">
<t>For the general congestion control considerations related to the use
of FEC, refer to <xref target="I-D.ietf-fecframe-framework"></xref>.</t>
</section>
<section anchor="IANASection" title="IANA Considerations">
<section title="Registration of FEC Scheme IDs">
<t>The value of FEC Scheme IDs is subject to IANA registration. For
general guidelines on IANA considerations as they apply to this
document, refer to <xref
target="I-D.ietf-fecframe-framework"></xref>.</t>
<t>This document registers three values in the FEC Framework
(FECFRAME) FEC Encoding IDs registry as follows:</t>
<t><list style="symbols">
<t>XXX for the Raptor FEC Scheme for Arbitrary Packet Flows (<xref
target="ArbitraryFlowScheme"></xref> using Raptor <xref
target="RFC5053"></xref>.</t>
<t>XXX for the Raptor FEC Scheme for Arbitrary Packet Flows (<xref
target="ArbitraryFlowScheme"></xref> using RaptorQ <xref
target="I-D.ietf-rmt-bb-fec-raptorq"></xref>.</t>
<t>XXX for the Optimised Raptor FEC Scheme for Arbitrary Packet
Flows (<xref target="OptimisedArbitraryFlowScheme"></xref>) using
Raptor <xref target="RFC5053"></xref>.</t>
<t>XXX for the Optimised Raptor FEC Scheme for Arbitrary Packet
Flows (<xref target="OptimisedArbitraryFlowScheme"></xref>) using
RaptorQ <xref target="I-D.ietf-rmt-bb-fec-raptorq"></xref>.</t>
<t>XXX for the Raptor FEC Scheme for a single sequence flow (<xref
target="SingleFlowScheme"></xref>) using Raptor <xref
target="RFC5053"></xref>.</t>
<t>XXX for the Raptor FEC Scheme for a single sequence flow (<xref
target="SingleFlowScheme"></xref>) using RaptorQ <xref
target="I-D.ietf-rmt-bb-fec-raptorq"></xref>.</t>
</list></t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&__reference.I-D.ietf-fecframe-framework;
&__reference.I-D.ietf-fecframe-sdp-elements;
&__reference.RFC.5052;
&__reference.RFC.5053;
&__reference.RFC.2119;
&__reference.RFC.4566;
&__reference.I-D.ietf-mmusic-rfc4756bis;
&__reference.I-D.ietf-rmt-bb-fec-raptorq;
<reference anchor="dvbts">
<front>
<title>ETSI TS 102 034 - Digital Video Broadcasting (DVB); Transport
of MPEG-2 Based DVB Services over IP Based Networks</title>
<author>
<organization></organization>
</author>
<date day="1" month="March" year="2005" />
</front>
</reference>
<reference anchor="MBMSTS">
<front>
<title>Multimedia Broadcast/Multicast Service (MBMS); Protocols and
codecs</title>
<author>
<organization>3GPP</organization>
</author>
<date day="01" month="April" year="2005" />
</front>
<seriesInfo name="3GPP TS" value="26.346" />
<format target="http://www.3gpp.org/ftp/Specs/html-info/26346.htm"
type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:16:15 |