doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc3452.txt b/doc/rfc/rfc3452.txt
new file mode 100644
index 0000000..a974b6c
--- /dev/null
+++ b/doc/rfc/rfc3452.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document generally describes how to use Forward Error Correction
+   (FEC) codes to efficiently provide and/or augment reliability for
+   data transport.  The primary focus of this document is the
+   application of FEC codes to one-to-many reliable data transport using
+   IP multicast.  This document describes what information is needed to
+   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".
+
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 1]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+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
+
+   This document describes how to use Forward Error Correction (FEC)
+   codes to provide support for reliable delivery of content using IP
+   multicast.  This document should be read in conjunction with and uses
+   the terminology of the companion document [4], which describes the
+   use of FEC codes within the context of reliable IP multicast
+   transport and provides an introduction to some commonly used FEC
+   codes.
+
+   This document describes a building block as defined in RFC 3048 [9].
+   This document is a product of the IETF RMT WG and follows the general
+   guidelines provided in RFC 3269 [3].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in 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.
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 2]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+      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
+
+   FEC codes are a valuable basic component of any transport protocol
+   that is to provide reliable delivery of content.  Using FEC codes is
+   valuable in the context of IP multicast and reliable delivery because
+   FEC encoding symbols can be useful to all receivers for
+   reconstructing content even when the receivers have received
+   different encoding symbols.  Furthermore, FEC codes can ameliorate or
+   even eliminate the need for feedback from receivers to senders to
+   request retransmission of lost packets.
+
+   The goal of the FEC building block is to describe functionality
+   directly related to FEC codes that is common to all reliable content
+   delivery IP multicast protocols, and to leave out any additional
+   functionality that is specific to particular protocols.  The primary
+   functionality described in this document that is common to all such
+   protocols that use FEC codes are FEC encoding symbols for an object
+   that is included in packets that flow from a sender to receivers.
+   This document for example does not describe how receivers may request
+   transmission of particular encoding symbols for an object.  This is
+   because although there are protocols where requests for transmission
+   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 benefits of using FEC codes for reliable content delivery
+   using IP multicast.  FEC codes are also useful in the context of
+   unicast, and thus the scope and applicability of this document is not
+   limited to IP multicast.
+
+3.  Functionality
+
+   This section describes FEC information that is either to be sent
+   out-of-band or in packets.  The FEC information is associated with
+   transmission of data about a particular object.  There are three
+   classes of packets that may contain FEC information: data packets,
+   session-control packets and feedback packets.  They generally contain
+   different kinds of FEC information.  Note that some protocols may not
+   use session-control or feedback packets.
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 3]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   Data packets may sometimes serve as session-control packets as well;
+   both data and session-control packets generally travel downstream
+   from the sender towards receivers and are sent to a multicast channel
+   or to a specific receiver using unicast.
+
+   As a general rule, feedback packets travel upstream from receivers to
+   the sender.  Sometimes, however, they might be sent to a multicast
+   channel or to another receiver or to some intermediate node or
+   neighboring router that provides recovery services.
+
+   This document specifies the FEC information that must be carried in
+   data 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 ID
+
+      Identifies the FEC encoder being used and allows receivers to
+      select the appropriate FEC decoder.  The value of the FEC Encoding
+      ID MUST be the same for all transmission of data related to a
+      particular object, but MAY vary across different transmissions of
+      data about different objects, even if transmitted to the same set
+      of multicast channels and/or using a single upper-layer session.
+      The FEC Encoding ID is subject to IANA registration.
+
+   2) FEC Instance ID
+
+      Provides a more specific identification of the FEC encoder being
+      used for an Under-Specified FEC scheme.  This value is not used
+      for Fully-Specified FEC schemes.  (See Section 3.1 for the
+      definition of Under-Specified and Fully-Specified FEC schemes.)
+      The FEC Instance ID is scoped by the FEC Encoding ID, and is
+      subject to IANA registration.
+
+   3) FEC Payload ID
+
+      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 format of the FEC Payload ID, are determined by the FEC
+      Encoding ID.  The full specification of each field MUST be
+      uniquely determined by the FEC Encoding ID for Fully-Specified FEC
+      schemes, and MUST be uniquely determined by the combination of the
+      FEC Encoding ID and the FEC Instance ID for Under-Specified FEC
+      schemes.  As an example, for the Under-Specified FEC scheme with
+
+
+
+Luby, et. al.                 Experimental                      [Page 4]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+      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
+      Encoding Symbol ID, where the full specification of both of these
+      fields depends on the FEC Instance ID.
+
+   4) FEC Object Transmission Information
+
+      This is information regarding the encoding of a specific object
+      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
+      information might include the lengths of the different source
+      blocks that make up the object and the overall object length.
+      This might also include specific parameters of the FEC encoder.
+
+   The FEC Encoding ID, FEC Instance ID (for Under-Specified FEC
+   schemes) and the FEC Object Transmission Information can be sent to a
+   receiver within the data packet headers, within session control
+   packets, or by some other means.  In any case, the means for
+   communicating this to a receiver is outside the scope of this
+   document.  The FEC Payload ID MUST be included in the data 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
+
+   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 format.
+
+   An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme
+   is 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.
+
+   It is possible that a FEC scheme may not be a Fully-Specified FEC
+   scheme, because either a specification is simply not available or a
+   party exists that owns the encoding scheme and is not willing to
+   disclose the algorithm or specification.  We refer to such an FEC
+   encoding schemes as an Under-Specified FEC scheme.  The following
+   holds for an Under-Specified FEC scheme:
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 5]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   o The fields and their formats of the FEC Payload ID and the specific
+     information in the FEC Object Transmission Information MUST be
+     defined for the Under-Specified FEC scheme.
+
+   o A value for the FEC Encoding ID MUST be reserved and associated
+     with the fields and their formats of the FEC Payload ID and the
+     specific information in the FEC Object Transmission Information.
+     An already reserved FEC Encoding ID value MUST be reused if the
+     associated FEC Payload ID has the same fields and formats and the
+     FEC Object Transmission Information has same information as the
+     ones needed for the new Under-Specified FEC scheme.
+
+   o A value for the FEC Instance ID MUST be reserved.
+
+   An Under-Specified FEC scheme is fully identified by the tuple (FEC
+   Encoding ID, FEC Instance ID).  The tuple MUST identify a single
+   scheme 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 Under-Specified FEC schemes that share the same FEC
+   Encoding ID -- but have different FEC Instance IDs -- also share the
+   same fields and corresponding formats of the FEC Payload ID and
+   specify the same information in the FEC Object Transmission
+   Information.
+
+   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 the values of Under-Specified FEC schemes.
+
+3.2.  FEC Payload ID and FEC Object Transmission Information
+
+   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 Payload ID and specify the information in the FEC Object
+   Transmission Information according to the needs of the encoding
+   scheme.  This applies to documents that reserve values of FEC
+   Encoding IDs for both Fully-Specified and Under-Specified FEC
+   schemes.
+
+   The specification of the fields and their packet formats for the FEC
+   Payload ID MUST specify the meaning of the fields and their format
+   down to the level of specific bits.  The total length of all the
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 6]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   fields in 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.
+
+4.  Applicability Statement
+
+   The FEC building block applies to creating and sending encoding
+   symbols for objects that are to be reliably transported using IP
+   multicast or unicast.  The FEC building block does not provide higher
+   level session support.  Thus, for example, many objects may be
+   transmitted within the same session, in which case a higher level
+   building block may carry a unique Transport Object ID (TOI) for each
+   object in the session to allow the receiver to demultiplex packets
+   within the session based on the TOI within each packet.  As another
+   example, a receiver may subscribe to more than one session at a time.
+
+   In this case a higher level building 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 information directly relevant to the FEC building block to
+   receivers.  For example, the length of the object is part of the FEC
+   Object 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 of packets.  Within the context of FEC repair schemes, feedback
+   packets are (optionally) used to request FEC retransmission.  The
+   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.
+
+   The FEC building block does not provide any support for congestion
+   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.
+
+
+
+Luby, et. al.                 Experimental                      [Page 7]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   A more complete description of the applicability of FEC codes can be
+   found in the companion document [4].
+
+5.  Packet Header Fields
+
+   This section specifies the FEC Encoding ID, the associated FEC
+   Payload ID format, and the specific information in the FEC Object
+   Transmission Information for a number of known Under-Specified FEC
+   schemes.  Under-Specified FEC schemes that use the same FEC Payload
+   ID fields, formats, 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.
+
+5.1.  Small Block, Large Block and Expandable FEC Codes
+
+   This subsection reserves the FEC Encoding ID value 128 for the
+   Under-Specified FEC schemes described in [4] that are called Small
+   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 Symbol ID structured as follows:
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                     Source Block Number                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      Encoding Symbol ID                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Source Block Number identifies from which source block of the
+   object 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.
+
+   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 Instance ID, and these details may be proprietary.
+
+   The FEC Object Transmission Information has the following specific
+   information:
+
+   o The FEC Encoding ID 128.
+
+
+
+Luby, et. al.                 Experimental                      [Page 8]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   o The FEC Instance ID associated with the FEC Encoding ID 128 to be
+     used.
+
+   o The total length of the object in bytes.
+
+   o The number of source blocks that the object is partitioned into,
+     and the length of each source block in bytes.
+
+   To understand how this out-of-band information is communicated, one
+   must look outside the scope of this document.  One example may be
+   that the source block lengths may be derived by a fixed algorithm
+   from the object length.  Another example may be that all source
+   blocks are the same length and this is what is passed out-of-band to
+   the receiver.  A third example could be that the full sized source
+   block length is provided and this is the length used for all but the
+   last source block, which is calculated based on the full source block
+   length and the object length.
+
+5.2.  Small Block Systematic FEC Codes
+
+   This subsection reserves the FEC Encoding ID value 129 for the
+   Under-Specified FEC schemes described in [4] that are called Small
+   Block Systematic FEC codes.  For Small Block Systematic FEC codes,
+   each source block is of length at most 65536 source symbols.
+
+   Although these codes can generally be accommodated by the FEC
+   Encoding ID described in Section 5.1, a specific FEC Encoding ID is
+   defined for Small Block Systematic FEC codes to allow more
+   flexibility and to retain header compactness.  The small source block
+   length and small expansion factor that often characterize systematic
+   codes may require the data source to frequently change 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.
+
+   The FEC Payload ID is composed of the Source Block Number, Source
+   Block Length and the Encoding Symbol ID:
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                     Source Block Number                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |      Source Block Length      |       Encoding Symbol ID      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 9]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   The Source Block Number identifies from which source block of the
+   object 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.
+
+   The Source Block Length is the length in units of source symbols of
+   the source block identified by the Source Block Number.
+
+   The Encoding Symbol ID identifies which specific encoding symbol(s)
+   generated from the source block are carried in the packet payload.
+   Each encoding symbol is either an original source symbol or a
+   redundant symbol generated by the encoder.  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
+   Instance ID, and these details may be proprietary.
+
+   The FEC Object Transmission Information has the following specific
+   information:
+
+   o The FEC Encoding ID 129.
+
+   o The FEC Instance ID associated with the FEC Encoding ID 129 to be
+     used.
+
+   o The total length of the object in bytes.
+
+   o The maximum number of encoding symbols that can be generated for
+     any source block.  This field is provided for example to allow
+     receivers to preallocate buffer space that is suitable for decoding
+     to recover any source block.
+
+   o For each source block, the length in bytes of encoding symbols for
+     the source block.
+
+   How this out-of-band information is communicated is outside the scope
+   of this document.  As an example the length in bytes of encoding
+   symbols for each source block may be the same for all source blocks.
+   As another example, the encoding symbol length may be the same for
+   all source blocks of a given object and this length is communicated
+   for each object.  As a third example, it may be that there is a
+   threshold value I, and for all source blocks consisting of less than
+   I source symbols, the encoding symbol length is one fixed number of
+   bytes, but for all source blocks consisting of I or more source
+   symbols, the encoding symbol length is a different fixed number of
+   bytes.
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 10]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   Note that each encoding symbol, i.e., each source symbol and
+   redundant symbol, must be the same length for a given source block,
+   and this implies that each source block length is a multiple of its
+   encoding symbol length.  If the original source block length is not a
+   multiple of the encoding symbol length, it is up to the sending
+   application to appropriately pad the original source block to form
+   the source block to be encoded, and to communicate this padding to
+   the receiving application.  The form of this padding, if used, and
+   how it is communicated to the receiving application, is outside the
+   scope of this document, and must be handled at the application level.
+
+6.  Requirements from other building blocks
+
+   The FEC building block does not provide any support for congestion
+   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.
+
+   There are no other specific requirements from other building blocks
+   for the use of this FEC building block.  However, any protocol that
+   uses the FEC building block will inevitably use other building blocks
+   for example to provide support for sending higher level session
+   information within data packets containing FEC encoding symbols.
+
+7.  Security Considerations
+
+   Data delivery can be subject to denial-of-service attacks by
+   attackers which send corrupted packets that are accepted as
+   legitimate by receivers.  This is particularly a concern for
+   multicast delivery because a corrupted packet may be injected into
+   the session close to the root of the multicast tree, in which case
+   the corrupted packet will arrive to many receivers.  This is
+   particularly a concern for the FEC building block because the use of
+   even one corrupted packet containing encoding data may result in the
+   decoding of an object that is completely corrupted and unusable.  It
+   is thus RECOMMENDED that the decoded objects be checked for integrity
+   before delivering objects to an application.  For example, an MD5
+   hash [8] of an object may be appended before transmission, and the
+   MD5 hash is computed and checked after the object is decoded but
+   before it is delivered to an application.  Moreover, in order to
+   obtain strong cryptographic integrity protection a digital signature
+   verifiable by the receiver SHOULD be computed on top of such a hash
+   value.  It is also RECOMMENDED that a packet authentication protocol
+   such as TESLA [7] be used to detect and discard corrupted packets
+   upon arrival.  Furthermore, it is RECOMMENDED that Reverse Path
+   Forwarding checks be enabled in all network routers and switches
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 11]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   along the path from the sender to receivers to limit the possibility
+   of a bad agent successfully injecting a corrupted packet into the
+   multicast tree data path.
+
+   Another security concern is that some FEC information may be obtained
+   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 correct protocol for decoding content from received packets.  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.
+
+8.  IANA Considerations
+
+   Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA
+   registration.  FEC Encoding IDs and FEC Instance IDs are
+   hierarchical:  FEC Encoding IDs scope ranges of FEC Instance IDs.
+   Only FEC Encoding IDs that correspond to Under-Specified FEC schemes
+   scope a corresponding set of FEC Instance IDs.
+
+   The FEC Encoding ID is a numeric non-negative index.  In this
+   document, the range of values for FEC Encoding IDs is 0 to 255.
+   Values from 0 to 127 are reserved for Fully-Specified FEC schemes and
+   Values from 128 to 255 are reserved for Under-Specified FEC schemes,
+   as described in more detail in Section 3.1.  This specification
+   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 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 is a numeric non-negative index.
+
+8.1.  Explicit IANA Assignment Guidelines
+
+   This document defines a name-space for FEC Encoding IDs named:
+
+                           ietf:rmt:fec:encoding
+
+   IANA has established and manages the new registry for the
+   "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 range [0, 255], boundaries included.  Assignment requests are
+   granted on a "Specification Required" basis as defined in RFC 2434
+   [6]: An IETF RFC MUST exist and specify the FEC Payload ID fields and
+   formats as well as the FEC Object Transmission Information for the
+   value of "ietf:rmt:fec:encoding" (FEC Encoding ID) being assigned by
+   IANA (see Section 3.1 for more details).  Note that the values 128
+
+
+
+Luby, et. al.                 Experimental                     [Page 12]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+   and 129 of "ietf:rmt:fec:encoding" are already assigned by this
+   document as described in Section 5.
+
+   This document also defines a name-space for FEC Instance IDs named:
+
+                      ietf:rmt:fec:encoding:instance
+
+   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 "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a
+   separate "ietf:rmt:fec:encoding:instance" sub-name-space that it
+   scopes.  Values of "ietf:rmt:fec:encoding" in the range [0, 127] do
+   not scope a "ietf:rmt:fec:encoding:instance" sub-name-space.
+
+   The values that can be assigned within each
+   "ietf:rmt:fec:encoding:instance" sub-name-space are non-negative
+   numeric indices. Assignment requests are granted on a "First Come
+   First Served" basis as defined in RFC 2434 [6].  The same value of
+   "ietf:rmt:fec:encoding:instance" can be assigned within multiple
+   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".
+
+   Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST
+   provide the following information:
+
+   o The value of "ietf:rmt:fec:encoding" that scopes the
+     "ietf:rmt:fec:encoding:instance" sub-name-space.  This must be in
+     the range [128, 255].
+
+   o Point of contact information
+
+   o A pointer to publicly accessible documentation describing the
+     Under-Specified FEC scheme, associated with the value of
+     "ietf:rmt:fec:encoding:instance" assigned, and a way 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 a product).
+
+   It is the responsibility of the requestor to keep all the above
+   information up to date.
+
+9.  Intellectual Property Disclosure
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+
+
+Luby, et. al.                 Experimental                     [Page 13]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+10.  Acknowledgments
+
+   Brian Adamson contributed to this document by shaping Section 5.2 and
+   providing general feedback.  We also wish to thank Vincent Roca,
+   Justin Chapweske and Roger Kermode for their extensive comments.
+
+11.  References
+
+   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+       9, RFC 2026, October 1996.
+
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [3] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
+       Multicast Transport (RMT) Building Blocks and Protocol
+       Instantiation documents", RFC 3269, April 2002.
+
+   [4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
+       J. Crowcroft, "The Use of Forward Error Correction (FEC) in
+       Reliable Multicast", RFC 3453, December 2002.
+
+   [5] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
+       Criteria for Evaluating Reliable Multicast Transport and
+       Application Protocols", RFC 2357, June 1998.
+
+   [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [7] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and
+       Secure Source Authentication for Multicast", Network and
+       Distributed System Security Symposium, NDSS 2001, pp. 35-46,
+       February 2001.
+
+   [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+       1992.
+
+   [9] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.
+       and M. Luby, "Reliable Multicast Transport Building Blocks for
+       One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
+
+
+
+
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 14]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+12.  Authors' Addresses
+
+   Michael Luby
+   Digital Fountain, Inc.
+   39141 Civic Center Drive
+   Suite 300
+   Fremont, CA  94538
+
+   EMail: luby@digitalfountain.com
+
+   Lorenzo Vicisano
+   Cisco Systems, Inc.
+   170 West Tasman Dr.,
+   San Jose, CA, USA, 95134
+
+   EMail: lorenzo@cisco.com
+
+   Jim Gemmell
+   Microsoft Research
+   455 Market St. #1690
+   San Francisco, CA, 94105
+
+   EMail: jgemmell@microsoft.com
+
+   Luigi Rizzo
+   Dip. di Ing. dell'Informazione
+   Universita` di Pisa
+   via Diotisalvi 2, 56126 Pisa, Italy
+
+   EMail: luigi@iet.unipi.it
+
+   Mark Handley
+   ICSI Center for Internet Research
+   1947 Center St.
+   Berkeley CA, USA, 94704
+
+   EMail: mjh@icir.org
+
+   Jon Crowcroft
+   Marconi Professor of Communications Systems
+   University of Cambridge
+   Computer Laboratory
+   William Gates Building
+   J J Thomson Avenue
+   Cambridge
+   CB3 0FD
+
+   EMail: Jon.Crowcroft@cl.cam.ac.uk
+
+
+
+Luby, et. al.                 Experimental                     [Page 15]
+
+RFC 3452                   FEC Building Block              December 2002
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included 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 or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   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
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 16]
+