One document matched: draft-ietf-rmt-bb-fec-basic-schemes-revised-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5052.xml">
<!ENTITY rfc3452 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3452.xml">
<!ENTITY rfc3453 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3453.xml">
<!ENTITY rfc3269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3269.xml">
<!ENTITY rfc3048 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3048.xml">
<!ENTITY rfc3695 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3695.xml">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<rfc category="std" docName="draft-ietf-rmt-bb-fec-basic-schemes-revised-06"
ipr="full3978" obsoletes="rfc3695">
<front>
<title abbrev="Basic FEC Schemes">Basic Forward Error Correction (FEC)
Schemes</title>
<author fullname="Mark Watson" initials="M." surname="Watson">
<organization>Digital Fountain</organization>
<address>
<postal>
<street>39141 Civic Center Drive</street>
<street>Suite 300</street>
<city>Fremont</city>
<region>CA</region>
<code>94538</code>
<country>U.S.A.</country>
</postal>
<email>mark@digitalfountain.com</email>
</address>
</author>
<date day="31" month="October" year="2008" />
<area>Transport</area>
<workgroup>Reliable Multicast Transport</workgroup>
<abstract>
<t>This document provides Forward Error Correction (FEC) Scheme
specifications according to the RMT FEC Building Block for the Compact
No-Code FEC Scheme, the Small Block, Large Block and Expandable FEC
Scheme, the Small Block Systematic FEC Scheme and the Compact FEC
Scheme. This document obsoletes RFC3695 and assumes responsibility for
the FEC Schemes defined in RFC3452.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The document specifies the following FEC Schemes according to the
specification requirements of the FEC Building Block <xref
target="RFC5052"></xref>: <list style="symbols">
<t>Compact No-Code FEC Scheme</t>
<t>Small Block, Large Block and Expandable FEC Scheme</t>
<t>Small Block Systematic FEC Scheme</t>
<t>Compact FEC Scheme</t>
</list></t>
<t>This document inherits the context, language, declarations and
restrictions of the FEC building block <xref target="RFC5052"></xref>.
This document also uses the terminology of the companion document <xref
target="RFC3453"></xref> which describes the use of FEC codes within the
context of reliable IP multicast transport and provides an introduction
to some commonly used FEC codes.</t>
<t>Building blocks are defined in <xref target="RFC3048"></xref>. This
document follows the general guidelines provided in <xref
target="RFC3269"></xref>.</t>
<t><xref target="RFC3452"></xref> and <xref target="RFC3695"></xref>
contained a previous versions of the FEC Schemes defined in this
specification. These RFCs were published in the "Experimental" category.
It was the stated intent of the RMT working group to re-submit these
specifications as an IETF Proposed Standard in due course. This document
obsoletes <xref target="RFC3695"></xref>. <xref target="RFC3452"></xref>
has already been obsoleted by <xref target="RFC5052"></xref> and this
document assumes responsibility for aspects of <xref
target="RFC3452"></xref> that were not included in <xref
target="RFC5052"></xref>.</t>
<t>This Proposed Standard specification is thus based on and backwards
compatible with the FEC Schemes defined in <xref
target="RFC3452"></xref> and <xref target="RFC3695"></xref> updated
according to accumulated experience and growing protocol maturity since
their original publication. Said experience applies both to this
specification itself and to congestion control strategies related to the
use of this specification.</t>
<t>The differences between the FEC Scheme specifications in <xref
target="RFC3452"></xref> and <xref target="RFC3695"></xref> and this
document are listed in <xref target="changes"></xref>.</t>
<t>Integer fields specified in this document are all encoded in network
byte order.</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 anchor="CompactNoCode" title="Compact No-Code FEC Scheme">
<section title="Introduction">
<t>The Compact No-code FEC Scheme is a Fully-Specified FEC Scheme. The
scheme requires no FEC coding and is specified primarily to allow
simple interoperability testing between different implementations of
protocol instantiations that use the FEC building block.</t>
</section>
<section title="Formats and Codes">
<section anchor="compactNoCodeFPISection" title="FEC Payload ID(s)">
<t>The FEC Payload ID for the Compact No-Code FEC Scheme is composed
of a Source Block Number and an Encoding Symbol ID as shown in <xref
target="compactNoCodeFPI"></xref>.</t>
<figure anchor="compactNoCodeFPI"
title="FEC Payload ID format for Compact No-Code FEC Scheme">
<artwork><![CDATA[
0 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 | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Source Block Number (SBN) is a 16-bit unsigned interger that
is used to identify from which source block of the object the
encoding symbol in the payload of the packet is generated. There are
two possible modes: In the unique SBN mode each source block within
the object has a unique Source Block Number associated with it, and
in the non-unique SBN mode the same Source Block Number may be used
for more than one source block within the object. Which mode is
being used for an object is outside the scope of this document and
MUST be communicated, either explicitly or implicitly, out-of-band
to receivers.</t>
<t>If the unique SBN mode is used then successive Source Block
Numbers are associated with consecutive source blocks of the object
starting with Source Block Number 0 for the first source block of
the object. In this case, there are at most 2^^16 source blocks in
the object.</t>
<t>If the non-unique SBN mode is used then the mapping from source
blocks to Source Block Numbers MUST be communicated out-of-band to
receivers, and how this is done is outside the scope of this
document. This mapping could be implicit, for example determined by
the transmission order of the source blocks. In non-unique SBN mode,
packets for two different source blocks mapped to the same Source
Block Number SHOULD NOT be sent within an interval of time that is
shorter than the transport time of a source block. The transport
time of a source block includes the amount of time needed to process
the source block at the sender transport layer, the network transit
time for packets, and the amount of time needed to process the
source block at the receiver transport. This allows the receiver to
clearly decide which packets belong to which source block.</t>
<t>The Encoding Symbol ID is a 16-bit unsigned integer that
identifies which specific encoding symbol generated from the source
block is carried in the packet payload. The exact details of the
correspondence between Encoding Symbol IDs and the encoding symbols
in the packet payload are specified in <xref
target="compactNoCodeSpec"></xref>.</t>
</section>
<section title="FEC Object Transmission Information">
<section title="Mandatory">
<t>The mandatory FEC Object Transmission Information element for
the Compact No-Code FEC Scheme is: <list style="symbols">
<t>FEC Encoding ID: zero (0)</t>
</list></t>
</section>
<section anchor="compactNoCodeCommonOTI" title="Common">
<t>The common FEC Object Transmission Information elements and
their value ranges for the Compact No-code FEC Scheme are: <list
style="hanging">
<t hangText="Transfer-Length:">a non-negative integer less
than 2^^48.</t>
<t hangText="Encoding-Symbol-Length:">a non-negative integer
less than 2^^16.</t>
<t hangText="Maximum-Source-Block-Length:">a non-negative
integer less than 2^^32.</t>
</list></t>
<t>Note that the semantics for the above elements are defined in
<xref target="RFC5052"></xref> and are not duplicated here.</t>
<t>The encoded Common FEC Object Transmission information is
defined in <xref target="compactNoCodeCommonFOTI"></xref>.</t>
<figure anchor="compactNoCodeCommonFOTI"
title="Encoded Common FEC OTI for Compact No-Code FEC Scheme">
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Transfer Length, Encoding Symbol Length and Maximum Source
Block length are encoded as unsigned integers, of length 48 bits,
16 bits and 32 bits respectivly.</t>
<t>All Encoding Symbols of a transport object MUST have length
equal to the length specified in the Encoding Symbol Length
element, with the optional exception of the last source symbol of
the last source block (so that redundant padding is not mandatory
in this last symbol). This last source symbol MUST be logically
padded out with zeroes when another Encoding Symbol is computed
based on this source symbol to ensure the same interpretation of
this Encoding Symbol value by the sender and receiver. However,
this padding does not actually need to be sent with the data of
the last source symbol.</t>
<t>The "Reserved" field in the Encoded FEC Object Transmission
Information MUST be set to zero by senders and its value MUST be
ignored by receivers.</t>
<t><list>
<t>Note: this FEC Scheme was first defined in <xref
target="RFC3695"></xref> which did not require that the
Encoding Symbol Length should be the same for every source
block. This document introduces a general requirement that the
Encoding Symbol Length be the same across source blocks. Since
no protocols were defined which support variation in the
Encoding Symbol Length between source blocks this can be done
without introducing backwards compatibility issues.</t>
</list></t>
</section>
<section title="Scheme-Specific">
<t>No Scheme-Specific FEC Object Transmission Information elements
are defined by this FEC Scheme.</t>
</section>
</section>
</section>
<section anchor="compactNoCodeProcedures" title="Procedures">
<t>The algorithm defined in Section 9.1. of <xref
target="RFC5052"></xref> MUST be used to partition the file into
source blocks.</t>
</section>
<section anchor="compactNoCodeSpec" title="FEC code specification">
<t>The Compact No-Code FEC scheme does not require FEC encoding or
decoding. Instead, each encoding symbol consists of consecutive bytes
of a source block of the object.</t>
<t>The following two subsections describe the details of how the
Compact No-Code FEC scheme operates for each source block of an
object.</t>
<section title="Source Block Logistics">
<t>Let X > 0 be the length of a source block in bytes. Let L >
0 be the length of the encoding symbol contained in the payload of
each packet. The value of X and L are part of the FEC Object
Transmission Information, and how this information is communicated
to a receiver is outside the scope of this document.</t>
<t>For a given source block X bytes in length with Source Block
Number I, let N = X/L rounded up to the nearest integer. The
encoding symbol carried in the payload of a packet consists of a
consecutive portion of the source block. The source block is
logically partitioned into N encoding symbols, each L bytes in
length, and the corresponding Encoding Symbol IDs range from 0
through N-1 starting at the beginning of the source block and
proceeding to the end. Thus, the encoding symbol with Encoding
Symbol ID Y consists of bytes L*Y through L*(Y+1)-1 of the source
block, where the bytes of the source block are numbered from 0
through X-1. If X/L is not integral then the last encoding symbol
with Encoding Symbol ID = N-1 consists of bytes L*(N-1) through the
last byte X-1 of the source block, and the remaining L*N - X bytes
of the encoding symbol can by padded out with zeroes.</t>
<t>As an example, suppose that the source block length X = 20,400
and encoding symbol length L = 1,000. The encoding symbol with
Encoding Symbol ID = 10 contains bytes 10,000 through 10,999 of the
source block, and the encoding symbol with Encoding Symbol ID = 20
contains bytes 20,000 through the last byte 20,399 of the source
block and the remaining 600 bytes of the encoding symbol can be
padded with zeroes.</t>
<t>There are no restrictions beyond the rules stated above on how a
sender generates encoding symbols to send from a source block.
However, it is recommended that an implementor refer to the
companion document <xref target="RFC3452"></xref> for general
advice.</t>
<t>In the next subsection a procedure is recommended for sending and
receiving source blocks.</t>
</section>
<section title="Sending and Receiving a Source Block">
<t>The following carousel procedure is RECOMMENDED for a sender to
generate packets containing FEC Payload IDs and corresponding
encoding symbols for a source block with Source Block Number I. Set
the length in bytes of an encoding symbol to a fixed value L which
is reasonable for a packet payload (e.g., ensure that the total
packet size does not exceed the MTU) and that is smaller than the
source block length X, e.g., L = 1,000 for X >= 1,000. Initialize
Y to a value randomly chosen in the interval [0..N-1]. Repeat the
following for each packet of the source block to be sent. <list
style="symbols">
<t>If Y <= N-1 then generate the encoding symbol Y.</t>
<t>Within the FEC Payload ID, set the Source Block Length to X,
set the Source Block Number = I, set the Encoding Symbol ID = Y,
place the FEC Payload ID and the encoding symbol into the packet
to send.</t>
<t>In preparation for the generation of the next packet: if Y
< N-1 then increment Y by one else if Y = N-1 then reset Y to
zero.</t>
</list></t>
<t>The following procedure is RECOMMENDED for a receiver to recover
the source block based on receiving packets for the source block
from a sender that is using the carousel procedure described above.
The receiver can determine from which source block a received packet
was generated by the Source Block Number carried in the FEC Payload
ID. Upon receipt of the first FEC Payload ID for a source block, the
receiver uses the Source Block Length and Encoding Symbol Length
received out-of-band as part of the FEC Object Transmission
Information to determine the length X in bytes of the source block
and length L in bytes of each encoding symbol. The reciever
allocates space for the X bytes that the source block requires. The
receiver also computes the length of the encoding symbol in the
payload of the packet by subtracting the packet header length from
the total length of the received packet. The receiver checks that
this symbol length is equal to L, except in the case that this is
the last symbol of the source block in which case the symbol length
in the packet may be less than L. After calculating N = X/L rounded
up to the nearest integer, the receiver allocates a boolean array
RECEIVED[0..N-1] with all N entries initialized to false to track
received encoding symbols. The receiver keeps receiving packets for
the source block as long as there is at least one entry in RECEIVED
still set to false or until the application decides to give up on
this source block and move on to other source blocks. For each
received packet for the source block (including the first packet)
the steps to be taken to help recover the source block are as
follows. Let Y be the value of the Encoding Symbol ID within the FEC
Payload ID of the packet. If Y <= N-1 then the receiver copies
the encoding symbol into the appropriate place within the space
reserved for the source block and sets RECEIVED[Y] = true. If all N
entries of RECEIVED are true then the receiver has recovered the
entire source block.</t>
</section>
</section>
</section>
<section anchor="scheme128"
title="Small Block, Large Block and Expandable FEC Scheme">
<section title="Introduction">
<t>This section defines an Under-Specified FEC Scheme for Small Block
FEC codes, Large Block FEC codes and Expandable FEC codes as described
in <xref target="RFC3453"></xref>.</t>
</section>
<section title="Formats and Codes">
<section title="FEC Payload ID(s)">
<t>The FEC Payload ID is composed of a Source Block Number and an
Encoding Symbol ID structured as shown in <xref
target="smallBlockFPI"></xref>.</t>
<figure anchor="smallBlockFPI"
title="FEC Payload ID format for Small Block, Large Block and Expandable FEC Codes">
<artwork><![CDATA[
0 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Source Block Number is a 32-bit unsigned integer that
identifies from which source block of the object the encoding
symbol(s) in the payload are generated. These blocks are numbered
consecutively from 0 to N-1, where N is the number of source blocks
in the object.</t>
<t>The Encoding Symbol ID is a 32-bit unsigned integer that
identifies which specific encoding symbol(s) generated from the
source block are carried in the packet payload. The exact details of
the correspondence between Encoding Symbol IDs and the encoding
symbol(s) in the packet payload are dependent on the particular FEC
Scheme instance used as identified by the FEC Encoding ID and by the
FEC Instance ID, and these details may be proprietary.</t>
</section>
<section title="FEC Object Transmission Information">
<section title="Mandatory">
<t>The mandatory FEC Object Transmission Information element for
the Small Block, Large Block and Expandable FEC Scheme are: <list
style="symbols">
<t>FEC Encoding ID: 128</t>
</list></t>
</section>
<section title="Common">
<t>The common FEC Object Transmission Information elements and
their value ranges for the Small Block, Large Block and Expandable
FEC Scheme are: <list style="hanging">
<t hangText="FEC Instance ID:">a non-negative integer less
than 2^^16.</t>
<t hangText="Transfer-Length:">a non-negative integer less
than 2^^48.</t>
<t hangText="Encoding-Symbol-Length:">a non-negative integer
less than 2^^16.</t>
<t hangText="Maximum-Source-Block-Length:">a non-negative
integer less than 2^^32.</t>
</list></t>
<t>Note that the semantics for the above elements are defined in
<xref target="RFC5052"></xref> and are not duplicated here.</t>
<t>The encoded Common FEC Object Transmission information is
defined in <xref target="smallLargeExpandableOTI"></xref>.</t>
<figure anchor="smallLargeExpandableOTI"
title="Encoded Common FEC OTI for Small Block, Large Block and Expandable FEC Scheme">
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Transfer Length (48 bits), FEC Instance ID (16 bits),
Encoding Symbol Length (16 bits) and Maximum Source Block Length
(32 bits) are encoded as unsigned integers.</t>
</section>
<section anchor="smallLargeExpandableSSOTI" title="Scheme-Specific">
<t>The Scheme-specific FEC Object Transmission Information field
for the Small block, Large Block and Expandable FEC Scheme
provides for the possibility of Instance-specific FEC Object
Transmission Information. The format of the Scheme-Specific FEC
Object Transmission information for this FEC Scheme is defined in
<xref target="smallLargeExpandableSSOTIfigure"></xref></t>
<figure anchor="smallLargeExpandableSSOTIfigure"
title="Encoded Scheme-specific FEC OTI for Small Block, Large Block and Expandable FEC Scheme">
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Instance-specific FEC OTI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance-specific FEC OTI contd. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Scheme-specific FEC Object Transmission Information field
contains the following sub-fields:</t>
<t><list style="hanging">
<t hangText="Length (1 octet)">an unsigned integer that
specifies the length of the Scheme-specific FEC OTI in
four-octet words (including this length field), except that
the value zero indicates that no Instance-specific FEC OTI
information is provided. When the Length is zero, three
padding bytes containing value zero SHALL follow the Length
field to maintain 4-octet alignment.</t>
<t hangText="Instance-specific FEC OTI Information ">the
contents of this field are FEC Scheme Instance-specific</t>
</list>Note that in the case of a Content Delivery protocol
which supports external signalling of the total FEC Object
Transmission Information length, then the Scheme-Specific FEC OTI
field defined here is optional. Otherwise, this field MUST be
included.</t>
</section>
</section>
</section>
<section title="Procedures">
<t>The algorithm defined in Section 9.1. of <xref
target="RFC5052"></xref> MUST be used to partition the file into
source blocks.</t>
</section>
<section title="FEC Code Specification">
<t>The FEC code specification and the correspondance of Encoding
Symbols IDs to encoding symbols are defined by specific instances of
this scheme and so are out of scope of this document.</t>
</section>
</section>
<section anchor="scheme129" title="Small Block Systematic FEC Scheme">
<section title="Introduction">
<t>This section defines an Under-Specified FEC Scheme for Small Block
Systematic FEC codes as described in <xref target="RFC3453"></xref>.
For Small Block Systematic FEC codes, each source block is of length
at most 65535 source symbols.</t>
<t>Although these codes can generally be accommodated by the FEC
Encoding ID described in <xref target="scheme128"></xref>, a specific
FEC Encoding ID is defined for Small Block Systematic FEC codes to
allow more flexibility and to retain header compactness. The small
source block length and small expansion factor that often characterize
systematic codes may require the data source to frequently change the
source block length. To allow the dynamic variation of the source
block length and to communicate it to the receivers with low overhead,
the block length is included in the FEC Payload ID.</t>
</section>
<section title="Formats and Codes">
<section title="FEC Payload ID(s)">
<t>The FEC Payload ID is composed of the Source Block Number, Source
Block Length and the Encoding Symbol ID structured as shown in <xref
target="smallSystematicFPI"></xref>. <figure
anchor="smallSystematicFPI"
title="FEC Payload ID format for Small Block Systematic FEC scheme">
<artwork><![CDATA[
0 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The Source Block Number is a 32-bit unsigned integer that
identifies from which source block of the object the encoding
symbol(s) in the payload are generated. These blocks are numbered
consecutively from 0 to N-1, where N is the number of source blocks
in the object.</t>
<t>The Source Block Length is a 16-bit unsigned integer that
specifies the length in units of source symbols of the source block
identified by the Source Block Number.</t>
<t>The Encoding Symbol ID is a 16-bit unsigned integer that
identifies which specific encoding symbol(s) generated from the
source block are carried in the packet payload. Each encoding symbol
is either an original source symbol or a redundant symbol generated
by the encoder. The exact details of the correspondence between
Encoding Symbol IDs and the encoding symbol(s) in the packet payload
are dependent on the particular FEC scheme instance used as
identified by the FEC Instance ID, and these details may be
proprietary.</t>
</section>
<section title="FEC Object Transmission Information">
<section title="Mandatory">
<t>The mandatory FEC Object Transmission Information element for
the Small Block Systematic FEC Scheme is: <list style="symbols">
<t>FEC Encoding ID: 129</t>
</list></t>
</section>
<section title="Common">
<t>The common FEC Object Transmission Information elements and
their value ranges for the Small Block Systematic FEC Scheme are:
<list style="hanging">
<t hangText="FEC Instance ID:">a non-negative integer less
than 2^^16.</t>
<t hangText="Transfer-Length:">a non-negative integer less
than 2^^48.</t>
<t hangText="Encoding-Symbol-Length:">a non-negative integer
less than 2^^16.</t>
<t hangText="Maximum-Source-Block-Length:">a non-negative
integer less than 2^^16.</t>
<t hangText="Max-Number-of-Encoding-Symbols:">a non-negative
integer less than 2^^16</t>
</list></t>
<t>Note that the semantics for the above elements are defined in
<xref target="RFC5052"></xref> and are not duplicated here.</t>
<t>The encoded Common FEC Object Transmission information is
defined in <xref target="smallSystematicCommonFOTI"></xref>.
<figure anchor="smallSystematicCommonFOTI"
title="FEC OTI format for Small Block Systematic FEC Scheme">
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The Transfer Length (48 bits), FEC Instance ID (16 bits),
Encoding Symbol Length (16 bits), Maximum Source Block Length (16
bits) and Maximum Number of Encoding Symbols (16 bits) are encoded
as unsigned integers.</t>
<t>All Encoding Symbols of a transport object MUST have length
equal to the length specified in the Encoding Symbol Length field,
with the optional exception of the last source symbol of the last
source block (so that redundant padding is not mandatory in this
last symbol). This last source symbol MUST be logically padded out
with zeroes when another Encoding Symbol is computed based on this
source symbol to ensure the same interpretation of this Encoding
Symbol value by the sender and receiver. However, this padding
need not be actually sent with the data of the last source symbol.
<list>
<t>Note: this FEC Scheme was first defined in <xref
target="RFC3452"></xref> which did not require that the
Encoding Symbol Length should be the same for every source
block. However, no protocols have been defined which support
variation in the Encoding Symbol Length between source blocks
and thus introduction of a general requirement that the
Encoding Symbol Length be the same across source blocks (as
defined here) should not cause backwards compatibility issues
and will aid interoperability.</t>
</list></t>
</section>
<section title="Scheme-Specific">
<t>The Scheme-Specific FEC Object Transmission Information format
defined in <xref target="smallLargeExpandableSSOTI"></xref> SHALL
be used.</t>
</section>
</section>
</section>
<section title="Procedures">
<t>The algorithm defined in Section 9.1. of <xref
target="RFC5052"></xref> MAY be used to partition the file into source
blocks. Otherwise the FEC Scheme instance MUST specify the algorithm
that is used.</t>
</section>
<section title="FEC Code Specification">
<t>The FEC code specification and the correspondance of Encoding
Symbols IDs to encoding symbols are defined by specific instances of
this scheme and so are out of scope of this document.</t>
</section>
</section>
<section anchor="Compact" title="Compact FEC Scheme">
<section title="Introduction">
<t>The Compact FEC Scheme is an Under-Specified FEC scheme. This FEC
scheme is similar in spirit to the Compact No-Code FEC scheme, except
that a non-trivial FEC encoding (that is Under-Specified) may be used
to generate encoding symbol(s) placed in the payload of each packet
and a corresponding FEC decoder may be used to produce the source
block from received packets.</t>
</section>
<section title="Formats and Codes">
<section title="FEC Payload ID(s)">
<t>The FEC Payload ID format defined in <xref
target="compactNoCodeFPISection"></xref> SHALL be used.</t>
</section>
<section title="FEC Object Transmission Information">
<section title="Mandatory">
<t>The mandatory FEC Object Transmission Information element for
the Compact No-Code FEC Scheme is: <list style="symbols">
<t>FEC Encoding ID: 130</t>
</list></t>
</section>
<section title="Common">
<t>The common FEC Object Transmission Information elements and
their encoding are the same as defined for the Small Block, Large
Block and Expandable FEC Scheme in <xref
target="smallLargeExpandableOTI"></xref>.</t>
</section>
<section title="Scheme-Specific">
<t>The Scheme-Specific FEC Object Transmission Information format
defined in <xref target="smallLargeExpandableSSOTI"></xref> SHALL
be used.</t>
</section>
</section>
</section>
<section title="Procedures">
<t>The algorithm defined in Section 9.1. of <xref
target="RFC5052"></xref> MUST be used to partition the file into
source blocks.</t>
</section>
<section title="FEC code specification">
<t>The FEC code specification and the correspondance of Encoding
Symbols IDs to encoding symbols are defined by specific instances of
this scheme and so are out of scope of this document.</t>
</section>
</section>
<section title="Security Considerations">
<t>This specification does not introduce any further security
considerations beyond those described in <xref
target="RFC5052"></xref>.</t>
</section>
<section title="Acknowledgments">
<t>This document is substantially based on <xref
target="RFC3695"></xref> by Michael Luby and Lorenzo Vicisano and <xref
target="RFC3452"></xref> by Michael Luby, Lorenzo Vicisano, Jim Gemmell,
Luigi Rizzo, Mark Handley and Jon Crowcroft.</t>
</section>
<section title="IANA Considerations">
<t>FEC Encoding IDs 0 and 130 were first defined and registered in the
ietf:rmt:fec:encoding namespace by <xref target="RFC3695"></xref>. This
document updates and obsoletes the definitions from that specification.
References to that specification should be replaced with references to
this document.</t>
<t>FEC Encoding IDs 128 and 129 were first defined and registered in the
ietf:rmt:fec:encoding namespace by <xref target="RFC3452"></xref>. This
document updates and obsoletes the definitions from that specification.
ces to that specification should be replaced with references to this
document.</t>
<t>Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA
registration. For general guidelines on IANA considerations as they
apply to this document, see <xref target="RFC5052"></xref>.</t>
<t>This document assigns the Fully-Specified FEC Encoding ID 0 under the
ietf:rmt:fec:encoding name-space (which was previously assigned by <xref
target="RFC3695"></xref> which is obsoleted by this document) to
"Compact No-Code" as specified in <xref target="CompactNoCode"></xref>
above.</t>
<t>This document assigns the Under-Specified FEC Encoding ID 128 under
the ietf:rmt:fec:encoding name-space (which was previously assigned by
<xref target="RFC3452"></xref>) to "Small Block, Large Block and
Expandable FEC Codes" as specified in <xref target="scheme128"></xref>
above.</t>
<t>This document assigns the Under-Specified FEC Encoding ID 129 under
the ietf:rmt:fec:encoding name-space (which was previously assigned by
<xref target="RFC3452"></xref>) to "Small Block, Systematic FEC Codes"
as specified in <xref target="scheme129"></xref> above.</t>
<t>This document assigns the Under-Specified FEC Encoding ID 130 under
the ietf:rmt:fec:encoding name-space (which was previously assigned by
<xref target="RFC3695"></xref> which is obsoleted by this document) to
"Compact FEC" as specified in <xref target="Compact"></xref> above.</t>
<t>As FEC Encoding IDs 128, 129 and 130 are Under-Specified, "FEC
Instance ID" sub-name-spaces must be established, in accordance to <xref
target="RFC5052"></xref>. Hence this document also assumes
responsibility for the "FEC Instance ID" registriesnamed <list>
<t>ietf:rmt:fec:encoding:instance:128, scoped by
ietf:rmt:fec:encoding = 128</t>
<t>ietf:rmt:fec:encoding:instance:129, scoped by
ietf:rmt:fec:encoding = 129</t>
<t>ietf:rmt:fec:encoding:instance:130, scoped by
ietf:rmt:fec:encoding = 130</t>
</list>The values that can be assigned within these namespaces are
non-negative numeric indices. Assignment requests are granted on a
"First Come First Served" basis. <xref target="RFC5052"></xref>
specifies additional criteria that MUST be met for the assignment within
the generic ietf:rmt:fec:encoding:instance name-space. These criteria
also apply to ietf:rmt:fec:encoding:instance:128,
ietf:rmt:fec:encoding:instance:129 and
ietf:rmt:fec:encoding:instance:130.</t>
<t></t>
</section>
<section anchor="changes"
title="Changes from schemes defined in RFC3452 and RFC3695">
<t>This section describes the changes between the Exprimental versions
of these FEC Scheme specifictions contained in <xref
target="RFC3452">RFC3452</xref> and <xref
target="RFC3695">RFC3695</xref> and those defined in this specification:
<list style="symbols">
<t>Scheme definitions have been updated to meet the requirements of
<xref target="RFC5052"></xref>.</t>
<t>Complete encoding formats for the FEC Object Trasmission
Information for each scheme are defined here, instead of within
content delivery protocol specifications, since the exact format
depends on the FEC Scheme.</t>
<t>The previous specifications for the Compact No-Code and Small
Block Systematic FEC Schemes did not require that all encoding
symbols of the object should have the same length. This requirement
is introduced in this specification. Since no protocols have been
defined which support variation of the encoding symbol length within
an object this should not cause backwards compatibility issues.</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5052;
</references>
<references title="Informative References">
&rfc3452;
&rfc3453;
&rfc3269;
&rfc3048;
&rfc3695;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 08:24:35 |