Internet Engineering Task Force                                  RMT WG
INTERNET-DRAFT                                                   M. Luby
draft-luby-rmt-bb-fec-raptor-object-00.txt            Digital Fountain
                                                          A. Shokrollahi
                                                                    EPFL
                                                         19 October 2004
                                                     Expires: April 2005



        Raptor Forward Error Correction (FEC) Schemes for Objects




Status of this Document


By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.


Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. Internet-
Drafts are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than a "work in progress." The list of current Internet-
Drafts can be accessed at http://www.ietf.org/1id-abstracts.html.


The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.


This document is a product of the IETF RMT WG.  Comments should be
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.



Abstract



This document describes the Raptor code and its application to reliable
delivery of objects.  Two Fully-Specified Forward Error Correction (FEC)
schemes are introduced, one for a non-systematic version of Raptor and
one for a systematic version of Raptor, that supplements the FEC schemes
described in RFC 3452.





Luby/Shokrollahi                                                [Page 1]


INTERNET-DRAFT          Expires: April 2005             October 2004



Raptor is a fountain code, i.e., as many encoding symbols as needed can
be generated by the encoder on-the-fly from the source symbols of a
source block.  The decoder is able to recover the source block from any
set of encoding symbols only slightly more in number than the number of
source symbols.















































Luby/Shokrollahi                                                [Page 2]


INTERNET-DRAFT          Expires: April 2005             October 2004



                           Table of Contents



1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . .   4
 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
 1.2. Gray sequences . . . . . . . . . . . . . . . . . . . . . . . .   5
 1.3. Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
2. Raptor Encoding of a Source Block . . . . . . . . . . . . . . . .   7
 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
 2.2. Pre-coding . . . . . . . . . . . . . . . . . . . . . . . . . .   7
 2.3. Generators . . . . . . . . . . . . . . . . . . . . . . . . . .   9
  2.3.1. Random Generator. . . . . . . . . . . . . . . . . . . . . .   9
  2.3.2. Degree Generator. . . . . . . . . . . . . . . . . . . . . .   9
  2.3.3. Encoding Symbol Generator . . . . . . . . . . . . . . . . .  10
 2.4. Encoding work. . . . . . . . . . . . . . . . . . . . . . . . .  10
3. Raptor Decoding of a Source Block . . . . . . . . . . . . . . . .  11
 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
 3.2. First Phase. . . . . . . . . . . . . . . . . . . . . . . . . .  13
 3.3. Second Phase . . . . . . . . . . . . . . . . . . . . . . . . .  14
 3.4. Third Phase. . . . . . . . . . . . . . . . . . . . . . . . . .  14
 3.5. Fourth Phase . . . . . . . . . . . . . . . . . . . . . . . . .  15
4. Raptor Object Delivery. . . . . . . . . . . . . . . . . . . . . .  15
 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  16
 4.2. Source blocks and sub-blocks . . . . . . . . . . . . . . . . .  17
 4.3. Session and packet information . . . . . . . . . . . . . . . .  17
  4.3.1. FEC Object Transmission Information . . . . . . . . . . . .  18
  4.3.2. FEC Payload ID. . . . . . . . . . . . . . . . . . . . . . .  19
 4.4. Encoding an object . . . . . . . . . . . . . . . . . . . . . .  19
  4.4.1. Smaller objects . . . . . . . . . . . . . . . . . . . . . .  20
  4.4.2. Larger objects. . . . . . . . . . . . . . . . . . . . . . .  22
  4.4.3. Large objects . . . . . . . . . . . . . . . . . . . . . . .  24
  4.4.4. Encoding work per object. . . . . . . . . . . . . . . . . .  25
 4.5. Decoding an object . . . . . . . . . . . . . . . . . . . . . .  25
  4.5.1. Decoding work per object. . . . . . . . . . . . . . . . . .  26
  4.5.2. Decoding failure probability. . . . . . . . . . . . . . . .  27
5. Systematic Raptor . . . . . . . . . . . . . . . . . . . . . . . .  27
 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  27
 5.2. Systematic information . . . . . . . . . . . . . . . . . . . .  28
 5.3. Generating source symbol triples from system-
 atic information. . . . . . . . . . . . . . . . . . . . . . . . . .  29
 5.4. Calculating the intermediate pre-coding sym-
 bols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  30
 5.5. Work and decoding failure probability. . . . . . . . . . . . .  30
 5.6. Calculating the systematic information . . . . . . . . . . . .  30
6. Raptor Systematic Object Delivery . . . . . . . . . . . . . . . .  32
 6.1. Session and packet information . . . . . . . . . . . . . . . .  33
  6.1.1. FEC Object Transmission Information . . . . . . . . . . . .  33
  6.1.2. FEC Payload ID. . . . . . . . . . . . . . . . . . . . . . .  33




Luby/Shokrollahi                                                [Page 3]


INTERNET-DRAFT          Expires: April 2005             October 2004



 6.2. Encoding an object . . . . . . . . . . . . . . . . . . . . . .  33
  6.2.1. Smaller objects . . . . . . . . . . . . . . . . . . . . . .  33
  6.2.2. Larger objects. . . . . . . . . . . . . . . . . . . . . . .  35
  6.2.3. Large objects . . . . . . . . . . . . . . . . . . . . . . .  35
 6.3. Decoding an object . . . . . . . . . . . . . . . . . . . . . .  35
7. Security Considerations . . . . . . . . . . . . . . . . . . . . .  36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . .  36
9. Intellectual Property . . . . . . . . . . . . . . . . . . . . . .  37
10. Normative References . . . . . . . . . . . . . . . . . . . . . .  37
11. Informative References . . . . . . . . . . . . . . . . . . . . .  37
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  38
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  39








































Luby/Shokrollahi                                                [Page 4]


INTERNET-DRAFT          Expires: April 2005             October 2004



1.  Introduction


This document describes the Raptor code and its application to reliable
delivery of objects.  Two Fully-Specified Forward Error Correction (FEC)
schemes are introduced, one for a non-systematic version of Raptor and
one for a systematic version of Raptor, that supplements the FEC schemes
described in RFC 3452.



We first provide a simple and easy to implement description of a non-
systematic Raptor encoder and decoder and then describe how to apply
this version to reliable delivery of objects.  We then describe how to
modify the non-systematic Raptor code to make it systematic, and then
describe how to apply the systematic Raptor codes to reliable delivery
of objects.  Thus, we introduce two new Fully-Specified FEC Schemes for
reliable object delivery, one for the non-systematic Raptor code and one
for the systematic Raptor code.


Raptor is a fountain code (as for example defined in [10]), i.e., as
many encoding symbols as needed can be generated by the encoder on-the-
fly from the source symbols of a source block.  The decoder is able to
recover the source block from any set of encoding symbols only slightly
more in number than the number of source symbols.  This fountain
property holds for both the non-systematic and the systematic versions
of Raptor.  There are many advantages to using fountain codes versus
other types of FEC codes, some of which are described in [9] and [10].


This document inherits the context, language, declarations and
restrictions of the FEC building block [4]. This document also uses some
of the terminology of the companion document [14] 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.


Building blocks are defined in RFC 3048 [7]. This document is a product
of the IETF RMT WG and follows the general guidelines provided in RFC
3269 [3].


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 RFC 2119 [2].



1.1.  Notation


We use the following notation hereafter.  For a positive value x let
floor(x) be x rounded down to the nearest integer and let ceil(x) be x
rounded up to the nearest integer.





Luby/Shokrollahi                                  Section 1.1.  [Page 5]


INTERNET-DRAFT          Expires: April 2005             October 2004



For positive integers i and j let i MOD j denote i modulo j.  For
example, 11 MOD 3 = 2.


For positive integers i and j let i^j denote i raised to the power j.
For example, 2^16 = 65,536.


Note that 65,521 is the largest prime smaller than 2^16.


For equal-length bit strings X and Y let X XOR Y denote the bit-by-bit
exclusive-or of X and Y.  For example, 1010 XOR 1100 = 0110.




1.2.  Gray sequences


We use a Gray sequence in the description of the generation of the half
symbols in the pre-coding step, as described below.  For all positive
integers i, let g[i] be defined as follows.  Let b[i] be the highest
order bit that is different in the binary representation of i-1 and i.
Then, the binary representation of g[i] is obtained by flipping bit b[i]
of g[i-1].  Table 1.2 provides some example values for g[i].  Note that
the sequence defined by g[.] has the property that each pair of
consecutive elements in the sequence differ in exactly one bit position.



i_____g[i]
0000  0000
0001  0001
0010  0011
0011  0010
0100  0110
0101  0111
0110  0101
0111  0100
1000  1100
1001  1101
1010  1111
1011  1110
1100  1010
1101  1011
1110  1001
1111  1000


Table 1.2: Gray sequence g[.]



We also use the function cnt[i], where cnt[i] returns the number of bits
that are set to one in the binary representation of i. For example the




Luby/Shokrollahi                                  Section 1.2.  [Page 6]


INTERNET-DRAFT          Expires: April 2005             October 2004



binary representation of 25 is 11001, and thus cnt[25] = 3.


For any fixed positive integer j let g[.,j] be the subsequence of g[.]
where for each element in the sequence exactly j bits are set to 1.
Thus, g[.,j] can be defined based on g[.] as follows.



  * c = 0, i = 0


  * Do forever


      o While (cnt(g[c]) not= j) do c = c+1


      o g[i,j] = g[c]


      o c = c+1


      o i = i+1



For example, g[0,2] = g[2], g[1,2] = g[4], g[2,2] = g[6], g[3,2] = g[8],
g[4,2] = g[12], etc.  Note that g[.,j] has the property that each pair
of consecutive elements in the sequence differ in exactly two bit
positions.  For all i = 1, let Pos1[i,j] be one of the bit positions in
which g[i,j] and g[i-1,j] differ and let Pos2[i,j] be the other bit
position in which they differ.  For example, Pos1[2,2] = 0 and Pos2[2,2]
= 1.




1.3.  Work


The complexity of encoding and decoding is measured in terms of the
number of bytes of symbols that are exclusive-ored together or copied,
which is defined to be the work.  Thus, for example, if a symbol is 64
bytes long, then computing the exclusive-or of two symbols counts as 64
bytes of work, and copying a symbol from one location to another also
counts as 64 bytes of work.  The total encoding and decoding times
depend also on the amount of bookkeeping operations that are needed to
determine which symbols are exclusive-ored together or copied.  But
since the symbols are typically relatively long, and since when there
are multiple source blocks the bookkeeping operations are done only once
and can be amortized over all the source blocks, the exclusive-or and
copy operations of symbols provide a rough estimate of the relative time
it takes to encode and decode on different CPU/OS platforms.
Furthermore, the efficiency of the bookkeeping operations are
implementation dependent, and in an efficient implementation the
bookkeeping operations take a fraction of the time that the exclusive-or




Luby/Shokrollahi                                  Section 1.3.  [Page 7]


INTERNET-DRAFT          Expires: April 2005             October 2004



and copy operations take.




2.  Raptor Encoding of a Source Block



2.1.  Overview


Symbols are the fundamental data units of the encoding and decoding
process, and for each source block all symbols are the same size,
typically a few bytes long.  The atomic operation performed on symbols
for both encoding and decoding is the exclusive-or operation.


A pre-coding step is used to produce L-K redundant symbols from the K
source symbols, where L > K, and the combination of the K source symbols
and the L-K redundant symbols form the L pre-coding symbols.  Section
2.2 describes how the pre-coding symbols are generated from the source
symbols.


Each encoding packet contains a Encoding Symbol ID (ESI) and encoding
symbols.  The ESI is used to generate a (d,a,b)-triple for each encoding
symbol carried in the encoding packet using the generators described in
Section 2.3. Then, each (d,a,b)-triple is used to generate the
corresponding encoding symbol from the pre-coding symbols as described
in Section 2.3.3.



2.2.  Pre-coding


The pre-coding step consists of generating redundant symbols from the K
source symbols as follows.  The redundant symbols consist of S LDPC
symbols and H half symbols. Let X be the smallest positive integer such
that X*(X-1) = 2*K.  The value of S is the smallest positive prime
integer that is at least ceil(0.01*K) + X.  The value of H is the
smallest integer such that choose(H,H') >= K + S, where H' = ceil(H/2)
and where choose(i,j) denotes the number of ways j objects can be chosen
from among i objects without repetition.  Then L = K+S+H.  Let the
positions of the pre-coding symbols range from 0 to L-1, where the first
K are the source symbols, the next S are the LDPC symbols, and the final
H are the half symbols.


For i = 0,...,L-1 let C[i] denote the ith pre-coding symbol.  Note that
C[0],..., C[K-1] are the original source symbols.  Initialize all the
redundant symbols C[K],...,C[L-1] to all zeroes.


The S LDPC symbols are defined as follows.





Luby/Shokrollahi                                  Section 2.2.  [Page 8]


INTERNET-DRAFT          Expires: April 2005             October 2004



  * For i = 0,...,K-1 do


      o a = 1 + (floor(i/S) MOD (S-1))


      o b = i MOD S


      o C[K + b] = C[K + b] XOR C[i]


      o b = (b + a) MOD S


      o C[K + b] = C[K + b] XOR C[i]


      o b = (b + a) MOD S


      o C[K + b] = C[K + b] XOR C[i]



The H half symbols are defined as follows.



  * For h = 0,...,H-1 do


      o For i = 0,...,K+S-1 do


          - If bit h of g[i,H'] is equal to 1 then C[h+K+S] = C[h+K+S]
            XOR C[i].



Equivalently, the H half symbols can be defined as follows, which
suggests an efficient implementation:



  * T = C[0].


  * For i = 1,...,K+S-1 do


      o C[Pos1[i,H']+K+S] = C[Pos1[i,H']+K+S] XOR T.


      o C[Pos2[i,H']+K+S] = C[Pos2[i,H']+K+S] XOR T.


      o T = T XOR C[i].


  * For all bit positions h of g[K+S-1,H'] that are equal to 1 do


      o C[h+K+S] = C[h+K+S] XOR T.







Luby/Shokrollahi                                  Section 2.2.  [Page 9]


INTERNET-DRAFT          Expires: April 2005             October 2004



2.3.  Generators


All of the generators described in the following subsections are used in
the generation of encoding symbols.




2.3.1.  Random Generator


The random number generator Rand[X, i, m] is defined as follows, where X
is a 2-byte unsigned integer, i is an unsigned integer and m is a
positive integer and the value produced is an integer between 0 and m-1.
Let X0 be first byte and let X1 the second byte of X.  Let V0 and V1 be
arrays of 256 entries each, where each entry is a random 4-byte unsigned
integer.  Then,



  Rand[X, i, m] = (V0[(X0 + i) MOD 256] XOR V1[(X1 + i) MOD 256]) MOD m




2.3.2.  Degree Generator


The degree generator Deg[v] is defined as follows, where v is an integer
that is at least 0 and less than 2^20 = 1,048,576.



  * In Table 2.3.2, find the index j such that f[j-1] <= v < f[j]


  * Deg[v] = d[j]




j___________f[j]_______d[j]
0          0            --
1          10,241       1
2          491,582      2
3          712,794      3
4          831,695      4
5          948,446      10
6          1,032,189    11
7          1,048,576    40


Table 2.3.2: Defines the degree distribution for encoding symbols








Luby/Shokrollahi                               Section 2.3.2.  [Page 10]


INTERNET-DRAFT          Expires: April 2005             October 2004



2.3.3.  Encoding Symbol Generator


Let L be the number of pre-coding symbols of the source block, let L' be
the smallest prime integer greater than or equal to L, and let C[0],...,
C[L-1] be the pre-coding symbols of the source block.  The encoding
symbol generator Enc[d, a, b] is defined as follows, where d is a
degree, a is between 1 and L'-1 and b is between 0 and L'-1.



  * While (b = L) do b = (b + a) MOD L'


  * Enc[d, a, b] = C[b].


  * For j = 1,...,d-1 do


      o b = (b + a) MOD L'


      o While (b = L) do b = (b + a) MOD L'


      o Enc[d, a, b] = Enc[d, a, b] XOR C[b]




2.4.  Encoding work


The work to produce the LDPC symbols is 3 times the total length in
bytes of the source symbols.  The work to produce the half symbols is
essentially 3 times the total length in bytes of the source symbols.
Thus, the total work for generating the pre-coding is 6 times the total
length in bytes of the source symbols.


>From the degree distribution described in Section 2.3.2 via Table 2.3.2,
it is not hard to see that the work on average to generate encoding
symbols is 4.63 times the total length in bytes of the encoding symbols
generated.




3.  Raptor Decoding of a Source Block



3.1.  Overview


This subsection provides an overview of Raptor decoding of a source
block.  It is assumed that the decoder knows the structure of the source
block it is to decode, including the symbol length and the number K of
symbols in the source block.





Luby/Shokrollahi                                 Section 3.1.  [Page 11]


INTERNET-DRAFT          Expires: April 2005             October 2004



>From the algorithms described in 2.2, the Raptor decoder can calculate
the total number L = K+S+H of pre-coding symbols and determine how they
were generated from the source block to be decoded.  It is assumed that
the received encoding symbols for the source block to be decoded are
passed to the decoder.  Furthermore, for each such encoding symbol it is
assumed that [d,a,b]-triple that was used to compute the encoding symbol
from the pre-coding symbols is passed to the decoder, and this allows
the decoder to use a portion of the encoding algorithm described in
Section 2.3.3 to compute the number and set of pre-coding symbols used
to generate the encoding symbol.


Let N >= K be the number of received encoding symbols for a source block
and let M = S+H+N.  The following M by L bit matrix A can be derived
from the information passed to the decoder for the source block to be
decoded.  Let C be the column vector of the L pre-coding symbols, and
let D be the column vector of M symbols with values known to the
receiver, where the first S+H of the M symbols are zero-valued symbols
that correspond to LDPC and half symbols (these are check symbols for
the LDPC and half symbols, and not the LDPC and half symbols
themselves), and the remaining N of the M symbols are the received
encoding symbols for the source block.  Then, A is the bit matrix that
satisfies A*C = D, where here * denotes matrix multiplication over
GF[2].  In particular, A[i,j] = 1 if  the pre-coding symbol
corresponding to index j is exclusive-or'd into the LDPC, half or
encoding symbol corresponding to index i in the encoding, or if index i
corresponds to a LDPC or half symbol and index j corresponds to the same
LDPC or half symbol.  For all other i and j, A[i,j] = 0.


Decoding a source block is equivalent to decoding C from known A and D.
(This is equivalent to recovering the K source symbols since if they can
be recovered then the other L-K pre-coding symbols can be recomputed.)
It is clear that C can be decoded if and only if the rank of A over
GF[2] is L.


The first step in decoding C is to form a decoding schedule.  In this
step A is converted, using Gaussian elimination (using row operations
and row and column reorderings) and after discarding M - L rows, into
the L by L identity matrix.  The decoding schedule consists of the
sequence of row operations and row and column re-orderings during the
Gaussian elimination process, and only depends on A and not on D.  The
decoding of C from D can take place concurrently with the forming of the
decoding schedule, or the decoding can take place afterwards based on
the decoding schedule.


The correspondence between the decoding schedule and the decoding of C
is as follows.  Let c[0] = 0, c[1] = 1,...,c[L-1] = L-1 and d[0] = 0,
d[1] = 1,...,d[M-1] = M-1 initially.





Luby/Shokrollahi                                 Section 3.1.  [Page 12]


INTERNET-DRAFT          Expires: April 2005             October 2004



  * Each time row i of A is exclusive-ored into row i' in the decoding
    schedule then in the decoding process symbol D[d[i]] is exclusive-
    ored into symbol D[d[i']].


  * Each time row i is exchanged with row i' in the decoding schedule
    then in the decoding process the value of d[i] is exchanged with the
    value of d[i'].


  * Each time column j is exchanged with column j' in the decoding
    schedule then in the decoding process the value of c[j] is exchanged
    with the value of c[j'].



>From this correspondence it is clear that the total number of exclusive-
ors of symbols in the decoding of the source block is the number of row
operations (not exchanges) in the Gaussian elimination. Since A is the
L by L identity matrix after the Gaussian elimination and after
discarding the last M - L rows, it is clear at the end of successful
decoding that the L symbols D[d[0]], D[d[1]],..., D[d[L-1]] are the
values of the L symbols C[c[0]], C[c[1]],..., C[c[L-1]].


The order in which Gaussian elimination is performed to form the
decoding schedule has no bearing on whether or not the decoding is
successful.  However, the speed of the decoding depends heavily on the
order in which Gaussian elimination is performed.  (Furthermore,
maintaining a sparse representation of A is crucial, although this
document does not describe the details of how this is done).  The
remainder of this section focuses on the order in which Gaussian
elimination should be performed.




3.2.  First Phase


The first phase of the Gaussian elimination the matrix A is conceptually
partitioned into submatrices.  The submatrix sizes are parameterized by
non-negative integers i and u which are initialized to 0.  The
submatrices of A are:



  (1) The submatrix I defined by the intersection of the first i rows
      and first i columns.  This is the identity matrix at the end of
      each step in the phase.


  (2) The submatrix defined by the intersection of the first i rows and
      all but the first i columns and last u columns.  All entries of
      this submatrix are zero.





Luby/Shokrollahi                                 Section 3.2.  [Page 13]


INTERNET-DRAFT          Expires: April 2005             October 2004



  (3) The submatrix defined by the intersection of the first i columns
      and all but the first i rows.  All entries of this submatrix are
      zero.


  (4) The submatrix U defined by the intersection of all the rows and
      the last u columns.


  (5) The submatrix X formed by the intersection of all but the first i
      columns and the last u columns and all but the first i rows.



Figure 3.2 illustrates the submatrices of A.  At the beginning of the
first phase X = A.  In each step, a row of A is chosen. The following
graph defined by the structure of X is used in determining which row of
A is chosen.  The columns that intersect X are the nodes in the graph,
and the rows that have exactly 2 ones in X are the edges of the graph
that connect the two columns (nodes) in the positions of the two ones.
A component in this graph is a maximal set of nodes (columns) and edges
(rows) such that there is a path between each pair of nodes/edges in the
graph.  The size of a component is the number of nodes (columns) in the
component.



I     0 U
0     X U


Figure 3.2: Submatrices of A in the first phase


There are at most L steps in the first phase.  The phase ends
successfully when i + u = L, i.e.  when X and the all zeroes submatrix
above X have disappeared and A consists of I, the all zeroes submatrix
below I, and U. The phase ends unsuccessfully in decoding failure if at
some step before X disappears there is no non-zero row in X to choose in
that step.  In each step, a row of A is chosen as follows:


Row Choice


  * If all entries of X are zero then no row is chosen and decoding
    fails.


  * Let r be the minimum integer such that at least one row of A has
    exactly r ones in X.


  * If r not= 2 then choose a row with exactly r ones in X with minimum
    original degree among all such rows.


  * If r = 2 then choose any row with exactly 2 ones in X that is part
    of a maximum size component in the graph defined by X.




Luby/Shokrollahi                                 Section 3.2.  [Page 14]


INTERNET-DRAFT          Expires: April 2005             October 2004



After the row is chosen in the step the first row of A that intersects X
is exchanged with the chosen row so that the chosen row is the first row
that intersects X.  The columns of A among those that intersect X are
reordered so that one of the r ones in the chosen row appears in the
first column of X and so that the remaining r-1 ones appear in the last
columns of X.  Then, the chosen row is exclusive-ored into all the other
rows of A below the chosen row that have a one in the first column of X.
Finally, i is incremented by 1 and u is incremented by r-1, which
completes the step.




3.3.  Second Phase


The submatrix U is further partitioned into the first i rows, UU, and
the remaining M - i rows, UL.  Gaussian elimination is performed in the
second phase on UL to either determine that its rank is less than u
(decoding failure) or to convert it into a matrix where the first u rows
is the identity matrix (success of the second phase).  Call this u by u
identity matrix UI.  The M - L rows of A that intersect UL - UI are
discarded. After this phase A has L rows and L columns.




3.4.  Third Phase


After the second phase the only portion of A which needs to be zeroed
out to finish converting A into the L by L  identity matrix is UU.  The
number of rows i of the submatrix UU is generally much larger than the
number of columns u of UU.  To zero out UU efficiently, the following
precomputation matrix UE is computed based on UI in the third phase and
then UE is used in the fourth phase to zero out UU.  The u rows of UI
are partitioned into ceil(u/7) groups of 7 rows each.  Then, for each
group of 7 rows all non-zero combinations of the 7 rows are computed,
resulting in 2^7- 1 = 127 rows (this can be done with 2^7-7-1 = 120
exclusive-ors of rows per group, since the combinations of Hamming
weight one that appear in UI do not need to be recomputed).  Thus, the
resulting precomputation matrix UE has ceil(u/7)*127 rows and u columns.
Note that UE is not formally a part of matrix A, but will be used in the
fourth phase to zero out UU.




3.5.  Fourth Phase


For each of the first i rows of A, for each group of 7 columns in the UU
submatrix of this row, if the set of 7 column entries in UU are not all
zero then the row of the precomputation matrix UE that matches the




Luby/Shokrollahi                                 Section 3.5.  [Page 15]


INTERNET-DRAFT          Expires: April 2005             October 2004



pattern in the 7 columns is exclusive-ored into the row, thus zeroing
out those 7 columns in the row at the cost of exclusive-oring one row of
UE into the row.


After this phase A is the L by L identity matrix and a complete decoding
schedule has been successfully formed.  Then, as explained at the
beginning of Section 3.1, the corresponding decoding consisting of
exclusive-oring known encoding symbols can be executed to recover the
source block based on the decoding schedule.


Only rows corresponding to recovering a source symbol need be considered
in this phase if only the source symbols and not all the pre-coding
symbols are to be decoded.  However, for the systematic Raptor codes
described in Section 5 all of the pre-coding symbols need be recovered.




4.  Raptor Object Delivery


This section specifies how to use the Raptor code specified in Sections
2 and 3 for reliable delivery of an object to many receivers in an IP
multicast network.  This could also be used for delivery using other
types of networks, e.g., unicast networks, but this is outside the scope
of this document.  This version of Raptor is a non-systematic code.


This section also defines a new Fully-Specified FEC scheme (as defined
in RFC3452 [4]). with a corresponding new FEC Encoding ID (with an as
yet undefined number) and the corresponding FEC Object Transmission
Information and FEC Payload ID format.




4.1.  Motivation


The basic properties of Raptor for reliable object delivery are that,
for any packet loss conditions, for delivery of objects of any relevant
size: (a) reception overhead of each individual receiver is minimal; (b)
the total transmission time and bandwidth needed to deliver objects to
any number of receivers is minimal.


In the solution described in this document the amount of working memory
needed for decoding can be much smaller than the object size and still
provide the above properties, and the amount of computation needed to
encode and decode is minimal.


Raptor is a fountain code (as for example defined in [10], called
expandable codes in [14]), i.e., as many encoding packets as needed can
be generated on-the-fly, each containing unique encoding symbols that




Luby/Shokrollahi                                 Section 4.1.  [Page 16]


INTERNET-DRAFT          Expires: April 2005             October 2004



are equally useful for recovering a object.  There are many advantages
to using fountain codes versus other types of FEC codes, some of which
are described in [9], [10] and [11]. One advantage is that, regardless
of packet loss conditions and receiver availability, fountain codes
minimize the number of encoding packets each receiver needs to receive
to reconstruct a object.  This is true even under harsh packet loss
conditions and when for example mobile receivers are only intermittently
turned-on or available over a long object delivery session.


One advantage of the fountain property of Raptor is that it makes it
possible to decide during the session how many encoding packets to
generate and send.  This can be useful if for example there is feedback
from receivers indicating whether or not they received enough encoding
packets to recover a object. When packet loss conditions are less severe
than expected the transmission can be terminated early. When packet loss
conditions are more severe than expected or receivers are unavailable
more often than expected the transmission can be seamlessly extended.


Alternatively, if a fixed duration object delivery session is used and
after the conclusion of the initial session feedback is received which
indicates that many receivers have not yet received enough packets to
recover the object then it would be advantageous to schedule a repair
session. For example, the scheduled duration of the initial session can
be short, assuming optimistically small losses, and then the duration
can be dynamically extended only if required.  This flexibility and
ability to optimize transmission bandwidth usage is simple with a
fountain code.




4.2.  Source blocks and sub-blocks


The maximum source block size B in bytes is recommended to be 4 MB in
this document.  Thus, objects that are larger than B bytes in size are
partitioned into more than one source block.  Limiting the source block
size to at most B bytes in size ensures that the encoding length of a
source block can potentially be many times larger than the source block,
and thus object delivery using this specification can handle very high
packet loss conditions.


The maximum block size W in bytes that can be decoded in working memory
is recommended to be 256 KB in this document.  Thus, source blocks that
are larger than W bytes in size are partitioned into N > 1 sub-blocks,
and the Raptor decoder decodes one sub-block at a time. Each sub-block
consists of the same number K of sub-symbols, where each sub-symbol is T
bytes long.  Then, each source symbol of the source block is T*N bytes
long, and consists of the concatenation of exactly one sub-symbol from
each of the N sub-blocks.  Figure 4.2 shows a source block placed into a




Luby/Shokrollahi                                 Section 4.2.  [Page 17]


INTERNET-DRAFT          Expires: April 2005             October 2004



two dimensional array, where each entry is a T-byte sub-symbol, each row
is a sub-block and each column is a source symbol.  The number shown in
each sub-symbol entry indicates their original order within the source
block.  For example, the sub-symbol numbered K contains bytes T*K
through T*(K+1)-1 of the source block.  Thus, the first K sub-symbols of
the source block numbered 0 to K-1 form the first sub-block, the next K
sub-symbols of the source block numbered K to 2*K-1 form the second sub-
block, etc.  Then, source symbol i is the concatenation of the ith sub-
symbol from each of the sub-blocks, which corresponds to the sub-symbols
of the source block numbered i, K+i, 2*K+i,..., (N-1)*K+i.



0          1    2       ...   ...   ... ...     K-1
K          K+1  K+2     ...   ...   ... ...     2*K-1
2*K      2*K+1 2*K+2 ...   ...   ...    ...     3*K-1
(N-1)*K ...     ...     ...   ...   ... ...     N*K-1


Figure 4.2: Source symbols from sub-symbols structure


Encoding symbols are generated from the source symbols composed of sub-
symbols,and thus the size of an encoding symbol is T*N bytes consisting
of N encoding sub-symbols each of size T bytes.




4.3.  Session and packet information


The overall structure of the FEC Object Transmission Information and the
FEC Payload ID are both defined in [4]. The receiver needs to receive
the specific FEC Object Transmission Information in a session
description (for example, carried in a FLUTE FDT as described in [8])
generally before starting to receive packets for a object to determine
some of the critical parameters needed to decode the object.  The FEC
Payload ID is carried in each packet to identify the encoding symbols
carried in that packet.




4.3.1.  FEC Object Transmission Information


Besides the FEC Encoding ID, the FEC Object Transmission Information
includes:



  * The object size F in bytes


  * The payload size P of each packet in bytes





Luby/Shokrollahi                               Section 4.3.1.  [Page 18]


INTERNET-DRAFT          Expires: April 2005             October 2004



  * The maximum source block size B in bytes


  * The maximum working memory size W in bytes that indicates the
    largest sub-block that can be decoded in receiver working memory.



A suggested value of P could be for example 512 bytes for object
delivery over multicast cellular networks, or 1024 bytes for other
multicast networks.  In general P must be equal to G*N*T, where G is
defined below.


A suggested value of B is 4 MB. This means that objects that are at
most 4 MB will consist of one source block, and that objects larger than
4 MB will be partitioned into more than one source block.  The method
used to partition a object larger than 4 MB into source blocks is
described in [8]. In general B must be at least W.


A suggested value of the maximum size W of a sub-block that can be
decoded in working memory is 256 KB for example for delivery of objects
to cellular devices.  Other values of W could also be suitable, e.g. W =
512 KB or W = 128 KB.  How a source block is partitioned into sub-blocks
depends on whether the source block size is smaller or larger than
working memory W, and is described below for the suggested values of B
and W.


For the suggested values the algorithms described below compute for each
source block:



  * The number G of encoding symbols for the source block carried in
    each encoding packet


  * The number K of source symbols in the source block


  * The number N of sub-blocks into which the source block is
    partitioned


  * The sub-symbol size T in bytes for the sub-blocks.



The symbol size is thus N*T bytes for the source block.




4.3.2.  FEC Payload ID


The FEC Payload ID is shown in Figure 4.3.2 and consists of a two-byte
Source Block Number (SBN) and a two-byte Encoding Symbol ID (ESI), and




Luby/Shokrollahi                               Section 4.3.2.  [Page 19]


INTERNET-DRAFT          Expires: April 2005             October 2004



thus the overall FEC Payload ID is 4 bytes long.  This allows sending of
objects of size up to P*2^32 bytes.  The FEC Payload ID is included in
the header of each packet carrying encoding symbols in its payload to
identify how the encoding symbols are generated from the source block.



  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 (SBN) |  Encoding Symbol ID (ESI)    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Figure 4.3.2: FEC Payload ID


A longer FEC Payload ID could be used for other services.  For example
with an FEC Payload ID that consists of a four-byte SBN and a four-byte
ESI, much larger source blocks can be used and much larger objects can
be sent.  would require some minor modifications to how the ESI is used
to generate encoding symbols.




4.4.  Encoding an object


All the examples in the subsequent subsections used the suggested
parameter settings of P = 512 bytes, W = 256 KB and B = 4 MB.




4.4.1.  Smaller objects


When the object size F <= W the object consists of a single source block
that in turn consists of one sub-block, i.e., Z = N = 1.  The number K
of source symbols in the object is computed as ceil(F/T).  For P = 512
bytes and W = 256 KB, the number G of encoding symbols placed into each
encoding packet and the symbol size T is determined by Table 4.4.1 based
on the object size F.  In general, for other values of P and W, it is
recommended that G and T are set in such a way such that K is at least
1,000 and T is as large as possible.


The SBN is set to 0 in the FEC Payload ID of each packet and the ESI is
set to a two-byte value X, where the value of X should be different in
each encoding packet.  The ESI is used to uniquely identify the encoding
symbols generated from the L pre-coding symbols of a source block that
are placed into a single packet, where the value of L and the pre-coding
symbols are generated as described in Section 2. The sequence of ESI
values for the packets sent for the object is generated as follows.





Luby/Shokrollahi                               Section 4.4.1.  [Page 20]


INTERNET-DRAFT          Expires: April 2005             October 2004



Generating ESI values


  * Let Q be the largest prime integer such that Q = floor(2^16/G)


  * Let A be an integer such that 0 < A < Q


  * Let B be an integer such that 0 <= B < Q


  * Let N be the number of packets to be sent in the session


  * X = B


  * For i = 0,...,N-1 do


      o Use X as the ESI for the next packet


      o X = (X + A) MOD Q



If additional packets for the object are to be send at a later time then
the ESI's for the packets sent in that session can be generated using
the above algorithm using the same value for A and using the value of X
at the end of the first session for the value of B.  For example,
suppose G = 16 (and thus Q = 4,093), A = 1 and B = 0.  If 150 packets
are sent in the first session then their ESI values are 0, 1, ..., 149,
and at the end X  = 150.  Suppose 50 additional packets are to be sent
in the MBMS repair session.  Then A = 1 and B = 150, and the ESI values
are 150, 151, ..., 199 and at the end X = 200.


The values of the encoding symbols placed into the packet with ESI X are
computed as follows:


Generating encoding symbols E0[X],..., EG-1[X]



  * v = Rand[X, 0, 2^20]


  * Y = (X*G) MOD 2^16


  * Repeat the following for i = 0,...,G-1


      o d = Deg[v]


      o a = 1 + Rand[Y, 1, L'-1]


      o b = Rand[Y, 2, L']






Luby/Shokrollahi                               Section 4.4.1.  [Page 21]


INTERNET-DRAFT          Expires: April 2005             October 2004



      o Ei[X] = Enc[d, a, b]


      o v = (v + 2^20/G) MOD 2^20


      o Y = (Y + 1) MOD 2^16



Because of the way ESIs are generated for packets in different sessions,
it is easy to see that all of the ESIs in the different sessions are all
distinct and all the Y values used to generate the (d, a, b)-triple for
each encoding symbol are all distinct as long as the total number of
packets generated is at most Q.



F range_________________N_____G_____T___________K range
512 B < F = 64 KB       1     16    32 bytes    16 = K = 2,048
64 KB < F = 128 KB      1     8 64 bytes        1,024 < K = 2,048
128 KB < F = 256 KB     1     4 128 bytes       1,024 < K = 2,048


Table 4.4.1: Source block parameters for small objects when P = 512
bytes and W = 256 KB



EXAMPLE 1
Object size F = 50 KB
Number of object packets = 100
Number of source blocks Z = 1
Number of sub-blocks N = 1
Number of encoding symbols per encoding packet G = 16
Symbol size T = 32 bytes
Number of source symbols K = 1,600



EXAMPLE 2
Object size F = 100 KB bytes
Number of object packets = 200
Number of source blocks Z = 1
Number of sub-blocks N = 1
Number of encoding symbols per encoding packet G = 8
Symbol size T = 64 bytes
Number of source symbols K = 1,600











Luby/Shokrollahi                               Section 4.4.1.  [Page 22]


INTERNET-DRAFT          Expires: April 2005             October 2004



EXAMPLE 3
Object size F = 200 KB bytes
Number of object packets = 400
Number of source blocks Z = 1
Number of sub-blocks N = 1
Number of encoding symbols per encoding packet G = 4
Symbol size T = 128 bytes
Number of source symbols K = 1,600




4.4.2.  Larger objects


When the object size F is more than W but at most B then the object
consists of a single source block that is partitioned into N sub-blocks,
where the length of each sub-block is greater than W/2 but at most W.
The value of N is the smallest power of two such that N*W >= F. The
size I of each sub-block is computed as ceil(F/N), and the number K of
sub-symbols per sub-block is computed as ceil(I/T).  Table 4.4.2 is used
to determine the sub-block parameters based on the object size F when P
= 512 bytes, W = 256 KB and B = 4 MB.  In general, for other values of W
and B, it is recommended that G and T are powers of two and set in such
a way such that K is at least 2,000 and T is as large as possible.


The SBN is set to 0 in the FEC Payload ID of each packet and the ESI is
set to a two-byte value X, where the value of X should be different in
each encoding packet.  The source block is partitioned into N sub-
blocks, and each encoding packet contains G encoding symbols generated
from the source block consisting of the N sub-blocks, where the values
of N and G are obtained from Table 4.4.2. The ESI values for the packets
and the values of the G encoding symbols E0[X],..., EG-1[X]  placed into
the packet with ESI X are computed as described in Section 4.4.1.



F range_________________N_____G_____T___________K range
256 KB < F = 512 KB     2     4 64 bytes        2,048 < K = 4,096
512 KB < F = 1 MB       4     2 64 bytes        2,048 < K = 4,096
1 MB < F = 2 MB         8     1 64 bytes        2,048 < K = 4,096
2 MB < F = 4 MB         16    1 32 bytes        4,096 < K = 8,192


Table 4.4.2: Source block parameters for large objects when P = 512
bytes, W = 256 KB and B = 4 MB










Luby/Shokrollahi                               Section 4.4.2.  [Page 23]


INTERNET-DRAFT          Expires: April 2005             October 2004



EXAMPLE 4
Object size F = 400 KB
Number of object packets = 800
Number of source blocks Z = 1
Number of sub-blocks N = 2
Size of a sub-block in bytes I = 200 KB
Number of encoding symbols per encoding packet G = 4
Sub-symbol size T = 64 bytes
Symbol size N*T = 128 bytes
Number of source symbols per source block K = 3,200



EXAMPLE 5
Object size F = 800 KB
Number of object packets = 1,600
Number of source blocks Z = 1
Number of sub-blocks N = 4
Size of a sub-block in bytes I = 200 KB
Number of encoding symbols per encoding packet G = 2
Sub-symbol size T = 64 bytes
Symbol size N*T = 256 bytes
Number of source symbols per source block K = 3,200



EXAMPLE 6
Object size F = 1.6 MB
Number of object packets = 3,200
Number of source blocks Z = 1
Number of sub-blocks N = 8
Size of a sub-block in bytes I = 200 KB
Number of encoding symbols per encoding packet G = 1
Sub-symbol size T = 64 bytes
Symbol size N*T = 512 bytes
Number of source symbols per source block K = 3,200



EXAMPLE 7
Object size F = 3 MB
Number of object packets = 6,144
Number of source blocks Z = 1
Number of sub-blocks N = 16
Size of a sub-block in bytes I = 192 KB
Number of encoding symbols per encoding packet G = 1
Sub-symbol size T = 32 bytes
Symbol size N*T = 512 bytes
Number of source symbols per source block K = 6,144






Luby/Shokrollahi                               Section 4.4.2.  [Page 24]


INTERNET-DRAFT          Expires: April 2005             October 2004



4.4.3.  Large objects


When the object size F is more than B then the object is partitioned
into more than one source block using the Algorithm for Computing Source
Block Structure described in Section 5.1.2.3 of FLUTE [8]. The inputs to
that algorithm are:



  * The maximum number of source symbols per source block.  This is set
    to the ratio of B/P, since there is one symbol per packet.  If B = 4
    MB and P = 512 bytes, the maximum number of source symbols per
    source block is 8,192.


  * The transfer length in bytes.  This is set to the object size F.


  * The symbol length in bytes. This is set to P since there is one
    symbol per packet.



The output of the algorithm is the number Z of source blocks, and the
number and lengths of source symbols in each of the Z source blocks
(with possibly the last symbol of the last source block logically filled
out with zeroes to a full length symbol).


Each encoding packet contains one encoding symbol generated from one of
the Z source blocks.  The SBN of each packet is set to the number of the
source block from which the encoding symbol carried in the payload of
the packet is generated, and thus the SBN is between 0 and Z-1. The ESI
values for each source block are generated using the algorithm described
in Section 4.4.1 independently for each source block, and thus the same
ESI values are used for different source blocks of the same object.  The
method for generating an encoding symbol from a source block is as
described in Section 4.4.2, where the source block is substituted for
the object in that description.



EXAMPLE 8
Object size F = 9 MB
Number of object packets = 18,432
Number of source blocks Z = 3
Size of source blocks = 3 MB (all equal size in this example)
For each of the 3 source blocks, the rest of the construction is
the same as for Example 6 where the source block is substituted
for the object in that description.








Luby/Shokrollahi                               Section 4.4.3.  [Page 25]


INTERNET-DRAFT          Expires: April 2005             October 2004



4.4.4.  Encoding work per object


The encoding work per object can be derived from Section 2, i.e., the
work to generate the pre-coding for a object is 6*F and the work on
average to generate packet payloads containing encoding symbols for a
object is 4.63 times the total length in bytes of the generated packet
payloads.




4.5.  Decoding an object


Just like for encoding, there are three cases of how to decide how to
recover the object, depending on the object size F. When F <= W then the
object is decoded as a single source block.  Each received encoding
packet contains an ESI and one or more encoding symbols.  The ESI is
used to reconstruct how each encoding symbol contained in the encoding
packet was generated, and then when enough encoding packets have arrived
the object is decoded.


When B >= F > W then the object consists of a single source block that
is partitioned into multiple sub-blocks that are decoded in a
coordinated way.  As each encoding packet arrives, the ESI is saved, and
each encoding sub-symbol corresponding to a sub-block is saved in a
temporary object dedicated to that sub-block.  Then, based on the
received ESIs the decoding schedule can be formed based on the
algorithms described in Section 3, and then that decoding schedule is
applied to the encoding sub-symbols for each sub-block in sequence,
decoding each sub-block within the limits of the working memory
resources based on the algorithms described in Section 3, where the sub-
block is substituted for the source block and the encoding sub-symbols
are substituted for the encoding symbols in that description.



When F >= B then the object consists of multiple source blocks that are
in turn partitioned into multiple sub-blocks.  Each source block is
handled independently of the other source blocks, i.e., all the ESIs for
a source block are saved in a temporary object dedicated to that source
block, and each encoding sub-symbol corresponding to a sub-block within
the source block are saved in a temporary object dedicated to that sub-
block within the source block.  Then, for each source block in turn,
based on the received ESIs for that source block the decoding schedule
can be formed, and then that decoding schedule is applied to the
encoding sub-symbols for each sub-block in sequence, decoding each sub-
block within the limits of the working memory resources.


The decoding memory requirements for Raptor are slightly more than the
sub-block length.  For example, a 100 KB object that is encoded and




Luby/Shokrollahi                                 Section 4.5.  [Page 26]


INTERNET-DRAFT          Expires: April 2005             October 2004



decoded as a single source block takes slightly more than 100 KB of
working memory for the decoding, whereas a 3 MB object is partitioned
into 16 sub-blocks of 192 KB each, and thus the working memory needed to
decode is slightly more than 192 KB.  Decoding can be performed in
place, i.e., a sub-block can be recovered in place using the same
working memory that contains the encoding sub-symbols for the sub-block
just before it is decoded.




4.5.1.  Decoding work per object


The decoding work per object depends slightly on the reception overhead,
i.e., the more packets received for an object the less the total work it
takes to decode the object.  For all object sizes the average decoding
workload per object is around 10 when the reception overhead is 0.02,
and drops to around 8 when the reception overhead is 0.04, where the
decoding workload is the decoding work divided by the number of bytes in
the object, and thus the decoding workload is the number of bytes that
are exclusive-ored on average to decode each byte of the object. The
decoding work per object is independent of the amount of packet loss and
packet loss patterns.


Since the sub-symbols that are exclusive-ored in the decoding generally
are many bytes long (sizes ranging from 32 bytes to 128 bytes depending
on the object size), and since a CPU can generally exclusive-or together
several bytes in a single operation, the exclusive-oring can be
pipelined in such a way that decoding is very efficient.




4.5.2.  Decoding failure probability


The decoding failure probability d for a given reception overhead e is
the probability the decoding process fails to recover the source block
when the number of received encoding symbols is (1+e)*K, where K is the
number of source symbols in the source block.  For all values of K that
are at least approximately 1,000 the decoding failure probability is at
most around d = 10^-3 when the reception overhead is e = 0.01 and the
decoding failure probability is at most around d = 10^-6 when the
reception overhead is e = 0.02. The decoding failure probability
continues to drop off as the reception overhead increases, but at a much
slower rate.


These results were obtained by running the decoder many times on
different packet sequences until several decoding failures were observed
and then reporting the average number of times decoding failed. In some
cases this required running the decoder tens of millions of times.




Luby/Shokrollahi                               Section 4.5.2.  [Page 27]


INTERNET-DRAFT          Expires: April 2005             October 2004



Because each encoding packet is generated at random independently of all
other encoding packets, the received encoding packets are random for any
loss pattern of encoding packets that does not depend on their values.
Since packet loss is independent of packet content, the value of d is
independent of packet loss.


There are other versions of Raptor codes with much smaller failure
probabilities, but this is beyond the scope of this document.




5.  Systematic Raptor



5.1.  Overview


The Raptor systematic encoder is used to generate repair symbols from a
source block that consists of K source symbols. The overall strategy
for doing this is as follows.  A first step is to generate systematic
information associated with K.  This systematic information is used to
generate K triples (d[0], a[0], b[0]),..., (d[K-1], a[K-1], b[K-1]) for
the source symbols.


The K source symbol triples are then used to decode L intermediate pre-
coding symbols from the source symbols using the Raptor decoder
described in Section 3. By the way the systematic information is
generated, the K source symbol triples are guaranteed to uniquely decode
the L intermediate pre-coding symbols, i.e., if the K source symbol
triples are used to produce K encoding symbols from the intermediate
pre-coding symbols using the Raptor encoder described in Section 2 then
these encoding symbols are exactly the source symbols.  Furthermore, the
K source symbol triples are generated from the same distribution as
other triples generated by the Raptor encoder, and thus the source
symbols can be thought of as random encoding symbols generated from the
intermediate pre-coding symbols.  The idea is to then use the Raptor
encoder to produce additional random triples and then use the Raptor
encoder to produce other encoding symbols, called repair symbols, from
the intermediate pre-coding symbols using the additional triples.  The
source symbols and the repair symbols are sent to receivers.


If a receiver receives all K of the source symbols then there is no need
for any decoding.  If there is at least one missing source symbol then
from the systematic information associated with K the receiver can
generate the K source symbol triples and the additional triples
corresponding to received repair symbols.  The Raptor decoder can be
used to recover the intermediate pre-coding symbols from any received
combination of source and repair symbols that is slightly more than K
symbols in total using the corresponding triples for the received




Luby/Shokrollahi                                 Section 5.1.  [Page 28]


INTERNET-DRAFT          Expires: April 2005             October 2004



symbols, and then the Raptor encoder can be used to recover the missing
source symbols from the intermediate pre-coding symbols using the
triples for the missing source symbols.




5.2.  Systematic information


The K triples for the source symbols are generated from the systematic
information as described in Section 5.3. How the systematic information
is generated is described in Section 5.6. The systematic information for
each relevant value of K can either be stored or generated as needed at
each receiver.  The systematic information associated with a source
block of K source symbols is:



  * An integer T.


  * Integers A and B such that 0 < A < 65,521 and 0 <= B < 65,521.


  * A list of T integers 0 < M[0] < M[1] < ... < M[T-1] < K+T.



Typically, T can be represented with one byte, while all the other
values can be represented with two bytes.  For example, for K = 1,000,
the value of T is at most 10, so that the description of the systematic
information is at most 25 bytes.  This representation can be further
shortened, e.g., the sequence M[0], ... , M[T-1] could be stored as
successive differences, and the differences typically take one byte.




5.3.  Generating source symbol triples from systematic information


The K source symbol triples (d[0], a[0], b[0]), ... , (d[K-1], a[K-1],
b[K-1]) are generated as follows from the systematic information (T, A,
B, M[0],..., M[T-1]) associated with K. Note that L' is smallest prime
that is at least the number L of intermediate pre-coding symbols.


Generate K triples for source symbols


  * Set i = 0,  j = 0, t = 0, X = B.


  * While i < K do


      o If t < T and j = M[t] then t = t+1






Luby/Shokrollahi                                 Section 5.3.  [Page 29]


INTERNET-DRAFT          Expires: April 2005             October 2004



      o Else


          - d[i] = Deg[Rand[X,0, 2^20]]


          - a[i] = 1 + Rand[X, 1, L'-1]


          - b[i] = Rand[X, 2, L']


          - i = i+1


      o X = (X + A) MOD 65,521


      o j = j + 1



Note that it is not necessary to store T explicitly, since it can be
obtained from the other data.




5.4.  Calculating the intermediate pre-coding symbols


The L intermediate pre-coding symbols are obtained by applying the
Raptor decoder described in Section 3 to the source symbols C[0], C[1],
..., C[K-1] using the decoding schedule calculated from the K source
symbol triples (d[0], a[0], b[0]),..., (d[K-1], a[K-1], b[K-1]).  The
procedure for obtaining the source symbol triples guarantees that the
decoding is successful. The result of this operation is the L
intermediate pre-coding symbols I[0], I[1],..., I[L-1].




5.5.  Work and decoding failure probability


At the sender, the intermediate pre-coding symbols can be calculated
with essentially the same work as a decoding step of the Raptor decoder
described in Section 3. From the degree distribution of the Raptor
encoder described in Section 2, it can be seen that the work to generate
repair symbols from intermediate pre-coding symbols is on average 4.63
times the total length in bytes of generated repair symbols.


At the receiver, there is no work to be done if all the source symbols
are received.  If there is at least one missing source symbol, then the
average work for decoding the intermediate pre-coding symbols from
received source and repair symbols is essentially the same as the
average work for the Raptor decoder described in Section 3. The
additional work to recreate missing source symbols from the intermediate
pre-coding symbols is on average 4.63 times the length in bytes of




Luby/Shokrollahi                                 Section 5.5.  [Page 30]


INTERNET-DRAFT          Expires: April 2005             October 2004



missing source symbols.


The decoding failure probability of the Raptor systematic decoder for a
given reception overhead is the same as for Raptor decoder described in
Section 3.



5.6.  Calculating the systematic information


In the description below o will denote the chosen reception overhead.
We recall the matrix interpretation of the Raptor decoding process as
described in Section 3, and the four phases of the decoding process.  In
that decoding algorithm an elimination process is applied to a matrix A
that is derived from the received symbols, and the pre-coding symbols.
The matrix has N rows corresponding to the N received symbols, and S+H
rows corresponding to the S LDPC and H half symbols.  The systematic
information associated with K is computed as follows:



  (1) Set A = 53,591, B = 10,267


  (2) Compute N = ceil((1 + o)*K)


  (3) Repeat the following until the systematic information is
      generated:


      (a)   X = B


      (b)   Repeat the following for i = 0,...,N-1


          (i)   Y[i] = Rand[X, 0, 2^16].


          (ii)  X = (X+A) MOD 65,521


      (c)   Apply the first phase of the decoding algorithm described in
            Section 3 until the number of rows in the matrix I
            corresponding to received symbols is K-10, or until the
            first phase is finished, whichever is first. Let Y[i1],
            Y[i2], ..., Y[im] denote the Y-values corresponding to these
            rows.


      (d)   If the first phase is not yet finished, i.e., if the matrix
            X has columns, then replace the matrix U by the matrix
            obtained from X and U.


      (e)   In the second phase of the algorithm (elimination of the
            matrix U) use the rows of the matrix corresponding to the
            LDPC and the half-symbols as pivot rows.




Luby/Shokrollahi                                 Section 5.6.  [Page 31]


INTERNET-DRAFT          Expires: April 2005             October 2004



      (f)   If this is not possible, then


          (i)   A = (A*10,267) MOD 65,521


          (ii)  B = X


          (iii) Go to Step (3a).


      (g)   If the pivoting on the LDPC and half symbols is possible in
            Step (3e) then


          (i)   Let Y[im+1],...,Y[iK] denote the Y-values of the pivot
                  rows of U that do not correspond to the LDPC or half
                  symbols.


          (ii)  Set E be the maximum value among i1, i2,..., iK . Set
                  T = E+1-K and compute the T indices among 0,..., E
                  missing from i1, i2, ..., iK, and let these indices in
                  increasing order be M[0], M[1],...,  M[T-1].


      (h)   Return the systematic information (T, A, B, M[0], M[1],...,
            M[T-1]).



The systematic information associated for K can be computed for all
relevant values of K once and for all and packaged with the Raptor
decoder software to receivers.  Alternatively, receivers may calculate
the systematic information using the algorithm described above for
relevant values of K on an as needed basis.  As another alternative, a
mixed strategy can be used, where the systematic information for some
values of K is packaged with the Raptor decoder software and as
systematic information for other values of K is needed the receiver
computes this on the fly, and once computed potentially saved for later
use.  Furthermore, the K source symbol triples for a given value of K
can be saved for reuse with other source blocks once they are computed.




6.  Raptor Systematic Object Delivery


This section specifies how to use the Raptor systematic code specified
in Section 5 for reliable delivery of an object to many receivers in an
IP multicast network.  This could also be used for delivery using other
types of networks, e.g., unicast networks, but this is outside the scope
of this document.


This section also defined a new Fully-Specified FEC scheme (as defined
in RFC3452 [4] and a corresponding new FEC Encoding ID (with an as yet




Luby/Shokrollahi                                   Section 6.  [Page 32]


INTERNET-DRAFT          Expires: April 2005             October 2004



undefined number) and the corresponding FEC Object Transmission
Information and FEC Payload ID format.


The FEC scheme described in this section is almost identical to the FEC
scheme described in Section 4. As described below, the only difference
in encoding is that the sent encoding symbols for a source block consist
of the source symbols of the source block and the repair symbols
generated from the intermediate pre-coding symbols, whch are in turn
generated from teh source symbols using the systematic information.
There are analogous differences in the decoding algorithm.  The overall
properties of this FEC scheme are exactly the same as those for the FEC
scheme defined in Section 4, except that: (a) the encoding and decoding
are both slightly more complex; (b) the original object is sent as part
of the encoding.




6.1.  Session and packet information


The overall structure of the FEC Object Transmission Information and the
FEC Payload ID are both defined in [4]. The receiver needs to receive
the specific FEC Object Transmission Information in a session
description (for example, carried in a FLUTE FDT as described in [8])
generally before starting to receive packets for a object to determine
some of the critical parameters needed to decode the object.  The FEC
Payload ID is carried in each packet to identify the encoding symbols
carried in that packet.




6.1.1.  FEC Object Transmission Information


Besides the FEC Encoding ID, the FEC Object Transmission Information is
the same as for the FEC scheme described in Section 4: the object size F
in bytes; the payload size P of each packet in bytes: the maximum source
block size B in bytes; the maximum working memory size W in bytes that
indicates the largest sub-block that can be decoded in receiver working
memory.



Some suggested values for these parameters, the relationships between
them, and the way parameters G, K, N and T are computed based on them is
all the same as described in Section 4.









Luby/Shokrollahi                               Section 6.1.1.  [Page 33]


INTERNET-DRAFT          Expires: April 2005             October 2004



6.1.2.  FEC Payload ID


The FEC Payload ID is the same as for the FEC scheme described in
Section 4.



6.2.  Encoding an object


All the examples in the subsequent subsections used the suggested
parameter settings of P = 512 bytes, W = 256 KB and B = 4 MB.




6.2.1.  Smaller objects


When the object size F <= W the object consists of a single source block
that in turn consists of one sub-block, i.e., Z = N = 1.


Everything is computed exactly the same way as described in Section
4.4.1, except for how the encoding symbols, i.e., source and repair
symbols, and ESIs are generated.


Each packet sent for the object either contains all source symbols
(source packet) or all repair symbols (repair packet).


Each source packet contains G source symbols, except for perhaps the
last source packet which may be either of shorter length or padded out
to the same length as all other source packets if K is not a multiple of
G.  The source symbols are placed into source packets sequentially,
i.e., the first source packet contains the first G source symbols, the
second source packet contains the next G source symbols, etc.  The ESI
carried in the ith source packet is (i-1)*G, which is the index of the
first source symbol carried in that packet where the indices of the
source symbols are 0,...,K-1.


The K source symbol triples (d[0], a[0], b[0]),..., (d[K-1], a[K-1],
b[K-1]) are generated as described in Section 5.3 from the systematic
information (T, A, B, M[0],..., M[T-1]) associated with K.  Then, the
Raptor decoder described in Section 3 is used to recover the L
intermediate pre-coding symbols from the K source symbols using the K
source symbol triples.


The ESI values placed into the R repair RTP packets are K, K+G, K+2*G,
... , K+(R-1)*G, respectively.  The G repair symbol triples (d[0], a[0],
b[0]),..., (d[G-1], a[G-1], b[G-1]) for the repair symbols placed into a
repair RTP packet with ESI i are computed as follows, and this depends
on T, A, and B, which is a portion of the systematic information
associated with K.




Luby/Shokrollahi                               Section 6.2.1.  [Page 34]


INTERNET-DRAFT          Expires: April 2005             October 2004



Generate G repair symbol triples for repair packet with ESI i


  * X = (B + (i+T)*A)) MOD 65,521


  * v = Rand[X, 0, 2^20]


  * Repeat the following for j = 0,...,G-1


      o d[j] = Deg[v]


      o a[j] = 1 + Rand[X, 1, L'-1]


      o b[j] = Rand[X, 2, L']


      o v = (v + ceil(2^20/G)) MOD 2^20


      o X = (X + A) MOD 65,521



The Raptor encoder described in Section 2 is used to generate the G
repair symbols from the L intermediate pre-coding symbols using the G
triples associated with the repair packet carrying the repair symbols.




6.2.2.  Larger objects


When the object size F is more than W but at most B then the object
consists of a single source block that is partitioned into N sub-blocks,
where the length of each sub-block is greater than W/2 but at most W.


Everything is computed exactly the same way as described in Section
4.4.2, except that Section 6.2.1 is used instead of Section 4.4.1.



6.2.3.  Large objects


When the object size F is more than B then the object is partitioned
into more than one source block using the Algorithm for Computing Source
Block Structure described in Section 5.1.2.3 of FLUTE [8].  Everything
is computed exactly the same way as described in Section 4.4.3, except
that Section 6.2.1 is used instead of Section 4.4.1 and Section 6.2.2 is
used instead of Section 4.4.2.









Luby/Shokrollahi                               Section 6.2.3.  [Page 35]


INTERNET-DRAFT          Expires: April 2005             October 2004



6.3.  Decoding an object


Just like for encoding, there are three cases of how to decide how to
recover the object, depending on the object size F. When F <= W then the
object is decoded as a single source block.  Each received encoding
packet contains an ESI and one or more encoding symbols.  The ESI is
used to reconstruct how each encoding symbol contained in the encoding
packet was generated, and then when enough encoding packets have arrived
the object is decoded.


Decoding is performed on a sub-block by sub-block basis.  A decoding
schedule is created based on received ESIs for a source block, and then
that same decoding schedule can be used to decode all sub-blocks of the
source block.  Each sub-block is decoded using the algorithms described
in Section 3, where the sub-block is substituted for the source block
and the encoding sub-symbols are substituted for the encoding symbols in
that description.


Decoding of each source block works as follows. If no source symbols
are missing then no decoding is necessary.  If some source symbols are
missing then it is checked to see if enough repair symbols have been
received to recover the missing source symbols. If so, it decodes the
missing source symbols as follows:



  * From the systematic information (T, A, B, M[0],..., M[T-1])
    associated with K, generate the K source symbol triples using the
    algorithm in Section 5.3.


  * Determine which source symbols have been received.


  * From the ESIs in received repair packets, generate the triples for
    the received repair symbols using the algorithm in Section 6.2.1.


  * Use the Raptor decoder described in Section 3 to recover the L
    intermediate pre-coding symbols from the received source symbols and
    repair symbols using their corresponding triples.


  * Use the Raptor encoder described in Section 2 and the triples for
    the missing source symbols to recover the missing source symbols
    from the L intermediate pre-coding symbols.




7.  Security Considerations


The security considerations for this document are the same as they are
for RFC 3452 [4].




Luby/Shokrollahi                                   Section 7.  [Page 36]


INTERNET-DRAFT          Expires: April 2005             October 2004



8.  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 RFC 3452 [4].  This document assigns the
Fully-Specified FEC Encoding ID X under the ietf:rmt:fec:encoding name-
space to "Raptor object".  The FEC Payload ID format and corresponding
FEC Object Transmission Information associated with FEC Encoding ID X is
described in Section 4.3, and the corresponding FEC scheme is described
in Section 4 of this document.


This document assigns the Fully-Specified FEC Encoding ID Y under the
ietf:rmt:fec:encoding name-space to "Raptor systematic object". The FEC
Payload ID format and corresponding FEC Object Transmission Information
associated with FEC Encoding ID Y is described in Section 6.1, and the
corresponding FEC scheme is described in Section 6 of this document.




9.  Intellectual Property


Digital Fountain does have intellectual property rights associated with
the technology described in this document, and intends to provide a full
IPR statement specific to this document to the IETF that will satisfy
the requirements of the IETF.




10.  Normative References



[1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, October 1996.


[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.


[3] Kermode, R., Vicisano, L., ``Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol Instantiation
documents'', RFC 3269, April 2002.


[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J.
Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452,
December 2002.


[5] Luby, M. and Vicisano, L., "Compact Forward Error Correction (FEC)
Schemes", RFC 3695, February 2004.





Luby/Shokrollahi                                  Section 10.  [Page 37]


INTERNET-DRAFT          Expires: April 2005             October 2004



[6] Mankin, A., Romanow, A., Bradner, S., Paxson V., "IETF Criteria for
Evaluating Reliable Multicast Transport and Application Protocols", RFC
2357, June 1998.


[7] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.,
Luby, M., "Reliable Multicast Transport Building Blocks for One-to-Many
Bulk-Data Transfer", RFC 3048, January 2001.


[8] T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, ''FLUTE - File
Delivery over Unidirectional Transport'', IETF RMT working group, RFC
3926, October 2004




11.  Informative References



[9] M. Luby. ''LT Codes'', Proceedings of The 43rd Annual IEEE Symposium
on Foundations of Computer Science, November 16-19 2002, pp. 271-282.


[10] A. Shokrollahi, ''Raptor Codes'', Digital Fountain Technical
Report, DF2003-06-001


[11] J. Byers, M. Luby, M. Mitzenmacher, ''A Digital Fountain Approach
to Asynchronous Reliable Multicast'', IEEE J. on Selected Areas in
Communications, Special Issue on Network Support for Multicast
Communication, Vol. 20, No. 8, October 2002, pp. 1528 - 1540


[12] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J.  Crowcroft,
"Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450
December 2002.


[13] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J.
Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451
December 2002.


[14] 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.




12.  Authors' Addresses


   Michael Luby
   luby@digitalfountain.com
   Digital Fountain, Inc.
   39141 Civic Center Drive




Luby/Shokrollahi                                  Section 12.  [Page 38]


INTERNET-DRAFT          Expires: April 2005             October 2004



   Suite 300
   Fremont, CA  94538
   U.S.A.


   M. Amin Shokrollahi
   amin.sholrollahi@epfl.ch
   Laboratory of Algorithms
   Laboratory of Algorithmic Mathematics
   EPFL
   IC-IIF-ALGO
   PSE-A
   1015 Lausanne
   Switzerland







































Luby/Shokrollahi                                  Section 12.  [Page 39]


INTERNET-DRAFT          Expires: April 2005             October 2004



13.  Full Copyright Statement


Copyright (C) The Internet Society (2004).


This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors retain
all their rights.


This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





































Luby/Shokrollahi                                  Section 13.  [Page 40]


INTERNET-DRAFT          Expires: April 2005             October 2004






















































Luby/Shokrollahi                                  Section 13.  [Page 41]