draft-ietf-fecframe-ldpc-02.txt   draft-ietf-fecframe-ldpc-03.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 9, 2012 NICTA Expires: April 7, 2013 INSA-Lyon/INRIA
J. Lacan J. Lacan
ISAE/LAAS-CNRS ISAE, Univ. of Toulouse
March 8, 2012 October 4, 2012
Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME
draft-ietf-fecframe-ldpc-02 draft-ietf-fecframe-ldpc-03
Abstract Abstract
This document describes a fully-specified simple FEC scheme for LDPC- This document describes a fully-specified simple FEC scheme for LDPC-
Staircase codes that can be used to protect media streams along the Staircase codes that can be used to protect media streams along the
lines defined by the FECFRAME framework. These codes have many lines defined by the FECFRAME framework. These codes have many
interesting properties: they are systematic codes, they perform close interesting properties: they are systematic codes, they perform close
to ideal codes in many use-cases and they also feature very high to ideal codes in many use-cases and they also feature very high
encoding and decoding throughputs. LDPC-Staircase codes are encoding and decoding throughputs. LDPC-Staircase codes are
therefore a good solution to protect a single high bitrate source therefore a good solution to protect a single high bitrate source
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 9, 2012. This Internet-Draft will expire on April 7, 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 7 4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 7
4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 9 4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 9
5. LDPC-Staircase FEC Scheme for Arbitrary ADU Flows . . . . . . 10 5. LDPC-Staircase FEC Scheme for Arbitrary ADU Flows . . . . . . 10
5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 10 5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 10
5.1.1. FEC Framework Configuration Information . . . . . . . 10 5.1.1. FEC Framework Configuration Information . . . . . . . 10
5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 12 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 12
5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 14 5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . 15 6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 15
6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 15 6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 15
6.3. When Several Source Flows are to be Protected Together . . 16 6.3. When Several Source Flows are to be Protected Together . . 16
6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 16 6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 16
7. Operations and Management Considerations . . . . . . . . . . . 16 7. Operations and Management Considerations . . . . . . . . . . . 16
7.1. Operational Recommendations . . . . . . . . . . . . . . . 16 7.1. Operational Recommendations . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 [RFC3453]. The Content Delivery Protocols (CDP) and applications [RFC3453]. The
[RFC6363] document describes a generic framework to use FEC schemes [RFC6363] document describes a generic framework to use FEC schemes
with media delivery applications, and for instance with real-time with media delivery applications, and for instance with real-time
streaming media applications based on the RTP real-time protocol. streaming media applications based on the RTP real-time protocol.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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;
o the use of the LDPC-Staircase scheme is such that there MUST be o the use of the LDPC-Staircase scheme is such that there MUST be
exactly one encoding symbol per group, i.e., G MUST be equal to 1 exactly one encoding symbol per group, i.e., G MUST be equal to 1
[RFC5170]; [RFC5170];
4.2. ADU Block Creation 4.2. ADU Block Creation
Two kinds of limitations MUST be considered, that impact the ADU Two kinds of limitations exist that impact the ADU block creation:
block creation:
o at the FEC Scheme level: the FEC Scheme and the FEC codec have o at the FEC Scheme level: the FEC Scheme and the FEC codec have
limitations that define a maximum source block size; limitations that define a maximum source block size;
o at the FECFRAME instance level: the target use-case MAY have real- o at the FECFRAME instance level: the target use-case can have real-
time constraints that MAY define a maximum ADU block size; time constraints that can/will define a maximum ADU block size;
Note that terminology "maximum source block size" and "maximum ADU Note that terminology "maximum source block size" and "maximum ADU
block size" depends on the point of view that is adopted (FEC Scheme block size" depends on the point of view that is adopted (FEC Scheme
versus FECFRAME instance). However, in this document, both refer to versus FECFRAME instance). However, in this document, both refer to
the same value since Section 4.1 requires there is exactly one source the same value since Section 4.1 requires there is exactly one source
symbol per ADU. We now detail each of these aspects. symbol per ADU. We now detail each of these aspects.
The maximum source block size in symbols, max_k, depends on several The maximum source block size in symbols, max_k, depends on several
parameters: the code rate (CR), the Encoding Symbol ID (ESI) field parameters: the code rate (CR), the Encoding Symbol ID (ESI) field
length in the Explicit Source/Repair FEC Payload ID (16 bits), as length in the Explicit Source/Repair FEC Payload ID (16 bits), as
well as possible internal codec limitations. More specifically, well as possible internal codec limitations. More specifically,
max_k cannot be larger than the following values, derived from the max_k cannot be larger than the following values, derived from the
ESI field size limitation, for a given code rate: ESI field size limitation, for a given code rate:
max1_k = 2^^(16 - ceil(Log2(1/CR))) max1_k = 2^^(16 - ceil(Log2(1/CR)))
Some common max1_k values are: Some common max1_k values are:
o CR == 1 (no repair symbol): max1_k = 2^^16 = 65536 symbols o CR == 1 (no repair symbol): max1_k = 2^^16 = 65536 symbols
o 1/2 <= CR < 1: max1_k = 2^^15 = 32,768 symbols o 1/2 <= CR < 1: max1_k = 2^^15 = 32,768 symbols
o 1/4 <= CR < 1/2: max1_k = 2^^14 = 16,384 symbols o 1/4 <= CR < 1/2: max1_k = 2^^14 = 16,384 symbols
Additionally, a codec MAY impose other limitations on the maximum Additionally, a codec can impose other limitations on the maximum
source block size, for instance, because of a limited working memory source block size, for instance, because of a limited working memory
size. This decision MUST be clarified at implementation time, when size. This decision MUST be clarified at implementation time, when
the target use-case is known. This results in a max2_k limitation. the target use-case is known. This results in a max2_k limitation.
Then, max_k is given by: Then, max_k is given by:
max_k = min(max1_k, max2_k) max_k = min(max1_k, max2_k)
Note that this calculation is only required at the encoder (sender), Note that this calculation is only required at the encoder (sender),
since the actual k parameter (k <= max_k) is communicated to the since the actual k parameter (k <= max_k) is communicated to the
decoder (receiver) through the Explicit Source/Repair FEC Payload ID. decoder (receiver) through the Explicit Source/Repair FEC Payload ID.
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 14, line 18 skipping to change at page 14, line 18
| Source Block Number (SBN) | Encoding Symbol ID (ESI) | | Source Block Number (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) | Number Encoding Symbols (n) | | Source Block Length (k) | Number Encoding Symbols (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Repair FEC Payload ID encoding format. Figure 7: Repair FEC Payload ID encoding format.
5.2. Procedures 5.2. Procedures
The following procedures apply: The following procedures apply:
o The source block creation procedures are specified in Section 4.3. o The source block creation MUST follow the procedures specified in
o The SBN value is incremented for each new source block, starting Section 4.3.
at 0 for the first block of the ADU flow. Wrapping to zero will o The SBN value MUST start with value 0 for the first block of the
happen for long sessions, after value 2^^16 - 1. ADU flow and MUST be incremented by 1 for each new source block.
o The ESI of encoding symbols is managed sequentially, starting at 0 Wrapping to zero will happen for long sessions, after value 2^^16
for the first symbol. The first k values (0 <= ESI <= k - 1) - 1.
identify source symbols, whereas the last n-k values (k <= ESI <= o The ESI of encoding symbols MUST start with value 0 for the first
n - 1) identify repair symbols. symbol and MUST be managed sequentially. The first k values (0 <=
o The FEC repair packet creation procedures are specified in ESI <= k - 1) identify source symbols whereas the last n-k values
Section 5.1.3. (k <= ESI <= n - 1) identify repair symbols.
o The FEC repair packet creation MUST follow the procedures
specified in Section 5.1.3.
5.3. FEC Code Specification 5.3. FEC Code Specification
The present document inherits from [RFC5170] the specification of the The present document inherits from [RFC5170] the specification of the
core LDPC-Staircase codes for a packet erasure transmission channel. core LDPC-Staircase codes for a packet erasure transmission channel.
Because of the requirement to have exactly one encoding symbol per Because of the requirement to have exactly one encoding symbol per
group, i.e., because G MUST be equal to 1 (Section 4.1), several group, i.e., because G MUST be equal to 1 (Section 4.1), several
parts of [RFC5170] are useless. In particular, this is the case of parts of [RFC5170] are useless. In particular, this is the case of
Section 5.6. "Identifying the G Symbols of an Encoding Symbol Section 5.6. "Identifying the G Symbols of an Encoding Symbol
skipping to change at page 16, line 49 skipping to change at page 16, line 49
The FEC Framework document [RFC6363] provides a comprehensive The FEC Framework document [RFC6363] provides a comprehensive
analysis of operations and management considerations applicable to analysis of operations and management considerations applicable to
FEC schemes. Therefore the present section only discusses topics FEC schemes. Therefore the present section only discusses topics
that are specific to the use of LDPC-Staircase codes as specified in that are specific to the use of LDPC-Staircase codes as specified in
this document. this document.
7.1. Operational Recommendations 7.1. Operational Recommendations
LDPC-Staircase codes have excellent erasure recovery capabilities LDPC-Staircase codes have excellent erasure recovery capabilities
with large source blocks, close to ideal MDS codes. For instance, with large source blocks, close to ideal MDS codes. For instance,
independently of FECFRAME, with source block size k=1024, CR=2/3, independently of FECFRAME, with source block size k=1024 symbols,
N1=5, G=1, with a hybrid ITerative/Maximum Likelihood (IT/ML) CR=2/3, N1=7, G=1, a hybrid ITerative/Maximum Likelihood (IT/ML)
decoding approach (see below) and when all symbols are sent in a decoding approach (see below) and when all symbols are sent in a
random order (see below), the average overhead amounts to 0.64% random order, the average overhead amounts to 0.237% (i.e., receiving
(corresponding to 6.5 symbols in addition to k) and receiving 1046 2.43 symbols in addition to k enables a successful decoding with a
symbols (corresponding to a 2.1% overhead) is sufficient to reduce probability 0.5) and an overhead of 1.46% (i.e., receiving 15 symbols
the decoding failure probability to 5.9*10^^-5. This is why these in addition to k) is sufficient to reduce the decoding failure
codes are a good solution to protect a single high bitrate source probability to 8.2*10^^-5. This is why these codes are a good
flow as in [Matsuzono10], or to protect globally several mid-rate solution to protect a single high bitrate source flow as in
source flows within a single FECFRAME instance: in both cases the [Matsuzono10], or to protect globally several mid-rate source flows
source block size can be assumed to be equal to a few hundreds (or within a single FECFRAME instance: in both cases the source block
more) source symbols. size can be assumed to be equal to a few hundreds (or more) source
symbols.
LDPC-Staircase codes are also a good solution whenever processing LDPC-Staircase codes are also a good solution whenever processing
requirements at a software encoder or decoder must be kept to a requirements at a software encoder or decoder must be kept to a
minimum. This is true when the decoder uses an IT decoding minimum. This is true when the decoder uses an IT decoding
algorithm, or an ML algorithm (we use a Gaussian Elimination as the algorithm, or an ML algorithm (we use a Gaussian Elimination as the
ML algorithm) when this latter is carefully implemented and the ML algorithm) when this latter is carefully implemented, or a mixture
source block size kept reasonable, or a mixture of both techniques of both techniques which is the recommended solution
which is the recommended solution [Cunche08][CunchePHD10]. For [Cunche08][CunchePHD10][LDPC-codec-OpenFEC]. For instance an average
instance an average decoding speed between 1.3 Gbps (corresponding to decoding speed between 1.78 Gbps (overhead of 2 symbols in addition
a very bad channel, close to the theoretical decoding limit and to k, corresponding to a very bad channel, close to the theoretical
requiring an ML decoding) and 4.3 Gbps (corresponding to a medium decoding limit, where ML decoding is required) and 3.41 Gbps
quality channel where IT decoding is sufficient) are easily achieved (corresponding to a medium quality channel where IT decoding is
with a source block size composed of k=1024 source symbols, a code sufficient) is easily achieved with a source block size composed of
rate CR=2/3 (i.e., 512 repair symbols), 1024 byte long symbols, G=1, k=1024 source symbols, a code rate CR=2/3 (i.e., 512 repair symbols),
and N1=5, on an Intel Xeon 5120/1.86GHz workstation running Linux/64 1024 byte long symbols, G=1, and N1=7, on an Intel Xeon 5120/1.86GHz
bits. Additionally, with a hybrid IT/ML approach, a receiver can workstation running Linux/64 bits. Under the same conditions, on a
decide if and when ML decoding is used, depending on local criteria Samsung Galaxy SII (GT-I9100P model, featuring an ARM Cortex-A9/1.2
(e.g., battery or CPU capabilities), independently from other GHz processor and running Android 2.3.4), decoding speed is between
receivers. 278 Mbps (overhead of 2 symbols and ML decoding) and 626 Mbps (IT
decoding).
As the source block size decreases, the erasure recovery capabilities As the source block size decreases, the erasure recovery capabilities
of LDPC codes in general also decrease. In the case of LDPC- of LDPC codes in general also decrease. In the case of LDPC-
Staircase codes, in order to compensate this phenomenon, it is Staircase codes, in order to limit this phenomenon, it is recommended
recommended to increase the N1 parameter (e.g., experiments carried to use a value of the N1 parameter at least equal to 7 (e.g.,
out in [Matsuzono10] use N1=7 if k=170 symbols, and N1=5 otherwise) experiments carried out in [Matsuzono10] use N1=7 if k=170 symbols,
and to use a hybrid IT/ML decoding approach. For instance, and N1=5 otherwise). For instance, independently of FECFRAME, with
independently of FECFRAME, with a small source block size k=256 source block size k=256 symbols, CR=2/3, N1=7, and G=1, the average
symbols, CR=2/3, N1=7, and G=1, 8he average overhead amounts to 0.71% overhead amounts to 0.706% (i.e., receiving 1.8 symbols in addition
(corresponding to 1.8 symbols in addition to k), and receiving 271 to k enables a successful decoding with a probability 0.5), and an
symbols (corresponding to a 5.9% overhead) is sufficient to reduce overhead of 5.86% (i.e., receiving 15 symbols ina addition to k) is
the decoding failure probability to 5.9*10^^-5. Using N1=9 or 10 sufficient to reduce the decoding failure probability to 5.9*10^^-5.
further improves these results if need be, which also enables to use
LDPC-Staircase codes with k=100 symbols for instance.
With very small source blocks (e.g., a few tens symbols), using for With very small source blocks (e.g., a few tens of symbols), using
instance Reed-Solomon codes [SIMPLE_RS] or 2D parity check codes MAY for instance Reed-Solomon codes [SIMPLE_RS] or 2D parity check codes
be more appropriate. may be more appropriate.
The way the FEC Repair Packets are transmitted is of high importance. The way the FEC Repair Packets are transmitted is of high importance.
A good strategy, that works well for any kind of channel loss model, A good strategy, that works well for any kind of channel loss model,
consists in sending FEC Repair Packets in random order (rather than consists in sending FEC Repair Packets in random order (rather than
in sequence) while FEC Source Packets are sent first and in sequence. in sequence) while FEC Source Packets are sent first and in sequence.
Sending all packets in a random order is another possibility, but it Sending all packets in a random order is another possibility, but it
requires that all repair symbols for a source block be produced requires that all repair symbols for a source block be produced
first, which adds some extra delay at a sender. first, which adds some extra delay at a sender.
8. IANA Considerations 8. IANA Considerations
Values of FEC Encoding IDs are subject to IANA registration.
[RFC6363] defines general guidelines on IANA considerations. In
particular it defines a registry called FEC Framework (FECFRAME) FEC
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 [RFC6363] as follows:
o XXX refers to the Simple LDPC-Staircase [RFC5170] FEC Scheme for o XXX refers to the Simple LDPC-Staircase FEC Scheme for Arbitrary
Arbitrary Packet Flows. Packet Flows, as defined in Section 5 of this document.
9. Acknowledgments 9. Acknowledgments
The authors want to thank K. Matsuzono, J. Detchart and H. Asaeda for The authors want to thank K. Matsuzono, J. Detchart and H. Asaeda for
their contributions in evaluating the use of LDPC-Staircase codes in their contributions in evaluating the use of LDPC-Staircase codes in
the context of FECFRAME [Matsuzono10]. the context of FECFRAME [Matsuzono10].
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 20, line 32 skipping to change at page 20, line 24
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
NICTA INSA-Lyon/INRIA
Australia Laboratoire CITI
6 av. des Arts
Villeurbanne cedex 69621
France
Email: mathieu.cunche@nicta.com.au Email: mathieu.cunche@inria.fr
URI: http://mathieu.cunche.free.fr/ URI: http://mathieu.cunche.free.fr/
Jerome Lacan Jerome Lacan
ISAE/LAAS-CNRS ISAE, Univ. of Toulouse
1, place Emile Blouin 10 av. Edouard Belin; BP 54032
Toulouse 31056 Toulouse cedex 4 31055
France France
Email: jerome.lacan@isae.fr Email: jerome.lacan@isae.fr
URI: http://dmi.ensica.fr/auteur.php3?id_auteur=5 URI: http://personnel.isae.fr/jerome-lacan/
 End of changes. 22 change blocks. 
76 lines changed or deleted 75 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/