One document matched: draft-ietf-rmt-bb-fec-basic-schemes-revised-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3452 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3452.xml'>
<!ENTITY rfc3453 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3453.xml'>
<!ENTITY rfc3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>
<!ENTITY rfc2357 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2357.xml'>
<!ENTITY rfc1321 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1321.xml'>
<!ENTITY rfc2324 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2324.xml'>
<!ENTITY rfc2434 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
<!ENTITY rfc3048 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3048.xml'>
<!ENTITY rfc3269 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3269.xml'>
<!ENTITY rfc3695 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3695.xml'>
<!ENTITY fecbb PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmt-fec-bb-revised.xml'>
]>
<?rfc toc="yes" ?>
<rfc ipr="full3978" docName="draft-ietf-rmt-bb-fec-basic-schemes-revised-02">
<front>
<title abbrev="Basic FEC Schemes">Basic Forward Error Correction (FEC) Schemes</title>
<author initials="M." surname="Watson" fullname="Mark 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 month="March" year="2006"/>
<area>Transport</area>
<workgroup>Reliable Multicast Transport</workgroup>
<abstract>
<t>This document provides 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.</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="I-D.ietf-rmt-fec-bb-revised"/>:
<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="I-D.ietf-rmt-fec-bb-revised"/>.
This document also uses the terminology of the companion document <xref target="RFC3453"/> 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 RFC 3048 <xref target="RFC3048"/>. This document is a
product of the IETF RMT WG and follows the general guidelines
provided in RFC 3269 <xref target="RFC3269"/>.</t>
<t>RFC3452 <xref target="RFC3452"/> and RFC3695 <xref target="RFC3695"/> 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. </t>
<t>This Proposed Standard specification is thus based on and backwards compatible with the FEC Schemes defined in RFC3452 <xref target="RFC3452"/> and RFC3695 <xref target="RFC3695"/> 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 RFC3452 <xref target="RFC3452"/> and RFC3695 <xref target="RFC3695"/> and this document listed in <xref target="changes"/></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"/>.</t>
</section>
<section 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 title="FEC Payload ID(s)" anchor="compactNoCodeFPISection">
<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"/>.
<figure title="FEC Payload ID format for Compact No-Code FEC Scheme" anchor="compactNoCodeFPI">
<artwork>
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>
<t> The 16-bit Source Block Number 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 the
source block is processed at the transport layer by the sender, the
network transit time for packets, and the amount of time the source
block is processed at the transport layer by a receiver. This allows
the receiver to clearly decide which packets belong to which source
block.</t>
<t> The 16-bit Encoding Symbol ID 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"/>.</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 title="Common" anchor="compactNoCodeCommonOTI">
<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="I-D.ietf-rmt-fec-bb-revised"/> and are not duplicated here.</t>
<t>The encoded Common FEC Object Transmission information is defined in <xref target="compactNoCodeCommonFOTI"/>.
<figure title="Encoded Common FEC OTI for Compact No-Code FEC Scheme" anchor="compactNoCodeCommonFOTI">
<artwork>
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>
<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 SHOULD be set to zero by senders and its value SHOULD be ignored by receivers.</t>
<t><list><t>Note: this FEC Scheme was first defined in <xref target="RFC3695"/> 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 title="Procedures" anchor="compactNoCodeProcedures">
<t>The algorithm defined in Section 9.1. of <xref target="I-D.ietf-rmt-fec-bb-revised"/> MUST be used to partition the file into source blocks.</t>
</section>
<section title="FEC code specification" anchor="compactNoCodeSpec">
<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 of refer to the
companion document <xref target="RFC3452"/> 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 received out-of-band as part of
the FEC Object Transmission Information to determine the length X in
bytes of the source block, and allocates space for the X bytes that
the source block requires. The receiver also computes the length L
of the encoding symbol in the payload of the packet by substracting
the packet header length from the total length of the received packet
(and the receiver checks that this length is the same in each
subsequent received packet from the same source block). 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 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 title="Small Block, Large Block and Expandable FEC Scheme" anchor="scheme128">
<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"/>.</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"/>.
<figure title="FEC Payload ID format for Small Block, Large Block and Expandable FEC Codes" anchor="smallBlockFPI"><artwork>
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>
<t> The Source Block Number 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 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" anchor="smallLargeExpandableFOTI">
<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="I-D.ietf-rmt-fec-bb-revised"/> and are not duplicated here.</t>
<t>The encoded Common FEC Object Transmission information is defined in <xref target="smallLargeExpandableFOTI"/>.
<figure title="Encoded Common FEC OTI for Small Block, Large Block and Expandable FEC Scheme" anchor="smallLargeExpandableOTI">
<artwork>
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>
</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 title="Procedures">
<t>The algorithm defined in Section 9.1. of <xref target="I-D.ietf-rmt-fec-bb-revised"/> 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="Small Block Systematic FEC Scheme" anchor="scheme129">
<section title="Introduction">
<t>This section defines an
Under-Specified FEC Scheme for Small
Block Systematic FEC codes as described in <xref target="RFC3453"/>. For Small Block Systematic FEC codes,
each source block is of length at most 65536 source symbols.</t>
<t> Although these codes can generally be accommodated by the FEC
Encoding ID described in <xref target="scheme128"/>, 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"/>.
<figure title="FEC Payload ID format for Small Block Systematic FEC scheme" anchor="smallSystematicFPI">
<artwork>
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 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 the length in units of source symbols of
the source block identified by the Source Block Number.</t>
<t> The Encoding Symbol ID 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="I-D.ietf-rmt-fec-bb-revised"/> and are not duplicated here.</t>
<t>The encoded Common FEC Object Transmission information is defined in <xref target="smallSystematicCommonFOTI"/>.
<figure title="FEC OTI format for Small Block Systematic FEC Scheme" anchor="smallSystematicCommonFOTI">
<artwork>
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>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"/> 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>No Scheme-Specific FEC Object Transmission Information elements are defined by this FEC Scheme.</t>
</section>
</section>
</section>
<section title="Procedures">
<t>The algorithm defined in Section 9.1. of <xref target="I-D.ietf-rmt-fec-bb-revised"/> MAY 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="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"/> 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"/>.</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 title="Procedures">
<t>The algorithm defined in Section 9.1. of <xref target="I-D.ietf-rmt-fec-bb-revised"/> 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="I-D.ietf-rmt-fec-bb-revised"/>.</t></section>
<section title="Acknowledgments">
<t>This document is substantially based on <xref target="RFC3695"/> by Michael Luby and Lorenzo Vicisano and <xref target="RFC3452"/> 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"/>. This document updates and obsoletes the definitions from that specification.</t>
<t>FEC Encoding IDs 128 and 129 were first defined and registered in the ietf:rmt:fec:encoding namespace by <xref target="RFC3452"/>. This document updates and obsoletes the definitions from that specification.</t>
</section>
<section title="Changes from schemes defined in RFC3452 and RFC3695" anchor="changes">
<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="I-D.ietf-rmt-fec-bb-revised"/>.</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 th exact format depends on the FEC Scheme.</t>
<t>The previous specifications for the Compact No-Code and Small Block Systematic FEC Schemes sis 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;
&fecbb;
</references>
<references title="Informative References">
&rfc3452;
&rfc3453;
&rfc3269;
&rfc2357;
&rfc1321;
&rfc2434;
&rfc3048;
&rfc3695;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:25:39 |