draft-ietf-rmt-bb-fec-07.txt   rfc3452.txt 
Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-fec-07.txt L.Vicisano/Cisco
J.Gemmell/Microsoft
L.Rizzo/U. Pisa
M.Handley/ICIR
J. Crowcroft/Cambridge U.
3 September 2002
Expires: March 2003
Forward Error Correction building block Network Working Group M. Luby
Request for Comments: 3452 Digital Fountain
Category: Experimental L. Vicisano
Cisco
J. Gemmell
Microsoft
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
Forward Error Correction (FEC) Building Block
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This memo defines an Experimental Protocol for the Internet
provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working community. It does not specify an Internet standard of any kind.
documents of the Internet Engineering Task Force (IETF), its areas, and Discussion and suggestions for improvement are requested.
its working groups. Note that other groups may also distribute working Distribution of this memo is unlimited.
documents as Internet-Drafts.
Internet-Drafts are valid for a maximum of six months and may be Copyright Notice
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as a "work in progress".
The list of current Internet-Drafts can be accessed at Copyright (C) The Internet Society (2002). All Rights Reserved.
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see Abstract
http://www.ietf.org/shadow.html.
This document is a product of the IETF RMT WG. Comments should be This document generally describes how to use Forward Error Correction
addressed to the authors, or the WG's mailing list at rmt@lbl.gov. This (FEC) codes to efficiently provide and/or augment reliability for
memo defines an Experimental Protocol for the Internet community. It data transport. The primary focus of this document is the
does not specify an Internet standard of any kind. Discussion and application of FEC codes to one-to-many reliable data transport using
suggestions for improvement are requested. Distribution of this memo is IP multicast. This document describes what information is needed to
unlimited. identify a specific FEC code, what information needs to be
communicated out-of-band to use the FEC code, and what information is
needed in data packets to identify the encoding symbols they carry.
The procedures for specifying FEC codes and registering them with the
Internet Assigned Numbers Authority (IANA) are also described. This
document should be read in conjunction with and uses the terminology
of the companion document titled, "The Use of Forward Error
Correction (FEC) in Reliable Multicast".
Abstract Table of Contents
This document generally describes how to use Forward Error Correction
codes to efficiently provide and/or augment reliability for data
transport. The primary focus of this document is the application of
Forward Error Correction codes to one-to-many reliable data transport
using IP multicast. This document describes what information is needed
to identify a specific Forward Error Correction code, what information
needs to be communicated out-of-band to use the Forward Error Correction
code, and what information is needed in data packets to identify the
encoding symbols they carry. The procedures for specifying Forward
Error Correction codes and registering them with IANA are also
described. This document should be read in conjunction with and uses
the terminology of the companion document titled ``The Use of Forward
Error Correction in Reliable Multicast''.
Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . 3
3.1 FEC Encoding ID and FEC Instance ID. . . . . . . . . . . 5
3.2 FEC Payload ID and FEC Object Transmission Information . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . 7
5. Packet Header Fields . . . . . . . . . . . . . . . . . . . 8
5.1 Small Block, Large Block and Expandable FEC Codes. . . . 8
5.2 Small Block Systematic FEC Codes . . . . . . . . . . . . 9
6. Requirements from other building blocks. . . . . . . . . . 11
7. Security Considerations. . . . . . . . . . . . . . . . . . 11
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . 12
8.1 Explicit IANA Assignment Guidelines. . . . . . . . . . . 12
9. Intellectual Property Disclosure . . . . . . . . . . . . . 13
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 16
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. FEC Encoding ID and FEC Instance ID. . . . . . . . . . . . . . 6
3.2. FEC Payload ID and FEC Object Transmission
Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Applicability Statement . . . . . . . . . . . . . . . . . . . . . 8
5. Packet Header Fields. . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Small Block, Large Block and Expandable FEC
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Small Block Systematic FEC Codes . . . . . . . . . . . . . . . 11
6. Requirements from other building blocks . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Explicit IANA Assignment Guidelines. . . . . . . . . . . . . . 14
9. Intellectual Property Disclosure. . . . . . . . . . . . . . . . . 15
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document describes how to use Forward Error Correction (FEC) codes This document describes how to use Forward Error Correction (FEC)
to provide support for reliable delivery of content using IP multicast. codes to provide support for reliable delivery of content using IP
This document should be read in conjunction with and uses the multicast. This document should be read in conjunction with and uses
terminology of the companion document [4], which describes the use of the terminology of the companion document [4], which describes the
FEC codes within the context of reliable IP multicast transport and use of FEC codes within the context of reliable IP multicast
provides an introduction to some commonly used FEC codes. transport and provides an introduction to some commonly used FEC
codes.
This document describes a building block as defined in RFC3048 [9]. This This document describes a building block as defined in RFC 3048 [9].
document is a product of the IETF RMT WG and follows the general This document is a product of the IETF RMT WG and follows the general
guidelines provided in RFC3269 [3]. guidelines provided in RFC 3269 [3].
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2]. document are to be interpreted as described in RFC2119 [2].
Statement of Intent
This memo contains part of the definitions necessary to fully
specify a Reliable Multicast Transport protocol in accordance with
RFC 2357. As per RFC 2357, the use of any reliable multicast
protocol in the Internet requires an adequate congestion control
scheme.
While waiting for such a scheme to be available, or for an
existing scheme to be proven adequate, the Reliable Multicast
Transport working group (RMT) publishes this Request for Comments
in the "Experimental" category.
It is the intent of RMT to re-submit this specification as an IETF
Proposed Standard as soon as the above condition is met.
2. Rationale 2. Rationale
FEC codes are a valuable basic component of any transport protocol that FEC codes are a valuable basic component of any transport protocol
is to provide reliable delivery of content. Using FEC codes is valuable that is to provide reliable delivery of content. Using FEC codes is
in the context of IP multicast and reliable delivery because FEC valuable in the context of IP multicast and reliable delivery because
encoding symbols can be useful to all receivers for reconstructing FEC encoding symbols can be useful to all receivers for
content even when the receivers have received different encoding reconstructing content even when the receivers have received
symbols. Furthermore, FEC codes can ameliorate or even eliminate the different encoding symbols. Furthermore, FEC codes can ameliorate or
need for feedback from receivers to senders to request retransmission of even eliminate the need for feedback from receivers to senders to
lost packets. request retransmission of lost packets.
The goal of the FEC building block is to describe functionality directly The goal of the FEC building block is to describe functionality
related to FEC codes that is common to all reliable content delivery IP directly related to FEC codes that is common to all reliable content
multicast protocols, and to leave out any additional functionality that delivery IP multicast protocols, and to leave out any additional
is specific to particular protocols. The primary functionality functionality that is specific to particular protocols. The primary
described in this document that is common to all such protocols that use functionality described in this document that is common to all such
FEC codes are FEC encoding symbols for an object that is included in protocols that use FEC codes are FEC encoding symbols for an object
packets that flow from a sender to receivers. This document for example that is included in packets that flow from a sender to receivers.
does not describe how receivers may request transmission of particular This document for example does not describe how receivers may request
encoding symbols for an object. This is because although there are transmission of particular encoding symbols for an object. This is
protocols where requests for transmission are of use, there are also because although there are protocols where requests for transmission
protocols that do not require such requests. are of use, there are also protocols that do not require such
requests.
The companion document [4] should be consulted for a full explanation of The companion document [4] should be consulted for a full explanation
the benefits of using FEC codes for reliable content delivery using IP of the benefits of using FEC codes for reliable content delivery
multicast. FEC codes are also useful in the context of unicast, and using IP multicast. FEC codes are also useful in the context of
thus the scope and applicability of this document is not limited to IP unicast, and thus the scope and applicability of this document is not
multicast. limited to IP multicast.
3. Functionality 3. Functionality
This section describes FEC information that is either to be sent out-of- This section describes FEC information that is either to be sent
band or in packets. The FEC information is associated with transmission out-of-band or in packets. The FEC information is associated with
of data about a particular object. There are three classes of packets transmission of data about a particular object. There are three
that may contain FEC information: data packets, session-control packets classes of packets that may contain FEC information: data packets,
and feedback packets. They generally contain different kinds of FEC session-control packets and feedback packets. They generally contain
information. Note that some protocols may not use session-control or different kinds of FEC information. Note that some protocols may not
feedback packets. use session-control or feedback packets.
Data packets may sometimes serve as session-control packets as well; Data packets may sometimes serve as session-control packets as well;
both data and session-control packets generally travel downstream from both data and session-control packets generally travel downstream
the sender towards receivers and are sent to a multicast channel or to a from the sender towards receivers and are sent to a multicast channel
specific receiver using unicast. or to a specific receiver using unicast.
As a general rule, feedback packets travel upstream from receivers to As a general rule, feedback packets travel upstream from receivers to
the sender. Sometimes, however, they might be sent to a multicast the sender. Sometimes, however, they might be sent to a multicast
channel or to another receiver or to some intermediate node or channel or to another receiver or to some intermediate node or
neighboring router that provides recovery services. neighboring router that provides recovery services.
This document specifies the FEC information that must be carried in data This document specifies the FEC information that must be carried in
packets and the other FEC information that must be communicated either data packets and the other FEC information that must be communicated
out-of-band or in data packets. This document does not specify out-of- either out-of-band or in data packets. This document does not
band methods nor does it specify the way out-of-band FEC information is specify out-of-band methods nor does it specify the way out-of-band
associated with FEC information carried in data packets. These methods FEC information is associated with FEC information carried in data
must be specified in a complete protocol instantiation that uses the FEC packets. These methods must be specified in a complete protocol
building block. FEC information is classified as follows: instantiation that uses the FEC building block. FEC information is
classified as follows:
1) FEC Encoding ID 1) FEC Encoding ID
Identifies the FEC encoder being used and allows receivers to Identifies the FEC encoder being used and allows receivers to
select the appropriate FEC decoder. The value of the FEC Encoding select the appropriate FEC decoder. The value of the FEC Encoding
ID MUST be the same for all transmission of data related to a ID MUST be the same 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, even if transmitted to the same set data about different objects, even if transmitted to the same set
of multicast channels and/or using a single upper-layer session. of multicast channels and/or using a single upper-layer session.
The FEC Encoding ID is subject to IANA registration. The FEC Encoding ID is subject to IANA registration.
2) FEC Instance ID 2) FEC Instance ID
Provides a more specific identification of the FEC encoder being Provides a more specific identification of the FEC encoder being
used for an Under-Specified FEC scheme. This value is not used used for an Under-Specified FEC scheme. This value is not used
for Fully-Specified FEC schemes. (See Section 3.1 for the for Fully-Specified FEC schemes. (See Section 3.1 for the
definition of Under-Specified and Fully-Specified FEC schemes.) definition of Under-Specified and Fully-Specified FEC schemes.)
The FEC Instance ID is scoped by the FEC Encoding ID, and is The FEC Instance ID is scoped by the FEC Encoding ID, and is
subject to IANA registration. subject to IANA registration.
3) FEC Payload ID 3) FEC Payload ID
Identifies the encoding symbol(s) in the payload of the packet. Identifies the encoding symbol(s) in the payload of the packet.
The types and lengths of the fields in the FEC Payload ID, i.e., The types and lengths of the fields in the FEC Payload ID, i.e.,
the format of the FEC Payload ID, are determined by the FEC the format of the FEC Payload ID, are determined by the FEC
Encoding ID. The full specification of each field MUST be Encoding ID. The full specification of each field MUST be
uniquely determined by the FEC Encoding ID for Fully-Specified FEC uniquely determined by the FEC Encoding ID for Fully-Specified FEC
schemes, and MUST be uniquely determined by the combination of the schemes, and MUST be uniquely determined by the combination of the
FEC Encoding ID and the FEC Instance ID for Under-Specified FEC FEC Encoding ID and the FEC Instance ID for Under-Specified FEC
schemes. As an example, for the Under-Specified FEC scheme with schemes. As an example, for the Under-Specified FEC scheme with
FEC Encoding ID 129 defined in Section 5.1, the fields in the FEC FEC Encoding ID 129 defined in Section 5.1, the fields in the FEC
Payload ID are a 32-bit Source Block Number followed by a 32-bit Payload ID are a 32-bit Source Block Number followed by a 32-bit
Encoding Symbol ID, where the full specification of both of these Encoding Symbol ID, where the full specification of both of these
fields depends on the FEC Instance ID. fields depends on the FEC Instance ID.
4) FEC Object Transmission Information 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. As an example, for the Under-Specified needed by the FEC decoder. As an example, for the Under-Specified
FEC scheme with FEC Encoding ID 129 defined in Section 5.1, this FEC scheme with FEC Encoding ID 129 defined in Section 5.1, this
information might include the lengths of the different source information might include the lengths of the different source
blocks that make up the object and the overall object length. blocks that make up the object and the overall object length.
This might also include specific parameters of the FEC encoder. This might also include specific parameters of the FEC encoder.
The FEC Encoding ID, FEC Instance ID (for Under-Specified FEC schemes) The FEC Encoding ID, FEC Instance ID (for Under-Specified FEC
and the FEC Object Transmission Information can be sent to a receiver schemes) and the FEC Object Transmission Information can be sent to a
within the data packet headers, within session control packets, or by receiver within the data packet headers, within session control
some other means. In any case, the means for communicating this to a packets, or by some other means. In any case, the means for
receiver is outside the scope of this document. The FEC Payload ID MUST communicating this to a receiver is outside the scope of this
be included in the data packet header fields, as it provides a document. The FEC Payload ID MUST be included in the data packet
description of the encoding symbols contained in the packet. header fields, as it provides a description of the encoding symbols
contained in the packet.
3.1. FEC Encoding ID and FEC Instance ID 3.1. FEC Encoding ID and FEC Instance ID
The FEC Encoding ID is a numeric index that identifies a specific FEC The FEC Encoding ID is a numeric index that identifies a specific FEC
scheme OR a class of encoding schemes that share the same FEC Payload ID scheme OR a class of encoding schemes that share the same FEC Payload
format. ID format.
An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme
formally and fully specified, in a way that independent implementors can is formally and fully specified, in a way that independent
implement both encoder and decoder from a specification that is an IETF implementors can implement both encoder and decoder from a
RFC. The FEC Encoding ID uniquely identifies a Fully-Specified FEC specification that is an IETF RFC. The FEC Encoding ID uniquely
scheme. Companion documents of this specification may specify Fully- identifies a Fully-Specified FEC scheme. Companion documents of this
Specified FEC schemes and associate them with FEC Encoding ID values. 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 These documents MUST also specify a format for the FEC Payload ID and
specify the information in the FEC Object Transmission Information. specify the information in the FEC Object Transmission Information.
It is possible that a FEC scheme cannot be a Fully-Specified FEC scheme, It is possible that a FEC scheme may not be a Fully-Specified FEC
because a specification is simply not available or that a party exists scheme, because either a specification is simply not available or a
that owns the encoding scheme and is not willing to disclose the party exists that owns the encoding scheme and is not willing to
algorithm or specification. We refer to such an FEC encoding schemes as disclose the algorithm or specification. We refer to such an FEC
an Under-Specified FEC scheme. The following holds for an Under- encoding schemes as an Under-Specified FEC scheme. The following
Specified FEC scheme: holds for an Under-Specified FEC scheme:
o The fields and their formats of the FEC Payload ID and the specific o The fields and their formats of the FEC Payload ID and the specific
information in the FEC Object Transmission Information MUST be information in the FEC Object Transmission Information MUST be
defined for the Under-Specified FEC scheme. defined for the Under-Specified FEC scheme.
o A value for the FEC Encoding ID MUST be reserved and associated with o A value for the FEC Encoding ID MUST be reserved and associated
the fields and their formats of the FEC Payload ID and the specific with the fields and their formats of the FEC Payload ID and the
information in the FEC Object Transmission Information. An already specific information in the FEC Object Transmission Information.
reserved FEC Encoding ID value MUST be reused if the associated FEC An already reserved FEC Encoding ID value MUST be reused if the
Payload ID has the same fields and formats and the FEC Object associated FEC Payload ID has the same fields and formats and the
Transmission Information has same information as the ones needed for FEC Object Transmission Information has same information as the
the new Under-Specified FEC scheme. ones needed for the new Under-Specified FEC scheme.
o A value for the FEC Instance ID MUST be reserved. o A value for the FEC Instance ID MUST be reserved.
An Under-specified FEC scheme is fully identified by the tuple (FEC An Under-Specified FEC scheme is fully identified by the tuple (FEC
Encoding ID, FEC Instance ID). The tuple MUST identify a single scheme Encoding ID, FEC Instance ID). The tuple MUST identify a single
that has at least one implementation. The party that owns this tuple scheme that has at least one implementation. The party that owns
MUST be able to provide information on how to obtain the Under-Specified this tuple MUST be able to provide information on how to obtain the
FEC scheme identified by the tuple, e.g. a pointer to a publicly Under-Specified FEC scheme identified by the tuple, e.g., a pointer
available reference-implementation or the name and contacts of a company to a publicly available reference-implementation or the name and
that sells it, either separately or embedded in another product. contacts of a company that sells it, either separately or embedded in
another product.
Different Under-Specified FEC schemes that share the same FEC Encoding Different Under-Specified FEC schemes that share the same FEC
ID -- but have different FEC Instance IDs -- also share the same fields Encoding ID -- but have different FEC Instance IDs -- also share the
and corresponding formats of the FEC Payload ID and specify the same same fields and corresponding formats of the FEC Payload ID and
information in the FEC Object Transmission Information. specify the same information in the FEC Object Transmission
Information.
This specification reserves the range 0-127 for the values of FEC This specification reserves the range 0-127 for the values of FEC
Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for Encoding IDs for Fully-Specified FEC schemes and the range 128-255
the values of Under-Specified FEC schemes. for the values of Under-Specified FEC schemes.
3.2. FEC Payload ID and FEC Object Transmission Information 3.2. FEC Payload ID and FEC Object Transmission Information
A document that specifies an FEC scheme and reserves a value of FEC A document that specifies an FEC scheme and reserves a value of FEC
Encoding ID MUST define the fields and their packet formats for the FEC Encoding ID MUST define the fields and their packet formats for the
Payload ID and specify the information in the FEC Object Transmission FEC Payload ID and specify the information in the FEC Object
Information according to the needs of the encoding scheme. This applies Transmission Information according to the needs of the encoding
to documents that reserve values of FEC Encoding IDs for both Fully- scheme. This applies to documents that reserve values of FEC
Specified and Under-Specified FEC schemes. Encoding IDs for both Fully-Specified and Under-Specified FEC
schemes.
The specification of the fields and their packet formats for the FEC The specification of the fields and their packet formats for the FEC
Payload ID MUST specify the meaning of the fields their format down to Payload ID MUST specify the meaning of the fields and their format
the level of specific bits. The total length of all the fields in the down to the level of specific bits. The total length of all the
FEC Payload ID MUST have a length that is a multiple of a 4-byte word. fields in the FEC Payload ID MUST have a length that is a multiple of
This requirement facilitates the alignment of packet fields in protocol a 4-byte word. This requirement facilitates the alignment of packet
instantiations. fields in protocol instantiations.
4. Applicability Statement 4. Applicability Statement
The FEC building block applies to creating and sending encoding symbols The FEC building block applies to creating and sending encoding
for objects that are to be reliably transported using IP multicast or symbols for objects that are to be reliably transported using IP
unicast. The FEC building block does not provide higher level session multicast or unicast. The FEC building block does not provide higher
support. Thus, for example, many objects may be transmitted within the level session support. Thus, for example, many objects may be
same session, in which case a higher level building block may carry a transmitted within the same session, in which case a higher level
unique Transport Object ID (TOI) for each object in the session to allow building block may carry a unique Transport Object ID (TOI) for each
the receiver to demultiplex packets within the session based on the TOI object in the session to allow the receiver to demultiplex packets
within each packet. As another example, a receiver may subscribe to within the session based on the TOI within each packet. As another
more than one session at a time. In this case a higher level building example, a receiver may subscribe to more than one session at a time.
block may carry a unique Transport Session ID (TSI) for each session to
allow the receiver to demultiplex packets based on the TSI within each
packet.
Other building blocks may supply direct support for carrying out-of-band In this case a higher level building block may carry a unique
information directly relevant to the FEC building block to receivers. Transport Session ID (TSI) for each session to allow the receiver to
For example, the length of the object is part of the FEC Object demultiplex packets based on the TSI within each packet.
Transmission Information that may in some cases be communicated out-of-
band to receivers, and one mechanism for providing this to receivers is
within the context of another building block that provides this
information.
Some protocols may use FEC codes as a mechanism for repairing the loss Other building blocks may supply direct support for carrying out-of-
of packets. Within the context of FEC repair schemes, feedback packets band information directly relevant to the FEC building block to
are (optionally) used to request FEC retransmission. The FEC-related receivers. For example, the length of the object is part of the FEC
information present in feedback packets usually contains an FEC Block ID Object Transmission Information that may in some cases be
that defines the block that is being repaired, and the number of Repair communicated out-of-band to receivers, and one mechanism for
Symbols requested. Although this is the most common case, variants are providing this to receivers is within the context of another building
possible in which the receivers provide more specific information about block that provides this information.
the Repair Symbols requested (e.g. an index range or a list of symbols
accepted). It is also possible to include multiple of these requests in
a single feedback packet. This document does not provide any detail
about feedback schemes used in combination with FEC nor the format of
FEC information in feedback packets. If feedback packets are used in a
complete protocol instantiation, these details must be provided in the
protocol instantiation specification.
The FEC building block does not provide any support for congestion Some protocols may use FEC codes as a mechanism for repairing the
control. Any complete protocol MUST provide congestion control that loss of packets. Within the context of FEC repair schemes, feedback
conforms to RFC2357 [5], and thus this MUST be provided by another packets are (optionally) used to request FEC retransmission. The
building block when the FEC building block is used in a protocol. FEC-related information present in feedback packets usually contains
an FEC Block ID that defines the block that is being repaired, and
the number of Repair Symbols requested. Although this is the most
common case, variants are possible in which the receivers provide
more specific information about the Repair Symbols requested (e.g.,
an index range or a list of symbols accepted). It is also possible
to include multiple requests in a single feedback packet. This
document does not provide any detail about feedback schemes used in
combination with FEC nor the format of FEC information in feedback
packets. If feedback packets are used in a complete protocol
instantiation, these details must be provided in the protocol
instantiation specification.
A more complete description of the applicability of FEC codes can be The FEC building block does not provide any support for congestion
found in the companion document [4]. control. Any complete protocol MUST provide congestion control that
conforms to RFC 2357 [5], and thus this MUST be provided by another
building block when the FEC building block is used in a protocol.
A more complete description of the applicability of FEC codes can be
found in the companion document [4].
5. Packet Header Fields 5. Packet Header Fields
This section specifies the FEC Encoding ID and the associated FEC This section specifies the FEC Encoding ID, the associated FEC
Payload ID format and the specific information in the FEC Object Payload ID format, and the specific information in the FEC Object
Transmission Information for a number of known Under-Specified FEC Transmission Information for a number of known Under-Specified FEC
schemes. Under-specified FEC schemes that use the same FEC Payload ID schemes. Under-Specified FEC schemes that use the same FEC Payload
fields and formats and specific information in the FEC Object ID fields, formats, and specific information in the FEC Object
Transmission Information as for one of the FEC Encoding IDs specified in Transmission Information (as for one of the FEC Encoding IDs
this section MUST use the corresponding FEC Encoding ID. Other FEC specified in this section) MUST use the corresponding FEC Encoding
Encoding IDs may be specified for other Under-Specified FEC schemes in ID. Other FEC Encoding IDs may be specified for other Under-
companion documents. Specified FEC schemes in companion documents.
5.1. Small Block, Large Block and Expandable FEC Codes 5.1. Small Block, Large Block and Expandable FEC Codes
This subsection reserves the FEC Encoding ID value 128 for the Under- This subsection reserves the FEC Encoding ID value 128 for the
Specified FEC schemes described in [4] that are called Small Block FEC Under-Specified FEC schemes described in [4] that are called Small
codes, Large Block FEC codes and Expandable FEC codes. Block FEC codes, Large Block FEC codes and Expandable FEC codes.
The FEC Payload ID is composed of a Source Block Number and an Encoding The FEC Payload ID is composed of a Source Block Number and an
Symbol ID structured as follows: Encoding 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number | | Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID | | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Source Block Number identifies from which source block of the object The Source Block Number identifies from which source block of the
the encoding symbol(s) in the payload are generated. These blocks are object the encoding symbol(s) in the payload are generated. These
numbered consecutively from 0 to N-1, where N is the number of source blocks are numbered consecutively from 0 to N-1, where N is the
blocks in the object. number of source blocks in the object.
The Encoding Symbol ID identifies which specific encoding symbol(s) The Encoding Symbol ID identifies which specific encoding symbol(s)
generated from the source block are carried in the packet payload. The generated from the source block are carried in the packet payload.
exact details of the correspondence between Encoding Symbol IDs and the The exact details of the correspondence between Encoding Symbol IDs
encoding symbol(s) in the packet payload are dependent on the particular and the encoding symbol(s) in the packet payload are dependent on the
encoding algorithm used as identified by the Fec Encoding ID and by the particular encoding algorithm used as identified by the FEC Encoding
FEC Instance ID, and these details may be proprietary. ID and by the FEC Instance ID, and these details may be proprietary.
The FEC Object Transmission Information has the following specific The FEC Object Transmission Information has the following specific
information: information:
o The FEC Encoding ID 128. o The FEC Encoding ID 128.
o The FEC Instance ID associated with the FEC Encoding ID 128 to be o The FEC Instance ID associated with the FEC Encoding ID 128 to be
used. used.
o The total length of the object in bytes. o The total length of the object in bytes.
o The number of source blocks that the object is partitioned into, and o The number of source blocks that the object is partitioned into,
the length of each source block in bytes. and the length of each source block in bytes.
How this out-of-band information is communicated is outside the scope of To understand how this out-of-band information is communicated, one
this document. As an example the source block lengths may be derived by must look outside the scope of this document. One example may be
a fixed algorithm from the object length. As another example, it may be that the source block lengths may be derived by a fixed algorithm
that all source blocks are the same length and this is what is passed from the object length. Another example may be that all source
out-of-band to the receiver. As a third example, it could be that the blocks are the same length and this is what is passed out-of-band to
full sized source block length is provided and this is the length used the receiver. A third example could be that the full sized source
for all but the last source block, which is calculated based on the full block length is provided and this is the length used for all but the
source block length and the object length. last source block, which is calculated based on the full source block
length and the object length.
5.2. Small Block Systematic FEC Codes 5.2. Small Block Systematic FEC Codes
This subsection reserves the FEC Encoding ID value 129 for the Under- This subsection reserves the FEC Encoding ID value 129 for the
Specified FEC schemes described in [4] that are called Small Block Under-Specified FEC schemes described in [4] that are called Small
Systematic FEC codes. For Small Block Systematic FEC codes, each source Block Systematic FEC codes. For Small Block Systematic FEC codes,
block is of length at most 65536 source symbols. each source block is of length at most 65536 source symbols.
Although these codes can generally be accommodated by the FEC Encoding Although these codes can generally be accommodated by the FEC
ID described in Section 5.1, a specific FEC Encoding ID is defined for Encoding ID described in Section 5.1, a specific FEC Encoding ID is
Small Block Systematic FEC codes to allow more flexibility and to retain defined for Small Block Systematic FEC codes to allow more
header compactness. The small source block length and small expansion flexibility and to retain header compactness. The small source block
factor that often characterize systematic codes may require the data length and small expansion factor that often characterize systematic
source to frequently change the source block length. To allow the codes may require the data source to frequently change the source
dynamic variation of the source block length and to communicate it to block length. To allow the dynamic variation of the source block
the receivers with low overhead, the block length is included in the FEC length and to communicate it to the receivers with low overhead, the
Payload ID. block length is included in the FEC Payload ID.
The FEC Payload ID is composed of the Source Block Number, Source Block The FEC Payload ID is composed of the Source Block Number, Source
Length and the Encoding Symbol ID: Block 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number | | Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID | | Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Source Block Number idenfities from which source block of the object The Source Block Number identifies from which source block of the
the encoding symbol(s) in the payload are generated. These blocks are object the encoding symbol(s) in the payload are generated. These
numbered consecutively from 0 to N-1, where N is the number of source blocks are numbered consecutively from 0 to N-1, where N is the
blocks in the object. number of source blocks in the object.
The Source Block Length is the length in units of source symbols of the The Source Block Length is the length in units of source symbols of
source block identified by the Source Block Number. the source block identified by the Source Block Number.
The Encoding Symbol ID identifies which specific encoding symbol(s) The Encoding Symbol ID identifies which specific encoding symbol(s)
generated from the source block are carried in the packet payload. Each generated from the source block are carried in the packet payload.
encoding symbol is either an original source symbol or a redundant Each encoding symbol is either an original source symbol or a
symbol generated by the encoder. The exact details of the redundant symbol generated by the encoder. The exact details of the
correspondence between Encoding Symbol IDs and the encoding symbol(s) in correspondence between Encoding Symbol IDs and the encoding symbol(s)
the packet payload are dependent on the particular encoding algorithm in the packet payload are dependent on the particular encoding
used as identified by the Fec Encoding ID and by the FEC Instance ID, algorithm used as identified by the FEC Encoding ID and by the FEC
and these details may be proprietary. Instance ID, and these details may be proprietary.
The FEC Object Transmission Information has the following specific The FEC Object Transmission Information has the following specific
information: information:
o The FEC Encoding ID 129. o The FEC Encoding ID 129.
o The FEC Instance ID associated with the FEC Encoding ID 129 to be o The FEC Instance ID associated with the FEC Encoding ID 129 to be
used. used.
o The total length of the object in bytes. o The total length of the object in bytes.
o The maximum number of encoding symbols that can be generated for any o The maximum number of encoding symbols that can be generated for
source block. This field is provided for example to allow receivers any source block. This field is provided for example to allow
to preallocate buffer space that is suitable for decoding to recover receivers to preallocate buffer space that is suitable for decoding
any source block. to recover any source block.
o For each source block, the length in bytes of encoding symbols for o For each source block, the length in bytes of encoding symbols for
the source block. the source block.
How this out-of-band information is communicated is outside the scope of How this out-of-band information is communicated is outside the scope
this document. As an example the length in bytes of encoding symbols of this document. As an example the length in bytes of encoding
for each source block may be the same for all source blocks. As another symbols for each source block may be the same for all source blocks.
example, the encoding symbol length may be the same for all source As another example, the encoding symbol length may be the same for
blocks of a given object and this length is communicated for each all source blocks of a given object and this length is communicated
object. As a third example, it may be that there is a threshold value for each object. As a third example, it may be that there is a
I, and for all source blocks consisting of less than I source symbols, threshold value I, and for all source blocks consisting of less than
the encoding symbol length is one fixed number of bytes, but for all I source symbols, the encoding symbol length is one fixed number of
source blocks consisting of I or more source symbols, the encoding bytes, but for all source blocks consisting of I or more source
symbol length is a different fixed number of bytes. symbols, the encoding symbol length is a different fixed number of
bytes.
Note that each encoding symbol, i.e., each source symbol and redundant Note that each encoding symbol, i.e., each source symbol and
symbol, must be the same length for a given source block, and this redundant symbol, must be the same length for a given source block,
implies that each source block length is a multiple of its encoding and this implies that each source block length is a multiple of its
symbol length. If the original source block length is not a multiple of encoding symbol length. If the original source block length is not a
the encoding symbol length, it is up to the sending application to multiple of the encoding symbol length, it is up to the sending
appropriately pad the original source block to form the source block to application to appropriately pad the original source block to form
be encoded, and to communicate this padding to the receiving the source block to be encoded, and to communicate this padding to
application. The form of this padding, if used, and how it is the receiving application. The form of this padding, if used, and
communicated to the receiving application, is outside the scope of this how it is communicated to the receiving application, is outside the
document, and must be handled at the application level. scope of this document, and must be handled at the application level.
6. Requirements from other building blocks 6. Requirements from other building blocks
The FEC building block does not provide any support for congestion The FEC building block does not provide any support for congestion
control. Any complete protocol MUST provide congestion control that control. Any complete protocol MUST provide congestion control that
conforms to RFC2357 [5], and thus this MUST be provided by another conforms to RFC 2357 [5], and thus this MUST be provided by another
building block when the FEC building block is used in a protocol. building block when the FEC building block is used in a protocol.
There are no other specific requirements from other building blocks for There are no other specific requirements from other building blocks
the use of this FEC building block. However, any protocol that uses the for the use of this FEC building block. However, any protocol that
FEC building block will inevitably use other building blocks for example uses the FEC building block will inevitably use other building blocks
to provide support for sending higher level session information within for example to provide support for sending higher level session
data packets containing FEC encoding symbols. information within data packets containing FEC encoding symbols.
7. Security Considerations 7. Security Considerations
Data delivery can be subject to denial-of-service attacks by attackers Data delivery can be subject to denial-of-service attacks by
which send corrupted packets that are accepted as legitimate by attackers which send corrupted packets that are accepted as
receivers. This is especially a concern for multicast delivery because legitimate by receivers. This is particularly a concern for
a corrupted packet may be injected into the session close to the root of multicast delivery because a corrupted packet may be injected into
the multicast tree, in which case the corrupted packet will arrive to the session close to the root of the multicast tree, in which case
many receivers. This is especially a concern for the FEC BB because the the corrupted packet will arrive to many receivers. This is
use of even one corrupted packet containing encoding data may result in particularly a concern for the FEC building block because the use of
the decoding of content that is completely corrupted and unusable. It even one corrupted packet containing encoding data may result in the
is thus RECOMMENDED that the decoded content be checked for integrity decoding of an object that is completely corrupted and unusable. It
before delivering the content to an application. For example, an MD5 is thus RECOMMENDED that the decoded objects be checked for integrity
hash [8] of the content may be appended before transmission, and the MD5 before delivering objects to an application. For example, an MD5
hash is computed and checked after the content is decoded but before it hash [8] of an object may be appended before transmission, and the
is delivered to an application. Moreover, in order to obtain strong MD5 hash is computed and checked after the object is decoded but
cryptographic integrity protection a digital signature verifiable by the before it is delivered to an application. Moreover, in order to
receiver SHOULD be computed on top of such a hash value. It is also obtain strong cryptographic integrity protection a digital signature
RECOMMENDED that a packet authentication protocol such as TESLA [7] be verifiable by the receiver SHOULD be computed on top of such a hash
used to detect and discard corrupted packets upon arrival. Furthermore, value. It is also RECOMMENDED that a packet authentication protocol
it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all such as TESLA [7] be used to detect and discard corrupted packets
network routers and switches along the path from the sender to receivers upon arrival. Furthermore, it is RECOMMENDED that Reverse Path
to limit the possibility of a bad agent successfully injecting a Forwarding checks be enabled in all network routers and switches
corrupted packet into the multicast tree data path. along the path from the sender to receivers to limit the possibility
of a bad agent successfully injecting a corrupted packet into the
Another vulnerability of LCT is the potential of receivers obtaining an multicast tree data path.
incorrect session description for the session. The consequences of a
receiver using an incorrect session description could be a denial of
service attack where legitimate receivers with the wrong session
description are unable to correctly receive the session content, or an
attack on network resources where receivers inadvertently try to receive
at a much higher rate than they are capable of because they receive
incorrect information within the session description related to
congestion control, thereby disrupting traffic in portions of the
network. To avoid these problems, it is RECOMMENDED that measures be
taken to prevent receivers from accepting incorrect session
descriptions, e.g., by using source authentication to ensure that
receivers only accept legitimate session descriptions from authorized
senders.
Another security concern is that some FEC information may be obtained by Another security concern is that some FEC information may be obtained
receivers out-of-band in a session description, and if the session by receivers out-of-band in a session description, and if the session
description is forged or corrupted then the receivers will not use the description is forged or corrupted then the receivers will not use
correct protocol for decoding content from received packets. To avoid the correct protocol for decoding content from received packets. To
these problems, it is RECOMMENDED that measures be taken to prevent avoid these problems, it is RECOMMENDED that measures be taken to
receivers from accepting incorrect session descriptions, e.g., by using prevent receivers from accepting incorrect session descriptions,
source authentication to ensure that receivers only accept legitimate e.g., by using source authentication to ensure that receivers only
session descriptions from authorized senders. accept legitimate session descriptions from authorized senders.
8. IANA Considerations 8. IANA Considerations
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA
registration. FEC Encoding IDs and FEC Instance IDs are hierarchical: registration. FEC Encoding IDs and FEC Instance IDs are
FEC Encoding IDs scope ranges of FEC Instance IDs. Only FEC Encoding hierarchical: FEC Encoding IDs scope ranges of FEC Instance IDs.
IDs that correspond to Under-Specified FEC schemes scope a corresponding Only FEC Encoding IDs that correspond to Under-Specified FEC schemes
set of FEC Instance IDs. scope a corresponding set of FEC Instance IDs.
The FEC Encoding ID is a numeric non-negative index. In this document, The FEC Encoding ID is a numeric non-negative index. In this
the range of values for FEC Encoding IDs is 0 and 255. Values from 0 to document, the range of values for FEC Encoding IDs is 0 to 255.
127 are reserved for Fully-Specified FEC schemes and Values from 128 to Values from 0 to 127 are reserved for Fully-Specified FEC schemes and
255 are reserved for Under-Specified FEC schemes, as described in more Values from 128 to 255 are reserved for Under-Specified FEC schemes,
detail in Section 3.1. This specification already assigns the values 128 as described in more detail in Section 3.1. This specification
and 129, as described in Section 5. already assigns the values 128 and 129, as described in Section 5.
Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes
independent range of FEC Instance IDs (i.e. the same value of FEC an independent range of FEC Instance IDs (i.e., the same value of FEC
Instance ID can be reused for different FEC Encoding IDs). An FEC Instance ID can be reused for different FEC Encoding IDs). An FEC
Instance ID is a numeric non-negative index. Instance ID is a numeric non-negative index.
8.1. Explicit IANA Assignment Guidelines 8.1. Explicit IANA Assignment Guidelines
This document defines a name-space for FEC Encoding IDs named: This document defines a name-space for FEC Encoding IDs named:
ietf:rmt:fec:encoding ietf:rmt:fec:encoding
It is IANA's responsibility to establish and manage a new registry for IANA has established and manages the new registry for the
the "ietf:rmt:fec:encoding" name-space. The values that can be assigned "ietf:rmt:fec:encoding" name-space. The values that can be assigned
within the "ietf:rmt:fec:encoding" name-space are numeric indexes in the within the "ietf:rmt:fec:encoding" name-space are numeric indexes in
range [0, 255], boundaries included. Assignment requests are granted on the range [0, 255], boundaries included. Assignment requests are
a "Specification Required" basis as defined in RFC2434 [6]: An IETF RFC granted on a "Specification Required" basis as defined in RFC 2434
MUST exist and specify the FEC Payload ID fields and formats as well as [6]: An IETF RFC MUST exist and specify the FEC Payload ID fields and
the FEC Object Transmission Information for the value of formats as well as the FEC Object Transmission Information for the
"ietf:rmt:fec:encoding" (FEC Encoding ID) being assigned by IANA (see value of "ietf:rmt:fec:encoding" (FEC Encoding ID) being assigned by
Section 3.1 for more details). Note that the values 128 and 129 of IANA (see Section 3.1 for more details). Note that the values 128
"ietf:rmt:fec:encoding" are already assigned by this document as and 129 of "ietf:rmt:fec:encoding" are already assigned by this
described in Section 5. document as described in Section 5.
This document also defines a name-space for FEC Instance IDs named: This document also defines a name-space for FEC Instance IDs named:
ietf:rmt:fec:encoding:instance ietf:rmt:fec:encoding:instance
The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space
associated with the "ietf:rmt:fec:encoding" name-space. Each value of associated with the "ietf:rmt:fec:encoding" name-space. Each value
"ietf:rmt:fec:encoding" assigned in the range [128, 255] has a separate of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a
"ietf:rmt:fec:encoding:instance" sub-name-space that it scopes. Values separate "ietf:rmt:fec:encoding:instance" sub-name-space that it
of "ietf:rmt:fec:encoding" in the range [0, 127] do not scope a scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do
"ietf:rmt:fec:encoding:instance" sub-name-space. not scope a "ietf:rmt:fec:encoding:instance" sub-name-space.
The values that can be assigned within each The values that can be assigned within each
"ietf:rmt:fec:encoding:instance" sub-name-space are non-negative numeric "ietf:rmt:fec:encoding:instance" sub-name-space are non-negative
indices. Assignment requests are granted on a "First Come First Served" numeric indices. Assignment requests are granted on a "First Come
basis as defined in RFC2434 [6]. The same value of First Served" basis as defined in RFC 2434 [6]. The same value of
"ietf:rmt:fec:encoding:instance" can be assigned within multiple "ietf:rmt:fec:encoding:instance" can be assigned within multiple
distinct sub-name-spaces, i.e. the same value of distinct sub-name-spaces, i.e., the same value of
"ietf:rmt:fec:encoding:instance" can be used for multiple values of "ietf:rmt:fec:encoding:instance" can be used for multiple values of
"ietf:rmt:fec:encoding". "ietf:rmt:fec:encoding".
Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST provide Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST
the following information: provide the following information:
- The value of "ietf:rmt:fec:encoding" that scopes the o The value of "ietf:rmt:fec:encoding" that scopes the
"ietf:rmt:fec:encoding:instance" sub-name-space. This must be in "ietf:rmt:fec:encoding:instance" sub-name-space. This must be in
the range [128, 255]. the range [128, 255].
- Point of contact information o Point of contact information
- A pointer to publicly accessible documentation describing the Under- o A pointer to publicly accessible documentation describing the
Specified FEC scheme, associated with the value of Under-Specified FEC scheme, associated with the value of
"ietf:rmt:fec:encoding:instance" assigned, and a way to obtain it "ietf:rmt:fec:encoding:instance" assigned, and a way to obtain it
(e.g. a pointer to a publicly available reference-implementation or (e.g., a pointer to a publicly available reference-implementation
the name and contacts of a company that sells it, either separately or the name and contacts of a company that sells it, either
or embedded in a product). separately or embedded in a product).
It is the responsibility of the requestor to keep all the above It is the responsibility of the requestor to keep all the above
information up to date. information up to date.
9. Intellectual Property Disclosure 9. Intellectual Property Disclosure
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this document. regard to some or all of the specification contained in this
For more information consult the online list of claimed rights. document. For more information consult the online list of claimed
rights.
10. Acknowledgments 10. Acknowledgments
Brian Adamson contributed to this document by shaping Section 5.2 and Brian Adamson contributed to this document by shaping Section 5.2 and
providing general feedback. We also wish to thank Vincent Roca, Justin providing general feedback. We also wish to thank Vincent Roca,
Chapweske and Roger Kermode for their extensive comments. Justin Chapweske and Roger Kermode for their extensive comments.
11. References 11. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
RFC2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Kermode, R., Vicisano, L., ``Author Guidelines for Reliable [3] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol Instantiation Multicast Transport (RMT) Building Blocks and Protocol
documents'', RFC3269, April 2002. Instantiation documents", RFC 3269, April 2002.
[4] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M., [4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
Crowcroft, J., "The use of Forward Error Correction in Reliable J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Multicast", Internet draft draft-ietf-rmt-info-fec-02.txt, January 2002. Reliable Multicast", RFC 3453, December 2002.
[5] Mankin, A., Romanow, A., Bradner, S., Paxson V., "IETF Criteria for [5] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
Evaluating Reliable Multicast Transport and Application Protocols", Criteria for Evaluating Reliable Multicast Transport and
RFC2357, June 1998. Application Protocols", RFC 2357, June 1998.
[6] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and [7] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and
Secure Source Authentication for Multicast", Network and Distributed Secure Source Authentication for Multicast", Network and
System Security Symposium, NDSS 2001, pp. 35-46, February 2001. Distributed System Security Symposium, NDSS 2001, pp. 35-46,
February 2001.
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April 1992. [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[9] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., [9] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.
Luby, M., "Reliable Multicast Transport Building Blocks for One-to-Many and M. Luby, "Reliable Multicast Transport Building Blocks for
Bulk-Data Transfer", RFC3048, January 2001. One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
12. Authors' Addresses 12. Authors' Addresses
Michael Luby Michael Luby
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
Lorenzo Vicisano EMail: luby@digitalfountain.com
lorenzo@cisco.com
cisco Systems, Inc.
Lorenzo Vicisano
Cisco Systems, Inc.
170 West Tasman Dr., 170 West Tasman Dr.,
San Jose, CA, USA, 95134 San Jose, CA, USA, 95134
EMail: lorenzo@cisco.com
Jim Gemmell Jim Gemmell
jgemmell@microsoft.com
Microsoft Research Microsoft Research
301 Howard St., #830 455 Market St. #1690
San Francisco, CA, USA, 94105 San Francisco, CA, 94105
EMail: jgemmell@microsoft.com
Luigi Rizzo Luigi Rizzo
luigi@iet.unipi.it
Dip. di Ing. dell'Informazione Dip. di Ing. dell'Informazione
Universita` di Pisa Universita` di Pisa
via Diotisalvi 2, 56126 Pisa, Italy via Diotisalvi 2, 56126 Pisa, Italy
EMail: luigi@iet.unipi.it
Mark Handley Mark Handley
mjh@icir.org
ICSI Center for Internet Research ICSI Center for Internet Research
1947 Center St. 1947 Center St.
Berkeley CA, USA, 94704 Berkeley CA, USA, 94704
EMail: mjh@icir.org
Jon Crowcroft Jon Crowcroft
J.Crowcroft@cl.cam.ac.uk
Marconi Professor of Communications Systems Marconi Professor of Communications Systems
University of Cambridge University of Cambridge
Computer Laboratory Computer Laboratory
William Gates Building William Gates Building
J J Thomson Avenue J J Thomson Avenue
Cambridge Cambridge
CB3 0FD CB3 0FD
EMail: Jon.Crowcroft@cl.cam.ac.uk
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). 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
assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are included kind, provided that the above copyright notice and this paragraph are
on all such copies and derivative works. However, this document itself included on all such copies and derivative works. However, this
may not be modified in any way, such as by removing the copyright notice document itself may not be modified in any way, such as by removing
or references to the Internet Society or other Internet organizations, the copyright notice or references to the Internet Society or other
except as needed for the purpose of developing Internet standards in Internet organizations, except as needed for the purpose of
which case the procedures for copyrights defined in the Internet developing Internet standards in which case the procedures for
languages other than English. copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
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
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 116 change blocks. 
505 lines changed or deleted 520 lines changed or added

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