One document matched: draft-ietf-fecframe-simple-rs-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category="std" ipr="trust200902">
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev='Simple Reed-Solomon FEC Scheme'>
Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
</title>
<author initials='V' surname="Roca" fullname='Vincent Roca'>
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Inovallee; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/people/roca/</uri>
</address>
</author>
<author initials='M' surname="Cunche" fullname='Mathieu Cunche'>
<organization>NICTA</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country>Australia</country>
</postal>
<email>mathieu.cunche@nicta.com.au</email>
<uri>http://mathieu.cunche.free.fr/</uri>
</address>
</author>
<author initials="J" surname="Lacan" fullname="Jerome Lacan">
<organization>ISAE/LAAS-CNRS</organization>
<address>
<postal>
<street>1, place Emile Blouin</street>
<city>Toulouse</city>
<code>31056</code>
<country>France</country>
</postal>
<email>jerome.lacan@isae.fr</email>
<uri>http://dmi.ensica.fr/auteur.php3?id_auteur=5</uri>
</address>
</author>
<author initials="A" surname="Bouabdallah" fullname="Amine Bouabdallah">
<organization>ISAE/LAAS-CNRS</organization>
<address>
<postal>
<street>1, place Emile Blouin</street>
<city>Toulouse</city>
<code>31056</code>
<country>France</country>
</postal>
<email>Amine.Bouabdallah@isae.fr</email>
<uri>http://dmi.ensica.fr/</uri>
</address>
</author>
<author initials="K" surname="Matsuzono" fullname="Kazuhisa Matsuzono">
<organization>Keio University</organization>
<address>
<postal>
<street>Graduate School of Media and Governance</street>
<street>5322 Endo</street>
<city>Fujisawa</city> <region>Kanagawa</region>
<code>252-8520</code>
<country>Japan</country>
</postal>
<email>kazuhisa@sfc.wide.ad.jp</email>
</address>
</author>
<date day="28" month="February" year="2011"/>
<area>Transport</area>
<workgroup>FecFrame</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Forward Error Correction</keyword>
<keyword>Reed-Solomon</keyword>
<abstract>
<t>
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 protect arbitrary media streams
along the lines defined by the FECFRAME framework.
Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which
means they offer optimal protection against packet erasures.
They are also systematic codes, 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 maximum number of encoding
symbols, and a computational complexity higher than that of LDPC codes for instance.
<!--
However, this complexity remains compatible with software codecs.
Finally, the FEC schemes described here are compatible with the software codec from Luigi Rizzo.-->
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<!-- =========================================== -->
<t>The use of Forward Error Correction (FEC) codes is a classic solution to improve the reliability
of unicast, multicast and broadcast Content Delivery Protocols (CDP) and applications.
The <xref target="FECFRAME-FRAMEWORK"/> document describes a generic framework to use FEC schemes
with media delivery applications, and for instance with real-time streaming media applications based
on the RTP real-time protocol.
Similarly the <xref target="RFC5052"/> document describes a generic framework to use FEC schemes
with with objects (e.g., files) delivery applications based on the ALC <xref target="RFC5775"/>
and NORM <xref target="RFC5740"/> reliable multicast transport protocols.
</t>
<t>More specifically, the <xref target="RFC5053"/> and <xref target="RFC5170"/> FEC schemes introduce
erasure codes based on sparse parity check matrices for object delivery protocols like ALC and NORM.
These codes are efficient in terms of processing but not optimal in terms of erasure recovery
capabilities when dealing with "small" objects.
</t>
<t>The Reed-Solomon FEC codes described in this document belong to the class of Maximum Distance
Separable (MDS) codes that are optimal in terms of erasure recovery capability.
It means that a receiver can recover the k source symbols from any set of exactly k encoding symbols.
These codes are also systematic codes, which means that the k source symbols are part of the encoding
symbols.
However they are limited in terms of maximum source block size and number of encoding symbols.
Since the real-time constraints of media delivery applications usually limit the maximum
source block size, this is not considered to be a major issue in the context of the FEC Framework
for many (but not necessarily all) use-cases.
Additionally, if the encoding/decoding complexity is higher with Reed-Solomon codes than it is with
<xref target="RFC5053"/> or <xref target="RFC5170"/> codes, it remains reasonable for most use-cases,
even in case of a software codec.</t>
<t>Many applications dealing with reliable content transmission or content storage already rely on
packet-based Reed-Solomon erasure recovery codes.
In particular, many of them use the Reed-Solomon codec of Luigi Rizzo <xref target="RS-codec"/>
<xref target="Rizzo97"/>.
The goal of the present document is to specify a simple Reed-Solomon scheme that is compatible
with this codec.
</t>
<t>
More specifically, the <xref target="RFC5510"/> document introduced such Reed-Solomon codes and
several associated FEC schemes that are compatible with the <xref target="RFC5052"/> framework.
The present document inherits from <xref target="RFC5510"/> the specification of the core Reed-Solomon codes
based on Vandermonde matrices, and specifies a simple FEC scheme that is compatible with the
FECFRAME framework <xref target="FECFRAME-FRAMEWORK"/>.
Therefore this document specifies only the information specific to the FECFRAME context and
refers to <xref target="RFC5510"/> for the core specifications of the codes.
To that purpose, the present document introduces:
<list style="symbols">
<t> the Fully-Specified FEC Scheme with FEC Encoding ID XXX
that specifies a simple way of using of Reed-Solomon codes over GF(2^^m), with 2 ≤ m ≤ 16,
with a simple FEC encoding for arbitrary packet flows;</t>
</list>
</t>
<t>
For instance, with this scheme, a set of Application Data Units (or ADUs) coming from one
or several (resp. one) media delivery applications (e.g., 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 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.
This constraint is relaxed when using a higher finite field size (m > 8), at the price of
an increased computational complexity.
</t>
</section>
<section anchor="Terminology" title="Terminology">
<!-- =========================================== -->
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 <xref target="RFC2119"/>.</t>
</section>
<section anchor="DefinitionsNotationsandAbbreviations" title="Definitions Notations and Abbreviations">
<!-- =========================================== -->
<section anchor="Definitions" title="Definitions">
<!-- =========================================== -->
<t>This document uses the following terms and definitions.
Some of them are FEC scheme specific and are in line with <xref target="RFC5052"/>:
<list style="hanging">
<t hangText="Source symbol:"> unit of data used during the encoding process.
In this specification, there is always one source symbol per ADU.</t>
<t hangText="Encoding symbol:"> unit of data generated by the encoding process.
With systematic codes, source symbols are part
of the encoding symbols.</t>
<t hangText="Repair symbol:"> encoding symbol that is not a source symbol.</t>
<t hangText="Code rate:"> the k/n ratio, i.e., the ratio between the number
of source symbols and the number of encoding symbols.
By definition, 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 produced during the encoding process.</t>
<t hangText="Systematic code:"> FEC code in which the source symbols are part
of the encoding symbols. The Reed-Solomon codes
introduced in this document are systematic.</t>
<t hangText="Source block:"> a block of k source symbols that are considered
together for the encoding.</t>
<t hangText="Packet Erasure Channel:">
a communication path where packets are either
dropped (e.g., by a congested router, or because the
number of transmission errors exceeds the correction
capabilities of the physical layer codes) or
received. When a packet is received, it is assumed
that this packet is not corrupted.</t>
</list>
</t>
<t>
Some of them are FECFRAME framework specific and are in line with
<xref target="FECFRAME-FRAMEWORK"/>:
<list style="hanging">
<t hangText="Application Data Unit (ADU):">
a unit of data coming from (sender) or given to (receiver)
the media delivery application.
Depending on the use-case, an ADU can use an RTP encapsulation.
In this specification, there is always one source symbol per ADU.</t>
<t hangText="(Source) ADU Flow:">
a flow of ADUs from a media delivery application
and to which FEC protection is applied.
Depending on the use-case, several ADU flows can be protected
together by the FECFRAME framework.</t>
<t hangText="ADU Block:"> a set of ADUs that are considered together by the FECFRAME
instance for the purpose of the FEC scheme.
Along with the F[], L[], and Pad[] fields, they form the set
of source symbols over which FEC encoding will be performed.
</t>
<t hangText="ADU Information (ADUI):">
a unit of data constituted by the ADU and the associated
Flow ID, Length and Padding fields
(<xref target="CommonProc_src_block_creation_global_encoding"/>).
<!--
and <xref target="CommonProc_src_block_creation_general_case_encoding"/>).
-->
This is the unit of data that is used as source symbol.</t>
<t hangText="FEC Framework Configuration Information:">
the FEC scheme specific information that enables the synchronization
of the FECFRAME sender and receiver instances.</t>
<t hangText="FEC Source Packet:">
a data packet submitted to (sender) or received from
(receiver) the transport protocol.
It contains an ADU along with its optional Explicit Source
FEC Payload ID.</t>
<t hangText="FEC Repair Packet:">
a repair packet submitted to (sender) or received from
(receiver) the transport protocol.
It contains a repair symbol along with its Repair
FEC Payload ID.</t>
</list>
</t>
<t>
The above terminology is illustrated in <xref target="fig_terminology"/>
(sender's point of view):
</t>
<figure anchor="fig_terminology" title="Terminology used in this document (sender).">
<artwork>
+----------------------+
| Application |
+----------------------+
|
ADU flow | (1) Application Data Unit (ADU)
v
+----------------------+ +----------------+
| FEC Framework | | |
| |------------------------- >| FEC Scheme |
|(2) Construct an ADU | (4) Source Symbols for | |
| block | this Source Block |(5) Perform FEC |
|(3) Construct ADU Info| | Encoding |
|(7) Construct FEC Src |< -------------------------| |
| Packets and FEC |(6) Ex src FEC Payload Ids,| |
| Repair Packets | Repair FEC Payload Ids,| |
+----------------------+ Repair Symbols +----------------+
| |
|(8) FEC Src |(8') FEC Repair
| packets | packets
v v
+----------------------+
| Transport Layer |
| (e.g., UDP ) |
+----------------------+
</artwork>
</figure>
</section>
<section anchor="Notations" title="Notations">
<!-- =========================================== -->
<t>This document uses the following notations:
Some of them are FEC scheme specific:
<list style="hanging" hangIndent="7">
<t hangText="k"> denotes the number of source symbols in a source block.</t>
<t hangText="max_k"> denotes the maximum number of source symbols for any source block.</t>
<!--
<t hangText="n_r"> denotes the number of repair symbols generated for a source block.</t>
-->
<t hangText="n"> denotes the number of encoding symbols generated for a source block.</t>
<!--
Therefore: n = k + n_r.</t>
-->
<!--
<t>max_n denotes the maximum number of encoding symbols generated for any
source block.</t>
-->
<t hangText="E"> denotes the encoding symbol length in bytes.</t>
<t hangText="GF(q)"> denotes a finite field (also known as Galois Field) with q elements.
We assume that q = 2^^m in this document.</t>
<t hangText="m"> defines the length of the elements in the finite field, in bits.
In this document, m is such that 2 ≤ m ≤ 16.</t>
<t hangText="q"> defines the number of elements in the finite field.
We have: q = 2^^m in this specification.</t>
<t hangText="CR"> denotes the "code rate", i.e., the k/n ratio.</t>
<t hangText="a^^b"> denotes a raised to the power b.</t>
</list>
</t>
<t>
Some of them are FECFRAME framework specific:
<list style="hanging" hangIndent="7">
<t hangText="B"> denotes the number of ADUs per ADU block.</t>
<t hangText="max_B"> denotes the maximum number of ADUs for any ADU block.</t>
</list>
</t>
</section>
<section anchor="Abbreviations" title="Abbreviations">
<!-- =========================================== -->
<t>This document uses the following abbreviations:
<list style="hanging" hangIndent="7">
<t hangText="ADU"> stands for Application Data Unit.</t>
<t hangText="ESI"> stands for Encoding Symbol ID.</t>
<t hangText="FEC"> stands for Forward Error (or Erasure) Correction code.</t>
<t hangText="FFCI"> stands for FEC Framework Configuration Information.</t>
<t hangText="FSSI"> stands for FEC Scheme Specific Information.</t>
<t hangText="RS"> stands for Reed-Solomon.</t>
<t hangText="MDS"> stands for Maximum Distance Separable code.</t>
</list>
</t>
</section>
</section>
<!-- =========================================================================================== -->
<section anchor="CommonProcedures" title="Common Procedures Related to the ADU Block and
Source Block Creation">
<!-- ================ -->
<t>
This section introduces the procedures that are used during the ADU block and the related
source block creation, for the FEC scheme considered.
</t>
<section anchor="Requirements" title="Restrictions">
<!-- ==================================== -->
<t>
This specification has the following restrictions:
<list style="symbols">
<t> there MUST be exactly one source symbol per ADUI, and therefore per ADU;</t>
<t> there MUST be exactly one repair symbol per FEC Repair Packet;</t>
<t> there MUST be exactly one source block per ADU block;</t>
</list>
</t>
</section>
<section anchor="CommonProc_problem" title="ADU Block Creation">
<!-- ==================================== -->
<t>
Several aspects must be considered, that impact the ADU block creation:
<list style="symbols">
<t> the maximum source block size (k parameter) and number of encoding symbols
(n parameter), that are constrained by the finite field size (m parameter);</t>
<t> the potential real-time constraints, that impact the maximum ADU block size,
since the larger the block size, the larger the decoding delay;</t>
</list>
We now detail each of these aspects.
</t>
<t>
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 - 1 value is also the theoretical maximum number of encoding symbols 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: k < n ≤ 255.
Given the target FEC code rate (e.g., provided by the end-user or upper application when
starting the FECFRAME framework, and taking into account the (known or estimated) packet
loss rate), the sender calculates:
<list style="empty">
<t>max_k = floor((2^^m - 1) * CR)</t>
</list>
This max_k value leaves enough room for the sender to produce the
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 block.
</t>
<t>
The source ADU flows usually have real-time constraints.
It means that the maximum number of ADUs of an ADU block must not exceed a certain
threshold since it directly impacts the decoding delay.
It is the role of the developer, who knows the flow real-time features, to define an
appropriate upper bound to the ADU block size, max_rt.
</t>
<t>
If we take into account these constraints, we find: max_B = min(max_k, max_rt).
Then max_B gives an upper bound to the number of ADUs that can constitute an ADU block.
</t>
</section>
<section anchor="CommonProc_src_block_creation_global_encoding"
title="Source Block Creation">
<!-- ==================================== -->
<t>
In its most general form the FECFRAME framework and the RS FEC scheme
are meant to protect a set of independent flows.
Since the flows have no relationship to one another, the ADU size of each
flow can potentially vary significantly.
Even in the special case of a single flow, the ADU sizes can largely
vary (e.g., the various frames of a "Group of Pictures (GOP) of an H.264 flow).
This diversity must be addressed since the RS FEC scheme requires a constant
encoding symbol size (E parameter) per source block.
Since this specification requires that there is only one source symbol per ADU,
E must be large enough to contain all the ADUs of an ADU block along
with their prepended 3 bytes (see below).
</t>
<t>
In situations where E is determined per source block
(default, specified by the FFCI/FSSI with S = 0, <xref target="RSover2mArbitraryFlows_fssi"/>),
E is equal to the size of the largest ADU of this source block plus three (for the
prepended 3 bytes, see below).
In this case, upon receiving the first FEC Repair Packet for this source block,
since this packet MUST contain a single repair symbol (<xref target="RSover2mArbitraryFlows_repair_fpi"/>),
a receiver determines the E parameter used for this source block.
</t>
<t>
In situations where E is fixed
(specified by the FFCI/FSSI with S = 1, <xref target="RSover2mArbitraryFlows_fssi"/>),
then E must be greater or equal to the size of 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.
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 message, using an appropriate
mechanism) and is not considered by this specification.
</t>
<t>
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 ≤ i ≤ B-1, 3 bytes are prepended
(<xref target="fig_src_block_creation_global_enc"/>):
<list style="symbols">
<t>The first byte, FID[i] (Flow ID), contains the integer identifier
associated to the source ADU flow to which this ADU
belongs to.
It is assumed that a single byte is sufficient, or said
differently, that no more than 256 flows will be protected by
a single instance of the FECFRAME framework.
</t>
<t>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 the ADU itself and does not include the
FID[i], L[i], or Pad[i] fields.
</t>
</list>
</t>
<t>
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 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 one source symbol to the source block.
</t>
<figure anchor="fig_src_block_creation_global_enc" title="Source block creation,
for code rate 1/2 (equal number of source and repair symbols, 4 in this example), and S = 0.">
<artwork>
Encoding Symbol Length (E)
< -------------------------------------------------------------- >
+----+----+-----------------------+------------------------------+
|F[0]|L[0]| ADU[0] | Pad[0] |
+----+----+----------+------------+------------------------------+
|F[1]|L[1]| ADU[1] | Pad[1] |
+----+----+----------+-------------------------------------------+
|F[2]|L[2]| ADU[2] |
+----+----+------+-----------------------------------------------+
|F[3]|L[3]|ADU[3]| Pad[3] |
+----+----+------+-----------------------------------------------+
\_______________________________ _______________________________/
\/
simple FEC encoding
+----------------------------------------------------------------+
| Repair 4 |
+----------------------------------------------------------------+
. .
. .
+----------------------------------------------------------------+
| Repair 7 |
+----------------------------------------------------------------+
</artwork>
</figure>
<t>
Note that neither the initial 3 bytes nor the optional padding are sent over the network.
However, they are considered during FEC encoding.
It means that a receiver who lost a certain FEC source packet (e.g., the
UDP datagram containing this FEC source packet) will be able to recover the ADUI
if FEC decoding succeeds.
Thanks to the initial 3 bytes, this receiver will get rid of the padding (if any)
and identify the corresponding ADU flow.
</t>
</section>
</section>
<!-- =========================================================================================== -->
<section anchor="RSover2mArbitraryFlows" title="Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary ADU Flows">
<!-- ==================================== -->
<t>
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 for arbitrary packet flows.
</t>
<section anchor="RSover2mArbitraryFlows_formatsAndCodes" title="Formats and Codes">
<!-- ==================================== -->
<section title="FEC Framework Configuration Information">
<!-- ================ -->
<t>
The FEC Framework Configuration Information (or FFCI) includes information
that MUST be communicated between the sender and receiver(s).
More specifically, it enables the synchronization of the FECFRAME sender
and receiver instances.
It includes both mandatory elements and scheme-specific elements,
as detailed below.
</t>
<section title="Mandatory Information">
<!-- ================ -->
<t>
<list style="hanging">
<t hangText="FEC Encoding ID:">
the value assigned to this fully-specified FEC scheme MUST be XXX,
as assigned by IANA (<xref target="iana-cons"/>).</t>
</list>
When SDP is used to communicate the FFCI, this FEC Encoding ID is carried in
the 'encoding-id' parameter.
</t>
</section>
<section title="FEC Scheme-Specific Information"
anchor="RSover2mArbitraryFlows_fssi">
<!-- ================ -->
<t>
The FEC Scheme Specific Information (FSSI) includes elements that are specific
to the present FEC scheme. More precisely:
<list style="hanging">
<t hangText="Encoding symbol length (E):"> a non-negative integer that indicates
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 = 0).</t>
<t hangText="Strict (S) flag:">
when set to 1 this flag indicates that the E parameter is the actual encoding symbol
length value for each block of the session
(unless otherwise notified by an updated FFCI 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 encoding symbol
length value for each block of the session
(unless otherwise notified by an updated FFCI if this possibility is considered by the use-case or CDP).
</t>
<t hangText="m parameter (m):">
an integer that defines the length of the elements in the finite field, in bits.
We have: 2 ≤ m ≤ 16.</t>
</list>
These elements are required both by the sender (RS encoder) and the receiver(s) (RS decoder).
</t>
<t>
When SDP is used to communicate the FFCI, this FEC scheme-specific information is carried in
the 'fssi' parameter in textual representation as specified in <xref target="SDP_ELEMENTS"/>.
For instance:
</t>
<t>
fssi = E:1400,S:0,m:8
</t>
<t>
If another mechanism requires the FSSI to be carried as an opaque octet string
(for instance after a Base64 encoding), the encoding format consists of the following 3 octets:
<list style="symbols">
<t> Encoding symbol length (E): 16 bit field.</t>
<t> Strict (S) flag: 1 bit field.</t>
<t> m parameter (m): 7 bit field.</t>
</list>
</t>
<figure anchor="fig_RSover2mArbitraryFlows_fssi_binary" title="FSSI encoding format.">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) |S| m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
</section>
<section title="Explicit Source FEC Payload ID"
anchor="RSover2mArbitraryFlows_src_fpi">
<!-- ================ -->
<t>
A FEC source packet MUST contain an Explicit Source FEC Payload ID that is appended to the
end of the packet as illustrated in <xref target="fig_src_pkt_format"/>.
</t>
<figure anchor="fig_src_pkt_format" title="Structure of a FEC Source Packet with the
Explicit Source FEC Payload ID.">
<artwork>
+--------------------------------+
| IP Header |
+--------------------------------+
| Transport Header |
+--------------------------------+
| ADU |
+--------------------------------+
| Explicit Source FEC Payload ID |
+--------------------------------+
</artwork>
</figure>
<t>
More precisely, the Explicit Source FEC Payload ID is composed of
the Source Block Number, the Encoding Symbol ID, and the Source Block Length.
The length of the first two fields depends on the m parameter (transmitted
separately in the FFCI, <xref target="RSover2mArbitraryFlows_fssi"/>):
<list style="hanging">
<t hangText="Source Block Number (SBN) (32-m bit field):">
this field identifies the source block to which this FEC source packet belongs.</t>
<t hangText="Encoding Symbol ID (ESI) (m bit field):">
this field identifies the source symbol contained in this FEC source packet.
This value is such that 0 ≤ ESI ≤ k - 1 for source symbols.</t>
<t hangText="Source Block Length (k) (16 bit field):">
this field provides the 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 8 < m ≤ 16. Therefore we
provide a single common format regardless of m.</t>
</list>
</t>
<figure anchor="fig_src_fpi_for_8" title="Source FEC Payload ID encoding format for m = 8 (default).">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure anchor="fig_src_fpi_for_16" title="Source FEC Payload ID encoding format for m = 16.">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The format of the Source FEC Payload ID for m = 8 and m = 16 are illustrated in
<xref target="fig_src_fpi_for_8"/> and <xref target="fig_src_fpi_for_16"/>
respectively.</t>
</section>
<section title="Repair FEC Payload ID" anchor="RSover2mArbitraryFlows_repair_fpi">
<!-- ================ -->
<t>
A FEC repair packet MUST contain a Repair FEC Payload ID that is prepended to the
repair symbol(s) as illustrated in <xref target="fig_repair_pkt_format"/>.
There MUST be a single repair symbol per FEC repair packet.
</t>
<figure anchor="fig_repair_pkt_format" title="Structure of a FEC Repair Packet with the
Repair FEC Payload ID.">
<artwork>
+--------------------------------+
| IP Header |
+--------------------------------+
| Transport Header |
+--------------------------------+
| Repair FEC Payload ID |
+--------------------------------+
| Repair Symbol |
+--------------------------------+
</artwork>
</figure>
<t>
More precisely, the Repair FEC Payload ID is composed of
the Source Block Number, the Encoding Symbol ID, and the Source Block Length.
The length of the first two fields depends on the m parameter (transmitted
separately in the FFCI, <xref target="RSover2mArbitraryFlows_fssi"/>):
<list style="hanging">
<t hangText="Source Block Number (SBN) (32-m bit field):">
this field identifies the source block to which the FEC repair packet belongs.</t>
<t hangText="Encoding Symbol ID (ESI) (m bit field)">
this field identifies the repair symbol contained in this FEC repair packet.
This value is such that k ≤ ESI ≤ n - 1 for repair symbols.</t>
<t hangText="Source Block Length (k) (16 bit field):">
this field provides the 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 8 < m ≤ 16. Therefore we
provide a single common format regardless of m.</t>
</list>
</t>
<figure anchor="fig_repair_fpi_for_8" title="Repair FEC Payload ID encoding format for m = 8 (default).">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure anchor="fig_repair_fpi_for_16" title="Repair FEC Payload ID encoding format for m = 16.">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The format of the Repair FEC Payload ID for m = 8 and m = 16 are illustrated in
<xref target="fig_repair_fpi_for_8"/> and <xref target="fig_repair_fpi_for_16"/>
respectively.
</t>
</section>
</section> <!-- RSover2mArbitraryFlows_formatsAndCodes -->
<section anchor="RSover2mArbitraryFlows_Procedures" title="Procedures">
<!-- ================ -->
<t>
The following procedures apply:
<list style="symbols">
<t>
The source block creation procedures are specified in
<xref target="CommonProc_src_block_creation_global_encoding"/>.
</t>
<t>
The SBN value is incremented for each new source block, starting at
0 for the first block of the ADU flow.
Wrapping to zero will happen for long sessions, after value 2^^(32-m) - 1.
</t>
<t>
The ESI of encoding symbols is managed sequentially, starting at
0 for the first symbol.
The first k values (0 ≤ ESI ≤ k - 1) identify source symbols, whereas
the last n-k values (k ≤ ESI ≤ n - 1) identify repair symbols.
</t>
<t>
The FEC repair packet creation procedures are specified in
<xref target="RSover2mArbitraryFlows_repair_fpi"/>.
</t>
</list>
</t>
</section>
<section anchor="RSover2mArbitraryFlows_FECCodeSpecification" title="FEC Code Specification">
<!-- ================ -->
<t>
The present document inherits from <xref target="RFC5510"/> the specification of the
core Reed-Solomon codes based on Vandermonde matrices for a packet transmission channel.
</t>
</section>
</section> <!-- RSover2mArbitraryFlows -->
<!-- =========================================================================================== -->
<section anchor="SecurityConsiderations" title="Security Considerations">
<!-- ==================================== -->
<t>
The FEC Framework document <xref target="FECFRAME-FRAMEWORK"/> provides a comprehensive
analysis of security considerations applicable to FEC schemes.
Therefore the present section follows the security considerations section of
<xref target="FECFRAME-FRAMEWORK"/> and only discusses topics that are specific
to the use of Reed-Solomon codes.
</t>
<section title="Attacks Against the Data Flow">
<!-- ================ -->
<section title="Access to Confidential Content">
<!-- ================ -->
<t>The Reed-Solomon FEC Scheme specified in this document does not change the
recommendations of <xref target="FECFRAME-FRAMEWORK"/>.
To summarize, if confidentiality is a concern, it is RECOMMENDED that one of the
solutions mentioned in <xref target="FECFRAME-FRAMEWORK"/> is used, with special
considerations to the way this solution is applied (e.g., before versus after
FEC protection, and within the end-system versus in a middlebox), to the operational
constraints (e.g., performing FEC decoding in a protected environment may be
complicated or even impossible) and to the threat model.
</t>
</section>
<section title="Content Corruption" anchor="sec_content_corruption">
<!-- ================ -->
<t>The Reed-Solomon FEC Scheme specified in this document does not change the
recommendations of <xref target="FECFRAME-FRAMEWORK"/>.
To summarize, it is RECOMMENDED that one of the solutions mentioned in
<xref target="FECFRAME-FRAMEWORK"/> is used on both the FEC Source and Repair Packets.
</t>
</section>
</section>
<section title="Attacks Against the FEC Parameters">
<!-- ================ -->
<t>
The FEC Scheme specified in this document defines parameters that
can be the basis of several attacks.
More specifically, the following parameters of the FFCI may be modified
by an attacker (<xref target="RSover2mArbitraryFlows_fssi"/>):
<list style="symbols">
<t>FEC Encoding ID:
changing this parameter leads the receiver to consider a different
FEC Scheme, which enables an attacker to create a Denial of Service (DoS).
</t>
<t>Encoding symbol length (E):
setting this E parameter to a value smaller than the valid one enables
an attacker to create a DoS since the repair symbols and certain source
symbols will be larger than E, which is an incoherency for the receiver.
Setting this E parameter to a value larger than the valid one has
similar impacts when S=1 since the received repair symbol size will be
smaller than expected. On the opposite it will not lead to any incoherency
when S=0 since the actual symbol length value for the block is determined
by the size of any received repair symbol, as long as this value is smaller
than E.
However setting this E parameter to a larger value may have impacts on
receivers that pre-allocate memory space in advance to store incoming
symbols.
</t>
<t>Strict (S) flag:
flipping this S flag from 0 to 1 (i.e., E is now considered as
a strict value) enables an attacker to mislead the receiver if the
actual symbol size varies over different source blocks.
Flipping this S flag from 1 to 0 has no major consequences unless the
receiver requires to have a fixed E value (e.g., because the receiver
pre-allocates memory space).
</t>
<t>m parameter:
changing this parameter triggers a DoS since the receiver and sender
will consider different codes, and the receiver will interpret the
Explicit Source FEC Payload ID and Repair FEC Payload ID differently.
Additionally, by increasing this m parameter to a larger value (typically
m=16 rather than 8, when both values are possible in the target use-case)
will create additional processing load at a receiver if decoding is
attempted.
</t>
</list>
</t>
<t>
It is therefore RECOMMENDED that security measures are taken to
guarantee the FFCI integrity, as specified in <xref target="FECFRAME-FRAMEWORK"/>.
How to achieve this depends on the way the FFCI is communicated from the sender
to the receiver, which is not specified in this document.
</t>
<t>
Similarly, attacks are possible against the Explicit Source FEC Payload ID
and Repair FEC Payload ID: by modifying the Source Block Number (SBN), or the
Encoding Symbol ID (ESI), or the Source Block Length (k),
an attacker can easily corrupt the block identified by the SBN.
Other consequences, that are use-case and/or CDP dependant, may also happen.
It is therefore RECOMMENDED that security measures are taken to guarantee the
FEC Source and Repair Packets as stated in <xref target="FECFRAME-FRAMEWORK"/>.
</t>
</section>
<section title="When Several Source Flows are to be Protected Together">
<!-- ================ -->
<t>The Reed-Solomon FEC Scheme specified in this document does not change the
recommendations of <xref target="FECFRAME-FRAMEWORK"/>.</t>
</section>
<section title="Baseline Secure FEC Framework Operation">
<!-- ================ -->
<t>The Reed-Solomon FEC Scheme specified in this document does not change the
recommendations of <xref target="FECFRAME-FRAMEWORK"/> concerning the use of
the IPsec/ESP security protocol as a mandatory to implement (but not mandatory
to use) security scheme.
This is well suited to situations where the only insecure domain is the one
over which the FEC Framework operates.
</t>
</section>
</section>
<!-- =========================================================================================== -->
<section anchor="OperationsManagement" title="Operations and Management Considerations">
<!-- ==================================== -->
<t>
The FEC Framework document <xref target="FECFRAME-FRAMEWORK"/> provides a comprehensive
analysis of operations and management considerations applicable to FEC schemes.
Therefore the present section only discusses topics that are specific to the use of
Reed-Solomon codes as specified in this document.
</t>
<section title="Finite Field Size (m) Recommendations">
<!-- ================ -->
<t>
The present document requires that m, the length of the elements in the finite field, in bits,
is such that 2 ≤ m ≤ 16.
However all possibilities are not equally interesting from a practical point of view.
It is expected that m=8, the default value, will be mostly used since it offers the
possibility to have small to medium sized source blocks and/or a significant number of repair symbols
(i.e., k < n ≤ 255). Additionally, elements in the finite field are 8 bits long which makes
read/write memory operations aligned on bytes during encoding and decoding.
</t>
<t>
An alternative when it is known that only very small source blocks will be used
is m=4 (i.e., k < n ≤ 15). Elements in the finite field are 4 bits long, so if two elements
are accessed at a time, read/write memory operations are aligned on bytes during encoding
and decoding.
</t>
<t>
An alternative when very large source blocks are needed is m=16 (i.e., k < n ≤ 65535).
However this choice has significant impacts on the processing load.
For instance using pre-calculated tables to speedup operations over the finite field (as done
with smaller finite fields) may require a prohibitive amount of memory to be used on embedded
platforms.
Alternative lightweigth solutions (e.g., <xref target="RFC5170"/>) MAY be prefered in situations
where the processing load is an issue <xref target="Matsuzono10"/>.
</t>
<t>
Since several values for the m parameter are possible, the use-case SHOULD define which
value(s) need(s) to be supported.
In situations where this is not specified, the default m=8 value SHOULD be supported and used.
</t>
</section>
</section>
<!-- =========================================================================================== -->
<section anchor="iana-cons" title="IANA Considerations">
<!-- =============================================== -->
<t>
Values of FEC Encoding IDs are subject to IANA registration.
<xref target="FECFRAME-FRAMEWORK"/> 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.
</t>
<t>
This document registers one value in the FEC Framework (FECFRAME)
FEC Encoding IDs registry as follows:
<list style="symbols">
<t>XXX refers to the Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary Packet Flows
as specified in this document and in <xref target="RFC5510"/>.
</t>
</list>
</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<!-- =============================================== -->
<t>
The authors want to thank Hitoshi Asaeda for his valuable comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- ==================================== -->
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization/>
</author>
<date year=""/>
</front>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC5052">
<front>
<title>Forward Error Correction (FEC) Building Block</title>
<author initials="M." surname="Watson"> <organization/> </author>
<author initials='M.' surname='Luby'> <organization /> </author>
<author initials='L.' surname='Vicisano'> <organization /> </author>
<date month="August" year="2007"/>
</front>
<seriesInfo name="RFC" value="5052"/>
</reference>
<reference anchor="RFC5510">
<front>
<title>Reed-Solomon Forward Error Correction (FEC) Schemes</title>
<author initials="J." surname="Lacan" fullname="Jerome Lacan">
<organization></organization> </author>
<author initials="V." surname="Roca" fullname="Vincent Roca">
<organization></organization> </author>
<author initials="J." surname="Peltotalo" fullname="Jani Peltotalo">
<organization></organization> </author>
<author initials="S." surname="Peltotalo" fullname="Sami Peltotalo">
<organization></organization> </author>
<date month="April" year="2009" />
</front>
<seriesInfo name="RFC" value="5510" />
</reference>
<reference anchor="FECFRAME-FRAMEWORK">
<front>
<title>Forward Error Correction (FEC) Framework</title>
<author initials="M." surname="Watson" fullname="Mark Watson">
<organization></organization> </author>
<author initials="A." surname="Begen" fullname="Ali Begen">
<organization></organization> </author>
<author initials="V." surname="Roca" fullname="Vincent Roca">
<organization></organization> </author>
<date month="February" year="2011" />
</front>
<seriesInfo name="draft-ietf-fecframe-framework-13" value="(Work in Progress)" />
</reference>
<reference anchor="SDP_ELEMENTS">
<front>
<title>SDP Elements for FEC Framework</title>
<author initials="A." surname="Begen" fullname="Ali Begen"> <organization/> </author>
<date month="October" year="2010" />
</front>
<seriesInfo name="draft-ietf-fecframe-sdp-elements-11" value="(Work in Progress)" />
</reference>
</references>
<references title="Informative References">
<!-- ==================================== -->
<reference anchor="RS-codec">
<front>
<title>Reed-Solomon FEC codec (revised version of July 2nd, 1998), available at
http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz and mirrored at http://planete-bcast.inrialpes.fr/</title>
<author initials="L." surname="Rizzo" fullname="Luigi Rizzo">
<organization/>
</author>
<date month="July" year="1998"/>
</front>
</reference>
<reference anchor="Rizzo97">
<front>
<title>Effective Erasure Codes for Reliable Computer Communication Protocols</title>
<author initials="L." surname="Rizzo" fullname="Luigi Rizzo">
<organization/>
</author>
<date month="April" year="1997" />
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value="Vol.27, No.2, pp.24-36" />
</reference>
<reference anchor="Matsuzono10">
<front>
<title>Performance Analysis of a High-Performance Real-Time Application with Several AL-FEC Schemes</title>
<author initials="K" surname="Matsuzono" fullname="Kazuhisa Matsuzono"> <organization/> </author>
<author initials="J." surname="Detchart" fullname="Jonathan Detchart"> <organization/> </author>
<author initials="M." surname="Cunche" fullname="Mathieu Cunche"> <organization/> </author>
<author initials="V." surname="Roca" fullname="Vincent Roca"> <organization/> </author>
<author initials="H." surname="Asaeda" fullname="Hitoshi Asaeda"> <organization/> </author>
<date month="October" year="2010" />
</front>
<seriesInfo name="35th Annual IEEE Conference on Local Computer Networks" value="(LCN 2010)" />
</reference>
<reference anchor="RFC5170">
<front>
<title>Low Density Parity Check (LDPC) Forward Error Correction</title>
<author initials="V." surname="Roca"> <organization/> </author>
<author initials="C." surname="Neumann"> <organization /> </author>
<author initials="D." surname="Furodet"> <organization /> </author>
<date month="June" year="2008"/>
</front>
<seriesInfo name="RFC" value="5170"/>
</reference>
<reference anchor="RFC5053">
<front>
<title>Raptor Forward Error Correction Scheme</title>
<author initials="M." surname="Luby" fullname="M. Luby"> <organization/> </author>
<author initials="A" surname="Shokrollahi" fullname="A. Shokrollahi"> <organization/> </author>
<author initials="M" surname="Watson" fullname="M. Watson"> <organization/> </author>
<author initials="T" surname="Stockhammer" fullname="T. Stockhammer"> <organization/> </author>
<date month="June" year="2007"/>
</front>
<seriesInfo name="RFC" value="5053"/>
</reference>
<?rfc include='reference.RFC.5775'?>
<reference anchor="RFC5740">
<front>
<title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast
(NORM) Protocol</title>
<author initials="B." surname="Adamson"> <organization></organization> </author>
<author initials="C." surname="Bormann"> <organization></organization> </author>
<author initials="M." surname="Handley"> <organization></organization> </author>
<author initials="J." surname="Macker"> <organization></organization> </author>
<date month="November" year="2009" />
</front>
<seriesInfo name="RFC" value="5740" />
</reference>
<!-- =================================================== -->
<!--
<reference anchor="RFC3447">
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials="J." surname="Jonsson" fullname="J. Jonsson"> <organization/> </author>
<author initials="B." surname="Kaliski" fullname="B. Kaliski"> <organization/> </author>
<date year="2003" month="February"/>
</front>
<seriesInfo name="RFC" value="3447"/>
<format type="TXT" octets="143173" target="ftp://ftp.isi.edu/in-notes/rfc3447.txt"/>
</reference>
-->
<!--
<reference anchor="RFC4303">
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials="S." surname="Kent" fullname="S. Kent"> <organization/> </author>
<date year="2005" month="December"/>
</front>
<seriesInfo name="RFC" value="4303"/>
<format type="TXT" octets="114315" target="ftp://ftp.isi.edu/in-notes/rfc4303.txt"/>
</reference>
-->
<!--
<reference anchor="RFC2104">
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author fullname="H. Krawczyk"> <organization/> </author>
<author fullname="M. Bellare"> <organization/> </author>
<author fullname="R. Canetti"> <organization/> </author>
<date month="February" year="1997"/>
</front>
<seriesInfo name="RFC" value="2104"/>
</reference>
-->
<!--
<reference anchor='RFC3711'>
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials='M.' surname='Baugher' fullname='M. Baugher'><organization /></author>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<author initials='M.' surname='Naslund' fullname='M. Naslund'><organization /></author>
<author initials='E.' surname='Carrara' fullname='E. Carrara'><organization /></author>
<author initials='K.' surname='Norrman' fullname='K. Norrman'><organization /></author>
<date year='2004' month='March' />
</front>
<seriesInfo name='RFC' value='3711' />
<format type='TXT' octets='134270' target='ftp://ftp.isi.edu/in-notes/rfc3711.txt' />
</reference>
-->
<!--
<reference anchor="RFC4082">
<front>
<title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction</title>
<author fullname="A. Perrig"> <organization/> </author>
<author fullname="D. Song"> <organization/> </author>
<author fullname="R. Canetti"> <organization/> </author>
<author fullname="J.D. Tygar"> <organization/> </author>
<author fullname="B. Briscoe"> <organization/> </author>
<date month="June" year="2005"/>
</front>
<seriesInfo name="RFC" value="4082"/>
</reference>
-->
<!--
<reference anchor="RFC4383">
<front>
<title>
The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
</title>
<author initials="M." surname="Baugher" fullname="M. Baugher"><organization/></author>
<author initials="E." surname="Carrara" fullname="E. Carrara"><organization/></author>
<date year="2006" month="February"/>
</front>
<seriesInfo name="RFC" value="4383"/>
<format type="TXT" octets="41766" target="ftp://ftp.isi.edu/in-notes/rfc4383.txt"/>
</reference>
-->
<!--
<reference anchor="RFC3275">
<front>
<title>(Extensible Markup Language) XML-Signature Syntax and Processing</title>
<author initials="D." surname="Eastlake" fullname="D. Eastlake"> <organization/>
</author>
<author initials="J." surname="Reagle" fullname="J. Reagle"> <organization/>
</author>
<author initials="D." surname="Solo" fullname="D. Solo"> <organization/>
</author>
<date year="2002" month="March"/>
</front>
<seriesInfo name="RFC" value="3275"/>
<format type="TXT" octets="164198" target="ftp://ftp.isi.edu/in-notes/rfc3275.txt"/>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:15:57 |