draft-ietf-rmt-bb-fec-03.txt   draft-ietf-rmt-bb-fec-04.txt 
Internet Engineering Task Force RMT WG Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-fec-03.txt L.Vicisano/Cisco draft-ietf-rmt-bb-fec-04.txt L.Vicisano/Cisco
J.Gemmell/Microsoft J.Gemmell/Microsoft
L.Rizzo/ACIRI and Univ. Pisa L.Rizzo/ACIRI and Univ. Pisa
M.Handley/ACIRI M.Handley/ACIRI
J. Crowcroft/UCL J. Crowcroft/UCL
19 July 2001 18 October 2001
Expires: January 2002 Expires: April 2002
RMT BB Forward Error Correction Codes RMT BB Forward Error Correction Codes
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Abstract Abstract
This memo describes the abstract packet formats and IANA This memo describes the abstract packet formats and IANA
registration procedures for use of Forward Error Correction registration procedures for use of Forward Error Correction
(FEC) codes within the context of reliable IP multicast (FEC) codes within the context of reliable IP multicast
transport. This memo should be read in conjunction with and transport. This memo should be read in conjunction with and
uses the terminology of the companion memo [1], which uses the terminology of the companion memo [1], which
describes the use of Forward Error Correction (FEC) codes describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and within the context of reliable IP multicast transport and
^L
provides an introduction to some commonly used FEC codes. provides an introduction to some commonly used FEC codes.
1. FEC Abstract Packet Fields and Out-of-Band Information 1. FEC Abstract Packet Fields and Out-of-Band Information
This section specifies the information that protocol packets must carry This section describes FEC information that is either to be sent out-of-
to implement the various forms of FEC-based reliability. A session is band or in packets. The FEC information is associated with transmission
defined to be all the information associated with a transmission of data of data about a particular object. There are three classes of packets
about a particular object by a single sender. There are three classes that may contain FEC information: data packets, session-control packets
of packets that may contain FEC information within a session: data and feedback packets. They generally contain different kinds of FEC
packets, session-control packets and feedback packets. They generally information. Note that some protocols may not use session-control or
contain different kinds of FEC information. Note that some protocols do feedback packets.
not use feedback packets.
Data packets may sometime serve as session-control packets as well; both Data packets may sometimes serve as session-control packets as well;
data and session-control packets generally travel downstream (from the both data and session-control packets generally travel downstream from
sender towards receivers) and are addressed to a multicast IP address the sender towards receivers and are sent to a multicast channel or to a
(sometime they might be addressed to the unicast address of a specific specific receiver using unicast.
receiver). In the following, for simplicity we will refer to both data
and session control packets as downstream-traveling packets, or simply
downstream packets.
As a general rule, feedback packets travel upstream (from receivers to As a general rule, feedback packets travel upstream from receivers to
the sender) and are addressed to the unicast address of the sender. the sender. Sometimes, however, they might be sent to a multicast
Sometimes, however, they might be addressed to a multicast IP address or channel or to another receiver or to some intermediate node or
to the unicast address of a receiver or also the the unicast address of neighboring router that provides recovery services.
some different node (an intermediate node that provides recovery
services or a neighboring router).
The FEC-related information that can be present in downstream packets This document specifies the FEC information that must be carried in data
can be classified as follows: packets and the other FEC information that must be communicated either
out-of-band or in data packets. This document does not specify out-of-
band methods nor does it specify the way out-of-band FEC information is
associated with FEC information carried in data packets. These methods
must be specified in a complete protocol instantiation that uses the FEC
building block. FEC information is classified as follows:
1) FEC Encoding Identifier 1) FEC Encoding ID
Identifies the FEC encoding being used and has the purpose of Identifies the FEC encoder being used and allows receivers to
allowing receivers to select the appropriate FEC decoder. As a select the appropriate FEC decoder. The value of the FEC Encoding
general rule, the "FEC Encoding Identifier" MUST be the same for a ID MUST be the same for all transmission of data related to a
given session, i.e., for all transmission of data related to a
particular object, but MAY vary across different transmissions of particular object, but MAY vary across different transmissions of
data about different objects in different sessions, even if data about different objects, even if transmitted to the same set
transmitted using the same set of multicast groups and/or using a of multicast channels and/or using a single upper-layer session.
single upper-layer session. The FEC encoding ID is subject to IANA registration.
2) FEC payload ID 2) FEC Encoding Name
Identifies the symbol(s) in the payload of the packet. The content Provides a more specific identification of the FEC encoder being
of this piece of information depends on the encoder being used used for an Under-Specified FEC scheme. This value is not used
for Fully-Specified FEC schemes. (See Section 1.1 for the
definition of Under-Specified and Fully-Specified FEC schemes.)
The FEC encoding name is scoped by the FEC encoding ID, and is
subject to IANA registration.
^L 3) FEC payload ID
(e.g. in Block FEC codes this may be the combination of block
index and encoding symbol identifier; in ideal expandable FEC
codes this may be just a flat encoding symbol identifier).
3) FEC Object Transmission Information Identifies the encoding symbol(s) in the payload of the packet.
The fields in the FEC Payload ID depend on the encoder being used
(e.g. in Block and Expandable FEC codes this may be the
combination of block number and encoding symbol ID).
4) FEC Object Transmission Information
This is information regarding the encoding of a specific object This is information regarding the encoding of a specific object
needed by the FEC decoder (e.g. for Block FEC codes this may be needed by the FEC decoder (e.g. for Block and Expandable FEC codes
the combination of block length and object length). This might this may be the combination of the source block lengths and the
also include general parameters of the FEC encoder. Note that, in object length). This might also include specific parameters of
strict terms, the "FEC Encoding Identifier" belongs to this class the FEC encoder.
of information, however, for practical purposes, we will consider
it separately.
All the classes of information above, except 2), can either be The FEC Encoding ID, FEC Encoding Name (for Under-Specified FEC schemes)
transmitted within the transport session (using protocol packet-header and the FEC Object Transmission Information can be sent to a receiver
fields) or out of band. The information described in 2) MUST be within the data packet headers, within session control packets, or by
transmitted in data-packet header fields, as it provides a description some other means. In any case, the means for communicating this to a
of the data contained in the packet. In the following we will specify receiver is out of the scope of this document. The FEC Payload ID MUST
the content of 1), 2) and 3) regardless of whether these pieces of be included in the data packet header fields, as it provides a
information are transmitted in protocol packets or out of band. This description of the data contained in the packet.
document neither specifies out-of-band methods to transport the
information nor does it specify the way out-of-band information is
associated with packet payloads. This last task is devolved to an upper-
layer protocol.
Within the context of FEC repair schemes, feedback packets are Within the context of FEC repair schemes, feedback packets are
(optionally) used to request FEC retransmission. The FEC-related (optionally) used to request FEC retransmission. The FEC-related
information present in feedback packets usually contains an FEC Block information present in feedback packets usually contains an FEC Block ID
Identifier, that defines the block that is being repaired, and the that defines the block that is being repaired, and the number of Repair
number of Repair Symbols requested. Although this is the most common Symbols requested. Although this is the most common case, variants are
case, variants are possible in which the receivers provide more specific possible in which the receivers provide more specific information about
information about the Repair Symbols requested (e.g. an index range or a the Repair Symbols requested (e.g. an index range or a list of symbols
list of symbols accepted). It is also possible to include multiple of accepted). It is also possible to include multiple of these requests in
these request in a single feedback packet. a single feedback packet.
This document does not provide any detail about the format of FEC
information in feedback packets.
1.1. FEC Encoding Identifier
This is a numeric index that identifies a specific FEC scheme OR a class This document does not provide any detail about feedback schemes used in
of encoding schemes that share the same format of "FEC Payload ID" and combination with FEC nor the format of FEC information in feedback
"FEC Object Transmission Information". packets. If feedback packets are used in a complete protocol
instantiation, these details must be provided in the protocol
instantiation specification.
^L 1.1. FEC Encoding ID and FEC Encoding Name
The FEC Encoding Identifier identifies a specific FEC scheme when the The FEC Encoding ID is a numeric index that identifies a specific FEC
encoding scheme is formally and fully specified, in a way that
independent implementors can implement both encoder and decoder from the
specification. Companion documents of this specification may specify
such FEC schemes and associate them with "FEC Encoding Identifier"
values. These documents MUST also specify a correspondent format for the
"FEC Payload ID" and "FEC Object Transmission Information". Currently
FEC Encoding Identifiers in the range 0-127 are reserved for this class
of encoding schemes (fully-specified schemes).
It is possible that a FEC scheme cannot be completely specified or that scheme OR a class of encoding schemes that share the same FEC Payload ID
such a specification is simply not available or also that a party exists format.
that owns the encoding scheme and it is not willing to disclose its
algorithm. We refer to these encoding schemes as "Under-Specified"
schemes. Under-specified schemes can still be identified as follows:
o A format of the fields "FEC Payload ID" and "FEC Object Transmission An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is
Information" MUST be defined for the encoding scheme. formally and fully specified, in a way that independent implementors can
implement both encoder and decoder from a specification that is an IETF
RFC. The FEC Encoding ID uniquely identifies a Fully-Specified FEC
scheme. Companion documents of this specification may specify Fully-
Specified FEC schemes and associate them with FEC Encoding ID values.
These documents MUST also specify a format for the FEC Payload ID and
specify the information in the FEC Object Transmission Information.
o A value of "FEC Encoding Identifier" MUST be reserved and associated It is possible that a FEC scheme cannot be a Fully-Specified FEC scheme,
to the format definitions above. An already reserved "FEC Encoding because a specification is simply not available or that a party exists
Identifier" MUST be reused if it is associated to the same format that owns the encoding scheme and is not willing to disclose the
of "FEC Payload ID" and "FEC Object Transmission Information" as the algorithm or specification. We refer to such an FEC encoding schemes as
ones needed for the new under-specified FEC scheme. an Under-Specified FEC scheme. The following holds for an Under-
Specified FEC scheme:
o A value of "FEC Encoding Name" must be reserved (see below). o The format of the FEC Payload ID and the specific information in the
FEC Object Transmission Information MUST be defined for the Under-
Specified FEC scheme.
An Under-specified FEC scheme is completely identified by the tuple (FEC o A value for the FEC Encoding ID MUST be reserved and associated with
Encoding Identifier, FEC Encoding Name). The tuple MUST identify a the format of the FEC Payload ID and the specific information in the
single scheme that has at least one implementation. The party that owns FEC Object Transmission Information. An already reserved FEC
this tuple MUST be able to provide information on how to obtain the Encoding ID value MUST be reused if it is associated with the same
under-specified FEC scheme identified by the tuple (e.g. a pointer to a format of FEC Payload ID and the same information in the FEC Object
publicly available reference-implementation or the name and contacts of Transmission Information as the ones needed for the new Under-
a company that sells it, either separately or embedded in another Specified FEC scheme.
product).
"FEC Encoding Names" are numeric identifiers scoped by a FEC Encoding o A value for the FEC Encoding Name MUST be reserved.
Identifier.
The FEC Encoding Name MUST be part of the "FEC Object Transmission An Under-specified FEC scheme is fully identified by the tuple (FEC
Information" and must be communicated to receivers together with the FEC Encoding ID, FEC Encoding Name). The tuple MUST identify a single scheme
Encoding Identifier. that has at least one implementation. The party that owns this tuple
MUST be able to provide information on how to obtain the Under-Specified
FEC scheme identified by the tuple, e.g. a pointer to a publicly
available reference-implementation or the name and contacts of a company
that sells it, either separately or embedded in another product.
Different FEC schemes that share the same FEC Encoding Identifier -- but Different Under-Specified FEC schemes that share the same FEC Encoding
have different FEC Encoding Names -- also share the same format of FEC ID -- but have different FEC Encoding Names -- also share the same
Payload ID and FEC Object Transmission Information. format of FEC Payload ID and specify the same information in the FEC
Object Transmission Information.
^L This specification reserves the range 0-127 for the values of FEC
This specification reserves the range 0-127 of FEC Encoding Identifiers Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for
for fully-specified encoding schemes and the range 128-255 for under- the values of Under-Specified FEC schemes.
specified encoding schemes.
1.2. FEC Payload ID and FEC Object Transmission Information 1.2. FEC Payload ID and FEC Object Transmission Information
A document that specifies an encoding scheme and reserves a value A document that specifies an FEC scheme and reserves a value of FEC
of FEC Encoding Identifier MUST define a packet-field format for FEC Encoding ID MUST define a packet format for the FEC Payload ID and
Payload ID and FEC Object Transmission Information according to the need specify the information in the FEC Object Transmission Information
of the encoding scheme. This also applies to documents that reserves according to the needs of the encoding scheme. This applies to documents
values of FEC Encoding Identifiers for under-specified encoding schemes. that reserve values of FEC Encoding IDs for both Fully-Specified and
In this case the FEC Object Transmission Information must also include a Under-Specified FEC schemes.
field to contain the "FEC Encoding Name".
A packet field definition of FEC Object Transmission Information MUST be
provided despite the fact that a protocol instantiation may decide to
communicate this information out of band.
All packet field definitions (FEC Payload ID and FEC Object Transmission
Information) MUST be fully specified at the level of bit-fields and they
must have a length that is a multiple of a 4-byte word (this is to
facilitate the alignment of packet fields in protocol instantiations).
Note that the specification of FEC Payload ID MUST allow an The packet format definition for the FEC Payload ID MUST specify the
implementation-independent identification of the packet payload even in meaning and layout of the fields down to the level of specific bits.
the case of Under-Specified encoding schemes. The FEC Payload ID MUST have a length that is a multiple of a 4-byte
word. This requirement facilitates the alignment of packet fields in
protocol instantiations.
2. Preassigned FEC Encoding Identifiers 2. Preassigned FEC Encoding IDs
This section specifies the FEC Encoding Identifier and the relative This section specifies the FEC Encoding ID and the associated FEC
packets field for a number of known schemes that follow under the class Payload ID format and the specific information in the FEC Object
of under-specified FEC schemes. Others may be specified in companion Transmission Information for a number of known Under-Specified FEC
schemes. Under-specified FEC schemes that use the same FEC Payload ID
format and specific information in the FEC Object Transmission
Information as for one of the FEC Encoding IDs specified in this section
MUST use the corresponding FEC Encoding ID. Other FEC Encoding IDs may
be specified for other Under-Specified FEC schemes in companion
documents. documents.
2.1. Small Block, Large Block and Expandable FEC Codes 2.1. Small Block, Large Block and Expandable FEC Codes
This section reserves a FEC Encoding Identifier for the families of This subsection reserves the FEC Encoding ID value 128 for the Under-
codes described in [1], and specifies the relative packet fields. Specified FEC schemes described in [1] that are called Small Block FEC
Under-specified FEC schemes that belong to this class MUST use this codes, Large Block FEC codes and Expandable FEC codes.
identifier and packet field definitions.
The FEC Encoding Identifier for under specified codes assigned to Small
Block, Large Block, and Expandable FEC Codes is 128.
^L
The FEC Payload ID is composed of an encoding symbol identifier and an The FEC Payload ID is composed of a Source Block Number and an Encoding
encoding block number structured as follows: Symbol ID structured as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding block number | | Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding symbol ID | | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In addition, a one bit FEC Encoding Flag MAY be included, and this flag The Source Block Number idenfities from which source block of the object
indicates whether the encoding symbol(s) in the payload of the packet the encoding symbol(s) in the payload are generated. These blocks are
are source symbol(s) or redundant symbol(s). numbered consecutively from 0 to N-1, where N is the number of source
blocks in the object.
The FEC Object Transmission Information has the following structure: The Encoding Symbol ID identifies which specific encoding symbol(s)
generated from the source block are carried in the packet payload. The
exact details of the correspondence between Encoding Symbol IDs and the
encoding symbol(s) in the packet payload are dependent on the particular
encoding algorithm used as identified by the Fec Encoding ID and by the
FEC Encoding Name, and these details may be proprietary.
0 1 2 3 The FEC Object Transmission Information has the following specific
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 information:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Encoding Name | Object Length (MSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Length (LSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that this structure limits the range of possible FEC Encoding Names o The total length of the object in bytes.
to 0-:-65536, despite the fact that the FEC Object Transmission
Information can also be transmitted out of band.
The Object Length, composed of a Most Significant Bytes portion (MSB) o The number of source blocks that the object is partitioned into, and
and a Least Significant Bytes portion (LSB), is expressed in bytes. the length of each source block in bytes.
2.2. Small Block Systematic FEC Codes 2.2. Small Block Systematic FEC Codes
The following definitions apply to systematic codes of small length This subsection reserves the FEC Encoding ID value 129 for the Under-
(total block length < 2^16). Specified FEC schemes described in [1] that are called Small Block
Systematic FEC codes. For Small Block Systematic FEC codes, each source
The FEC Encoding Identifier for under specified codes assigned to Small block is of length at most 65536 bytes.
Block Systematic FEC Codes is 129.
Although these codes can generally be accommodated by the FEC Encoding Although these codes can generally be accommodated by the FEC Encoding
ID described in Section 2.1, a specific FEC Encoding ID is defined for
^L Small Block Systematic FEC codes to allow more flexibility and to retain
header compactness. The small source block length and small exapansion
Identifier described in Section 2.1, a specific Encoding-ID is defined factor that often characterize systematic codes may require that the
for systematic codes to allow better flexibility and to retain header data source changes frequently the source block length. To allow the
compactness. The small source block length and small exapansion factor dynamic variation of the source block length and to communicate it to
that often characterize systematic codes may require that the data the receivers with low overhead, the block length is included in the FEC
source changes frequently the source block length. To allow the dynamic
variation of the source block length and to communicate it to the
receivers with low overhead, the block length is included in the FEC
Payload ID. Payload ID.
The FEC Payload ID is composed of the encoding block number, the The FEC Payload ID is composed of the Source Block Number, Source Block
encoding symbol identifier and the block length: Length and the Encoding Symbol ID:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding block number | | Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source block length | encoding symbol ID | | Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FEC Object Transmission Information, when used, has the following The Source Block Number idenfities from which source block of the object
structure: the encoding symbol(s) in the payload are generated. These blocks are
numbered consecutively from 0 to N-1, where N is the number of source
blocks in the object.
0 1 2 3 The Source Block Length is the length in units of source symbols of the
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 identified by the Source Block Number.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Encoding Name | Number of redundant symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When variable block-length is used, the number of redundant symbols is The Encoding Symbol ID identifies which specific encoding symbol(s)
to be interpreted as a maximum value (upper bound). This field is generated from the source block are carried in the packet payload. The
provided as an indication to allow receives to preallocate a decoder exact details of the correspondence between Encoding Symbol IDs and the
suitable for all the object blocks. encoding symbol(s) in the packet payload are dependent on the particular
encoding algorithm used as identified by the Fec Encoding ID and by the
FEC Encoding Name, and these details may be proprietary.
Note that this structure limits the range of possible FEC Encoding Names The FEC Object Transmission Information has the following specific
to 0-:-65536, despite the FEC Object Transmission Information can also information:
be transmitted out of band.
3. IANA Considerations o The total length of the object in bytes.
Values of FEC Encoding Identifiers and FEC Encoding Names are subject to o The maximum length in bytes of the encoding symbols that can be
IANA registration. FEC Encoding Identifiers and FEC Encoding Names are generated for any source block. This field is provided to allow
hierarchical: FEC Encoding Identifiers (at the top level) scope ranges receivers to preallocate buffer space that is suitable for decoding
to recover any source block.
^L o The length in bytes of a source symbol.
of FEC Encoding Names. Not all FEC Encoding Identifiers have a 3. IANA Considerations
corresponding FEC Encoding Name scope (see below).
A FEC Encoding Identifier is a numeric non-negative index. Value from 0 Values of FEC Encoding IDs and FEC Encoding Names are subject to IANA
to 127 are reserved for FEC encoders that are fully specified, as registration. FEC Encoding IDs and FEC Encoding Names are hierarchical:
described in section 3.1. The assignment of a FEC Encoding Identifier in FEC Encoding IDs scope ranges of FEC Encoding Names. Only FEC Encoding
this range can only be granted if the requestor can provide such a
specification published as an IETF RFC. Values greater than 127 can be
assigned to under-specified encoding schemes. Note: this specification
already assigns the values 128 and 129.
In any case values of FEC Encoding Identifiers can only be assigned if IDs that correspond to Under-Specified FEC schemes scope a corresponding
the required FEC packet fields corresponding to it (see section 1.2) are set of FEC Encoding Names.
specified in a RFC.
Each FEC Encoding Identifier assigned to an under-specified encoding The FEC Encoding ID is a numeric non-negative index. In this document,
scheme scopes an independent range of FEC Encoding Names (i.e. the same the range of values for FEC Encoding IDs is 0 and 255. Values from 0 to
value of FEC Encoding Name can be reused for different FEC Encoding 127 are reserved for Fully-Specified FEC schemes, as described in more
Identifiers). An FEC Encoding Name is a numeric non-negative index. The detail in Section 1.1. The assignment of a FEC Encoding ID in this range
document that reserves a FEC Encoding Identifier MAY also specify a can only be granted if the requestor can provide such a specification
range for the subordinate FEC Encoding Names. published as an IETF RFC, as described in more detail in Section 1.1.
Values from 128 to 255 are reserved for Under-Specified FEC schemes, as
described in more detail in Section 1.1. This specification already
assigns the values 128 and 129, as described in Section 2.
Under the scope of a FEC Encoding Identifier, FEC Encoding Names are Values of FEC Encoding IDs can only be assigned if the required format
assigned on a First Come First Served base to requestors that are able for the FEC Payload ID and the specific information in the FEC Object
to provide point of contact information and a pointer to publicly Transmission Information are specified in an IETF RFC.
accessible documentation describing the FEC scheme and ways to obtain it
(e.g. a pointer to a publicly available reference-implementation or the Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an
name and contacts of a company that sells it, either separately or independent range of FEC Encoding Names (i.e. the same value of FEC
embedded in another product). The requestor is responsible for keeping Encoding Name can be reused for different FEC Encoding IDs). An FEC
this information up to date. Encoding Name is a numeric non-negative index.
Under the scope of a FEC Encoding ID, FEC Encoding Names are assigned on
a First Come First Served base to requestors that are able to provide
point of contact information and a pointer to publicly accessible
documentation describing the Under-Specified FEC scheme and ways to
obtain it (e.g. a pointer to a publicly available reference-
implementation or the name and contacts of a company that sells it,
either separately or embedded in another product). The requestor is
responsible for keeping this information up to date.
4. Acknowledgments 4. Acknowledgments
Brian Adamson contributed to this document by shaping Section 2.2 and Brian Adamson contributed to this document by shaping Section 2.2 and
providing general feedback. We also wish to thank Vincent Roca for his providing general feedback. We also wish to thank Vincent Roca and
comments. Justin Chapweske for their comments.
5. References 5. References
[1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M., [1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M.,
Crowcroft, J., "The use of Forward Error Correction in Reliable Crowcroft, J., "The use of Forward Error Correction in Reliable
Multicast", Internet draft draft-ietf-rmt-info-fec-00.txt, November Multicast", Internet draft draft-ietf-rmt-info-fec-01.txt, October 2001.
2000.
^L
6. Authors' Addresses 6. Authors' Addresses
Michael Luby Michael Luby
luby@digitalfountain.com luby@digitalfountain.com
Digital Fountain, Inc. Digital Fountain, Inc.
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
skipping to change at page 10, line 5 skipping to change at page 10, line 5
1947 Center St. 1947 Center St.
Berkeley CA, USA, 94704 Berkeley CA, USA, 94704
Jon Crowcroft Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk J.Crowcroft@cs.ucl.ac.uk
Department of Computer Science Department of Computer Science
University College London University College London
Gower Street, Gower Street,
London WC1E 6BT, UK London WC1E 6BT, UK
^L
7. Full Copyright Statement 7. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
skipping to change at page 11, line 4 skipping to change at line 421
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE." FITNESS FOR A PARTICULAR PURPOSE."
^L
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/