draft-ietf-tsvwg-rlc-fec-scheme-07.txt   draft-ietf-tsvwg-rlc-fec-scheme-08.txt 
TSVWG V. Roca TSVWG V. Roca
Internet-Draft B. Teibi Internet-Draft B. Teibi
Intended status: Standards Track INRIA Intended status: Standards Track INRIA
Expires: March 11, 2019 September 7, 2018 Expires: March 23, 2019 September 19, 2018
Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC)
Schemes for FECFRAME Schemes for FECFRAME
draft-ietf-tsvwg-rlc-fec-scheme-07 draft-ietf-tsvwg-rlc-fec-scheme-08
Abstract Abstract
This document describes two fully-specified Forward Erasure This document describes two fully-specified Forward Erasure
Correction (FEC) Schemes for Sliding Window Random Linear Codes Correction (FEC) Schemes for Sliding Window Random Linear Codes
(RLC), one for RLC over the Galois Field (A.K.A. Finite Field) (RLC), one for RLC over the Galois Field (A.K.A. Finite Field)
GF(2), a second one for RLC over the Galois Field GF(2^^8), each time GF(2), a second one for RLC over the Galois Field GF(2^^8), each time
with the possibility of controlling the code density. They can with the possibility of controlling the code density. They can
protect arbitrary media streams along the lines defined by FECFRAME protect arbitrary media streams along the lines defined by FECFRAME
extended to sliding window FEC codes, as defined in [fecframe-ext]. extended to sliding window FEC codes, as defined in [fecframe-ext].
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2019. This Internet-Draft will expire on March 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Possible Parameter Derivations . . . . . . . . . . . . . 7 3.1. Possible Parameter Derivations . . . . . . . . . . . . . 7
3.1.1. Case of a CBR Real-Time Flow . . . . . . . . . . . . 8 3.1.1. Case of a CBR Real-Time Flow . . . . . . . . . . . . 8
3.1.2. Other Types of Real-Time Flow . . . . . . . . . . . . 10 3.1.2. Other Types of Real-Time Flow . . . . . . . . . . . . 10
3.1.3. Case of a Non Real-Time Flow . . . . . . . . . . . . 11 3.1.3. Case of a Non Real-Time Flow . . . . . . . . . . . . 11
3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 11 3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 11
3.3. Encoding Window Management . . . . . . . . . . . . . . . 13 3.3. Encoding Window Management . . . . . . . . . . . . . . . 13
3.4. Pseudo-Random Number Generator (PRNG) . . . . . . . . . . 13 3.4. Pseudo-Random Number Generator (PRNG) . . . . . . . . . . 13
3.5. Coding Coefficients Generation Function . . . . . . . . . 14 3.5. Coding Coefficients Generation Function . . . . . . . . . 15
3.6. Finite Fields Operations . . . . . . . . . . . . . . . . 17 3.6. Finite Fields Operations . . . . . . . . . . . . . . . . 17
3.6.1. Finite Field Definitions . . . . . . . . . . . . . . 17 3.6.1. Finite Field Definitions . . . . . . . . . . . . . . 17
3.6.2. Linear Combination of Source Symbols Computation . . 17 3.6.2. Linear Combination of Source Symbols Computation . . 17
4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU 4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU
Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 18 4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 18
4.1.1. FEC Framework Configuration Information . . . . . . . 18 4.1.1. FEC Framework Configuration Information . . . . . . . 18
4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 19 4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 19
4.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 20 4.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 20
4.1.4. Additional Procedures . . . . . . . . . . . . . . . . 21 4.1.4. Additional Procedures . . . . . . . . . . . . . . . . 21
5. Sliding Window RLC FEC Scheme over GF(2) for Arbitrary ADU 5. Sliding Window RLC FEC Scheme over GF(2) for Arbitrary ADU
Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 21 5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 21
5.1.1. FEC Framework Configuration Information . . . . . . . 21 5.1.1. FEC Framework Configuration Information . . . . . . . 22
5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 22 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 22
5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 22 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 22
5.1.4. Additional Procedures . . . . . . . . . . . . . . . . 22 5.1.4. Additional Procedures . . . . . . . . . . . . . . . . 22
6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 22 6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 22
6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 23 6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 23
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 24 8.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 24
8.1.1. Access to Confidential Content . . . . . . . . . . . 24 8.1.1. Access to Confidential Content . . . . . . . . . . . 24
8.1.2. Content Corruption . . . . . . . . . . . . . . . . . 24 8.1.2. Content Corruption . . . . . . . . . . . . . . . . . 25
8.2. Attacks Against the FEC Parameters . . . . . . . . . . . 25 8.2. Attacks Against the FEC Parameters . . . . . . . . . . . 25
8.3. When Several Source Flows are to be Protected Together . 26 8.3. When Several Source Flows are to be Protected Together . 26
8.4. Baseline Secure FEC Framework Operation . . . . . . . . . 26 8.4. Baseline Secure FEC Framework Operation . . . . . . . . . 26
9. Operations and Management Considerations . . . . . . . . . . 26 8.5. Additional Security Considerations for Numerical
Computations . . . . . . . . . . . . . . . . . . . . . . 27
9. Operations and Management Considerations . . . . . . . . . . 27
9.1. Operational Recommendations: Finite Field GF(2) Versus 9.1. Operational Recommendations: Finite Field GF(2) Versus
GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 27 GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Operational Recommendations: Coding Coefficients Density 9.2. Operational Recommendations: Coding Coefficients Density
Threshold . . . . . . . . . . . . . . . . . . . . . . . . 27 Threshold . . . . . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. TinyMT32 Pseudo-Random Number Generator . . . . . . 31 Appendix A. TinyMT32 Pseudo-Random Number Generator . . . . . . 31
Appendix B. Decoding Beyond Maximum Latency Optimization . . . . 34 Appendix B. Decoding Beyond Maximum Latency Optimization . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Application-Level Forward Erasure Correction (AL-FEC) codes, or Application-Level Forward Erasure Correction (AL-FEC) codes, or
simply FEC codes, are a key element of communication systems. They simply FEC codes, are a key element of communication systems. They
are used to recover from packet losses (or erasures) during content are used to recover from packet losses (or erasures) during content
delivery sessions to a potentially large number of receivers delivery sessions to a potentially large number of receivers
(multicast/broadcast transmissions). This is the case with the (multicast/broadcast transmissions). This is the case with the
FLUTE/ALC protocol [RFC6726] when used for reliable file transfers FLUTE/ALC protocol [RFC6726] when used for reliable file transfers
skipping to change at page 6, line 27 skipping to change at page 6, line 28
ID and Repair FEC Payload ID formats, carrying the signalling ID and Repair FEC Payload ID formats, carrying the signalling
information associated to each source or repair symbol. It also information associated to each source or repair symbol. It also
defines the FEC Framework Configuration Information (FFCI) defines the FEC Framework Configuration Information (FFCI)
carrying signalling information for the session; carrying signalling information for the session;
5. FEC Code Specification: Finally this section provides the code 5. FEC Code Specification: Finally this section provides the code
specification. specification.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the following definitions and abbreviations: This document uses the following definitions and abbreviations:
a^^b a to the power of b
GF(q) denotes a finite field (also known as the Galois Field) with q GF(q) denotes a finite field (also known as the Galois Field) with q
elements. We assume that q = 2^^m in this document elements. We assume that q = 2^^m in this document
m defines the length of the elements in the finite field, in bits. m defines the length of the elements in the finite field, in bits.
In this document, m is equal to 1 or 8 In this document, m is equal to 1 or 8
ADU: Application Data Unit ADU: Application Data Unit
ADUI: Application Data Unit Information (includes the F, L and ADUI: Application Data Unit Information (includes the F, L and
padding fields in addition to the ADU) padding fields in addition to the ADU)
E: size of an encoding symbol (i.e., source or repair symbol), E: size of an encoding symbol (i.e., source or repair symbol),
assumed fixed (in bytes) assumed fixed (in bytes)
br_in: transmission bitrate at the input of the FECFRAME sender, br_in: transmission bitrate at the input of the FECFRAME sender,
skipping to change at page 7, line 25 skipping to change at page 7, line 29
This section introduces the procedures that are used by these FEC This section introduces the procedures that are used by these FEC
Schemes. Schemes.
3.1. Possible Parameter Derivations 3.1. Possible Parameter Derivations
The Sliding Window RLC FEC Scheme relies on several parameters: The Sliding Window RLC FEC Scheme relies on several parameters:
Maximum FEC-related latency budget, max_lat (in seconds) with real- Maximum FEC-related latency budget, max_lat (in seconds) with real-
time flows: time flows:
a source ADU flow can have real-time constraints, and therefore a source ADU flow can have real-time constraints, and therefore
any FECFRAME related operation must take place within the validity any FECFRAME related operation SHOULD take place within the
period of each ADU. When there are multiple flows with different validity period of each ADU (Appendix B describes an exception to
real-time constraints, we consider the most stringent constraints this rule). When there are multiple flows with different real-
(see [RFC6363], Section 10.2, item 6, for recommendations when time constraints, we consider the most stringent constraints (see
several flows are globally protected). The maximum FEC-related [RFC6363], Section 10.2, item 6, for recommendations when several
latency budget, max_lat, accounts for all sources of latency added flows are globally protected). The maximum FEC-related latency
by FEC encoding (at a sender) and FEC decoding (at a receiver). budget, max_lat, accounts for all sources of latency added by FEC
Other sources of latency (e.g., added by network communications) encoding (at a sender) and FEC decoding (at a receiver). Other
are out of scope and must be considered separately (said sources of latency (e.g., added by network communications) are out
differently, they have already been deducted from max_lat). of scope and must be considered separately (said differently, they
max_lat can be regarded as the latency budget permitted for all have already been deducted from max_lat). max_lat can be regarded
FEC-related operations. This is an input parameter that enables a as the latency budget permitted for all FEC-related operations.
FECFRAME sender to derive other internal parameters as explained This is an input parameter that enables a FECFRAME sender to
below; derive other internal parameters as explained below;
Encoding window current (resp. maximum) size, ew_size (resp. Encoding window current (resp. maximum) size, ew_size (resp.
ew_max_size) (in symbols): ew_max_size) (in symbols):
at a FECFRAME sender, during FEC encoding, a repair symbol is at a FECFRAME sender, during FEC encoding, a repair symbol is
computed as a linear combination of the ew_size source symbols computed as a linear combination of the ew_size source symbols
present in the encoding window. The ew_max_size is the maximum present in the encoding window. The ew_max_size is the maximum
size of this window, while ew_size is the current size. For size of this window, while ew_size is the current size. For
instance, at session start, upon receiving new source ADUs, the instance, at session start, upon receiving new source ADUs, the
ew_size progressively increases until it reaches its maximum ew_size progressively increases until it reaches its maximum
value, ew_max_size. We have: value, ew_max_size. We have:
ew_size <= ew_max_size 0 < ew_size <= ew_max_size
Decoding window maximum size, dw_max_size (in symbols): at a Decoding window maximum size, dw_max_size (in symbols): at a
FECFRAME receiver, dw_max_size is the maximum number of received FECFRAME receiver, dw_max_size is the maximum number of received
or lost source symbols that are still within their latency budget; or lost source symbols that are still within their latency budget;
Linear system maximum size, ls_max_size (in symbols): at a FECFRAME Linear system maximum size, ls_max_size (in symbols): at a FECFRAME
receiver, the linear system maximum size, ls_max_size, is the receiver, the linear system maximum size, ls_max_size, is the
maximum number of received or lost source symbols in the linear maximum number of received or lost source symbols in the linear
system (i.e., the variables). It SHOULD NOT be smaller than system (i.e., the variables). It SHOULD NOT be smaller than
dw_max_size since it would mean that, even after receiving a dw_max_size since it would mean that, even after receiving a
sufficient number of FEC Repair Packets, a lost ADU may not be sufficient number of FEC Repair Packets, a lost ADU may not be
recovered just because the associated source symbols have been recovered just because the associated source symbols have been
skipping to change at page 9, line 32 skipping to change at page 9, line 34
For decoding to be possible within the latency budget, it is required For decoding to be possible within the latency budget, it is required
that the encoding window maximum size be smaller than or at most that the encoding window maximum size be smaller than or at most
equal to the decoding window maximum size, the exact value having no equal to the decoding window maximum size, the exact value having no
impact on the the FEC-related latency budget. For the FEC Schemes impact on the the FEC-related latency budget. For the FEC Schemes
specified in this document, in line with [Roca17], the ew_max_size specified in this document, in line with [Roca17], the ew_max_size
SHOULD be computed with: SHOULD be computed with:
ew_max_size = dw_max_size * 0.75 ew_max_size = dw_max_size * 0.75
The ew_max_size is the main parameter at a FECFRAME sender. The ew_max_size is the main parameter at a FECFRAME sender. It is
RECOMMENDED to check that the ew_max_size value stays within
reasonnable bounds in order to avoid hazardous behaviours.
The dw_max_size is computed by a FECFRAME sender but not explicitly The dw_max_size is computed by a FECFRAME sender but not explicitly
communicated to a FECFRAME receiver. However a FECFRAME receiver can communicated to a FECFRAME receiver. However a FECFRAME receiver can
easily evaluate the ew_max_size by observing the maximum Number of easily evaluate the ew_max_size by observing the maximum Number of
Source Symbols (NSS) value contained in the Repair FEC Payload ID of Source Symbols (NSS) value contained in the Repair FEC Payload ID of
received FEC Repair Packets (Section 4.1.3). A receiver can then received FEC Repair Packets (Section 4.1.3). A receiver can then
easily compute dw_max_size: easily compute dw_max_size:
dw_max_size = max_NSS_observed / 0.75 dw_max_size = max_NSS_observed / 0.75
A receiver can then chose an appropriate linear system maximum size: A receiver can then chose an appropriate linear system maximum size:
ls_max_size >= dw_max_size ls_max_size >= dw_max_size
It is good practice to use a larger value for ls_max_size as It is good practice to use a larger value for ls_max_size as
explained in Appendix B, which does not impact maximum latency nor explained in Appendix B, which does not impact maximum latency nor
interoperability. However the linear system size should not be too interoperability. However the linear system size should not be too
large for practical reasons (e.g., in order to limit computation large for practical reasons (e.g., in order to limit computation
complexity). complexity). It is RECOMMENDED to check that the ls_max_size value
stays within reasonnable bounds in order to avoid hazardous
behaviours.
The particular case of session start needs to be managed The particular case of session start needs to be managed
appropriately. Here ew_size increases each time a new source ADU is appropriately. Here ew_size increases each time a new source ADU is
received by the FECFRAME sender, until it reaches the ew_max_size received by the FECFRAME sender, until it reaches the ew_max_size
value. A FECFRAME receiver SHOULD continuously observe the received value. A FECFRAME receiver SHOULD continuously observe the received
FEC Repair Packets, since the NSS value carried in the Repair FEC FEC Repair Packets, since the NSS value carried in the Repair FEC
Payload ID will increase too, and adjust its ls_max_size accordingly Payload ID will increase too, and adjust its ls_max_size accordingly
if need be. if need be.
3.1.2. Other Types of Real-Time Flow 3.1.2. Other Types of Real-Time Flow
skipping to change at page 26, line 41 skipping to change at page 27, line 5
8.4. Baseline Secure FEC Framework Operation 8.4. Baseline Secure FEC Framework Operation
The Sliding Window RLC FEC Scheme specified in this document does not The Sliding Window RLC FEC Scheme specified in this document does not
change the recommendations of [RFC6363] concerning the use of the change the recommendations of [RFC6363] concerning the use of the
IPsec/ESP security protocol as a mandatory to implement (but not IPsec/ESP security protocol as a mandatory to implement (but not
mandatory to use) security scheme. This is well suited to situations mandatory to use) security scheme. This is well suited to situations
where the only insecure domain is the one over which the FEC where the only insecure domain is the one over which the FEC
Framework operates. Framework operates.
8.5. Additional Security Considerations for Numerical Computations
In addition to the above security considerations, inherited from
[RFC6363], the present document introduces several formulae, in
particular in Section 3.1.1. It is RECOMMENDED to check that the
computed values stay within reasonnable bounds since numerical
overflows, caused by an erroneous implementation or an erroneous
input value, may lead to hazardous behaviours. However what
"reasonnable bounds" means is use-case and implementation dependent
and is not detailed in this document.
Section 3.1.2 also mentions the possibility of "using the timestamp
field of an RTP packet header" when applicable. A malicious attacker
may deliberately corrupt this header field in order to trigger
hazardous behaviours at a FECFRAME receiver. Protection against this
type of content corruption can be addressed with the above
recommendations on a baseline secure operation. In addition, it is
also RECOMMENDED to check that the timestamp value be within
reasonnable bounds.
9. Operations and Management Considerations 9. Operations and Management Considerations
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 specific FEC Schemes. Therefore, the present section only discusses specific
topics. topics.
9.1. Operational Recommendations: Finite Field GF(2) Versus GF(2^^8) 9.1. Operational Recommendations: Finite Field GF(2) Versus GF(2^^8)
The present document specifies two FEC Schemes that differ on the The present document specifies two FEC Schemes that differ on the
skipping to change at page 28, line 14 skipping to change at page 28, line 42
o YYYY refers to the Sliding Window Random Linear Codes (RLC) over o YYYY refers to the Sliding Window Random Linear Codes (RLC) over
GF(2) FEC Scheme for Arbitrary Packet Flows, as defined in GF(2) FEC Scheme for Arbitrary Packet Flows, as defined in
Section 5 of this document. Section 5 of this document.
o XXXX refers to the Sliding Window Random Linear Codes (RLC) over o XXXX refers to the Sliding Window Random Linear Codes (RLC) over
GF(2^^8) FEC Scheme for Arbitrary Packet Flows, as defined in GF(2^^8) FEC Scheme for Arbitrary Packet Flows, as defined in
Section 4 of this document. Section 4 of this document.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Spencer Dawkins, Gorry Fairhurst, The authors would like to thank Russ Housley, Alan DeKok, Spencer
Jonathan Detchart, Emmanuel Lochin, and Marie-Jose Montpetit for Dawkins, Gorry Fairhurst, Jonathan Detchart, Emmanuel Lochin, and
their valuable feedbacks on this document. Marie-Jose Montpetit for their valuable feedbacks on this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[fecframe-ext] [fecframe-ext]
Roca, V. and A. Begen, "Forward Error Correction (FEC) Roca, V. and A. Begen, "Forward Error Correction (FEC)
Framework Extension to Sliding Window Codes", Transport Framework Extension to Sliding Window Codes", Transport
Area Working Group (TSVWG) draft-ietf-tsvwg-fecframe-ext Area Working Group (TSVWG) draft-ietf-tsvwg-fecframe-ext
(Work in Progress), September 2018, (Work in Progress), September 2018,
skipping to change at page 28, line 45 skipping to change at page 29, line 28
[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, Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011, DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>. <https://www.rfc-editor.org/info/rfc6363>.
[RFC6364] Begen, A., "Session Description Protocol Elements for the [RFC6364] Begen, A., "Session Description Protocol Elements for the
Forward Error Correction (FEC) Framework", RFC 6364, Forward Error Correction (FEC) Framework", RFC 6364,
DOI 10.17487/RFC6364, October 2011, DOI 10.17487/RFC6364, October 2011,
<https://www.rfc-editor.org/info/rfc6364>. <https://www.rfc-editor.org/info/rfc6364>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[KR12] Rikitake, K., "TinyMT Pseudo Random Number Generator for [KR12] Rikitake, K., "TinyMT Pseudo Random Number Generator for
Erlang", ACM 11th SIGPLAN Erlang Workshop (Erlang'12), Erlang", ACM 11th SIGPLAN Erlang Workshop (Erlang'12),
September 14, 2012, Copenhagen, Denmark, DOI: September 14, 2012, Copenhagen, Denmark, DOI:
http://dx.doi.org/10.1145/2364489.2364504, September 2012. http://dx.doi.org/10.1145/2364489.2364504, September 2012.
[PGM13] Plank, J., Greenan, K., and E. Miller, "A Complete [PGM13] Plank, J., Greenan, K., and E. Miller, "A Complete
Treatment of Software Implementations of Finite Field Treatment of Software Implementations of Finite Field
Arithmetic for Erasure Coding Applications", University of Arithmetic for Erasure Coding Applications", University of
skipping to change at page 32, line 11 skipping to change at page 32, line 11
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
* ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
* TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
* THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE. * SUCH DAMAGE.
*/ */
#include <stdint.h>
/** /**
* tinymt32 internal state vector and parameters * tinymt32 internal state vector and parameters
*/ */
typedef struct { typedef struct {
uint32_t status[4]; uint32_t status[4];
uint32_t mat1; uint32_t mat1;
uint32_t mat2; uint32_t mat2;
uint32_t tmat; uint32_t tmat;
} tinymt32_t; } tinymt32_t;
 End of changes. 20 change blocks. 
34 lines changed or deleted 68 lines changed or added

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