draft-ietf-fecframe-simple-rs-00.txt   draft-ietf-fecframe-simple-rs-01.txt 
FecFrame V. Roca FecFrame V. Roca
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Standards Track M. Cunche Intended status: Standards Track M. Cunche
Expires: September 1, 2011 NICTA Expires: March 17, 2012 NICTA
J. Lacan J. Lacan
A. Bouabdallah A. Bouabdallah
ISAE/LAAS-CNRS ISAE/LAAS-CNRS
K. Matsuzono K. Matsuzono
Keio University Keio University
February 28, 2011 September 14, 2011
Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
draft-ietf-fecframe-simple-rs-00 draft-ietf-fecframe-simple-rs-01
Abstract Abstract
This document describes a fully-specified simple FEC scheme for Reed- This document describes a fully-specified simple FEC scheme for Reed-
Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to
protect arbitrary media streams along the lines defined by the protect arbitrary media streams along the lines defined by the
FECFRAME framework. Reed-Solomon codes belong to the class of FECFRAME framework. Reed-Solomon codes belong to the class of
Maximum Distance Separable (MDS) codes which means they offer optimal Maximum Distance Separable (MDS) codes which means they offer optimal
protection against packet erasures. They are also systematic codes, protection against packet erasures. They are also systematic codes,
which means that the source symbols are part of the encoding symbols. which means that the source symbols are part of the encoding symbols.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 1, 2011. This Internet-Draft will expire on March 17, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 15 5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 15 6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 15
6.1.1. Access to Confidential Content . . . . . . . . . . . . 15 6.1.1. Access to Confidential Content . . . . . . . . . . . . 15
6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 16 6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 16
6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 16 6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 16
6.3. When Several Source Flows are to be Protected Together . . 17 6.3. When Several Source Flows are to be Protected Together . . 17
6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 17 6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 17
7. Operations and Management Considerations . . . . . . . . . . . 17 7. Operations and Management Considerations . . . . . . . . . . . 17
7.1. Finite Field Size (m) Recommendations . . . . . . . . . . 17 7.1. Operational Recommendations: Finite Field Size (m) . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The use of Forward Error Correction (FEC) codes is a classic solution The use of Forward Error Correction (FEC) codes is a classic solution
to improve the reliability of unicast, multicast and broadcast to improve the reliability of unicast, multicast and broadcast
Content Delivery Protocols (CDP) and applications. The Content Delivery Protocols (CDP) and applications. The [RFC6363]
[FECFRAME-FRAMEWORK] document describes a generic framework to use document describes a generic framework to use FEC schemes with media
FEC schemes with media delivery applications, and for instance with delivery applications, and for instance with real-time streaming
real-time streaming media applications based on the RTP real-time media applications based on the RTP real-time protocol. Similarly
protocol. Similarly the [RFC5052] document describes a generic the [RFC5052] document describes a generic framework to use FEC
framework to use FEC schemes with with objects (e.g., files) delivery schemes with with objects (e.g., files) delivery applications based
applications based on the ALC [RFC5775] and NORM [RFC5740] reliable on the ALC [RFC5775] and NORM [RFC5740] reliable multicast transport
multicast transport protocols. protocols.
More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce
erasure codes based on sparse parity check matrices for object erasure codes based on sparse parity check matrices for object
delivery protocols like ALC and NORM. These codes are efficient in delivery protocols like ALC and NORM. These codes are efficient in
terms of processing but not optimal in terms of erasure recovery terms of processing but not optimal in terms of erasure recovery
capabilities when dealing with "small" objects. capabilities when dealing with "small" objects.
The Reed-Solomon FEC codes described in this document belong to the The Reed-Solomon FEC codes described in this document belong to the
class of Maximum Distance Separable (MDS) codes that are optimal in class of Maximum Distance Separable (MDS) codes that are optimal in
terms of erasure recovery capability. It means that a receiver can terms of erasure recovery capability. It means that a receiver can
skipping to change at page 4, line 51 skipping to change at page 4, line 51
recovery codes. In particular, many of them use the Reed-Solomon recovery codes. In particular, many of them use the Reed-Solomon
codec of Luigi Rizzo [RS-codec] [Rizzo97]. The goal of the present codec of Luigi Rizzo [RS-codec] [Rizzo97]. The goal of the present
document is to specify a simple Reed-Solomon scheme that is document is to specify a simple Reed-Solomon scheme that is
compatible with this codec. compatible with this codec.
More specifically, the [RFC5510] document introduced such Reed- More specifically, the [RFC5510] document introduced such Reed-
Solomon codes and several associated FEC schemes that are compatible Solomon codes and several associated FEC schemes that are compatible
with the [RFC5052] framework. The present document inherits from with the [RFC5052] framework. The present document inherits from
[RFC5510] the specification of the core Reed-Solomon codes based on [RFC5510] the specification of the core Reed-Solomon codes based on
Vandermonde matrices, and specifies a simple FEC scheme that is Vandermonde matrices, and specifies a simple FEC scheme that is
compatible with the FECFRAME framework [FECFRAME-FRAMEWORK]. compatible with the FECFRAME framework [RFC6363]. Therefore this
Therefore this document specifies only the information specific to document specifies only the information specific to the FECFRAME
the FECFRAME context and refers to [RFC5510] for the core context and refers to [RFC5510] for the core specifications of the
specifications of the codes. To that purpose, the present document codes. To that purpose, the present document introduces:
introduces:
o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that
specifies a simple way of using of Reed-Solomon codes over specifies a simple way of using of Reed-Solomon codes over
GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for
arbitrary packet flows; arbitrary packet flows;
For instance, with this scheme, a set of Application Data Units (or For instance, with this scheme, a set of Application Data Units (or
ADUs) coming from one or several (resp. one) media delivery ADUs) coming from one or several (resp. one) media delivery
applications (e.g., a set of RTP packets), are grouped in an ADU applications (e.g., a set of RTP packets), are grouped in an ADU
block and FEC encoded as a whole. With Reed-Solomon codes over block and FEC encoded as a whole. With Reed-Solomon codes over
GF(2^^8), there is a strict limit over the number of ADUs that can be GF(2^^8), there is a strict limit over the number of ADUs that can be
skipping to change at page 6, line 14 skipping to change at page 6, line 14
Source block: a block of k source symbols that are considered Source block: a block of k source symbols that are considered
together for the encoding. together for the encoding.
Packet Erasure Channel: a communication path where packets are Packet Erasure Channel: a communication path where packets are
either dropped (e.g., by a congested router, or because the number either dropped (e.g., by a congested router, or because the number
of transmission errors exceeds the correction capabilities of the of transmission errors exceeds the correction capabilities of the
physical layer codes) or received. When a packet is received, it physical layer codes) or received. When a packet is received, it
is assumed that this packet is not corrupted. is assumed that this packet is not corrupted.
Some of them are FECFRAME framework specific and are in line with Some of them are FECFRAME framework specific and are in line with
[FECFRAME-FRAMEWORK]: [RFC6363]:
Application Data Unit (ADU): a unit of data coming from (sender) or Application Data Unit (ADU): a unit of data coming from (sender) or
given to (receiver) the media delivery application. Depending on given to (receiver) the media delivery application. Depending on
the use-case, an ADU can use an RTP encapsulation. In this the use-case, an ADU can use an RTP encapsulation. In this
specification, there is always one source symbol per ADU. specification, there is always one source symbol per ADU.
(Source) ADU Flow: a flow of ADUs from a media delivery application (Source) ADU Flow: a flow of ADUs from a media delivery application
and to which FEC protection is applied. Depending on the use- and to which FEC protection is applied. Depending on the use-
case, several ADU flows can be protected together by the FECFRAME case, several ADU flows can be protected together by the FECFRAME
framework. framework.
ADU Block: a set of ADUs that are considered together by the ADU Block: a set of ADUs that are considered together by the
FECFRAME instance for the purpose of the FEC scheme. Along with FECFRAME instance for the purpose of the FEC scheme. Along with
skipping to change at page 8, line 19 skipping to change at page 8, line 19
max_B denotes the maximum number of ADUs for any ADU block. max_B denotes the maximum number of ADUs for any ADU block.
3.3. Abbreviations 3.3. Abbreviations
This document uses the following abbreviations: This document uses the following abbreviations:
ADU stands for Application Data Unit. ADU stands for Application Data Unit.
ESI stands for Encoding Symbol ID. ESI stands for Encoding Symbol ID.
FEC stands for Forward Error (or Erasure) Correction code. FEC stands for Forward Error (or Erasure) Correction code.
FFCI stands for FEC Framework Configuration Information. FFCI stands for FEC Framework Configuration Information.
FSSI stands for FEC Scheme Specific Information. FSSI stands for FEC Scheme Specific Information.
RS stands for Reed-Solomon.
MDS stands for Maximum Distance Separable code. MDS stands for Maximum Distance Separable code.
4. Common Procedures Related to the ADU Block and Source Block Creation 4. Common Procedures Related to the ADU Block and Source Block Creation
This section introduces the procedures that are used during the ADU This section introduces the procedures that are used during the ADU
block and the related source block creation, for the FEC scheme block and the related source block creation, for the FEC scheme
considered. considered.
4.1. Restrictions 4.1. Restrictions
skipping to change at page 9, line 27 skipping to change at page 9, line 27
certain threshold since it directly impacts the decoding delay. It certain threshold since it directly impacts the decoding delay. It
is the role of the developer, who knows the flow real-time features, is the role of the developer, who knows the flow real-time features,
to define an appropriate upper bound to the ADU block size, max_rt. to define an appropriate upper bound to the ADU block size, max_rt.
If we take into account these constraints, we find: max_B = If we take into account these constraints, we find: max_B =
min(max_k, max_rt). Then max_B gives an upper bound to the number of min(max_k, max_rt). Then max_B gives an upper bound to the number of
ADUs that can constitute an ADU block. ADUs that can constitute an ADU block.
4.3. Source Block Creation 4.3. Source Block Creation
In its most general form the FECFRAME framework and the RS FEC scheme In its most general form the FECFRAME framework and the Reed-Solomon
are meant to protect a set of independent flows. Since the flows FEC scheme are meant to protect a set of independent flows. Since
have no relationship to one another, the ADU size of each flow can the flows have no relationship to one another, the ADU size of each
potentially vary significantly. Even in the special case of a single flow can potentially vary significantly. Even in the special case of
flow, the ADU sizes can largely vary (e.g., the various frames of a a single flow, the ADU sizes can largely vary (e.g., the various
"Group of Pictures (GOP) of an H.264 flow). This diversity must be frames of a "Group of Pictures (GOP) of an H.264 flow). This
addressed since the RS FEC scheme requires a constant encoding symbol diversity must be addressed since the Reed-Solomon FEC scheme
size (E parameter) per source block. Since this specification requires a constant encoding symbol size (E parameter) per source
requires that there is only one source symbol per ADU, E must be block. Since this specification requires that there is only one
large enough to contain all the ADUs of an ADU block along with their source symbol per ADU, E must be large enough to contain all the ADUs
prepended 3 bytes (see below). of an ADU block along with their prepended 3 bytes (see below).
In situations where E is determined per source block (default, In situations where E is determined per source block (default,
specified by the FFCI/FSSI with S = 0, Section 5.1.1.2), E is equal specified by the FFCI/FSSI with S = 0, Section 5.1.1.2), E is equal
to the size of the largest ADU of this source block plus three (for to the size of the largest ADU of this source block plus three (for
the prepended 3 bytes, see below). In this case, upon receiving the the prepended 3 bytes, see below). In this case, upon receiving the
first FEC Repair Packet for this source block, since this packet MUST first FEC Repair Packet for this source block, since this packet MUST
contain a single repair symbol (Section 5.1.3), a receiver determines contain a single repair symbol (Section 5.1.3), a receiver determines
the E parameter used for this source block. the E parameter used for this source block.
In situations where E is fixed (specified by the FFCI/FSSI with S = In situations where E is fixed (specified by the FFCI/FSSI with S =
skipping to change at page 12, line 6 skipping to change at page 12, line 4
i.e., if S = 1), or the maximum length of any encoding symbol i.e., if S = 1), or the maximum length of any encoding symbol
(i.e., if S = 0). (i.e., if S = 0).
Strict (S) flag: when set to 1 this flag indicates that the E Strict (S) flag: when set to 1 this flag indicates that the E
parameter is the actual encoding symbol length value for each parameter is the actual encoding symbol length value for each
block of the session (unless otherwise notified by an updated FFCI block of the session (unless otherwise notified by an updated FFCI
if this possibility is considered by the use-case or CDP). When if this possibility is considered by the use-case or CDP). When
set to 0 this flag indicates that the E parameter is the maximum set to 0 this flag indicates that the E parameter is the maximum
encoding symbol length value for each block of the session (unless encoding symbol length value for each block of the session (unless
otherwise notified by an updated FFCI if this possibility is otherwise notified by an updated FFCI if this possibility is
considered by the use-case or CDP). considered by the use-case or CDP).
m parameter (m): an integer that defines the length of the elements m parameter (m): an integer that defines the length of the elements
in the finite field, in bits. We have: 2 <= m <= 16. in the finite field, in bits. We have: 2 <= m <= 16.
These elements are required both by the sender (RS encoder) and the These elements are required both by the sender (Reed-Solomon encoder)
receiver(s) (RS decoder). and the receiver(s) (Reed-Solomon decoder).
When SDP is used to communicate the FFCI, this FEC scheme-specific When SDP is used to communicate the FFCI, this FEC scheme-specific
information is carried in the 'fssi' parameter in textual information is carried in the 'fssi' parameter in textual
representation as specified in [SDP_ELEMENTS]. For instance: representation as specified in [SDP_ELEMENTS]. For instance:
fssi = E:1400,S:0,m:8 fssi = E:1400,S:0,m:8
If another mechanism requires the FSSI to be carried as an opaque If another mechanism requires the FSSI to be carried as an opaque
octet string (for instance after a Base64 encoding), the encoding octet string (for instance after a Base64 encoding), the encoding
format consists of the following 3 octets: format consists of the following 3 octets:
skipping to change at page 15, line 30 skipping to change at page 15, line 30
Section 5.1.3. Section 5.1.3.
5.3. FEC Code Specification 5.3. FEC Code Specification
The present document inherits from [RFC5510] the specification of the The present document inherits from [RFC5510] the specification of the
core Reed-Solomon codes based on Vandermonde matrices for a packet core Reed-Solomon codes based on Vandermonde matrices for a packet
transmission channel. transmission channel.
6. Security Considerations 6. Security Considerations
The FEC Framework document [FECFRAME-FRAMEWORK] provides a The FEC Framework document [RFC6363] provides a comprehensive
comprehensive analysis of security considerations applicable to FEC analysis of security considerations applicable to FEC schemes.
schemes. Therefore the present section follows the security Therefore the present section follows the security considerations
considerations section of [FECFRAME-FRAMEWORK] and only discusses section of [RFC6363] and only discusses topics that are specific to
topics that are specific to the use of Reed-Solomon codes. the use of Reed-Solomon codes.
6.1. Attacks Against the Data Flow 6.1. Attacks Against the Data Flow
6.1.1. Access to Confidential Content 6.1.1. Access to Confidential Content
The Reed-Solomon FEC Scheme specified in this document does not The Reed-Solomon FEC Scheme specified in this document does not
change the recommendations of [FECFRAME-FRAMEWORK]. To summarize, if change the recommendations of [RFC6363]. To summarize, if
confidentiality is a concern, it is RECOMMENDED that one of the confidentiality is a concern, it is RECOMMENDED that one of the
solutions mentioned in [FECFRAME-FRAMEWORK] is used, with special solutions mentioned in [RFC6363] is used, with special considerations
considerations to the way this solution is applied (e.g., before to the way this solution is applied (e.g., before versus after FEC
versus after FEC protection, and within the end-system versus in a protection, and within the end-system versus in a middlebox), to the
middlebox), to the operational constraints (e.g., performing FEC operational constraints (e.g., performing FEC decoding in a protected
decoding in a protected environment may be complicated or even environment may be complicated or even impossible) and to the threat
impossible) and to the threat model. model.
6.1.2. Content Corruption 6.1.2. Content Corruption
The Reed-Solomon FEC Scheme specified in this document does not The Reed-Solomon FEC Scheme specified in this document does not
change the recommendations of [FECFRAME-FRAMEWORK]. To summarize, it change the recommendations of [RFC6363]. To summarize, it is
is RECOMMENDED that one of the solutions mentioned in RECOMMENDED that one of the solutions mentioned in [RFC6363] is used
[FECFRAME-FRAMEWORK] is used on both the FEC Source and Repair on both the FEC Source and Repair Packets.
Packets.
6.2. Attacks Against the FEC Parameters 6.2. Attacks Against the FEC Parameters
The FEC Scheme specified in this document defines parameters that can The FEC Scheme specified in this document defines parameters that can
be the basis of several attacks. More specifically, the following be the basis of several attacks. More specifically, the following
parameters of the FFCI may be modified by an attacker parameters of the FFCI may be modified by an attacker
(Section 5.1.1.2): (Section 5.1.1.2):
o FEC Encoding ID: changing this parameter leads the receiver to o FEC Encoding ID: changing this parameter leads the receiver to
consider a different FEC Scheme, which enables an attacker to consider a different FEC Scheme, which enables an attacker to
create a Denial of Service (DoS). create a Denial of Service (DoS).
skipping to change at page 16, line 49 skipping to change at page 16, line 48
(e.g., because the receiver pre-allocates memory space). (e.g., because the receiver pre-allocates memory space).
o m parameter: changing this parameter triggers a DoS since the o m parameter: changing this parameter triggers a DoS since the
receiver and sender will consider different codes, and the receiver and sender will consider different codes, and the
receiver will interpret the Explicit Source FEC Payload ID and receiver will interpret the Explicit Source FEC Payload ID and
Repair FEC Payload ID differently. Additionally, by increasing Repair FEC Payload ID differently. Additionally, by increasing
this m parameter to a larger value (typically m=16 rather than 8, this m parameter to a larger value (typically m=16 rather than 8,
when both values are possible in the target use-case) will create when both values are possible in the target use-case) will create
additional processing load at a receiver if decoding is attempted. additional processing load at a receiver if decoding is attempted.
It is therefore RECOMMENDED that security measures are taken to It is therefore RECOMMENDED that security measures are taken to
guarantee the FFCI integrity, as specified in [FECFRAME-FRAMEWORK]. guarantee the FFCI integrity, as specified in [RFC6363]. How to
How to achieve this depends on the way the FFCI is communicated from achieve this depends on the way the FFCI is communicated from the
the sender to the receiver, which is not specified in this document. sender to the receiver, which is not specified in this document.
Similarly, attacks are possible against the Explicit Source FEC Similarly, attacks are possible against the Explicit Source FEC
Payload ID and Repair FEC Payload ID: by modifying the Source Block Payload ID and Repair FEC Payload ID: by modifying the Source Block
Number (SBN), or the Encoding Symbol ID (ESI), or the Source Block Number (SBN), or the Encoding Symbol ID (ESI), or the Source Block
Length (k), an attacker can easily corrupt the block identified by Length (k), an attacker can easily corrupt the block identified by
the SBN. Other consequences, that are use-case and/or CDP dependant, the SBN. Other consequences, that are use-case and/or CDP dependant,
may also happen. It is therefore RECOMMENDED that security measures may also happen. It is therefore RECOMMENDED that security measures
are taken to guarantee the FEC Source and Repair Packets as stated in are taken to guarantee the FEC Source and Repair Packets as stated in
[FECFRAME-FRAMEWORK]. [RFC6363].
6.3. When Several Source Flows are to be Protected Together 6.3. When Several Source Flows are to be Protected Together
The Reed-Solomon FEC Scheme specified in this document does not The Reed-Solomon FEC Scheme specified in this document does not
change the recommendations of [FECFRAME-FRAMEWORK]. change the recommendations of [RFC6363].
6.4. Baseline Secure FEC Framework Operation 6.4. Baseline Secure FEC Framework Operation
The Reed-Solomon FEC Scheme specified in this document does not The Reed-Solomon FEC Scheme specified in this document does not
change the recommendations of [FECFRAME-FRAMEWORK] concerning the use change the recommendations of [RFC6363] concerning the use of the
of the IPsec/ESP security protocol as a mandatory to implement (but IPsec/ESP security protocol as a mandatory to implement (but not
not mandatory to use) security scheme. This is well suited to mandatory to use) security scheme. This is well suited to situations
situations where the only insecure domain is the one over which the where the only insecure domain is the one over which the FEC
FEC Framework operates. Framework operates.
7. Operations and Management Considerations 7. Operations and Management Considerations
The FEC Framework document [FECFRAME-FRAMEWORK] provides a The FEC Framework document [RFC6363] provides a comprehensive
comprehensive analysis of operations and management considerations analysis of operations and management considerations applicable to
applicable to FEC schemes. Therefore the present section only FEC schemes. Therefore the present section only discusses topics
discusses topics that are specific to the use of Reed-Solomon codes that are specific to the use of Reed-Solomon codes as specified in
as specified in this document. this document.
7.1. Finite Field Size (m) Recommendations 7.1. Operational Recommendations: Finite Field Size (m)
The present document requires that m, the length of the elements in The present document requires that m, the length of the elements in
the finite field, in bits, is such that 2 <= m <= 16. However all the finite field, in bits, is such that 2 <= m <= 16. However all
possibilities are not equally interesting from a practical point of possibilities are not equally interesting from a practical point of
view. It is expected that m=8, the default value, will be mostly view. It is expected that m=8, the default value, will be mostly
used since it offers the possibility to have small to medium sized used since it offers the possibility to have small to medium sized
source blocks and/or a significant number of repair symbols (i.e., k source blocks and/or a significant number of repair symbols (i.e., k
< n <= 255). Additionally, elements in the finite field are 8 bits < n <= 255). Additionally, elements in the finite field are 8 bits
long which makes read/write memory operations aligned on bytes during long which makes read/write memory operations aligned on bytes during
encoding and decoding. encoding and decoding.
skipping to change at page 18, line 11 skipping to change at page 18, line 10
will be used is m=4 (i.e., k < n <= 15). Elements in the finite will be used is m=4 (i.e., k < n <= 15). Elements in the finite
field are 4 bits long, so if two elements are accessed at a time, field are 4 bits long, so if two elements are accessed at a time,
read/write memory operations are aligned on bytes during encoding and read/write memory operations are aligned on bytes during encoding and
decoding. decoding.
An alternative when very large source blocks are needed is m=16 An alternative when very large source blocks are needed is m=16
(i.e., k < n <= 65535). However this choice has significant impacts (i.e., k < n <= 65535). However this choice has significant impacts
on the processing load. For instance using pre-calculated tables to on the processing load. For instance using pre-calculated tables to
speedup operations over the finite field (as done with smaller finite speedup operations over the finite field (as done with smaller finite
fields) may require a prohibitive amount of memory to be used on fields) may require a prohibitive amount of memory to be used on
embedded platforms. Alternative lightweigth solutions (e.g., embedded platforms. Alternative lightweight solutions (e.g.,
[RFC5170]) MAY be prefered in situations where the processing load is [RFC5170]) MAY be preferred in situations where the processing load
an issue [Matsuzono10]. is an issue [Matsuzono10].
Since several values for the m parameter are possible, the use-case Since several values for the m parameter are possible, the use-case
SHOULD define which value(s) need(s) to be supported. In situations SHOULD define which value(s) need(s) to be supported. In situations
where this is not specified, the default m=8 value SHOULD be where this is not specified, the default m=8 value SHOULD be
supported and used. supported and used.
8. IANA Considerations 8. IANA Considerations
Values of FEC Encoding IDs are subject to IANA registration. Values of FEC Encoding IDs are subject to IANA registration.
[FECFRAME-FRAMEWORK] defines general guidelines on IANA [RFC6363] defines general guidelines on IANA considerations. In
considerations. In particular it defines a registry called FEC particular it defines a registry called FEC Framework (FECFRAME) FEC
Framework (FECFRAME) FEC Encoding IDs whose values are granted on an Encoding IDs whose values are granted on an IETF Consensus basis.
IETF Consensus basis.
This document registers one value in the FEC Framework (FECFRAME) FEC This document registers one value in the FEC Framework (FECFRAME) FEC
Encoding IDs registry as follows: Encoding IDs registry as follows:
o XXX refers to the Simple Reed-Solomon FEC Scheme over GF(2^^m) for o XXX refers to the Simple Reed-Solomon [RFC5510] FEC Scheme over
Arbitrary Packet Flows as specified in this document and in GF(2^^m) for Arbitrary Packet Flows.
[RFC5510].
9. Acknowledgments 9. Acknowledgments
The authors want to thank Hitoshi Asaeda for his valuable comments. The authors want to thank Hitoshi Asaeda for his valuable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119. Requirement Levels", RFC 2119.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
"Reed-Solomon Forward Error Correction (FEC) Schemes", "Reed-Solomon Forward Error Correction (FEC) Schemes",
RFC 5510, April 2009. RFC 5510, April 2009.
[FECFRAME-FRAMEWORK] [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, September 2011.
Correction (FEC) Framework",
draft-ietf-fecframe-framework-13 (Work in Progress),
February 2011.
[SDP_ELEMENTS] [SDP_ELEMENTS]
Begen, A., "SDP Elements for FEC Framework", Begen, A., "SDP Elements for FEC Framework",
draft-ietf-fecframe-sdp-elements-11 (Work in Progress), draft-ietf-fecframe-sdp-elements-11 (Work in Progress),
October 2010. October 2010.
10.2. Informative References 10.2. Informative References
[RS-codec] [RS-codec]
Rizzo, L., "Reed-Solomon FEC codec (revised version of Rizzo, L., "Reed-Solomon FEC codec (revised version of
July 2nd, 1998), available at July 2nd, 1998), available at
http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz and http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz,
mirrored at http://planete-bcast.inrialpes.fr/", mirrored at http://planete-bcast.inrialpes.fr/ and
July 1998. http://openfec.org/", July 1998.
[Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer [Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer
Communication Protocols", ACM SIGCOMM Computer Communication Protocols", ACM SIGCOMM Computer
Communication Review Vol.27, No.2, pp.24-36, April 1997. Communication Review Vol.27, No.2, pp.24-36, April 1997.
[Matsuzono10] [Matsuzono10]
Matsuzono, K., Detchart, J., Cunche, M., Roca, V., and H. Matsuzono, K., Detchart, J., Cunche, M., Roca, V., and H.
Asaeda, "Performance Analysis of a High-Performance Real- Asaeda, "Performance Analysis of a High-Performance Real-
Time Application with Several AL-FEC Schemes", 35th Annual Time Application with Several AL-FEC Schemes", 35th Annual
IEEE Conference on Local Computer Networks (LCN 2010), IEEE Conference on Local Computer Networks (LCN 2010),
 End of changes. 28 change blocks. 
84 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/