draft-ietf-fecframe-simple-rs-01.txt   draft-ietf-fecframe-simple-rs-02.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: March 17, 2012 NICTA Expires: June 1, 2012 NICTA
J. Lacan J. Lacan
A. Bouabdallah A. Bouabdallah
ISAE/LAAS-CNRS ISAE/LAAS-CNRS
K. Matsuzono K. Matsuzono
Keio University Keio University
September 14, 2011 November 29, 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-01 draft-ietf-fecframe-simple-rs-02
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 March 17, 2012. This Internet-Draft will expire on June 1, 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 33 skipping to change at page 2, line 33
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8
4. Common Procedures Related to the ADU Block and Source 4. Common Procedures Related to the ADU Block and Source
Block Creation . . . . . . . . . . . . . . . . . . . . . . . . 8 Block Creation . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 8 4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 8
4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 9 4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 9
5. Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary 5. Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary
ADU Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 11 ADU Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 11 5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 11
5.1.1. FEC Framework Configuration Information . . . . . . . 11 5.1.1. FEC Framework Configuration Information . . . . . . . 11
5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 12 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 13
5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 14
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 15 5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 15 6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 16
6.1.1. Access to Confidential Content . . . . . . . . . . . . 15 6.1.1. Access to Confidential Content . . . . . . . . . . . . 16
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 . . . . . . . . . 18
7. Operations and Management Considerations . . . . . . . . . . . 17 7. Operations and Management Considerations . . . . . . . . . . . 18
7.1. Operational Recommendations: Finite Field Size (m) . . . . 17 7.1. Operational Recommendations: Finite Field Size (m) . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 [RFC6363] Content Delivery Protocols (CDP) and applications. The [RFC6363]
document describes a generic framework to use FEC schemes with media document describes a generic framework to use FEC schemes with media
delivery applications, and for instance with real-time streaming delivery applications, and for instance with real-time streaming
media applications based on the RTP real-time protocol. Similarly media applications based on the RTP real-time protocol. Similarly
the [RFC5052] document describes a generic framework to use FEC the [RFC5052] document describes a generic framework to use FEC
skipping to change at page 6, line 15 skipping to change at page 6, line 15
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
[RFC6363]: [RFC6363]:
Application Data Unit (ADU): a unit of data coming from (sender) or Application Data Unit (ADU): The unit of source data provided as
given to (receiver) the media delivery application. Depending on payload to the transport layer. Depending on the use-case, an ADU
the use-case, an ADU can use an RTP encapsulation. In this may use an RTP encapsulation.
specification, there is always one source symbol per ADU. (Source) ADU Flow: A sequence of ADUs associated with a transport-
(Source) ADU Flow: a flow of ADUs from a media delivery application layer flow identifier (such as the standard 5-tuple {Source IP
and to which FEC protection is applied. Depending on the use- address, source port, destination IP address, destination port,
case, several ADU flows can be protected together by the FECFRAME transport protocol}). Depending on the use-case, several ADU
framework. flows may be protected together by the FECFRAME 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
the F[], L[], and Pad[] fields, they form the set of source the F[], L[], and Pad[] fields, they form the set of source
symbols over which FEC encoding will be performed. symbols over which FEC encoding will be performed.
ADU Information (ADUI): a unit of data constituted by the ADU and ADU Information (ADUI): a unit of data constituted by the ADU and
the associated Flow ID, Length and Padding fields (Section 4.3). the associated Flow ID, Length and Padding fields (Section 4.3).
This is the unit of data that is used as source symbol. This is the unit of data that is used as source symbol.
FEC Framework Configuration Information: the FEC scheme specific FEC Framework Configuration Information: Information which controls
information that enables the synchronization of the FECFRAME the operation of the FEC Framework. The FFCI enables the
sender and receiver instances. synchronization of the FECFRAME sender and receiver instances.
FEC Source Packet: a data packet submitted to (sender) or received FEC Source Packet: At a sender (respectively, at a receiver) a
from (receiver) the transport protocol. It contains an ADU along payload submitted to (respectively, received from) the transport
with its optional Explicit Source FEC Payload ID. protocol containing an ADU along with an optional Explicit Source
FEC Repair Packet: a repair packet submitted to (sender) or received FEC Payload ID.
from (receiver) the transport protocol. It contains a repair FEC Repair Packet: At a sender (respectively, at a receiver) a
symbol along with its Repair FEC Payload ID. payload submitted to (respectively, received from) the transport
protocol containing one repair symbol along with a Repair FEC
Payload ID and possibly an RTP header.
The above terminology is illustrated in Figure 1 (sender's point of The above terminology is illustrated in Figure 1 (sender's point of
view): view):
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
ADU flow | (1) Application Data Unit (ADU) | (1) Application Data Units (ADUs)
|
v v
+----------------------+ +----------------+ +----------------------+ +----------------+
| FEC Framework | | | | FEC Framework | | |
| |------------------------- >| FEC Scheme | | |-------------------------->| FEC Scheme |
|(2) Construct an ADU | (4) Source Symbols for | | |(2) Construct source |(3) Source Block | |
| block | this Source Block |(5) Perform FEC | | blocks | |(4) FEC Encoding|
|(3) Construct ADU Info| | Encoding | |(6) Construct FEC |<--------------------------| |
|(7) Construct FEC Src |< -------------------------| | | source and repair | | |
| Packets and FEC |(6) Ex src FEC Payload Ids,| | | packets |(5) Explicit Source FEC | |
| Repair Packets | Repair FEC Payload Ids,| | +----------------------+ Payload IDs +----------------+
+----------------------+ Repair Symbols +----------------+ | Repair FEC Payload IDs
| | | Repair symbols
|(8) FEC Src |(8') FEC Repair |
| packets | packets |(7) FEC source and repair packets
v v v
+----------------------+ +----------------------+
| Transport Layer | | Transport Layer |
| (e.g., UDP ) | | (e.g., UDP) |
+----------------------+ +----------------------+
Figure 1: Terminology used in this document (sender). Figure 1: Terminology used in this document (sender).
3.2. Notations 3.2. Notations
This document uses the following notations: Some of them are FEC This document uses the following notations: Some of them are FEC
scheme specific: scheme specific:
k denotes the number of source symbols in a source block. k denotes the number of source symbols in a source block.
max_k denotes the maximum number of source symbols for any source max_k denotes the maximum number of source symbols for any source
block. block.
n denotes the number of encoding symbols generated for a source n denotes the number of encoding symbols generated for a source
block. block.
E denotes the encoding symbol length in bytes. E denotes the encoding symbol length in bytes.
GF(q) denotes a finite field (also known as Galois Field) with q GF(q) denotes a finite field (also known as Galois Field) with q
elements. We assume that q = 2^^m in this document. elements. We assume that q = 2^^m in this document.
m defines the length of the elements in the finite field, in m defines the length of the elements in the finite field, in
bits. In this document, m is such that 2 <= m <= 16. bits. In this document, m is such that 2 <= m <= 16.
q defines the number of elements in the finite field. We have: q defines the number of elements in the finite field. We have:
q = 2^^m in this specification. q = 2^^m in this specification.
CR denotes the "code rate", i.e., the k/n ratio.
CR denotes the "code rate", i.e., the k/n ratio.
a^^b denotes a raised to the power b. a^^b denotes a raised to the power b.
Some of them are FECFRAME framework specific: Some of them are FECFRAME framework specific:
B denotes the number of ADUs per ADU block. B denotes the number of ADUs per ADU block.
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.
skipping to change at page 8, line 37 skipping to change at page 8, line 38
4.1. Restrictions 4.1. Restrictions
This specification has the following restrictions: This specification has the following restrictions:
o there MUST be exactly one source symbol per ADUI, and therefore o there MUST be exactly one source symbol per ADUI, and therefore
per ADU; per ADU;
o there MUST be exactly one repair symbol per FEC Repair Packet; o there MUST be exactly one repair symbol per FEC Repair Packet;
o there MUST be exactly one source block per ADU block; o there MUST be exactly one source block per ADU block;
4.2. ADU Block Creation 4.2. ADU Block Creation
Several aspects must be considered, that impact the ADU block Two kinds of limitations MUST be considered, that impact the ADU
creation: block creation:
o the maximum source block size (k parameter) and number of encoding o at the FEC Scheme level: the finite field size (m parameter)
symbols (n parameter), that are constrained by the finite field directly impacts the maximum source block size and the maximum
size (m parameter); number of encoding symbols;
o the potential real-time constraints, that impact the maximum ADU o at the FECFRAME instance level: the target use-case MAY have real-
block size, since the larger the block size, the larger the time constraints that MAY define a maximum ADU block size;
decoding delay; Note that terminology "maximum source block size" and "maximum ADU
We now detail each of these aspects. block size" depends on the point of view that is adopted (FEC Scheme
versus FECFRAME instance). However, in this document, both refer to
the same value since Section 4.1 requires there is exactly one source
symbol per ADU. We now detail each of these aspects.
The finite field size parameter, m, defines the number of non zero The finite field size parameter, m, defines the number of non zero
elements in this field which is equal to: q - 1 = 2^^m - 1. This q - elements in this field which is equal to: q - 1 = 2^^m - 1. This q -
1 value is also the theoretical maximum number of encoding symbols 1 value is also the theoretical maximum number of encoding symbols
that can be produced for a source block. For instance, when m = 8 that can be produced for a source block. For instance, when m = 8
(default) there is a maximum of 2^^8 - 1 = 255 encoding symbols. So: (default) there is a maximum of 2^^8 - 1 = 255 encoding symbols. So:
k < n <= 255. Given the target FEC code rate (e.g., provided by the k < n <= 255. Given the target FEC code rate (e.g., provided by the
end-user or upper application when starting the FECFRAME framework, end-user or upper application when starting the FECFRAME framework,
and taking into account the (known or estimated) packet loss rate), and taking into account the known or estimated packet loss rate), the
the sender calculates: sender calculates:
max_k = floor((2^^m - 1) * CR) max_k = floor((2^^m - 1) * CR)
This max_k value leaves enough room for the sender to produce the This max_k value leaves enough room for the sender to produce the
desired number of repair symbols. Since there is one source symbol desired number of repair symbols. Since there is one source symbol
per ADU, max_k is also an upper bound to the maximum number of ADUs per ADU, max_k is also an upper bound to the maximum number of ADUs
per ADU block. per ADU block.
The source ADU flows usually have real-time constraints. It means The source ADU flows MAY have real-time constraints. In that case
that the maximum number of ADUs of an ADU block must not exceed a the maximum number of ADUs of an ADU block must not exceed a certain
certain threshold since it directly impacts the decoding delay. It threshold since it directly impacts the decoding delay. The larger
is the role of the developer, who knows the flow real-time features, the ADU block size, the longer a decoder may have to wait until it
to define an appropriate upper bound to the ADU block size, max_rt. has received a sufficient number of encoding symbols for decoding to
succeed, and therefore the larger the decoding delay. When the
target use-case is known, these real-time constraints result in an
upper bound to the ADU block size, max_rt.
If we take into account these constraints, we find: max_B = For instance, if the use-case specifies a maximum decoding latency,
min(max_k, max_rt). Then max_B gives an upper bound to the number of l, and if each source ADU covers a duration d of a continuous media
ADUs that can constitute an ADU block. (we assume here the simple case of a constant bit rate ADU flow),
then the ADU block size must not exceed:
max_rt = floor(l / d)
After encoding, this block will produce a set of at most n = max_rt /
CR encoding symbols. These n encoding symbols will have to be sent
at a rate of n / l packets per second. For instance, with d = 10 ms,
l = 1 s, max_rt = 100 ADUs.
If we take into account all these constraints, we find:
max_B = min(max_k, max_rt)
This max_B parameter is an upper bound to the number of 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 Reed-Solomon In its most general form the FECFRAME framework and the Reed-Solomon
FEC scheme are meant to protect a set of independent flows. Since FEC scheme are meant to protect a set of independent flows. Since
the flows have no relationship to one another, the ADU size of each the flows have no relationship to one another, the ADU size of each
flow can potentially vary significantly. Even in the special case of flow can potentially vary significantly. Even in the special case of
a single flow, the ADU sizes can largely vary (e.g., the various a single flow, the ADU sizes can largely vary (e.g., the various
frames of a "Group of Pictures (GOP) of an H.264 flow). This frames of a "Group of Pictures (GOP) of an H.264 flow will have
diversity must be addressed since the Reed-Solomon FEC scheme different sizes). This diversity must be addressed since the Reed-
requires a constant encoding symbol size (E parameter) per source Solomon FEC scheme requires a constant encoding symbol size (E
block. Since this specification requires that there is only one parameter) per source block. Since this specification requires that
source symbol per ADU, E must be large enough to contain all the ADUs there is only one source symbol per ADU, E must be large enough to
of an ADU block along with their prepended 3 bytes (see below). contain all the ADUs 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 11, line 41 skipping to change at page 12, line 20
FEC Encoding ID: the value assigned to this fully-specified FEC FEC Encoding ID: the value assigned to this fully-specified FEC
scheme MUST be XXX, as assigned by IANA (Section 8). scheme MUST be XXX, as assigned by IANA (Section 8).
When SDP is used to communicate the FFCI, this FEC Encoding ID is When SDP is used to communicate the FFCI, this FEC Encoding ID is
carried in the 'encoding-id' parameter. carried in the 'encoding-id' parameter.
5.1.1.2. FEC Scheme-Specific Information 5.1.1.2. FEC Scheme-Specific Information
The FEC Scheme Specific Information (FSSI) includes elements that are The FEC Scheme Specific Information (FSSI) includes elements that are
specific to the present FEC scheme. More precisely: specific to the present FEC scheme. More precisely:
Encoding symbol length (E): a non-negative integer that indicates Encoding symbol length (E): a non-negative integer that indicates
either the length of each encoding symbol in bytes (strict mode, either the length of each encoding symbol in bytes ("strict" mode,
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).
skipping to change at page 12, line 4 skipping to change at page 12, line 31
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 (Reed-Solomon encoder) These elements are required both by the sender (Reed-Solomon encoder)
and the receiver(s) (Reed-Solomon 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 [RFC6364]. 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:
o Encoding symbol length (E): 16 bit field. o Encoding symbol length (E): 16 bit field.
o Strict (S) flag: 1 bit field. o Strict (S) flag: 1 bit field.
o m parameter (m): 7 bit field. o m parameter (m): 7 bit field.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
skipping to change at page 18, line 33 skipping to change at page 19, line 20
particular it defines a registry called FEC Framework (FECFRAME) FEC particular it defines a registry called FEC Framework (FECFRAME) FEC
Encoding IDs whose values are granted on an IETF Consensus basis. Encoding IDs whose values are granted on an 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 [RFC5510] FEC Scheme over o XXX refers to the Simple Reed-Solomon [RFC5510] FEC Scheme over
GF(2^^m) for Arbitrary Packet Flows. GF(2^^m) for Arbitrary Packet Flows.
9. Acknowledgments 9. Acknowledgments
The authors want to thank Hitoshi Asaeda for his valuable comments. The authors want to thank Hitoshi Asaeda and Ali Begen for their
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.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, September 2011. Correction (FEC) Framework", RFC 6363, September 2011.
[SDP_ELEMENTS] [RFC6364] Begen, A., "Session Description Protocol Elements for the
Begen, A., "SDP Elements for FEC Framework", Forward Error Correction (FEC) Framework", RFC 6364,
draft-ietf-fecframe-sdp-elements-11 (Work in Progress), October 2011.
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, http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz,
mirrored at http://planete-bcast.inrialpes.fr/ and mirrored at http://planete-bcast.inrialpes.fr/ and
http://openfec.org/", July 1998. http://openfec.org/", July 1998.
 End of changes. 27 change blocks. 
85 lines changed or deleted 104 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/