 1/draftietfrmtbbfecrs03.txt 20071010 18:12:07.000000000 +0200
+++ 2/draftietfrmtbbfecrs04.txt 20071010 18:12:07.000000000 +0200
@@ 1,22 +1,22 @@
Reliable Multicast Transport J. Lacan
InternetDraft ENSICA/LAASCNRS
Intended status: Experimental V. Roca
Expires: November 8, 2007 INRIA
+InternetDraft ISAE
+Intended status: Standards Track V. Roca
+Expires: April 12, 2008 INRIA
J. Peltotalo
S. Peltotalo
Tampere University of Technology
 May 7, 2007
+ October 10, 2007
ReedSolomon Forward Error Correction (FEC) Schemes
 draftietfrmtbbfecrs03.txt
+ draftietfrmtbbfecrs04.txt
Status of this Memo
By submitting this InternetDraft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
@@ 27,43 +27,43 @@
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt.
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
 This InternetDraft will expire on November 8, 2007.
+ This InternetDraft will expire on April 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
 This document describes a FullySpecified FEC Scheme for the Reed
 Solomon forward error correction codes over GF(2^^m), with m in
+ This document describes a FullySpecified Forward Error Correction
+ (FEC) Scheme for the ReedSolomon FEC codes over GF(2^^m), with m in
{2..16}, and its application to the reliable delivery of data objects
on the packet erasure channel.
This document also describes a FullySpecified FEC Scheme for the
special case of ReedSolomon codes over GF(2^^8) when there is no
encoding symbol group.
Finally, in the context of the UnderSpecified Small Block Systematic
FEC Scheme (FEC Encoding ID 129), this document assigns an FEC
Instance ID to the special case of ReedSolomon codes over GF(2^^8).
ReedSolomon codes belong to the class of Maximum Distance Separable
 (MDS) codes, i.e. they enable a receiver to recover the k source
+ (MDS) codes, i.e., they enable a receiver to recover the k source
symbols from any set of k received symbols. The schemes described
here are compatible with the implementation from Luigi Rizzo.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions Notations and Abbreviations . . . . . . . . . . . 6
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6
@@ 90,64 +90,67 @@
8. ReedSolomon Codes Specification for the Erasure Channel . . . 17
8.1. Finite Field . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. ReedSolomon Encoding Algorithm . . . . . . . . . . . . . 18
8.2.1. Encoding Principles . . . . . . . . . . . . . . . . . 18
8.2.2. Encoding Complexity . . . . . . . . . . . . . . . . . 19
8.3. ReedSolomon Decoding Algorithm . . . . . . . . . . . . . 19
8.3.1. Decoding Principles . . . . . . . . . . . . . . . . . 19
8.3.2. Decoding Complexity . . . . . . . . . . . . . . . . . 20
8.4. Implementation for the Packet Erasure Channel . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
 12.2. Informative References . . . . . . . . . . . . . . . . . . 26
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
 Intellectual Property and Copyright Statements . . . . . . . . . . 29
+ 9.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 23
+ 9.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 23
+ 9.3. Attacks against the FEC parameters . . . . . . . . . . . . 25
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
+ Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction
The use of Forward Error Correction (FEC) codes is a classical
solution to improve the reliability of multicast and broadcast
transmissions. The [2] document describes a general framework to use
FEC in Content Delivery Protocols (CDP). The companion document [4]
describes some applications of FEC codes for content delivery.
 Recent FEC schemes like [9] and [10] proposed erasure codes based on
+ Recent FEC schemes like [9] and [8] proposed erasure codes based on
sparse graphs/matrices. These codes are efficient in terms of
processing but not optimal in terms of correction capabilities when
dealing with "small" objects.
The FEC scheme described in this document belongs to the class of
Maximum Distance Separable codes that are optimal in terms of erasure
correction capability. In others words, it enables a receiver to
recover the k source symbols from any set of exactly k encoding
symbols. Even if the encoding/decoding complexity is larger than
 that of [9] or [10], this family of codes is very useful.
+ that of [9] or [8], this family of codes is very useful.
Many applications dealing with content transmission or content
storage already rely on packetbased ReedSolomon codes. In
particular, many of them use the ReedSolomon codec of Luigi Rizzo
 [7]. The goal of the present document to specify an implementation
+ [5]. The goal of the present document to specify an implementation
of ReedSolomon codes that is compatible with this codec.
The present document:
o introduces the FullySpecified FEC Scheme with FEC Encoding ID 2
that specifies the use of ReedSolomon codes over GF(2^^m), with m
in {2..16},
o introduces the FullySpecified FEC Scheme with FEC Encoding ID 5
that focuses on the special case of ReedSolomon codes over
 GF(2^^8) and no encoding symbol group (i.e. exactly one symbol per
 packet), and
+ GF(2^^8) and no encoding symbol group (i.e., exactly one symbol
+ per packet), and
o in the context of the UnderSpecified Small Block Systematic FEC
Scheme (FEC Encoding ID 129) [3], assigns the FEC Instance ID 0 to
the special case of ReedSolomon codes over GF(2^^8) and no
encoding symbol group.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@@ 184,27 +187,27 @@
This document uses the following notations:
L denotes the object transfer length in bytes.
k denotes the number of source symbols in a source block.
n_r denotes the number of repair symbols generated for a source
block.
 n denotes the encoding block length, i.e. the number of encoding
+ n denotes the encoding block length, i.e., the number of encoding
symbols generated for a source block. Therefore: n = k + n_r.
max_n denotes the maximum number of encoding symbols generated for
any source block.
 B denotes the maximum source block length in symbols, i.e. the
+ B denotes the maximum source block length in symbols, i.e., the
maximum number of source symbols per source block.
N denotes the number of source blocks into which the object shall
be partitioned.
E denotes the encoding symbol length in bytes.
S denotes the symbol size in units of mbit elements. When m = 8,
then S and E are equal.
@@ 212,76 +215,73 @@
In this document, m belongs to {2..16}.
q defines the number of elements in the finite field. We have: q
= 2^^m in this specification.
G denotes the number of encoding symbols per group, i.e. the
number of symbols sent in the same packet.
GM denotes the Generator Matrix of a ReedSolomon code.
 rate denotes the "code rate", i.e. the k/n ratio.
+ rate denotes the "code rate", i.e., the k/n ratio.
a^^b denotes a raised to the power b.
a^^1 denotes the inverse of a.
I_k denotes the k*k identity matrix.
3.3. Abbreviations
This document uses the following abbreviations:
ESI stands for Encoding Symbol ID.
FEC OTI stands for FEC Object Transmission Information.
RS stands for ReedSolomon.
MDS stands for Maximum Distance Separable code.
 GF(q) denotes a finite field (A.K.A. Galois Field) with q
+ GF(q) denotes a finite field (also known as Galois Field) with q
elements. We assume that q = 2^^m in this document.
4. Formats and Codes with FEC Encoding ID 2
This section introduces the formats and codes associated to the
FullySpecified FEC Scheme with FEC Encoding ID 2 that specifies the
use of ReedSolomon codes over GF(2^^m).
4.1. FEC Payload ID
The FEC Payload ID is composed of the Source Block Number and the
Encoding Symbol ID. The length of these two fields depends on the
parameter m (which is transmitted in the FEC OTI) as follows:
o The Source Block Number (field of size 32m bits) identifies from
which source block of the object the encoding symbol(s) in the
 payload is(are) generated. There are a maximum of 2^^(32m)
 blocks per object.
+ payload is(are) generated. There is a maximum of 2^^(32m) blocks
+ per object.
o The Encoding Symbol ID (field of size m bits) identifies which
specific encoding symbol(s) generated from the source block
 is(are) carried in the packet payload. There are a maximum of
 2^^m encoding symbols per block. The first k values (0 to k  1)
+ is(are) carried in the packet payload. There is a maximum of 2^^m
+ encoding symbols per block. The first k values (0 to k  1)
identify source symbols, the remaining nk values identify repair
symbols.
There MUST be exactly one FEC Payload ID per source or repair packet.
In case of an Encoding Symbol Group, when multiple encoding symbols
are sent in the same packet, the FEC Payload ID refers to the first
symbol of the packet. The other symbols can be deduced from the ESI
of the first symbol by incrementing sequentially the ESI.
 The format of the FEC Payload ID for m = 8 and m = 16 is illustrated
 in Figure 1 and Figure 2 respectively.

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 (328=24 bits)  Enc. Symb. ID 
+++++++++++++++++++++++++++++++++
Figure 1: FEC Payload ID encoding format for m = 8 (default)
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
@@ 281,43 +281,47 @@
 Source Block Number (328=24 bits)  Enc. Symb. ID 
+++++++++++++++++++++++++++++++++
Figure 1: FEC Payload ID encoding format for m = 8 (default)
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
+++++++++++++++++++++++++++++++++
 Src Block Nb (3216=16 bits)  Enc. Symbol ID (m=16 bits) 
+++++++++++++++++++++++++++++++++
+
Figure 2: FEC Payload ID encoding format for m = 16
+ The format of the FEC Payload ID for m = 8 and m = 16 is illustrated
+ in Figure 1 and Figure 2 respectively.
+
4.2. FEC Object Transmission Information
4.2.1. Mandatory Elements
o FEC Encoding ID: the FullySpecified FEC Scheme described in this
section uses FEC Encoding ID 2.
4.2.2. Common Elements
The following elements MUST be defined with the present FEC scheme:
o TransferLength (L): a nonnegative integer indicating the length
of the object in bytes. There are some restrictions on the
maximum TransferLength that can be supported:
max_transfer_length = 2^^(32m) * B * E
For instance, for m = 8, for B = 2^^8  1 (because the codec
operates on a finite field with 2^^8 elements) and if E = 1024
bytes, then the maximum transfer length is approximately equal to
 2^^42 bytes (i.e. 4 Tera Bytes). Similarly, for m = 16, for B =
+ 2^^42 bytes (i.e., 4 Tera Bytes). Similarly, for m = 16, for B =
2^^16  1 and if E = 1024 bytes, then the maximum transfer length
is also approximately equal to 2^^42 bytes. For larger objects,
another FEC scheme, with a larger Source Block Number field in the
FEC Payload ID, could be defined. Another solution consists in
fragmenting large objects into smaller objects, each of them
complying with the above limits.
o EncodingSymbolLength (E): a nonnegative integer indicating the
length of each encoding symbol in bytes.
@@ 335,57 +339,56 @@
The following element MUST be defined with the present FEC Scheme.
It contains two distinct pieces of information:
o G: a nonnegative integer indicating the number of encoding
symbols per group used for the object. The default value is 1,
meaning that each packet contains exactly one symbol. When no G
parameter is communicated to the decoder, then this latter MUST
assume that G = 1.
 o Finite Field parameter, m: The m parameter is the length of the
 finite field elements, in bits. It also characterizes the number
 of elements in the finite field: q = 2^^m elements. The default
 value is m = 8. When no finite field size parameter is
 communicated to the decoder, then this latter MUST assume that m =
 8.
+ o m: The m parameter is the length of the finite field elements, in
+ bits. It also characterizes the number of elements in the finite
+ field: q = 2^^m elements. The default value is m = 8. When no
+ finite field size parameter is communicated to the decoder, then
+ this latter MUST assume that m = 8.
4.2.4. Encoding Format
This section shows the two possible encoding formats of the above FEC
OTI. The present document does not specify when one encoding format
or the other should be used.
4.2.4.1. Using the General EXT_FTI Format
The FEC OTI binary format is the following, when the EXT_FTI
 mechanism is used (e.g. within the ALC [11] or NORM [12] protocols).
+ mechanism is used (e.g., within the ALC [10] or NORM [11] protocols).
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
+++++++++++++++++++++++++++++++++
 HET = 64  HEL = 4  
+++++++++++++++++ +
 TransferLength (L) 
+++++++++++++++++++++++++++++++++
 m  G  Encoding Symbol Length (E) 
+++++++++++++++++++++++++++++++++
 Max Source Block Length (B)  Max Nb Enc. Symbols (max_n) 
+++++++++++++++++++++++++++++++++
Figure 3: EXT_FTI Header Format
4.2.4.2. Using the FDT Instance (FLUTE specific)
 When it is desired that the FEC OTI be carried in the FDT Instance of
 a FLUTE session [13], the following XML attributes must be described
 for the associated object:
+ When it is desired that the FEC OTI be carried in the FDT (File
+ Delivery Table) Instance of a FLUTE session [12], the following XML
+ attributes must be described for the associated object:
o FECOTIFECEncodingID
o FECOTITransferLength (L)
o FECOTIEncodingSymbolLength (E)
o FECOTIMaximumSourceBlockLength (B)
o FECOTIMaxNumberofEncodingSymbols (max_n)
@@ 425,25 +428,25 @@
special case of ReedSolomon codes over GF(2^^8) and no encoding
symbol group.
5.1. FEC Payload ID
The FEC Payload ID is composed of the Source Block Number and the
Encoding Symbol ID:
o The Source Block Number (24 bit field) identifies from which
source block of the object the encoding symbol in the payload is
 generated. There are a maximum of 2^^24 blocks per object.
+ generated. There is a maximum of 2^^24 blocks per object.
o The Encoding Symbol ID (8 bit field) identifies which specific
encoding symbol generated from the source block is carried in the
 packet payload. There are a maximum of 2^^8 encoding symbols per
+ packet payload. There is a maximum of 2^^8 encoding symbols per
block. The first k values (0 to k  1) identify source symbols,
the remaining nk values identify repair symbols.
There MUST be exactly one FEC Payload ID per source or repair packet.
This FEC Payload ID refer to the one and only symbol of the packet.
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 (24 bits)  Enc. Symb. ID 
@@ 469,38 +472,38 @@
5.2.4. Encoding Format
This section shows the two possible encoding formats of the above FEC
OTI. The present document does not specify when one encoding format
or the other should be used.
5.2.4.1. Using the General EXT_FTI Format
The FEC OTI binary format is the following, when the EXT_FTI
 mechanism is used (e.g. within the ALC [11] or NORM [12] protocols).
+ mechanism is used (e.g., within the ALC [10] or NORM [11] protocols).
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
+++++++++++++++++++++++++++++++++
 HET = 64  HEL = 3  
+++++++++++++++++ +
 TransferLength (L) 
+++++++++++++++++++++++++++++++++
 Encoding Symbol Length (E)  MaxBlkLen (B)  max_n 
+++++++++++++++++++++++++++++++++
Figure 6: EXT_FTI Header Format with FEC Encoding ID 5
5.2.4.2. Using the FDT Instance (FLUTE specific)
When it is desired that the FEC OTI be carried in the FDT Instance of
 a FLUTE session [13], the following XML attributes must be described
+ a FLUTE session [12], the following XML attributes must be described
for the associated object:
o FECOTIFECEncodingID
o FECOTITransferLength (L)
o FECOTIEncodingSymbolLength (E)
o FECOTIMaximumSourceBlockLength (B)
@@ 511,23 +514,29 @@
This section defines procedures that are common to FEC Encoding IDs 2
and 5. In case of FEC Encoding ID 5, m = 8 and G = 1. Note that the
block partitioning algorithm is defined in [2].
6.1. Determining the Maximum Source Block Length (B)
The finite field size parameter, m, defines the number of non zero
elements in this field which is equal to: q  1 = 2^^m  1. Note
that q  1 is also the theoretical maximum number of encoding symbols
that can be produced for a source block. For instance, when m = 8
 (default):
+ (default) there is a maximum of 2^^8  1 = 255 encoding symbols.
 max1_B = 2^^8  1 = 255
+ Given the target FEC code rate (e.g., provided by the user when
+ starting a FLUTE sending application), the sender calculates:
+
+ max1_B = floor((2^^m  1) * rate)
+
+ This max1_B value leaves enough room for the sender to produce the
+ desired number of parity symbols.
Additionally, a codec MAY impose other limitations on the maximum
block size. Yet it is not expected that such limits exist when using
the default m = 8 value. This decision MUST be clarified at
implementation time, when the target use case is known. This results
in a max2_B limitation.
Then, B is given by:
B = min(max1_B, max2_B)
@@ 543,48 +552,48 @@
AT A SENDER:
Input:
B: Maximum source block length, for any source block. Section 6.1
explains how to determine its value.
k: Current source block length. This parameter is given by the
block partitioning algorithm.
 rate: FEC code rate, which is given by the user (e.g. when
+ rate: FEC code rate, which is given by the user (e.g., when
starting a FLUTE sending application). It is expressed as a
floating point value.
Output:
max_n: Maximum number of encoding symbols generated for any source
 block
+ block.
 n: Number of encoding symbols generated for this source block
+ n: Number of encoding symbols generated for this source block.
Algorithm:
 max_n = floor(B / rate);
+ max_n = ceil(B / rate);
if (max_n > 2^^m  1) then return an error ("invalid code rate");
n = floor(k * max_n / B);
AT A RECEIVER:
Input:
 B: Extracted from the received FEC OTI
+ B: Extracted from the received FEC OTI.
 max_n: Extracted from the received FEC OTI
+ max_n: Extracted from the received FEC OTI.
 k: Given by the block partitioning algorithm
+ k: Given by the block partitioning algorithm.
Output:
n
Algorithm:
n = floor(k * max_n / B);
Note that a ReedSolomon decoder does not need to know the n value.
@@ 599,24 +608,24 @@
Solomon Codes over GF(2^^8)
In the context of the UnderSpecified Small Block Systematic FEC
Scheme (FEC Encoding ID 129) [3], this document assigns the FEC
Instance ID 0 to the special case of ReedSolomon codes over GF(2^^8)
and no encoding symbol group.
The FEC Instance ID 0 uses the Formats and Codes specified in [3].
The FEC Scheme with FEC Instance ID 0 MAY use the algorithm defined
 in Section 9.1. of [3] to partition the file into source blocks.
+ in Section 9.1. of [2] to partition the file into source blocks.
This FEC Scheme MAY also use another algorithm. For instance the CDP
sender may change the length of each source block dynamically,
 depending on some external criteria (e.g. to adjust the FEC coding
+ depending on some external criteria (e.g., to adjust the FEC coding
rate to the current loss rate experienced by NORM receivers) and
inform the CDP receivers of the current block length by means of the
EXT_FTI mechanism. This choice is out of the scope of the current
document.
8. ReedSolomon Codes Specification for the Erasure Channel
ReedSolomon (RS) codes are linear block codes. They also belong to
the class of MDS codes. A [n,k]RS code encodes a sequence of k
source elements defined over a finite field GF(q) into a sequence of
@@ 628,21 +637,21 @@
mbit elements, and Section 8.4 the use of [n,k]RS codes when
applied to symbols composed of several mbit elements, which is the
target of this specification.
8.1. Finite Field
A finite field GF(q) is defined as a finite set of q elements which
has a structure of field. It contains necessarily q = p^^m elements,
where p is a prime number. With packet erasure channels, p is always
set to 2. The elements of the field GF(2^^m) can be represented by
 polynomials with binary coefficients (i.e. over GF(2)) of degree
+ polynomials with binary coefficients (i.e., over GF(2)) of degree
lower or equal than m1. The polynomials can be associated to binary
vectors of length m. For example, the vector (11001) represents the
polynomial 1 + x + x^^4. This representation is often called
polynomial representation. The addition between two elements is
defined as the addition of binary polynomials in GF(2) and the
multiplication is the multiplication modulo a given irreducible
polynomial over GF(2) of degree m with coefficients in GF(2). Note
that all the roots of this polynomial are in GF(2^^m) but not in
GF(2).
@@ 723,45 +732,45 @@
Note that, in practice, the [n,k]RS code can be shortened to a
[n',k]RS code, where k <= n' < n, by considering the submatrix
formed by the n' first columns of GM.
8.2.2. Encoding Complexity
Encoding can be performed by first precomputing GM and by
multiplying the source vector (k elements) by GM (k rows and n
columns). The complexity of the precomputation of the generator
matrix can be estimated as the complexity of the multiplication of
 the inverse of a Vandermonde matrix by nk vectors (i.e. the last nk
 columns of V_{k,n}). Since the complexity of the inverse of a k*k
 Vandermonde matrix by a vector is O(k * log^^2(k)), the generator
+ the inverse of a Vandermonde matrix by nk vectors (i.e., the last
+ nk columns of V_{k,n}). Since the complexity of the inverse of a
+ k*kVandermonde matrix by a vector is O(k * log^^2(k)), the generator
matrix can be computed in 0((nk)* k * log^^2(k)) operations. When
the generator matrix is precomputed, the encoding needs k operations
per repair element (vectormatrix multiplication).
Encoding can also be performed by first computing the product s *
V_{k,k}^^1 and then by multiplying the result with V_{k,n}. The
multiplication by the inverse of a square Vandermonde matrix is known
as the interpolation problem and its complexity is O(k * log^^2 (k)).
The multiplication by a Vandermonde matrix, known as the multipoint
evaluation problem, requires O((nk) * log(k)) by using Fast Fourier
 Transform, as explained in [14]. The total complexity of this
+ Transform, as explained in [7]. The total complexity of this
encoding algorithm is then O((k/(nk)) * log^^2(k) + log(k))
operations per repair element.
8.3. ReedSolomon Decoding Algorithm
8.3.1. Decoding Principles
The ReedSolomon decoding algorithm for the erasure channel allows
the recovery of the k source elements from any set of k received
elements. It is based on the fundamental property of the generator
 matrix which is such that any k*ksubmatrix is invertible (see [8]).
+ matrix which is such that any k*ksubmatrix is invertible (see [6]).
The first step of the decoding consists in extracting the k*k
submatrix of the generator matrix obtained by considering the columns
corresponding to the received elements. Indeed, since any encoding
element is obtained by multiplying the source vector by one column of
the generator matrix, the received vector of k encoding elements can
be considered as the result of the multiplication of the source
vector by a k*k submatrix of the generator matrix. Since this
submatrix is invertible, the second step of the algorithm is to
invert this matrix and to multiply the received vector by the
obtained matrix to recover the source vector.
@@ 791,125 +800,220 @@
known. The following specification describes the use of ReedSolomon
codes for generating redundant symbols from the k source symbols and
for recovering the source symbols from any set of k received symbols.
The k source symbols of a source block are assumed to be composed of
S mbit elements. Each mbit element corresponds to an element of
the finite field GF(2^^m) through the polynomial representation
(Section 8.1). If some of the source symbols contain less than S
elements, they MUST be virtually padded with zero elements (it can be
the case for the last symbol of the last block of the object).
 However, this padding need not be actually sent with the data to the
 receivers.
+ However, this padding does not need to be actually sent with the data
+ to the receivers.
The encoding process produces n encoding symbols of size S mbit
elements, of which k are source symbols (this is a systematic code)
and nk are repair symbols (Figure 7). The mbit elements of the
repair symbols are calculated using the corresponding mbit elements
of the source symbol set. A logical jth source vector, comprised of
the jth elements from the set of source symbols, is used to
calculate a jth encoding vector. This jth encoding vector then
provides the jth elements for the set encoding symbols calculated
for the block. As a systematic code, the first k encoding symbols
are the same as the k source symbols and the last nk repair symbols
 are the result of the Reed Solomon encoding.
+ are the result of the ReedSolomon encoding.
Input: k source symbols
0 j S1
+++++++++++++++++++++++++++
 X  source symbol 0
+++++++++++++++++++++++++++
+++++++++++++++++++++++++++
 X  source symbol 1
+++++++++++++++++++++++++++
. . .
+++++++++++++++++++++++++++
 X  source symbol k1
+++++++++++++++++++++++++++
*
 ++
  generator 
  matrix 
+ ++
+  generator matrix 
 GM 
 (k x n) 
 ++
+ ++

V
Output: n encoding symbols (source + repair)
0 j S1
+++++++++++++++++++++++++++
 X  enc. symbol 0
+++++++++++++++++++++++++++
+++++++++++++++++++++++++++
 X  enc. symbol 1
+++++++++++++++++++++++++++
. . .
+++++++++++++++++++++++++++
 Y  enc. symbol n1
+++++++++++++++++++++++++++
 Figure 7: Packet encoding scheme
+ Figure 7: Packet encoding scheme
An asset of this scheme is that the loss of some encoding symbols
produces the same erasure pattern for each of the S encoding vectors.
It follows that the matrix inversion must be done only once and will
be used by all the S encoding vectors. For large S, this matrix
inversion cost becomes negligible in front of the S matrixvector
multiplications.
Another asset is that the nk repair symbols can be produced on
demand. For instance, a sender can start by producing a limited
number of repair symbols and later on, depending on the observed
erasures on the channel, decide to produce additional repair symbols,
up to the nk upper limit. Indeed, to produce the repair symbol e_j,
where k <= j < n, it is sufficient to multiply the S source vectors
with column j of GM.
9. Security Considerations
 Data delivery can be subject to denialofservice attacks by
 attackers which send corrupted packets that are accepted as
 legitimate by receivers. This is particularly a concern for
 multicast delivery because a corrupted packet may be injected into
 the session close to the root of the multicast tree, in which case
 the corrupted packet will arrive at many receivers. This is
 particularly a concern for the FEC building block because the use of
 even one corrupted packet containing encoding data may result in the
 decoding of an object that is completely corrupted and unusable. It
 is thus RECOMMENDED that source authentication and integrity checking
 are applied to decoded objects before delivering objects to an
 application. For example, a SHA1 hash [5] of an object may be
 appended before transmission, and the SHA1 hash is computed and
 checked after the object is decoded but before it is delivered to an
 application. Source authentication SHOULD be provided, for example
 by including a digital signature verifiable by the receiver computed
 on top of the hash value. It is also RECOMMENDED that a packet
 authentication protocol such as TESLA [6] be used to detect and
 discard corrupted packets upon arrival. Furthermore, it is
 RECOMMENDED that Reverse Path Forwarding checks be enabled in all
 network routers and switches along the path from the sender to
 receivers to limit the possibility of a bad agent successfully
 injecting a corrupted packet into the multicast tree data path.
+9.1. Problem Statement
 Another security concern is that some FEC information may be obtained
 by receivers outofband in a session description, and if the session
 description is forged or corrupted then the receivers will not use
 the correct protocol for decoding content from received packets. To
 avoid these problems, it is RECOMMENDED that measures be taken to
 prevent receivers from accepting incorrect session descriptions,
 e.g., by using source authentication to ensure that receivers only
 accept legitimate session descriptions from authorized senders.
+ A content delivery system is potentially subject to many attacks:
+ some of them target the network (e.g., to compromise the routing
+ infrastructure, by compromising the congestion control component),
+ others target the Content Delivery Protocol (CDP) (e.g., to
+ compromise its normal behavior), and finally some attacks target the
+ content itself. Since this document focuses on a FEC building block
+ independently of any particular CDP (even if ALC and NORM are two
+ natural candidates), this section only discusses the additional
+ threats that an arbitrary CDP may be exposed to when using this
+ building block.
+
+ More specifically, several kinds of attacks exist:
+
+ o those that are meant to give access to a confidential content
+ (e.g., in case of a nonfree content),
+
+ o those that try to corrupt the object being transmitted (e.g., to
+ inject malicious code within an object, or to prevent a receiver
+ from using an object),
+
+ o and those that try to compromise the receiver's behavior (e.g., by
+ making the decoding of an object computationally expensive).
+
+ These attacks can be launched either against the data flow itself
+ (e.g. by sending forged symbols) or against the FEC parameters that
+ are sent either inband (e.g., in an EXT_FTI or FDT Instance) or out
+ ofband (e.g., in a session description).
+
+9.2. Attacks Against the Data Flow
+
+ First of all, let us consider the attacks against the data flow.
+ Access control is typically provided by means of encryption. This
+ encryption can be done over the whole object (e.g., by the content
+ provider, before the FEC encoding process), or be done on a packet
+ per packet basis (e.g., when IPSec/ESP is used [14]). If access
+ control is a concern, it is RECOMMENDED that one of these solutions
+ be used. Even if we mention these attacks here, they are not related
+ nor facilitated by the use of FEC.
+
+ Protection against corruptions (forged packets) is achieved by means
+ of a content integrity verification/sender authentication scheme.
+ This service can be provided at the object level, but in that case a
+ receiver has no way to identify which symbol(s) is(are) corrupted if
+ the object is detected as corrupted. This service can also be
+ provided at the packet level, and after having removed all forged
+ packets, the object can be recovered if the number of symbols
+ remaining is sufficient. Several techniques can provide this source
+ authentication/content integrity service:
+
+ o at the object level, the object MAY be digitally signed (with
+ public key cryptography) (e.g., using RSASSAPKCS1v1_5 [13]).
+ This signature enables a receiver to check the object, once this
+ latter has been fully decoded. Even if digital signatures are
+ computationally expensive, this calculation occurs only once per
+ object, which is usually acceptable;
+
+ o at the packet level, each packet can be digitally signed. A major
+ limitation is the high computational and transmission overheads
+ that this solution incurs (unless ECC is used, but ECC is
+ protected by IPR). To avoid this problem, the signature may span
+ a set of symbols in order to amortize the signature calculation,
+ but if a single symbol is missing, the integrity of the whole set
+ cannot be checked;
+
+ o at the packet level, a Group Message Authentication Code (MAC)
+ [15] (e.g., using HMACSHA1 with a secret key shared by all the
+ group members, senders and receivers) scheme can be used. This
+ technique creates a cryptographically secured (thanks to the
+ secret key) digest of a packet that is sent along with the packet.
+ The Group MAC scheme does not incur prohibitive processing load
+ nor transmission overhead, but it has a major limitation: it only
+ provides a group authentication/integrity service since all group
+ members share the same secret group key, which means that each
+ member can send a forged packet. It is therefore restricted to
+ situations where group members are fully trusted (or in
+ association with another technique as a precheck);
+
+ o at the packet level, TESLA [16] is a very attractive and efficient
+ solution that is robust to losses, provides a true authentication/
+ integrity service, and does not incur any prohibitive processing
+ load or transmission overhead.
+
+ It is up to the developer, who knows the security requirements of the
+ target usecase, to define which solution is the most appropriate.
+ Nonetheless, it is RECOMMENDED that at least one of these techniques
+ be used.
+
+ Techniques relying on public key cryptography (digital signatures and
+ TESLA during the bootstrap process) require that public keys be
+ securely associated to the entities. This can be achieved by a
+ Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by pre
+ distributing the public keys of each group member. It is up to the
+ developer, who knows the features of the target usecase, to define
+ which solution to use.
+
+ Techniques relying on symmetric key cryptography (group MAC) require
+ that a secret key be shared by all group members. This can be
+ achieved by means of a group key management protocol, or simply by
+ predistributing the secret key (but this manual solution has many
+ limitations). Here also, it is up to the developer to define which
+ solution to use, taking into account the target usecase features.
+
+9.3. Attacks against the FEC parameters
+
+ Let us now consider attacks against the FEC parameters (or FEC OTI).
+ The FEC OTI can either be sent inband (i.e., in an EXT_FTI or in an
+ FDT Instance containing FEC OTI for the object) or outofband (e.g.,
+ in a session description). Attacks on these FEC parameters can
+ prevent the decoding of the associated object: for instance modifying
+ the B parameter will lead to a different block partitioning at a
+ receiver thereby compromising decoding; or setting the m parameter to
+ 16 instead of 8 with FEC Encoding ID 2 will increase the processing
+ load while compromising decoding.
+
+ It is therefore RECOMMENDED that security measures be taken to
+ guarantee the FEC OTI integrity. To that purpose, the packets
+ carrying the FEC parameters sent inband (i.e., in an EXT_FTI header
+ extension or in an FDT Instance) may be protected by one of the per
+ packet techniques described above: TESLA, digital signature, or a
+ group MAC. Alternatively, when FEC OTI is contained in an FDT
+ Instance, this object may be digitally signed. Finally, when FEC OTI
+ is sent outofband for instance in a session description, this
+ latter may be protected by a digital signature.
+
+ The same considerations concerning the key management aspects apply
+ here also.
10. IANA Considerations
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 [2].
This document assigns the FullySpecified FEC Encoding ID 2 under the
"ietf:rmt:fec:encoding" namespace to "ReedSolomon Codes over
GF(2^^m)".
@@ 920,99 +1024,105 @@
This document assigns the FEC Instance ID 0 scoped by the Under
Specified FEC Encoding ID 129 to "ReedSolomon Codes over GF(2^^8)".
More specifically, under the "ietf:rmt:fec:encoding:instance" sub
namespace that is scoped by the "ietf:rmt:fec:encoding" called
"Small Block Systematic FEC Codes", this document assigns FEC
Instance ID 0 to "ReedSolomon Codes over GF(2^^8)".
11. Acknowledgments
 The authors want to thank Brian Adamson for his valuable comments.
 The authors also want to thank Luigi Rizzo for comments on the
 subject and for the design of the reference ReedSolomon codec.
+ The authors want to thank Brian Adamson, Igor Slepchin, Stephen Kent,
+ and Francis Dupont for their valuable comments. The authors also
+ want to thank Luigi Rizzo for his comments and for the design of the
+ reference ReedSolomon codec.
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119.
[2] Watson, M., Luby, M., and L. Vicisano, "Forward Error
 Correction (FEC) Building Block",
 draftietfrmtfecbbrevised07.txt (work in progress),
 April 2007.
+ Correction (FEC) Building Block", RFC 5052, August 2007.
[3] Watson, M., "Basic Forward Error Correction (FEC) Schemes",
draftietfrmtbbfecbasicschemesrevised03.txt (work in
progress), February 2007.
+12.2. Informative References
+
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Reliable Multicast", RFC 3453, December 2002.
 [5] "HMAC: KeyedHashing for Message Authentication", RFC 2104,
 February 1997.

 [6] "Timed Efficient Stream LossTolerant Authentication (TESLA):
 Multicast Source Authentication Transform Introduction",
 RFC 4082, June 2005.

12.2. Informative References

 [7] Rizzo, L., "ReedSolomon FEC codec (revised version of July
+ [5] Rizzo, L., "ReedSolomon FEC codec (revised version of July
2nd, 1998), available at
 http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz, and
+ http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz and
mirrored at http://planetebcast.inrialpes.fr/", July 1998.
 [8] Mac Williams, F. and N. Sloane, "The Theory of Error Correcting
+ [6] Mac Williams, F. and N. Sloane, "The Theory of Error Correcting
Codes", North Holland, 1977 .
 [9] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
 "Raptor Forward Error Correction Scheme",
 draftietfrmtbbfecraptorobject08 (work in progress),
 April 2007.
+ [7] Gohberg, I. and V. Olshevsky, "Fast algorithms with
+ preprocessing for matrixvector multiplication problems",
+ Journal of Complexity, pp. 411427, vol. 10, 1994.
 [10] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity
+ [8] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity
Check (LDPC) Forward Error Correction",
draftietfrmtbbfecldpc06.txt (work in progress),
May 2007.
 [11] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered
+ [9] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
+ "Raptor Forward Error Correction Scheme",
+ draftietfrmtbbfecraptorobject09 (work in progress),
+ June 2007.
+
+ [10] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered
Coding (ALC) Protocol Instantiation",
draftietfrmtpialcrevised04.txt (work in progress),
February 2007.
 [12] Adamson, B., Bormann, C., Handley, M., and J. Macker,
+ [11] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negativeacknowledgment (NACK)Oriented Reliable Multicast
 (NORM) Protocol", draftietfrmtpinormrevised04.txt (work
+ (NORM) Protocol", draftietfrmtpinormrevised05.txt (work
in progress), March 2007.
 [13] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca,
+ [12] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca,
"FLUTE  File Delivery over Unidirectional Transport",
 draftietfrmtfluterevised03.txt (work in progress),
 January 2007.
+ draftietfrmtfluterevised04.txt (work in progress),
+ October 2007.
 [14] Gohberg, I. and V. Olshevsky, "Fast algorithms with
 preprocessing for matrixvector multiplication problems",
 Journal of Complexity, pp. 411427, vol. 10, 1994 .
+ [13] Jonsson, J. and B. Kaliski, "PublicKey Cryptography Standards
+ (PKCS) #1: RSA Cryptography Specifications Version 2.1",
+ RFC 3447, February 2003.
+
+ [14] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
+ December 2005.
+
+ [15] "HMAC: KeyedHashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [16] "Timed Efficient Stream LossTolerant Authentication (TESLA):
+ Multicast Source Authentication Transform Introduction",
+ RFC 4082, June 2005.
Authors' Addresses
Jerome Lacan
 ENSICA/LAASCNRS
+ ISAE
1, place Emile Blouin
Toulouse 31056
France
 Email: jerome.lacan@ensica.fr
+ Email: jerome.lacan@isae.fr
URI: http://dmi.ensica.fr/auteur.php3?id_auteur=5
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: vincent.roca@inrialpes.fr