draft-ietf-fecframe-simple-rs-04.txt   draft-ietf-fecframe-simple-rs-05.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: April 6, 2013 INSA-Lyon/INRIA Expires: May 10, 2013 INSA-Lyon/INRIA
J. Lacan J. Lacan
A. Bouabdallah
ISAE, Univ. of Toulouse ISAE, Univ. of Toulouse
A. Bouabdallah
CDTA
K. Matsuzono K. Matsuzono
Keio University Keio University
October 3, 2012 November 6, 2012
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-04 draft-ietf-fecframe-simple-rs-05
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.
The price to pay is a limit on the maximum source block size, on the The price to pay is a limit on the maximum source block size, on the
maximum number of encoding symbols, and a computational complexity maximum number of encoding symbols, and a computational complexity
higher than that of LDPC codes for instance. higher than that of LDPC codes for instance.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 6, 2013. This Internet-Draft will expire on May 10, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 18 skipping to change at page 2, line 19
(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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions Notations and Abbreviations . . . . . . . . . . . 5 3. Definitions Notations and Abbreviations . . . . . . . . . . . 4
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . 13 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 13
5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 14 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 14
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 16 5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 16 6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 16
6.1.1. Access to Confidential Content . . . . . . . . . . . . 16 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 . . . . . . . . . . . . 17
6.3. When Several Source Flows are to be Protected Together . . 17 6.3. When Several Source Flows are to be Protected Together . . 18
6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 18 6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 18
7. Operations and Management Considerations . . . . . . . . . . . 18 7. Operations and Management Considerations . . . . . . . . . . . 18
7.1. Operational Recommendations: Finite Field Size (m) . . . . 18 7.1. Operational Recommendations: Finite Field Size (m) . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
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
schemes with objects (e.g., files) delivery applications based on the schemes with objects (e.g., files) delivery applications based on the
ALC [RFC5775] and NORM [RFC5740] reliable multicast transport Asynchronous Layered Coding (ALC) [RFC5775] and NACK-Oriented
Reliable Multicast (NORM) [RFC5740] reliable 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
skipping to change at page 4, line 49 skipping to change at page 3, line 50
Many applications dealing with reliable content transmission or Many applications dealing with reliable content transmission or
content storage already rely on packet-based Reed-Solomon erasure content storage already rely on packet-based Reed-Solomon erasure
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], Section 8 "Reed-Solomon Codes Specification for the
Vandermonde matrices, and specifies a simple FEC scheme that is Erasure Channel", the specifications of the core Reed-Solomon codes
compatible with the FECFRAME framework [RFC6363]. Therefore this based on Vandermonde matrices, and specifies a simple FEC scheme that
document specifies only the information specific to the FECFRAME is compatible with the FECFRAME framework [RFC6363]:
context and refers to [RFC5510] for the core specifications of the
codes. To that purpose, the present document 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;
Therefore sections 4, 5, 6 and 7 of [RFC5510], that define [RFC5052]
specific Formats and Procedures, are not considered and are replaced
by FECFRAME specific Formats and Procedures.
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 media delivery applications (e.g., a ADUs) coming from one or several media delivery applications (e.g., a
set of RTP packets), are grouped in an ADU block and FEC encoded as a set of RTP packets), are grouped in an ADU block and FEC encoded as a
whole. With Reed-Solomon codes over GF(2^^8), there is a strict whole. With Reed-Solomon codes over GF(2^^8), there is a strict
limit over the number of ADUs that can be protected together, since limit over the number of ADUs that can be protected together, since
the number of encoded symbols, n, must be inferior or equal to 255. the number of encoded symbols, n, must be inferior or equal to 255.
This constraint is relaxed when using a higher finite field size (m > This constraint is relaxed when using a higher finite field size (m >
8), at the price of an increased computational complexity. 8), at the price of an increased computational complexity.
2. Terminology 2. Terminology
skipping to change at page 5, line 32 skipping to change at page 4, line 36
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Definitions Notations and Abbreviations 3. Definitions Notations and Abbreviations
3.1. Definitions 3.1. Definitions
This document uses the following terms and definitions. Some of them This document uses the following terms and definitions. Some of them
are FEC scheme specific and are in line with [RFC5052]: are FEC scheme specific and are in line with [RFC5052]:
Source symbol: unit of data used during the encoding process. In Source symbol: unit of data used during the encoding process. In
this specification, there is always one source symbol per ADU. this specification, there is always one source symbol per ADU.
Encoding symbol: unit of data generated by the encoding process. Encoding symbol: unit of data generated by the encoding process.
With systematic codes, source symbols are part of the encoding With systematic codes, source symbols are part of the encoding
symbols. symbols.
Repair symbol: encoding symbol that is not a source symbol. Repair symbol: encoding symbol that is not a source symbol.
Code rate: the k/n ratio, i.e., the ratio between the number of Code rate: the k/n ratio, i.e., the ratio between the number of
source symbols and the number of encoding symbols. By definition, source symbols and the number of encoding symbols. By definition,
the code rate is such that: 0 < code rate <= 1. A code rate close 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 to 1 indicates that a small number of repair symbols have been
produced during the encoding process. produced during the encoding process.
Systematic code: FEC code in which the source symbols are part of Systematic code: FEC code in which the source symbols are part of
the encoding symbols. The Reed-Solomon codes introduced in this the encoding symbols. The Reed-Solomon codes introduced in this
document are systematic. document are systematic.
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): The unit of source data provided as Application Data Unit (ADU): The unit of source data provided as
payload to the transport layer. Depending on the use-case, an ADU payload to the transport layer. Depending on the use-case, an ADU
may use an RTP encapsulation. may use an RTP encapsulation.
(Source) ADU Flow: A sequence of ADUs associated with a transport- (Source) ADU Flow: A sequence of ADUs associated with a transport-
layer flow identifier (such as the standard 5-tuple {Source IP layer flow identifier (such as the standard 5-tuple {Source IP
address, source port, destination IP address, destination port, address, source port, destination IP address, destination port,
transport protocol}). Depending on the use-case, several ADU transport protocol}). Depending on the use-case, several ADU
flows may be protected together by the FECFRAME 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 flow ID (F[]), length (L[]), and padding (Pad[]) fields, they
symbols over which FEC encoding will be performed. form the set of source 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: Information which controls
the operation of the FEC Framework. The FFCI enables the FEC Framework Configuration Information (FFCI): Information which
controls the operation of the FEC Framework. The FFCI enables the
synchronization of the FECFRAME sender and receiver instances. synchronization of the FECFRAME sender and receiver instances.
FEC Source Packet: At a sender (respectively, at a receiver) a FEC Source Packet: At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the transport payload submitted to (respectively, received from) the transport
protocol containing an ADU along with an Explicit Source FEC protocol containing an ADU along with an Explicit Source FEC
Payload ID (that must be present in the FEC scheme defined by the Payload ID (that must be present in the FEC scheme defined by the
present document, see Section 5.1.2). present document, see Section 5.1.2).
FEC Repair Packet: At a sender (respectively, at a receiver) a FEC Repair Packet: At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the transport payload submitted to (respectively, received from) the transport
protocol containing one repair symbol along with a Repair FEC protocol containing one repair symbol along with a Repair FEC
Payload ID and possibly an RTP header. 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 |
skipping to change at page 9, line 14 skipping to change at page 8, line 48
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), the and taking into account the known or estimated packet loss rate), 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 MAY have real-time constraints. When there are The source ADU flows can have real-time constraints. When there are
multiple flows, with different real-time constraints, let us consider multiple flows, with different real-time constraints, let us consider
the most stringent constraints (see [RFC6363], section 10.2, item 6 the most stringent constraints (see [RFC6363], section 10.2, item 6
for recommendations when several flows are globally protected). In for recommendations when several flows are globally protected). In
that case the maximum number of ADUs of an ADU block must not exceed that case the maximum number of ADUs of an ADU block must not exceed
a certain threshold since it directly impacts the decoding delay. a certain threshold since it directly impacts the decoding delay.
The larger the ADU block size, the longer a decoder may have to wait The larger the ADU block size, the longer a decoder may have to wait
until it has received a sufficient number of encoding symbols for until it has received a sufficient number of encoding symbols for
decoding to succeed, and therefore the larger the decoding delay. decoding to succeed, and therefore the larger the decoding delay.
When the target use-case is known, these real-time constraints result When the target use-case is known, these real-time constraints result
in an upper bound to the ADU block size, max_rt. in an upper bound to the ADU block size, max_rt.
skipping to change at page 10, line 33 skipping to change at page 10, line 25
the largest ADU of this source block plus three (for the prepended 3 the largest ADU of this source block plus three (for the prepended 3
bytes, see below). If this is not the case, an error is returned. bytes, see below). If this is not the case, an error is returned.
How to handle this error is use-case specific (e.g., a larger E How to handle this error is use-case specific (e.g., a larger E
parameter may be communicated to the receivers in an updated FFCI parameter may be communicated to the receivers in an updated FFCI
message, using an appropriate mechanism) and is not considered by message, using an appropriate mechanism) and is not considered by
this specification. this specification.
The ADU block is always encoded as a single source block. There are The ADU block is always encoded as a single source block. There are
a total of B <= max_B ADUs in this ADU block. For the ADU i, with 0 a total of B <= max_B ADUs in this ADU block. For the ADU i, with 0
<= i <= B-1, 3 bytes are prepended (Figure 2): <= i <= B-1, 3 bytes are prepended (Figure 2):
o The first byte, FID[i] (Flow ID), contains the integer identifier
o The first byte, F[i] (Flow ID), contains the integer identifier
associated to the source ADU flow to which this ADU belongs to. associated to the source ADU flow to which this ADU belongs to.
It is assumed that a single byte is sufficient, or said It is assumed that a single byte is sufficient, or said
differently, that no more than 256 flows will be protected by a differently, that no more than 256 flows will be protected by a
single instance of the FECFRAME framework. single instance of the FECFRAME framework.
o The following two bytes, L[i] (Length), contain the length of this o The following two bytes, L[i] (Length), contain the length of this
ADU, in network byte order (i.e., big endian). This length is for ADU, in network byte order (i.e., big endian). This length is for
the ADU itself and does not include the FID[i], L[i], or Pad[i] the ADU itself and does not include the F[i], L[i], or Pad[i]
fields. fields.
Then zero padding is added to ADU i (if needed) in field Pad[i], for Then zero padding is added to ADU i (if needed) in field Pad[i], for
alignment purposes up to a size of exactly E bytes. The data unit alignment purposes up to a size of exactly E bytes. The data unit
resulting from the ADU i and the F[i], L[i] and Pad[i] fields, is resulting from the ADU i and the F[i], L[i] and Pad[i] fields, is
called ADU Information (or ADUI). Each ADUI contributes to exactly called ADU Information (or ADUI). Each ADUI contributes to exactly
one source symbol to the source block. one source symbol of the source block.
Encoding Symbol Length (E) Encoding Symbol Length (E)
< -------------------------------------------------------------- > < -------------------------------------------------------------- >
+----+----+-----------------------+------------------------------+ +----+----+-----------------------+------------------------------+
|F[0]|L[0]| ADU[0] | Pad[0] | |F[0]|L[0]| ADU[0] | Pad[0] |
+----+----+----------+------------+------------------------------+ +----+----+----------+------------+------------------------------+
|F[1]|L[1]| ADU[1] | Pad[1] | |F[1]|L[1]| ADU[1] | Pad[1] |
+----+----+----------+-------------------------------------------+ +----+----+----------+-------------------------------------------+
|F[2]|L[2]| ADU[2] | |F[2]|L[2]| ADU[2] |
+----+----+------+-----------------------------------------------+ +----+----+------+-----------------------------------------------+
skipping to change at page 11, line 51 skipping to change at page 11, line 51
This Fully-Specified FEC Scheme specifies the use of Reed-Solomon This Fully-Specified FEC Scheme specifies the use of Reed-Solomon
codes over GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding codes over GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding
for arbitrary packet flows. for arbitrary packet flows.
5.1. Formats and Codes 5.1. Formats and Codes
5.1.1. FEC Framework Configuration Information 5.1.1. FEC Framework Configuration Information
The FEC Framework Configuration Information (or FFCI) includes The FEC Framework Configuration Information (or FFCI) includes
information that MUST be communicated between the sender and information that must be communicated between the sender and
receiver(s). More specifically, it enables the synchronization of receiver(s) [RFC6363]. More specifically, it enables the
the FECFRAME sender and receiver instances. It includes both synchronization of the FECFRAME sender and receiver instances. It
mandatory elements and scheme-specific elements, as detailed below. includes both mandatory elements and scheme-specific elements, as
detailed below.
5.1.1.1. Mandatory Information 5.1.1.1. Mandatory Information
FEC Encoding ID: the value assigned to this fully-specified FEC o 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
carried in the 'encoding-id' parameter. When SDP is used to communicate the FFCI, this FEC Encoding ID MUST
be carried in the 'encoding-id' parameter of the 'fec-repair-flow'
attribute specified in RFC 6364 [RFC6364].
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
o 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
o 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
in the finite field, in bits. We have: 2 <= m <= 16. o m parameter (m): an integer that defines the length of the
elements 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 MUST be carried in the 'fssi' parameter of the 'fec-
representation as specified in [RFC6364]. For instance: repair-flow' attribute, in textual representation as specified in RFC
6364 [RFC6364]. For instance:
fssi=E:1400,S:0,m:8 a=fec-repair-flow: encoding-id=XXX; 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 of Figure 3: format consists of the following 3 octets of Figure 3:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) |S| m | | Encoding Symbol Length (E) |S| m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FSSI encoding format. Figure 3: FSSI encoding format.
skipping to change at page 13, line 35 skipping to change at page 13, line 41
| Explicit Source FEC Payload ID | | Explicit Source FEC Payload ID |
+--------------------------------+ +--------------------------------+
Figure 4: Structure of a FEC Source Packet with the Explicit Source Figure 4: Structure of a FEC Source Packet with the Explicit Source
FEC Payload ID. FEC Payload ID.
More precisely, the Explicit Source FEC Payload ID is composed of the More precisely, the Explicit Source FEC Payload ID is composed of the
Source Block Number, the Encoding Symbol ID, and the Source Block Source Block Number, the Encoding Symbol ID, and the Source Block
Length. The length of the first two fields depends on the m Length. The length of the first two fields depends on the m
parameter (transmitted separately in the FFCI, Section 5.1.1.2): parameter (transmitted separately in the FFCI, Section 5.1.1.2):
Source Block Number (SBN) (32-m bit field): this field identifies
o Source Block Number (SBN) (32-m bit field): this field identifies
the source block to which this FEC source packet belongs. the source block to which this FEC source packet belongs.
Encoding Symbol ID (ESI) (m bit field): this field identifies the
o Encoding Symbol ID (ESI) (m bit field): this field identifies the
source symbol contained in this FEC source packet. This value is source symbol contained in this FEC source packet. This value is
such that 0 <= ESI <= k - 1 for source symbols. such that 0 <= ESI <= k - 1 for source symbols.
Source Block Length (k) (16 bit field): this field provides the
o Source Block Length (k) (16 bit field): this field provides the
number of source symbols for this source block, i.e., the k number of source symbols for this source block, i.e., the k
parameter. If 16 bits are too much when m <= 8, it is needed when parameter. If 16 bits are too much when m <= 8, it is needed when
8 < m <= 16. Therefore we provide a single common format 8 < m <= 16. Therefore we provide a single common format
regardless of m. regardless of m.
0 1 2 3 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 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 | | Source Block Number (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 5 skipping to change at page 15, line 8
+--------------------------------+ +--------------------------------+
Figure 7: Structure of a FEC Repair Packet with the Repair FEC Figure 7: Structure of a FEC Repair Packet with the Repair FEC
Payload ID. Payload ID.
More precisely, the Repair FEC Payload ID is composed of the Source More precisely, the Repair FEC Payload ID is composed of the Source
Block Number, the Encoding Symbol ID, and the Source Block Length. Block Number, the Encoding Symbol ID, and the Source Block Length.
The length of the first two fields depends on the m parameter The length of the first two fields depends on the m parameter
(transmitted separately in the FFCI, Section 5.1.1.2): (transmitted separately in the FFCI, Section 5.1.1.2):
Source Block Number (SBN) (32-m bit field): this field identifies o Source Block Number (SBN) (32-m bit field): this field identifies
the source block to which the FEC repair packet belongs. the source block to which the FEC repair packet belongs.
Encoding Symbol ID (ESI) (m bit field) this field identifies the
o Encoding Symbol ID (ESI) (m bit field): this field identifies the
repair symbol contained in this FEC repair packet. This value is repair symbol contained in this FEC repair packet. This value is
such that k <= ESI <= n - 1 for repair symbols. such that k <= ESI <= n - 1 for repair symbols.
Source Block Length (k) (16 bit field): this field provides the
o Source Block Length (k) (16 bit field): this field provides the
number of source symbols for this source block, i.e., the k number of source symbols for this source block, i.e., the k
parameter. If 16 bits are too much when m <= 8, it is needed when parameter. If 16 bits are too much when m <= 8, it is needed when
8 < m <= 16. Therefore we provide a single common format 8 < m <= 16. Therefore we provide a single common format
regardless of m. regardless of m.
0 1 2 3 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 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 | | Source Block Number (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 10 skipping to change at page 16, line 20
o The ESI of encoding symbols MUST start with value 0 for the first o The ESI of encoding symbols MUST start with value 0 for the first
symbol and MUST be managed sequentially. The first k values (0 <= symbol and MUST be managed sequentially. The first k values (0 <=
ESI <= k - 1) identify source symbols whereas the last n-k values ESI <= k - 1) identify source symbols whereas the last n-k values
(k <= ESI <= n - 1) identify repair symbols. (k <= ESI <= n - 1) identify repair symbols.
o The FEC repair packet creation MUST follow the procedures o The FEC repair packet creation MUST follow the procedures
specified in Section 5.1.3. specified in 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], Section 8 "Reed-Solomon
core Reed-Solomon codes based on Vandermonde matrices for a packet Codes Specification for the Erasure Channel", the specifications of
transmission channel. the core Reed-Solomon codes based on Vandermonde matrices.
6. Security Considerations 6. Security Considerations
The FEC Framework document [RFC6363] provides a comprehensive The FEC Framework document [RFC6363] provides a comprehensive
analysis of security considerations applicable to FEC schemes. analysis of security considerations applicable to FEC schemes.
Therefore the present section follows the security considerations Therefore the present section follows the security considerations
section of [RFC6363] and only discusses topics that are specific to section of [RFC6363] and only discusses 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 [RFC6363]. 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 [RFC6363] is used, with special considerations solutions mentioned in [RFC6363] is used, with special considerations
to the way this solution is applied (e.g., before versus after FEC to the way this solution is applied (e.g., is encryption applied
protection, and within the end-system versus in a middlebox), to the before or after FEC protection, within the end-system or in a
operational constraints (e.g., performing FEC decoding in a protected middlebox), to the operational constraints (e.g., performing FEC
environment may be complicated or even impossible) and to the threat decoding in a protected environment may be complicated or even
model. impossible) and to the threat 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 [RFC6363]. To summarize, it is change the recommendations of [RFC6363]. To summarize, it is
RECOMMENDED that one of the solutions mentioned in [RFC6363] is used RECOMMENDED that one of the solutions mentioned in [RFC6363] is used
on both the FEC Source and Repair Packets. on both the FEC Source and Repair Packets.
6.2. Attacks Against the FEC Parameters 6.2. Attacks Against the FEC Parameters
skipping to change at page 19, line 11 skipping to change at page 19, line 20
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.
[RFC6363] defines general guidelines on IANA considerations. In [RFC6363] defines general guidelines on IANA considerations. In
particular it defines a registry called FEC Framework (FECFRAME) FEC particular it defines the "FEC Framework (FECFRAME) FEC Encoding IDs"
Encoding IDs whose values are granted on an IETF Consensus basis. subregistry of the "Reliable Multicast Transport (RMT) FEC Encoding
IDs and FEC Instance IDs" registry, 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 subregistry 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 and Ali Begen for their The authors want to thank Hitoshi Asaeda and Ali Begen for their
valuable comments. 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.
[RFC6364] Begen, A., "Session Description Protocol Elements for the [RFC6364] Begen, A., "Session Description Protocol Elements for
Forward Error Correction (FEC) Framework", RFC 6364, the Forward Error Correction (FEC) Framework",
October 2011. RFC 6364, October 2011.
10.2. Informative References 10.2. Informative References
[RS-codec] [RS-codec] Rizzo, L., "Reed-Solomon FEC codec (C language)",
Rizzo, L., "Reed-Solomon FEC codec (C language)", original original codec: http://info.iet.unipi.it/~luigi/vdm98/
codec: http://info.iet.unipi.it/~luigi/vdm98/ vdm980702.tgz, improved codec: http://openfec.org/,
vdm980702.tgz, improved codec: http://openfec.org/, July 1998.
July 1998.
[Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer [Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable
Communication Protocols", ACM SIGCOMM Computer Computer Communication Protocols", ACM SIGCOMM
Communication Review Vol.27, No.2, pp.24-36, April 1997. Computer Communication Review Vol.27, No.2, pp.24-36,
April 1997.
[Matsuzono10] [Matsuzono10] Matsuzono, K., Detchart, J., Cunche, M., Roca, V., and
Matsuzono, K., Detchart, J., Cunche, M., Roca, V., and H. H. Asaeda, "Performance Analysis of a High-Performance
Asaeda, "Performance Analysis of a High-Performance Real- Real-Time Application with Several AL-FEC Schemes",
Time Application with Several AL-FEC Schemes", 35th Annual 35th Annual IEEE Conference on Local Computer
IEEE Conference on Local Computer Networks (LCN 2010), Networks (LCN 2010), October 2010.
October 2010.
[RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density
Check (LDPC) Forward Error Correction", RFC 5170, Parity Check (LDPC) Forward Error Correction",
June 2008. RFC 5170, June 2008.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T.
"Raptor Forward Error Correction Scheme", RFC 5053, Stockhammer, "Raptor Forward Error Correction Scheme
June 2007. for Object Delivery", RFC 5053, June 2007.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775, Layered Coding (ALC) Protocol Instantiation",
April 2010. RFC 5775, April 2010.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable "Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", RFC 5740, November 2009. Multicast (NORM) Protocol", RFC 5740, November 2009.
Authors' Addresses Authors' Addresses
Vincent Roca Vincent Roca
INRIA INRIA
655, av. de l'Europe 655, av. de l'Europe
Inovallee; Montbonnot Inovallee; Montbonnot
ST ISMIER cedex 38334 ST ISMIER cedex 38334
France France
Email: vincent.roca@inria.fr EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/ URI: http://planete.inrialpes.fr/people/roca/
Mathieu Cunche Mathieu Cunche
INSA-Lyon/INRIA INSA-Lyon/INRIA
Laboratoire CITI Laboratoire CITI
6 av. des Arts 6 av. des Arts
Villeurbanne cedex 69621 Villeurbanne cedex 69621
France France
Email: mathieu.cunche@inria.fr EMail: mathieu.cunche@inria.fr
URI: http://mathieu.cunche.free.fr/ URI: http://mathieu.cunche.free.fr/
Jerome Lacan Jerome Lacan
ISAE, Univ. of Toulouse ISAE, Univ. of Toulouse
10 av. Edouard Belin; BP 54032 10 av. Edouard Belin; BP 54032
Toulouse cedex 4 31055 Toulouse cedex 4 31055
France France
Email: jerome.lacan@isae.fr EMail: jerome.lacan@isae.fr
URI: http://personnel.isae.fr/jerome-lacan/ URI: http://personnel.isae.fr/jerome-lacan/
Amine Bouabdallah Amine Bouabdallah
ISAE, Univ. of Toulouse CDTA
10 av. Edouard Belin; BP 54032 Center for Development of Advanced Technologies
Toulouse cedex 4 31055 Cite 20 aout 1956, Baba Hassen
France Algiers
Algeria
Email: amine.bouabdallah@gmail.com
EMail: abouabdallah@cdta.dz
Kazuhisa Matsuzono Kazuhisa Matsuzono
Keio University Keio University
Graduate School of Media and Governance Graduate School of Media and Governance
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
Email: kazuhisa@sfc.wide.ad.jp EMail: kazuhisa@sfc.wide.ad.jp
 End of changes. 74 change blocks. 
111 lines changed or deleted 151 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/