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/ |