RMT V. Roca
Internet-Draft A. Roumy
Intended status: Experimental Protocol INRIA
Expires: January 05, 2012 B. Sayadi
Alcatel-Lucent, Bell Labs
July 04, 2011

The Generalized Object Encoding (GOE) Approach for the Forward Erasure Correction (FEC) Protection of Objects and its Application to Reed-Solomon Codes over GF(2^^8)

Abstract

This document describes a Generalized Object Encoding (GOE) approach for the protection of one or multiple objects, using one or several FEC schemes, in the context of a Content Delivery Protocol (CDP) like FLUTE/ALC, FCAST/ALC or FCAST/NORM. In RFC5052, the encoding process is determined by the object (e.g., file) boundaries, i.e., the same code is applied to the whole object that has been submitted to the CDP by the user. The GOE approach instead decouples the definition of source blocks that are FEC encoded from the natural object boundaries. More precisely, either different portions of a given object can be protected with different FEC codes (i.e., portions of different nature and/or with different code rates), with a possible overlapping, or at the opposite, different consecutive objects can be protected globally through a single FEC encoding. If a GOE FEC Scheme defines how to create and process repair packets using the GOE approach, source objects must be encoded with a standard No-Code FEC Scheme. Therefore the same flow of source packets can be shared by different flows of repair packets, using different systematic GOE FEC schemes. An additional benefit is that the GOE approach is backward compliant since the source packets can be processed by receivers that do not support any GOE FEC scheme by simply discarding the repair packets. The present document first of all introduces the GOE approach. It then defines the GOE Reed-Solomon FEC Scheme for the particular case of Reed-Solomon codes over GF(2^^8) and no encoding symbol group, the GOE equivalent to FEC Encoding ID 5 defined in RFC5510.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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 as "work in progress."

This Internet-Draft will expire on January 05, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

The use of Forward Error Correction (FEC) codes is a classic solution to improve the reliability of unicast, multicast and broadcast Content Delivery Protocols (CDP) and applications [RFC3453]. The [RFC5052] document describes a generic framework to use FEC schemes with objects (e.g., files) delivery applications based on the ALC [RFC5775] and NORM [RFC5740] reliable multicast transport protocols.

More specifically, the [RFC5053] (Raptor) and [RFC5170] (LDPC-Staircase) FEC schemes introduce erasure codes based on sparse parity check matrices for object delivery protocols like ALC and NORM. Similarly, the [RFC5510] document introduces Reed-Solomon codes based on Vandermonde matrices for the same object delivery protocols.

The way these FEC schemes is used leads to two limitations. First of all, [RFC5052] defines an approach where the same FEC encoding is applied to all the blocks of a given object, i.e., the whole object is encoded using the same FEC scheme, with the same target code rate, resulting in an equivalent protection. This approach may not suit situations where some subsets of an object deserve a higher erasure protection than the others.

A second limitation is associated to the protection of a large set of small objects. [RFC5052] defines an approach where each object is protected individually. This feature limits the robustness of their delivery: since there is a small number of source and repair packets for a given small object, a significant number of these packets may be erased thereby preventing this object to be decoded at a receiver. For instance, if the source and repair packets of a given object are transmitted in sequence (which may not be the best strategy), a packet erasure burst will significantly impact transmission robustness. Other transmission ordering strategies (e.g., with long packet interleavings or random ordering strategies) can reduce the impacts of packet erasure bursts, but they do not solve the fundamental problem of the protection of small objects. On the opposite a global FEC protection of all the objects of this set, using a single FEC encoding (when possible), provides optimal transmission robustness, since all the objects can be decoded as long as the erasure rate remains lower than the protection brought by the FEC code rate (we assume an ideal (MDS) FEC code is used).

In order to mitigate the above limitations, a better approach consists in decoupling FEC protection from the natural object boundaries. This is the goal of the Generalized Object Encoding (GOE) approach defined in the present document. The GOE approach is independent of the nature of the FEC code, in the sense that the general mechanisms it defines are not restricted to a single type of FEC code. On the opposite, the GOE approach can be used associated to any of the existing FEC schemes, re-using their code definition. However a new FEC Encoding ID value, a new FEC Object Transmission Information (FEC OTI) and a new FEC Payload ID (FPI) must be defined in order to accommodate the GOE specifics. This means that a dedicated FEC Scheme must be defined, for instance for Reed-Solomon codes (re-using the [RFC5510] code definition) and for LDPC-Staircase codes (re-using the [RFC5170] code definition).

The present document, in addition to presenting the GOE approach, defines the GOE Reed-Solomon FEC Scheme for the particular case of Reed-Solomon codes over GF(2^^8) and no encoding symbol group, the GOE equivalent to FEC Encoding ID 5 defined in [RFC5510]. Similar documents are expected to specify GOE equivalents to other FEC schemes.

2. Terminology

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

2.1. Definitions, Notations and Abbreviations

2.1.1. Definitions

This document uses the following terms and definitions. Some of them are FEC scheme specific and are in line with [RFC5052]:

Source Packet:
a data packet containing only source symbols, that is sent over the packet erasure channel. Most of the time a source packet will contain a single source symbol.
Repair Packet:
a data packet containing only repair symbols, that is sent over the packet erasure channel. Most of the time a repair packet will contain a single repair symbol.
Packet Erasure Channel:
a communication path where packets are either dropped (e.g., by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical layer codes) or received. When a packet is received, it is assumed that this packet is not corrupted.
Systematic code:
FEC code in which the source symbols are part of the encoding symbols. The Reed-Solomon codes introduced in this document are systematic.
Code rate:
the k/n ratio, i.e., the ratio between the number of source symbols and the number of encoding symbols. By definition, the code rate is such that: 0 < code rate ≤ 1. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process.
Object:
the object (e.g., file) submitted to the CDP by the user.
Generalized Object:
a group of consecutive source symbols, that belong to one or several objects (as defined above) and that are considered together for the purpose of a GOE scheme. Generalized objects may be a subset of a given object or at the opposite encompass several objects. The key point when defining generalized objects is that all the source symbols of a generalized object require an equal erasure protection.
Source symbol:
unit of data used during the encoding process. In this specification, there is always one source symbol per ADU.
Encoding symbol:
unit of data generated by the encoding process. With systematic codes, source symbols are part of the encoding symbols.
Repair symbol:
encoding symbol that is not a source symbol.
Source block:
a block of k source symbols that are considered together for the encoding.

2.1.2. Notations

This document uses the following notations:

k
denotes the number of source symbols in a source block.
n
denotes the number of encoding symbols generated for a source block.
E
denotes the encoding symbol length in bytes.
NO
denotes the number of objects to be considered.
NGO
denotes the number of generalized objects to be considered.

2.1.3. Abbreviations

This document uses the following abbreviations:

ADU
stands for Application Data Unit.
TOI
stands for Transmission Object Identifier.
SBN
stands for Source Block Number, i.e., a block identifier.
ESI
stands for Encoding Symbol ID.
FEC
stands for Forward Error (or Erasure) Correction code.
LDPC
stands for Low Density Parity Check.
RS
stands for Reed-Solomon.
MDS
stands for Maximum Distance Separable code.
GO
stands for Generalized Object.
UEP
stands for Unequal Erasure Protection.
FEC OTI
stands for FEC Object Transmission Information.

3. Goals and Requirements

The main goal of the GOE FEC protection approach is to decouple FEC protection from the natural object boundaries, in order to enable either a differentiated protection of sub-parts of a single object (e.g., to achieve Unequal Erasure Protection (UEP)), or at the opposite a global protection of several objects (e.g., a large set of small objects). Appendix Appendix A gives two examples where the mapping from object(s) to generalized object(s) brings benefits in terms of either UEP or global protection of a set of objects.

Additionally, the following are general requirements for GOE FEC schemes:

Because of the GOE features, the following are specific requirements that a CDP SHOULD consider:

4. GOE Principles

4.1. GOE at a CDP Sender

Let us consider a CDP sender first. GOE encoding works as follows:

4.2. GOE at a CDP Receiver

Let us now consider a CDP receiver. GOE decoding works as follows:

Concerning FEC OTI processing, as explained in Section 3, if a given generalized object, say GO[0], includes source symbols that belong to several objects, say O[0], O[1] and O[2], then at some point of time, the receiver must have processed the FEC OTI of both GO[0] and O[0], O[1] and O[2]. When the FEC OTI is sent in separate packets (e.g., if FEC OTI is sent within EXT_FTI LCT or NORM header extensions), there is a dependency between all of them. The CDP sender must be aware of that dependency and SHOULD manage the session in such a way to maximize the probability that a receiver receives all the required FEC OTI in due time.

5. Formats and Codes with FEC Encoding ID XXX for Reed-Solomon codes over GF(2^^8)

This section introduces the formats and codes associated with the Fully-Specified FEC Scheme with FEC Encoding ID XXX, which focuses on the special case of Reed-Solomon codes over GF(2^^8) and no encoding symbol group. This GOE FEC Scheme is the GOE equivalent to FEC Encoding ID 5 defined in [RFC5510].

5.1. FEC Payload ID (for Repair Packets Only)

The FEC Payload ID, to be used only with repair packet, i.e., packets containing a repair symbol each, is composed of the Source Block Number (SBN) and the Encoding Symbol ID (ESI). There is no change in terms of format with respect to [RFC5510] but a restriction in terms of valid ESI as explained below:

There MUST be exactly one FEC Payload ID per repair packet. This FEC Payload ID refers 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  

5.2. FEC Object Transmission Information

5.2.1. Mandatory Elements

5.2.2. Common Elements

The Common elements are the same as those specified in [RFC5510] for FEC Encoding ID 5.

5.2.3. Scheme-Specific Elements

The following element MUST be defined with the present FEC scheme. It defines the composition of a generalized object:

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 [RFC5775] or NORM [RFC5740] 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    |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                      Transfer Length (L)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Encoding Symbol Length (E)  | MaxBlkLen (B) |     max_n     | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*_O|                                                           |
+-+-+         ISS_TOI (length = 32*ISS_O + 30 bits)             +
|                          ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    ISS Source Block Number    |    ISS Encoding Symbol ID     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Generalized Object Size                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      

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 [FLUTE], the following XML attributes must be described for the associated object:

The FEC-OTI-Scheme-Specific-Info contains the string resulting from the Base64 encoding (in the XML Schema xs:base64Binary sense) of the following value:

 0                   1          
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*_O|                                                           |
+-+-+         ISS_TOI (length = 32*ISS_O + 30 bits)             +
|                          ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    ISS Source Block Number    |    ISS Encoding Symbol ID     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Generalized Object Size                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  

During Base64 encoding, the FEC OTI Scheme-Specific Information (of variable length) is transformed into a string of printable characters (in the 64-character alphabet) that is added to the FEC-OTI-Scheme-Specific-Info attribute.

6. Procedures with FEC Encoding ID XXX for Reed-Solomon codes over GF(2^^8)

This section defines procedures that MUST be applied to FEC Encoding ID XXX. The block partitioning algorithm that is defined in Section 9.1 of [RFC5052] MUST be used. The procedure called "Determining the Maximum Source Block Length (B)" in [RFC5510] MUST be used. The procedure called "Determining the Number of Encoding Symbols of a Block" in [RFC5510] MUST be used.

6.1. Determining the Encoding Symbol Length (E)

The E parameter usually depends on the maximum transmission unit on the path Maximum Transmission Unit (PMTU) from the source to each receiver. This PTMU may be known, may be discovered, or may be estimated, depending on the target use case. In order to minimize the protocol header overhead (e.g., the Layered Coding Transport (LCT), UDP, IPv4, or IPv6 headers in the case of ALC), E MAY be chosen to be as large as possible. In that case, E is chosen so that the size of a packet composed of a single encoding symbol remains below but close to the PMTU (or by the minimum PMTU to each possible destinations in case of one-to-many sessions). This value E is also the source symbol size (i.e., the source symbols, before FEC encoding, and the encoding symbols, after FEC encoding, are of equal size).

This size MUST be used to segment all of the NO objects considered by the GOE FEC schemes for this CDP into source symbols. By doing so, a generalized object that straddles several objects (among the NO possibles) benefits from the same source symbol size across object boundaries.

7. Security Considerations

TBD

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

This document assigns the Fully-Specified FEC Encoding ID XXX under the "ietf:rmt:fec:encoding" name-space to "Generalized Object Encoding for Reed-Solomon Codes over GF(2^^8)".

9. Acknowledgments

TBD

10. References

10.1. Normative References

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

10.2. Informative References

[RFC3453] 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.
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, March 2009.
[RFC5170] Roca, V., Neumann, C. and D. Furodet, "Low Density Parity Check (LDPC) Forward Error Correction", RFC 5170, June 2008.
[RFC5052] Watson, M., Luby, M. and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J. and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, April 2009.
[RFC5053] Luby, M., Shokrollahi, A, Watson, M and T Stockhammer, "Raptor Forward Error Correction Scheme", RFC 5053, June 2007.
[RFC5740] Adamson, B., Bormann, C., Handley, M. and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.
[RFC5775] Luby, M., Watson, M. and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[FLUTE] Paila, T., Walsh, R., Luby, M., Roca, V. and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, February 2011.

Appendix A. Two Examples of GOE Protection of Objects

Figure 4 is an example of use of a GOE FEC scheme to provide unequal erasure protection of a large object, whose first part is of higher importance than the remaining bytes. Different code rates are applied to each generalized object, to provide for different erasure protection. The 80 packets generated after a No-Code FEC encoding of the object of TOI 1, along with the 20 repair symbols generated after a Reed-Solomon(60, 40) encoding of the high priority generalized object of TOI=10 and the 10 repair symbols generated after a Reed-Solomo(50, 40) encoding of the low priority generalized object of TOI=11 are sent over the network. Here the two generalized objects are kept separate, however nothing in the GOE approach requires this is the case. Other types of mappings are possible.

+------------------------------------------------------------------+
| Object, TOI=1, k=80 source symbols                               |
+------------------------------------------------------------------+
\--------------- ----------------/\--------------- ----------------/
                V                                 V
 +------------------------------+  +------------------------------+
 |      1st GO (high prio)      |  |      2nd GO (low prio)       | 
 |     TOI=10, k=40 symbols     |  |     TOI=11, k=40 symbols     |
 +------------------------------+  +------------------------------+
                |                                 |
   FEC Encoding, code rate=0.5       FEC Encoding, code rate=0.8
                |                                 |
                V                                 V
        20 repair symbols                 10 repair symbols
  

On the opposite, Figure 4 is an example of use of a GOE FEC scheme to globally protect a set of small objects. A single generalized object of TOI 10 is defined that gathers the source symbols of the original objects of TOI 1 to 7 included. The 80 packets generated after a No-Code FEC encoding of the objects of TOI 1 to 7, along with the 40 repair symbols generated after a Reed-Solomon(120, 80) encoding of the generalized object of TOI=10 are sent over the network. With an MDS code, any subset of 80 packets among the 120 possible packets are sufficient to decode all the original objects.

+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +------------------+
|TOI=1| |TOI=2| |TOI=3| |TOI=4| |TOI=5| |TOI=6| |       TOI=7      |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +------------------+
\-------------------------------- ---------------------------------/
                                 V
+------------------------------------------------------------------+
| Generalized Object, TOI=10, k=80 source symbols                  |
+------------------------------------------------------------------+
                                 |
                    FEC Encoding, code rate=0.5
                                 | 
                                 V
                         40 repair symbols
  

Authors' Addresses

Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex, 38334 France EMail: vincent.roca@inria.fr URI: http://planete.inrialpes.fr/people/roca/
Aline Roumy INRIA Campus Universitaire de Beaulieu RENNES Cedex, 35042 France EMail: aline.roumy@inria.fr URI: http://www.irisa.fr/prive/Aline.Roumy/
Bessem Sayadi Alcatel-Lucent, Bell Labs France EMail: bessem.sayadi@alcatel-lucent.com