path: root/doc/rfc/rfc3452.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L